Bij strategy-only IT-roadmapadvies eindigt de betrokkenheid doorgaans na het plan en blijft de interne organisatie verantwoordelijk voor uitvoering, leveranciersafstemming, escalaties en integratie. Bij consultancy-geleide roadmapuitvoering kan de partner deze regie en opleveringsverantwoordelijkheid tijdens de uitvoering blijven dragen, mits rollen, acceptatie en contractvoorwaarden expliciet zijn vastgelegd.
Kernpunten: verantwoordelijkheid na de IT-roadmap
Het onderscheid zit niet alleen in de roadmap zelf, maar vooral in wie na oplevering de samenhang tussen taken, leveranciers en besluitvorming bewaakt.
- Strategy-only biedt meer contractuele vrijheid en kan lagere instapkosten hebben, maar legt uitvoeringsrisico en regiedruk bij de eigen organisatie.
- Bij meerdere leveranciers moet expliciet vaststaan wie afhankelijkheden oplost en de diagnose leidt wanneer een probleem over contractgrenzen heen loopt.
- Gedeelde cloudtaken vereisen per fase een heldere verdeling van uitvoering, eindverantwoordelijkheid, raadpleging en informatievoorziening.
- Een centrale uitvoeringspartner kan één aanspreekpunt bieden, maar vergroot partnerafhankelijkheid als afspraken niet transparant en herzienbaar zijn.
- Offertes zijn pas goed vergelijkbaar wanneer per fase ook acceptatiecriteria en escalatiepaden aan toegewezen verantwoordelijkheden zijn gekoppeld.
Na de roadmap: waar blijft de aanspreekbaarheid?
Een IT-roadmap beschrijft een richting, fasering en samenhang tussen veranderingen. Daarmee is echter nog niet vastgelegd wie de samenhang bewaakt zodra verschillende partijen aan de uitvoering bijdragen. Precies daar ligt het onderscheid tussen een opdracht die met het roadmapdocument afloopt en een leveringsmodel waarin regie na de planfase doorloopt. Bij de eerste vorm komt de vraag naar afhankelijkheden, afstemming en escalatie in de praktijk terug bij de eigen organisatie. Bij de tweede vorm kan die verantwoordelijkheid expliciet onderdeel zijn van de voortgaande samenwerking.
In een landschap met meerdere leveranciers biedt Service Integration and Management (SIAM) hiervoor een concreet uitgangspunt. SIAM wijst een centrale service-integrator aan die technische afhankelijkheden, escalaties en processen over leveranciersgrenzen heen synchroniseert. Die rol vervangt niet automatisch het werk van afzonderlijke leveranciers. De rol richt zich juist op de punten waar hun werkzaamheden elkaar raken: welke afhankelijkheid eerst moet worden opgelost, waar een escalatie thuishoort en hoe een proces niet uiteenvalt in losse overdrachten.
Daardoor verschuift de vraag bij de beoordeling van een roadmappartner. Niet alleen de kwaliteit van de voorgestelde fasen telt, maar ook of er na oplevering een partij is die de onderlinge samenhang blijft organiseren. Een roadmap kan inhoudelijk helder zijn en toch ruimte laten voor onduidelijkheid wanneer een technische afhankelijkheid over meer dan één leverancier loopt. De centrale service-integrator is dan niet slechts een extra contactpersoon, maar de aangewezen plek waar de coördinatie van die grensoverschrijdende situatie samenkomt.
Doorlopende aanspreekbaarheid vraagt ook om een samenwerkingsvorm die herijking mogelijk maakt. Transparante en flexibele voorwaarden, bijvoorbeeld bundels die per maand opzegbaar zijn, laten ruimte om de relatie te herzien. Structureel kwartaaloverleg geeft daarnaast een vast moment om de roadmap opnieuw tegen de actuele uitvoering te houden. Dat overleg is geen vervanging voor dagelijkse coördinatie; het is een terugkerend moment waarop de route, de voortgang en de komende fasen opnieuw naast elkaar kunnen worden gelegd.
De kernvraag na het plan luidt daarom niet uitsluitend wie een activiteit uitvoert. De vraag is wie de technische afhankelijkheden, de escalaties en de processen tussen leveranciers bijeenhoudt. Als die rol intern blijft, ligt ook de blijvende regie intern. Als een partner deze rol blijft invullen, moet die voortgaande taak zichtbaar zijn in de samenwerkingsafspraken en in de ruimte om die afspraken periodiek opnieuw te beoordelen.
Bronnen bij deze sectie: scopism.com, wikipedia.org
Gedeelde cloudtaken maken een RACI per fase nodig
Gedeelde verantwoordelijkheid in een cloudomgeving betekent niet dat taken vanzelf een eigenaar krijgen. Juist wanneer klant en leveranciers ieder een deel van de uitvoering verzorgen, kan een taak tussen partijen blijven hangen. Dat risico speelt bij werkstromen die zowel organisatorische keuzes als technische uitvoering raken, waaronder data-classificatie, endpoint security en identity governance. Een roadmap die deze onderwerpen benoemt zonder de rolverdeling per fase uit te werken, geeft richting maar laat nog open wie handelt, wie het resultaat accepteert en wie aanspreekbaar blijft als de uitvoering stokt.
Een expliciete RACI-structuur maakt die verdeling zichtbaar. Per transformatiefase kan worden vastgelegd welke partij een taak uitvoert, welke partij eindverantwoordelijk is, wie geraadpleegd wordt en wie geïnformeerd blijft. Daarmee wordt gedeelde verantwoordelijkheid niet opgevat als een algemene belofte, maar als een reeks concrete toedelingen. Voor data-classificatie, endpoint security en identity governance voorkomt dit dat de klant ervan uitgaat dat een leverancier de taak oppakt, terwijl die leverancier de taak slechts als inbreng of informatieplicht ziet.
Dit onderscheid raakt rechtstreeks aan de vergelijking tussen strategy-only advies en uitvoering met doorlopende betrokkenheid. Een strategy-only partner kan een RACI als onderdeel van de roadmap opnemen, maar de interne organisatie blijft na de adviesopdracht degene die de taakverdeling in de uitvoering bewaakt. Wanneer een partner ook bij de uitvoering betrokken blijft, wordt zichtbaar of die partner niet alleen de indeling helpt formuleren, maar ook binnen de toegewezen rol opereert. De RACI is in beide gevallen geen administratieve bijlage: zij laat zien waar de verantwoordelijkheid per fase feitelijk landt.
De beoordeling van een uitvoerende partij kan bovendien steunen op toetsbare signalen. Aantoonbare certificeringen van specialisten op het gebied van Microsoft 365, Azure en cybersecurity vormen, samen met bewezen praktijkervaring in multi-vendor regie, een aanwijzing dat de partij de relevante werkgebieden en samenwerking tussen partijen kan onderbouwen. Een certificering op zichzelf zegt daarbij niet wie een taak in een specifieke fase draagt. De combinatie met ervaring in regie over meerdere leveranciers is relevant omdat de verdeling van cloudtaken vaak juist aan de grenzen tussen betrokken partijen getoetst wordt.
De bruikbare vraag voor een offerte is daarom per fase: welke taken rond data-classificatie, endpoint security en identity governance zijn toegewezen, en aan welke partij? Pas wanneer uitvoeren, eindverantwoordelijkheid, raadpleging en informatievoorziening afzonderlijk zijn benoemd, wordt zichtbaar of de gedeelde taak werkelijk belegd is of slechts als gezamenlijke verantwoordelijkheid blijft bestaan.
Bronnen bij deze sectie: microsoft.com
Wanneer meerdere leveranciers geen keteneigenaar hebben
Het verschil in verantwoordelijkheid wordt het scherpst zichtbaar wanneer een verandering niet binnen één contract of één uitvoerende partij blijft. Neem een tenant-migratiefout. De oorzaak kan pas worden onderzocht als de betrokken werkzaamheden in samenhang worden bekeken. Hetzelfde geldt voor een koppelingsprobleem: afzonderlijke partijen kunnen hun eigen onderdeel toelichten, maar daarmee is nog niet bepaald wie verantwoordelijk is voor de diagnose van de volledige keten.
Een RACI-vacuüm ontstaat wanneer leveranciers in zo’n situatie uitsluitend als Consulted of Informed zijn opgenomen. Zij leveren dan input, worden geraadpleegd of ontvangen informatie, maar zijn niet contractueel aangewezen als Accountable voor de ketendiagnose. Dat is een andere positie dan eindverantwoordelijkheid. De termen kunnen op papier dicht bij elkaar lijken, maar in een escalatie bepalen ze of een partij het onderzoek over de keten moet dragen of alleen reageert binnen het eigen afgebakende onderdeel.
Bij tenant-migratiefouten kan dit betekenen dat meerdere leveranciers betrokken zijn zonder dat één van hen de opdracht heeft om de samenhangende oorzaak vast te stellen. Bij koppelingsproblemen doet zich hetzelfde patroon voor: informatie uit verschillende delen kan nodig zijn, terwijl niemand contractueel eigenaar is van de diagnose die die informatie bijeenbrengt. De open plek wordt dan niet opgevuld door de roadmap zelf. Een roadmap kan werkzaamheden faseren, maar maakt een keteneigenaar alleen zichtbaar wanneer die rol ook expliciet is toegewezen.
Voor de vergelijking van leveringsmodellen is dit een concrete praktijksituatie. Strategy-only advies kan de noodzaak van een rolverdeling blootleggen, maar na afloop van de opdracht blijft de vraag welke interne of externe partij Accountable is. Bij een uitvoeringsgerichte vorm kan die vraag onderdeel worden van de afspraken over de uitvoering. Niet iedere leverancier hoeft ketendiagnose te bezitten; het punt is dat Consulted en Informed geen vervanging zijn voor een contractueel aangewezen Accountable-partij.
Wie voorstellen vergelijkt, kan daarom kijken naar één nauwkeurig onderscheid: staat voor een tenant-migratiefout of een koppelingsprobleem vast wie de ketendiagnose leidt? Als dat niet contractueel is belegd, blijft de diagnose een taak waarvoor betrokken partijen wel informatie kunnen leveren, maar waarvoor geen eindverantwoordelijke is aangewezen.
Bronnen bij deze sectie: scopism.com, wikipedia.org
Uitvoeringsrisico en regiedruk: het kernverschil tussen beide modellen
De lagere instap van strategy-only advies en de bredere betrokkenheid van consultancy-geleide uitvoering zijn geen gelijksoortige aanbiedingen met alleen een ander prijskaartje. Zij leggen na oplevering andere werkzaamheden bij de interne organisatie neer. De vergelijking hieronder benoemt die verdeling als afruil, niet als oordeel dat één vorm in alle situaties passend is.
| Vergelijkpunt | Strategy-only advies | Consultancy-geleide uitvoering |
|---|---|---|
| Initiële kosten | De opdracht kan lage initiële kosten hebben, omdat de focus op het advies en de roadmap ligt. | De vergelijking draait minder om uitsluitend de instap en meer om de betrokkenheid bij de uitvoering na het plan. |
| Contractuele vrijheid | Deze vorm biedt maximale contractuele vrijheid na afloop van de adviesopdracht. | Doorlopende betrokkenheid bundelt meer van de uitvoeringsrelatie bij een partner, waardoor de contractuele inrichting onderdeel van de afruil wordt. |
| Uitvoeringsrisico | Het volledige uitvoeringsrisico kan bij de eigen interne organisatie blijven. | De uitvoeringsgerichte partner kan verantwoordelijkheid voor de oplevering dragen binnen de overeengekomen uitvoering. |
| Escalatiedruk | De interne organisatie draagt de druk van escalaties nadat het plan is opgeleverd. | De regie kan bij de partner liggen die tijdens de uitvoering als aanspreekpunt optreedt. |
| Integratiewerk | De interne organisatie kan zelf de integratie tussen werkzaamheden en betrokken partijen moeten organiseren. | De partner kan die integratie als onderdeel van de uitvoeringsbetrokkenheid organiseren. |
Bronnen bij deze sectie: scopism.com, wikipedia.org
Eén aanspreekpunt werkt alleen binnen beheersbare contractvoorwaarden
Een centraal aanspreekpunt kan de verantwoordelijkheid voor oplevering in consultancy-geleide uitvoering concentreren. Daar staat een contractuele beperking tegenover: wanneer die centrale rol bij één partner ligt, kan partnerafhankelijkheid toenemen. De bruikbaarheid van deze constructie hangt daarom mede af van de mate waarin de contractvoorwaarden inzichtelijk en flexibel blijven.
| Aspect | Wat centrale uitvoering biedt | Welke begrenzing nodig blijft |
|---|---|---|
| Aanspreekpunt | De organisatie heeft één partij als aanspreekpunt voor de uitvoering in plaats van uitsluitend losse uitvoerende partijen. | De centralisatie betekent ook dat veel regie bij dezelfde partner terechtkomt. |
| Opleveringsverantwoordelijkheid | Consultancy-geleide uitvoering koppelt de betrokken partner aan opleveringsverantwoordelijkheid. | Die verantwoordelijkheid is alleen toetsbaar binnen duidelijke afspraken over wat de partner draagt. |
| Partnerafhankelijkheid | Een geconcentreerde uitvoeringsrelatie kan de coördinatie rond oplevering vereenvoudigen. | Wanneer contracten niet transparant zijn ingericht, ontstaat minder zicht op de voorwaarden van die afhankelijkheid. |
| Herzienbaarheid | Een doorlopende relatie kan tijdens de uitvoering blijven bestaan. | Maandelijks opzegbare en transparante contracten houden ruimte om de relatie te beëindigen of te herzien; zonder die eigenschappen neemt de afhankelijkheid toe. |
Bronnen bij deze sectie: scopism.com, wikipedia.org
Wanneer blijft interne regie passend bij meerdere ICT-contractanten?
Het behouden van bestaande, losse ICT-contracten sluit een expliciete keuze over regie niet uit. De vraag is niet alleen wie contractueel aanblijft, maar ook waar de integratiefunctie wordt ondergebracht wanneer werkzaamheden van die partijen elkaar raken.
- Kan een organisatie de controle over losse ICT-contractanten behouden zonder een externe integrator?
Ja. De organisatie kan de volledige interne controle over losse ICT-contractanten behouden en zelf de regie- en integratiefunctie dragen. Daarmee blijft zij degene die de samenhang tussen contractanten organiseert. Deze keuze gaat dus verder dan contractbeheer alleen: de interne organisatie neemt ook de rol op zich die nodig is wanneer technische afhankelijkheden of werkzaamheden tussen partijen op elkaar aansluiten. Dat kan passend zijn wanneer die functie bewust intern is belegd. De relevante grens ligt bij de vraag wie handelt wanneer leveranciers elk vanuit hun eigen contractpositie naar dezelfde technische impasse kijken.
Wat verandert er wanneer de SIAM-regiefunctie wordt uitbesteed?
Bij uitbesteding van de regie- en integratiefunctie wordt SIAM ingezet om technische impasses en vingerwijzen tussen leveranciers te beperken. De organisatie kan daarbij haar afzonderlijke contractanten behouden; wat verandert, is de plaats waar coördinatie en integratie worden georganiseerd. De externe regiefunctie is niet hetzelfde als het overnemen van ieder afzonderlijk leverancierscontract. Zij richt zich op de grens tussen die contracten, waar een probleem anders kan blijven liggen doordat partijen naar elkaar verwijzen. Dit betekent niet dat een uitbestede regiehouder alle incidenten voorkomt. Het onderscheid is dat de integratiefunctie expliciet buiten de interne organisatie wordt belegd, in plaats van dat interne medewerkers die functie naast de controle over de losse contracten dragen.
Bronnen bij deze sectie: scopism.com, wikipedia.org
De offerte is pas vergelijkbaar wanneer eigenaarschap per fase is vastgelegd
Een offerte voor een roadmap is pas op verantwoordelijkheid te vergelijken wanneer de afspraken niet bij algemene termen als ondersteuning, regie of uitvoering blijven. De toets ligt in een gedetailleerde RACI-matrix per transformatiefase. Daarin staat niet alleen welke activiteit op de planning staat, maar ook welke partij de taak uitvoert, wie eindverantwoordelijk is en welke rol de overige betrokkenen vervullen. Zo wordt zichtbaar of interne regie daadwerkelijk intern blijft, of dat een uitvoerende partner een doorlopende rol krijgt.
De fasegebonden uitwerking moet de uitvoerende partner én de zittende leveranciers expliciet opnemen. Dat voorkomt dat de roadmap een losstaand plandocument wordt naast de bestaande contractrelaties. Per fase ontstaat dan een gedeeld werkdocument waarin de taaktoedeling aansluit op de partijen die tijdens de uitvoering daadwerkelijk betrokken zijn. Een uitvoerende partner kan daarin een andere verantwoordelijkheid hebben dan een zittende leverancier, zonder dat één van beide slechts impliciet wordt verondersteld.
Acceptatiecriteria horen bij dezelfde toedeling. Een taak is niet volledig beschreven wanneer alleen vastligt wie haar uitvoert; ook moet duidelijk zijn op basis waarvan het resultaat wordt geaccepteerd. Daarmee wordt de overgang tussen uitvoering en oplevering controleerbaar. Zonder acceptatiecriteria kan onduidelijk blijven of een fase gereed is, terwijl de volgende fase al afhankelijk is van dat resultaat. De matrix geeft dan niet alleen rollen weer, maar markeert ook het punt waarop een partij haar toebedeelde bijdrage heeft opgeleverd.
Escalatiepaden maken vervolgens duidelijk wat er gebeurt wanneer de taak, de acceptatie of de afstemming niet volgens die verdeling verloopt. Zij verbinden een probleem aan een aangewezen route tussen interne teams, de uitvoerende partner en zittende leveranciers. Dat is iets anders dan een algemene afspraak dat partijen zullen samenwerken: de route voor opschaling is vooraf onderdeel van de fase.
Deze detaillering maakt ook de financiële en operationele grens van de keuze zichtbaar. Als herstelwerk na een onduidelijke oplevering tussen partijen blijft liggen, kunnen werkzaamheden doorlopen zonder dat helder is wie de volgende stap draagt. Een RACI per fase met taken, acceptatiecriteria en escalatiepaden legt die grens vooraf vast: elke herstelvraag moet aan een expliciet toegewezen partij en fase kunnen worden gekoppeld.
Bronnen bij deze sectie: microsoft.com