Gen8

Google Workspace of Microsoft 365 als basis

Kennis

De keuze tussen Workspace en Microsoft 365 maak je niet voor je AI-workflows. Maar de stack die je al hebt, bepaalt wel hoe een koppeling loopt, hoe rechten werken en hoeveel beheer erbij komt kijken.

Het uitgangspunt

Vrijwel niemand kiest zijn kantoorstack opnieuw omdat er AI bij komt, en dat is verstandig. De relevante vraag is de omgekeerde: gegeven wat je al hebt, waar loopt een workflow soepel en waar kost hij extra werk?

Drie dingen verschillen praktisch: hoe de koppeling tot stand komt, hoe rechten doorwerken, en wie het beheer draagt.

De route van een koppeling

Niet elk systeem wordt op dezelfde manier ontsloten. Op ons platform bestaan eigen gereedschapssets voor onder meer Gmail, Google Drive en agenda aan de Google-kant, en voor Outlook-mail, Outlook-agenda, SharePoint en OneDrive aan de Microsoft-kant. Binnen Microsoft 365 is Teams de uitzondering: daarvoor bestaat geen eigen koppeling, en wat een workflow met Teams doet loopt via MCP of via maatwerk. Dat is geen oordeel over Microsoft — het bepaalt wel de doorlooptijd van die ene koppeling en wie hem onderhoudt.

Praktisch: een document- of mailworkflow op SharePoint, OneDrive, Drive, Gmail of Outlook vertrekt vanaf een bestaande koppeling. Een workflow die een melding in een Teams-kanaal zet of een bericht uit Teams oppikt, vraagt een expliciete keuze over de route voordat je begint. Vraag die route altijd na voordat je een planning maakt; “het kan” en “het is een directe koppeling” zijn verschillende uitspraken.

Rechten

Beide stacks hebben een uitgewerkt rechtenmodel, en in beide geldt hetzelfde uitgangspunt: een workflow mag zien wat de gebruiker mag zien, en niet meer. Het verschil zit in waar de complexiteit zit.

In beide gevallen is de eerste stap dezelfde en wordt hij het vaakst overgeslagen: vaststellen wat er vandaag al te breed gedeeld staat. Een workflow verandert daar niets aan, maar maakt het wel ineens zichtbaar — en dat voelt dan als een probleem dat de workflow heeft veroorzaakt.

Beheerlast

De vraag die telt: wie merkt het als een koppeling stopt? In beide stacks verlopen autorisaties, wijzigen beheerders beleid en vervallen accounts. Zorg dat elke koppeling op naam van de organisatie staat in plaats van op een persoonlijk account, en dat er één interne beheerder is die dat kan herstellen. Dat is belangrijker dan de merkkeuze.

Gemengde omgevingen

Veel organisaties hebben beide: mail in de ene stack, documenten in de andere, en een afdeling die iets eigens gebruikt. Dat is werkbaar, mits je per workflow expliciet opschrijft welk systeem de bron is en welk systeem de bestemming. Wat niet werkt, is dezelfde informatie op twee plekken bijhouden en de workflow laten raden welke de juiste is.

Volgende stap

Wat je hiermee doet

Schrijf voor de workflow die je wilt bouwen op welke systemen hij moet lezen en schrijven, en vraag per systeem na welke route dat is: eigen gereedschap, configuratie, MCP of maatwerk. Die vier antwoorden bepalen de planning meer dan de inhoud van de workflow.

Veelgestelde vragen

Moeten we overstappen naar één stack voordat we beginnen?

Nee. Een migratie is een groot project met eigen risico's, en een workflow die op twee stacks werkt is prima te bouwen. Wel is het verstandig om per proces één bronsysteem aan te wijzen in plaats van twee gelijkwaardige.

Betekent een MCP-route dat iets minder betrouwbaar is?

Niet minder betrouwbaar, wel anders belegd: er zit een extra laag tussen die iemand moet inrichten en onderhouden. Vraag bij die route altijd wie de eigenaar is en hoe een storing zichtbaar wordt.

Wil je dit op je eigen proces toepassen?

Breng één proces mee naar een gesprek. We beoordelen geschiktheid, risico en wat de eerste stap kost.

  • Reactie binnen één werkdag
  • Geen verplichtingen