Een evaluatie van het ‘Information Center’ in de praktijk (I)*
Informatie­
systeem
Organiseren

Drs. Peter-Paul J. M. Schouten

Een evaluatie van het ‘Information Center’
in de praktijk (I)*

1. Inleiding
Een aan IBM ontleende definitie van een Information Center luidt als volgt:
‘An Information Center is an organization which, under control and coor­
dination of the Data Processing-Department, is designed specifically to
support, assist and educate end users to make direct use of application
software tools to develop and do maintenance and do their own applica­
tions.’ (5)
Sinds IBM Canada in de jaren zeventig als eerste het Information Centerconcept introduceerde, hebben zich zowel op het theoretische als op het
praktische vlak vele ontwikkelingen voorgedaan. De grote hoeveelheid aan­
dacht die dit concept en de hieruit ontsproten varianten de afgelopen jaren
in de internationale vakliteratuur hebben gekregen, heeft ertoe bijgedragen
dat vele bedrijven tot de implementatie van een Information Center zijn
overgegaan. In Nederland werken inmiddels circa 70 bedrijven met een
Information Center, of een afdeling die gelijksoortige produkten en dien­
sten levert.
Bij de oprichting van Information Centers binnen deze bedrijven werd
meestal niet uitgegaan van theoretische concepten zoals die in de literatuur
worden beschreven. Dit vloeide voort uit het feit dat bedrijven vaak gebon­
den waren aan bestaande situaties, vooral met betrekking tot automatise­
ringsafdelingen, waarbinnen, soms verdeeld over verschillende onderafde­
lingen, reeds bepaalde Information Center-achtige activiteiten werden
verricht. Daarnaast ligt het voor de hand dat plaats en structuur van een
Information Center sterk afhangen van factoren zoals: type bedrijf, grootte
van het bedrijf, beschikbare middelen, reden van oprichting en de persoon­
lijke zienswijzen van degenen die met de oprichting belast zijn geweest.
Deze ontwikkelingen hebben ertoe geleid dat de praktische toepassingen
en de theoretische concepten inzake Information Centers over het algemeen
niet parallel lopen.
 Om na te gaan hoe het in Nederland is gesteld met praktische toepassingen
van Information Centers en in hoeverre theoretische concepten en prakti­
* Aflevering II van dit artikel zal in het jüli/augustusnummer van het MAB verschijnen.
6-249

sche toepassingen met elkaar overeenkomen dan wel van elkaar verschillen,
is bij een negental organisaties een onderzoek verricht. Hierbij wordt met
betrekking tot de theoretische concepten met name gerefereerd aan het
boek ‘Application Development Without Programmers’ van James Martin
(4) en aan een publikatie van L. W. Hammond in IBM Systems Journal (2).
In paragraaf 2 wordt de onderzoekmethode beknopt toegelicht. In de pa­
ragrafen 3 tot en met 9 worden gegevens uit het onderzoek gerelateerd aan
theoretische concepten. In paragraaf 3 betreffen dit gegevens omtrent
justificatiecriteria die ten aanzien van Information Centers worden gehan­
teerd. Paragraaf 4 geeft een beeld van door Information Centers gestelde
doelstellingen. Paragraaf 5 gaat in op de plaats van het Information Center
binnen de organisatie.
Omdat de interne organisatie van een Information Center onder andere
sterk afhankelijk bleek te zijn van het takenpakket van het Information
Center, wordt eerst in paragraaf 6 het takenpakket van het Information
Center behandeld, waarna in paragraaf 7 de verschillende interne organi­
satiestructuren van Information Centers aan de orde komen. In de para­
grafen 8 en 9 wordt een tweetal aspecten van het takenpakket van het
Information Center nader belicht. Het gaat hierbij om het programmeren
door functionarissen van het Information Center c.q. door eindgebruikers
respectievelijk het doorberekenen van de kosten die door eindgebruikers
worden gemaakt. Paragraaf 10 tenslotte behelst de eindconclusie die uit
het onderzoek getrokken kan worden.
 Als laatste dient nog melding te worden gemaakt van het feit dat, daar in
sommige interviews vertrouwelijke informatie is verstrekt, in dit artikel
geen namen van personen of bedrijven gerelateerd worden aan besproken
situaties of problemen.
2. Het Onderzoek
Het onderzoek heeft plaatsgevonden bij een negental organisaties. Onder
deze organisaties bevond zich een tweetal bankinstellingen, een goederen­
en personentransportbedrijf, drie produktie/assemblagebedrijven, een uit­
geverij, een warenhuisketen, en een keten van detailhandelsbedrijven. Al
deze bedrijven hadden minstens 7000 werknemers in dienst. Het aantal
eindgebruikers binnen de onderzochte organisaties varieerde van 10 tot
1500, bij de meeste organisaties lag het aantal rond 250.
Met de manager of een personeelslid van het Information Center (verder
te noemen: IC) van deze bedrijven werd een interview gehouden dat circa
twee uur in beslag nam. In één geval werd met de manager van de auto­
matiseringsafdeling gesproken omdat bij dit bedrijf geen sprake was van
een IC als zelfstandige entiteit binnen de organisatie, terwijl wel ic-achtige
diensten werden verleend. Ter verificatie werd tevens een adviseur van een
groot adviesbureau op het gebied van automatiseringszaken gevraagd zijn
visie op het fenomeen ‘Information Center’ te geven.
6-250

Het interview was opgesplitst in twee delen. Het eerste deel omvatte vragen
omtrent de opzet, de organisatie en het functioneren van het IC binnen de
betreffende organisatie. In het tweede deel werd een reeks problemen met
de ondervraagde persoon doorgenomen. Deze problemen waren afgeleid uit
een inventarisatie van problemen die door 52 Amerikaanse iC-managers
was gemaakt en die gepubliceerd werd in het tijdschrift ‘Datamation’ (1).
Ook werd gebruik gemaakt van een artikel van R. T. Johnson in hetzelfde
tijdschrift (3).
 3. Justificatie van een Information Center
‘De invoering van een IC is een strategisch plan van de tweede orde. In veel
bedrijven is het nog zo slecht gesteld met bijvoorbeeld de besturing van het
produktieproces en de administratieve informatieverwerking, dat zij er goed
aan doen deze problemen van de eerste orde op te lossen voordat ze
überhaupt aan het opzetten van een IC gaan denken.’
De adviseur op het gebied van automatiseringszaken die deze uitspraak
deed, wilde hiermee twee dingen aangeven:
1. Binnen veel bedrijven zijn heel wat andere zaken die wat aandacht
betreft een veel grotere prioriteit zouden moeten hebben dan de even­
tuele oprichting van een IC.
2. Binnen veel bedrijven is de kwaliteit van de gegevens van dermate
inferieure kwaliteit dat het management er goed aan doet om eerst daar
wat aandacht aan te besteden, voordat tot oprichting van een IC wordt
besloten.
Bovenstaande bewering viel buiten het onderzoeksterrein en is daarom ook
niet geverifieerd. Bij een juiste justificatie van een IC zullen bovengenoemde
criteria echter wel een rol moeten spelen.
Is de invoering van een IC inderdaad niet gerechtvaardigd als de gegevens
waarmee wordt gewerkt niet van goede kwaliteit zijn? Door sommige mana­
gers wordt beweerd dat het twee onafhankelijke zaken zijn en dat om die
reden de doorgang van het één niet afhankelijk mag zijn van het ander.
Hierin hebben zij in zoverre gelijk dat het inderdaad mogelijk is een efficiënt
werkend IC op te zetten dat werkt met gegevens van slechte kwaliteit. Het
is echter sterk de vraag of de totale bedrijfseffectiviteit hiermee gediend
wordt. Uit het oogpunt van het belang voor de totale organisatie ligt het
voor de hand eerst een investering te doen om de kwaliteit van de gegevens
op te vijzelen, en daarna te gaan investeren in een IC.
 Een andere norm die bij de justificatie van een IC moet worden gehanteerd
is het economische criterium. De beslissing over het invoeren van een IC
zou onder andere moeten worden genomen op basis van een kosten-baten
analyse. Hammond (2) zegt hierover:
‘Implementation of an IC must be a business decision. Executive manage­
ment must be able to judge the return on investment for an IC in a manner
6-251

similar to other I/S and business opportunities. After initial justification,
continuing cost/benefit analysis must be performed to ensure that the IC
remains a profitable contributor to the business operation.’
Een bekend probleem bij deze kosten-baten analyses is het vaststellen van
de baten. Kwantificeerbare voordelen, zoals bijvoorbeeld besparingen door
produktiviteitsverbeteringen op verschillende vlakken, zijn veelal redelijk
in te schatten. Niet-kwantificeerbare voordelen, zoals daar zijn: grotere
flexibiliteit, gebruikerstevredenheid, snellere bevrediging van de informa­
tiebehoeften, kwaliteitsverbetering van informatie en dergelijke, zijn echter
veel moeilijker of soms geheel niet van te voren te voorspellen. Toch kunnen
deze niet-kwantificeerbare voordelen een grote bijdrage leveren aan het
totale rendement van de organisatie en in sommige gevallen boven de
kwantificeerbare voordelen uitstijgen.
Als reden voor het niet diepgaand onderzoeken van deze niet-kwantificeer­
bare voordelen wordt in de literatuur de initiële desinteresse van het
topmanagement aangehaald. Het topmanagement is in eerste instantie
alleen geïnteresseerd in de harde besparingen die door de invoering van
een IC gerealiseerd worden. Hierbij worden de kwalitatieve voordelen als
een prettige bijkomstigheid gezien. Omdat de positieve aspecten verbonden
aan deze kwalitatieve verbeteringen meestal op langere termijn aan het
licht komen, raakt het top-management pas in latere stadia overtuigd van
het belang en de waarde van deze baten.
 Als een IC zich eenmaal een plaats binnen de organisatie heeft verworven
steekt een ander probleem de kop op. Hierboven is gesproken over een
kosten-baten analyse aangaande een IC, waarbij de kosten en baten met
betrekking tot het gehele bedrijf werden bekeken. Betreffende een IC bestaat
echter nog een andersoortige kosten-baten analyse: een kosten-baten analyse
waarbij vanuit het IC zelf wordt geredeneerd. Dit is een pure financiële
analyse van kosten en inkomsten. Wat hierbij een belangrijke rol speelt en
tevens een probleem vormt, is het kostendoorberekeningssysteem dat ont­
worpen en gehanteerd dient te worden, hierop wordt in paragraaf 9 afzon­
derlijk teruggekomen.
Wat zijn nu de ervaringen van de verschillende bedrijven omtrent de
problematiek die bij de justificatie van een IC om de hoek komt kijken?
In de praktijk blijkt dat de meeste bedrijven aan bovenstaande problemen
nauwelijks aandacht besteden. Voor de initiële justificatie wordt veelal wel
een goed onderbouwde kostenberaming gemaakt, maar aan de opstelling
van de baten wordt te weinig aandacht besteed. Zelfs eenvoudig na te
trekken kwantificeerbare voordelen worden niet nagetrokken. Toch lijkt het
niet ondoenlijk om op basis van ervaring van andere bedrijven een redelijke
schatting te maken van bijvoorbeeld de toegenomen produktiviteitsverbe­
teringen door het gebruik van een bepaald softwarepakket.
 Op grond van welke motieven wordt dan wel de beslissing genomen om tot
6-252

de implementatie van een IC over te gaan? Koploper in de genoemde
motieven was de aandacht die het fenomeen IC in de internationale vak­
literatuur toebedeeld kreeg. Daarnaast werden de volgende redenen opge­
geven:
- achterstallig onderhoud van bestaande systemen;
- toename van ad hoe informatie-aanvragen bij de systeemontwikkelingsafdeling;
- groeiende behoefte aan minder massale en minder scherp te omlijnen
programma’s die veelal direct verbonden waren met het besluitvor­
mingsproces;
- door toekomstige eindgebruikers werd aangedrongen op plaatsing van
microcomputers en aanschaf van vierde generatie software op de main­
frame;
- toekomstige eindgebruikers maakten gebruik van relatief dure facilitei­
ten die door een extern Computer Service-bedrijf werden geboden.
Deze redenen waren veelal doorslaggevend zonder dat aan een verdergaande
justificatie aandacht werd besteed.
Enerzijds kan bij deze gang van zaken een aantal vraagtekens worden
geplaatst. Anderzijds is het enigszins te begrijpen dat aan de initiële kosten­
baten analyse weinig aandacht wordt besteed. Dit verschijnsel vloeit voort
uit twee feiten:
1. de reeds genoemde niet-kwantificeerbare baten;
2. de uitermate positieve artikelen die over ervaringen met ic’s worden
gepubliceerd.
Betreffende het probleem van het kostendoorberekeningssysteem valt
in dit kader nog het volgende te vermelden. Slechts drie bedrijven
hanteerden een gestructureerd kostendoorberekeningssysteem waarbij
de eindgebruiker ook daadwerkelijk voor de kosten moest opdraaien.
Met daadwerkelijk wordt in dit geval bedoeld dat er harde guldens van
rekening naar rekening werden overgeschreven. Tevens was bij deze
bedrijven ook duidelijk gesteld dat het IC volledig self-supporting moest
zijn.
Bij de meeste overige bedrijven werden overzichten verstuurd, waarbij
echter nimmer rekeningen betaald moesten worden. Sommige van deze
overzichten waren niet gerelateerd aan guldens. Door ic’s die deze
overzichten verstuurden werd ook niet of nauwelijks een steekhoudende
kosten-baten analyse gemaakt.
 4. D oelstellingen van een Information Center
Een aspect waaraan tijdens de voorbereiding van de invoering van een
Information Center veel aandacht hoort te worden besteed, is een scherpe
formulering van de doelstellingen. Deze doelstellingen fungeren niet alleen
als een leidraad voor functionarissen van het IC, maar dienen ook voor de
eindgebruikers een hoop duidelijkheid te scheppen.
6-253

Hammond (2) geeft aan dat de doelstellingen opgenomen dienen te worden
in een zogenaamd ‘Mission Statement’:
‘The Mission Statement for the IC is a very significant document in terms
of defining the function of the IC in the ic-environment and the rôles and
responsibilities of both staff and the users. The relationship between the
IC and the Informations Systems-development staff must also be defined
in the document. It is a concise statement of what will be done, how it will
be done and by whom.’
Hammond (2) legt hierna nogmaals de nadruk op de relatie tussen het IC
en de conventionele systeem-ontwikkelingsafdeling. Zij moeten elkaar niet
beconcurreren maar elkaar aanvullen. Deze toon van coöperatie moet in
het gehele Mission Statement te herkennen zijn. Regels aangaande het
optreden van het IC met betrekking tot grote projecten en de verdeling van
het werkterrein tussen het IC en de conventionele systeem-ontwikkelings­
afdeling moeten expliciet in het Mission Statement worden vastgelegd.
Het Mission Statement bestaat uit drie onderdelen:
1. Vastlegging van de doelstellingen van het IC.
 Bij de bepaling van doelstellingen moet onderscheid worden gemaakt
tussen lange termijn doelstellingen en korte termijn doelstellingen. De
korte termijn doelstellingen zijn afhankelijk van de ontwikkelingsfase
waarin het IC zich bevindt. Dit brengt met zich mee dat zij na bepaalde
periodes moeten worden bijgesteld of verdwijnen, dan wel dat er nieuwe
korte termijn doelstellingen geformuleerd moeten worden. Het spreekt
voor zich dat korte termijn doelstellingen veel concreter kunnen worden
geformuleerd dan lange termijn doelstellingen.
Voorbeelden van lange termijn doelstellingen kunnen zijn:
- kwaliteitsverbetering van het computersysteem;
- aanmoedigen van het programmeren door eindgebruikers;
- kwaliteitsverbetering van beslissingsondersteunende informatie.
Voorbeelden van korte termijn doelstellingen kunnen zijn:
- binnen twee jaar moet 75% van alle financiële analisten tot eindge­
bruiker zijn geschoold;
- binnen drie jaar moet het IC volledig self-supporting zijn.
2. Vastlegging van de taken van het IC om genoemde doelstellingen te

bereiken.
Hieronder kunnen zaken vallen als:
- aankoop van hardware en software;
- verzorgen van cursussen;
- beschikbaar stellen van data.
3. Vastlegging van meer algemene criteria.
Voorbeelden hiervan zijn:
6-254

- duur van de ondersteuning vanuit het IC;
- complexiteit van applicaties die nog door het IC ondersteund worden;

- mate van eindgebruikersparticipatie.
Tevens moet in het Mission Statement duidelijk worden vastgelegd in
hoeverre het IC toestaat dat eindgebruikers zelf hun applicaties ontwerpen
met behulp van vierde generatie talen. Binnen deze vierde generatie talen
zal dan een onderscheid moeten worden gemaakt tussen zeer gebruikers­
vriendelijke query-talen, rapportgeneratoren en grafiekgeneratoren ener­
zijds en applicatiegeneratoren (bijvoorbeeld MAPPER, RAMIS II, FOCUS),
‘very-high-level’ programmeertalen (bijvoorbeeld APL) en ‘parameterized
application packages’ (bijvoorbeeld SAS, SPSS) anderzijds. Dit onderscheid
wordt aangebracht op basis van de hoeveelheid kennis die vereist is om op
efficiënte wijze met een pakket te kunnen werken. Dit hangt sterk samen
met de gebruikersvriendelijkheid en de aard van het pakket.
 De term ‘end-user computing’ doelt op het gebruik van al deze mogelijk­
heden. De term ‘programmeren door eindgebruikers’ wordt in de praktijk
veelal in verband gebracht met het gebruik van applicatiegeneratoren, ‘veryhigh-level’ programmeertalen en ‘parameterized application packages’ door
eindgebruikers. Deze betekenis zal in dit rapport zo worden aangehouden.
Tijdens de gesprekken bleef het na de vraag ‘Wat voor doelstellingen zijn
er voor het IC geformuleerd?’ vaak opvallend lang stil. Na enig nadenken
werd het antwoord dan meestal gevormd door gemeenplaatsen als:
- het stimuleren van persoonlijk computergebruik;
- produktiviteitsverbetering van de eindgebruikers;
- helpen de gebruikers zichzelf te helpen.
Het zou zowel voor de functionarissen van het IC als voor de eindgebruikers
een goede zaak zijn als doelstellingen concreter geformuleerd zouden wor­
den. Het is daarbij aan te raden het niet te laten bij de zogenaamde lange
termijn doelstellingen maar zeker ook korte termijn doelstellingen duidelijk
aan te geven. Tevens, en dit is zeker niet het onbelangrijkste aspect, kan
het functioneren van het IC aan deze korte termijn doelstellingen getoetst
worden.
Het door Hammond (2) genoemde belang om de relatie en werkterreinafbakening tussen het IC en de conventionele systeem-ontwikkelingsafdeling
in het Mission Statement goed te omschrijven, blijkt in de praktijk inder­
daad geen overbodige luxe te zijn. Hierop wordt later nog teruggekomen.
 5. Plaats in de Organisatie
Volgens Hammond (2) wordt het succes van een IC voor een belangrijk deel
bepaald door zijn plaats in de organisatie. Als het IC te hoog in de organisatie
wordt geplaatst, bijvoorbeeld als stafafdeling van de automatiseringsafde­
ling, wordt het vaak gezien als een hulpmiddel voor het management van
6-255

de automatiseringsafdeling en niet voor de eindgebruikers. Dit verhindert
de opbouw van een goede relatie tussen IC en eindgebruikers. Als anderzijds
het IC te laag in de organisatie is geplaatst, bestaat het gevaar dat het
beschouwd wordt als een afdeling waarvan niet de gehele organisatie gebruik
mag maken, maar toebehoort aan de afdeling waaronder het geplaatst is.
De meest bevredigende plaats voor het IC is op gelijke hoogte met afdelingen
zoals ‘Conventionele Systeem Ontwikkeling’ en ‘Data-Base Management’,
direct onder de leiding van de automatiseringsafdeling.
Martin (4) ziet figuur 1 als voorbeeld van een organisatiestructuur waarbin­
nen het IC een geschikte plaats inneemt. De automatiseringsafdeling is
hierbij opgesplitst in twee secties: de sectie Conventionele Systeemontwik­
keling en het IC. Beide zijn ge-‘linked’ aan de Data-Administration die een
belangrijke rol moet vervullen in het standaardiseren van data die in beide
afdelingen gebruikt worden.
De organisatiestructuur zoals die wordt weergegeven in figuur 2 kwam voort
uit experimenten die IBM Canada in de jaren zeventig heeft uitgevoerd.
Deze structuur komt verder in alle iBM-publikaties als zodanig naar voren.
Teule (6) gaat wat betreft het inpassen van een IC in een organisatie iets
verder. Volgens deze auteur ziet de meest gebruikte organisatievorm, vooral
in de beginfasen van het IC, er schematisch uit als in figuur 3.
 Figuur 1
Top DP Executive

Manager of
Data Administration
Information Center
^
' \
/ \
/

Technical
Specialists

Information
Center
Consultants

'

Manager of
Conventional
Application
Development

System
Analysts

Conventional
Development

Figuur 2
Management Automatiseringsafdeling
I-------------------------- 1------------------1----------------T-----------------------------1
Operations
Systeem
Toepassings
IC

6-256

Programmering

Programmering

Figuur 3

Informatie Directeur

Technische begeleiding
door een ‘centraal IC’
IC Holding

Maatschappij

Automatiseringsafdeling

Computerafdeling

Programmering

IC Verkoop­

afdeling

IC Werkmaat­

schappij
Tevens constateert Teule (6) dat naarmate het IC meer ingevoerd raakt in
het bedrijf er een zekere tendens kan ontstaan om het IC te laten functio­
neren binnen een gebruikersafdeling. Op grond hiervan zouden dan ook
andere organisatievormen kunnen ontstaan zoals:
- een IC als onderdeel van een stafafdeling;
- een IC per lokatie, onderdeel van de automatiseringsafdeling;
- een IC per bedrijfsonderdeel, direct rapporterend aan een ‘Informatie

Directeur’.
In alle gevallen zal er een sterke band met de automatiseringsafdeling
blijven bestaan, zodat er bij elke rapportagelijn een gestippelde lijn naar de
automatiseringsafdeling zal lopen, zoals aangegeven in figuur 3.
Voordat tot een weergave van de plaats van het IC binnen de onderzochte
organisaties wordt overgegaan, dient eerst het volgende gezegd te worden.
 In principe zou het mogelijk zijn om hieronder acht figuren weer te geven
waarin voor elke organisatie de plaats van het IC wordt geschetst waarbij
gebruik wordt gemaakt van afdelingsnamen zoals die daadwerkelijk binnen
de betreffende bedrijven worden gehanteerd. Hiermee wordt echter weinig
opgeschoten. Het volgende is namelijk het geval:
1. de terminologie die wordt gebezigd als benaming voor de verschillende
onderafdelingen binnen de automatiseringsafdeling is bij de onder­
zochte bedrijven totaal verschillend;
2. wanneer het geval van gelijke benamingen zich voordoet gaat bijna nooit
exact hetzelfde takenpakket achter deze benamingen schuil. Bij elk
6-257

figuur zou dan een uitleg van de benamingen en bijbehorende taken­
pakketten moeten volgen;
3. de overzichtelijkheid zou verdwijnen en daarnaast is het niet echt
interessant om te weten of bijvoorbeeld het voorbereidend werk voor de
conventionele systeemontwikkeling in een aparte afdeling wordt gedaan
of dat dit ook onder een afdeling ‘Conventionele Systeem Ontwikkeling’
valt.
Dit zijn de redenen die ertoe geleid hebben om de overzichten wat beknopter
en met meer algemene namen weer te geven.
Op de verscheidenheid aan benamingen vormt alleen de benaming ‘Afdeling
Systeem Ontwikkeling’ een uitzondering. Deze naam zal in onderstaande
figuren dan ook als een algemene naam naar voren komen. De algemene
namen die verder zullen worden aangehouden zijn:
- Automatiseringsafdeling (aa );
- Systeem Ontwikkeling (so). Als het IC in de organisatie in lijn onder de
afdeling so valt, kunnen onder ‘so’ zowel conventionele als moderne
technieken van systeem-ontwikkeling inclusief onderhoud worden ver­
staan. In alle andere gevallen staat SO alleen voor conventionele
systeemontwikkeling inclusief onderhoud;
- Data Management (dm ). Deze afdeling houdt zich bezig met de tech­
nieken die met opslag en communicatie van data te maken hebben;
- Operations (o). Deze afdeling bemoeit zich met de technische kanten
van de hardware en het systeembeheer.
 Bij vier van de onderzochte organisaties zou de situatie nu als volgt geschetst
kunnen worden:
Figuur 4
Management AA

O

SO

DM

IC

Hierbij deden zich twee gevallen voor waarbij het IC verbonden was met
decentrale informatiecentra die over bepaalde divisies van het bedrijf ver­
spreid waren. Een dergelijke situatie zou als in figuur 5 kunnen worden
weergegeven. Eén van deze organisaties had in eerste instantie voor een
structuur gekozen waarbij geen centraal IC aanwezig was, maar was echter
snel, onder andere om financiële en coördinatieve redenen, tot oprichting
van een centraal IC overgegaan.
6-258

Figuur 5

Management AA

O

SO

DM

ic

ic

ic

ic

ic

Binnen één organisatie hing het IC direct onder SO:
Figuur 6
Management aa

O

SO

DM

IC
In een ander geval viel het IC onder DM dat op zijn beurt weer onder SO

viel:
Figuur 7

Management AA

O

so
DM

IC

6-259

Bij één organisatie was er sprake van een IC dat onder Operations viel:
Figuur 8
Management AA

O

SO

DM

IC

Een laatste organisatievorm die voorkwam is niet op een algemene manier
weer te geven. In dit geval was er naast het SO een aparte afdeling ‘Stan­
daard Programmatuur en Bijzondere Toepassingen’, waaronder onder an­
dere het IC viel.
 Figuur 9
Management aa

O

SO

SP&BT

IC

dm

In de organisatie waarbij geen zelfstandig aanwijsbaar IC aanwezig was,
werden de ic-achtige diensten door de afdelingen ‘Onderhoud’ en ‘Opera­
tions’ verricht. Deze afdelingen ressorteerden rechtstreeks onder het Ma­
nagement AA. Hierbij moet worden aangetekend dat de ontwikkeling van
de ic-achtige diensten die door deze onderafdelingen werden verleend, nog
maar net op gang gekomen was. Het aantal eindgebruikers was tien. Deze
gegevens wekken misschien de indruk dat dit bedrijf zich in een stadium
bevindt dat alle andere bedrijven ook doorlopen hebben voordat tot de
oprichting van een zelfstandig IC werd besloten en dat het management
van dit bedrijf binnenkort ook tot deze beslissing komt. Door de leiding
van de automatiseringsafdeling werd echter medegedeeld dat zij geenszins
6-260

van plan was tot een zelfstandig IC over te gaan, zelfs niet als het aantal
eindgebruikers in de toekomst sterk zou uitbreiden. De leiding kon de
voordelen van een zelfstandig IC niet inzien en was er van overtuigd dat de
huidige situatie (verdeling van de taken over onderafdelingen) minstens zo
efficiënt was. De reden hiervoor kan niet liggen in het feit dat het bedrijf
te klein was voor een zelfstandig IC, maar was eerder een uitvloeisel van de
sterk gedecentraliseerde structuur (in elke provincie een zelfstandige divi­
sie) van de organisatie.
Al met al is dus een grote verscheidenheid aan organisatievormen te con­
stateren. In vier gevallen was sprake van situaties zoals die in de literatuur
worden besproken (figuur 4). Ook de vorm zoals die door Teule werd
beschreven, werd in de praktijk teruggevonden (figuur 5). De andere orga­
nisatievormen genoten tot dusverre minder bekendheid.
 Het door Hammond (2) genoemde belang om de werkterreinafbakening en
relatie tussen het IC en de andere onderafdelingen goed vast te leggen,
blijkt in de praktijk inderdaad geen overbodige luxe te zijn. Bij vijf van de
acht organisaties die met een zelfstandig IC werkten, was sprake van voel­
bare spanningen die heersten tussen het IC en de SO-afdeling. In drie van
deze gevallen was het IC rechtstreeks onder het Management AA geplaatst.
Dit spanningsveld werd in alle gevallen als hinderlijk ervaren.
De spanningen waren veelal het gevolg van twee oorzaken:
1. IC en SO beconcurreerden elkaar;
2. SO kon zich niet voorstellen dat eindgebruikers efficiënt kunnen pro­
grammeren. SO voelde een concurrentiële situatie tussen eindgebruikers
en SO en zag het IC als de boosdoener omdat het IC het programmeren
door eindgebruikers stimuleert. Deze laatste oorzaak doet zich uiteraard
alleen voor binnen bedrijven waar eindgebruikers zelf programmeren.
Afgezien van een vooraf opgestelde strikte terreinafbakening zijn oplossin­
gen voor het uit de weg ruimen van deze spanningen in eerste instantie
moeilijk te vinden. Suggesties die gedaan werden voor een integratie tussen
SO en IC bieden geen soelaas.
Ook in deze situaties bleek namelijk dit soort spanningen voor te komen.
De enige andere oplossing die werd toegepast, was de situatie via informele
weg te verbeteren.
 James Martin (4) onderkent deze spanningen ook als een daadwerkelijk
probleem. Hij zegt hierover:
‘The solution to the rivalry lies in good overall DP management by an
executive whom both the Information Center manager and the manager of
conventional DP report to. The manager of conventional dp should be
encouraged to use new software techniques also, and challenged to dem­
onstrate how productivity can be increased and maintenance costs cut with
good data-base techniques and application generators ( ..........) Because
they serve the same community, often with the same data bases, it is vital
that Information Center management, conventional development
6-261

management and maintenance management work closely together and
explore the most cost-effective trade-offs.’
Het valt moeilijk te zeggen welke vorm van organisatie de meest geslaagde
is. Enerzijds kan dit nog niet gedaan worden omdat er nog geen nuttige
evaluatie van ervaringen kan worden gemaakt, te wijten aan het feit dat het
fenomeen IC nog maar zo kort bestaat, anderzijds hangt erg veel af van de
organisatie van de betrokken automatiseringsafdelingen en de taken die
aan de verschillende onderafdelingen opgedragen zijn.
Er kan niet worden geconstateerd dat vooral de langer bestaande ic’s zich
onder de eerst geschetste organisatievorm scharen, net zomin er een zinnig
verband kan worden gelegd tussen het aantal eindgebruikers en de plaats
van het IC in de organisatie.
Doordat het IC en alles wat direct met het IC samenhangt zich nog in een
experimenteel stadium bevindt, is de plaats van het IC binnen de organisatie
alsmede de interne organisatie van het IC, waarover in paragraaf 7 meer,
sterk afhankelijk van de persoonlijke zienswijzen van personen die met
deze vraagstukken belast zijn.
Referenties

1.
2.
3.
4.
5.
6.
T. Guimaraes, The Evolution of the Information Center, Datamation, 15 July 1984, biz.
127-130.
 L. W. Hammond, Management Considerations for an Information Center, IBM Systems
Journal, no. 2, 1982, blz. 131-161.
R. T. Johnson, The Infocenter Experience, Datamation, jan. 1984, blz. 137-142.
J. Martin, Application Development Without Programmers, Prentice Hall, Englewood
Cliffs, New Jersey, 1982.
L. Paul, Opening the Door to the Information Center (The First Step), Computerworld,
28 dec. 1981, blz. 15-16, 4 jan. 1982, blz. 18-19.
G. W. Teule, Schets, Structuur en Organisatie van een Informatiecentrum, Informatie,
mei 1983, blz. 10-15.
Een eerste, uitgebreide versie van dit artikel verscheen als Research Memorandum Nr. 8503
van de Faculteit der Economische Wetenschappen van de Universiteit van Amsterdam.
6-262.
