Managers gebruiken graag vuistregels. Zij geven snel richting en duidelijkheid. De communicatie is daardoor uiterst effectief. Een vuistregel is een kernachtige samenvatting van ervaringen. Hij heeft voorspellende waarde. Er wordt mee aangegeven wat in een bepaalde situatie de meest waarschijnlijke gebeurtenis zal zijn. Niets wordt sneller overgenomen door anderen dan vuistregels. Ook door mensen die niet zelf de ervaring hebben opgedaan waarop zij betrekking hebben. De regels gaan dan een eigen leven leiden en zijn vaak moeilijk uit te roeien.

Echt gevaarlijk worden ze, wanneer het domein waarop zij slaan sterk aan verandering onderhevig is. Je komt dan in een situatie waarin een vuistregel vaker niet waar is dan wel waar. Automatisering is zo’n domein. De volgende stellingen hebben hun kracht gedeeltelijk of totaal verloren; hoewel zij nog regelmatig gebruikt worden. 

Vuistregel 1: De automatisering moet naadloos aansluiten op de organisatie.

Deze regel is gebaseerd op de zienswijze dat organisaties en mensen in hun functioneren geen concessies zouden moeten doen aan beperkingen van de automatisering. Begin jaren zestig was het soms noodzakelijk mensen binaire of hexadecimale getallen of woorden te laten lezen. De vuistregel kreeg in de jaren zeventig een wijdere betekenis. Ook organisatorische procedures, werkafspraken, taak- en werkverdelingen mochten zo min mogelijk veranderd worden. De automatisering moest maar in staat zijn deze zaken één op één te automatiseren. Sommige onderzoeksmethoden zijn daarop gebaseerd. Minutieus worden de bestaande organisatie en procedures in kaart gebracht. Afdelingsgewijze automatisering is zo’n benadering. Sinds enkele jaren wordt hier totaal anders over gedacht. Vandaag zou de vuistregel moeten luiden: ‘De organisatie moet radicaal veranderd worden met behulp van informatietechnologie’. Business process management (BPM) is de onderliggende kennis- en ervaringswereld. Deze constatering gaat uit van de gedachte dat een organisatie gegroeid en gebaseerd is op de (beperkingen van de) menselijke communicatie, samenwerking en informatieverwerking. Door een organisatie opnieuw in te richten - maar dan gebruik te maken van elektronische faciliteiten - ontstaat een compleet andere structuur en een veel efficiëntere werkwijze. Overigens zou je kunnen stellen dat na een succesvol organisatieontwerp de IT pas echt goed aansluit op de organisatie. De vuistregel blijft dan woordelijk van kracht, maar heeft een geheel andere lading gekregen. 


Vuistregel 2: Redundantie moet vermeden worden.

Redundantie is het op meer plaatsen in bestanden voorkomen van dezelfde gegevens. Die gegevens moeten, wanneer zij gewijzigd worden, op alle plaatsen tegelijk worden aangepast, anders ontstaan er problemen. De inkoopprijs van een artikel zou dan bijvoorbeeld op de verkoopafdeling anders zijn dan op de inkoopafdeling. Er is nog een andere reden (geweest) waarom redundantie vermeden moest worden, namelijk: het besparen van ruimte op externe geheugens. In het project ‘Landelijke gezinsadministratie’ in de jaren zeventig werd berekend dat men voor elke letter of cijfer die bespaard kon worden, een huis kon kopen. Uit die tijd stamt ook de gewoonte om jaartallen niet aan te geven met vier cijfers (1995) maar met twee cijfers (95). De cijfers van de eeuw (19..) werden als redundant beschouwd. De kosten om een administratief- en automatiseringstechnisch correcte eeuwwisseling te realiseren liep wereldwijd nu in de miljarden dollars. Het vermijden van redundantie om geheugenruimte te besparen, levert vandaag de dag niet veel meer op. De vuistregel zou dan nog steeds van toepassing kunnen zijn op de organisatorische problematiek. Maar ook dat wordt steeds minder waar. Moderne softwaresystemen kunnen heel goed overweg met redundante gegevens. Een bepaalde redundantie kan een grote snelheidswinst opleveren. Snelheidwinst is tegenwoordig belangrijker dan ruimtebesparing. We gaan naar een tijdperk toe waarin we het niet erg vinden dat sommige gegevens organisatorisch redundant zijn, dat wil zeggen: waarschijnlijk nooit gebruikt zullen worden.

Vuistregel 3: Omissies in lijst- en schermpresentatie zijn niet zo erg. Als de bestanden maar goed zijn.

De gebruiker van een informatiesysteem raakt gefrustreerd wanneer in zijn overzicht de som van een reeks bedragen fout wordt weergegeven. Het standaardantwoord van de automatiseerder in zo’n situatie is dat er niets aan de hand is zolang de gegevens in de database maar juist zijn. De onderliggende gedachte is dat het oplossen van de fout tamelijk eenvoudig kan zijn. Waarschijnlijk is het aanpassen van één of enkele regels in het programma voldoende om het probleem de wereld uit te helpen. Wanneer de fout echter het gevolg is van bedragen die verkeerd in de database staan, kan de ellende grote vormen aannemen. Bestanden kunnen vervuild zijn door een programmafout of andere storing. Het corrigeren daarvan (bestanden en programma’s) kan lang duren en veel kosten met zich meebrengen. Deze vuistregel geeft aan hoe automatiseerders in grote lijnen nog steeds denken over het presenteren van gegevens op papier en beeldschermen. Het ontwerpen van de juiste systeem-, programma- en opslagstructuur is het moeilijkste werk. Het ontwerpen van lijsten en beelschermoverzichten is veel eenvoudiger. Vaak worden daarvoor minder begaafde dan wel leerlingprogrammeurs ingezet. In moderne systemen worden gebruikers vaak faciliteiten geboden, zoals rapportgeneratoren, om zelf de overzichtjes te maken. Het belangrijkste is tenslotte de structuur. Als er vandaag de dag iets is dat in de schijnwerpers staat, dan is het wel de presentatie van gegevens in woord, beeld, animatie, geluid en video. Multimedia is onstuitbaar de ICT binnengedrongen. Of je wilt of niet: de vormgeving en presentatie staan nummer één. Meer dan vroeger wordt nagedacht over hoe informatie overkomt of moet overkomen op gebruikers. Voorheen bestond het onderwerp ‘Formulier- en beeldschermindelingen’ maar uit één leseenheid. Tegenwoordig zijn complete cursussen gericht op presentatie van informatie. Of zoals een directeur van een hotelketen, die zich persoonlijk bemoeide met het ontwerp van beeldschermindelingen, het zei: “Mijn beeldschermpresentatie is veel belangrijker dan jullie automatiseringsstructuur. De schermen moeten directief zijn voor mijn medewerkers in tientallen hotels. Op elk moment moet iemand achter de receptie door iemand anders vervangen kunnen worden. Het beeldschermoverzicht moet zo duidelijk zijn dat dit eenvoudig mogelijk is.” Met andere woorden: eerst de presentatie en dan de structuur. 

Vuistregel 4: Grote bedrijven hebben meer voordeel van automatisering. 

Deze vuistregel komt voort uit oude en niet meer geldende succescriteria van automatisering. Vroeger waren grote informatiesystemen een voorwaarde voor succes. Hoe meer transacties van dezelfde soort, hoe beter. Hoe groter de bestanden, hoe beter toepasbaar de automatisering. Dat had te maken met de toenmalige computertechnologie. De mainframes in de jaren zestig en zeventig kostten miljoenen euro's. En daar bleef het niet bij. Een vuistregel was: ‘De introductie van automatisering kost drie computers’. En de ontwikkeling van systemen en het beheer kostten elk nog eens het equivalent van zo’n aanschaf. Deze vuistregel wordt door niemand meer gebruikt. De kosten van de apparatuur zouden nu slechts een zeer beperkt deel mogen uitmaken van het totale automatiseringsbudget. In de jaren zeventig en tachtig domineerden de minicomputertoepassingen. Automatisering kwam economisch binnen het bereik van middelgrote bedrijven. Hoewel de kosten nog altijd opliepen tot enkele honderdduizenden guldens. Pas met het volwassen worden van PC-toepassingen (en de daarbij behorende ontwikkelingen op softwaregebied) konden ook kleine bedrijven met succes automatiseren. De budgetten daarvoor begonnen bij enkele tienduizenden euro's. De kwaliteit en geavanceerdheid van die automatisering hoeft niet onder te doen voor de automatisering in grote ondernemingen. Het probleem van de automatisering in grote bedrijven is de besluitvorming over de vernieuwing van informatiesystemen. Men zit met een vervelende erfenis. Legacy-systemen is een professionele uitdrukking geworden. Grote organisaties hebben een remmende voorsprong ten opzichte van het midden- en kleinbedrijf. In kleine ondernemingen gaat bovendien de besluitvorming over de toepassing van moderne informatietechnologie meestal veel sneller en is niet politiek getint. De vuistregel kan vandaag worden omgedraaid: ‘Kleine bedrijven profiteren meer van automatisering dan grote’. 
 

Vuistregel 5: Specificaties van een informatiesysteem worden gemaakt voor de opdrachtgever/ gebruiker.

Men zal zich afvragen wat er met deze stelling aan de hand is. Dit is immers altijd het geval geweest in de automatisering. Ook opdrachtgevers vinden deze zienswijze zo logisch dat daarover nauwelijks wordt gediscussieerd. We bevinden ons echter in een tijd waarin het nodige op deze vuistregel valt af te dingen. De problemen met het specificeren van een informatiesysteem op basis van de wensen van de opdrachtgever zijn bekend. De echte (of alle) wensen zijn moeilijk boven tafel te krijgen. Verder is de transformatie van wensen naar specificaties geen eenvoudige zaak. Specificaties zijn niet altijd eenduidig of een juiste vertaling van de wensen. Ten slotte confronteren we de opdrachtgever met de vastlegging van zijn wensen in de vorm van specificaties. Vaak zijn deze specificaties op een manier omschreven dat opdrachtgevers ze niet kunnen bevatten. Toch moet de opdrachtgever formeel deze specificaties goedkeuren alvorens tot de realisatie in de vorm van programmatuur kan worden overgegaan. Vertegenwoordigers uit de school van het ‘formeel specificeren’ wijzen op de gebrekkige wijze van het tot standkomen van die specificaties. Dat is juist. Het kan altijd beter. Maar de toepassing van dergelijke formele methoden zijn voor een opdrachtgever ook niet eenvoudig te volgen. Als er eenmaal specificaties zijn, is het wijzigen daarvan meestal niet zonder grote gevolgen. Daarom worden specificaties na goedkeuring bevroren. Veranderingen tijdens de bouw zijn immers moeilijk, duur en problematisch. Wanneer wordt gewerkt op basis van vaste prijsafspraken wil de automatiseerder terecht afbakenen wat wel en wat niet in de vaste prijs begrepen is. Vaak is het meer werk ten opzichte van de specificaties, maar niet meer werk ten opzichte van de uitgangssituatie van de opdrachtgever. Het ontstaan van deze problemen heeft te maken met de beperkingen van het ontwikkelen van programmatuur. Moderne ontwikkelingmethodieken zoals Normalized Systems bieden faciliteiten om eenvoudig veranderingen aan te brengen in bestaande systemen en dus ook in systemen in de bouwfase. De vraag is gerechtvaardigd waarom men zich zo verschrikkelijk inspant om in extenso dingen vast te leggen. We weten dat dit maar tot op zekere hoogte lukt. We weten ook dat opdrachtgevers er ongelukkig mee zijn, omdat zij juist tijdens de bouw pas zien wat de mogelijkheden zijn of wat het resultaat wordt van al die voorbereidingen. Opdrachtgevers zijn gebaat bij een ruimere definitie van systemen, met marges waarbinnen wijzigingen mogelijk zijn. Een goede vaststelling van het doel van het systeem kan dan helpen, want een simpel personeelregistratiesysteem mag niet al wijzigend ontaarden in een carrièreplanningssysteem. De vuistregel is begrijpelijk vanuit de beperkingen van een oude technologie, maar is eigenlijk altijd al onjuist geweest. Opdrachtgevers hebben geen behoefte aan specificaties. Automatiseerders hebben er behoefte aan. Een prikkelende (tegen)vuistregel zou daarom zijn: ‘Specificaties vormen het vangnet voor de automatiseerder’. 

Vuistregel 6: Standaardpakketten zijn goedkoper en sneller implementeerbaar. 

Deze vuistregel vindt zijn oorsprong in de jaren zeventig. Vòòr die tijd werden programma’s specifiek voor één klant geschreven. Maatwerkontwikkeling betekende dat veel voorkomende functies, zoals bijvoorbeeld beeldschermopmaak, elke keer opnieuw voor de klant gecodeerd moesten worden. Dit coderen was een tijdrovende en kostbare zaak. Vanaf de jaren zeventig begonnen softwarebedrijven reeds eerder ontwikkelde programma’s aan andere klanten te verkopen. Zo ontstond geleidelijk het standaardpakket. Het programmeren werd beperkt tot extra specificaties voor een klant. De klant op zijn beurt selecteerde het pakket dat het beste aansloot bij de organisatie, dat wil zeggen: de minste aanpassing behoefde. De onderliggende gedachte van een standaardpakket is het hergebruik van programmacode. Vanaf de jaren tachtig kwamen steeds meer gereedschappen beschikbaar, zoals libraries, generatoren en objectgeoriënteerde programmeeromgevingen. Het daadwerkelijk coderen wordt tegenwoordig als het ware weggeautomatiseerd. Het ontwikkelen op maat kan daardoor betrouwbaarder, sneller en dus goedkoper gebeuren. Een ander voordeel van standaardpakketten zou zijn dat de functionaliteit door een softwarehuis wordt aangeboden. Aanvullende en nieuwe mogelijkheden komen beschikbaar in nieuwe versies. De oude klant-specifieke aanpassingen moeten dan wel eenvoudig in nieuwe versies opgenomen kunnen worden. Als dit niet of slechts gedeeltelijk automatisch mogelijk is, vervallen veel voordelen van een standaardpakket. Als de omvang van de wijzigingen op het standaardpakket gering is, heeft de vuistregel zeker waarde. Bij omvangrijke wijzigingen, bijvoorbeeld enkele manjaren programmeerwerk, is de geldigheid van de vuistregel afhankelijk van de onderliggende technologie van het pakket. Als het een verouderde technologie betreft, zou in zo’n geval het zelf ontwikkelen in een nieuwe technologie een betere keuze zijn. De vuistregel is grotendeels situationeel en daarmee niet geschikt om als uitgangspunt te dienen bij beslissingen. 

BronAutomatiseringsgids