Hvilke prosesser det lønner seg å automatisere, og hvordan du kjenner dem igjen

Fire spørsmål du kan sile det daglige arbeidet med selv: er det en kjede med et resultat, får maskinen data eller et bilde, avgjør steget noe om et menneske, og har prosessen allerede en ytre frist.

Spørsmålet «hva burde vi automatisere» kommer som regel for sent, fordi det tar for gitt at svaret er en liste over verktøy. I praksis har de fleste mislykkede automatiseringsprosjektene startet med riktig verktøy lagt oppå feil valgt arbeid, og det var valget, ikke verktøyet, som avgjorde resultatet.

Denne artikkelen prøver ikke å definere hva automatisering av forretningsprosesser er, fordi definisjonen ikke avgjør noe; i stedet gir den fire spørsmål du kan sile det daglige arbeidet med selv, og etter hvert spørsmål viser den hvordan et tilfelle som består ser ut, og et som ikke består. Silen koster ingenting og tar én ettermiddag, men sparer mer enn en hvilken som helst verktøysammenligning, fordi den svarer på det tidligste spørsmålet i kjeden.

Første spørsmål: er det en kjede med et resultat eller en rekke klikk

Dette er grensen som skiller mest, og den er verdt å trekke nøyaktig: en prosess er en kjede av handlinger med inndata, et resultat og en eier: faktura fra ordre, innmelding av ny medarbeider, kundehenvendelsen fra skjema til svar. En prosedyre, eller en enkelt handling, er hvordan et steg gjøres: hvor du klikker, hva du limer inn, hvilket felt nummeret skal stå i.

Begge deler kan automatiseres, men avkastningen er flere ganger så stor, og nettopp derfor er rekkefølgen viktig: automatiserer du kjeden, endrer du resultatet — dokumentet kommer inn i regnskapet av seg selv, og ingen kopierer det lenger. Automatiserer du en rekke klikk, gjør du ett steg raskere i en kjede som ellers er den samme, og gevinsten er akkurat så stor som det ene stegets andel var.

Den praktiske måten å kjenne det igjen på er å spørre hva som skjer med resultatet etterpå, og svaret sier som regel alt: er det «så tar noen denne filen og legger den inn i et annet system», fortsetter kjeden, og å automatisere ett steg er å flytte flaskehalsen, ikke å fjerne den. Er svaret «så er jobben ferdig og resultatet ligger i systemet», har du en prosess med et tydelig sluttpunkt, og det er slike det lønner seg å ta først.

La oss ta én typisk kjede og følge den til endes, fordi det er nettopp følgingen som viser hvor gevinsten faktisk ligger: kunden fyller ut et skjema på nettstedet, henvendelsen kommer på e-post, noen taster den inn i kundesystemet, noen andre lager et tilbud, og etter godkjenning skriver enda noen ut fakturaen i regnskapssystemet. Her er det én prosess med et tydelig resultat (fra henvendelse til faktura), og i den er det minst tre steder der de samme dataene tastes inn på nytt, hver gang med mulighet for å ta feil.

Automatiserer du fra denne kjeden bare det å taste henvendelsen inn i kundesystemet, er gevinsten reell, men liten, fordi de to andre overføringene blir igjen. Automatiserer du hele kjeden, endres selve arbeidets karakter: mennesket kopierer ikke lenger, men kontrollerer og tar beslutninger der de virkelig trengs. Nettopp derfor lønner det seg å tegne kjedens grenser før enhver samtale om verktøy, fordi de avgjør hvor stor den mulige gevinsten er.

Kjeden har også en eier, og det er et spørsmål som ofte blir stående ustilt. Kan ingen bestemt person si hvordan prosessen går fra start til slutt, blir automatiseringen en rekke antakelser om hvordan den antakelig foregår, og det første virkelige tilfellet vil knuse dem. Å finne eieren tar som regel én samtale, men sparer flere uker, så det er den billigste delen av prosjektet.

Andre spørsmål: får maskinen data eller et bilde

Dette er den viktigste tekniske forskjellen i hele automatiseringen, og i Norge har den nå også en rettslig side. Får systemet strukturerte data (XML, JSON, en post i en database), kan det behandle dem uten å gjette. Får det et bilde, det vil si en PDF-fil eller et skannet ark, må noen før behandlingen gjette hva som står der, og nettopp denne gjettingen skaper feilene noen senere retter for hånd.

Fakturaeksemplet viser det best, fordi begge mulighetene lever side om side der og kalles nesten det samme. En strukturert elektronisk faktura, i dagligtale også kalt EHF-faktura, er et maskinlesbart dokument i et bestemt format — i Norge EHF (Elektronisk handelsformat), som bygger på den europeiske standarden EN 16931 og Peppol BIS Billing 3.0. Mottakerens system kan bokføre den uten at et menneske er med, og det er nettopp dette formatet de rettslige fristene gjelder.

En PDF-faktura mottakeren har godtatt å motta elektronisk, er også et gyldig dokument: den er et gyldig salgsdokument etter bokføringsregelverket. Men gyldig er den som salgsdokument, ikke som elektronisk faktura slik forskrift om elektronisk faktura i offentlige anskaffelser § 3 definerer det, og for maskinen er den fortsatt et bilde.

Derav følger en konklusjon som sparer mye penger: Å kjenne igjen PDF-fakturaer med OCR (optisk tegngjenkjenning) er ikke innføring av EHF-faktura. Det er en egen handling folk med rette automatiserer, fordi den kutter kopieringen, men den skaper ikke et strukturert dokument og oppfyller ikke plikten til å utstede et. En virksomhet som tar OCR som svar på et rettslig krav, oppdager etter et par år at den har automatisert feil ende, og da må prosjektet startes på nytt med systemet som utsteder fakturaene, ikke med det som tar dem imot.

Den praktiske sjekken her er enkel: spør i hvilket format systemet kan levere data og ta imot dem. Er svaret «vi kan eksportere CSV», er det allerede strukturerte data, bare ufullstendig automatisert. Er svaret «vi kan skrive ut» eller «vi kan lagre som PDF», er bildet det eneste uttaket, og det videre arbeidet krever enten et grensesnitt eller blir stående som gjetting.

Svaret er ofte bedre enn bedriften tror, fordi mange regnskaps- og lagersystemer har et grensesnitt, det er bare det at ingen noensinne har spurt etter det, siden det daglige arbeidet klarer seg med eksport. Ett spørsmål til leverandøren om systemet har et programvaregrensesnitt (API) og hva det kan brukes til, avgjør ofte om prosjektet i det hele tatt er verdt å starte.

Tredje spørsmål: avgjør steget noe om et menneske

Det meste av automatisering er å flytte tall mellom systemer, og der er det ingen særlige juridiske spørsmål. Det finnes likevel én gruppe steg som må kjennes igjen for seg: de stegene som avgjør noe om et bestemt menneske — om personen skal ansettes, få kreditt, sies opp eller få en ytelse.

Personvernforordningen artikkel 22 om automatiserte individuelle avgjørelser, herunder profilering, gir rett til ikke å underlegges en avgjørelse som utelukkende bygger på automatisert behandling og som har rettsvirkning eller på tilsvarende måte påvirker vedkommende i betydelig grad. Unntak finnes (nødvendig for en avtale, lov med egnede vernetiltak, uttrykkelig samtykke), men også da står retten til menneskelig inngripen, til å si sin mening og til å bestride avgjørelsen. Tilsynsmyndighetenes retningslinjer legger til en nyanse: den menneskelige inngripenen må være reell, og en formell godkjenningsknapp noen trykker uten å se på innholdet, tar ikke prosessen ut av artikkel 22.

Det er ikke et forbud mot å automatisere, men en anvisning om hva som i en slik prosess kan automatiseres: du kan automatisere det forberedende arbeidet (å samle data, kontrollere, lage et forslag), men selve avgjørelsen blir hos mennesket som virkelig tar den. I praksis endrer det prosjektets omfang, så det lønner seg å merke det før utviklingen, ikke etter.

Ved siden av det er det verd å kjenne én frist som ennå ikke er kommet, men som påvirker de langsiktige planene: kravene i KI-forordningen til høyrisikosystemer på ansettelsesområdet, det vil si utvelgelse og personalbeslutninger, begynner å gjelde 2. desember 2027. Det betyr at valget i dag er friere, men for et system du bygger for lang sikt, må denne datoen inn i planen.

Fjerde spørsmål: har prosessen allerede en ytre frist

For en del prosesser settes fristen ikke av bedriftens prioriteringer, men av en ytre plikt, og de flytter seg av seg selv til toppen av listen, fordi det ikke lenger er spørsmål om å gjøre, bare om når og hvordan. I Norge er det tydeligste eksempelet igjen fakturaer, og der er det tre datoer som pleier å bli blandet.

For det første har en virksomhet som sender faktura til offentlig virksomhet, brukt det strukturerte formatet siden 2. april 2019. For det andre skal bokføringspliktige fra 1. januar 2027 utstede elektronisk faktura til en annen bokføringspliktig. For det tredje skal bokføringen skje i et elektronisk regnskapssystem som tar imot og behandler e-faktura automatisk fra 1. januar 2030, og fram dit gjelder overgangsregler for plikten til å motta.

Nettopp B2B-datoen er den som i omløp oftest er feil, og grunnen er enkel: det opprinnelige forslaget la opp til 2028, det ble senere trukket fram til 2027, og en del andrehåndsartikler rettet det aldri. For en virksomhet som planlegger budsjett er forskjellen mellom to år stor, så datoen er verdt å sjekke i førstehåndskilden, ikke i et referat.

Ytre frister finnes også andre steder: arbeidstiden skal kunne vises i en oversikt som er tilgjengelig, regnskapsdokumenter har oppbevaringsfrister, og i avtaler pleier det å stå rapporteringsdatoer. Det felles er at disse fristene ikke er til diskusjon, og en prosess som har en slik, gir et tydelig grunnlag for arbeidet — til forskjell fra en prosess du automatiserer fordi det virker moderne.

Slik ser en prosess ut som det lønner seg å ta først

Slår du sammen alle fire spørsmålene, blir det et konkret portrett du kan legge ved en hvilken som helst liste: den verdifulleste første kandidaten er en kjede med et tydelig resultat, der dataene allerede finnes strukturert eller kan bli det, der ingen steg avgjør noe om et menneske, og som har en ytre frist eller i det minste et målbart omfang.

I praksis ser det som regel slik ut: ordren fra butikken kommer inn i regnskapssystemet uten å kopieres over; en godkjenningskjede der henvendelsen går til riktig person og kommer tilbake med et merke; datasynkronisering mellom lager og nettsted, der et menneske i dag eksporterer en fil to ganger om dagen. Alle tre har ett felles kjennetegn — mellom to systemer går det i dag et menneske med en fil.

Nettopp dette kjennetegnet er lettest å få øye på og vanskeligst å glemme, så det lønner seg å starte kartleggingen der. Skriv ned hvor noen i bedriften din eksporterer, limer inn eller taster inn på nytt, hvor ofte og hvor lenge. Listen er som regel kortere enn ventet, og i den er det nesten alltid én post som skiller seg ut.

Det andre kjennetegnet som løfter en kandidat, er prisen på en feil, og den blir som regel hoppet over i regnestykkene: betyr en kopieringsfeil i denne kjeden feil faktura til kunden, feil beholdning på lageret eller en oversittet frist, er gevinsten av automatisering ikke bare de sparte timene, men også de unngåtte feilene, og det er som regel det største av de to tallene. En prosess der feilen er usynlig og ufarlig, er i så måte en mindre verdifull kandidat, selv om den tar like lang tid.

Det tredje kjennetegnet er hvordan omfanget endrer seg med bedriften, og det er det viktigste av de tre: arbeid som vokser med bedriften, fordi flere ordrer betyr mer kopiering, blir med tiden stadig dyrere, og nettopp der betaler automatiseringen seg dobbelt: den frigjør tid i dag og tar bort en kostnad som ellers ville vokst. Arbeid med uendret omfang uavhengig av omsetningen gir ikke denne andre gevinsten.

Til portrettet hører også én ting om rekkefølgen, fordi bedrifter tar oftere feil der enn i valg av verktøy: den første automatiserte prosessen skal ikke velges etter hvilken som er størst eller vondest, men etter hvilken som er best forstått og raskest ferdig, fordi det første prosjektet lærer bedriften hvordan slike prosjekter foregår — hvordan du beskriver unntak, tester og håndterer feil. Den læringen er mye billigere å få på et enkelt arbeid enn på det pengestrømmen henger på.

Slik ser en prosess ut som det ikke lønner seg å ta først

Like nyttig som å kjenne igjen en god kandidat er å kjenne igjen det som ser tiltalende ut, men betaler seg dårlig, og slike tilfeller er det fire av. Det første er arbeid som skjer sjelden (en gang i kvartalet eller en gang i året), fordi utviklingskostnaden blir den samme, mens innsparingen deles på fire eller på én.

Det andre er en prosess hvis orden ennå skifter, og det er tilfellet der hastverket koster dyrest: er ordenen endret tre ganger det siste halve året, vil automatiseringen låse den versjonen som likevel snart skifter, og vedlikeholdet spiser gevinsten. Her er riktig rekkefølge først å bli enige om ordenen og først deretter automatisere den, selv om det i praksis ofte skjer omvendt.

Det tredje er arbeid der hvert tilfelle er et unntak, og der ligger grensen i selve oppgavens natur, fordi automatisering takler det hyppige og forutsigbare godt, men dårlig en situasjon der ti tilfeller har ti ulike veier; der er menneskets skjønn selve arbeidet, og å erstatte det med et regeltre skaper som regel flere unntak enn det fjerner.

Disse tre tilfellene har ett kjennetegn felles: i dem låser automatiseringen noe som ennå ikke er klart til å låses. Det sjeldne arbeidet er ikke tilstrekkelig innarbeidet til at det lønner seg å støpe det; den skiftende prosessen leter ennå etter formen sin; unntaksarbeid er i bunnen skjønn. I alle tre er riktig handling å vente eller først rydde, ikke å automatisere fortere.

Det fjerde er tilfellet der skjermen imiteres fordi systemet ikke har et grensesnitt. Det er av og til den eneste mulige veien, men det er også den skjøreste: det holder med én endring på skjermen, så stanser arbeidet. Har systemet et grensesnitt, eller kan du kreve et, er det nesten alltid et gunstigere valg enn å imitere skjermen.

Hva skjer med menneskene hvis arbeid automatiseres

Dette spørsmålet går automatiseringstilbud som regel utenom, selv om det stilles i bedriften allerede den første dagen, og ubesvart blir det en stille motstand som kan stanse prosjektet sikrere enn et hvilket som helst teknisk problem. Det ærlige svaret i de fleste små og mellomstore bedrifter er at automatisering frigjør tid, ikke et menneske: kopieringen er den delen av arbeidet ingen vil ha, og når den forsvinner, rekker det samme mennesket som regel endelig det det tidligere ikke var tid til.

Derav følger en praktisk anbefaling som høres myk ut, men er et rent prosjektledelsesspørsmål: mennesket som gjør arbeidet i dag, skal trekkes inn i prosjektet som den kyndigste kilden, ikke informeres om resultatet. Vedkommende kjenner unntakene ingen har skrevet ned, og det er nettopp unntakene som knuser automatiseringen. Et prosjekt der denne samtalen skjer i starten, koster mindre enn ett der den skjer etter den første feilen.

Det er også ærlig å si den andre siden, fordi det motsatte ville være å late som: består noens arbeid i bedriften fullt og helt av å flytte data mellom to systemer, da erstatter automatiseringen virkelig dette arbeidet, og det er en samtale om rollebytte som styres av bedriftens ledelse, ikke av leverandøren. Et tilbud som ikke stiller dette spørsmålet i det hele tatt, er ikke fintfølende — det er ganske enkelt ikke tenkt ferdig.

Slik regner du ut ditt eget tall

Regnestykket som trengs til beslutningen, får plass på én side og krever verken konsulent eller undersøkelse. Du trenger fire tall: hvor mange ganger i uken dette arbeidet skjer, hvor mange minutter det tar hver gang, hva timen koster for mennesket som gjør det, og hvor ofte det oppstår en feil noen siden retter.

De tre første gir den direkte tidskostnaden i året, og dette tallet er som regel mindre enn ventet — nettopp derfor lykkes det ofte ikke å begrunne prosjektet med det alene. Det fjerde tallet er det som for det meste avgjør, fordi prisen på en feil sjelden bare er tiden det tar å rette den: feil faktura betyr korrespondanse med kunden, feil beholdning betyr enten en vare som blir usolgt, eller en bestilling av en vare som ikke lenger er på lager, og en oversittet frist betyr av og til gebyr.

Mot disse tallene setter du utviklingskostnaden og vedlikeholdet, og det er nettopp vedlikeholdet som glemmes. En automatisering som kobler to systemer, lever bare så lenge begge grensesnittene lever, så i planen må det være plass til endringer noen andre vil kreve. Betaler regnestykket seg bare når vedlikeholdskostnaden ikke telles med, betaler det seg i virkeligheten ikke i det hele tatt.

En ting til det lønner seg å avklare før samtalen, er hvor ofte systemene skifter. En skytjeneste som oppdaterer seg selv, kan endre grensesnittet uten varsel, mens et lokalt installert program blir stående uendret i årevis, men når det først oppdateres, krever det av og til at alt sjekkes på nytt. Ingen av de to variantene er dårligere, men de krever ulik vedlikeholdsplan, og et tilbud som ikke speiler det, vil være for billig akkurat der kostnadene senere oppstår.

Hvorfor du ikke skal stole på prosentene fra undersøkelsene

I automatiseringstilbud dukker det nesten alltid opp et tall: at halvparten av arbeidet kan automatiseres, at prosjektene mislykkes i en tredjedel av tilfellene, at noen sparte titusenvis av timer. Disse tallene finnes og kan siteres, men de beskriver nesten aldri den bedriften de vises til, og nettopp det gjør dem til et dårlig grunnlag for en beslutning.

Det mye siterte målet om at en stor del av arbeidet kan automatiseres, er et regnestykke over aktiviteter i lønnsmassen i et bestemt land og et bestemt år, med det årets teknologi, og det ble offentliggjort av et konsulentselskap som selger akkurat denne tjenesten. Målet for prosjektsvikter kommer fra en konsulents erfaring med kunder som tilkalte ham etter de første sviktene, så utvalget er skjevt allerede per definisjon. Tallet for sparte timer beskriver en bestemt regnskapsavdeling på førti mennesker i et annet land for flere år siden.

Derav følger ikke at automatisering ikke lønner seg, men at det riktige tallet er ditt eget: hvor mange ganger i uken dette arbeidet skjer, hvor lenge det tar og hva timen koster. Dette regnestykket kan du lage på én side, det beskriver nettopp din bedrift, og det er det eneste det lønner seg å ta en beslutning på.

Hva du må vite om systemene før du ber om tilbud

Når kandidaten er valgt, er neste steg ikke å be om tilbud, men fem minutters undersøkelse av selve systemene, fordi det er nettopp det som avgjør om samtalen med utføreren blir om en løsning eller om en mulighet. Finn ut om hvert involverte system har et programvaregrensesnitt, om det er tilgjengelig på lisensnivået ditt, og om leverandøren tar betalt for det for seg, fordi alle tre svarene pleier å skille seg.

Det andre spørsmålet er hvem som lagrer dataene og hvem som får endre dem. Inneholder to systemer den samme informasjonen, for eksempel kundens opplysninger eller varens beholdning, må du før koblingen bestemme hvilket av dem som er hovedkilden, fordi automatiseringen ellers begynner å overskrive begge gjensidig og resultatet blir dårligere enn før. Denne avgjørelsen er gratis hvis du tar den i starten, og dyr hvis du oppdager den under testingen.

Det tredje er spørsmålet om hva som skjer når noe ikke går. I hver automatisering finnes tilfeller som ikke kommer gjennom (et felt mangler, systemet svarer ikke, dataene strider mot hverandre), og de trenger et sted å lande og et menneske som ser på dem. Automatisering uten feilhåndtering virker bare så lenge alt er i orden, og det er det aldri lenge.

Du bør også på forhånd bestemme hva du vil måle suksess etter, fordi prosjektet uten det aldri tar slutt, det bare avbrytes. Målet kan være ganske enkelt: hvor mange ganger i måneden noen fortsatt kopierer data for hånd, hvor mange feil som ble rettet forrige måned, og hvor lenge en henvendelse går fra skjema til svar. Dette tallet har mening å måle én gang før arbeidet starter, så du senere har noe å sammenligne med. Bedrifter som ikke tar denne målingen, krangler etter et halvt år om det i det hele tatt endret seg noe.

Til slutt: automatisering er ikke et engangsarbeid, men noe som blir i bedriften og krever en eier som ethvert annet system. Når prosessen er koblet, må noen vite hvor de skal se hvis den stanser, og noen må ha rett til å stoppe den hvis resultatet ser feil ut. I bedrifter der denne rollen ikke er navngitt, slutter automatiseringen stille å virke, og det merkes først etter en måned, når noen leter etter et dokument som er borte.

Hva du kan starte med i praksis

Starten er verken valg av verktøy eller å be om tilbud, men én uke der det skrives ned hva som skjer: hvilket arbeid som gjentas, hvor ofte, hvor lenge, og hvor i det et menneske flytter data mellom systemer. Deretter stiller du hvert innslag de fire spørsmålene i denne artikkelen, og det meste av listen faller bort allerede etter de to første.

Tilbake blir det som regel én eller to kandidater, og det er bra, fordi det er akkurat så mange det også lønner seg å starte med samtidig: to ferdige arbeider gir mer enn seks påbegynte. Når kandidaten er valgt, er neste steg å finne ut om de involverte systemene har grensesnitt, fordi det avgjør både prisen og hvor robust løsningen blir.

Er det på dette tidspunktet klart hvilken prosess som er din, men uklart hvordan den skal kobles, kan det tas opp med oss: automatisering av forretningsprosesser hos oss er integrasjoner og arbeidsflyter mellom systemer du allerede har. Vil du først forstå hvordan de ulike tilnærmingene og verktøygruppene skiller seg, skriv til oss eller send listen din — svaret er ofte at det holder med én kobling, ikke en plattform.