Tre fallgropar att undvika när det är dags att byta affärssystem
Det finns mycket att tänka på när man ska byta affärssystem. Detta är en artikelserie i fem delar som syftar till att kortfattat och övergripande beskriva några viktiga steg att ta när ett bolag ska se över sin systemkarta och byta ut själva hjärtat, affärssystemet.
Det här är den fjärde artikeln i ordningen som kommer beröra införandeprojektet och tre vanliga fallgropar att se upp för. Nästa artikel kommer handla om våra tankar kring förvaltning av det nya systemet. Vill du läsa de första tre artiklarna kring förarbetet före du väljer system och valet av system och valet av partner hittar du dem här!
Det är svårt att tipsa kring projekt som en allmän företeelse eftersom projekten ser annorlunda ut varje gång. Det beror på vilket system, vilken partner, vilken typ av organisation, tidsplan och mycket mer. Vi har identifierat några aspekter som är vanligt förekommande och kan gälla de flesta av projekt.
Interna resurser
En av de vanligaste orsakerna till att ett systeminförande inte går som man förväntar sig är att det inte finns tillräckligt med interna resurser. Oftast startas projektet upp och förarbetet görs noga. Därefter är det inte ovanligt att man skjuter på vissa uppgifter som rent praktiskt går att skjuta på. Låt oss ta exemplet tester av flöden. Det är orimligt att från projektledningen förutsätta att personalen på bolaget först ska utföra åtta timmar normalt arbete och sedan ha tid för några timmars tester i det nya systemet.
Se därför till att budgetera med en lägre ”normal” arbetstid från projektdeltagarna under projektets gång och korrigera projektets tidsplan till att spegla vad som är praktiskt möjligt.
Datamigrering
Utmaningarna som finns med migrering av affärsdata mellan system är samma nu som de varit tidigare. Tekniken har förvisso gjort det enklare för oss, men principen ”skit in, skit ut” gäller faktiskt fortfarande. Vi har sett att bolags önskemål om att ta med sig många års historik på transaktionsnivå, eller åtminstone en aggregerad nivå, förstör hela strukturen i det nya systemet. Bara för att man behöver behålla viss data betyder det inte att den måste följa med in i det nya systemet!
Vårt råd är därför att bara migrera vissa tvättade grundregister, och hantera all historik separat. Det gör man med fördel i ett externt ”datalager” som man sedan bygger rapporter mot. Dit flyttar man inte bara historik utan även kontinuerligt data från det nya affärssystemet, tidrapporteringssystem, lagersystem, CRM-system och andra system som man använder sig av.
Ändra systemet eller ändra er verksamhet?
Sista företeelsen att se upp med är också den viktigaste. Detta är anpassningar och hur dessa hanteras i systemet. Det händer sällan att ett bolag i en viss storlek kan använda systemet helt i sitt standardutförande. Dock medför varje utförd anpassning på standardprodukten stora konsekvenser.
Ta uppgraderingar som exempel. Alla system hamnar förr eller senare i molnet, eller så kommer systemet inte att finnas kvar på marknaden. I en riktig SaaS-lösning finns kunderna i samma databas, delar alla funktioner och framförallt sker uppdateringar centralt utan att det innebär ett projekt för varje kund. Det är som att jämföra med att Facebook uppdateras – det sker för (nästan) alla användare samtidigt.
Anpassar man systemet måste man betala för sitt eget uppgraderingsprojekt och hantera sina egna funktioner. Detta blir dyrt och omständligt i framtiden. Se därför till att i projektet arbeta aktivt med att använda standardsystemet i så hög utsträckning som möjligt för att undvika kostnader och problem längre fram.