iZettle använde Agila kontrakt för att på 6 månader ersätta gamla legacysystem med ett globalt, baserat på ett standardsystem. Parallellt uppgraderades kritiska affärsprocesser på marknadsenheter runt om i världen. Vi träffade Maria Izzo för att lära oss hur det gjorde.
(this article is also available in english here)
”As you create human connections, you also create bonds of responsibility.”
– Maria Izzo
Berätta lite kort om iZettle?
iZettle är en leverantör av handelslösningar, med fokus på små och medelstora företag. Om du någon gång betalat med kort på kafé, i en taxi eller till en hantverkare – är sannolikheten stor att betalningen genomfördes med hjälp av iZettles teknologi. Vi finns idag på ett flertal marknader runt om i världen, från EU till Sydamerika.
Berätta lite om dig – vem är Maria Izzo?
Jag arbetar på iZettle som “Automation lead”. Automation (ett ganska nytt team) har som uppgift skapa förutsättningar för tillväxt och innovativa arbetssätt för andra “iZettlers”. Vi skall helt enkelt skapa verktygen som våra “iZettlers” behöver för att lyckas i sina roller.
Vem är Maria? Jag är en nyfiken person som älskar att lära sig nya saker. Det har drivit mig till att arbeta inom ett flertal olika områden. Några av dem inkluderar; marknadsföring, kommunikation, forskning, ekonomi, till finansiella tjänster risk och IT.
Du har just avslutat ett projekt där ni använde Agila kontrakt. Berätta lite om bakgrunden för projektet?
Efter att iZettle köpt företaget IntelligentPOS – (mer känt som iZettle Pro) – insåg vi att vi satt på två olika CRM system (“customer relationship management”) baserade på SalesForce. Vi satte som vårt mål att förenkla livet för iZettler’s genom att ersätta dessa två legacysystem med en global, förbättrad version.
Våra CRM system används dagligen på 12 olika marknader över ett flertal olika avdelningar (däribland Försäljning, Risk, Support och Marknadsföring). De är med andra ord affärskritiska.
Vilka var utmaningarna?
Några av de mest spännande utmaningarna med att ersätta ett system som i ett snabbväxande företag som iZettle, är att affärsprocesserna ofta vuxit organiskt. När vi började arbetet såg vi snabbt visst – vi hade samma grundsystem, men dessa såg ut och användes på väldigt olika sätt. Några exempel: Automations- och dokumentation graden varierade kraftigt och vi brottades med många fall av redundans.
En utmaning i ett omställningsprojekt i ett snabbväxande bolag är att affärsprocesserna ”evolverar” varje dag. Så när du ersätter ett system, måste det göras snabbt, smidigt och med ett minimum av disruption. Jag brukar likna det med att utföra ett hjärtbyte på en springande patient.
När vi inledde arbetet började vi med att formulera våra effektmål. Om jag sammanfattar dessa så var de:
- Slå ihop våra två CRM system (instanser) till en.
- Harmonisera och automatisera ett flertal affärsprocesser, så att livet blir enklare för iZettler’s på våra olika affärsenheter.
Varför valde ni att använda Agila kontrakt?
Vi visste att det fanns några nyckelområden med stor osäkerhet när vi började projektet:
- Avsaknad av enhetlighet i våra affärsprocesser
- Osäkerhet över vilken funktionalitet våra affärsägare ansåg mest värdefull.
- Vi ville även komma igång snabbt efter den initiala förstudien, så vi kunde bibehålla momentumet i projektet. Ett Agilt kontrakt gav oss flexibiliteten att komma igång snabbt istället för att kasta bort tid och pengar på fördjupad analys, utan att få något levererat.
- Sist men inte minst, den initiala offerten och estimatet vi fick från våra leverantörer bedömde vi som “rimlig”. Utifrån denna frågade vi oss, “givet osäkerhetsfaktorerna, hur kan vi maximera värdeleveransen med utgångspunkt från deras förslag?” Vi fann att ett Agilt kontrakt innebar en rimlig värde/riskbalans för bägge parter, vilket möjliggjorde att vi kunde komma igång på stående fot.
Ett Agilt kontrakt verkade helt enkelt som det bästa lösningen givet vår situation.
Om jag skulle summerar fördelarna vi såg:
- En hög grad av flexibilitet i prioriteringarna och arbetsinnehåll i de sprintar som planerades i projektet.
- En mycket högre grad av transparens och kontroll över budgeten, vilket gav låg risk att vi skulle överskrida kostnadsramen. (Detta förstås givet att bägge parter gjorde sin insats, i enlighet med vad som stipulerades i avtalet.)
- För oss som kund betydde Agila kontrakt att vi behövde ha ett högre fokus på att kontinuerligt följa upp och försäkra oss om att vi nådde de effektmål vi satte upp. Detta inkluderade en formell sign-off i slutet av projektet. Att vår roll och ansvar för effektmålen tydliggjordes, såg vi som något positivt.
Låt oss ta en titt på tidslinjen inklusive huvudfaserna i projektet:
| Fas | Aktiviteter |
|---|---|
| Initial discovery (“förstudie”) | Analys och överblick av våra affärsprocesser. Här gjorde vi också vårt val av leverantör. |
| Skriva kontrakt | Förhandling och underskrift av det Agila kontraktet. |
| Kick-off | Vi inledde projektet med en kick-off som inkluderade alla deltagarna i de tvärfunktionella teamen. I den ingick personer i vår organisation (tex användbarhetsexperter) som deltog aktivt vid sidan om sina vardagliga arbetsuppgifter. Deltagandet var viktigt eftersom när personliga kontakter knyts, skapas även ansvarskänsla och motivation att dra sitt strå till stacken. |
| Implementering | Här byggde vi upp vår nya CRM miljö steg för steg i små korta iterationer. Utvärdering och testning skedde kontinuerligt. Efter varje iteration kunde våra användarspecialister och affärsansvariga provköra nya versioner inkl. utvärdera användarvänligheten av vårt nya system. Under implementeringen växte även våra acceptanstestscenarios fram. Dessa provkördes regelbundet. |
| Go live | Den formella bytet från våra tidigare CRM instanser/system, till vårt nya. Här skedde även det formella steget över i de nya affärsprocesserna. Vårt Automation team (där jag ingick) tar över ägandeskap över lösningen. |
| Kontinuerlig förbättring av affärsprocesserna över våra marknader (“bus ops”) | I en regelbunden tvåveckorscykel, förbättrade vi automatiseringen av våra affärsprocesserna. Detta sker synkroniserat över våra olika geografiska områden. Prioritering av högsta affärsvärde sker regelbundet i via vårt koncept “Thunderdome” (se beskrivning nedan). |
Om vi sammanfattar tidslinjen så kan man säga att det gick snabbt. På sex månader gick vi från ide, till kontinuerlig förbättring av våra affärsprocesser, (inkl ersättning av tidigare legacysystem) över 12 olika marknader.
Som kund, vilket förberedelsearbetet gjorde ni innan kontraktet skrevs?
Den största insatsen var att överblicka och beskriva våra affärsprocesser. Huvuddelen av arbetet gjorde vi själva, med ett litet stöd från en leverantör med expertis på området (vilken vi betalde på löpande räkning).
I nästa steg ingick att välja vilken leverantör att arbeta tillsammans med under leveransfasen. Vi jämförde ett antal alternativ och i slutänden bestämde vi oss för att välja en leverantör vi hade tidigare erfarenhet av. Vi kunde därmed validera att de defacto hade specialistkunskap i det CRM system vi valt att använda. Vi frågade leverantören om de var beredda att skriva ett Agilt kontrakt med oss, vilket de var. Efter det körde vi igång.
Resultatet blev att vi kunde hålla ett högt tempo. Kontraktet var underskrivet en månad efter vi hade initierat vår förstudie.
Hur reagerade leverantören på ert förslag att använda ett Agilt kontrakt?
De var positiva till att använda ett Agilt kontrakt. De visste att om de gjorde det rätt, så skulle det även öppna upp för fler projekt med oss senare. Om vi spolar fram till nutid, så har sedan starten skrivit vårt femte kontrakt ihop. Vi har fått ett väl fungerande samarbete visat sig lönsamt, för bägge parter.
Låt oss gå igenom huvudelementen i ert Agila kontrakt
| Element | |
|---|---|
| Prismodell | Vi använde en målpris baserat på tid. I kontraktet hade vi inskrivet ett grundpris per dag för leverantören under projektet tidsram. Vid tidigare leverans än utsatt datum fick leverantören bonus i form av vinstdelning av den återstående budgeten. |
| Tidslinje och delleveranser | Tidslinje och deleveranser fanns beskrivna ii kontraktet. Predikterat “go live” datum var satt till Q1 2018. |
| Vinst och riskdelning | Vårt målpris stipulerade att om slutdatumet överskreds, skulle priset per konsult falla per dag till en punkt när det bara ersatte bara direkta kostnader. Om leverans skedde före utsatt slutdatum skulle den återstående budgeten fördelas lika (50/50) mellan kund och leverantör. Detta skapade ett gemensamt incitament för bägge parter att leverera före utsatt tid. |
| Deltagande av nyckelpersoner | Leverantören garanterade att samma personer som inledde projekte skulle följa det till slut. Dvs att personer inte skulle bytas ut under projektets gång (förutom vid force majeure). Leverantören garanterade även att kunskapsöverlämning skedde mellan projektdeltagare vid kortsiktig frånvaro. Ett sådant tillfälle var avtalsenlig semester. Som kund hade vi slutligen en option att ersätta personer i projektet, om samverkan inte fungerade. |
| Projektstruktur | Här definierades nyckelrollerna som krävdes från både oss som kund och från leverantören. (se beskrivning nedan) |
| Konflikthantering | När kontraktet togs fram konsulterade vi experter på AgilaKontrakt för att bolla ideer om hur kontraktet skulle byggas upp. Vi beslutade att sno lite ideer från dem som vi använde i denna sektion. Några av dem var: - Personer som har en konflikt måste först först själva göra en insats för att försöka lösa den. Tex. genom att helt enkelt ta en promenad tillsammans. - I nästa steg aktiverades en medlare som inte var direkt involverad i projektet. Denna måste gemensamt väljas av parterna i konflikten. - I det slutgiltiga steget, om ännu olöst, eskaleras konflikten upp till styrgruppen. Det visade sig att vi aldrig behövde använda det sista steget. Vi blev väldigt sammansvetsade under projektet och vår samverkan fungerade väl. |
Fanns det några konflikter som ni behövde lösa?
Ja, en gång. Vi insåg rätt tidigt att vår leverantör hade en annan definition av “klart” betydde (det man inom Agilt kallar “definition of done”). Den goda nyheten var att så snart vi såg detta problem så kunde vi ta upp det med leverantören och hitta en lösning. En viktig lärdom vi tog med oss till nästa projekt blev att tidigt etablera en gemensam definition av “klart” och att detta skedde tidigt under kontrakteringsfasen.
Hur såg projektstrukturen ut och vilka rollerna fanns hos kund/leverantör?
Leverantörssidan
På leverantörssidan fanns en projektledare samt två systemspecialister, var och en med ett dedikerat affärsenhetsfokus (Sales och Service i vårt fall). Det fanns även en generell systemspecialist som vi kallade för “wildcard”. Det var en person som hjälpte till där det behövdes mest. Summerar man dessa roller så kan man säga att leverantören hade djupgående kunskaper om hur CRM systemet (ett standardsystem som köptes från hyllan) fungerade (inkl hur det behövde konfigureras). I leverantörens ansvar ingick att löpande följa upp status på tid och budget (vilket gjorde med hjälp av en enkel budget burndown). Detta gjorde att vi löpande hade koll på budgeten och slapp oväntade överraskningar.
Kundsidan
Våra aktiva roller var:
- Ett sammahållande ledarskapsteam – Business sponsor, Project Lead och Project manager (jag). Vi höll ihop vår gemensamma insats.
- Ett tvärfunktionellt leveransteam – Detta bestod av två CRM systemadministratörer, konsulterna från leverantören, två integrationsteam med ansvar att bygga integrationer mot våra interna system (bemannades med utvecklare samt data/db) plus deltagare från fyra affärsenheter (Sales, Support, Risk och Marknadsföring). Deltagarnas från våra affärsenheter var även distribuerade geografiskt för att representera våra olika marknader.
Det faktum att våra marknadsenheter är distribuerade över världen gjorde att samverkan mer komplicerad. Vi fick helt enkelt prova oss fram, tills vi hittade en form som fungerade.
Under implementationsfasen, så bestod affärsenheternas “commitment” att dela kunskap över vilka scenarios våra affärsprocesser behövde stödja samt aktivt deltagande i acceptanstestning. Personerna som deltog i leveransteamet (några per affärenhet) hade även ansvaret att träna upp sin personal på sin enhet i det nya processerna innan “go-live” datumet. Som hjälp hade de träningsmaterial som togs fram av det tvärfunktionella leveransteamet.
När vi gick över från implementationsfas till kontinuerlig förbättring av våra affärsprocesser så intensifierades samarbetet. Idag förbättrar vi våra affärsprocesser varannan vecka globalt via en fast tvåveckorsrytm (vi kallar det vår “bus ops” sprint) .
Du nämde conceptet ”Thunderdome” tidigare, kan du utveckla detta?
Absolut! En nyckelingrediens inom ramen för “bus.ops” är prioritering. För oss innebar det att hitta en fungerande form för prioritering givet att våra maknadsenheter var distribuerade. Thunderdome blev vår approach för att förstå – utifrån alla önskemål som fanns – vad som utgör det högsta värdet för iZettle under nästa sprint. Vi genomför denna prioritering på en fast tid, 2-3 arbetsdagar innan nästa “bus ops.” sprint startar.
Namnet “Thunderdome” är taget från filmen Mad Max där “två män går in och en går ut”. I vårt fall var det inte fullt lika dramatiskt. I vårt fall innebar det att många önskemål (stories) från våra affärenheter går in (i vår backlog), och några av dessa prioriteras att levereras under nästa sprint. Hur kommer vi fram till vilka dessa är? Jo vi låter våra affärsenheterna “brottas” om saken 🙂 Detta sker strukturerat genom att att växelvis får varje affärsenhet se världen från sitt, sedan de andras perspektiv. Ut kommer vad som marknadsenheterna tillsammans anser, utgör det högsta affärsvärdet får iZettle.
Hur går Thunderdome till?
Vi använder en digital tavla där alla kan se varandras önskemål. Mötet sker tidsboxat (en timme), på en fast tid varannan vecka (vilket är lite knepigt att få till på normal arbetstid, då vi är verksamma över flera kontinenter). Vi träffas digital via Google Hangout. Regeln är att om du har ett önskemål/story som du vill ha in in backloggen, då måste du som affärsenhet delta på mötet. Vi har även som deal att om du inte dyker upp på “Thunderdome” – så får du köpa att dina stories riskerar att inte blir prioriterade. Deltagandet på mötet är oftast högt.
En konsekvens av att kontinuerligt välja ut högsta värdet för iZettle under den kommande tvåveckorsperioden är att vi sällan på mötet tar oss fram till till slutet av backloggen. Så för att se till att vi inte missar viktiga stories som borde prioriteras upp, ber vi våra affärsägare att på egen hand uppdatera backloggen, ta bort duplikat och gå igenom backloggen på egen hand innan vi träffas gemensamt.
Fördelarna med denna 2-veckorsrytm är att om någon affärsägare av misstag glömt en viktig story, så är det inte hela världen, det kommer strax ett nytt tillfälle där du kan ändra prioriteringen.
Vilket har varit resultatet av projektet? Hur gick det efter att det var klart?
Vi lanserade den 9:e April 2018, vilket var endast 8 dagar efter vårt planerade (ideala) go-live datum. Om vi betänker att vi samtidigt ersatta två legacysystem och uppdaterade ett antal kritiska affärsprocesser över flera marknader, och att detta fungerade från dag 1, så får vi ändå säga att utfallet var över förväntan.
Tidsmässigt så gick vi från ide till “live” på 6 månader. Efter detta lyckades vi öka takten ytterligare, nu förbättrar vi våra affärsprocesser regelbundet varannan vecka.
När du blickar tillbaka, vilka var fördelarna med att använda ett Agilt kontrakt?
Fördelarna var att det snabbt byggde förtroende på båda sidor. Detta skapade ett effektivt och nära samarbete som var nyckeln till att lösa oförutsedda händelser, och till att ständigt optimera värde leveransen för iZettle. Det gjorde det roligare att arbeta i projektet, både som kund och som leverantör. Sammantaget har det hjälpt oss bygga långsiktiga professionella relationer, och även vänskap mellan deltagarna.
Tack Maria Izzo för att du tog dig tid att dela dina erfarenheter och insikter!