Standarder - fordeler og ulemper

DEBATT: Er standardene «det beste vi har, inntil vi får noe bedre», spør Tore Audun Høie.

Publisert Sist oppdatert

Debattinnlegg av Tore Audun Høie, konsulent, og forfatter med fem publiserte bøker om ledelse og teknologi.

Ole Kroknes har et godt og reflektert innlegg om standarder i Computerworld nummer 37, publisert 4. oktober. Hans observasjoner er alle korrekte, nemlig at noen standarder er

  • Selvsagte
  • Kompliserte
  • Overlappende

For eksempel har både ISO 20000 (it-serviceledelse, også kalt ITIL) og ISO 27000 (datasikkerhet) avsnitt om katastrofeplanlegging, som nå heter noe finere. Mitt skjønn er at ISO 20000 er best, og at ISO 27000 kunne henvise, men hvor er folkene som har ledig tid til å gjøre dette?

Datasikkerhet avhenger av god kvalitet som er godt dekket i ISO 20000. Så, til listen ovenfor kan vi tilføye at standardene i dag (og trolig i fremtiden) er:

  • Uferdige

Et eksempel på uferdighet er en standard Kroknes ikke nevner, nemlig ISO 21500 for prosjektledelse. Den forsøker å integrere tidligere standarder som Kroknes har som eksempler.

Men også ISO 21500 har mangler. Den forutsetter at prosjektene er definert, og avgrenset ved start og slutt. I virkeligheten foregår mye viktig arbeid før prosjektet får betegnelsen prosjekt. Man bør også følge opp prosjekter for å finne ut om de var vellykkede, og om andre prosjekter kan lære noe. Over prosjektet ligger styring, hvordan bør man styre en portefølje med prosjekter som kanskje delvis er avhengige? En utvidelse til ISO 21500 arbeider med dette og mer, neste møte er 1. november, og jeg deltar.

Tilbake til det selvsagte. ITIL er kalt en selvsagt standard. Min PhD hadde dette som tema i 1980. Det tok 25 år før det selvsagte ble akseptert i 2005, og fra foreninger og akademia var det sterk motstand. Mange feil er begått fordi driften ikke hadde god nok styring, i 2003 var Den Danske Bank nede i en uke, og måtte låne penger av nasjonalbanken for å drive videre. Problemene i norske banker fortsetter.

En standard utenfor ikt kan illustrere, «Sjekkliste for trygg kirurgi». I følge WHO kan den spare en halv million dødsfall årlig. Hvis vi legger til feil og forsinkelser er dette en ganske god effekt av en liste som egentlig er gratis. Mange pålegg er så innlysende at de kan forstås som en fornærmelse. Eksempler er å bekrefte pasientens identitet (gjentas), merke operasjonsfeltet, sjekke at instrumentene er sterile, telle instrumentene til slutt (så ingen er glemt) og rapportere feil med instrumentene.

Tilbake til ikt, burde ikke Sjekklisten være en premiss for administrativ programvare til sykehus? Kroknes nevner korrekt at ITIL ikke er for utvikling, dette er kanskje en feil? Blant annet utdannes ikke dagens studenter i å lage en vedlikeholdsvennlig arkitektur, så vidt jeg vet. ITIL legger viktige premisser for vedlikehold, inklusive problemstyring, endringsstyring og kapasitetsplanlegging. Dessuten har standarden en sammenhengende metodikk, noe enkelte akademikere har problemer med. Kanskje arkitekturen bør ta hensyn til slike forhold?

For øvrig foreskriver ITIL akseptsjekk når et program skal inn i produksjon (det gjør læreboken til Ian Sommerville også). Hvis utviklerne ikke er forberedt på dette, kan det bli mange strafferunder.

Arkitekturen bør også sørge for at bedriftens verdigrunnlag inkluderes, for eksempel holdningen til ansatte. Hvis ansatte regnes som «ressurser» som skal kommanderes og kontrolleres («command and control»), kan man skrive et gammeldags program. Hvis ansatte er stakeholdere (interessenter) i bedriften, bør de få mulighet for å delta i styre og stell, og da kreves en helt annen type program. En svensk PhD-avhandling hevder at når du kjøper et administrativt program, kjøper du også verdigrunnlaget til leverandøren.

Dårlig arkitektur kan være en grunn til at mange bedrifter sliter med å oppdatere sin portefølje, kanskje særlig innen finans. Finans var i sin tid pionérer, men derfor får de problemene først. Helse har haltet etter i bruk av ikt, men kan få større vedlikeholdsutfordringer enn finans, fordi helse har mer kompliserte utfordringer. Bruk av rammeverk som ITIL kan føre til bedre refleksjon og kanskje bedre langtidsverdi for resultatet. ITIL brukes forøvrig for drift i alle helseregioner, men burde nok sterkere inn også i utviklingsfasen.

En ny standard er kanskje enda viktigere, men jeg har ikke brukt den (bare undervist). ISO 28500 er for IT Governance, altså styring, og den spesifiserer andre standarder som grunnlag. Et mål for ISO 38500 er et godt resultat av ikt-prosjekter. Dette burde (igjen) være selvsagt, det er pinlig for dagens informatikkfag at ISO 38500 er nødvendig.

ISO 38500 kan føre til at man enda en gang tenker igjennom målene med ny programvare. Er et mål effektivisering? Følgespørsmålet er da «effektivisere hva»? I en bedrift kan man effektivisere regnskapet, men regnskapet tjener ikke penger. Bedre vil være å effektivisere produksjon eller salg, men igjen, hva betyr det å effektivisere? Skal selgere selge så raskt som mulig, eller er relasjonsbygging viktig, som Christian Grønroos sier? Er kundetilfredshet en viktig parameter? Hvis ja, bør den kanskje bli en premiss for arkitekturen?

I helse er kanskje valgene enda krassere. Er kvalitet eller penger viktigst? Inntil nylig var penger det viktigste verdimålet, politikerne snakket til stadighet om budsjetter (som de hadde vedtatt). Nå presser kvalitet på som et viktig verdialternativ. Et program beregnet på å spare penger, er temmelig ulikt et som skal hjelpe kvaliteten.

Igjen snakker vi om innlysende ting, men innen helse og finans som jeg kjenner best, ser man ikke alltid det som er innlysende. Å glemme saksen i pasienten er sjelden, men å planlegge en operasjon ufullstendig er dessverre mer vanlig. Finansprogrammer som var beregnet på en del av virkeligheten, eller basert på feil modeller, medvirket til finanskrisen. Viktigere er at intelligente ansatte ikke spurte intelligente spørsmål. Standarder, i hvert fall noen, kan føre til at spørsmålene tas opp, også de som virker dumme.

Kroknes anbefaler en «klartenkt fastlege», et godt begrep som burde bli obligatorisk i ikt-undervisning. En kompetent utenforstående kan stille spørsmål ved «innlysende» premisser, kanskje bedre enn en standard. Personen kan også gi råd om bruk av standarder, med fordeler og ulemper. Men for de mange som ikke liker innblanding, kan standarder være en hjelp, ofte sagt å være «det beste vi har, inntil vi får noe bedre»