Hvordan forberede virksomheten på valg av workflow-/BPM-/RPA-/ERP-/CRM-system uten å bli avhengig av leverandøren?

Skriv deretter ned krav som beskytter mot leverandørbinding: eksport av data og sakshistorikk i et åpent format, dokumentert API, prosesser beskrevet i BPMN-standarden, rett til egen konfigurering og klare regler for å avslutte avtalen. Navngi de risikoene dere kan identifisere i dag. Ikke vær naiv – skriv ned alle risikoer. Sammenlign tilbud ut fra egne scenarier og med total kostnad over flere år (investering pluss løpende driftskostnader). Lisenser, fornyelser, opplæring, vedlikehold av teamet, endringer, migreringer. Tenk gjennom hvor sannsynlig det er at leverandøren mister nøkkelkonsulenter, bestemmer seg for å erstatte administratorer og utviklere med KI, eller slutter å støtte dagens driftssystem.

Dette innlegget er for styrer i selskaper og kommunale foretak som ønsker å rydde opp i flyten av dokumenter, kostnadsfakturaer, kontrakter eller søknader, og som skal velge et workflow-system – det vil si et verktøy som fører en sak fra én person til den neste etter fastsatte regler. Vanligvis finnes det tre veier å velge mellom: en ferdig BPM-plattform, et low-code-verktøy eller et skreddersydd system bygget på bestilling; prinsippene nedenfor gjelder for alle tre. Innlegget er også nyttig for CFO-er, siden det ofte er de som til slutt betaler for konsekvensene av et dårlig valg.

Hvorfor leverandørbinding oppstår allerede ved start

Leverandørbinding skyldes sjelden én enkelt dårlig beslutning. Den begynner vanligvis tidligere enn virksomheten legger merke til: prosessene blir beskrevet i leverandørens verktøy i stedet for i egne dokumenter; data og sakshistorikk ligger i et format som ikke lar seg hente ut enkelt; kun implementeringspartneren kjenner konfigurasjonen; og avtalen sier mye om implementeringen, men lite om hva som skjer når virksomheten ønsker å gå videre. Etter noen år koster det å bytte system mer enn å vedlikeholde det – selv om det ikke lenger dekker behovene.

Trinn 1. Beskriv prosessene før dere snakker med leverandører

Før en forespørsel om tilbud utarbeides, lønner det seg å beskrive arbeidsflytene systemet skal understøtte: hvem melder inn en sak, hvem godkjenner den og i hvilken rekkefølge, hvilke unntak og terskler som finnes (for eksempel en annen vei over et bestemt beløp), hvilke frister som gjelder, og hvilket beslutningsspor som skal etterlates med tanke på en eventuell revisjon. Det lønner seg å skrive dette ned i BPMN-standarden, som forstås av ulike verktøy. Da tilhører prosessbeskrivelsen virksomheten – ikke systemet.

Uten en slik beskrivelse ender man opp med å sammenligne leverandørenes presentasjoner i stedet for løsningene. Hver demonstrasjon ser bra ut, for leverandøren viser sitt beste scenario – ikke deres vanskeligste unntak.

Trinn 2. Sjekk hva dere allerede har

En del av arbeidsflytene kan ofte løses i verktøy virksomheten allerede har: i CRM, i fagsystemer, i sak-/arkivsystemet eller i kontorpakken. Noen ganger er konklusjonen fra analysen at det ikke trengs et nytt system, og at det holder med en endring i rutiner eller konfigurasjon. En slik kartlegging viser også hvilke integrasjoner det nye systemet må håndtere, for eksempel mot økonomisystemet og KSeF (det polske e-fakturasystemet), samt hvor informasjon i dag går tapt. Mer om dette: kartlegging av IT-systemer.

Trinn 3. Krav som beskytter mot leverandørbinding

Disse kravene bør skrives inn i forespørselen om tilbud som vilkår – ikke som ønsker:

1. Eksport av data og sakshistorikk i et åpent, dokumentert format, når som helst og uten ekstra kostnad.
2. Dokumentert API for integrasjon med andre systemer, med rett for andre leverandører til å benytte det.
3. Prosesser beskrevet i en standard (BPMN) som kan eksporteres og gjenskapes andre steder.
4. Rett til konfigurering ved eget team eller en hvilken som helst partner, med dokumentasjon av endringer.
5. Regler for å avslutte avtalen: overgangsperiode, bistand til datamigrering og en kostnad kjent på forhånd.
6. Fritt valg av driftspartner: om man etter implementeringen kan bytte til et annet implementeringsselskap uten å miste produsentens support.

Det samme gjelder RPA, ERP og CRM

Disse prinsippene gjelder for ethvert system som strukturerer arbeidet i virksomheten. Men hver gang lønner det seg å starte med spørsmålet om hva man ønsker å oppnå, for svaret avgjør om man i det hele tatt velger riktig type verktøy.

RPA. Det første spørsmålet er: hvorfor akkurat RPA, og ikke BPM? En programvarerobot overtar repeterende oppgaver fra mennesker i eksisterende systemer, men endrer ikke selve prosessen; BPM strukturerer selve prosessen. Hvis målet er å avlaste ansatte fra å overføre data manuelt mellom systemer, kan en robot være tilstrekkelig. Hvis målet er en ny, kortere saksflyt, befester roboten ofte den gamle. En robot er dessuten avhengig av andre systemers skjermbilder og formater: enhver endring i disse kan stoppe den, så det lønner seg å kjenne kostnaden ved å vedlikeholde scenariene og ha dem beskrevet utenfor produsentens verktøy.

ERP. Her er nøkkelspørsmålet: skal ERP-systemet gi oss beste praksis og ferdige prosesser, eller skal det støtte våre egne prosesser som bygger konkurransefortrinn? I det første tilfellet lønner det seg å holde seg til systemets standard og begrense tilpasninger, siden hver endring gjør oppdateringer og partnerbytte vanskeligere. I det andre tilfellet fungerer det noen ganger bedre med et enkelt ERP-system omsluttet av et smidig BPM-system, der man endrer de prosessene som utmerker virksomheten, uten å bygge om kjernen. I begge tilfeller må finans-, lager- og personaldata, samt integrasjoner mot KSeF og banker, kunne hentes ut i sin helhet, inkludert historikk.

CRM. Før man begynner å sammenligne tilbud, bør man avklare hva man legger i begrepet CRM: å strukturere kundeservice, flerkanalssalg eller en plattform for å hente inn kontrakter. Dette er tre ulike prosjekter, med ulike brukere, ulike integrasjoner og ulike suksessmål. Uavhengig av variant bør eksport av kundedatabasen med kontakthistorikk og samtykker, samt API mot salgs- og kundeservicesystemer, være et krav i forespørselen om tilbud – ikke et tillegg.

Trinn 4. Sammenlign total kostnad, ikke lisensprisen

Tilbud bør sammenlignes med total kostnad over flere år: innkjøp og implementering, drift og lisenser, videreutvikling og kostnaden ved å avslutte avtalen. Den billigste lisensen kan vise seg å bli den dyreste i tredje år, når hver prosessendring betyr et betalt oppdrag hos én og samme partner. Sammenligningen gjøres best med deres egne scenarier: la hver leverandør vise det samme vanskelige tilfellet fra deres virksomhet. Mer om vurdering av tilbud: vurdering av tilbud og leverandørsamtaler.

Trinn 5. Overlevering og driftsavtale

Systemet bør overleveres etter på forhånd avtalte testscenarier og kriterier, ikke etter leverandørens egne påstander. Driftsavtalen bør angi hvor raskt feil rettes, hvem som gjør endringer og til hvilken pris, og bekrefte bestemmelsene om dataeksport og avslutning av avtalen.

Eksempel fra praksis

I en konsernkonstellasjon av datterselskaper i en internasjonal konsern brukte selskapet et sentralt ERP-system, samtidig som det hadde behov for å automatisere finansprosesser innenfor procure-to-pay-gruppen, og dette i tråd med konsernets innkjøpsretningslinjer (corporate purchasing guidelines). Fristelsen var stor til å ta i bruk konsernets egne samarbeidsverktøy, men disse viste seg å være ganske dyre og oppfylte verken kravene til uavhengighet eller muligheten for enkel utgang dersom det skulle oppstå problemer.

I møter med interessentene utarbeidet vi en detaljert kravspesifikasjon som gikk utover standardfunksjonene i ferdige løsninger. Vi utviklet flere alternative integrasjonsmåter mot fagsystemene, samt mekanismer som begrenset risikoen for binding til én enkelt leverandør. Resultatet ble en samlet applikasjonsstrategi basert på standarder, og et miljø der nye arbeidsflyter utvikles smidig, gjennom prototyping i korte møter med prosesseierne – også de ikke-tekniske. Dette miljøet omslutter ERP-systemet: det gir stor fleksibilitet der virksomheten utmerker seg, uten kostnadene ved store implementeringer.