På 2,5 år har SBAB gjort något få andra banker klarat: skiftat ut sitt gamla legacy-banksystem, moderniserat sin arkitektur och fått bättre ledtid. Vi tog tillfället i akt att prata med Klas Ljungkvist, CIO, hur de gjorde för att tackla utmaningen. Fascinerande och uppfriskande är hur SBAB löpande adresserade vad som behövdes; från avtalsform till process; för att det var rätt sak att göra. Håll i hatten för nu åker vi!
(this article is also available in English here)
Låt oss börja med bakgrunden. Vad var det som gjorde att ni såg behovet av att initiera ert moderniseringsprojekt ”Surtsey”?
Vi får backa till 2015/2016 och situationen vi satt i då. Det vi såg var att vi satt med uråldriga plattformar som utgjorde ett hinder för flexibilitet och utveckling. Förutom flexibiliteten så hade vi även problem med robusthet och tillförlitlighet. Vi hade det jag kallar ett ”jobbigt legacyläge”.
Vi bestämde oss för att göra något åt saken. Första steget var att skapa en ny IT strategi för att bygga en målbild. I den ingick att pensionera våra gamla legacysystem – bland annat corebanksystem, system för lånereskontra, händläggarsystem för vår företagsaffär, data management och kredit-onboarding – samt att införa en smidigare integration mellan kärnsystem och applikationer.
Satte ni upp några effektmål? Kan du eventuellt dela ett?
Två av de övergripande målen för programmet var långsiktig överlevnad och konkurrenskraft. Givet det satte vi några effektmål för skiftet. Ett av effektmålen var ”halverad ledtid i utveckling (från prioritering till i produktion)”. Vi hade ett benchmark på ledtiden från 2017 på 36 dagar. Under programmets gång gjorde vi små temperaturchecks på ledtiden för att se att den trendade i rätt riktning.
Idag ligger vi väldigt nära vår målsättning med en ledtid mellan 15-20 dagar. Faktum är att framstegen vi gjort gör att vi inte längre målsätter ledtid, utan snarare följer upp det regelbundet som en KPI.
En av de nyckelfaktorerna till halveringen var skapandet av ett microservicebaserat integrationslager, istället för den monolit vi hade tidigare.
Vad var tidsramen för initiativet?
Vi var lite optimistiska när vi satte igång, vi trodde vi skulle kunna steka av hela rasket på 3 år. Med omfattningen på hela rasket och vår höga ambition, så blev det tydligt rätt snart att det fixar man inte på tre år.
Om vi dock preciserarar vissa delar som tex corebanksystembytet så var vår ursprungliga prognos att det skulle ta 1.5år, med facit att det tog 2.5 år.
Hur långt in i projektet behövde ni komma för att kunna göra en tillförlitlig prognos för sluttidpunkten)?
Om vi tittar på utbytet av corebank-systemet så delade vi upp vårt skifte i två inkrementella steg – Betalning och Sparande. Betaldelen fick vi grepp om rätt snart och genomförde med hyfsad precision. Spardelen var svårare materia. För sparandet var det ungefär 1.5 år innan avslut när vi såg att vi hade en prognos med hyfsad säkerhet.
Om användarupplevelse (tex handläggare)
Skiften av detta slag kan ju lätt bli tekniktunga med användarupplevelsen hos de som arbetat med systemen hamnar i andra eller tredje hand.
Hur gjorde ni för att se till att slutanvändarupplevelsen hölls på en vettig nivå och inte degraderades (för att man inte hinner med)?
Det vi gjorde var att vi satte ett tidigt randvillkor: För slutkund skall det inte vara någon skillnad. Detta har vi i princip uppnått.
Förutom det hade vi ett effektmål riktat till våra handläggare i syfte att deras användarupplevelse inte skulle försämras, och om det blev en degradering så skulle vi ha skapat förutsättningarna för att kunna rätta till den. Detta effektmål övervakade vi kontinuerligt i styrgruppen.
Här har utfallet blivit ömsom vin, ömsom vatten. Viss funktionalitet har blivit bättre, men vi har prioriterat att hålla tidsramen för att kunna driftsätta lösning i första hand, vilket har gjort att vi fått göra avkall på viss funktionalitet för handläggarna. Vi lyckades dock med det övergripande målet att förutsättningarna för att uppgradera användarupplevelse är på plats (i de fallen den degraderats), vilket gör att vi nu steg för steg kan adressera denna.
En organisationsmässig faktor som är värd att nämna när vi pratar användarupplevelse, är att vi aldrig sett detta som ett ”renodlat IT-projekt”. Vårt fokus är verksamhetsförbättring.
Ett exempel på det är att verksamhetsfunktioner som Ekonomi, Backoffice och Handläggare, varit integrerade och drivande del av projektet. Verksamhetskunniga anslöt till de existerande Agila teamen och vår systemleverantör. Vi behövde få ett fungerande och tätt samarbete, något som i efterhand varit en nyckelfaktor.
Har ni exempel på områden där ni de facto lyckats förbättra användarupplevelsen?
Det har vi. Vi har genom våra integrationer kunna implementera fler funktioner till våra användare. Den ökade driftstabiliteten får även betraktas som ett positivt steg framåt användarupplevelsemässigt. Det gamla systemet hade en viss förmåga att packa ihop lite emellanåt.
Att kunna göra vettiga trade offs är en central förmåga i Agila projekt. Kan du berätta vilka trade offs ni gjorde på hög nivå (i vilken ordning kom budget, tid och scope) samt om den ändrades under projektets gång?
Från början var de (i ordning):
1.) Tid 2.) Scope (få en så bra lösning som möjligt) och 3.) Budget
Detta justerades dock en bit in projektet till att bli:
1.) Tid 2.) Budget 3.) Scope
Detta med utgångspunkt att tiden var den dyrbaraste faktorn.
Lite om projektorganisationen
Ni arbetade både internt och med hjälp av externa partners för att genomföra skiftet. Grovt hur många team var involverade i projektet under peakperioden?
I vårt program som helhet ca 4-5 agila team med fokus på utveckling. Parallellt med dessa fanns även en stor involvering från verksamhet, bla ekonomi, redovisning och backoffice.
Kan du berätta lite om vilka roller/ansvar ni tog som kund och vilka roller/ansvar som leverantören tog?
Fokus och roller varierade under projekttiden.
Fas 1 – Inledning
Vi inledde med en väldigt tunn projektledning ovan våra Agila team. Avtalsmässigt så inledde vi med ett fastprisavtal ihop med vår leverantör. Nettoeffekten blev att leverantören sprang i förväg mot den kravspecifikation som fanns i avtalet. Vår uppstartstid internt var längre och vi hade svårt att hålla jämna steg. Vi insåg att vi behövde dra i handbromsen och ändra både avtalsförhållandet och arbetssätt för att ha en chans att gå i mål.
Fas 2 – hitta en gemensam takt
Vi tillsatte en lite tyngre projektledning och arbetade med att tydliggöra roller och ansvar. Processmässigt initierade vi en gemensam rytm, som var gemensam för alla involverade parter. Vi lyckades nu etablera en gemensamt takt och leveransrytm. Dock kände sig våra Agila team sondmatade i detta läge. Vi var inte i mål med att släppa tillräckligt med initiativ och ansvarstagande till våra Agila team. Så nästa steg var att skapa en mer balanserad projektledning.
Fas 3 – Skifte av mandat och kontinuerlig ökning av leveransförmåga
I den tredje fasen försökte vi hitta ett balanserad mellanläge av projektledning mellan fas1 och fas2. Vi arbetade hårt med att ge mandat till våra Agila team som nu hade byggt upp kunskap och förmåga. Vi gjorde förbättringar som innebar att vi kontinuerligt förbättrade vår gemensamma leveransförmåga, vilket vi kunde se avspegla sig i sjunkande ledtider och ökad initiativkraft i våra Agila team och även hos vår systemleverantör.
Det låter lätt, men att personal och team att utveckla initiativkraft och ansvarstagande, samtidigt som det finns hårda leveransförväntningar är allt annat än enkelt. Vilka var nycklarna mellan fas2 och fas3?
Några saker samverkade. En sak var att vi gick ifrån fastprisavtalet till ett agilt förhållningssätt med gemensamt incitament att gå i mål. En annan var att vi stimulerade både agila team och verksamhet att få upp initiativtagandet. Ett organisatoriskt skifte som jag tror hade signalvärde i denna fas var att vi ändrade projektledarrollen, och stöpte om den till programledning. För egen del försöker jag spendera mer tid på golvet som coachade ledare, ha en dialog med programledare att släppa ett större ansvar och en parallell dialog med team och verksamhet ta ett ökat ansvar.
Om skiftet från fastprisavtal
Ganska tidigt in projektet skrotade ni det ursprungliga fastprisavtalsupplägget och ersatte det med ett mer Agilt. Vilka var de tidiga insikter ni gjorde som drev på det skiftet?
Skiftet mellan fas1 och fas2 betecknas av insikten att fastprisavtalet skapade ett incitament för leverantören att springa mot vår ursprungliga kravspec även i de fall som den blivit inaktuell. Nya omvärldsfaktorer gjorde att den ursprungliga kravspecen inte stämde med våra prioriterade behov, och avtalet vi hade var inte flexibelt att hantera detta.
Det gjorde att vi ändrade avtal och samverkansform för att de till att vi kunde gå i takt och mot gemensamma mål. Kortfattat innebar det ett skifte från att leverantören fick betalt per funktion till att vi nyttjade en gemensam kostnads och tidsram. Exekveringsmässigt fungerade det mycket bättre, vi hade nu flexibilitet att gemensamt agera på ändrade förutsättningar.
Hur vi styckade elefanten – om stegen innan utveckling
Vad man gör innan utveckling påbörjas är ofta en nyckelfaktor där det gäller att hitta en bra balans (inte för lite, inte för mycket). Vilka faser hade ni grovt i stegen innan utveckling påbörjades?
Det första steget (ca 2015) innan vi satte igång var en förstudie fokuserat på att beskriva förmågorna i det gamla systemet . Tricket är att hålla den på en rimlig detaljeringsnivå. Denna baserade leverantören sin ursprungliga kostnadsuppskattning på.
I nästa steg delade vi upp elefanten i mindre steg.
Vi delade ursprungligt upp Surtsey i ett antal mindre faser; först bank, sedan hypotek. Ganska snart insåg vi dock att vi måste börja med något förhållandevis lätt, så vi fokuserade inledningsvis på privatlån.
Vad fokuserade ni på under product discovery (fasen innan utveckling)?
När vi inledde varje fas började vi med att göra en värdeströmsbild av flödet ”end-to-end”. Baserat på denna mappade vi sedan upp användningsfall (use cases). Behovsbilden var klar för oss när vi hade förstått och kunde beskriva värdeströmsbild samt användingsfall.
Detta var ett skifte mot hur vi hade kravspecat tidigare, där vi snarare hade specat funktioner.
Mot användningsfallen mappade vi sedan user stories som blev artefakterna teamen arbetade mot. Vi mätte löpande vår progress i varje fas mot utvecklade user stories. Visst upptäckte vi saker under arbetets gång, men oftast höll sig variationen (av antal user stories) inom 25%.
Om framgångsfaktorer
Ett flertal banker har ju försökt genomföra skiften av liknande slag, men med begränsad framgång. Vad tror det var som gjorde att ni lyckades?
Ett antal saker. De faktorer jag skulle lyfta fram är:
- Stark vilja och acceptans i ledning och styrelse
- Att vi har lärt och anpassat oss, under projektet gång. Det har funnits en kontinuerlig vilja till förbättring hos alla parter, leverantörer inkluderat.
- Vi har haft ett löpande fokus på vad som vi är villiga att prioritera bort får att nå våra mål För oss innebar det ett ökade fokus på att scopa ned under programmets gång. Detta i syfte av att bli klara i tid.
Om förbättringar, före och efter
Om vi kikar lite på arkitekturella förmågor, utan att gå ned oss i teknikstackar, vilka förmågor har blivit bättre efter skiftet?
Flexibilitet, ledtid och tillförlitligheten har tagit stora steg framåt.
Hela banksystembytet har inneburit att vi kunnat skifta ut en monolit och ersätta detta med ett integrationslager baserat på microtjänster. Detta gör att vi idag kan agera ruskigt fort vilket vi även ser i våra ledtider.
Vi har lyckats lägga ett antal system i malpåse, tex vårt handläggarsystem för företagsaffären och och core-banksystemet.
Parallellt med insatserna ovan har vi idag en mycket bättre datahantering. VI är nära att kunna skrota vår gamla data lake. All cred till vårt data science team för det arbetet!
Nämn en viktig förbättring ni såg hos eran leverantör (i deras process/org) under resan?
En insikt vi drog tidigt under bankbytet var att ledtiden var för lång, detta var drivet av att vi gjorde saker i stora batcher (bla produktionssättningar).
Vi lyckades arbeta fram ett sätt som gjorde att små saker (user stories) kunde sättas i produktion utan att hindra annat. Undan för undan lärde sig leverantören att göra detta smidigt. Resultatet blev att leverantören halverade sin ledtid.
Ni är nu i drift och systemen är i användning. Världen står dock sällan still. Jag är nyfiken på vad är det för steg ni ser att ni vill fokusera på framöver? Kan du nämna något?
Vi kommer att fortsätta vårt legacykrig 🙂 Vi arbetar just nu fokuserat med att byta lånereskontra (ett gammalt Cobol-system) och kredit-onboarding.
Rekommendation till andra
Vad skulle du rekommendera andra som ger sig in ett liknande projekt?
Oj. Några saker.
- Var beredd på att det kommer att göra ont, men att det är nödvändigt. Ett sådant här projekt är inte lätt! Underskatta inte ledtiden i att få nya system på plats vad gäller infrastruktur och ickefunktionella krav.
- Sträva efter att försöka göra det stora smått, så att du kan blir klar med olika delar var för sig.
- Hitta en leverantör, som har en bra ”cultural fit” med dig. En leverantör som du gillar.
- Skapa en bra samverkan med den verksamhet du bygger systemen för. I vårt fall integrerade vi verksamhetskunniga med våra team.
- Starta i tid. Och tokprioritera projektet när du väl har bestämt dig för att köra.
Tack Klas för att du tog dig tid! Varmt lycka till på resan framöver!