Het onderwijs digitaliseert, maar niet altijd succesvol

Het onderwijs digitaliseert. Denk daarbij aan het gebruik van elektronische leeromgevingen en (zoals streaming videotoepassingen). De digitalisering speelt ook bij de onderwijsondersteunende processen, zoals studievoortgang-, financiële en HRM-administraties. Binnen het onderwijs zijn nieuwe behoeften ontstaan voor de ondersteuning bij, en de uitvoering van, deze onderwijsondersteunende processen. Instellingen willen de processen doelmatiger en efficiënter inrichten, zonder dat daarbij de kwaliteit van het onderwijs wordt aangetast. Sterker nog, de vrijkomende financiële middelen dienen juist meer ten goede te komen aan het primaire proces: het onderwijs.

De rol van financiële administratie verandert van een puur registrerende functie naar een strategisch en beleidsmatig onderdeel van de bedrijfsvoering. Binnen HRM verbreedt het gezichtsveld zich van pure personeelsregistratie en salarisadministratie naar onder andere formatieplanning, performancemanagement (beoordelen en functioneren), opleiding en loopbaanplanning. Voor alle onderwijsondersteunende processen geldt dat er een toenemende behoefte bestaat aan adequate, betrouwbare, eenvoudig toegankelijke en flexibele (op maat gesneden) stuurinformatie. Hierbij bestaat tevens de behoefte om niet alleen op centraal niveau, maar ook op decentraal niveau rapportages te kunnen genereren.

De systemen die momenteel binnen het onderwijs worden gehanteerd, zijn qua techniek veelal verouderd, en bieden onvoldoende ondersteuning aan de uitgebreidere gewenste functionaliteit. De introductie van de backoffice en de shared service centers, en de vraag naar standaardisatie en integratie van IT hebben de vraag naar ordentelijke IT-ondersteuning daarbij alleen maar verder doen toenemen.

De belangstelling voor geïntegreerde systemen (waarbij meerdere processen door één systeem ondersteund worden, een bekend voorbeeld is Enterprise Resource Planning (ERP)) is de laatste jaren sterk toegenomen. Dit heeft geleid, en leidt nog steeds, tot diverse pakketselectie- en implementatietrajecten. In de praktijk verlopen deze projecten niet altijd naar wens. Met name grotere IT-projecten blijken complexer te zijn dan aanvankelijk is ingeschat. Niet goed lopende en zelfs mislukte IT-projecten zijn aan de orde van de dag. De vraag is of binnen het onderwijs specifieke succesfactoren zijn aan te wijzen die het welslagen van de projecten beïnvloeden.

Wat zijn nu de succesfactoren voor IT-projecten binnen het onderwijs …

Ook bij onderwijsinstellingen zien we implementatietrajecten die niet het gewenste resultaat opleveren. Zowel binnen pakketselectietrajecten als de daaruit volgende implementatietrajecten geldt dat een gestructureerde aanpak het succes van IT-projecten kan vergroten. Succesfactoren binnen deze trajecten zijn voor organisaties in het algemeen beschreven in diverse literatuur (zie bijvoorbeeld [Donk05] en [Moon08]). In dit artikel zijn de succesfactoren opgenomen die specifiek naar voren zijn gekomen uit onze ervaring binnen het onderwijs.

… gedurende het pakketselectietraject

De keuze voor het juiste pakket kan ondersteund worden door het gebruik van een standaardmethodiek. De standaardmethodiek kan een hulpmiddel zijn bij het bepalen van de juiste keuze. In figuur 1 hebben we de standaard-pakketselectiemethodiek weergegeven zoals KPMG deze in selecties hanteert. Uit deze fasering lichten wij een aantal belangrijke stappen en activiteiten toe, met name het vooronderzoek en de workshop / proof of concept.

Figuur 1. KPMG-pakketselectiemethodiek.[Klik hier voor grotere afbeelding]

Vooronderzoek

Het vooronderzoek is zo’n kritieke stap. Hierin wordt vastgesteld wat de organisatie wil met haar processen en hoe dit vertaald kan worden in het te selecteren pakket: ambities inzake procesoptimalisatie verhouden zich direct tot de eisen en wensen die aan het systeem gesteld worden. In bijvoorbeeld het geval van een HRM-pakket zal in deze fase bepaald worden welke mate van selfservice een instelling wil toepassen. Denk hierbij aan Employee Self Service (wijzigen van adresgegevens, à la carte-systemen), Manager Self Service en zelfs Sollicitant Self Service.

Organisaties zijn vaak geneigd de huidige situatie in de functionele eisen te kopiëren. Wanneer de organisatie toegevoegde waarde wil creëren (en dat is meestal het geval), is het van belang dat ook buiten de huidige situatie wordt gedacht. Dat wil niet zeggen dat de huidige situatie volledig moet worden losgelaten. Deze kan vaak als minimale eis worden gehanteerd en een goede basis vormen. Van belang is dat iemand het proces begeleidt (facilitator), aangezien medewerkers met een bepaalde vaste scope qua werkzaamheden snel blijven hangen in de bekende huidige situatie. Onze ervaring leert dat het conceptueel denken gestimuleerd wordt door het vragen naar functionaliteiten die de gebruiker momenteel nog niet heeft.

Organisaties kunnen gebruikmaken van de kennis die vergelijkbare organisaties hebben opgedaan bij het doorlopen van een dergelijk traject. Hierdoor kan bijvoorbeeld bij het opstellen van het pakket van eisen gemakkelijker focus worden aangebracht op de belangrijke onderwerpen.

Indien een organisatie voor een bepaald onderdeel reeds over een ondersteunende IT-toepassing beschikt, is het relatief eenvoudig om een (deel van) de functionele eisen te formuleren. Moeilijker wordt het als functionele eisen gedefinieerd moeten worden waarvoor nog geen functionaliteit bestaat en waarover de ideeën nog niet zijn uitgekristalliseerd, en dit is binnen het onderwijs vaak het geval. Denk bijvoorbeeld aan de wens om competentiemanagement te laten ondersteunen door de IT-toepassing, terwijl het proces hieromtrent binnen de organisatie nog moet worden vormgegeven.

Gebruikers zijn bij het opstellen van de functionele specificaties geneigd te ‘overvragen’ in de functionaliteit. Zij beschrijven de eisen voor hun specifieke aandachtsgebied in grote mate van detail en vinden daarbij elke eis even belangrijk. Hierdoor ontstaat een eisenpakket waaraan geen leverancier tegemoet zal kunnen komen. Aanwezigheid van een projectlid met kennis van de IT-markt en de mogelijkheden van pakketten kan dit helpen voorkomen. In de praktijk van Europese aanbestedingen zien wij veelal het onderscheid tussen knock-out, eis, wens hoog en wens laag. Aan deze definitie hangen vervolgens wegingscriteria. De weging van een eis is zeer belangrijk; de eis moet niet te hoog worden ingestoken. Als een onderwijsorganisatie ervoor kiest om CASO te blijven gebruiken als verloningspakket, zal een knock-out voor een bewezen koppeling (meer dan één jaar in gebruik) met CASO ertoe leiden dat slechts drie pakketten overblijven. Daarnaast is een bekend voorbeeld de ondersteuning van de cao’s voor het onderwijs door de diverse pakketten. Er zijn slechts enkele pakketten die de cao’s voor het onderwijs kunnen ondersteunen. Tot slot noemen we nog het voorbeeld van de eerste en derde geldstroom. Dit is zeer specifiek voor het onderwijs en de eisen ten aanzien van de ondersteuning hiervan in een financieel pakket zullen derhalve goed moeten worden uitgewerkt.

Essentieel in deze fase is verder de pakketselectie niet als middel te zien om organisatiebeleid op te stellen. Het beleid vormt een randvoorwaarde, het pakket moet de uitvoering hiervan kunnen ondersteunen. Indien het organisatiebeleid nog niet helder is, kan een deelproject (definiëren van beleid) onderdeel worden gemaakt van het totale project. In de tussentijd (om het proces niet te zeer te vertragen) kan de betreffende functionaliteit op hoofdlijnen worden meegenomen in het programma van eisen, zodat de belangrijkste gebieden hiervan onderdeel uitmaken. Zo wordt gewaarborgd dat deze door de te kiezen oplossing wel kunnen worden ondersteund.

Workshop / proof of concept

In de praktijk komt het nog wel eens voor dat aan de leverancier gevraagd wordt om te laten zien wat het pakket kan. De potentiële gebruiker krijgt dan een flitsende presentatie te zien, waarbij de sterke punten van het pakket uitgelicht worden. Dit geeft echter geen goed beeld van het pakket en laat niet zien in hoeverre het pakket kan aansluiten bij de eisen vanuit de instelling. Het is daarom raadzaam om de leverancier in de workshop een case te laten presenteren die door de instelling is opgesteld op basis van haar gewenste processen. KPMG gebruikt templates om de leverancier zodanig te instrueren dat alleen de gewenste onderdelen en functionaliteiten gedemonstreerd worden. Onze ervaring is dat veelal informatie uit de dagelijkse praktijk wordt gebruikt die wordt aangepast aan de gewenste processen. Dit is voor de gebruiker herkenbaar. Bij een HRM-pakket kan bijvoorbeeld gebruik worden gemaakt van het proces van aanname tot en met vertrek van een medewerker ‘X’, inclusief de tussenliggende stappen in zijn carrière bij de organisatie, zoals het registreren van beoordelingen en het vastleggen van cursus ‘Y’.

Net als in de autobranche bestaat er onderscheid tussen de fabrikant en de dealer. De dealer is in deze context de implementatiepartner. Net als bij de aanschaf van een auto bent u vrij een implementatiepartner te kiezen die bij de instelling past. U kunt daarbij letten op de kennis die de implementatiepartner heeft van de (onderwijs)processen, maar vaak nog belangrijker is de culturele fit. Deze klik kan al tijdens de selectie bepaald worden en met name tijdens de workshop / proof of concept. Door de workshop op de locatie van de leverancier uit te laten voeren kan een instelling bepalen of er een klik is. Hiermee krijgt de instelling een beeld van hoe het er bij de implementatiepartner aan toe gaat (wordt men vriendelijk ontvangen, is het kantoor netjes ingericht, etc.). Daarnaast is het raadzaam om tijdens een workshop actief vragen te stellen. Daarmee kan bepaald worden in hoeverre de leverancier meedenkt met de instelling.

Contractuele afspraken

De pakketselectie wordt afgesloten met een contract. Uiteraard is er alles aan gedaan om een succesvol implementatietraject tegemoet te zien. Het is desalniettemin raadzaam bij het opstellen van het contract juridische expertise in te schakelen, temeer daar de praktijk uitwijst dat de drempel om juridische stappen te ondernemen lager is geworden.

Daarnaast is het van belang om goed de scope van het contract te evalueren. Zo is het beheer van Edukaat op dit moment onderdeel van het contract. In geval van het vervangen van Edukaat zal de beheerorganisatie aan de klant moeten worden ingericht. Daarnaast zal in de contracten helder moeten worden afgebakend waar de verantwoordelijkheden liggen.

… gedurende het implementatietraject

De keuze van het pakket is slechts het begin, daarna begint een intensieve samenwerking met de implementatiepartner: het implementatietraject. De succesfactoren in deze fase die uit onze ervaring binnen het onderwijs naar voren zijn gekomen, zijn hieronder toegelicht.

Hoge ambities

De spanning tussen ambities en realisatie is een algemeen spanningsveld dat terugkomt binnen de publieke sector. Zo komt uit het rapport van de Rekenkamer ([Alge07] en [Alge08]) naar voren dat een belangrijke oorzaak voor het (deels) mislukken van IT-projecten binnen de overheid is dat IT-projecten van de overheid vaak te ambitieus zijn. Bij deze projecten is er geen balans tussen ambitie, beschikbare middelen en tijd. Dit onderwerp komt ook als spanningsveld naar voren in het onderzoek van Stichting SURF ([SURF05]). Instellingen binnen het onderwijs hebben vaak hoge ambities en nemen daardoor te veel hooi op hun vork.

Een instrument om de ambities, beschikbare middelen en tijd op elkaar af te stemmen is de business case (zie ook PRINCE2 ([OGC05])). De business case beschrijft de rechtvaardiging van het project aan de hand van de kosten en baten van het project en eventuele alternatieven. Implementatieprojecten binnen het onderwijs hebben over het algemeen een doorlooptijd van enkele jaren. Het is daarom belangrijk de business case gedurende het project regelmatig te actualiseren. Geschikte momenten hiervoor zijn het afsluiten van fasen binnen het project.

Doordat het veelal lastig is de baten te kwantificeren gaat een business case vaak met name in op de kosten. Het kwantificeren van baten kan een significante bijdrage leveren aan het verkrijgen van draagvlak en de identificatie van stakeholders. Dit begint bij het helder omschrijven van het doel van het project, dat veelal niet enkel een technische vervanging van een IT-systeem betreft, maar ook realisatie van strategische doelen. Bij het realiseren van de baten van het project en het beheersen daarvan is de business case een belangrijk instrument ([Koet05a], [Koet05b]).

Structureren van het project

Het onderwijs verwijst veelal naar PRINCE2 ([OGC05]) bij het beheersen van de projecten. In de praktijk zien wij echter dat inhoudelijke expertise ten aanzien van PRINCE2 slechts beperkt aanwezig is. Daarbij wordt PRINCE2 veelal als doel gezien, en niet als middel. Dit resulteert in het opstellen van plannen en het vullen van templates, zonder dat daarbij voldoende gebruik wordt gemaakt van de toegevoegde waarde van deze documenten. Zo kan bijvoorbeeld de business case die in de voorgaande paragraaf reeds naar voren kwam, ongebruikt in de kast verdwijnen, maar ook actief als sturingsinstrument worden gehanteerd.

Met name bij meerdere (onderling afhankelijke en samenhangende) projecten ontbreekt binnen het onderwijs vaak een heldere en gestructureerde programmabesturing. Doordat het proces om te komen tot de selectie en implementatie van een IT-systeem een lange doorlooptijd kent en veelal kan worden opgedeeld in verschillende (logisch met elkaar samenhangende) deelprojecten, is het vaak verstandig om een programma te starten.

Daarbij kan ervoor worden gekozen het programma in verschillende plateaus op te delen (gebruik van plateauplanning). Een plateau bestaat uit een viertal invalshoeken die met elkaar in evenwicht zijn. Deze invalshoeken zijn de volgende (zie ook figuur 2):

• Management & organisatie: de organisatiestructuur, performancemeting en besturingsprincipes.
• IT-infrastructuur: de langetermijnplannen op het gebied van IT-infrastructuur binnen de organisatie.
• Personeel & cultuur: het perspectief van de medewerkers op de organisatie en hun eigen mogelijkheden.
• Processen & diensten: de processen en de toegevoegde waarde die deze leveren voor de organisatie.

Figuur 2. De vier invalshoeken per plateau.

De invoering van een geïntegreerd IT-systeem zal elk van bovenstaande factoren beïnvloeden, mede doordat de implementatie ook impact zal hebben op de uitvoering van processen binnen de gehele organisatie.

Door middel van plateauplanning kan ondanks de complexe situatie toch een beheerste implementatie plaatsvinden. Door het opdelen van het programma in meerdere plateaus wordt het programma beter beheersbaar, doordat niet wordt getracht alles in één keer te realiseren. Elk plateau kent een formele start en een formeel einde, waardoor binnen de lange doorlooptijd van het totale programma verschillende keren een formele afronding plaatsvindt en er duidelijk voortgang wordt geboekt.

Samengevat is onze ervaring dat instellingen profiteren van een gefaseerde aanpak, waarbij eerst de basis op orde wordt gebracht en daarna pas wordt overgegaan op het volgende plateau. Gezien het complexe karakter en de tijdsduur van IT-projecten bestaat het risico dat initiële doelstellingen van het project, en de wijze waarop deze bereikt worden, verslappen. Het is daarom verstandig om binnen de projectstructuur momenten van reflectie in te bouwen, al dan niet in een geformaliseerde en verbijzonderde quality assurance-rol.

De menselijke factor in beeld

Het uitvoeren van projecten vindt altijd plaats in de dynamiek van project- en lijnorganisatie. Dit samenspel uit zich ook in het vinden van de juiste medewerkers voor de juiste plekken binnen het project. Wij zien dat binnen projecten vaak onvoldoende expertise ten aanzien van projectbeheersing aanwezig is. Projecten worden dan geleid en uitgevoerd door vakspecialisten van de betreffende administraties. Hierdoor gaat het project te snel de diepte in en is er onvoldoende aandacht voor het besturen van het proces. Het is aan te raden projectmanagementexpertise in te schakelen bij de besturing van projecten, bijvoorbeeld door de betrokken medewerkers te trainen.

Projectorganisaties binnen het onderwijs vertrouwen voor wat betreft de technische component vaak sterk op de leverancier. Hierdoor houdt de organisatie onvoldoende grip op de integratie van applicaties in de bestaande applicaties en IT-infrastructuur.

Binnen het onderwijs is veelal sprake van een gedecentraliseerde organisatieopbouw: professionals die hun werkprocessen relatief autonoom inrichten. Hierdoor kunnen centrale belangen ondergeschikt raken aan de decentrale belangen. Uit de praktijk komt naar voren dat binnen diverse onderwijsorganisaties de centrale belangen onvoldoende zijn uitgekristalliseerd en doorgaans volgend zijn aan de decentrale praktijk. Lastig hierbij is dat de decentrale processen vaak niet op dezelfde wijze zijn ingericht bij de diverse afdelingen of faculteiten. Dit bemoeilijkt het vaststellen van eenduidig beleid en daarmee het vaststellen van de functionele specificaties van een IT-systeem.

Het managen van de verwachtingen van de belanghebbenden is cruciaal. Zowel de eindgebruikers als de eindverantwoordelijken voor het project dienen voldoende geïnformeerd te zijn over het doel en de voortgang van het project. Het is daarbij van belang te redeneren vanuit de ontvanger. Wat is de informatiebehoefte van de betreffende belangengroep? Ook tijdigheid is hierbij van belang: te vroeg communiceren kan ertoe leiden dat de aandacht voor het project verslapt en dat de voortgang van het project wordt betwist. Te laat communiceren kan ertoe leiden dat belanghebbenden zich niet betrokken voelen en belangrijke beslissingen niet tijdig kunnen worden genomen (mosterd na de maaltijd).

Organisatorische verandering

IT-implementatietrajecten zijn veelal een gevolg van organisatiebrede veranderingstrajecten. Het veranderingsproces is nodig om aan nieuwe behoeften te kunnen voldoen: van gestandaardiseerd onderwijsaanbod naar vraaggericht onderwijs, van starheid in vaste werktijden, vaste verlofdagen, vaste personeelsformatie, vaste jaartaakmodellen naar organisatorische wendbaarheid (flexibel samengestelde teams) en slagvaardigheid. Veranderingen in het onderwijsmodel (meer gericht op het ontwikkelen van competenties van leerlingen) leiden ertoe dat binnen veel onderwijsinstellingen de behoefte bestaat aan het meer flexibel inzetten van onderwijsmedewerkers en het sturen op competenties van docenten. Het organiseren van deze verandering vindt niet vanzelf plaats, maar heeft behoefte aan specifieke sturing (verandermanagement).

Figuur 3. Voorbeeld van een communicatieplan.[Klik hier voor grotere afbeelding]

In de praktijk zien we dat het verandertraject het ondergeschoven kindje binnen het IT-project is. De verandering wordt als gevolg van de IT-implementatie gezien, in plaats van andersom. Het project besteedt uitsluitend aandacht aan de IT-component, hiermee wordt de organisatorische inbedding vergeten. Tevens gaat er te weinig aandacht uit naar de veranderingsbereidheid van de organisatie en haar medewerkers. Ook zien we dat de implementatietrajecten al gestart zijn, terwijl de gewenste procesinrichting nog niet helder is en het verandertraject nog niet is uitgestippeld.

Ook hier is het managen van verwachtingen cruciaal. Communicatie met en naar de betrokkenen speelt daarbij een sleutelrol. Een belangrijk instrument binnen het verandertraject is daarom het communicatieplan (zie figuur 3).

De succesfactoren samengevat

Samengevat komt het bovenstaande op het volgende neer:

Pakketselectie

• Weet wat je wilt.
• Overvraag niet.
• Het pakket moet volgend zijn ten opzichte van beleid, niet leidend.
• Wees leidend: bepaal zelf wat je wilt zien in de presentatie van de implementatiepartner.
• Bepaal de mate van culturele klik met de implementatiepartner.
• Schakel juridische expertise in.
• Draag zorg voor kennis van technische en juridische aspecten van Europese aanbestedingen (indien van toepassing).
• Kies de juiste procedure binnen de Europese aanbestedingen (indien van toepassing).

Implementatie

• Kwantificeer in de business case ook de baten.
• Actualiseer de business case regelmatig.
• Pas PRINCE2 als middel toe, niet als doel.
• Kies voor gefaseerde aanpak, waarbij eerst de basis op orde wordt gebracht en daarna pas wordt overgegaan op het volgende plateau.
• Bouw momenten van reflectie in: een kwaliteitsverhogende maatregel.
• Kies voor de juiste mensen op de juiste plaats binnen het project.
• Schakel daar waar nodig expertise in.
• Wees leidend ten opzichte van de leverancier.
• Zorg voor een eenduidige visie op organisatiebeleid en -processen.
• Manage de verwachtingen van de betrokkenen.
• Maak het organisatorisch verandertraject leidend ten opzichte van de technische (IT-) component.
• Structureer en plan het organisatorisch verandertraject.
• Stel een communicatieplan op.