remco header

Een nieuw intranet: breng alvast de techniek in kaart!

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Ga je aan de slag met een nieuw intranet? Dan is het belangrijk om vooraf alvast de technische architectuur in kaart te brengen met de afdeling ICT en met de leverancier.

Door geformuleerde doelen en de analyse van gebruikers als leidraad te gebruiken, voorkom je dat technische uitgangspunten de functionaliteit van het nieuwe intranet gaan bepalen. In de perfecte wereld zou de techniek gewoon dát moeten faciliteren wat de organisatie vraagt, maar de praktijk is een stuk weerbarstiger. In dit artikel lees je meer:

Programma van eisen

Voorafgaand aan de aanbesteding of gunning van het intranet aan een leverancier, wordt vaak gewerkt met een Programma van Eisen waar eenvoudige “kan wel of kan niet” vragen in staan. Maar hoe verhouden deze eenvoudige vragen zich eigenlijk tot de praktijk?

Een voorbeeld:

Vraag klant: Kan onze SharePoint omgeving gekoppeld worden met het intranet?

Antwoord leverancier: Ja, dit is mogelijk.

Vraag klant: Kunnen onze medewerkers door middel van Single Sign-on inloggen op het intranet?

Antwoord leverancier: Ja, dit is mogelijk door te koppelen met Active Directory.

Vraag klant: Kunnen we externe gebruikers uitnodigen op het intranet?

Antwoord leverancier: Ja, dit is standaard functionaliteit binnen ons pakket.

Vraag klant: Kan de oplossing in de cloud gehost worden?

Antwoord leverancier: Ja, dit is mogelijk.

Op het eerste gezicht zijn de gevraagde functionaliteiten vaak geen probleem, maar hoe zit dit als het verder wordt onderzocht?

Gevraagde eisen verder onderzocht

Neem bijvoorbeeld de functionaliteit om met Single Sign-on in te loggen op het intranet. Dit houdt in dat medewerkers bij het opstarten van hun pc en het invullen van hun gebruikersnaam en wachtwoord, ook meteen zijn ingelogd op het intranet.

De leverancier geeft in bovenstaand voorbeeld aan dat dit mogelijk is door te koppelen met Active Directory, dus dat klinkt goed!

Even voor niet-techneuten: met een Active Directory kunnen ICT-beheerders van de organisatie centraal beheren wie toegang heeft tot het organisatiedomein. Met andere woorden, zodra gebruikers inloggen op hun PC, worden de inloggegevens vergeleken met de gegevens in de Active Directory en krijgt men automatisch toegang tot gekoppelde systemen, zoals het intranet.

Maar de vragen die eigenlijk van belang zijn om ervoor te zorgen dat medewerkers meteen zijn ingelogd, gaan verder. Dat zijn vragen als: Hoe zit het eigenlijk met de kwaliteit van de gegevens in de Active Directory van de organisatie? Staat elke medewerker hier in of maakt de organisatie gebruik van afdelingsaccounts? Staan tijdelijke krachten en externe medewerkers wel in de Active Directory? Wordt de Active Directory automatisch en tijdig bijgewerkt wanneer er nieuwe mensen in dienst treden of de organisatie verlaten?

Stel de juiste vragen in het programma van eisen

De uitdagingen worden groter als de gevraagde functionaliteiten elkaar gaan raken en kruisverbanden gaan vormen. Kunnen gebruikers bijvoorbeeld, op basis van hun Active Directory account, Single Sign-on inloggen op het intranet als deze in de Cloud wordt gehost? En kan het Cloud gehoste intranet op basis van deze gegevens ook documenten vanuit de interne SharePoint omgeving tonen? Hoe kunnen externe gebruikers inloggen op het intranet en moeten deze gebruikers ook toegevoegd worden aan de Active Directory? Hebben externe gebruikers ook toegang tot informatie in de interne SharePoint omgeving?

Met andere woorden: Je ziet in het voorbeeld vier keer een ‘Ja’ ingevuld, maar als je de verschillende gevraagde elementen met elkaar gaat combineren, dan is het goed mogelijk dat de werkelijkheid een stuk complexer is. De afdeling IT en de leverancier kunnen je helpen om gezamenlijk de uitdagingen en (on)mogelijkheden boven water te krijgen.

Technisch ontwerp

Niet alleen de leverancier speelt een rol om tot een Technisch Ontwerp te komen, maar ook de afdeling IT. Samen kan een goede fasering uitgedacht worden waarin rekening is gehouden met de doorontwikkeling van het product van de leverancier, technische (on) mogelijkheden en de reeds uitgestippelde planning voor de aanschaf of upgrade van de te koppelen systemen.

Op deze manier voorkom je verrassingen tegen het einde van het project waar vaak geen tijd of budget meer over is. Testomgevingen zijn een goed middel om technische problemen vroegtijdig op te sporen.

Testomgeving

Wij hebben goede ervaringen met het zover mogelijk naar voren halen van complexe of cruciale functionaliteiten en uitdagingen. Je kunt een testomgeving al vroeg in het project gebruiken om bepaalde koppelingen of functionaliteiten te testen. Hierdoor worden technische complicaties snel zichtbaar.

Wordt er intern bijvoorbeeld gewerkt in een Citrix-omgeving? Zorg dan dat daar alvast een testomgeving draait en begin zo snel mogelijk met het ontwikkelen en testen van de koppelingen en functionaliteiten in die omgeving.

In bouwfase zo min mogelijk onzekerheden

Door het vroegtijdig testen van cruciale koppelingen en functionaliteit, voorkom je dat er nog veel onzekerheden zijn in de bouwfase. In de bouwfase kun je deze onzekerheid niet gebruiken, want dit zorgt voor veel stress en kan leiden tot het noodgedwongen moeten uitstellen van de deadline.

Nog vragen?

Heb je na het lezen van dit artikel nog vragen? Neem dan gerust contact met ons op!

Wil je nog meer lezen? Dit artikel verscheen tevens (hoofdstuk 4) in ons boek ‘Een succesvol social intranet in een snel veranderende wereld’.

Download Ebook In 7 stappen naar een succesvol social intranet

Download Ebook In 7 stappen naar een succesvol social intranet-mobile

Facebooktwitterpinterestlinkedinyoutubeinstagram