Functioneel beheer van ICT-gebruik en gebruikers

Hoe krijg je als middelgrote organisatie een goede informatievoorziening

Natuurlijk weet je dat jouw organisatie afhankelijk is van de informatievoorziening en dat daarom de inzet van ICT noodzakelijk is. Natuurlijk weet je ook dat de meeste managers niet bekend hoeven te zijn met de ICT-technologie en niet op de hoogte hoeven te zijn van de terminologie die door ICT’ers gebruikt wordt. En natuurlijk weet je dat de communicatiekloof tussen business en ICT vaak wel erg groot is en dat dat dikwijls tot wederzijdse irritaties leidt. Maar ja, iedere specialistische afdeling heeft zijn eigen jargon. En als ze elkaar op de ICT-afdeling onderling zo gemakkelijker begrijpen, dan moet dat maar. Maar laten ze dan ook die ICT maar lekker regelen, eventueel met één of meerdere leveranciers. Ze moeten faciliteren zoals elke facilitaire afdeling. En de business geeft wel aan wat de behoefte is.

Onze ICT werkt, maar werkt ICT ook voor ons?

Als je dit herkent vanuit jouw eigen organisatie, dan weet je dat de ICT-technologie in jouw organisatie misschien wel werkt, maar vaak niet voor u. Want jouw informatievoorziening laat te wensen over. En dat is techneuten niet aan het verstand te peuteren. je vraagt iets en ze beloven het te regelen. Wat ze maken ligt echter vaak zover af van wat je wilt, dat je besluit om dan maar genoegen te nemen met inferieure oplossingen.
Een effectieve en efficiënte inzet van ICT wordt lastig als die communicatiekloof niet wordt overbrugd. Oplossingen worden vanuit de ICT-wereld vaak gezocht in innovatieve aanpakken als Rup, Scrum, Agile, SOA, Togaf, Archimate, Requirementsanalyse, MSP, Prince2, PMBok, ITIL, ASL, BiSL en zo nog een paar honderd. Maar het probleem wordt hiermee NIET opgelost. Eigenlijk wordt het alleen nog maar weer groter gemaakt. Want genoemde aanpakken betreffen vaak deeloplossingen die weer nieuwe specialisaties opleveren en nieuwe terminologie introduceren.
Het is noodzakelijk dat de business (dus directie, MT, afdelingsmanagers) haar verantwoordelijkheid neemt inzake informatievoorziening. Ieder krijgt wat hem of haar toekomt. Een auto kopen zonder van kennis van zaken levert in immers ook niet de best deal op.

En wat is de oplossing?

Wat is dan de oplossing? Dè oplossing bestaat niet. Er is niet één aanpak die goed is in alle situaties. Het is noodzakelijk dat de business (dus, nogmaals, directie, MT, afdelingsmanagers) meer kennis verwerft over ICT, de mogelijkheden die ICT biedt en, tot op zekere hoogte, de terminologie die daarbij gebruikt wordt. De business moet de verantwoordelijkheid nemen voor een goede informatievoorziening en de regie hierover pakken.
Dit artikel gaat in op 4 veel voorkomende problemen bij het vernieuwen van de informatievoorziening:

1. Een nieuw informatiesysteem (synoniemen: software, applicatie, pakket, ICT-systeem, systeem) invoeren heeft meestal meer consequenties dan in eerste instantie gedacht. Zorg voor een goede zakelijke rechtvaardiging (synoniem: business case) voordat je tot zo’n investering overgaat; de kans dat je bedrogen uitkomt is anders erg groot.
2. Als je een nieuw informatiesysteem overweegt, weet dan wat je echt nodig heeft. Het opstellen van het programma van eisen (synoniemen: specificaties, requirements) lijkt gemakkelijk, maar is het niet. In de praktijk komt het vaak voor dat het onvolledig (bijvoorbeeld ‘identiek aan bestaande systeem, maar dan ook…’), te uitgebreid (proza) of onduidelijk (voor meerderlij uitleg vatbaar) gebeurt.
3. Meestal wordt een nieuw informatiesysteem niet meer op maat gemaakt, maar wordt een reeds bestaand pakket gekocht. Vaak hebben pakketten mogelijkheden om te worden aangepast aan de behoefte van de organisatie. De manier waarop maatwerkaanpassingen gedaan kunnen worden zijn zeer divers: configureren of maatwerkaanpassingen. Sommige systemen zijn dermate configureerbaar (synoniem: aanpasbaar) dat ze lijken op een “bouwdoos” of een ontwikkelomgeving waarmee het systeem nog gebouwd moet worden. Door leveranciers van informatiesystemen kan dan makkelijk gesteld worden dat aan alle gestelde eisen voldaan kan worden. Maar het kiezen van het beste systeem voor jouw situatie vergt een zorgvuldig selectieproces. Zeker omdat er méér zaken van belang zijn dan alleen de geboden functionaliteit.
4. Wanneer je de keuze heeft gemaakt voor een bepaald informatiesysteem dan wordt dat systeem geïnstalleerd en in gebruik genomen. Het implementatie- of invoeringstraject kan in sommige situaties een groot veranderproject impliceren, met de nodige risico’s. Zeker als het gaat om informatiesystemen waardoor bedrijfsprocessen (in de business) gaan veranderen, als er veel gebruikers van het informatiesysteem zijn en als de bedrijfsgegevens van het oude naar het nieuwe systeem moeten worden overgeheveld.

In de volgende hoofdstukken wordt voor elk van de 4 bovenbeschreven problemen een best practice beschreven.

Business case basis voor goede ICT

“Een goed begin is het halve werk.”
Voor ICT-projecten is het goede begin: de business case.

Een business case is meer dan een stuk papier en meer dan een kosten/baten analyse.
Een echte business case is de onderbouwing van een voorgenomen verandering. De verandering wordt in alle aspecten in kaart gebracht: de voordelen, de risico’s, de noodzakelijkheden, de kosten en andere implicaties. Er is een bepaalde mate van zekerheid nodig, zonder meteen al erg hoge kosten te maken (denk daarbij aan zo’n 5 % van de verwachte projectkosten). Een goede business case wordt gedragen door de stakeholders. Dit vereist dat de business case tot stand komt in een vlot lopend proces met een goede communicatie, waarbij weerstanden tegen de verandering zoveel mogelijk worden weggenomen. De business case verschaft besluitvormers het middel om te sturen. In de eerste plaats om de Go / No go beslissing te nemen en vervolgens om zo te sturen dat de baten ook daadwerkelijk gerealiseerd worden en de kosten binnen de verwachting blijven.
In de business case komen de volgende onderwerpen aan bod:

• het “waarom” van het project;
• de baten (zoveel mogelijk kwantitatief) en de wijze waarop de baten gerealiseerd gaan worden;
• de kosten en tijdsaspecten;
• de uitgangspunten en aannames;
• de investeringsbeoordeling (terugverdientijd, rendement);
• alternatieven en conclusie.

Gedurende het hele project blijft de business case het ijkpunt waarop de stuurgroep beslist over onvoorziene omstandigheden. Door de focus op de business case wordt bereikt dat er geen energie wordt verspild aan projecten die onvoldoende bijdragen aan de doelstellingen van de organisatie.

Welke eisen stel ik aan het nieuwe systeem?

Allereerst is het belangrijk dat je zich realiseert wat je nu eigenlijk verwacht van jouw leverancier. Een veel voorkomend misverstand is de veronderstelling dat een ICT-leverancier een systeem levert en dat de klant verantwoordelijk is voor het gebruik ervan. Dit is een te simpele voorstelling van zaken. We onderscheiden 4 niveaus van commitment:

1.  levering AS-IS;
   De leverancier is tot niet meer verplicht dan het pakket in de huidige staat (met al z’n onvolkomenheden) te leveren.
2. conformance to specification;
   De leverancier moet er voor zorgen dat het product aan de, vaak zelf geschreven, specificaties voldoet. Zijn de specificaties niet goed? Jammer dan, probleem van de klant.
3. fitness for use;
   De leverancier moet er voor zorgen dat het ICT-systeem gebruikt kan worden.
4. fitness for purpose
   De leverancier moet er voor zorgen dat de klant de door hem gestelde doelen met het IC- systeem gaat realiseren.

Niveau 4 gaat wel erg ver, maar niveau 1 en 2 zijn aan de andere kant wel erg in het voordeel van de ICT-leverancier. Een succesvolle implementatie van een ICT-systeem vereist commitment van de ICT-leverancier en van jouw eigen organisatie.
Om de eisen voor een nieuw informatiesysteem op te stellen, IT’ers noemen dit de specificaties of requirements, is een goede samenwerking nodig tussen de business en de IT’ers die het systeem gaan ontwikkelen. Een goed wederzijds begrip, een goede communicatie en een goed proces zijn noodzakelijk om een compleet en consistent eisenpakket op te stellen. Moderne aanpakken en technieken als Agile, Scrum, UML, Requirements Engineering beogen het opstellen van de requirements in goede banen te leiden. Bedenk hierbij altijd dat de aanpak en de methode dienstbaar moeten zijn aan het doel. De communicatiekloof tussen business en IT kan soms erg groot zijn. Er wordt aan beide zijden jargon gehanteerd zonder dat partijen zich dit realiseren. De requirements zijn belangrijk voor zowel de opdrachtgever (management), de ontwikkelaars (externe leverancier of eigen ontwikkelafdeling), de testers  als de gebruikers van het systeem. De requirements vormen als het ware de brug tussen business en IT. Fouten (waaronder omissies) in requirements kunnen zeer duur zijn. (Zie ook het artikel Betere software door product- of proceskwaliteit’.)

Ook als de intentie bestaat om een reeds op de markt bestaand pakket te kopen is het belangrijk om requirements op te stellen. Op basis hiervan worden alternatieve pakketten vergeleken. Daarnaast is het zo dat de meeste ICT-systemen erg flexibel (configureerbaar, aanpasbaar) zijn en dat er een grijs gebied is tussen een pakket en een maatwerksysteem. Nadat een pakket is gekocht zijn er dus nog vele keuzes te maken voordat er een gebruiksklaar systeem is.
Een programma van eisen bestaat uit de volgende onderdelen:

• de verbeteringen die de business wil doorvoeren in nieuwe of bestaande bedrijfsprocessen;
• de taken of activiteiten die gebruikers met het systeem gaan uitvoeren;
• de functionaliteiten die het systeem moet hebben om in de behoeften te voorzien;
• niet-functionele eisen zoals betrouwbaarheid, bruikbaarheid, efficiency, onderhoudbaarheid en overdraagbaarheid;
• eisen met betrekking tot leverancier, oplevering, kosten, werkwijze, techniek etc.

De eisen waaraan het systeem moet voldoen zijn niet alle even belangrijk. Het is een goed gebruik om ze te prioriteren met behulp van MoSCoW: Must have, Shoud have, Could have en Would have.
Tegenwoordig worden binnen de meeste organisatie vele ICT-systemen gebruikt (10-tallen en soms 100-tallen), welke in toenemende mate met elkaar verbonden zijn. Het is belangrijk om suboptimalisatie te voorkomen; hiervoor is een totaalbeeld van de informatiehuishouding met relaties tussen de verschillende domeinen nodig. Kortom: een centraal overzicht danwel een gemeenschappelijk referentiekader, een blauwdruk van de bedrijfsprocessen met daaraan gerelateerde een blauwdruk van de informatievoorziening (enterprise architectuur) is noodzakelijk. Het is nodig om de gevolgen van elke verandering te kunnen overzien en te borgen dat het gewenste effect gerealiseerd gaat worden.

Hoe selecteer ik een nieuw systeem?

Het is goed om van te voren afspraken te maken over het hele proces van pakketselectie, zoals  bij voorbeeld over: Hoe lang gaan we erover doen? Wie neemt, op welk moment welke beslissingen en op basis waarvan?
Bij het uitvoeren van een pakketselectie is het goed om ook zelf actief te zoeken. De ICT-leveranciers in de markt zijn over het algemeen erg actief in het benaderen van hun potentiële klanten. Maar er is meer: denk breder en overweeg ook andere (wellicht niet-ICT) oplossingen.

In de business case maak je duidelijk wat je van het ICT-systeem verwacht. In de voorselectie komt je tot een beperkt aantal ICT-leveranciers waar je mee in gesprek gaat. Door de leveranciers worden de pakketten gepresenteerd. Het is voor je belangrijk om deze sessie goed voor te bereiden en het programma van eisen hierbij als leidraad te gebruiken. Geen enkel pakket zal aan al jouw eisen en wensen voldoen. je zoekt naar de beste match tussen jouw eisen en wensen en de mogelijkheden van het ICT-systeem. Een goed inzicht in de hardheid van jouw eisen en wensen is daarbij een must.
Er wordt nogal eens gemakkelijk gedacht over het implementeren. Een goed advies is om vooraf een risico- en impactanalyse te maken.  Dan weet je waar je afspraken over moet maken met jouw leveranciers en kunt je een gedegen plan van aanpak maken voor de implementatie. Let wel: implementatie kent een technische kant en een bedrijfsmatige kant.
Evalueren van het traject is altijd nuttig. Enerzijds om vast te stellen of het traject geslaagd is of wellicht bijsturing vereist, anderzijds om hiervan te leren voor volgende trajecten. De evaluatie wordt nogal eens overgeslagen. Jammer, want later is de kennis weggezakt en zijn de betrokken medewerkers niet meer beschikbaar.
Het proces eindigt met een decharge zodat het voor iedereen duidelijk is dat deze fase is afgesloten.

Hoe zorg ik ervoor dat het nieuwe systeem goed wordt ingevoerd?

Er zijn (grotere) organisatie waarbij op regelmatige basis nieuwe ICT-systemen in gebruik worden genomen. De expertise om deze trajecten te begeleiden is dan meestal in huis beschikbaar. Lastiger is het in middelgrote en kleinere organisatie waarbij grote veranderingen in de informatievoorziening maar af en toe voorkomen. Het is dan goed om de selectie en invoering van een nieuw ICT-systeem bewust als project te gaan uitvoeren.

Een ICT-project is een geheel van activiteiten met als doel een werkend informatiesysteem te realiseren in jouw organisatie. Dit doel moet gerealiseerd worden met beperkte middelen in een bepaalde tijdsperiode. Opdrachtgevers van ICT-projecten dienen bij elk project dat ze opstarten te bedenken welke projectorganisatie en projectaanpak daar het beste bij passen. Want ervaringen in de afgelopen decennia leren dat het oorspronkelijke projectdoel vaak niet wordt gehaald, dat de toegekende middelen niet toereikend zijn en dat de geplande einddatum niet wordt gehaald.

Nogal eens wordt er één projectmanager aangesteld die het project moet gaan runnen. Dit past lang niet bij elke situatie. Bekijk per project de taken van de projectleiding en overweeg of deze bij één of meerdere personen worden belegd. Overweeg tevens of het project gediend is bij een projectmanager die onafhankelijk staat ten opzichte van de leverancier van het ICT-systeem. Indien het draagvlak aan de gebruikerskant een belangrijk onderdeel is van het takenpakket kan het verstandig zijn een gebruikersprojectleider aan te stellen. Het aanstellen van een (of meerdere) projectmanager(s) ontslaat je als opdrachtgever van het project niet van de verantwoordelijkheid voor het project. Elk project hoort een stuurgroep (project board) te hebben. Volgens de meest gehanteerde projectmanagementaanpak Prince2 hebben hierin zitting de business executive, de senior user en de senior supplier, dus de manager die het grootste businessbelang heeft bij het projectresultaat, de hoogste verantwoordelijke aan de gebruikerskant en de hoogste verantwoordelijke aan de leverancierskant. Met deze vertegenwoordiging in de stuurgroep wordt het voor projectmanager mogelijk om onoplosbare problemen aan te kaarten, zodat ze opgelost kunnen worden.

De eerder genoemde projectmanagementaanpak Prince2 is een bewezen aanpak die echter wel op maat gesneden moet worden. In de praktijk leidt dit “op maat snijden” vaak tot een middelmatige aanpak die niet leidt tot een succesvol resultaat.

Dus een volgende keer gaat alles goed?

In dit artikel hebben we een viertal veel voorkomende problemen besproken. Niet alle problemen zijn te voorkomen, maar met een basis bestaande uit een goed uitgewerkte business case, een scherp beeld van de gewenste situatie en een goed georganiseerd en gemanaged project worden eventuele problemen snel ontdekt, zodat ze gemakkelijker uit de wereld kunnen worden geholpen.