Exakt samma fast på ny plattform!

Nu ska ni få en liten historia ur verkligheten, men det hjälper inte om ni frågar var någonstans detta har utspelats för dels vill jag skydda mina uppdragsgivare, och dels har jag faktiskt sett precis nedanstående ske på fyra helt olika platser under tolv års tid. Jag gissar att det händer igen och igen och igen...

Det var en gång en verksamhet som behövde ett system. Eftersom organisationen hade beslutat om en viss teknik (en generell applikationsteknik som byggde på en generell relationsdatabas och ett generellt språk för mellanlager och användargränssnitt), så beslöt man sig för att bygga systemet i precis denna teknik.

Organisationen berömde sig av sina noggranna förstudier och sin rigorösa beslutsprocess, och därför tog man god tid på sig för att inhämta kraven från användarna. Alla processer kartlades, och man såg till att ingen detalj glömdes bort. Man gjorde det så noga så att det tog så lång tid, att när informationsarkitekterna tog över för att modellera objektrymd och databas, så hade kravfångarna och verksamhetsmodellerarna ingen budget kvar. De lämnade över kravdokumentet och började jobba på andra projekt. De som var konsulter gick vidare till andra uppdrag i helt andra verksamheter.

Informationsarkitekterna och programmerarna ville jobba agilt och gjorde sitt bästa för att samarbeta runt de överlämnade kravdokumenten, men när de sprang på frågor fanns det inga kravfångare kvar att fråga; och verksamheten tänkte minsann inte lägga en minut till på att förklara sina verksamhetsprocesser och behov en gång till.

Nå, till slut lyckades utvecklarna leverera ett system, inte på budget och inte så att verksamheten blev helt nöjd, men åtminstone så att det kunde anses färdigt enligt de högst luddiga och oklara acceptanskriterierna. Nja, kriterierna var egentligen inte luddiga, språkligt/syntaktiskt sett, men det hade visat sig under resans gång att de innehöll självmotsägelser och det är ju innehållsligt/semantiskt sett samma sak som oklarhet.

Verksamheten och IT-utvecklingen (varför ses aldrig IT som en del av verksamheten när informationsflöden utgör själva verksamhetens blod?) bråkade en stund om vems felet var (rätt svar: ingens, förstås, eftersom det inte existerar någon metod att på förhand ta reda på om krav är självmotsägande med mindre än att du försöker skapa en lösning som uppfyller dem); men verksamheten - som behövde systemet - accepterade och tog det i drift.

Det fungerade. Inte bra, men det fungerade. Åtminstone delvis.

Ganska snart insåg man att det faktiskt var viktigt att systemet både fungerade bra och till alla delar. Systemet skulle ju stödja verksamhetens absolut viktigaste process. Pengar behövde skakas fram för att lyfta systemet ytterligare ett steg.

Men nu tänkte någon till. Var inte grundproblemet egentligen att man valt en generell plattform för att göra systemet? Var det inte så att verksamhetens behov bättre matchades av en mer specifik plattform, ett sk affärssystem, som hade moduler för att stödja den här typen av verksamhet? Naturligtvis skulle det komma att krävas specialanpassningar, men i det stora hela var det en bättre match mellan plattform och verksamhet. På sikt måste ett plattformsbyte vara bättre!

Eftersom denna någon besatt ett rätt så omfattande mandat fattades beslutet utan några förstudier (personer på höga mandat besitter ju magiska egenskaper att se verkligheten sådan den är och behöver inte se några förstudier gjorda av folk med mindre mandat): plattformen skulle bytas ut, innan man gick vidare med att rätta bristerna i det befintliga systemet!

Något ytterligare kravarbete skulle inte behövas, resonerade man, eftersom det befintliga systemet tjänade som facit. Första delprojektet skulle ju bara replikera det befintliga. "Exakt samma, fast på ny plattform!", löd ordern.

Men vem skulle göra arbetet? De befintliga utvecklarna kunde ju funktionskraven bäst, och var därför bäst skickade att göra det! Sedan kunde man kasta in konsulter som kände till plattformen, alltså det nya affärssystemet.

Utvecklarna kliade sig i huvudet. De visste hur databasmodellen såg ut som stöttade de befintliga funktionerna. De visste att affärssystemet i botten var en relationsdatabas. "Exakt samma fast på ny plattform!" löd ordern. Alltså tog man det befintliga schemat och tryckte in i affärssystemets databas, och sedan gav man sig i kast med att anpassa de gränssnittsmoduler som mest liknade den befintliga funktionaliteten.

Det gick trögt. De befintliga utvecklarna kände ju inte till affärssystemets finesser, det gamla systemets databasmodell stöttade inte dessa finesser; så en enorm mängd specialtricks, skript, fulhack osv krävdes. När sedan experterna på affärssystemet skulle komma in och stötta visade det sig att dessa inte alls var så värst mycket till experter. I synnerhet begrep de sig inte på den röra som de befintliga utvecklarna lämnat efter sig. Lämnat efter sig? Ja, det ingick ju inte i någon budget att dessa bägge utvecklargrupper skulle arbeta parallellt.

Nu började någon-med-det-stora-mandatet bli nervös. Version 1 av systemet hade kostat mycket mer än prognosen. Version 2 riskerade att bli ännu dyrare och ta ännu längre tid och vara ännu sämre. Det utlovade leveransdatumet närmade sig och de tilldelade pengapåsarna var tomma. Bäst att agera! Bäst att kommendera fram en leverans!

Och så blev det. Systemet som varken var en skräddarsydd lösning byggd på en generell plattform; eller en smart anpassning av ett standardsystem; och vars funktionalitet (när det över huvudtaget fungerar) var en karikatyr av det som några kravfångare och verksamhetsspecialister drömt fram för länge sedan; det togs i bruk. Och kostade snabbt (i frustration, i fel, i utebliven verksamhetsnytta, i folk som tvingas lägga eoner av tid i handhavandet) betydligt mer än hela den sammantagna utvecklingskostnaden av version 1 och version 2.

Detta är så onödigt, och ändå händer det igen och igen och igen. Några enkla tips på vägen för att inte sätta sig i detta klister:

• Förstudier är galet. Studier är det rätta. Dessa ska bedrivas samtidigt som systemutvecklingen så att man hela tiden vet att man är på rätt spår. Se Scrum för en enkel och handfast metod som löser detta, till en låg kostnad.
• Det finns ingen metod som validerar krav innan de är implementerade. Krav kan vara självmotsägande. Vi kan vissa tricks för att minska risken att vi fångar krav som sen blir tokiga, men säkra kan vi (av matematiska skäl) inte vara. Det går därför inte att minska risken genom att vara rigorös. Det enda sättet att på allvar minska risken i systemutvecklingen är att minska omfattningen. Bryt ner i delmål och delprojekt, så vet ni att ni är på banan.
• Krav kan inte överlämnas i kravdokument. Dokument är viktiga som gemensamma sätt att fästa sin samsyn på papper, men det går inte att skriva ner alla aspekter och vara säker på att dessa tas om hand längre fram. Kravfångare och utvecklare ska campera ihop och jobba tätt. Överlämningar är en känd spillkälla.
• När Gartner Group sammanfattar statistik över lyckade och misslyckade IT-projekt försöker de hitta skälen till att projekt lyckas. Den viktigaste faktorn har varit närvaro av användare. Värdeflödet (tänk lean) är när en användare får ett verktyg som stödjer användarens värdeskapande processer. Man måste ha med dem för att uppnå det!
• Att ha mandat betyder inte att ha förmåga. Och ska du ha reell makt över utfallet behöver du mandat och förmåga på rätt nivå. Folk i höga positioner ska inte göra känslomässiga val av teknik. Inte utan en analys som visar att deras antaganden är rätt. Förbättringar ska vara ett empiriskt experiment. Inte magkänsla hos någon med hög månadslön.
• Om man vill använda färdiggjorda system ska man vara helt på det klara med att dessa verkligen stöttar ens verksamhet (eller så får man göra om sin verksamhet så att den passar systemet), och man måste känna till den verkliga kostnaden av att anpassa. Tänk på att konsulter för ett specifikt system är mycket dyrare och mer sällsynta än konsulter för standardtekniker.
• Att säga: "Exakt samma fast på ny plattform" är inte en kravspec. Plattformar ser väldigt olika ut. Annars hade det inte funnits plats för dem bägge på marknaden: de har olika uppbyggnad och fokus. Säger man "Exakt samma" så menar man ofta "Likadan fasad". Problemet är att de olika plattformarna är radikalt olika hustyper. Att limma på en fasad från en sorts hus utanpå en helt annan sorts hus, brukar inte bli så bra.
• Kostnaden i utvecklingen är inte programmeringen. Kostnaden är att ta fram informationen om exakt hur systemet ska fungera. Fokus ska ligga på att förbättra den informationsframtagningen. Och när vi säger exakt så menar vi exakt. Datorer är exakta.
• Systemkostnaden är till väldigt liten del programmeringen. Livscykelkostnaden är lätt tio gånger högre. Räknar vi med kostnaden av utebliven verksamhetsnytta pga dåliga system blir den mycket högre än så!
• Det går inte att kommendera fram en annan verklighet än den vi lever i. Nej, på riktigt: det går inte.