Application portfolio rationalization vermindert de toekomstige ondersteuningslast zonder de bedrijfsvoering te verstoren wanneer u alleen consolideert waar applicaties niet alleen functies, maar ook gestandaardiseerde processen, integraties, datastromen en beheertaken delen. Behoud of tolereer unieke productie- of complianceprocessen als vervanging duur maatwerk vereist, wijs een proceseigenaar aan, ruim afhankelijkheden bij uitfasering op en toets de volledige exploitatiekosten en interne behe
Kernpunten van dit artikel
Een kleiner applicatielandschap verlaagt de beheerlast pas wanneer de resterende processen stabiel kunnen draaien zonder nieuw maatwerk, verborgen afhankelijkheden of permanente externe ondersteuning.
- Beoordeel overlap als aanwijzing voor onderzoek, niet als bewijs dat één applicatie de andere veilig kan vervangen.
- Consolideer vooral gestandaardiseerde werkwijzen; uitzonderlijke of bedrijfskritische processen kunnen goedkoper en stabieler zijn om te behouden.
- Vergelijk kosten over de volledige gebruiksduur, omdat beheer, updates, integraties en support zwaarder wegen dan de initiële licentie- en projectkosten.
- Maak proceseigenaars verantwoordelijk voor vervangende werkwijzen, acceptatie en uitzonderingen, zodat uitgefaseerde tools niet terugkeren buiten formeel beheer.
- Behandel uitfasering als een operationele overgang: resterende integraties en automatiseringen kunnen anders instabiliteit en langere incidentafhandeling veroorzaken.
- Toets of de organisatie het doelplatform na de overgang zelf kan beheren; zonder overdraagbare kennis kan externe support een vaste kostenpost worden.
Wanneer applicatieconsolidatie de beheerlast werkelijk verlaagt
Applicatieconsolidatie is geen optelsom waarbij elke verwijderde applicatie automatisch leidt tot minder beheer. De grens ligt bij het proces dat de applicatie ondersteunt. Gestandaardiseerde administratieve processen lenen zich doorgaans voor samenvoeging: wanneer een doelplatform die werkwijze zonder ingrijpende afwijkingen kan dragen, verdwijnen mogelijk afzonderlijke beheeractiviteiten, integratiepunten en ondersteuningsvragen. De verwachte verlichting ontstaat dan niet uitsluitend uit een kleiner contractenbestand, maar uit minder afzonderlijke varianten die onderhouden en ondersteund moeten worden.
Die redenering verandert bij unieke productie- of complianceprocessen. Een generieke suite kan functioneel veel afdekken, maar het forceren van zulke afwijkende processen naar die suite leidt volgens de beschikbare inzichten tot dure maatwerkextensies en productiviteitsverlies. De applicatie verdwijnt dan wel uit het oude landschap, terwijl de afwijking als maatwerk op het doelplatform voortleeft. Daarmee verschuift de ondersteuningslast in plaats van dat zij afneemt: onderhoud wordt gekoppeld aan extensies, afhankelijkheden en specifieke kennis rond de aangepaste werkwijze.
De kostenverdeling over de levensduur ondersteunt daarom een andere volgorde in de beoordeling. De initiële licentie- of aanschafprijs vertegenwoordigt doorgaans slechts 20% tot 30% van de totale levenscycluskosten. De overige 70% tot 80% ontstaat in de exploitatiefase, via doorlopend onderhoud, integratiebeheer, security governance en support. Een aantrekkelijk geprijsd doelplatform is dus onvoldoende bewijs voor een lagere toekomstige last. De relevante vraag is of het platform de processen gedurende de exploitatie kan dragen zonder dat deze kostenposten opnieuw groeien.
Technische schuld verdient daarbij een eigen plaats in de beoordeling. Ongedocumenteerde maatwerkkoppelingen en opgebouwde technische schuld leggen beslag op gemiddeld 21% tot 40% van de totale IT-capaciteit en budgetten. Slecht geconsolideerde systemen vragen bovendien drie tot vier keer meer onderhoudsinspanning per functiepunt. Dit maakt zichtbaar waarom een portfoliobesluit niet alleen over functies of licenties gaat: verborgen koppelingen kunnen capaciteit blijven absorberen, ook nadat een applicatie formeel is samengevoegd. Een kandidaat is pas overtuigend consolideerbaar wanneer de standaardisatie van het proces én de beheersbaarheid van de exploitatie aantoonbaar overeind blijven.
Bronnen bij deze sectie: isaca.org, opengroup.org, cmu.edu, bizzdesign.com
Zichtbare overlap kan eindigen in blijvende externe support
Onderbenutte licenties en vergelijkbare functionaliteit zijn een legitieme aanleiding om het applicatieportfolio opnieuw te bekijken. Organisaties benutten gemiddeld 30% tot 40% van hun aangeschafte softwarelicenties niet, of hebben functioneel overlappende tools verspreid over afdelingen. Dat gegeven wijst op mogelijke verspilling, maar bewijst nog niet dat twee toepassingen zonder gevolgen tot één kunnen worden teruggebracht. Licentiegebruik laat immers niet zien welke afdelingsworkflows, gegevenscontext of rapportageafhankelijkheden achter die functies schuilgaan.
Een veelvoorkomende route naar hogere kosten begint met een oppervlakkige feature-inventarisatie. Wanneer die inventarisatie leidt tot consolidatie naar één centraal doelplatform zonder analyse van de werkprocessen, komen unieke afdelingsworkflows pas later in beeld. Zij worden vervolgens opgevangen met complex maatwerk. Als de interne IT-organisatie niet beschikt over de benodigde beheercompetenties voor dat maatwerk, ontstaat structurele escalatie naar externe consultants. De aanvankelijke licentiebesparing verandert dan in hoge maandelijkse supportkosten. De fout zit niet in het onderzoeken van overlap, maar in het behandelen van functiegelijkheid als bewijs dat de onderliggende werkwijze uitwisselbaar is.
Licentiedruk kan hetzelfde effect via een tweede route veroorzaken. Een naderende verlenging kan aanleiding zijn om een contract snel op te zeggen. Wanneer de datamigratie vervolgens onder tijdsdruk plaatsvindt, kunnen metadata en audittrails verloren gaan. Financiële of audit-afdelingen ontdekken daarna dat rapportageprocessen zijn verbroken. Tijdelijke extractiescripts bieden dan een acute reparatie, maar voegen nieuwe technische schuld toe. De beheerlast wordt hierdoor moeilijker voorspelbaar, omdat de tijdelijke oplossing onderdeel dreigt te worden van de dagelijkse operatie.
Dit onderscheid beschermt de bedrijfsvoering tegen een verkeerd tempo in de besluitvorming. Overlap maakt onderzoek zinvol; procesanalyse bepaalt of een consolidatievoorstel ook na de overgang houdbaar is. Een besluit dat uitsluitend op ongebruikte licenties of vergelijkbare features rust, kan kosten uit de contractregel verplaatsen naar herstelwerk, maatwerk en externe support. Het gewenste resultaat is daarom niet alleen minder licenties, maar een situatie waarin de resterende werkwijzen en informatie aantoonbaar zonder zulke noodconstructies kunnen blijven functioneren.
Bronnen bij deze sectie: gsa.gov, bizzdesign.com
Proceseigenaarschap bepaalt of uitfaseren beheersbaar blijft
De organisatorische gereedheid voor uitfaseren is niet af te lezen aan de technische leeftijd van een applicatie. Zij blijkt uit de vraag wie het proces vertegenwoordigt dat door de applicatie wordt ondersteund. Een formele Business Application Owner kan keuzes over vervangende werkwijzen dragen en acceptatie organiseren wanneer een bestaande toepassing verdwijnt. Daarmee krijgt niet alleen de techniek, maar ook het herontwerp van het werkproces een herkenbare verantwoordelijke.
Bij weesapplicaties is dat mandaat diffuus. Niemand heeft dan een duidelijke positie om vast te stellen welke werkwijze stopt, welke uitzondering bewust blijft bestaan en wie de nieuwe aanpak accepteert. De beschikbare inzichten verbinden die diffuse verantwoordelijkheid met passieve weerstand en met de terugkeer van ongeautoriseerde SaaS-tools. Dat laatste is geen detail in het portfolio: een op papier verwijderd hulpmiddel kan zo buiten het formele beheer opnieuw verschijnen. De applicatietelling daalt dan tijdelijk, terwijl versnippering terugkeert via toepassingen waarvoor geen helder eigenaarschap bestaat.
Ook de technische afsluiting heeft een operationele kant. Deactivering van een legacy-applicatie zonder opruiming van integraties kan zombie-scheduled tasks en webhooks achterlaten die blijven pingen. Daardoor kunnen API-logbestanden overbelast raken en kunnen cascading error loops ontstaan in gekoppelde kernsystemen. De keten eindigt in vertraagde incidentoplossing, een hogere MTTR en operationele instabiliteit. Dit is geen argument om elke oude applicatie te behouden, maar wel een reden om uitfaseren als een beheersbesluit te behandelen, niet als enkel het uitschakelen van een systeem.
Een geloofwaardige beoordeling houdt daarom ook ruimte voor Tolerate of Behoud. Bij complexe nichesystemen kan consolidatie de TCO verhogen. Behoud of tolereren is in dat geval een verdedigbare uitkomst, mits de procesverantwoordelijkheid en de gevolgen voor beheer expliciet zijn. De kwaliteit van het besluit blijkt niet uit het aantal uitgefaseerde applicaties, maar uit de vraag of proceskeuzes, resterende afhankelijkheden en verantwoordelijkheden een stabiele operatie mogelijk maken.
Bronnen bij deze sectie: isaca.org, opengroup.org, bizzdesign.com
Vergelijk exploitatiekosten vóór licenties en projectprijs
Een TCO-vergelijking over vijf tot zeven jaar zet de kosten van de huidige situatie naast die van het beoogde landschap. De tabel maakt onderscheid tussen de zichtbare initiële investering en de kosten die gedurende de exploitatie terugkeren. De genoemde percentages zijn algemene kostverdelingen, geen berekening voor een individuele organisatie.
| Kostendimensie | Huidige situatie | Beoogde geconsolideerde situatie | Betekenis voor het besluit |
|---|---|---|---|
| Initiële aanschaf en implementatie | Breng licentie- of aanschafkosten en implementatie afzonderlijk in beeld. | Neem de nieuwe aanschaf en implementatie als eigen, eenmalige post op. | Over een levenscyclus van vijf tot zeven jaar beslaan initiële aanschaf en implementatie doorgaans 20% tot 25% van de totale kosten. Een lage project- of licentiepost toont dus slechts een beperkt deel van de economische werkelijkheid. |
| Doorlopend beheer | Beoordeel de terugkerende beheerinspanning van de bestaande toepassingen. | Maak zichtbaar welke beheerlast na consolidatie resteert en welke onderhoudscomplexiteit daarbij hoort. | De doorlopende beheer-, update- en supportfase vertegenwoordigt doorgaans 75% tot 80% van de totale levenscycluskosten. Hier beslist zich of een lagere applicatietelling ook werkelijk tot lagere exploitatiekosten leidt. |
| Updates en support | Neem lopende update- en supportkosten mee als structurele uitgaven. | Vergelijk de verwachte terugkerende update- en supportfase met de huidige situatie, niet alleen met de initiële investering. | Circa 70% van moderniseringsinitiatieven mist de beoogde businesscase wanneer onderhoudscomplexiteit niet expliciet wordt meegewogen. Een kostenbeeld zonder deze fase kan daarom een verkeerde businesscase opleveren. |
| Run-the-business-uitgaven | Gebruik de bestaande uitgaven als uitgangspunt voor de verwachte verandering. | Toets de besparing op deze uitgaven tegen de volledige doorlopende beheerlast. | Een gestructureerde rationalisatie kan 15% tot 28% besparing op run-the-business-uitgaven opleveren. Dit is een potentieel, geen vast resultaat per kandidaat of organisatie. |
| Contractuele beheersbaarheid | Beoordeel in hoeverre dienstverlening en evaluatie duidelijk afgebakend zijn. | Maak servicebundels, periodiek kwartaaloverleg en maandelijks opzegbare voorwaarden zichtbaar. | Dergelijke voorwaarden zijn signalen dat de dienstverlening op langdurige waarde en toetsbaarheid is ingericht, zonder contractuele afhankelijkheid als uitgangspunt. |
Bronnen bij deze sectie: bizzdesign.com
Toets feature-overlap op processen, integraties en beheertaken
Gebruik per consolidatiekandidaat een korte scorecard die eerst vaststelt wat beide applicaties functioneel gemeen hebben en daarna controleert of die overeenkomst ook in de dagelijkse operatie bestaat. De volgorde voorkomt dat een brede featurelijst een oordeel vooruitloopt dat pas na toetsing van processen, integraties, datastromen en beheertaken mogelijk is.
- 1. Vergelijk de functies. Leg vast welke softwarefeatures overlappen. Dit is functionele overlap: twee systemen kunnen vergelijkbare mogelijkheden bieden. Deze stap identificeert de kandidaat, maar vormt nog geen bewijs dat één toepassing de andere kan vervangen. Een hoge mate van functiegelijkheid kan de indruk wekken dat consolidatie eenvoudig is, terwijl de functiecatalogus niets zegt over de manier waarop werk feitelijk door de organisatie stroomt.
2. Toets het proces achter iedere overlappende functie. Kijk vervolgens of dezelfde processen worden ondersteund. De vraag is niet alleen of een feature op beide platforms aanwezig is, maar of dezelfde werkwijze ermee kan worden uitgevoerd. Wanneer het proces niet gedeeld is, kan de zichtbare feature-overlap een te grove voorstelling van de werkelijkheid geven.
3. Toets integraties en datastromen. Operationele overlap omvat ook gedeelde integraties en datastromen. Breng daarom in beeld of de kandidaat en het doelplatform op dezelfde manier verbonden zijn met de processen die zij ondersteunen. Verschillen op dit niveau betekenen dat een toepassing misschien functioneel vervangbaar lijkt, maar operationeel een andere afhankelijkheidsstructuur heeft.
4. Vergelijk beheertaken. Neem ook de beheertaken op in het oordeel. Operationele overlap gaat niet alleen over wat gebruikers doen, maar ook over wat nodig blijft om het systeem te beheren. Uitsluitend sturen op functionele overlap verschuift licentiekosten vaak naar een hogere operationele beheerlast op het doelplatform. Die verschuiving maakt een schijnbesparing zichtbaar: de contractkosten dalen, terwijl de terugkerende inspanning toeneemt. - 5. Isoleer de resterende micro-workflows. De laatste toets richt zich op de uitzonderingen die buiten de brede overeenkomst vallen. De functionaliteitsillusie ontstaat wanneer analisten 90% functiegelijkheid zien, maar de resterende 10% bestaat uit bedrijfskritieke micro-workflows. Juist die beperkte rest kan achteraf duur maatwerk vereisen. Beoordeel daarom niet alleen hoeveel functies overlappen, maar ook wat de niet-overlappende workflow betekent voor het proces en voor het toekomstige beheer. Pas wanneer deze rest zonder kostbaar maatwerk kan worden opgevangen, ondersteunt feature-overlap een overtuigend consolidatieoordeel.
Bronnen bij deze sectie: bizzdesign.com
Twee kostenafwegingen die een consolidatievoorstel kunnen kantelen
Ook wanneer een kandidaat procesmatig consolideerbaar lijkt, blijven twee financiële afwegingen afzonderlijke aandacht vragen: de tijd waarin de investering terugkomt en de afhankelijkheid die ontstaat door concentratie bij één leverancier.
- Wanneer wordt een migratie-investering problematisch?
Consolidatie vraagt significante initiële uitgaven voor datamigratie en herinrichting. Die CapEx staat tegenover de verwachte structurele exploitatiebesparingen, of OpEx. De terugverdientijd vormt daarbij een harde praktische grens: duurt deze langer dan 36 maanden, dan dreigt het platform al verouderd te zijn voordat de investering rendeert. Dat betekent niet dat iedere investering met zo’n horizon per definitie onjuist is, maar wel dat de verwachte besparing niet los kan worden beoordeeld van de levensduur van het beoogde platform. Een voorstel moet dus zichtbaar maken of de structurele exploitatiebesparing binnen deze periode opweegt tegen de initiële migratie- en herinrichtingsuitgaven. Zonder die verbinding kan een substantiële projectinvestering economisch achterblijven bij de beloofde verbetering. - Waarom kan consolidatie tegelijk eenvoud en afhankelijkheid vergroten?
Het samenbrengen van tools bij één leverancier kan het aantal API-koppelingen en leverancierscontracten verminderen. Dat verlaagt de verscheidenheid aan relaties en verbindingen die rond het applicatielandschap bestaan. Daar staat een andere afhankelijkheid tegenover: de organisatie wordt sterker gebonden aan prijsverhogingen en productroadmaps van die ene leverancier. In een multi-vendor landschap blijft die afhankelijkheid meer verdeeld, maar zijn er juist meer API-koppelingen en contracten te beheren. Het besluit gaat daarom niet alleen over minder applicaties of minder koppelingen. Het weegt een beperkter integratie- en contractenlandschap af tegen minder ruimte om buiten de richting en prijsstelling van één ecosysteem te bewegen.
Bronnen bij deze sectie: gsa.gov, opengroup.org, bizzdesign.com
Een kleiner applicatielandschap telt pas als beheer intern kan landen
De economische toets van een consolidatievoorstel verschuift na de overgang naar Day-2 Operations. Daar wordt zichtbaar of de verwachte vereenvoudiging in de dagelijkse operatie standhoudt. Een voorstel dat uitsluitend licentiebesparingen en projectkosten presenteert, laat precies de kosten buiten beeld die later terugkeren. Een expliciete Day-2-calculatie maakt daarom de verwachte maandelijkse beheerlast in uren zichtbaar, samen met benodigde licentie-upgrades en SLA-voorwaarden. Deze drie onderdelen horen bij elkaar: beheeruren maken de operationele inspanning tastbaar, licentie-upgrades laten zien welke kosten kunnen meegroeien en SLA-voorwaarden begrenzen welke ondersteuning onderdeel van de dienstverlening is.
De tweede controle betreft beheerautonomie. Documentatie, architectuurplaten en training zijn geen losse opleverartefacten wanneer zij zijn gericht op het eerstelijns- en standaardbeheer door de interne organisatie. Zij bepalen of kennis na de overgang beschikbaar blijft voor dagelijkse vragen en terugkerende werkzaamheden. Zonder deze overdraagbaarheid kan externe ondersteuning van een tijdelijke transitiekost veranderen in een vaste component van de TCO. De organisatie heeft dan wel een kleiner landschap, maar niet noodzakelijk meer grip op de exploitatie ervan.
Deze twee onderdelen leggen ook een nuttige grens tussen een aantrekkelijk projectverhaal en een kostengevoelig voorstel. De maandelijkse Day-2-calculatie toetst de financiële continuïteit; de inrichting voor intern eerstelijns- en standaardbeheer toetst de operationele continuïteit. Gezamenlijk maken zij zichtbaar of de besparing afhankelijk blijft van externe inzet of in de eigen beheerorganisatie kan landen. Een voorstel zonder een expliciete berekening van beheeruren, licentie-upgrades en SLA-voorwaarden én zonder gestructureerde documentatie, architectuurplaten en training biedt geen onderbouwing voor een lagere toekomstige externe beheerlast.
Bronnen bij deze sectie: bizzdesign.com