Leg vóór iedere uitrolgolf per activiteit vast wie uitvoert, beslist en escaleert: het projectteam behandelt prioritaire technische defecten tijdens stabilisatie, het permanente beheermodel behandelt reguliere ondersteuning en interne IT behandelt wat het aantoonbaar qua kennis en capaciteit kan dragen. Classificeer meldingen apart als defect, gebruikersvraag of wijziging, sluit stabilisatie alleen af na een toetsbare overdracht en beleg doorlopende governance bij een expliciete eigenaar.
Kernpunten van post-go-live eigenaarschap
Een gefaseerde Microsoft 365-implementatie vraagt om een servicegrens die meebeweegt met de uitrol, zonder dat open werk tussen project, beheer en interne IT blijft liggen.
- Verdeel werk per uitrolgolf, omdat bouwen aan volgende groepen en ondersteuning van live groepen maanden naast elkaar kunnen lopen.
- Maak de overdracht operationeel toetsbaar: beheerders moeten de omgeving zelfstandig kunnen bedienen, niet alleen documentatie ontvangen.
- Scheid prioritaire projectdefecten, reguliere gebruikersvragen en nieuwe functionele wensen, zodat ieder type werk een passend afhandelpad krijgt.
- Koppel de verdeling aan interne capaciteit, specialistische kennis, contractuele flexibiliteit en periodieke governance voor tenantbeheer en optimalisatie.
Leg eigenaarschap vóór de go-live per werkcategorie vast
Eigenaarschap na een Microsoft 365-go-live begint niet met een brede afspraak over ‘beheer’, maar met een verdeling per werkcategorie vóórdat een uitrolgolf live gaat. Die verdeling maakt zichtbaar welk werk tijdelijk bij het project blijft, welk werk in het permanente beheermodel terechtkomt en waar interne IT zelf de uitvoerende partij is. Zonder dat onderscheid kan een afgeronde technische oplevering ten onrechte worden gezien als het moment waarop alle vervolgvragen automatisch naar één team verschuiven.
De eerste grens ligt bij de feitelijke kennis en bezetting van interne IT. Bij middelgrote organisaties met 50 tot 250 werkplekken ontbreekt doorgaans diepgaande Microsoft 365- en SOC-certificering. In die situatie kan een co-managed model of uitbesteding aan een gespecialiseerde MSP een voorwaarde zijn voor veilige continuïteit. Dat is geen vaste taakverdeling voor elke organisatie. Een intern team met voldoende capaciteit en aantoonbare kennis kan meer zelf dragen; wanneer die capaciteit ontbreekt, ontstaat er juist een afhankelijkheid die expliciet in de verdeling moet staan. De relevante vraag is daarom niet of intern of extern beheer per definitie beter is, maar welk team een bepaalde activiteit tijdens en na een uitrolgolf daadwerkelijk kan uitvoeren.
Bij een wave-based uitrol wordt die grens scherper. Project- en beheerwerk lopen dan maanden naast elkaar: een volgende groep wordt nog opgebouwd, terwijl eerdere groepen al ondersteuning nodig hebben. Het bouwende projectteam en het ondersteunende transitieteam hebben daarom een afzonderlijke organisatorische positie nodig. Anders concurreren zij om dezelfde mensen en verdwijnt tijd voor stabilisatie naar de volgende implementatieactiviteit. Door per golf te benoemen welk team bouwt en welk team de live omgeving ondersteunt, wordt ook duidelijk wanneer een activiteit van het project naar beheer verhuist.
De serviceafspraak bepaalt vervolgens of deze verdeling kan meegroeien. Starre meerjarige beheercontracten kunnen tijdige bijsturing belemmeren als het volwassenheidsniveau van de organisatie verandert. Modulaire servicebundels die maandelijks opzegbaar zijn, gecombineerd met vaste kwartaaloverleggen, bieden ruimte om ondersteuning tijdens volgende migratiegolven aan te passen. Een gesprek over Microsoft 365-beheer wordt daardoor concreter: niet alleen de omvang van de dienstverlening telt, maar ook of de verantwoordelijkheden kunnen verschuiven wanneer interne kennis, capaciteit en de uitrolfase veranderen.
Een geslaagde go-live voorkomt geen gat in de nazorg
Projectacceptatie en opleverdocumentatie tonen dat een project formeel kan worden afgerond; zij bewijzen niet dat de operationele overdracht werkt. Dat onderscheid wordt zichtbaar wanneer een beheerteam na de livegang vragen krijgt die het niet zelfstandig kan afhandelen. Een overdracht die bestaat uit honderden pagina’s generieke functionele ontwerpen, zonder interactieve kennisoverdracht en zonder operationele acceptatietesten, laat beheerders achter zonder handelingsvermogen. De kennis zit dan nog bij de vertrekkende consultants, niet in een werkwijze die het beheerteam kan toepassen.
Een vage nazorgclausule vergroot dat risico. Wanneer onduidelijk is welke meldingen nog onder het project vallen en wie ze behandelt, kan het ticketvolume na go-live met 300 tot 400% stijgen. Een generalistisch intern IT-team raakt dan overbelast. Als escalaties vervolgens vastlopen, wachten gebruikers langer op antwoord. Dat tast vertrouwen aan en kan ertoe leiden dat gebruikers uitwijken naar ongeautoriseerde shadow IT. Daarmee verschuift een onduidelijke supportgrens van een organisatorisch probleem naar een risico voor compliance en databeveiliging.
Ook het einde van hypercare vraagt een expliciete grens. Ontbreken formele exitcriteria, dan kan een leverancier het project urenmatig afsluiten met een formele dechargeverklaring terwijl configuratiefouten en onopgeloste rechtenstructuren blijven bestaan. Als daarna ondersteuning alleen beschikbaar is via dure consultancy op nacalculatiebasis, ontstaat een combinatie van open operationeel werk en een uitgeput projectbudget. De organisatie kan dan worden geremd door kwesties die tijdens de stabilisatie hadden moeten worden beoordeeld, zonder dat nog vaststaat wie de rekening of de uitvoering draagt.
Een bruikbare overdracht is dus interactief en toetsbaar. Zij laat zien dat beheer de omgeving kan bedienen, niet alleen dat documentatie is overgedragen. Daarnaast begrenst zij welke meldingen nog projectwerk zijn, wanneer stabilisatie eindigt en welke werkzaamheden daarna via regulier beheer of een afzonderlijk vervolgtraject lopen. Pas dan verdwijnt het gat tussen formele oplevering en dagelijkse ondersteuning.
Bronnen bij deze sectie: apm.org.uk
Hypercare draagt defecten over, regulier beheer draagt de dienst
Hypercare en regulier beheer vullen elkaar aan, maar hebben een ander doel. De eerste laag houdt de projectverantwoordelijkheid bij prioritaire defecten; het permanente model draagt de dagelijkse dienst nadat reguliere vragen volgens afgesproken responstijden zijn overgedragen. De scheiding voorkomt bovendien dat kennis over tijdens de bouw gemaakte tenantconfiguraties alleen bij het projectteam blijft.
| Onderdeel | Tijdelijke stabilisatie | Permanent beheermodel | Overdrachtsmoment |
|---|---|---|---|
| Doel | Defecten met hoge prioriteit isoleren en oplossen onder projectverantwoordelijkheid. | De live dienst blijvend ondersteunen. | Wanneer de afhandeling niet langer een prioritair projectdefect betreft. |
| Type melding | Een technisch defect met hoge prioriteit dat na de go-live zichtbaar wordt. | Reguliere gebruikersvragen, behandeld volgens vastgestelde responstijden. | Reguliere vragen gaan stapsgewijs naar het permanente model. |
| Kennisbasis | Het projectteam beschikt nog over kennis van de gebouwde omgeving. | Beheer werkt met operationele runbooks. | Runbooks dragen tenantconfiguraties, zoals Conditional Access en Intune, over aan de operationele partij. |
| Functionele wens | Niet automatisch als prioritair defect behandelen. | Een beheerst wijzigingspad is nodig. | Een wens die als P1/P2-incident wordt ingediend, hoort eerst te worden geclassificeerd. |
Bronnen bij deze sectie: pmi.org, apm.org.uk, deloitte.com
Tickettriage bepaalt of werk bij project, beheer of interne IT hoort
Een ticket is geen bruikbare eigenaarcategorie. Direct na go-live kunnen technische bugs, gebruikersvragen en functionele wijzigingsverzoeken uiterlijk op elkaar lijken, maar zij vragen een andere beoordeling. Zonder strikte triage belanden ze op één hoop. Het projectteam kan dan weigeren omdat het verzoek buiten de scope valt, terwijl interne IT weigert wegens ontbrekende kennis. Het resultaat is niet alleen vertraging, maar ook een blijvend geschil over wie de melding had moeten behandelen.
| Soort melding | Primaire afhandelende laag | Escalatie of vervolgpad | Waarom afzonderlijk behandelen |
|---|---|---|---|
| Defectcorrectie | Projectverantwoordelijkheid wanneer het een technisch bug betreft dat direct na livegang wordt vastgesteld. | Classificeer het als projectdefect en isoleer de technische oorzaak. | Voorkomt dat een defect als reguliere vraag verdwijnt of als scope-uitbreiding wordt afgewezen. |
| Gebruikersvraag | Het permanente beheermodel, waaronder interne IT kan vallen. | Afhandelen volgens de vastgestelde responstijden; complexe kwesties alleen doorzetten naar een partij met passende kennis. | Een gebruikersvraag is niet automatisch een projectprobleem. |
| Complex Entra ID- of Endpoint-incident | Een laag met aantoonbare Microsoft 365-kennis. | Escaleren zodra de eerstelijns helpdesk zonder die kennis de melding niet kan dragen. | Belasting van niet-gecertificeerde eerstelijnsmedewerkers leidt tot escalatiestops, oplopende hersteltijden en vertraging van reguliere IT-processen. |
| Functioneel wijzigingsverzoek | Een apart wijzigingspad, niet de incidentenstroom. | Classificeer eerst de wens en bepaal daarna de behandeling. | Ad-hoc aanpassingen zonder impactanalyse kunnen een onbeheerbare verzameling rechten en security-uitzonderingen veroorzaken. |
De indeling werkt alleen wanneer alle uitzonderingen in het officiële ticketsysteem blijven. Wanneer één sleutelfiguur operationele vragen informeel afhandelt, ontstaat een persoonsafhankelijk model. Bij uitval of vertrek van die medewerker valt de ondersteuning direct stil, omdat reproduceerbare processen ontbreken. Triage gaat daarom niet uitsluitend over snelheid: zij maakt de gekozen verdeling overdraagbaar, zichtbaar en minder afhankelijk van individuele kennis.
Bronnen bij deze sectie: isaca.org, www.gov.uk, deloitte.com
Snelle wijzigingen en strakke governance vragen om een apart pad
Governance na livegang beweegt tussen twee reële belangen: de security baseline beschermen en functionele verandering niet onnodig vertragen. Een zeer rigide inrichting met formele Change Advisory Boards kan tenant-wildgroei beperken en de baseline beschermen. De keerzijde is dat snelle functionele adoptie wordt geremd wanneer ieder klein verzoek hetzelfde formele traject doorloopt. Een werkbare scheiding plaatst standaard self-servicewijzigingen apart van strategische besluiten die periodiek worden genomen.
| Keuze in de wijzigingsaanpak | Opbrengst | Nadeel of risico | Benodigde grens |
|---|---|---|---|
| Alle wijzigingen via formele Change Advisory Boards | Beschermt de security baseline en beperkt tenant-wildgroei. | Kan snelle functionele adoptie afremmen. | Onderscheid maken tussen self-service standaardwijzigingen en strategische kwartaalbesluiten. |
| Standaard self-servicewijzigingen apart behandelen | Geeft ruimte aan snelle functionele aanpassing. | Deze route mag niet worden verward met wijzigingen die tenantbreed doorwerken. | De aard van de wijziging bepaalt of deze standaard of strategisch is. |
| Tenantbrede policy aanpassen zonder voldoende overdracht | Geen onderbouwde structurele opbrengst. | Ad-hoc wijzigingen zonder security-impactanalyse kunnen Conditional Access-regels breken, met acute operationele storingen en data-onbereikbaarheid als gevolg. | Interactieve kennisoverdracht en shadowing tijdens de pilotfase. |
| Doorlopende governance zonder benoemde eigenaar | Geen blijvende borging van de veilige tenant. | Maandelijkse updates, gewijzigde API’s en nieuwe features kunnen leiden tot SharePoint-sprawl, verouderde Intune-policies en onbeheerde gasttoegang. | Expliciet eigenaarschap voor doorlopende governance. |
De beschikbare onderbouwing legt geen vaste financiële behandeling vast voor configuratiefouten die nog openstaan wanneer hypercare eindigt. Juist daarom hoort die grens vooraf benoemd te worden in de afspraken over wijziging en overdracht: anders blijft onduidelijk of het werk als defectcorrectie, regulier beheer of afzonderlijke consultancy wordt gezien. De operationele kant is wel helder: zonder shadowing blijft documentatie abstract, waardoor het interne beheerteam tenantbrede policies niet zelfstandig kan troubleshooten.
Bronnen bij deze sectie: pmi.org, isaca.org
Wat valt buiten reguliere support en wie bewaakt de voortgang?
De onderstaande scopevragen maken onderscheid tussen de continuïteit van de ondersteuning, de tijdelijke aard van hypercare en het terugkerende gesprek over governance.
- Wanneer wordt volledig intern beheer kwetsbaar? Volledig intern beheer biedt maximale directe controle en interne nabijheid. Daartegenover staan hoge vaste loonkosten en continuïteitsrisico’s bij ziekte of verloop. Een Managed Service Partner kan schaalbare expertise en tooling leveren, maar vraagt strikte afspraken over de afbakening. De keuze is dus geen tegenstelling tussen controle en kwaliteit, maar een verdeling waarin duidelijk staat welk werk intern blijft en voor welk werk externe capaciteit beschikbaar is.
- Is hypercare hetzelfde als doorlopende managed support? Nee. Een vaste project-hypercare geeft budgetzekerheid voor de initiële periode, maar stopt abrupt op de afgesproken deadline. Tijdens gefaseerde migratiegolven kan een maandelijks opzegbare servicebundel meer flexibiliteit bieden, omdat de benodigde ondersteuning mee kan bewegen. Dat is geen universele contractvorm: de relevante toets is of de contractuele grens past bij de nog veranderende uitrol.
- Wie bewaakt terugkerende governanceonderwerpen? Gestructureerde kwartaaloverleggen kunnen security baselines, Secure Scores, back-upintegriteit en roadmap-updates cyclisch en transparant aan de directie rapporteren. Daarmee ontstaat een vast moment om te zien welke onderwerpen terugkeren en of de ondersteuning nog aansluit op de actuele situatie. De bespreking is geen vervanging voor dagelijkse ticketafhandeling; zij maakt zichtbaar welke onderwerpen een bredere bestuurlijke opvolging vragen.
- Valt optimalisatie automatisch onder een brede supportterm? Nee, niet zonder expliciete afbakening. De noodzaak van strikte grenzen bij managed support betekent dat nieuwe wensen en optimalisatieverzoeken een eigen afhandelpad nodig hebben. Anders kan een partij een verzoek als reguliere ondersteuning zien, terwijl een andere partij het als aanvullend werk classificeert. Die onduidelijkheid hoort vóór contractering zichtbaar te zijn, inclusief de verantwoordelijke partij en de wijze waarop het verzoek wordt beoordeeld.
Bronnen bij deze sectie: www.gov.uk
Een bruikbare overdracht eindigt met taken die ook daarna een eigenaar houden
Een voorstel voor post-go-live ondersteuning wordt toetsbaar wanneer het niet alleen teams noemt, maar per activiteit een gedetailleerde RACI-matrix bevat. Daarin staat afzonderlijk wie uitvoert, wie beslist en wie bij afwijkingen escaleert. Die detaillering is nodig voor eerstelijnsincidenten, beleidswijzigingen in Intune, security monitoring via MDR, back-uptests en functionele optimalisaties. Deze activiteiten hebben een verschillend karakter: een algemene formulering als ‘ondersteuning’ maakt niet zichtbaar of alle vijf ook werkelijk binnen de afgesproken verantwoordelijkheid vallen.
De RACI krijgt pas operationele betekenis wanneer de servicevoorwaarden de verdeling uitvoerbaar houden. Transparante, flexibele voorwaarden kunnen bestaan uit modulaire ondersteuningsbundels die maandelijks opzegbaar zijn, geleverd door gecertificeerde specialisten met vaste aanspreekpunten. Die combinatie maakt het mogelijk om de ondersteuning aan te passen wanneer capaciteit of de ondersteuningsbehoefte verandert, zonder dat het dagelijkse aanspreekpunt verdwijnt. De toets gaat daarbij niet alleen over de aanwezigheid van expertise, maar ook over de vraag of de organisatie weet bij wie die expertise voor een concrete activiteit bereikbaar is.
Voor de besluitvorming werkt een eenvoudige controle: neem elke genoemde activiteit één voor één door en zoek de uitvoerende, besluitvormende en escalatierol op in de afspraak. Ontbreekt één van die rollen, dan is ook de overgang naar een andere partij niet controleerbaar. Een vaste naam zonder taakomschrijving is evenmin voldoende, omdat dan niet vaststaat welke werkzaamheden die persoon of dat team draagt. De financiële consequentie volgt uit dezelfde onduidelijkheid: open werk kan tussen partijen blijven liggen of afzonderlijk worden gefactureerd. Een activiteit zonder expliciete taaktoewijzing valt uiteindelijk buiten eigenaarschap én buiten het beschikbare budget.
Bronnen bij deze sectie: apm.org.uk, isaca.org