Complexiteit en de inrichting van de ICT-beheerorganisatie

6

de EDP-Auditor nummer 1 2005

Complexiteit en de inrichting van de ICT-beheerorganisatie Toenemende complexiteit van ICT-middelen en ICT-organisaties brengt risico’s met zich mee en baart het management blijkbaar zorgen. Hier ligt dus een mogelijkheid voor ICT-auditors om toegevoegde waarde te bieden. In dit artikel gaan de auteurs na of daarbij aanvulling op gangbare Johan Schuyl en Arno Nuijten

Inleiding In 1996 hebben Truijens en Winterink [TRUI96] in de EDP-Auditor een artikel gepubliceerd over complexiteitstoename van de geautomatiseerde informatieverzorging en de uitdaging die daaruit voortvloeit voor de ICT-auditors. Hun uitnodiging aan ICT-auditors tot vervolgonderzoek op dit terrein heeft, voorzover ons bekend, helaas geen grootschalige opvolging gekregen. De geschetste complexiteitstoename van de ICT heeft ons inziens echter wel degelijk plaatsgevonden gezien de wereldwijde toename en koppeling van ICT-componenten die sindsdien verder een vlucht hebben genomen. Tegelijkertijd heeft in de afgelopen jaren een professionalisering plaatsgevonden in de inrichting en beoordeling van de ICT-beheerprocessen, mede gestuurd door de ontwikkeling van procesgerichte modellen voor ICT-beheer zoals ITIL en CobiT. Het is echter de vraag of de implementatie van ICT-beheerprocessen volgens een dergelijk procesgericht model vanzelf resulteert in verminderde complexiteit van de ICT-organisatie zelf, aangezien zij veelal gepaard gaat met nieuwe afdelingen, functies, onderlinge afhankelijkheden en wellicht bureaucratie in

Drs. J. Schuyl is als ICT-auditor werkzaam bij EDP AUDIT POOL in Den Haag en schrijft dit artikel op persoonlijke titel. Drs. Ing. A.L.P. Nuijten RE is werkzaam als zelfstandig auditor op het gebied van ICT- en bedrijfsprocessen. Naast training en coaching van ICT-auditors verricht hij onderwijs/onderzoek aan de Erasmus Universiteit.

beoordelingskaders voor ICT-beheer wenselijk is.

de ogen van gebruikers. De twijfel of procesgericht ICTbeheer heeft geresulteerd in minder complexe ICT-organisaties wordt versterkt door recente publicaties die duiden op de wens tot eenvoudiger en slagvaardiger beheerorganisaties [LAMB03]. Tevens blijkt uit een onderzoek van Giarte Research [AUTO03] [COMP03] dat 79% van de managers bij middelgrote en grote firma’s vindt dat complexiteit van de ICT de oorzaak is van onvoldoende benutting van de strategische mogelijkheden die ICT biedt. Aangezien wij als ICT-auditors veelal gebruikmaken van normenkaders ontleend aan ITIL of CobiT, is het zinvol om na te gaan of deze procesgerichte modellen voor ICTbeheer daadwerkelijk aanknopingspunten bieden voor eenvoudiger, slagvaardiger en minder complexe ICTorganisaties. In deel 1 van dit artikel proberen wij deze vraag te beantwoorden. Daartoe zullen wij eerst een uiteenzetting geven van het begrip complexiteit zoals wij het in dit artikel hanteren. Daarbij worden tevens enkele verwante begrippen uit de sociotechniek geïntroduceerd, aangezien deze ons kunnen helpen bij de analyse van de complexiteit van ICT-organisaties naar analogie van complexiteitsanalyse in productieorganisaties. Ook zullen wij aandacht besteden aan complexiteitsbeheersing volgens Galbraith, een van de grondleggers van het complexiteitsdenken in organisaties. Daarna zullen wij, op basis van de verschillende invalshoeken voor complexiteitsbeheersing, nagaan in hoeverre een procesgerichte benadering zoals ITIL concrete aanknopingspunten biedt voor complexiteitsreductie van de ICT-organisatie. Dit leidt tot een enigszins teleurstellende


doch niet verrassende tussenbalans waarin we concluderen dat de invoering van een procesgerichte modellering van de ICT-organisatie niet automatisch resulteert in slagvaardige en minder complexe ICT-organisaties. In het tweede deel van dit artikel doen wij vervolgens een aanzet om, in aanvulling op (niet in plaats van) eerder genoemde modellen voor ICT-beheer, complexiteit van de ICT-organisatie meetbaar en beheersbaar te maken. Daartoe maken wij gebruik van principes van complexiteitsreductie die binnen de sociotechniek en productielogistiek worden toegepast op fabricageprocessen. Aan de hand van een voorbeeld werken wij dit uit voor de (gegevens)logistiek van ICT-beheerprocessen. Wij sluiten dit verhaal af met enkele conclusies gericht op het gebruik van modellen voor ICT-beheer voor de inrichting en (ten behoeve van de ICT-auditors) de beoordeling van ICT-organisaties.

Deel 1. Bieden procesgerichte modellen voor ICT-beheer aanknopingspunten voor complexiteitsreductie? Begrippenkader en scope De vraag ‘wat is complexiteit?’ is onderwerp van vele studies, uiteenlopend van filosofische bespiegelingen tot wiskundige uiteenzettingen. Onderstaand belichten wij summier enkele thema’s hieruit die noodzakelijk worden geacht voor het begrippenkader zoals gehanteerd in dit artikel. Voor een bruikbare definitie van complexiteit wordt die van Koolhaas [KOOL82] gebruikt. Deze definitie is onafhankelijk van het object en kan daardoor in elk willekeurig vakgebied worden gebruikt. Koolhaas poneert dat complexiteit veroorzaakt wordt door: 1. het aantal verschillende elementen met onderlinge verbanden; 2. het aantal verschillende manieren waarop elementen zijn verbonden; 3. de manier waarop de onderlinge relaties kunnen veranderen. Indien we deze definitie hanteren voor ICT-complexiteit (en daarbij zowel de hardware, software als organisatorische elementen in ogenschouw nemen), dan komt naar voren dat een ICT-beheerorganisatie in zichzelf leidt tot toename van elementen en derhalve tot complexiteitsverhoging. Ook neemt de ICT-complexiteit toe indien de organisatie en de ICT-elementen onderhevig zijn aan een grotere dynamiek van de omgeving en toenemende interactie met de

omgeving (ICT-systemen van klanten, leveranciers). Complexiteit kan dan theoretisch worden gereduceerd door een aantal elementen in de ICT-organisatie te elimineren dan wel de organisatie uit te sluiten van interactie met de omgeving. Het mag duidelijk zijn dat deze complexiteit juist inherent is aan de uitdaging waarvoor de onderneming gesteld is en het simpelweg uitbannen ervan zou de effectiviteit en de doelmatigheid van de onderneming schade aandoen. De complexiteit van de (ICT-)oplossing is noodzakelijk om te overleven [BOUL56] en wordt door ons in dit artikel aangeduid als externe (doelmatige) complexiteit. In dit artikel zijn wij echter vooral op zoek naar interne, ondoelmatige of aangeslibde (ICT-) complexiteit. Hiervan is sprake als het aantal ICT-componenten, het aantal organisatie-eenheden en/of interacties hoger is dan strikt noodzakelijk. In het kader van dit artikel richten wij ons uitsluitend op het onderzoeken van aangeslibde complexiteit in de ICT-organisatie, met andere woorden: zou de ICTorganisatie eenvoudiger (minder complex) kunnen worden ingericht zonder aantasting van de ICT-beheerprocessen. Het tweede thema betreft het subjectieve karakter van het begrip ‘complexiteit’. In deze beschouwing is de mate van complexiteit afhankelijk van de waarnemer. Een rekenopgave, een schaakprobleem of een ICT-storing is wellicht voor de ene persoon een complexe opgave terwijl een andere persoon dezelfde opgave eenvoudig en niet complex zou kunnen beschouwen. Anders gezegd: complexiteit is niet een absolute en objectieve grootheid, echter is relatief in de context van de waarnemer: iemand vindt iets complex. Complexiteitsreductie vanuit deze optiek is derhalve te realiseren door middel van een hoger niveau aan kennis, informatie in de ICT-organisatie, hetgeen in verband kan worden gebracht met de veelal gehanteerde volwassenheidsniveaus van de ICT-organisatie. Echter ook in deze context gelden de principes van Koolhaas dat toename van het aantal elementen, relaties en veranderlijkheid resulteert in complexiteitstoename. Ons streven om de complexiteit van de ICT-organisatie te bezien vanuit de bril, kennis van de sociotechniek en productielogistiek, dwingt ons om op deze plaats de aldaar gehanteerde begrippen kort toe te lichten. De sociotechniek is een tak van de organisatiekunde die zich kenmerkt door een integrale aanpak van het (her)ontwerp van organisaties. Deze integrale aanpak uit zich doordat aan drie aspecten tegelijk aandacht wordt gegeven [KOLL03]: • de kwaliteit van de organisatie (gericht op efficiëntie, flexibiliteit en innovativiteit); • de kwaliteit van de arbeid (met aandacht voor stressrisico’s en leermogelijkheden);

7

8


• de kwaliteit van de arbeidsrelaties (gebaseerd op coöperatie in plaats van conflict). Om alle aspecten te verbeteren is de sociotechniek gericht op het sturen van de regelnoodzaak op alle drie niveaus. In dit artikel zullen we alleen aandacht besteden aan elementen van het eerste punt, de kwaliteit van de organisatie. De regelnoodzaak kan worden gesplitst in de externe en interne regelnoodzaak [HOEV91]. De externe regelnoodzaak ontstaat door de variatie die is opgelegd door de omgeving, een behoefte die dus afhankelijk is van de

input en output. De interne of aangeslibde regelnoodzaak ontstaat wanneer de beheerorganisatie en -middelen in de vorm van regelcapaciteit ondoelmatig en te complex is ingericht (teveel componenten, interacties, veranderlijkheid). De aangeslibde regelnoodzaak moet zoveel mogelijk worden beperkt. Beheersing van de complexiteit in organisaties volgens Galbraith Voor het beheersen van complexiteit in organisaties heeft Galbraith [GALB76] een model opgesteld als in tabel 1.

1. Regels en programma’s

De eerste drie instrumenten (regels en programma’s, hiërarchische verwijzing en

2. Hiërarchische verwijzing

doelstelling) zijn volgens Galbraith altijd nodig.

3. Doelstelling 4. Speling

Met het inbouwen van speling zal de organisatie het prestatieniveau verlagen. Speling kan ingebouwd worden door meer middelen ter beschikking te stellen of een lager resultaat te aanvaarden. Dit kan op verschillende manieren tot uiting komen. Het klassieke voorbeeld van speling is het gebruikmaken van buffervoorraden of het verruimen van doorlooptijden. Maar ook het overgaan op minder producten of diensten is het inbouwen van speling, dit leidt tot een kwalitatieve verlaging van het prestatieniveau.

5. Autonome taken

In plaats van het nastreven van een scheiding van afdelingen naar taken worden taken gegroepeerd rond eenheden die beschikken over alle voor de taak benodigde middelen. Op deze manier komen zaken als ontwerp, bouw en test in één groep te liggen. Dit zorgt ervoor dat de input binnen de groep beperkt wordt tot een opdracht met een outputverplichting. Mogelijkheden voor deze indeling zijn bijvoorbeeld geografische gebieden, markten, klanten of producten.

6. Verticale informatiesystemen Door gebruik te maken van informatiesystemen kan de regelcapaciteit worden verhoogd. De theorie van Galbraith gaat uit van een hiërarchische opbouw van organisaties waarbij de doelstelling is dat alleen de noodzakelijke beslissingen door het hogere niveau gemaakt moeten worden. De oplossingen zijn gericht op het ontlasten van de hogere niveaus. Door te investeren in een verticaal informatiesysteem dat ervoor zorgt dat de beslisser de beschikking heeft over de informatie van lager gelegen niveaus, krijgt de beslisser de informatie uit diverse stromen verwerkt tot hapklare pakketjes waardoor hij duidelijk inzicht in de situatie krijgt en een beslissing kan nemen. 7. Laterale relaties

Laterale beslissingsprocessen verleggen het niveau van besluitvorming van boven naar beneden. De besluiten worden genomen op de plaatsen waar de informatie zich bevindt. Er zijn zeven vormen van laterale relaties: 1. direct contact tussen managers die een gezamenlijk probleem hebben; 2. verbindingsrollen als schakel tussen twee afdelingen; 3. taakgroepen voor het oplossen van problemen die meer dan één afdeling raken; 4. permanente teams voor terugkerende interdepartementale problemen; 5. integrerende rol als leiding geven een probleem wordt bij laterale processen; 6. koppelmanager als de differentiatie groter wordt; 7. matrix ontwerp. De vormen worden van boven naar beneden steeds ingewikkelder en kostbaarder.

Tabel 1. Model voor het beheersen van complexiteit in organisaties


Tezamen met de definities van complexiteit (Koolhaas) en regelbehoefte/noodzaak (Sociotechniek) hanteren wij het model van Galbraith als uitgangspunt voor de beschouwing van een van de meest gangbare modellen voor ICTbeheer, namelijk ITIL. Deze beschouwing wordt hierna uitgewerkt. In hoeverre heeft ITIL oog voor complexiteit van de ICT-organisatie Information Technology Infrastructure Library (ITIL)1 wordt gehanteerd als voorbeeld van de procesgerichte modellen voor de inrichting (en beoordeling) van ICT-beheer. ITIL zal in deze paragraaf worden bezien vanuit eerder genoemde invalshoeken van complexiteit (volgens Koolhaas), complexiteitsbeheersing (volgens Galbraith) en regelnoodzaak/capaciteit (volgens Sociotechniek). Wij maken hiertoe gebruik van een tabel over complexiteitsbeheersing van de ICT-organisatie uit het artikel ‘de effectieve en efficiënte ICT organisatie’ van B. Appelboom [APPE02], waarbij eveneens ITIL in beschouwing is genomen vanuit de optiek ‘informatiebehoefte voor beheersing van de complexiteit’. De betreffende tabel hebben wij aangevuld met de begrippen volgens Galbraith en volgens de sociotechniek, resulterend in tabel 2. Dit resulteert in de volgende conclusies met betrekking tot de mate waarin en de wijze waarop ITIL bruikbaar is als leidraad voor de inrichting en beoordeling van een ICTorganisatie op ondoelmatige complexiteit: • uit de grijze gebieden in tabel 2 blijkt dat ITIL vooral gericht is op de complexiteit van ICT-processen en ICTobjecten (infrastructuur en applicaties) en niet of nauwelijks gericht is op de complexiteit van organisatie, personeel, leveranciers en afnemers; • uit de grijze gebieden in tabel 2 blijkt tevens dat ITIL, vanuit de sociotechnische kijk op complexiteitsbeheersing, de nadruk legt op het verhogen van de regelcapaciteit (treffen van organisatorische maatregelen) en minder op het verlagen van de regelnoodzaak (vereenvoudiging van de ICT-omgeving inclusief ICT-organisatie); • uit de grijze gebieden in tabel 2 blijkt eveneens dat, vanuit de optiek van Galbraith op complexiteitsreductie, binnen ITIL daarbij het accent ligt op verticale informatiesystemen, autonome taken en laterale relaties als instrument voor complexiteitsbeheersing. Op zich is het juist opvallend dat autonome taken en laterale relaties een nadrukkelijke rol krijgen toebedeeld, aangezien ITIL weinig concrete aanknopingspunten biedt voor de organisatorische allocatie van taken, anders dan dat bij

de beschrijving van elk proces consequent sprake is van een manager die verantwoordelijk is voor het proces. Binnen de methode wordt vervolgens gesteld dat niet alle managers ook aparte personen hoeven te zijn en verschillende functies kunnen worden samengevoegd. Het is evident dat een ongelukkige allocatie van taken binnen de organisatie kan resulteren in een (onnodig) grote behoefte tot informatie-uitwisseling en derhalve aangeslibde complexiteit. Met de bovenstaande analyse wordt geenszins beoogd om een sluitend bewijs te leveren omtrent tekortkomingen in ITIL. Ook is niet bewezen dat ITIL representatief is voor andere procesgerichte modellen voor inrichting en beoordeling van ICT-beheer. Anderzijds geeft de bovenstaande analyse een duidelijke indicatie dat procesgerichte modellen voor ICT-beheer niet automatisch resulteren in minder complexe en slagvaardige ICT-organisaties. Een meer voortvarende implementatie van ITIL of andere procesgerichte modellen voor de inrichting en beoordeling van ICT-organisaties lijkt derhalve niet de meest voor de hand liggende oplossing te zijn voor de in de inleiding van dit artikel aangehaalde zorg over de toegenomen complexiteit van ICT-organisaties. Het is derhalve zinvol om na te gaan op welke wijze inzicht kan worden verkregen in de (aangeslibde) complexiteit van de ICT-organisatie en hoe dit inzicht kan worden gebruikt bij de inrichting en beoordeling van ICTorganisaties. Op basis van kennis uit de sociotechniek maken wij in deel 2 van dit artikel hiertoe een aanzet.

Deel 2 Analyse van de complexiteit van de ICT-organisatie – een sociotechnische benadering Aanpak voor complexiteitsanalyse van productieorganisaties Centraal in de sociotechnische benadering voor complexiteitsanalyse staat de bepaling van de ‘aangeslibde regelnoodzaak’ zoals eerder beschreven. Daartoe wordt binnen productiebedrijven gebruikgemaakt van de analyse van de productstromen, waarbij de bewerkingen van de producten in groepen worden ingedeeld. Uitgangspunt bij het ontwerpen van productstromen is het parallelliseren van gedifferentieerde stromen naar meer homogene substromen. De homogene substromen kunnen vervolgens door kleinere zelfstandige productie-eenheden worden verwerkt. Het komt er simpelweg op neer om binnen een fabricageproces de machines en bewerkingen dusdanig

9

10


Inzichtelijkheid in de complexiteit Vergroten van: Bedrijfsprocessen en informatiebehoefte

ICT-objecten (Infrastructuur applicaties)

Gebruikers/afnemers ICT-objecten/diensten

Vergroting informatie verwerkingscapaciteit door:

Interpretatie in termen van Galbraith

Klantgerichte structuur/teams [ITIL]

Verlagen van de regelnoodzaak: autonome taken Verhogen van regelcapaciteit: Verticale informatiesystemen Verlagen van de regelnoodzaak: autonome taken. Verhogen van regelcapaciteit: Verticale informatiesystemen 1 Verhogen van regelcapaciteit: verticale informatiesystemen. 2 Verlagen van de regelnoodzaak: autonome taken Verhogen van regelcapaciteit: Verticale informatiesystemen Laterale relaties (ITIL beschrijft een change advisory board) Verhogen van regelcapaciteit: verticale informatiesystemen Laterale relaties Verhogen van regelcapaciteit: Verticale informatiesystemen Laterale relaties Verhogen van regelcapaciteit: Verticale informatiesystemen Laterale relaties Verlagen van de regelnoodzaak: autonome taken. Verhogen van regelcapaciteit: Verticale informatiesystemen

Capacity management [ITIL] Objectgerichte structuur/teams (netwerk/appl/syst) Inrichting Configuration Management [ITIL] Centralisatie helpdeskfunctie1 [ITIL] Decentralisatie helpdeskfunctie2 [ITIL] Service Desk2 [ITIL]

Storingen, problemen en wijzigingen ICT-objecten

Inrichting Incident, Problem en Change Management [ITIL] Introductie Projectmatig werken [ITIL]

Serviceniveau ICT-dienstverlening

Inrichting Service Level Management-proces [ITIL]

Beschikbaarheid, continuiteit, capaciteit en kosten ICT-objecten/diensten Applicaties

Inrichting Availability, Continuity, Capacity en Financial Management [ITIL] Capacity management [ITIL]

ICT-vaardigheden

Competentiegerichte structuur/teams (ontwikkeling/beheer…) Inrichting Kennis Management en database Documentatie informatie systeem Standaardisatie documentatie Inrichting Vendor Management [ITIL, supplier management] Raamovereenkomsten, standaardisatie contracten Verkleinen informatiebehoefte ICT-organisatie door: Standaardisatie infrastructuur en applicaties. Ontkoppeling of Integratie infrastructuur en applicaties Standaardisatie gebruikersprofielen

Technische kennis/informatie ICT-objecten Leveranciers ICT-objecten/diensten

Reduceren van de complexiteit van: ICT-objecten (infrastructuur applicaties) en diensten Gebruikers/Afnemers ICT-objecten en diensten Leveranciers ICT-diensten

Hoofdaannemers ICT-diensten Standaardisatie van contracten Kosten ICT-objecten/diensten Werken op resultaat in plaats van inzetverplichting (MBO, fixed price) Reduceren van Verkleinen informatiebehoefte veranderlijkheid van: ICT-organisatie door: Benodigde personele ICT-capaciteit Uitbesteding werk tegen resultaatverantwoordelijkheid Leveranciers ICT-objecten/diensten Meer preferred suppliers, raamovereenkomsten, lange termijn contracten, solide partners ICT-objecten (infrastructuur Invoeren Release management [ITIL] applicaties) en diensten Vergroten flexibiliteit infrastructuur applicaties Eigen toevoegingen zijn cursief gedrukt. 1 om meer inzicht te krijgen in de complexiteit. 2 om meer inzicht te krijgen in veranderlijkheid. De grijze gebieden in de tabel zijn de gebieden waar ITIL invulling aan geeft.

Tabel 2. Complexiteitsbeheersing van de ICT-organisatie

Verhogen van regelcapaciteit: verticale informatiesystemen Verlagen van de regelnoodzaak: speling Interpretatie in termen van Galbraith Verlagen van de regelnoodzaak: speling

Verlagen van de regelnoodzaak: speling Verlagen van de regelnoodzaak: speling Verlagen van de regelnoodzaak: autonome taken Interpretatie in termen van Galbraith Verlagen van de regelnoodzaak: autonome taken Verlagen van de regelnoodzaak: autonome taken Verlagen van de regelnoodzaak: speling


te groeperen dat er zo min mogelijk overbodige interactie tussen machines en omstellingen van machines behoeven plaats te vinden. Voor het bepalen van de gunstigste organisatie van productstromen wordt binnen de sociotechniek de volgende aanpak gehanteerd [HOEV91]: 1. vergaren van benodigde informatie (productenpakket, bewerkingen, et cetera); 2. zoeken naar hoofdstromen; 3. toewijzen/verdelen van overige/deelbare capaciteiten; 4. inventariseren van intergroepsrelaties en het reduceren hiervan; 5. reduceren intergroepsrelaties door aangepast ontwerp van product; 6. reduceren van intergroepsrelaties door gerichte investeringen; 7. lay-out bepalen (intern transport, opslag). De groepsindelingen worden gemaakt op basis van unieke bewerkingen. Het is de bedoeling om bij dit proces het aantal intergroepsrelaties zo laag mogelijk te houden. De intergroepsrelaties zijn een maat voor de aangeslibde regelnoodzaak. In de volgende paragraaf zullen wij de sociotechnische aanpak voor het analyseren van complexiteit vertalen naar processen en organisatie voor ICT-beheer. Daarbij dient in acht te worden genomen dat een vertaling dient plaats te vinden van: • fabricage processen naar beheerprocessen • productlogistiek naar gegevenslogistiek • machines (als bewerkingscapaciteit) naar mensen/afdelingen (als bewerkingscapaciteit). Complexiteitsanalyse vertaald naar ICTorganisaties Het model voor het bepalen van de aangeslibde regelnoodzaak van Hoevenaars [HOEV91] is afkomstig uit de industrie en heeft betrekking op productieprocessen. Om het model voor beheerprocessen te kunnen gebruiken zullen we het moeten aanpassen. Het ontwerp van het product kan niet worden aangepast, stap vijf zal dus vervallen. Het bepalen van de lay-out waarbij intern transport en opslag een rol speelt, is ook niet van toepassing op beheer. Uit het model blijven dan vijf stappen over: 1. vergaren van benodigde informatie (productenpakket, bewerkingen, et cetera); 2. zoeken naar hoofdstromen; 3. toewijzen/verdelen van overige/deelbare capaciteiten;

4. inventariseren van intergroepsrelaties en het reduceren hiervan; 5. reduceren van intergroepsrelaties door gerichte investeringen. De aanpak volgt productstromen door de verschillende stappen van het productieproces. Twee begrippen zijn hierbij van belang: producten en bewerkingen. Deze begrippen zullen ook binnen beheerprocessen moeten worden gedefinieerd. Producten kunnen we karakteriseren aan de hand van de bekende processen. Zo kunnen we opgeloste incidenten, opgeloste problemen, doorgevoerde wijzigingen, capaciteitsplannen et cetera onderscheiden. De bewerkingen zijn de handelingen die nodig zijn om het product voort te brengen en zijn ondergebracht bij afdelingen. De afdelingen kunnen we zien als de clusters waartussen de productstromen zich bewegen. Voor het opstellen van een model is het nodig om te weten welke bewerkingen worden uitgevoerd op de producten die door beheerprocessen worden opgeleverd. Bewerkingen en taken In een productieomgeving worden de bewerkingen in logische eenheden – machines – samengebracht. De eenheden die bewerkingen uitvoeren binnen het beheerproces zijn medewerkers gegroepeerd in afdelingen. ITIL geeft wel bewerkingen aan maar alleen als onderdeel van het proces en niet gekoppeld aan medewerkers. Voor het definiëren van productstromen is deze koppeling essentieel. In het verleden zijn verschillende initiatieven ondernomen om uitputtende lijsten te maken van taken die worden onderkend binnen beheer. Deze pogingen blijken vaak na verloop van tijd een mislukking doordat de lijsten niet in overeenstemming zijn met de actualiteit of onvolledig zijn. Om te komen tot een taakomschrijving is een meer generieke methode nodig. Om te beginnen zullen taken Specifiek, Meetbaar, Acceptabel, Realiseerbaar en Tijdgebonden (SMART) moeten zijn met een eenduidig gedefinieerde invoer en uitvoer. Ruijs gebruikt in zijn boek ICT-dienstverlening als basis voor het definiëren van taken een servicematrix. De servicematrix is een tabel waarin de gemaakte afspraken tussen dienstverlener en opdrachtgever zijn vastgelegd. Deze tabel is een beknopt overzicht van een overeenkomst, het SLA [RUIJ03]. Om de afspraken na te kunnen komen moet aan iedere cel een directe taak worden toegekend. Alle directe taken zouden betrekking moeten hebben op één of meer afspraken bij één of meer objecten. Op deze manier kan worden nagegaan welke taken een bijdrage leveren aan de processen zoals deze in ITIL gedefinieerd zijn.

11

12


Dienst

Functionaliteit

Beschikbaarheid

Capaciteit

Prestatie

Object Gebruikersondersteuning Wijzigingen Beveiliging Calamiteiten

Tabel 3. De servicematrix, waarin de gemaakte afspraken tussen dienstverlener en opdrachtgever worden vastgelegd Hiermee zijn de producten en de bewerkingen van de beheerprocessen in kaart gebracht. Stap 1 ‘Vergaren van benodigde informatie’ uit het model is ingevuld. De volgende stap is het zoeken naar hoofdstromen.

linaire groepen of afdelingoverstijgend overleg. Een dergelijk overleg roept extra regelnoodzaak op in de vorm van regels en procedures. Dergelijke overleggen zullen als aparte bewerkingseenheid worden gedefinieerd.

Hoofdstromen Voor het vinden van de hoofdstromen is het nodig de routes van de producten tussen de verschillende bewerkingstations in kaart te brengen. De basis voor het bewerkingstation is de afdeling. Het hergroeperen van taken in functies kan slechts gedeeltelijk vrijblijvend. Vrijwel altijd zal er al een organisatie bestaan waarin medewerkers bepaalde kwaliteiten hebben die bij de verschillende functies passen. Voor het inpassen van functies en medewerkers in organisatorische eenheden zijn minder beperkingen aanwezig.

Uitgewerkt voorbeeld van complexiteitsanalyse

Door vervolgens de stromen in te vullen, aantallen producten die tussen afdelingen verplaatst worden, wordt duidelijk welke stromen van belang zijn. Hoe meer informatie een organisatie verzameld heeft hoe succesvoller deze analyse kan plaatsvinden. Als de informatie niet direct beschikbaar is, zal eerst een periode in acht moeten worden genomen waarin de benodigde gegevens worden verzameld. Aan de hand van de hoofdstromen kunnen de medewerkers met voor die hoofdstromen cruciale capaciteiten worden geïdentificeerd en ingedeeld. Stap 3 ‘Toewijzen/verdelen van overige deelbare capaciteiten’ en stap 4 ‘Inventariseren van intergroepsrelaties en het reduceren hiervan’ vallen feitelijk samen. Het indelen van afdelingen of groepen zal worden gedaan om te komen tot zo min mogelijk intergroepsrelaties. Stap 5 ‘Reduceren van intergroepsrelaties door gerichte investeringen’ zal binnen beheer voornamelijk plaatsvinden door het opleiden van medewerkers, hierdoor kunnen medewerkers meer taken uitvoeren. Een groot verschil met productieomgevingen is dat de bewerkingen die gedefinieerd zijn binnen beheer toegekend zijn aan mensen en niet aan machines. Mensen zijn mobiel en kunnen bijvoorbeeld deelnemen aan interdiscip-

In het volgende voorbeeld zullen de eerste vier stappen worden uitgevoerd. Het voorbeeld is fictief en belicht één proces: wijzigingsbeheer. De reden voor het kiezen van wijzigingsbeheer is het feit dat management juist bij het invoeren van nieuwe systemen en de integratie van systemen een grote complexiteit ervaart. We gaan uit van de organisatie O. O voert drie producten die aan drie klantgroepen worden geleverd. De organisatie is functioneel ingedeeld in de afdelingen Aanname, Bewerking en Chargeren, verder is er een staf voor Personele en financiële zaken en een afdeling ICT. De afdeling ICT is opgedeeld in de groepen: • Functioneel beheer (5 fte); • Applicatie beheer (5 fte); • Databases (3 fte); • Netwerk (5 fte); • Kantoorautomatisering (4 fte); • Testen (4 fte); • Helpdesk (3 fte). De afdeling heeft één hoofd. Binnen de organisatie worden de volgende systemen gebruikt: • CRM; • HRM; • Financieel systeem, met crediteuren, debiteuren en budgetbewaking; • Ordersysteem, status van werk; • Kantoorautomatisering suite. Binnen de organisatie zijn ITIL-processen ingevoerd. Voor de verschillende functies zullen de taken die horen


bij wijzigingsbeheer worden opgenoemd. Deze taken komen overeen met de activiteiten die in het proces door ITIL zijn beschreven.

TESTER Testen doorgevoerde aanpassingen Uitbrengen implementatie advies

FUNCTIONEEL BEHEERDER Opstellen wijzigingsverzoek [Deelnemen wijzigingsoverleg] Interpreteren implementatie advies Accepteren wijziging

HELPDESKMEDEWERKER Registreren wijzigingsverzoek Registratie Configuratie management database ICT MANAGER [Deelnemen wijzigingsoverleg]

APPLICATIE BEHEERDER Classificeren wijzigingsverzoek [Deelnemen wijzigingsoverleg] Implementeren aanpassingen testomgeving Implementeren aanpassingen productieomgeving DATABASE BEHEERDER Classificeren wijzigingsverzoek [Deelnemen wijzigingsoverleg] Implementeren aanpassingen testomgeving Implementeren aanpassingen productieomgeving NETWERK BEHEERDER Classificeren wijzigingsverzoek [Deelnemen wijzigingsoverleg] Implementeren aanpassingen testomgeving Implementeren aanpassingen productieomgeving

WIJZIGINGSOVERLEG Goedkeuren wijziging, inclusief kostenoverwegingen De taak ‘deelnemen aan wijzigingsoverleg’ staat tussen haken omdat het wijzigingsoverleg als aparte eenheid wordt opgenomen in het model. Doordat de organisatie functioneel is ingericht komt de functiebenaming overeen met de afdeling. In figuur 1 (zie p. 14) zijn de afdelingen met onderlinge relaties weergegeven. Om de hoofdstromen te definiëren is het vervolgens nodig om uit beschikbare gegevens vast te stellen welke verzoeken het meeste voorkomen en welke groepen dus het zwaarst belast worden. In dit voorbeeld gaan we uit van de cijfers zoals in tabel 4. De aangeslibde beheersbehoefte kan worden berekend als in tabel 5, waarbij een overgang tussen afdelingen als een pijl is weergegeven in figuur 1.

Aantal Wijzigingen

Impact Netwerk

5

Applicatie en Netwerk

40

Applicatie en Database

25

Applicatie

10

Database

100

Totaal

Tabel 4. Definiëren van de hoofdstromen

Product

Groep

Aantal

Voor het grootste deel van de wijzigingen geldt dat deze gerelateerd zijn aan de applicatie en de database. Het samenvoegen van de expertise voor het oplossen van deze wijzigingen zal dus leiden tot een aanzienlijke verlaging van de aangeslibde regelnoodzaak. De taken die nodig zijn voor het doorvoeren van wijzigingen in het netwerk komen vrijwel niet in combinatie met andere wijzigingen voor, bovendien zijn er relatief weinig wijzigingen aan het netwerk. Het opdelen van deze capaciteit zal weinig bijdragen aan optimalisatie.

Aantal stappen = aantal pijlen

Stappen maal aantal

Wijziging Applicatie

70

8

560

Database

50

8

400

Netwerk

25

8

200

145

24

1160

Tabel 5. Berekenen van de aangeslibde beheersbehoefte

13

14


IN

UIT

Functioneel beheer

Helpdesk

Applicatie beheer

Wijzigingsoverleg

Opstellen wijzigingsverzoek

Registreren wijzigingsverzoek

Classificeren wijzigingsverzoek

Interpreteren implementatie advies Accepteren wijziging

Registratie CMDB

Implementeren aanpassingen testomgeving

Goedkeuren wijziging, inclusief kosten

Informeren gebruikers

Implementeren aanpassingen productieomgeving Database beheer Classificeren wijzigingsverzoek Implementeren aanpassingen testomgeving Implementeren aanpassingen productieomgeving Netwerk beheer Classificeren wijzigingsverzoek Implementeren aanpassingen testomgeving Implementeren aanpassingen productieomgeving

Testen Testen doorgevoerde aanpassingen Uitbrengen implementatie advies

Figuur 1. De afdelingen met de onderling relalies De groep kantoorautomatisering komt in het wijzigingsbeheerproces niet aan bod, dit kan het gevolg zijn van de keuze om een standaard te kiezen. Op basis van deze informatie zijn de hoofdstromen de applicaties met databases. Daarnaast zijn netwerk en kantoorautomatisering te onderscheiden.

In elke groep komen medewerkers met kennis van dat specifieke systeem, een applicatiegroep bestaat uit: • Functioneel beheerder; • Applicatie beheerder; • Database beheerder; • Tester.

De groepen in de ICT-afdeling worden onderverdeeld naar soorten applicatie: • Groep Applicatie CRM; • Groep Applicatie HRM en Financiele systeem; • Groep Applicatie ordersysteem; • Groep Kantoorautomatisering; • Groep Netwerken; • Helpdesk.

Het aantal fte per groep zal afhangen van de grootte en de functionaliteit van het systeem. Het changemanagement-proces met de intergroepsrelaties ziet er dan uit als in figuur 2. De aangeslibde regelnoodzaak voor de nieuwe situatie is als in tabel 6. Nu kan het verschil worden berekend. Zie tabel 7.


Het model laat zien dat voor wijzigingsbeheer een organisatie met afdelingen georganiseerd rond applicaties en niet rond kennisgebieden een lagere aangeslibde regelnoodzaak heeft. Voor een reorganisatie van de ICT-afdeling kan natuurlijk niet worden gesteund op de resultaten van het doorberekenen van een enkel proces, alle processen zullen moeten worden betrokken.

Applicatie Groep IN Opstellen wijzigingsverzoek

Registreren wijzigingsverzoek Registratie CMDB

Uit de analyse in dit artikel blijkt dat ITIL (als representant van procesgerichte modellen voor de inrichting en de beoordeling van ICT-organisaties) niet primair gericht is op het voorkomen van aangeslibde, ondoelmatige complexiteit in de ICT-organisaties, aangezien: • binnen ITIL de nadruk ligt op de complexiteit van ICT-processen en ICT-objecten (infrastructuur en applicaties) en minder op de complexiteit van organisatie, personeel, leveranciers en afnemers; • binnen ITIL, vanuit de sociotechnische kijk op complexiteitsbeheersing, de nadruk ligt op het verhogen van de regelcapaciteit (treffen van organisatorische maatregelen) en minder op het verlagen van de regelnoodzaak (vereenvoudiging van de ICT-omgeving inclusief ICT-organisatie); • vanuit de optiek van Galbraith op complexiteitsreductie, binnen ITIL het accent ligt op verticale informatiesystemen, autonome taken en laterale relaties als instrument voor complexiteitsbeheersing. Op zich is het juist opvallend dat autonome taken en laterale relaties een nadrukkelijke rol krijgen toebedeeld, aangezien ITIL weinig concrete aanknopingspunten biedt voor de organisatorische allocatie van taken. Juist een ongeluk-

Groep

Implementeren aanpassingen testomgeving Testen doorgevoerde aanpassingen

Wijzigings overleg Goedkeuren wijziging, inclusief kosten

Uitbrengen implementatie advies Interpreteren implementatie advies Accepteren wijziging Implementeren aanpassingen productieomgeving UIT Informeren gebruikers

Figuur 2. Het changemanagement-proces

Aantal


Stappen maal aantal

120

6

720

Wijziging Applicatie Netwerk

25

6

150

145

12

870

Tabel 6. De aangeslibde regelnoodzaak voor de nieuwe situatie


Stappen maal aantal

Oude situatie

24

1160

Nieuwe situatie

12

870

Verschil

12

290

Tabel 7. Berekening van het verschil

Netwerk beheer Classificeren wijzigingsverzoek Implementeren aanpassingen testomgeving

Classificeren wijzigingsverzoek

Conclusies

Product

Helpdesk

15

Implementeren aanpassingen productieomgeving

16


kige allocatie van taken binnen de organisatie kan resulteren in een (onnodig) grote behoefte tot informatie-uitwisseling en derhalve aangeslibde, ondoelmatige complexiteit.

om de eenvoud en slagvaardigheid van de ICT-organisaties te verbeteren. Literatuur [APPE02]

Met deze analyse wordt geenszins beoogd om een sluitend bewijs te leveren omtrent tekortkomingen in ITIL. Ook is niet bewezen dat ITIL representatief is voor andere procesgerichte modellen voor inrichting en beoordeling van ICT-beheer. Anderzijds geeft de bovenstaande analyse een duidelijke indicatie dat procesgerichte modellen voor ICT-beheer niet automatisch resulteren in minder complexe en slagvaardige ICT-organisaties. Een meer voortvarende implementatie van ITIL of andere procesgerichte modellen voor de inrichting en beoordeling van ICTorganisaties lijkt derhalve niet de meest voor de hand liggende oplossing te zijn voor de in de inleiding van dit artikel aangehaalde zorg over de toegenomen complexiteit van ICT-organisaties.

Appelboom, B., (2002), De effectieve en efficiënte ICT organisatie, in: IT beheer jaarboek 2002.

[AUTO03] Automatiseringsgids, (2003), Nederlandse bedrijven willen IT vereenvoudigen, in: Automatiseringsgids, 23 juni. [BOUL56] Boulding, K.E., (1956), General Systems Theory, the skeleton of science, in: Management Science, vol 2, April, p. 122. [COMP03] Computable, (2003), Complexiteit IT remt strategisch nut, in: Computable, 18 juli, www.computable.nl/artikels/archief3/d29rs3jt.htm [GALB76] Galbraith, J.R., (1976), Het ontwerpen van complexe organisaties (oorspronkelijke titel: Designing complex organisations), Samson, Alphen aan den Rijn. [HOEV91] Hoevenaars, A.M., (1991), Produktiestructuur en

In deel 2 van dit artikel hebben wij derhalve een aanzet gemaakt om complexiteitsanalyse zoals toegepast binnen de sociotechniek en productielogistiek uit te werken voor ICT-beheer. Het model van aangeslibde regelnoodzaak is een hulpmiddel om de complexiteit van een organisatie te analyseren. In de voorbeelden wordt duidelijk dat bij het inrichten van een beheerorganisatie niet alleen naar processen maar ook naar groepering van taken moet worden gekeken als men de complexiteit wil reduceren.

organisatievernieuwing, Febo, Enschede. [KOLL03]

[KOOL82] Koolhaas, J.W., (1982), Organization dissonance and change, John Wiley & Sons, New York. [LAMB03] Lambeck, Erik, Jeroen de Wolf en Ellen Loen, (2003), Beheer kan zich veel beter organiseren, in: IT beheer, nr. 8, oktober. [RUIJ03]

Wij hopen dat wij met dit artikel een bijdrage leveren aan de ‘awareness’ bij ICT-auditors dat onze gangbare normenkaders, ITIL maar ook CobiT, niet vanzelfsprekend resulteren in minder complexe ICT-organisaties. Een ongelukkige implementatie van de activiteiten zoals beschreven in ITIL kan mogelijk zelfs leiden tot een toename van de (aangeslibde, ondoelmatige) complexiteit van de ICTorganisatie en daardoor afbreuk doen aan de efficiency en de effectiviteit van de ICT binnen een organisatie. Hierin ligt ons inziens een uitdaging voor de ICT-auditor gezien de behoefte bij zowel management als ICT-professionals,

Ruijs, L. en W. de Jong, (2003), ICT-dienstverlening, Academic Service, Schoonhoven.

[TRUI96]

De exercitie in dit artikel is puur theoretisch gebleven. Om de theorie te staven zou een veldonderzoek moeten worden uitgevoerd. Hiervoor zouden bij een grote organisatie de beheerprocessen in kaart moeten worden gebracht. Vervolgens zou met behulp van het model de aangeslibde regelnoodzaak moeten worden bepaald. Aan de hand van de structuur en meetgegevens zou daarna een alternatieve structuur met een lagere aangeslibde regelnoodzaak kunnen worden voorgesteld.

Kollenburg, T. van, (2003),Taakgroepen: duurzaam verbeteren?, Technische Universiteit Eindhoven.

Truijens, J. en J. Winterink, (1996), Complexiteitstoename van de (geautomatiseerde) informatieverzorging, in: de EDP-Auditor, nr. 3.

Noot 1 Service Support, The Stationary Office, Norwich, 2000; Service Delivery, The Stationary Office, Norwich, 2001.

Complexiteit en de inrichting van de ICT-beheerorganisatie

Recommend Documents