Van Fileshare naar Metadata

Fileshares!
Veel klanten komen vanuit de situatie waarin alle documenten worden opgeslagen in fileshares. Met de introductie van een online teamsite moeten al die documenten worden ondergebracht in deze web omgeving.
Het is jammer als we gewoon een copy – paste aktie uitvoeren, we maken dan geen gebruik van de extra functies die online teamsites in de regel bieden. Vanuit eindgebruikersperspectief introduceren we dan alleen maar belemmeringen (zoals de iets lager performance, inherent aan web omgevingen).
Het grootste verschil tussen een fileshare en een team site is het gebruik van metadata. Metadata stelt je in staat om meerdere weergaven te tonen van de documentenset (een folderstructuur is slechts 1 weergave die ook nog eens gefixeerd is). Daarnaast verhoogt het de doorzoekbaarheid van documenten (door het expliciet vermelden van additionele eigenschappen van een document).
Hoe transformeer je een fileshare naar een teamsite?
Hieronder een startpunt om van een fileshare naar een teamsite te migreren. In dit voorbeeld wordt uitgegaan van een migratie naar SharePoint WSS 3 (de basis variant van SharePoint 2007). Met wat inlevingsvermogen is het ook van toepassing op andere producten. Let op, dit is een startpunt oftewel uitgangspunten. Iedere situatie is uniek, de echte vertaling hoort in de implementatie te zitten! Toch een poging om je alvast op weg te helpen.

1. de eerste map of drive letter is vaak een teamsite
2. het eerste niveau van je mappenstructuur leidt vaak tot libaries (vanwege basale security)
3. alle onderliggende folderniveau’s kunnen heel vaak opgelost worden met (site) kolommen
4. alle folderknooppunten (mappen met alleen maar submappen en geen documenten) die gebaseerd zijn op standaard eigenschappen van de software (hier SharePoint) kunnen meteen verwijderd worden, ze worden namelijk opgepakt als weergave (view)

Standaard document eigenschappen van SharePoint zijn onder meer:

• bestandsnaam
• titel
• naam auteur
• datum en tijd creatie of upload
• datum en tijd mutatie
• naam gewijzigd door…
• type document (Word, Excel, PowerPoint, PDF)
• versie (hierover komt nog een blogpost)

Deze eigenschappen vervallen dus in de team site structuur.
Metadata verplicht?
Voor de werking van de weergaven en een voorspelbare verfijning van Search is vaak een kern set aan metadata noodzakelijk. Deze moet je kunnen afdwingen. Maximaal aantal is ongeveer 4 velden voor wat formelere documenten. Voorkom het gebruik van “overige”, “divers”, “algemeen” etc. omdat ze helemaal geen informatie opleveren.
Ga er van uit dat niet-verplichte metadata vaak ook niet wordt ingevuld.
Combineer een kern-set met tagging (sterk verbeterd in SharePoint 2010), wat rekening houdt met actuele termen (vaak in tegenstelling tot een strakke taxonomie, die bijna altijd verouderd is).
Voorbeelden van kern set metadata
Algemene voorbeelden zijn:

• publicatie status (intern, naar klant)
• revisie datum (datum waarop document herzien moet worden)
• revisie groep (wie gaat de revisie uitvoeren)
• archiefwaardig (ja/nee, moet het worden verwijderd of blijft het bewaard) in geval van ontbreken information policies of records management
• document taal (dropdown lijst van schrijftaal document)

Wat meer specifieke (in de context van een project) voorbeelden zijn:

• projectfase
• deliverable
• milestone

Als we het type document gaan opnemen kunnen we deze beter vertalen naar de content types (zoals Kennisdocument, Brief, Memo, Projectplan, Voortgangsrapport, Contract, Offerte, Rapport, Verslag, Functioneel ontwerp etc.).
Limieten
Er zijn limieten aan het gebruik van een enkele library met metadata:

• meer dan 2000 documenten in een SharePoint 2007 library vertraagt de rendering van de pagina (het wordt gewoon traag), aparte libraries of folders heffen deze beperking weer op
• als het toekennen van rechten erg fijnmazig moet verlopen, dan is het gebruik van folders in een library een optie (geen item level security gebruiken, niet beheersbaar op langere termijn), met views halen we de folderstructuur weer weg…

Nuancering
De echte transformatie kan wel eens een flinke klus zijn. Als je de bovenstaande uitgangspunten eens toepast op je filestructuur, dan ben je volgens mij al een eind op weg. Het is echter belangrijk dat je vanaf de start van je implementatie gebruik maakt van de additionele voordelen van metadata (of tagging). Zorg ervoor dat eindgebruikers ook direct de voordelen kunnen gebruiken (zoals views op de libraries, zelf view kunnen maken, ingerichte Search richting prefilter en verfijningen op metadata). Alleen dan zullen eindgebruikers de metadata vullen en de wat langere wachttijd voor Opslaan voor lief nemen.
Het voordeel komt pas naar voren na enkele weken intensief gebruik. Daarna wil je niet meer terug naar de fileshare! De moeite waard, denk ik zo…