Vigtigste pointer fra indlægget
Processer før værktøjet
Hvem godkender, hvad er undtagelserne, og hvilket beslutningsspor skal bevares.
Oversigt over det, I allerede har
CRM, fagsystemer, journaliseringssystem og kontorpakke kan ofte klare en del af arbejdsgangene.
Krav mod vendor lock-in
Eksport, API, BPMN, rettigheder til konfiguration, exitplan.
Omkostning over flere år
Køb, implementering, vedligeholdelse og exitomkostning, sammenlignet på jeres scenarier.
Zdjęcia ilustracyjne
Skriv derefter de krav ned, der beskytter mod vendor lock-in: eksport af data og sagshistorik i et åbent format, dokumenteret API, processer beskrevet i BPMN-standarden, ret til egen konfiguration og klare regler for exit fra kontrakten. Navngiv de risici, I allerede i dag kan identificere. Vær ikke naiv, og skriv alle risici ned. Sammenlign tilbud på jeres egne scenarier og ud fra den samlede omkostning over flere år (investering plus løbende driftsomkostninger). Licenser, fornyelser, oplæring, vedligeholdelse af teamet, ændringer, migreringer. Overvej, hvor sandsynligt det er, at leverandøren mister nøglekonsulenter, beslutter at erstatte administratorer og udviklere med AI, eller holder op med at understøtte det nuværende styresystem.
Dette indlæg henvender sig til ledelser i virksomheder og kommunale selskaber, der vil skabe orden i dokumenthåndtering, omkostningsfakturaer, kontrakter eller ansøgninger, og som står over for valget af et workflow-system – det vil sige et værktøj, der fører en sag fra én person til den næste efter fastlagte regler. Der er som regel tre veje at vælge imellem: en færdig BPM-platform, et low-code-værktøj eller et skræddersyet system udviklet til formålet; principperne nedenfor gælder for alle tre. Indlægget er også relevant for finansdirektører, for det er typisk dem, der betaler for konsekvenserne af et dårligt valg.
Hvorfor vendor lock-in opstår fra starten
Vendor lock-in opstår sjældent som følge af én enkelt dårlig beslutning. Det begynder som regel tidligere, end virksomheden lægger mærke til: processerne bliver beskrevet i leverandørens værktøj i stedet for i jeres egne dokumenter; data og sagshistorik ligger i et format, der ikke let kan hentes ud; kun implementeringspartneren kender konfigurationen; og kontrakten siger meget om implementeringen og lidt om, hvad der sker, når virksomheden vil skifte leverandør. Efter nogle år koster det mere at skifte system end at vedligeholde det, selv hvis det ikke længere matcher behovene.
Trin 1. Beskriv processerne, før I taler med leverandører
Inden der udarbejdes en udbudsforespørgsel, er det en god idé at beskrive de arbejdsgange, systemet skal understøtte: hvem rejser sagen, hvem godkender den og i hvilken rækkefølge, hvad er undtagelserne og tærsklerne (for eksempel en anden vej over et bestemt beløb), hvad er fristerne, og hvilket beslutningsspor skal bevares i tilfælde af en revision. Det er bedst at nedskrive det i BPMN-standarden, som forskellige værktøjer forstår. Så tilhører procesbeskrivelsen virksomheden og ikke systemet.
Uden en sådan beskrivelse sammenligner man leverandørernes præsentationer og ikke selve løsningerne. Enhver demo ser godt ud, fordi leverandøren viser sit bedste scenarie og ikke jeres sværeste undtagelse.
Trin 2. Undersøg, hvad I allerede har
En del af arbejdsgangene kan ofte håndteres i de værktøjer, virksomheden allerede har: CRM, fagsystemer, journaliseringssystem eller kontorpakke. Nogle gange er konklusionen fra analysen, at der ikke er brug for et nyt system, men blot en ændring af procedure eller konfiguration. En sådan kortlægning viser også de integrationer, det nye system skal kunne håndtere, for eksempel med finans- og regnskabssystemet og KSeF (det polske nationale e-fakturasystem), samt de steder, hvor information i dag går tabt. Læs mere: kortlægning af it-systemer.
Trin 3. Krav der beskytter mod vendor lock-in
Disse krav bør skrives ind i udbudsforespørgslen som betingelser og ikke som ønsker:
- Eksport af data og sagshistorik i et åbent, dokumenteret format, når som helst og uden ekstra betaling.
- Dokumenteret API til integration med andre systemer, med ret til at andre leverandører kan bruge det.
- Processer beskrevet i en standard (BPMN), som kan eksporteres og genskabes andetsteds.
- Ret til konfiguration udført af jeres eget team eller en hvilken som helst partner, med dokumentation af ændringer.
- Regler for exit fra kontrakten: en overgangsperiode, hjælp til datamigrering og en omkostning, der er kendt på forhånd.
- Valg af driftspartner: om man efter implementeringen kan skifte til en anden implementeringsvirksomhed uden at miste producentens support.
Det er som at leje et kontor med en kontrakt, der fortæller, hvad det koster at flytte ind, men intet siger om at flytte ud. Så længe alt fungerer, lægger ingen mærke til det. Problemet opstår den dag, man skal flytte.
Det samme gælder RPA, ERP og CRM
Disse principper gælder for ethvert system, der skaber orden i virksomhedens arbejde. Hver gang er det dog værd at starte med spørgsmålet om, hvad man vil opnå, for svaret afgør, om man overhovedet vælger den rigtige type værktøj.
RPA. Det første spørgsmål er: hvorfor netop RPA og ikke BPM? En softwarerobot overtager menneskets gentagne opgaver i eksisterende systemer, men ændrer ikke selve processen; BPM skaber derimod orden i processen. Hvis målet er at aflaste medarbejderne fra at overføre data mellem systemer, kan en robot være tilstrækkelig. Hvis målet er en ny, kortere sagsgang, fastholder en robot ofte den gamle. En robot er desuden afhængig af andre systemers skærmbilleder og formater: enhver ændring i dem kan stoppe den, så det er en god idé at kende omkostningen ved at vedligeholde scenarierne og have en beskrivelse af dem uden for producentens værktøj.
ERP. Her er det centrale spørgsmål: skal ERP-systemet levere bedste praksis og færdige processer, eller skal det understøtte jeres egne processer, som skaber konkurrencefordel? I det første tilfælde er det en god idé at holde sig til systemets standard og begrænse tilpasninger, da hver tilpasning gør opdateringer og leverandørskifte sværere. I det andet tilfælde fungerer det nogle gange bedre med et enkelt ERP-system omgivet af et agilt BPM-system, hvor man ændrer de processer, der adskiller virksomheden fra konkurrenterne, uden at skulle lave om på kernen. I begge tilfælde skal finans-, lager- og personaledata samt integrationer med KSeF og banker kunne hentes ud i deres helhed, sammen med historikken.
CRM. Før man begynder at sammenligne tilbud, er det en god idé at fastlægge, hvad man forstår ved CRM: at skabe orden i kundeserviceprocesserne, flerkanalssalg eller en platform til at indhente kontrakter. Det er tre forskellige projekter med forskellige brugere, forskellige integrationer og forskellige succeskriterier. Uanset hvilken variant der vælges, bør eksport af kundedatabasen med kontakthistorik og samtykker samt API til salgs- og kundeservicesystemer være en betingelse i udbudsforespørgslen og ikke et tilvalg.
Trin 4. Sammenlign den samlede omkostning, ikke licensprisen
Det er en god idé at opstille tilbuddene i den samlede omkostning over flere år: køb og implementering, vedligeholdelse og licenser, videreudvikling samt omkostningen ved at forlade kontrakten. Den billigste licens kan vise sig at være den dyreste i det tredje år, når enhver procesændring betyder en betalt opgave hos én bestemt partner. Sammenligningen bør helst laves på jeres egne scenarier: lad hver leverandør vise den samme svære case fra jeres virksomhed. Læs mere om vurdering af tilbud: vurdering af tilbud og samtaler med leverandører.
For en finansdirektør er de to vigtigste tal som regel dem, der ikke står i tilbuddet: omkostningen ved at ændre en proces efter implementeringen og omkostningen ved at forlade leverandøren. Det er værd at bede om dem direkte i forbindelse med vurderingen af tilbuddene.
Trin 5. Overtagelse og vedligeholdelsesaftale
Systemet bør overtages efter forudaftalte testscenarier og kriterier og ikke efter leverandørens egne udsagn. Vedligeholdelsesaftalen bør angive, inden for hvilken tid fejl rettes, hvem der foretager ændringer og til hvilken pris, samt bekræfte bestemmelserne om dataeksport og exit fra kontrakten.
Eksempel fra praksis
I en gruppe af datterselskaber under en international koncern anvendte virksomheden et centralt ERP-system, samtidig med at den havde behov for at automatisere finansielle processer inden for procure-to-pay-gruppen, og det i overensstemmelse med koncernens indkøbsretningslinjer (corporate purchasing guidelines). Der var et stærkt pres for at vælge koncernens egne samarbejdsværktøjer, men de viste sig at være ret dyre og opfyldte hverken kravene til uafhængighed eller muligheden for en nem exit, hvis der skulle opstå problemer.
På møder med interessenterne udarbejdede vi en detaljeret kravspecifikation, der rakte videre end de standardfunktioner, som færdige løsninger tilbyder. Vi udviklede flere alternative måder at integrere med fagsystemerne på samt mekanismer, der begrænsede risikoen for binding til én leverandør. Resultatet blev en sammenhængende applikationsstrategi baseret på standarder og et miljø, hvor nye arbejdsgange opstår agilt gennem prototyping på korte møder med procesejerne, også de ikke-tekniske. Dette miljø omgiver ERP-systemet: det giver stor fleksibilitet dér, hvor virksomheden adskiller sig fra konkurrenterne, uden omkostningerne ved store implementeringer.