Skrevet af Published
Trust og opstart

Bliver det et stort IT-projekt?

En digital medarbejder kan starte som en smal rolle oven på eksisterende systemer. Se hvordan man undgår at gøre første version for stor.

Kort svar

Ikke hvis man starter rigtigt. En digital medarbejder bør normalt begynde som en smal rolle med få kilder, tydeligt output, begrænset adgang, logs og stopregler. Den skal ikke starte med at erstatte alle systemer eller forbinde hele virksomheden. Første version skal bevise, at rollen kan hjælpe i hverdagen, før man udvider mandat og integrationer.

Problemet i praksis

Mange ledere kan godt se potentialet, men frygter endnu et projekt med workshops, systemkortlægning og uklart resultat.

IT-projekter bliver ofte store, når man starter med alle systemer, alle undtagelser og alle rettigheder på én gang.

De gentagne opgaver bliver derfor liggende, selvom de er for små til roadmapet og for irriterende til at fortsætte manuelt.

Hvad ændrer sig med en digital medarbejder?

Samtalen flyttes fra “hvilke systemer skal bygges om?” til “hvilken tilbagevendende opgave mangler en ejer?”.

Første version kan arbejde oven på eksisterende systemer: læse aftalte mails, mapper, CRM-visninger, regneark eller eksporter og aflevere et konkret beslutningsgrundlag.

IT bliver en rammesætter for adgang, sikkerhed og drift — ikke nødvendigvis ejer af et stort flerårigt projekt.

Den rigtige frygt

Spørgsmålet er helt rimeligt. Mange virksomheder har prøvet projekter, der startede med en lille forbedring og endte med integrationer, workshops og afhængigheder på tværs af hele organisationen.

Derfor bør første digitale medarbejder ikke designes som “AI i hele virksomheden”. Den bør designes som én kollega med et afgrænset ansvar.

Et godt spørgsmål er ikke: hvor meget kan den teknisk få adgang til? Det er: hvilket tilbagevendende arbejde kan den eje forsvarligt fra første uge i drift?

En smal første version

Forestil dig en digital opfølgningskoordinator. Den læser en aftalt CRM-visning, udvalgte mails og en delt mappe. Hver morgen afleverer den en liste over åbne sager, manglende svar, usikre punkter og anbefalet næste interne handling.

Den kan skrive interne udkast og måske oprette en opgave, hvis mandatet er klart. Men den sender ikke kundeløfter, ændrer priser eller konkluderer på juridiske spørgsmål.

Det kræver ikke, at alle systemer bygges om fra start. Det kræver, at rollen, kilderne og stopreglerne er konkrete.

IT skal med — men som ramme, ikke som alibi for at vente

Det er en fejl at sige, at IT slet ikke skal involveres. Adgang, identitet, logs, datagrænser og drift er vigtige. Men det er noget andet end at gøre første version til et stort transformationsprogram.

En praktisk start kan være læseadgang til bestemte mapper, eksport fra CRM, afgrænsede mailbokse eller et regneark med aftalte felter. Hvis det virker, kan næste version få bedre integrationer.

På den måde lærer virksomheden af faktisk brug i stedet for at forsøge at designe alt på forhånd.

Når simple regler er nok

Hvis behovet er “send en besked, når felt X ændres”, skal man ikke bygge en digital medarbejder. Brug systemets egne regler, et workflow eller en simpel integration.

En digital medarbejder giver mere mening, når arbejdet kræver sammenhæng: flere kilder, vurdering af undtagelser, prioritering og et output der skal kunne forklares.

Den bør ikke være en dyr erstatning for et simpelt flow. Den bør være en rolle, der samler arbejde som ellers falder mellem mennesker og systemer.

Sådan undgår man scope creep

Skriv mandatet før løsningen bygges: hvad må den læse, hvad må den gøre selv, hvad må den kun forberede, og hvad skal den eskalere?

Hold første version til lavrisiko-handlinger. Brug logs til at se, hvilke sager der er normale, hvilke der stopper, og hvor bedre integration faktisk vil give værdi.

Det gør projektet mindre dramatisk. Ikke fordi man ignorerer risiko, men fordi man starter med en rolle der kan forstås, testes og justeres.

Sådan starter man uden at overbygge

  1. 1

    Vælg én smal rolle, for eksempel opfølgningskoordinator, fakturakontrol, mødeforberedelse eller kundeservice-triage.

  2. 2

    Definér input, output og stopregler før integrationer: hvad må rollen læse, hvad skal den aflevere, hvad må den gøre selv, og hvornår skal den eskalere?

  3. 3

    Start med begrænset adgang og lavrisiko-handlinger. Udvid først, når logs viser stabile sager, kendte undtagelser og et klart behov for dybere integration.

Risici der skal styres

  • At love, at en digital medarbejder aldrig kræver IT-arbejde. Adgang, sikkerhed, data og drift skal stadig afklares.
  • At gøre første version for bred, så man designer en platform i stedet for en rolle.
  • At bruge en digital medarbejder, hvor en simpel regel, et workflow eller en native systemfunktion ville være billigere og mere stabil.

Kilder og videre læsning

Relaterede sider

Ofte stillede spørgsmål

Kan en digital medarbejder bygges uden IT?
Ikke helt. IT bør typisk være med til adgang, sikkerhed, drift og systemgrænser. Pointen er, at første version ikke behøver være et stort systemprojekt, hvis rollen er smal og rettighederne er afgrænsede.
Hvornår bliver det et stort projekt?
Når man starter med for bredt scope: alle systemer, skriveadgang overalt, uklare mål og mange undtagelser. Start i stedet med én opgave, få kilder og et output, som mennesker kan vurdere hurtigt.
Hvornår er almindelig automatisering nok?
Når processen er fast, input er ens, og der ikke kræves vurdering. Så kan et workflow, en regel, Power Automate, et CRM-flow eller en simpel integration være bedre end en digital medarbejder.
Hvad er en god første version?
En rolle der læser aftalte kilder, samler en opfølgningsliste, markerer usikre punkter, skriver interne udkast og eskalerer sager med kundeløfter, persondata, pris, jura eller modstridende kilder.

Vil du finde den første digitale medarbejder i jeres virksomhed?

Skriv til Mikkel