Dubbele applicaties vinden in je softwareportfolio: zo pak je het aan
Ontdek hoe je dubbele applicaties vindt, wildgroei aan applicaties terugdringt, kosten verlaagt en je applicatieportfoliomanagement verbetert met applicatierationalisatie.
De meeste organisaties denken dat ze hun applicatielandschap kennen. Maar zodra ze beginnen met applicatierationalisatie, ontdekken ze meerdere applicaties met precies hetzelfde zakelijke doel, vaak gekocht door verschillende teams, betaald uit verschillende budgetten en beheerd door verschillende mensen.
Deze gids legt uit wat dubbele applicaties zijn, waarom ze ontstaan, wat ze kosten en vooral hoe je ze stap voor stap opspoort.
Wat zijn dubbele applicaties?
Dubbele applicaties zijn twee of meer applicaties in je portfolio die dezelfde business capability ondersteunen. De overlap hoeft niet volledig te zijn: als het meeste van wat de ene tool doet ook kan met een andere tool waarvoor je al betaalt, heb je applicatieoverlap, en daarmee dubbele software.
Projectmanagement is het klassieke voorbeeld. In veel organisaties vind je al deze tools naast elkaar:
- Jira
- Microsoft Planner
- Asana
- Monday.com
Elke tool was een logische keuze voor het team dat hem koos. Samen betekenen ze vier contracten, vier sets gebruikersaccounts en vier plekken waar projectinformatie staat.
Waarom dubbele applicaties ontstaan
Dubbele applicaties zijn zelden het gevolg van één verkeerde beslissing. Ze zijn een symptoom van wildgroei aan applicaties, in het Engels ook wel application sprawl: de gestage, vaak onzichtbare groei van het applicatielandschap. De meest voorkomende oorzaken:
Het resultaat is wildgroei aan software en een steeds complexer applicatielandschap: meer koppelingen, meer leveranciers, meer beveiligingsbeoordelingen en meer data verspreid over meer systemen.
Dubbele applicaties zijn zelden één verkeerde beslissing. Ze zijn de optelsom van veel logische.
De verborgen kosten van dubbele applicaties
De licentiekosten zijn alleen het zichtbare deel. Elke dubbele applicatie vermenigvuldigt kosten in de hele organisatie:
| Kosten | Waarom ze oplopen |
|---|---|
| Licenties | Meerdere leveranciers betalen voor dezelfde capability, vaak elk onder de drempel voor volumekorting |
| Supportcontracten | Aparte supportafspraken, verlengingen en leveranciersmanagement voor elke tool |
| Koppelingen | Elke applicatie heeft eigen koppelingen nodig met identity, data en andere systemen |
| Training en onboarding | Medewerkers die van team wisselen, leren een andere tool voor hetzelfde werk |
| Beveiliging en compliance | Meer leveranciers om te beoordelen, meer toegang om te beheren, meer plekken met data |
Daarom is lagere softwarekosten meestal het eerste resultaat van een rationalisatie, en is het opruimen van dubbele applicaties een van de snelste routes naar een geoptimaliseerd applicatieportfolio.
Dubbele applicaties vinden in 5 stappen
Een praktisch rationalisatieproces volgt vijf stappen:
- Stel een applicatie-inventaris op
- Groepeer applicaties op business capability
- Zoek overlappende functionaliteit
- Vergelijk gebruik en bedrijfswaarde
- Maak een rationalisatieplan
Stap 1: Stel een applicatie-inventaris op
Je kunt niet rationaliseren wat je niet ziet. Begin met een complete lijst van de applicaties die in gebruik zijn: uit je CMDB, inkoop- en financiële administratie, SSO- en identitylogs en de software die teams gebruiken zonder tussenkomst van IT. Leg per applicatie minstens de leverancier, de eigenaar en de afdelingen vast die haar gebruiken. Dezelfde inventaris is ook het startpunt om cloudadoptie te meten.
Stap 2: Groepeer applicaties op business capability
Namen zeggen weinig. “Planner”, “Asana” en “Monday.com” lijken in een lijst niets met elkaar te maken te hebben, maar ze ondersteunen allemaal dezelfde business capability: project- en taakbeheer. Koppel elke applicatie aan de business capabilities die ze ondersteunt. Capabilities met meer dan één applicatie zijn je eerste kandidaten voor dubbeling.
Stap 3: Zoek overlappende functionaliteit
Vergelijk binnen elke capability wat de applicaties echt doen. Volledige overlap betekent dat de ene tool de andere helemaal kan vervangen. Gedeeltelijke overlap betekent dat ze de kernfunctionaliteit delen, maar elk iets eigens hebben. Niet elke overlap is een probleem: soms is een gespecialiseerde tool terecht.
Stap 4: Vergelijk gebruik en bedrijfswaarde
Kijk per overlappende groep naar het aantal actieve gebruikers, de kosten per gebruiker, de bedrijfswaarde, de technische fit met je landschap en eventuele risico’s rond de leverancier. Zo wordt een lijst dubbele applicaties een vergelijking op basis van feiten.
Stap 5: Maak een rationalisatieplan
Beslis per applicatie: behouden, vervangen, consolideren of uitfaseren. Plan de wijzigingen rond de verlengingsdata van contracten, migreer data en gebruikers gefaseerd en wijs per beslissing een eigenaar aan. Een kort, realistisch plan werkt beter dan een ambitieus plan dat nooit start.
Voorbeeld: vier projectmanagementtools
Zo ziet dat er in de praktijk uit, bij een fictieve middelgrote organisatie:
| Applicatie | Gebruikt door | Actieve gebruikers | Belangrijkste gebruik |
|---|---|---|---|
| Jira | IT en development | 180 | Softwareontwikkeling, issue tracking |
| Microsoft Planner | Operations, HR | 260 | Takenlijsten en kleine projecten |
| Asana | Marketing | 45 | Campagneplanning |
| Monday.com | Sales | 30 | Salesprojecten en opvolging |
Het resultaat: twee contracten in plaats van vier, één manier van werken voor de meeste teams en minder koppelingen om te onderhouden.
Waarom applicatierationalisatie vaak mislukt
De meeste rationalisatietrajecten lopen niet vast op de beslissingen. Ze lopen vast op de data die nodig is om ze te nemen:
Zoals we uitlegden in CMDB vs. applicatieportfoliomanagement, vertelt een CMDB je welke applicaties er zijn, niet of ze overlappen. Precies daar lopen de meeste rationalisatieprojecten vast.
De belangrijkste inzichten
Veelgestelde vragen
Wat is applicatierationalisatie?
Applicatierationalisatie (in het Engels: Application Rationalization) is het doorlichten van je applicatieportfolio om te bepalen welke applicaties je behoudt, vervangt, consolideert of uitfaseert. Het doel is een eenvoudiger en goedkoper landschap waarin elke applicatie haar plek verdient.
Wat is softwarerationalisatie?
Softwarerationalisatie wordt vaak als synoniem voor applicatierationalisatie gebruikt. Soms gaat het breder over alle software, ook tools en platformen die geen bedrijfsapplicatie zijn, maar de aanpak is dezelfde: overlap en verspilling vinden en daarna consolideren.
Wat is wildgroei aan applicaties?
Wildgroei aan applicaties (in het Engels: application sprawl) is de ongecontroleerde groei van het aantal applicaties in een organisatie, vaak door aankopen per afdeling, shadow IT en fusies. Het leidt tot dubbele functionaliteit, hogere kosten en een complexer applicatielandschap.
Hoe vind je dubbele applicaties?
Stel een complete applicatie-inventaris op, groepeer elke applicatie op de business capability die ze ondersteunt, zoek capabilities die door meer dan één applicatie worden bediend en vergelijk daarna functionaliteit, gebruik en bedrijfswaarde om te bepalen welke je houdt.
Wat levert rationalisatie van je applicatieportfolio op?
Lagere licentie- en supportkosten, minder koppelingen om te onderhouden, minder trainingsinspanning, minder risico op het gebied van beveiliging en compliance, en een eenvoudiger landschap dat makkelijker te beheren en te veranderen is.
Bekijk je portfolio met volledige context
Plan een live demo, dan verrijken we een deel van je eigen applicatiedata.
Demo aanvragen