Help, de boom is weg!

 

Hoe richt je als organisatie het SharePoint platform in als een portal die de efficiëntie en effectiviteit van de medewerkers kan vergroten. We horen en lezen veel over Het Nieuwe Werken, maar vaak is niet duidelijk hoe de eerste stappen te maken.

 

De titel voor dit artikel heb ik niet zelf verzonnen. Hij komt van een van onze klanten in het onderwijs. Na het gezamenlijk opzetten van een informatiearchitectuur voor hun nieuwe portal en dit vertaald te hebben naar een blauwdruk voor het inrichten van de portal in Microsoft Office SharePoint Server 2007, heeft de klant de eigen organisatie moeten overtuigen van de ‘nieuwe’ aanpak. In een organisatie waar men gewend is de informatie in een portal op te slaan in een hiërarchische structuur was de nieuwe informatiearchitectuur veel meer ingericht rond de eindgebruiker. De presentatie “Help, de boom is weg” had dan ook als doel de impact duidelijk te maken binnen de organisatie. De hiërarchische manier van informatie opslaan maakt plaats voor een nieuwe manier om met informatie werken. 

 

Men is gewend te denken in hiërarchische structuren als het gaat om organisaties en informatie die in deze organisaties wordt opgeslagen. Immers voor een handboek voor product A moet ik bij Afdeling X zijn e.d. Iedereen weet wat voor een crime het is dit soort hiërarchische structuren beheersbaar te houden in een intranet of portal omgeving. Wie heeft niet gehoord dat er teveel “sites” zijn op het intranet. Dat het intranet te vol en ondoorzichtig is geworden. Het kost (nieuwe) medewerkers altijd enige tijd om hun weg te vinden naar de juiste informatie. Het leidt tot veel dubbeling van zelfde informatie (ik wil het document immers op mijn afdelingssite hebben) en hiermee tot onbetrouwbare informatie. Immers welke bron is de waarheid. Is een organisatie inmiddels gewend aan een bepaalde structuur dan is het veranderen van deze structuur vaak een organisatorische en niet technische uitdaging.

 

Op de vraag of dit betekent  dat u uw “boom” in uw intranet of portal weg moet halen Is niet direct ja. Tenminste niet zonder hier goed over na te denken. De basisvraag die Rubicon altijd stelt is waar u uw portal(en) voor wilt gaan gebruiken. U kunt deze vraag beantwoorden door te kijken naar de drieluik, informatie, doelgroep  en functionaliteit. Deze schetsen de behoefte van de organisatie die u dan kunt vertalen naar een informatiearchitectuur die de behoefte vervult. Hierbij wordt ook de impact op beheer en migratie in de toekomst als ontwerpregel meegenomen. Immers een omgeving die 100 procent voldoet aan de wensen van de eindgebruiker, maar onmogelijk is te beheren levert in het eind geen enkele winst op.

 

Nadat we de behoefte geschetst hebben en weten wie binnen de organisatie deze behoeftes hebben is de volgende stap in het vaststellen van de informatiearchitectuur, het bepalen van enkele basisregels die uw organisatie aan een portal wil stellen. Gaan we uit van een gebruikercentrale of een organisatie centrale aanpak bijvoorbeeld, of een gezonde mix. Het Nieuwe Werken focust zich duidelijk rond een hele sterke gebruikers centrale aanpak. Dit ziet u dan ook duidelijk terugkomen in de meeste producten van Microsoft en de functionele mogelijkheden van SharePoint in het bijzonder. Laten we in dit artikel ook de gebruikerscentrale aanpak als basisregel nemen. Dit betekent dat we vanuit de gebruiker moeten denken en straks ook ons resultaat hierop kunnen testen. Als gebruiker of medewerker heb ik immers informatie nodig om mijn werk te kunnen doen, produceer ik zelf informatie die anderen nodig hebben en wil ik kunnen samenwerken met anderen, eenvoudig informatie kunnen vinden, mijn uren kunnen boeken, etc…

De tweede regel is dat we informatie die relevant is voor de eindgebruiker zo dicht mogelijk naar hem of haar brengen. Lees hier, in zo min mogelijk clicks naar de meest relevante en dagelijks gebruikte informatie. Dit zal voor elke type medewerker in uw organisatie anders zijn. De derde en voor dit voorbeeld laatste basisregel is dat informatie eenvoudig vindbaar moet zijn.

 

Deze basisregels kunnen we faciliteren middels twee ontwerprichtlijnen voor onze informatie architectuur. Door de informatiearchitectuur “plat” te houden en functionele ingangen te bieden aan eindgebruiker is het zoeken naar de juiste ingang voor informatie beduidend eenvoudiger. Immers voor handboek van product A ga ik naar het onderdeel producten, waar de gehele organisatie haar product informatie beheert, ongeacht welke afdeling. De tweede richtlijn is het gebruik van metadata. We gaan informatie voorzien van kenmerken, zoals type informatie, afdeling, eigenaar, etc… Kenmerken die het eenvoudig maken om informatie middels personalisatie dichter bij de eindgebruiker te brengen, maar vooral het mogelijk maken om zoeken binnen de organisatie om te zetten naar vinden.

 

De conclusie die we kunnen trekken is dat u voor het opzetten van een goede informatiearchitectuur van uw SharePoint omgeving, u even stil moet staan bij een aantal vragen zoals deze geschetst zijn in dit artikel. Middels het beantwoorden van deze vragen creëert u handvaten om een juiste structuur aan te brengen in uw intranet of portal omgeving. Dit gaat uiteraard op voor elke portal of intranet product dat u gebruikt. Rubicon helpt haar klanten middels haar iView aanpak in dit soort trajecten om niet alleen de informatiearchitectuur vast te stellen, maar deze ook te vertalen naar een (technische) blauwdruk voor MOSS 2007 en een roadmap om dit binnen de organisatie ingeregeld te krijgen. De behoefte vaststelling schetst altijd een utopie die we in de praktijk op een zo gebruikers- en investeringsvriendelijke manier proberen te bereiken.

 

Wilt u meer weten over de Rubicon iView aanpak voor SharePoint voor het bepalen van uw SharePoint informatiearchitectuur, neem dan gerust contact op met ons op.

 

Publicatiedatum: 19 maart 2009