Het Kwaliteits Instituut Nederlandse Gemeenten (KING) beschrijft in de Handreiking KING: Applicatiesanering en contract management: ‘De basis op orde’ een aanpak voor het saneren van applicaties. King positioneert ‘applicatiesanering’ in een breder perspectief. Immers, ook een gesaneerd applicatielandschap moet onderhouden worden. Het gestructureerd werken en sturen met een (applicatie)portfolio is hiervoor een goed instrument.

Volgens King bied applicatiesanering een oplossing de volgende problemen:

• Beheerskosten worden structureel lager
• Focus op het uitzetten oude applicaties (incl. bijbehorende contracten)
• Alignement met strategie visie van de organisatie
• Actieve sturing op een eenvoudig en overzichtelijk applicatielandschap.
• Managen spanning tussen korte termijn business en lange termijn IT doelstellingen
• Veel sneller en beter aanpassingen aan de organisatie kunnen doen
• Kosten van upgrades zijn lager
• Hoeveelheid benodigde kennis neemt af (complexiteitsreductie)
• Eén applicatieregistratie, inzicht in kosten, eigenaarschap, functionele (!) en technische kwaliteit

Voordat zinvol gesaneerd kan worden is het nodig om een beeld te hebben van de richting waar de organisatie heen wil groeien, vastgelegd in architectuurprincipes.

King's aanpak bestaat uit vier stappen. De eerste 2 stappen zijn gericht op het creëren van inzicht en overzicht, terwijl de derde stap bestaat uit het consolideren en harmoniseren. Vervolgens ligt de weg vrij voor de optionele vierde stap, het structureel inregelen van applicatieportfoliomanagement.

1. Inventariseren: het resultaat van de inventarisatie is een compleet overzicht van het applicatielandschap. Het overzicht geeft aan welke de organisatie allemaal heeft (gekocht, geïnstalleerd, in gebruik, in beheer) en wat het werkelijke gebruik is van de applicaties (welke processen, welke functionaliteit, wie, waar, wanneer, hoe tevreden is de gebruiker).

2. Analyseren: de stap van de analyse is erop gericht een globaal beeld te krijgen van de ‘levensvatbaarheid’ van de aanwezige applicaties, als hulpmiddel om verder besluitvorming te ondersteunen..

3. Kiezen en realiseren van de sanering: op basis van de inventarisatie en de analyse kunnen keuzes worden gemaakt over de toekomst van de applicatie ('bevriezen', uitfaseren mét en zonder (gedeeltelijke) vervanging) en kan de daadwerkelijke implementatie van deze strategie in gang worden gezet.

4. Inrichten applicatieportfoliomanagement: voor structureel applicatieportfoliomanagement, is een duidelijke set van criteria nodig waaraan applicaties moeten voldoen om binnen een applicatielandschap te (blijven) bestaan. Deze criteria zullen uiteindelijk een afgeleide zijn van bijvoorbeeld randvoorwaarden en uitgangspunten uit een ICT beleidsplan of een set van architectuurprincipes.

Ter ondersteuning van de eerste twee fasen beschrijft KING (a) een inventarisatiekader en een (b) analysekader, waarmee de inventarisatie en analyse kunnen worden uitgevoerd.

Ad (1) Inventariseren
De inventarisatie moet antwoord geven op onderstaande vragen:

• Waar zitten witte, grijze of zwarte vlekken in procesondersteuning? Hoe erg is dit voor de organisatie?
• Welke applicaties worden niet gebruikt worden of slechts deels;
• Waar zitten doublures zitten in procesondersteuning met applicaties (incl. impact)?
• Welke is al beschikbaar is en kan hergebruikt worden?

KING beschrijft een zgn. inventarisatiekader waarmee per applicatie de relevante aspecten van applicaties kunnen worden 'gescoord':

Architectuur

• Applicatie: naam van de applicatie
• Korte omschrijving: korte omschrijving
• Processen: bedrijfsprocessen/functie waar applicatie een relatie mee heeft.
• Applicaties/koppelingen: (andere) applicaties waar applicatie een relatie mee heeft. Koppeling standaard of niet?
• Type: soort applicatie (King onderkent: business applicaties, kantoorautomatisering of tool/freeware/zelfbouw).

Applicatie

• Leverancier: leverancier van de applicatie
• Contract: soort contract
• Looptijd contract: datum tot hoe lang contract loopt; of datum waarop het contract is afgesloten.
• Opzegtermijn contact: bepalingen mbt opzegtermijn in contract
• Contract opgezegd: ja/nee
• Contract opgezegd: per datum
• SLA Dienstverlening: indien applicatie behouden blijft is deze opgenomen in een SLA (pdc)

Operationeel

• Gebruikers: afdelingen/gebruikersgroepen die applicatie gebruiken

Ad (2) Analyseren
KING beschrijft ook een hulpmiddel voor het uitvoeren van de analyse, het zgn. analysekader:

Bedrijfsfactoren

• Operationeel belang: belang van de applicatie voor de huidige uitvoering (invloed op bedrijfsprocessen).
• Toekomstige behoeftes: bruikbaarheid van de applicatie in de toekomst irt strategische doelstellingen.
• Voldoet aan de huidige standaard: past de applicatie binnen de huidige ICT/bedrijfsstandaarden en architectuur.

Applicatiefactoren

• Support: in welke kan vanuit de huidige (IT) organisatie de applicatie worden ondersteund?
• Data: betrouwbaarheid, toekomstvastheid, veiligheid, directe/tijdige benaderbaarheid en nut voor de organisatie.
• Overlappende functionaliteit: mate waarin de door de applicatie geleverde functionaliteit uniek is en eventuele overlap met andere applicaties.

Technische factoren

• Integratie en afhankelijkheden: mate waarin applicatie eenvoudig integreerbaar is en/of er weinig afhankelijkheden zijn. Veel afhankelijkheden met andere systemen en/of applicaties bemoeilijken toekomstige upgrades en aanpassingen.
• Onderhoudbaarheid en ondersteuning: heeft de applicatie veel/vaak onderhoud nodig om bugs te repareren of zijn er weinig/ nooit problemen en vergt de applicatie daarmee weinig ondersteuning van de ICT organisatie?
• Architectuur & platform: hoe schaalbaar is de applicatie? Zijn er geen belemmeringen voor toekomstige uitbreiding, of is grootschalige aanpassing van de applicatie of onderliggende infrastructuur noodzakelijk. Is de applicatie ‘portable’ naar een ander platform?
• Technische ‘dekking’: past de applicatie goed binnen de huidige en toekomstige ICT infrastructuur.

Leverancier factoren

• Support: is de leverancier of distributeur/reseller in staat om nu en in de toekomst ondersteuning te bieden bij het opzetten en onderhouden van de applicatie?
• Strategie: is de strategie van de leverancier erop gericht, en is de leverancier goed in staat, om de applicatie verder te ontwikkelen en mee te gaan met toekomstige ontwikkelingen, of is de verwachting dat de leverancier de applicatieontwikkeling tot een minimum gaat beperken? Hierbij kan ook de levensvatbaarheid van een leverancier worden meegenomen.
• Prijs: is prijs per klant of prijs per afgenomen dienst mogelijk? Onderhoud betaald of onderhoud in contract.
• Markt: is er een aantrekkelijk alternatief in de markt (of bij een mogelijke samenwerkingspartner!) ontstaan die qua functionaliteit een set van applicaties kan vervangen?

Ad (3) Kiezen/realiseren
Applicatiesanering in het algemeen en het daadwerkelijk uitfaseren van applicaties in het bijzonder vraagt om lef. Het is gemakkelijk om iets wat niet of nauwelijks gebruikt wordt in stand te houden: niemand heeft er toch last van? Wat halen we niet allemaal overhoop als we een onderdeel willen opruimen. Bovendien zijn mensen gehecht aan bestaande zaken. Gebruikers zullen bijvoorbeeld niet met het verzoek komen om een applicatie te vervangen of uit te faseren. Ze zijn eraan gehecht en komen hoogstens met verzoeken tot wijzigingen. De reden om tóch aan de applicaties te saneren is omdat er anders nadelinge gevolgen optreden:

• Extra ICT beheerkosten
• Spaghetti architectuur
• Overlap in functionaliteiten
• Complexiteit bij toekomstige veranderingen

Ad (4) Inrichten applicatieportfoliomanagement
Applicatiesanering wordt vaak als ad hoc project opgestart. Niets mis mee, maar in dit project kan al een belangrijke basis worden gelegd voor structureel portfoliomanagement. KING omschrijft portfoliomanagement als een methode om applicaties, ICT-projecten en infrastructuur organisatiebreed te besturen en te beheren vanuit het oogpunt van:

• Het besparen op kosten voor licenties en beheer.
• Het reduceren van de complexiteit van de portfolio (bv licenties, dubbel beheer, koppelingen etc.);
• Het reduceren van de risico’s
• Het verbeteren van de performance
• Het verbeteren van de (ondersteuning van de) kwaliteit van dienstverlening

Portfoliomanagement komt in essentie neer op het 'centraal organiseren van de samenhang'. Voor het goed kunnen uitvoeren van het proces applicatieportfoliomanagement zijn volgens KING de onderstaande variabelen van belang en moeten voor deze aspecten 'spelregels' (lees: architectuurprincipes) worden opgesteld.

Applicaties

Algemeen
• status van een applicatie
• beschrijving van de applicatie
• soort applicatie (conform indeling verdieping GEMMA informatiearchitectuur)
• eigenaar van de applicatie
• gebruikers van een applicatie
• (niet)bedrijfskritisch en eisen over beschikbaarheid

Techniek
• gebruikte ontwikkeltechniek
• ondersteunde applicatieservers, operating systemen, databases en hardware (infrastructuur)

Beheer
• mate van documentatie
• contract, looptijd, opzegtermijn
• leverancier, ouderdom en levensduur
• besteedde uren voor onderhoud en exploitatie
• aanwezigheid service level overeenkomst.

Interoperabiliteit
• ondersteunde open standaarden
• afhankelijkheden met andere informatiesystemen

Gebruik
• gebruikte ontwikkeltechniek
• de nodige koppelingen
• het aanwezig zijn van een licentie en onderhoudscontract.

Kosten van de applicatie en de kosten voor verandering
• huidige kosten per onderdeel per jaar
• kosten voor vervanging
• (niet) gebruikte functionaliteit
• met het gebruik van de applicatie gepaard gaande risico’s op het terrein van continuïteit, veiligheid en compliance.

Levenscyclus van de applicatie
• behouden, verbeteren, migreren of vervangen

Bron: Handreiking KING: Applicatiesanering en contract management: ‘De basis op orde’