Deze blogserie bevat een introductie van samenwerken (deel 1), de voordelen van Sharepoint in deel 2, in deel 3 (dit deel) bespreken we de nadelen van Sharepoint en in deel 4 wordt ingezoomd op de mogelijkheden om de voorbereiding en inrichting van een tool als Sharepoint te optimaliseren.
Zolang de organisatie Sharepoint uitsluitend gebruikt waarvoor het gemaakt is, het uitwisselen van kennis en informatie via documenten die kunnen worden opgeslagen en beheerd in kleine groepen, is Sharepoint een prima product. En nogmaals nee, we hebben geen aandelen…
Sharepoint ondersteunt tevens de basisvereisten voor contentmanagement. Sharepoint wordt vaak ingezet met de intentie om ook documentmanagement of recordsmanagement (archivering) te introduceren. Basale functionaliteit hiervoor is aanwezig. Bij zwaardere of hogere eisen kom je als organisatie bedrogen uit. Voor documentmanagement en recordsmanagement gelden andere uitgangspunten. Sharepoint is wel een ecm-product, maar is wel een collaboration tool en géén ecm-suite. Het biedt geen totaaloplossing voor het enorme aanbod van opslaglocaties van informatie en documenten (denk aan e-mail, sharefiles, etc.).
Met deze informatie in het achterhoofd fronzen wij onze wenkbrauwen als we in ogenschouw nemen dat alle bedrijven op de top 500 van Fortune gebruikmaken van deze tool. Het beheer van de informatie in Sharepoint in een grotere context is een heel ander verhaal. De Shell’s en Ahold’s van deze wereld hebben zelf interne regels en moeten aan allerlei nationale en internationale voorschriften voldoen om hun kennis en informatie inzichtelijk te maken op het moment dat dit van hen gevraagd wordt. Beheer van informatie is dan geen bijzaak meer maar van levensbelang voor de organisatie. Bij overtreding van de afspraken zal de organisatie hoge kosten tegemoet kunnen zien als boete of grote reputatieschade kunnen oplopen.
Deel 3: de nadelen
Als een organisatie een collaboration tool zoekt, wat zouden dan de redenen kunnen zijn om géén Sharepoint te kiezen of niet alleen Sharepoint te kiezen?
1) Compliancy is niet voldoende geregeld in Sharepoint. Meer dan 60 procent van de organisaties die hebben deelgenomen aan een AIIM-onderzoek uit 2011 geven aan dat zij de informatie en documenten in de SP-sites ‘compliant' moeten maken. Het is niet 'out of the box' mogelijk in Sharepoint om de compliancy-regels zo te vertalen dat direct zichtbaar is of aan de regels wordt voldaan. Sharepoint biedt wel de mogelijkheid functionaliteit toe te voegen die ontwikkeld is voor een speciaal doel, koppelingen te maken met andere applicaties en dergelijke. Sommige organisaties zullen om aan de regels te voldoen dus tijd en geld moeten investeren.
2) Beveiligingsproblemen. Voor specifieke soorten informatie, met name gevoelige informatie, wil een organisatie waterdichte beveiliging hebben om te voorkomen dat onbevoegden toegang hebben, informatie kunnen inzien of wijzigen. Het intellectueel eigendom van de organisatie, klantinformatie, personeelsinformatie, juridische geschillen moeten onder alle omstandigheden uit handen blijven van de 'verkeerde' personen. Uit hetzelfde AIIM-onderzoek blijkt dat maar liefst in 61 procent van alle gevallen door medewerkers 'per ongeluk' misbruik gemaakt wordt van de afspraken. In Sharepoint kan dit misbruik bij gebruik van de 'out of the box'-applicatie niet goed voorkomen worden doordat het controlemechanisme op de afspraken niet aanwezig is.
3) Specifieke functionaliteit ontbreekt. Uit een onderzoek van AIIM uit 2010 blijkt dat tweederde van alle bedrijven waar Sharepoint draait behoefte heeft aan aanvulling op specifieke onderdelen. Op het moment dat de organisatie Sharepoint ook ter beschikking wil stellen in projecten waarin samengewerkt wordt met derde partijen, buiten de muren van de eigen organisatie, in het veld of onderweg, dan vereist dat extra functionaliteit die niet standaard is meegeleverd. In dat soort gevallen gaan bedrijven op zoek naar 'add ons' voor Sharepoint en wordt de oplossing vaak veel duurder, maar ook het beheer en soms het gebruik complexer.
4) In geïntegreerd informatiebeheer is 'out of the box' in de Sharepoint-omgeving niet voorzien. Het beheer van informatie is beperkt tot uitsluitend informatie die is opgeslagen in of op Microsoft-apparaten en -platforms. Dat werkt prima zolang de interne wereld en de externe wereld beperkt blijft tot mobieltjes, Microsoft-apparatuur en platforms. Het dagelijks proces staat samenwerken via Sharepoint dan in de weg.
5) Centraal rechtenbeheer wordt meestal afgedwongen door inrichting met behulp van groepen. Veel organisaties hebben in het verleden de inrichting van de sites en de onderliggende folderstructuur overgelaten aan iemand binnen de groep die met Sharepoint wilde werken. De rechten in de vorm van toegang tot de site en de folders zijn toegekend door een functioneel beheerder. De inzage van documenten, rechten om te bewerken of te verwijderen van documenten en het delen met specifieke andere deelnemers uit de groep kan de eigenaar van het document zelf bepalen (en dat gebeurt dus ook op grote schaal; als de eigenaar niet zelf rechten toekent gelden de rechten van de folder of documentbibliotheek). Zolang alle deelnemers in dienst blijven of binnen dezelfde groep blijven werken gaat dit goed. Vele documenten blijven na verloop van tijd onbeheerd achter en handmatig rechten aanpassen door de functioneel beheerder(s) is meestal onbegonnen werk.
6) Operationale efficiency verbetert niet. Door de structuur van de sites binnen Sharepoint ontstaan virtuele silo's met informatie. Alleen binnen die silo's zullen mensen de mogelijkheid hebben om kennis en informatie te delen. Tussen de silo's kan dat niet, hetgeen betekent dat een document (fysiek en niet virtueel) in meerdere silo's geplaatst moet worden als het voor meerdere groepen interessant is. Het idee van samenwerken in de organisatie is daarmee verkleind tot samenwerken in groepen binnen de organisatie.
Zelf afweging maken
Elke organisatie kan zelf de afweging maken op basis van deze plussen (deel 2) en minnen (deel 3). Nogmaals willen we nadrukkelijk stellen dat Sharepoint onder bepaalde omstandigheden heel geschikt is om te gebruiken. Toch is ook daarmee het hele verhaal nog niet verteld. Wat zijn dan die omstandigheden? Waardoor wordt het succes bepaald? In deel 4 meer over de voorbereiding, de inrichting en de keuzes die organisaties vooraf kunnen maken om ontevredenheid en teleurstelling te voorkomen.
Deze bijdrage kwam tot staand in samenwerking met Lisette de Haas, consultant bij Incentro.
Eerdere delen
Lees ook:
– deel 1, Collaboration tools: introductie van samenwerken
– deel 2, Collaboration tools: voordelen van Sharepoint
Eigenlijk zou ik kunnen volstaan met mijn slotreactie op deel 2 in deze reeks. Ook hier weer een aantal valide nadelen van Sharepoint genoemd, maar helaas mis ik wederom de link naar de collaboration-omgeving (alleen in puntje 3 wordt het even aangestipt)
Wat voorbeelden:
– hoe gaat sharepoint om met verschillende vestigingen (al dan niet van hetzelfde bedrijf) die elk een eigen active directory hebben. Kan ik dan ook nog op een veilige manier mijn documenten afschermen?
– hoe is de performance als men vanuit de hele wereld op één repository moet werken?
– in sommige landen/sectoren ben je verplicht informatie in de lokale taal aan te bieden. Hoe ga je een sharepoint inrichten die, afhankelijk van de lokatie en rol in zowel het Spaans, Frans, Duits en Engels moet opkomen?
– bij een koppeling tussen office en sharepoint: hoe ga je om met de verschillende regio-settings ($ versus €; . versus ,; 24h versus 12h enz)
– hoe ga je om met verschillende lokale wetgevingen als het gaat over bijv. electronische handtekeningen
@Anja,
Als je doel het geven van een overzicht is, zoals je aangeeft in laatste reactie op deel 2, kun je m.i. beter geen opdeling maken van voor- en nadelen in twee artikelen. Dat reacties dan alle kanten uit gaan is dus niet enkel ‘beroepsdeformatie’ maar deels ook het gevolg van de door jouw (of redactie) gekozen weg.
Verder herken ik me als gebruiker van Sharepoint maar ten dele in de door jouw gegeven minpunten. Tenminste als het om samenwerken gaat in (internationale) teams. Wel terecht zijn de opmerkingen over informatie- en rechtenbeheer hoewel deze niet zo zeer met het product maar meer met het proces te maken hebben.
Maar daar ga je ons natuurlijk alles over vertellen in de deel 4:-)
Al deze nadelen kloppen inderdaad, alleen ik ben van mening dat dit voor veel van de overige ECM pakketten ook geldt en dus niet specifiek voor SharePoint als pakket. Voorbeelden:
@1: Compliancy ontstaat niet door een pakket maar de set van maatregelen die je neemt als organisatie. Bij alle pakketten moet er werk gedaan worden om het geheel compliant te maken.
@2: Dit is niet uniek voor SharePoint. De mens is vaak de zwakke schakel in informatiebeveiliging.
@3: Het genoemde voorbeeld van samenwerking met derde partijen is vooral een infrastructurele en procedurele uitdaging. Zonder deze maatregelen werkt het voor andere pakketten ook niet. Alleen bij het gebruik van een SaaS oplossing zijn de infrastructurele uitdagingen een stuk minder (m.n. toegang)
@5: Dit is vooral een organisatorisch probleem dat ontstaat door de ‘organische’ aanpak die organisaties kiezen bij de implementatie van SharePoint. Oftewel een prijs van het succes dat SharePoint soms heeft… zonder dat er naar toekomstig gebruik gekeken wordt of dat er tijd/geld gereserveerd wordt om de volgende stap te maken.
@6: Zie mijn vorige punt.
Aanvullend op eerdere reacties:
Compliancy: nee, je kunt niet alle mogelijke regeltjes wat betreft compliancy verwerken in SharePoint, maar in welk pakket kan dat wel? Je kunt echter prima bepalen hoe lang een bestand bewaard moet blijven, bijvoorbeeld. Ook auditing mogelijkheden voor je rules zijn aanwezig, dus dat je niet kunt zien of aan de regels wordt voldaan is ook niet juist.
Dat je SharePoint niet out of the box kunt gebruiken voor samenwerken met externe partijen is ook onzin. Middels claims based authenticatie kun je meerdere userstores toegang geven tot je omgeving. Op die manier is het eenvoudig om een groep externe gebruikers te definieren en een groep interne gebruikers. Door een omgeving goed in te richten en het beheer in goede handen te houden is het prima haalbaar om een secure omgeving te maken voor een extranet. Ik heb zelf meerdere van dit soort omgevingen opgezet, zonder enig gebruik van third party tools.
Opmerking 4 kan ik helemaal geen kaas van maken.
Punt 5 ben ik het ook niet mee eens; de vrijheid om sites zelf in te richten is juist de kracht van SharePoint. Het feit dat een projectleider zelf een projectsite kan aanmaken en beheren betekent dat er veel sneller en efficienter geschakeld kan worden. En ja: de projectleider kan ook een puinhoop maken van zijn site, maar dat is dan ook eigen verantwoordelijkheid. Meer vertrouwen hebben in medewerkers is een van de kenmerken van het nieuwe werken. En met regels m.b.t. ongebruikte documenten en sites kan de omgeving zichzelf op orde houden, helemaal geen beheer voor nodig.
Als laatste dan de efficiency. Wanneer je een omgeving zo inricht dat iedereen alleen maar in zijn of haar eigen hokje kan, dan ben je sowieso niet handig bezig. Het systeem heet niet voor niets SHAREpoint. Een document kan overigens ook prima in meerdere document bibliotheken bestaan als kopie; waarbij veranderingen in het origineel gepubliseerd kunnen worden naar alle kopieen. Allemaal out of the box functionaliteit.
@ Redactie: Is deze inhoud beoordeeld door een 2e iemand met verstand van zaken? Want dit soort stukken (zie ook vorige artikel + reacties daarop) draagt nu niet echt bij aan het imago van Computable.
Hi Anja,
Bedankt voor je overzicht en inzichten rondom SharePoint. Een framework wat steeds vaker wordt ingezet bij bedrijven. Wat ik mis in je artikel is hoe om te gaan met specifieke software development vraagstukken en de alternatieven daarop. Wat wij veel zien is dat het framework perfect werkt waarvoor het gemaakt is, alle wensen die daarbuiten nog moeten worden gerealiseerd zijn de valkuilen in dit verband. Vaak willen bedrijven ook die specifieke maatwerk wensen laten ontwikkelen in SharePoint en daarmee beginnen de uitdagingen. Uitdagingen als het gaat om het realiseren van de logica (te traag en te onvoorspelbaar) en men moet teveel effort stoppen in ontwikkeling om daadwerkelijk een functie te kunnen realiseren…met als volgende uitdaging, het onderhoud!
Beter is om andere platforms te gebruiken voor het snel ontwikkelen van deze logica en bijvoorbeeld via iFrames de logica/applicatie aan te bieden. Daarmee doen beide wereld waarin ze goed zijn en voor zijn gemaakt.
Vriendelijke groet,
Mark
Alle punten zijn zoals sommige al vertellen valide in mijn opinie. Dat niet iedereen alles exact begrijpt is wel vervelend, maar dat heb ik bij meer artikelen op computable. Misschien omdat dit mijn vakgebied is dat ik het verhaal kan volgen.
Daarentegen snap ik wat reacties niet. Hoe kun je iets als voorbeeld stellen terwijl het eigenlijk vragen naar verduidelijking zijn in de techniek/opzet van SharePoint? Ja, je kan alles veilig (zelfs GxP compliant opzetten zodat zelfs de FDA het als een goed platform ziet)
De performance kun je heel goed inregelen en zelfs op uur nivo servers (in een volledig automatisch proces bijschakelen en/of down brengen, #eigenervaring)
Net zoals bijna elke CMS tool kun je op basis van conidties landen/sectoren voorzien van een bepaalde taal en zelfs “China-Compliant” maken door lokaal gerepliceerde repository te plaatsen. (wederom zelf gedaan)
Regio settings zoals $ en €, taal, tijdzone’s etc zijn per gebruiker, site, site collectie, farm, locatie, groep, in te stellen.
Je kan verschillende lokale wetgevingen qua regelgeving volgen… maar dat kun je in word ook. Ook digitale handtekeningen kunnen gebruikt/opgeslagen enz. worden.
Tot dusver eigenlijk dus meer vragen en onduidelijkheden en/of bevestiging van hetgeen wat in het artikel staat. Misschien verwacht ik te weinig van Computable, maar ik vind deze reeks tot dusver geen “afbreuk” van Computable.
@Mark: Ik snap wat je met je iFrames opmerking wil zeggen, als je SharePoint 2013 ziet en hoe daar het framework word uiteengezet en ook dat ze de integratie iets verder los willen trekken en meer “Facebook-app-achtige” integratie model kiezen komt dat ook meer bij wat jij suggereert.
Natuurlijk zijn de opmerkingen die tussendoor staan en die ik ook lees in het artikel van Anja waar dat de grootste valkuil en moeilijkheid van SharePoint is de organisatie/processen/etc. daar rondom heen. Mijn visie daarom is dat er tot op een bepaalde hoogte er een stuk van “afdwingen” van standaarden nodig is, maar de gebruikers zeker niet ’te’ veel beperken qua vrijheid van opzetten en indelen en gebruiken van SharePoint.
@Ewout: je kaapt mijn zin weg, ik wilde eigenlijk ook zeggen dat ik tot dusver de serie leuk vind en uitkijk naar het 4e deel.
Ik begeef mij in goed gezelschap als ik mijn opmerkingen uit deel 2 herhaal (Pavake (:-). Helaas zijn een aantal reacties immiddels wat grimmig van aard, het mag duidelijk zijn dat ik een grondige review vooraf heb laten plaatsvinden (en opmerkingen van andere deskundigen zijn opgenomen in de serie), zoals een ervaren schrijver betaamd.
Het is ook nu weer bijzonder om alle reacties te lezen en te zien hoe iedereen op zijn eigen manier aankijkt tegen het vakgebied en verschillende invalshoeken zoekt om een punt te benaderen. Voor elk wat wils, gelukkig maar. Waar ik blij van wordt is dat er inhoudelijk eigenlijk niet zoveel aan te merken lijkt op de punten die ik in deze serie als overzichtsartikel beschrijf.Dat sommige hun kruid te vroeg verspelen omdat ze niet kunnen wachten met een reactie tot alles is geplaatst is inherent aan de beperkingen van het format blog en de keuze voor een serie. Die kritiek neem ik zeker mee als ik nog eens een serie schrijf.
De heilige drie-eenheid voor een schrijver is m.i. nadenken over doel-doelgroep-medium. In dit geval levert dit een volgende redenering op:
Het doel was en is een overzichtsartikel te schrijven over collaboration tools en specifiek Sharepoint omdat deze een dusdanig dominante rol speelt in de markt dat, niemand die een oplossing zoekt in de richting van samenwerking, hier omheen kan (op zijn minst moet weten wat het is en kan cq niet kan).
De doelgroep is voor mij het lezerspubliek van Computable, een manager/professional die geinteresseerd is in IT maar geen deskundige is, tot en met de IT-professional (geen expert, die heeft andere fora en podia). Daarom is dit ook betrekkelijk eenvoudig geschreven, voor iedereen in die doelgroep te begrijpen, en niet te diepgaand.
Het medium is een blog, geen tijdschriftartikel of boek waarin ik zeker dieper ga (en voor de IT-professional waarschijnlijk beter herkenbaar ben als vakgenoot; Google rustig op mijn naam en je komt ook publicaties in andere media tegen en boeken (in november verschijnt een boek in het engels in een wetenschappelijke serie bij Springer in New York).
De opbouw van de boodschap voor dit brede publiek is een uitdaging, in 1 a 2 A4 een overzicht schetsen vraagt levert hier en daar wat verlies aan nuancering op en het is dus goed dat enkele van jullie mij helpen die alsnog toe te voegen.
Overigens geldt volgens mij ook voor het schrijven van reacties, dat de opbouw van de boodschap goed overwogen moet worden en om naar analogie van de afsluiting van deel twee in voetbaltermen te blijven “de bal gespeeld moet worden en niet de man” (en in dit geval vrouw).
Ik kijk nu al uit naar jullie opbouwende reacties op deel 4, die deze week door de redactie wordt vrijgegeven, tot binnenkort.
Anja,
Dat sommige reaguurders niet je beoogde doelgroep zijn is prima maar het zou leuk zijn als je toch inhoudelijk in zou gaan op wat reacties en niet telkens een (voor mij) nietszeggend antwoord cut & paste. Als dat voor jouw een probleem is mag natuurlijk ook je mede-auteur, Lisette de Haas antwoorden op een aantal vragen en opmerkingen.
@Anja
Je stelt:
“Het doel was en is een overzichtsartikel te schrijven over collaboration tools en specifiek Sharepoint omdat deze een dusdanig dominante rol speelt in de markt dat, niemand die een oplossing zoekt in de richting van samenwerking, hier omheen kan (op zijn minst moet weten wat het is en kan cq niet kan).”
Hierin zit het hele eieren eten daar waar het gaat om mijn reacties:
– wat is samenwerking in jouw context (zie mijn opmerkingen bij deel 1)? Ik doe heel veel aan collaborative software development, en ben heel goed in staat dit te doen zonder sharepoint (+/- 500 ontwikkelaars, meerdere landen/partijen)
– je noemt een aantal voor- en nadelen op van sharepoint. Ik ben absoluut geen sharepoint expert (alleen gebruiker van) dus daarin wil ik best afgaan op jouw expertise. Echter, bij het gros van de punten die je noemt mis ik een link naar het hele collaboration verhaal (althans, naar mijn definitie van collaboration, zijnde samenwerken over de volle breedte van applicatie lifecycle development over meerdere vestigingen/partijen/lokaties). Een aantal typische dingen waar je dan tegenaan loopt worden genoemd in de reactie van Michiel Hamers: kan het tool omgaan met bijv. regionale instellingen of wetgevingen.
Als het artikel alleen over sharepoint gegaan had, was ik niet zo kritisch geweest, maar ik ben nog steeds op zoek naar het “collaboration-sausje” in je verhaal.
Anja,
Ik zag ook na 3 publicaties geen verbetering in de kwaliteit van het onderwerp en ook jouw interactie met de lezers. Dat was ook voor me de reden om niet meer na de publicatie van dit deel op je artikel te reageren. Het is niet makkelijk om je verhaal in een stuk dat korter is dan een A4tje op te nemen, maar het is maar zo, dat doen we allemaal. En als je je doel in dat stuk tekst niet kan bereiken dan zou je je moeten afvragen wat je aan je stijl veranderen moet en hoe je de kwaliteit van je stuk verhogen kan.
Veel succes met het laatste deel van je publicaties.