SharePoint-oplossingen maken het digitaal ondersteunen van vele bedrijfsprocessen mogelijk die door verschillende lagen van de organisatie gaan. Mensen hebben hierbij uiteenlopende verantwoordelijkheden en taken. Deze SharePoint-oplossingen moeten door de organisatie zelf worden gestuurd en onderhouden, maar welk beleid voer je hierop? Dit is waar Governance om de hoek komt kijken. In dit artikel beschrijf ik de visie die InSpark heeft als het aankomt op Governance op SharePoint en geef ik richtlijnen om tot een basis van een SharePoint Governance-plan te komen.
Wat is governance?
Laten we beginnen met de definitie van Governance. Deze wordt in de praktijk nog wel eens op meerdere manieren uitgelegd. Wat het beste bij de visie van InSpark op Governance past, is het volgende: “Governance bestaat uit een set van regels, rollen, verantwoordelijkheden en processen die vast worden gelegd om een organisatie te helpen bij het bewaken en sturen van het gebruik van technologieën om business doelen te bereiken.”
Met een goed Governance-document dwing je de organisatie om op een gestructureerde en gestandaardiseerde manier om te gaan met technologie. De set aan regels, rollen, verantwoordelijkheden en processen die je vastlegt, zorgen ervoor dat een eenduidig en stevig beleid gevoerd kan worden.
Governance is belangrijk voor de gehele organisatie. Zo is voor het management Governance een uitdraging van beleid en regels, waar het voor IT een houvast is waarmee de grenzen van technologie bewaakt kunnen worden. En voor de (eind)gebruiker biedt Governance een duidelijk beeld van de regels en processen die vanuit de organisatie worden gesteld binnen de technologie.
Juist omdat SharePoint een applicatie is die zich extreem laat vormen door de (eind)gebruikers is Governance erg belangrijk. Wanneer je op een SharePoint-applicatie geen Governance hanteert, loop je een heel groot risico om in plaats van een bedrijfskritische applicatie een onbeheersbaar beest te krijgen.
SharePoint Governance in zes hoofdvragen
Om tot een goed Governance-document te komen, moet je de juiste informatie vastleggen. Om dit te kunnen doen, heb ik een aantal hoofdvragen gedefinieerd die kunnen helpen bij het achterhalen van deze informatie. Uiteraard is er nog veel meer te beschrijven, maar wanneer je dit als basis gebruikt, heb je een goede eerste opzet van je Governance-document te pakken. De vragen zijn als volgt:
- Waarom stel je dit Governance-document op?
- Welke rollen zijn er betrokken?
- Welke richtlijnen worden er gehanteerd op het gebied van IT?
- Welke richtlijnen worden er gehanteerd op het gebied van informatiemanagement?
- Welke richtlijnen worden er gehanteerd op het gebied van customizations?
- Zijn er afwijkingen?
1. Waarom stel je dit Governance-document op?
Het is belangrijk Governance te koppelen aan de doelstellingen van de organisatie. Hiermee kan het management altijd aantonen dat Governance niet zomaar een losstaand iets is. Er moet een duidelijke samenhang met de organisatiedoelen zijn voor de applicatie en bijbehorende Governance. De volgende deelvragen helpen om dit vorm te geven:
- Wat wil je met Governance bereiken?
- Wat is de korte en lange termijnvisie van de organisatie op de applicatie?
- Welke plek moet deze applicatie innemen in het algehele applicatielandschap?
- Hoe kan ik deze applicatie inzetten om mijn doelstellingen te bereiken?
2. Welke rollen zijn er betrokken?
Bij elke applicatie is het belangrijk een goede definitie te maken van de rollen die vertegenwoordigd moeten worden. Bij Governance moet je vooral denken aan rollen die te maken hebben met verantwoording naar de organisatie toe. De volgende rollen kunnen worden gedefinieerd:
| Rol | Taak |
| Business Owner | Deze rol wordt gewoonlijk vertegenwoordigd door één persoon. Deze persoon kijkt vanuit een business perspectief naar de applicatie. Deze persoon hoeft dan ook weinig affiniteit te hebben met IT inhoudelijk. Wel moet de Business Owner de inhoud bewaken en uitdragen naar de organisatie. |
| Executive Sponsor | Deze rol wordt gewoonlijk vertegenwoordigd door één persoon. Deze persoon is verantwoordelijk voor het creëren van draagvlak binnen de organisatie. Hiervoor moet de applicatie strategisch op een juiste manier gepositioneerd worden. Tevens moet deze persoon de applicatie aan de organisatie “verkopen”. |
| Governance board | Deze rol wordt gewoonlijk vertegenwoordigd door meerdere personen. Deze groep personen is verantwoordelijk voor het samenstellen van de regels, rollen, verantwoordelijkheden en processen die in het Governance-document beschreven worden.
Deze groep bestaat uit personen vanuit verschillende lagen van de organisatie. Afdelingen die in ieder geval vertegenwoordigd moeten worden zijn Communicatie, HR, IT en Management. |
| Solution Administrator (Technologie) | Deze rol wordt gewoonlijk vertegenwoordigd door één persoon. Deze persoon beheert de applicatie vanuit een architectuuroogpunt. De Solution Administrator maakt beslissingen op architectuurgebied die vastgelegd moeten worden in een Governance-document. Denk hierbij aan de opzet van regels omtrent web applicaties, site collecties, databasegrootte, quota etc. Deze persoon staat nauw in contact met de Business Owner. |
| SharePoint Development Team | Deze rol wordt gewoonlijk vertegenwoordigd door meerdere personen. Deze personen zijn verantwoordelijk voor het technisch managen van de applicatie. Denk hierbij aan OTAP straat, Back-up en Recovery, Security en ontwikkeling. |
| SharePoint Functioneel Team | De rol wordt gewoonlijk vertegenwoordigd door meerdere personen. Deze personen zijn verantwoordelijk voor het ondersteunen van de Business bij het uitdenken en ontwerpen van nieuwe functies. Wanneer deze functies met standaard functionaliteit kunnen worden gerealiseerd, en niet repeterend uitgerold hoeven te worden, zal dit team de nieuwe functies ook inrichten. Wanneer deze functies niet met standaard functionaliteit gerealiseerd kunnen worden, zal de samenwerking met het SharePoint Development Team gezocht moeten worden. |
3. Welke richtlijnen worden er gehanteerd op het gebied van IT?
Hier leg je vast wat de uitgangspunten zijn voor de opzet en het beheer van de applicatie. Denk hierbij aan architectuur, licenties, omgeving, lifecycle management, databeveiliging en security.
| Architectuur | Welke keuzes hebben we gemaakt op het gebied van architectuur en waarom hebben we deze keuzes gemaakt? Hier leg je onder andere vast of een applicatie wel of niet in de cloud gehost mag worden en of er wel of geen externen worden toegelaten tot deze applicatie. Het is van groot belang dat de keuzes op deze gebieden goed vast worden gelegd. |
| Licenties | Welke licenties worden er gebruikt? Waarom is de keuze gemaakt voor deze licenties? |
| Omgeving | Welke keuzes zijn er gemaakt bij het opzetten van de omgeving? Is er een volledige OTAP-straat? Wat zijn de regels omtrent uitrol van custom code? |
| Lifecycle management | Welke keuzes zijn er gemaakt over lifecycle management? Wordt er gebruik gemaakt van automatisch archiveren of verwijderen van content wanneer dit niet gebruikt wordt? Welke oplossing is hiervoor gekozen? Wat zijn de regels op het gebied van tijdsbestek van waarschuwingen en daadwerkelijke archivering of verwijdering? |
| Data protection | Welke keuzes zijn er gemaakt op het gebied van databescherming? Welke content wordt er geback-upt? Hoe wordt er geback-upt? Hoe vaak wordt er geback-upt? Hoe vaak wordt een back-up getest? Wat is de retentietijd? |
| Security | Welke keuzes zijn er gemaakt op het gebied van Security? Is de omgeving beveiligd aangeboden met een SSL-certificaat? Wie hebben er toegang tot Central Administration? Wie mogen rechten toekennen op dit niveau? |
4. Welke richtlijnen worden er gehanteerd op het gebied van Informatiemanagement?
Hier leg je vast welke regels er worden gehanteerd op het gebied van informatie die aangeboden wordt. Hierbij moet je niet alleen denken aan presentatie, maar ook aan de hiërarchie.
| Web Applications | Hoe ga je om met webapplicaties? Wanneer kies je voor een aparte webapplicatie? Welke regels definieer je op het gebied van een webapplicatie? Denk hierbij bijvoorbeeld aan wel of geen quotations. Wie mogen webapplicaties maken? |
| Site Collections | Hoe ga je om met sitecollecties? Wanneer kies je voor een aparte sitecollectie? Welke regels definieer je op het gebied van een sitecollecties? Denk hierbij bijvoorbeeld aan wel of geen aparte database per sitecollectie. Wie mogen sitecollecties maken? |
| Sites | Hoe ga je om met sites? Mogen gebruikers zelf sites aanmaken? Zet je daarvoor self site creation in? Sta je het gebruik van custom site templates toe? Wie mogen de site templates beheren? |
| Navigatie | Hoe moet de globale navigatie worden ingezet? Moet deze overal gelijk zijn? Hoe moet de huidige navigatie worden ingezet? Wie mag de navigatie beheren? |
| Search | Hoe wordt search ingezet? Welke soorten content moeten geïndexeerd worden? Hoe ga je om met het refinement panel? |
| Managed metadata | Zet je managed metadata in? Wanneer zet je managed metadata in? Wie mag managed metadata beheren? |
5. Welke richtlijnen worden er gehanteerd op het gebied van Customizations?
Hier leg je vast welke regels er worden gedefinieerd op het gebied van customizations. Denk hierbij aan het wel of niet toestaan van Custom solutions of inzet van Tooling. Wanneer sta je het inzetten van deze methodieken toe?
| Custom solutions | In welke programmeertaal worden de Custom solutions ontwikkeld? Welke tool wordt hiervoor gebruikt? Wie heeft de bevoegdheid om een Custom solution uit te rollen? |
| Tooling | Welke tooling wordt er gebruikt voor Custom solutions? Wel of geen SharePoint Designer toestaan? |
6. Afwijkingen?
Hoe ga je om met afwijkingen van het bovengenoemde? Het is van belang dat ook deze afwijkingen goed vastgelegd worden, om in de toekomst eventuele problemen uit de weg te gaan.
Conclusie: het is nooit af!
Ik heb hierboven geprobeerd uit te leggen dat het definiëren en vastleggen van regels, rollen, verantwoordelijkheden en processen in Governance heel belangrijk is voor het succesvol laten zijn van technologie voor een organisatie. Het gevaar is echter dat men denkt dat Governance na de definitie en vastlegging klaar is. Dit is niet zo. Governance is een doorlopend proces dat vraagt om discipline van de organisatie. Elke wijziging van regels, rollen, verantwoordelijkheden en processen moet worden vastgelegd. Wanneer dit niet gebeurt, is Governance een nietszeggend document geworden. Wanneer men Governance goed invoert en uitvoert, maakt dit de kans dat SharePoint echt een professionele bedrijfskritische applicatie wordt vele malen groter. SharePoint Governance is de juiste manier om ervoor te zorgen dat bedrijfsprocessen op SharePoint veilig, goed, maar vooral ook prettig verlopen, voor zowel IT als voor de eindgebruiker.
