Kan affärssystemprojekt vara agila?
24 aug 16
En student på Stockholms Universitets affärssystemsutbildning frågade mig nyligen ”Varför är inte affärssystemsprojekt agila?” Jag svarade något i stil med att det är viktigt att alla delar hänger ihop i ett affärssystem och därför behöver de konfigureras på ett strukturerat sätt. Men när jag började fundera på frågan och vad som gör att affärssystemsprojekt lyckas så är svaret inte så självklart.
Att arbeta agilt blev ett populärt begrepp inom systemutveckling för ett antal år sedan och efter det har fler och fler verksamheter tagit till sig begreppet och det mer flexibla och iterativa arbetssättet som det står för. Syftet med ett agilt arbetssätt är dels att fokusera på det som verkligen tillför värde men även att bli bättre på att anpassa sig till förändringar i omvärlden istället för att köra vidare enligt en föråldrad plan. I ett affärssystemsprojekt går det ofta över ett år från det att kravspecifikationen skapas tills det att systemet är konfigurerat och klart att användas. Det är i princip raka motsatsen till ett agilt arbetssätt. Men måste det vara så?
Vi har tidigare i flera inlägg presenterat hur en upphandling i dialog mellan leverantör och kund skapar bättre förutsättningar för att förstå varandra och hitta rätt lösningar, vilket även är ett mer agilt arbetssätt. När implementationsprojekten börjar är dock leverantörernas approacher snarlika. Deras metod startar nästan alltid med en ”förstudie” där leverantören ska kartlägga kundens arbetssätt och behov för att där efter designa en lösning som därefter konfigureras i systemet. Vanligen måste kunden godkänna ett dokument efter respektive fas som talar om att det som står i dokumentet är vad kunden vill och att alla ändringar kommer att betraktas som tilläggsbeställningar. Det arbetssättet är definitivt inte flexibelt och iterativt. Syftet från leverantören är naturligtvis att få en säkerhet i sin leverans och slippa ändringar som försenar och fördyrar projektet. Utmaningen är att i takt med att kund och leverantör lär sig mer och mer om varandra så kommer de också ofta på bättre och smartare lösningar. Dessutom kan nya behov uppstå i takt med att omvärlden ändrar sig. Det är dock svårt att hantera detta i implementationsprojektet eftersom designdokumenten är spikade sedan länge och inte går att ändra på utan mycket byråkrati och höga kostnader. Risken med arbetssättet är således att den strikta strukturen leder till dåliga lösningar som inte täcker moderna behov trots att systemet är precis ny implementerat.
Går det då att göra affärssystemsprojekt mera flexibla utan att riskera förseningar och fördyringar på grund av att projektets omfattning ändrar sig hela tiden? Ja, det finns några leverantörer som arbetar mer kundnära och iterativt i sina implementationsprojekt och som därmed ofta är bättre på att hantera förändringar i projekten. I dessa projekt jobbar kundens och leverantörens personal tätt tillsammans med konfigurering direkt i systemet baserat på en gap-analys gentemot leverantörens standardiserade processer. Arbetet sker iterativt och kunden kan direkt se hur lösningen kommer fungera i deras verksamhet och därigenom lättare påtala vad som är bra respektive mindre bra.
För att lyckas med denna mer flexibla implementationsmetod krävs att leverantörens verkligen har väl inarbetade och beprövade standardiserade processer (inte bara i sin säljpresentation utan förkonfigurerat i sitt system och inlärd hos konsulterna). Det krävs även att leverantörens konsulter har både djup verksamhetsförståelse och stor kunskap om sitt system. Sist men inte minst krävs att kunden tillsätter personal som också har djup verksamhetsförståelse och systemkunskap men även har mandat att fatta beslut om hur systemet ska konfigureras.
Med dessa komponenter på plats kan även ett affärssystemsprojekt bli agilt utan att för den skulle bli försenat eller gå över budget.