Ga naar het hele artikel

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
de EDP-Auditor nummer 1 2005
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 EDP-Auditor nummer 1 2005
• 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
de EDP-Auditor nummer 1 2005
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
de EDP-Auditor nummer 1 2005
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
de EDP-Auditor nummer 1 2005
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
de EDP-Auditor nummer 1 2005
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
de EDP-Auditor nummer 1 2005
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
de EDP-Auditor nummer 1 2005
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.
de EDP-Auditor nummer 1 2005
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
Aantal stappen = aantal pijlen
Stappen maal aantal
120
6
720
Wijziging
Applicatie
Netwerk
25
6
150
145
12
870
Tabel 6. De aangeslibde regelnoodzaak voor de nieuwe situatie
Aantal stappen = aantal pijlen
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
de EDP-Auditor nummer 1 2005
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.

Download Report