Hur förbereder man företaget inför valet av ett workflow-/BPM-/RPA-/ERP-/CRM-system utan att hamna i beroende av leverantören?

Skriv sedan ner de krav som skyddar mot inlåsning: export av data och ärendehistorik i ett öppet format, dokumenterat API, processer dokumenterade enligt BPMN-standarden, rätt till egen konfiguration och tydliga regler för att avsluta avtalet. Namnge de risker ni redan idag kan identifiera. Var inte naiv – skriv ner alla risker. Jämför anbuden utifrån era egna scenarier och den totala kostnaden över flera år (investering plus återkommande driftskostnader). Licenser, förnyelser, utbildning, underhåll av teamet, ändringar, migreringar. Fundera på hur sannolikt det är att leverantören förlorar nyckelkonsulter, bestämmer sig för att ersätta administratörer och utvecklare med AI, eller slutar stödja det nuvarande operativsystemet.

Det här inlägget vänder sig till styrelser i företag och kommunala bolag (spółka komunalna) som vill ordna upp hanteringen av dokument, kostnadsfakturor, avtal eller ansökningar och som står inför valet av ett workflow-system, det vill säga ett verktyg som för ett ärende från en person till nästa enligt fastställda regler. Normalt finns tre vägar att välja mellan: en färdig BPM-plattform, ett low-code-verktyg eller ett specialbyggt system; principerna nedan gäller för alla tre. Inlägget är också till nytta för ekonomidirektörer, eftersom det oftast är de som får betala för konsekvenserna av ett dåligt val.

Varför beroendet av leverantören uppstår redan från start

Inlåsning beror sällan på ett enda dåligt beslut. Den börjar vanligtvis tidigare än företaget märker: processerna beskrivs i leverantörens verktyg i stället för i egna dokument, data och ärendehistorik lagras i ett format som inte går att enkelt ta ut, bara implementationspartnern känner till konfigurationen, och avtalet säger mycket om implementeringen men lite om vad som händer när företaget vill avsluta samarbetet. Efter några år kostar det mer att byta system än att behålla det, även om det inte längre motsvarar behoven.

Steg 1. Beskriv processerna innan ni börjar prata med leverantörer

Innan en anbudsförfrågan tas fram är det värt att beskriva de flöden som systemet ska hantera: vem som anmäler ärendet, vem som godkänner det och i vilken ordning, vilka undantag och tröskelvärden som finns (till exempel en annan väg över ett visst belopp), vilka tidsfrister som gäller och vilket beslutsspår som ska finnas kvar inför en eventuell revision. Bäst är att dokumentera det enligt BPMN-standarden, som förstås av olika verktyg. Då tillhör processbeskrivningen företaget – inte systemet.

Utan en sådan beskrivning jämför man leverantörernas presentationer – inte lösningarna. Varje demo ser bra ut, eftersom leverantören visar sitt bästa scenario och inte ert svåraste undantag.

Steg 2. Undersök vad ni redan har

En del av flödena går ofta att hantera i verktyg som företaget redan har: i CRM, i verksamhetssystem, i ärendehanteringssystemet eller i kontorspaketet. Ibland blir slutsatsen av analysen att ett nytt system inte behövs, utan att det räcker med en ändring av rutiner eller konfiguration. En sådan inventering visar också vilka integrationer det nya systemet måste hantera, till exempel med ekonomisystemet och KSeF (det polska e-fakturasystemet), samt var information idag går förlorad. Läs mer: inventering av IT-system.

Steg 3. Krav som skyddar mot inlåsning

Dessa krav är värda att skriva in i anbudsförfrågan som villkor – inte som önskemål:

1. Export av data och ärendehistorik i ett öppet, dokumenterat format, när som helst och utan extra avgift.
2. Dokumenterat API för integration med andra system, med rätt för andra leverantörer att använda det.
3. Processer dokumenterade enligt en standard (BPMN) som går att exportera och återskapa någon annanstans.
4. Rätt till konfiguration av det egna teamet eller valfri partner, med dokumentation av ändringar.
5. Regler för att avsluta avtalet: övergångsperiod, hjälp med datamigrering och en kostnad som är känd i förväg.
6. Val av förvaltningspartner: om det efter implementeringen går att byta till ett annat implementeringsföretag utan att förlora tillverkarens support.

Samma sak gäller för RPA, ERP och CRM

Dessa principer gäller för alla system som ordnar upp företagets arbete. Varje gång är det dock värt att börja med frågan vad man vill uppnå, eftersom svaret avgör om man överhuvudtaget väljer rätt typ av verktyg.

RPA. Den första frågan är: varför just RPA och inte BPM? En mjukvarurobot tar över repetitiva mänskliga uppgifter i befintliga system, men ändrar inte själva processen; BPM ordnar upp själva processen. Om målet är att avlasta medarbetare från att skriva av data mellan system kan en robot räcka. Om målet är ett nytt, kortare ärendeflöde befäster roboten ofta det gamla. Roboten är dessutom beroende av andra systems skärmbilder och format: varje ändring i dem kan stoppa den, så det är värt att känna till kostnaden för att underhålla scenarierna och ha en beskrivning av dem utanför leverantörens verktyg.

ERP. Här är nyckelfrågan: ska ERP-systemet förse oss med branschens bästa praxis och färdiga processer, eller ska det stödja våra egna processer som bygger konkurrensfördelar? I det första fallet är det värt att hålla sig till systemets standard och begränsa ändringar, eftersom varje avvikelse försvårar uppdateringar och byte av partner. I det andra fallet fungerar ibland ett enkelt ERP-system bättre, omgärdat av ett smidigt BPM-system där man ändrar de processer som särskiljer företaget utan att bygga om kärnan. I båda fallen måste finansiella data, lager- och personaldata samt integrationer med KSeF och banker gå att ta ut i sin helhet, tillsammans med historiken.

CRM. Innan vi börjar jämföra anbud är det värt att fastställa vad vi menar med CRM: att ordna upp kundserviceprocesser, flerkanalig försäljning eller en plattform för att dra in kontrakt. Det är tre olika projekt, med olika användare, olika integrationer och olika framgångsmått. Oavsett vilken variant det gäller bör export av kunddatabasen med kontakthistorik och samtycken samt API till försäljnings- och kundtjänstsystem vara ett villkor i anbudsförfrågan – inte ett tillval.

Steg 4. Jämför den totala kostnaden, inte licenspriset

Anbuden är bäst att ställa samman utifrån den totala kostnaden över flera år: inköp och implementering, underhåll och licenser, vidareutveckling samt kostnaden för att avsluta avtalet. Den billigaste licensen visar sig ofta vara den dyraste under det tredje året, när varje processändring innebär ett betalt uppdrag hos en enda partner. Jämförelsen görs bäst utifrån era egna scenarier: låt varje leverantör visa samma svåra fall från ert företag. Mer om utvärdering av anbud: utvärdering av anbud och samtal med leverantörer.

Steg 5. Godkännande och förvaltningsavtal

Systemet bör godkännas enligt i förväg överenskomna testscenarier och kriterier – inte enligt leverantörens utfästelser. Förvaltningsavtalet bör ange inom vilken tid fel åtgärdas, vem som genomför ändringar och till vilket pris, samt bekräfta bestämmelserna om dataexport och om att avsluta avtalet.

Exempel från praktiken

I en koncerns grupp av dotterbolag använde företaget ett centralt ERP-system, samtidigt som man behövde automatisera finansiella processer ur procure-to-pay-gruppen, i enlighet med koncernens riktlinjer för inköp (corporate purchasing guidelines). Frestelsen var stark att ta till koncernens gruppverktyg för samarbete, men de visade sig vara ganska dyra och uppfyllde varken kraven på oberoende eller möjligheten till en enkel exit om problem skulle uppstå.

Vid möten med intressenterna tog vi fram en detaljerad kravbeskrivning som gick längre än de standardfunktioner som färdiga lösningar erbjuder. Vi utarbetade flera alternativa sätt att integrera med verksamhetssystemen och mekanismer som begränsade risken för bindning till en enda leverantör. Resultatet blev en sammanhållen, standardbaserad applikationsstrategi och en miljö där nya flöden skapas smidigt, genom prototyper vid korta möten med processägare, även icke-tekniska sådana. Den här miljön omger ERP-systemet: den ger stor flexibilitet där företaget särskiljer sig, utan kostnaderna för stora implementeringsprojekt.