juli 10, 2015
Standardsystem, ett bra sätt att sänka sina kostnader för systemförvaltning? Absolut så länge man inte anpassar och bygger om standardsystemet. Men går det att vara konkurrenskraftig och unik om man anpassar verksamheten efter standardsystemet? Troligtvis inte.
"Systemstöd är en kritisk framgångsfaktor för vår verksamhet, vi har många affärs- och verksamhetsunika processer. Vi är verksamma på en marknad med hård konkurrens vilket kräver att vi hela tiden arbetar med att bli effektivare. Under många år har vi byggt egenutvecklade systemlösningar för våra affärs- och verksamhetsunika processer, system som nu börjar bli till åren och väldigt ”dyra” att underhålla, och det finns nu ett stort behov av att uppdatera dessa system. Vi har nu initierat ett projekt med målet att ersätta dessa med standardsystem".
Detta är ett citat från ett samtal som jag hade för en tid sedan. Det är tyvärr inte en helt ovanlig inställning/uppfattning att det skulle bli bättre och billigare med standardsystem. Men vilken systemleverantör av standardsystem tror ni utvecklar system som stödjer just era verksamhetsunika processer? Eller för att tala affärsspråk, vilken verksamhet tror ni utvecklar en produkt med en så begränsad målgrupp? Dock är detta fortfarande inte en helt ovanlig situation även om allt fler börjar förstå möjligheterna med att utveckla egna system. Självklart finns det massor av bra standardsystem som stödjer olika processer, gemensamt för dessa är dock att processerna ser ungefär likadana ut i de flesta verksamheter.
Alla som har erfarenhet av, och kunskap om, systemutveckling vet att det rör sig om ett ständigt lärande
För att ta ett exempel som det skrivits om en hel del, för vissa kanske gammalt och uttjatat men som lärdom fortfarande väldigt aktuellt. Polisens PUST Java* vs PUST Siebel**, viktigt att poängtera för denna blogg är att varken jag själv eller vi på Valtech var med i projektet, däremot skrevs det en hel del om projektet för drygt ett år sedan, både från personer med insyn, användare(Poliser) och personer som fått i uppdrag att utreda. Hur kommer det sig att man gjorde allt rätt för att sedan göra allt fel?
PUST Java började med frågeställningen ”varför ser vi inga poliser ute på gatan?”. Förklaringen var bland annat att Poliserna satt på stationen med trassliga IT-system. PUST Java började med att man satt ihop ett team som i nära samarbete med användarna (Poliserna) fick i uppdrag att kartlägga och förstå deras dagliga arbete. Innan man byggde in något i systemet så började man med att göra prototyper som testades i fält för att säkerställa att de fungerade som man tänkt. PUST Java är ett lysande exempel på ett system-/verksamhetsprojekt där man arbetade enligt principerna för Agil/Lean och Design Thinking. Systemet var en succé, hanteringen av vissa mängdbrott minskade med upp till 85%.
Polisens PUST Java* är namnet på det mobila utredningsstöd som togs fram för att effektivisera och korta ner handläggningstiderna för så kallade mängdbrott, eller vardagsbrott. PUST Java var ett skräddarsytt system som utvecklats i nära samarbete med användarna (Poliserna). PUST Siebel** är namnet på det system som sedan skulle ersätta PUST Java i den standardsystemstrategi som klubbats i syfte att sänka systemförvltningskostnaderna. Siebel är ett standardsystem med fokus på CRM (Customer Relationsship Management).
De flesta hade förhoppningsvis fortsatt att vidareutveckla PUST Java men efter att systemet bara varit i drift i några månader klubbades ett nytt initiativ igenom. Man skulle genomföra en ”standardsystemstrategi” med målsättning att sänka kostnaderna för systemunderhåll. Detta resulterade i att PUST Java nu skulle bli PUST Siebel, målsättningen blev nu att ”flytta över samma funktioner” till Siebel i syfte att sänka kostnaderna. Resultatet blev förödande och det är kanske inte så konstigt, Siebel är tänkt att användas som ett CRM system(Customer Relationship Management). Det hade varit intressant att få information om hur man identifierade att Polisens arbete stämde överens med Siebels syn på CRM, men tydligen har man sålt Siebel till polismyndigheter i andra länder exempelvis Finland, men de verkar använda Siebel till helt andra saker ex. sitt vapenregister. Jag har som sagt inte själv någon insyn i projektet mer än det skrivits, men det är ett bra exempel på hur illa det kan gå när man försöker lösa det unika med ”standard”.
Polisens PUST Java vs PUST Siebel är ett tydligt exempel på skillnaden mellan hur olika målbild och genomförande påverkar resultatet. Exemplet visar tydligt resultatet av att försöka lösa det unika med standard samt vad som händer när huvudmålsättningen är att minska systemförvaltningskostnaderna.
För att möta kraven på unika processer så är standardsystemen anpassningsbara, alltså man kan bygga om/justera ”lite”. Som köpare tecknar man alltså ett avtal med en produktleverantör eller troligare med en systemintegratör eftersom det kommer krävas arbete med att åstadkomma alla anpassningar. Ett avtal som reglerar licenskostnader och årliga kostnader för uppdateringsavtal på ett standardsystem som man troligtvis kommer bygga om eller justera ”lite”. Det många missar dock är den verkliga kostnaden/TCO:n (Total Cost of Ownership). Ett ombyggt standardsystem kommer exempelvis inte kunna ta del av uppgraderingar, i alla fall inte utan att det blir ett ganska omfattande arbete. Och varje gång man gör nya ombyggen och justeringar så blir systemet allt svårare att underhålla och förnya. Man får alltså en ökad systemförvaltningskostnad när målet var precis tvärt om.
Ett annat intressant exempel är Försvaret och FMV, samtidigt som Försvaret investerat enorma summor och tid i sitt SAP projekt så har FMV en helt annan strategi. FMV har valt att använda mindre komponenter för att bygga ett system som stödjer verksamheten och inte tvärt om. Det är lätt och billigt att göra förändringar och uppgraderingar i systemet, om samma kommer gälla Försvarets SAP låter jag vara osagt. FMV har byggt ett system för deras verksamhet som också är billigt att förvalta/vidareutveckla (snabbt kunna agera på förändringar).
Förändring är en del av arbetet
Om ombyggnad eller justeringar av standardsystem är ett av skälen till många haverier eller projekt där kostnaderna dragit iväg, så är arbetssätt och metodik ett annat viktigt skäl. Det finns fortfarande en övertro på förstudier och detaljerade kravspecifikationer, man vill säkerställa vad man köper, kravspecifikationen blir innehållsförteckningen som skall bockas av. Alla som har erfarenhet av, och kunskap om, systemutveckling vet att det rör sig om ett ständigt lärande, och ny kunskap ger nya förutsättningar som i sig skapar nya möjligheter. Men om fokus är att bocka av ”innehållsförteckningen” så går dessa möjligheter förlorade. Även om allt fler börjar implementera agila metoder ex. Scrum så är dessa fortfarande bara metoder. Att arbeta Agilt eller Lean på riktigt kräver mer än att bara implementera en metod. Det handlar om att implementera ett nytt synsätt, en ny kultur, i många fall innebär det ändringar/justeringar i verksamhetens ”DNA”. Men det räcker inte, tekniken måste också vara agil/lean. Det handlar om att:
-
Agera på validerat lärande istället för på antaganden och kvalificerade gissningar
-
Förändring är en del av arbetet
-
Releasa smått och ofta istället för stort och sällan
-
Budgetera för team istället för en innehållsförteckning
-
Ha en målsättning och vision med fokus på att skapa mätbart värde
-
Sätta upp en teknisk arkitektur som möjliggör snabb förändring
-
Vi arbetar i ett team inte i olika silos eller grupperingar
Det finns en rad exempel där system och teknik verkligen har förändrat förutsättningarna, och i vissa fall “revolutionerat/reformerat" hela branscher. Men vad är det som ligger bakom deras framgångar? Jag skulle säga att det finns två huvudsakliga komponenter;
-
Synsätt och kultur kring arbetssätt; de arbetar insiktsdrivet och gör releaser löpande, ett arbetssätt där man snabbt drar nytta av ny kunskap och nya insikter, det är inte ett projekt, det är en ständig utveckling.
-
De har byggt ett ”skräddarsytt” system med hjälp av olika komponenter för att skapa en flexibel och lättrörlig systemarkitektur, en micro-services arkitektur som tillåter löpande förändringar/förbättringar. Systemet är en del av verksamheten.
Rör det affärsunika processer så måste man börja med att inse att systemstödet för de affärsunika processerna är en del av kärnverksamheten. Så istället för att försöka bygga om ett standardsystem, bygg istället ett system bestående av ett antal mindre, väldefinierade komponenter som interagerar med varandra över ett väldefinierat protokoll. På så sätt kan man byta ut enstaka delar över tid, och minska risk och kostnad. Du får helt enkelt en lösning som är förberedd för att hantera förändringar eller rättare sagt ständiga förbättringar.
Så precis som utvecklingen av kärnverksamheten inte har någon slutdestination så har inte utveckling av systemstödet för de affärs- och verksamhetsunika processerna någon slutdestination.
