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

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

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

Gebaseerd op een afbeelding die ik tegenkwam in een presentatie van Nicole de Swart over Niet-functionele requirements Hoe uitvragen bij gebruikers? illustreert bovenstaande figuur het nut en de noodzaak van requirements.

Bron: Presentatie van Nicole de Swart over Niet-functionele requirements Hoe uitvragen bij gebruikers?

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.

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

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:

• Applicatieportfoliomanagement
• Business case voor IT-complexiteitsreductie

Bron: Applicatieportfoliomanagement voor IT-complexiteitsreductie, Arjan Juurlink

Quint Wellington Redwood ontwikkelde het Demand Supply Governance Framework (DSGF) om organisaties te helpen grip te krijgen op de besturing van IT. De achtergrond van het DSGF is dat Quint in samenwerking met het ministerie van Defensie in 2002 een model ontwikkelde voor de het outsourcen van IT (Smart Buyer Function, SBF) en aansturen van externe IT-leveranciers. Dit model evalueerde tot een framework gericht op de aansturing van IT-diensten van zowel externe als interne IT-organisaties (Sourcing Governance Framework, SGF). Door meer nadruk te leggen op regie (aansturen van de vraag naar IT-diensten, bereiken van het juiste evenwicht tussen vraag en aanbod), verbrede het framework zich tot een Demand Supply Governance Framework voor regie.

Het DSGF is een hulpmiddel voor het snel en doelmatig inrichten van de regiefunctie. Centraal binnen het DSGF staat het managen van de vraag naar IT-diensten en het aanbod door zowel externe als interne leveranciers van IT-diensten. De term 'demand supply governance' slaat op het op elkaar afstemmen van vraag en aanbod ('regie'). Het DSFG brengt de aandachtsgebieden in kaart die goed gemanaged moeten worden om - in de woorden van Quint - 'de overeengekomen IT-diensten te kunnen leveren en de toegevoegde waarde van IT voor de klant te verhogen'.

De doelstellingen van demand supply governance (regie) zijn tweeledig:

1. Borgen dat interne en externe leveranciers daadwerkelijk de IT-diensten leveren, conform de afspraken die daarover met de klant zijn gemaakt.

2. Het aantoonbaar verhogen van de toegevoegde waarde van IT, door een focus op diensten en projecten die de business een duurzaam concurrentievoordeel opleveren.

Binnen het DSGF worden drie domeinen onderkend: 'Business', 'IT' en 'Alignment' (het ‘regiedomein’) met elk drie niveaus: strategisch, tactisch en operationeel. Quint addresseert 29 aandachtsgebieden door deze te plotten op de negenvlaksmatrix. Verder worden ook drie werkstromen* (delivery flows) onderkend die staan voor de 'objecten' van (be)sturing.

1. De correcte levering van gecontracteerde standaarddiensten en aanvragen aan de gebruiker, conform de producten- en dienstencatalogus en SLA’s.

2. De tijdige en correcte levering van changes (speciale orders).

3. De tijdige en correcte levering van projectresultaten en de controle over het projectportfolio.

Alledrie de domeinen zijn betrokken bij elk van de leveringsstromen. De regieorganisatie richt zich binnen de drie stromen voornamelijk op de koppelvlakken die essentieel zijn voor een goede levering van IT-diensten en -projecten. Aan de hand van de aandachtsgebieden en de sturing van de werkstromen biedt het DSGF inzicht in de rollen die in de verschillende domeinen te vervullen zijn en welke competenties hiervoor nodig zijn.

*Ik woonde recentelijk een (interne) presentatie van Quint Wellington Redwood bij waarin vier ipv drie werkstromen werden onderkend:

1. Projecten

2. Specials (toekomstige PDC items)

3. Standaard verzoeken (PDC)

4. Operationele dienstverlening (SLA)

Bron: Whitepapper Regie van IT – diensten en projecten Verbinden van vraag en aanbod (Quint Wellington Redwood)

Daan Rijsenbrij hanteert een brede opvatting van beleid, waarbij beleid wordt opgevat als:

• Missie of de toekomstvisie
• Strategie, de weg waarlangs wordt voortgegaan
• Doel waarnaar we onderweg willen zijn
• Interne voorschriften, procedures of reglementen

Beleid kan volgens Rijsenbrij zowel 'expliciet' als 'impliciet' zijn. Bij impliciet beleid gaat het om feitelijk gevolgd beleid. "Impliciet beleid ontstaat doordat er vanuit de omgeving van de organisatie of door het functioneren van de organisatie zelf voorvallen optreden die problemen veroorzaken. Doordat deze problemen zich voordoen worden er vraagtekens geplaatst bij de bedrijfsvoering. Ieder gezond bedrijf zal vervolgens deze vraagtekens willen wegnemen en zal met oplossingen komen om de gerezen problemen op te kunnen lossen. Deze oplossingen leiden weer tot een bepaalde manier van handelen bij de medewerkers van de desbetreffende organisatie. Deze specifieke manier van handelen tenslotte zien we als impliciet beleid voor het functioneren van het bedrijf." Expliciet beleid gaat over gezegd of geschreven beleid. Het expliciete beleid beschrijft als het ware de lange termijn visie van de organisatie.

Volgens Rijsenbrij onstaan vanuit de omgeving kansen en bedreigingen voor de organisatie en komen vanuit het bedrijf zélf - door een sterkte-zwakte-analyse - sterke en zwakke punten naar voren. Tezamen leveren de kansen en bedreigingen en sterkten en zwakten de strategische aandachtspunten op voor de organisatie. Om deze strategische aandachtspunten te kunnen realiseren wordt op top-niveau binnen de organisatie een bedrijfsbeleid opgesteld. Het informatiebeleid is nodig om recht te doen aan het belang en de invloed van ICT op het functioneren van een organisatie. Het informatiebeleid vormt in feite een integraal onderdeel van het bedrijfsbeleid en doet uitspraken over:

• Hoe om te gaan met bedrijfsgegevens
• Hoe om te gaan met informatiesystemen
• Hoe om te gaan met informatietechnologie
• Hoe om te gaan met de werkorganisatie rond de informatievoorziening
• Hoe om te gaan met de inzet van middelen t.a.v. de informatievoorziening

Bij de ontwikkeling van informatiebeleid gaat het erom voor bovengenoemde vijf punten strategische keuzes te maken en randvoorwaarden op te stellen voor het realiseren van het informatiebeleid.

Bron: Informatiebeleid, -planning en -architectuur, Daan Rijsenbrij

In het Tijdschrift IT Management (TITM) stond ooit (9/2009) een artikel getiteld "KLM’ers vliegen in formatie" over de manier waarop bij KLM de ontwikkeling, het beheer en onderhoud van de informatiesystemen is geregeld. Als opwarmertje een inleidende quote:

“De IT-organisatie van KLM is de afgelopen zeven jaar volledig getransformeerd. Vóór 2002 was er bij de business de nodige ontevredenheid over hetgeen de toenmalige IT-organisatie leverde. Nu treedt IT op als enabler van ‘smart leadership’ bij de business.”

Gezien mijn bijna-KLM-ervaring uit het verleden (ik heb effectief een week bij de KLM rondgehuppeld, achteraf bleek de week van 11/9/2001, niet helemaal gelukkig getimed!) was de interesse gewekt. Hierbij een poging de - vanuit het perspectief van het inrichten van de organisatie van de informatievoorziening gezien - belangrijkste aspecten van de KLM-werkwijze te reconstrueren.

Binnen de organisatie van de informatievoorziening (IV-organisatie) spelen vijf organisatieonderdelen een cruciale rol:

1. Information Services (IS): dé centrale ICT service provider van KLM. De organisatie levert centrale ICT-diensten op het gebied van ontwikkeling, beheer en onderhoud van ICT-systemen en van internet- en intranetdiensten. Zodra informatie en informatiesystemen een rol spelen, wordt IS betrokken.

2. CIO Office: richt zich op compliance (kijken of door IT ingevulde ‘hoe’ past binnen de architectuur), en de financiën (welk financieel beslag legt een eventuele vernieuwing op het geheel?)

3. Development

4. Operations

5. Business Development Organization (BDO)

Development vs. operations
Het onderscheid tussen Operations en Development ligt, als het gaat om aanpassingen aan de systemen, op het technische en functionele vlak. Dus bij opdrachten op het gebied van innovatie is Development altijd ‘in the lead’, maar Operations bepaalt op welke termijn de gevraagde technologie uiteindelijk opgeleverd en ingezet kan worden. Als het gaat om ‘continuïteit is niet meer de Information Manager, maar de exploitatiemanager bij de BDO in de lead. Bovendien is Development onderaannemer geworden van Operations.

Operations
- Ervoor zorgen dat alle systemen 7x24 uur draaien.
- Onderaannemer van ICT-Development.
- Business Service Managers: verantwoordelijk voor één of meerdere services, ofwel de SLA en daaronder de zogeheten Service Provisioning Agreement (SPA).
- Maandelijks rapportages over verleende diensten.

De BDO heeft als doel het ondersteunen van de business bij het bereiken van businessdoelen door zowel continue optimalisatie van de informatievoorziening (process en organisatie) als het veiligstellen van de continuïteit. BDO is het organisatieonderdeel waarin mensen van de ‘business’ zitten en die als het gaat om IT-innovatie de ‘wat-vraag’ formuleren en de uiteindelijke businessimplementatie verzorgen. De BDO is verantwoordelijk voor het formuleren van de ‘wat-vraag’ en het overbrengen van business-vraag (het ‘wat’ + te verwachten benefits).

Elk bedrijfsonderdeel heeft een 'eigen' BDO waarbinnen wordt nagedacht over hoe organisatie er ‘morgen’ uit gaat zien en welke IT-systemen daar dan bij van pas komen. Als het gaat om innovatie is BDO verantwoordelijk voor de businessarchitectuur en voor Information Management. De BDO-afdelingen zijn tot stand gekomen als onderdeel van een reorganisatie waarbij 16 Informatie Management-afdelingen zijn geconsolideerd naar vijf BDO’s. De business zag de IM-organisatie ‘oude stijl’ vaak als onderdeel van IT. BDO streeft ernaar om nu juist te worden gezien als partner van de business. Binnen de BDO is zowel de continuïteit als innovatie van belang, maar geldt dat sprake is van een financiële scheiding tussen innovatie en continuïteit voor wat betreft IT-kosten.

Elke BDO heeft een counterpart bij de ICT-Development-organisatie, de zgn. ‘Organizer’. De Organizer - die gaat over de 'hoe'-vraag - benoemt een projectleider, gaat aan de slag en weet dat hij of zij mensen nodig heeft uit beide onderdelen. Haalbaarheid qua resources ligt bij Development-organisatie.

Functies binnen BDO
(1) Business analyse
(2) Informatiemanagement
(3) Project- en programmamanagement
(4) Functioneel applicatiemanagement
(5) Business architectuur

Ad (1) Business analisten
Een business analist zorgt voor de optimalisatie van de processen, organisatie en informatievoorziening. Zijn kerncompetenties zijn: Business Process Modelling, Requirements management en Value Management. Een goede business analist is een generalist met zodanige skills dat je ze overall kunt inzetten, in staat binnen korte tijd processen te doorzien.
- (zeer veel) kennis van de businessprocessen/formuleren heldere business processen
- fungeren als intermediair tussen business en IT
- genereren valide business cases (ist-, soll-situatie + delta daartussen)
- opstellen business requirements
- meerwaarde moeten toevoegen aan de innovatie van de business.

Business analyse framework
- As-is
- To-be (requirement analysis)
- Change (business change management)
- Benefits (benefits definition/tracking)

Ad (2) Informatiemanagement
Het proces van IT-innovatie begint bij Informatie Management, de mensen die in de managementteams zitten bij de diverse businesses. Zij adviseren de business proactief als ze kansen of bedreigingen zien waar ICT een rol zou kunnen spelen of ze krijgen direct een verzoek vanuit de business.
Een informatiemanager draait als een project assurance mee bij ale projecten binnen een BDO en bewaakt in feite de kwaliteit van het project namens de opdrachtgever.

Ad (4) Functioneel applicatiemanagement
Binnen elke BDO worden alle bedrijfskritische applicaties beheerd. Binnen een BDO zitten ook functies die zich ontfermen over de continuïteit en het functionele beheer van de applicaties, en die komen al in beeld voordat een innovatieproject wordt opgeleverd.
De Functioneel Applicatie Beheerder bij KLM IT is verantwoordelijk voor het ondersteunen van gebruikers met betrekking tot de eigen applicaties en gerelateerde business processen. Daarnaast bestaat de rol uit:
• afhandelen en voorkomen van incidenten en het analyseren van problemen.
• deelnemen aan incident-, problem- en changeproces.
• beheren van het functionele deel van de eigen applicaties en de doorlooptijd hiervan.
• deelnemen in projecten op basis van kennis van de systemen en de verantwoordelijkheid voor de beheersbaarheid van de applicatie

Ontwikkeling (development) bij de KLM
Business heeft idee => BDO ontwikkelt business case => Besluitvorming
Als na besluitvorming de BDO-organisatie deze business case wil realiseren, gaat de BDO naar de Organizer aan de Development-kant.

Design permit
Vereist om met het maken van het ontwerp te starten.
CIO (Enterprise architecten) beslissen na check op toepassing architectuur/regelgeving
Beheerorganisatie adviseert na check beheer-regelgeving.

Build permit
Vereist om met de bouw van applicatie en infra te starten en met de inrichting van het beheer.
CIO beslist na check op toepassing architectuur regelgeving
Beheerorganisatie adviseert na check beheer-regelgeving.
- Beheerstructuur is duidelijk
- Betrokken lijnmanagers in exploitatie fase zijn gecommitteerd
- Exploitatiekosten zijn aantoonbaar gebudgetteerd en geminimaliseerd
- Opstellen SLA’s en SPA’s is als activiteit benoemd
- Activiteiten zijn benoemd voor het opstellen cq. wijzigen van bestaande en/of nieuwe producten.

Operate permit
Vereist om in productie te gaan.
Beheerorganisatie beslist na toetsing naleving beheer-regelgeving.
- applicatie ontwikkel richtlijnen zijn op de juiste wijze toegepast
- Benodigde beheerdocumentatie gereed
- Benodigde service afspraken gemaakt
- Gebruikersacceptatietest (GAT) ok

Bron: artikel "KLM’ers vliegen in formatie" in Tijdschrift IT Management (TITM) (9/2009?)

In dit Youtube-filmpje "ITIL a simple explanation" wordt met behulp van een restaurant als metafoor op eenvoudige en grafische wijze de essentie van ITL uitgelegd. ITIL is - in de woorden van de makers - 'globally accepted as the blueprint for IT to deliver business value'. Eigenlijk dus vooral een appellerende oproep om de praktijk meer in lijn te brengen met de theorie ;-).