Behovsafdækning før systemkøb: spørgsmål og kriterier for SMV'er

Hvorfor behovsafdækning vejer tungere i en SMV

EU's SMV-definition dækker virksomheder med under 250 ansatte og en årlig omsætning under en fastsat grænse. Inden for definitionen skelnes der mellem mikro-, små og mellemstore virksomheder (Europa-Kommissionens brugervejledning til SMV-definitionen).

Regeringens Økonomiske Redegørelse viser, at SMV'erne står for 63 pct. af fuldtidsbeskæftigelsen og mere end halvdelen af omsætningen i privat erhverv.

Samme redegørelse peger på, at SMV'ernes vækst siden 2019 har været beskeden målt mod det historiske gennemsnit. Det gælder værdiskabelse, produktivitet og beskæftigelse.

To forhold gør behovsafdækningen ekstra tung i den størrelse virksomhed.

For det første er specialviden en knap ressource: 60 pct. af de SMV'er, der har rekrutteret eller forsøgt at rekruttere it-specialister, har haft svært ved at besætte stillingen (analyse fra Digitaliseringsstyrelsen, gengivet af DI).

For det andet er kompetencegabet ikke kun teknisk: I en undersøgelse, Wilke har gennemført for 3, svarer 33 pct. af de adspurgte SMV'er, at manglende specialviden er deres største udfordring på cybersikkerhedsområdet. 47 pct. føler sig ikke godt rustet til at håndtere et cyberangreb.

Et forkert eller utilstrækkeligt systemvalg rammer derfor bredere end en enkelt afdeling. Det binder arbejdstid, kræver kompetencer, virksomheden måske ikke har, og kan tvinge dyre nødløsninger igennem senere.

I debatindlægget fra Industriens Fond og GTS-foreningen fremhæves det, at det for mange SMV'er er urealistisk at opbygge egne forsknings- og udviklingsmiljøer. Et fejlslagent udviklingsprojekt kan få langt større konsekvenser for en mindre virksomhed end for en international koncern.

Den samme asymmetri gælder ved systemkøb: Jo mindre organisation, jo mindre buffer til at rette op på et valg, der ikke passede til driften.

Fra daglig drift til konkrete systemkrav

Start med processerne, ikke produkterne. Vælg de 5-10 arbejdsgange, der fylder mest eller skaber flest fejl – ordre til faktura, tilbud til kontrakt, indkøb til betaling, kundeservice til sag, løn til bogføring.

Beskriv for hver: hvem udfører opgaven, hvilke trin indgår, hvilke data opstår eller ændres, hvor oplysninger registreres i dag (regneark, mail, fagsystem, papir), og hvor der bruges tid på manuel genindtastning, kopiering eller efterkontrol.

Det er disse observationer, der bliver til systemkrav – ikke leverandørens funktionsliste.

Skeln mellem behov og ønske med et enkelt spørgsmål pr. punkt: Hvis systemet ikke kan dette, hvad sker der så i driften?

Kan opgaven ikke gennemføres, skal den løses manuelt uden for systemet, eller opstår der en konkret fejl-, tids- eller sikkerhedsrisiko, er der tale om et behov.

Er svaret, at opgaven blot bliver mere bekvem, er der tale om et ønske, som skal vurderes mod sin pris.

Skriv svarene ned i et kravdokument med kolonnerne: krav, begrundelse i driften, hvem der har kravet, og kategori (ufravigeligt eller ønske).

Medtag dataadgang og dataejerskab fra begyndelsen. Notér, hvilke data der skal ind i systemet, hvem der må se og ændre dem, og hvordan de kan komme ud igen. Angiv i hvilket format, med hvilken frekvens og til hvilken pris.

Det sidste punkt bliver afgørende, hvis I senere vil skifte leverandør.

Har I ikke kompetencerne internt til at vurdere datamodeller, integrationer eller sikkerhedskrav, er ekstern bistand en realistisk vej.

GTS-institutter hjælper virksomheder med at omsætte ny viden til konkrete løsninger og giver adgang til specialiseret rådgivning og testfaciliteter. De fungerer som en bro mellem forskning og marked.

DI's SMV-portal tilbyder tilsvarende rådgivning blandt andet inden for digitalisering.

Afsætning af behov før systemkøb – afgørende trin

Spørgsmål, der afdækker behovet før første demo

Skriv kravene ned og send dem til leverandøren, før I ser en demo. Ellers styrer sælgeren demoens rækkefølge, og de viste funktioner bliver let standarden for, hvad I tror, I har brug for.

Brug i stedet disse spørgsmål som afdækning mod jeres egen kravliste: Hvem i vores organisation skal bruge systemet dagligt, og hvor mange er det om to år?

Hvilke af vores processer understøtter systemet direkte, og hvilke skal stadig køre ved siden af?

Hvilke systemer skal det integrere med – og hvordan: færdig integration, API, filudveksling eller manuel eksport?

Hvordan og hvor ofte kan vi trække vores egne data ud, og i hvilket format?

Fortsæt med rapportering og drift: Kan vi selv opstille de rapporter, ledelsen efterspørger, eller kræver det leverandøren?

Fungerer de centrale funktioner på mobil for medarbejdere ude hos kunder?

Hvad sker der, når vi fordobler antallet af brugere, ordrer eller transaktioner – og hvilken merpris udløser det?

Hvilke supportkanaler findes, hvornår har de åbent, og hvilke svartider er aftalt?

På hvilket sprog og i hvilket land ligger supporten og driften?

Hvor ofte opdateres systemet, hvordan varsles ændringer, og kan vi selv styre, hvornår de rulles ud?

Bed altid om skriftlige svar og om en samlet pris på det, der er nødvendigt for at komme i drift: implementering, migrering af eksisterende data, integrationer til jeres øvrige systemer, opsætning, oplæring og efterfølgende drift.

Bed også om at få oplyst prisstigninger og vilkår ved opsigelse.

Når svarene kommer skriftligt på jeres egne spørgsmål, kan de senere indgå i beslutningsgrundlaget – i modsætning til mundtlige løfter fra en demo.

Sikkerhed og beredskab som købskriterium – ikke en eftertanke

Sikkerhedsniveauet i danske SMV'er er bedre, end det har været, men ikke godt nok. 84 pct. har indført de to mest basale tiltag – backup af data og systematisk opdatering af software – mod 75 pct. året før.

16 pct. har fortsat ikke gennemført elementære initiativer som opdatering af software og backup af data (analysen 'Digital sikkerhed i danske SMV'er 2023' fra Digitaliseringsstyrelsen, gengivet af DI).

De to tiltag beskrives i samme kilde som et minimumsniveau for cybersikkerhed, som stort set alle virksomheder bør implementere.

I undersøgelsen fra Wilke for 3 er bekymringen til stede, men virksomhederne oplever barrierer for at handle: 61 pct. af de adspurgte SMV'er er bekymrede for cyberangreb.

Ifølge samme undersøgelse fremhæver virksomhederne manglende tid, begrænsede ressourcer, uklart overblik over risici og oplevelsen af, at området er komplekst.

Hvad koster det at lade være? Ifølge en analyse fra SMV Danmark koster et ransomware-angreb 376.350 kr. alene i tabt omsætning fra e-handel for en virksomhed med 10-49 ansatte.

I leverandøren CyberNordics materiale angives, at 85 pct. af cyberangreb sker uden for normal daglig arbejdstid. Gennemsnitlig tid før et angreb opdages er 212 dage.

Samme materiale angiver, at et ransomware-angreb kan koste op til 1.000 gange mere end en forebyggende sikkerhedsløsning.

Samme kilde beskriver en dansk produktionsvirksomhed med 45 ansatte, hvor en ransomware-hændelse ifølge kilden kostede over 350.000 kr. i driftstab og genoprettelse af data.

Tallene kommer fra en aktør, der sælger sikkerhedsløsninger, og bør derfor læses som leverandørens argument. De peger på de samme konsekvenser, som DI beskriver, når det påpeges, at cyberangreb kan lukke selv større virksomheder og arbejdspladser ned.

Omsæt det til konkrete krav i kravdokumentet: Hvordan tages backup, hvor ofte, hvor opbevares den, og hvornår er gendannelse sidst testet?

Hvem gennemfører opdateringer, og hvordan dokumenteres det?

Hvordan styres adgang – roller, rettigheder, fjernelse af adgange ved fratrædelser, flerfaktor?

Bliver hændelser logget, og hvem gennemgår loggen?

Hvem reagerer, hvis der kommer en alarm uden for arbejdstid, og inden for hvilken reaktionstid?

Hvor hostes data, hvem er underleverandører, og foreligger der databehandleraftale?

Og kan leverandøren levere de kompetencer, virksomheden ikke selv kan ansætte?

Cybersikkerhed i danske SMV'er – nøgletal og konsekvenser

SMV's udfordringer i IT- og cybersikkerhedsområdet

Kriterier og vægtning: fra must-have til pris

Del kravene i to grupper.

De ufravigelige krav skal formuleres, så de kan besvares med ja eller nej og efterprøves. Eksempler: 'systemet understøtter dansk bogføringskalender', 'data kan eksporteres komplet i maskinlæsbart format', 'backup gendannes inden for aftalt tid', 'opsætningen kræver ikke interne specialister ud over det aftalte'.

Ønskerne vurderes derimod efter vægt, fordi de skal vejes mod pris og kompleksitet.

De kriterier, der typisk bør indgå, er: funktionalitet i forhold til jeres kortlagte processer; brugervenlighed for de medarbejdere, der bruger systemet hver dag; sikkerhed og beredskab; integration til eksisterende systemer.

Dertil kommer totaløkonomi over en flerårig periode; leverandørens support og reaktionstider; skalerbarhed i brugere, data og funktioner; og exit – hvor let og hvor dyrt det er at flytte data og skifte leverandør.

Vægtningen kan gøres enkelt og dokumenterbart: Giv hver kategori en vægt, der summerer til 100 pct. Lad hver leverandør blive bedømt på en skala (for eksempel 1-5) pr. kategori ud fra de skriftlige svar og eventuelle tests, og gang score med vægt.

Læg sikkerhed og exit ind som selvstændige kategorier med reel vægt – ikke som bilag til funktionalitet.

Totaløkonomien skal omfatte licens eller abonnement, implementering, migrering af data, integrationer, oplæring, løbende drift og support, ændringer ved vækst samt omkostninger ved en eventuel udflytning.

Sammenlign først leverandørerne på totaløkonomien, når sikkerheds- og beredskabskravene er opfyldt. Ellers risikerer den billigste løsning at være den, der efterlader de største udgifter til senere.

Vigtige overvejelser ved systemkøb: Sikkerhed vs. pris

Involver dem, der skal bruge og betale for systemet

Sæt tre grupper om bordet med hver sin rolle. Ledelsen ejer budget og risiko. Den eller dem, der i dag varetager it-drift og systemejerskab, skal med. Nøglebrugere fra de funktioner, der skal arbejde i systemet hver dag, skal også med.

Nøglebrugerne leverer beskrivelserne af processer, data og smertepunkter, som kravene bygges på.

Ledelsen beslutter niveauet for sikkerhed, oppetid og support, inden priserne sammenlignes. Ellers bliver de krav nemt justeret ned ad gangen for at få budgettet til at passe.

Interessekonflikten mellem budget og sikkerhed er velbeskrevet: I leverandøren CyberNordics materiale beskrives det, hvordan anbefalinger fra en it-ansvarlig vejer tungt, mens direktørens blik ofte er rettet mod budgettet.

Derfor er det afgørende, at den it-ansvarlige kan argumentere klart for, hvorfor 'god nok' sjældent er godt nok.

Konflikten løses ikke ved at gentage, at sikkerhed er vigtig. Løsningen er at gøre konsekvenserne konkrete: Hvad koster nedetid i de processer, der er kortlagt? Hvilke data kan ikke genskabes? Hvilke minimumskrav må være opfyldt, uanset pris?

Tag også højde for, at systemet ikke må forudsætte interne specialkompetencer, virksomheden ikke kan rekruttere.

Beslut derfor eksplicit, hvad leverandøren skal dække – overvågning, opdateringer, support uden for arbejdstid, gendannelse – og hvad I selv kan løfte.

Fordel ansvaret skriftligt pr. opgave, og skriv ind i beslutningsreferatet, hvem der har godkendt hvilke krav og hvilket sikkerhedsniveau.

Afprøv løsningen i jeres egen virkelighed

En demo viser, hvad systemet kan i leverandørens hænder. En pilot viser, hvad det kan med jeres data og jeres medarbejdere.

Gennemfør derfor en afgrænset prøveperiode, hvor et lille antal nøglebrugere udfører udvalgte opgaver fra kravdokumentet med egne testdata – typisk en anonymiseret kopi af faktiske data.

Mål det, der er aftalt på forhånd: tid pr. opgave, antal manuelle ekstratrin, fejlrate, om integrationen faktisk udveksler data korrekt, og om rapporterne kan trækkes uden leverandørens hjælp.

Skriv succeskriterierne ned, før piloten begynder, og bed leverandøren om at bekræfte dem.

Aftal også, hvad der sker med data efter prøveperioden, og hvordan en eventuel opsigelse håndteres.

Brug pilotens resultater aktivt: Hvis et ufravigeligt krav ikke kan opfyldes i praksis, er det en grund til at sortere leverandøren fra – ikke til at lempe kravet midt i processen.

Hvis ønsker viser sig unødvendige i den daglige brug, kan de tages ud og give en lavere pris.

Beslutningsgrundlag og opfølgning efter køb

Beslutningen bør kunne forklares et år senere af nogen, der ikke var med i processen.

Saml kravdokumentet med behov, ønsker og ufravigelige krav. Saml vægtningen af kriterierne, leverandørernes skriftlige svar og totaløkonomiberegningen. Saml pilotens resultater målt mod de aftalte succeskriterier. Saml et beslutningsreferat, der angiver, hvem der besluttede hvad, og hvilke krav der eventuelt ikke blev opfyldt og hvorfor.

Det gør det muligt at vurdere både leverandøren og jeres egen kravstilling, hvis systemet skal skiftes eller udvides.

Behov ændrer sig med kunder, medarbejdere og regler, og et systemkøb er derfor ikke afsluttet ved idriftsættelsen.

Læg et fast tidspunkt ind for gennemgang – for eksempel årligt. Kontroller: Bruges funktionerne? Betaler vi for licenser, ingen bruger? Holder support og svartider, som de er aftalt? Er dataadgang og eksport stadig mulig uden leverandørens mellemkomst? Er backup og opdateringer fortsat gennemført og dokumenteret? Har ændringer i driften skabt nye krav, der ikke var med i det oprindelige dokument?

Juster kravdokumentet, så det afspejler den nuværende drift i stedet for den, der var grundlag for købet.

Processen til systemkøb i SMV – fra behov til beslutning