In het artikel Effectieve sturing op IT-kosten gaan Ernest-Jan Mutsaers, Sjoerd Verhoeven en Iwert Veenstra (Nolan, Norton & Co.) in op de vraag hoe IT-kosten beheerst kunnen worden door een gelaagde sturing op efficiency, volume en assortiment.

Nolan, Nortan & Co. (NNC) ontwikkelde het zgn. EVO-model voor het op een gelaagde wijze sturen op IT-kosten. 'EVO' staat hierbij voor Efficiency of supply, Volume of demand, Optimised assortment. Het model is bedoeld als oplossing voor de problematiek van stijgende IT-kosten. Deze stijging is het gevolg van drie oorzaken:

1. Complexiteit IT-omgevingen: gedateerde IT-omgevingen (legacy), complexe applicatielandschap door fusies, (deels) aan elkaar gekoppelde informatiesystemen met overlappende functionaliteiten, gefragmenteerde dataopslag en beperkte interoperabiliteit.

2. Geen gemeenschappelijk begrippenkader bij business en IT: door de verschillen in begrippenkaders van business en IT ontbreekt zicht op en overeenstemming over de IT-dienstverlening, condities, bijbehorende kosten en de wijze waarop deze kosten beïnvloed kunnen worden.

3. Kostenreductie eenzijdig belegd bij IT-organisatie: bij kostenreductie en -beheersing is een te beperkte focus op de vraagzijde, zodat met besparingen aan de aanbodzijde verbleken bij de jaarlijks toenemende vraag naar IT vanuit de business.

Het EVO-model moet zorgen voor een transparante en stuurbare IT-dienstverlening om zo de IT-kosten minimaal te beheersen en zelfs in het gunstige geval te verlagen. Binnen het model is sprake van een gelaagde sturing op IT-kosten waarbij business en IT samen optrekken, maar toch ook sprake is van duidelijk gesplitste rollen en verantwoordelijkheden 'om daadwerkelijke beïnvloeding van IT-kosten mogelijk te maken'.

Het model richt zich op 3 lagen in de sturing van de kosten:

1. Efficiency of supply: sturing op 'kosten per eenheid'.

2. Volume of demand: sturing op 'volume van de vraag'

3. Optimised assortment: sturing op 'assortiment en complexiteit'.

De belangrijkste aandachtsgebieden bij het effectief sturen op IT-kosten zijn:

1. Definiëren van heldere IT-producten en -diensten: IT stelt in overleg met de business en product- en dienstencatalogus (PDC) op, zodat de business kan bepalen welke producten, diensten en eventuele varianten in serviceniveaus zij - en in welke hoeveelheden - wil afnemen.

2. Heldere tarifering van IT-producten en -diensten: het vaststellen en het bereiken van vereenstemming over de tarifering per product/dienst en de wijze van doorbelasting.

3. Realiseren van transparantie in afname van IT-producten en -diensten: noodzakelijk om op basis van de gedefinieerde PDC en bijbehorende tarifering ook daadwerkelijk te kunnen doorbelasten.

4. Realiseren van effectieve sturing op IT-kosten: sturen op kostenbeheersing voor elk van de drie onderkende niveaus.

De sturing op IT-kosten richt zich dus op de drie categorieëen van het EVO-model: (a) bij de sturing op kosten per eenheid (als primaire verantwoordelijkheid van IT-supply) gaat het erom dat lage(re) kosten per eenheid te realiseren, (b) bij het sturen op volume van de vraag gaat het erom dat de business stuurt op (beperking van) de vraag naar IT-diensten, waarvoor inzicht nodig is in de belangrijkste veroorzakers van kosten (IT-costdrivers), bij (c) gaat het om te sturen op assortiment en complexiteit(sreductie).

De verantwoordelijkheid voor het reduceren van de complexiteit van het IT-landschap moet belegd worden op corporate-niveau. Het raakt namelijk meer dan één organisatieonderdeel en vraagt vaak om het beslechten van de spanning tussen korte en langere termijn organisatiedoelen.

Bron: Effectieve sturing op IT-kosten (Nolan, Norton & Co.), juni 2009

Peter Hinssen - zelfverklaard S-curve-fetisjist - stelt dat we halverwege de digitale revolutie. In zijn boek Digitaal is het nieuwe normaal gaat Hinssen op zoek naar wat er gebeurt als we het omslagpunt ('halfwegpunt') voorbij zijn/gaan.

"Het idee achter het Nieuwe Normaal is heel eenvoudig: 'we zijn halverwege'. Het Nieuwe Normaal gaat over alles wat we 'digitaal' noemen en over het feit dat 'digitaal' steeds meer 'normaal' gaat worden. Dit betekent dat we nog evenveel weg moeten afleggen als er achter ons ligt."

Peter Hinssen onderzoekt de wereld van het 'digitale' ná het halfwegpunt; de impact van het Nieuwe Normaal. "Het glas is halfvol, en dit zal onze visie op technologie drastisch veranderen. De volgende tien, twintig, dertig jaar zullen gekenmerkt worden door een wereld die steeds meer digitaal wordt, en die ons gedrag en de manier waarop we technologie omarmen, drastisch zal veranderen. De impact op bedrijven en de manier waarop we technologie gebruiken, zal enorm zijn."

Op Youtube vind je onderstaande serie van negen interviews waarin Peter Hinssen - per hoofdstuk - uitlegt waar zijn boek over gaat. Volgens Hinssen zélf is de moraal van zijn verhaal: "If technology stops being technology but just becomes normality, we have to treat it as normal in our organizations as well. That basically means, don't leave technology to the technologist, but think about technology innovation as a mindset for the entire organization."

• 01 Introducing the new normal
• 02 Exploring the limits
• 03 Rules of the new normal
• 04 Customer strategies for the new normal
• 05 Information strategies for the new normal
• 06 Describing organizations in the new normal
• 07 Innovation in the new normal
• 08 Technology strategy for the new normal
• 09 The big picture

Bron: Digitaal is het nieuwe normaal, Peter Hinssen

Scope creep is het verschijnsel waarbij - bij het ontwikkelen van software - de omvang van het het te ontwikkelen systeem ongemerkt of ongecontroleerd steeds verder toeneemt. Problematisch omdat "[e]en toename van de scope direct negatieve invloed (heeft) op het budget en/of de doorlooptijd. Dit is een van de redenen dat zoveel ICT-projecten uitlopen en meer kosten dan gepland."

Nicole de Swart - auteur van het Handboek requirements, Brug tussen business en ICT - onderscheidt in haar artikel Nooit meer scope creep drie manieren om scope creep te voorkomen:

1. Geen wijzigingen toestaan: projectmanagement-technisch verleidelijk om het projectresultaat binnen tijd en budget op te leveren, dankzij een plan van aanpak en planning die gebaseerd is op de vooraf goedgekeurde requirements. Kwalitatief gezien minder, wanneer dit betekent dat opdrachtgever en andere belanghebbenden een systeem krijgen dat niet aan hun behoeften voldoet.

2. Een goed wijzigingsbeheerproces: een wijzigingsbeheerproces kan worden ingezet als hulpmiddel om rekening te houden met wijzigingen en tóch grip te houden op het project: "wijzigingen in de requirements en de financiële en planningstechnische consequenties daarvan, [kunnen] weloverwogen doorgevoerd worden. Ieder wijzigingsverzoek wordt dan geregistreerd, geanalyseerd en toe- of afgewezen. Bovendien moet iedere goedgekeurde wijziging doorgevoerd worden in de software en in de documentatie." Nadeel is alleen dat wijzigingen veel tijd en geld kosten en dit de belanghebbenden remt om te komen met verbeteringen en/of wijzigingen.

3. De scope geleidelijk laten ontstaan: op voorhand géén (gedetailleerde) scope vaststellen, maar "business de mogelijkheid geven om just in time te bepalen welke requirements ze de komende twee (of vier) weken willen laten implementeren". Voorwaarde hierbij is dat softwareontwikkeling iteratief en incrementeel plaatsvindt, waarbij de requirements en het systeem geleidelijk groeien tot het gewenste gewenste eindresultaat. "Als je een project niet begint met een goedgekeurde set aan requirements dan kunnen ze ook niet wijzigen of toenemen."

Volgens De Swart is het onvermijdelijk dat requirements wijzigen tijdens de looptijd van het project. Ze baseert zich hierbij op onderzoek van C. Jones die heeft aangetoond dat de requirements bij een eenjarig project gemiddeld met 27% toenemen. Bij een project van anderhalf jaar is dat al 43% en bij een tweejarig project maar liefst 63%.

Als belangrijkste oorzaken van veranderende requirements noemt De Swart voortschrijdend inzicht, wijzigende behoeften van de business en onvolledig of onjuist geëliciteerde requirements: "We hebben de afgelopen decennia ervaren dat het vrijwel onmogelijk is om de requirements en de scope van het te ontwikkelen systeem op voorhand vast te stellen."

De Swart bepleit voor een 'fundamenteel andere werkwijze' waarbij: "De business zelf het stuur in handen (krijgt) en iedere iteratie op basis van de opgeleverde software (kan) besluiten of het systeem verder uitgebreid moet worden en of ze daar nog geld aan uit willen geven. Op deze manier vervalt de noodzaak om op voorhand afspraken te maken over fixed date, fixed cost en fixed scope. Het IT-project biedt de business de flexibiliteit om gaandeweg te ontdekken waaraan ze het meeste behoeften hebben."

Bron: Nooit meer scope creep, Nicole de Swart

Volgens Norbert Vincent, Business Informatie Manager bij PON Automobiel handel, vervult een Business Informatiemanager (BIM) zes rollen:

1. Informatiestrateeg

2. Informatiemanager (opstellen business informatieplan)

3. Programmamanager

4. Relatiemanager

5. Intermediair

6. Sourcing manager

Beheers je deze rollen, dan worden nog drie aanvullende eisen gesteld aan de informatiemanager als persoon:

1. Leiderschap (inspireren, perspectief bieden, realisme)

2. Executiekracht (commitment verkrijgen, organiseren, afmaken: 'afmaken begint bij de start')

3. Bruggenbouwer (lobby'en, win/win + dillemma's slechten, vertalen)

Bron: Presentatie "Rol en toegevoegde waarde informatiemanager", Norbert Vincent; Focus on Demand 2011, 08-12-2011

In het artikel “Informatiemanager? ICT or business?” betoogt Rik Maes dat informatiemanagers zich niet moeten opstellen als ict-managers en intermediair tussen business en ICT, maar op zoek moeten gaan naar een nieuwe identiteit. Volgens Maes gaat informatiemanagement in ieder geval niet over het managen van ICT, noch over het managen van het ‘alignment’ van business en ICT.

“Informatiemanagers zouden moeten ophouden te werken als vermomde ICT-managers. Evenmin zouden ze zich nog moeten definieren als intermediairs tussen business en ICT. Succesvolle informatiemanagers zijn ‘infopreneurs’, hypergevoelig voor het onthullende karakter van menselijke activiteiten, een bijdrage leverend aan het herinterpreteren van hun organisatie en van de maatschappij als geheel en dit alles belichamend in hun professionele en persoonlijke leven.”

Bij de term ‘informatiemanagement’ wordt vaak de link gelegd met computers. Niet verwonderlijk volgens Maes: “Geen wonder: gedurende decennia werd de betekenis van informatie en informatiemanagement voor organisaties in feite verborgen achter de overweldigende opkomst van informatie- en communicatietechnologie (ICT). Deze laatste werd beschouwd als een strategische ‘resource’, die een directe en beslissende impact had op de business.”

“Op de keper beschouwd heeft ICT geen andere al of niet strategische impact dan via het faciliteren van informatie- en communicatieprocessen. (…) CEO en CIO zouden zich primair moeten inlaten met ICT-onafhankelijke conversaties over de informatie- en communicatieprocessen …, in plaats van quasi-automatisch terug te vallen op ‘techno talk’…”

Het risico van het positioneren van informatiemanagement al seen intermediare functie tussen business en ict, is dat dit volgens Maes vaak resulteert in “‘stuck in the middle’: missionarissen die aan de businesskant tegen dovemansoren praten, halfbakken overlopers voor de ICT-kant en voor henzelf vredesstrijdkrachten zonder een duidelijke identiteit en missie.”

Wanneer de business de informatie-/communicatieverantwoordelijkheden delegeert richting de ict dreigt informatie te worden gereduceerd tot “feiten die beheerd worden in databases en haar kwaliteit wordt gemeten aan de hand van de kwaliteit van deze databases en andere technische artefacten, in plaats van aan de hand van haar bijdrage aan de business. ICT’ers zijn slechte informatiemanagers, als ze blijven redeneren vanuit hun technische wereld!”

Maes is van mening dat informatiemanagement gepositioneerd moet worden aan de linkerkant van de business-ICT-as: "Op deze manier wordt informatie in essentie gezien als een bedrijfsmiddel en kan de relatie met ICT een contractuele zijn: ICT heeft een ondersteunende functie en moet als dusdanig gemanaged worden; outsourcing is hier een logisch uitvloeisel van. Bovendien komt hierdoor beter tot uiting dat informatiemanagement een gedeelde algemene businessverantwoordelijkheid is: separaat, in de vorm van een aparte functie, is informatiemanagement enkel accommoderend en stimulerend, maar nooit leidend.”

“Organisatorische informatie gaat niet over feiten, maar over de interpretatie van feiten. Daarom is informatiemanagement in essentie de constructie van betekenis voor de organisatie. Daarnaast draagt het bij aan de betekenis van de organisatie voor haar omgeving; informatiemanagement gaat over de identiteit van de organisatie. Informatiemanagers zouden moeten ophouden te werken als vermomde ICT-managers. Evenmin zouden ze zich nog moeten definiëren als intermediairs tussen business en ICT. Informatiemanagers zijn bouwers van betekenis voor hun organisatie; hun ultieme taak is bij te dragen aan de identiteit van hun organisatie. (...) [I]nformatie-’governance’ [is] belangrijker voor hun slagen dan ICT-’governance’, beter informatiegebruik belangrijker dan steeds maar ingewikkelder informatieproductie en het begrijpen van organisatorische dubbelzinnigheid belangrijker dan het vatten van technische complexiteit. Uiteindelijk zijn hun attitude en hun gedrag van vitaler belang dan hun kennis: succesvolle informatiemanagers zijn ‘infopreneurs’, hypergevoelig voor het onthullende karakter van menselijke activiteiten, een bijdrage leverend aan het herinterpreteren van hun organisatie en van de maatschappij als geheel en dit alles belichamend in hun professionele en persoonlijke leven. Welke moderne organisatie kan aan een dergelijke informatiemanager voorbijgaan?”

Bron: Informatiemanager? ICT or business (mei 2011), Rik Maes

De beer(put) is weer los! De Volkskrant (26/11/2011) beschrijft in het artikel "Weer duur iict-fiasco bij overheid" het ict-debacle bij de automatisering van de waterschappen. Het Waterschapshuis, de koepel van 26 waterschappen, verstrekt begin 2007 een opdracht aan Logica voor het ontwikkelen van een geautomatiseerd systeem voor de inning van de waterschapsbelasting. Per 1 januari 2009 had het systeem er moeten zijn, maar - omdat het automatiseringsproject op een mislukking is uitgelopen ('project verloopt niet zoals gewenst', 'levering product blijft uit' en 'onvoldoende zich op kostenontwikkeling') - hebben alle 26 waterschappen de samenwerking met Logica ('een geldbeluste leverancier') beëindigd. "De waterschappen moeten hierdoor rekening houden met een schadepost van 25 miljoen euro."

Voor een volledige reconstructie verwijs ik naar het artikel, maar hierbij - ter leering ende vermaeck - de 'hoogtepunten':

"[D]e voorzitter en de directeur van het Waterschapshuis [doen] in juni 2009 hun beklag (...) bij Andy Green, bestuursvoorzitter van Logica International: als er op 1 september geen werkend belastingsysteem  zou zijn, 'ploft de hele zaak'. Nog in hetzelfde gesprek weet Green 1 januari 2010 aanvaardt te krijgen. De bestuursvoorzitter noemt het de 'Golden Date'. Eind november 2009 is duidelijk dat de Golden Date zacht is als pudding. Er wordt een glijdende oplevering afgesproken tot juni 2010. Ook in juni 2010 is er geen werkend systeem."

"Een ict'er die Logica en het waterschapsproject van nabij kent, zegt: 'Iedereen kon zien: dit gaat niet werken. Te veel belangen, te veel vereisten en daardoor een te complex project voor de leverancier, voor Logica. Overspecificatie heet dat in ons vak. Het is schering en inslag. 'Er ontstaat dan een context die voor alle partijen almaar ingewikkelder wordt. En telkens zegt men: laten we het opnieuw proberen. Dat is trouwens volop in het financiële belang van Logica. En als men er uiteindelijk toch niet uitkomt, ja, dan worden die waterschappers door het hoofdkantoor in Londen natuurlijk drie keer in het pak genaaid. Niemand durft te zeggen: laten we stoppen. Want als je dat zegt, zeg je dat er fouten zijn gemaakt. En wie neemt daarvoor tegenwoordig nog de verantwoordelijkheid?'

"[De VVD'er Mark Strolenberg (bestuurslid van Reest & Wieden, een groot waterschap uit de provincies Drenthe en Overijssel)] deelt de kritiek van de ict'er op de opdrachtgever: 'Het waterschapshuis heeft er te veel toeters en bellen aan gehangen. Als de opdracht goed was geformuleerd en in kleine stapjes was uitgevoerd, had het niet zover hoeven komen.' Strolenberg deelt ook de opvatting dat iedereen wegduikt voor de verantwoordelijkheid voor het echec, inclusief zijn eigen Waterschapshuis. Hij vertelt dat hij indirect vanuit het Waterschapshuis te horen heeft gekregen dat hij zijn mond moet houden. Strolenberg: 'Stel je voor. Men is jaren bezig geweest met een project. Dan gaat de stekker eruit. Het is een product dat nooit zal werken. De zaak kan in de afvalbak. Er is niks meer mee te doen. We staan weer bij nul. En dan moet je je mond houden als volksvertegenwoordiger in het waterschap. Ik mag gaan vertellen dat de lasten omhoog gaan, omdat we miljoenen hebben verspeeld, dat wel. Maar een openbare discussie over hoe het zover is kunnen komen, mag niet. Dat is toch niet uit te leggen aan burgers?'"

Het Waterschapshuis laat 'het Logica-dossier geïsoleerd [behandelen] door een bestuurlijke commissie die een onderhandelteam, aangevuld met een advocaat aanstuurt. (...) In kringen van de waterschappen valt de naam van Pieter Cloo, partner bij het adviesbureau Boer & Croon, als een van de onderhandelaars. Dat zou opmerkelijk zijn, omdat Cloo als lid van de raad van bestuur van uitkeringsinstantie UWV medeverantwoordelijk was voor de opzet van een ict-systeem voor de Wia, de opvolger van de WAO. Vanwege technische en financiële onbeheersbaarheid moest het project in juni 2008 worden stopgezet. De mislukking kostte 87 miljoen euro. De ontwikkelaar was Logica."

Zie ook: Ict-drama‘s bij de overheid: problemen in plaats van oplossingen en Faalindustrie vol IT-fiasco's volgens René Veldwijk

Bron: "Weer duur ict-fiasco bij overheid", Volkskrant 26 november 2011 en Vk.nl: "Opnieuw duur ict-fiasco: automatisering waterschappen mislukt"

In de Volkskrant (29/10/2011) opnieuw aandacht voor slecht opdrachtgeverschap bij de overheid. Dit keer onder de titel "Ict-drama bij UWV". Als ex-medewerker van UWV had dit vanzelfsprekend mijn directe aandacht. Wat me persoonlijk fascineert is de surrealistische tunnelvisie waarmee bij de overheid - in dit geval UWV - door slecht opdrachtgeverschap erin slaagt, projecten bij voorbaat te laten mislukken. Het artikel geeft aan hoe bij het project Polisadministratie uitliep op een drama, ondanks het feit dat alle lichten op rood stonden. Voor de (smeuïge) details rond het project verwijs ik naar het artikel, maar ik doe een poging de ‘algemene lijn eruit te halen. Wanneer je jezelf laat afschepen met een fiets, terwijl je een Bentley hebt besteld, gaat er namelijk onderweg ergens wel iets mis....

CDA-Kamerlid Ger Koopmans, is voorstander van een diepgaand parlementair onderzoek waarin "(h)et (ook) moet gaan over de vraag waarom automatiseringsprojecten bij de overheid almaar in de modder blijven steken: de gemoderniseerde bevolkingsadministratie, het electronische patiëntendossier, het communicatiesysteem C2000 van politie, ambulance en brandweer - allemaal projecten die twee dingen gemeen hebben: elke keer moet nog één keer en wel voor de laatste keer extra geld op tafel komen. En uiteindelijk scheppen die ict-projecten vooral problemen in plaats van oplossingen."

Volgens een schatting van de Algemene Rekenkamer eind 2007 verliest de Nederlandse overheid jaarlijks vier tot vijf miljard aan geheel of gedeeltelijk mislukte ict-projecten. Voor de Polisadministratie gold: "Tegen de tijd dat de zaak was vastgelopen en al het ontkennen niet meer hielp - dat was in de eerste helft van 2007 - waren we 256 miljoen verder."

"Het diepste punt in de relatie tussen Capgemini (de leverancier van de Polisadministratie, BS) en UWV werd bereikt eind 2006. Het management van Capgemini stuurde een officiële brief aan de leiding van UWV. Strekking: dat nieuwe ict-systeem waar we in uw opdracht nu al tweëenhalf jaar aan knutselen en knoeien wordt helemaal niks. De opzet van de database zal nooit kunnen werken. Vergeet het alsjeblieft. Stop met die handel. De leiding van UWV wendde een bloedende neus voor. Er was één gesprek en daarna verdween de brief. Laatjes genoeg. Het project moest doorgaan. Iemand die van de hoed en de rand weet, zegt: "Ik geloof dat het voor de hele overheid geldt, in elk geval geldt het voor UWV: men kent geen weg terug. Wat eenmaal in gang is gezet, moet worden afgemaakt, ongeacht duur en prijs. De managers zagen het spaak lopen, maar letterlijk zei men: "Er is geen alternatief"."

Een ingewijde van UWV verteld: "We hadden een Bentley besteld ... We kregen een fiets. Iedere maand werden de functionaliteiten van het nieuwe systeem bijgesteld. Naar beneden. Je moet erbij zeggen de politiek schroefde de verwachtingen veel te hoog op. Het systeem moest alles kunnen. Ja, dan kan niet." Volgens andere insiders: "Zelfs een beginneling in het ict-vak kon zien dat het nieuwe administratiesysteem nooit zou gaan werken. (...) Iedereen wist het: we halen het nooit een functionerend systeem in 2006. Niemand mocht het zeggen. Als je het wel zei, wist je één ding: m'n kop gaat eraf."

"Het eigenaardige is: het wérd gezegd, de kritische stukken waren er en er was verontrusting bij de ontvangers, zij het van de obligate soort. En voor de rest was er vooral de stilte van het graf. Kennelijk kwam het alle betrokken partijen uit zich van de domme te houden, ook de politiek. Door de jaren heen zijn er rapportages en bevindingen opgesteld, steevast in ambtelijke dieventaal, maar daardoor des te vernietigender." Met kwalificaties als "Het is onwaarschijnlijk dat de gerealiseerde kwaliteit van het polisadministratiesysteemcomplex voldoet aan de acceptatiecriteria." hoeft je niet heel erg into ICT te zijn om je zorgen te gaan maken.

Over de vraag hoe het project van de Polisadministratie zo uit de hand kon lopen, zijn er twee lezingen. "De eerste lezing luidt: het is Capgemini dat er een bende van heeft gemaakt. Gewezen wordt op de India connection. Dat is een ander woord voor goedkoop=duurkoop. Onder andere Capgemini doet zaken met 'lagelonenlanden waar je zelf nooit zaken zou doen'' - aldus Chris Verhoef, hoogleraar informatica aan de Vrije Universiteit van Amsterdam. 'De praktijk wijst uit dat keer op keer die partijen de klussen binnenhalen die aanbieden tegen afbraakprijzen. De overheid is op weg naar verbetering van de IT-functie. Zonder gedegen vaklieden die de software ook echt kunnen maken, wordt het echter nooit wat.' Volgens deze lezing schreef Capgemini de opmerkelijke brief om zich juridisch in te dekken. Zo van: wij hebben erop gewezen dat een echec voor de deur staat, kom ons straks niet aan de kop zeuren met een schadeclaim."

"Volgens een andere verklaring kwam de brief voort uit min of meer oprechte bezorgdheid over het naderende total loss. UWV wordt door menigeen beschouwd als een fusie van zes bedrijfsverenigingen die niet uit verliefdheid in elkaar zijn opgegaan. De permanente stammenstrijd die hiervan het gevolg is, maakt dat een bedrijfssucces niet veel meer is dan een toevalstreffer. Hoe het ook zij, eind 2006 stond voor de insiders vast dat de opgebouwde polisadministratie volkomen onbruikbaar was."

Ik zou zelf zeggen - en dat durf ik omdat ik tot mei 2006 werkzaam was voor UWV - een combinatie van factoren. Het is té goedkoop om Capgemini de schuld te geven; je krijgt de leverancier die je verdient! Hoe naïief kun je zijn. Een parlementaire onderzoek lijkt mij wat overdreven (of het zou moeten zijn om met terugwerkende kracht een soort bijltjesdag te faciliteren). De oorzaken van het mislukken, zijn volgens mij te veel een open deur om er nog meer overheidsgeld tegenaan te gooien. Voor een dubbeltje zit je met complexe ict-systemen écht niet op de eerste rang. Dat de beloofde leverancier-technische de hoog-gekwalificeerde medewerkers al snel worden vervangen door - voor de leverancier althans - goedkopere krachten is een bekend mechanisme. Dat je als je dan toch gehinderd wordt door een tunnelvisie kritische geluiden niet wilt/kunt horen, lijkt me ook logisch. Combineer dit met een te hoog ambitieniveau, de interne 'fusie-perikelen', de externe samenwerking met de Belastingdienst. Verder blijft descoping natuurlijk de barba-truc om het mislukken van een ict-project te verdoezelen. Ook al blijft het verschil tussen een fiets en een Bentley tóch - letterlijk - opmerkelijk.

Zie ook: Faalindustrie vol IT-fiasco's volgens René Veldwijk

Bron: Volkskrant 29/10/2011, Ict-drama bij UWV, Jan Tromp

Jan Willem Knop schrijft in het artikel Requirements zijn de Big Hitter……voor succesvolle projecten! op XR Magazine dat de IT-wereld een slechte track record heeft als het gaat om het succesvol afronden van IT-projecten. Een goed ingericht requirements proces is volgens hem dé sleutel tot een geslaagd IT-project. Voor de goede orde, een project slaagt volgens Knop als het opgeleverde eindresultaat voldoet aan de (business) doelstellingen: op tijd en tegen gebudgetteerde kosten op te leveren.

Zich baserend op promotieonderzoek van Aart J. van Dijk (Succes and Failure Factors in ICT projects: A Dutch Perspective) beschrijft Jan Willem Knop zeven factoren die bepalend zijn voor de succesvolle afloop van een IT-project:

1. Goed projectmanagement

2. Realistische deadlines

3. Goede communicatie

4. Sterk en compleet requirements document

5. Voldoende betrokkenheid van toekomstige gebruikers

6. Betrokkenheid en commitment van senior management

7. Voldoende professionaliteit (professionals)

Wanneer je aandacht besteedt aan alle zeven factoren, is de kans groot een project succesvol af te ronden. Het verwaarlozen van één van de factoren, geeft een garantie op mislukking.

Requirements worden niet alleen expliciet genoemd, maar leveren ook een bijdrage aan goede communicatie: ‘Als ze zodanig beschreven zijn dat ze door alle belanghebbenden eenduidig geïnterpreteerd worden, verbetert dit de onderlinge communicatie over de requirements.’

Requirements engineering is het proces om tot requirements te komen. Volgens Jan Willem Knop zijn er vijf aandachtspunten die van belang zijn voor het succesvol toepassen van requirements engineering:

1. Organiseer je proces

2. Betrek de business

3. Wees pragmatisch

4. Start met het probleem

5. Leg requirements vast

Het artikel dat verscheen in XR Magazine is gebaseerd op het boek ‘Precies volgens Plan!’ geschreven door Mark Hoogveld, Jan Willem Knop en Marcel Schaar.

Bron: Requirements zijn de Big Hitter……voor succesvolle projecten!, Jan Willem Knop, 19 oktober 2011

Het Handboek Architectuur van gemeente Amsterdam uit 2007 is een zeer leesbaar en begrijpelijk architectuurdocument. Een van de modellen die gebruikt wordt is een vijflagenmodel voor het beschrijven van de onderkende vijf architecturen:

1. Organisatiearchitectuur: beschrijft het 'wie'en 'wat'; onderkende organisatieonderdelen, onderlinge verhoudingen, relaties met buitenwereld, producten en/of diensten die worden geleverd aan klanten, organisaties en elkaar (front-, mid- en back-office).

2. Procesarchitectuur: processen waarmee de in de organisatiearchitectuur onderscheiden producten en diensten worden voortgebracht ('waar en wanneer').

3. Informatiearchitectuur: inrichting van de informatiehuishouding. Bij het uitvoeren van processen is informatie nodig over de klant, de zaak en het product of dienst, deze 'informatie' omvat meer dan alleen dat wat geautomatiseerd is! Het gaat om de informatie zélf en de betekenis ervan (het 'wat') en de uitwisseling van informatieberichten (het 'waar en wanneer').

4. Applicatiearchitectuur: 'applicaties' worden gedefinieerd als de functionele aspecten van de informatiehuishouding (het 'welke applicatie doet wat'), het gaat hierbij altijd om een combinatie van functionaliteit en database(s). Een belangrijke ontwikkeling is dat waar applicaties vroeger één gesloten brok software was voor één proces, nu steeds meer sprake is van kleine, samenwerkende softwarecomponenten die elkaar zogenaamde services bieden.

5. Infrastructuur-architectuur: samenstel van machines, opslagvoorzieningen, netwerkcomponenten en generieke applicaties die gebruikt worden voor het uitwisselen van informatie tussen applicaties.

De samenhang tussen de eerste twee lagen bestaat eruit dat daar waar het op organisatieniveau gaat om de vraag wát je wil leveren en op welke manier dat geregeld wordt, op procesniveau de vraag centraal staat hoe je deze productie en/of dienstverlening kunt inrichten. Vervolgens is het nodig de bovenste twee lagen in lijn te brengen met de drie lagen daaronder: een verbinding te maken met de vereisten die de doelen op organisatie- en procesniveau stellen aan de informatievoorziening en de techniek van de ICT.

Een architectuur geeft op hoofdlijnen weer hoe de de verschillende componenten en initiatieven op alle vijf lagen in elkaar grijpen en beschrijft op samenhangende wijze de gewenste situatie. De architectuur vormt een bestemmingsplan voor toekomstige organisatie en informatievoorziening. Concreet betekent dit dat de architectuur bestaat uit drie onderdelen:

1. Grondslagen: het richtinggevende en kaderstellende uitspraken.

2. Modellen: beschrijvende platen

3. Standaarden: concrete afspraken

Bron: Handboek Architectuur, De samenhang in de organisatie en de informatievoorziening van de gemeente Amsterdam

Wilbert Teunissen en Henry Coumans (beiden werkzaam bij Sogeti) beschrijven in het artikel Implementeren van Functioneel Beheer is meer dan een procesmodel, compact en helder, de essentie van functioneel beheer. Hun insteek is niet alleen een theoretische basis te geven, maar ook een pragmatische aanpak te presenteren voor het inrichten en professionaliseren van functioneel beheer.

Binnen de business speelt de informatievoorziening (lees: de ondersteuning van bedrijfsprocessen door informatiesystemen) een steeds belangrijker rol. Om de kwaliteit en continuïteit van de informatievoorziening te borgen, heeft functioneel beheer dan ook als belangrijkste taak ervoor te zorgen dat een informatiesysteem functioneel blijft voldoen aan de eisen van de business. Hiertoe vervult functioneel beheer de volgende taken:

1. Afstemmen met de eigenaar welke functionaliteiten op welk moment tegen welke kosten moeten worden 'ingekocht'.

2. Ondersteunen van gebruikers van de functionaliteiten tijdens de dagelijkse 'operatie' in geval van verstoringen en vragen.

3. Begeleiden van wijzigingen, zowel correcties als vernieuwingen, vanaf het opkomen van de wens of noodzaak, via de financiering en de realisatie, tot en met de implementatie.

4. Evalueren van het gebruik van functionaliteiten met eigenaar en gebruikers (inventariseren of wijzigingen noodzakelijk zijn).

Functioneel beheer is dé intermediair tussen business en IT en heeft vanuit de business contact met zowel de eigenaar als de gebruikers van de bedrijfsprocessen en applicaties. Richting de ICT-leveranciers moet functioneel beheer borgen dat de IT-dienstverlening geleverd wordt conform  verwachting en gemaakte afspraken. Functioneel beheer heeft dus te maken met drie partijen: eigenaar, gebruikers en ICT-leverancier(s).

Functioneel beheer als intermediair tussen eigenaar, gebruikers en ICT-leverancier(s) is actief binnen drie aandachtsgebieden:

1. Het 'spel met de eigenaar: formeel fungeert voor functioneel beheer de eigenaar als opdrachtgever; de proceseigenaar is verantwoordelijk voor het leveren van de producten en/of diensten die een proces levert en is degene die vanuit deze verantwoordelijkheid beslist over de aard van de bijdrage van functioneel beheer. Functioneel beheer vertaalt de bedrijfsdoelstellingen en -processen naar de gewenste optimale ondersteuning in de vorm van geleverde functionaliteit. Vaststelling van deze ondersteuning vindt plaats in de vorm van zgn. requirements. In samenspraak met de eigenaar worden de requirements inhoudelijk afgestemd, worden keuzes gemaakt en worden requirements voorzien van een prioriteit. De eigenaar kan beslissingsbevoegdheden ook delegeren aan functioneel beheer. Dit geldt ook voor de verantwoordelijkheden voor het accepteren van wijzigingen.

2. Contact met de gebruikers: functioneel beheer ondersteunt gebruikers op twee manieren; direct bij hun dagelijkse werkzaamheden in de vorm van het bieden van ondersteuning op de werkvloer en indirect door het beheren van de functionaliteit, waarbij gesignaleerde nieuwe en/of veranderde informatiebehoeften worden vertaald naar functionele wijzigingen en opgeleverde wijzigingen worden geaccepteerd en geïmplementeerd.

3. Sturing op ICT: functioneel beheer moet op efficiënte en effectieve wijze - met behulp van heldere en formele afspraken - de levering van de ICT-dienstverlening sturen om een stabiele levering van functionaliteit te borgen (incl. behoud van flexibliteit).

Vanuit haar intermediairpositie moet functioneel beheer een brug slaan tussen de business en ICT. Teunissen en Coumans stellen dat voor het goed vervullen van deze rol, kennis van de bedrijfsprocessen onontbeerlijk is. Deze kennis is nodig om aan te geven welke functionaliteiten gewenst of noodzakelijke zijn.

'Functionaliteitenbeheer'
Een belangrijke taak van functioneel beheer is het signaleren, initiëren van de behoefte aan nieuwe en/of gewijzigde informatievoorziening. De gesignaleerde veranderbehoefte wordt vervolgens door functioneel in meer detail vastgelegd. 'Dat kan zover gaan dat functioneel beheer het functioneel ontwerp maakt. In ieder geval zal functioneel beheer het ontwerp toetsen aan de specificaties die zij zelf heeft vastgesteld. Zoals bij het spel met de eigenaar al is aangegeven, is de situatie denkbaar waarbij functioneel beheer de prioriteiten vaststelt en de acceptatie doet van de opgeleverde wijziging. Bij de acceptatie kan zij zich laten ondersteunen door de gebruikers door hen te laten deelnemen aan gebruikersacceptatietesten. Het gehele traject van specificaties, prioritering, ontwerp, acceptatie, implementatie en opleiding valt binnen een gestructureerd wijzigingsproces, waarbij functioneel beheer naast een bijdrage aan de uitvoering ook de coördinatie voor zijn rekening neemt. Bij de uitvoerende taken moet ook gedacht worden aan het onderhoud van de documentatie, procedures en werkinstructies.'

Kerngebruikers (key users)
'In het geval het aantal gebruikers te groot is om een ieder voldoende aandacht te geven of indien sprake is van een gedecentraliseerde organisatievorm, worden kerngebruikers geïnstalleerd om zo te komen tot kanalisering van signalen. Deze kerngebruikers zijn in dat geval de aanspreekpunten op de werkvloer (zowel voor de gebruikers als de functioneel beheerders) en zorgen zelf voor overdacht richting de gebruikers.'

Rol in projecten
Veranderingen worden vaak in projectvorm gerealiseerd. Functioneel beheer zal in dat geval de rol in projecten moeten pakken/krijgen die haar in staat stelt de eisen en wensen van de gebruikersorganisatie weer in lijn te brengen met de geleverde ICT-diensten. 'Vanuit deze rol zal functioneel beheer ervoor moeten zorgen dat de veranderingen ook hun weerslag hebben op functioneel beheer zelf. Zo zal in een vroeg stadium de impact op het spel met de eigenaar, het contact met de gebruikers en de sturing op IT moeten worden vastgesteld om vervolgens te worden opgenomen in het projectresultaat. Bij de toetsing van het door het project opgeleverde projectresultaat zal zij gebruik maken van acceptatiecriteria.'

Teunissen en Coumans noemen 13 kritische succesfactoren voor een goed functionerende functioneel beheerder:

• Kennis van bedrijfsprocessen
• Inzicht in functioneel ontwerpen
• Kennis van testen en implementatie
• Kennis van service managementprocessen
• Didactisch vaardig
• Communicatief en initiatiefrijk
• Teamplayer
• Coördinerend en delegerend
• Service- en klantgericht
• Pragmatische instelling
• Stressbestending
• Sociaal
• Flexibel

Volgens Teunissen en Coumans vormen de bovengenoemde drie aandachtsgebieden de basis voor de een aanpak tot professionalisering. In aanvulling hierop formuleren Teunissen en Coumans vier doestellingen voor het professionaliseren van functioneel beheer:

1. Verklein de afstand met de business: functioneel beheer weet wat de gebruikers dagelijks doen en wat de behoeften zijn van de business (eigenaar en gebruikers). Praktische zaken hierbij zijn een centrale mailbox voor functioneel beheer, een procedure voor het aanmelden van wijzigingsvoorstellen, gebruikersoverleg en een overzicht van de kerngebruikers.

2. Structureer de werkzaamheden: werkzaamheden van functioneel beheer zijn gestructureerd, zoals bijvoorbeeld via werkinstructies voor het afhandelen van wijzigingsverzoeken en een functioneel beheerdossier per informatiesysteem.

3. Optimaliseer de sturing op IT: sturing op de IT-leverancier wordt gekenmerkt door vastgelegd afspraken (service level agreements), voortgangsbesprekingen, vaste aanspreekpunten en procedures.

4. Toespitsing van de projectrol: functioneel beheer moet vanaf de start van een project betrokken zijn en levert acceptatiecriteria als input voor het project.

Teunissen en Coumans stellen ook dat er twee randvoorwaarden zijn om professionalisering écht goed van de grond te krijgen:

1. Draagvlak en communicatie: functioneel beheer moet expliciet in de organisatie onderkend en erkend worden; hiervoor is zowel commitment als communicatie nodig van business én ICT, over de functie, positie en verantwoordelijkheden van functioneel beheer.

2. Ruimte scheppen: functioneel beheerders moeten ruimte krijgen om hun eigenlijke functioneel beheertaken uit te voeren.

Samenvattend: uitgaande van de theoretische basis presenteren Teunissen en Coumans een pragmatisch professionaliseringstraject, die - aldus de auteurs - allesbehalve 'rocket science' is:

Zie ook:

• Functioneel beheer volgens Wilbert Teunissen (2)
• Functioneel beheer volgens Wilbert Teunissen (3)

Bron: Implementeren van functioneel beheer is meer dan een procesmodel, Wilbert Teunissen, in: IT Service Management best practices / 2009 Gold Edition