Skip to main content

Ruim een jaar geleden ben ik afgestudeerd. Collegebanken, werkcolleges, studieboeken en casussen behoren tot het verleden. Vrienden die nog studeren vragen mij vaak: “Verschilt je studie erg van de praktijk?” De enige praktijk tijdens je studie is vaak de casus in je studieboek. En ondanks de dappere pogingen van de auteurs zijn deze casussen helaas niet representatief voor de praktijk. Neem de bedrijven die gebruikt worden in de casus, voornamelijk bedrijven in de categorie ‘hypermodern en innovatief’. Denk aan Google, Facebook, Apple en Tesla. Hightech, vooruitlopend op de markt, enthousiaste medewerkers en vrijwel geen beperkingen zoals geld en tijd. Dat de casuïstiek uit je studieboeken verschilt met de realiteit zal geen verrassing zijn, maar op welke gebieden?

Vooropgesteld, de praktijk is veel complexer en lastiger dan ik mij voorstelde tijdens mijn studie. Maar heel soms is de werkelijkheid zoals in de studieboeken: de organisatie begint met het in kaart brengen van de eisen en wensen van de stakeholders, stelt op basis daarvan user stories op, bepaalt functionele en technische specificaties en dan er wordt gebouwd. Beperkingen (technisch en/of financieel) lijken er nauwelijks te zijn.

Tot zover de ideale situatie die vaak geschetst wordt in de casus en geambieerd wordt in de praktijk.  Er wordt een helder projectplan opgesteld en iedereen gaat enthousiast aan de slag. En dan komen de eerste verrassingen. Bijvoorbeeld door een grotere functionele- of technische complexiteit dan werd verwacht, tekortschietend draagvlak of een veranderende projectomgeving. Daardoor duurt de ontwikkeling van het nieuwe systeem langer en vallen investeringen hoger uit. Het uitfaseren van oude systemen duurt langer waardoor besparingen lager uitvallen. Het project lijkt op een dood spoor te zijn beland en de directie eist verbetering.

Dit heb ik zelf meegemaakt bij een project waar ik driekwart jaar bij betrokken ben geweest. Het project was een lastige implementatie van een complex informatiesysteem. Bijvoorbeeld door de migratie van de bestaande database; historie mag immers niet verloren gaan. Mijn ervaring is dat het erg complex kan zijn om een migratie te voltooien wegens een gebrek aan kennis binnen de organisatie over de bestaande database. De database bestaat al vele jaren, de mensen die de database ontworpen hebben werken niet meer bij de organisatie en er is geen goede documentatie bijgehouden. Eerder regel dan uitzondering in de praktijk…

En dan het menselijk aspect van organisatieontwikkeling. Vakken zoals “Organizational Behaviour” en “Project Management” zijn vaak niet de lastigste tentamens tijdens je studie, maar in de praktijk zijn dit meestal de grootste uitdagingen. Draagvlak onder medewerkers is essentieel maar lastig te beïnvloeden. Tijdens het project hoorde ik bijna elke dag uitspraken als: “wat een geldverspilling”, “er wordt al vijf jaar geroepen dat het informatiesysteem elk moment kan worden geïmplementeerd”, “wij willen niet, management wil dit” en de meest gehoorde: “eerst zien, dan geloven”. Toch zijn de medewerkers essentieel voor het ontwikkelen van een nieuw informatiesysteem. Zonder hun input en medewerking heeft een project geen enkele kans van slagen want de medewerkers hebben kennis van de werkprocessen. De werkprocessen moeten worden gevat in business rules (formele uitwerking van de werkprocessen, procedures en protocollen die gelden in een organisatie) in het informatiesysteem. Zonder draagvlak komt deze kennis niet boven tafel en zal het project falen.

Ook het draagvlak binnen het management is cruciaal en is niet zomaar vanzelfsprekend, zelfs als management jouw opdrachtgever is. In de praktijk blijkt regelmatig een verschil tussen zeggen en doen. ‘Ja’ is niet per definitie ‘ja’, maar regelmatig ‘misschien’ of soms zelfs ‘nee’. Zo ook onlangs tijdens een overleg met een projectleider en opdrachtgever over de voorbereiding van een workshop. Doel van de workshop was om hun project te evalueren en de doelstellingen voor het vervolgproject te definiëren. Vanwege de beperkte beschikbare tijd voor de workshop hebben wij, de consultants, meerdere malen benadrukt dat er gelet moet worden op de tijd. Natuurlijk, opdrachtgever en projectleider waren het helemaal met ons eens. Maar op de dag zelf gaf de projectleider een veel te lange introductie en werd door een van de projectleden, op verzoek van de projectleider, een uitgebreide productpresentatie gegeven. Nog voordat de workshop feitelijk was begonnen, was de planning vakkundig om zeep geholpen door de projectleider… Dat roept natuurlijk meteen de vraag op: “Wil de projectleider eigenlijk wel een grondige evaluatie van zijn project?” Nee, want het project heeft niet opgeleverd wat beoogd was en de projectleider wilde geen grondige evaluatie van zijn functioneren. Dus, de medewerking van medewerkers, projectleiders en opdrachtgevers is niet vanzelfsprekend. Zelfs niet als er overeenstemming lijkt te zijn. De kunst is om als consultant hier op een handige manier op in te spelen en flexibel genoeg te zijn om hier mee om te gaan. Hiervoor moet je erkennen dat er nou eenmaal belangen zijn, dat je met mensen werkt die hun eigen beperkingen hebben en dat je de context wat kunt oprekken maar niet zomaar kunt veranderen. Daarnaast is het belangrijk om te beseffen dat heel veel beïnvloeding niet op de formele momenten plaatsvindt, maar juist via de informele route.

Een ander thema waar de casuïstiek in studieboeken geen aandacht aan besteedt is de samenhang met andere systemen. Er zijn vrijwel geen bedrijfssystemen die niet gekoppeld zijn met andere systemen zoals bijvoorbeeld het financiële systeem. Het goed ontwerpen, ontwikkelen en testen van koppelingen is een deelproject op zich. Het wordt nog spannender als koppelingen gelegd worden met ketenpartners, wat in toenemende mate voorkomt. Andere databases, andere business rules, andere mensen en uiteenlopende belangen.

Informatisering door de gehele keten brengt nog andere uitdagingen met zich mee, zo heb ik onlangs ervaren tijdens een ander project. Stel, organisatie A schaft een nieuw informatiesysteem aan waardoor organisatie B betere informatie tot haar beschikking krijgt en daardoor efficiënter kan werken. De keten wordt hierdoor efficiënter, maar zal organisatie A dit zomaar doen? Hoogstwaarschijnlijk niet want organisatie A maakt de kosten maar organisatie B ontvangt de baten. Tegenstrijdige belangen die lastig op te lossen zijn en eerder regel dan uitzondering zijn bij keteninformatisering. Nog afgezien van de complexiteit op het gebied van bijvoorbeeld definities, techniek, migratie- en informatiestandaarden. Het zijn de grote uitdagingen waar organisaties voor staan de komende jaren en daar kunnen wij als informatiekundigen een belangrijke rol in spelen.
Terugkomend op de vraag: “Verschilt de praktijk erg veel van de theorie?” Absoluut, maar het is daardoor veel leuker! Tijdens mijn studie overzag ik niet het belang van bestaande systemen en databases, draagvlak onder medewerkers, koppelingen met andere systemen en ketenvraagstukken. Dat leer je niet in een casus, dat leer je in de praktijk. En hoe ga je om met deze uitdagingen? Deels door een uitgebreide analyse in de beginfase van het project. Alleen door de huidige situatie te doorgronden kan je voorzien welke uitdagingen je gaat tegenkomen in de ontwikkeling van een nieuw systeem. Maar een grondige analyse voorkomt niet dat je verrassingen tegenkomt op inhoudelijk, technisch, organisatorisch én menselijk vlak. Dat maakt het werk van een consultant zo leuk en uitdagend!

Leave a Reply