Daarom een selectie uit argumenten zoals besproken in de Sharepoint wiki  workshop op de wikiSym 2008.

Allereerst, wat is Sharepoint wiki? Om goed up and running te komen in deze discussie is het handig om de volgende filmpjes en sites door te nemen: Microsoft site Demosite Channel9.

We gaan hier geen pro argumenten noemen voor Microsoft. Deze zijn er overduidelijk wat betreft leveranciers kwaliteit, integratie met andere producten en aansluiting met andere ICT Strategie gerelateerde zaken.

Wat belangrijk is om te weten: Microsoft is relatief laat in de wiki markt gestapt. Dit heeft een ironie in zich, omdat Sharepoint geinspireerd is op een van de eerste wiki’s: Die van Ward Cunningham. Bij Microsoft zijn ze ook niet gek, en Sharepoint als product kent een lange geschiedenis van R&D (1997-1999: Site Server) tot de huidige versie 2007.

Ik neem de punten over van het expert panel, en laat die achterwege waar ik geen goede interpretatie kan aanbieden

• Alleen correct Internet Explorer ondersteuning
• Nieuwe pagina’s worden standaard afgeschermd, ipv. open voor de hele organisatie te zijn
• De prijs van MOSS2007 loopt van 4400 tot 57000 dollar. Om dit enkel als wiki te gebruiken is dit in ieder geval erg duur.
• Gericht op archiveren van documenten (authoritive versions) , ipv snel en eenvoudig samenwerken rond concepten
• Basis wiki functionaliteit – maar te beperkt want gebruikers klagen er over
• Focus van Microsoft ligt op andere punten, namelijk documenten en koppeling andere producten
• Ongeldige html documenten zijn een risico voor archivering en koppeling andere systemen. (Lex: Dit is wel met nieuwe versies stapsgewijs beter geworden)
• Geen export mogelijkheden dus lastig koppelen & migreren
• Import functies ontbreken. (Lex: Organisaties met een mediawiki zullen alles handmatig moeten overzetten.)
• Omdat het niet een officiele module is, maar een template zijn er geen garanties rond upgrades. Micorosoft heeft de vrijheid om dit bij nieuwere versies wiki niet meer te ondersteunen. (Lex: het is even de vraag in hoeverre dit een daadwerkelijk risico is..)

Dit gecombineerd met de conclusies van de gebruikers zijn er de volgende keuzes:

1) Pleeg (kostbaar) maatwerk om de wiki gebruikersklaar te maken

2) Wacht op de nieuwe Sharepoint 2009/2010 waar de wiki waarschijnlijk een stuk beter is

3) Neem een aparte wiki-oplossing.

Aan u de keuze!

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.

DMS en proces

Dat Sharepoint een duidelijke positie in de arena van Document Management Systemen (DMS) verworden heeft was al eerder duidelijk uit dit artikel van information week. Ikzelf , mijn eerdere blog, schreef ik al over de verschillen in toepassing tussen Sharepoint en Wiki’s. Sharepoint is beter voor vaste bekende processen en Wiki’s zijn beter voor improvisatie.

Improvisatie

Als het om documenten gaat, is dat dé manier om in Sharepoint te improviseren. (Ik laat de Sharepoint Wiki module hier even buiten beschouwing, omdat deze te beperkt is en hierdoor weinig succesvolle toepassingen kent.) Niet gek dat ze dat bij Microsoft zo bedacht hebben: De meeste organisaties werken op basis van online drives, digitale documenten en e-mail. Sharepoint is dat betreft een mogelijke e-mail killer en een grote verbetering ten opzichte van de netwerk schijven door betere zoek en geintegreerd versie beheer.

Productiviteit

Wiki’s nemen de gedachte van het verwijderen van inproductieve stappen een niveau hoger. Door in de wiki te werken, hoef je niet ook geen documenten meer te plaatsen of op te halen. Ook kan er makkelijker een structuur aangemaakt worden. Met documenten is de organisatie er een van mappen, in wiki worden pagina’s onderling met elkaar verbonden. In plaats van organisatie op basis van (ver)plaatsen, is er organisatie op basis van verbinding. Wederom het verwijderen van inproductieve stappen.

Rapporten

Wiki’s kennen ook een prijs: Als men uiteindelijk een rapport naar de klant wil sturen, dan zal men de pagina’s moeten ophalen , converteren en integreren in een document. Nieuwe versies van pagina’s worden dan niet automatisch in het document geplaatst. Als dit teveel werk is, zal men de concepten beter niet in wiki uitwerken. Desalniettemin kunnen bij deze typen (Gartner ? Forrester?) organisaties wiki nuttig zijn. Gebruik de wiki dan voor de algemene kennisbank en als vervanger van intranet – maar dan interactief voor de medewerkers.

Als laatste: Wiki’s kennen tegenwoordig ook integratie en import en export mogelijkheden met Word. Zo kunnen bestaand *.doc handleidingen eenvoudig in de wiki gebruikt worden.

Met betrekking tot de Sharepoint Wiki Module: Binnenkort zal ik hier een artikel aan wijden. Waarom het niet werkt, en wat er nodig is om het wel te laten werken.

Sharepoint

So I would put Sharepoint up for the 80% most important processes your organisation internally has in common, and optimize the software for productivity and quality around that. For instance, often organisations start with migrating their team and project network drives to Sharepoint and open up a lot of data company wide. The Sharepoint search will help employees find the right documents. Perhaps certain types of projectdocument folders are structured, for instance for each project in different phases. Perhaps the project has a workflow (planned, in action, finished etc.) for which you would like your employees to use that new system.

Wiki

Wiki’s would cater a different challange. How can users do and organise their work which is different from what their collegues do? How can they work effectively on non-core processes organisation wide? For instance, design a little database table with all approved catering companies, and share it with others for party’s? And how can other employees also contribute to that page if they know a good caterer?

That’s the remaining 20 % which you can support by wiki. It’s heterogenous and not directly important to your business. But, in the end, you can make substantial savings with optimizing these processes.

More wiki ahead

After all, a knowledge economy implies less factory-like processes and more innovation and change driven processes. So this 20% could be higher in your case. It is likely to grow in the near future. No wonder that innovative company’s like Motorola, Google and Intel are heavy wiki users. They let their employees decide on their own processes. Motivation and control is done by appropriate (result based) rewarding, getting passionate employees, and good facilities (no personal productivity constraints).

Wiki or Sharepoint

So, in the end the decision is yours to make and would be based on the business needs. Do you need to centralize or decentralize? Know that implementing wiki is about getting users to use it for their own needs and implementing Sharepoint is about getting the right technical fit with the needs of your organisation.
The combination of both is possible but -mind you- not all wiki’s connect to Sharepoint!

Good luck