Whitepaper 4.9.2013 1 / 7 Agila arbetsmetoder för framgångsrik implementering av system: Case Vianor Författare: Tuomo Pesonen Direktör, Projektleverans tuomo.pesonen@relexsolutions.com Ett chockerande antal företag har bromsats upp, kommit på fel kurs, eller till och med gått under på grund av misslyckade IT-projekt. I många fall har kostnaderna i slutändan blivit mycket större än vad man inledningsvis planerat. Ibland har man helt enkelt inte lyckats ro projektet i land och tvingats avbryta det, i värsta fall efter att ha lagt ned år av resurser och pengar på projektet. Vi ska inte peka finger. En snabb sökning på nätet ger så många exempel på misslyckanden att det kan ses som IT-branschens motsvarighet till en masskollision. Genom att vara medveten om riskerna kan man undvika en del av de många fallgroparna i stora systemprojekt. För att radikalt minska riskerna krävs ändå helt nya sätt att implementera och anpassa system. Under de senaste åtta åren har vi på RELEX samlat på oss en hel del erfarenheter av framgångsrika IT-projekt. Vi tror oss inte ha alla svaren, men vårt tillvägagångssätt ser ut att fungera både vi och våra kunder har lyckats med att antingen undvika eller åtminstone lösa största delen av de problem som vanligtvis brukar uppstå i större systemprojekt. Vilken är då vår hemlighet? Det är faktiskt inte mycket till en hemlighet, utan mer en allmän princip: lättrörlighet eller på IT-språk, agilitet. Vi ser många fördelar i agil processutveckling och i den här artikeln förklarar vi varför. Hör det inte till att IT-projekt är smärtfyllda? Kort svar: nej. Däremot är många IT-projekt redan från starten förutbestämda att råka ut för problem. Vattenfallsmetoden är en traditionell metodik inom programvaruutveckling. Metoden bygger på att varje utvecklingsprojekt startar med en omfattande specifikationsfas där slutprodukten definieras i minsta detalj. Därefter framskrider arbetet sekventiellt, på samma sätt som vattnet forsar utför ett vattenfall. Tankesättet kommer ursprungligen från tillverknings- och byggindustrin, där det ofta är kostsamt eller till och med omöjligt att införa ändringar sent i processen.
2 / 7 Tillämpat på programvaruutveckling leder vattenfallsmodellen till problem, vilket gjort att de flesta valt att frångå modellen. Istället tillämpar man agila metoder för programvaruutveckling. Det gör även vi på RELEX, men vi har också hittat andra tillämpningsområden för lättrörlighet. Vi på RELEX använder oss av agila metoder också i den processutveckling som utgör det kärnan i alla våra implementeringsprojekt. Vi är faktiskt ganska måna om att betona att införandet av våra planerings- och varustyrningslösningar inte ska ses som ett IT-projekt utan som affärsutveckling. Målet är att optimera kundens processer och sedan passa in systemet inte tvärtom. Även om vattenfallsmetoden nästan dött ut inom programvaruutveckling tillämpas den fortfarande ofta vid implementering av system. Kunden börjar med att ta fram en kravställning, som leverantören sedan försöker leverera. En viktig mätare på framgång är hur väl resultatet i slutändan motsvarar den ursprungliga kravställningen. Vi på RELEX vill inte jobba enligt den här traditionella modellen. Vi tror helt enkelt inte att den leder till bra resultat varken för oss eller för våra kunder. Att ta fram en detaljerad kravställning innan man satt igång med att utveckla arbetsprocesserna är en orimlig och ofta omöjlig uppgift. För det första är det mycket svårt att i ett enda steg identifiera de optimala processerna då helheten består av en mångfald arbetsrutiner som dessutom är avhängiga av varandra. För det andra har kunden i startfasen ofta mycket lite praktisk erfarenhet av hur det är att jobba i systemet i praktiken och de nya möjligheter som systemet medför, vilket gör det väldigt knepigt att förutse hur systemet bäst kan stödja de planerade processerna. För det tredje är processexperterna sällan experter på IT och vice versa, vilket gör att de olika grupperna ofta utarbetar var sin del av kravställningen ur var sitt perspektiv. Att följa en kravställning som skapats under de här förhållandena leder garanterat till problem och man kan räkna med att problemen mångfaldigas ju större projekt det handlar om. Vilket är då alternativet? Det allra viktigaste är att utveckla och förbättra specifikationen parallellt med implementeringen och användningen av systemet. Så fort en första version av systemet tagits i bruk, ökar kundens kunskap och erfarenhet av systemet radikalt. Förutsättningarna att ta rätt beslut angående hur processerna och systemet faktiskt ska se ut blir snabbt bättre. Även då man tillämpar agila metoder inom systemimplementering behövs en inledande specifikationsfas. Målet för specifikationsfasen är att bygga upp en grundläggande, gemensam förståelse för vilka kundens viktigaste mål och behov är inom de processer där systemet främst kommer att användas. Enligt vår erfarenhet är det en bra idé att först lägga fokus på mellan tre och fem kärnprocesser, såsom sortimentsstyrning, registervård, avrop/varupåfyllning och prognostisering. Ofta räcker det med ett arbetsmöte per process för att få en översikt av situationen idag och mot vilket håll man vill utveckla processen. Förutom att diskutera arbetsrutiner är det även viktigt att identifiera framtida roller och ansvar, för att säkerställa att systemet genast från början sitter rätt i organisationen. Den inledande specifikationen utgör i praktiken en hypotes eller bästa gissning. Den kommer att ändras och finslipas då användarna börjar utnyttja systemet i sitt dagliga arbete.
3 / 7 När den inledande specifikationen är klar är det dags att kavla upp ärmarna och implementera systemet. I våra projekt brukar det ta mellan fyra och åtta veckor från att den inledande specifikationen blivit klar tills att kunden kan börja testköra systemet, vanligtvis för en varugrupp eller ett mindre urval butiker. Vi kallar detta för pilotfasen. Användarna kan nu se hur systemet fungerar i praktiken i den egna verksamheten, vilket gör det mycket enklare att komma med konkreta förbättringsförslag. Utifrån responsen finjusterar vi systemet tillsammans med kunden så att processerna fungerar så bra som möjligt. Detta görs stegvis i pilotfasen, som oftast tar mellan två och tre månader. Specifikation Justering av användningsprocess Design Implementering Validering Specifikation Användarnas erfarenheter från pilot Underhåll Fortlöpande återkoppling Bild 1: Från vattenfallsmodellen till agil utveckling av affärsprocesser. Då vi pratar om implementeringsprojekt handlar agilitet alltså främst om agil utveckling av affärsprocesser. I praktiken innebär detta kontinuerliga, små förändringar i systemet i takt med att arbetsprocesserna utvecklas. Det kan t.ex. handla om justering av beräkningslogiken eller vyerna i användargränssnittet. I RELEX projekt genomförs lejonparten av förändringarna initialt av våra konsulter och så småningom av kundens egna systemanvändare. I och med att en stor del av förändringarna kan göras genom att konfigurera systemet, slipper vi i regel ta den mera tidskrävande omvägen via programvaruutveckling. Samtidigt vet vi att de verkliga processexperterna är de personerna som använder systemet. Ju mera användarna själva kan göra i systemet, desto snabbare utvecklas användningsprocessen. Trots att samma principer tillämpas i bägge fallen är det viktigt att komma ihåg att agilitet i implementering av system inte är innebär precis sak som agil programvaruutveckling. I agil programvaruutveckling utvecklar man ett helt nytt system eller åtminstone ny funktionalitet. Agil systemimplementering handlar om att utveckla affärsprocesser och skräddarsy ett existerande system. En central förutsättning för att man överhuvudtaget ska kunna utnyttja agila metoder inom systemimplementering är att det system som ska implementeras är tillräckligt flexibelt, det vill säga enkelt att konfigurera och ändra.
4 / 7 Varför tillämpar inte alla agila metoder? Agil utveckling av affärsprocesser är en enkel idé: Inför en resa tittar du på kartan för att välja den bästa rutten, men under resans gång kanske du får veta om trafikstockningar, översvämningar eller dåligt väglag på någon del av sträckan, varefter du ändrar din ruttplan. Kartan ger startpunkten och riktningen, men målet är inte att följa den ursprungliga resplanen till punkt och pricka utan att nå slutdestinationen på ett bekvämt, snabbt, billigt och säkert sätt. Allt det här låter ju väldigt bra, eller hur? Frågan är då varför inte fler IT-leverantörer arbetar på det här sättet. Svaret är: för att det inte är lätt. Agil systemimplementering ställer höga krav på programvaran, IT-leverantörens medarbetare samt leverantörens affärsmodell. Det första och mest grundläggande kravet är att programvaran som implementeras måste vara flexibel. Agil processutveckling kräver att du hela tiden kan ändra systemet och få återkoppling för att kunna analysera om förändringen ger rätt effekt. Om systemet inte är utformat för att stöda snabba och enkla ändringar blir det snabbt uppenbart att agil systemimplementering inte är genomförbart för att förändringarna tar för lång tid eller för att de blir fruktansvärt dyra. För att effektivt kunna analysera effekterna av de förändringar som görs krävs i praktiken att systemet erbjuder minnesbaserad analys (in-memory analytics). Minnesbaserad analys innebär att man kan bearbeta enorma datamängder direkt i datorernas internminne, så att analyser kan genomföras på några sekunder istället för timmar eller dagar direkt återkoppling för varje ändring med andra ord. På RELEX är flexibilitet ett mål som vi kontinuerligt jobbar hårt för att uppnå, vilket bland annat syns som en stor satsning på forskning och utveckling. Resultatet är att avancerade beräkningar och rapporter i RELEX system kan genomföras i flykten, med extremt hög prestanda, vilket gör det möjligt att utnyttja vilka grund-, mäteller transaktionsdata som helst som sök- och filtreringskriterier. Därmed är det också snabbt och enkelt att implementera förändringar t.ex. i sättet att jobba med orderförslag, för precis de artiklar man vill, i takt med att ett ökande erfarenhet eller förändringar i verksamheten gör förändringar aktuella. Det andra kravet är att leverantören ska ha sakkunskap att ställa rätt frågor i den inledande specifikationsfasen. Vilka som är de rätta frågorna varierar från fall till fall. Vem bestämmer vilka produkter som ska ingå i sortimentet och vilka artiklar som ska vara lagerföras? Hur ska inköp informeras om förändringar i planerade kampanjer och vad ska inköp göra med informationen? Vilka är de viktigaste måltalen i det här projektet? Alla frågor kan inte få ett utförligt svar genast i början av utvecklingsprojektet, men det är viktigt att förstå målprocessen. I och med att målprocessen oftast inte är helt kristallklar i starten krävs det erfarenhet för att hitta rätt. Bra konsulter spelar en viktig roll i att skräddarsy lösningen i enlighet med kundens behov. Det tredje kravet är att leverantören och kunden måste ha samma mål. Om leverantören tar betalt för allt förändringsarbete genast från början och/eller det inte finns något tak på konsultarvodena uppstår ett incentiv för leverantören att dra ut på projektet. Detta ligger naturligtvis inte i kundens intresse. Den bästa avtalsmodellen utgår ifrån att målet är att implementera ett bra och fungerande system så snabbt och effektivt som möjligt. Om systemet inte kräver kontinuerlig support från leverantör eller tredje part tjänar kunden på detta och det ska också vara lönsamt för leverantören i längden.
5 / 7 Case: Vianor Ett bra exempel på RELEX arbetssätt är det implementeringsprojekt som vi genomförde tillsammans med däckkedjan Vianor. Det stod tidigt klart att det fanns två huvudsakliga utmaningar att tackla i projektet: 1) Helt nya processer för sortiments- och varustyrning behövde byggas upp, 2) Aktiv förändringsledning, speciellt ute i driften, skulle krävas för att förankra de nya arbetsrutinerna. Låt oss titta närmare på sortimentsstyrningen. När projektet inleddes fanns det ingen tydlig process för sortimentsstyrning i och med att ansvaret för att fylla på butikslagren och lägga beställningar legat hos verkstäderna. I samarbete med RELEX arbetade Vianors utvecklingsteam fram en modell där säsongssortimentet i varje verkstad definierades utifrån en frekvensbaserad XYZ-klassificering. Istället för att lägga ned alltför mycket tid på att finslipa modellen på pappret, valde gruppen att i ett tidigt skede testa modellen tillsammans med pilotverkstäderna och sedan justera modellen utifrån återkopplingen från driften. När piloten startade var verkstäderna i största allmänhet riktigt nöjda, men man upptäckte snabbt ett behov att kunna beställa in varor som inte ingick i verkstadens lagerförda sortiment för att kunna svara på kundförfrågningar. Frågan diskuterades med RELEX och man valde att lägga in en ny beställningsmodell beställning mot kundorder för dessa situationer. Lösningen implementerades inom några dagar och testades snabbt i pilotverkstäderna. Efter positiv respons blev lösningen en bestående del av den nya verksamhetsmodellen. Under pilotens senare del utnyttjade allt fler verkstäder det nya systemet för varupåfyllning. Då började det synas att den implementerade modellen fungerade bäst för större verkstäder, som blev tilldelade ett brett sortiment. De mindre verkstäderna upptäckte att de egentligen skulle behöva ett snäppet bredare sortiment för att kunna betjäna sina kunder på bästa sätt. Återigen gjordes några snabba ändringar i systemets beräkningsmodeller. Ändringarna testades följande dag och togs i bruk i pilotverkstäderna. I och med att mottagandet ute i driften var positivt, kvarstod förändringarna. De två utmaningar som Vianor stod inför är mycket vanliga inom utveckling av affärsprocesser. Det är svårt att överblicka alla effekter som förändringar i arbetsrutinerna kommer att ha innan dessa har implementerats. Därför är det viktigt att det finns tillräckligt med inbyggd flexibilitet för att kunna ändra arbetsmodellen vartefter rutinerna testats i praktiken.
6 / 7 Specifikation Tidigt i pilot Senare i pilot Sortimentsstyrning Systematisk process för sortimentsstyrning tas fram Finjustering: Ny beställningsmodell för en del av sortimentet Finjustering: Mera avancerad beräkningsmodell för mindre verkstäder Varupåfyllning Utgångspunkt i RELEX standardmall Finjusteringar: t.ex. saldomål alltid multipel av fyra för personbilsdäck Införande av ytterligare funktionalitet: t.ex. förhandsbeställningar inför säsong Förändringsledning Val av pilotverkstäder av olika storlek, med olika nyckeltal och i olika regioner. Fortlöpande dialog med verkstäderna: Validering av specifikationen. Utrullning till övriga verkstäder: Validering av de förändringar som gjorts i pilotens tidigare faser. Bild 2: Vianors implementeringsprojekt framskred iterativt. Genom att implementera RELEX lösning har Vianor kunnat minska lagervärdet inför säsong (topplagret) med 30 procent utan att tumma på tillgängligheten. Vianors logistikchef Markus Huttunen är övertygad om förtjänsterna i RELEX modell för agil processutveckling: Implementeringsprojektet flöt på otroligt smidigt och de problem vi stötte på löstes i regel inom 24 timmar till och med helt ny funktionalitetet levererades inom några dagar. Den största utmaningen i projektet låg i att definiera hur vi skulle jobba. RELEX projektgrupp var, tack vare sin gedigna kunskap om leveranskedjan, till stor hjälp för oss i att effektivt nå våra mål. Nästa steg? Om du överväger att köpa ett nytt IT-system finns det ett par viktiga punkter att tänka på: 1) Det är mycket troligt att arbetsprocesserna i ditt företag kommer att förändras över tid, och 2) Det är nästan säkert att din och dina kollegers uppfattning om vilka behov för systemstöd ni egentligen har kommer att förändras i takt med att ni utnyttjar systemet i ert dagliga arbete. Med detta i åtanke är det kanske bättre att investera i ett system som ni själv kan konfigurera för att möta era behov, istället för att behöva starta ett nytt IT-projekt varje gång någonting behöver ändras? Vi på RELEX tar inte ut någon licensavgift innan kunden haft möjlighet att, genom en pilot, försäkra sig om att systemet verkligen stöder målprocesserna och att det finns en reell nytta i att fortsätta använda systemet. Eftersom vår lönedag infaller först när dessa mål har uppnåtts har vi ett starkt egenintresse att göra vårt yttersta för att leverera den bästa möjliga lösningen. Våra kunders problem är våra problem. Om du vill veta mer om hur den här typen av system kan stödja varustyrningsoch planeringsprocessena i ditt företag, ta då kontakt med Johanna Småros ( eller +358 40 543 1142). En timme räcker för att gå igenom nuläget på ditt företag och fatta beslut om de första stegen.
7 / 7 Om Vianor Vianor ägs av Nokian Tyres och är en internationell däck- och bilservicekedja som består av helägda och entreprenörsdrivna verkstäder. Vianor är den största däckkedjan i Norden. I slutet av 2012 omfattade kedjan 1 037 verkstäder i 26 olika länder. Namnet Vianor kommer från de latinska orden Via Nor, som betyder den nordiska vägen. www.vianor.com