Einstein jobber ikke her

Jeg husker en tid da feil i databaser ble rettet raskt og effektivt ved at en programmerer gikk inn i basen og endret verdier.

125 kroner ble til 125.000 kroner for eksempel. Direkte, der og da. Uten noen form for logging eller revisjon. Det er lenge siden, men ikke så lenge siden. Det var før ITIL populariserte begrepet Change Management-prosess.

Alle insidenter skjer under produksjon, men det er ikke sikkert at driftsorganisasjonen har skylden.

Ofte ligger problemet hos dem som har levert programmene. Vi må ta utgangspunkt i hele verdikjeden, fra behov til drift. Hver eneste endring i programmer og driftsplattformer innebærer en forretningsrisiko som skal håndteres gjennom en formalisert endringsprosess som vi ofte forkorter til CM. En gammel leveregel sier at i snitt vil hver endret kodelinje innføre minst én feil.

I løpet av de tre siste år har Gartner intervjuet over hundre kilder om dette. Resultatet er summert opp i fem kjerneårsaker til at CM tryner oftere enn godt er. Her kommer de i prioritert rekkefølge, jeg tror du får noen gode tips.

Nummer 1: Verken it-folk eller forretningen er villige til å innse at CM-prosessen er essensielt viktig. Forretningen vil ha det NÅ, de har ingen tid å miste. Det er også en kjent sak at mange it-miljøer aktivt motarbeider innføring av CM-prosesser, de betrakter dem som unødvendig og tidkrevende byråkratisering. De saktner farten. Når det tar 30 sekunder å endre et program, hvorfor bruke mer?

Mange it-folk er vant til å gjøre hva de vil, når de vil. De motarbeider selvfølgelig alt som smaker av kontroll eller overstyring. Det pågår en maktkamp mellom håndverkerne og forvalterne. Det er et paradoks at de som behøver CM mest ofte er de som bruker det minst.

Nummer 2: CM krever endring i atferden. Blant annet må man slutte med å beundre så grenseløst heltene som behersker de tekniske finessene med blendende fingerferdighet, redder alle situasjoner og helst jobber alene. De vet hva de driver med (sier de) og behøver ingen kontroll. Etter Gartners oppfatning er 80 prosent av utfordringen rundt CM å snu kulturen.

Nummer 3: Ulike datasystemer behøver ulik endringshastighet. Noen systemer er så kritiske at endringene må kontrolleres og testes flere ganger under produksjonslignende forhold, men det tar tid. Andre tåler raske endringer selv om det innebærer en viss risiko for at ting går skeis. Noen endringer er akuttilfeller, de må bare gjøres så raskt som mulig, og så rydder man opp etterpå. Å skjære alle situasjoner over én kam er en alvorlig feil. Å balansere endringshastighet og risiko er ikke en beslutning it skal ta. Det er opp til forretningen å finne den rette mixen selv om de ofte har lyst til å snike seg unna ansvaret.

Nummer 4: Det er ofte umulig å etterspore hvem som har gjort endringen. De som nekter å følge CM-prosessen kan derfor ikke oppdages. Synden går ustraffet, ansvaret blir pulverisert. It-ledelsen bør ikke tolerere dette, det er deres forbannede plikt å definere arbeidsopplegg og krav for både egne ansatte og leverandører. Hvis det finnes gode grunner til at en CM-prosess ikke kan etterleves (slik ansatte påstår), er det et problem med prosessen som må utbedres, ikke omgås.

Nummer 5: Ivrige CM-tilhengere ønsker å implementere hele prosesspakken de har pønsket ut, også de mest avanserte funksjonene straks, istedenfor å gå gradvis til verks. Folk orker ikke så mange prosessendringer på en gang, fiasko lurer rundt hjørnet. Å innføre nye prosesser skal være en evolusjon, ikke en revolusjon. Organisasjoner gjør ulike vurderinger av hastighet og risiko etterhvert som tiden går og konkurransesituasjonen endrer seg. Prosesser skal være levende, tilpasningsdyktige organismer, akkurat som datasystemer. De skal aldri bli ferdig.

Som kjent er en god problemdefinisjon halve problemløsningen. Beskrivelsene ovenfor bærer derfor i seg kimen til løsninger. Modne it-ledere innfører målemetoder og terskelverdier for sine viktigste prosesser, for å følge med på hvordan de utvikler seg. Og de ser over sine CM-prosesser flere ganger i året for å oppdage muligheter for forbedringer. Tvillingprosessen til CM, kalt PM (Problem Management) egner seg godt til å holde øye med utviklingen.