Publicerad
Författare
De flesta organisationer har idag insikt om att man som kund bör hålla nere antalet kundunika anpassningar. Detta har kommit som insikt efter många år med plågsamma uppgraderingar, och där en av orsakerna till problemen varit kundens anpassningar. Det var under 1980-1990-talet ganska vanligt att leverantörerna av affärssystem visade stor villighet till kundanpassningar, och i vissa fall till och med uppmuntrade kunderna till unika anpassningar. Detta som ett sätt att kunna erbjuda en systemlösning som var helt skräddarsydd för kundens unika behov. Efter några år började dock de flesta kunder inse att priset på lång sikt blev väldigt högt då varje uppgradering blev både komplicerad och dyr. Och med tiden kom dessa kundanpassningar att bli ett direkt hinder för kontinuerlig utveckling av verksamheten.
Det man ska komma ihåg när det gäller ”dåtidens” anpassningar var att kunderna ofta kunde ha flera hundra anpassningar och där dessa anpassningar var dåligt dokumenterade och saknade spårbarhet. Följden blev att de konsulter som senare skulle arbeta med uppgraderingen fick arbeta i blindo och utan kunskap om den logik som var inbyggd i anpassningarna. Resultatet blev därmed också stökigt med många tester och brandutryckningar när väl uppgraderingen skulle genomföras. För en del kunder innebar också uppgraderingen att ett antal funktioner faktiskt blev ”nedgraderade” då de tvingades avstå en del finesser som fanns inbyggda i anpassningarna.
Om vi så rör oss till år 2019 och tittar på hur leverantörerna idag agerar kan vi konstatera att flertalet leverantörer försöker förmå kunden att avstå ifrån anpassningar. Man förespråkar att kunden ska använda systemets standardprocesser och i möjligaste mån försöka anpassa sina processer efter systemets flöden. Och lägger vi till sk publika molnsystem är det i många fall inte ens möjligt att göra kundunika anpassningar då källkoden är gemensam för alla kunder.
Innebär då ovanstående att det bara är av godo att avstå från kundunika anpassningar? För att besvara denna fråga bör man definiera vad som ligger i begreppet ”anpassning”. Förr innebar anpassning att man gjorde förändringar och tillägg i systemets källkod vilket långsiktigt blev dåligt både för kunden och leverantören. Under de senaste 15 åren har vi dock sett att flertalet affärssystem fått väsentligt förbättrade möjligheter till ”konfiguration” och där systemets processer och funktioner kan påverkas för att bättre stödja kundens unika behov. I vissa fall enbart med standardmässig parametersättning och andra fall via en kombination av parametersättning och tilläggskod via script (utanför källkoden) eller standardiserade API:er. Även detta bör betraktas som en form av anpassning, men där kunden inte blir lika inbunden som när källkoden förändras.
Kundunika anpassningar via förändring av källkoden bör alltid undvikas. Att däremot göra anpassningar i form av script utanför källkoden kan motiveras då kunden har unika behov. Det är viktigt att förstå att begreppet ”standardsystem” innebär att systemet används av många kunder vilket inte är detsamma som att systemet faktiskt passar för alla kunder. Och det finns faktiskt ganska många organisationer som har blivit framgångsrika baserat på att de arbetar annorlunda jämfört med andra organisationer. Och i dessa fall är det befogat att hitta en systemlösning som bejakar kundens identitet istället för att tvinga kunden att förändra sina processer till att bli lika konkurrenterna.
Kundunika anpassningar via förändring av källkoden bör alltid undvikas. Att däremot göra anpassningar i form av script utanför källkoden kan motiveras då kunden har unika behov.
Grundprincipen bör vara att i möjligaste mån följa systemets standardprocesser men acceptera anpassningar där de affärsmässigt kan motiveras. Men det är också viktigt att tänka långsiktigt och säkerställa att anpassningen/tillägget genomförs och underhålls så att det följer systemets utveckling och inte blir ett framtida hinder.
Bäst för alla parter är givetvis att kunden hittar ett system med så hög grad av flexibilitet att kunden når optimala flöden utan behov av anpassning. Och i valet mellan ett standardsystem med hög funktionalitet men med bristande flexibilitet och ett system med bristande funktionalitet men med hög flexibilitet kan valet lika väl landa på det senare alternativet. Flexibilitet är i nutiden mer värt än ”standard” för att ge kunden möjlighet att över tid kunna förändra och utveckla sin verksamhet.
Viktigt att ha i åtanke är att såväl ”standard” som ”flexibilitet” har sitt pris, men utifrån olika perspektiv och med olika konsekvenser som följd. Det är idag inte ”anpassningarna” i sig själva som är problemet för kunden utan den brist på flexibilitet som tvingar fram anpassningarna.
