Med værktøjer som Microsofts Power Platform kan medarbejdere uden udviklerbaggrund bygge apps og automatiske arbejdsgange. Det kaldes ofte citizen development, altså udvikling lavet af forretningens egne folk. Det er nyttigt, og det kan give mange små forbedringer, som IT aldrig ville nå. Ledelsesspørgsmålet opstår, når det, en controller byggede til sig selv, bliver det, hele regnskabsafdelingen er afhængig af ved månedsafslutningen. Så skal nogen eje det. Tre beslutninger gør forskellen: hvad der må bygges af hvem, hvornår en løsning er blevet kritisk, og hvad der sker, når personen, der byggede den, stopper.
Fra regneark til kritisk flow
Emnet er i familie med regnearket, kun én forstår, som er behandlet på ekstern-it-chef.dk. Forskellen ligger i omfanget. En selvbygget app kan hente data fra ERP, sende godkendelser på tværs af selskaber og skrive tilbage i systemerne. I en organisation med flere afdelinger kan der hurtigt komme mange af dem, og IT-afdelingen ved ikke altid, at de findes.
Et tænkt eksempel: en controller i et datterselskab bygger et flow, der samler tal fra tre systemer til månedsrapporten. Det virker fint, og to andre selskaber begynder at bruge det. To år senere siger controlleren op. Flowet kører på controllerens personlige konto, og da kontoen lukkes, stopper rapporteringen midt i en månedsafslutning. Ingen i IT kendte til det, og ingen i økonomi kan rette det.
Tre niveauer af det, der bygges
Reglen kan ikke være, at alt skal godkendes, for så går værdien tabt. Den kan heller ikke være, at alt er frit. En enkel opdeling i tre niveauer virker for de fleste.
- Personligt. Værktøjer, der kun hjælper den, der byggede dem. Ingen følsomme data og ingen afhængighed hos andre. Frit inden for de almindelige regler.
- Fælles i afdelingen. Flere bruger løsningen. Den skal have en navngiven ejer, og en kollega skal kunne overtage den.
- Forretningskritisk. Løsningen indgår i regnskab, kunderettede leverancer, rapportering eller lignende, eller den rører data på tværs af selskaber. Her skal IT med. Løsningen skal dokumenteres og forvaltes som et system, og den skal stå i applikationsporteføljen.
Hele pointen er bevægelsen mellem niveauerne. De fleste kritiske løsninger starter som personlige. Derfor skal der være en fast lejlighed, hvor I ser på, hvad der er vokset, fx en årlig liste over de mest brugte apps og flows.
Miljøer, adgange og ejerskab
Platformen kan sættes op, så noget af det bliver lettere. Teknikken hører til hos IT. Ledelsen skal vide, at nogen har besluttet følgende:
- om der er adskilte miljøer til forsøg og til det, forretningen er afhængig af,
- hvilke datakilder der må forbindes, og hvilke der kræver godkendelse,
- hvilke konti løsningerne kører på, så de ikke afhænger af én persons konto,
- hvem der kan se, hvad der er bygget på tværs af organisationen.
Disse beslutninger ejes af IT, som skal aftale dem med forretningen. I en koncern skal det også afgøres, om reglerne er fælles, og om de lokale selskaber må sætte deres egne. Det hænger sammen med spørgsmålet om tenants. Hvad platformen konkret kan, og hvordan den sættes op, ændrer sig, og det må jeres tekniske folk læse hos Microsoft. Vi skriver ikke om abonnementer eller priser her.
Når personen stopper
Overdragelsen er det punkt, der oftest går galt. Læg det ind i den proces, I allerede bruger ved fratrædelse og jobskifte. HR-listen ved fratrædelse skal rumme spørgsmålet: har medarbejderen bygget noget, som andre bruger? I bør kunne svare på, hvem der overtager, hvor løsningen er beskrevet, og hvilke konti den afhænger af.
Reglen er også en god anledning til at spørge, om en løsning stadig er nødvendig. Mange flows kan lukkes, når den, der byggede dem, stopper. Andre skal erstattes af noget, der forvaltes ordentligt.
Hvem ejer det, juridisk?
Efter ophavsretsloven § 59 overgår ophavsretten til et edb-program til arbejdsgiveren, når en arbejdstager laver det som led i sit job eller efter arbejdsgiverens anvisninger. Programmer og apps lavet af medarbejdere i arbejdet tilhører altså som udgangspunkt arbejdsgiveren.
Der er to forbehold. Om et flow eller en lavkode-app overhovedet er et edb-program efter loven, er ikke undersøgt her. Det er et spørgsmål til advokat. Og reglen nævner arbejdstagere. Bygges løsningen af en konsulent eller en freelancer, skal rettighederne aftales, og det er også noget, advokaten skal se på.
For ledelsen er det forretningsmæssige ejerskab vigtigere end det juridiske: hvem svarer, når løsningen fejler, og hvem må beslutte, at den lukkes?
Hvem der skal tage beslutningen
Reglerne bør godkendes i IT-styregruppen eller det forum, der afgør tilsvarende sager. Det er også her, grænsen til afdelingernes egne køb skal aftales, for de to emner har samme kerne. Giver I lov til at bygge selv, skal det hænge sammen med reglerne for at købe selv. Sæt også en ansvarlig for at støtte dem, der bygger. Det kan være en lille rolle i IT-afdelingen, der svarer på spørgsmål og ser det, der er på vej til at blive vigtigt.
Hvad gør I nu?
Bed IT om en liste over de mest brugte selvbyggede løsninger, og spørg økonomi og de store afdelinger, hvilke de ikke kan undvære. Kan I ikke få den liste, er det det første, der skal laves. Sæt derefter navn på ejeren af de løsninger, der er forretningskritiske, og skriv de tre niveauer ned på én side.
Det skal I lade være med
- At forbyde værktøjerne · det fjerner forbedringerne og skubber arbejdet ud af syne.
- At lade kritiske løsninger køre på en persons konto · så stopper de sammen med personen.
- At gå ud fra, at juraen er enkel · rettigheder til selvbyggede løsninger er et spørgsmål til advokat, når de betyder noget.
Det skal I kræve af dem, der leder IT
- ☐ Et overblik over selvbyggede løsninger og deres brugere.
- ☐ En kort regel for de tre niveauer, som forretningen kan forstå.
- ☐ Besluttede miljøer, datakilder og konti.
- ☐ Et punkt om selvbyggede løsninger i fratrædelsesproceduren.
- ☐ En navngiven ejer af hver forretningskritisk løsning.
Kilder
- Ophavsretsloven, LBK nr. 1093 af 20. august 2023: § 59 om ansattes edb-programmer.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Procesejere · Applikationsporteføljen
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CIO hos Nielco IT
