Implementatie IT Service Management “Slagingskans, slechts 10%”
Paper t.b.v. de module VMT – MIM04 Versie 1.0 © 2002 – J.R.M. Belt
Inhoud 1
VOORWOORD ........................................................................................................3
2
INLEIDING...............................................................................................................4
3
CASE: CHANGE MANAGEMENT OF ICT SERVICE MANAGEMENT? ...............5 3.1 3.2 3.3
4
SLAGINGSKANS, SLECHTS 10%. WAAROM?....................................................8 4.1 4.2 4.3 4.4 4.5 4.6
5
URGENTIEBESEF VESTIGEN .................................................................................8 DE LEIDENDE COALITIE VORMEN ..........................................................................9 EEN VISIE EN STRATEGIE ONTWIKKELEN ..............................................................9 DE VERANDERINGSVISIE COMMUNICEREN ..........................................................10 DOOR ‘EMPOWERMENT’ EEN BREED DRAAGVLAK VOOR ACTIE CREËREN .............10 DE LAATSTE DRIE FASEN ...................................................................................11
HET ACHTFASENPROCES .................................................................................12 5.1
6
ITIL EN ICT SERVICE MANAGEMENT ...................................................................5 DE ORGANISATIE ................................................................................................5 DE PROJECTSCOPE ............................................................................................6
BEREKENING VAN DE SLAGINGSKANS VAN HET PROJECT ....................................13
KOTTER VERSUS SCHILT ..................................................................................14 6.1 6.2
DUURZAAM INRICHTEN VAN WERKPROCESSEN ...................................................14 NOODZAAK: WAAR MOETEN WE AAN WERKEN?..................................................15
7
CONCLUSIE EN ADVIES .....................................................................................17
8
NAWOORD ...........................................................................................................18
9
LITERATUURLIJST ..............................................................................................19
10 LIJST MET FIGUREN EN TABELLEN .................................................................20 10.1 10.2
FIGUREN ......................................................................................................20 TABELLEN .....................................................................................................20
11 BIJLAGE: ITIL, DE SERVICE SUPPORT EN DELIVERY SET............................21 11.1 DE SERVICE SUPPORT SET ...........................................................................21 11.1.1 Configuration Management ................................................................................ 21 11.1.2 Incident Management.......................................................................................... 21 11.1.3 Problem Management ......................................................................................... 21 11.1.4 Change Management .......................................................................................... 21 11.1.5 Release Management .......................................................................................... 21 11.2 DE SERVICE DELIVERY SET ...........................................................................21 11.2.1 Service Level Management ................................................................................. 21 11.2.2 Availability Management .................................................................................... 22 11.2.3 Capacity Management ........................................................................................ 22 11.2.4 IT Service Continuity Management..................................................................... 22 11.2.5 Financial Management ....................................................................................... 22
2
1 Voorwoord De titel “Implementatie IT Service Management”, met als ondertitel “Slagingskans, slecht 10%” is gekozen vanwege een ‘mislukt’ project bij een ICT organisatie van een grote bancaire onderneming. Destijds heb ik dit project mogen leiden en was er, ondanks de meningen van anderen, vast van overtuigd dat het project wel degelijk een veel grotere slagingskans had. De foto op de titelpagina (Allen Luong) geeft enigszins weer hoe ik destijds dit project ben ‘ingegaan’. Teveel de focus op het doel, in plaats van hoe het doel te bereiken. Destijds had ik nog nooit van John P. Kotter gehoord, en zijn boek “Leiderschap bij verandering” dus nog niet gelezen. Was dit wel het geval geweest, dan is het nog niet zeker of de slagingskans van het project groter geweest zou zijn. Wel had ik een handvat gehad om op basis van de fouten die gemaakt kunnen worden, zoals door Kotter beschreven in deel I van zijn boek, het project een andere wending te geven. Ook had ik een handvat gehad om te beslissen of het project wel of niet van start had moeten gaan. Gedane zaken nemen echter geen keer, maar zaak is het om op basis van in het verleden gemaakte fouten te leren, om in de toekomst dergelijke valkuilen te vermijden. J.R.M. Belt Oss, 27 juni 2002
3
2 Inleiding Kotter beschrijft in deel I in zijn boek “Leiderschap bij verandering” waarom ondernemingen falen bij een transformatieproces van de organisatie. Als eerste wordt dan ook een case beschreven van de situatie zoals deze was voor de start van het project. Hierbij wordt aandacht geschonken aan de organisatiestructuur zoals deze werd aangetroffen, en wordt de doelstelling van het project toegelicht. Belangrijk hierbij is dat de initiële doelstelling een andere was dan de doelstelling in het verloop van het project. Verder wordt een korte beschrijving gegeven van de fouten die, volgens Kotter, gemaakt worden waardoor ondernemingen falen bij dergelijke transformaties binnen de organisatie. Hierbij zal een link gelegd worden naar de beschreven case, en waar de fouten, zoals Kotter deze beschrijft, gemaakt zijn in dit project. Vervolgens wordt aan de hand van het achtfasenproces, zoals in deel II is beschreven, getoetst hoe het project wel succesvol had kunnen worden doorgevoerd, of dat gezegd had moeten worden: “Dit project zal in deze vorm, en in deze context niet slagen.” Daarnaast wordt gekeken hoe volgens Jan Schilt, de schrijver van het boek “Procesverbetering in ICT Service Management” projecten meer succesvol aangepakt kunnen worden. In dit boek wordt namelijk beschreven hoe procesverbetering als een leerproces gebruikt dient te worden dat leidt tot het ontwikkelen van kennis en vaardigheden die (her-)gebruikt kunnen worden bij het inrichten en verbeteren van werkprocessen. Voor dit boek is gekozen omdat het project destijds was toegespitst op het invoeren van ITIL processen. Kotter beschrijft namelijk alleen een ‘generieke’ aanpak voor projecten in het algemeen. Schilt heeft zich gespecialiseerd in het ‘lerend’ implementeren van ICT Service Management. Tot slot worden Kotter en Schilt met elkaar vergeleken en worden verbanden aangetoond tussen de aanpak van beide auteurs. In het hoofdstuk “Conclusie en Advies” beschreven hoe met behulp van beide boeken een dergelijk project voortaan wel succesvol gestart kan worden, of dat toch de vraag moet worden gesteld: “Is dit project wel levensvatbaar”, en wellicht niet moet worden gestart.
4
3 Case: Change Management of ICT Service Management? De ICT afdeling van een grote bancaire organisatie had behoefte aan de invulling van Change Management volgens ITIL. Het advies wat destijds werd gegeven was om niet alleen Change Management te implementeren, maar om te kiezen voor meer processen, o.a.: • • • •
Configuration Management Incident Management Problem Management, en Change Management
Op deze wijze zou binnen de organisatie ICT Service Management gewaarborgd worden, wat het beheer van de operationele omgeving alleen maar ten goede zou komen. Om de begrippen ITIL en ICT Service Management toe te lichten, worden deze in de navolgende paragraaf kort beschreven. In de twee daarop volgende paragrafen komen de organisatievorm en de projectscope aan bod.
3.1
ITIL en ICT Service Management
In de tachtiger jaren was binnen de Britse overheid de kwaliteit van de dienstverlening op ICT gebied van een dusdanig niveau, dat de CCTA (Central Computer and Telecommunications Agency) de opdracht kreeg om een aanpak te ontwikkelen voor een meer efficiënte en meer economische inzet van IT middelen binnen de Britse overheid. Het resultaat van deze opdracht is gedocumenteerd in de ‘Information Technology Infrastructure Library’. ITIL is dan ook een verzameling van ‘Best Practices’ die in het werkveld van ICT beheer werd aangetroffen. Binnen ITIL is er sprake van een Service Support set en een Service Delivery set. De Support set behelst de operationele processen en de Delivery set bevind zich meer op het snijvlak van de tactische en de strategische processen. Tabel 1: ITIL Processen
Service Support set
Service Delivery set
Configuration Management Incident Management Problem Management Change Management Release Management
Availability Management Capacity Management IT Service Continuity Management Financial Management Service Level Management
Het begrip ICT Service Management behelst het geheel van alle ITIL processen welke binnen een ICT organisatie geïmplementeerd kunnen worden teneinde de ICT dienstverlening zo optimaal mogelijk te kunnen benutten. Voor een meer gedetailleerde beschrijving per proces wordt verwezen naar de bijlage ‘ITIL, de Service Support en Delivery set’.
3.2
De organisatie
De ICT organisatie bestond (destijds) uit een tweetal afdelingen – Infrastructure en Business Applications – met ieder een verantwoordelijk ICT manager. Beide managers legden verantwoording af aan een General Manager, welke verantwoordelijk was voor de organisatie in zijn geheel. In totaal bestond de organisatie uit zo’n 35 medewerkers. Drie medewerkers waren in dienst van de organisatie (de twee ICT managers en de General Manager) en de overige medewerkers waren ingehuurd personeel.
5
Het hoofdkantoor van de organisatie is (tot op heden nog steeds) gevestigd in Utrecht, alwaar tevens de ICT Manager Business Applications kantoor hield. De ICT Manager Infrastructure had zijn zetel in Brussel. Verder waren de diverse medewerkers voor beide afdelingen over de twee locaties verspreid. De afdeling Business Applications had de verantwoording over alle applicaties, zowel bedrijfskritische als ondersteunende. De afdeling Infrastructure was verantwoordelijk voor de gehele ICT infrastructuur. De verantwoording behelsde zowel toekomstige ontwikkelingen als de huidige operationele ondersteuning.
3.3
De projectscope
Het initiële doel van het project was om het Change Management proces binnen de organisatie te beschrijven en te implementeren. Er was binnen de organisatie namelijk behoefte om wijzigingen in de ICT infrastructuur gecontroleerd en gestructureerd door te voeren. Na enkele gesprekken met het management van de afdeling, bleek echter al snel dat ook andere processen de nodige aandacht verdienden. Immers, om wijzigingen goed te kunnen doorvoeren, moet men exact weten over welke ICT infrastructuur men dan praat. Indien er dan eenmaal wijzigingen zijn doorgevoerd, wil men ook nog de incidenten die hieruit voortvloeien, zo snel mogelijk kunnen oplossen. Vervolgens is het zaak om na uitvoerige analyse deze incidenten structureel op te lossen, opdat deze niet meer zullen voorkomen. Hier komen zowel Incident, als Problem Management om de hoek kijken. Om een en ander op basis van gedegen informatie betreffende de ICT infrastructuur te kunnen analyseren werd geadviseerd om ook Configuration Management in het project te betrekken. Change Management werd gezien als hét ondersteunende ITIL proces wat voor deze organisatie van belang was. Het Change Management proces draagt de verantwoording om wijzigingen op de ICT infrastructuur gecontroleerd door te voeren, met als belangrijk kenmerk, dat dit geen nieuwe incidenten – of tot een minimum beperkt – tot gevolg mag hebben. Om duidelijk te maken waarom de scope breder gezien moest worden dan alleen het voorgaande proces, en hiervoor commitment bij het management te verkrijgen werden onderstaande punten in het advies betrokken. •
Het Problem Management proces is van belang om na uitvoerige analyse van alle reeds opgetreden incidenten, voorstellen te doen tot verbetering van de ICT infrastructuur. Deze worden dan middels een Request for Change (RfC) aangeboden aan het Change Management proces, met als doel om deze structurele wijzigingen door te voeren teneinde het aantal incidenten te verminderen.
•
Incident Management draagt zorg voor het snel en correct afhandelen van opgetreden incidenten. Tevens dient dit proces informatie te verschaffen aan Problem Management, opdat een uitvoerige analyse van opgetreden incidenten mogelijk is, om zodoende verbetervoorstellen aan Change Management te kunnen aanbieden.
•
Configuration Management is het proces waarbinnen is gewaarborgd dat alle informatie over de ICT infrastructuur, welke in voorgaande processen nodig is, op juistheid is gecontroleerd en geregistreerd. Binnen dit proces zijn namelijk alle relaties van alle ICT componenten geïnventariseerd.
6
Besloten werd aldus om niet één proces – Change Management – te implementeren, maar een viertal processen tegelijkertijd, namelijk: • • • •
Configuration Management Incident Management Problem Management, en Change Management
Daarbij werd tevens nog besloten dat dit ondersteund moest worden middels een Service Management tool. Daartoe werd binnen de projectscope ook nog een selectietraject ingepast, teneinde een goed werkend (ICT-) hulpmiddel te selecteren. Al deze zaken werden door het advies dat geschreven was, mede op basis van voorgaande informatie, vrij snel geaccordeerd, zonder stil te staan bij de feitelijke vorm van de organisatie, invloeden, afhankelijkheden, eventuele problemen en risico’s.
7
4 Slagingskans, slechts 10%. Waarom? Nadat het Plan van Aanpak was geschreven, is het ter beoordeling voorgelegd aan een tweetal onafhankelijke specialisten op het gebied van ITIL processen en de implementatie daarvan. Beide kwamen eigenlijk tot de conclusie dat dit project, in deze vorm en opzet, nauwelijks kans van slagen had. Maximaal 10% was een harde uitspraak die beide specialisten deden. Mede door het geloof in eigen kunnen, en de overtuiging dat, met enige bijsturing, dit project wel zeker kans van slagen had, werd toch een aanvang gemaakt met het project. Zeven maanden later echter, moest de conclusie getrokken worden dat dit project bij deze organisatie inderdaad een zeer geringe slagingskans had. Wellicht zelfs nog minder dan 10%. Kotter stelt zichzelf in deel I van zijn boek de vraag waarom ondernemingen falen bij het doorvoeren van transformaties in de organisatie. Hij reikt de lezer hiertoe een achttal fouten aan welke – op basis van zijn ervaringen – doorgaans worden gemaakt: 1. 2. 3. 4. 5. 6. 7. 8.
Teveel zelfgenoegzaamheid toelaten Nalaten een voldoende krachtige leidende coalitie te vormen De kracht van de visie onderschatten De visie 10 (of 100 of zelfs 1000) keer te weinig communiceren Toelaten dat obstakels de nieuwe visie in de weg staan Nalaten kortetermijnsuccessen te creëren Te vroeg juichen Verzuimen om veranderingen stevig te verankeren in de organisatiecultuur
In dit hoofdstuk zal dan ook aan de hand van het achtfasenproces, zoals door Kotter is beschreven, verklaard worden op welke punten het misging.
4.1
Urgentiebesef vestigen
(…) In persoonlijke gesprekken met medewerkers geeft iedereen grif toe dat er problemen zijn. Dan komen de ‘maren’. Maar de gehele branche heeft deze problemen. Maar we boeken echt enige vooruitgang. Maar het probleem zit niet hier, het zit daar op die afdeling. Maar ik kan er verder niets aan doen vanwege mijn stomme baas. (…) Ik heb topmanagers ontelbare keren horen beweren dat alle mensen in hun managementteam de noodzaak van ingrijpende wijzigingen inzien. Vervolgens kwam ik er zelf achter dat de helft van het ‘team’ vindt dat de status-quo eigenlijk nog zo slecht niet is. In het openbaar praten ze hun baas wel na, maar onder vier ogen krijg ik een ander verhaal te horen. (…) Bron: John P. Kotter, Leiderschap bij verandering
Kijkend naar de ICT organisatie kan gesteld worden dat bovenstaand gegeven daar zeker opgeld deed. Wanneer iedereen bij elkaar in een meeting sprak over de in te voeren processen, was men er het allemaal over eens dat dit zeker moest gebeuren en een goed plan was. Sprekende met de mensen onder vier ogen, bleek echter dat het urgentiebesef van bijvoorbeeld Configuration Managent niet echt hoog was. “We hebben toch tools genoeg om de ICT infrastructuur te inventariseren. Volgens mij is een CMDB (Configuration Management Database) eigenlijk helemaal niet noodzakelijk. Het brengt ook nog eens een hoop administratief werk met zich mee en daar zit ik niet op te wachten.” Gesprekken met de verantwoordelijke managers welke de opdracht tot de ITIL implementatie hadden gegeven, brachten echter een ander beeld naar voren. Iedereen was het er inderdaad over eens dat met name Configuration Management zeer belangrijk was. 8
4.2
De leidende coalitie vormen
Het tweede punt waar het in het project op misging is de leidende coalitie. Zoals Kotter beschrijft hoe een goede leidende coalitie gevormd kan worden, bestond deze in het geheel niet binnen het project. (…) Vergeet nooit dat een leidende coalitie die alleen uit managers bestaat – zelfs voortreffelijke managers die prima mensen zijn – tot gevolg zal hebben dat ingrijpende veranderingsprojecten mislukken. (…) Twee soorten mensen moeten koste wat kost vermeden worden bij het samenstellen van een leidende coalitie. De eerste soort zijn mensen met een levensgroot ego die andere mensen geen ruimte laten. De tweede soort bestaat uit wat ik stokers noem, mensen die genoeg wantrouwen zaaien om teamwerk om zeep te helpen. (…) Bron: John P. Kotter, Leiderschap bij verandering
De leidende coalitie binnen het project bestond uit louter managers. Volgens Kotter dus reden genoeg om een mislukking te garanderen. Daarbij komt nog dat er specifiek één manager aanwezig was binnen de leidende coalitie met inderdaad een behoorlijk groot ego. Kenmerkend waren bijvoorbeeld uitspraken als “Ik ben verantwoordelijk voor een goed verloop van dit project, dus ik heb het laatste woord als er een beslissing genomen moet worden”, of “Waarom zouden de ‘externen’ inspraak moeten hebben? Zij moeten gewoon doen waarvoor zij zijn ingehuurd en niet zeuren.” Zoals eerder is beschreven bestond, buiten de drie managers van de organisatie zelf, het team verder geheel uit ‘externen’. Ongeveer 32 mensen waren dus ingehuurd en mochten vooral niet meedenken. Immers, ze zouden het bedrijf toch spoedig weer verlaten. Binnen het project is zeker een aantal keer uitgesproken dat het aantal ‘externen’ niet in verhouding stond tegenover het aantal mensen in vaste dienst. Dit werd dan gepareerd met de opmerking dat hier nou eenmaal voor gekozen was. Eénmaal is zelfs de opmerking geplaatst dat het niet eens zeker was of de ICT organisatie met de huidige structuur nog lang zou bestaan.
4.3
Een visie en strategie ontwikkelen
Volgens Kotter voldoet een effectieve visie aan tenminste zes kenmerken: •
Voorstelbaar: draagt een beeld over van hoe de toekomst eruit zal zien.
•
Aantrekkelijk: spreekt de langetermijnbelangen aan van medewerkers, klanten, aandeelhouders, en anderen die een belang in de onderneming hebben.
•
Haalbaar: omvat realistische, bereikbare doelen.
•
Gericht: is duidelijk genoeg om als richtsnoer te dienen bij besluitvorming
•
Flexibel: is algemeen genoeg om individueel initiatief en alternatieve reacties toe te laten in het licht van veranderende omstandigheden
•
Communiceerbaar: is gemakkelijk te communiceren, kan binnen vijf minuten uitgelegd en begrepen worden.
Zoals uit de vorige paragraaf bleek, was het voor de ICT organisatie in zijn geheel niet duidelijk hoe de toekomst er uit zou zien. Er werd achteraf bezien niet gekeken naar de langetermijnbelangen van bijvoorbeeld medewerkers – deze waren immers voornamelijk ingehuurd, en hadden in de optiek van het management dus geen belangen – en (interne) klanten. Deze klanten werden zelfs in het geheel niet betrokken bij het project. Door de gestelde deadlines waren deze zeker niet realistisch en bereikbaar. 9
Dit komt mede door het feit dat dergelijke processen goed gewaarborgd moeten worden in de organisatie, de mensen dus die het werk moeten uitvoeren. Ook hier speelt weer mee dat het leeuwendeel van de medewerkers ingehuurd waren en op korte termijn het bedrijf zouden verlaten. Het personeelsverloop onder hen bedroeg zo’n 26% op jaarbasis. Daarnaast was het project zeker niet flexibel te noemen maar eerder star en strak geregeld. Er waren nauwelijks mogelijkheden aanwezig om het project op basis van nieuwe inzichten bij te sturen. Was een beslissing eenmaal genomen, dan bleef dat zo.
4.4
De veranderingsvisie communiceren
Binnen de ICT organisatie zelf was er sprake van communicatie, hetzij dat dit voornamelijk was op basis van besluiten die door de twee afdelingsmanagers waren genomen. Binnen de afdeling Infrastructure in Brussel was zelfs nog een opmerkelijk punt aan de orde, het hiërarchieke aspect. Goede ideeën te over, echter, zij zouden nooit doorgang vinden als ‘de baas’ dat niet goed vond. De andere manager had overigens de idee dat communicatie naar de rest van de onderneming pas in een later stadium van belang zou zijn, namelijk, als het project succesvol was doorgevoerd. Pas dan zou er breed gecommuniceerd worden naar bijvoorbeeld de interne klanten. Men zag niet de noodzaak in om dit vroegtijdig op te starten. Dit was mede in gegeven doordat dergelijke projecten in een vorige periode, volgens het ICT management, al een tweetal keren eerder waren mislukt.
4.5
Door ‘empowerment’ een breed draagvlak voor actie creëren
Kotter vangt in hoofdstuk 7 aan met een stukje over een manager die het woord ‘empowerment’ niet meer kan aanhoren. Binnen ICT Service Management implementaties wordt meer gesproken over ‘awareness’. Beide woorden verschillen niet zoveel van elkaar en hebben eigenlijk dezelfde strekking; een breed draagvlak creëren voor de beoogde verandering binnen de organisatie.
Figuur 1: Barrières voor 'empowerment' Bron : John P. Kotter – Leiderschap bij verandering
Zoals al uit vorige paragrafen gebleken is, is het niet verwonderlijk dat er binnen dit project nauwelijks sprake kon zijn van ‘awareness’ of ‘empowerment’. Kijkend naar voorgaande figuur, kan gesteld worden dat de formele structuur het handelen moeilijk maakte. Echt ontmoedigen was niet aan de orde door bazen, van meewerken en het nut inzien van de verandering ook niet. Alle medewerkers bezien, behalve de projectleider en de programmamanager, was er ook geen sprake van vaardigheden welke nodig zijn. 10
De allergrootste barrière echter was dat medewerkers zeker de visie begrepen, sommigen hem zelfs wilden verwezenlijken, maar geen van allen kon echter de goede kant op door de eerder beschreven verhoudingen van in- en externen binnen de ICT organisatie. Empowerment binnen de rest van de organisatie – alle interne klanten – was zelfs in het geheel niet aan de orde. Men wist feitelijk domweg niet dat een dergelijk project ter verbetering voor wat betreft het operationele beheer van de ICT dienstverlening gestart was. Hierover was niet gecommuniceerd dus hoe moest men empowerd raken?
4.6
De laatste drie fasen
De laatste drie fasen die Kotter beschrijft zijn: • • •
Kortetermijnsuccessen genereren Verbeteringen consolideren en meer verandering tot stand brengen Nieuwe benaderingen in de organisatiecultuur verankeren
Doordat aan de eerste vijf fasen niet voldaan werd, en het feit dat het project na zes maanden (de eerste maand betrof een analyse van de situatie, binnen de resterende zes maanden moest het project voltooid zijn), werd overgedragen aan een projectleider die het geheel een andere wending moest geven, kan er niet worden ingegaan op de drie laatste fasen die Kotter beschrijft in relatie tot het project. Algemeen kan wel worden gesteld dat er in het initiële project geen korte termijn successen waren gedefinieerd. De processen moesten worden ingericht, worden beschreven en op een bepaalde datum geïmplementeerd zijn. Tussentijdse mijlpalen waren daarbij van ondergeschikt belang omdat de tijd hiervoor te kort was. Althans, dat was de mening van het management die de opdracht had gegeven. Verbeteringen consolideren en meer verandering tot stand brengen zullen naar alle waarschijnlijkheid ook niet hebben plaatsgevonden. Evenmin zullen nieuwe benaderingen niet in de organisatiecultuur verankerd zijn. Het is gevaarlijk om dit zo te stellen en het betreft hier dan ook een aanname die is gebaseerd op de non-resultaten uit de vijf voorgaande fasen, zoals deze beschreven zijn in de voorgaande paragrafen.
11
5 Het achtfasenproces Aan de hand van onderstaand model, en de beschrijving van verloop van het project in het vorige hoofdstuk zien we dat punt 1 en 2 zonder meer zijn overgeslagen. Binnen punt 3 is er wel een visie ontwikkeld, echter deze was dermate beperkt dat er geen breed draagvlak voor kon zijn.
Figuur 2: Het achtfasenproces voor ingrijpende verandering Bron: John P. Kotter – Leiderschap bij verandering
12
Communicatie (fase 4) betrof alleen de eigen ICT organisatie, en een breed draagvlak was niet of nauwelijks aanwezig. Zoals Kotter in zijn boek stelt dat ‘empowerment’ (fase 5) een vereiste is om veranderingen succesvol te kunnen doorvoeren, zo is binnen procesverbeteringen gericht op ICT Service Management ‘awareness’ de grote onmisbare schakel. Voor wat betreft de overige drie punten binnen het achtfasenproces, hieraan is binnen het project, zoals beschreven in de paper, helemaal geen aandacht aan geschonken. Zoals Kotter stelt in zijn boek is het juist van belang om geen enkele stap over te slaan of zelfs weg te laten. Door één of meer inleidende activiteiten weg te laten of deels uit te voeren, is er zelden een goede basis tot stand te brengen om hierop voor te bouwen. Laat men stappen weg in de afsluitende fase (stap 7 en 8), zal zeer waarschijnlijk de finish niet gehaald worden, althans, niet zonder problemen en teleurstellingen. Veranderingen worden niet gewaarborgd en verankerd en zullen dus sneller verwateren of zelfs helemaal geen doorgang vinden.
5.1
Berekening van de slagingskans van het project
Op bladzijde 36 van het boek ‘Leiderschap bij verandering’ beschrijf Kotter het belang van de volgorde van het achtfasenproces. Het is niet zo dat elke fase eerst voor honderd procent moet zijn afgerond alvorens aan een nieuwe fase te beginnen. Wel is het zaak om geen fasen over te slaan. Iedere fase volgt logisch op de andere en wanneer dus een fase zou worden overgeslagen, mist men de basis voor de fase waar men zich dat moment in bevindt. Uitgaande van alle twintig stappen binnen het achtfasenproces (zie figuur ‘Het achtfasenproces voor ingrijpende verandering), wordt aangenomen dat alle stappen even belangrijk zijn. Dit betekent dus dat iedere stap 5% vertegenwoordigd als aandeel voor een succesvolle implementatie van ICT Service Management binnen de organisatie. Kijken we dan naar het project zoals beschreven in de paper ontstaat het volgende rekenmodel: Tabel 2: Berekening slagingskans
Fase 1. Urgentiebesef vestigen 2. De leidende coalitie vormen 3. Een visie en strategie ontwikkelen 4. De veranderingsvisie communiceren 5. Door ‘empowerment’ een breed draagvlak voor actie creëren 6. Kortetermijnsuccessen genereren 7. Verbeteringen consolideren en meer verandering tot stand brengen 8 .Nieuwe benaderingen in de organisatiecultuur verankeren Totaal
Waarde
Score
10% 10% 10% 10% 15% 15% 15% 15% 100%
0% 0% 5% 5% 0% 0% 0% 0% 10%
Voorop staat dat dit rekenmodel niet gebaseerd is op toetsing in de praktijk. Ook is niet bekend of elke activiteit binnen een fase even zwaar gewogen moet worden, hierover doet Kotter namelijk geen uitspraak. Daarom is de aanname gedaan dat alle activiteiten binnen de acht fasen uitgevoerd moeten worden en geen der activiteiten of fasen mogen worden overgeslagen. Tevens is van belang dat de volgorde niet wordt gewijzigd. Wel kan het zo zijn dat men binnen een bepaalde fase voor bijvoorbeeld 80% klaar is, en alvast met de volgende fase begint. Het project had dus inderdaad maar een slagingskans van 10.
13
6 Kotter versus Schilt Omdat het project zich richtte op het implementeren van ITIL processen is het naast de aanpak van Kotter van belang om ook eens te kijken naar de literatuur op dit specifieke gebied. Het implementeren van een informatiesysteem verschilt namelijk nogal wezenlijk van het implementeren van ondersteunende werkprocessen. Bij een informatiesysteem is er op het einde van het project doorgaans iets tastbaars wat wordt opgeleverd, bij ITIL is dat in mindere mate het geval. Men spreekt hier namelijk over een manier van werken, iets wat moet ‘inslijten’, en niet op een bepaald moment kan worden opgeleverd. Daarom is ervoor gekozen in het kader van de paper om ook het boek ‘Procesverbetering in ICT Service Management’ van Jan Schilt te spiegelen aan de aanpak van Kotter. Jan Schilt ontwikkelde als trainer/consultant van ISES International de aanpak welke beschreven is zijn boek. Hij richt zich hierbij op het duurzaam inrichten van ICT Service Management processen, kortweg ITIL. Aan bod komen de essenties van hoofdstuk 2 ‘Duurzaam inrichten van werkprocessen’ en hoofdstuk 3 ‘Noodzaak: Waar moeten we aan werken?’. De overige hoofdstukken gaan dieper in op hoe de aanpak dan gehanteerd moet worden en blijven verder buiten beschouwing.
6.1
Duurzaam inrichten van werkprocessen
Schilt stelt dat het duurzaam inrichten van werkprocessen alleen dan succesvol zal zijn als mensen in staat zijn om te leren. Verder hanteert Schilt bij het lerend veranderen de leercirkel van Kolb.
Figuur 3: Leercirkel van Kolb
In hun dagelijkse werkzaamheden verrichten mensen op bijvoorbeeld een ICT afdeling activiteiten om storingen op te lossen (DOEN). Heeft men dit werk goed gedaan? Gaat dit snel genoeg en heeft iemand er voldoende kennis van (BEZINNEN)? Daarna zal men beseffen dat de kennis wellicht nog verbetering behoeft en zoekt men naar mogelijkheden om de storingen nog sneller op te lossen (DENKEN). Tot slot vindt de betreffende medewerker een artikel waardoor hij inderdaad sneller incidenten kan afhandelen en besluit dit voortaan op de nieuwe manier te doen (BESLISSEN). Hiermee is de cirkel rond want ook bij de nieuwe manier van werken gaat men DOEN, om vervolgens te BEZINNEN, te DENKEN of dit nog beter kan, etc… 14
Daarnaast beschrijft de auteur ontwerpprincipes om de veranderingen succesvol tot stand te brengen. Deze zijn vertaald naar een achttal regels die houvast geven bij het begeleiden van teams en ontwerpen en ontwikkelen van leersituaties: 1. 2. 3. 4. 5. 6. 7. 8.
Maak gebruik van de persoonlijke ambitie van de betrokkenen Maak gebruik van individuele- en groepsreflectie Maak gebruik van feedbacksystemen Pas collectief diagnosticeren, ontwerpen, implementeren en beheren toe Maak gebruik van een gemeenschappelijk visie, strategie en doelen Laat de beoogde verandering ontstaan door het veranderen van gedrag Gebruik de werkplek als leeromgeving Pas leren toe op inzichten, regels en gedrag
Niet alle acht stappen van Schilt komen evenredig overeen met het achtfasenproces van Kotter. Wel zijn alle acht stappen te relateren aan een fase binnen het achtfasenproces zoals uit onderstaande figuur blijkt.
Figuur 4: Het achtfasenproces versus ontwerpprincipes
6.2
Noodzaak: Waar moeten we aan werken?
Een verandering binnen een organisatie mag en kan nooit een doel op zich zijn. Een verandering zal uiteindelijk moeten leiden tot het oplossen van een probleem; in het kader van de paper is dit dus het invoeren van de ITIL processen. Dit betekent overigens ook veranderingen in het gedrag van mensen en de structuur van de organisatie. Een probleem is vaak wat het management ziet: een symptoom. De oorzaak van het probleem zit vaak dieper in het gedrag van de betrokkenen verstopt. Dat gedrag zal op een zodanige manier moeten worden aangepakt, wil men de oorzaak van het probleem structureel aanpakken. Bron: Jan Schilt – Procesverbetering in ICT Service Management
15
Schilt haalt ook de term urgentie aan als hij schrijft over het feit dat er veel redenen zijn om te veranderen. Urgentie zegt namelijk iets over de termijn waarbinnen een probleem moet zijn opgelost. Hier ligt dus een sterke link naar het urgentiebesef zoals Kotter dat omschrijft. De noodzaak om veranderingen binnen een ICT organisatie door te voeren komen volgens hem voort uit de volgende domeinen: • • • • •
De omgeving van de organisatie Het hoger management van de organisatie De ICT Manager De teams binnen de ICT organisatie De medewerkers van de ICT organisatie
Kijkend naar de beschreven case moet gesteld worden dat aan met name de eerste twee punten geen aandacht is geschonken. De organisatie in zijn geheel is veel te weinig betrokken bij het invoeren van de ITIL processen. Het project spitste zich alleen toe op de ICT organisatie, hetgeen een kwalijke zaak genoemd kan worden. Vervolgens schrijft Schilt ook “Veranderen kunt u niet alleen” en doelt daarmee op het belang van het team. Effectieve veranderingen zijn namelijk vaak het resultaat van teams. Een veranderaar alleen zal niet veel kunnen bereiken. Wat veel voorkomt, en ook in het geval van het project wat is beschreven is in de paper, is dat de projectleider alleen ‘sleurt’ aan het project. Hij moet de medewerkers achter de vodden aanzitten en probeert op allerlei manieren enig resultaat te boeken. Gevolg is dat duurzame veranderingen helaas zelden een duurzaam karakter zullen hebben. Hier kan de link gelegd worden naar wat Kotter beschrijft als de kracht van een leidende coalitie vormen. Volgens Schilt heeft het werken in teams onder andere de volgende voordelen: • • • • •
Kennis delen Samen creëren Verantwoordelijkheid Draagvlak / noodzaak Samen leren
Dit is exact de kern van wat Kotter bedoeld met een leidende coalitie welke over voldoende draagkracht beschikt.
16
7 Conclusie en advies Na de boeken over Kotter en Schilt gelezen te hebben moet inderdaad de conclusie getrokken worden dat het project, zoals beschreven in de paper, inderdaad een slagingskans had van slechts 10%. Hadden de inzichten van beide auteurs dan hulp kunnen bieden aan een welslagen van het project? Hier moet de conclusie getrokken worden dat dit zeker niet het geval zou zijn geweest. De ICT organisatie zoals deze werd aangetroffen was op dat moment zeker niet rijp voor dergelijke grote veranderingen en transformaties. Wel hadden hun inzichten hulp geboden bij de vraag “Moet ik dit project wel uitvoeren, en wil ik als projectleider de verantwoording hiervoor dragen?”. Het antwoord hierop luidt volmondig “Nee!”. Advies is dan ook om, voordat een dergelijk project van start gaat, niet te starten met de beschrijving van het projectplan, en hiervoor zo snel mogelijk akkoord zien te krijgen. Gestart moet worden met een onderzoek en goede analyse of het project volgens het achtfasenproces ‘levensvatbaar’ is. Vervolgens kan men hieraan nog de inzichten van Schilt spiegelen, en zal een keuze gemaakt moeten worden of het project inderdaad gestart kan worden. Pas daarna moet eventueel een aanvang gemaakt worden met de beschrijving van de projectbrief, de projectopdracht en het projectplan.
17
8 Nawoord Beide boeken – Leiderschap bij verandering & Procesverbetering in ICT Service Management – hebben bij het inzicht gegeven wat ik destijds node miste. Jan Schilt is overigens een goede kennis en vriend van mij en is tevens een van de specialisten die mij als coach en steun aan de zijlijn heeft ondersteund bij het project. Dit ondanks zijn overtuiging dat dit project een zeer geringe kans van slagen had. Daar ik een persoon ben die graag zijn werk goed doet, en het liefst zo perfect mogelijk, mag duidelijk zijn dat ik grote moeite heb gehad om dit project in goede banen te krijgen. Over het project leiden in goede banen kan zelfs niet gesproken worden. Op een gegeven moment is het project me zelfs uit handen geglipt, en na een rustperiode van twee weken vakantie, heb ik dan ook te maken gekregen met een burn-out. Jan Schilt is een van de mensen geweest die me heeft geholpen om hierover heen te komen, en om het project op bepaalde punten toch nog af te ronden alvorens ik dit heb overgedragen aan een andere projectleider. Ik ben hem hiervoor nog steeds zeer dankbaar. Ik ben ervan overtuigd dat, mede door de steun van Jan destijds, en de inzichten die ik heb gekregen door het lezen van beide boeken, ik een dergelijk project niet meer zal aanpakken. Het advies wat ik in het vorige hoofdstuk heb beschreven heb ik zeker ook voor mezelf geschreven en raad ik iedereen van harte aan.
18
9 Literatuurlijst John P. Kotter Leiderschap bij verandering – ISBN 90-5261-231-5
Jan Schilt Procesverbetering in ICT Service Management – ISBN 90-5871-152-8
19
10 Lijst met figuren en tabellen 10.1 Figuren Figuur 1: Barrières voor 'empowerment' .................................................................................................. 10 Figuur 2: Het achtfasenproces voor ingrijpende verandering ........................................................................ 12 Figuur 3: Leercirkel van Kolb ................................................................................................................ 14 Figuur 4: Het achtfasenproces versus ontwerpprincipes .............................................................................. 15
10.2 Tabellen Tabel 1: ITIL Processen ........................................................................................................................ 5 Tabel 2: Berekening slagingskans ......................................................................................................... 13
20
11 Bijlage: ITIL, de Service Support en Delivery set In deze bijlage wordt per proces de kern weergegeven en wat in voordelen dit betekent voor de ICT organisatie, indien zij geïmplementeerd zouden worden. De Service Support set behandeld de processen welke zich in de operationele sfeer begeven. De Service Delivery set beschrijft de processen welke zich voornamelijk op het tactisch vlak bevinden. Hier liggen echter ook steeds meer raakvlakken met strategische processen.
11.1 De Service Support set 11.1.1 Configuration Management Configuration Management levert een bijdrage aan het verwerken van veranderingen in de ICT infrastructuur, het zoeken naar – en oplossen van – problemen en bij het ondersteunen van de gebruiker. Het gevolg is: minder fouten en dus minder kosten als gevolg van dubbel werk. 11.1.2 Incident Management Verbeterde productiviteit door gebruikers – Als gevolg van het tijdig en sneller oplossen van incidenten is er een verminderde Business impact, hetgeen leidt tot maximale beschikbaarheid van ICT diensten. 11.1.3 Problem Management Dit proces leidt tot een kwaliteitsverbetering om het, na uitvoerige analyse van één of meer incidenten, de problemen structureel wegneemt in de ICT dienstverlening. Dit heeft weer tot gevolg dat er een drastische vermindering optreedt van het aantal incidenten. 11.1.4 Change Management Binnen Change Management stelt men zeker stellen dat via gestandaardiseerde methoden en procedures, wijzigingen in de ICT infrastructuur snel worden afgehandeld met een zo gering mogelijke impact van incidenten als gevolg van die wijziging. 11.1.5 Release Management Omdat men op voorhand een release beleid samenstelt, waarin wordt bepaald hoe en wanneer wijzigingen op de ICT infrastructuur plaats vinden, is er een verhoogde efficiëntie als men spreekt over het doorvoeren van deze wijzigingen. Immers, soft- en hardware is op voorhand getest, door zowel de ondersteunende organisatie als de gebruikers organisatie en er is minder kans op incidenten doordat er getest is en de wijzigingen gecontroleerd worden doorgevoerd.
11.2 De Service Delivery set 11.2.1 Service Level Management Middels Service Level Management krijgt de ICT organisatie een beter inzicht in wat de ‘Business’ van haar verlangt. Hierdoor kan zij haar dienstverlening beter budgetteren en beter inplannen. Hoewel de voordelen van Service Level Management vooraf moeilijk te concretiseren zijn, leidt dit proces in ieder geval een bijdrage aan het verbeteren van de moraal van ICT medewerkers en tot een verbeterde verhouding met de klant.
21
11.2.2 Availability Management Het belangrijkste voordeel van dit proces is dat ICT dienstverlening wordt ontworpen, geïmplementeerd en beheerd die voldoet aan de overeengekomen beschikbaarheideisen die de ‘Business’ stelt aan diezelfde ICT dienstverlening. Hierbij wordt zeker gesteld dat de kosten die hiervoor moeten worden gemaakt, kunnen worden verantwoord. 11.2.3 Capacity Management Voordelen hiervan zijn dat de risico’s voor bijvoorbeeld bestaande applicaties worden verminderd. Men heeft middels dit proces namelijk een goed inzicht op de ICT middelen, op de performance ervan en hoe zij beheerd worden. Hierdoor wordt er op toekomstige ontwikkelingen beter geanticipeerd. 11.2.4 IT Service Continuity Management Door de richtlijnen van dit proces te volgen kunnen organisaties de impact van calamiteiten beperken, doordat als een calamiteit zich voordoet, zij hun systemen op een beheerste wijze kunnen herstellen. Hierdoor verliezen zij minder tijd en kunnen dus een hogere continuïteit aan haar gebruikers bieden. 11.2.5 Financial Management Het essentiële voordeel voor het invoeren van Financial Management is dat het management (ICT en Business) betere informatie krijgt over de kosten van de levering van ICT diensten. Deze informatie stelt hen in staat om afwegingen te maken tussen kosten en kwaliteit, om zo tot een economisch verantwoorde dienstverlening te komen.
22
