Doe eens gek! Houd rekening met de mensen in uw organisatie bij het implementeren van ICT oplossingen.

 ERP, CRM, workflowmanagement en documentmanagement systemen, ze hebben één ding gemeen: Veel van de implementaties in organisaties mislukken of zijn veel minder succesvol dan initieel gepland. De voornaamste reden hiervoor blijft:

 Onvolledige betrokkenheid en inzicht in de behoeften van organisatie, afdelingen en individuen.

 Vaak zie je dit terug in een aantal concrete zaken binnen het project, veelal ontbreekt:

1. De toegevoegde waarde analyse van de ICT oplossing voor de organisatie
2. Aandacht voor de onvermijdbare gevolgen bij het kiezen van bepaalde uitgangspunten
3. Een juiste behoeften-analyse (requirements) en prioritering hiervan
4. Een communicatiemechanisme naar de betrokken afdelingen, gedurende de looptijd van het project.
5. Doorvoering van noodzakelijke organisatorische wijzigingen, om het ICT produkt echt waardevol te maken

 Met behulp van een workshopmethodiek is het mogelijk de gebruikers wél betrokken te laten zijn, op een efficiente en effectieve manier.

 [Leeswijzer: Eerst worden verschillende tekortkomingen in projecten behandeld die eenvoudig opgelost kunnen worden bij het inzetten van workshops. Daarna wordt de brug geslagen naar de workshopmethodiek en de bijbehorende checklist.]

 De toegevoegde waarde analyse van de ICT oplossing voor de organisatie

Organisaties vragen zichzelf veelal te weinig af wat de toegevoegde waarde is van het ICT produkt. In het ERP tijdperk werd bijvoorbeeld de "me-too" strategie toegepast, zonder dat hier een renderende business case aan vooraf ging

 Aan de andere kant zie je vaak dat de keuze voor een ICT oplossing bepaald wordt door enkele mensen in de organisatie, maar dat het ICT produkt uiteindelijk voor de totale organisatie aangeschaft wordt. Het gebruik van de ICT oplossing is laag in de overige bedrijfsonderdelen. De andere organisatiedelen hebben net even andere behoeften en kiezen voor (ongeveer) dezelfde functionaliteit, maar een ander produkt. Dit is niet wenselijk, maar wel de harde realiteit.

 Het succes van je project begint in deze fase, want als hier al duidelijk wordt dat er met het ICT systeem geen "probleem" in de organisatie wordt opgelost, zullen de mensen in de organisatie het ICT produkt niet omarmen, maar liever op de oude, vertrouwde manier verder willen werken. Schat dus goed in wat de waarde is van het nieuwe systeem voor organisatie, afdelingen en individu!

 Aandacht voor de onvermijdbare gevolgen bij het kiezen van bepaalde uitgangspunten.

 Organisaties maken aan het begin van trajecten duidelijk wat de uitgangspunten zijn, maar wat de gevolgen hiervan zijn en hoe de projectorganisatie hierop gaat acteren blijft onduidelijk. Het is uitermate belangrijk dit al in het beginstadium te onderkennen.

 Zo kan bijvoorbeeld , als uitgangspunt, gekozen worden voor een standaard pakket. Het gevolg hiervan is dan wel dat de bedrijfsprocessen hierop aangepast moeten worden en dat aandacht besteed zal moeten worden aan mensen en de verandering van de werkwijzen. Veelal wordt het uitgangspunt: "standaardpakket" geopperd in verband met een lagere TCO, maar wordt geen tijd, geld en middelen vrijgemaakt om de processen en werkwijzen van mensen aan te passen. Dit is een irreele gedachte! Als gekozen wordt voor een standaardpakket zul je als organisatie meer tijd moeten besteden aan het aanpassen van je organisatie/processen en duidelijk moeten communiceren naar de betrokkenen in de afdelingen.

Juiste behoefte analyse (requirements) en prioritering

 Organisaties definieren vaak beperkt wat de daadwerkelijke behoeften zijn of definieren het niet eenduidig.

 Bedrijfsprocessen beperken zich bijvoorbeeld niet tot één bepaalde afdeling, terwijl degene die het deel-proces beschrijft vaak alleen kijkt binnen zijn afdeling. Het totale, afdelingsoverschrijvende, bedrijfsproces bevat daarom vaak dubbele activiteiten en/of discrepanties. Daarnaast ontbreekt de aansluiting tussen organisatie eenheden. Een ontwikkelaar of applicatieconsultant kan het totale, afdelingsoverschrijvende, bedrijfproces onmogelijk correct ontwerpen.

 Naast de eenduidige definitie van afdelingsoverschrijdende processen worden functionaliteiten vaak niet geprioriteerd. Daardoor kan het voorkomen dat iets wat niet urgent en niet belangrijk is, maar wel een significante inspanning vergt van de projectorganisatie, eerder wordt uitgevoerd dan iets wat betrekkelijk eenvoudig op te lossen is en wel degelijk belangrijk en urgent. Prioritering van functionaliteiten is ook geen afdelingsgerelateerde activiteit, maar moet in samenspraak met alle betrokken afdelingen gebeuren.

Aansluiting met de individuen uit de betrokken afdelingen

 In projecten wordt vaak beperkt aandacht besteed aan de communicatie richting en afdelingen en betrokkenen, de mensen die daadwerkelijk met het systeem moeten gaan werken.

Mensen horen meestal beknopt dat er "iets" met hun werkzaamheden gaat gebeuren, maar wat is onduidelijk. En onbekend maakt onbemind, zeker als dat onbekende direct invloed heeft op je eigen werkzaamheden! Zelden hoor ik bij de implementatie van projecten dat eindgebruikers blij zijn dat ze het systeem in gebruik mogen nemen, meestal is er een aversie opgebouwd voor het systeem en de eventuele organisatorische wijzigingen en dus verloopt implementatie moeizaam.

 Vooral bij grotere trajecten, zoals ERP trajecten is het uitermate belangrijk afgevaardigden van verschillende afdelingen op te nemen in het project team, te zorgen dat deze mensen communicatief sterk in hun schoenen staan en zo de achterliggende afdelingen continue van informatie kunnen voorzien. Afgevaardigden kunnen eenvoudig afdelingsgerelateerde vragen beantwoorden, omdat ze verstand hebben van de business. Het feit dat de afgevaardigde zelf deel uitmaakt van het veranderingsproces geeft de betrokkenen in de afdeling het gevoel dat er serieus en voor lange termijn naar de belangen van de afdeling gekeken wordt en daarmee naar de belangen van de indivduen binnen deze afdeling.

 Betrokkenheid van individuen zal zorgen voor een hogere acceptatiegraad van het nieuwe systeem. Bij de (altijd aanwezige) tekortkomingen in het systeem zal de eindgebruiker eerder deze tekortkoming accepteren, in plaats van het nieuwe systeem met behulp van deze constateringen aan te voeren als nieuw bewijs om het ICT-systeem te elimineren uit de organisatie.

 Doorvoering van noodzakelijke organisatorische wijzigingen, om het ICT produkt echt waardevol te maken

 Organisatorische wijzigingen, die nodig zijn om het ICT instrument echt waardevol te maken worden vaak niet doorgevoerd. De redenen hiervoor varieren, maar één van de de belangrijkste is wel: de wijziging heeft, bij succesvol invoeren, betrekking op verschillende afdelingen. Vaak is het lastig om met verschillende afdelingen snel tot een eenduidige oplossing te komen, derhalve wordt de oude werkwijze overgenomen.

 Tevens kan het voorkomen dat eindgebruikers geen tijd hebben of krijgen om over een nieuwe opzet na te denken: de huidige manier van werken wordt overgenomen.  Binnen een business intelligence implementatie werd mij gevraagd de rapporten na te bouwen precies zoals het oude dos-systeem, op deze manier werden belangrijke nieuwe prestatieindicatoren totaal buiten beschouwing gelaten. De mogelijkheden van het nieuwe systeem en daarmee de "added value" is dus totaal niet duidelijk.

 Bij sommige trajecten wordt zelfs het standaard-pakket aangepast aan de huidige bedrijfsprocessen, met alle kosten vandien. Terwijl met enige discussie en communicatie in de organisatie het bedrijfsproces goed aangepast kan worden aan het standaard-proces van de standaard applicatie, waardoor duur maatwerk uitgesloten blijft.

Inzetten van een workshopmethodiek

De bovenstaande problematieken spelen een grote rol bij het falen van systeem implementaties, zoals ERP of CRM.  In alle paragrafen worden elementen genoemd als:

-       Afdelingsoverschrijdende communicatie, afstemming en het nemen van  beslissingen

-       Verkrijgen van commitment van de betrokken eindgebruikers

-       Met elkaar denken in plaats van voor elkaar

Juist in omgevingen waar deze elementen spelen zijn workshops een effectief hulpmiddel om de implementatie te laten slagen. De opgeleverde documenten zijn immers opgesteld door de afgevaardigden zelf, hebben een breed draagvlak, en bevatten geen discrepanties omdat verschillende afdelingen naar het gehele proces kijken.

 Om het workshop proces goed te kunnen uitvoeren heb ik een checklist bijgevoegd. Wanneer aan deze punten wordt voldaan is de acceptatie van een ICT-systeem significant vergroot.

Checklist voor het uitvoeren van een workshop

Definieren en afstemmen workshop opdracht

q  Actie: accepteer het projectplan en neem dit plan als uitgangspunt

o    Randvoorwaarde: de stakeholders staan beschreven

o    Randvoorwaarde: de organisatorische doelstellingen staan beschreven

q  Actie: stel workshop opdracht op stem  workshop opdracht af met de opdrachtgever

o    Randvoorwaarde: Opdrachtgever heeft voldoende slagkracht voor te veranderen bedrijfsonderdeel

De tactische workshop voorbereiding

q  Actie:  haal de projectdoelen en scope uit het projectplan en “vertaal” ze in de taal van de workshopgroep(en)

q  Actie: Laat de, voor iedereen duidelijke, workshop doelstellingen accoderen door de opdrachtgever

q  Actie: Kies belangrijke afgevaardigden in samenspraak met de opdrachtgever

o    Randvoorwaarde:  alleen competente afgevaardigden die mandaat hebben in organisatie

o    Randvoorwaarde: afgevaardigden nemen autonome beslissingen in de workshop

q  Actie: definieer het uitgangspuntendocument, waarin alle randvoorwaarden staan genoemd waarbinnen de workshopgroep zal acteren

o    Randvoorwaarde: uitgangspunten document is afgestemd met alle workshopleden én de opdrachtgever

q  Actie: definieer een geschillencommissie, die beslist over issues die niet in de workshop opgelost kunnen worden.

o    Randvoorwaarde: mechanisme van de geschillencommissie is beschreven

q  Actie: stel een goede scribe aan, die de workshopresultaten, de geschillenlijst bijhoudt en de tijd monitored

q  Actie: stel een goede workshopmoderator aan

o    Randvoorwaarde: ervaring in groeps- en gespreksprocessen

o    Randvoorwaarde: moderator heeft geen inhoudelijke rol, maar dient als katalysator

De operationele workshop voorbereiding

q  Actie: spreek alle workshopleden (afgevaardigden) persoonlijk voor de eerste sessie van de workshop

q  Actie: definieer duidelijk wat de workshopaanpak wordt, welke informatie je allemaal wilt vastleggen en transparant maken en welke hulpmiddelen je gaat gebruiken

q  Actie: definieer duidelijk welke documenten opgeleverd gaan worden en het formaat en inhoud van de documenten. Maak een template voor de scribe en maak en template voor de geschillenlijst

q  Actie: zorg ervoor dat uitnodigingen, locatie en catering goed geregeld zijn. Niet regelen is onprofessioneel overkomen.

De workshop zelf

q  Actie: houd je uiteraard bij de in de vorige fases afgestemde doelstellingen,scope en uitgangspunten.

q  Actie: geef iedereen in de workshop een goed en opbouwend gevoel, door te luisteren naar de verschillende belangen, uit te leggen waarom iets wel of niet kan.

q  Actie: leg de resultaten vast in officiele documenten

q  Actie: leg uit wat de resultaten zijn aan het eind van iedere workshop, zodat workshopleden weten wat er gedurende de dag is bereikt

q  Actie: commiteer de workshopleden aan het resultaat en vat to do's samen

Na de workshop:

q  Actie: communiceer de resultaten eerst naar de workshopleden, voordat deze naar allerlei (inclusief management) gaan, laat de resultaten accoderen door de workshopmembers.

q  Actie: zet to-do's op papier en koppel er een naam aan vast, volg de to-do's op in de volgende workshop

Patrick van Burgel (2003)