Funderar du på att byta system? Fundera då en gång till
12 dec 25
Varje vecka blir vi på HerbertNathan & Co kontaktade av nya organisationer som bestämt sig för att genomföra en systemupphandling och byta sitt verksamhetssystem eller ERP-system. Ofta söker man ett leverantörsoberoende konsultstöd för genomförandet. Det är givetvis glädjande att inflödet av nya förfrågningar och uppdrag är relativt konstant och att våra eftertraktade konsulter får möjlighet att bidra med sin kompetens och erfarenhet. Det som är mindre glädjande och även aningen förvånande är antalet organisationer som saknar en genomarbetad strategi för sitt systembyte.
Varför räcker det inte att systemet känns gammalt?
Det är inte ovanligt att beslutet om att genomföra en upphandling baseras på att det befintliga systemet upplevs som ”gammalt och omodernt” eller där kunden har tröttnat på sin leverantör som kunden uppfattar som oengagerad. Och givetvis kan ett gammalt, omodernt system och en oengagerad leverantör vara en drivkraft till att se över sitt befintliga applikationslandskap och överväga ett byte. Men beslutsunderlaget bör vara mer genomarbetat för att investeringen ska leda till ett bestående värde. Risken är annars väldigt stor att det nya systemet enbart blir en kopia på det tidigare systemet men med ett trevligare gränssnitt.
Frågor att besvara innan upphandling
Det är många frågor som bör besvaras innan man fattar beslut om att genomföra en upphandling. Frågor som har stor påverkan både på upphandlingens genomförande och inte minst den efterföljande implementeringen. Några få exempel:
● Är det självklart att det nya systemet ska omfatta samma processer som det tidigare systemet?
● Finns det alternativ där det tidigare systemet kan eller bör ersättas av en kombinerad systemlösning bestående av flera applikationer med syfte att varje delprocess får ett maximerat systemstöd?
● Har kunden affärsprocesser och/eller delprocesser som är så unika att ett s.k. standardsystem skulle begränsa i stället för att utveckla kundens förmågor?
● Kan det befintliga systemet behållas men där vissa delprocesser kan utvecklas med integrerade och flexibla 3:e parts lösningar?
● Är det givet att hela applikationsmiljön ska vara molnbaserad eller finns det motiv till att hantera någon del av applikationsmiljön internt? Eller tvärtom?
● Är det självklart att hela systembytet ska ske vid ett och samma tillfälle? Eller bör implementeringen ske stegvis med syfte att dels minska risken för störningar och dels ge kunden möjlighet att öka sitt lärande av systemet i strukturerade faser? Och kan en fasindelad implementering påverka valet av system och hur det kan brytas upp i beståndsdelar?
● Vilka optioner bör inkluderas i upphandlingen?
● Alternativt vilka processer och/eller funktionella förmågor bör upphandlas i ett senare skede då implementeringen är genomförd och det slutliga resultatet bättre går att överblicka och kan ge struktur och förutsättningar till efterföljande upphandlingar och kompletteringar?
● Hur viktigt är det att leverantören och systemet erbjuder både ett urval av alternativa partner för implementering och tilläggsapplikationer? Frågor som definitivt begränsar och påverkar urvalet av systemet.
Syftet med dessa och många andra frågor är att säkerställa att det framtida landskapet med applikationer kan maximera kundens förmåga till utveckling och bidra till att verksamheten kan nå sina mål. Och då är inte alltid svaret att ”vi ska byta ut vårt gamla system mot ett nytt”.
Det lönar sig alltid att börja med att ta ett steg tillbaka och betrakta helheten innan man börjar gå framåt när det gäller att förändra och utveckla sitt landskap med applikationer. Vi upplever ofta att kunden har en applikationsmiljö som bygger på hur verksamheten såg ut för väldigt många år sedan och där förändringarna över tid primärt handlat om att lappa och laga utan att någonsin ha tagit steget till att ”börja om” utifrån de nya förutsättningar som råder över tid. Och i dessa situationer kan det finnas skäl till att våga bryta upp den ”gamla systemmiljön” och komponera en modern arkitektur som mer speglar verksamhetens aktuella affärsmodell och processer.
En välgrundad och genomarbetad strategi för hur verksamhetens processer och applikationer bör utvecklas över tid förbättrar väsentligen förutsättningarna till att kunden upphandlar på rätt sätt och implementerar rätt system för rätt process och vid rätt tillfälle.