In deel één van deze serie is aandacht besteed aan collaboration tool in het algemeen. In deel twee en drie van deze blogserie zijn Lisette de Haas en ik ingegaan op de voor- en nadelen van SharePoint. In dit vierde en laatste deel besteden we aandacht aan de ‘organisatorische’ aandachtspunten.
De gehele reeks dient als handvat en aandachtspunten voor de afweging van de keuze van SharePoint. De oorspronkelijke werktitel was dan ook To SharePoint or Not to SharePoint. De aanpassing van de titel heeft in dit geval onbedoelde verwarring gezaaid. Gelukkig hebben de vele reacties op de vorige delen ons de gelegenheid gegeven deze verwarring voor een groot deel weg te nemen. Dit is dus geen technische handleiding over hoe een collaboration tool te implementeren/configureren. Een zo breed onderwerp als de keuze van een collaboration tool dekt niet de gehele lading voor alle verschillende organisaties, we hebben getracht de meest voorkomende punten in de afweging mee te nemen.
Welke tool een organisatie ook kiest om de documenten in op te slaan, of dat nu SharePoint, Alfresco Share, Teamsites of nog iets anders is, er moet vooraf nagedacht worden over een aantal uitgangspunten. Deze opslaglocatie mag er binnen de kortste keren niet net zo uitzien als de spreekwoordelijke 'omgevallen boekenkast'.
Om de tool optimaal te benutten en de samenwerking tussen medewerkers te bevorderen moeten in elk geval de volgende punten op orde zijn:
– Contentstrategie; een contentstrategie is een strategie voor de inhoud van het systeem, het biedt richtlijnen voor het beheer van de content. Het gaat dan met name om de vraag welke informatie moet worden vastgelegd en voor hoelang deze bewaard moet blijven. Tevens worden afspraken gemaakt over wat waar geplaatst wordt en hoe het makkelijk teruggevonden wordt. Maak onderscheid in persoonlijke-, afdelings- en projectinformatie.
Onder de strategie valt ook compliancy. Zodra de organisatie te maken heeft met business rules of externe vereisten, moet inzichtelijk worden gebracht aan welke compliancy regels voldaan moet worden. Hier kan de inrichting van SharePoint op aangepast worden.
– Contenthiërarchie en contentstandaarden; SharePoint kent een standaard structuur waarin alle content/data wordt geplaatst; van sitecollectie tot lijstpagina met documenten. Door de informatie te structureren ontstaat er minder snel informatie overload.
Wat is een goede structuur voor de inrichting van SharePoint? Een bedrijfsproces blijft vrijwel altijd hetzelfde. Hier en daar zal een proces ‘leaner’ worden, maar over het algemeen wijzigt het hoofdproces niet. Zodra het bedrijfsproces leidend wordt voor de structuur, dient het proces (en de onderliggende stappen) in kaart te worden gebracht. Ga na waar de huidige informatie is opgeslagen, richt de site in met blokken die overeenkomen met de structuur van het proces en plaats de informatie onder het stukje proces waar het hoort. Op deze manier wordt gelijk een stukje kennisborging behaald. Waar in het proces nog geen informatie over beschreven staat, kan dit aangevuld worden. Heeft een medewerker informatie die buiten het proces valt? Ga dan de discussie aan of het wel geplaatst moet worden. Wees voorzichtig met titels als ‘Algemeen’ en ‘Overig’. Die groeien als kool zodra de structuur niet intern als afdoende wordt doorleefd.
Naast de structuur op hoofdniveau, wordt er ook gewerkt met structuur op documentniveau. Worden er vereisten gesteld aan de vorm waarin de content wordt gepresenteerd? Vraag af wie het stuk gaat lezen en pas daar de schrijfstijl op aan (reader focused content). Is het handig om te werken met vaste koppen (of op basis van een template)?
Wordt het invullen van metadata verplicht of moet dit een vrijwillige keuze zijn? Onder metadata valt ook het toekennen van (vak)termen die van toepassing zijn op de documenten die in de collaboration omgeving staan. Denk alvast na over het definiëren van een taxonomie of de mogelijkheid om niet-gedefinieerde termen te kunnen toevoegen aan content. Als je in SharePoint iets wil kunnen terugvinden wat je collega heeft gemaakt zijn bijvoorbeeld tags of keywords essentieel voor een goede Search engine inrichting.
Resultaten uit het verleden bieden geen garantie voor de toekomst, of wel? Om op deze vraag een antwoord te kunnen geven moet een onderzoek plaatsvinden naar de huidige situatie. Hoe vaak komt het voor dat een document niet gevonden wordt, of dat een map met o zo belangrijke informatie al jaren niet bekeken is? Voer waar mogelijk een (korte) analyse uit over het gebruik van het systeem, dit kan zorgen voor extra aandachtspunten voor het inrichten van het nieuwe systeem. Vaak zie je dan ook direct op welke termen informatie teruggezocht wordt en over welke onderwerpen geen resultaten worden verkregen. Door dit inzicht kan de inrichting bijgesteld worden zodat de gebruikers informatie beter en sneller kunnen gebruiken.
– Permissies en controle; Een belangrijk onderwerp is het autorisatiebeheer. In deel 3 staat beschreven dat rechten die op het laagste niveau uitgegeven zijn, niet eenvoudig centraal aangepast kunnen worden.
Een oplossing kan zijn om met machtigingen op blok/siteniveau te werken en zo min mogelijk (tot geen) met individuele rechten. Zodra een site gevoelige of niet openbare informatie betreft, verleen dan toegang op groepsniveau. Zodra een persoon geen recht meer heeft om bij bepaalde informatie te komen, hoeft deze alleen uit de groep(en) gehaald te worden, in plaats van elke site/pagina/document af te gaan waar autorisatie voor gegeven is.
Bedenk ook goed wie (welke medewerker), wat (welke informatie uit welk proces), waar mag plaatsen (in welke site en welk deel van de structuur), bekijken, aanpassen en verwijderen. In het geval van ‘alles-open-tenzij’ kan elke gebruiker de niet gevoelige informatie lezen. Vanaf waar mag deze bewerken en zelfs verwijderen? Is het nodig dat inzichtelijk wordt gemaakt wie de content heeft gezien/toegevoegd/bewerkt en wanneer dit is gebeurd? Lang niet altijd is een trail noodzakelijk, maar als een organisatie of onderdeel zich moet verantwoorden intern of extern, is het heel handig om de 'fout', “misverstand” of “rotte appel” te reproduceren en aan te pakken.
Conclusie
In deze blogserie hebben we argumenten gegeven waarom ‘out of the box' SharePoint het beste gebruikt kan worden als een organisatie tijdelijk documenten wil delen in een bepaalde groep; voor adhoc samenwerken. Na afronding van deze periode breng je het geheel over in een Document Management System, waarmee de informatie voor een langere termijn geborgd wordt.
Op het moment dat een organisatie de punten (uit de gehele artikelreeks) in beeld heeft gebracht is het meestal zonneklaar of SharePoint het beste past bij de situatie waarin de organisatie verkeert. We weten zeker dat dan nog steeds organisaties kiezen voor SharePoint, en daar is niets mis mee, maar dan wel op basis van de juiste argumenten en niet omdat toevallig de IT afdeling het al min of meer op de plank heeft liggen en snel wil anticiperen op verzoeken uit de organisatie.
De auteurs
Lisette de Haas en Anja van der Lans zijn consultants die zich bezighouden met het begeleiden van gebruikersgroepen en verbeteren van de informatiehuishouding van organisaties als onderdeel van het vakgebied Enterprise Information Management bij Incentro.
Anja,
Nu het laatste deel gepubliceerd is kunnen we als lezers eindelijk de balans opmaken, met hopelijk nu wel de ‘juiste bril’ omdat Lisette ons bij deel 3 uitlegde dat er wat mis gegaan was met de titel. Dat het hierdoor een beetje ‘Sharepoint a breakpoint’ werd is misschien een vergissing van de lezers maar jij bleef ook wel erg volharden in je eenzijdige boodschap.
Samengevat concludeer ik dat nadeel van Sharepoint de multi-purpose oplossing is waardoor het van alles kan maar weinig echt goed, tenminste niet ‘out-of-the-box’. Maar elke nadeel heb z’n voordeel zei Johan Cruijff eens en het is juist die flexibiliteit welke Sharepoint zo populair maakt. Bijvoorbeeld als oplossing voor Intranet, de portal functie waar ik dagelijks mee werk en het delen van informatie binnen internationale teams zo vergemakkelijkt. Natuurlijk speelt de integratie met de vele andere Microsoft producten die er intern bij veel bedrijven gebruikt worden daar ook een rol bij, niet veel anders met het vroegere Lotus Notes/Domino en de Smartsuite.
En zoals ik eigenlijk al na het lezen van eerste opinie dacht gaat het dus meer om het proces van samenwerken dan de middelen die er verstrekt zijn. Maar ja, samenwerken is dan ook een dynamisch proces waarbij beperkingen eerder tot frustraties dan resultaten leiden. Terugkomend op je mededeling dat een blog geen boek is was dan ook erg vermakelijk voor mij, de hier verkregen interactie mist namelijk inderdaad bij een boek. Maar dat het allemaal toch interessant en informatief is geworden komt volgens mij juist door de vele reacties, de collaboration waar een community meestal voor bedoeld is toch?
Aardig fenomeen, zo’n vervolgserie. Tip voor de redactie: is het mogelijk om de mogelijkheid te bieden voor een optie “gerelateerde artikelen”.
Het komt niet vaak voor dat ik artikelen uit Computable afdruk, maar dat ga ik nu eerst doen, nu het verhaal compleet is. Daarna zal ik dan mijn commentaar over het geheel geven.
@Anja&Lisette: Allereerst een compliment over je duidelijke uiteenzetting. Het is een mooi en duidelijk verhaal. Ook weer veel herkenning als het gaat om het feit dat het eigenlijk altijd valt of staat bij de organisatie. En ook de eeuwige discussie out-of-the-box vs. custom.
Daarnaast heb ik als beginnend Computable reageerder, maar ervaren SharePoint expert genoten van het feit dat er zeer kritische reacties geplaatst worden, in mijn optiek geeft dat aan hoe “hot” dit item is en dat vele mensen met vele invalshoekken hier een idee bij hebben.
De standpunten rondom wat slim is voor de contentstrategie laat ik graag aan jou over, het ziet er goed uit. Er moet goed over nagedacht worden, echter ik ben geen IM specialist om daar een uitgebreid verhaal over te houden.
Ik deel niet de mening van @Ewout dat “…het van alles kan maar weinig echt goed..”. In mijn optiek is juist de kracht dat er een hele solide basis is die voor 99% van de standaard gebruikers het afdoende is. Maar goed, dat is nou ook weer het leuke van meningen, ze mogen verschillen.
Hopelijk mag ik nog meer van dergelijke blog artikelen lezen en het liefst in een serie. Ik vind het erg leuk om hierover te lezen en te reageren.
Even een reactie op de inhoud van deze aflevering.
Aan het eind komen permissies, controle en autorisatiebeheer terloops ter sprake. Gelukkig staat erbij dat dit een belangrijk onderwerp is.
In mijn tijd als free lancer werkte ik eens bij een organisatie waar ze meer verschillende (autorisatie-) profielen (1300) hadden dan personeelsleden (1000) – aantallen bij benadering.
Dit was een gevolg van opeenvolgende reorganisaties: bij elke reorganisatie werden nieuwe profielen gemaakt en toegekend terwijl de oude bleven bestaan. Mensen hadden daardoor altijd meerdere profielen: de nieuwste plus alle eerder toegekende profielen. Bovendien verzamelden zij profielen omdat zij bij elke functieverandering de bijbehorende nieuwe profielen kregen maar hun oude profielen behielden.
Het was ook een gevolg van een zwak beleid. Als lijnfunctionarissen met veel bombarie stellen dat zij hun werk niet (meer) kunnen doen en de beheerders worden door hun manager niet gedekt bij het uitvoeren en handhaven van enig autorisatiebeleid, krijg je zulke wildgroei.
Wat ik wil zeggen is: autorisatiebeleid is niet alleen belangrijk, het is ook knap lastig – zowel technisch als qua onderlinge relaties. En net als ieder *beleid* is het een verantwoordelijkheid van het management – en uiteindelijk van de hoogste baas.
Goed om te zien dat er andere sfeer rondom het laatste deel hangt. Naast alle interessante reacties die n.a.v. een post geplaatst worden, is een ander voordeel dat je direct de kans hebt om het een en ander recht te zetten.
@Karel, de situatie die je schetst is herkenbaar. Eén grote chaos met alle profielen, verschillende gebruikersgroepen en apart toegekende rechten. Om nog te zwijgen over het groot aantal personen die gemachtigd is voor mappen die ze helemaal niet in mogen zien. Stel dat er dan eindelijk de capaciteit is gevonden om dit allemaal door te nemen en recht te zetten, dan heb je nog het deel ‘bijhouden’. Iets wat beleid zou moeten opvangen, maar lastig te realiseren is. Zeker zodra men minder vrijheid heeft dan voorheen. Zoals Ewout ook al zegt, samenwerken is een dynamisch proces waarbij beperkingen eerder tot frustraties dan resultaten leiden. Hierbij is een heldere uitleg waarom bepaalde keuzes gemaakt zijn/worden van essentieel belang (begrip creëren).
@Michiel
Als je mijn eerdere reacties terug leest zul je zien dat we niet zoveel van mening verschillen. Vergelijk je objectief de mogelijkheden van verschillende producten dan komt Sharepoint niet op alle punten als beste uit de bus voor een aantal genoemde punten in deze reeks, het nadeel van de ‘one-size-fits-all’ oplossing. De plus van Sharepoint is echter dat je door de ‘openheid’ wel gespecialiseerde oplossingen binnen het framewerk kunt integreren om te profiteren van het beste van verschillende werelden binnen een enkele portal. Maar misschien is dat ook uiteindelijk wel het open einde van deze serie als ik kijk naar de eindconclusie.
Uiteindelijk gaat het om de eisen en wensen, waarbij zwaartepunt gelegd kan worden op samenwerken, een document management systeem of beiden. Dat vaak omgekeerde volgorde gekozen wordt, waarbij verwacht wordt dat Sharepoint (of elke andere inzet van ICT) alle problemen eventjes oplost, laat voorbeeld van Karel zien. De volwassenheid van een organisatie zoals tot uitdrukking komt in genoemde technische en organisatorische problemen zijn dan vaak een valkuil.
@Lisette
De spreekwoordelijke bruggen slaan tussen koninkrijkjes waar lijnmanagers de piketpaaltje metersdiep de grond ingeslagen hebben lijkt me een hell of a job;-)
Anja,
In het eerste en tweede deel kwam je met voor en nadelen van deze oplossing. Als ik deze punten gebruik om daar mijn business case voor het implemteren van SharePoint mee te onderbouwen dan weet ik zeker dat deze (business case) gelijk in de prullenbak gegooid wordt. Zoals ik al eerder zei ik verwacht een andere analyse van een consultant die ik hiervoor ingehuurd heb.
In het laatste deel kom je met een aantal goede tips! Deze tips heb je nodig om ermee de bouwstenen van je oplossing goed op elkaar te zetten. Het volgen van deze tips vereist een bepaald niveau van professionaliteit en ervaring binnen de klantorganisatie. Dan vraag ik me af als de klantorganisatie de professionaliteit en kennis niet heeft, willen ze deze kennis opdoen en hun werkprocessen veranderen voor een oplossing die ze als “out of the box” en tijdelijk willen gebruiken? En als ze die professionaliteit al hebben, wanneer komen ze er achter dat deze oplossing in een ‘Out of the box’-vorm niet voldoet aan hun eisen en dat snel een maatwerk moet worden(dus misschien geen SharePoint)?
Mijn tweede opmerking is over “als een organisatie tijdelijk documenten wil delen in een bepaalde groep…”
Ik kom dit soort situaties bij veel bedrijven tegen. Iets wat toen “tijdelijk” en klein opgezet was heeft in de loop van de tijd eigen leven gekregen, is veranderd in een oerwoud en een belangrijk positie in de werkprocessen ingenomen. De oplossing voldoet niet meer aan de eisen van nu, veroorzaakt veel inefficiënties, en ze kunnen hem ook niet makkelijk vervangen (vanwege het oerwoud van processen)
Ik zal tegen de organisatie die SharePoint als een tijdelijke oplossing willen gebruiken zeggen, denk ff goed na en kijk verder dan je neus lang is!
Bovendien de tips die je gegeven hebt zijn te zwaar voor de realisatie van een tijdelijke oplossing. Ik vind deze tips meer nuttig als deze oplossing grondig bekeken moet worden voor implementatie binnen de organisatie.
Samengevat, ik mis de lading van dit deel in de voorgaande delen. Of de SharePoint een juiste oplossing is of niet laat ik aan andere experts over die meer kennis en ervaring met de Collaboration tools hebben dan ik.
@Reza,
voor elke tijdelijke oplossing geldt dat die meer tijd kost dan het implementeren van de goede oplossing, omdat na een tijdelijke oplossing nog steeds de goede oplossing geïmplementeerd gaat (moet…) worden. Er geldt namelijk dat: tijdelijk+goed>> goed.
Daarnaast in de meeste collab-gereedschappen is het een organisatie verhaal en geen functionele verhaal om het werkend te krijgen voor de echte gebruiker.
Ik heb het verloop van deze serie als leerzaam ervaren, niet zozeer het schrijven zelf maar de manier waarop de auteur reageert en de snelheid waarmee hij/zij dat doet bepaalt voor een deel het verloop van de discussie.
@ewout, Je reactie over de piketpaaltjes en de hell of a job uitspraak klopt. In ons vak als business consultant die bedrijven begeleiden bij het proces om te komen tot enterprise information oplossingen is deze uitdaging in ruime mate aanwezig en de moeite waard om steeds aandacht voor te vragen omdat we weten dat het resultaat van welke implementatie dan ook daarna veel beter is.
@andre, ben benieuwd naar je reactie op de feuilleton
@michiel, dank voor je opbouwende reactie en input
@karel, inderdaad is beleid onvermijdelijk om chaos te voorkomen en vervolgens is monitoren van dit beleid en daarop sturen zo mogelijk nog belangrijker (en tevens de meest voorkomende zwakke punt van veel management in organisaties)
@reza, ik hoop dat je een consultant inhuurt die past bij wat de organisatie vraagt en nodig heeft. Volgens mij is de informatie in de serie niet geschikt om een business case op te bouwen, dat is ook niet de bedoeling en hebben we ook nooit beweerd.
Je stelt de vraag wanneer de organisatie erachter komt dat ze de verkeerde keuze hebben gemaakt? Wel dat is meestal te laat en dan wordt het initiatief geleidelijk niet meer ondersteund, bloed het dood en begint na een paar jaar het hele proces van het maken van een (toevallige) keuze weer van voren af aan.
Tijdelijke oplossing of niet; als je een dergelijke oplossing kiest moet je de in deel 4 geschetste uitgangspunten op hebben om het initiatief tot een succes te laten worden (op de korte én lange termijn)
@ maarten; eens dat dit een organisatorisch verhaal is en daarmee raak je tevens de kern van ons betoog. Wij lopen in de praktijk tegen dit soort problemen en hopen met onze blogserie in elk geval een aanzet gegeven te hebben voor een goede discussie in organisaties over dit onderwerp.
@anja,
Je hebt in het tweede en derde deel, voor en nadelen van iets benoemd. Deze lees ik als een advies. En als een advies goed onderbouwd is dan zou ik deze met wat kleine aanpassingen voor bijvoorbeeld business case of iets anders gebruiken. Naar mijn mening was de informatie in de reacties meer degelijk dan de benoemde voor en nadelen in die artikelen.
En wat betreft het inhuren van een juiste consultant, geen probleem! Dankzij jouw artikelen heb ik in de reacties kennis gemaakt met mensen die veel kennis en ervaring met dit product hebben, ik weet ze nu te vinden!
De vraag die ik gesteld heb is eigenlijk geen vraag! Het is maar een “prik” om de betreffende organisatie wakker te krijgen en te behoeden van deze situatie en ik ben het met je reactie hieromtrent eens.
@Maarten: In mijn reactie heb ik aangegeven dat er een bepaalde volwassenheid en ervaring binnen de klantorganisatie moet aanwezig zijn om deze tips te kunnen volgen en dit systeem te kunnen laten landen. Dit is hetzelfde als “organisatie verhaal” dat je hebt benoemd. In dit verhaal zie ik de techniek niet echt als de uitdaging (tenzij je compleet verkeerde keuze maakt!) maar wel de organisatorische zaken rondom de het nuttig gebruiken van deze oplossing.