I-TIL besvær?

I-TIL besvær?

DND: Det handler om å forstå helheten og sammenhengen før vi begynner å klå på enkeltelementene.

Av Rune Ulvnes, Consulting Director i Comperio

Jeg vil påstå at det i dag finnes to retninger innenfor ledelsesfilosofien:

  1. den reduksjonistiske
  2. den holistiske (eller systemtenkende).

Reduksjonistene tror den beste måten å angripe komplekse problemstillinger er gjennom oppdeling. Skal en reduksjonist vurdere hvorfor de norske hopperne kommer til kort, vil han kanskje leie inn en kostholdsekspert, en psykolog og en aerodynamiker. De tre vil lage en rapport uten å vite om eller interessere seg for funnene fra de andre to ekspertene. Treneren vil lese alle tre rapportene, og komme til en konklusjon.

En holistiker derimot, synes denne angrepsmåten er meningsløs, og ville heller ha ansatt en systemtenkende toppidrettsekspert som kan følge hopperne over lengre tid. Systemtenkeren vil forsøke å se destruktive mønster, og foreslå konkrete tiltak som kan hjelpe.

ITIL følger reduksjonistenes tankesett, da det er et rammeverk som kun endrer driftsavdelingens hverdag. ITIL er utviklet av driftseksperter for driftsavdelinger. Jeg har sett IT avdelinger hvor svak driftskompetanse er årsaken til lav driftskvalitet, og hvor innføring av ITIL har økt de inkompetentes beslutningsmyndighet. I dette tilfellet var konsekvensen katastrofal for bedriften og deres kunder. Jeg har også sett en driftssjef som har feilet med å bedre driftskvaliteten med ITIL, mens den påfølgende sjefen løste problemet gjennom å la utviklere og driftere møte hverandre og bli kjent (noe som kostet 5 møter á 1 time med 10 møtedeltagere = 50 timeverk).

Drift er kun et steg blant mange for å realisere en løsning, og skal vi løse driftsutfordringer må vi se på hele verdikjeden fra idé til drift. For IT-løsninger er produkteieren den viktigste for driftsavdelingen. Produkteieren bestemmer hvor mye tid man skal benytte på ikke funksjonelle krav, og hvor lenge utviklerne får lov til å jobbe på løsningen etter den er lansert for å plukke bort driftsproblemer. En dyktig utvikler som får lov til å lage en stabil løsning med høy kvalitet under et godt testregime, kan lage løsninger som kutter driftskostnaden radikalt i forhold til løsninger som er utviklet under press av en middelmådig utvikler.

For å lykkes med smidig drift vil jeg fremme følgende holistiske prinsipper:

  • Felles visjon og mål hos produkteier, utvikling og drift. Et felles mål å enes om er viktig skal de tre gruppene kunne jobbe sammen.
  • Ingen vegger mellom produkteier, drift og utvikling. Jo tettere de to ulike fagområdene kjenner hverandre, jo enklere og mer naturlig vil de jobbe sammen for å fjerne feil.
  • Feilene skal løses av de som har laget dem. Dersom utviklerne som har laget feilene aldri får se dem, vil de aldri lære.
  • Automatisering av driftsrutinene. Å ha driftsansatte som roterer logger er historie. Nye verktøy som cloud, automatiske tester og utvidet automatisk overvåkning gjør de tradisjonelle driftsansatte overflødige. Den nye driftsansatt er utvikler med et uendelighetsfokus som gjør alt for å bli overflødig.
  • Ikke løs symptomene på feil, men årsakene til dem. Overraskende ofte er årsakene til feilen produktsjefens eller utviklerens manglende kompetanse. Slike feil bør håndteres selv om de er vanskelig å melde inn via Jira. Feil: Inkompetent produktsjef. Løsning: Kurs i brukerforståelse.

Jeg er ikke kritisk til ITIL-verktøykassa, da den inneholder mange gode forslag på hva vi bør gjøre for å jobbe profesjonelt som en driftsavdeling. Jeg er kritisk til de reduksjonistiske implementasjonene av ITIL.

Jeg taler for det grensesprengende kvalitetsprosjektet som ser på hele verdikjeden under ett, og hvor driftsavdelingens arbeidsmetoder er en av mange viktige elementer man må granske før man foreslår en løsning. Vi må forstå helheten og sammenhengene før vi begynner å klå på enkeltelementene.