Regnestykket bag en automatisering — og hvornår det ikke går op

De fleste automatiseringsprojekter bliver solgt på en fornemmelse: "det her tager alt for lang tid, det må kunne gøres automatisk." Fornemmelsen har ofte ret. Men den siger ikke noget om, hvorvidt netop denne opgave er den næste der skal automatiseres — og det er det spørgsmål, der afgør om pengene er godt brugt.

Her er den model jeg selv regner på, før jeg giver et tilbud. Den er bevidst simpel, fordi et regnestykke der kræver et regneark, sjældent bliver lavet.

De fire tal du skal bruge

Frekvens. Hvor mange gange om året kører processen? Det er det tal der betyder mest, og det er også det folk oftest gætter forkert på. En opgave der tager tyve minutter og laves hver dag, koster over 80 timer om året. En opgave der tager en hel dag og laves fire gange om året, koster 32. Den kedelige, korte opgave er næsten altid den dyre.

Tid pr. kørsel. Regn med den tid det faktisk tager, inklusive den tid det tager at komme i gang, finde filen og huske hvor man slap. Ikke den tid det tager, når alt går som det skal, og man lige er blevet færdig med det samme i går.

Fejlrate og fejlomkostning. Hvor ofte går det galt, og hvad koster det, når det gør? Det er her manuelle processer bliver dyre på en måde ingen har bogført. En forkert indtastet pris opdaget efter tre uger koster ikke ti minutter — den koster en kreditnota, en sur kunde og en time hos bogholderen.

Levetid. Hvor længe kommer processen til at eksistere i sin nuværende form? Hvis I skifter ERP om otte måneder, er det den reelle levetid, uanset hvor godt automatiseringen ellers ville virke.

Regnestykket

Den årlige gevinst er:

(frekvens × tid pr. kørsel × timepris)
+ (frekvens × fejlrate × fejlomkostning)

Den skal holdes op mod prisen på at bygge løsningen plus driften over levetiden. Driften glemmer folk konsekvent: API-kald, hosting, en licens og — vigtigst — den tid nogen skal bruge på at kigge til flowet, når det fejler.

Et eksempel. En bogholder bruger 25 minutter tre gange om ugen på at afstemme betalinger mellem betalingsgateway og økonomisystem. Cirka en gang om måneden går noget galt, og det koster typisk en times oprydning.

• 156 kørsler × 25 min = 65 timer om året
• 12 fejl × 1 time = 12 timer om året
• 77 timer × 350 kr. = cirka 27.000 kr. om året

En automatisering til 45.000 kr. med 4.000 kr. i årlig drift er tjent hjem efter godt to år. Det er acceptabelt hvis processen holder — og en dårlig forretning hvis økonomisystemet skal skiftes næste sommer.

Fire gange hvor svaret er nej

Frekvensen er for lav. Alt der kører færre end omkring 20 gange om året, skal have en anden begrundelse end tid. Der findes gode grunde — compliance, sporbarhed, at kun én person kan opgaven — men "det tager lang tid" er ikke en af dem, når det sker fire gange årligt.

Processen er ikke stabil endnu. Automatisering fastfryser en arbejdsgang. Er I stadig i gang med at finde ud af, hvordan opgaven skal løses, betaler I for at cementere noget der bliver lavet om. Vent til den har kørt uændret i et par måneder.

Datagrundlaget er rodet. Automatisering af en proces med ustabile data flytter bare fejlen længere ned ad kæden, hvor den er sværere at få øje på. Ryd op først. Det er kedeligere, og det er næsten altid den rigtige rækkefølge.

Der findes en indstilling. Det sker oftere end man skulle tro: det system I allerede betaler for, kan det I efterspørger, men ingen har slået det til. Jeg har afsluttet flere afklaringssamtaler med en henvisning til en dokumentationsside frem for et tilbud. Det koster mig en opgave og sparer jer et sekscifret beløb.

Det regnestykket ikke fanger

To ting falder uden for modellen, og de er begge vigtige.

Den ene er flaskehalse hos personer. Når kun én person kan en opgave, er omkostningen ikke timerne — det er ventetiden, når vedkommende er syg, på ferie eller siger op. Den koster ikke noget i regnearket og en hel del i virkeligheden.

Den anden er det der bliver muligt bagefter. Nogle automatiseringer er kedelige i sig selv, men fjerner den forhindring der gjorde noget andet urealistisk. En produktdatapipeline er ikke spændende, men den er tit forudsætningen for, at man overhovedet kan overveje flere markeder.

Begge dele er reelle argumenter. De skal bare siges højt som argumenter, i stedet for at blive gemt i et optimistisk timeestimat.

Sådan prioriterer du en liste

Har I ti kandidater, så lav tallene for dem alle på en formiddag — grove estimater er fint, præcisionen ændrer sjældent rækkefølgen. Sortér efter årlig gevinst divideret med forventet byggepris, og start i toppen.

Det giver næsten altid en anden rækkefølge end den, folk foreslår ud fra frustration. Den mest irriterende opgave er sjældent den dyreste.

Og hvis toppen af listen er en opgave, som ingen synes er værd at tale om, er det som regel et tegn på at regnestykket virker.