wikiup

Waarom Sharepoint Wiki volgens gebruikers niet werkt

januari 29, 2009 at 9:00 am 3 reacties

Belofte maakt schuld. Eerder had ik belooft om een review van de Sharepoint Wiki module te schrijven. Dit omdat pertinent naar voren komt dat mensen graag zouden hebben dat deze wel goed is en tegelijkertijd zien dat dit niet zo is.

Dit artikel bestaat uit 2 delen waarvan dit de eerste is:

1) Waarom Sharepoint volgens toekomstige gebruikers niet werkt?

2) Waarom de Sharepoint wiki volgens wiki-experts niet werkt?

Toekomstige gebruikers

Met een team van medewerkers heb ik een pilot project gedaan, om te proeven wat wiki is en waarvoor dit te gebruiken is. Na afloop van dit project kwam de vraag in welke mate dit moest aansluiten bij de lopende Sharepoint implementatie. 1 systeem is vaak goedkoper als 2, met name omdat de beheerskosten 50% van de totale systeem lifecycle kosten zijn. Minder IT’ers nodig dus. Echter is de Sharepointwiki module  wel een zinnige oplossing?

Ervaring

De pilot groep was enigszin beslagen in het gebruik in wiki’s maar had de functionaliteit nog niet professioneel ingezet, daar het een verkenning betrof. We hebben een aantal basistaken uitgevoerd en gekeken in hoeverre er een match was met het Sharepointwiki. De issues:

1. Organiseren van pagina’s
   Pagina’s kunnen, identiek aan mediawiki software, niet in een hierarchie geplaatst worden. Ze staan allemaal ‘naast’ elkaar. Omdat men niet verplicht is de onderlinge pagina’s te linken, wordt het aanbod van pagina’s al snel heel erg groot en daarmee onoverzichtelijk. Men moet met de hand constant navigatie en of landingspagina’s aanmaken, een tijdrovend klusje.
2. Commentaar plaatsen
   Er is geen mogelijkheid om commentaar aan een pagina toe te voegen. Dit is onhandig, want dit betekent dat in de pagina’s zelf de discussie moet plaats vinden. Een voorbeeld is “ (Aan GebruikerX: wat vind jij hiervan?)
3. Bestanden en plaatjes plaatsen
   Gebruikers kunnen niet een bestand (template of plaatje) direct aan een wiki-pagina toevoegen. De pagina’s die hierdoor ontstaan zullen voornamelijk uit tekst en links bestaan, en geen overige contenttypen. Bestanden kunnen wel gelinked worden. Dit betekent dat de gebruiker eerst het bestand upload in een plaatjes of bestanden -library. Vervolgens dient deze de link op te zoeken en deze in de wiki inplakken.
4. Verlaten pagina’s
   Gebruikers (& Beheerders) kunnen niet een overzicht van verlaten (niet gelinkde en niet bezochte) pagina’s opvragen. Het verwijderen van deze pagina’s houdt de boel schoon en overzichtelijk.
5. Populaire / Niet populaire pagina’s
   Gebruikers (& Beheerders) kunnen geen overzicht van de populariteit van de pagina’s krijgen. Dit zorgt voor dat waardevolle kennis herkend wordt (kwaliteit) en brengt ook in kaart waar men in de praktijk tegen aan loopt. Dit vormt vaak een beginpunt van inspiratie voor kennisontwikkeling.
6. Gewenste of lege pagina’s
   Gebruikers kunnen niet een overzicht van niet gevulde pagina’s opvragen. Dit nodigt juist mensen uit om hun specifieke kennis bij te dragen en benoemd open vragen in de organisatie.
7. Recente bezoekers
   Inzicht in wie actief op de wiki-site is helpt de acceptatie te verhogen. Het is niet leeg of onbezocht, er gebeurt wat. Het wordt nog sterker een sociale omgeving.
8. Email notificatie
   Als gebruikers zich abonneren op een pagina dan wordt bij wijziging de integrale pagina verstuurd. Handiger is dat alleen de wijzigingen worden verstuurd. Dat scheelt flink in leestijd. Hierdoor wordt de alert functie ook meer gebruikt en is men meer betrokken bij de veranderingen die anderen aanbrengen. Ook wordt de integrale tekst verstuurd bij een hele kleine wijziging zoals spelling en dergelijke. Er is geen mogelijkheid om aan te geven dat het een kleine wijziging betreft en de ge-abboneerden geen e-mail hoeven te krijgen.
9. Change Summary
   Men kan niet snel de laatste wijzigingen van een pagina op het scherm krijgen. Dit is gedeeltelijk identiek aan bij de beperkingen bij E-mail Notification. Bij grote lappen tekst moet men dus zoeken naar de wijziging in de pagina. Ook ontbreekt de mogelijkheid om dit met kleurtjes te markeren. Alhoewel dat een functie voor gevorderde gebruiker is.

Punten 1-3 hebben vooral te maken met het gemak waarmee kennisgedeeld kan worden. Bij Sharepoint is dit niet altijd even gelukkig ontworpen. Punten 4-7 hebben te maken met de sociale processen rond een wiki. Dit zijn punten die acceptatie en gebruik onder gebruikers versnellen. Punten 8-9 hebben een relatie met het gemak waarmee op de hoogte kan worden gebleven.

Dit allemaal zijn issues die op te lossen zijn. Dit kan door met kleinschalig maatwerk Sharepoint aan te passen danwel een wiki te nemen die integreert met Sharepoint. Zo blijft er een centrale portal met een uniforme look and feel. De keuze hierin hangt af van een aantal factoren: Kosten van implementatie v.s. de Synergie voordelen in beheer. Kijk ook naar het tijdspad wanneer de organisatie Sharepoint 2009 gaat implementeren. De verwachting is dat deze versie een hoop van de issues heeft opgelost. Als laatste kijk goed naar de gebruikersgroep. Als deze in potentie snel kan doorgroeien naar gevorderd gebruik, zal basisfunctionaliteit steeds minder voldoen.

Gepost onder:Uncategorized. Tags:Organisatie, sharepoint, Wiki.