Tijdens het seminar Van uitvoeren naar uitblinken: Functioneel Beheer 2.0 (georganiseerd door Sogeti) werd een quick scan geïntroduceerd om de volwassenheid te meten van functioneel beheer. Hierbij werden zes aspecten gescoord op basis van drie 'stellingen'. Per stelling kun je aangeven of je - als je naar je eigen organisatie kijkt - het hier mee eens of oneens bent. Elk 'Eens' levert twee punten op, zodat per aspect maximaal zes punten kunt scoren. De eindscore geeft een goede indruk waar je als organisatie staat. De stellinigen geven in ieder geval een goede indruk van wát je überhaupt moet regelen voor het inrichten en verder professionaliseren van functioneel beheer.

1. Organisatie
1.1 Functioneel beheer wordt onderkend als aparte functie in uw organisatie.
1.2 Functioneel beheer is organisatorisch gepositioneerd bij de business.
1.3 Er zijn hoofdgebruikers (key users) die het centrale aanspreekpunt zijn voor FB.

2. Medewerkers
2.1 Er is in de hele organisatie duidelijkheid over de verantwoordelijkheden van functioneel beheer.
2.2 Voor functioneel beheer zijn competenties gedefinieerd en wordt hierop beoordeeld.
2.3 De functioneel beheerder wordt gestimuleerd zijn competenties via gerichte cursussen te verbeteren.

3. Samenwerking
3.1 De functioneel beheer-procedures en -taken zijn afgestemd met eindgebruikers en IT (leveranciers).
3.2 Functioneel beheer evalueert periodiek de gebruikerstevredenheid van de informatiesystemen.
3.3 Functioneel beheer evalueert periodiek de kwaliteit van de door IT geleverde diensten.

4. Kennis
4.1 Functionele beheer heeft diepgaande kennis van de informatiesystemen waarvoor zij verantwoordelijk is.
4.2 Functioneel beheer heeft diepgaande kennis van de bedrijfsprocessen die deze systemen ondersteunen.
4.3 Functioneel beheer is op de hoogte van de kwaliteitseisen die aan deze informatiesystemen worden gesteld.

5. Processen en procedures
5.1 Functioneel beheer heeft procedures voor de afhandeling van gebruikersvragen en volgt deze ook.
5.2 Functioneel beheer heeft procedures voor het opstellen van wijzigingsvoorstellen en volgt deze ook.
5.3 Functioneel beheer wordt actief betrokken bij een project; vanaf de start tot en met de implementatie.

6. Sturing en afspraken
6.1 Functioneel beheer weet hoe het besluitvormingsproces ten aanzien van wijzigingen en projecten loopt.
6.2 Functioneel beheer kent de projectplanning en bepaalt op basis daarvan de benodigde FB-capaciteit.
6.3 Functioneel beheer bewaakt of de contractafspraken met IT leveranciers aansluiten bij de gebruikerseisen.

Bron: Sogeti

Het referentiedomeinenmodel ziekenhuizen is een generiek model voor informatiedomeinen met bedrijfsactiviteiten en informatieobjecten in ziekenhuizen. Binnen het model wordt ingegaan op de relatie tussen bedrijfsactiviteiten, informatieobjecten en informatiedomeinen. Hieronder een definitie van de belangrijkste begrippen uit het referentiemodel:

1. Bedrijfsactiviteit: handeling die kan worden toegekend aan een specifieke persoon of rol. Een voorbeeld van een bedrijfsactiviteit is het uitvoeren van een preoperatieve screening.

2. Bedrijfsproces: reeks van activiteiten, met een duidelijk startpunt en eindpunt, en die leidt tot een duidelijk (en voor de klant nuttig) resultaat. Een voorbeeld van een bedrijfsproces is het operatief proces. In het operatief proces worden diverse bedrijfsactiviteiten (na elkaar) uitgevoerd, zoals het plannen van de operatie, het voorbereiden van de operatie, het uitvoeren van de preoperatieve screening, het uitvoeren van de operatie zelf en het opstellen van het operatieverslag.

3. Bedrijfsfunctie: set van activiteiten die onderling samenhang vertonen in de vereiste kennis, vaardigheden of middelen. Bedrijfsfuncties hebben vaak een meer permanent karakter dan bedrijfsprocessen. Een voorbeeld van een bedrijfsfunctie is verzorging & verpleging. Een bedrijfsfunctie levert een organisatie functionaliteit die bijdraagt aan een of meerdere bedrijfsprocessen.

4. Informatieobject: eenheid van informatie die relevant is vanuit een bedrijfsperspectief. Een informatieobject heeft betekenis voor de doelstelling en voor het functioneren van een organisatie. Een voorbeeld van een informatieobject is een operatieverslag. Informatieobjecten zijn onafhankelijk van fysieke inrichting of implementatie in een organisatie. Ze kunnen worden vertaald naar een fysiek model en naar fysieke verschijningsvormen van informatie (bijvoorbeeld tabellen in een database, informatie in een datawarehouse-omgeving, informatie in documenten). Dat betekent dat onderscheid moet worden gemaakt tussen de inhoud van een begrip (als concept, iets wat betekenis heeft in de werkelijkheid) en de manifestatie/vorm waarin het wordt opgeslagen of gepresenteerd (papier, digitaal, etiket, ponsplaatje). De manifestatie/vorm blijft buiten beschouwing wanneer gesproken wordt over informatieobjecten.

5. Informatiedomein: verzameling van bedrijfsactiviteiten met een maximale samenhang in de informatie die door de activiteiten wordt geproduceerd en gebruikt. Een informatiedomein wordt dus gedefinieerd door de bedrijfsactiviteiten die erin worden ondersteund en door de informatieobjecten die erbinnen worden gedefinieerd. Door de bedrijfsactiviteiten en informatieobjecten te clusteren op basis van onderlinge samenhang wordt bereikt dat informatiedomeinen zoveel mogelijk op zichzelf staan, en zo weinig mogelijk informatieobjecten uit andere domeinen nodig hebben.

Voor informatie-intensieve organisaties is het vaak zo dat bedrijfsfuncties en informatiedomeinen met elkaar samenvallen. Het verdient voor de begrijpelijkheid en herkenbaarheid de voorkeur deze één op één relatie te handhaven.

Bron: Referentiedomeinenmodel ziekenhuizen (versie 2| 21-06-2012) op www.nictiz.nl

Het bovenstaande negenvlaksmodel kwam ik tegen bij VERA. 'VERA' staat voor Volkshuisvesting Enterprise Referentie Architectuur en heeft als doel het faciliteren van uniforme gegevensuitwisseling tussen ICT systemen en richt zich met name op het ontwikkelen van implementeerbare gegevensdefinities.

Bron: http://www.stichting-vera.nl/wat-is-vera/

In het artikel Misvattingen, misverstanden en vragen over ASL en BiSL gaan Machteld Meijer en René Sieders in op het verschil tussen het maken van het functioneel ontwerp en het opstellen van de functionele eisen (requirements).

In BiSL treft men het proces Specificeren aan en in ASL het proces Ontwerp. In praktijk blijkt dat over het onderscheid tussen deze twee veel verwarring bestaat, omdat een functioneel ontwerp ook wel wordt aangeduid met de term functionele specificaties. Regelmatig zie je dan ook dat het maken van een functioneel ontwerp als een taak belegd is bij de functioneel beheerders. Toch is dat niet logisch.
Indien een applicatie moet worden gebouwd of aangepast is businessinformatiemanagement verantwoordelijk voor het aangeven wat de functionele eisen zijn (vaak requirements of gebruikersspecificaties genoemd). Aangeven hoe deze worden opgenomen in de applicatie is een taak van applicatiemanagement. Dit staat in een functioneel ontwerp. Om een functioneel ontwerp aan te kunnen passen heb je dus kennis nodig van de opbouw van de applicatie. Voor de gebruikersorganisatie is het niet nodig die opbouw te kennen. Zij moeten kunnen aangeven wat ze nodig hebben en niet hoe dat wordt vormgegeven. Specificeren gaat over het probleem (de vraag) en hoort thuis bij de functioneel beheerders en ontwerpen gaat over de oplossing (het aanbod) en hoort dus bij applicatiemanagement thuis. Maken en onderhouden van een functioneel ontwerp hoort dus thuis bij applicatiemanagement. (...) Het functioneel ontwerp is een document dat met de afnemer (lees: de functioneel beheerder) wordt afgestemd en veelal ook door de afnemer wordt geaccordeerd. Het is daarmee een onderdeel van het contract. Daardoor is een duidelijke overgang van Ontwerp naar Realisatie handig.

Bron: Misvattingen, misverstanden en vragen over ASL en BiSL, Machteld Meijer & René Sieders

In het artikel Succesvolle sourcing begint met een onderbouwd besluit, plot Joost van den Berg functioneel beheer, applicatiebeheer en technisch beheer op het negenvlaksmodel van Maes.

De verschillende beheeractiviteiten zijn verdeeld over het technologiedomein en het informatiedomein en bevinden zich meer op het operationele (uitvoerende) niveau dan op het tactische (structuur) niveau. Applicatiebeheer en technisch beheer zijn daarbij onderdeel van het technologiedomein. Het middelste domein van de informatie en communicatie is de plek waar de behoefte van de business wordt samengebracht met en afgestemd op het aanbod en de mogelijkheden van ict. In dit middelste domein bevindt zich het functionele beheer van de voorziening.

Bron: Succesvolle sourcing begint met een onderbouwd besluit, Joost van den Berg

In het artikel Combinatie van Cobit en BISL biedt een sterk Information Governance framework visualiseert Joep G.M. Janssen het negenvlaksmodel van Maes op bovenstaande wijze en geeft hij als omschrijving:

Het negenvlaksmodel is een raamwerk voor integratie, waarmee het management op een samenhangende en afgewogen wijze en op strategisch, structurerend en uitvoerend niveau een relatie kan leggen tussen informatie- en communicatieprocessen die de bedrijfsprocessen ondersteunen en de daarbij behorende technologie.

Bron: Combinatie van Cobit en BISL biedt een sterk Information Governance framework, Joep G.M. Janssen

Volgens Roel Grit is informatie een onderdeel van de zogenaamde informatieladder (naar Informatiemanagement, Bruins & Pinkster, 2007).

De informatieladder bestaat uit vijf 'treden':

1. Feiten: gebeurtenissen of omstandigheden die zich in de werkelijkheid voordoen (bijv. de auto rijdt 120 kilometer per uur).

2. Gegevens: registraties van feiten. Als feiten op papier of in de computer worden vastgelegd, spreekt men van gegevens. Als gegevens met een computer met elkaar in verband worden gebracht, spreekt men wel van data.

3. Informatie: feiten die betekenis voor je hebben.

4. Kennis: 'veredelde informatie', kennis ontstaat uit informatie, als die is aangevuld met vaardigheden en ervaring.

5. Competentie: combinatie van kennis, vaardigheden, houding en gedrag die nodig is om in een bepaalde beroepssituatie goed te kunnen functioneren. Een competentie heeft te maken met iemand doet met zijn kennis.

Bron: Informatiemanagement, Roel Grit

Bovenstaande weergave van het Negenvlaksmodel van Maes is afkomstig uit de Woningcorporatie referentie architectuur (CORA).

Bron: http://www.bitti.nl/userFiles/upload/presentaties/Introductie_cora_van_Dijk.pdf

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’

In de whitepaper Van applicatiecomplexiteit naar een businessgerichte architectuur geeft Atos Consulting haar visie op applicatieportfoliorationalisatie.

Voor veel bedrijven is de informatievoorziening een 'stroperige spaghetti' als gevolg van een (te) complex applicatielandschap. Deze applicatielandschapcomplexiteit heeft nadelige gevolgen voor de business: inconsistente gegevens, ondermaatse ondersteuning van bedrijfsprocessen (incl. slechte managementinformatie), langzame ontwikkeling van nieuwe producten, trage aanpassing aan wijzigende wet- en regelgeving en/of oplopende beheer- en onderhoudskosten.

Volgens Atos geeft "Driekwart van IT-managers ... aan grote problemen te ervaren met onderhoud, ontwikkeling en uitfaseren van applicaties als gevolg van complexiteit. Waarbij ontwikkeling en integratie van nieuwe systemen teveel tijd en geld kost, applicatie-onderhoud te duur is en uitfaseren van verouderde applicaties moeilijk is."

Atos stelt dat voor het oplossen van IT-complexiteit de business hard nodig is en bepleit een aanpak in zeven stappen:

1. Bepaal de uitgangspunten voor de ideale applicatieportfolio: identificeer de juiste business drivers (bijv. gemeenschappelijk klantbeeld, ketenintegratie, risicobeheersing, enz.); een adequaat inzicht in de business-strategie is nodig om vervolgens de criteria op te stellen waaraan de applicatieportfolio moet voldoen.

2. Breng kwaliteit en knelpunten van het bestaande applicatielandschap in kaart: inzicht in het bestaande situatie is nodig voor het opstellen van een migratiestrategie. Relevante aspecten hierbij zijn: bedrijfsarchitectuur, informatie- en applicatiearchitectuur, architectuur van de IT-infrastructuur en de governance (besturing van de informatievoorziening) en alignment (afstemming van de informatievoorziening op de business strategie).

3. Stel een bestemmingsplan op, eventueel met meerdere scenario’s: op basis van een beeld van de toekomstige situatie weet je waar je naar toe wilt gaan, beschreven in een doelarchitectuur (bedrijfsprocessen, producten en/of diensten, informatie, applicaties en infrastructuur) die fungeert als bestemmingsplan. Een architectuur in de vorm van een bestemmingsplan geeft principes, keuzes en richtlijnen, duidelijk genoeg om richting aan te geven, maar laat daarbinnen ruimte voor invulling.

4. Maak de businesscase voor de rationalisatie van de applicatieportfolio: de businesscase geeft inzicht in wat de rationalisatie gaat opleveren en voor wie, vanuit een bedrijfsbreed perspectief.

5. Kies een scenario en stel een roadmap op: onderlinge vergelijking van de scenario's en afstemming met de bedrijfsstrategie leidt tot de keuze van één oplossingsrichting welke vervolgens wordt uitgewerkt. Bij de uitwerking hoort ook het opstellen van een roadmap voor de implementatie van de rationalisatie.

6. Herontwerp de IT-governance om rationalisatie blijvend te kunnen besturen: de complexiteit van het applicatielandschap is een afgeleide van de complexiteit van de productportfolio (stimuleren van hergebruik ter bestrijding van het 'wij-zij-uniek-syndroom', het reduceren van applicaties door een overzicht te creëren in hoeverre het applicatielandschap bijdraagt aan de ondersteuning van de business processen). Applicatiecomplexiteit kan dan ook alleen door de business en IT samen worden opgelost.

7. Voer de rationalisatie uit en monitor de realisatie van besparingen: het rekenmodel dat bij de businesscase is gebruikt kan met de nodige voorzorg ook worden toegepast om te blijven monitoren of tijdens het implementatietraject de investeringen en de baten aan de beoogde doelen blijven voldoen.

Bij het opstellen van het bestemmingsplan (zie 3) kan rationalisatie worden bereikt door een mix van de onderstaande negen maatregelen:

1. Harmonisatie: uitfaseren van een applicatie ten faveure van een meer geschikte andere in geval van functionele redundantie (meerdere applicaties bieden dezelfde of vergelijkbare functionaliteit).

2. Consolidatie: gelijktrekken van verschillende technische uitvoeringen van dezelfde applicatie.

3. Standaardisatie: vervanging van maatwerksoftware door standaard 'pakket' software. Maatwerk kan nog ingezet worden voor het realiseren van concurrentievoordeel en het realiseren van noodzakelijke functionaliteit waarvoor geen pakketten beschikbaar zijn.

4. Nieuwe functionaliteit: toevoegen van nieuwe functionaliteit om 'zwakke plekken' in het applicatielandschap aan te pakken.

5. Uitfasering: uitfaseren van systemen die overbodig zijn of een lage toegevoegde waarde hebben.

6. Reduceren platformen: reductie van variëteit aan technische platformen (hardware systemen, operating systemen, databases, ontwikkelingsomgevingen).

7. Integratie: integreren van applicaties door modulaire opbouw, ontsluiting via webservices en het optimaliseren van koppelingen.

8. Herontwerp: herinrichten en/of optimaliseren van bedrijfsprocessen met IT.

9. Optimaliseren onderhoud, beheer en exploitatie: met een gerationaliseerd systeemlandschap kan het beheer vaak eenvoudiger gecentraliseerd worden, tegen lagere kosten en met een hogere kwaliteit van dienstverlening.

Zie ook: Applicatierationalisatie volgens Dave van Herpen en Applicatieportfoliomanagement volgens Arjan Juurlink

Bron: whitepaper Applicatie Portfolio Rationalisatie: 'Van applicatiecomplexiteit naar een businessgerichte architectuur' Jeroen van Dullemen, Rick Teunissen en Peter-Jan van de Venn (Atos Consulting), juni 2006