Een platformkeuze is ook een keuze voor je organisatie

Technologie bepaalt niet alleen wat een digitaal platform kan, maar ook waar kennis, verantwoordelijkheid en zeggenschap komen te liggen.

Organisaties denken vaak dat ze een CMS, SaaS-platform of maatwerkapplicatie inkopen. In werkelijkheid leggen ze voor jaren vast wie veranderingen kan doorvoeren, waar belangrijke kennis komt te liggen en hoe snel de organisatie later nog kan bewegen.

Toch gaat het gesprek bij een nieuw digitaal platform meestal eerst over functionaliteit. Kan het systeem koppelen met het CRM? Kunnen redacteuren zelf pagina’s opbouwen? Hoe werkt de zoekfunctie? En past het binnen het beschikbare budget?

Dat zijn logische vragen, maar ze zijn niet voldoende.

Een digitale keuze verandert namelijk niet alleen de techniek. Zij beïnvloedt ook werkprocessen, verantwoordelijkheden, besluitvorming en afhankelijkheden. Juist die gevolgen blijven tijdens selectietrajecten vaak onderbelicht, omdat ze moeilijker in een demo of offerte te vangen zijn.

In de praktijk zie ik dat de lastigste problemen zelden ontstaan doordat een platform iets niet kan. Ze ontstaan meestal later, wanneer onduidelijk blijkt wie keuzes mag maken, wie de kwaliteit bewaakt, welke kennis intern aanwezig moet zijn en wie de gevolgen van veranderingen kan overzien.

Daarom kijk ik bij een platformkeuze altijd naar vier vragen:

• Zeggenschap: wie kan beslissen en veranderingen doorvoeren?
• Verantwoordelijkheid: wie beheert, controleert en beveiligt?
• Afhankelijkheid: welke kennis en middelen liggen buiten de organisatie?
• Bewegingsruimte: hoe eenvoudig kan de organisatie later bijsturen?

De technologie is daarbij belangrijk, maar nooit het volledige antwoord.

De techniek is zichtbaar, de organisatie erachter minder

Een demo maakt functionaliteit tastbaar. Je ziet schermen, workflows en mogelijkheden. De organisatorische gevolgen zijn veel moeilijker te tonen.

Neem een flexibel CMS waarmee redacteuren zelf landingspagina’s kunnen samenstellen. Tijdens de selectie klinkt dat aantrekkelijk. De organisatie wordt minder afhankelijk van developers en kan sneller nieuwe pagina’s publiceren.

Na de livegang blijkt echter dat niemand verantwoordelijk is voor de samenhang. Componenten worden per afdeling anders gebruikt, pagina’s krijgen uiteenlopende structuren en toegankelijkheidsproblemen stapelen zich langzaam op. Iedere redacteur heeft technisch de vrijheid om een pagina te bouwen, maar er is geen duidelijke governance om die vrijheid goed te gebruiken.

De technische flexibiliteit heeft het probleem dan niet opgelost. Het heeft de verantwoordelijkheid verplaatst naar de organisatie.

Wie bepaalt welke componenten beschikbaar zijn? Wie bewaakt de visuele en inhoudelijke samenhang? Wie controleert toegankelijkheid, kwaliteit en vindbaarheid? En is de redactie voldoende ingericht om al die keuzes zelfstandig te maken?

Hetzelfde geldt voor een maatwerkapplicatie. Maatwerk kan precies aansluiten op een bestaand proces, maar vraagt ook om blijvende kennis van de code, architectuur en achterliggende keuzes. Wanneer die kennis alleen aanwezig is bij één ontwikkelaar of leverancier, wordt een technisch sterke oplossing alsnog kwetsbaar.

Flexibiliteit is daarom alleen een voordeel wanneer een organisatie in staat is die flexibiliteit te organiseren.

Hoe meer vrijheid een platform biedt, hoe meer keuzes, kennis en verantwoordelijkheid er meestal binnen de organisatie nodig zijn.

Platform, architectuur en leverancier zijn verschillende keuzes

In veel selectietrajecten worden verschillende beslissingen samengevoegd tot één keuze. De organisatie kiest bijvoorbeeld voor een bepaald CMS en denkt daarmee ook iets te hebben besloten over flexibiliteit, onafhankelijkheid en toekomstbestendigheid.

Maar een platform, technische architectuur en leverancier zijn niet hetzelfde.

Je kunt kiezen voor open-source software en alsnog volledig afhankelijk worden van één leverancier. Dat gebeurt bijvoorbeeld wanneer alleen die leverancier toegang heeft tot de hosting, documentatie ontbreekt en alle kennis bij een klein aantal ontwikkelaars ligt.

Andersom kan een SaaS-oplossing redelijk overdraagbaar zijn wanneer data eenvoudig kan worden geëxporteerd, koppelingen goed zijn gedocumenteerd en de organisatie duidelijke afspraken heeft gemaakt over eigenaarschap en continuïteit.

Ook architectuur heeft eigen gevolgen. Een headless opzet kan bijvoorbeeld veel vrijheid bieden in de presentatie en integratie met andere systemen. Tegelijkertijd vraagt zij vaak om meer technische kennis, extra infrastructuur en meer afstemming tussen frontend, backend en verschillende leveranciers.

De technologie bepaalt dus niet zelfstandig hoeveel vrijheid een organisatie heeft. Ook de architectuur, contracten, documentatie, hosting en manier van samenwerken bepalen hoeveel zeggenschap en afhankelijkheid uiteindelijk ontstaat.

Dat maakt een platformselectie ingewikkelder, maar ook eerlijker. Je kiest niet één product. Je kiest een combinatie van techniek, inrichting en samenwerking.

Iedere digitale keuze verdeelt verantwoordelijkheid

Bij een digitaal platform zijn meestal verschillende partijen betrokken: bestuur, communicatie, ICT, redacties, leveranciers en gebruikers. Een technologische keuze verdeelt impliciet het werk en de verantwoordelijkheid tussen die partijen.

Een SaaS-oplossing legt bijvoorbeeld veel technisch beheer bij de leverancier. Dat kan rust geven. Updates, infrastructuur en beveiliging worden grotendeels buiten de eigen organisatie geregeld.

Daar staat tegenover dat de leverancier ook veel bepaalt. Wanneer functies veranderen, welke integraties worden ondersteund en hoe snel specifieke wensen kunnen worden uitgevoerd, ligt niet volledig in eigen hand.

Een open-source platform biedt in theorie meer vrijheid rond code, data en leverancierskeuze. Maar die vrijheid heeft alleen waarde wanneer de organisatie de omgeving goed documenteert, toegang tot belangrijke middelen behoudt en voorkomt dat alle kennis alsnog bij één partij terechtkomt.

Open source is dus niet automatisch onafhankelijk. Het biedt vooral de mogelijkheid om onafhankelijkheid beter te organiseren.

Bij iedere keuze moet daarom duidelijk zijn wie eigenaar wordt van:

• de productvisie en roadmap;
• inhoud en redactionele kwaliteit;
• data en gegevensmodellen;
• technische architectuur;
• beveiliging en privacy;
• hosting en infrastructuur;
• accounts, domeinen en repositories;
• onderhoud en doorontwikkeling.

Wanneer deze verantwoordelijkheden niet expliciet worden verdeeld, ontstaan ze vanzelf. Meestal bij de partij die op dat moment de meeste kennis of toegang heeft.

Dat kan jarenlang goed gaan. Totdat de samenwerking verandert, een medewerker vertrekt of de organisatie plotseling sneller moet kunnen handelen.

De goedkoopste bouw is niet altijd de voordeligste keuze

In selecties krijgt de initiële investering vaak veel gewicht. Dat is begrijpelijk. Het bedrag is concreet, staat in een offerte en moet vooraf worden goedgekeurd.

De kosten na de livegang zijn minder zichtbaar.

Denk aan updates, licenties, hosting, ondersteuning, trainingen, doorontwikkeling en het vervangen van koppelingen. Maar ook aan de tijd die nodig is om beslissingen te nemen en wijzigingen uit te voeren.

Hoeveel mensen zijn betrokken bij een kleine aanpassing? Hoe lang duurt het voordat een wijziging kan worden ingepland? Hoeveel leveranciers moeten samenwerken voor een release? En hoe snel kan de organisatie reageren op nieuwe wetgeving, veranderend gedrag of een onverwachte kans?

De duurste afhankelijkheid staat niet altijd op een factuur. Soms zit zij in de weken die nodig zijn om een relatief kleine wijziging door te voeren, de drie partijen die daarvoor moeten afstemmen of de kennis die eerst opnieuw moet worden opgebouwd.

Een platform dat goedkoop wordt gebouwd maar moeilijk te beheren is, kan over een periode van vijf jaar veel duurder uitvallen. Andersom kan een hogere investering in architectuur, toegankelijkheid, documentatie of redactioneel beheer later juist ruimte en snelheid opleveren.

Daarom hoort bij een platformkeuze altijd een beeld van de volledige levenscyclus. Niet alleen tot aan de livegang, maar tot aan de volgende grote verandering.

De kwaliteit van een platform wordt uiteindelijk niet zichtbaar op de dag dat het wordt opgeleverd. Zij wordt zichtbaar wanneer de organisatie iets wil aanpassen.

Digitale volwassenheid bepaalt welke oplossing past

Niet iedere organisatie kan dezelfde vrijheid, complexiteit of verantwoordelijkheid dragen.

Een zeer flexibel platform kan goed passen bij een organisatie met duidelijke governance, ervaren redacteuren, een product owner en structureel budget voor doorontwikkeling. Voor een kleinere organisatie zonder interne technische kennis kan een meer gestandaardiseerde oplossing verstandiger zijn.

Dat betekent niet dat de kleinere organisatie minder ambitieus is. De oplossing moet alleen aansluiten op wat zij kan organiseren.

Ik zie regelmatig dat organisaties kiezen voor maximale flexibiliteit omdat dit toekomstbestendig klinkt. In de praktijk betekent die flexibiliteit vaak dat er ook meer keuzes moeten worden gemaakt. Over componenten, autorisaties, contentmodellen, koppelingen, releases en kwaliteit.

Wanneer niemand daarvoor tijd, kennis of mandaat heeft, verandert flexibiliteit langzaam in complexiteit.

De beste oplossing is daarom niet het platform met de meeste mogelijkheden. Het is het platform waarvan de mogelijkheden aansluiten op de volwassenheid en ambities van de organisatie.

Dat vraagt om een eerlijk beeld van de interne situatie:

• Is er iemand die productkeuzes kan maken?
• Is er voldoende kennis om leveranciers goed aan te sturen?
• Kan de organisatie structureel investeren in onderhoud en verbetering?
• Zijn redacties in staat om zelfstandig kwaliteit te bewaken?
• Is er intern eigenaarschap over data, privacy en toegankelijkheid?
• Kan de organisatie omgaan met de vrijheid die het platform biedt?

Een platform kan de organisatie ondersteunen, maar neemt deze verantwoordelijkheden niet weg.

Begin niet met de lijst van functies

Een lange lijst met eisen lijkt zekerheid te geven. In de praktijk worden uiteenlopende wensen daarin vaak gelijkwaardig behandeld.

Een voorkeur van één afdeling staat dan naast een voorwaarde die bepalend is voor de continuïteit van de hele organisatie. Alles krijgt het label must-have, waardoor het steeds moeilijker wordt om echte keuzes te maken.

Ik begin daarom liever niet met functionaliteit, maar met een beperkt aantal strategische vragen:

• Welk probleem moet het platform werkelijk oplossen?
• Welke processen en verantwoordelijkheden veranderen hierdoor?
• Wie wordt eigenaar van product, inhoud, data en techniek?
• Welke kennis moet intern aanwezig blijven?
• Waar mag de organisatie bewust afhankelijk van zijn?
• Welke veranderingen moeten over vijf jaar nog eenvoudig mogelijk zijn?
• Hoe ziet een overstap naar een andere partij of oplossing eruit?

Vooral de vraag waar een organisatie bewust afhankelijk van mag zijn is belangrijk.

Volledige onafhankelijkheid is meestal niet haalbaar en ook niet altijd wenselijk. Een organisatie hoeft niet alle kennis zelf in huis te hebben en hoeft niet ieder technisch onderdeel zelfstandig te kunnen beheren.

Afhankelijkheid is niet per definitie verkeerd. Onbewuste of onbeheersbare afhankelijkheid wel.

Het doel is daarom niet om iedere leverancier overbodig te maken. Het doel is om te begrijpen waar de afhankelijkheden zitten, welke risico’s daarbij horen en welke afspraken nodig zijn om ze beheersbaar te houden.

Pas daarna wordt duidelijk welke functionaliteit, architectuur en technologie werkelijk nodig zijn.

Kijk ook naar de weg terug

Bij iedere belangrijke digitale keuze hoort een exitvraag.

Wat gebeurt er als de leverancier stopt, de samenwerking niet meer werkt of het platform niet langer aansluit op de organisatie?

Kan de organisatie haar data volledig exporteren? Is de code beschikbaar? Zijn configuratie en infrastructuur gedocumenteerd? Kan een andere partij het beheer redelijkerwijs overnemen? En wie bezit de accounts, domeinen, repositories en sleutels?

Een exitstrategie is geen teken van wantrouwen. Het is normaal risicobeheer. Goede leveranciers begrijpen dat en richten hun samenwerking zo in dat een opdrachtgever niet onnodig gevangen raakt.

Maar overdraagbaarheid gaat verder dan toegang tot code en data.

Een nieuwe partij moet ook kunnen begrijpen waarom het platform is ingericht zoals het is. Welke uitzonderingen bestaan er? Welke koppelingen zijn kwetsbaar? Welke keuzes zijn bewust gemaakt en welke zijn historisch ontstaan?

Een codebase kan volledig beschikbaar zijn en alsnog nauwelijks overdraagbaar blijken.

Goede overdraagbaarheid vraagt daarom ook om:

• actuele technische documentatie;
• vastgelegde architectuurkeuzes;
• inzicht in processen en uitzonderingen;
• overdraagbare accounts en toegangsrechten;
• duidelijke afspraken over eigendom;
• voldoende intern eigenaarschap om een overdracht te begeleiden.

De vraag is niet alleen of een organisatie kan vertrekken, maar ook hoeveel tijd, geld en risico daarmee gemoeid zijn.

Een digitale keuze is uiteindelijk een organisatiemodel

Technologie bepaalt niet alles, maar legt wel veel vast.

Een platform maakt sommige handelingen eenvoudig en andere moeilijk. Het geeft bepaalde mensen vrijheid en maakt anderen afhankelijk. Het versnelt processen of voegt juist controles toe. Het bepaalt hoeveel kennis nodig is en waar die kennis komt te liggen.

Daarom moet een platformkeuze niet uitsluitend bij techniek of inkoop worden neergelegd. Ook de mensen die verantwoordelijk zijn voor strategie, content, dienstverlening, privacy, toegankelijkheid en continuïteit moeten begrijpen welke richting wordt gekozen.

Dat betekent niet dat iedereen zich met iedere technische keuze moet bemoeien. Wel dat de organisatorische gevolgen onderdeel moeten zijn van het besluit.

De kwaliteit van een digitale keuze wordt niet bepaald op de dag van de livegang. Zij wordt zichtbaar in de jaren erna: wanneer de organisatie wil veranderen, een leverancier moet vervangen, nieuwe wetgeving moet verwerken of onverwacht moet opschalen.

Wie alleen een platform selecteert, kiest vooral voor functionaliteit.

Wie strategisch kiest, bepaalt ook waar kennis, zeggenschap en verantwoordelijkheid komen te liggen.

Een digitale keuze is daarmee nooit alleen technisch. Zij is een ontwerp voor de manier waarop een organisatie straks kan werken, beslissen en veranderen.