ITIL® og alle de nye frameworks - hvad er bedst?

ITIL® som grundlag

(I slutningen af artiklen er der mulighed for at downloade et overblik, der viser ITIL i en sammenligning med de frameworks der nævnes i artiklen)

Sammenligningsgrundlaget for de øvrige frameworks er ITIL, fordi det stadig—og især med ITIL 4—er det bredest dækkende og mest omfangsrige. Oversigten nedenfor over de forskellige, og hvordan deres delelementer passer sammen, viser derfor et ITIL-element som overskrift i tabellen, og den nærmeste pendant fra de øvrige frameworks nedad i alfabetisk rækkefølge. Hvor et element står i parentes er det delvist overlappende eller sammenhængende, men ikke helt. Blanke felter i tabellen er et udtryk for, at det pågældende framework ikke har et element svarende til ITIL-elementet i overskriften. Eventuelle elementer fra andre frameworks, der måtte mangle i ITIL, er udeladt fra oversigten for ikke at komplicere den yderligere. Oversigten omfatter kun de frameworks, der har en relativt bredt dækkende procesmodel på både strategisk, taktisk og operationelt niveau.

ITIL har udviklet sig enormt siden den første version fra 1989, hvor det primært handlede om styring af IT-infrastruktur. I dag er ITIL en fuldt generisk servicemodel, der godt nok stadig har sine rødder i IT, men kan anvendes på en hvilken som helst form for service uanset branche eller målgruppe. Frem til og med opdateringen af version 3 i 2011 beskæftigede ITIL sig med planlægning og design af services, og her idriftsættelse og drift, understøttet af løbende forbedring—men hele udviklingsforløbet, herunder projektledelse, udviklingsmetoder, sammenhæng mellem applikationer og infrastruktur etc., var stort set fraværende. Man designede en service, ventede på, at nogen udviklede den, og så satte man den i drift. Det fremgår også af CSI-modellen fra version 3, at de to nederste trin var "How do we get there?" og "Did we get there?", altså lægge en plan og bagefter evaluere på den, men uden eksplicit at nævne, at planen faktisk også skal føres ud i livet.

Med ITIL 4 fra 2019, har man bevæget sig væk fra den lineære, simplistiske tilgang til services som styret af en række (isolerede) processer og ser mere holistisk ikke bare på en integreret procesmodel, men et helt service-værdisystem. 26 processer er blevet til 34 practices, og discipliner som omverdensanalyse, projektledelse, softwareudviklingsmetoder og arkitektur har fået mere fremtrædende roller. Ser man på oversigten nedenfor fremgår det da også, at omend de øvrige har hver deres fokusområder, er ITIL det framework, der dækker bredest over hele livscyklussen for en servicemodel, og også tager højde for de gensidigt afhængige aspekter, den er omgivet af.

ITIL 4 bygger i højere grad end de tidligere versioner på serviceteori, hvilket har flere implikationer, der måske rækker (langt) ud over, hvad ITIL anvendes til i det daglige rundt omkring i IT-afdelingerne. Der, hvor ITIL 4 adskiller væsentligst fra de øvrige frameworks, er netop de elementer, der omgærder proces- og/eller servicemodellen. ITIL starter med serviceforbrugeren, altså kunden, og de eksterne faktorer, der påvirker og påvirkes af serviceleverandøren. ITIL anerkender eksplicit også, at processer på ingen måde kan stå alene, men er et udtryk for en arbejdsgang, der udføres af nogle mennesker med støtte af teknologi i form af systemer, infrastruktur osv. Disse mennesker kan i øvrigt befinde sig i egen organisation eller eksternt. Først herefter definerer ITIL en egentlig operating model i form af service value chain, som er det tætteste, vi kommer på service lifecycle fra version 3, med processer i hovedsædet.

Komplementære modeller

Der, hvor ITIL kommer lidt til kort, er netop samspillet mellem ovennævnte serviceleverandører—det, man ville kalde upstream i en værdikædesammenhæng—som stadig anses for at være relativt lineært. Virkeligheden er, at stort set alle værdistrømme er indbyrdes og gensidigt afhængige af netværk af mange forskellige aktører, herunder naturligvis leverandører, men også konkurrenter og nye, herunder også komplementære aktører—altså services, produkter og teknologier, der spiller sammen med eller muliggør serviceleverandørens services, produkter og teknologier, men ikke som sådan er direkte konkurrenter eller leverandører—og sidst men ikke mindst selvfølgelig kunderne. I generel ledelsesteori er dette samspil kendt som Michael Porter's 5 Forces, som Andy Grove siden har udvidet til 6 med netop de komplementære aktører som særskilt kategori.

Opmærksomheden på netop samspillet mellem forskellige serviceleverandører, der arbejder for den samme kunde, er steget, ikke mindst med udbredelsen af cloud-services. Her kommer især SIAM og FitSM ind i billedet, når vi taler om begrebet serviceintegration som selvstændig disciplin. Serviceintegration har ofte været misforstået som tekniske integrationer mellem systemer, og den del er da bestemt heller ikke irrelevant; men serviceintegration omfatter hele værdiskabelsen for en (fælles) kunde, som ved en velintegreret (eller velorkestreret) service ikke behøver bekymre sig om, hvilke serviceleverandører der leverer hvilke dele af den samlede service. FitSM står for "Federated ITSM", og her er der netop tale om fødererede services, som leveres af et hvilket som helst antal eksterne leverandører (og interne samarbejdspartnere) i samspil.

ITIL bygger i version 4 i videre udstrækning end tidligere på generel serviceteori, hvor der ikke skelnes mellem kunder og leverandører per se, men blot er tale om aktører, der gensidigt udveksler værdi gennem servicerelationer, et aktivt samspil, altså value co-creation. Brugeren (serviceforbrugeren) er ganske vist den, der får den umiddelbare gavn af servicerelationen, men begge (eller alle) aktører får værdi ud af relationen; ellers ville de ikke indgå i den. I den henseende mister begrebet penge sin betydning, idet penge i og for sig ikke eksisterer eller har nogen iboende værdi, men blot er et udtryk for en målestok for værdiskabelse; et løfte om eller en forpligtelse til en fremtidig servicerelation. Derfor har produkter og varer heller ingen iboende værdi, idet værdi af et produkt, en vare eller en service først kommer til udtryk i brug, ikke ved sin blotte eksistens.

Som eksempel vil en frisør, der ikke har nogen kunder, ikke opleve nogen værdiskabelse (indtjening) blot ved at holde salonen åben. Omvendt vil frisørens kunder ikke opleve nogen værdiskabelse, hvis frisørens services (klipning, farvning etc.) ikke lever op til det ønskede outcome. Tilsvarende tjener et taxiselskab ingen penge, hvis der ikke er nogen kunder, der er villige til at betale minut- eller kilometertaksten for at blive kørt til lufthavnen. Bilen, og de øvrige ressourcer, har ingen iboende værdi. Værdien kommer først til udtryk, når bilen (og chaufføren og kørekortet og vejene etc.) bliver brugt til at transportere en passager til rette destination, til rette ankomsttid—og helst i nogenlunde fysisk og mentalt helskindet tilstand.

VeriSM, der også tænker serviceforbrugeren ind som både indgangspunkt og udgangspunkt, omfatter elementer af governance og styringsprincipper ("service management principles" eller "guardrails", som de kalder det), og forsøger altså at tænke service management ind i en mere helhedsorienteret kontekst, der også tager højde for verden uden for IT-afdelingen. VeriSM går dog ikke særlig meget i dybden med hverken governance eller principperne, men nøjes med at definere begreberne og i øvrigt forklare, at de er unikke og forskellige for hver eneste organisation. Det er der i sig selv ikke noget forkert i, og selv om ITIL heller ikke bruger så mange sider på governance, er anbefalingerne om guiding principles som universelt retningsanvisende anbefalinger både mere konkrete og håndgribelige—omend svære at være uenig i. Hvem ville eksempelvis sige, at man skal spilde ressourcer, gøre tingene mere besværligt end nødvendigt, ignorere forandringer i omverdenen og undgå at samarbejde på tværs af organisatoriske skel? Ikke desto mindre er der stadig meget læring og inspiration at hente ude i organisationerne, alene fra de nuværende syv guiding principles fra ITIL.

COBIT drejer sig ikke om processer så meget som om governance og kontroller, og adskiller governance fra den øvrige management-del. Dette går godt i tråd med principperne for god selskabsledelse (corporate governance), som vi bekender os til i vores del af verden, herunder eksempelvis anbefalingerne fra Komitéen for god selskabsledelse under Erhvervsstyrelsen om bestyrelsens uafhængighed og arbejdsdelingen mellem bestyrelse (governance) og direktion (management). Dette står i kontrast til forholdene i lande som USA, hvor det ikke er ualmindeligt, at én og samme person er både bestyrelsesformand og administrerende direktør på samme tid, og at bestyrelsen i øvrigt helt eller delvist består af medlemmer af virksomhedens øverste daglige ledelse (direktionen eller øverste ledelseslag i øvrigt).

Denne manglende uafhængighed er der mange ulemper ved, både for virksomheden selv og for omverdenen, og nogle af de grelleste eksempler omfatter energiselskabet Enrons sammenbrud (der førte til Sarbanes-Oxley-lovgivningen) i USA og fødevaregiganten Parmalat i Europa. Disse eksempler er af værste skuffe, fordi de omfattede svindel med regnskaber og bestikkelse af den eksterne revision, men problemstillingen kan også have mere internt rettet betydning i form af eksempelvis manglende klarsyn og kritisk stillingtagen til virksomhedens situation og drift eller utilstrækkelige ledelseskompetencer i en sammenblandet bestyrelse og direktion.

...og hvad så?

Alt dette kan virke meget fjernt fra dagligdagen i en IT-afdeling, og med de to ovennævnte undtagelser (VeriSM og COBIT) drejer alle de øvrige frameworks sig da også mestendels om proceselementerne; i nogle tilfælde med specifikt fokus på et eller nogle få områder, i andre tilfælde primært de mere driftsrettede dele som incident, service request, problem, change, release og deployment. Nogle af disse frameworks har en del år på bagen og lader til at være gået lidt i glemmebogen, og er i hvert fald ikke blevet vedligeholdt eller opdateret de senere år; andre udkommer med nogle års mellemrum i nye udgaver eller under nye navne. Det meste lader til at stamme fra den engelsktalende del af verden, omend bl.a. Tyskland og Holland også har bidraget  med egne frameworks.

Sammenhængen mellem COBIT og ITIL kan beskrives på den måde, at COBIT beskæftiger sig mere med governance og compliance, mens ITIL mere fokuserer på service og værdiskabelse. Under governance-laget har COBIT altid drejet sig om kontroller, men med 2019-versionen har man ændret ordlyd og taler nu på modellens laveste abstraktionsniveau om "objectives". Disse målsætninger handler om styring af en lang række discipliner (40 i alt), som i vid udstrækning kan kobles til ITIL's practices. Som det fremgår af oversigten, er COBIT måske også det framework, ud over ITIL, der finder den bredeste anvendelse.

Tvillingeparret ASL og BiSL opstod i årene efter opdateringen af ITIL til version 3 i 2007. Fokus her er mere snævert på hhv. leverandørsiden (Application Services Library) og modtagersiden (Business Information Services Library). Der er hovedvægt på strategi, planlægning og politik, og lidt om governance og maturity, men ingen fuldstændig procesmodel og ikke den store vægt på praktisk anvendelighed og de mere driftsrettede discipliner, der stort set er samlet under ét element, (end) user support. Disse to frameworks er sandsynligvis mest udbredt i Holland, hvor det har sine rødder, og i de senere versioner er nogle af eksaminerne kun tilgængelige på hollandsk.

BRMBOK (Business Relationship Management Body of Knowledge) drejer sig specifikt om business relationship management som disciplin, og organisationen bag, BRM Institute, har udviklet nogle kurser på området for både menige business relationship managers og højere ledelseslag. Her er ITIL også for nylig selv kommet på banen med ikke alene en management practice guide, men en hel bog og et tilhørende 3-dages kursus og certificering, specifikt rettet mod business relationship managers, service delivery managers, key account managers og lignende roller.

CMMI, Capability Maturity Model Integration, har egentlig ikke noget med IT at gøre, men er en metode til at vurdere modenhed i capabilities af enhver art. CMMI er udvidet til at dække forskellige områder, og den meste relevante i nærværende sammenhæng er CMMI for Services (CMMI-SVC), som har 22 procesområder, der også fremgår af oversigten. Igen er der ikke tale om en fyldestgørende procesmodel fra strategisk til operationelt niveau, men det spiller i og for sig heller ikke den store rolle. Styrken i CMMI ligger i fleksibiliteten i modellens anvendelighed, og den har da også givet inspiration til modenhedsmodeller i både COBIT, FitSM, ITIL og flere andre. Omend der har været en del berettiget kritik af disse modenhedsmodeller af, at de skærer alt og alle over én kam, har de fleste nogle fællestræk, bl.a. at modenhedsvurderingen sker på en skala fra 1 til 5, hvor man ikke kan stige til næste niveau, førend alle forudsætninger for det nuværende niveau er opfyldt.

DevOps (en sammentrækning af Development og Operations, udvikling og drift) er egentlig slet ikke et framework, men snarere en filosofi à la Lean, og selvom der bruges mange af de samme begreber—relationship, knowledge, configuration, change, deployment, release, problem, incident og continuous improvement—har DevOps ikke en egentlig procesmodel (og fremgår derfor heller ikke af oversigten), men beskæftiger sig i højere grad med at integrere alle disse discipliner ved at etablere flow, håndtere feedback og skabe et miljø for vedvarende læring og forbedring—akkurat som gengivet i flere af ITIL's guiding principles. DevOps ignorerer ikke processer, men understreger, at værdiskabelse bliver til i et samspil mellem mennesker, processer og teknologi, og lægger vægt på automatisering som vejen til at øge effektiviteten og frigive menneskelige ressourcer til højere formål (akkurat som i Lean).

FitSM er som beskrevet ovenfor et forsøg på at sætte mere fokus på føderering af services, dvs. at tage mere hensyn, end hidtil har været tilfældet i ITIL, til, at (dele af) services kan være leveret af flere forskellige eksterne leverandører eller samarbejdspartnere. Samtidig er FitSM et forsøg på at skære lidt ned på kompleksitetsgraden i ITIL og fokusere på de operationelle dele, der finder hyppigst anvendelse i praksis. Omvendt betyder det, at der er nogle huller eller mangler i procesmodellen (hvilket også fremgår af oversigten), hvor der især mangler dækning på det taktiske niveau omkring projekter, udvikling og styring ud over den daglige afvikling af driften. Den strategiske del, herunder governance-laget, er delvist dækket af en række generelle krav til servicesystemet. Den Europæiske Union anbefaler FitSM som styrings- og procesmodel for offentlige institutioner, og modellen kan da også fint anvendes i det daglige, men vil i modne organisationer komme til kort på en række områder.

ISO/IEC 20000 er ISO-standarden for IT service management. Denne standard blev udviklet til at afspejle "best practice" i ITIL, og mange af begreberne og definitionerne er derfor i vid ustrækning sammenlignelige eller ens. At det er en standard betyder dog, at den stiller nogle krav til, hvad der skal være opfyldt, hvorimod ITIL ikke stiller nogen form for krav, men blot giver anbefalinger. Al erfaring viser, at den slags krav ikke fungerer i praksis, fordi alle organisationer er unikke og har deres egne interne forhold (ressourcer og capabilities), modenhed og udfordringer, markeds- og konkurrencesituation etc., og det er derfor nødvendigt at ”adopt & adapt” som ITIL anbefaler. Procesmodellen i ISO 20000 er—ligesom FitSM, som den har været inspiration til—bredt dækkende, men mangler nogle elementer på det taktiske niveau, og har heller ikke samme dækning af omverdensfaktorer, guiding principles og andre elementer ud over procesmodellen som ITIL.

IT4IT, der blev lanceret i 2015, blev af nogle udråbt som den fjerde version af ITIL, der på det tidspunkt havde nogle år på bagen siden sidste opdatering i 2011. IT4IT er også en standard, som bygger bro mellem ITSM (ITIL) på den ene side og arkitektur på den anden side. The Open Group, der står bag IT4IT, står også bag andre mere hardcore arkitekturmodeller som TOGAF og ArchiMate, der ikke har noget direkte med service management at gøre. IT4IT beskriver et sammenhængende servicesystem med værdistrømme, der bygger på Michael Porter's generiske værdikædemodel (ligesom service value chain i ITIL 4) med kerneaktiviteter fra strategisk til operationelt niveau og en række støttefunktioner (finans, projekt, indkøb etc.) Procesmodellen dækker også relativt bredt, hvis man regner støttefunktionerne med, men overordnet holder IT4IT sig til sit arkitektoniske ophav og giver ikke detaljerede anbefalinger til service management-praksis på samme niveau som ITIL.

Lean IT er en specifik anvendelse af Lean-filosofien i en IT-kontekst. Lean har traditionelt mindst to perspektiver, nemlig fokus på værdi og fokus på spild. Værdiperspektivet siger, at ved at gøre sig klart, hvad der er værdi for kunden, kan alt andet defineres som spild. Starter man omvendt med at definere, identificere og fjerne spild, må alt andet være værdiskabende. (Begge baserer sig på MECE-princippet: Mutually Exclusive, Collectively Exhaustive. Et tredje perspektiv anerkender ikke denne dikotomi, og anser ikke værdi og spild for nødvendigvis at være hinandens modsætninger.) Fokusset i værdiperspektivet på kundeværdi, værdistrømme, flow, pull og perfektion går næsten ordret igen i ITIL's guiding principles og continual improvement-disciplin. Der er ingen egentlig procesmodel, selvom mange af principperne og disciplinerne fra ITIL går igen. Lean i en IT-kontekst er alt for omfangsrigt at beskrive her, men et eksempel er incident management-processen, som stort set udelukkende er et udtryk for spild, idet man afhjælper symptomer på fejl, der kunne have været løst, inden de førte til gene for en kunde eller øvrig modtager af serviceværdi.

SIAM har taget IT-delen ud af navnet og til gengæld indføjet, at der ikke kun er tale om service management, men også integration, af services. Modellen er, sammen med søstermodellen VeriSM, ikke kun målrettet IT-services, men forholder sig efter eget udsagn generisk til enhver form for service, i hvert fald i en organisatorisk kontekst, herunder (men bestemt ikke begrænset til) finans, HR, facilities etc. I princippet er ITIL 4 også en fuldt generisk servicemodel, og alle tre finder da også anvendelse på alle services inden for alle sektorer; det være sig hospitaler, rejseselskaber, banker, fødevarer etc. Hvor SIAM har en bredt dækkende procesmodel, der lægger sig meget op ad ITIL, uden dog at være helt så fyldestgørende, har VeriSM ikke en egentlig procesmodel og beskriver ikke sig selv som et framework, men som en approach, der kobler det bedste af alle verdener i et "management mesh", som beskriver de capabilities, der skal til for at etablere et værdiskabende servicesystem. Der er dog en vis linearitet i VeriSM-modellen fra design og planlægning til drift, og begreber som "issues" og "source events" kan genkendes som det, der i ITIL hedder incidents og problems. Både SIAM og VeriSM udkom i årene mellem ITIL v3 og 4, muligvis for at udfylde et hul i markedet, men efter lanceringen af ITIL 4 i 2019 har der ikke været meget aktivitet.

SRE står for Site Reliability Engineering og er Google's model for styring af deres services. Det er heller ingen bredt dækkende procesmodel i egentlig forstand, men bruger i sagens natur mange af de samme begreber. En stor fejl i ITIL har altid været definitionen af KPI'er som en sammenblanding af målinger, som er et udtryk for en faktisk tilstand—og mål for disse, hvilket derimod udtrykker et ønsket fremtidigt niveau. Måske for at gøre op med denne forvanskning, eller måske blot for at undgå det fortærskede KPI-begreb, bruger SRE i stedet begreberne "service level indicator" (SLI) og "service level objective" (SLO) og skelner således netop mellem indikatoren, altså den nuværende tilstand, og målsætningen. Det fremmeste formål for SRE er at sikre stabilitet i services, der har meget strenge krav til oppetid (availability), og dermed hurtigst muligt at kunne reagere på og inddæmme nedbrud. Som i DevOps er der fokus på forbedring gennem automatisering, og onde tunger kunne finde på at sige, at SRE er opstået, fordi man i DevOps har glemt Ops-delen.

SRE opererer bl.a. med begrebet "error budget", som er den maksimale nedetid, der er tilladt inden for en given måleperiode. Trues målet, sættes udviklingsaktiviteter på pause, og ressourcerne koncentreres i stedet om at sikre stabiliteten og dermed undgå at overskride SLO. Et andet væsentligt begreb i denne sammenhæng, som også kan anskues som en slags erstatning for eller videreudvikling af KPI-regimet og kaskaderede mål (som det også hedder i COBIT) er begrebet OKR, Objectives and Key Results, der kort fortalt er en slags agil tilgang til målinger og målstyring. At gå i detaljer om det er en hel artikel (eller bog) i sig selv, og falder uden for emnet for nærværende artikel.

TRIM (The Rational IT Model) udkom efter ITIL Practitioner, der var en udvidelse af version 3, som blandt andet introducerede hvad der på det tidspunkt var 9 guiding principles (og som bekendt senere blev reduceret til 7 i ITIL 4). Meningen med TRIM var, som flere andre frameworks med variabel succes har forsøgt, at bygge oven på ITIL Foundation og skabe en mere praksisnær tilgang til ITIL, en form for let implementerbar model, som kunne tages for pålydende og implementeres i enhver IT-organisation. Årsagen til, at den slags modeller aldrig har vundet indpas, er givetvis (som nævnt under beskrivelsen af FitSM og ISO 20000 ovenfor), at det ikke kan lade sig gøre at implementere én standardiseret model i mere end én organisation. Da alle organisationer er unikke, er det nødvendigt at tilpasse retningslinjer og anbefalinger til den konkrete situation.

USM, forkortelse for Unified Service Management, er heller ikke en detaljeret procesmodel som sådan, men har til gengæld den store styrke, at den er opbygget modulært af kun 5 grundlæggende byggesten—agree, change, recover, operate og improve—som tilsammen kan kombineres til enhver given proces fra ITIL, COBIT, ISO 20000 osv. USM opererer også udfra MECE-begrebet, altså at der ikke må være overlap mellem forskellige processer, og at der heller ikke må være noget udeladt, der "falder mellem to stole". USM fokuserer specifikt på procesdimensionen ("what") og udelukker således mennesker ("who") og teknologi ("how")—hvilket tilsammen udgør det, der i ITIL 4 hedder en practice. Processer i USM sammensættes i workflows (tilsvarende value streams i ITIL 4), og procesmodellen i USM kan således ekspanderes ud i alle permutationer af delelementerne af de 5 grundsten, men omfatter i praksis 8 workflows, der er fyldestgørende for et effektivt management-system.

USMBOK, Universal Service Management Body of Knowledge, ikke at forveksle med USM, er en samling af principper, praksisser, koncepter, processer og aktiviteter til styring af IT-services. Modellen er udviklet af en amerikaner, muligvis også som et forsøg på at gøre anbefalingerne fra ITIL nemmere at implementere, og med det erklærede formål at anlægge et mere udefrakommende, kundecentreret perspektiv end den traditionelle ITSM-tankegang. Der har pågået en strid om rettighederne til navnet USM, men USMBOK lader ikke til at have rørt på sig i de senere år. Som med flere af de andre frameworks mangler den især fylde på det taktiske niveau, hvilket også ses af oversigten, og er her mest taget med for fuldstændighedens skyld.

YaSM, yet another service management model, er, som navnet med en vis ironi antyder, netop endnu en service management-model, som prøver ikke at være det. Procesmodellen lægger sig tæt op ad ITIL  og ISO 20000, og som flere af de andre modeller forsøger YaSM at gøre anbefalingerne fra ITIL mere lettilgængelige og nemmere at implementere, blandt andet ved at beskrive en række detaljerede aktiviteter, input og output for hver proces, og at skabe en generisk service management-model, der ikke er bundet op specifikt på IT-services.

Konklusion

En forhenværende kollega sagde for år tilbage, at der altid er noget at hente i nye modeller, der kommer på markedet, og hver især har alle de ovenstående—og alle dem, der ikke er nævnt her—en erklæret hensigt om at gøre verden til et bedre sted ved at stille en simpel, lettilgængelig og let implementerbar model til rådighed til at styre planlægning, udvikling, ibrugtagning, leverance og forbedring af services af en enhver art.

Alle gode hensigter til trods forbliver dog ITIL, i sin nuværende fjerde udgave, den bredest dækkende og mest omfattende servicemodel, der ikke kun fokuserer på processer, men på hele service-værdisystemet med governance, forholdet til omverdenen og "best management practice" beskrevet som samspillet mellem mennesker processer og teknologi.

Det ville være enormt værdifuldt for alle organisationer, hvis der fandtes en model, der 1:1 kunne implementeres i enhver tænkelig organisatorisk sammenhæng, uanset branche, konkurrencesituation, samfund etc., men sådan en model kan ikke eksistere. Det nærmeste, vi kommer på at skabe forbedring i en kompleks verden er ikke at fastlægge forhåndsdefinerede standarder for enhver tænkelig situation, men at udstikke retningslinjer og vejledning til, hvad der er vigtigt at holde sig for øje, efterhånden som virkeligheden udspiller sig.

Som Captain Barbossa siger i Pirates of the Caribbean: "The Code is more what you'd call guidelines than actual rules!"