In het artikel Busines-IT alignment: zal nooit gebeuren stelt Arno Oosterhaven dat de dappere pogingen om business en IT op één lijn te brengen weinig hebben opgeleverd. Hij pleit er dan ook voor om Business-IT alignment niet te zien als op te lossen 'probleem', maar als fenomeen waarmee we moeten leren leveren.
Business-IT alignment (bITa) staat al ‘sinds mensenheugenis’ in de top-5 van ict-aandachtspunten in de boardroom. Kennelijk lukt het ons maar niet om dit ‘probleem’ op te lossen. Moeten we ons daarover zorgen maken? Schieten wij (business én ict) al jaren schromelijk tekort om hier verbetering in aan te brengen? Of is het een fenomeen waarmee we moeten (leren) leven? Het antwoord is: Ja, we moeten ermee leren leven! Sterker nog, we moeten de gezonde spanning die er bestaat tussen business en ict koesteren.
De spanning tussen business en IT is gezond en moet vooral blijven bestaan. Oosterhaven is van mening dat sprake is van een paradox: juist door de gezonde spanning (‘gap’) tussen business en ict te koesteren (er goed mee om te gaan) het mogelijk is de toegevoegde waarde van ict voor de business te vergroten (door de bITa verbeteren). Door jezelf bewust te zijn van de spanning en deze vooral bespreekbaar te houden, blijft iedereen scherp.
Alignment betekent letterlijk ‘op één lijn brengen’. Business-IT alignment (bITa) betekent dus business en IT op één lijn brengen of, zo u wilt, ict in lijn brengen met de business. Oosterhaven beschrijft drie pogingen om de bITa tot stand te brengen:
Het Strategic Alignment Model (SAM) van Henderson en Venkatraman (1993): model waarin vier alignment perspectieven (of -aanpakken) worden onderkend: (i) de strategie uitvoeren, (ii) de juiste IT kiezen, (iii) (concurrentie)potentieel van IT benutten, en (iv) IT-services optimaliseren.
Het Strategic Alignment Maturity Model van Luftman (1999): model waarin wordt ingegaan op de factoren die alignment beïnvloeden. Door de invloedsfactoren meetbaar te maken, is het mogelijk de mate van bITa vast te stellen. Luftman plaatste op zijn model een volwassenheidsmodel waarmee groeiperspectieven kunnen worden getoond op weg naar het ‘bITa-walhalla’.
Het Amsterdamse informatiemodel of 9-vlaksmodel (1997): model is een uitbreiding van SAM, waarin expliciet aandacht is voor een Informatiedomein (incl. informatiemanagement als aparte entiteit) als 'brug' tussen business en IT.
Volgens Oosterhaven heeft het mislukken van de pogingen om business en IT op één lijn te brengen, vooral geleid tot het besef dat "we ons (eindelijk) dat business-en-ict-vraagstukken eigenlijk veranderingsvraagstukken zijn, waarin de eerder genoemde interventies misschien wel randvoorwaardelijk zijn, maar niet de oplossing bieden om business en ict ‘op één lijn te brengen’. Het gaat bij bITa immers om een continu veranderingsproces waarin onderlinge relaties, samenwerken, persoonlijk belangen, begrip en respect voor elkaar dominante factoren zijn en om passende ‘zachte’ interventies vragen".
Oosterhaven stelt dat "ruim twintig jaar onderzoek en experimenten ons wel inzicht heeft gebracht in het fenomeen bITa, maar dat we nog steeds geen antwoord hebben op de vraag hoe we de kloof tussen business en ict kunnen dichten".
Als bITa al jaren hoog op de managementagenda staat en we al decennia lang - zonder succes - proberen er iets aan te doen, wordt het - aldus Oosterhaven - tijd om het over een andere boeg te gooien. Het is tijd ons af te vragen "of het eigenlijk wel een ‘probleem’ is dat per se moet worden opgelost of dat de ‘gap’ tussen business en ict iets is waarmee we moeten leren leven. Sterker nog, misschien is hier wel sprake van een ‘gezonde spanning’ tussen business en ict waar we de scherpe kantjes vanaf moeten halen, maar die we vooral in stand moeten houden omdat het vragen oproept die ons scherp houden".
Vanuit de gedachte dat van een (gezonde) spanning tussen business en ict trekt Oosterhaven vier vermeldenswaardige conclusies over de relatie tussen business en ict:
Dé 'business' bestaat niet. Er zijn vele bedrijfsonderdelen als afnemers van ict-voorzieningen, met hun eigen wensen en belangen, soms tegengesteld. Het is onmogelijk die allemaal ‘op één lijn te brengen’, zeker vanuit de alom gerespecteerde (business)wens van efficiënte gemeenschappelijk voorzieningen. Het collectieve belang vereist dat je individueel wat van je wensen inlevert.
De wereld verandert, de ict-wensen ook. De oplossingen waartoe we (business én ict) in het verleden hebben besloten, voldoen vaak niet meer en belemmeren ons nu. We hebben last van onze 'installed base' (denk bijvoorbeeld aan 'legacy' applicaties). Misschien geldt zelfs de ‘wet van de remmende voorsprong’. Vernieuwen kost meer tijd en geld dan we ons kunnen veroorloven. De business wil snel en goedkoop en verwijt ict dat ze op de (legacy) rem staat.
De business wil meer dan er (financieel) kan. Investeringsruimte en budgetten leggen beperkingen op. Er moeten keuzes worden gemaakt. Dat maakt niet iedereen gelukkig, zeker niet als die keuzes aan ict worden overgelaten.
We hebben last van de ‘duivelsdriehoek’: geld, tijd en kwaliteit zijn voortdurend met elkaar in conflict. De business wil een snelle oplossing voor weinig geld en neemt genoegen met mindere (technische) kwaliteit omdat zij wordt afgerekend op resultaten op korte termijn (motto: 'wie dan leeft die dan zorgt'). Ict daarentegen wil voldoende tijd en geld om ervoor te zorgen dat de oplossing ook past in de bestaande ict-infrastructuur en voldoende robuust en onderhoudbaar is in de toekomst.
“Binnen … organisatie[s] zijn de afgelopen decennia steeds meer processen door applicaties ondersteund. Voortdurend zijn nieuwe technieken en applicaties geïntroduceerd. Meestal gedreven door een behoefte aan innovatie en betere ondersteuning van de processen, niet zelden ook door een sterke drang om elke nieuwe technologie en versies te kopen die – althans volgens de leverancier – aan alle bestaande problemen een einde zou maken. De aandacht is steevast gericht op snelle implementaties. Voor het opruimen van systemen die (deels) overbodig werden is geen aandacht, tijd of geld. Wél toevoegen, niet afbouwen.
Het resultaat? Een complex applicatielandschap, diversiteit, houtje-touwtje integratie van applicaties met ontelbare verbindingen, oplopende beheer-, onderhouds- en licentiekosten en gebrek aan overzicht. Tegelijkertijd wordt van uw organisatie steeds meer flexibiliteit verwacht, nieuwe samenwerkingen en nieuwe wet- en regelgeving staan voor de deur."
Het is dus hoogste tijd voor een grote schoonmaak en het toepassen van applicatieportfoliomanagement: welke applicaties horen thuis in de applicatieportfolio en welke applicaties zijn aan vervanging toe of dienen te worden afgeschreven. Volgens Dijkshoorn moet je bij het bepalen welke applicaties waarde hebben, welke te behouden en welke juist uit te faseren, drie stappen hanteren:
Identificeren: in kaart brengen van het applicatielandschap (op hoofdlijnen). Het doel hiervan is tweeledig. Ten eerste het identificeren van de applicaties, het in kaart brengen van de applicaties in het landschap. Ten tweede het identificeren van criteria op basis waarvan de classificatie van de applicaties plaatsvindt.
Classificeren: beantwoorden vragen in het kader van de functionele eigenschappen (in welke mate levert de applicatie een directe bijdrage aan de primaire doelen van de organisatie en hoe staat het met de mate van gebruikerstevredenheid) en technische eigenschappen (verzameling van gegevens op basis waarvan kan worden vastgesteld of een applicatie up-to-date is of verouderd en of de applicatie voldoet aan marktstandaarden) van een applicatie.
Beoordelen: afwegen van het belang en de toegevoegde waarde van een applicatie voor de organisatie op basis van de functionele en technische kwaliteit. Deze afweging resulteert in een beslissing of advies over een zgn. 'applicatieveranderscenario'. Voor elke applicatie moet een veranderscenario worden opgesteld inclusief concrete vervolgstappen. Op basis hiervan ontstaan een roadmap waarmee daadwerkelijk en onderbouwd de rationalisatie uitgevoerd kan worden.
Een belangrijk advies van Dijkshoorn is door niet té gedetailleerd te classificeren: "Door eerst alleen die vragen te beantwoorden die inzicht geven in het belang van een applicatie en een eerste beeld geven van de technische kwaliteit, ontstaat al een beeld in de toegevoegde waarde van de applicatie. Op basis van deze eerste analyse kunnen dan verdere iteraties plaatsvinden, mogelijk alleen voor die applicaties waar knellende problemen bestaan."
Belangrijke vragen zijn in dit verband: mate waarin de applicatie waarde oplevert voor het proces wat ondersteund wordt, mate waarin de (niet) beschikbaarheid van een applicatie een risico vormt voor de organisatie, mate waarin de technologie van de applicatie verouderd is, mate waarin de applicatie past in de toekomstige architectuur.
Bij het classificeren worden de antwoorden op deze vragen gescoord met waardes van bijvoorbeeld 1 tot 10 die worden vermenigvuldigt met een ‘weegfactor’. De weegfactoren geven het relatieve belang van een parameter aan ten opzichte van andere parameters. De totaalscores van de functionele en technische eigenschappen per applicatie kan worden uitgezet in een tweedimensionaal (strategisch) kwadrant. Dit kwadrant geeft op samenhangende manier inzicht in de status van een applicatie. De plek in het kwadrant bepaalt in feite het voor de applicatie van toepassing zijnde veranderscenario.
Dijkshoorn onderkent vier verschillende veranderscenario’s:
Beheren: applicaties scoren hoog op zowel functionele als technische eigenschappen en sluiten goed aan op de behoeften van de organisatie. Beheer en onderhoud van deze systemen handhaven op het huidige niveau.
Functioneel opwaarderen: applicaties scoren hoog op technische eigenschappen, maar relatief laag op functionele eigenschappen. Veelal is dat het gevolg van veranderingen in de omgeving, waardoor de applicatie de bedrijfsprocessen niet meer goed ondersteunt. Het toevoegen van nieuwe functionaliteit kan het bestaansrecht van de applicatie vergroten. Alternatief is aanschaf van een kant-en-klaar pakket.
Technisch opwaarderen: applicaties hebben hoge functionele eigenschappen, de organisatie is sterk van deze toepassingen afhankelijk. Technisch voldoen de applicaties niet en en ze vragen veel onderhoud. Applicaties zijn kandidaat voor opwaardering dan wel technische vernieuwing.
Afstoten/vervangen: applicaties scoren laag op zowel de functionele als technische eigenschappen. Feitelijk moeten deze applicaties verdwijnen. Deze systemen kunnen in het verleden van grote betekenis zijn geweest, maar sluiten niet meer aan bij de eisen en wensen van de organisatie en zijn daarnaast technologisch achterhaald.
Volgens Edwin Oord zijn er vier soorten informatiesystemen:
1. Registratiesystemen: datagerichte informatiesystemen die primair gebruikt worden om belangrijke gegevens te registreren, te beheren en beschikbaar te stellen aan processen of systemen binnen de organisatie.
2. Gegevensverwerkende systemen: informatiesystemen die bedoeld zijn om volledig of grotendeels geautomatiseerd gegevens te verwerken en daarmee straight-through-processing mogelijk maken. Het kan daarbij gaan om een geheel (keten)proces of om een kleine bouwsteen zoals een rekenmodule.
3. Taakondersteunende systemen: informatiesystemen die de uitvoering van (deels) handmatige taken door medewerkers ondersteunen.
"Het vervangen van een taakondersteunend systeem door een gegevensverwerkend systeem is een bekend middel om kosten te besparen. Maar taakondersteunende systemen blijven meestal nodig voor het verwerken van complexe situaties en uitzonderingen."
4. Interactieondersteunende systemen: informatiesystemen die de interactie met –vooral– klanten ondersteunen door informatie aan klanten te presenteren en verzoeken of opdrachten van klanten te ontvangen.
Organisatieadviseur (Boer & Croon) en universitair hoofddocent (VU) Hans Burg schreef op www.executive-people.nl een meesterlijke column over dat het onze eigen schuld is dat binnen overheidsland mega-projecten mislukken omdat we vergeten zijn welke échte problemen we ook alweer moesten oplossen. Het is niet mijn gewoonte om teksten van anderen integraal over te nemen, maar omdat deze column zich moeilijk laat samenvatten, hieronder de volledige column.
Boter op ons hoofd: reusachtige ICT-projecten
“Reusachtige ICT-projecten” bij de overheid, staat in chocoladeletters in het FD van vrijdag 6 april (2012). Een doorn in mijn oog, aangezien we het niveau ‘leedvermaak’ zelden overstijgen, maar wel gezamenlijk profiteren van al die intussen welbekende en uitgekauwde projecten met een vlekje. Of het nu een journalist is die ons nog eens fijntjes de schokkende cijfers onder ogen brengt, de wetenschapper die graag de statistieken er nog eens bijhaalt, de adviseur die nog maar eens vertelt dat 100 1-miljoen-projecten echt beter te managen zijn dan één 100-miljoen-project of de system integrator die honderden zo niet duizenden mandagen jaarlijks slijt aan overheidsinstanties.
Boter op ons aller hoofd dus! Want het kan anders. Kleiner, slimmer en succesvoller. Maar dat vraagt wel om durf. En om de wil het echte probleem onder ogen te zien en te willen oplossen. Einstein zei al: “Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction.” Hierbij mijn aanzet tot een vleugje genius…
De overheid heeft slechte ervaringen met een aantal grote ICT-projecten en er staan een aantal veranderingen op stapel die wederom tot “reusachtige” ICT-projecten gaan leiden. Althans, als we de vakbladen mogen geloven en als we blijven denken zoals we dachten. Een nieuw IT-systeem voor de Nationale Politie van 220 miljoen euro? Een webportaal voor het UWV van 60 tot 100 miljoen euro? Traditioneel denkend, dringt de voor de hand liggende vraag over deze “reusachtige” ICT-projecten zich op: hoe eten we die olifant? Mijn vleugje genius zegt me dat we daar dus niet moeten beginnen! De vraag moet zijn: van welke mug hebben we die olifant gemaakt?
Ik neem als voorbeeld het nieuwe systeem voor de Nationale Politie, waar ik geen enkele betrokkenheid bij heb of heb gehad. Even op de achterkant van een sigarenkistje, want ik heb 220 miljoen euro nog nooit bij elkaar gezien en er niet automatisch gevoel voor. Een commercieel softwarepakket met zo’n prijskaartje ken ik niet, dus mijn aanname is dat we het hebben over ontwikkel- en migratiekosten. Met een uurtarief van 70 euro en een arbeidsproductiviteit van zo’n 30 uur per functiepunt, kom ik snel rekenend op ruim 100.000 functiepunten.
Dat is orde grootte Microsoft Office in zijn volle omvang en 4x de omvang van de software voor NASA’s space shuttle. Dat kan niet waar zijn! Wat zit er in die 220 miljoen euro? Stel we fixeren het systeem fors op 10.000 functiepunten, dan kost dat 21 miljoen euro op basis van bovenstaande cijfers, en dat is maar 10 procent van het totaal. Zelfs met 26 herhaalde migratietrajecten van de huidige systemen, in een politiek complex landschap en met een veelvoud aan feasibility studies, second opinions en sterk overdreven aanbestedingsrituelen, is dat gat niet dicht te fietsen.
Dat doet vermoeden dat in die 220 miljoen euro ook de, al dan niet uitbestede, meerjaren beheercontracten zitten. Maar de organisatorische kosten en baten van de redundantievermindering en personeelsreductie dan? Ook meegenomen in die 220 miljoen euro? Kortom, meer vragen en aannames dan antwoorden. Zwak verhaal, ik geef op. Er is meer genius nodig.
Terug naar de basis. De Nationale Politie heeft een nieuw systeem nodig. We hebben de keuze uit 26 bestaande systemen, we fixeren de functionaliteit, we migreren slechts data en we sturen strak en centraal, al was het alleen maar omdat dat de nieuwe nationale politiecultuur gaat zijn. En de huidige korpsen werken mee, omdat ze er beter van worden. En omdat we geen overheidstijd en -geld willen verspillen. Daar past toch eerder een begroting bij van 40 miljoen euro binnen een sluitende business case? En waarom niet een begroting van 20 miljoen euro?
En laten we zo de hele lijst van “reusachtige” ICT-projecten van de overheid aanpakken. We maken het met zijn allen veel te groot en complex, en zijn volledig uit het oog verloren welk probleem we aan het oplossen zijn. Overdrijf de politieke context niet, maar benut die juist effectief. Ga niet de olifant opeten, maar vindt de oorspronkelijke mug!
Dit lijkt overigens een duivels dilemma, waarmee ik zelfs in mijn eigen voet lijk te schieten. De overheid is namelijk een belangrijke klant voor alle adviseurs en system integrators in Nederland. Als we al die “reusachtige” ICT-projecten van de overheid weten terug te brengen tot kleinere en eenvoudigere varianten, dan verdwijnt er nog meer van deze zichzelf al ombuigende markt. Met alle gevolgen van dien voor omzetten, werkgelegenheid, beurskoersen, etc. Ik zou het vooruitgang en geen dilemma willen noemen: we zijn de volgende volwassenheidsfase van de Nederlandse ICT-markt binnen getreden. En iedereen zal zijn plekje daarin weer opnieuw moeten verdienen, vanuit realisme. Ook deze zeepbel is geklapt. Ik gun oprecht iedereen veel succes in deze nieuwe werkelijkheid. Maar eerst: boter van ons hoofd!
In totaal kunnen zes verschillende typen data-analyse worden onderkend:
beschrijvende data-analyse;
verkennende data-analyse;
inferentiële data-analyse;
voorspellende data-analyse;
causale data-analyse;
mechanistische data-analyse.
In het Engels worden deze zes typen aangeduid als 1. Descriptive, 2. Explanatory, 3. Inferential, 4. Predictive, 5. Causal en 6. Mechanistic.
De meeste eenvoudige analyse is de beschrijvende data-analyse, waarvan het doel is om een samenvatting te geven van de measurements (metingen, waarden, elementen) in de dataset. Voorbeelden hiervan zijn het debiteurensaldo, de omzet, kosten en het aantal klanten.
Een verkennende data-analyse bouwt voort op de beschrijvende data-analyse. Hierbij wordt gezocht naar trends en correlaties, met als doel om hypotheses te formuleren maar nog niet om deze te bevestigen. Een voorbeeld van een dergelijke hypothese is dat debiteuren niet te hoog mogen zijn gewaardeerd.
Het derde type data-analyse, inferentiële data-analyse, is data-analyse gefocust op een gevonden trend, waarvan gevalideerd moet worden of deze trend ook standhoudt buiten de geselecteerde data (steekproef/deelwaarneming). Dit betekent - in termen van de controle - dat een trend is gevonden in de deelwaarneming en dat deze over de gehele dataset wordt getoetst. Dit is de meeste gebruikte analyse wereldwijd, die u zich misschien nog herinnert van de module statistiek (SPSS) in uw opleiding. Een voorbeeld hiervan is dat er een correlatie bestaat tussen omzet en debiteurenstand. Let op: er wordt in dit geval alleen een correlatie aangetoond, maar (nog) geen casueel verband.
De vierde vorm van data-analyse is het voorspellen van een waarde in de toekomst op basis van data (predictive analytics). In dit geval kan de vraag zijn: voorspel de debiteurenstand over zes maanden. Predictive analytics laat puur de voorspellingen zien, maar beschrijft niet waarom de voorspelling werkt.
Een causale data-analyse is gericht op het vinden van de relaties tussen twee metingen. Dit betekent dat wanneer je één meting verandert, je aan kunt geven wat dit gemiddelde voor een andere meting betekent. Bijvoorbeeld: hoe hoger de omzet, hoe hoger de debiteurenstand. Deze analyse laat - gegeven een bepaalde relatie - de gemiddelde impact van de wijziging van de ene meting op de andere zien.
De laatste vorm van data-analyse is de mechanistische data-analyse. Deze vorm van data-analyse zoekt ook naar het effect van één meting op een andere meting. Het verschil met een causale data-analyse is dat een mechanistische analyse zoekt naar hoe het aanpassen van één meting altijd en zeer specifiek leidt tot een voorspelbaar gedrag in de andere meting. Een voorbeeld hiervan - van buiten de accountancy - is hoe het aanpassen van de vleugels van een vliegtuig leidt tot minder weerstand. In de financiële wereld kan gedacht worden aan de harde oorzaak-gevolgrelatie tussen verhoging van het rentepercentage en verhoging van de post rente in de winst- en verliesrekening.
Carolien Kars en Hans Evers beschrijven in het Praktijkboek Procesmanagement hoe je een procesarchitectuur kunt opstellen. Hierbij gaan ze ook in op bedrijfsfuncties. Uit de doelstellingen van een organisatie, is af te leiden welke bedrijfsfuncties nodig zijn om deze doelstellingen te bereiken.
Voor elk van de bedrijfsfuncties moet worden vastgesteld tot welke categorie ze behoren: (1) Primaire bedrijfsfucnties, (2) Ondersteunende bedrijfsfuncties of (3) Bestuurlijke bedrijfsfuncties.
Ten aanzien van de bestuurlijke functies stellen Kars en Evers dat deze de Plan-Do-Check-Act cyclus van Deming als basis: "Besturing komt op alle niveaus en over alle processen heen voor. Benoem dus zoveel mogelijk de besturende functies apart; het is verleidelijk om de activiteiten anders in het primaire proces te integreren. Dat is echter niet de bedoeling. Het levert processen op die moeilijk leesbaar zijn en waarbij het lastig is na te gaan waar men in het proces 'zit' tijdens de uitvoering ervan."
De functionele decompositie leidt tot een functioneel model van een een organisatie. Vervolgens kunnen de functies worden aan de hand van criteria geordend worden tot een proces. "Dat wil zeggen: ze worden als 'kralen' (functionele eenheden) aan een ketting (proces) geregen."
Volgens Kars en Evers kunnen bij het ordenen van functies drie criteria gebruikt worden: - logische samenhang - fysieke en organisatorische locatie van de procesuitvoering - distributiekanaal waarlangs de uitvoering plaatsvindt (waar vindt het klantcontact plaats?)
Een proces is volgens Kars en Evers dus altijd samengesteld uit functies:
De door Kars en Evers beschreven werkwijze is een voorbeeld van een functie-gebaseerde methode voor het ontwerpen van een proces-architectuur. Deze methode begint met het ontwerpen van een functiehiërarchie, waaruit vervolgens een proces-architectuur wordt afgeleid. Een functiehiërarchie beschrijft een hiërarchische decompositie van bedrijfsfuncties in meer gedetailleerde functies. waarbij een bedrijfsfunctie de capaciteit van een organisatie is om bepaalde activiteiten uit te voeren. Een voorbeeld is de inkoopfunctie, die bedrijven in staat stelt om goederen en diensten in te kopen.
In het artikel ICT-Applicaties rationaliseren: Kostenbesparing door portfoliobeheersing betoogt Gilbert Silvius dat zodra ict-budgetten onder druk staan, kortetermijn investeringen kunnen worden uitgesteld of afgeblazen, maar dat dit voor de middellange en lange termijn geen reële optie is: "Door niet meer te investeren in nieuwe ICT-applicaties voeg je geen nieuwe functionaliteit toe en neemt de waarde van ICT voor de organisatie door veroudering langzaam af."
Van beheer naar vernieuwing Silvius pleit voor een structurele oplossing gericht op het verlagen van de kosten van ICT-beheer om zo binnen een gelijkblijvend budget investeringsruimte 'terug te winnen'. Silvius baseert zich op Gartner die stelt dat de beheerkosten van ICT vaak bijna 90 procent van het ICT-budget in beslag nemen en dat dit percentage zou moeten worden teruggebracht naar 70 of 75.
Voor het drastisch terugdringen van de beheerkosten van uw ICT-applicaties heeft Silvius een stappenplan opgesteld bestaande uit vier fasen en twaalf stappen:
Fase 1. Inventarisatie
01 Systematisch positioneren 02 Indelen van applicaties 03 Meten van het aantal gebruikers 04 Inschatten van de kosten per applicatie
Fase 2. Rationalisatie
05 Laten vervallen van niet of nauwelijks gebruikte applicaties 06 Opheffen van verschillende versies van dezelfde applicatie 07 Verwijderen van 'dode' code in maatwerkapplicaties 08 Standaardiseren applicaties met gelijke functionaliteit
Fase 3. Consolidatie
09 Migreren van toepassingen met overlappende functionaliteit 10 Benutten van ongebruikte functionaliteit van bestaande standaardapplicaties 11 Optimaliseren van de gebruikte ICT-platforms 12 Dataoptimalisatie
Fase 4. Portfoliomanagement
Hieronder zullen de verschillende fasen/stappen kort worden toegelicht:
Fase 1. Inventarisatie Voorwaarde voor het daadwerkelijk kunnen rationaliseren en consolideren, is dat je inzicht en overzicht hebt over de in gebruik zijnde applicaties. De eerste stap is dan ook het inventariseren en onderzoeken van de relevante gegevens van het applicatielandschap.
01 Systematisch positioneren Een cruciale stap om te kunnen rationaliseren en/of consolideren - in de zin van het terugdringen van de functionele overlap - is het systematisch positioneren van de functionaliteit van alle geïdentificeerde applicaties.
02 Indelen van applicaties Voor het systematisch inventariseren van functionaliteit is een ‘raamwerk’ nodig van mogelijke functionaliteit. Hierbij is het niet genoeg te kijken naar welk bedrijfsproces een applicatie ondersteunt. Applicaties kunnen namelijk generiek worden gebruikt en uit het ondersteunde bedrijfsproces blijkt niet altijd duidelijk de aarde van de functionaliteit van de applicatie.
03 Meten van het aantal gebruikers Een volgende inventarisatiestap is het meten van het aantal gebruikers van de verschillende applicaties.
04 Inschatten van de kosten per applicatie Voor elke applicaties is het nodig de kosten van het gebruik en beheer te meten of in te schatten. Hierbij moet worden gelet op zowel de directe kosten van een applicatie (licenties, onderhoudscontracten, dedicated medewerkers en dedicated infrastructuur) als de indirecte kosten (organisatorische kosten, zoals de helpdesk, en kosten van het netwerk en de werkstations).
Fase 2. Rationalisatie
Na de inventarisatie-fase helpen vier stappen bij het rationaliseren van de applicatieportfolio.
05 Laten vervallen van niet of nauwelijks gebruikte applicaties Op basis van het aantal gebruikers is het mogelijk te signaleren óf er applicaties voorkomen zónder gebruikers. Als het gebruik niet meer van toepassing is, kun je de autorisatie van de applicatie verwijderen en, na een bepaalde wachttijd, de applicatie zelf. Ook van applicaties die slechts een zeer beperkt gebruik kennen, kunt u dit gebruik ter discussie stellen.
06 Opheffen van verschillende versies van dezelfde applicatie Als er verschillende versies voorkomen van dezelfde softwareproducten voor, kan mogelijk een deel van de versies worden opgeheven.
07 Verwijderen van 'dode' code in maatwerkapplicaties Binnen maatwerkapplicaties komt na jaren van onderhoud en wijzigingen vaak nietgebruikte regelcode voor. Deze ‘dode’ code vormt een onnodige ballast in het draaien en onderhouden van de applicatie. Bij het opsporen van niet-gebruikte code kan gebruik worden gemaakt van ondersteunende softwaretools.
08 Standaardiseren applicaties met gelijke functionaliteit Bij het standaardiseren van specialistische toepassingen geldt dat gebruikers soms enige concessie zullen moeten doen aan de functionaliteit. Bij de standaardisatie naar een van de toepassingen dient u speciale aandacht te schenken aan macro’s. Migratie hiervan is veelal niet mogelijk, waardoor ze opnieuw zullen moeten worden gemaakt.
Fase 3. Consolidatie
Bij consolidatie zijn er geen quick wins meer te behalen en moeten er soms compromissen worden gesloten op het gebied van functionaliteit.
09 Migreren van toepassingen met overlappende functionaliteit Dankzij de geïnventariseerde functionaliteit van de applicaties is het mogelijk (gedeeltelijk) overlappende functionaliteit te onderkennen. Voor deze functionaliteit moet de vraag worden gesteld of alle applicaties noodzakelijk zijn of dat één applicatie de rol van de andere(n) kan overnemen. Hierbij is het onvermijdelijk dat de business soms iets aan functionaliteit moet inleveren.
10 Benutten van ongebruikte functionaliteit van bestaande standaardapplicaties Het komt voor dat functionaliteit van een standaardapplicatie niet geheel in gebruik is genomen. In sommige gevallen is het denkbaar dat de kosten van licenties beter kunnen worden uitgenut als de functionaliteit van de reeds aanwezige standaardapplicaties wordt verbreed.
11 Optimaliseren van de gebruikte ICT-platforms Concentreer en standaardiseer de ontwikkeling en het beheer van applicaties op een beperkt aantal platforms en benut de mogelijkheden van deze platforms optimaal.
12 Dataoptimalisatie Gegevens worden vaak in meerdere applicaties gebruikt, zodat wijzigingen in deze gegevens in meerdere bestanden doorgevoerd moeten worden. Naast inefficiëntie creëert deze dubbele vastlegging ook het risico van verschillen tussen de gegevens en fouten. Het is vaak complex om de verschillende bestanden te vervangen door een enkelvoudig vastgelegd bestand. Een andere oplossing is een enkelvoudig ‘mutatiepunt’ te creëren in de vorm van enkelvoudige bronbestanden waaruit de verschillende applicaties kunnen putten.
Fase 4. Portfoliomanagement
De eerste drie fasen inventarisatie, rationalisatie en consolidatie zijn nodig voor het ‘opschonen’ van de in gebruik zijnde applicaties. Het inrichten van een proces voor applicatieportfoliomanagementproces is nodig om te borgen dat de resultaten geen eenmalige actie zijn. 'Portfoliomanagement' is een instrument afkomstig uit de financiële wereld dat bruikbaar is om - ondanks de grote verscheidenheid aan applicaties - het totaal aan applicaties overzichtelijk en beheerbaar te maken.
Nadat het onderkennen van de verschillende rationalisatie- en consolidatiemogelijkheden, komt de fase waarin je de besparingen ook daadwerkelijk gaat realiseren. Hiervoor is het nodig projecten in te plannen en uit te voeren. Omdat met name de vervolgprojecten op het vlak van de consolidatie van toepassingen complex en ingrijpend kunnen zijn, moet je prioriteiten stellen tussen de verschillende voorstellen op basis van:
de kosten van de projecten en de te behalen kostenbesparingen;
de snelheid waarmee u de besparingen kunt realiseren;
de risico’s en afhankelijkheden van de verschillende projecten;
het verandervermogen van de organisatie.
De afwegingen die u maakt bij het samenstellen van de totale projectenkalender vormen het projectportfoliomanagementproces. Binnen dit proces worden de bedrijfsmiddelen afgestemd op de de ontwikkelingen in de organisatie en technologie. Het proces resulteer in een aantal gewenste veranderingen in de bedrijfsmiddelen die afgewogen moeten worden in onderlinge samenhang gegeven de prioriteiten, bijvoorbeeld op basis van rendement of noodzaak, en beperkingen van de organisatie, bijvoorbeeld budget of verandervermogen. Het inrichten van de portfoliomanagementprocessen en -procedures zorgt voor een structureel optimaal kostenniveau in plaats van het ad hoc realiseren van eenmalige besparingen.
Volgens Silvius is het applicatieportfoliomanagementproces een onderdeel van het assetportfoliomanagement en kan op onderstaande wijze de samenhang tussen de verschillende portfoliomanagementbegrippen worden weergegeven:
De rationalisatie- en consolidatieprojecten resulteren - aldus Silvius - onder andere in de volgende kostenbesparingen:
afname licentiekosten;
afname kosten applicatiebeheer;
afname kosten infrastructuurbeheer;
vrijkomende servercapaciteit.
Het Silvius' stappenplan helpt om binnen de organisatie enkele tientallen rationalisatie- en consolidatiemogelijkheden identificeren die gezamenlijk kunnen leiden tot 15 tot wel 25 procent lagere kosten voor ICT-beheer. Volgens Silvius kan met de relatief eenvoudig uit te voeren rationalisatieactiviteiten al circa tien tot vijftien procent van de in gebruik zijnde applicaties worden geschrapt. De hiermee samenhangende kostenbesparing ligt vermoedelijk lager, tussen vijf en tien procent. Naar verwachting kun je in de consolidatiefase nog een aanvullende tien tot vijftien procent besparen op de kosten van het applicatiebeheer realiseren.
Wilbert Teunissen (Sogeti) definieert functioneel beheer als het vak(gebied) dat ervoor zorgt dat de functionaliteit van informatiesystemen en de daaraan gekoppelde IT-diensten blijven aansluiten bij de (steeds veranderende) behoeften van de gebruikers.
Functioneel beheer heeft volgens Teunissen vier doelstellingen:
Zorgen voor een ongestoord en optimaal gebruik van de bestaande informatiesystemen.
Vertalen van gebruikerswensen en -eisen (businesswensen) in noodzakelijke wijzigingen.
Borgen van gebruikers- en beheereisen bij onderhoud en ontwikkeling.
Het geruisloos in gebruik en beheer nemen van aangepaste en nieuwe functionaliteit.
Volgens Teunissen zijn er zes succesfactoren van belang bij het inrichten en uitvoeren van functioneel beheer:
Informatiedomein: beschrijf het verantwoordelijkheidsgebied van functioneel beheer en geef daarbinnen inzicht in de relatie tussen bedrijfsprocessen, informatiesystemen, gegevens en IT-diensten. Informatie waarbij architectuur een belangrijke rol speelt.
Processen: benoem de activiteiten die functioneel beheer moet uitvoeren in relatie tot de business als opdrachtgever en IT als opdrachtnemer op basis van de producten en diensten die moeten worden geleverd en de eisen die daaraan worden gesteld.
Organisatie: bepaal de wijze waarop functioneel beheer georganiseerd moet worden: decentraal of centraal. Dit is vooral afhankelijk van het informatiedomein dat bestaat uit afdelingsafhankelijke of bedrijfsoverstijgende systemen.
Medewerkers: onderken de diverse niveaus van functioneel beheer en koppel daaraan de benodigde kennis en competenties. Kennis van zowel de bedrijfsprocessen als de (relatie tussen) informatiesystemen is essentieel.
Communicatie (samenwerking): stem de uit te voeren procesactiviteiten af met gebruikers en IT-beheerders. Formaliseer de samenwerking in een communicatie- en overlegstructuur.
Sturing: de manager van functioneel beheer stuurt op de realisatie van de genoemde doelstellingen en het efficiënt uitvoeren van de activiteiten. Daarbij worstelt hij met de spagaat tussen beheer en projecten. Alleen met helder inzicht in de verantwoordelijkheden en tijdsbesteding kan hij hieruit komen. Daarbij hoort ook een duidelijk besluitvormingsproces ten aanzien van wijzigingen en projecten.
Teunissen onderkent vier niveaus van functioneel beheer:
Functioneel beheer vervult binnen en organisatie een belangrijke rol als het gaat om grip te houden op kosten en kwaliteit van IT-diensten. Een functioneel beheerder is in staat gebruikersbehoeften en wensen te kanaliseren, te beoordelen en te prioriteren en heeft kennis om de consequenties van wijzigingen in bedrijfsprocessen, producten of diensten voor de bestaande informatievoorziening te overzien. Dit laatste wordt steeds belangrijk omdat met de vervanging van maatwerk door standaardpakketten vaak gekozen wordt voor geïntegreerde, afdelingsoverstijgende (ERP-)oplossingen. De impact van wijzigingen wordt daarmee groter en de risico's nemen navenant toe.
Een functioneel beheerder is een vakman die weet wat zijn verantwoordelijkheden zijn en met welk doel hij zijn activiteiten uitvoert. Hij heeft uitgebreide kennis van het dagelijkse werk van de gebruikers en hoe zij daarbij de ondersteunende informatiesystemen toepassen. Wijzigingen en projecten zorgen voor veranderingen in de stabiele omgeving; de functioneel beheerder weet de risico's te beperken en de eindgebruiker te begeleiden naar de nieuwe situatie. In dat proces heeft de functioneel beheerder te maken met vele partijen waarvan hij de belangen moet behartigen en waarmee hij moet samenwerken (...) Met functioneel beheer krijgt u grip op de kwaliteit van uw informatievoorziening en verhoogt u de gebruikerstevredenheid aanzienlijk.
In zijn presentatie Lean & Agile op slideshare.net deelt Claudio Perrone (@agilesensei) zijn inzichten op het gebied van het combineren van Lean en Agile met softwareontwikkeling.
Volgens Claudio Perrone zijn zeven principes van Lean thinking die cruciaal zijn voor het ontwikkelen van software:
Elimineren van verspilling (waste)
Inbouwen van kwaliteit
Creëren van kennis
Weifelen (defer) met commitment
Snel leveren
Respect voor mensen
Optimaliseren van het geheel
Bron: presentatie Lean & Agile op slideshare.net, Claudio Perrone
Joe Justice (Wikispeed) legt in zijn Ted-talk (26-12-2011) uit hoe de toepassing van Agile, Lean en Scrum binnen de auto-industrie revolutionaire resultaten oplevert bij het ontwikkelen van een '100 miles per gallon'-auto.
Mocht je écht de smaak te pakken krijgen, dan bekijk dan het uitgebreidere verhaal van Joe Justice's presentatie (1:31:13) op de Scrum Gathering in Seattle.
Informatiemanagement
