Hvad koster IT-automatisering?

Hvad bestemmer prisen?

To arbejdsgange, der ser næsten ens ud for brugeren, kan være meget forskellige at automatisere. En formular, der opretter en sag i et moderne system med et veldokumenteret API, er typisk enklere end en proces, der skal læse varierende dokumenter, finde oplysninger i gamle systemer og håndtere mange særregler.

Det første prisparameter er omfanget. Hvor starter processen, hvornår er den færdig, og hvilke trin skal fortsat udføres af et menneske? En tydelig grænse gør både estimering, test og ansvar lettere. Hvis projektet samtidig skal rydde op i stamdata, ændre arbejdsgange og erstatte flere systemer, er det reelt et større forandringsprojekt.

Integrationerne betyder også meget. Standardiserede API’er og webhooks giver stabile forbindelser. Manglende adgang, uklare datamodeller eller afhængighed af brugerflader kræver mere analyse og mere robust fejlhåndtering. Endelig påvirker sikkerhed, dokumentation, logning, godkendelser og oppetidskrav den samlede indsats.

• Antal systemer, datakilder og integrationer.
• Datakvalitet, filformater og variation i input.
• Antal regler, undtagelser og manuelle godkendelser.
• Krav til sikkerhed, sporbarhed, oppetid og dokumentation.
• Behov for brugerflade, rapportering og løbende administration.

Del budgettet i tre dele

Et brugbart budget skelner mellem afklaring, implementering og drift. Afklaringen kortlægger den nuværende proces, datakilder, undtagelser og succeskriterier. Resultatet bør være et konkret flow, en afgrænsning og en liste over de største usikkerheder. Den indsats kan virke som en ekstra omkostning, men reducerer risikoen for at bygge den forkerte løsning.

Implementeringen omfatter integrationer, forretningsregler, eventuel brugerflade, test og idriftsættelse. Her er det vigtigt at aftale, hvad den første version skal kunne. Alt behøver ikke være automatisk fra første dag. Hvis de hyppigste sager kan behandles sikkert, mens sjældne undtagelser sendes til manuel kontrol, kan virksomheden få værdi tidligere og lære af den faktiske brug.

Driften fortsætter efter lanceringen. Systemer ændrer API’er, medarbejdere ændrer processen, og fejl skal kunne opdages. Budgettér derfor med overvågning, support, sikkerhedsopdateringer og mindre justeringer. En automatisering uden ejer og vedligeholdelse bliver gradvist mindre pålidelig, selv om den fungerede på lanceringsdagen.

Sådan bygger I en realistisk business case

Start med en baseline. Mål hvor mange sager processen håndterer, hvor lang tid de typiske trin tager, hvor ofte der opstår fejl, og hvor længe en sag venter mellem afdelinger. Brug et repræsentativt tidsrum frem for medarbejdernes bedste gæt. Notér også sæsonudsving og sager, der kræver ekstra arbejde.

Beregn derefter den forventede effekt forsigtigt. Automatiseringen fjerner sjældent al menneskelig tid. Der vil fortsat være kontrol, undtagelser og vedligeholdelse. Til gengæld kan værdien være større end timebesparelsen: kortere svartid, færre afbrydelser, ensartet dokumentation og mindre risiko for glemte opfølgninger kan have mærkbar forretningsværdi.

Sammenlign den årlige gevinst med både etablering og forventet drift. Lav gerne tre scenarier: forsigtigt, forventet og optimistisk. Hvis projektet kun hænger sammen i det optimistiske scenarie, bør processen afgrænses yderligere eller undersøges bedre, før I investerer.

Hvad skal der til for at få et brugbart estimat?

Et seriøst estimat kræver ikke en lang kravspecifikation, men det kræver konkrete oplysninger. Beskriv processen trin for trin, angiv de systemer og konti der indgår, og medbring eksempler på input og output uden følsomme oplysninger. Fortæl hvor ofte processen kører, hvem der ejer den, og hvilke fejl der er uacceptable.

Afklar også, om leverandøren kan få adgang til testmiljøer og teknisk dokumentation. En kort teknisk undersøgelse kan være den bedste første leverance, hvis en kritisk integration er usikker. Når usikkerheden er reduceret, kan næste fase estimeres langt bedre.

Den billigste løsning er ikke nødvendigvis den med færrest udviklingstimer. En løsning skal kunne overvåges, forklares og ændres. Vælg derfor en første version, der er lille nok til at styre, men komplet nok til at fungere sikkert i den virkelige arbejdsgang.