• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
Home Informatiemanagement
Informatiemanagement
"Weer duur ict-fiasco bij overheid"
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

ict-fiasco waterschappen logica

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"

Laatst aangepast op maandag, 01 januari 2018 12:56  
Ict-drama‘s bij de overheid: problemen in plaats van oplossingen
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

ict icoon scrabble

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

Laatst aangepast op zaterdag, 15 december 2018 20:06  
7 kritieke succesfactoren voor IT-projecten
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

succesvolle requirements engineering

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

Laatst aangepast op vrijdag, 17 november 2017 22:08  
Vijflagenmodel voor architectuur
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

Vijflagenmodel architectuur organisatie proces informatie applicatie infrastructuur

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

Laatst aangepast op vrijdag, 17 november 2017 22:05  
Functioneel beheer volgens Wilbert Teunissen (1)
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

implementeren Functioneel beheer procesmodel

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:

professionaliseren functioneel beheer Teunissen Coumans

Zie ook:

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

Laatst aangepast op vrijdag, 17 november 2017 22:08  
Faalindustrie vol IT-fiasco's volgens René Veldwijk
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

De faalindustrie volgens René Veldwijk

In een interview in de Volkskrant (15/10/2011) trekt René Veldwijk, bestuurskundige en ict-ondernemer, van leer tegen de belastinggeld verspillende 'faalindustrie'. Hij kent de "chaos bij de overheid" uit eigen ervaring en stelt: 'Alle grote ict-projecten van de overheid zullen mislukken of financieel extreem uit de klauw lopen. Die tendens wordt alleen maar sterker.' Helaas moet ik het - als ervaringsdeskundige - met hem eens zijn.

Veldwijk spreekt over '(f)unctionele grootheidswaan': 'De essentie ervan is dat iedereen wint. Voor de ict-bedrijven bestaat de winst uit meerwerk. Gammele systemen dragen bij aan werkgelegenheid en enorme ict-afdelingen. Voor de bestuurders ligt de winst in inspectietripjes naar Bombay. Ze maken een cultuur waarin iedereen verantwoordelijk is als het mis gaat. En intussen zegt iedereen: het is voor de goede zaak.' 'Spuit ze een waarheidsserum in en ze zullen volhouden dat het voor de goede zaak is. Maar ik zeg: kijk naar de empirie, de proefondervindelijke
waarneming. Ik heb een lijst met een stuk of veertig projecten uit de faalindustrie. De gemoderniseerde bevolkingsadministratie, het nieuwe
handelsregister, de ict bij Defensie.' Veldwijk noemt ook nog het toeslagensysteem van de Belastingdienst (500 mln) en het ict-systeem voor de uitkeringen van het UWV (89 mln).

Over het project "Polisadministratie" van de UWV en de Belastingdienst (maandelijks alle inkomens van alle Nederlanders in één geautomatiseerd systeem krijgen), zegt hij het volgende: 'Een project van grootheidswaan was het, echt waar. Of het technisch kon, boeide niemand. (..) Ik was bij de aftrap in 2000 (..) en ik zat erbij dat de topambtenaar van toen, de heer Van 't Eind, letterlijk zei: 'Dames en heren, laat het u duidelijk zijn dat haalbaarheid geen enkele overweging is voor mijn politieke opdrachtgevers.' Letterlijk zei hij dat. Hij zei het met een glimlach. Eerst dacht ik: ironie. 'Later dacht ik: die man heeft precies door wat de spagaat is. Bestuurders die van alles willen en ict'ers die zich afvragen: hoe kunnen ze het verzinnen, maar dan wel voor het grote geld gaan.'

Een van de redenen waarom juist bij de overheid ict-projecten mislukken is - in de woorden van Veldwijk - 'omdat daar de ict-kneuzen zitten.' Volgens Veldwijk geldt dat '(d)e besten onder de ict'ers, de mensen die gaan voor het eindresultaat (..) gaan niet naar de overheid.'

'De overheid let niet op de centen. Ik werk momenteel aan een project voor een bedrijf. Mijn inkomsten zijn hun kosten. Dat doet hen pijn en die pijn leidt ertoe dat zakelijke keuzes worden gemaakt.' 'Bij de overheid is er voor grote ict-projecten geen pijn. Den Haag levert de gelden aan bijvoorbeeld het UWV. Die geven eenderde van het geld uit aan opdrachten voor Capgemini en Logica en maken tweederde zelf op. Als het
project uitloopt, komt er meer geld. Want liever geldverlies dan gezichtsverlies. Zo ontstaat een beweging waarin falen in ieders belang is
en projecten nooit afkomen. Omdat ict geen fysieke verschijningsvorm heeft en in die zin onzichtbaar is, kunnen wantoestanden eindeloos groeien. '(..) Dan krijg je dus systemen die niet afkomen of die niet afkomen of die niet betrouwbaar functioneren of niet te onderhouden zijn. (..) Iedereen in de sector weet het. (..) Maar iedereen houdt zijn mond. Ik niet. Niet omdat ik een beter mens ben, maar omdat ik geen deel wil uitmaken van de ict-faalindustrie.

Volgens Veldwijk is géén sprake van oplichting, maar welbegrepen eigenbelang: 'Nee, als iedereen het weet is het geen oplichting meer, maar een ongeschreven contract (...) Woorden als oplichting en corruptie neem ik niet in de mond. Ik wil wel zeggen dat ik verbijsterd ben. We gooien jaarlijks miljarden aan belastinggeld weg, terwijl iedereen met een basiscursus organisatiekunde moet kunnen zien wat er aan de hand is. Als je die verbijstering radicaal wilt noemen, ben ik graag radicaal.'

"De ict-staf is tot het einde toe positief, want het salaris komt uit de projectbudgetten. En de UWV-voorzitter wil niet met een mislukking naar de
minister. En de minister wil niet met een mislukking naar de Kamer. En de politiek kan de sociale zekerheid niet meer overhevelen naar de gemeenten, want niemand durft nog te werken met het oude ict-systeem. De moraal? Win, win, win!'"

In een column in Database Magazine liet Veldwijk zich al eerder in vergelijkbare bewoordingen negatief uit over de faalindustrie.

Volgens Veldwijk mislukken ICT-projecten met de overheid als opdrachtgever bijna standaard. Hij stelt dat - ondanks krantenartikelen en kamerdebatten - de schade voor de ICT-leverancier vaak verwaarloosbaar is: '...de ICT-leverancier van tegenwoordig heeft een economisch belang bij falen. Als een project van 8 miljoen euro wordt opgeblazen tot naar schatting 80 miljoen omzet dan ben je beter af met een mislukking dan met uitvoering conform plan.'

'Bij megafaalprojecten rollen er geen koppen van het interne ICT-management maar wanneer projecten uit de hand lopen komt er aanvullend budget vanuit Den Haag. (..) Waar commerciële bedrijven (...) bijna kapot zijn gegaan aan de kosten van mislukte ICT-projecten, betekent een groot ICT-project bij de overheid juist extra omzet en een faalproject véél extra omzet.' Veldwijk concludeert dan ook dat bij de overheid ICT-falen onderdeel uitmaakt van een ontspoord zo niet corrupt systeem en stelt dat deze conclusie past bij de voor iedereen waarneembare faalepidimie bij de overheid.

Veldwijk komt ook (kort) aan het woord in een artikel in Elsevier (14 mei 2011) onder de titel "Grossieren in IT-fiasco's". Het artikel maakt melding van het verprutsen van belastingeld met ambitieuze, peperdure automatiseringsprojecten en stelt dat als het gaat om IT-investeringen door de overheid een euro weinig waard is. Voor automatiseerders is de overheid een goudmijn. Hun IT-projecten zijn duur en complex - en als het misloopt, zijn de kosten voor de belastingbetaler. Als service van de zaak zet Elsevier twaalf in het oogspringende, problematische IT-zeperds uit de afgelopen tien jaar op een rij.

De ambities van automatiseringstrajecten worden zelden waargemaakt. Onderzoek waarbij de Algemene Rekenkamer in 2008 vijf grote IT-projecten onderzocht leiden tot de conclusie dat de projecten fors meer kostten dan verwacht, geen enkel project op tijd klaar was en dat de systemen die werden opgeleverd beduidend anders waren dan bedoeld.

Chris Verhoef, hoogleraar informatica aan de Vrije Universiteit, schat in dat het bij de overheid ruwweg twee keer zo vaak misgaat als in het bedrijfsleven. Volgens Verhoef willen politic met een IT-project (te) makkelijk scoren: 'We gaan het voor u, burgers en bedrijven, makkelijker én goedkoper maken. (..) Ze beginnen zeer ambitieuze projecten, want IT belooft vooruitgang. Maar ze zien er de enorme complexiteit niet van in.' IT-leverancier doen graag mee, maar zien geld verdienen als hun rol, niet om de overheid te vertellen of het misschien anders en goedkoper kan.

Bronnen: De Volkskrant, "Bij de overheid zitten ict-kneuzen" (15/10/2011), interview René Veldwijk, en column De Faalindustrie in Database Magazine, 28 september 2010, "Grossieren in IT-fiasco's", artikel in Elsevier, 14 mei 2011

Laatst aangepast op vrijdag, 17 november 2017 22:05  
Impactanalyse functoneel beheer volgens Van der Spaa
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

impactanalyse functioneel beheer

In het artikel "Time & Impact management Functioneel Beheer" bepleit Marina Idema van der Spaa een drieledige impactanalyse. Bij het (willen) wijzigen van de geautomatiseerde informatievoorziening is het niet alleen nodig om een impactanalyse te laten uitvoeren door de ICT-leverancier (applicatiebeheer én technische beheer), maar is het ook nuttig en nodig de impact te bepalen voor functioneel beheer en de gebruikersorganisatie.

Als het gaat om de ICT-impact, is inzicht nodig in de impact op de geautomatiseerde informatievoorziening, de verwachte tijdsinspanning, mogelijke opleverdata en financiële plaatje. De impactanalyse voor functioneel beheer en de gebruikersorganisatie geeft inzicht in de alle met de wijziging samenhangende werkzaamheden en de daarvoor benodigde tijdsplanning die daarvoor nodig is aan de kant van functioneel beheer zélf en voor de gebruikersorganisatie. Inzicht in de benodigde uren aan de business-kant zijn met name van belang met het oog op resourcemanagement.

De resultaten van alledrie de impactanalyses (AB, TB, FB) helpen bij het maken van een keuze voor een oplossing(srichting) en zijn cruciaal voor het inplannen van het wijzigingsvoorstel in een release: "De inhoud van een release zou (...) niet alleen maar moeten worden gebaseerd op de beschikbare capaciteit aan de leverancierskant, maar een totaal overzicht van alle beheerdomeinen. Met een gedegen planning aan de voorkant is voor een functioneel beheerafdeling beter inzichtelijk wat wel en niet mogelijk is. Ook voor de gebruikersorganisatie wordt hiermee duidelijk hoeveel resource capaciteit functioneel beheer van de gebruikersorganisatie verwacht voor acceptatietesten en eventuele opleidingen etc."

Bij het bepalen van de impact voor functioneel beheer en de gebruikersorganisatie zijn volgens Van der Spaa de onderstaande activiteiten van belang:

  • Opstellen requirements
  • Opstellen impactanalyse
  • Aanpassen/opstellen handleidingen gebruikersorganisatie
  • Aanpassen/opstellen handleidingen beheerorganisatie
  • Aanpassingen / Opstellen  processen en beschrijvingen
  • Aanpassingen beveiligingen
  • Opleiding(en) gebruikersorganisatie
  • Communicatie intern
  • Communicatie extern
  • Opstellen Acceptatietest
  • Uitvoeren Acceptatietest
  • Aanpassingen/opstellen processen en beschrijvingen (AO)

Bron: Time & Impact management Functioneel Beheer, Marina Idema van der Spaa

Laatst aangepast op maandag, 01 juni 2020 08:42  
Functionele en technische kwaliteit van applicaties
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

functionele technische kwaliteit applicaties Juurlink

In het boek Applicatieportfoliomanagement voor IT-complexiteitsreductie beschrijft Arjan Juurlink negen aspecten die bepalend zijn voor de functionele en technische waarde van applicaties:

Functionele kwaliteit van een applicatie

  1. Procesondersteuning: mate waarin als het systeem er niet zou zijn extra handmatig werk (uitgedrukt in fte) nodig zou zijn.

  2. Strategisch belang (competitive advantage): mate waarin je concurrentie al dan niet ook beschikken over dezelfde functionaliteit (features).

  3. Gebruikerstevredenheid: mate waarin gebruikers al dan niet tevreden zijn over het functioneren van de applicatie ('gebruikerswaarde').

  4. Functioneel risico: risico op factoren verwachte wettelijke wijzigingen, aantal gebruikers, operatie die binnen 2 dagen stopt of mogelijke reputatieschade.

Technische kwaliteit van een applicatie

  1. Technisch doelplatform: mate waarin de technologie verouderd danwel standaard (incl. bijbehorende ondersteuning vanuit de markt).

  2. Schaalbaarheid: mate waarin applicatie opschaalbaar is tegen redelijkek kosten.

  3. Flexibiliteit (procesuitbreiding): mate waarin applicatiek aanpasbaar is aan nieuwe additionele producten, processen en/of diensten.

  4. Stabiliteit/betrouwbaarheid: mate waarin applicatie stabiel gevoelig is voor (ver)storingen.

  5. Borging van beheer: mate waarin beheer (goed) is ingeregeld (niet beheerd, 'best effort' of volledig in beheer).

Gerelateerd artikel: Beheermodel van Op de Coul

Bron: Applicatieportfoliomanagement voor IT-complexiteitsreductie, Arjan Juurlink

Laatst aangepast op maandag, 01 januari 2018 12:55  
Applicatieportfoliomanagement (APM) volgens Gartner
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

TIME application triage gartner

Het TIME-model van Gartner is een model voor het classificeren van applicaties (application assessment), waarbij elke applicatie wordt beoordeeld op basis van de technische condities (architectuur, aanpasbaarheid, stabiliteit, enz.) en de business waarde.

TIME is hierbij een acroniem voor:

  1. Tolerate

  2. Invest

  3. Migrate

  4. Eliminate

Door bij het managen van de applicatieportfolio gebruik te maken van het TIME-model, kan de business haar toekomstige uitgaven in de bestaande bedrijfsapplicaties optimaliseren. De essentie van het model is dat het categoriseren van de applicatieportfolio - ook wel applicatieportfolio-triage genoemd - op basis van waarde, technische effectiviteit, risico helpt bij het nemen van verantwoorde investeringsbeslissingen.

APM investeringen

Bron: http://www.epiheirimatikotita.gr/elibrary/management/John.Wiley.and.Sons.IT.Portfolio.Management.Step-by-Step.pdf

Laatst aangepast op vrijdag, 17 november 2017 22:06  
Applicatieportfoliomanagement volgens Arjan Juurlink
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

applicatieportfoliomanagement

Arjan Juurlink beschrijft in zijn boek Applicatieportfoliomanagement voor IT-complexiteitsreductie het belang van hebben van een helder inzicht in het applicatielandschap en het vastleggen van de relevante gegevens in een zgn. Applicatie Inventory. In het onderstaande wordt aangegeven wat volgens Juurlink de belangrijke aspecten zijn van het applicatie en geeft inzicht in de de belangrijkste begrippen en processen die een rol spelen bij het reduceren van complexiteit in het applicatie- en infrastructuurlandschap.

IT (Service)-portfoliomanagement: paraplubegrip voor alle activiteiten die zich bezighouden met het in lijn brengen van de IT-voorzieningen en de strategische doelstellingen van de organisatie. Het gaat om het besturen van de samenhang van de portfolio van IT-diensten met de strategie van de organisatie. Doel is door te sturen op samenhang in de portefeuille van IT-services de effectiviteit van de inzet van IT toe te laten nemen.

In het ideale geval is een organisatie in staat om naar IT-voorzieningen te kijken als onderdeel van business-services. Applicaties zijn het meest zichtbare deel van een business-service en worden door de gebruiker vaak als een geheel gezien met gegevens en infrastructuur. Omdat een SLA de dienstverlening vaak beschrijft in relatie tot het (complexe) applicatielandschap, gebruikt Arjan Juurlink het begrip applicatieportfoliomanagement als hulpmiddel voor het reduceren van complexiteit in het applicatie- en infrastructuurlandschap.

Voor het kunnen reduceren van de complexiteit in het applicatie- en infrastructuurlandschap is het volgens Juurlink noodzakelijk een Applicatie Inventory ('single-source-of-truth') aan te leggen, waarin minimaal voor elke applicatie de kosten, het belang en het risico (incl. de verwachte ontwikkeling van alledrie de aspecten tot het eind van de levenscyclus). Juurlink waarschuwt voor het gevaar om té veel zaken vast te leggen en pleit voor het vastleggen van een beperkt aantal gegevens voor het gehele landschap. Op basis van need-to-know is het mogelijk later alsnog meer informatie te inventariseren. Hij onderscheidt drie categorieën informatie:

  1. Analysegegevens: gegevens die nodig zijn om het applicatielandschap in te delen in categorieëen. Het is van belang deze groep gegevens zo beperkt mogelijk te houden, omdat deze informatie voor het gehele landschap moet worden vastgesteld.

  2. Rapportagegegevens: wanneer de eigenaar van een groep applicaties wil kunnen sturen op de afhankelijkheden en op de voortgang van de migratie naar de doelarchitectuur, zijn overzichten nodig op basis van doorsneden en invalshoeken (zoals proces, informatie- of productdomein, ontwikkelomgeving en soort technologie), om de voortgang (in 'standgegevens') te kunnen volgen.

  3. Executiegegevens: (tijdelijke) gegevens die nodig zijn om te weten wanneer een applicatie daadwerkelijk wordt gemigreerd, zoals bijvoorbeeld aantallen logische of fysieke database-instanties. Het verzamelen van deze gegevens vindt plaats op basis van need-to-know en alleen voor applicaties die deel uitmaken van een migratie.

Juurlink clustert de eigenschappen van een applicatie in zeven categorieën:

  1. Applicatiegegevens: [ identificatie, naam, versie | service level | status | maatwerk/standaard | fase levenscyclus | client/server/beide | jaar in productie | datum laatste release | jaar end-of-life ]

  2. Functionele gegevens: [ relatie procesketen | relatie bedrijfsproces | belang voor bedrijfsproces | mate waarin proces wordt ondersteund | mate van gebruik (business events) | doelomgeving ja/nee | functionele kwaliteit ]

  3. Gebruiksgegevens: [ aantal gebruikers | gem. frequentie van gebruik | aantal installaties | aantal incidenten | performance | gebruikerstevredenheid | datakwaliteit | inleertijd ]

  4. Organisatiegegevens: [ businesseigenaar (eigenaar functionaliteit) | eigenaar applicatie | functioneel beheerteam | applicatiebeheerteam | aantal beheerders in organisatie | aantal beheerders buiten de organisatie ]

  5. Leveranciersgegevens: [ leveranciersnaam | productnaam | productversie | omvang leverancier | binnen/buitenlands ]

  6. Technische gegevens: [ hardwareplatform | operatingsystem | DBMS | aantal interfaces intern/extern | ontwikkelplatform | aantal regels code | middleware | doelomgeving ja/nee | technische kwaliteit ]

  7. Business-strategie: op welke wijze draagt applicatie bij aan de strategie?

Arjan Juurlink hanteert de volgende definities:

  1. Applicatie: eenheid van functionaliteit die van buitenaf autoriseerbaar is ten behoeve van een eindgebruiker. Een applicatie ondersteunt één of meer stappen uit een bedrijfsproces. Alles wat verdwijnt op het moment dat een applicatie wordt uitgezet, behoort tot deze applicatie.

  2. Component: een applicatie bestaat uit componenten, een component is ondeelbaar en draait op dezelfde technische stack (optelsom van functionaliteit, ontwikkelplatform, databaseplatform, middleware, operating system en hardware).

  3. Informatiesysteem: aantal applicaties die een bepaalde samenhang hebben (in termen van onderlinge verbindingen tussen applicaties, componenten en/of eindgebruikers).

Volgens Arjan Juurlink kunnen vijf soorten applicaties worden onderscheiden:

  1. End User-applicatie: applicaties die door eindgebruikers zélf zijn ontwikkeld (vaak op eigen werkplek, denk aan allerlei Excel-trucendozen)

  2. Image-applicaties: in verre mate gestandaardiseerde besturingssoftware en/of gebruikerssoftware (MS Office, internetbrowsers).

  3. Standaardkantoorapplicaties: standaarddiensten (meestal standaardpakketten) die een gebruiker kan bestellen via de IT-catalogus.

  4. SLA-applicaties: applicaties die niet standaard in de bestelcatalogus voorkomen, en meestal worden gebruikt ter ondersteuning van de (primaire) bedrijfsprocessen. Voor deze applicaties worden Service Level Agreements (SLA's) afgesloten met de (interne) leverancier, bijv. ten aanzien van beschikbaarheid, maximale tijd voor afhandeling van storingen. Het gaat meestal om uitgebreidere standaardpakketten, ERP-pakketten en specifieke maatwerkontwikkelingen.

  5. IT-for-IT applicaties: ontwikkel- en beheertools, 'tooling' om IT-diensten te maken en/of beheren.

Nadat de basisgegevens van het applicatielandschap zijn geïnventariseerd en geregistreerd, is het mogelijk applicaties te classificeren. Classificatie helpt bij het bepalen van migratiescenario's naar de doelarchitectuur of uitfasering. Arjan Juurlink noemt de volgende veelvoorkomende scenario's:

  • Behouden
  • Uitbouwen
  • Opschonen
  • Herplatformen
  • Migreren
  • Consolideren
  • Vervangen
  • Uitzetten

Arjan Juurlink beschrijft zijn boek beknopt ASL en BiSL, maar in relatie tot complexiteitreductie zijn vooral drie processen van belang:

  1. Applicatielifecyclemanagement : ASL-proces dat beslissingen faciliteert over investeringen in vernieuwing en onderhoud van een applicatie (gebaseerd op de levenscyclus van de applicatie).

  2. Applicatieportfoliomanagement: ASL-proces dat het applicatie- en infrastructuurlandschap optimaliseert voor de bedrijfsdoelstellingen.

  3. Planning en control: BiSL-proces wordt door Juurlink vertaalt naar projectportfoliomanagement dat zich bezig houdt met de coördinatie van projecten en programma's van een organisatie om de realisatie te optimaliseren, het risicoprofiel van de portfolio evenwichtig te houden en ervoor te zorgen dat projecten in lijn zijn met de strategie van de organisatie en binnen budgettaire grenzen wordt opgeleverd.

Volgens Juurlink bij het nemen van 'portfoliobeslissingen' gekeken worden naar de verdere - liefst gehele - levensduur van applicaties en de onderliggende infrastructuur. De lifecycle van functionaliteit wordt opgedeeld in drie categorieën:

  1. Doelapplicaties: applicaties die (al) deel uitmaken van de doelomgeving.

  2. Te migreren kernapplicaties: applicaties waarvan de functionaliteit nog niet in de doelomgeving is gemigreerd (maar dit moet nog wel gebeuren omdat deze applicaties nog zeker zo'n drie tot vijf jaar gebruikt moeten worden).

  3. Legacy applicaties: applicaties die nog binnen de planperiode (meestal 1 tot 3 jaar) gesaneerd zullen worden.

Zie ook:

Bron: Applicatieportfoliomanagement voor IT-complexiteitsreductie, Arjan Juurlink

Laatst aangepast op maandag, 01 januari 2018 12:56  
Meer artikelen...


JPAGE_CURRENT_OF_TOTAL

Every day you ask yourself, 'How did our values influence decisions I made today?' If they didn't, they are pretty much bullshit.

Peter Senge

Banner
Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 214 gasten online
Artikelen

klantgericht volgens don peppers martha rogers lean klant

Banner

visueel presenteren dan roam presentatie

Visueel presenteren
het ontwerpen van presentaties die overtuigen
Dan Roam

Bij Bol.com | Managementboek

 



Bewaren

Lean boekentips

Banner