Hvornår giver det mening at bygge et skræddersyet internt værktøj?

Et skræddersyet internt værktøj giver mening, når en vigtig, tilbagevendende arbejdsopgave ikke bliver løst tilfredsstillende af eksisterende systemer, og forbedringen er stor nok til at betale for både udvikling og løbende drift. Virksomheden skal samtidig have en ansvarlig for processen og være klar til at ændre den måde, arbejdet udføres på.

Hvis et regneark, et standardsystem eller en mindre integration løser problemet godt nok, bør det være udgangspunktet. At noget kan specialudvikles, er ikke i sig selv en grund til at gøre det.

Hvilket problem skal et internt digitalt værktøj løse?

Interne digitale værktøjer hjælper medarbejdere med at udføre virksomhedens arbejde. I denne guide betyder skræddersyet, at løsningen tilpasses en bestemt arbejdsgang, uanset om den bygges med kode eller på en platform med færdige komponenter.

Start med en konkret opgave: Hvem gør hvad, med hvilke oplysninger, og hvor går arbejdet i stå? Beskriv for eksempel, at en koordinator hver morgen sammenholder åbne sager med tre lister og kontakter kolleger for at finde den seneste status. Det giver et bedre beslutningsgrundlag end ønsket om at få »et moderne system«.

Undersøg især:

• Hvor tit opgaven udføres, og hvor mange der deltager.
• Hvor meget tid der går til at flytte oplysninger, vente eller rette fejl.
• Hvilke konsekvenser en fejl har, og hvordan den opdages i dag.
• Om problemet skyldes manglende funktioner, uklare ansvarsområder eller dårlig brug af det eksisterende system.

En uklar proces bliver ikke klar af at få en brugerflade. Hvis ingen kan beslutte, hvornår en sag er godkendt, bør den regel afklares før udviklingen.

Hvornår taler behovet for at bygge?

Et stærkt argument er en stabil arbejdsgang, hvor eksisterende løsninger har en konkret mangel. Det kan være, at medarbejdere gentager den samme kontrol på tværs af systemer, eller at virksomhedens nødvendige godkendelsesregler ikke kan understøttes uden omfattende omveje.

Prøv den vanskelige del af processen i et relevant standardsystem, før du afviser det. En manglende farve eller en anden placering af en knap er et svagt argument for specialudvikling. En nødvendig regel, som ikke kan håndhæves, er et stærkere argument.

GOV.UK's vejledning om bygge- eller købebeslutningen fremhæver blandt andet særlige behov, manglende mulighed for at tilpasse eller integrere standardprodukter og ressourcer til at drive løsningen. Vejledningen er skrevet til britiske myndigheder; her bruges kriterierne som beslutningsstøtte, ikke som krav til danske virksomheder.

Eksempel: Et skræddersyet administrationsværktøj

Et tænkt eksempel er en servicevirksomhed, hvor en opgave skal registreres, fordeles, udføres og kontrolleres, før den sendes videre til fakturering. Status ligger i et regneark, dokumentation i mapper og afklaringer i mails.

Et skræddersyet administrationsværktøj er relevant, hvis den opdeling skaber dokumenterede problemer: medarbejdere arbejder ud fra forskellige oplysninger, opgaver mangler en ansvarlig, eller afsluttede opgaver bliver sendt videre uden nødvendig dokumentation.

Den første version kunne samle én arbejdsgang med fælles status, ansvarlig medarbejder og kontrol af de oplysninger, der er nødvendige for at afslutte opgaven. Værdien skal vurderes på, om opgaverne faktisk bliver behandlet mere sikkert eller med mindre manuelt arbejde.

Der er stadig en reel købemulighed. Hvis virksomhedens nuværende sags- eller ordresystem allerede kan håndtere forløbet med opsætning og oplæring, er et nyt administrationsværktøj svært at begrunde. Hvis kun overdragelsen til fakturering mangler, bør en afgrænset integration undersøges først.

Specialudvikling er stærkest begrundet, når den nødvendige arbejdsgang er afprøvet, alternativerne fejler på bestemte krav, og de krav har betydning for den daglige drift.

Et custom dashboard til virksomheden: Hvilken beslutning bliver bedre?

Et custom dashboard til en virksomhed giver først værdi, når nogen bruger oplysningerne til at træffe en konkret beslutning. Et tænkt eksempel er en driftsleder, der skal omfordele arbejde ud fra sager uden ansvarlig, overskredne frister og ledig kapacitet.

Hvis behovet alene er overblik og analyse, bør eksisterende rapportering undersøges først. Power BI understøtter dashboards med visualiseringer fra flere rapporter og datamodeller, så flere datakilder er ikke i sig selv en grund til at bygge en ny løsning.

Hvis medarbejderen også skal omfordele en sag, gemme en begrundelse og følge særlige godkendelsesregler, er behovet mere omfattende end en visning af tal. Afprøv, om de handlinger kan foregå i det eksisterende system eller via en mindre udvidelse, før du bestiller en samlet app.

Afklar datagrundlaget: Hvad betyder »ledig kapacitet«, hvilket system er kilden, og hvor gamle må oplysningerne være? Et flot dashboard gør ikke uenige definitioner eller manglende registreringer pålidelige.

Sammenlign med de mindre løsninger

Vurdér alternativerne med den samme virkelige opgave og de samme nødvendige krav:

• Behold og forbedr regnearket, når få personer arbejder med et enkelt forløb, og fejlrisiko og koordinering er håndterbare.
• Konfigurér standardsoftware, når behovet følger en almindelig proces, og produktet løser de væsentlige krav. Undersøg adgang, eksport og integrationer før køb.
• Byg en integration eller automatisering, når eksisterende systemer fungerer, men oplysninger skal overføres eller kontrolleres mellem dem.
• Undersøg en low-code-platform, når et tilpasset forløb kan bygges inden for platformens rammer. Power Apps kan forbinde forretningsapps med eksisterende datakilder, men licenser, rettigheder og vedligeholdelse skal stadig vurderes.
• Specialudvikl, når vigtige krav falder uden for de egnede alternativer, og virksomheden kan finansiere og forvalte løsningen.

Low-code er også udvikling. En løsning med færre håndskrevne kodelinjer kræver stadig test, dokumentation, adgangsstyring og en ansvarlig, når processen ændres.

Hvis du er i tvivl om forskellen mellem en informationsside og et arbejdsredskab, forklarer guiden om webapp vs. hjemmeside den afgrænsning.

Regn på værdien uden at love en besparelse

Sammenlign omkostninger over samme periode. Medtag afklaring, udvikling eller opsætning, datamigrering, oplæring, licenser, hosting, support, fejlrettelser og forventede ændringer. Medregn også medarbejdernes tid under indførelsen.

For en gentagen opgave kan du begynde med denne beregning:

Antal opgaver pr. måned × minutter sparet pr. opgave ÷ 60 = frigjorte timer pr. måned.

Et rent regneeksempel: 300 opgaver om måneden og fire minutter mindre manuelt arbejde pr. opgave svarer til 20 timer. Ved en hypotetisk intern timeomkostning på 300 kr. er kapacitetsværdien 6.000 kr. om måneden. Hvis løbende drift og vedligeholdelse antages at koste 1.500 kr., er forskellen 4.500 kr. En hypotetisk etablering på 90.000 kr. svarer da til 20 måneders simpel tilbagebetaling.

Tallene er valgte eksempeltal, ikke markedspriser eller en forventet effekt. Beregningen ser bort fra blandt andet indkøring og tidsværdien af penge. Hvis kun halvdelen af tidsgevinsten opnås, falder kapacitetsværdien til 3.000 kr. og forskellen til 1.500 kr.; samme etablering svarer da til 60 måneder.

Frigjort tid er heller ikke automatisk en kontant besparelse. Beskriv, hvad medarbejderne skal bruge tiden til. Hold værdien af færre fejl adskilt, så samme gevinst ikke tælles to gange. Brug observationer fra jeres egen proces og et forsigtigt scenarie, før beregningen bruges som investeringsgrundlag.

Hvornår bør I vente eller lade være?

Vent, hvis opgaven udføres sjældent, processen er under omorganisering, eller medarbejderne endnu ikke er enige om reglerne. Undersøg standardsoftware først, hvis problemet hovedsageligt er en almindelig funktion, som jeres eksisterende system allerede tilbyder.

Lad også være med at starte, hvis der er budget til udvikling, men ingen til vedligeholdelse. Før et internt værktøj bliver en del af driften, skal det være klart:

• Hvem der ejer processen og prioriterer ændringer.
• Hvem der hjælper brugerne og håndterer tekniske fejl.
• Hvordan adgang gives, begrænses og fjernes.
• Hvordan data sikkerhedskopieres, gendannes og eksporteres.
• Hvordan arbejdet fortsætter ved nedbrud, og hvem der kan overtage løsningen.

Jo mere kritisk opgaven er, desto mere kræver den af driftsplanen. »Kun til intern brug« er ikke et argument for at springe adgangskontrol eller genoprettelse over.

Lav et beslutningsoplæg før et udviklingsprojekt

Skriv et kort oplæg med én arbejdsgang, brugerne, det observerede problem, de nødvendige krav, de afprøvede alternativer og en samlet økonomisk vurdering. Angiv også, hvem der ejer løsningen, og hvordan effekten skal måles.

Hvis et vigtigt spørgsmål stadig er ubesvaret, så afprøv det i en prototype eller en afgrænset pilot. Test eksempelvis den vanskelige integration eller lad de faktiske brugere gennemføre en opgave. Aftal på forhånd, hvad der skal være opfyldt for at fortsætte, og stop, hvis pilotens resultat ikke understøtter investeringen.

Når beslutningen om at bygge er truffet, kan guiden om at hyre en freelance webudvikler hjælpe med scope, screening og aftale. Hvis første leverance stadig rummer væsentlig usikkerhed, gennemgår fast pris vs. timepris valget af betalingsmodel.