Hur många incidenter är lagom många incidenter?

av | feb 25, 2016 | FLÖDE, ITIL/ITSM

Leverans av IT-tjänster är en komplex syssla med många felkällor. Felen kan levereras av leverantörer, vara inbyggda i redan existerande tjänster eller vara resultatet av det vi själva har gjort.

Det är ganska få för att säga inga kunder som önskar att det “strular” i de tjänster de avropar från IT-leverantörer. Man förväntar sig att det som fungerade igår ska fungera idag, och man förväntar sig att leveranser av ny funktionalitet också ska fungera när det väl landar på desktopen eller appen hos användaren. Men är det rimligt att förvänta sig att det alltid ska fungera? Att vi aldrig ska uppleva några incidenter och buggar? 

Ingen vill betala för den kvaliteten

Inom IT skulle nog de flesta säga “nej det är omöjligt”, det är för komplext, för många aktörer inblandade och felet kan dessutom vara skapat av användaren själv genom SBS (skit bakom spakarna). Alternativt så skulle man svara med “det går att göra men det skulle vara alldeles för dyrt, ingen kund skulle vara beredd att betala det priset”. Här börjar det bli intressant.

Under mina nu ganska många år inom IT-branschen så har jag aldrig någonsin stött på en organisation som med någon form av åtminstone rudimentär säkerhet räknat ut vad den faktiska kostnaden för “zero defects” skulle vara.

Och frågan är ju naturligtvis om det verkligen skulle vara så dyrt. Argumentet utgår ju ifrån antagandet att kvalitet per automatik är dyrt.

Om den sammanlagda insatsen av initialt arbete plus efteråtgärder/rättningar överstiger den alternativa kostnaden/insatsen för att ha kvalitet redan vid källan; är det då dyrt med hög kvalitét?

Hur mycket pengar sparar vi också på att plötsligt bli avbrutna av icke-planerat arbete som tar all vår uppmärksamhet? Samtidigt som det hindrar oss att genomföra de leveranser vi redan åtagit oss? Vad är vår ”Cost of delay” då?

Incidenter, buggar och defekter?

Inom IT har fel många olika namn. Pratar vi ITSM och ITIL så kallas det Incidenter. Utgår vi från systemutveckling så får det ofta namnet bugg. Inom ramverket Lean IT så beskrivs det som defekter.

Oavsett vilket så kännetecknas alla ovan av samma följdeffekter:

  • Missnöjda kunder och användare
  • Oönskade kostnader/fördyrning
  • Planerat arbete och leveranser försenas
  • Frustration, stress och irritation internt i organisationen

När kvalitet får vara vägledande 

Låt oss vända blicken utåt en stund och fundera hur man resonerar kring detta i andra branscher som har haft framgång med sitt kvalitetsarbete.

Först ut har vi Toyota (respektive numer också Porsche) som utgår från resonemanget “kvalitet är billigt”. Genom att göra rätt från början och genom kvalitet vid källan (inte i efterhand genom efteråtgärder) så har man sänkt kostnaderna. Toyota har till exempel mer än 55 år av lönsamhet i bilbranschen vilket de är helt ensamma om bland övriga massproducenter.

Porsches helomvändning från att tidigare ha ett gigantiskt test- och kontrollcenter efter produktionslinans slut till att säkra kvaliteten under konstruktion har också vänt deras bolag till en vinstmaskin från tidigare berg- och dalbana i resultaträkningen.

Nästa intressanta exempel är Vägverkets (numer trafikverkets) nollvision. I all enkelhet går det ut på visionen att noll personer ska omkomma i trafiken varje år. Att det är en vision är för att de vet att det är ett långsiktigt mål med många faktorer som kan påverka. Men som de säger, visionen kan ju inte vara att 30 personer ska dö varje år för den naturliga frågan då blir ju: “ok, vem är det som vi vill avrätta i år? Den där pensionären, eller småbarnsmamman på väg till jobbet”?

Samma argument kan man ju enkelt använda inom IT, vilken användare tänker vi inte ska kunna jobba nu på torsdag?

Tyvärr tycks vi inom IT ha skapat en toleransnivå för att det strular och “det är helt enkelt något man måste räkna med”. Effekten blir dock att kvalitet alltid hamnar i andra hand.

Nu kommer vän av ordningen antagligen säga att vi har viktigare saker att sköta, till exempel den här enorma back-loggen av önskemål. Problemet är ju då att varje gång vi måste lägga fokus på att lösa en incident/åtgärda en bugg så tappar vi ju i hastighet i vår leverans av nya grejer. Häri ligger kanske klon.

Kvalitet är billigt

Det är billigt med hög kvalitet. Mycket billigare än att behöva rätta fel.

Vi levererar snabbare om vi gör rätt från början. Om vi har kvalitet så kan vi jobba med värdeadderande arbete istället för slöseri. Såsom att laga det som redan borde fungera. Enligt ”Littles law” så betyder alltid större lager av inventarier (i det här fallet olösta incidenter) längre leveranstider och högre kostnader. 

Hur får vi ordning på det?

Idag har vi många bra förändringar inom IT-branschen som pågår. Den agila metodiken innebär att vi inte måste sitta med fel i våra system till nästa leverans om 9 månader.

Intåget av mer strukturerad Incidenthantering á la ITIL har skapat en plattform av gemensam terminologi samt bra verktyg för att bättre förstå varför fel uppstår och hur de ska åtgärdas (Incident och Problem Management).

Testautomatisering sparar också tid. Dock lider testautomatisering som Edward Deming sa, “vi kan inte testa oss till kvalitet”. Det börjar och slutar med att ledarna i organisationer uttalar sin tydliga ambition och outtömliga driv mot 100% kvalitet i allt vi gör just eftersom det kommer sänka våra kostnader, öka vår hastighet i leveranser och i slutändan naturligtvis innebära nöjdare kunder.

Genom att tydligt förklara att det inte finns en konflikt mellan god kvalitet och låga omkostnader, genom att tydliggöra att vi får snabbare leveranser om vi inte måste rätta fel hela tiden och genom att tydligt uttala att vi “förväntar oss inget annat än att det ska fungera” redan från början förstår IT-organisationen vad som är viktigt. Och det går alldeles utmärkt att jobba agilt samtidigt som vi har fokus på detta. Det går att driva projekt med precis samma fokus.

Det går att förvalta med utgångspunkt från att varje gång något inte fungerar som det är tänkt så har vi ett utmärkt tillfälle att lära oss, förbättra oss och implementera dessa förbättringar. Förbättringar som nästan alltid har sin grund i att våra arbetssätt måste ändras, inte tekniken. 

Vad är det som behöver ändras?

  • För det första, full transparens för alla inblandade över hur ofta och mycket det inte fungerar som det ska. Även till kund.
  • Om möjligt, involvera din kund i besluten att investera tid och resurser i att städa koden, åtgärda kända fel och därmed balansera insatserna lagom mellan nytt och underhåll.
  • Ställ tydliga krav på leverantörer (när så går) att vi förväntar oss att leveranser till oss ska vara felfria. Det kallas acceptanstest för att man bara går igenom en formell kontroll att det fungerar. Om det hetat “nu ska vi leta efter buggar som leverantören borde ha hanterat redan från börjantest” så hade det varit en annan femma.
  • Förklara också klart och tydligt för leverantören att du är beredd att investera de pengar som behövs för att i slutändan spara på att de lägger tid på att testa ordentligt. Men förklara också klart och tydligt att de måste påvisa effektivitet i hur de säkerställer att det fungerar redan från början (brukar vara enkla saker som att ha miljön dokumenterad, löpande testa det som skapas redan från kravfångst och framåt, samt ha en strukturerad testmetod).
  • Kanske kan det också vara bra att nämna för leverantören i sammanhanget att vi inte längre är intresserade av att betala dubbelt för samma sak längre (en affärsmodell som länge varit rådande inom IT-branschen där vi bygger något, levererar till kund och sen tar betalt igen för samma sak för att rätta det som från början redan borde ha fungerat).
  • Och sist men kanske viktigast, släpp loss kraften hos din egen personal att själva hitta bästa sättet att faktiskt minimera mängden fel. De är proffsen, det är de som bäst vet vad som behöver göras, inte chefen med en perfekt plan.

Vad är det som behöver ändras?

  • För det första, full transparens för alla inblandade över hur ofta och mycket det inte fungerar som det ska. Även till kund.
  • Om möjligt, involvera din kund i besluten att investera tid och resurser i att städa koden, åtgärda kända fel och därmed balansera insatserna lagom mellan nytt och underhåll.
  • Ställ tydliga krav på leverantörer (när så går) att vi förväntar oss att leveranser till oss ska vara felfria. Det kallas acceptanstest för att man bara går igenom en formell kontroll att det fungerar. Om det hetat “nu ska vi leta efter buggar som leverantören borde ha hanterat redan från börjantest” så hade det varit en annan femma.
  • Förklara också klart och tydligt för leverantören att du är beredd att investera de pengar som behövs för att i slutändan spara på att de lägger tid på att testa ordentligt. Men förklara också klart och tydligt att de måste påvisa effektivitet i hur de säkerställer att det fungerar redan från början (brukar vara enkla saker som att ha miljön dokumenterad, löpande testa det som skapas redan från kravfångst och framåt, samt ha en strukturerad testmetod).
  • Kanske kan det också vara bra att nämna för leverantören i sammanhanget att vi inte längre är intresserade av att betala dubbelt för samma sak längre (en affärsmodell som länge varit rådande inom IT-branschen där vi bygger något, levererar till kund och sen tar betalt igen för samma sak för att rätta det som från början redan borde ha fungerat).
  • Och sist men kanske viktigast, släpp loss kraften hos din egen personal att själva hitta bästa sättet att faktiskt minimera mängden fel. De är proffsen, det är de som bäst vet vad som behöver göras, inte chefen med en perfekt plan.

Två centrala förmågor

För att komma vidare i det här måste två centrala förmågor utvecklas inom organisationen:

  1. Att betrakta fel som ett tillfälle till lärande och förbättring.
  2. Att identifiera det underliggande felet till att “felet” tillkom från början. Inte bara “det här blev fel, jaha men rätta det då”.

På Toyota använder man tekniken 5 varför parat med PDCA-hjulet. Det finns självklart andra modeller, tex. DMAIC som används inom Lean IT. Vilken man väljer är inte viktigt, men vad som är viktigt är att få bort det underliggande felet.

Så ställ er frågan: “varför är det inte viktigt för oss med kvalitet” och jobba sedan fram det underliggande felet. Då kan ni kanske börja bygga in kvalitet på ett sätt ni inte gör idag och därmed spara tid och pengar samtidigt som ni ökar er förmåga att leverera till kund.

Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.

Kvalitet enligt Lean

Kvalitetsarbete är en grundpelare inom Lean IT. Tvådagars kursen Lean IT Foundation ger en gedigen grund för IT-organisationer som avser göra en insats i sitt kvalitetsarbete. Kvalitetsaspekterna av Lean IT är applicerbara oavsett om ni i dagsläget arbetar utifrån ITIL eller Agile/Scrum.

Författare
Torbjörn Dahlström

Jag har en idé om att vi kan bättre. Vi kan få ut mer värde av våra IT-initiativ. Vi kan korta ledtider i leveranser. Vi kan knyta verksamhet och IT närmare. Och vi kan samtidigt få nöjdare och mer motiverade medarbetare på köpet. Läs mer om Torbjörn

Kostnadsfri rådgivning

Vill du prata med oss för en kostnadsfri rådgivningssession kring era behov/utmaningar? Kontakta oss genom formuläret nedan!

Share This