Einstein’s wet van waanzin
In de zomer van 2013 heeft het Ministerie van Defensie formeel het programma SPEER beëindigd. SPEER betrof de invoering van ERP (SAP) software bij het Ministerie van Defensie. Er werd een aantal van 12.000 werkplekken genoemd. SPEER was daarmee een van de grootste SAP implementaties ooit. Eind 2013 heeft men een "Eindrapportage" gepubliceerd waarin het verloop van het programma is beschreven. Daarnaast heeft de Algemene Rekenkamer (16 januari 2014) ook een rapportage geschreven.
Het programma heeft ruim 10 jaar in beslag genomen. Er worden diverse bedragen genoemd. Zo noemt de Algemene Rekenkamer een oorspronkelijk budget van €185 miljoen. De bestedingen zouden anno 2013 €481 miljoen bedragen. Hierbij merkt de Rekenkamer op dat niet alle kosten zijn meegerekend; interne kosten zouden bijvoorbeeld buiten beschouwing zijn gelaten. De Rekenkamer meent dat de totale kosten zullen uitkomen op ongeveer €900 miljoen.
De Eindrapportage geeft een beeld van het verloop van SPEER. Men stelt dat dit een open en eerlijk beeld geeft. Hierbij moet worden opgemerkt dat de Eindrapportage is geschreven door mensen die direct betrokken waren bij SPEER en er ook een direct belang bij hadden; commercieel of vanuit hun functie en carrière. Een bewijs hiervan is een brief van een advocaat die eiste dat ik de Eindrapportage van mijn website moest verwijderen (auteursrecht). Het document mag slechts worden benaderd via de website van het commerciële bedrijf dat de eindredactie verzorgde en adviseerde over SPEER. Ik kan mij niet onttrekken aan de indruk dat de eis werd ingegeven door ongenoegen over mijn kritiek op de Eindrapportage. Het is hoe dan ook duidelijk dat de Eindrapportage symptomen beschrijft maar voorbij gaat aan de echte problemen.
Alleen op grond van doorlooptijd en bestedingen zal menigeen concluderen dat SPEER een mislukking was en wijzen naar de reputatie van de overheid als het gaat om IT projecten. Maar dat is te gemakkelijk. Voor zover we bij SPEER kunnen spreken van een mislukking, is dat niet uniek voor de overheid. In de loop der jaren zijn er tal van ERP/SAP projecten geweest die hebben geleid tot zeer kostbare mislukkingen. In noot 2 vindt u een kleine greep.
De Eindrapportage beschrijft een redelijk positief beeld van het SPEER project. De Algemene Rekenkamer neemt een onafhankelijke positie in en is minder positief. Beide rapportages gaan echter voorbij aan fundamentele problemen van het programma SPEER: ICT en standaardisatie zijn centraal gesteld. De ondersteunende stafafdelingen, ICT en iets minder mate Inkoop (aanbestedingen) richtten zich vooral op hun eigen doelen.
Het echte doel van SPEER, verbetering van de bedrijfsvoering, werd ondergeschikt gemaakt aan ICT. Dit is niet nieuw. Het is dagelijkse realiteit. Einstein heeft ooit waanzin gedefinieerd als: hetzelfde blijven doen en een ander effect verwachten. Wanneer komen wij er achter dat waanzin regeert in dit soort projecten?
Waarom mislukken ICT-projecten?
Is er een rode lijn aan te wijzen? Zeker! Waarom mislukken ICT-projecten? Omdat het ICT-projecten zijn. Het grootste probleem van elk ICT project, SAP of niet, is dat de techniek centraal wordt gesteld. De kern van elke mislukking is dat het middel ICT als doel wordt gezien. Vervolgens wordt het project dan ook nog eens geleid door een IT-manager (CIO) en gemanaged door een ICT-projectmanager. Maar al te vaak geldt: "To a man with a hammer in his hand, the whole world looks like a nail". Men denkt dat ICT overal een oplossing voor biedt. Dat is verreweg de grootste oorzaak van het falen van ICT-projecten. Dit blijkt ook de grootste oorzaak te zijn van de problemen van SPEER.
Bij haar aantreden zorgde de directrice van SAP Benelux voor veel ophef door beschuldigend naar de klant te wijzen. Ook deze dame begrijpt blijkbaar het verschil tussen doel en middel niet. Overigens vraag ik mij af wie zij zag als de klant; de IT-afdeling van de klant is ook een (interne) leverancier, veelal met eigen belangen. Ook een interne IT-afdeling zal IT zien als doel. In ieder geval was de reactie van de SAP directrice kenmerkend voor de sector
Tot op zekere hoogte heeft het departement dit probleem onderkend. Na een aantal jaren heeft men een Supervisor aangesteld met wortels in de bedrijfsvoering. Maar toen was het al te laat; SPEER had de reputatie van een IT-project en daar kom je niet meer vanaf. Ook is het zo dat deze Supervisor waarschijnlijk heel snel ging denken als een IT-manager. In een soortgelijke discussie vertelde een manager mij dat hij het volledig met mij eens was maar dat hij binnenkort zou worden overgeplaatst naar de IT-divisie. In die functie zou hij het volledig met mij oneens zijn. Een terechte opmerking en een wijze les!
De overheid maakt het zichzelf moeilijk
Schijnbeheersing door de CIO en Gateway Reviews
Om ICT-projecten beter te beheersen heeft de overheid de rol van de CIO versterkt. Ook heeft men vanuit Groot Brittannië de Gateway Reviews overgenomen. Helaas worden hierdoor de fundamentele problemen juist versterkt. De CIO is een interne leverancier met een focus op ICT. De problemen voortkomend uit aanbodgedreven projecten worden dus fundamenteel verankerd in projecten.
De Gateway Reviews kunnen een bijdrage leveren aan verbetering van projecten. Ze zijn bedoeld om beter en meer structureel te kijken naar projecten en hun beheersing. Het is alleen niet de bedoeling dat Gateway Reviews, net als verwante aanpakken als PRINCE2 en MSP (Managing Successful Programmes), in handen komen van (interne) leveranciers. Bij deze aanpakken staat centraal dat vanuit de bedrijfsvoering wordt gedacht. Gateway Reviews worden bij de overheid echter ingezet bij ICT-projecten en door CIO's met medewerking van adviseurs die zich richten op het "snijvlak van ICT en de Business". Gateway Reviews blijken daardoor bij de overheid ineffectief; net als MSP en PRINCE2. Deze aanpakken zijn bedoeld voor de bedrijfsvoerders, dwz de verantwoordelijke lijnfunctionarissen. Zij moeten ermee aan de gang niet de ICT’rs.
Aanbestedingen
Ooit sprak ik een directeur van een groot ICT bedrijf. Dit bedrijf had geoffreerd op een ICT-project van de overheid. Tot mijn grote verbazing was de offerte verlieslatend. De directeur vertelde mij dat de aanbesteding uiterst vaag was, dat hierdoor de offerte ook uiterst vaag was en dat de aanbestedende dienst slechts op prijs zou selecteren; een zo laag mogelijke offerte zou dus kansrijk zijn. Gezien de uiterst vage beschrijvingen is selectie op prijs natuurlijk het enige meetbare criterium. Maar de consequentie was dat meerwerk snel aan de orde zou komen, met hoge extra kosten tot gevolg. Hier zou het ICT bedrijf de winst op maken.
Dit is een publiek geheim. Waarom laat men zich nog bedriegen?
Wanneer een aanbesteding wordt uitgevoerd voor standaard producten en bulkgoederen zal de procedure kunnen werken. Ook voor Turn Key projecten kan de procedure werken. Maar voor projecten met grote onzekerheid, zoals bij software ontwikkeling per definitie het geval is, is de huidige manier van aanbesteden te rigide. Het gevolg is schijnbeheersing en daarmee al snel hoge overschrijdingen.
De Eindrapportage stelt dat SPEER de manier van aanbesteden heeft herzien. Het programma heeft onderkend dat de oorspronkelijke manier van aanbesteden problemen opleverde en heeft meer flexibiliteit toegepast. Het is te betwijfelen of de aanbestedingsprocedures dusdanig flexibel waren gemaakt dat de effectiviteit echt werd vergroot.
Specifieke problemen van SPEER
Het departement had te maken met specifieke problemen. De stammenstrijd tussen de diverse onderdelen van Defensie mag bekend zijn. SPEER probeerde, geleid door software, een uniforme werkwijze af te dwingen. Een kansloze onderneming. Voormalig minister Hillen stelde dat Defensie moest verSAPpen. Nee, SPEER moet zich aanpassen aan de bedrijfsvoering.
Het SPEER programma trachtte tussen diverse grote reorganisaties door te laveren. Zowel de diverse reorganisaties als SPEER trachtten de bedrijfsvoering te veranderen, elk vanuit hun eigen doelen. Dit creëerde talloze afhankelijkheden en risico's. SPEER had daarom nooit zelfstandig mogen bestaan. De werkzaamheden hadden altijd een ondergeschikt deel moeten uitmaken van de reorganisaties. De Eindrapportage wijst op het belang van visievorming en de Business Case. Alleen al door de vele afhankelijkheden zijn visievorming en een degelijke Business Case vrijwel onmogelijk om na te streven.
De adviseurs bespreken deze problemen in de Eindrapportage maar komen niet verder dan de symptomen. De Eindrapportage stelt diverse malen dat het SPEER ontbrak aan een duidelijke visie. Als IT-ers verwarren ook zij doel met middel. Een IT-er kan een duidelijke visie hebben op een IT-project en IT-producten als doel. Maar dit helpt het project niet. De bedrijfsvoering heeft een behoefte aan een visie op hun werkwijze; het echte doel. Die visie kan IT niet leveren.
Parallel hieraan besteedt de Eindrapportage veel aandacht aan de Business Case en de baten die SPEER zou moeten opleveren. Maar ook hier onderkent men niet of onvoldoende dat SPEER geen zelfstandige Business Case kon hebben. De afhankelijkheden met reorganisaties waren te groot om kosten en vooral baten aan SPEER te kunnen toewijzen. En ook hier geldt dat het voor een project dat is gericht op een middel (ICT) en daarmee aanbodgedreven is, vrijwel onmogelijk is een degelijke Business Case op te stellen. De Business Case is een middel voor de klant van een project om de rechtvaardiging te toetsen. Een door een (interne) leverancier geschreven Business Case zal niet meer zijn dan een papieren, bureaucratische exercitie zonder waarde.
Een additioneel probleem is de conversie van data van verouderde Legacy systemen naar het SAP systeem. In de Eindrapportage blijkt dat dit een groot punt van zorg was en nog steeds is. De geschiedenis leert dat conversieproblemen altijd optreden en zorgen voor hoge kosten en veel vertragingen. In de opzet van SPEER is gekozen om conversie te behandelen als aparte, losstaande projecten. Dit vergrootte slechts de afhankelijkheden, de risico's en daarmee de overschrijdingen.
In de Eindrapportage wordt gesproken over de beperkte medewerking van de bedrijfsvoering. Dit was natuurlijk volledig te verwachten. Binnen de bedrijfsvoering wordt vrijwel niemand warm van een ICT-project. De perceptie dat het volledig om techniek gaat ontstaat heel gemakkelijk. Zo'n verkeerde beeldvorming moet meteen voorkomen worden. Hebben de ICT’rs die beeldvorming aangepakt? Niet dus, eerder bevestigd.
In de Eindrapportage worden baten van het project gespecificeerd in termen van besparingen. Er worden arbeidsplaatsen geschrapt. Een andere reden voor de bedrijfsvoering om met grote zorgen en argwaan naar SPEER te kijken. Het omgaan met belanghebbenden en met hun zorgen lijkt geen prioriteit gehad te hebben binnen SPEER. Ook dit is vaak kenmerkend voor een ICT-project. Met alle negatieve gevolgen van dien.
De afsluiting van SPEER
In 2013 is het programma officieel beëindigd. Maar de werkzaamheden zijn verre van afgerond. Waarom is het programma dan beëindigd? Waarschijnlijk om politieke redenen; men was SPEER-moe na vele jaren van problemen en overschrijdingen.
Verdere ontwikkeling is nu overgedragen aan de staande organisatie. Het is te verwachten dat hierdoor de beheersing van het vervolgtraject zal verminderen. Kosten van verdere ontwikkeling zullen minder expliciet zijn en zullen vrijwel onbeheersbaar toenemen.
De Algemene Rekenkamer geeft een schokkend beeld van wat er bij de beëindiging van SPEER is opgeleverd. Er moet nog heel veel worden gedaan om effectief gebruik te maken van de resultaten van SPEER. Mede hierop baseert de Rekenkamer de schatting van wat SPEER zal gaan kosten: ongeveer €900 miljoen. In tegenstelling tot de Eindrapportage rekent de Rekenkamer ook interne kosten mee. De minister "herkent zich niet" in de cijfers van de Rekenkamer. Zij beroept zich daarbij uitsluitend op boekhoudregels die stellen dat interne kosten niet worden meegerekend. Het moment van beëindigen van SPEER en deze beperkte reactie van de minister geven weinig hoop voor effectieve beheersing van verdere kosten.
De Rekenkamer lijkt hierbij over het hoofd te zien waar de verreweg de meeste kosten gemaakt zullen gaan worden. Onderhoud en beheer kosten meestal een veelvoud van de kosten van ontwikkeling. Hierbij geldt dat de kosten van onderhoud hoger zullen worden naarmate de kwaliteit van de oplevering lager is. SPEER heeft zeker te maken met kwaliteitsproblemen.
Niet alleen zijn er grote zorgen over de kwaliteit van data na conversie. Ook geeft de Eindrapportage indicaties van problemen met de kwaliteit van de software. Door de manier waarop SPEER is opgezet en bestuurd zijn deze kwaliteitsproblemen onvermijdelijk. Door de verwarring van doel en middel heeft men zich gericht op technische kwaliteit (dus: volgens de leverancier) en onvoldoende op functionele kwaliteit (dus: volgens de bedrijfsvoering). Ook is hierdoor het risicomanagement onvoldoende.
Het gebrek aan kwaliteit zal ervoor zorgen dat de kosten van deze SAP invoering nog lang erg hoog zullen zijn. Misschien zal de naam SPEER niet meer gebruikt worden maar het is te voorzien dat problemen met SAP bij Defensie nog vaak aan het licht zullen komen.
Conclusies
Zowel de Eindrapportage als de rapportage van de Algemene Rekenkamer zijn te positief over SPEER. Het Ministerie van Defensie heeft veel tijd en geld verspild met het herhalen van ineffectieve praktijken die al decennia lang op dezelfde manier zijn gemaakt.
- ICT projecten mislukken omdat ze ICT projecten zijn.
- Wanneer een project wordt aangestuurd door een stafafdeling en hun specialisten, zal het project een ongeleid projectiel worden. Een CIO zal zich richten op ICT. Een inkoper zal zich richten op de aanbestedingsprocedure. Het doel van het project zal uit het oog worden verlopen en de beoogde verbeteringen zullen niet (volledig) worden gerealiseerd tegen hoge kosten.
- Voor een groot deel komen deze problemen voort uit de zucht naar efficiëntie. Maar wanneer efficiëntie wordt gezien als doel, zal effectiviteit het kind van de rekening worden. SPEER is daarvan een goed voorbeeld. Kwaliteit werd en wordt het kind van de rekening omdat SPEER zo efficiënt mogelijk was opgezet: een gespecialiseerd en geïsoleerd programma onder leiding van specialisten. Kosten en tijd zijn vervolgens uit de hand gelopen door gebrek aan kwaliteit die keer op keer tegen hoge kosten hersteld moesten worden. Een andere specialist, een financieel expert, zal dan met verwijzing naar boekhoudregels stellen dat er geen probleem is omdat herstelkosten vallen onder een ander budget.
Keer op keer zien wij dat projecten op dezelfde manier in dezelfde problemen komen. Keer op keer zien wij ook dat ICT specialisten (of zij die zich bevinden op "het snijvlak van ICT en business") met dezelfde oplossingen maar onder nieuwe labels komen. De nieuwste ICT trends zoals SCRUM, Agile en andere aanpakken voor systeemontwikkeling zijn oude wijn in nieuwe zakken.
In dit artikel zeg ik weinig nieuws. Als expert in methodes voor het sturen en managen van projecten (PRINCE2) en programma's (MSP) zie ik vrijwel dagelijks dat de ICT sector deze Best Practices kaapt en ze vervolgens in een verbasterde versie in de markt zet als hun volgende kunstje en ultieme oplossing.
Toch kan de schuld niet volledig bij de ICT sector worden gelegd. Zolang hun klanten zich niet anders gaan gedragen en dezelfde rituelen dansen volhouden, zal er weinig veranderen. De ICT sector en hun klanten houden elkaar in een kostbare wurggreep. Het volgende ICT project zal op dezelfde wijze in het nieuws komen, met dezelfde beschrijving van symptomen. Het ergste van dit soort projecten, binnen en buiten de overheid, is dat de macht der gewoonte regeert. Common sense is not common at all.
Het is een herhaling van zetten. Einstein's wet van waanzin is wat mij betreft volledig van toepassing: hetzelfde blijven doen en een ander effect verwachten. Het is dus hard tijd om projecten fundamenteel anders te benaderen. Het is mogelijk om met veel minder geld en tijd te komen tot veel betere resultaten. Vergeet hierbij niet de menselijke kant. De huidige praktijk is voor veel betrokkenen uitermate demotiverend en verspilt veel menselijk kapitaal.
Noten
1. Mijn volledige reactie op de Eindrapportage en op de rapportage van de Algemene Rekenkamer.
2. Een kleine greep van mislukte projecten:
Coca Cola, Free Record Shop en SAMAS kwamen ernstig in de problemen. En ook zonder SAP gaat het bij IT projecten regelmatig ernstig mis, zoals bij UWV of Van Lanschot.
3. 'De waanzin regeert!' Zolang ICT bedrijven hiermee wegkomen zal de situatie niet veranderen. Het management verantwoordelijk voor bedrijfsvoering en bedrijfsresultaat moet dit doorbreken. De volgende 2 artikelen van Nico Beenker met de reacties, laten zien dat de verkeerde zetten al 50 jaar lang hun tol eisen. Iedereen weet het maar men laat het gebeuren.
Opdrachtgever grootste risico bij IT-projecten
Met delegeren red je het niet
Dat IT-projecten vaak mislukken is bekend. De opdrachtgevers zijn vaak zélf verantwoordelijk voor de problemen. Sommige gerenommeerde IT-bedrijven maken hen het uitglijden wel erg gemakkelijk.
Falende IT-projecten een schande voor de (IT)adviesbranche?
Of te wijten aan inadequate sturing van de opdrachtgever
Als IT-projecten mislukken dan tast dat de reputatie van de ICT leveranciers aan. Maar zo gaat het al tientallen jaren. De ICT bedrijven lijken van teflon. En iedere keer staan weer generaties managers klaar met enorme bakken geld om dat weg te gooien. Hoe kan dit?
Waar vind ik toepasbare kennis en gedeelde ervaringen?
Probeer het Pro-abonnement een maand gratis
En krijg toegang tot de kennisbank. 110 onderwerpen, kritisch, wars van hypes, interactief en geselecteerd op wat wél werkt.
Word een PRO
In deze reactie ga ik een (al vaker gebruikte) vergelijking opbouwen, die op het eerste gezicht nogal kunstmatig
en overdreven lijkt. Bij nader inzien zal echter blijken dat ik ‘een punt heb’ met mijn
redenering.
Neem de volgende situatie in gedachten:
U bent toe aan een nieuwe auto. Om u te oriënteren gaat u naar verschillende
garagebedrijven. De verkopers zijn jong, dynamisch en aangenaam. U kiest een bedrijf uit
waarmee u zaken wilt gaan doen. Zij vragen welke eisen u stelt aan uw vervoermiddel. U
vertelt honderduit wat u zou willen kunnen met uw nieuwe auto. Zo wilt u niet alleen van A
naar B reizen, maar u wilt comfortábel van A naar B reizen. Uw verkoper knikt begrijpend en
wakkert uw enthousiasme nog een beetje aan. De concurrentie is tenslotte moordend in de
autobranche. Hij belooft u dat hij een auto heeft die aan al uw eisen voldoet. Ja, sterker
nog, hij heeft een auto die meer dan aan uw eisen/wensen/dromen tegemoetkomt. Al snel
komt het tot een koopovereenkomst. Iedereen blij.
De grote dag van de levering van uw auto is aangebroken. U gaat met uw ‘oude schicht’
welgemoed op weg naar uw garagebedrijf. Daar zullen u de sleutels van uw
spiksplinternieuwe bolide overhandigd worden. De frisse verkoper staat u te woord.
Hij vertelt dat een aantal opties, dat u bij uw auto had besteld, niet meer leverbaar bleken te
zijn. Het garagebedrijf moest tot een aantal modificaties overgaan om u toch een model met
vergelijkbare specificaties te kunnen leveren. Als voorbeeld noemt de verkoper “RONDE WIELEN”(?!).
Helaas zijn er vierkante wielen op uw wagen gemonteerd, zodat het niet meer
zo comfortabel rijden is. Gelukkig hebben ze dat probleem opgelost door het hele
veersysteem te veranderen.
Bovendien moet u niet raar opkijken als uw op een willekeurige ochtend uw autootje wilt
starten en; HIJ DOET NIKS(!?). “Daar moet u op dit moment even genoegen mee nemen,
want de werkplaats heeft nog geen oplossing voor dit probleem gevonden.
Tenslotte is er nog een aantal storingen te noemen, die zich op onregelmatige tijden en in
niet nader te bepalen omstandigheden voor kunnen doen. Die zullen we oplossen als ze
inderdaad de kop opsteken.”
Vraag: Gaat u akkoord met levering van een dergelijk vervoermiddel? Ik denk het niet!! U
zult alles doen om onder de koop vandaan te komen. U zult uw garagehouder in minder
prettige bewoordingen laten weten dat ‘dit niet bepaald de bedoeling is van de
overeenkomst die u met hem gesloten hebt’. Kortom: met zo’n apparaat gaat u de weg niet
op!
Gelukkig is het niet zo droevig gesteld in de auto-industrie. Integendeel; het bovenstaande
verhaal is uiteraard ontsproten aan de fantasie. De auto-industrie levert tegenwoordig
buitengewoon betrouwbare producten af, waar je jarenlang storingsvrij plezier van kan
hebben. Om zover te komen is deze industrie zich al meer dan honderd jaar permanent aan
het verbeteren. Ze zullen wel moeten, want de concurrentie ligt op de loer!.
Conclusie is dus dat voor de auto-industrie het hierboven vertelde verhaal (gelukkig) erg
fantasierijk is.
Kijken we echter naar de automatiseringsindustrie (ict) dan blijkt het
verhaal helemaal niet zo fantasierijk te zijn, maar bittere realiteit! In de ict worden we
voortdurend geconfronteerd met door de klant niet-geautoriseerde modificaties, met
onverklaarbare storingen tot gevolg, die op allerlei onnavolgbare manieren met kunst- en
vliegwerk, min of meer worden opgelost. Het is me een gestumper en gestuntel op de
elektronische snelweg.
En: Het excuus dat de auto-industrie al meer dan honderd jaar bestaat en de
automatiseringsindustrie nog maar dertig jaar, gaat niet op! In de automatiseringsindustrie
wordt gezegd dat er ‘iedere drie ouderwetse kalendermaanden een automatiseringsjaar
voorbij is’. Dus is het een schande dat in de ict het na honderdtwintig jaar stuntelen en
stumperen niet verder is dan dat het nu is. Zeker voor wat betreft de kwaliteit. Met de
“hardware” gaat het misschien de goede kant op, maar met de “software” is het nog steeds
droevig gesteld! Het is een wonder dat we het allemaal maar accepteren.
Engbert Visscher
Met jouw goedvinden voeg ik er nog een kleine maar essentiële component aan toe. Je benoemt hem wel in je artikel maar hij zit nog wat verscholen in het hele verhaal.
Projecten zoals Speer zijn zoiets als een mooie jonge vrouw die de ideale Prins krijgt opgedrongen met de toevoeging: Jij zult nu gelukkig worden.
Die ideale Prins voor defensie (Speer) is dat in deze case zoals gezien door de ogen van de Minister, door ogen van de externe ICT adviseurs en door de ogen van de CIO.
Allemaal heel verstandige mensen. Hebben ze gelijk?
Jazeker, vanuit het perspectief van een neutrale buitenstaande hebben ze gelijk.
Maar..
De bruid, hier de operationele defensie eenheden, hebben een heel ander beeld van die ideale prins. Bovendien moet de bruid nu haar lievelingsactiviteiten loslaten en daarvoor de activiteiten en de leefwijze van de haar opgedrongen Prins overnemen.
Misschien dat deze exercitie in de middeleeuwen kans van slagen had maar vandaag de dag gaat dit niet meer werken.
Overigens werkt deze methode in de USA wel. Maar daar is het motto van de directie. U bent het met ons eens of u verlaat het bedrijf. Die cultuur kennen we in Nederland niet.
Moraal van dit verhaal: Als je wilt dat je organisatie effectiever en efficiënter gaat werken en dat alle onderdelen op een zelfde manier gaan werken dan kun je die visie maar beter eerst bij je mensen neerleggen en een proces in gang zetten dat hen ook tot die overtuiging brengt.
Pas als men hier in brede lagen van de organisatie van overtuigd is kan je gaan zoeken naar methoden en middelen (zoals SAP) om die gedeelde visie te realiseren.
Het basisprincipe "IT volgt de business" geldt vandaag de dag niet meer.
IT is een dermate dominante innovatiefactor geworden dat zij ook vaak leidend is in de inrichting van business en proces. Dat dit niet altijd wenselijk is lijkt mij evident, immers, de de organisatiestrategie en de "strategic alignment" van de operatie kan daardoor te rigide bepaald worden. Tegelijkertijd biedt IT juist ook de faciliteiten om eenduidig, consistent en aansluitbaar te kunnen werken en beheren...
Business en IT zijn dermate verweven dat ze in symbiose zijn. Ze zouden als van gelijkwaardig belang gezien moeten worden en als één integraal systeem benaderd moeten worden. De menselijke organisatie van weleer is de afgelopen decennia tot een cyborg verworden, waarbij de mens haar nieuwe "lichaamsfuncties" langzaam aan het leren begrijpen en internaliseren is... en vaak ook afstoot.
Een natuurlijke reactie, wellicht, op een ontwikkeling die voornamelijk door wedloop bepaald wordt en deels door intrinsieke innovatie. We kunnen ons afvragen of het goed voor de mensheid is om alles te machinaliseren en automatiseren. Het comfort van de techniek bespot wellicht tegelijkertijd onze zintuigen.
Machines hebben, anders dan mensen, specifieke instructies nodig en kennen geen abstractie, beeldspraak of gevoel (tenzij specifiek geformuleerd). Daarom is het bepalen van heldere basisregels op meta-niveau en een consistente projectie daarvan op de operatie noodzakelijk om zo'n symbiotisch systeem goed te doen functioneren. Daar is dus een zeker systematische werk- en denkwijze voor nodig. Ik zie het persoonlijk als een "grote puzzel", waar op basis van alle (business) variabelen een gemene deler gevonden dient te worden op basis waarvan de organisatie gestructureerd kan worden.
De bedrijfscultuur speelt vaak parten om een goed werkend systeem neer te zetten. Mensen willen wel A en C zeggen maar geen B, bijvoorbeeld. Dan werkt het niet meer. Of men wil gefaseerd implementeren op de onlogische volgorde, om vervolgens te constateren dat het systeem niet werkt. Men gebruikt ducktape waar gelast moet worden en beklaagd zich vervolgens over de stabiliteit, enzovoorts en besluit uiteindelijk om de nieuwe kleren van de keizer lof toe te zwaaien. Menselijk, al te menselijk...
Kortom, in deze tijd waarin mens en machine samensmelt zien we intergratieproblemen. Als je met machines wilt werken zul je specifiek en consistent moeten zijn, anders werkt het niet. De menselijke natuur en omgangscultuur binnen organisaties werkt dit vaak tegen. Business en techniek zijn vandaag de dag in symbiose.
Vind ik.
Met vriendelijke groet,
Stefan Block
SAP is een van origine Duits ERP systeem ontworpen voor commerciële ondernemingen.
De pogingen dat te implementeren in een overheidsorganisatie met een heel andere beslissingsdynamiek en -nog lastiger- medewerkers die eeuwen lang gewend zijn om hun werkwijze ongewijzigd te blijven benutten, en waar iedereen een mening heeft die bijna veto rechten geeft, zijn dus uitermate complex.
Als je dan probeert een standaard pakket aan te passen aan die vorm van bedrijfsvoering is laten we zeggen: naïef.
Projectleiding door de klant
Opknippen van een SPEER tot een klein speldenkussen.
De spelden als duidelijke gebruikerseisen en het kussen als een robuuste infrastructuur.
Aanbesteden en betalen naar resultaat
Tijdens het project moet(!) de klanttevredenheid al duidelijk stijgen
Ook zijn er 'Stevige (interim) Leiders' nodig in de lijn die de klant op 1 zetten en houden. Zij weten hoe je de specialisten in toom, maar ook tevreden houdt. Tot dat moment blijft het getob en SAPpelen aan de leiband van goed bedoelend en goed verdienend ICT volk.
Maar zoals gezegd voor stevige leiders wordt niet gekozen want het zit niet in de cultuur van het poldermodel om dat te doen.
Wat mij betreft is een parlementaire enquête op zijn plaats en broodnodig. Deze enquête zal onder andere als onderzoeksvraag moeten hebben 'welke culturele aspecten aan opdracht en leverancierszijde zijn onlosmakelijk verbonden met falende ICT projecten binnen de overheid'.
Elk project dat na oplevering van dit rapport wordt gestart maakt helder en eenduidig gebruik van de bevindingen op straffe van ontslag van de verantwoordelijk opdrachtgever.
Ik hoor de reacties al.. 'ehh, kan dat rapport niet zonder enquête?' Jazeker, de conclusies kunnen we nu al trekken. Hierboven heb ik al een beginnetje gemaakt. Maar het is een cultuur'ding'. En dat zal door de tweede kamer het ambtelijk apparaat ingedrukt moeten worden.
900 miljoen euro.....pffff.
Fantastisch dat je zoveel tijd en moeite stopt in het doorgronden van dit SPEER project en dit met ons deelt. Het is en blijft belastinggeld en daarnaast leerzaam.
Ik kan me heel goed vinden in je commentaar / visie:
- run het vanuit de business
- IT is middel en nooit doel
- Grote IT projecten zijn VERANDERMANAGEMENT trajecten. Ze raken direct de mensen, machtsposities, veranderen verhoudingen, er zijn weerstanden en ga maar door.
Mijn gedachten gangen / visie:
Ik zou eerst eindeloos de scope van het project doorspreken totdat iedereen exact weet wat het doel gaat worden en er ook volledig achter staat. En pas als iedereen er volledig achter staat, het draagvlak er is, weerstanden weg zijn, dan pas starten met bouwen. Het bouwen zelf is technisch gezien namelijk nooit de uitdaging. Het is gewoon een REORGANISATIE met alle perikelen van dien. En zolang er geen consensus is starten we niet.
Daarnaast zou ik werken met een MVP en in kleine stappen van succes naar succes gaan. Vanuit deze positieve flow kan je groeien en willen en gaan mensen mee. En groot voordeel van MVP (of lean en mean) is dat je steeds een 'select' gezelschap stoort met je project. Steeds is maar een klein deel van alle betrokkenen aan de beurt om zich in te spannen. En ook dit stappenplan tekenen we vooraf zoveel mogelijk uit met alle betrokkenen. Wat dan, waarom dan, waar loop je tegenaan in het veld/werk, wat is dan de winst, et cetera. Gewoon eerst heel kritisch tekenen wat je hebben wilt en waarom.
En dan nog wat: SAP heeft er natuurlijk alle belang bij dat het niet goed gaat. Eenmaal gekozen voor SAP is altijd gekozen (zie ook een leuk interview met Luc Verbist in de rubriek ICT & Internet op ManagementSite, gaat over leverancierskeuzes). En SAP weet dat maar al te goed. En als het mis gaat kunnen ze altijd wijzen. En daar komt bij: aanbestedingen van deze grootte zijn slechts voor enkele bedrijven weggelegd vanwege de eisen, garanties, et cetera. De echt innovatieve en kleine bedrijven komen niet aan bod.
De overheid zou er verstandig aan doen om het gehele aanbestedingstraject te herzien. Welk doel dient het en welke spelregels zitten innovatie in de weg. Want uiteindelijk wil je innoveren. En innovatie komt van mensen die er voor gaan een prikkel voelen, hun grenzen opzoeken, hun passie volgen.
Nogmaals dank Nico voor het artikel!
Softwareontwikkeling is tastbaar en meetbaar en geeft een schijnzekerheid terwijl slechts een instrument wordt ontwikkeld zonder al te veel aandacht te besteden aan waar het echt om gaat, het effectief en efficiënt inzetten van deze in de organisatie. Dit laatste zou de driver moeten zijn.
Men weet dat het invoeren van een nieuwe technologie impact heeft op de organisatie, haar mensen, processen en procedures, strategie en in vele gevallen haar cultuur. Het rendement van een invoering van software ligt aan de snelheid van adaptatie en assimilatie in de organisatie en dit kan alleen met behulp van een holistische aanpak vanuit een organisatieveranderoptiek.
Het gaat niet alleen om de softwareontwikkeling, uitrol en training, de organisatie zal
"Ready, Willing and Able" worden gemaakt om implementatie succesvol te maken. De initiele investeringen zullen wellicht wat hoger zijn maar de slagingskansen nemen fors toe en het rendement zal hoger en sneller zijn.
Penny wise, pound foolish zullen we maar zeggen.
Naar mijn overtuiging kunnen deze kostenverslindende trajecten alleen voorkomen worden wanneer we anders gaan aankijken naar uitbestedingswerkwijzes, door anders te gaan werken met financierings en/of verrekeningsmodellen tussen klant en leverancier. Met name de relatie klant-leverancier moet veel meer evenwaardig zijn en moet men durven business commitment (met langere termijn visie) met elkaar aan te gaan. En dus ook inkopers minder leidend in bepalend in de uitbesteding. Ik blijf hopen...
Prof. Dr. Albert Boonstra heeft hier een prima boek op geschreven, ICT mensen en organisaties, dat ik momenteel gebruik voor mijn eindscriptie. Hij noemt ICT als ondersteuning van de bedrijfsdoelen en laat dit zien in een model (vergelijkbaar met 7-S).
Dergelijke projecten zijn in feite ook veranderingstrajecten omdat medewerkers (interne klanten) hun werkwijze moeten veranderen. Boonstra noemt dit Technochange of ICT in samenhang met organisatieverandering. Naar adoptie en acceptatie van technologie is veel onderzoek verricht, dus met de slaag en faalfactoren had men rekening kunnen houden.
Wat SAP betreft hoor ik vaak de betekening "Software Against People"; lijkt me een duidelijk signaal hoe men soms/vaak over SAP denkt.
Een heel herkenbaar verhaal overigens!
Met vriendelijke groet,
Roel van der Vliet
En ik ga helemaal mee in de uitspraak van Alexander Ket dat grote IT-projecten gewoon verandermanagement trajecten zijn. Inderdaad we hebben te maken met ménsen in organisaties. Die kun je niet rationaliseren alsof het processen of machines zijn. Bovendien hebben diezelfde 'gebruikers' vaak uiterst zinnige dingen te zeggen en is weerstand simpelweg om te buigen in betere oplossingen, maar dan moet je als CIO of projectmanager wel het lef hebben om te luisteren, bij te sturen en ja: tijd te 'verliezen'.
En verder, als je de aanbestedingdocumenten van de meeste overheden ziet, dan weet je dat ze voor de gek gehouden willen worden. De meesters van deceptie met de meest onrealistisch lage prijs winnen het gevecht om de gunning. En goh......wordt het toch nog veel duurder. Wat een verrassing. Met een realistische prijs wint geen enkele leverancier een aanbesteding.
In de overheid is het helemaal kommer en kwel. Het probleem daar is dat er te grote doelen worden gesteld, de IT adviseur daar niet eerlijk over durft te zijn en het gemiddeld elke vier jaar anders moet, omdat een andere politieke partij het voor het zeggen heeft en het per definitie altijd net weer anders wil. Een overheidsproject met een horizon langer dan 2 jaar is bijna per definitie tot mislukken gedoemd.
Misschien moeten we daar eens bij stil staan. Een implementatie van 10 jaar!!!! Hoe bestaat het?! De eisen en wensen die men toen had gelden allang niet meer. De wereld is allang niet meer hetzelfde.
Mijn advies: stel eens niet zo'n absurde doelen met zulke tijdslijnen, maar durf voor kleine afgeronde successen te gaan. Dat maakt het een stuk controleerbaarder, de kosten rijzen de pan niet uit, de verander stappen zijn te overzien en je kunt eerder stoppen of pas op de plaats maken. Scheelt (ons) een hoop geld.
De kern is:
- Mensen willen wel veranderen maar willen niet veranderd worden.
- Kwaliteit kan alleen bereikt worden door de vraag van de (interne) klant; niet door het aanbod van de (interne) leverancier
- Sturen op efficiëntie is zinloos; efficiëntie is slechts een bijproduct van effectiviteit. "There is nothing so useless as doing efficiently that which should not be done at all." (Peter Drucker)
En daarom is het onverstandig om stafafdelingen zoals Financiën, HR en ICT macht te geven. Deze afdelingen zouden een ondersteunende rol moet hebben. Helaas is dat in Tayloriaanse organisaties (machinebureaucratie) niet het geval.
"Where Taylor rules (short term focus, efficiency, compliance), Deming is ignored (long term focus, effectiveness, quality)." (Nico Viergever)
1. "een interne IT-afdeling zal IT zien als doel". In mijn ervaring zien juist interne IT-afdelingen IT als middel en zijn zij juist de waarschuwende partij, terwijl de opdrachtgevers hooggeplaatste managers (directeuren) of bestuurders zijn die zonder verstand van ICT, zonder te willen luisteren naar mensen die de juiste afwegingen kunnen maken, verordonneren wat er volgens hen moet gebeuren. Echte ICT-ers zouden het nooit zover laten komen.
2. Een onuitroeibare foute opvatting van onder meer dit soort opdrachtgevers is om niet te automatiseren maar een "interactief" kliklikliklik systeem te maken waar voor elke simpele transactie tig keer geklikt moet worden. Mensen, leer dat nou eens: als je moet klikken is het NIET geautomatiseerd! Per definitie! Klikken is handwerk!
3. Opdrachtgevende bestuurders zien hun kleine moeilijkheden steevast als grote problemen waarvoor een groooote oplossing binnengerold moet worden. Daardoor kun je vaak de problemen juist niet meer oplossen: het gereedschap is te lomp.
@Stefan, IT is weliswaar een innovatiefactor voor organisaties maar een goede bedrijfsstrategie maakt gebruik van allerlei sociale en technologische innovaties. Ik verdenk je er haast van dat je een ICT-er is want dit is typisch zo'n reactie, die alleen een ICT-er kan geven.
Het is sowieso onzinnig om bijna een miljard uit te geven aan de implementatie van software, die 20 miljoen kost. Dan weet je van tevoren, dat dit een hopeloos project wordt.
Ik riep het in 1993 al, te vaak helaas tegen dovemans oren: Problemen in ICT projecten zijn voor 20% technisch en 80% menselijk en niet andersom.
Laat je dit soort projecten runnen door 'techneuten' die technisch denken, dan kan het niet anders dat je problemen krijgt omdat ze voor alles zoeken naar een technische oplossing. Een iets andere vorm van de vergelijking met de hamer en de spijkers. De crux zit hem ècht in de kwaliteit van de (onderlinge) communicatie.
En met communicatie bedoel ik niet veel bellen en veel emailen, maar de verbale oordeelsvorming tijdens een overleg, de wijze waarop afspraken worden gemaakt en de manier waarop mensen daarop worden aangesproken, óók - of juist- als het mis gaat of dreigt mis te gaan
Is de oordeelsvorming onder de maat dan kun je de mooiste modellen, systemen en infrastructuren hebben: Het werkt voor geen meter of maar een beetje.
Winfried Deijmann
Dus in hoeverre ondersteunt dit systeem hen bij de uitoefening van hun vak?
Vaak start de vraag om een dergelijk systeem hoog in een organisatie en wordt er top down gewerkt. Tegen de tijd dat vragen gesteld worden aan de vakman is het systeem al bijna klaar/ingevuld en dan ontstaan de problemen (en vaak duur onderhoud en aanpassingen). Nog maar te zwijgen over de software die al klaar is en waar een bedrijf ingeperst wordt, omdat het zo goed werkt bij een ander bedrijf. Hier zijn voorbeelden genoeg te noemen.
En ja, een administratief medewerker heeft andere wensen dan een manager. Als dan voor beiden naar 1 oplossing gezocht wordt zijn beiden hoogstwaarschijnlijk ontevreden en is het draagvlak om het systeem te voeden ver zoek. Beter is het om de verbinding te zoeken (en dat kan zomaar betekenen dat er geen duur systeem hoeft te komen).
Het wordt tijd dat we eens maatschappelijk verantwoord gaan investeren in projecten zodat veel gemeenschapsgeld niet over de balk gegooid wordt. We hoeven geen coordinatoren/controleurs etc te hebben die dit bewaken, maar laat de vakmensen beoordelen wat ze nodig hebben en ben dan gezamelijk als team kritisch.
Wanneer je de Eindrapportage leest, krijg je de indruk dat SPEER is gestart vanuit de IT. Men wilde af van de wildgroei van Legacy en de informatievoorziening herstructureren.
Een citaat uit de Eindrapportage:
"In zijn brief van 10 september 2001 aan de Tweede Kamer zette
Staatssecretaris Van Hoof uiteen hoe Defensie de herstructurering van
de informatievoorziening wilde vormgeven. De informatievoorziening
moest beter worden afgestemd op de operationele inzet en de bedrijfsvoering.
Deze moest flexibel zijn, doelmatig en beheersbaar"
Ik heb de indruk dat SPEER van begin af aan een IT gedreven project was waarbij gebruikerseisen gezocht werden. De rest (duur/kosten) is dan een logisch gevolg.
De auto-industrie van tegenwoordig is juist een van bedrijfstakken waar mij dit van toepassing lijkt. Auto's zijn mechanisch enorm veel sterker geworden, maar als het fout gaat, betreft het meestal de software die nu van alles aanstuurt. De ICT/software is ook in auto's leidend geworden.
In veel moderne auto's zitten allerlei functies gekoppeld, waardoor de kans op idiote storingen juist toeneemt. Is er iets mis, dan koppelt de moderne automonteur de auto aan een diagnose-apparaat, in plaats van -zoals vroeger- zelf op zoek te gaan. Vindt dat apparaat niks, dan bestaat het niet. Maar het kan ook zijn dat het probleem de melding vanuit het systeem zelf blijkt te zijn.
Maar de boordsoftware heeft de vorm van de wielen nog niet onder controle, anders hadden we vast al echt vierkante wielen gehad.
Kortom: ICT beoogt allerlei processen efficiënter te maken, maar is zelf een belangrijk onderdeel van de algehele verwarring. Ik vrees voor de dag dat de stroom langdurig uitvalt.
Echte IT-ers willen weten welke afstemmingen nodig zijn, welke problemen zijn er, wie ondervindt die problemen en wat moet er opgelost worden. Wat is er nu inflexibel, wat betekent dat precies en wie moet er wat precies kunnen. Wat bedoel je precies met "afstemmen op de bedrijfsvoering". Wat gebeurt er nu niet doelmatig, is dat iets wat met automatisering opgelost kan worden of is het een gedragsprobleem, logistiek probleem of organisatorisch probleem.
Wat maakt het nu niet beheersbaar? Is het niet beheersbaar of is het meer zo dat de top er geen zicht op heeft? Moet de top dan niet gewoon meer belangstelling tonen en zorgen dat ze meer verstand van zaken hebben?
Haalbaarheid, werkbaarheid, beheerbaarheid, bruikbare funktionaliteit, gebruikersaspekten: IT-ers vinden die zaken vanaf het begin af aan belangrijk.
Het probleem is eerder dat de echte IT-ers buiten de besluitvorming gehouden worden. In termen van Prince II: pas als het Work Package aan de orde komt worden de echte IT-ers erbij gehaald, en tegen die tijd is het allang een prestigekwestie in plaats van een praktische operatie.
Je artikel doet veel stof opwaaien als ik de reacties zie. Met je conclusie ben ik het eens: een ICT project moet gepositioneerd worden als een managementvraagstuk. Maar ik sla even aan op je opmerkingen over Gateway Reviews: het beeld wat je schets kan ik volstrekt niet plaatsen. En staat ook haaks op het grote succes van de peer-to-peer methode van Gateway. Volstrekt onvergelijkbaar met Prince2 of MSP. Hier wordt échte denkkracht gebruikt van ervaren professionals. En ik kan het weten: heb in de afgelopen twee jaren in een 10-tal Reviewteams geparticipeerd, allen met het hoogste lijnmanagement als Senior Responsible Owner. Waarbij de afgegeven adviezen de kern van de tent - en daarmee de directietafel - in volle omvang raken.
Even mond spoelen dus!
Goede groet,
Dirk-Jan
Echte IT-ers? IT-ers vinden dat belangrijk? De ervaring leert dat IT-ers dat zelf wel vinden maar dat hun gebruikers daar toch heel anders over denken.
Is jouw reactie er ook niet een van de categorie: "To a man with a hammer in his hand the whole world looks like a nail"
Wat jouw verwijzing naar PRINCE2 betreft: niet alleen door de foutieve schrijfwijze (in de ICT sector wordt inderdaad vaak gesproken over PRINCE II, In deze sector heeft men de klok horen luiden maar waar is de klepel???), maar ook inhoudelijk zit je er naast. Want om een voorbeeld te geven: hoe zit het dan met de leverancier in de Stuurgroep?
Toch is ook de verwijzing naar PRINCE2 een aardige in deze context. Bij het Ministerie van Defensie zijn jarenlang bakken met geld uitgegeven aan PRINCE2 trainingen. Maar door de verkeerde partijen voor het verkeerde publiek. Voor en door ICT-ers.
Door de verkeerde partijen: vooral een ICT-gigant met wortels in ICT beheer heeft hier veel geld mee verdiend. Maar PRINCE2 is een aanpak voor klanten, niet voor leveranciers. Ook moet ik de eerste beheerder nog tegenkomen die een goed verhaal over verandering (projecten) kan vertellen. Ook de genoemde Gateway Review aanpak kwam uit deze hoek: de initiator, de voormalig CIO Rijk kwam van deze ICT-gigant vandaan en vergeleken de Gateway Review eens met ITL (ICT beheer). Sic!
Voor de verkeerde partijen: de PRINCE2 opleidingen werden veelal aan ICT medewerkers geven, meestal met als enige reden dat ze ook al ITIL hadden gevolgd.
Dit alles is relevant is de context van SPEER. De problemen zijn fundamenteel. Projectbeheersing, voor zover serieus genomen, van deze categorie projecten wordt gezien als een ICT taak. Maar waar is het opdrachtgeverschap?
Even mond spoelen? Ik geloof het niet. Al bij de introductie van de Gateway Review door de CIO Rijk had ik grote bedenkingen. Want alleen voor ICT projecten??? Voor ICT-ers door ICT-ers??? Dat is nu ook net de kern van mijn kritiek op SPEER.
Nu zie ik wat de Gateway Review bij SPEER heeft opgeleverd (hoewel de review vertrouwelijk is). Deze Gateway Review heeft zich blijkbaar positief uitgesproken over het stoppen van SPEER maar onder de radar doorgaan met SPEER.
En dit was niet mijn eerste ervaring; zie http://www.viergever.info/nl/methode_invoeren.aspx (einde case 2).
The proof of the pudding is in the eating. Tot nu toe smaakt het niet goed...
Ik neem weer de auto als metafoor. Jaren en jaren reed ik in een zuinig en zeer betrouwbaar Japannertje uit begin jaren '90. Er was sprake van een bescheiden afdeling ICT, in de vorm van een motormanagement dat nooit van zich liet horen en in stilte de brandstofinjectie regelde. Iedere afdeling deed z'n werk en alles marcheerde. Een katalysator zorgde ervoor dat de uitlaatgassen minder vuil het milieu in gingen. Stuurbekrachtiging zat er niet in, de ramen moest ik zelf open slingeren en ook zaken als airco, airbags en ABS ontbraken. Eens per jaar bezocht ik de garage voor keuring en onderhoud. De garagist keek wat bedenkelijk bij de zachtjes voortschrijdende roest, maar ik kon weer een jaartje bollen. Ik was er stik tevreden mee.
De meeste auto's van nu zitten vol elektronische systemen en software, zoals elektrische stuurbekrachtiging, met allerlei instelmogelijkheden voor 'rijbeleving'. Ook de handrem is elektrisch en het schakelen gebeurt vaak al via een gerobotiseerde automaat. De software van het motormanagement berekent per cilinder nauwgezet de hoeveelheid brandstof, luchtmengsel en het ontstekingsmoment. Het resultaat is er naar, want op de snelweg zoeven die moderne wagens je achteloos voorbij.
Ook zitten er allemaal elektronische leukigheidjes in, waarmee de rijder veiliger en comfortabeler aan het verkeer deelneemt, zich kan vermaken en waarover hij kan opscheppen tegen andere autogekken. Deze systemen zijn op een of andere manier ook nog aan elkaar gekoppeld.
Het laat zich raden met welke auto je de meeste kans op storingen hebt. Daar komt bij dat de monteur door de veelheid aan systemen nergens bij kan en allerlei aggregaten moet verwijderen om een onderdeel te vervangen. Is dat nu efficiency? Toch is terug naar de eenvoud meestal ondenkbaar of onmogelijk.
De Vanguard Methode:
@NicoViergever @Managementsite IT kan succesvol en goedkoop zijn. Volgens John Seddon is de sleutel een systeemaanpak https://www.youtube.com/watch?v=hbNsQFd8DQw
2:28 PM - 26 Mar 2014
Systeemdenken vanuit de vraag; dit alles in lijn met de ideeën van E.Deming en bijvoorbeeld .Goldratt. Dit laat ook zien dat innovatie niet een zozeer IT vraagstuk is maar vooral een vraagstuk van organiseren.
Daar heb ik het over!
Ook mijn ervaring is dat bij grote ICT projecten er altijd twee problemen op te lossen zijn:
- de organisatorische
- de technische
Om organisatorische problemen op te lossen zul je uiteindelijk het gedrag van mensen moeten veranderen maar veel managers kunnen of zijn niet in staat hun mensen inhoudelijk aan te spreken / aan te sturen zodat zij hun gedrag aan passen. Daarom bestaat er ook vanuit de niet-techniek hoek de ijdele hoop dat een technische oplossing organisatorische problemen kan verhelpen hetgeen zich vaak uit in een haast onmogelijk te realiseren programma van eisen.
Zo werk het dus niet, eerst de organisatorische problemen aanpakken en pas dan bekijken wel technische ondersteuning je nodig hebt. De oorzaak van het falen van projecten in de techniek zoeken (of technische mensen als een CIO aanwijzen) is mijn inziens onjuist, die CIO had gewoon gecorrigeerd moeten worden door een CEO.
Als techneut word ik er wel een beetje flauw van de altijd maar weer met het beschuldigende vingertje naar "de techniek" wordt gewezen, hoewel je gelijktijdig, en zeer terecht, concludeert dat de opdrachtgever zelf verantwoordelijk is. In het spanningsveld opdrachtgever / aannemer zal helaas altijd de opdrachtgever verliezen.
Verder, al vind ik Agile weer de zoveelste hype op ICT gebied, het is toch fundamenteel anders bv het waterfall model. Zeker geen oude wijn in nieuwe zakken. Waarom software/ICT projecten falen is al in 1975 uitmuntend geanalyseerd door F.P. Brooks in zijn boek de Mythical Man-Month.
(zie http://en.wikipedia.org/wiki/The_Mythical_Man-Month) en alle lezers die menen een vergelijking te moeten maken met andere vakgebieden zouden eerst eens dit boek moeten lezen.
Vriendelijke groet,
Frits
- het bestek was voldoende gedetailleerd en concreet.
- er werd geopteerd voor een onderhandelingsprocedure waarbij kwaliteit hoger scoorde dan prijs.
- we werken in fasen. elk deelproject wordt terug onderhandeld met de dienstverlener.
- we werken in fasen waardoor de organisatie zich stapsgewijs kan aanpassen aan de nieuwe manier van werken en waardoor kan geleerd worden uit vorige fasen.
- er is een sterke begeleiding vanuit IT waarbij de ICT-ers niet alleen voeling hebben met de techniek maar ook zeer veel voeling hebben met de inhoudelijke materie
- vanuit de dienst personeelsbeleid is er ook voldoende personeel beschikbaar om dit project te begeleiden en te sturen
- er is een zeer nauwe samenwerking tussen de administratie en de dienstverlener. De dienstverlener dient zijn werkzaamheden in de burelen van het bestuur uit te voeren zodat er snel en vlot kan informatie doorstromen naar de verschillende instanties
- er wordt gezorgd voor interne kennisopbouw zodat het provinciebestuur in staat is om zelf het onderhoud op de systemen uit te voeren (doen we met 2 fte) en om bepaalde zaken binnen een project toch in eigen beheer uit te voeren (vb. rapportering waar een groot budget naartoe gaat en dat perfect door eigen mensen kan worden uitgevoerd).
- pragmatische aanpak waarbij alle medewerkers binnen het project maar één doel hebben nl. een goed project neerzetten binnen tijd en budget.
Deze manier van werken werd binnen ons bestuur reeds vele malen toegepast en het aantal 'mislukte projecten' en bijgevolg niet nul maar wel bijzonder klein.
De door Petra aangedragen suggesties zijn prima. Vooral het opdelen van zowel werk als van onderhandelingen met dienstverleners is cruciaal in mijn optiek. In het kader van SPEER is het ministerie van Defensie daar ook achter gekomen, zo blijkt uit de Eindrapportage.
Ik zou wel van Petra willen weten of haar klant ook vindt dat er sprake is van een succes. Heel vaak hoor ik helaas van ICT-projectmanagers dat de meeste van hun projecten succesvol zijn. Wanneer je vervolgens vraagt wat de klant ervan vindt, hoor je een heel ander verhaal.
Wat mij in dit kader heel veel zorgen baart, is dat Petra veel nadruk legt op kosten (budget) en tijd. Het is bijna een wetmatigheid dat projecten die op tijd en binnen budget zijn beëindigd, mislukt zijn. Zie als voorbeelden:
- RandstadRail, http://nl.wikipedia.org/wiki/RandstadRail#Problemen_met_ingebruikname
Op tijd en binnen budget opgeleverd maar kort na oplevering buitengebruik gesteld en pas na een jaar van herstelwerkzaamheden weer opnieuw in gebruik. Het projectmanagement kreeg toch complimenten voor het op tijd en binnen budget opleveren. De tijd en kosten voor herstel waren volgens de betrokkenen buiten het project en daarmee geen probleem...
-Heathrow T5 was ook op tijd en binnen budget opgeleverd maar... http://en.wikipedia.org/wiki/London_Heathrow_Terminal_5#Opening
In zijn boek over Project Based Work beschrijft J.Rodney Turner onderzoek in Australië. In het begin van de jaren 90 van de vorige eeuw werd gekeken naar honderden projecten die op tijd en binnen budget waren opgeleverd. Een aantal jaren later werden al deze projecten, zonder uitzondering, beoordeeld als mislukt.
Tijdens een PRINCE2 cursus, een aantal maanden geleden in Oslo, merkte een deelnemer op dat in haar organisatie een project werd gebruikt als modelproject. Zo moesten alle andere projecten ook bestuurd worden. Het project had op tijd en binnen budget opgeleverd. Maar, zo vertelde zij lachend, de resultaten van het project waren nooit in gebruik genomen...
De wetmatigheid: wanneer primair gestuurd wordt op kosten en tijd, zal de kwaliteit het kind van de rekening worden. En daarmee zullen de resultaten op lange termijn niet worden gehaald (daarmee ook een reden waarom de leverancier, intern of extern, zich niet moet bezighouden met de Business Case en ook een projectmanager van de klant moet komen).
Het is echter wel mijn ervaring dat wanneer de focus volledig op de Business Case ligt (op toegevoegde waarde vanuit opdrachtgeverschap dus!) de kwaliteit zal toenemen. En daarmee zullen tijd en kosten als bijproduct afnemen. Ook op de langere termijn in beheer en onderhoud.
En of de klanten tevreden zijn? Ik denk het wel. Zeker bij de dienst personeelsbeleid (= de grootste klant) is men zeker tevreden met het systeem. Het vorige 'systeem' bestond immers uit een pakket dat kan dienen voor de loonadministratie maar waarbij alle andere processen gebeurden via Access en Excel (dus veel fouten, dubbel werk enzovoort). Nu wordt er on line gesolliciteerd (en ja, we hebben veel vacatures (ook voor minder geschoolde profielen) en veel kandidaten, en tijdsregistratie (registratie van vakantie, reglarisaties, ...) gebeurt nu ook via ESS waardoor 2 fte kunnen worden uitgespaard op de dienst personeelsbeleid.
De andere medewerkers binnen de organisatie worden alleen met ESS/MSS geconfronteerd en daar moet ik ruiterlijk toegeven dat er wel wat gemopperd werd (wordt?). We hebben immers gekozen voor een standaard SAP-implementatie waarbij je dus geconfronteerd wordt met 'Duitse' schermen (ze doen wat ze moeten doen maar zijn echt niet sexy en niet altijd even doordacht qua gebruiksvriendelijkheid).
Moraal van het verhaal: Het ding werkt bij ons en het blijft werken. Het is zeer robuust en we kunnen er alle processen mee ondersteunen. Alleen zou SAP eens werk mogen maken van een meer sexy interface. Het oog wil immers ook wat.
En voor wie echt nieuwsgierig is: het provinciebestuur is steeds bereid om haar kennis te delen met anderen. U mag ons bijgevolg steeds contacteren in verband met onze projectwerking op informaticavlak. Dit kan voor beide partijen een leerrijke ervaring zijn.
Het verschil tussen denken en doen.
Mijn complimenten voor je analyse. Ik wil daar graag nog het nodige aan toevoegen.
Ik voer momenteel een promotieonderzoek uit naar het strategisch veranderingsproces van Defensie vanaf 2003 tot heden. Het programma SPEER kan niet los worden gezien van beoogde veranderingen in de aansturing van de uitvoerende defensie-onderdelen in het bijzonder de traditionele land-, luchtmacht en marine. Onder leiding van minister Kamp was het in 2003 zaak de invloed van deze onderdelen, die ieder een eigen koers dreigden te varen, in te dammen en te komen tot een defensiebrede bedrijfsvoering. Daarbij werd destijds inderdaad gedacht, in het bijzonder door de CIO, dat die bedrijfsvoering kon worden afgedwongen door invoering van een ERP. Daarbij werd er, gegeven de grote invloed van de krijgsmachtdelen, voor gekozen de leiding in handen te geven van de financiële zuil vanuit de gedachte dat alles uiteindelijk terug te voeren is tot de begroting en dat langs die weg dus alles kan worden 'beheersd'. In de uitvoering van het project ontwikkelden zich twee bestuurlijke uitdagingen. Als eerste moesten de zogeheten beleidsverantwoordelijken (staffunctionarissen) voor resp. de financiële, personele en materieel-logistieke bedrijfsprocessen - ik noem ze even de 'denkers' - tot overeenstemming komen over een integraal ontwerp van ERP. Voorts moest dit ontwerp worden verkocht aan de krijgsmachtdelen; ofwel de 'doeners'. Het is niet gelukt de denkers en de doeners aan elkaar te verbinden binnen een gefaseerde aanpak. Ca. 10 jaar na de start van het project is men tot de conclusie gekomen dat de 'doeners' nu aan zet zijn, omdat het voor de 'denkers' te moeilijk is geworden; helaas inderdaad ettelijke miljoenen verder. Het laatste woord is dus nog zeker niet gezegd over dit project. Wordt vervolgd...
Bedankt voor deze toelichting! Het bevestigt heel veel van wat ik dacht en van de aannames waarop ik mijn stuk heb gebaseerd.
Mogelijk ben je niet helemaal op de hoogte van de laatste ontwikkelingen want de "doeners" waar jij het over hebt zijn de ICT-ers. Het vervolgtraject is wederom belegd bij de CIO. In de Eindrapportage wordt gesteld dat de staande organisatie nu klaar zou zijn voor verdere ontwikkeling; met de staande organisatie bedoelt met de ICT organisatie.
Ook hiervan had ik al een vermoeden. Dit vermoeden werd bevestigd in een recente "ambtelijke technische briefing " van Defensie aan een aantal leden van de Tweede Kamer.
Een paar andere punten tijdens die "ambtelijke technische briefing ":
- In 2015 zou de basis (!) op orde moeten zijn.
- Er werd ooit gestreefd naar 12.000 gebruikers; er zijn nu ongeveer 4.250 gebruikers. Defensie kon of wilde dit niet toelichten. Men stelde slechts dat de cijfers moeilijk liggen en slecht vergelijkbaar zijn door de vele reorganisaties.
- Er zijn nog altijd problemen met draagvlak.
De constatering dat de staande organisatie klaar is, is dus onzin tenzij je daarbij slechts kijkt naar de ICT ontwikkelorganisatie zoals de Eindrapportage en Defensie doen.
Ik werd al niet vrolijk van het beeld dat de Algemene RekenKamer schetste; de "ambtelijke technische briefing " schetste een nog somberder beeld (onbedoeld uiteraard).
Wordt dus inderdaad vervolgd; naar verwachting met enorme extra kosten.
http://www.computable.nl/artikel/nieuws/erp/5048348/1276992/defensie-is-nog-ontevreden-over-sap.html
en
http://www.computable.nl/artikel/achtergrond/erp/5048147/1276992/sap-levert-vooral-meer-inspanningen-op.html
Hierbij valt op dat men in bepaalde opzichten een iets meer positief beeld schetst dan de rapportage van de Algemene Rekenkamer en van de CIO aan leden van de Tweede Kamer in een overleg van afgelopen februari.
Men stelt o.a.: ‘Onze hoofdprocessen zitten nu in SAP’ terwijl Rekenkamer en CIO stelden dat de basis nog niet is voltooid (zij mijn eerdere toevoeging hierboven).
Niet alle externe leveranciers zijn in de gelegenheid met deze eindgebruikers te schakelen. Hierboven is al eerder terecht gewezen op verschillende belangen van betrokkenen.
Daarnaast denk ik, dat een (grote) externe partij, die "problem-owner" is, er anders in staat dan een problem- solver. Ik doel hiermee op de wijze van aanpak.
Ik ben er van overtuigd dat een problem-owner zijn software centraal stelt en daar oplossingen (dikwijls in een later stadium) op inricht, oftewel, het bedrijf moet zich aanpassen aan de software.
Als problem- solver is men eerder geneigd om bestaande procedures en gebruikers centraal te stellen, met andere woorden, hoe kunnen de bestaande procedures efficiënter worden ingericht.
Daarnaast is een bedrijf constant in beweging. Zeker in deze tijden. Beweging is ook verandering, en dat betekent ook dat beslissers (projectmanagers) of mensen die betrokken zijn bij een implementatie worden vervangen of weggaan, waardoor een oude visie wellicht niet meer relevant is, of tenminste aan verandering onderhevig...Dat kan alleen maar als de ontwikkelaar flexibel en onafhankelijk , buiten eigen bestaande kaders kan ontwikkelen.
Kortom , stel het bedrijf en haar gebruikers centraal...niet alleen in woorden , maar echt, in daden. Maatwerk dus.
Wat is het geval? Bij de implementatie gaat men doorgaans uit van de Kleinste Gemene Veelvoud van wensen en eisen. Waarschijnlijk verleid door het woord "kleinste". Hier mee wordt een gedrocht van een stuk software ontwikkeld dat vooral door zijn complexiteit niet meer te overzien, niet meer te beheersen en dus niet meer te managen is. En dus loopt het vaak uit de hand niettegenstaande het feit dat er best voorbeelden gegeven kunnen worden van min of meer geslaagde implementaties. Ik ken voorbeelden van bedrijven waar een SAP (maar het had ook Oracle kunnen zijn) implementatie gemaakt is waar werkelijk elk probleem van het bedrijf mee opgelost moest worden of het nou de afdeling Finance, Productie, HR of welke dan ook betrof en ook al waren er goede deeloplossingen voorhanden. Gevolg is dat niemand meer efficiënt werken kan en er een gebruikersvijandig stuk software ontstaan is.
Verantwoordelijke managers zouden moeten besluiten dat slechts de Grootste Gemene Deler van wensen en eisen geïmplementeerd mag worden en niet meer! Geheid dat er dan veel meer projecten slagen. Bijvangst is dan dat veel mensen die met dergelijke software producten moeten werken zich niet meer gegijzeld voelen door de Automatisering.
Uit studies blijkt dat het budget voor 60% opgaat aan software, 40% aan bruikbaarheid en verandermanagement. Bij acceptatie van het resultaat keert het plaatje om. De software (en bij uitbreiding alles wat technologisch is) is verantwoordelijk voor 30% van de acceptatie. Het klaarmaken van de organisatie, de opleiding, zorgen dat het systeem 'bruikbaar' is, staat in voor 70%.
ICT projecten bestaan dus niet (puur technologische projecten).
Slechts een klein aantal projecten bepalen bij de start de doelstellingen op een SMART wijze. Slechts een fractie hiervan volgen ook de realisatie van de doelstellingen op. Zowel het bepalen van de doelstellingen en het opvolgen zijn business issues en daar wringt het schoentje...