|
|
Door C.E.
Dallinga-Hunter
In de halve eeuw van computertechnologie is een overgang
geweest van automatisering - het door automaten/computers laten
verrichten van bestaande taken - naar informatisering: het
bepalen van vorm, inhoud en samenhang van informatiestromen, op
een wijze die passend is voor de organisatie, gebruikmakend van
de mogelijkheden van computersystemen en, daarna, ook van
netwerken. Uit voorbeelden - een multinationale onderneming, het
ministerie van Onderwijs en Wetenschappen, een Nederlandse
universiteit - zal blijken dat en waarom deze overgang niet
zonder schokken is verlopen. Uit de ervaringen vallen lessen te
trekken, die mede de aandachtsgebieden voor de komende jaren
bepalen.
In een moderne tekst over informatisering hoort het woord
'gebruiker' of 'eindgebruiker' thuis. Dit om aan te geven dat de
mens centraal staat in de beschouwing. Soms is dit het geval,
vaak echter blijkt het technische systeem - de computer, tele- of
datacommunicatie-infrastructuur, toepassingssysteem - de centrale
plaats in te nemen en is de mens in dit systeem slechts een
afgeleide, zo niet een slachtoffer. Immers, vele in de laatste
tien jaar ontwikkelde systemen hebben gebreken vertoond die soms
voor de gebruiker van catastrofale aard waren. De kranten hebben
er wel eens bol van gestaan.
Ik wil betogen dat het centraal stellen van de techniek een
onjuiste benadering is. Uitgangspunt moeten de vraagstukken van
de organisatie en vooral de rol en de taak van de mens in de
organisatie zijn. Alleen dan kunnen alle problemen in een vroeg
stadium van de ontwikkeling tot hun recht komen, doordat ook
niet-technologen zowel bij de strategieontwikkeling als bij de
toepassingen van de informatietechnologie betrokken
worden.
De stelling is niet nieuw, er wordt al veel lippendienst aan
bewezen. Toch zal het in Nederland nog wel langer dan tien jaar
duren voor een geïntegreerde aanpak van
informatiseringsproblemen regel is. Hiermee wordt bedoeld een
opzet, waarbij in alle stadia ook alle relevante factoren
meespelen. De snelheid van de ontwikkeling in deze richting wordt
mede bepaald door de mate waarin het onderwijs zo'n houding, bij
systeemontwikkelaars én gebruikers, bevordert. Dat vereist
een meervoudige rol van de informatietechnologie in het
onderwijs: niet alleen onderwerp van studie, maar ook
gebruiksinstrument in de studie.
Voorafgaand aan de bespreking van problemen,
keuzemogelijkheden en strategieontwikkeling in de huidige
situatie geef ik een kort, sterk op persoonlijke ervaringen
gebaseerd overzicht van de historische ontwikkeling.
De jaren vijftig tot negentig
Degenen die mij in de computerwereld introduceerden maakten in de
jaren vijftig kennis met de eerste digitale computers. Zij
maakten de schok mee die door de enorme versnelling van
berekeningen - tot wel duizend optellingen per seconde - werd
veroorzaakt. Niet alleen ging alles vlugger, maar ook tot dan toe
buiten het bereik liggende problemen konden worden aangepakt. Het
daardoor opgewekte enthousiasme was, meer dan bedrijfseconomische
overwegingen, de stuwende kracht bij het gebruik van de eerste
computers.
Wat Nederland betreft werd de eerste commercieel
verkrijgbare computer aangeschaft voor het
Koninklijke/Shell-laboratorium, Amsterdam. Deze was een
bezienswaardigheid, die trots getoond werd aan collega's van
elders, maar ook aan hoge bezoekers als koningin Juliana en de
toenmalige Sjah van Perzië. Na korte tijd werd dit wonder -
het kreeg de naam MIRACLE, een acroniem waarin de M afkomstig was
van Mokum - dag en nacht, vaak zeven dagen per week, gebruikt. U
moet daarbij bedenken dat de gebruikers, dat waren vooral
beta-wetenschappers, niet alleen zelf de programma's schreven,
maar ook de machines bedienden. Alleen voor het onderhoud waren
er drie specialisten. De gebruiker was de baas; de computer was
(bijna) zijn persoonlijke dienaar. Wel een tijd en aandacht
vragende dienaar. Daar kwam verandering in.
Computers kostten veel geld en werden steeds krachtiger en
duurder. Allengs werd het echter duidelijk dat de
programmeringskosten nog sneller stegen. Dit en de uitbreiding
van de gebruikerskring leidden tot de ontwikkeling van
symbolische programmeertalen: FORTRAN (formula translation) en
algol (algorithmic language) voor de technisch-wetenschappelijke
computing, en COBOL (common business oriented language) voor de
administratief-commerciële computing. In de jaren zestig
bevorderden deze ontwikkelingen het ontstaan van rekencentra die,
met hun operators, programmeurs en andere specialisten, de
gebruikers veel werk uit handen konden nemen. Niet altijd tot
plezier van de gebruikers: er kwamen spelregels en wachttijden en
ook de kosten werden beter zichtbaar gemaakt. De rekencentra
groeiden en werden datacentra; door ontwikkelingen als
time-sharing en de verbetering van datacommunicatieverbindingen
konden zij ook op afstand hun klanten bedienen.
Vanuit de bedrijfsleiding gezien bleven de kosten van
computing - hardware, software, communicatie en menskracht voor
bediening en ontwikkeling - in de jaren zestig en ook nog enige
tijd daarna in het algemeen beneden één procent van
de jaarlijkse omzet. Dit had, bij grote ondernemingen, tot gevolg
dat het management van de automatisering op afdelings- en
divisieniveau plaatsvond. Pas toen de kosten van automatisering
en communicatie in de jaarrekening zichtbaar werden en vervolgens
soms meer dan vijf procent van de bedrijfskosten gingen bedragen,
groeide ook de gerichte aandacht van de (financiële)
managers. In die periode - eind jaren zeventig en in de jaren
tachtig - kwamen de vragen: waaraan geven we ons geld uit, is er
wildgroei, wat is de kosten/batenverhouding?
Er waren andere factoren die de vraagstelling nog dringender
maakten. De kracht van de general purpose computers groeide, maar
ook de onvrede met het serviceniveau van de datacentra.
De technische ontwikkeling, vooral de miniaturisering van
computercomponenten, zorgde niet alleen voor een enorme
capaciteitsvergroting van de machines, maar bood ook nieuwe
mogelijkheden: minicomputers, intelligente werkstations, personal
computers. Hierdoor werden tal van activiteiten mogelijk, waarbij
men het centrale datacentrum wel kon missen. De mogelijkheden
leken onbeperkt, maar de kostenstijgingen bleken dat ook te zijn,
waarbij een belangrijke bijdrage werd geleverd door het gebrek
aan standaardisatie zowel in de hardware, de software, de
communicatie als in de toepassingsprogramma's.
Met de laatste opmerkingen komen we toe aan een aantal
problemen van de jaren negentig.
De jaren negentig
Naast de eerste, meest brede vraag: hoe hanteer ik
informatiseringsproblemen? en ook als onderdeel daarvan, doen
zich een aantal deelproblemen voor. Deze betreffen enerzijds de
interne bedrijfssituatie, anderzijds de relatie met leveranciers
en (eventuele) adviseurs. Men moet zich daarbij realiseren dat
het bij de huidige stand van zaken niet meer gaat louter om het
aanschaffen van computerkracht (voor een persoon, een afdeling of
het hele bedrijf). Nee, het gaat om de vraag hoe men een
infrastructuur op het gebied van informatisering creëert, die
ten dienste kan staan van het gehele instellingsgebeuren, met al
zijn interne en externe interacties. Als men daarvan uitgaat,
moet een informatiseringsplan dat die naam verdient, uitvloeisel
zijn van het instellingsplan. Wij komen hier nog op terug, en
stippen nu eerst enige belangrijke deelproblemen aan, overigens
zonder daarvoor algemeen geldende oplossingen te kunnen
bieden.
Een belangrijke vraag bij de aanschaf van
computerfaciliteiten betreft de keuze van de leverancier. Wil men
zich beperken tot één leverancier van hardware en de
daarbij passende produkten? Dat kan kosten besparen en problemen
voorkomen, maar leidt tot een afhankelijkheid die in
kwetsbaarheid kan ontaarden. Factoren die hierbij meespelen zijn
de levensduur van computersystemen, de snelheid van veranderingen
in de instelling zelf en het tempo van nieuwe ontwikkelingen in
de computerindustrie. De producenten streven elkaar steeds
voorbij, bij voorbeeld wat betreft prijs/prestatieverhouding of
verbetering van mens-machine-interface.
Bij een multinationale onde
rneming als Shell
beperkte men zich niet tot één leverancier. Dat was
bedrijfsbeleid, echter niet alleen gebaseerd op de hiervoor
genoemde overwegingen, maar ook vereist door de grote variatie in
behoeften van de centrale kantoren en de vele werkmaatschappijen.
In zo'n situatie is standaardisering alleen uitvoerbaar bij een
uiterst strakke hiërarchische leiding.
Ook wanneer men kiest voor één hardware (of
plug-compatible) lijn, blijft er een keuzevraag met betrekking
tot de software. Die is snel gemaakt wanneer de
hardwareleverancier operatingsystemen levert die uitsluitend op
de eigen machine functioneren. De ontwikkeling van een
machine-onafhankelijk besturingssysteem is al lang geleden
gestart in de laboratoria van Bell: UNIX. Dit produkt is algemeen
geaccepteerd in de wereld van wetenschappelijke toepassingen.
Toepassing in de commerciële wereld is geremd door het niet
voltooid zijn van back-up en recoveryprocedures;
gebruikszekerheid en beschikbaarheid zijn voor dat type
toepassingen een absolute eis.
De volgende keuzevraag betreft database-management software,
analyse- en ontwerphulpmiddelen, talen, generatoren en
ontwikkelhulpmiddelen, documentatie en testhulp-middelen,
schattingshulpmiddelen, enzovoort. Er zijn op elk van deze
terreinen vele produkten op de markt, elk gebaseerd op een eigen
filosofie. Om de complexiteit te tonen nemen we de
database-managementsystemen als voorbeeld. Het systeem kan
hiërarchisch zijn, een netwerk, relationeel, semantisch,
associatief, neutraal of wat de (nabije) toekomst nog meer te
bieden heeft. Zoals gezegd is het niet mogelijk om een algemene
uitspraak te doen over welk systeem het beste is: dat hangt zeer
sterk af van de conceptuele en de logische gegevensstructuur die
wordt geïmplementeerd. En deze hangen weer af van het type
bedrijf of bedrijfsproces waarop de gegevens betrekking
hebben.
Een algemene opmerking die wel over het keuzeprobleem
gemaakt kan worden, luidt dat de leveranciers (uiteraard) vooral
de nadruk leggen op de kwaliteiten van hun produkten en dat de
verkopers vaak beter op de hoogte zijn van de commerciële dan
van de technische aspecten van hun produkten. Om teleurstellingen
te voorkomen is eigen vakkennis of die van een betrouwbaar,
onafhankelijk adviseur zeer gewenst. Dit is slechts gedeeltelijk
bedoeld als kritiek op de leverancier; men kan het ook een
kenmerk noemen van een jonge, nog niet uitontwikkelde
industrie.
Een managementprobleem voor de jaren negentig wordt ook
gevormd door de steeds groeiende verbinding van systemen. Men kan
zeggen dat met de aanleg van lokale, regionale, nationale en
internationale netwerken en hun onderlinge verbindingen een
nieuwe, 'gedistribueerde' wereld voor ons open gaat, met zeer
vele, nu nog onbedachte toepassingen. Het betekent in elk geval
dat het strategisch beleid met betrekking tot informatisering
zich ontwikkelt van een individueel beleid op elk van de gebieden
hardware, software, communicatie, toepassingen op het gebied van
numerieke computing, high performance computing,
gegevensverwerking, tekstverwerking, electronische post, computer
integrated manufacturing, computer-ondersteund onderwijs,
computer aided experimentation, enzovoort, tot een meer
geïntegreerd beleid dat, zoals hiervoor opgemerkt, een
afgeleide zal zijn van het instellingsbeleid. De formulering van
een informatiseringsbeleid vereist derhalve kennis van en
ervaring met zowel informatisering als bedrijfsprocessen. Dit
houdt in betrokkenheid van computerspecialisten,
organisatiedeskundigen en vooral ook de gebruikers van de
systemen in alle fasen van een ontwikkeling. Daarbij zijn
experimenten op de werkvloer nodig, met behoud van het overzicht,
wat het informatiseringsproces maakt tot een iteratief
proces, waarbij bottom-up en top-down fasen elkaar
afwisselen.
Strategisch informatiseringsbeleid
Aanpak afhankelijk van de aard van de instelling. Het
informatiseringsbeleid is de opvolger en uitbreiding van het
automatiseringsbeleid. Bij het automatiseringsbeleid van een
organisatie was een belangrijke vraag: wat is het niveau van de
automatiseringsmanager, aan wie rapporteert hij of zij en hoe
intensief is de relatie met het hogere niveau? Het antwoord was
niet overal hetzelfde en soms om goede redenen. Ik loop weer even
mijn eigen ervaringen langs.
Bij Shell waren er twee mogelijkheden, afhankelijk van de
aard van het bedrijf. Betrof het een exploratie- of
produktiemaatschappij dan rapporteerde, vanaf de jaren tachtig,
de chef automatisering aan de algemeen directeur. Betrof het een
marketing-, chemisch- of olieproduktiebedrijf dan vond de
rapportage plaats aan de financieel directeur. Men kan zeggen dat
deze verschillen op natuurlijke wijze tot stand kwamen, bepaald
als zij werden door aard en niveau van de relatie tussen
automatisering en de desbetreffende disciplines. Er was een
sterke wisselwerking tussen leiding en
automatiseringsgroep.
Bij de overheid (rijk, provincie, gemeente, ook bij de
universiteit) trof men ook verschillende situaties aan, bepaald
door historische en politieke factoren. Zo rapporteerde in het
ministerie van Onderwijs en Wetenschappen, eind jaren tachtig, de
afdeling organisatie en automatisering aan de
secretaris-generaal, met dwarsverbanden naar elk der
directoraten-generaal en/of directies. De wisselwerking tussen
leiding en automatiseringsgroep was in vergelijking met het
bedrijfsleven niet sterk, mede omdat op het hogere niveau de
vakkennis beperkt was.
Bij de Informatiseringsbank, toen een losstaand, maar niet
geheel zelfstandig onderdeel van het departement, bestond aan het
eind van de jaren tachtig een interactie op afstand, zowel
letterlijk (Groningen-Zoetermeer) als figuurlijk. Dit leidde tot
een verschil tussen 'droom en daad', dat wil zeggen tussen
wetgeving en praktische uitvoerbaarheid, dat soms grote problemen
veroorzaakte. Na de reorganisatie is die situatie gewijzigd, met
als doel het strategisch belang van de informatisering voor het
bereiken van de bedrijfsdoeleinden tot gelding te brengen.
Enerzijds rapporteert de informatiseringsdirectie direct aan de
hoofddirecteur, anderzijds licht deze het departement voor over
de praktische haalbaarheid van wetsveranderingen en van het
tijdstip dat men daarvoor op het oog heeft.
Bij de universiteiten zijn de situaties onderling
verschillend. Het is niet ongewoon dat er een softwaregroep is
van redelijke kwaliteit, die echter niet in staat is tot het
uitvoeren of voorbereiden van een strategisch beleid. Dit mede
omdat op de hogere niveaus òf de belangstelling òf de
kennis voor
het leveren van een bijdrage aan zo'n beleid onvoldoende aanwezig
is. In het volgende ga ik wat meer in detail in op mijn
ervaringen bij de Universiteit van Amsterdam.
Toen ik in 1989 door de Universiteit van Amsterdam werd
aangetrokken - op het niveau van adjunct-secretaris - was mijn
opdracht om de automatisering en informatisering gerichte
aandacht te geven, zowel bij de vijftien faculteiten als bij de
zes diensten en de vijf overige beheerseenheden. Uitgangspunt
daarbij was de weloverwogen conclusie van het College van Bestuur
dat deconcentratie van het beheer noodzakelijk was. Een vereiste
daarvoor is een goed samenspel tussen de twintig eenheden op het
gebied van studenten, onderwijs, onderzoek, bestuur, beheer
(financiën, gebouwen, personeel), bibliotheken en algemene
zaken en hiervoor zijn weer goede bestuurlijke- en
beheersinformatiesystemen nodig. Voor het opzetten en doen
functioneren daarvan besloot het College van Bestuur een
functionaris aan te stellen op het hoogst mogelijke ambtelijke
niveau en om daarvoor geen ambtenaar te kiezen, maar een
onafhankelijk deskundige met ervaring in het
bedrijfsleven.
Zowel de opdracht als de daaraan ten grondslag liggende
overwegingen klonken mij aantrekkelijk in de oren, te meer omdat
het College van Bestuur duidelijk maakte dat het ernst was met de
veranderingsprocessen. Tijdige, correcte en zo volledig mogelijke
bestuurlijke informatie is onmisbaar voor het besturen van een zo
omvangrijke en complexe organisatie als de Universiteit van
Amsterdam, was de vaste overtuiging.
Wat snel opviel was de tegenstelling tussen de hoge
kwaliteit van onderwijs en onderzoek op het gebied van
informatisering en de geringe kennis en ervaring op dit terrein
van bestuurders, beheerders, directeuren, beleidsambtenaren,
raadsleden en anderen alsmede het vrijwel ontbreken van
verbindingen tussen deze onderdelen van de instelling. Het kwam
mij voor dat hierin verbetering te brengen moest zijn, te meer
omdat bleek dat aan wetenschappelijke zijde belangstelling
bestond voor het toepassen van de eigen kennis op de bestuurlijke
problemen van de universiteit. Anderzijds waren de diensten sterk
geïnteresseerd in mogelijke verbeteringen in hun procedures
en methodieken.
Dit leidde ertoe dat theoretisch goed opgeleide
bijna-afgestudeerden als stagiaire konden worden betrokken bij
verscheidene vernieuwingsprojecten. Op deze wijze kregen zij, op
een passende schaal, te maken met praktische moeilijkheden zoals
deze in het voorafgaande aan de orde kwamen en zoals zij ook
later in hun loopbaan zouden ontmoeten. Zij wisten daar ook goede
oplossingen voor te vinden, zodat deze symbiose wederzijds tot
voldoening aanleiding gaf. Enige voorbeelden :
Voor het downloaden van de financiële gegevens uit het
grootboeksysteem op de mainframe- computer werden
selectieprogramma's en procedures gemaakt. Zaten de gegevens
eenmaal in de pc, konden er modellen mee doorgerekend worden en
werden de gegevens via grafische vormgeving op een aantrekkelijke
manier gepresenteerd.
Beslissingsondersteunende systemen werden bestudeerd en
geïmplementeerd; toepassingen werden gemaakt en besproken met
de beleidsambtenaren. Duidelijk werd, dat op dit terrein nog heel
veel experimenten moeten plaatsvinden alvorens deze hulpmiddelen
in de lijnorganisatie vruchtbaar gebruikt kunnen worden.
Een belangrijk werkprincipe bij veranderingsprocessen is, om
eerst de bestaande situatie globaal in kaart te brengen. Ook deze
taak werd door afstudeerders uitgevoerd. In drie tot zes maanden,
afhankelijk van de lengte van de afstudeerstage, droegen zij bij
aan het systematisch in kaart brengen van de
informatiehuishoudens van de zes diensten van het bureau van de
universiteit: personeel, financiën, bouw en huisvesting,
studentzaken, onderwijs en onderzoek en algemene zaken. Daarna
kwamen ook de faculteiten en de universiteitsbibliotheek aan de
beurt.
Deze beschrijving van enige activiteiten aan de Universiteit van
Amsterdam heeft als doel te illustreren dat elke instelling haar
specifieke problemen heeft, zowel wat de informatiebehoefte als
de interne relaties betreft. Tevens wordt, hoop ik, duidelijk dat
deel-automatiseringen in het huidige informatiseringstijdperk
niet verstandig zijn; bij de vele mogelijkheden die de stand van
de techniek biedt, en nog gaat bieden, is het buiten beschouwing
laten van samenhangen tussen organisatieonderdelen een bron van
moeilijkheden.
De architectuur van het systeem
Het is gebruikelijk om, sprekende over de structuur van
informatiesystemen, onderscheid te maken tussen gegevens-,
functionele en technologische architectuur. Met andere woorden:
welke ordening brengen we aan in de gegevens, voor welke
doeleinden willen we ze gebruiken en hoe worden we daarbij
geholpen of gehinderd door de mogelijkheden van de beschikbare
(hard- en software) hulpmiddelen? Deze laatste formulering maakt
duidelijk dat de genoemde architecturen niet onafhankelijk van
elkaar zijn.
In het volgende worden de architecturen afzonderlijk
besproken en wordt niet steeds de onderlinge afhankelijkheid
benadrukt. Deze is echter wel altijd aanwezig en bepaalt ook vaak
de gedachtengang.
Informatie-architectuur
Op welk niveau zijn de gegevens die in geautomatiseerde systemen
gebruikt worden beschreven? Vaak ligt dit op het niveau van een
fysiek gegevensmodel per toepassingsgebied. Onder fysiek
gegevensmodel verstaan we de feitelijke vastlegging in
electronische vorm. Bij de UvA bestond er voor sommige
toepassingen, bijvoorbeeld de centrale studenteninschrijving, een
aanzet tot een conceptueel en een logisch gegevensmodel. Onder
logisch gegevensmodel verstaan we de beschrijving van de gegevens
en hun onderlinge relaties in directe samenhang met de
toepassingsprogramma's. Onder conceptueel gegevensmodel verstaan
we de afbeelding van de realiteit in het benoemen van
gegevenseenheden en de onderlinge relaties tussen de eenheden. Om
van zo'n situatie te geraken tot een voor de gehele universiteit
aanvaardbare informatie-architectuur is een taak, die men niet
moet onderschatten. Immers, op verschillende plaatsen zijn
verschillende definities in omloop met betrekking tot
studentgegevens, gevolg van de niet parallel lopende interessen
en belangen van de diverse actoren.
Anderzijds: de studentgegevens zijn parameters in de
bekostigingsmodellen, zowel van het ministerie van O&W naar de
universiteit als van het College van Bestuur naar de faculteiten,
zodat eenduidigheid en eensgezindheid over de definities wel zeer
gewenst is. Zo gewenst, dat de taaie volharding nodig om
misverstanden uit de weg te ruimen en meningsverschillen en
belangentegenstellingen te overbruggen, moet worden opgebracht.
Een belangrijk, zelfs doorslaggevend hulpmiddel daarbij is het
altijd bieden door de projectleider van een heldere,
waarheidsgetrouwe, voor alle betrokken partijen overeenstemmende
en slechts voor één uitleg vatbare voorstelling van
zaken en het tot gemeenschappelijk bezit van de betrokkenen maken
daarvan.
Een voorbeeld waarbij blijkt dat het maken van een
universitair gegevensmodel zijn vruchten kan afwerpen, ligt op
het raakvlak van financiën en personeel. Begrotingen laten
zien dat 85 procent van de universitaire begroting bepaald wordt
door de post 'personele lasten'. Zorgvuldig personeelsbeleid en
-beheer zijn niet alleen nodig voor goed onderwijs en onderzoek,
maar betreffen ook een zeer grote component van de bestedingen
van de universiteit. Mijn ervaringen zowel op het ministerie van
O&W als bij de Universiteit van Amsterdam laten zien dat de
samenspraak tussen personeelsdienst en financiële dienst over
de toch gemeenschappelijke definitiekwesties veel te wensen
overlaat. Het is veelal de automatiseringsafdeling die met beide
diensten spreekt en dan is het weer afhankelijk van het aanzien
en de overtuigingskracht van deze organisatie of die in staat is
om de personeels- en financiële deskundigen aan
één tafel te krijgen. Bij de Informatiseringsbank
lukte dit mede door de hiërarchische organisatie: de
hoofddirecteur kon de informatica-, de personeels- en de
financieel directeur bij zich roepen om de noodzakelijke
afstemming te bereiken (zie kader).
Terug naar de informatie-architectuur van de universiteit.
Slechts weinige universiteiten zullen zich herkennen in een
hiërarchisch informatie- of gegevensmodel. Een netwerkmodel
benadert de realiteit een stuk beter. Het is daarom ook niet
verwonderlijk dat de stichting universitaire administratieve
automatisering (SUAA) ruim tien jaar geleden koos voor IDMS, een
netwerkdatabase-managementsysteem. De afbeelding van de realiteit
op de computer was hiermee uitvoerbaar, maar zoals we nu weten,
niet erg efficiënt en flexibel. Met de komst van de
relationele database-architectuur is hier verandering in gekomen,
maar ook hier zien we nog de afstand tussen ontwerp en praktijk.
De jonge afstudeerders in informatica of
bedrijfsinformatiekunde bleken vertrouwd met de mogelijkheden en
beperkingen van relationele databases. Het rekencentrum van de
Amsterdamse universiteiten bood echter op dit terrein alleen
beperkte ondersteuning op het onderwijs- en onderzoekdeel;
dezelfde service werd niet geleverd onder het besturingssysteem
van de bestuurlijke- en beheersproblemen. Dit is zowel een
kwestie van financiële middelen als van beleid van het
universitair rekencentrum, dat op afstand van de universiteiten
functioneert als een zelfstandige stichting. Het feit dat de
universitaire bestuurders in het bestuur van het rekencentrum
zitten, verkort deze afstand onvoldoende; de invloed van
gebruikers op de bedrijfsvoering is heel beperkt. Het wordt met
het werken aan bestuurlijke informatie van dag tot dag
duidelijker dat de universiteit een veel-, zo niet allesomvattend
gegevensmodel nodig heeft. Eénmalig zo'n model maken kan
iedereen die de juiste menskracht gedurende een aantal maanden
aan het werk kan zetten. Eénmalig opzetten heeft echter
weinig zin wanneer er geen hulpmiddelen zijn om de modellen te
onderhouden en aan te passen aan de steeds veranderende eisen en
wensen. Zowel op het gebied van data dictionary/directories als
op het gebied van datamodelinghulpmiddelen is er de laatste tien
jaar wel veel, maar toch nog onvoldoende beschikbaar gekomen.
Relevante technieken, met name de middelen voor overbrenging van
wijzigingen in één van de modellen, bijvoorbeeld in
het logische model, naar de andere (conceptueel en fysiek model)
ontbreken in de meeste produkten.
Samenvattend: in grote en complexe organisaties, waar
beheers- én stuurgegevens gebruikt worden voor zowel
beheers- als stuurinformatie, is de aanwezigheid van een
informatiemodel op drie niveaus, namelijk conceptueel, logisch en
fysiek, noodzakelijk. Er zijn weinig universitaire
onderwijsorganisaties die dit al op het concernniveau
gerealiseerd hebben. De state-of-the-art is dat op elk van de
beheersgebieden: financiën, personeel, huisvesting,
studenten, onderwijs en onderzoek dit onderwerp nu serieus
benaderd wordt.
Alleen wanneer er informatiemanagers op het hoogste
concernniveau zijn aangesteld, mag men activiteiten verwachten
die zowel leiden tot een omvattend gegevensmodel als tot
richtlijnen en adviezen aan organisatorische eenheden over de te
hanteren definities en de inrichting van de lokale
gegevensmodellen. Het doel van een adequate modellering en
beschrijving van de gegevens is om op de zich steeds wijzigende
organisatiestructuren en wijzen van gebruik van de informatie op
een flexibele manier te kunnen anticiperen.
Functionele architectuur
Nadat we in het vorige gedeelte stil hebben gestaan bij het
belang van de modellering van gegevens, komen we nu toe aan de
functies, de processen en de activiteiten die op de
gegevensverzamelingen worden losgelaten. Voor het beschrijven van
deze functionele modellen zijn vele methodieken ontwikkeld en van
hulpmiddelen voorzien. Zelf vind ik de data-flow-diagrammethode
één van de meest overzichtelijke wijzen van processen
weergeven. De schematische weergave van globaal niveau tot het
diepste gewenste niveau van detail zorgt ervoor dat de processen
goed doordacht worden en dat cirkelredeneringen en onheldere
samenhangen beter zichtbaar worden gemaakt dan in uitsluitend
beschrijvende tekst.
Voor het maken van functionele modellen geldt dat beperking
en beheersing belangrijke kundigheden (moeten) zijn van de
architect/ontwerper. Zeer veel systemen zijn onbetaalbaar en/of
onbeheersbaar geworden doordat het geloof van de vaak
technologisch geschoolde projectleider in de mogelijkheden van de
hardware en software groter was dan uiteindelijk in realiteit
gewettigd bleek. De ontwikkeling van het geautomatiseerde systeem
dat de wet op de studiefinanciering uitvoert is zo'n voorbeeld
van te groot geloof in de oplossingen van de techniek. Wanneer ik
terugkijk naar de reeks van mij bekende succesvolle en mislukte
projecten, blijken de omvang en de complexiteit uiterst
belangrijke factoren. Decompositiemethoden en -technieken kunnen
hierbij de helpende hand bieden. Na de decompositie in
basiselementen bouwt men het proces opnieuw op, waarbij slechts
de volstrekt onmisbare elementen worden gebruikt. Op deze wijze
bereikt men een minimale verzameling van functionele
processen.
Onderdeel van de functionele architectuur en direct
gekoppeld aan het organisatiemodel is de wijze van besluitvorming
over automatiseringsprojecten. Betreft het automatisering binnen
een overzichtelijke afdeling dan loopt men weinig risico bij de
realisatie van een qua omvang en complexiteit beheersbaar
systeem. Vindt de besluitvorming via de top van de organisatie
plaats, dan zijn de risico's bij realisatie een stuk groter. Wie
bereidt de keuzes en afwegingen voor, hoe goed zijn de
directeuren in staat om de individuele en gezamenlijke
consequenties van de besluitvorming te overzien? Lange tijd deden
de projectleiders van geautomatiseerde systemen, die vaak vrij
zelfstandig konden opereren, weinig moeite om zich los te maken
van het vakjargon en in een voor de opdrachtgevers begrijpelijke
taal te communiceren. Pas na een reeks van publiek besproken en
beschreven mislukkingen is de persoonlijke betrokkenheid van
topbestuurders en managers op dit punt vergroot. Ook de wijze
waarop functionele modellen beschreven werden heeft niet tot een
helder inzicht in het verschil tussen automatiseren en
informatiseren geleid en daardoor de professionalisering van de
informatisering geen goed gedaan.
Als in de jaren zeventig en tachtig in de besluitvormende
vergaderingen de produkten van analisten en ontwerpers op tafel
kwamen, waren dat ordners vol met schema's en teksten zonder
overzicht, zonder samenhang maar met veel details in de bijlagen.
Vaak was één persoon niet meer in staat om het
overzicht en de samenhang te bewaken. Later is gebleken dat zo'n
aanpak op fiasco's uitloopt. Een van mijn zeer ervaren collega's
vroeg, als onderdeel van adviezen die hij gaf over een
informatiseringsproject, waar het ene velletje papier was waarop
hij de functionaliteit van het systeem in één
oogopslag kon zien. Was dat er niet, dan gaf hij de opdracht het
te maken; kwam het er niet dan gaf hij advies het project te
stoppen en een andere opzet en aanpak te kiezen. Veelal vonden
dan ook spelerswisselingen plaats.
Veel projectleiders en systeemontwerpers vertonen holistisch
gedrag, het liefst koppelen ze op papier alles aan alles.
Projectleiders met meer zelfbeheersing, die in het verleden
bewezen hebben binnen de afgesproken kosten en tijd hun produkten
op te kunnen leveren, zijn zeldzaam; zij moeten gekoesterd worden
door de organisatie en gestimuleerd om hun kennis en ervaring op
anderen over te dragen.
Over de functionele architectuur is nog veel meer te zeggen.
Bijvoorbeeld: wie bepaalt wie in de organisatie het gehele
systeem en delen van het systeem geautomatiseerd mag gebruiken?
Wie mag gegevens raadplegen, wie mag gegevens bewerken, wie mag
gegevens verwijderen? Het antwoord op deze vragen luidt veelal:
de functionele systeembeheerder of -beheerders. Vooral in sterk
gedecentraliseerde/gedeconcentreerde bedrijven en organisaties
wordt deze vraag niet op uitsluitend rationele gronden
beantwoord. Machtrelaties, relatieve autonomie, vertrouwen en
vooral wantrouwen spelen hierin mee. Ook hier geldt dat de
techniek steeds meer mogelijkheden biedt, maar niet minder waar
is dat men de techniek ook nog de baas moet blijven.
Eén van de meest aantrekkelijke ontwikkelingen van de
afgelopen tien jaar is dat er hulpmiddelen op de markt zijn
gekomen, waarmee men in enkele dagen de buitenkant, dit is de
gebruikerskant, van een systeem kan simuleren. Met het
simulatiemodel kan men participerend ontwerpen en daarbij komen
tot een beter mens-machine interface. Het zijn deze hulpmiddelen
die de nuttige bijdrage van de niet-informatici zichtbaar
vergroten. Vaak is het voor de traditioneel gevormde
automatiseerder moeilijk om een dergelijke stap naar nieuwe
werkwijzen te maken, maar dat is niet uniek voor
automatiseerders.
Technologische architectuur
Een informatietechnoloog 'pur sang' was zijn verhaal natuurlijk
met deze architectuur begonnen, om daarna de rest eraan te
relateren. Het is niet zonder reden dat ik er mee besluit, omdat
ik wil benadrukken dat de techniek de mens moet ondersteunen, en
dat de techniek niet de mens zal domineren. Dit principe
onderschrijft, zoals eerder gezegd, iedereen, maar in de
praktijk... Een vrij recente krantekop luidde: 'Computers nemen
de taak van de rechters over', en in het artikel stelde de auteur
dat, wanneer een computer iets beter/objectiever kan zijn dan de
mens, de computer de taken dan maar moet overnemen. Het debat
over dit onderwerp zal, zolang er mensen op aarde zijn, niet
eindigen. Het doordenken van de vraag in welke situaties de
menselijke arbeid vervangen kan en mag worden door machines, is
uiterst boeiend. Reeds lang zijn we blij dat onze salarissen via
nauwkeurige machines berekend worden: de willekeur van reken- en
schrijffouten werd snel en positief opgeheven bij de introductie
van computers. Maar een totale overname van het werk van
onderwijzend personeel door computersystemen lijkt ons momenteel
- en waarschijnlijk ook voor de toekomst - géén
ideaal. Wel moet men een afweging maken: waarin is de mens sterk,
wat doet hij zelf, wanneer schakelt hij de machine in om meer,
beter of sneller resultaat te krijgen? Waarbij de continue
beschikbaarheid van de machines een niet onbelangrijk element is.
Met betrekking tot de technologische architectuur zijn er
strategische beleidskeuzen te maken op het gebied van de
hardware, de software, de communicatie, de methodieken, de
technieken en hulpmiddelen bij de realisatie van toepassingen,
bij de keuze: kopen of maken, onderhoud uitbesteden of in eigen
beheer uitvoeren, wel of géén general purpose
rekencentrum, wel of géén standaardisering, bij de
bepaling van de hoogte van de jaarlijkse investeringen in de
infrastructuur en van de exploitatiekosten in mensen en middelen.
De te maken technologische keuzen moeten goed afgestemd
worden op de bedrijfscultuur van de organisatie, waarbij geldt
dat men bij veranderingen niet te grote stappen moet maken. Het
opereren van minicomputers, een nieuw systeem van doorbelasting
van kosten, om een paar voorbeelden te noemen, vereisen
zorgvuldige introductie. Na de inrichting van de rekencentra met
grote general purpose mainframe computers hebben we in de jaren
zeventig en tachtig de opkomst van de mini, de dedicated
computers, de afdelingsmachines. In de tweede helft van de jaren
tachtig zien we de machines op vier niveaus werken, van personal
computer/werkstation via mini en mainframe tot supercomputers.
Ook in de jaren negentig zullen de discussies over welke machine
het beste is voor een organisatie of organisatie-onderdeel nog
gevoerd worden. Ze worden met de nieuwe systeem- en
netwerkarchitecturen gelukkig steeds minder relevant, waardoor de
aandacht van de beleidsmakers zich kan richten op de
toepassingen, die door de technologische infrastructuur steeds
gevarieerder worden.
Een interessante vraag is ook, hoe het gebruik van personal
computers zich zal ontwikkelen. Het lijkt mij niet ondenkbaar dat
het aantal pc's per persoon - voorzover deze althans
computergebruiker is - zal oplopen tot drie. Uit eigen ervaring
weet ik, dat het gebruik van een werkstation effectief is wanneer
op het werk, onderweg en thuis met dezelfde systematiek en
uitwisselbare gegevens gewerkt kan worden. Maar zolang draagbare
pc's zwaarder zijn dan 2,5 kilo blijf ik de vulpen als aardig
alternatief gebruiken.
Voornamelijk door de ontwikkelingen van de tele- en
datacommunicatie-infrastructuren wordt de vraag: centrale of
decentrale oplossing? steeds vaker beantwoord met: geen van
beide, liever iets er tussen in. Dat betekent dus een systeem van
gedistribueerde computerfaciliteiten. Dit door de technologie
mogelijk gemaakte antwoord stelt wel weer geheel nieuwe eisen aan
de organisatie en aan de omgang van de organisatie met het
informatiesysteem.
Knelpunten en oplossingen
Naar ik hoop heeft het voorafgaande duidelijk gemaakt dat goed
informatiseringsbeleid pas kan worden gevoerd wanneer er binnen
de organisatie voldoende kennis, deskundigheid en ervaring is
opgebouwd met betrekking tot de mogelijkheden en beperkingen van
informatietechnologie. Het is niet verwonderlijk, dat er een
duidelijke kloof is tussen de praktijk van informatisering en de
voorhanden theoretische grondslagen in relevante vakgebieden als
kerninformatica, wiskunde, organisatiekunde en
psychologie.
Voor een evenwichtige en betrouwbare ontwikkeling van
methodieken voor de aanpak van informatiseringsprojecten is een
theoretische basis op de genoemde terreinen gewenst. Wat de
informatica betreft liggen er mogelijkheden om de kloof te
overbruggen in het opzetten van bijvoorbeeld software engineering
research centra en telematica-onderzoekcentra, en in het tot
stand brengen van samenwerkingsverbanden tussen wetenschappelijke
instituten, overheid en bedrijfsleven. Ook is het een goede zaak
dat steeds meer mensen een studie op hogeschool- of universitair
niveau afronden in een van de vele disciplines die de informatica
als geïntegreerd onderdeel van de studie kennen. Dat leidt
tot vakken als communicatiewetenschap, sociaal wetenschappelijke
informatica, rechtsinformatica, informatierecht, boek- en
informatiewetenschap, documentatie- en bestuurlijke
informatiekunde, alfa informatica, bedrijfsinformatiekunde,
informatiemanagement, electronic dataprocessing auditing,
medische, fysieke, neurale en biologische informatica, gamma
informatica, informatiesystemen, kunstmatige intelligentie,
telecommunicatie, datacommunicatie. Men moet hopen dat de
beoefenaren voldoende contact onderhouden met de kerninformatica,
zodat uit dat gebied komende nieuwe mogelijkheden hun niet
ontgaan.
Door de vorming en scholing van deze hoger opgeleiden van
goede kwaliteit en in voldoende aantallen, mogen we verwachten
dat de professionalisering van de informatisering gestaag
voortgaat, mits, nogmaals, de samenwerking tussen de
informatiseringsdisciplines onderling en tussen de andere
disciplines en de informatica door de opleiding wordt
bevorderd.
Een ander aspect vormt de al gesignaleerde technische
dominantie in informatiseringsprocessen, die er toe leidt dat de
hanteerbaarheid van systemen voor niet-technici belemmerd wordt.
Weinigen zullen beweren dat de MS-DOS-architectuur en
-verschijningsvorm of de IBM operating systemen en hun
doorwerking in de applicaties, merkbaar mensvriendelijk zijn. Om
hier verandering in te brengen zal een geheel nieuwe generatie
van systeemontwerpers opgeleid moeten worden die de problematiek
benadert vanuit het menselijk, functioneel, organisatorisch
handelen en die de informatiesystemen daarop laat aansluiten.
Gezien de huidige stand van zaken zal deze situatie nog jaren op
zich laten wachten.
De politieke en bestuurlijke aandacht voor
informatietechnologie is in Nederland nog beperkt. Werden in het
begin van de jaren tachtig veel stimuleringsfondsen gecreëerd
en stimuleringsprogramma's op nationale en Europese schaal
ontwikkeld, de resultaten van die programma's zijn nog zelden
tastbaar en zichtbaar en ze hebben de ervoor ijverende politici
vermoedelijk geen extra stemmen opgeleverd.
Op het bestuurlijke vlak is er wel veel geleerd, vooral door
schade en schande. Postdoctorale opleidingen leveren een
werkelijke aanvulling in dit nieuwe vakgebied. Als er
één mooi terrein te noemen valt voor éducation
permanente dan is het wel het informatiseringsgebied. Wanneer
gedurende enige jaren de ontwikkelingen niet bijgehouden worden,
dan heeft men een zodanige achterstand opgelopen, dat die slechts
met zeer veel inspanning ingehaald kan worden.
Uitgangspunt voor een goed informatiebeleid is dat er een
afstemming plaatsvindt tussen doel of missie van de organisatie,
verder uitgewerkt in een bedrijfsplan, en het
informatiseringsplan. Het informatiseringsplan bevat
beleidskeuzen, herkenbare prioriteiten en keuzen en fasering met
betrekking tot de uitvoering, zoals de nieuwbouw of vernieuwbouw
van informatiesystemen.
Voor de informatiseringsorganisatie moet gestreefd worden
naar een goede balans tussen lokale kennis, taken en
verantwoordelijkheden en het centraal samenbrengen van schaarse
deskundigheid op specialistische gebieden. De centraal
gesitueerde organisatie moet haar bestaansrecht bewijzen door aan
de lokale eenheden en de concernleiding waardevolle adviezen en
andere assistentie te geven. Bij het opzetten en onderhouden van
adequate bestuurlijke informatie is het van belang dat de
informatie van binnen uit de organisatie toegankelijk is, dat
deze tezamen met informatie uit de buitenwereld, geplaatst in
tijdreeksen, op goed leesbare en snel herkenbare wijze wordt
gepresenteerd. De verantwoordelijkheid voor de bepaling van
bestuurlijke informatie ligt idealiter dicht bij de strategische
planningorganisatie.
Het op orde hebben van de informatiesystemen, een goede
verzameling definities van bestuurlijke informatie en een
adequaat werkende administratieve organisatie zijn noodzakelijke
componenten voor een onderneming met een professioneel bestuur en
beheer.
|
|
