Vorige week werd er nog om gelachen in de cursus, maar de realiteit is best wel treurig. Het duurbetaalde, door consultants opgestelde SharePoint governance plan met zijn vijfenzeventig pagina’s is in de virtuele lade verdwenen en de governance is nog steeds ver te zoeken. SharePoint governance is het geheel van afspraken en regels rond het succesvol beheren van het SharePoint platform in je organisatie of bedrijf. Natuurlijk, zonder plan kom je er ook niet. Of, zoals Microsoft in 2010 zelf al stelde:
“A good Governance Plan is ‘necessary but not sufficient’ to ensure success, so be advised: a Governance Plan alone will not guarantee the success of your solution. You still have to ensure that the Governance Plan is applied. However, not having a Governance Plan or having a plan that is either impractical or unrealistic is a clear recipe for disaster.”
Maar hoe voorkomen we zo‘n SharePoint disaster? Vier tips.
Tip 1: Succes zit niet in het plan, maar in het team
Natuurlijk is het verstandig om afspraken en regels te codificeren. Vast te stellen, vast te leggen en te publiceren zodat iedereen weet wat er mag en wat er kan. Vaak laten organisaties en bedrijven dit optekenen door externen. Dat kan een risico zijn voor betrokkenheid en acceptatie. Er zijn ook fijne, eenvoudige handleidingen en voorbeelden op het internet. Het wordt al snel te ingewikkeld en te gedetailleerd, terwijl er vaak van project naar beheer en naar ervaring nog een lange weg is te gaan. Dus liever een paar punten die iedereen begrijpt en accepteert, dan een boekwerk.
Belangrijker is het team, of eventueel teams. Vaak begint een organisatie met enthousiasme aan SharePoint vanuit een beperkt opgezet experiment in de ICT-afdeling. Of een projectteam. Of een scrum-team, waarin we recht in de leer veel aandacht besteden aan wie scrummaster, wie productowner moet worden. Maar het SharePoint governanceteam mikt op de lange termijn en moet vooruit kunnen kijken naar de beheer situatie. Daarin zijn andere rollen nodig. Check voor inspiratie nog eens de guidance van Microsoft zelf. Denk ook aan rollen, die vandaag in het project misschien (nog) ontbreken: de bedrijfsjurist, iemand van P&O, communicatie, de recordsmanager, de functioneel beheerder(-s).
Let bij de teams op het onderscheid tussen technische en specialistische kennis en het niveau waar (financiële) beslissingen kunnen worden genomen. In een grotere organisatie zullen deze wellicht een getrapte vorm hebben: een technisch/tactisch team voor ontwikkeling en uitwerking, met advisering naar een strategisch/besluitvormend team. Zodat we met de managers niet hoeven te bomen over metadatavelden, maar knopen kunnen doorhakken wanneer nodig.
Let ook op de relatie tussen de huidige projectteams, stuurgroepen en de organisatie van governance. De focus van projecten is op de korte termijn, op de realisatie van afgebakende doelen en deeloplossingen en doorgaans niet op de besturing van het platform als geheel.
Tip 2: Manage het hele platform, in samenhang met informatie-architectuur
Want dat laatste brengt ons op tip 2: het denken in projecten werkt vaak een eenzijdige focus op de beperkte scope van een individueel project met zich mee. Op die manier zie je soms op één SharePoint platform (of op twee of meer als het tegen zit) verschillende oplossingen worden gebouwd. Het later verbinden van oplossingen is niet altijd goed mogelijk, als ieder project met architectuur-oogkleppen op is gerealiseerd. Denk daarbij bijvoorbeeld aan een digitaal archiefoplossing in SharePoint die alleen voor een beperkt aantal (‘zaakgerichte’)processen beschikbaar is en niet voor andere.
Ook wordt het thema governance soms opgepakt binnen zo’n beperkte project-blik, waardoor de governance niet het gehele platform geldt, maar uitsluitend het gedeelte van het project. Hele stukken SharePoint buiten de projectkaders vallen dan ook buiten alle regels en afspraken. Gevolg is bijvoorbeeld dat daar een wildgroei aan content optreedt, waarvoor later door ontbreken van metadata en bewaarstrategie geen eenvoudige oplossingen meer voorhanden zijn.
Tip 3: Begin vroeg, het is later dan je denkt!
SharePoint governance wordt vaak beschouwd als vergelijkbaar met de beheerfase van iedere andere applicatie. Aan het einde van de projectfase wordt dan een formele overdracht bepaald en gelden de beheerregels van de volgende fase. De eigenaardigheid van SharePoint is dat men negen van de tien keer start vanuit een ‘experimentele’ of ‘pilot’ fase en dat die naadloos, ongemerkt en vooral onafgesproken overgaat in productie. Ineens was iedereen lekker aan het SharePointen, rezen de teamsites de pan uit en was er nooit iets afgesproken over dat beheer.
Omdat deze werkwijze zo gemeengoed is, zou het een regel moeten zijn dat er vanaf de start van een SharePoint project een governanceteam in de kiem al aanwezig is. Indachtig tip 2 heeft dat team dus ook een bredere blik dan uitsluitend het project dat is gestart met SharePoint. Het governanceteam gaat immers over alle SharePoint gebruik, binnen of buiten een huidig project. Ook – en vooral – als ze het daar ‘experiment’ of ‘pilot’ noemen.
De architect heeft er zeker zitting in, zodat deze kan wijzen op samenhang, consolidatie van andere applicaties en toekomstige trends richting SharePoint. Ook de recordsmanager is present, zodat niet alleen de records van die ene nieuwe oplossing in SharePoint zijn veiliggesteld, maar alle mogelijke records die op het SharePoint platform landen.
Tip 4: Schrijven en tekenen, maar met mate
Voor wie zich niet kan bedwingen: natuurlijk is het zinnig enkele basisafspraken vast te leggen. Maar probeer eens een tien-punten-governance-plan dat niet langer dan èèn A4tje mag zijn. Maak voor aan de muur een tekening van SharePoint. Teken het platform èn de projecten die zich op het platform begeven. Wat gebeurt nog buiten die projecten? Welke rollen en personen zijn betrokken? Teken het SharePoint governance team(-s). Zorg dat de governance het hele platformgebruik dekt!
