Sådan vælger I en dansk udviklingspartner

En virksomhed med tolv ansatte har som regel ikke et it-problem. Den har en arbejdsgang, hvor de samme oplysninger bliver tastet ind to eller tre gange, fordi de systemer, der findes, ikke taler sammen. Det er ikke et spørgsmål om at være bagud. Det er et spørgsmål om, at ingen har haft tid til at sætte sig ned og se på det.

Spørgsmålet ”hvem i Danmark kan bygge det til os” har derfor et forarbejde, og forarbejdet afgør, hvor godt svaret bliver.

Beskriv opgaven, ikke løsningen

Den mest almindelige fejl i en henvendelse er, at den beskriver et system i stedet for et problem. ”Vi skal have en app” er en løsning. ”Vores montører skriver timer på en seddel, som bogholderen taster ind om fredagen” er en opgave, og den kan besvares.

Skriv derfor tre ting ned, før I kontakter nogen som helst: hvad der sker i dag, hvor det går galt, og hvad I gerne vil kunne i stedet. Fem minutter i almindeligt dansk er nok. En kravspecifikation er ikke nødvendig på det her tidspunkt, og den er ofte skadelig, fordi den låser løsningen, før nogen har set på problemet.

De seks spørgsmål, der skiller partnere ad

1. Hvem ejer det, der bliver bygget, når projektet er slut? Kildekode, data og rettigheder skal stå skriftligt, og svaret skal være til at forstå uden en jurist ved siden af.
2. Hvad sker der, hvis I vil skifte leverandør om to år? Kan I tage systemet med, og hvad koster det at få det udleveret i en form, en anden kan arbejde videre i?
3. Hvem retter fejl, når de opstår, og hvordan aftales det? Drift er ikke det samme som udvikling, og de to ting bør aftales hver for sig.
4. Hvor ligger data, og hvem har adgang? Både i drift og hos eventuelle underleverandører.
5. Hvad er den mindste version, der giver værdi? En partner, der ikke kan svare på det, sælger et projekt, ikke en løsning.
6. Hvad skal I selv levere undervejs? Adgange, beslutninger og tid fra de medarbejdere, der kender arbejdsgangen. Det er næsten altid dét, der afgør, om en tidsplan holder.

Kontrakten behøver ikke være skræmmende

Staten har i mange år brugt et sæt standardkontrakter til it, K01 til K04, hvor K01 er tænkt til kortvarige projekter med begrænset tilpasning, K02 til større projekter med etapevise delleverancer, K03 til agile forløb og K04 til drift. De er offentligt tilgængelige og gode at læse, netop fordi de sætter ord på de spørgsmål, ingen husker at stille. Digitaliseringsstyrelsen skriver samtidig selv, at K01, K02 og K03 ikke længere er tidssvarende på flere områder og kræver tilpasning, og at K04 er den mest anvendte.

Pointen for en virksomhed med tolv ansatte er ikke at bruge dem. Den er, at de emner, kontrakterne behandler, er de samme uanset projektets størrelse: leverance, ændringer, fejl, ophør og hvem der ejer hvad.

Der findes offentlig hjælp til afklaringen

SMV:Digital, som drives af Digitaliseringsstyrelsen og Erhvervshus Midtjylland sammen med landets erhvervshuse, giver mulighed for at søge tilskud til privat rådgivning, der skal afklare potentialet ved digitalisering. Ordningen har efter eget udsagn støttet mere end 7.000 digitale projekter i SMV'er siden 2018. Det er værd at undersøge, før I betaler for afklaringen selv.

Sådan bruger I et estimat

Et estimat er ikke et tilbud, og det skal heller ikke læses som et. Det, et godt estimat gør, er at sætte et spænd på opgaven, sige hvad der bygges først, og sige ærligt fra, hvis idéen ikke holder. Får I tre estimater, der ligger meget langt fra hinanden, er det som regel ikke prisen, der er forskellig. Det er forståelsen af opgaven.

Beder I flere om at regne på det samme, så giv dem den samme beskrivelse. Ellers sammenligner I ikke tilbud, I sammenligner gætterier.

Vil I have opgaven regnet igennem hos os, kan I beskrive den i Tegnestuen, og rammerne for, hvad tingene typisk lander i, står på priser. Har I brug for at se, hvad vi selv har bygget og har i drift, ligger det under referencer.

Kilder

• Standardkontrakter K01 til K04, Digitaliseringsstyrelsen. Læst 31. august 2026.
• SMV:Digital, Digitaliseringsstyrelsen. Læst 31. august 2026.