Bijna alle tot nog toe ontvangen reacties zijn instemmend. Wellicht komen die dus allemaal van directieleden en leveranciers? Wat ik vooral mis zijn reacties van de mensen van de werkvloer. Dames en heren eindgebruikers - mag ik u van harte uitnodigen om ook te reageren??

Dank je Hans voor jouw aanvulling! De 'echte regisseur' in jouw verhaal is de dominante manager. De persoon die strak aan de eerdere gekozen uitgangspunten vast houdt. Belangrijk is dat die uitgangspunten op visie zijn gebaseerd. En dus niet op ellenlange lijsten met (detail-)eisen en wensen.

De regisseur en de projectterroristen:

Vaak wordt gezegd, dat een grammetje visie meer waard is dan 1000 kilo eisen. Dat geldt zeker in projecten, ook zoals Guus ze hierboven omschreven heeft. Als product-en processpecificaties gedetailleerd worden vastgelegd, dan zie je alleen nog maar bomen, maar het bos ben je kwijt. Achter iedere boom zie je een risico schuilen. Voor ieder risico definieer je maatregelen. Dat tot grote tevredenheid van de projectterrorist, die hiermee volledig in de kaart wordt gespeeld. Als immers de bezwaren over één van zijn bomen met veel moeite onder het tapijt zijn geveegd, dan neemt hij toch gewoon de volgende boom. In het bos zijn er tenslotte genoeg.

De echte regisseur echter gaat uit van zijn eigen visie: wat moet er bereikt worden en welke zijn de knock-out criteria die er echt toe doen (meestal minder dan tien). Dat is ook het verhaal naar alle betrokkenen op ‘wat’-niveau. En voor het hoe verwijst hij naar bestaande standaards en best practices. Hij weet, dat niets zijn project zo erg vertraagt als het opnieuw uitvinden van wielen en het maken van uitzonderingen op standaards. Dat communiceert hij ook. Zoals geldt voor iedere regisseur, zo telt er voor hem in het project maar één beeld van de werkelijkheid en dat is zijn beeld.
Hij maakt alle keuzes die er toe doen en via verwachtingsmanagement overtuigt hij een ieder die het beeld van zijn werkelijkheid wil zien. En de betrokkenen die het niet willen zien? De regisseur erkent simpel, dat er ook andere werkelijkheden kunnen bestaan, alleen niet in dit project. En hij zorgt ervoor, dat de betrokkenen niet te lastig worden.
Dan is er natuurlijk één essentiële randvoorwaarde: het projectteam (intern of extern) moet waarmaken wat de regisseur belooft. De regisseur moet daarom de nodige tijd besteden aan de afstemming met zijn projectteam met als belangrijkste stelregels:
• Er is maar één visie en werkelijkheid in het project en dat is die van de regisseur.
• Als er alternatieven zijn, wordt de regisseur om een keuze gevraagd.
• Als toekomstige gebruikers sputteren, dan wordt dit gerapporteerd aan de regisseur, want die heeft dan blijkbaar de verwachtingen niet goed gemanaged.
Kortom, democratisch beginselen moeten niet op projecten worden toegepast. Daarom pleit ik weer voor de benaming opdrachtgever. De rol van opdrachtgever is precies de rol die een regisseur moet invullen.

Hans Truin ICTStrateeg

Dank je wel voor deze mooie en uitgebreide toevoeging Paul! De metafoor van het verbouwen van de keuken is krachtig. Iedereen weet immers wat een keuken is en begrijpt de consequenties als je van het eerdere plan afwijkt. Maar ook voor jou blijft het dus nog de vraag of de dominante directeur het in z'n ERP project gaat redden.

De invloed van de directie en managers op automatiseringstrajecten is ontegenzeggelijk belangrijk, en daar is nog veel te winnen.
Heb echter niet de illusie dat één directeur, alleen vanwege het feit dat hij de baas is, een heel project kan trekken. Nog afgezien van de vraag of hij of zij dat wel zou willen.
Ik kan me nog levendig de discussie met een interne projectmanager herinneren over het beginsel van 'proceseigenaar: komende uit een grote organisatie waar het principe van 'process owner' duidelijk doorgevoerd was, viel ik van mijn stoel van verbazing dat in deze organisatie het principe van 'proceseigenaar' vrijwel onbekend was. Er heerste een pionierscultuur, waarin zelfs de fabricage nog steeds als een soort technologisch proefproject gerund werd, met een paar ingenieurs ernaast, die dan als 'proceseigenaar' bekend stonden. Geen wonder dat de brede SAP-implementatie daar volgens dezelfde lijnen uitgezet werd.
Ik vergelijk een brede ERP-implementatie graag met het vernieuwen van de eigen keuken: daar moet je met elkaar van tevoren een functioneel ontwerp maken, kiezen uit maatwerk of standaard-modules, met elkaar tot overeenstemming komen op grote lijnen tot en met de details, een goede leverancier kiezen, bepalen hoeveel je zelf kunt doen en wat je laat doen door de aannemer/loodgieter, enz.
Iedereen begrijpt dat een nieuwe keuken meer kost dan alleen de kastjes en de apparaten: je moet eerst de oude keuken eruit slopen, de muren egaliseren, leidingen verleggen, alles vakkundig inbouwen en stellen, aftegelen en uiteindelijk testen.
Een nieuwe keuken bouwen, dat herkent iedereen, maar niemand schijnt zich te realiseren dat het implementeren van een ERP-pakket bijna hetzelfde proces is. Iedereen begrijpt dat wanneer je halverwege het keuken-project ineens besluit om toch maar de wasbak aan de andere kant te plaatsen, je een heleboel extra kosten krijgt - plus heibel in de tent. Maar diezelfde mensen realiseren zich niet dat een soortgelijke verandering in de specificaties van je ERP-systeem het project op z'n kop zetten en veel extra kosten veroorzaken.
Net als een keuken bouwen bestaat een ERP-implementatie ook uit een grote technologische component, die zeer vakkundig ingericht en aangesloten moet worden, denk maar aan het aanrechtblad, dat twee maanden na oplevering ineens loslaat en de waterleiding opentrekt.
In de ICT wereld zijn deze veranderingen gedurende het project schering en inslag en vaak nog van een veel grotere orde (ach, als we nou toch aan het hakken breken zijn, laten we dan die hele muur eruit gooien en de naastgelegen ruimte bij de keuken trekken).
Er zijn geen simpele lineaire modellen die als een panacee verklaren waarom het ene project wel werkt en het andere project op een catastrofe uitloopt.
Er zijn wel een paar principes van verstandig leiderschap en zinvol projectleiderschap waarmee dit soort technologische investeringen met hoge impact in goede banen geleid kunnen worden.

Okay Nanne - goed luisteren dus en aannames toetsen op de werkvloer. En daarna moet het management tijdens het project met straffe hand het plan uitvoeren. We zijn het tot nu toe dus roerend eens in dit gremium! Nog mensen hier met andere meningen wellicht?

Helemaal eens, teveel inspraak leidt soms ook tot niet-innoveren (niet iedereen is bekend met nieuwe ontwikkelkingen en mogelijkheden). Daarom is luisteren/ kennis van processen van belang voor managers. Door het luisteren naar medewerkers ontstaat er tevens een gevoel van inspraak bij medewerkers. De manager kan dan nieuwe ontwikkelingen/ visie hiermee combineren en het 'IT-Project (bestaat dat eigenlijk nog wel in 2011??) dicteren.

Goede aanvulling Leo! En mooi ook hoe jij de link legt naar de verschillende taken die bepaalde functionarissen binnen de organisatie hebben - maar inderdaad lang niet altijd zo uitvoeren! Slappe knieen dragen niet echt bij aan succes in een ERP project.

Ik denk dat de uitgangspunten en het globale programma van eisen tamelijk veel inspraak verdraagt, nee eist. Daarna is het een kwestie van stug doorgaan op de ingeslagen route. De taak van het topmanagement is om het middlemanagement te leren, hoe je op de werkbloer draagkracht creeert: inderdaad, door BINNEN DE GESTELDE BEPERKINGEN iedereen op zijn detailniveau inspraak te geven over bv de te kiezen user interface.
Het middle management is meestal de bottleneck!

Het mag met inspraak nooit zover komen, dat een systeem gekozen wordt omdat de invoerschermen zo mooi zijn: De gewenste uitvoer moet leidend zijn.

Dat is al de tweede instemmer op rij! Maar jij legt wel nadruk op het vooraf goed betrekken van de gebruikers Fons. Dat lijkt mij eerlijk gezegd ook onvermijdelijk. De beste kennis van de dagelijkse praktijk ligt immers nog altijd op de werkvloer?

Helemaal mee eens. Van dat iedereen mee moet kunnen beslissen is nog geen enkele implementatie beter geworden. Het is wel van belang dat de "kartrekker" vooraf wel goed heeft geluisterd naar de gebruikers om toch een goed draagvlak te creeren.

Jij klinkt vrij optimistisch (heer) Krijgsman! En dat geeft zeker moed. Maar persoonlijk ken ik tal van organisaties waar ik er niet op vertrouw dat het in een dergelijke opzet "uiteindelijk wel goed komt". Inspraak van de werkvloer in de selectie- en implementatiefase is in de afgelopen 20 jaar immers tot een soort van recht uitgegroeid?

Eens, al dat meepraten kost tijd, zorg dat je een enkele goede mensen hebt en klaar. Als ze zien dat het uiteindelijk goed komt, snoert het iedereen de mond wel.