Applicatie rationalisatie in 10 stappen
Applicatie rationalisatie is het doelmatig inzetten van applicaties, zorgen dat de informatievoorziening in applicaties de bedrijfsvoering op een effectieve en efficiënte wijze ondersteunt.
Bij applicatie rationalisatie richt men zich op het organiseren van het applicatielandschap, waar gekeken wordt naar functionaliteiten die de applicaties aanbieden. Applicaties die dezelfde functionaliteit aanbieden moeten worden aangepakt, zodat dubbele functionaliteit vermeden wordt. Hetzelfde geldt voor dubbele interfaces tussen de applicaties.
Business case
Veelal wordt gedacht dat applicatie rationalisatie leidt tot kostenbesparing. Dat is niet altijd zo. De besparing wordt vaak overschat, en de kosten om tot die besparing te komen, worden onderschat. Besparingen zitten in kosten van beheer: minder applicaties betekent minder licenties, servers waar de applicaties op moeten draaien, minder beheerders. Het grootste deel van die kosten zit in “minder beheerders” en mensen feitelijk ontslaan gebeurt niet vaak. Veelal geven die beheerders zodra ze tijd krijgen, een andere invulling aan werkzaamheden: dingen die ook moeten gebeuren, maar bleven liggen, zoals gebruikersondersteuning of informatieanalyse. Ook goede doelstellingen, maar daarvan wordt het niet goedkoper maar beter. Soms is er eindelijk tijd voor nieuwe applicaties, en wordt het geheel duurder. Het is belangrijk hier vooraf een keuze in te maken: de kennis van de beheerders is cruciaal voor een succesvolle rationalisatie. Als iemand gevraagd wordt zijn eigen functie overbodig te maken (kostenbesparing), is de medewerking niet altijd even overtuigend. Aan kwaliteitsverbetering werken mensen eerder vol enthousiasme mee.
Een ander, en minstens zo belangrijk argument voor rationalisatie, is de versimpeling van het landschap van applicaties. Het wordt minder complex. Dus heb je meer overzicht, kun je sneller impact analyses doorvoeren en keuzes maken. Het betekent meer wendbaarheid, verbeterde aanpasbaarheid, verkorte doorlooptijden van changes en sneller nieuwe ontwikkelingen. Dat is veelal lastiger in cijfers uit te drukken, maar rekenmodellen zijn zeker te maken.
Indicaties voor een positieve business case:
Een 10 stappen plan
Stap 1
Straks is het landschap rationeel; en wat dan? Dat wil je het graag rationeel houden. Dus het allereerste om te doen, is het neerzetten van een structuur / besturing om het landschap rationeel te houden. Beginnen met het eindbeeld voor ogen, dat helpt onderweg enorm met het maken van keuzes.
Zet de uitgangspunten op een rij:
Gebruik het POTI model om het eindbeeld te schetsen. Meer informatie over het POTI model, zie methode programmamanagement MSP (Managing Successfull Programs).
Voorbeelden van onderwerpen in het beleid rondom informatievoorzieningen en ICT:
Begin de inzichten keuzes in de organisatie te implementeren en start parallel stap 2.
Stap 2
Maak een basale inventarisatie van het applicatielandschap en leg per applicatie de volgende informatie vast:
Applicaties zijn ook de “eigen maaksels” in bijvoorbeeld Excel die de financiële administratie heeft ontwikkeld en elke maand gebruikt om de rapportage voor de directie te produceren.
Benoem iemand die tot taak heeft deze basale inventarisatie actueel te houden. Publiceer elke maand de laatste versie.
Stap 3
Bepaal per applicatie de “business value” (waarde tussen 1 – 9) door de scores van noodzaak en gebruik met elkaar te vermenigvuldigen.
Scoor noodzaak
en scoor gebruik
Bedenk hoe deze scores te geven: door het de business te vragen, door een “expert judgement” vanuit IT te doen. Denk na of een toevallige gebruiker niet het verkeerde beeld kan doen ontstaan.
Soms ontstaat het beeld in iteraties. Laat altijd de business eigenaar de score “aftekenen”.
Stap 4
Bepaal de kwaliteit per applicatie (1 – 9 punten), door elke van de onderstaande vragen met ja of nee te beantwoorden; “ja” betekent 1 punt.
Functionele kwaliteit:
Technische kwaliteit:
Laat de verantwoordelijk beheerder de uiteindelijke score “aftekenen”.
Stap 5
Plot alle applicaties in een grafiek op basis van de scores in stap 3 en 4.
Applicatie rationalisatie is het doelmatig inzetten van applicaties, zorgen dat de informatievoorziening in applicaties de bedrijfsvoering op een effectieve en efficiënte wijze ondersteunt.
Bij applicatie rationalisatie richt men zich op het organiseren van het applicatielandschap, waar gekeken wordt naar functionaliteiten die de applicaties aanbieden. Applicaties die dezelfde functionaliteit aanbieden moeten worden aangepakt, zodat dubbele functionaliteit vermeden wordt. Hetzelfde geldt voor dubbele interfaces tussen de applicaties.
Business case
Veelal wordt gedacht dat applicatie rationalisatie leidt tot kostenbesparing. Dat is niet altijd zo. De besparing wordt vaak overschat, en de kosten om tot die besparing te komen, worden onderschat. Besparingen zitten in kosten van beheer: minder applicaties betekent minder licenties, servers waar de applicaties op moeten draaien, minder beheerders. Het grootste deel van die kosten zit in “minder beheerders” en mensen feitelijk ontslaan gebeurt niet vaak. Veelal geven die beheerders zodra ze tijd krijgen, een andere invulling aan werkzaamheden: dingen die ook moeten gebeuren, maar bleven liggen, zoals gebruikersondersteuning of informatieanalyse. Ook goede doelstellingen, maar daarvan wordt het niet goedkoper maar beter. Soms is er eindelijk tijd voor nieuwe applicaties, en wordt het geheel duurder. Het is belangrijk hier vooraf een keuze in te maken: de kennis van de beheerders is cruciaal voor een succesvolle rationalisatie. Als iemand gevraagd wordt zijn eigen functie overbodig te maken (kostenbesparing), is de medewerking niet altijd even overtuigend. Aan kwaliteitsverbetering werken mensen eerder vol enthousiasme mee.
Een ander, en minstens zo belangrijk argument voor rationalisatie, is de versimpeling van het landschap van applicaties. Het wordt minder complex. Dus heb je meer overzicht, kun je sneller impact analyses doorvoeren en keuzes maken. Het betekent meer wendbaarheid, verbeterde aanpasbaarheid, verkorte doorlooptijden van changes en sneller nieuwe ontwikkelingen. Dat is veelal lastiger in cijfers uit te drukken, maar rekenmodellen zijn zeker te maken.
Indicaties voor een positieve business case:
- veel applicaties met relatief weinig gebruikers
- veel dezelfde functionaliteit in meerdere applicaties
- veel interfaces
- veel dataverzamelingen
- complex landschap zonder overzicht
- langere testtrajecten
- lange doorlooptijd van wensen vanuit de business
Een 10 stappen plan
Stap 1
Straks is het landschap rationeel; en wat dan? Dat wil je het graag rationeel houden. Dus het allereerste om te doen, is het neerzetten van een structuur / besturing om het landschap rationeel te houden. Beginnen met het eindbeeld voor ogen, dat helpt onderweg enorm met het maken van keuzes.
Zet de uitgangspunten op een rij:
- Bepaal criteria: wat is een rationeel landschap? Wanneer is het klaar?
- Geef “werken onder architectuur” vorm
- Kies overzicht boven detaillering; neem een iteratieve aanpak; blijf pragmatisch en voorkom “sterven in schoonheid”
- Beschrijf het beleid rondom informatievoorziening en ICT: hoe komt de business van wens tot realisatie?
- Betalen voor gebruik: breng het budget naar de business, dat zorgt voor betrokkenheid
- Richt eigenaarschap bij de business in; borg de doelstelling van rationalisatie in targets van de business
- Richt “applicatie portfolio management” of een soortgelijke variant in
- Stel een roadmap voor het landschap en per applicatie op en zorg dat zowel de business als IT ontwikkelingen op de roadmap terecht komen
Gebruik het POTI model om het eindbeeld te schetsen. Meer informatie over het POTI model, zie methode programmamanagement MSP (Managing Successfull Programs).
Voorbeelden van onderwerpen in het beleid rondom informatievoorzieningen en ICT:
- Standaard applicaties i.p.v. maatwerk; andere make-or-buy beslissingen
- Geen dubbele functionaliteit
- Authentieke bronnen
- Eenduidige definities
- Geen dubbele interfaces
Begin de inzichten keuzes in de organisatie te implementeren en start parallel stap 2.
Stap 2
Maak een basale inventarisatie van het applicatielandschap en leg per applicatie de volgende informatie vast:
- Nummer / ID
- Naam
- Eigenaar in de business
- Aantallen gebruikers
- Beheerder
- Leverancier extern
Applicaties zijn ook de “eigen maaksels” in bijvoorbeeld Excel die de financiële administratie heeft ontwikkeld en elke maand gebruikt om de rapportage voor de directie te produceren.
Benoem iemand die tot taak heeft deze basale inventarisatie actueel te houden. Publiceer elke maand de laatste versie.
Stap 3
Bepaal per applicatie de “business value” (waarde tussen 1 – 9) door de scores van noodzaak en gebruik met elkaar te vermenigvuldigen.
Scoor noodzaak
- Zonder deze applicatie kan ik mijn werk niet doen (3 punten)
- Zonder deze applicatie kan ik mijn werk minder goed doen (2 punten)
- Zonder deze applicatie kan ik ook redelijk mijn werk doen (1 punt)
en scoor gebruik
- Deze applicatie wordt door minstens 50% van de gebruikers elke werkdag gebruikt (3 punten)
- Deze applicatie wordt door minstens 25% van de gebruikers elke week gebruikt (2 punten)
- Deze applicatie wordt beperkt gebruikt (1 punt)
Bedenk hoe deze scores te geven: door het de business te vragen, door een “expert judgement” vanuit IT te doen. Denk na of een toevallige gebruiker niet het verkeerde beeld kan doen ontstaan.
Soms ontstaat het beeld in iteraties. Laat altijd de business eigenaar de score “aftekenen”.
Stap 4
Bepaal de kwaliteit per applicatie (1 – 9 punten), door elke van de onderstaande vragen met ja of nee te beantwoorden; “ja” betekent 1 punt.
Functionele kwaliteit:
- Beschikbaarheid; kan de applicatie altijd gebruikt worden?
- Integriteit, betrouwbaarheid, juistheid; werkt de applicatie altijd op de juiste manier
- Stabiliteit
- Volledigheid, dekt de functionaliteit de business behoefte
- Herstelkwaliteit; als het mis gaat, kan dan snel hersteld worden met behoud van gegevens etc?
Technische kwaliteit:
- Aanpasbaarheid
- Testbaarheid
- Koppelbaarheid / is integratie in het landschap mogelijk
- Beveiliging op orde
Laat de verantwoordelijk beheerder de uiteindelijke score “aftekenen”.
Stap 5
Plot alle applicaties in een grafiek op basis van de scores in stap 3 en 4.
Stap 6
Voer de stappen 2 – 5 ook uit vanuit de invalshoeken “interface” en “data-verzameling”. De behoefte tot rationaliseren zit niet altijd in aantallen applicaties, maar in interfaces en brongegevens. Soms is de snelste weg naar voren niet te beginnen aan de “voorkant” met de applicaties, maar aan de achterkant, met wegwerken dubbele interfaces, verbeteren gegevensverzamelingen, enzovoort.
Stap 7
Stel aanpakken op voor “uitzetten”, “verbeteren”, “doorontwikkelen” en “instandhouden”. Wat ga je in elk van die aanpakken wel en niet doen? Stem de aanpakken af met de business.
De vastgestelde aanpakken hebben consequenties: te regelen in projecten. Uit te voeren door de staande organisatie of door een aparte projectorganisatie. Maak die keuze en vertaal de aanpakken in projecten. Hou de projecten zo klein en pragmatisch mogelijk. Niet elke aanpak is per definitie 1 project.
Maak een lijst met voorgenomen projecten en zet die in volgorde.
Stap 8
Start projecten. Niet allemaal tegelijk, maar 1 voor 1. Zodra een project loopt, kan de volgende starten, dakpansgewijs, totdat de grenzen van wat gelijktijdig kan lopen zijn bereikt. En als het dan sneller moet, kijk dan hoe de beperkingen kunnen worden weggenomen, doe dat, er versnel daarna de projecten (niet andersom).
Begin sowieso het project “uitzetten”: ook al zit daar niet altijd het business belang of zitten daar niet de kosten, het is een makkelijke plek om te beginnen, ruimt op, toont beweging, en geeft “lessons learned” voor de applicaties / interfaces / dataverzamelingen die belangrijker zijn.
Stap 9
Indien daar behoefte aan is, werk de inventarisatie van stap 2 verder uit. Houd meer gegevens per applicatie bij. Bijvoorbeeld, deel applicaties in naar de verschillende bedrijfsprocessen die ze ondersteunen. Label de applicaties naar de aard van de processen (strategisch / tactisch / operationeel) of de aard van het gebruik (dagelijkse operatie / verandering in de organisatie / innovatie).
Alternatief, deel de applicaties in naargelang het gewenste serviceniveau (7x24 ondersteuning en “always on” of 5x8 met “next business day”).
Alternatief, ga de diepte in met onderwerpen als “architectuur” en “decompositie”. Bedenk wel of je dit echt wilt, wat de te bereiken voordelen zijn. Probeer deze vooraf te becijferen.
Het applicatielandschap kan bijvoorbeeld ook verder worden gerationaliseerd door uniforme keuzes te maken. Bijvoorbeeld, er wordt niet meer naar een enkele applicatie gekeken, maar naar het landschap van applicaties, en herbruikbare bouwblokken binnen applicaties.
Bijvoorbeeld:
Ook hier geldt: keep it stupid simple. Niet alles hoeft tegelijk en het betere is de vijand van het goede.
Stap 10
Richt ondersteunende besturing in, passend bij de organisatie, en passend bij de ambitie.
Bijvoorbeeld, rondom vraag naar en aanbod van informatie binnen de organisatie; welke wensen leven bij de business, hoe worden die geventileerd en vertaald in concrete vragen? Hoe wordt dat omgezet in ontwikkeling en hoe worden leveranciers aangestuurd? (demand / supply management).
Immers, als je het voorbrengingsproces hoe applicaties “ontstaan” ook niet parallel aanpakt en bestuurt, ruim je misschien aan de achterkant het applicatielandschap prachtig op, maar mis je de vernieuwing aan de voorkant.
Voer de stappen 2 – 5 ook uit vanuit de invalshoeken “interface” en “data-verzameling”. De behoefte tot rationaliseren zit niet altijd in aantallen applicaties, maar in interfaces en brongegevens. Soms is de snelste weg naar voren niet te beginnen aan de “voorkant” met de applicaties, maar aan de achterkant, met wegwerken dubbele interfaces, verbeteren gegevensverzamelingen, enzovoort.
Stap 7
Stel aanpakken op voor “uitzetten”, “verbeteren”, “doorontwikkelen” en “instandhouden”. Wat ga je in elk van die aanpakken wel en niet doen? Stem de aanpakken af met de business.
De vastgestelde aanpakken hebben consequenties: te regelen in projecten. Uit te voeren door de staande organisatie of door een aparte projectorganisatie. Maak die keuze en vertaal de aanpakken in projecten. Hou de projecten zo klein en pragmatisch mogelijk. Niet elke aanpak is per definitie 1 project.
Maak een lijst met voorgenomen projecten en zet die in volgorde.
Stap 8
Start projecten. Niet allemaal tegelijk, maar 1 voor 1. Zodra een project loopt, kan de volgende starten, dakpansgewijs, totdat de grenzen van wat gelijktijdig kan lopen zijn bereikt. En als het dan sneller moet, kijk dan hoe de beperkingen kunnen worden weggenomen, doe dat, er versnel daarna de projecten (niet andersom).
Begin sowieso het project “uitzetten”: ook al zit daar niet altijd het business belang of zitten daar niet de kosten, het is een makkelijke plek om te beginnen, ruimt op, toont beweging, en geeft “lessons learned” voor de applicaties / interfaces / dataverzamelingen die belangrijker zijn.
Stap 9
Indien daar behoefte aan is, werk de inventarisatie van stap 2 verder uit. Houd meer gegevens per applicatie bij. Bijvoorbeeld, deel applicaties in naar de verschillende bedrijfsprocessen die ze ondersteunen. Label de applicaties naar de aard van de processen (strategisch / tactisch / operationeel) of de aard van het gebruik (dagelijkse operatie / verandering in de organisatie / innovatie).
Alternatief, deel de applicaties in naargelang het gewenste serviceniveau (7x24 ondersteuning en “always on” of 5x8 met “next business day”).
Alternatief, ga de diepte in met onderwerpen als “architectuur” en “decompositie”. Bedenk wel of je dit echt wilt, wat de te bereiken voordelen zijn. Probeer deze vooraf te becijferen.
Het applicatielandschap kan bijvoorbeeld ook verder worden gerationaliseerd door uniforme keuzes te maken. Bijvoorbeeld, er wordt niet meer naar een enkele applicatie gekeken, maar naar het landschap van applicaties, en herbruikbare bouwblokken binnen applicaties.
Bijvoorbeeld:
- Communicatielaag; apparaten / media t.b.v. communicatie
- Presentatielaag; portals etc
- Prestatielaag à business processen à applicaties zoals gebruikers ze ervaren
- Serviceslaag à herbruikbare functionele blokken
- Applicatielaag à functionaliteit en data
- Infrastructuur à netwerken, computers
Ook hier geldt: keep it stupid simple. Niet alles hoeft tegelijk en het betere is de vijand van het goede.
Stap 10
Richt ondersteunende besturing in, passend bij de organisatie, en passend bij de ambitie.
Bijvoorbeeld, rondom vraag naar en aanbod van informatie binnen de organisatie; welke wensen leven bij de business, hoe worden die geventileerd en vertaald in concrete vragen? Hoe wordt dat omgezet in ontwikkeling en hoe worden leveranciers aangestuurd? (demand / supply management).
Immers, als je het voorbrengingsproces hoe applicaties “ontstaan” ook niet parallel aanpakt en bestuurt, ruim je misschien aan de achterkant het applicatielandschap prachtig op, maar mis je de vernieuwing aan de voorkant.