Dette trenger du før du starter
Velg én avgrenset oppgave, for eksempel overføring av en godkjent ordre til et planleggingssystem. Ta med en medarbeider som utfører oppgaven og en person som kjenner systemene.
Ha tilgang til systemenes navn, rutinebeskrivelser og noen eksempler dere har lov til å bruke. Konstruerte data er tilstrekkelig for å skissere prosessen. Dere trenger ikke kjøpe programvare for å gjøre kartleggingen.
Et prosesskart viser rekkefølgen på arbeidet. Microsoft beskriver også hvordan prosesskart kan brukes til å finne automatiseringsmuligheter i Power Automate. Fremgangsmåten nedenfor er et eget, verktøyuavhengig arbeidsopplegg. Kilde: Microsoft Learn.
Forventet resultat: En beskrivelse av dagens arbeidsflyt, et utfylt arbeidsark og ett avgrenset forslag dere kan diskutere med en leverandør.
1. Bestem start og slutt
Skriv to setninger:
- Arbeidet starter når en ordre er godkjent.
- Arbeidet er ferdig når ordren er registrert og bekreftet i planleggingssystemet.
Dette er et konstruert eksempel. Bruk deres egne hendelser. Unngå å kartlegge hele virksomheten i første runde.
2. Følg en sak gjennom dagens arbeid
Be medarbeideren vise hvert steg. Noter også det som skjer utenfor systemet: en telefon, en e-post eller en kontroll mot et regneark.
Skill mellom arbeidstid og ventetid. En sak som ligger i en innboks til neste dag, har ikke nødvendigvis tatt en hel arbeidsdag å behandle.
Noter hvilke opplysninger som skrives inn på nytt. Spør hva som skjer dersom noen oppdager en feil etterpå: Hvor blir den rettet, og må rettingen gjentas flere steder?
3. Fyll ut et enkelt arbeidsark
Kopier tabellen og fyll ut ett arbeidsark per overføring. Eksempelkolonnen viser en konstruert ordreoverføring.
| Felt | Eksempel | Deres prosess |
|---|---|---|
| Oppgave | Registrere godkjent ordre i planlegging | |
| Starthendelse | Ordren får status «godkjent» | |
| Kildesystem | Ordresystem | |
| Mottakersystem | Planleggingssystem | |
| Opplysninger som flyttes | Ordrenummer, varenummer, antall, leveringsdato | |
| Kobling mellom registreringene | Unikt ordrenummer | |
| Autoritativ kilde | Ordresystemet eier ordredetaljene | |
| Ansvarlig for avvik | Navngitt rolle i drift | |
| Arbeidstid per sak | Måles; kontroll og retting tas med | |
| Antall saker | Måles over en representativ periode | |
| Vanlige unntak | Endret ordre, duplikat, ukjent varenummer | |
| Mulig overføringsmåte | Avklar API eller støttet import med leverandøren |
«Autoritativ kilde» betyr hvilket system dere stoler på hvis systemene viser forskjellige verdier. Det kan være nødvendig å velge kilde per opplysning: Ordresystemet eier antallet, mens planleggingssystemet eier faktisk utførelsesdato.
4. Finn unntakene
Gå gjennom minst disse situasjonene som diskusjonspunkter:
- Ordren endres etter at den er overført.
- Overføringen forsøkes to ganger.
- Et obligatorisk felt er tomt.
- Systemet som skal motta data, er utilgjengelig.
- Varenummeret finnes bare i ett av systemene.
Beskriv ønsket handling ved hvert unntak. Skal saken vente, sendes tilbake eller varsles til en bestemt person?
En løsning er lettere å vurdere når dere også vet hva den skal gjøre utenfor normaltilfellene.
5. Velg én overføring å forbedre først
Se etter en oppgave der dataene er tydelige, ansvaret er avklart og resultatet kan kontrolleres. Vurder både nytte og konsekvensen av feil.
Hvis opplysningene allerede finnes i faste felt, bør en vanlig integrasjon vurderes. Hvis noen først må tolke fritekst, kan denne tolkningen behandles som et eget steg.
Be systemleverandørene bekrefte hvilke muligheter som faktisk finnes. At et system har et API, sier ikke alene at det gir tilgang til de nødvendige opplysningene eller handlingene.
Hvis dere er usikre på om oppgaven krever tolkning eller faste regler, kan dere bruke vurderingene i AI eller vanlig automatisering? Slik velger bedriften.
6. Skriv hva en vellykket test skal vise
Formuler krav dere kan kontrollere. For eksempel:
- En godkjent testordre opprettes i mottakersystemet med riktig antall.
- Et nytt forsøk på samme overføring oppretter ikke en ekstra ordre.
- En ordre uten varenummer blir stående til avklaring.
- Den ansvarlige får beskjed hvis en overføring feiler.
- En avtalt endring kan spores fra kilde til mottaker.
Dette er forslag til akseptansekriterier: Vilkår dere bruker for å avgjøre om leveransen fungerer. Leverandøren må bekrefte hvordan kravene kan oppfylles i deres systemer.
Ta også med situasjonen der mottakeren har lagret ordren, men avsenderen ikke får bekreftelsen. Be leverandøren vise hvordan et nytt forsøk unngår å opprette en ekstra ordre. Stripe dokumenterer en slik mekanisme med en egen nøkkel for å kjenne igjen gjentatte forespørsler. Dette kalles idempotens: Samme operasjon kan gjentas uten en ekstra virkning. Andre systemers støtte og begrensninger må avklares konkret. Kilde: Stripe om idempotente forespørsler.
Et ordrenummer hjelper dere å koble registreringer sammen, men er ikke alene en garanti mot duplikater. Avklar også hvordan løsningen skiller et nytt forsøk fra en faktisk endring av ordren.
7. Gjør kartleggingen til en konkret bestilling
Her er et konstruert eksempel, ikke en kundehistorie eller en ferdig teknisk spesifikasjon. Alle systemnavn, testdata og ønskede tidsgrenser er eksempler som må tilpasses og avklares med leverandøren.
Oppgaven: Vi vil overføre godkjente ordrer fra ordresystemet til planleggingssystemet. Første leveranse gjelder opprettelse og endring før arbeidet starter. Fakturering og historiske ordrer er utenfor denne leveransen. Kansellering skal fanges opp og gå til manuell avklaring.
Data og ansvar: Testordre TEST-1042 har vare V-17, antall 12 og leveringsdato 30.09.2026. Ordresystemet er kilden for disse feltene. Planleggingssystemet eier faktisk utførelsesdato. Leverandøren må avklare hvilke identifikatorer som trengs for ordre og ordrelinjer, og hvordan varenummer kobles mellom systemene.
Tidsbehov: I eksemplet ønsker vi at en godkjent ordre blir synlig innen fem minutter ved normal drift. Dette er et foreslått krav, ikke en bekreftet egenskap. Be leverandøren forklare kostnad og konsekvenser, og vurder om en sjeldnere overføring er tilstrekkelig.
Oppfølging: Driftsansvarlig skal kunne finne saker som venter eller feiler, se hvilken ordre det gjelder og forstå neste handling. Avtal hvem som følger opp, innen hvilken frist og hvem som overtar ved fravær.
Knytt bestillingen til en kort testtabell:
| Test i et avtalt testmiljø | Ønsket resultat i eksemplet |
|---|---|
| Godkjenn TEST-1042 | Én ordre med riktig vare, antall og dato blir synlig innen avtalt frist. |
| Gjenta samme overføring | Det finnes fortsatt bare én ordre. |
| Bryt forbindelsen etter lagring, før bekreftelse | Et kontrollert nytt forsøk gir ingen ekstra ordre. |
| Endre antallet fra 12 til 10 før oppstart | Den eksisterende ordren oppdateres, og endringen kan spores. |
| Send en ordre med ukjent varenummer | Saken står til avklaring uten at systemet gjetter en erstatning. |
| La mottakeren være utilgjengelig | Saken vises som uavklart og kan følges opp uten dobbel registrering. |
| Kanseller en overført ordre | Saken fanges opp for manuell avklaring før videre arbeid. |
Avtal hva dere gjør mens integrasjonen er stanset. Hvis noen registrerer en ordre manuelt, må dette kunne avstemmes før automatiske forsøk fortsetter. Be om en demonstrasjon av gjenopptakelsen, og avklar hvem som godkjenner den.
Send eksemplet sammen med arbeidsarket. Be leverandøren merke hvert punkt som bekreftet mulig, avhengig av nærmere undersøkelse eller utenfor tilbudet. Da blir usikkerheten synlig før dere bestiller utvikling.
Vanlige feil i kartleggingen
Bare å beskrive ønsket løsning: «Vi vil ha AI» sier lite om data, ansvar og unntak. Start med arbeidsoppgaven.
Bare å telle tastetrykk: Kontroll, leting og retting tar også tid. Ta dem med når dere måler.
Å hoppe over endringer: Avklar hva som skjer etter første overføring, særlig ved kansellering og korrigering.
Å sende ekte kundedata for tidlig: Bruk konstruerte eksempler i første skisse. Avklar tilgang og databehandling før reelle opplysninger deles.
Dette kan du sende til en leverandør
Samle arbeidsarket, en enkel tegning av stegene og de viktigste testkravene. Be om en vurdering av gjennomførbarhet, begrensninger, etableringskostnad og løpende oppfølging.
Digital Flow tilbyr integrasjoner og automasjon. Send oss en beskrivelse av prosessen, så har dere et konkret utgangspunkt for å avklare neste steg.