Bert Overbeek is trainer, coach en interim manager, maar tegenwoordig kan je ook zeggen: organisatiedokter en -innovator. Opgeleid door NS en Schouten en Nelissen, besloot Jongebazen-oprichter Bert Overbeek na 25 jaar loondienst om voor zichzelf te gaan werken. Hij wilde zijn klanten meer op maat bedienen, de basis van zijn werk verdiepen en de kwaliteit van zijn werk vergroten en had het gevoel dat hij daarvoor onafhankelijk moest kunnen opereren. Hij is er gelukkig van geworden. (Website met filmpje: www.pitchersupport.jimdo.com)
Prof. dr. Mastenbroek van Managementsite ‘ontdekte’ dat Overbeek meer kon dan bedrijven helpen met verbeteringen van resultaat en sfeer. Hij vroeg de schrijvende organisatieontwikkelaar of hij een weblog voor jonge managers wilde bijhouden, als partnerlink van het grote ManagementSite. Dat was tien jaar geleden. Sindsdien schreef Overbeek bijna 1500 artikelen en zes boeken. Ze werden uitgegeven door Haystack en door Futuro Uitgevers. Twee boeken werden bestsellers en eindigden in de top 10 (‘Het Flitsbrein’ en ‘Mannen en/of vrouwen’).
Overbeek vindt kosteloze kennisdeling en informatie-uitwisseling zo belangrijk, dat hij hier op jongebazen.nl nu 10 jaar de finesses van het managementvak deelt met vakbroeders en collega’s. Daarmee liep hij voor op de moderne social media trends waarin het ‘geven’ van gratis informatie een marketing tool is geworden.
Meer dan 100 000 mensen bezoeken Jongebazen per jaar. En het heeft hem veel respect opgeleverd in managementland. Alles wat te maken heeft met het verbeteren van organisaties, teams en mensen boeit hem. 21 jaar ervaring en intensieve studies helpen hem daarbij. Zijn humor leidt er toe dat mensen hem graag inhuren als spreker en inspirator, en zijn veelzijdigheid heeft hem het compliment van een topvrouw opgeleverd, dat hij altijd een eigen gezichtspunt kiest en je daardoor aan het denken zet.
Organisaties weten de weg naar hem te vinden. Hij zei daarover in een interview: ‘Het is niet altijd makkelijk om mijn werk te combineren met jongebazen, omdat je op zo’n blog wel eens inzichten los wilt maken die strijdig zijn met wat gangbaar is in mijn vak. Wat zegt hij daar nu weer?, denken opdrachtgevers dan. Maar ik kan ze gerust stellen. In mijn werk kan ik me goed op een opdracht richten.’
Bert twittert op Goeroetweets, een titel die is afgeleid van zijn boek ‘Goeroegetwitter’. Het woord ‘goeroe’ is duidelijk met een knipoog. Want hij is wars van goeroeneigingen, en prefereert laagdrempeligheid. Jongebazen heeft een eigen groep op Linkedin.
Correspondentie met Bert Overbeek via pitcher.support@hetnet.nl Zijn website is www.pitchersupport.jimdo.com
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...