Uit praktijkervaring en berichten in de media blijkt dat de

Transcriptie

1 Methodieken.4 Uit praktijkervaring en berichten in de media blijkt dat de hedendaagse opzet, inrichting en implementatie van beheertools tot ontevredenheid leidt. Dit artikel beschrijft de resultaten van een onderzoek naar de praktische bruikbaarheid van Strategische Tool Architectuur Planning (STAP) als oplossing voor dit probleem. Hiertoe is de ontwikkelde aanpak in de praktijk toegepast bij een representatieve ICT-dienstverlener. 343 Auteurs: Mike Floris - Q-pex en Rob Mersel - Steenbok Adviesgroep In de presentatie van de leverancier leek het allemaal zo mooi. Binnen no-time alle ICTinfrastructuur onder controle, met een totaaloverzicht in een centraal managementstation. Alle problemen zouden vroegtijdig worden gesignaleerd, en zo zou de uptime worden gegarandeerd. Het aan te schaffen helpdeskpakket zou de beheerprocessen optimaal ondersteunen. In de praktijk blijkt dat er van deze beloften maar weinig terecht komt. Het komt er op neer dat er alleen maar méér bureaucratie en extra beheerproblemen bijkomen. De totale kosten van beheer stijgen en daar staat geen aantoonbare kwaliteitsverbetering tegenover. Hoe kan dat? De beheertools die de leveranciers aanbevelen zijn niet per definitie als schuldigen aan te wijzen. Ook beheerorganisaties zouden voor het maken van een keuze voor een bepaalde beheertool hun werkelijke problemen en behoeften beter in kaart moeten brengen. Zij benaderen de keuze nog te vaak vanuit een technische en tactische invalshoek, en dit is een te nauwe scope voor de keuze van een beheertool. Deze keuze zou geen gevoelsmatige afweging van de afdelingsmanager, netwerkbeheerder of servicemanager moeten zijn, maar is dat vaak nog wel. Van een planmatige werkwijze met concrete resultaten is geen sprake. Met STAP kunnen tools wel strategisch en planmatig worden aangeschaft. Dit artikel beschrijft eerst de structuur van deze methode, om daarna een praktijkcasus waarin STAP werd toegepast te beschrijven. De in deze casus gebruikte technieken en modellen komen aan de orde, evenals de ervaringen ermee. KENMERKEN VAN BEHEERTOOLS Traditionele methoden voor informatiebeleid en -planning (IBP) richten zich voornamelijk op de ontwikkeling van een informatiearchitectuur: 'het traject van beleids- en planvorming met betrekking tot de totale bedrijfsinformatiesystemen' [Hopstaken, 1988, p.308] Beheertools bestaan echter vooral uit standaardprogrammatuur zoals HP OpenView, CA Unicenter, IBM Tivoli, BMC Patrol. In dit opzicht wijken ze af van de bedrijfsinformatiesystemen. Beheertools hebben de volgende kenmerken: De afnemer legt zichzelf met de aanschaf van een beheertool meteen een werkwijze op. Dit kan impact hebben op de bestaande beheerprocessen. Beheertools omvatten een gelimiteerd aantal functies en formulieren, hun functionaliteit en het niveau van de informatieverschaffing is dus begrensd. IT Service Management best practices, deel 3

2 344 Ze bestaan uit verschillende softwareproducten die als bouwstenen in elkaar passen. Integratiemogelijkheden en -onmogelijkheden bepalen de mate van functionaliteit en informatieverschaffing. Ze worden aangeboden door (verschillende) leveranciers. Afnemers moeten zich afvragen of ze met één of meerdere leveranciers in zee willen en stilstaan bij de consequenties die dit heeft. Beheertools veroorzaken een grotere afhankelijkheid van leveranciers. Om in aanmerking te blijven komen voor productondersteuning, moeten afnemers meegaan met de laatste softwareupdates en releases die de leveranciers opleggen. De snelle technologische ontwikkelingen en stijgende functionele behoefte van de beheerorganisaties hebben een snel veranderend toolbeleid tot gevolg. Beheertools voldoen aan nationale en internationale standaarden voor beheer en beveiliging, dit is vooral in telecommunicatie noodzakelijk. Ze maken gebruik van autonome agents die direct ingrijpen op de ICT-infrastructuur. De dynamiek van de ICT-infrastructuur moet worden afgestemd op de dynamiek van de beheertools. Goed changemanagement is noodzakelijk. De grote complexiteit van beheertools maakt hoog opgeleide beheerders van deze tools noodzakelijk. Deze kenmerken vereisen een ander informatiebeleid en -planning (IBP), namelijk één die zich voornamelijk richt op de ontwikkeling van een toolarchitectuur in plaats van de bedrijfsinformatiesystemen als geheel. Afgeleid van de definitie van informatiebeleid en -planning definiëren wij STAP als: Het traject van beleids- en planvorming met betrekking tot beheertools. Het architectuurplan voor beheertools is het beleidsvoornemen van het management, zoals dat is omschreven in een actieprogramma van uit te voeren activiteiten voor de komende jaren met een prioriteitenstelling, een portefeuille van projectomschrijvingen en een algemene planning van tijd en kosten en baten'. WAT IS STAP STAP staat voor Strategische Tool Architectuur Planning. De methode beschrijft kernvragen, activiteiten en hulpmiddelen voor drie fasen: 1. De ontwikkeling van een toolbeleid, dat de ambities en de beheerdoelstellingen ondersteunt. 2. De ontwikkeling van een architectuurplan voor de beheertools. Hierin staat hoe zowel de informatievoorziening als de automatisering van het beheer van de ICT-infrastructuur wordt vormgegeven. 3. De ontwikkeling van een projectenplan waarmee het toolbeleid en het architectuurplan tot uitvoering kunnen worden gebracht. Figuur 1 toont de structuur van STAP. In de beschrijving van de fasen wordt een concrete uitvoering van de methode gegeven. Hulpmiddelen In het onderzoek is een concrete invulling voor STAP ontwikkeld door middel van aanpassing van bestaande hulpmiddelen. Deze zijn gekozen vanwege hun toepasbaarheid binnen de bestaande praktijk van beheerorganisaties: Hexagon-brainstorming [Hexagon, 2003] - experts genereren in een brainstormsessie trefwoorden, die vervolgens worden gefilterd door aan ieder trefwoord een score toe te kennen. MOS-SWOT-analyse - de Managementkenmerken, Organisatiekenmerken en de Situatiekenmerken (MOS) worden in verband gebracht met de Strengths, Weaknesses, Opportunities en Threats

3 Methodieken Beleidstraject Proces Onderzoekstraject Beheerbeleid Fase 1 Motieven Cultuur Communicatie Inhoud Procedureel Situatieanalyse (on)mogelijkheden M O S S W O T 345 Fase 2 Toolbeleid Beleid Realisatiebeleid Analyse huidige Analyse Model huidige Model Fase 3 Toolarchitectuur Prioriteiten Projectenplanning Projectdefinities Projectenplan Figuur 1 De structuur van STAP (SWOT) van een organisatie. Problemenkruis - het gaat hier om vier dimensies: 1. inhoudelijk - waarover gaat het? 2. procedureel - hoe pakken we het aan? 3. communicatief - hoe communiceren en besluiten we daarover? 4. cultureel - welke normen en waarden hanteren we? Workshops - Alle belangrijke beslissers zitten bij elkaar en communiceren direct met elkaar. Workshops zijn een uiterst productieve manier om resultaten te boeken, maar vereisen een zeer gestructureerde aanpak, en een facilitator die in staat is om alles in goede banen te leiden. Een workshop wordt gestart op basis van concrete voorstellen, omdat dit effectiever is dan tijdens de workshops tot meningsvorming te komen. Interviews - worden gebruikt in voorbereiding op de workshops om de deelnemers voor te bereiden en om de eerste discussiestukken op te stellen. Techniek voor Interactieve Proces Ontwikkeling (TIPO) [Wagter, 2001] - een methode waarmee bedrijfsprocessen en de daarmee samenhangende informatievoorziening binnen een organisatie worden doorgelicht. Het is een interactieve aanpak waarbij de materiedeskundigen een centrale rol spelen. Dit betekent dat er workshops worden gehouden waarin de medewerkers samen de verschillende bedrijfsprocessen in kaart brengen, onder begeleiding van een procesbegeleider. Standard Integrated Management Approach (SIMA) [Klompé, 2000] - is een aanpak voor het inrichten van beheer. STAP gebruikt twee matrices van de servicemanagement-architectuur (SMA) uit deze aanpak. Zij vormen een onontbeerlijk communicatiemiddel: 1. De matrix verantwoordelijkheden beschrijft welke afdelingen betrokken zijn bij het leveren van ICT-diensten volgens de beheerprocessen. Dit stelt managers in staat om een gezamenlijk beeld te krijgen IT Service Management best practices, deel 3

4 34 Tabel 1 Gebruikte hulpmiddelen per fase Fase Toolbeleid Fase Architectuurplan Fase Projectplan Hulpmiddelen Hexagon X X X MOS-SWOT analyse X Problemenkruis X Workshops X X X Interviews X X SIMA / SMA X TIPO X van de organisatorische inrichting. 2. De matrix tools beschrijft welke tools worden gebruikt voor het leveren van ICT-diensten volgens de beheerprocessen. Ze worden gebruikt om: - te laten zien hoe de organisatie in elkaar zit; - wie waarvoor verantwoordelijk is; - waar doublures zitten; - waar straks de interfaces komen; - hoe een afdeling in de toekomst zal werken; - wat een beheertool straks moet bijdragen aan het beheer. Tabel 1 toont in welke fasen de verschillende hulpmiddelen zijn toegepast. Tijdens de beschrijving van de fasen komen concrete voorbeelden aan de orde. Positionering van STAP STAP wordt gebruikt door een multidisciplinair team dat bestaat uit de leiding én uit informatie- of beheerarchitecten van de beheerorganisatie. De positionering van STAP vindt daarom op twee manieren plaats. STAP in het beheerparadigma Binnen het beheerparadigma van Looijen kan STAP op het niveau van het informatiesysteem van de beheerorganisatie worden gepositioneerd. Looijen onderscheidt drie niveaus in de ICT-organisatie: reële systemen informatiesystemen het beheer hiervan Het reëel systeem omvat alle bedrijfsprocessen, en wordt ondersteund door het informatiesysteem. Dit geheel wordt beheerd. Het beheer zelf heeft weer zijn eigen reëel systeem. Dat omvat alle beheerprocessen en wordt ondersteund door zijn eigen informatiesysteem. STAP vindt plaats in het informatiebeleid en B B IS Positie STAP IS RS RS Figuur 2 STAP in het beheerparadigma, B = beheer, IS = informatiesysteem en RS = reëel systeem (bedrijfs- resp. beheerprocessen) [Looijen, 2001]

5 Methodieken -planning voor de beheertools, en dit wordt gerealiseerd door het informatiesysteem van het beheer. STAP richt zich dus op de informatiearchitecten/beheerarchitecten van de beheerorganisatie, zoals figuur 2 laat zien. STAP binnen Business-IT alignment STAP geeft een invulling aan de onderlinge afstemming tussen Business en de ICT-afdeling (Business-IT alignment) in de beheerorganisatie. Voordat de methode kan worden ingezet, moet aan een aantal randvoorwaarden zijn voldaan: Bedrijfsbeleid - het bedrijfsbeleid (business strategy) moet bekend zijn bij de partijen die bij STAP betrokken zijn. Informatiebeleid - Het informatiebeleid (Information Technology strategy) moet bekend zijn bij de betrokken partijen. Onder het informatiebeleid scharen wij ook het informatiesysteembeleid en informatietechnologiebeleid. Afstemming op strategisch niveau - het bedrijfsbeleid en het informatiebeleid moeten op elkaar zijn afgestemd (strategic alignment). Beheerbeleid - binnen de beheerorganisatie moet het beheerbeleid zijn opgesteld. Dit moet aansluiten op het informatiebeleid. Het beheerbeleid omvat het beleid voor de interne informatievoorziening van de beheerorganisatie. De methode STAP wordt dus pas ingezet nádat de gebruikersorganisatie (Business Domain) en de beheerorganisatie (IT Domain) op elkaar zijn afgestemd (Business IT alignment). Hierna moet dit beheerbeleid concreet worden ingevuld met informatiesystemen en processen. STAP vervult hierin de rol van informatieplanningsmethode, en kan worden gepositioneerd in de overgang van het externe niveau van strategiebepaling naar het interne niveau van het realiseren van deze strategie. Hier wordt STAP dus gebruikt door de leiding van de beheerorganisatie, zie figuur 3. STAP IN DE PRAKTIJK Om te toetsen of STAP toepasbaar is bij beheerorganisaties, is een casestudie uitgevoerd bij een middelgrote ICT-dienstverlener. De beheerorganisatie van deze dienstverlener werkt met verschillende beheertools. Dat is te verklaren door verschillende overnames van andere bedrijven, en daarmee de overname van andersoortige technische platformen en ontwikkelprojecten. Omdat de beheerorganisatie één gezicht aan de klant wil tonen, wil zij een uniforme werkwijze invoeren. Daarnaast wil ze zo efficiënt mogelijk werken, door middel van het benutten van schaalvoordelen en bundeling van kennis en ervaring. Hiertoe wil de beheerorganisatie haar verschillende beheertools verder integreren en uniformeren. De leiding 1 is tot de conclusie gekomen dat 347 Business Domain IT Domain External Business Strategy Information Technology Strategy Positie STAP Internal Organisation Infrastructures and Processes Information Systems Infrastructure & Processes Figuur 3 STAP in de afstemming van Business met ICT [Venkatraman, 1993] IT Service Management best practices, deel 3

6 348 een benadering vanuit een technische invalshoek dit niet zal bereiken. Daarom zet zij in op de strategische benadering en de planmatige werkwijze van STAP. FASE 1: TOOLBELEID Het toolbeleid beschrijft de ambities en de beheerdoelstellingen die de jaarlijkse cyclus van Strategisch Tool Architectuur Planning ondersteunen en sturen. Het geeft een beeld van: 1. De motieven van de leiding om al dan niet een toolbeleid en architectuurplan te willen formuleren en te gebruiken; 2. De reikwijdte van het toolbeleid en architectuurplan; 3. De relevante trends; Beleidstraject Proces 4. De interne en externe (on)mogelijkheden van het toolbeleid en het architectuurplan; 5. De kritieke succes factoren van het architectuurplan;. De afspraken omtrent: - Inhoudelijke keuzen - doelstelling, randvoorwaarden en eisen, resultaten; - Procedurele keuzen - werkwijze, werkvormen en gereedschappen, fasering, planning, mijlpalen; - Procesmatige keuzen - communicatievorm, bijvoorbeeld een projectenorganisatie met rollen en spelregels. Onderzoekstraject - Beheer beleid Fase 1 Motieven Cultuur Communicatie Inhoud Procedureel Fase 2 Beleid Situatieanalyse Analyse huidige Analyse (on)mogelijkheden M O S S W O T Model huidige Model Fase 3 Prioriteiten Projectdefinities Figuur 4 De fase toolbeleid in STAP Toolbeleid Projectenplanning Realisatiebeleid Toolarchitectuur Projectenplan 1 Om het onderscheid aan te geven met het theoretische begrip management gebruiken wij binnen de casus de term leiding.

7 Methodieken Kernvragen Tijdens de fase toolbeleid wordt gekeken naar de huidige en toekomstige inrichting van het ICT-beheer en welke rol beheertools hierbij spelen. De kernvragen die aan bod komen zijn: Welke motieven zijn er om wel of niet een beleid en plan te willen formuleren en te gebruiken? Wat zijn de interne en externe (on)mogelijkheden om een beleid en plan te ontwerpen en te ontwikkelen? Wat men in een bepaalde wil, bepaalt de keuze. Enerzijds wordt deze keuze beïnvloed door relevante interne en externe trends. Dit zijn de ontwikkelingen in de branche en de maatschappelijke omgeving, al dan niet in relatie tot ICT en trends in de (toepassingsmogelijkheid) van de ICT zelf. Anderzijds bepalen interne en externe (on)mogelijkheden de keuze. Een belangrijk element hierbij is de vaststelling van de nieten : welke onderdelen uit het huidige toolbeleid komen niet ter sprake in het traject bij de vorming van een toolarchitectuur. Activiteiten en hulpmiddelen Het proces om tot het toolbeleid te komen bevat de volgende activiteiten: 1. Vaststellen motieven - binnen een Hexagon-workshop is het zogenaamde problemenkruis opgesteld. De deelnemers kennen gewichten toe aan elk van de opgestelde motieven. Dit mondt uit in een lijst met prioriteiten voor motieven, zie tabel Uitvoeren van de (on)mogelijkheden analyse - dit gebeurt door met een representatief aantal betrokkenen de SWOT s te beschrijven en die in relatie te brengen met de MOS-kenmerken. Door hierover te discussiëren ontstaat een gemeenschappelijk beeld van de (on)mogelijkheden voor de ontwikkeling van het architectuurplan. 3. Vaststellen reikwijdte - wordt bepaald door de resultaten van de MOS-SWOTanalyse te gebruiken voor het plannen van de architectuur. Daarmee wordt vastgesteld welke organisatieonderdelen en ICT wel of niet aan de orde komen. 4. Vaststellen van de relevante beheertrends - in de branche of in de maatschappelijke omgeving, al dan niet in rechtstreekse relatie tot ICT en trends in de (toepassing van) ICT zelf. Hier is opnieuw gebruik gemaakt van de Hexagon-methode om de prioriteit van relevante ICT-trends te geven die van invloed zullen zijn op het toolbeleid. 5. Vaststellen van de kritieke succesfactoren - in termen van winstmarge, continuïteit, marktaandeel, en kwaliteit van de dienstverlening van het bedrijf.. Maken van afspraken - met betrokkenen omtrent de taakverdeling tijdens de ontwikkeling van het architectuurplan in de volgende fase. 349 Business doelstelling Motief Aan de klant één gezicht tonen Goedkoper aanbieden van ICTdiensten Verhogen Kwaliteit ICT-diensten Efficiëntie Effectief Integratie Tabel 2 Prioriteiten en motieven Totaal Prioriteit IT Service Management best practices, deel 3

8 350 Onderzoeksresultaat van de fase toolbeleid Binnen het onderzoek waren twee doelen geformuleerd waarmee binnen de fase toolbeleid de praktische bruikbaarheid van STAP kon worden aangetoond: 1. Inzicht krijgen in de ambities om de beheerdoelstelling te ondersteunen. 2. Vaststellen in welke mate het toolbeleid richtinggevend is voor de toolarchitectuur. Hiervoor zijn drie knelpunten gesignaleerd: 1. Gebrek aan beleidskader; 2. Afwezigheid van een multidisciplinair team; 3. Onvoldoende betrokkenheid van de leiding bij het toolbeleid. Gebrek aan kaders vanuit beheerbeleid Tijdens de case bleek dat de deelnemers geen heldere uitspraken deden over de bijdrage van beheertools aan de bedrijfsvoering. De fase toolbeleid werd voornamelijk gebruikt voor het bediscussiëren van mogelijke verbeteringen ten aanzien van de bedrijfsvoering zelf. Terwijl het hebben van een goed afgestemde bedrijfsvoering juist een voorwaarde is om het toolbeleid te mogen starten [Hopstaken, 1988]. Het doel hiervan is immers te bekijken in welke mate beheertools hieraan bijdragen. De focus van de deelnemers lag voornamelijk op het oplossen van problemen waarvan ze het vermoeden hadden dat die door beheertools werden veroorzaakt. Ze spraken voornamelijk over de concretisering van verbeteringsacties aan beheertools en dachten niet na over de rechtvaardiging van die verbeteringen aan het beheer. Daarnaast vonden de deelnemers dat trends op het gebied van beheertools niet thuis hoorden op strategisch niveau. Een aantal was van mening dat STAP hier teveel doordraaft. Volgens hen staat het gebruik van teveel beheertools vast. Dit moest worden teruggebracht. Het had volgens hen geen zin naar alternatieve beheertools te kijken. Het had hier niet om de vraag 'te veel of te weinig tools' moeten gaan, maar om de vraag of de tools als zodanig een bijdrage leverden aan de beheerdoelstellingen. Een betere afbakening van de kaders door het beheerbeleid had hiervoor kunnen zorgen. Afwezigheid van een multidisciplinair team De deelnemers waren niet eensgezind over de bedrijfsvoering en spraken elkaar regelmatig tegen. De deelnemende managers begrepen en accepteerden elkaars disciplines niet. Dit is echter wel een voorwaarde voor het opstellen van beleid [Wagter, 2001]. Als positief punt kan genoemd worden dat aan het eind van de fase toolbeleid de deelnemers dichter bij elkaar waren gekomen. Zij waren blij dat ze een vertrekpunt hadden gedefinieerd, zodat ze op strategisch niveau de koers voor beheertools vast zouden kunnen stellen. Daarnaast werd er nu open met elkaar gecommuniceerd over de beleidskeuzes omtrent tools. Wij vinden dit groepsresultaat echter geen specifiek effect van de fase toolbeleid maar van het uitvoeren van de workshops als zodanig. Onvoldoende betrokkenheid van de leiding bij toolbeleid Tijdens de fase toolbeleid werd duidelijk dat de leiding vooral draagvlak en mandaat bij de bedrijfsdirectie wilde creëren, met het tactische doel om voldoende middelen (budget, resources, tijd, et cetera) te krijgen om de knelpunten met beheertools op te lossen. Door deze bijbedoelingen was er onvoldoende betrokkenheid bij de uitvoering en resultaten van STAP als zodanig. Vanwege het strategische karakter (van STAP) en de inbedding daarvan in de organisatie is deze betrokkenheid echter absolute noodzaak [Prakken, 1997]. FASE 2: ARCHITECTUURPLAN Het architectuurplan beschrijft zowel de informatievoorziening als de automatisering

9 Methodieken van het beheer. Het beschrijft: 1. De huidige en de van de architectuur volgens de leiding; 2. Een sterkte-zwakte analyse van de huidige ; 3. Het realisatiebeleid. Kernvragen Tijdens fase architectuurplanning wordt de huidige en toekomstige inrichting van het toolbeleid vastgelegd, en de rol van de beheertools hierin. De kernvragen die tijdens de architectuurplanning aan bod komen zijn: Wat is het architectuur- en automatiseringsbeleid ten aanzien van de ; waar willen we heen? Wat is de huidige architectuur en welke problemen worden daarin onderkend of welke vernieuwingen worden daarin gewenst? Wat is het beleid omtrent de realisatie van de vernieuwingen? Wat is het model van de architectuur? Het toolbeleid van de geeft de elementen weer die in de architectuur kunnen worden opgenomen. Ook geeft het een visie op de realisatie hiervan, samen met de gestelde eisen en randvoorwaarden. Het realisatiebeleid geeft selectiecriteria voor de keuze uit de projecten in de volgende fase. Ook geeft het aan welke methoden en technieken zijn toegestaan bij de uitvoering van deze projecten. 351 Beleidstraject Proces Onderzoekstraject Beheerbeleid Fase 1 Motieven Cultuur Communicatie Inhoud Procedureel Situatieanalyse (on)mogelijkheden M O S S W O T Fase 2 Toolbeleid Beleid Realisatiebeleid Analyse huidige Analyse Model huidige Model Fase 3 Toolarchitectuur Prioriteiten Projectenplanning Projectdefinities Projectenplan Figuur 5 De fase architectuurplan in STAP IT Service Management best practices, deel 3

10 352 Activiteiten en hulpmiddelen Het proces om tot het architectuurplan te komen bevat de volgende activiteiten: 1. Opstellen van het model van de huidige - om te weten vanuit welke uitgangspositie de verandering moet plaatsvinden is een model van de huidige organisatie en architectuur noodzakelijk. Hiervoor is gebruik gemaakt van het model Service Management Architectuur (SMA) van SIMA. Eerst is op basis van interviews een inventarisatie gemaakt. Daarna zijn in een workshop twee modellen opgesteld: een 'model huidige tools' (figuur ) en een 'model huidige verantwoordelijkheden'. 2. Analyseren van de huidige - het model van de huidige architectuur wordt door een aantal representatieve betrokkenen ter discussie gesteld. Zij geven een oordeel over sterke en zwakke punten van de huidige architectuur, en de te ondernemen optimalisatieacties. 3. Analyseren van de - om te weten waar de veranderingen naartoe moeten, is een model van de van de organisatie en toolarchitectuur noodzakelijk. Niet als een allesbepalende blauwdruk, want daarvoor is de van nagenoeg alle organisaties te turbulent, maar wel als een blauwdruk op een duidelijk afgebakend deelgebied. De is een globale streefrichting met zoveel mogelijk vrijheden. Op basis hiervan zijn twee modellen opgesteld: een 'model tools' en een 'model verantwoordelijkheden' (figuur 7). 4. Vaststellen en opstellen van het realisatiebeleid - een analyse van de huidige en, een beschrijving van de realisatie naar de en globaal de kosten en baten die hier betrekking op hebben. Service Management Architectuur (SMA) verantwoordelijkheiden en tools De SMA verantwoordelijkheden beschrijft welke afdelingen betrokken zijn bij het leveren van diensten volgens de beheerprocessen. De matrix geeft een beeld van de organisatorische inrichting van het beheer. Discussies over de afbakening van verantwoordelijkheden en bevoegdheden van afdelingen kunnen Tool Usage Cls Processes Incident management Problem management Change management Release management Configuration management Capacity management Service level management Financial management Security management ERP SAP R/3 v4. ABAP Sybase Databases Files PC HP-UX-11.2 HP 9000-K570 Outsourcing Switch UTP cables Figuur SMA huidige tools

11 Methodieken zo beter worden gevoerd. De beslissing over welke diensten en processen worden geleverd en welke niet moet voortvloeien uit de servicemanagementstrategie. De matrix laat de gaten en mogelijke overlappingen tussen de verschillende afdelingen zien. Uit de matrix wordt duidelijk welke raakvlakken er tussen afdelingen moeten zijn. Afdelingen leveren bijvoorbeeld vaak diensten aan elkaar. Uit de matrix blijkt welke Operational Level Agreements (OLA s) tussen afdelingen moeten worden gesloten. De matrix maakt ook duidelijk bij welke processen de afdelingen elkaar overlappen. Dit is ook te zien voor de verschillende outsourcingpartners. Uit de overgang van de 'as is' naar de 'to be' matrix blijkt wat het effect van de organisatieverandering is. Het geeft de reikwijdte van de opdracht voor het veranderingsmanagement weer. De SMA tools beschrijft op vergelijkbare wijze welke beheertools betrokken zijn bij het leveren van diensten volgens de beheerprocessen. De matrix geeft een beeld van de technische ondersteuning van het beheer. Uit de overgang van de 'as is' naar de 'to be' matrix blijkt wat het effect van de techniekverandering is. Het geeft de reikwijdte van de opdracht voor het implementatiemanagement weer. Onderzoeksresultaat van de fase architectuurplan Binnen het onderzoek waren twee doelen geformuleerd waarmee binnen de fase architectuurplan de praktische bruikbaarheid van STAP zou kunnen worden aangetoond: 1. Inzicht in de verbetering van de huidige architectuur en de manier waarop dit zou moeten worden aangepakt; 2. Inzicht in de optimalisatie van de automatisering en de manier waarop dit zou moeten worden aangepakt. Hiervoor zijn drie knelpunten gesignaleerd: 1. Beperkte bevoegdheden van de leiding; 2. Te technisch gerichte invulling van het architectuurplan; 3. Het architectuurplan was niet in lijn met het geldende toolbeleid. 353 Responsibilities to be Cls ERP SAP R/3 v4. ABAP Sybase Databases Files PC HP-UX-11.2 HP 9000-K570 Switch UTP cables Processes Incident management Problem management Change management Release management Configuration management Capacity management Service level management Financial management Security management Outsourcing Figuur 7 SMA verantwoordelijkheden IT Service Management best practices, deel 3

12 354 Beperkte bevoegdheden leiding Het architectuurplan is een afspiegeling van het huidige toolbeleid en beschrijft het kader en de richtlijnen waarbinnen toolingprojecten worden uitgevoerd. Hierbij worden keuzes gemaakt, die gevolgen hebben voor het behalen van de beheerdoelstellingen. Deze keuzes moeten worden gemaakt door een bevoegd managementteam [Hopstaken, 1988]. In de fase architectuurplan bleek dat de deelnemers zonder medeweten van de leiding besluiten hadden genomen die betrekking hadden op de architectuur. De deelnemers maakten duidelijk dat eerst de leiding moest worden overtuigd. Volgens ons had de leiding het benodigde mandaat moeten krijgen van de bedrijfsdirectie. Het ontbreken hiervan belemmerde de uitvoering van het architectuurplan binnen de beheerorganisatie, omdat de leiding de consequenties van de keuzes kon afwijzen. Invulling architectuurplan te technisch Het architectuurplan binnen de beheerorganisatie moet de volgende elementen beschrijven [Floris, 2004]: Organisatie - een verzameling mensen in een op bepaalde producten gericht samenwerkingsverband, waarin activiteiten worden uitgevoerd met behulp van middelen, en relaties worden onderhouden met de omgeving; Techniek - applicatie- en systeemsoftware en server- en netwerksystemen; Middelen - financiën, huisvesting en gereedschappen; Gegevens - gegevens verschaffen informatie, die nodig is voor het goede verloop van een beheerproces. Gegevens worden gegenereerd door beheerprocessen en ontvangen door beheerprocessen; Personeel - het gaat hierbij om de beoordeling van de consequenties voor mensen die met de architectuur gaan werken of met de gevolgen daarvan worden geconfronteerd. In de fase architectuurplan liet de leiding zich sturen door de alledaagse problemen met beheertools. De vraag in welke mate de beheerdoelstellingen niet werden gehaald en welke oorzaken hieraan ten grondslag lagen, kwam niet aan de orde. Het gevolg was dat het accent voornamelijk op Techniek kwam te liggen. Hierdoor overzagen de deelnemers de impact van implementatie van het architectuurplan op de aspecten Organisatie, Middelen, Gegevens en Personeel niet. Dit zal uiteindelijk resulteren in onvoorziene sociale, economische, organisatorische en politieke problemen [Hopstaken, 2001]. Architectuurplan niet in lijn met geldend toolbeleid Tijdens de fase architectuurplan bleek dat dit plan niet werd getoetst aan het toolbeleid. Deelnemers baseerden hun uitspraken voornamelijk op 'onderbuikgevoelens'. Het toolbeleid en architectuurplan waren hierin niet duidelijk herkenbaar. Tijdens de fase architectuurplan liepen de deelnemers regelmatig vooruit op de volgende fase (projectenplan). Ook waren ze geneigd te komen met oplossingen voor de diverse problemen met beheertools. Hierdoor heerste er een waarbij strategie, tactiek en operatie door elkaar liepen. Hierdoor is het resulterende architectuurplan niet verankerd in het toolbeleid, en daarmee niet in de doelstellingen van de beheerorganisatie. Omdat de bijdrage aan de beheerdoelstellingen niet duidelijk is, is acceptatie van het architectuurplan door de leiding onzeker. FASE 3: PROJECTENPLAN Het projectenplan beschrijft hoe de beheerorganisatie de bereikt. Er is in de vorige fasen een compleet beeld ontstaan waar de beheerorganisatie naartoe wil en waar ze nu staat: Motieven en onmogelijkheden van informatieplanning zijn bepaald; Modellen van de huidige en zijn beschreven; Verbeteringspunten voor de zijn onderkend; Wegen waarlangs realisatie mag verlopen zijn vastgesteld.

13 Methodieken Deze verbeteringen moeten meestal worden verdeeld in hapklare projecten, omdat het vaak te complex en kostbaar is dit in één groot project te doen. Het projectenplan beschrijft: 1. De overeengekomen prioriteitenstelling ten aanzien van uit te voeren projecten. 2. Een evenwichtig opgebouwde portefeuille van projectomschrijvingen. 3. Een totale tijdsplanning van de te ondernemen projecten. Kernvragen Tijdens de fase projectenplan wordt per verbetering bekeken hoe hoog haar prioriteit is. Ook wordt haar invloed op de doorlooptijd van de verschillende projecten ingeschat. Als het beoogde resultaat als haalbaar wordt ingeschat, wordt het architectuurplan definitief vastgesteld. Dan kan de realisatie verder worden uitgewerkt in projectomschrijvingen en een algemene tijdsplanning. Als blijkt dat het architectuurplan onhaalbaar is, moet dit worden aangepast. De kernvragen die tijdens de projectplanning aan bod komen zijn: Hoe en tegen welke globale lasten en baten worden het toolbeleid en het architectuurplan uitgevoerd? Wanneer en in welke volgorde worden zij uitgevoerd? Activiteiten en hulpmiddelen Het proces om tot het projectenplan te komen bestaat uit de volgende activiteiten: 1. Stellen van globale prioriteiten - de ver- 355 Beleidstraject Proces Onderzoekstraject Beheerbeleid Fase 1 Motieven Cultuur Communicatie Inhoud Procedureel Situatieanalyse (on)mogelijkheden M O S S W O T Fase 2 Toolbeleid Beleid Realisatiebeleid Analyse huidige Analyse Model huidige Model Fase 3 Toolarchitectuur Prioriteiten Projectenplanning Projectdefinities Projectenplan Figuur 8 De fase projectenplan in STAP IT Service Management best practices, deel 3

14 Motief 35 Verbetering Inzicht in klantenverwachting ontbreekt Bewijzen verzamelen m.b.t. Service Levels is niet mogelijk Klant heeft geen inzicht in de kwaliteit van de afgenomen dienst Aansturing leveranciers gebeurt niet Geen Tabel 3 Stellen van globale prioriteiten Efficiëntie Integratie Effectief Totaal Prioriteit beteringen worden verdeeld naar prioriteit. De (on)mogelijkheden zoals vastgesteld in de fase toolbeleid, middels de MOS-SWOT analyse, worden opnieuw gebruikt. Ook de analyseresultaten van de globale lasten en baten van de realisatie van de uit de fase architectuurplan worden gebruikt (zie tabel 3). 2. Definiëren van projecten - het weten wat we willen door het formuleren van doel, wegen en middelen. De Hexagon-methode is wederom gebruikt voor het vaststellen van de prioriteit van een relevante verbetering (zie tabel 4). 3. Beschrijven van de globale totale tijdsplanning - de prioriteitstelling van de projecten en de portefeuille van de projectdefinities vormen in tijd uitgezet de 'planweg' van de verbeteringen aan de architectuur. Deze totale tijdsplanning is noodzakelijk voor het afstemmen en coördineren van de uitvoering van de verschillende projecten (zie tabel 5). Project P1 Naam Doelstelling Verbetering Maximaal Budget Project P2 Naam Doelstelling Verbetering Maximaal Budget Invoering Service Level Management Verhoging Kwaliteit ICT-diensten door verbetering integratie, efficiëntie en effectiviteit Ontwikkeling van Service Levels Ontwikkeling van instrumentarium om de meetbaarheid van SLA s mogelijk te maken Ontwikkeling van klantenrapportage euro Realisatie monitoring infrastructurele componenten Verhoging Kwaliteit ICT-diensten door verbetering efficiëntie Ontwikkeling metrieken DB en OS systemen Implementatie monitoring tools euro Tabel 4 Definiëren van projecten Code Projectnaam Starten op Realisatie op P1 Invoering Service Level Management P2 Realisatie monitoring infrastructurele componenten Pn Tabel 5 Planning van projecten

15 Methodieken Onderzoeksresultaat van de fase projectenplan Binnen het onderzoek was één doel geformuleerd waarmee binnen de fase projectenplan de praktische bruikbaarheid van STAP zou kunnen worden aangetoond: Vaststellen hoe het toolbeleid en het architectuurplan tot uitvoering kunnen worden gebracht. Hierbij is één knelpunt aan het licht gekomen, namelijk dat de beoogde verbeteringen te vaag waren omschreven. Het toolbeleid en architectuurplan werden niet gebruikt door de deelnemers, en de gebruikte aannames waren niet te herleiden tot baten voor de beheerorganisatie. De prioriteitenstelling was vooral gebaseerd op 'onderbuikgevoelens'. De tijdsplanning ontstond op basis van ruwe schattingen. Hierdoor was er geen harde relatie tussen de lasten van de projecten en de baten van de verbeteringen in de beheerorganisatie. Het ontbreken van de relatie met het toolbeleid en het architectuurplan heeft geresulteerd in een projectenplan dat gebrekkig was onderbouwd. BEVINDINGEN Bovenstaande waarnemingen leiden tot de volgende bevindingen: Huidige methoden en technieken voor informatieplanning zijn onvoldoende toepasbaar - deze zijn in de beschikbare literatuur onvoldoende uitgewerkt om direct in de praktijk toe te passen. De doelstelling van workshop en interviews worden wel omschreven, maar de uitvoering ervan ontbreekt. Ook technieken voor het vastleggen van de modellen van de huidige en de ontbreken. In de case zijn daarom SMA, TIPO en de Hexagon-methode voor brainstorming toegevoegd. Kennis en kunde van STAP vereist bij deelnemers - Informatieplanning wordt beschouwd als een activiteit voor de leiding van de beheerorganisatie. Beheerarchitecten namen niet deel aan de casestudie. Tijdens de fase toolbeleid werd duidelijk dat voor het vaststellen van beleidskaders op het niveau van organisatie, processen en beheertools, de deelnemers over diepgaande informatie moeten beschikken. Het beleid moet ook gebaseerd zijn op gesignaleerde beheertrends. In de fase architectuurplan zijn daar aanvullende, meer gedetailleerde, modellen voor nodig. Dit alles werd door de leiding als 'niet strategisch' gekwalificeerd. De deelnemers hebben kennis nodig van STAP. De relatie tussen de fasen toolbeleid, architectuurplan en projectenplan moet bekend zijn. De deelnemers moeten bekend zijn met de gehanteerde terminologie, methoden en technieken. Hiervoor is naast de leiding, ook de inzet van ondersteunende informatie- en beheerarchitecten nodig. Procesbesturing noodzakelijk - Er is managementsturing nodig, in plaats van een externe adviseur. Deelnemers konden zich niet goed voorbereiden op de workshops en andere sessies tijdens de fasen van STAP. Te veel details bleven onduidelijk en bleken achteraf, tijdens volgende fasen, niet te kloppen. Dit heeft tot een langere doorlooptijd van STAP geleid. Daarnaast hadden de deelnemers te veel invloed op het verloop van STAP. De facilitator van de methode was daardoor gedwongen tijdens de sessies de structuur van de methode los te laten. Hierdoor kon de geldigheid van het resultaat niet worden gegarandeerd. AANBEVELINGEN Voor een succesvolle toolarchitectuurplanning zijn in ieder geval nodig: Training - De deelnemers aan een STAPproject moeten de denkwijze achter de methode, het gebruikte begrippenkader en de gebruikte technieken goed kennen. Ze moeten geoefend zijn in het toepassen van STAP voordat de methode daadwerkelijk wordt gebruikt binnen de beheerorganisatie. Multidisciplinair team - Het succesvol uitvoeren van STAP vereist inhoudelijke 357 IT Service Management best practices, deel 3

16 358 diepgang naast strategische besluitvorming. Er moet een multidisciplinair team worden samengesteld om naast toolbeleid ook beheermodellen, toolarchitectuur en projectenplannen op te stellen. Dit team moet bestaan uit de leiding, beheerarchitecten en toolspecialisten. Mandaat - Het team moet het benodigde mandaat krijgen om de noodzakelijke (beleids-)beslissingen te kunnen nemen. Bij onvoldoende mandaat moet steeds bij de hoogste directie van de organisatie goedkeuring worden verkregen. Dit geeft onzekerheid bij het team en vertraging in de uitvoering van STAP. Procesmatige inbedding - STAP moet zijn ingebed in de organisatie als een strategisch en cyclisch proces, dat deel uitmaakt van de planningscyclus in de beheerorganisatie. Betrokkenheid van de leiding kan worden bereikt door een lid hiervan aan te wijzen als proceseigenaar. Hij is verantwoordelijk voor de besturing en onderhoud van het proces. Dit is vergelijkbaar met de rol van de Chief Information Officer (CIO) voor de bedrijfsprocessen. Volwassenheid - Succesvol STAP uitvoeren vereist een mate van volwassenheid van de beheerorganisatie. Bijvoorbeeld door het behalen van een ISO certificaat of het vaststellen dat men niveau 3 van het IT Service Capability Maturity Model [Niessink, 2005] heeft bereikt. Pas dan is het mogelijk te sturen op de resultaten van toolbeleid, architectuurplan en het projectenplan. Verbeteringen kunnen dan concreet worden omschreven, en dan kunnen de beheerprocessen en beheerorganisatie op de juiste manier door de beheertools worden ondersteund. CONCLUSIE Het is niet gelukt om tijdens de case de STAP-methode volledig volgens het boekje toe te passen. De bevindingen die hieruit zijn voortgekomen hebben geleid tot een aantal aanbevelingen voor verbetering van de toepasbaarheid van de methode. Zo moeten bestaande algemene informatieplanning- en beleidmethoden worden aangevuld met specifieke methoden en technieken voor de praktische toepassing binnen beheerorganisaties. Wij verwachten dat met deze verbeteringen de STAP-methode wél toepasbaar is voor het kiezen, inrichten en implementeren van tools binnen een beheerorganisatie. Wij trekken als eindconclusie uit het afstudeeronderzoek: de operatie is mislukt maar de patiënt heeft het overleefd. De STAP-methode is in 2004 ontwikkeld door Mike Floris, tijdens zijn afstudeeronderzoek voor de faculteit Informatica aan de Open Universiteit Nederland, onder begeleiding van prof. dr. B. Prakken, Radboud Universiteit Nijmegen, en dr.ir. R.J. Mersel, Steenbok Adviesgroep. LITERATUUR Argelo, J., Boterman, S., Praktijkboek informatieplanning, Opbrengsten en werkwijze, Leiden, 199. Floris, M.A.H., Informatiebeleid voor beheertools, Nijmegen, Klompé R., Borgers, M., Hemmen, L. van, The SIMA : A practical approach to information technology management, World Class IT Service Management Guide 2000, Ten Hagen & Stam Uitgevers, Den Haag, Hexagon Report, Origin Manufacturing Consultancy, z.p.l, Hopstaken, B.A.A., Kranendonk, A., Informatieplanning, Puzzelen met beleid en plan, H.E. Stenfert Kroese BV, Leiden/Antwerpen, Hopstaken, B.A.A., Kranendonk, A. Informatieplanning in tweevoud, Leiden, Hopstaken, B.A.A., Kranendonk, A., Informatieplanning, Puzzelen met beleid en plan, Kluwer, Deventer, Laagland, P., Het beschrijven van organisaties en hun informatiesystemen: de methode PRISMA, Soest, 198.

17 Methodieken Linstone, H., Turoff, M., The Delphi Method: Techniques and Applications, Massachusetts, Looijen, M., Beheer van informatiesystemen, Den Haag, Martin, J., Strategic information planning methodologies, second edition, Englewood, Niessink, F., Clerc, V., Tijdink, T., Vliet van, H., The IT Service Capability Maturity Model, Bilthoven, Prakken, B., Informatie en besturing van organisaties, Assen, Scheffer, S.,Toolselectie, IIK project, Veenendaal, Theeuwes, J.A.M., Informatieplanning, Deventer, Venkatraman, N., Henderson, John C., Continuous Strategic Alignment, European Management Journal (11:2), pp , Pergamon Press Ltd., Wagter, R., Berg van den, M., Luijpers, J., Steenbergen, M., DYA: snelheid en samenhang in business- en ICT-architectuur, Den Bosch, IT Service Management best practices, deel 3

18