Je organisatie voorbereiden op een IBM audit begint met het in kaart brengen van alle geïnstalleerde IBM-software en het vergelijken van dat gebruik met de licentierechten die je daadwerkelijk bezit. Hoe eerder je dit doet, hoe sterker je positie is als IBM aanklopt. In dit artikel beantwoorden we de meest gestelde vragen over IBM audits, van de eerste signalen tot het afhandelen van een nabetalingsclaim.
Wat triggert een IBM audit bij jouw organisatie?
Een IBM audit wordt doorgaans getriggerd door een combinatie van contractuele afspraken en commerciële overwegingen van IBM zelf. Elke klant met een IBM-licentieovereenkomst kan op basis van die overeenkomst worden onderworpen aan een verificatie van het softwaregebruik. IBM heeft contractueel het recht om dit periodiek te doen, en in de praktijk gebeurt dat vaker bij grotere accounts of bij organisaties die recent zijn gefuseerd of overgenomen.
Andere veelvoorkomende triggers zijn:
- Een significante groei in de IT-omgeving, zoals uitbreiding van servers of virtualisatieplatformen
- Migratie naar de cloud waarbij IBM-software mee wordt genomen
- Verlopen of vernieuwde contracten waarbij IBM de gelegenheid aangrijpt om het gebruik te toetsen
- Interne meldingen of signalen uit IBM’s eigen verkoopdata die wijzen op potentieel onderlicentiegebruik
Het is belangrijk te weten dat IBM audits vaak strategisch worden ingezet als commercieel instrument. Een audit is zelden willekeurig.
Welke IBM-producten vallen het vaakst onder een audit?
De IBM-producten die het vaakst onderwerp zijn van een audit zijn Db2, WebSphere, MQ, Cognos, SPSS en IBM Rational-producten. Daarnaast staan IBM-mainframelicenties en producten die draaien in gevirtualiseerde of cloud-omgevingen hoog op de lijst, omdat de licentiemetingen daar het meest complex en foutgevoelig zijn.
Virtualisatietechnologieën zoals VMware en IBM zelf hebben specifieke licentieregels die afhankelijk zijn van het aantal beschikbare processors, niet alleen van het aantal daadwerkelijk gebruikte. Dit maakt het bijzonder lastig om compliant te blijven zonder gestructureerde monitoring van IBM licenties. Veel organisaties onderschatten hoe snel het gebruik in gevirtualiseerde omgevingen groeit ten opzichte van de aangeschafte rechten.
Hoe werkt het IBM audit proces stap voor stap?
Het IBM audit proces verloopt doorgaans in een vaste volgorde, van aankondiging tot eindrapportage. Wanneer je weet wat je kunt verwachten, kun je elke fase beter voorbereiden en bewaken.
- Aankondiging: IBM stuurt een formele kennisgeving, vaak via het IBM Software Compliance-team of een externe auditpartner zoals KPMG of Deloitte.
- Scoping: IBM bepaalt welke producten, entiteiten en tijdsperiodes worden meegenomen in de audit.
- Data-verzameling: Jouw organisatie wordt gevraagd om licentiedata, installatierapporten en deployment-informatie aan te leveren, vaak via IBM’s eigen tool ILMT (IBM License Metric Tool).
- Analyse: IBM analyseert de aangeleverde data en vergelijkt die met de licentierechten in hun systemen.
- Bevindingen: IBM presenteert een conceptrapport met eventuele tekortkomingen in de licentiedekking.
- Onderhandeling: Je hebt de mogelijkheid om de bevindingen te betwisten of aanvullende documentatie in te dienen.
- Afsluiting: De audit wordt afgesloten met een akkoord, een nabetalingsclaim of een aanpassing van het licentiecontract.
Wat zijn de grootste risico’s bij een IBM audit?
Het grootste risico bij een IBM audit is het aantonen van onderlicentiegebruik, wat kan leiden tot aanzienlijke nabetalingsclaims voor IBM licenties die in het verleden hadden moeten worden aangeschaft. Naast de directe financiële impact brengt een audit ook reputatierisico en juridische kwetsbaarheid met zich mee als het gebruik structureel niet compliant blijkt.
Andere significante risico’s zijn:
- Onjuiste interpretatie van licentievoorwaarden, met name rond virtualisatie en subkapaciteitslicenties
- Onvolledige of verouderde documentatie die je positie in de onderhandeling verzwakt
- Tijdsdruk tijdens de audit waardoor je geen ruimte hebt om bevindingen goed te analyseren
- Het ontbreken van een interne eigenaar die het auditproces coördineert
Hoe bereid je de technische documentatie voor op een IBM audit?
De voorbereiding van technische documentatie voor een IBM audit draait om het aantonen dat je licentiegebruik overeenkomt met de rechten die je bezit. De kern is een actueel en volledig overzicht van alle IBM-software-installaties, gecombineerd met bewijs van de bijbehorende licentieaankopen.
Praktische stappen om je documentatie op orde te brengen:
- Implementeer of actualiseer ILMT als je IBM-software gebruikt die valt onder subkapaciteitslicenties
- Leg alle aankoopbewijzen, contracten en licentiecertificaten gestructureerd vast
- Documenteer je virtualisatieconfiguraties en laat zien welke software op welke hosts draait
- Voer een interne pre-audit uit om discrepanties te identificeren voordat IBM dat doet
- Wijs een verantwoordelijke aan die alle communicatie met IBM coördineert
Goede documentatie is niet alleen een verdediging tijdens een audit, maar ook een structureel voordeel bij het beheren van je IBM licenties op de lange termijn.
Wanneer schakel je een onafhankelijke IBM audit specialist in?
Je schakelt een onafhankelijke IBM audit specialist in zodra je een auditaankondiging ontvangt, maar bij voorkeur al daarvoor als onderdeel van een structureel licentiebeheerprogramma. Hoe eerder een specialist betrokken is, hoe meer invloed je hebt op de scope en het verloop van de audit.
Een externe specialist is in ieder geval aan te raden wanneer:
- Je organisatie een complexe IT-omgeving heeft met veel gevirtualiseerde systemen
- Je interne kennis van IBM-licentiemodellen beperkt is
- IBM een auditpartner inzet die namens hen de bevindingen verzamelt
- Je vermoedt dat er sprake is van onderlicentiegebruik en je dit wilt kwantificeren voordat IBM dat doet
Een onafhankelijke specialist staat aan jouw kant, kent de licentieregels door en door en kan de bevindingen van IBM effectief betwisten of nuanceren.
Wat doe je als IBM een nabetalingsclaim indient?
Als IBM een nabetalingsclaim indient, accepteer die dan niet zonder grondig onderzoek. Een claim is een startpunt voor onderhandeling, geen eindvonnis. Veel claims bevatten fouten, verkeerde aannames over virtualisatieconfiguraties of een onjuiste interpretatie van de licentievoorwaarden die in jouw voordeel kunnen worden gecorrigeerd.
Concrete stappen bij een nabetalingsclaim:
- Vraag een gedetailleerde onderbouwing van de claim op en analyseer elk onderdeel
- Vergelijk de bevindingen met je eigen documentatie en licentierechten
- Identificeer punten waarop de claim aanvechtbaar is, bijvoorbeeld door een onjuiste scopedefinitie
- Onderhandel actief over de hoogte van de claim en de commerciële voorwaarden van de afwikkeling
- Overweeg om de claim te gebruiken als aanleiding voor een heronderhandeling van je totale IBM-contractportfolio
Een nabetalingsclaim kan in veel gevallen aanzienlijk worden gereduceerd als je de juiste argumenten en documentatie inbrengt. Laat je niet onder tijdsdruk zetten om snel te tekenen.
Hoe Thornstein Groep helpt bij IBM audits en licentieoptimalisatie
Een IBM audit hoeft geen verrassing te zijn als je de juiste ondersteuning hebt. Thornstein Groep begeleidt organisaties door het volledige IBM auditproces, van de eerste aankondiging tot de afhandeling van nabetalingsclaims. Wij staan aan jouw kant als onafhankelijke specialist met diepgaande kennis van IBM licentiemodellen, contractvoorwaarden en auditprocedures.
Wat wij voor je doen:
- Uitvoeren van een interne pre-audit om je positie te bepalen voordat IBM start
- Beoordelen en betwisten van IBM-bevindingen en nabetalingsclaims
- Adviseren over het structureel op orde brengen van je software licenties
- Ondersteunen bij onderhandelingen over licentiecontracten en claimafwikkeling
- Opzetten van een continu licentiebeheerprogramma om toekomstige risico’s te minimaliseren
Wil je weten hoe sterk jouw organisatie staat voor een IBM audit, of heb je al een auditaankondiging ontvangen? Neem contact op met Thornstein Groep voor een vrijblijvend gesprek.
