Hvornår har en virksomhed brug for et internt system?

Hvad er et internt system?

Et internt system er software, som hjælper virksomhedens egne medarbejdere med en bestemt arbejdsgang, data eller administration.

Det kan understøtte sagsstyring, medarbejderadministration, ordrebehandling, godkendelser, dokumentflow, onboarding eller intern planlægning.

Mulige funktioner er login, brugerroller, formularer, status, historik, dashboards og integrationer. De bør vælges ud fra arbejdsgangen - ikke fordi de findes.

Internt system, webapp, dashboard og automation - hvad er forskellen?

Begreberne overlapper:

Et internt system fokuserer på medarbejdernes arbejdsproces og handlinger.

Et dashboard fokuserer primært på overblik og beslutningsstøtte.

Automation udfører bestemte trin uden manuel handling.

En custom webapp er den bredere tekniske kategori og kan også være kundeportal eller SaaS. Læs mere i guiden om custom webapplikationer til virksomheder.

Et internt system kan godt indeholde både dashboard, automation og API-integrationer.

8 tegn på at virksomheden bør undersøge et internt system

1. De samme data findes i flere spreadsheets

Kundeinformation findes måske i salgsarket, projektarket, økonomiarket og en separat rapport.

Problemet er ikke kun dobbeltarbejde. Det er også spørgsmålet:

Hvilken version er den rigtige?

Når flere filer fungerer som parallelle databaser, opstår der let forskellige statusværdier og noter. Et centralt system kan gøre én datakilde autoritativ.

Hvis ét regneark bruges af én person til simpel analyse, er der derimod ikke nødvendigvis et problem.

2. Medarbejdere taster de samme oplysninger flere gange

Kunden oprettes i CRM. Derefter kopieres oplysninger til Excel, økonomisystem og en intern rapport.

Afgør først, hvor data burde leve. Løsningen kan være API-integration, automation eller et internt system.

Hvis de eksisterende systemer allerede har gode brugerflader, kan forbindelsen mellem dem være det eneste, der mangler.

3. Mail eller chat fungerer som workflow

“Kan du godkende denne?”

“Er kunden klar?”

“Hvem har sagen?”

“Har nogen sendt dokumentet?”

Når status primært ligger i mailtråde og chatbeskeder, bliver processen svær at følge. Det er uklart, hvem der har ansvaret, og hvilke trin der allerede er udført.

Et system kan gøre status, ansvar, deadline og historik eksplicitte. Mail kan stadig bruges til kommunikation, mens workflowet får et tydeligt sted at leve.

4. Kun én eller få medarbejdere forstår processen

Hvis standardsvaret er “spørg Anne - hun ved, hvordan arket fungerer”, er virksomheden personafhængig.

Problemet er ikke Anne. Problemet er, at regler, undtagelser og historik kun findes i hendes hukommelse og manuelle rutiner.

Et internt system kan gøre regler og status mere synlige. Dokumentation og procesbeskrivelser kan også hjælpe - og bør ofte komme før software.

5. Standardsoftware passer næsten - men ikke helt

CRM, ERP og projektværktøjer er ofte den bedste løsning, når behovet er almindeligt.

Custom bliver først interessant, når virksomheden konsekvent arbejder rundt om værktøjet: centrale felter mangler, godkendelser ligger udenfor, eller dobbeltregistrering er nødvendig.

Hvis standardsoftwaren løser 90-100 % af behovet rimeligt, er det ofte bedre at beholde den.

6. Ledelsen bruger tid på manuelt at samle status

Før det ugentlige møde samler en medarbejder data fra mails, spreadsheets, CRM og flere kolleger.

Her er det ikke sikkert, at virksomheden har brug for et fuldt system. Problemet kan være et overbliksproblem.

Hvis brugerne primært skal se data og status, kan et dashboard der erstatter spreadsheets være nok.

7. Adgang og ansvar bliver svære at styre

Et voksende spreadsheet-setup kan ende med, at alle kan redigere alt, shared logins bruges flere steder, eller ingen kan se, hvem der ændrede en vigtig status.

Et internt system kan gøre adgang mere eksplicit gennem login, roller og rettigheder.

Det kan eksempelvis betyde, at en medarbejder kun ser egne relevante sager, en manager ser teamets data, og en administrator kan ændre systemopsætning.

Det er ikke en sikkerhedsgaranti; adgangsmodel, logging og drift skal stadig passe til data og risiko.

8. Administration vokser direkte med virksomheden

Hvis flere kunder eller medarbejdere automatisk betyder flere kopieringer, statusmails, regneark og manuelle kontroller, er processen værd at undersøge.

Målet er ikke nødvendigvis at reducere antallet af medarbejdere.

Målet er at undgå, at simple administrative trin vokser én-til-én med forretningen, når de i stedet kan struktureres bedre.

Hvornår er Excel stadig den rigtige løsning?

Excel og Google Sheets er ofte rigtige, når processen er enkel, få personer bruger data, arbejdet primært er analyse, formatet ændrer sig ofte eller processen er midlertidig.

Et spreadsheet er ikke et problem bare fordi det er et spreadsheet.

Problemet opstår, når samme fil samtidig bliver database, workflow, adgangssystem og forretningskritisk driftsplatform.

Hvornår er standardsoftware bedre end custom?

Standardsoftware er som udgangspunkt værd at undersøge først.

Fordelene er ofte hurtigere implementering, mindre initial udvikling, eksisterende support og mindre teknisk ejerskab.

Custom software bør ikke vælges, fordi “eget system” lyder mere professionelt. Hvis et etableret produkt løser behovet tilfredsstillende, er det ofte den rationelle løsning.

Hvornår er en automation nok?

Hvis problemet er:

“Når en ordre oprettes her, skal kunden oprettes dér.”

så mangler virksomheden måske ikke et internt system. Den mangler et workflow mellem eksisterende systemer.

En automation kan være nok, hvis input og output er tydelige, medarbejderne allerede har gode systemer, og processen er regelbaseret.

Guiden om manuelle processer der kan automatiseres går dybere med vurderingen.

Hvornår er et dashboard nok?

Hvis problemet primært er:

“Vi kan ikke se data samlet.”

men medarbejderne ikke behøver at redigere komplekse records, håndtere godkendelser eller arbejde gennem flere procestrin, kan et dashboard være nok.

Et dashboard samler overblik.

Et internt system kombinerer typisk overblik med handlinger og regler.

Hvornår kræves et egentligt internt system?

Et internt system bliver særligt relevant, når virksomheden har behov for:

data + brugere + handlinger + regler

Eksempel:

En manager skal kunne:

1. se relevante medarbejdere eller sager
2. ændre status
3. godkende information
4. udløse næste trin
5. se historik

Det er mere end rapportering. Det er en arbejdsproces.

Standardsoftware vs. custom internt system

Ingen model vinder alle rækker. Spørgsmålet er, hvor særligt virksomhedens workflow faktisk er.

Hvordan vurderer man, om problemet er stort nok?

Før et systemprojekt bør problemet kunne beskrives med virksomhedens egne data.

Mål eksempelvis:

• hvor ofte processen udføres
• hvor mange medarbejdere der bruger den
• antal manuelle trin
• ventetid
• fejl og genbehandling
• hvor mange systemer data flyttes mellem
• hvor ofte status efterspørges manuelt
• hvor mange afhængigheder processen har

Målet er en baseline, så virksomheden senere kan vurdere, om løsningen faktisk forbedrer processen.

Kortlæg processen før du vælger teknologi

Start ikke med:

“Vi skal have et system.”

Beskriv først processen.

Trigger

Hvad starter arbejdsgangen?

Input

Hvilke data kræves?

Aktører

Hvem gør hvad?

Regler

Hvilke beslutninger træffes?

Output

Hvornår er processen afsluttet?

Undtagelser

Hvad kan gå galt eller kræve manuel håndtering?

Systemer

Hvor lever data i dag?

Når det er tydeligt, er det lettere at vælge mellem spreadsheet, dashboard, integration, automation og system.

Automatisér ikke en dårlig proces

Dårlig tilgang:

“Byg vores eksisterende 18-trins Excel-flow som software.”

Bedre tilgang:

“Find ud af, hvilke af de 18 trin der faktisk er nødvendige.”

Gamle særregler, dobbeltregistrering og uklare ansvar bør fjernes, før de bliver kodet ind i et nyt system.

Digitalisering gør en proces mere konsekvent. Derfor er det vigtigt, at processen er værd at gøre konsekvent.

Hvilke typer interne systemer findes?

Interne systemer kan eksempelvis være:

Administrationssystem

Central data og daglige administrative funktioner.

Medarbejdersystem

Roller, status, dokumenter og processer omkring medarbejdere.

Sagsstyring

Sager, ansvar, historik og status.

Ordre- eller produktionsworkflow

Intern behandling af en ordre eller opgave gennem faste trin.

Godkendelsessystem

Godkendelser af dokumenter, udgifter, content eller andre beslutninger.

Dashboard med handlinger

Overblik kombineret med redigering, godkendelser og workflows.

Dokumentflow

Dokumenter, ansvar, status og sporbarhed.

Kategorierne overlapper; systemtypen bør beskrives ud fra arbejdsgangen.

Hvilke funktioner har et internt system typisk?

Mulige funktioner er login, roller, dashboard, formularer, status, søgning, godkendelser, notifikationer, historik, dokumenter og integrationer.

Jo flere funktioner, desto større scope. Første version bør derfor ikke være en ønskeliste over fremtidige muligheder.

Brugerroller bør defineres tidligt

En simpel rollemodel kan være:

Medarbejder: ser og redigerer egne relevante data.

Manager: ser teamets data og kan godkende.

Administrator: administrerer system, brugere og brede rettigheder.

Rollemodellen påvirker UI, data, workflows og test og bør afklares tidligt.

Hvilket system ejer data?

Hvis samme kunde findes i CRM, økonomisystem, spreadsheet og internt system, skal virksomheden definere en source of truth.

Eksempel:

• CRM ejer salgsrelationen
• økonomisystem ejer faktura og betalingsstatus
• internt system ejer virksomhedens særlige workflow

Det nye system behøver ikke erstatte alt.

Det kan være bedre at lade hvert system fortsætte med det, det er godt til.

Integration med eksisterende systemer

Et internt system kan hente eller sende data til CRM, økonomisystem, ERP, databaser eller tredjepartsservices.

Men integration bør kun bygges, hvis:

• den nødvendige API- eller dataadgang findes
• datakvaliteten er god nok
• dataejerskabet er tydeligt
• forretningsbehovet retfærdiggør kompleksiteten

Læs mere om dataflow og fejlhåndtering i guiden til API-integration for virksomheder.

Skal alt samles i ét system?

Nej.

Et godt setup kan eksempelvis være:

• CRM til salg
• økonomisystem til faktura
• internt system til virksomhedens særlige arbejdsgang
• integrationer mellem de relevante dele

Målet er ikke “ét system til alt”.

Målet er at gøre ansvar, data og arbejdsgange tydelige.

MVP: start med én værdifuld proces

En MVP er ikke en halvfærdig version af hele drømmesystemet.

Det er:

den mindste løsning, der kan håndtere én vigtig arbejdsgang ordentligt i virkelig drift.

I stedet for at bygge HR, projekter, kunder, økonomi, lager og rapportering i første version, kan virksomheden starte med én afgrænset proces og teste den med reelle brugere.

Hvordan vælger man den første proces?

En god første proces er typisk:

• hyppig
• relativt stabil
• forstået af brugerne
• forretningsmæssigt relevant
• afgrænset
• ejet af en tydelig person eller funktion
• målbar

En dårlig første proces ændrer sig hele tiden, kræver mange usikre integrationer, mangler intern ejer eller har ekstrem fejlkonsekvens.

Datamigration fra spreadsheets

At flytte Excel-data til et system er sjældent bare “importér filen”.

Data kan indeholde:

• dubletter
• manglende felter
• forskellige datoformater
• historiske kolonner ingen længere bruger
• tomme værdier
• ukendte IDs
• forskellige versioner af samme record

Før migrationen bør virksomheden definere datamodellen, rense data og beslutte, hvad der faktisk skal flyttes.

Irrelevant historik kan med fordel blive i et arkiv frem for at blive importeret ukritisk.

Sikkerhed og adgang

Et internt system bør som minimum vurderes ud fra:

• authentication
• authorization
• brugerroller
• least privilege
• sessioner
• logging
• backups
• secrets
• persondata

Sikkerhedsniveauet skal passe til data, brugere og risiko.

Audit log og historik

Når ansvar og sporbarhed er vigtigt, kan systemet registrere:

• hvem der ændrede noget
• hvornår ændringen skete
• tidligere status eller værdi
• hvem der godkendte

Audit log er ikke nødvendig i alle små værktøjer. Men hvis spørgsmålet ofte er “hvem ændrede dette?”, er historik sandsynligvis relevant.

Hvad sker der, hvis systemet fejler?

Et internt system kan blive forretningskritisk.

Spørg derfor før lancering:

• Kan medarbejderne fortsætte arbejdet?
• Kan data genskabes?
• Findes backup?
• Hvem modtager fejl?
• Hvad sker der med integrationer?
• Kan jobs genkøres uden at skabe dubletter?
• Hvem har ansvar for teknisk drift?

Fejltilstande bør være en del af systemdesignet fra start.

Hvem ejer systemet og koden?

Afklar før projektet:

• kildekode
• repository
• database
• hosting
• domæne eller subdomæne
• tredjepartskonti
• dokumentation
• deployment
• backups

AS Web Solutions beskriver aktuelt sin model sådan, at kunden som udgangspunkt ejer den specialudviklede kode efter betaling, mens tredjepartssoftware og open source følger deres egne licenser.

Vedligeholdelse efter lancering

Et internt system kan efter launch kræve:

• sikkerheds- og dependency-opdateringer
• hosting
• backupkontrol
• tilpasning af integrationer
• fejlrettelser
• ændringer efter reel brugerfeedback

Vedligeholdelse og feature-udvikling bør adskilles, så et stabilt system ikke automatisk bliver et evigt udviklingsprojekt.

Hvad påvirker prisen på et internt system?

Prisen påvirkes især af:

• antal brugerroller
• workflows og godkendelsestrin
• datamodel
• datamigration
• integrationer
• dokumenthåndtering
• notifikationer
• rapportering
• sikkerhedskrav
• administration
• test
• drift

Det giver derfor mere mening at scope én første proces end at gætte en pris ud fra ordet “internt system”.

AS Web Solutions' aktuelle prisoversigt beskriver en webapplikation/portal som et fokuseret MVP og understreger, at endelig pris afhænger af projektets omfang, integrationer og funktionalitet.

Dokumenteret eksempel: Sporting Health Club

AS Web Solutions' aktuelle projektoversigt dokumenterer et internt medarbejdersystem for Sporting Health Club, hvor personaleadministration tidligere foregik i regnemodeller og spreadsheets.

Den dokumenterede løsning samlede data centralt og brugte rollebaseret adgang med Admin, Manager og Staff. Den omfattede også godkendelsesprocesser for managers og et mobilvenligt interface.

Casen illustrerer pointen: løsningen samlede data, roller og arbejdsgange omkring en eksisterende administrativ proces.

Se Sporting Health Club-casen i AS Web Solutions' projektoversigt.

Hvornår bør virksomheden ikke bygge et internt system?

Byg sandsynligvis ikke custom software, hvis:

• et eksisterende system løser behovet godt
• processen sker sjældent
• arbejdsgangen ændrer sig hver uge
• bedre procesdisciplin løser problemet
• en simpel automation er nok
• et dashboard er nok
• Excel fungerer uden væsentlig friktion
• ingen ejer processen
• værdien ikke kan retfærdiggøre udvikling og drift

At vælge ikke at bygge kan være den rigtige tekniske beslutning.

Røde flag før et systemprojekt

Stop op, hvis:

• “vi bygger bare alle funktioner fra starten”
• ingen kan definere MVP
• hver stakeholder vil have sit eget modul
• processen ikke er dokumenteret
• eksisterende data er meget dårlige
• ingen ejer produktet internt
• integrationer antages at være nemme uden API-review
• ingen har tænkt på drift
• custom vælges primært fordi det lyder bedre

Et systemprojekt bør reducere uklarhed - ikke kode den fast.

14 spørgsmål før virksomheden bygger et internt system

1. Hvilket konkret problem skal systemet løse? Beskriv problemet uden at nævne teknologi.
2. Hvem bruger systemet? Identificér faktiske brugergrupper.
3. Hvor ofte udføres processen? En sjælden proces er en svagere kandidat.
4. Hvor lever data i dag? Kortlæg ark, mails og systemer.
5. Hvilket system ejer data? Definér source of truth.
6. Hvilke roller kræves? Medarbejder, manager, administrator eller andre.
7. Hvad skal brugeren kunne gøre? Ikke kun hvad brugeren skal kunne se.
8. Hvilke undtagelser findes? Beskriv de mest almindelige fejl- og særtilfælde.
9. Hvilke integrationer kræves? Undersøg API-adgang før estimat.
10. Hvilke data skal migreres? Ikke al historik behøver at flytte med.
11. Hvad er absolut nødvendigt i version 1? Skeln MVP fra ønskeliste.
12. Hvordan måler vi forbedringen? Brug virksomhedens egen baseline.
13. Hvem ejer systemet internt? Der skal være ansvar efter lancering.
14. Hvad sker der, hvis systemet er utilgængeligt? Definér drift og fallback.

En praktisk beslutningsmatrix

Tabellen er et godt første filter før et systemprojekt.

Sådan vurderer du, om virksomheden er klar

Virksomheden er typisk klar til at undersøge et internt system, når:

• problemet er veldefineret
• processen er relativt stabil
• brugerne er identificeret
• friktionen er tydelig og kan måles
• standardsoftware er vurderet
• dataejerskab kan afklares
• én første proces kan udvælges
• der findes en intern ansvarlig
• drift efter launch kan håndteres

Hvis flere af punkterne mangler, er procesafdækning sandsynligvis næste skridt - ikke udvikling.

Fra problem til første version

En praktisk proces er:

1. Dokumentér det nuværende workflow.
2. Find flaskehalse og gentagne manuelle trin.
3. Fjern unødvendige trin.
4. Undersøg standardsoftware.
5. Vurder dashboard, automation og integration.
6. Hvis custom stadig giver mening: scope én proces.
7. Definér brugere, data og roller.
8. Byg og test MVP.
9. Brug løsningen i virkelig drift.
10. Udvid først derefter.

Et internt system bør ikke starte med en liste over funktioner. Det bør starte med én konkret arbejdsgang, de personer der bruger den, de data den kræver, og de problemer virksomheden oplever i dag.

Hvis processen er vokset ud af spreadsheets, mails eller standardværktøjer, kan AS Web Solutions hjælpe med at kortlægge den og vurdere, om udvikling af et internt system faktisk er det rigtige næste skridt.

FAQ

Hvad er et internt system?

Et internt system er software til virksomhedens egne medarbejdere, som samler data, roller og handlinger omkring en konkret arbejdsgang.

Hvornår er Excel ikke længere nok?

Når flere brugere, versioner, godkendelser, adgangsbehov og manuelle overleveringer gør arket til en forretningskritisk driftsplatform frem for et fleksibelt regneark.

Hvad er forskellen på et internt system og et dashboard?

Et dashboard fokuserer primært på overblik. Et internt system lader typisk brugerne både se data og udføre handlinger gennem regler og workflows.

Hvad er forskellen på et internt system og en webapp?

Et internt system er en type webapplikation med fokus på medarbejdernes interne arbejdsgange. Webapp er den bredere tekniske kategori.

Skal man bygge custom eller bruge standardsoftware?

Brug standardsoftware, hvis det løser behovet godt. Custom giver først mening, når workflowet er særligt nok til, at standardværktøjer skaber vedvarende friktion eller mangler centrale funktioner.

Kan et internt system integreres med eksisterende systemer?

Ja, hvis de relevante systemer har brugbar API- eller dataadgang. Integration bør scopes ud fra dataejerskab, adgang, datakvalitet og fejlscenarier.

Kan man starte med én proces?

Ja. Det er ofte den mest robuste tilgang. Vælg én stabil og værdifuld arbejdsgang og test den i drift før næste modul bygges.

Hvad koster et internt system?

Der findes ikke én standardpris. Scope påvirkes blandt andet af roller, workflows, datamigration, integrationer, sikkerhed og drift.

Hvem bør eje systemet internt?

En tydelig forretningsejer bør have ansvar for workflow og prioriteringer, mens teknisk drift og vedligehold også skal have en kendt ejer.

Hvordan ved man, om investeringen giver mening?

Mål den nuværende proces først: frekvens, manuelle trin, ventetid, genbehandling og friktion. Sammenlign derefter med det forventede scope og de alternativer, der er billigere eller enklere.