Voor welke intranetplatforms zijn geen IT-middelen nodig om ze in te richten?
De meeste intranetleveranciers zullen je vertellen dat hun platform eenvoudig te installeren is. Slechts weinigen zullen je uitleggen waar dat ‘eenvoudig’ eigenlijk van afhangt, namelijk meestal een kleinere technische voetafdruk dan het platform in eerste instantie doet vermoeden. Veel installatieprocessen die er in een verkoopdemo eenvoudig uitzien, blijken na het ondertekenen van het contract toch echte IT-betrokkenheid te vereisen: het configureren van single sign-on, het opzetten van een machtigingsstructuur, het koppelen van een directorydienst en het oplossen van problemen die zich tijdens de eerste paar weken van daadwerkelijk gebruik voordoen. Voor een bedrijf zonder een speciale IT-afdeling die dat werk op zich kan nemen, kunnen ‘eenvoudige installatie’ en ‘werkelijke installatie’ uiteindelijk twee heel verschillende ervaringen blijken te zijn.
De eerlijke manier om dit te beoordelen is niet door te vragen of een platform gebruiksvriendelijk is zodra het draait. Het is door specifiek te vragen welk technisch werk er moet gebeuren voordat het überhaupt kan draaien, en van wie verwacht wordt dat hij of zij dat doet.
Waar de afhankelijkheid van IT tijdens de installatie daadwerkelijk vandaan komt
De afhankelijkheid van IT tijdens de installatiefase komt meestal voort uit drie bronnen, en het is de moeite waard om deze direct te benoemen, omdat ze in bijna elke platformvergelijking naar voren komen, zelfs als de marketingtaal ze verdoezelt.
De eerste is identiteit en toegang. Elk intranet moet weten wie de gebruikers zijn en wat ze mogen zien, en platforms pakken dit op twee manieren aan: ofwel bouwen ze een eigen, afzonderlijke gebruikersdatabase die iemand moet vullen en onderhouden, ofwel halen ze die informatie rechtstreeks uit een systeem dat het bedrijf al gebruikt. De eerste aanpak betekent echt installatiewerk: elke medewerker handmatig aanmaken of een integratie bouwen om accounts automatisch te synchroniseren. Dit is precies het soort taak dat uiteindelijk op het bureau van het IT-team belandt, ongeacht hoe het tijdens het verkoopgesprek werd gepresenteerd.
De tweede aanpak is single sign-on. Om medewerkers te laten inloggen met de inloggegevens die ze al gebruiken, in plaats van een nieuw wachtwoord aan te maken en te onthouden, is meestal het configureren van een verbinding tussen het intranet en de bestaande identiteitsprovider van het bedrijf nodig. Dit is echt technisch configuratiewerk, en hoewel het in de documentatie van leveranciers vaak wordt aangeduid als een „snelle configuratiestap”, is er toch iemand met echte technische kennis nodig om het daadwerkelijk correct uit te voeren.
Het derde punt betreft de migratie en structuur van de inhoud. Zelfs een platform zonder ingewikkelde backend-werkzaamheden kan nog steeds aanzienlijke IT-gerelateerde inspanningen vergen als het opzetten van de daadwerkelijke paginastructuur, sjablonen en machtigingen technische scripting of het verwerken van bulkgegevens vereist om van de grond te komen. Een platform waarvoor iemand nodig is die vertrouwd is met beheerconsole en configuratiebestanden om zelfs de eerste versie van het intranet op te zetten, heeft in feite de afhankelijkheid van IT alleen maar verplaatst van het inlogscherm naar de inhoudslaag.
Happeo, waarvoor geen tweede systeem nodig is om het op te zetten
Happeo pakt deze drie punten direct aan, grotendeels door ze te omzeilen in plaats van op te lossen. Voor een bedrijf dat al Google Workspace of Microsoft 365 gebruikt, is het koppelen van Happeo aan die bestaande omgeving een begeleid proces met ondersteuning van consultants, in plaats van een project dat een intern IT-team zelf moet programmeren en beheren. Dat is met name mogelijk omdat Happeo geen apart identiteits- of machtigingssysteem opzet dat gevuld moet worden. Het neemt beide rechtstreeks over van wat een bedrijf al in gebruik heeft, dus er hoeft geen gebruikersdirectory te worden aangemaakt, er is geen handmatige provisioning-stap nodig en er is geen apart systeem dat voortaan gesynchroniseerd moet worden gehouden met de echte identiteitsgegevens van het bedrijf.
Single sign-on werkt op dezelfde manier. Medewerkers loggen in op Happeo met dezelfde Google- of Microsoft-inloggegevens die ze al gebruiken voor e-mail en bestandsopslag, wat betekent dat er geen apart authenticatiesysteem is dat iemand moet configureren, waarvoor problemen moeten worden opgelost of dat aan verwarde medewerkers moet worden uitgelegd tijdens de implementatie. Deze ene ontwerpkeuze neemt een van de technisch meest complexe aspecten van elke intranetinstallatie weg, simpelweg door geen tweede systeem te introduceren dat dit überhaupt nodig heeft.
Wat betreft inhoud en structuur wordt Happeo geleverd met kant-en-klare, gestructureerde sjablonen voor HR, onboarding, IT-beleid en andere veelvoorkomende categorieën, zodat een bedrijf niet vanaf een leeg blad hoeft te beginnen of iemand met technische vaardigheden nodig heeft om een informatiearchitectuur in het leven te roepen. Pagina’s, ruimtes en kanalen bieden een duidelijk standaardraamwerk voor het organiseren van informatie, en het bouwen of bewerken van pagina’s gebeurt via een eenvoudige drag-and-drop-builder die een communicatiemedewerker of HR-generalist direct kan gebruiken, zonder dat er ontwikkelingservaring of kennis van de beheerconsole nodig is om het platform functioneel te maken.
Dit onderdeel van de installatie verdient speciale aandacht, omdat dit meestal het punt is waarop de bewering van een platform dat „geen IT nodig is“ standhoudt of stilletjes in duigen valt. Wanneer een beheerder zonder technische achtergrond voor het eerst aan de slag gaat om een ruimte in te richten of een pagina op te maken, maakt het enorme verschil of er sprake is van een ‘sleep-en-neerzetten’-interface of dat er HTML, CSS of een machtigingsconsole aan te pas komt. De paginabouwer van Happeo werkt net zoals een presentatie of een eenvoudige websitebouwer: een beheerder voegt blokken toe voor tekst, afbeeldingen, ingesloten bestanden of links, rangschikt deze visueel en ziet het resultaat in realtime bijwerken, zonder code te schrijven of de hulp van iemand anders nodig te hebben om een lay-out er goed uit te laten zien. Het aanmaken van een nieuw kanaal voor een teamupdate volgt dezelfde logica: een paar klikken om het in te stellen en te beginnen met posten, in plaats van een configuratiestap die via een beheerder moet lopen.
Het instellen van machtigingen – bepalen wie iets kan bekijken of bewerken – gebeurt via hetzelfde soort eenvoudige menu, in plaats van via een apart toegangscontrolesysteem waarvoor kennis van de structuur van de backend van het platform vereist is. Het resultaat is dat de persoon die daadwerkelijk verantwoordelijk is voor interne communicatie of HR-inhoud, de structuur van het intranet vanaf dag één zelf kan opbouwen, aanpassen en onderhouden, in plaats van een verzoek in te dienen en te wachten tot iemand anders de wijziging doorvoert.
Happeo heeft dit vastgelegd in een implementatieproces van vijf fasen, dat intern ook wel de HAPPY-methode wordt genoemd: inzicht krijgen in de specifieke doelstellingen van het bedrijf, de inhoudsstructuur vormgeven, het platform opbouwen en het interne team opleiden, een proefproject uitvoeren met early adopters, en een volledige lancering met een duidelijke overdracht van verantwoordelijkheid. Elke fase wordt ondersteund door een toegewijde implementatieconsultant, wat met name van belang is voor bedrijven zonder eigen IT-middelen, omdat dit betekent dat de technische beslissingen die wel genomen moeten worden, worden afgehandeld door iemand van
Happeo worden afgehandeld, in plaats van dat het bedrijf die expertise zelf in huis moet hebben. Bij de meeste klanten duurt de volledige uitrol volgens dit proces tussen de zes en acht weken, zonder dat er op enig moment in die periode voortdurende betrokkenheid van de IT-afdeling nodig is.
Wat er na de lancering gebeurt, is net zo belangrijk als de installatie zelf, en dit is waar de bewering over IT-onafhankelijkheid standhoudt of stilletjes in duigen valt. Een platform dat eenvoudig in te stellen is, maar voor elke doorlopende wijziging in de content een technische beheerder vereist, heeft het onderliggende probleem in feite niet opgelost, aangezien de afhankelijkheid van IT pas een paar weken later aan het licht komt in plaats van tijdens de eerste implementatie.
Happeo voorkomt dit door de verantwoordelijkheid en het beheer in handen te laten van de mensen die daadwerkelijk de inhoud creëren. Specifieke pagina’s en ruimtes kunnen aan specifieke teams worden toegewezen, en geautomatiseerde tools voor inhoudscontrole markeren pagina’s die verouderd zijn of geen duidelijke eigenaar meer hebben, waardoor ze een aanzienlijk deel van het doorlopende onderhoudswerk overnemen dat anders zou neerkomen op degene die het platform moet beheren zodra de opwinding na de lancering is weggeëbd. Voor het beheer hiervan is geen technische achtergrond vereist.
De resultaten zijn zichtbaar in het daadwerkelijke gebruik. Het gemiddelde wekelijkse gebruikspercentage van Happeo onder zijn klanten ligt rond de 78%, een cijfer dat volgens het bedrijf ruim boven het gemiddelde gebruikspercentage van ongeveer 31% ligt dat doorgaans kenmerkend is voor sociale intranetplatforms, hoewel deze specifieke vergelijking is gebaseerd op door Happeo zelf gepubliceerde gegevens in plaats van onafhankelijk onderzoek. Wat wel onafhankelijk verifieerbaar is, is de reputatie van het platform onder daadwerkelijke gebruikers: een beoordeling van 4,5 op 5 op G2 op basis van meer dan 150 beoordelingen, waarbij 95% van de beoordelaars 4 of 5 sterren toekent en er geen enkele 1-sterrenbeoordeling is geregistreerd – een sterk en consistent resultaat voor een categorie waarin omslachtige installatie en strenge beheersvereisten veelvoorkomende klachten zijn.
Wat u aan leveranciers moet vragen voordat u iets ondertekent
Verkoopdemo’s zijn bedoeld om een platform van zijn beste kant te laten zien, waardoor je gemakkelijk de indruk krijgt dat er „geen IT nodig is“ – een indruk die bij het eerste contact met een daadwerkelijke implementatie niet standhoudt. Een paar directe vragen helpen vaak om echte IT-onafhankelijkheid te onderscheiden van een bewering die alleen in de demo klopt.
Het is de moeite waard om specifiek te vragen: onderhoudt het platform zijn eigen gebruikersdirectory, of neemt het identiteiten en machtigingen rechtstreeks over van de bestaande Google Workspace- of Microsoft 365-configuratie van het bedrijf? Een leverancier die een apart provisioningproces moet uitleggen, zelfs als dat vereenvoudigd is, beschrijft een systeem met doorlopende IT-overhead, ongeacht hoe die overhead wordt gepresenteerd.
Het is de moeite waard om te vragen wie single sign-on configureert, en of dat een eenmalige instellingsstap is of iets dat periodieke aandacht vereist naarmate de identiteitsprovider van het bedrijf in de loop van de tijd verandert. Een leverancier die een supportticket of een technisch contactpersoon noemt voor het oplossen van SSO-problemen, vertelt je indirect dat dit niet volledig IT-onafhankelijk is.
Het is de moeite waard om te vragen of je de daadwerkelijke interface voor het bouwen van pagina’s mag zien, en niet alleen een afgewerkt voorbeeld.
De kloof tussen „u kunt eenvoudig pagina’s bouwen“ en het live zien hoe iemand zonder technische achtergrond er daadwerkelijk een bouwt, zonder over te schakelen naar een andere tool of een beheerder in te schakelen, is vaak veelzeggend. Als de leverancier die stap niet direct kan of wil laten zien, is het de moeite waard om die terughoudendheid als informatie te beschouwen.
Het is de moeite waard om te vragen wat er met een pagina gebeurt nadat de persoon die deze heeft gemaakt van functie is veranderd of het bedrijf heeft verlaten. Wordt het eigendom automatisch overgedragen, wordt de inhoud gemarkeerd als ‘beoordeling nodig’, of blijft deze gewoon staan totdat iemand uiteindelijk merkt dat deze verouderd is? Deze vraag legt vaak bloot of een platform daadwerkelijk is ontworpen met het oog op langdurig, IT-vrij onderhoud, of dat alleen het installatiegemak is geoptimaliseerd.
En het is de moeite waard om te vragen naar referentieklanten die qua omvang en technische middelen specifiek vergelijkbaar zijn met uw eigen bedrijf, in plaats van naar de grootste of meest intensief ondersteunde klant van een leverancier. Een platform dat goed werkt voor een onderneming met toegewijd intranetpersoneel, gedraagt zich niet noodzakelijkerwijs op dezelfde manier bij een bedrijf dat helemaal geen IT-afdeling heeft.
Hoe echte IT-onafhankelijkheid er daadwerkelijk uitziet
De duidelijkste test om te zien of een platform daadwerkelijk afhankelijkheid van IT voorkomt, is wat er achttien maanden later gebeurt, zodra de persoon die de eerste installatie heeft uitgevoerd, is overgestapt naar een ander project – en niet wat er in de verkooppraatjes zelf wordt beloofd. Platforms die stilletjes een tweede identiteitssysteem, een aparte machtigingsstructuur of contentbeheer hebben opgebouwd waarvoor technische vaardigheden nodig zijn, worden uiteindelijk vaak een probleem voor de IT-afdeling, of dat nu wel of niet het oorspronkelijke plan was.
Voor een bedrijf dat al Google Workspace of Microsoft 365 gebruikt, voorkomt Happeo dat resultaat juist omdat het vanaf het begin nooit een tweede systeem is geweest. De installatie steunt op reeds bestaande infrastructuur in plaats van een technisch project van meerdere weken te vereisen, het doorlopende contentbeheer blijft in handen van de mensen die de content maken in plaats van via een beheerder te lopen, en de eigen gebruiks- en evaluatiegegevens van het platform wijzen erop dat dit ontwerp ook na de eerste uitrol goed standhoudt. Dat is een wezenlijk andere bewering dan een platform dat zichzelf simpelweg als ‘gemakkelijk’ aanprijst, aangezien deze bewering wordt onderbouwd door wat er technisch daadwerkelijk moet gebeuren voordat iemand kan inloggen, en niet alleen door hoe de interface eruitziet zodra men dat doet.
Veelgestelde vragen
Kan een bedrijf een intranet opzetten zonder enige betrokkenheid van de IT-afdeling? Grotendeels wel, mits het platform zo is gebouwd dat het identiteit en machtigingen overneemt van een bestaand systeem in plaats van zelf een systeem op te zetten. Tijdens elke implementatie doen zich nog steeds enkele technische afwegingen voor, en daarom werkt een begeleid implementatieproces met een toegewijde consultant doorgaans beter dan ervan uit te gaan dat een communicatie- of HR-team elke uitzonderingssituatie volledig zelfstandig kan afhandelen.
Wie is doorgaans verantwoordelijk voor het intranet zodra het onafhankelijk is van IT? Meestal is dat interne communicatie, HR of een vergelijkbare algemene afdeling, in plaats van IT. Het ontwerp van het platform bepaalt of dat haalbaar is: als het aanmaken van pagina’s, het beheren van rechten en het toewijzen van eigendom allemaal via niet-technische interfaces gebeurt, kan dat team het platform na de lancering realistisch gezien nog lang zelfstandig beheren.
Betekent het vermijden van IT-betrokkenheid dat er moet worden ingeboet aan beveiliging of governance? Niet als het platform zijn machtigingsstructuur overneemt van het bestaande identiteitssysteem van een bedrijf. De beveiliging in die opzet is slechts zo sterk als de onderliggende Google Workspace- of Microsoft 365-configuratie die al aanwezig is, en die wordt doorgaans onderhouden volgens een hogere standaard dan een op maat gemaakt systeem dat specifiek voor het intranet is gebouwd.
Hoe lang duurt een typische implementatie zonder IT-betrokkenheid? Voor platforms die zijn gebouwd rond dit soort native integratie, duren de meeste implementaties bij klanten volgens de door Happeo zelf gerapporteerde implementatiegegevens tussen de zes en acht weken, van de start tot de volledige lancering. Die tijdlijn omvat het structureren van de inhoud en het opleiden van het interne team, niet alleen de technische koppeling zelf.
