Onze IT kwam met de vraag of we de bibliotheekcatalogus niet willen laten omzetten naar Sharepoint 2010: dan zijn we in elk geval nog van enige ondersteuning verzekerd.
Wel… ik weet zo goed als niets van Sharepoint: ben als een razende aan ’t inlezen en uitproberen nu.
Op internet is er niet veel over te vinden, en de collega’s die ik ernaar vroeg waren op zijn hoogst weifelend. Kan het? ‘To a hammer everything looks like a nail‘ hoorde ik twee mensen zeggen. Sharepoint wordt door de IT gezien als de haarlemmerolie van de 21e eeuw.
Ervaren collega’s waarschuwen me wel dat elke 3 jaar een nieuwe SP update komt, en dat je dan je hele site moet aanpassen. Met name de web parts geven dan gedonder, maar dat zouden we dus toch hebben…
Mijn eigen twijfels omvatten naast of het überhaupt kan -kun je een catalogusrecord als sharepointdocument zien?- ook het ontbreken aan udates en toevoegen van nieuwe functionaliteit vanuit het oogpunt van een catalogus-programmeur.
Aan de andere kant, als het het integreert zou je een workflowkunnen opzetten die beter bij het primaire proces aansluit, als je het voor elkaar krijgt.
En ik ben er nooit vies van om iets te proberen.
Laat ik eerst maar eens een lijstje maken met de functionaliteiten die onze catalogus nu heeft, en die ik graag in SP terug wil zien. Afhankelijk daarvan kan de IT dan beslissen of we inderdaad door mogen gaan met ons eigen programma en dat inbouwen in SP, of dat we de hele kaartenbak zelf er in leegkieperen.
We hebben nu een catalogus van 400.000 records: metadata met daaraan gekoppeld zo’n 200 GB full-text meestal in PDFs. Dat is geen kattenpis.
Functionaliteiten
Structuur:
- velden: herhaalbaar, onbeperkt van lengte
- woord (titel) en phrase (auteur) indexen
- tabellen en indexen gekoppeld aan bepaald velden (elk veld eigen index / evt tabel)
- zoek/vervang per veld over zoekselectie
- kopieren record / kopieren velden uit ander rcord
- nu koppeling op basis van http naar full-text: ?
Invoer
- afzonderlijk item: via views (invoerschermen op basis van materiaalsoort & locatie -nu 60- met deels vooringevoerde velden)
- tabellen en indexen om invoer losse items consistent te houden
- bulk: uitvoerformaat Pica – MOPC – RIS – selectie XML eigen uitvoer (zowel compleet record als selectie velden)
- overschrijven / aanvullen van records op basis van bep velden met unieke inhoud (PPN / ID)
Uitvoer
- diverse formaten lang: (complete record & selectie velden in) XML – Pica – APA – RIS – Vancouver – ISBD
- diverse formaten kort (om lijsten te maken): selectie van velden zelf vooraf samen te stellen & aan te vullen
- dynamische links – RSS (zie zoekacties)
- inversie auteursnamen (Vries, S.C. de -> S.C. de Vries)
Zoeken
- in basisindex (door onszelf te definiëren wat erin mag & aan te passen)
- in diverse combinaties van velden (auteur + editor / uitgever + corporatie) vooraf gedefineerd (door onself aan te vullen)
- in elk veld afzonderlijk
- via dynamische links / RSS van zoekactie
- zoekgeschiedenis: tijdens sessie blijven zoekacties bewaard – & wisoptie- om te kunnen combineren AND / OR / NOT / Whithin /genest
- aanvinken uit zoekactie wat je wilt bewaren alles / niets / selectie
- zoekactie (voorgedefinieerd of on-the-fly) bewaren als bestand / dynamische link / RSS
- zoeken beperken tot materiaalsoort / al dan niet digitaal
Leen
- lenersbestand (LDAP?)
- indien LDAP dan seintje bij aanstaande vertrek lener
- uitleen – rappel – innemen: meteen vanuit record, per item en als bulk
- overzicht uitgeleende items per lener
- ibl: (apart formaat, niet in catalogus, wel gekoppeld aan leners) reservering (waar / voor wie / NCC nr) – ontvangst – teruggestuurd + alle data daarvan)
(Tijdschriften)
- leveranciersbestand
- info over titel
- ontvangst – rappel
- circulatiebriefjes
Bestel
- leveranciersbestand (zelfde als voor tijdschriften). Kan CRM zijn, maar mogelijkheid voor leverancier niet in CRM
- bestelling gekoppeld aan record: te zien / aan te klikken vanuit record
- notatie ontvangst : datum, aantal
- overzicht van openstaande / ontvangen bestellingen per leverancier
- bestelinformatie: voor wie besteld naam + afdeling (kan LDAP zijn), datum
Vergeet ik nog wat?
Iemand nog goede ideeën?
Dee'tjes 
“Iemand nog goede ideëen”
Mijn eerste spontane reactie, Dymphie: niet aan beginnen. Misschien iets te kort door de bocht, maarrrr bezint eer ge begint. Interessant thema en ik snap ook dat de keuze hiervoor in jouw organisatie anders uit kan pakken dan in mijn organisatie.
Veel succes met je afweging. Ik ben heel erg benieuwd.
Groeten,
Guus
Goede ideeën? Een extreem korte haalbaarheidsstudie laten uitvoeren door je IT afdeling, of op zijn minst even 10 minuutjes laten bellen met een leverancier van een bibliotheeksysteem.
Toegegeven, het is op niveau van eindgebruiker maar ik ben redelijk bekend met Sharepoint 2007 en hoewel ik zeker weet dat je een veldenstructuur zonder problemen in het op lijsten gestoelde SP kunt krijgen, houdt het daar ook volledig mee op qua emuleren van de functionaliteiten van een volwaardig bibliotheeksysteem. Als ik je lijst met functionele eisen naloop dan zie ik bijna alleen maar dingen waarvan ik zeker weet dat het niet out of the box kan met Sharepoint. Dat begint al met herhaalde velden waar je aparte indexen op wilt (kan niet) en de zoek&vervang functie binnen en tussen records (kan niet). Uitvoerformaten of uberhaupt presenteerformaten zijn redelijk beperkt tot de views die je in SP kan aanmaken maar die kunnen weinig meer dan sorteren, groeperen en/of filteren van de aangemaakte velden: niks geen PICA of RIS standaarden.
Over circulatie (tijdschriftenbeheer en uitleenadministratie) heb ik het dan nog niet eens. Een record aanmaken zal nog gebrekkig kunnen (dus stel daar expliciete criteria voor op waar het aan moet voldoen, dus welke velden nodig zijn!), het eraan koppelen van exemplaren en exemplaarinformatie met een eigen exemplaarrecord kan niet out of the box. Dat die exemplaren dan de status uitgeleend meekrijgen en er een rappeladministratie achter hangt, ook niet mogelijk. Over koppelingen nadenken met andere systemen als leverancierbestanden of godbetert, zelfservice, ik zie het niet gebeuren.
Oh ja, en als je IT afdeling je wijsmaakt dat de zoekmogelijkheden van Sharepoint optimaal zijn, prik daar zsm doorheen, IT-ers vinden fulltext kunnen doorzoeken het enige criterium van zoeken. Zelfs met Sogeti en een paar belletjes aan Microsoft zelf kreeg ik niet boven tafel hoe de zoekfunctie precies werkt, lees wat de wegingsfactoren zijn voor de relevancy ranking. Bij je criteria van zoekopties schat ik dat 80% absoluut niet kan met de standaard Sharepoint.
*Als*, en ik herhaal *als*, het mogelijk is om een catalogus plus beheer en circulatiemodule te bouwen in Sharepoint dan komen daar diverse extra add-on pakketten van andere leveranciers aan te pas icm een heel ontwikkel-maatwerktraject. Het zou me werkelijk niet verbazen als de kosten daarvan hoger waren dan van je huidige bibliotheeksoftware. En dat is uiteindelijk het enige steekhoudende argument waarmee je een IT afdeling kunt overtuigen.
Sharepoint vind ik een uitstekend systeem maar het is (nog niet eens trouwens) een CMS. Bibliotheeksystemen zijn complexe en uitbreide relationele databases waar echter geen fulltext content in te vinden is over het algemeen. Deze vraag van je IT afdeling mag je vergelijken met die IT-ers (en docenten) die ik vroeger langs kreeg in de bibliotheek en die opmerkten dat ze ‘zelf ook wel een Access database’je in elkaar konden zetten voor die boekies’. Ik ben projectleider geweest van inrichting en implementatie van een bibliotheeksysteem ruim 10 jaar geleden. Vergeleken daarmee zijn de lijsten en documentlibraries in Sharepoint idd kinderspel.
Positieve signalen? Heb ik ook hoor. Als je bereid bent 80% van je functionaliteiten van je huidige systeem op te offeren is het met veel maatwerk best in Sharepoint te krijgen. Vervolgens kun je dat doorverkopen aan andere instellingen met bibliotheken 😉
Ik ben wel heel benieuwd naar de verdere ontwikkelingen, daar dan niet van.
groet,
Raymond
Wij werken met Sharepoint 2007 als een portal en document library. Het systeem bestaat vooral uit lijsten waarin je metadata zelf kunt definiëren. Aan items koppel je documenten. Revisies hiervan kun je bijhouden. Een volwaardig CMS is het niet want als je die lijsten dan wilt tonen, zou je verwachten dat je de webparts eenvoudig kunt instellen voor gebruikers. Dat lijkt te kunnen, maar gebruikers worden als lezers, bewerkers etc. van documenten gezien. Er is in Sharepoint geen duidelijk onderscheid tussen een backend en een front end op applicatieniveau. Dat moet er helemaal in geprogrammeerd worden. Er zijn wel diverse gebruikers te definiëren, maar dat is niet toereikend om out of the box een CMS te bouwen.
Sharepoint hangt natuurlijk helemaal aan de andere Microsoft Office Producten. Dat maakt het krachtig als al die andere applicaties er zijn, maar ook wel beperkt: exporten van data zullen altijd via stappen moeten gaan met bijbehorende Office producten, veel moet geprogrammeerd worden. En hoe zou je je data er in moeten krijgen? Hier zijn geen standaard voorzieningen voor. Met andere woorden: het is nogal een in zichzelf gekeerd systeem, dat primair een document library is, een server versie van Microsoft Office, waarin de focus ligt op kantoor documenten en hun cycli. Dat is iets heel anders dan een catalogus. Hoewel wat dat is tegenwoordig natuurlijk ook sterk aan discussie onderhevig is.
Groeten,
Henk
Allemaal heel erg bedankt voor de reacties.
Ikzelf ben er ook huiverig voor omdat ik nog geen enkel zelf-gemaakt bibliotheeksysteem -bij collega’s- heb gezien dat echt goed functioneerde.
Ben zelf ook reuze benieuwd wat het gaat worden.
Ik hou jullie op de hoogte, en als je nog tips h ebt: ik hou me aanbevolen!
Hi!
Ik kwam je blog tegen via google en vind het een super idee om eens verder over na te denken.
SharePoint 2010 biedt veel nieuwe functionaliteit (sterk verbeterde search, taxonomie, enz.) die hier absoluut veel waarde toevoegen en wat in 2007 onmogelijk was.
Ik heb ervaring met het implementeren van SharePoint 2010 als archief systeem (conform NEN 2082) en zie hier veel overeenkomsten in. In een archief heb je bijvoorbeeld ook elektronische en niet elektronische stukken. Ook zijn er mogelijkheden voor bijvoorbeeld rappellijsten.
Aangezien ik zelf voor een SharePoint club werk die ook bij diverse bibliotheken SharePoint heeft geïmplementeerd zou ik je willen aanbieden om eens (uiteraard geheel vrijblijvend) een afspraak te maken waarin we obv een werkende demo omgeving een aantal kritische punten bekijken. Dit kan je een goed beeld geven bij wat standaard (on)mogelijk is. Ik wil hiermee nog niet zeggen dat SharePoint 100% geschikt is maar zie wel veel aanknopingspunten.
groet,
Alexander
Beste Dymphie,
Jazeker is het mogelijk om met sharepoint 2010 een bibliotheekcatalogus te maken. De vele mogelijkheden die sharepoint biedt en de maatwerkoplossingen die gemaakt kunnen worden maken alle functionaliteiten mogelijk. Een goede voorbereiding en duidelijke afspraken met het ontwikkelteam zijn van groot belang. Zelf hebben wij reeds diverse portals gebouwd waarin identieke situatie voorkomen.
Natuurlijk betreft het geen standaardoplossing en zal er een groot gedeelte op maat gemaakt moeten worden.
Er is veel mogelijk maar feit blijft dat aan alle oplossingen zowel voor- als nadelen zitten. Het is verstandig om hierover met de professionals goede afspraken te maken. Technisch is het mogelijk! Maar niet alleen de techniek bepaalt of het uitgevoerd kan worden!
groet,
Roy