De behoefte aan structuur is vaak generiek en ontstaat vaak aan twee kanten.
- Als je als beheerder iets wilt beheren of controleren dan heb je behoefte aan structuur en ordening. Als deze te star is, dan zit je eindgebruikers in de weg. Het is echter onmogelijk te automatiseren als er geen structuur te ontdekken valt.
- Als je als eindgebruiker de weg makkelijk wilt vinden dan heb je behoefte aan overzicht en dus ook structuur. Je raakt anders de weg kwijt in de ‘brei’ aan informatie.
Nu denkt een beheerder van een systeem vaak aan een standaard structuur voor iedereen en een eindgebruiker aan een structuur voor zichzelf. Aan de eigenaar van Office365 (heb je die al?) de schone taak om hier tussen een evenwichtige balans te organiseren. De structuur die voor iedereen, voor een team en voor een individu als logisch ervaren wordt verschilt namelijk ….
Over het algemeen kent SharePoint de volgende hiërarchie:
- Platform: Microsoft is hier de baas en brengt frequent nieuwe functionaliteiten uit.
- Tenant: de omgeving van je eigen school. Hier zijn enkele organisatie-specifieke instellingen te configureren. Dat wordt meestal door een beheerder uitgevoerd.
- Sitecollecties: een verzameling teamsites.
- Teamsites: een verzameling van functionaliteiten voor samenwerking.
- Apps: dat kunnen bijvoorbeeld bibliotheken, lijsten, aankondigingen zijn.
- Items: de afzonderlijke mappen/bestanden of lijstitems.
Je kunt er voor kiezen om met sitecollecties niet zoveel te doen en iedereen, middels self-service, teamsites te laten aanmaken. Binnen dezelfde collectie. Het andere uiterste is dat je elke teamsite als beheerder aanmaakt en bevolkt met de juiste mensen.
In het eerste geval ligt de verantwoordelijkheid compleet bij de eindgebruikers. Het kan organisch snel groeien, aangezien het als heel laagdrempelig ervaren wordt. De hoeveelheid teamsites zal op zich niet storend zijn aangezien je niet snel tegen het maximum van je tenant oploopt. Als er meerdere teamsites dubbel ontstaan dan moet de organisatie dit zelf oplossen.
In het andere geval heb je veel werk als beheerder. Het aanmaken van sites en toevoegen van groepen is nogal herhalend. Het werpt ook een drempel op. De kans op ‘rommel’ waar niemand de weg in weet is wel veel kleiner.
Je snapt natuurlijk wel dat we als organisatie de middenweg hebben gekozen. Praktisch gezien doordat we sitecollecties ‘weggeven’ aan teams. Daarbij dienen zij zelf aan te geven wie de beheerder wordt van hun collectie. Deze kan voor zijn team binnen de collectie zoveel en zo snel als gewenst teamsites maken. Het aanvragen van nieuwe sitecollecties laten we formeel lopen. Het aanmaken van teamsites kan informeel ontstaan binnen de teams zelf. Wat ons betreft op basis van wandelgang-verzoekjes.
De sitecollecties hebben we aangemaakt voor:
- elke organieke eenheid, voor samenwerking binnen teams van diensten en onderwijs. Hierin zitten geen studenten.
- elke school, voor de communicatie tussen docenten en hun studenten.
- elk groter onderwerp dat dwars door de organisatie loopt, voor samenwerking dat teams overstijgt. Voorbeelden zijn VSV, ARBO, Functioneel Beheer, etc.
- projecten, voor samenwerking binnen projectteams.
Binnen de context van SharePoint leidt dat voor mij tot de volgende stelling:
Leg het beheer op een zo hoog mogelijk niveau, zo laag mogelijk weg.
Daarvoor zijn wel een aantal zaken nodig:
- Hou overzicht over de collecties.
- Bewaak dat informatie binnen de juiste collecties ontstaat. Doe dit op een meer signalerende, voorlichtende toon dan een blokkerende.
- Leidt collectie-beheerders op en blijft ze begeleiden. Bijvoorbeeld door community-vorming. Bij ons zijn dit zo’n 4% van de gebruikers initieel.
- Help ze bij collectie-ontwerp met tekeningen. Een voorbeeld vind je hieronder. Hier kom ik binnenkort op terug.
