Dat de invoering van het gemeentebrede documentmanagementsysteem (dms) Doc.Loods in Rotterdam is mislukt, komt door de ingewikkelde metadata. Dat is een bekend probleem in de dms-wereld. De gemeente onderzoekt nu de mogelijkheid of er open source oplossingen beschikbaar zijn om tot een vereenvoudiging van de interface te komen. Dat zegt Hans Nijman, chief information officer (cio) van de gemeente Rotterdam.
Bij de gemeente Rotterdam is vanaf 2004 tevergeefs geprobeerd een nieuw dms in te voeren. De kosten bedroegen ruim tien miljoen euro. Nadat de in 2009 aangetreden cio Hans Nijman merkte dat er een nieuwe budgetoverschrijding dreigde, legde hij het project vorig jaar stil. Doc.Loods is een op Hummingbird-gebaseerd systeem dat door leverancier Logica op maat moest worden gemaakt voor de gemeente Rotterdam.
Cio Nijman wil de nuance aanbrengen dat er weldegelijk functionaliteit is opgeleverd. Zo is Doc.Loods bij een aantal diensten in gebruik, wordt de archiveringsfunctionaliteit gebruikt en er is een dossiermodule gerealiseerd voor de digitale omgevingsvergunning in het kader van de Wabo. Maar de gemeentebrede uitrol van de interface van het Hummingbird-product is mislukt. Dat leverde te veel maatwerk op in relatie tot het postvoortgangsproces
Struikelblok
Nijman: 'Het grote struikelblok, en dat is een bekend probleem bij een dms, is dat er bij zo'n systeem om te ingewikkelde metadata wordt gevraagd waardoor het voor gebruikers onwerkbaar wordt. Dat was hier ook het probleem.' De cio vertelt dat een stuurgroep momenteel op de markt rondkijkt of er werkbare oplossingen beschikbaar zijn om tegen beperkte kosten tot een vereenvoudiging van de interface te komen. 'Ik ben pleitbezorger van open source, zoals Alfresco, én hergebruik.'
Interview
Lees ook het uitgebreide interview met cio Hans Nijman: Verbeterplan ict bij gemeente Rotterdam ligt op koers.
Meestal lees je verhalen over projecten die te ver doorgeschoten zijn. Het lijkt me goed dat hij wel dingen durft stop te zetten.
Geen idee wat Hans Nijman bedoelt met metadata. Bedoelt hij een structuur van document-properties waaronder de documenten geïndexeerd worden of wellicht de tabelstructuur van de toegepaste indexering? Waarom zou dat te complex worden? Dat soort structuren wordt toch opgezet aan de hand van de gewenste functionaliteit? Is te complexe metadata dan niet de boodschapper die de schuld krijgt?
Vanuit onze ervaringen met Sharepoint het afgelopen jaar hebben we in ieder geval ontdekt dat iedere applicatie ‘multi-tenant’ moet worden opgezet als je hem wilt kunnen opschalen, zelfs al is ie voor één organisatie. Beschikbaarheid van gegevens onder een bepaalde gebruikersrol moet volledig bepaald worden door de rechten op het document te bepalen op het moment van aanmaak, niet door de plaats of folder waarin het document terechtkomt.
De voordelen zijn, dat de ontwikkelaar op alle overige plekken niets meer te stellen heeft met welke documenten wanneer zichtbaar en toegankelijk zijn en dat alle documenten van een bepaald type in één omgeving terecht kunnen komen. Moet je eens kijken wat dat doet voor je metadata.
Ik denk dat niet zozeer de te complexe metadata het probleem is maar eerder onjuiste configuratiekeuzes. Bij dergelijke configuraties is het altijd de kunst om het zo eenvoudig mogelijk te houden zodat alle werknemers goed met het DMS kunnen werken.
Mogelijke oorzaak kan ook zijn dat indertijd simpelweg voor het verkeerde platform gekozen is. Helaas zie ik vaker desastreuze beslissingen genomen worden vanuit het architecturele vlak die gebaseerd lijken op persoonlijke voorkeur van de desbetreffende ontwerper.
Niet zelden krijg ik het idee dat van tevoren te weinig gekeken wordt welke capaciteiten werkelijk worden gevraagd en het te simplistisch inschatten van de zoekfunctionaliteit die een dergelijke applicatie vraagt.
Een degelijk plan dat door meerdere partijen kan worden bekeken (zeker op aanbestedingsniveau zoals bij gemeenten gebruikelijk) kan veel informatie opleveren over de gevraagde ‘zwaarte’ van benodigde infrastructuur en toepassingen.
Sharepoint is bijvoorbeeld een leuk pakketje voor kleine tot middelgrote documentverzamelingen maar schiet toch echt tekort als je het over serieus grote hoeveelheden hebt zoals in geval van een grote gemeente.
Gecombineerd met alle privacy wetgeving en gebruiks- en toegangsrechten van dien heb je een stevige toepassing nodig, hopelijk kan die worden gevonden binnen het Open Source domein.
Als men het heeft over “te ingewikkelde metadata wordt gevraagd waardoor het voor gebruikers onwerkbaar wordt”, dan is dat de bekende valkuil van content management systeem implementaties, dat de klant/opdrachtgever gewoon te veel metadata van de content wil vastleggen, waardoor de eindgebruiker teveel gegevens moet invoeren om content te kunnen toevoegen. Bij ‘Te veel’ moet je denken aan honderden attributen per object. Voor een systeem is dat geen probleem, maar wel voor gebruikers.
Om dit aantal attributen te verlagen verlangt daadkracht en de wens om het simpel te houden, hetgeen vooral in overheidsorganisaties lastig is.
Het is een uitstekende gedachte bij de (her)ontwikkeling en invoering van een dergelijk systeem eerst vanuit een gebruikersperspectief de werkwijze trachten “te vangen”.
Veel DMS systeem-implementaties hebben een virtuele realiteit geschapen voor documentstromen/parafenlijnen die ver afstaat van de dagelijkse werkwijze.
Met name het concept standaardisatie van workflows is een levensgevaarlijke aangezien dit doorgaans enkel zorgt voor oversimplificatie of overcomplexiteit.
De eigenlijke vraag bij DMS trajecten moet ook niet zozeer zijn “hoe gaan we nu met documenten om” maar “hoe gaan we straks besluitvorming reconstrueren en verantwoorden” en welke metadata is daar dan voor nodig.
Ook zijn de invoering van dergelijke systemen bij uitstek een kans om eens grondig de (vaak historisch gegroeide) mandaterings/beslisstructuur onder de loep te nemen.
@Erwin van Boven: Sharepoint een leuk pakketje??? Weet jij een groter platform of iets met een grotere schaalbaarheid? Sharepoint is absurd zwaar. Anders moet je voor de grap even zoeken op literatuur omtrent Sharepoint.
@Rob Koelmans Ik ben het met je eens Sharepoint is behoorlijk schaalbaar. Mogelijk is dhr. Van Boven alleen bekend met Windows sharepoint services (WSS)
Hulde aan deze CIO die op de rem is gaan staan…maar roept hij nu aan het eind wel iets te zien in alfresco?
Wat is de verdere rol van implementatiepartner Logica hierin? Zij zijn het immers die deze obstakels niet vroegtijdig mede hebben gedetecteerd en voor adequate alternatieven hebben gezorgd. of misschien wel, maar werd er niet naar hen geluisterd, wie zal het zeggen…
Metadata altijd lastig, KISS principe is hier idd het devies. Eindgebruikers weten vaak niet wat metadata kan betekenen voor de organisatie 🙁
Ik zie hier helaas mensen dingen roepen die niet relevant zijn, en niet op empirische waarnemingen gebaseerd (ik bash uit principe nooit,heeft namelijk geen enkele zin)… schaalbaarheid is architectuur ding , puur technisch en te testen. Heeft niets met vendor te maken maar met de juiste keuzes qua architectuur, open- of closed source maakt hierin niet uit. “Meten is weten, en weet wat je meet”.
“forgive me if I’m wrong” maar hier spreken we over SOAP.
Quote “Maar de gemeentebrede uitrol van de interface van het Hummingbird-product is mislukt. Dat leverde te veel maatwerk op in relatie tot het postvoortgangsproces”
Misschien was het beter geweest om aan te geven waar deze bottleneck precies in zat. Deze constatering alleen laat teveel vragen open. Het betrof hier dus een integratie probleem, gemeentebreed!
Voor een bescheiden uitleg omtrent Microsoft metadata heb ik dit ooit eens aan mijn blog toegevoegd: http://xmlfreak.wordpress.com/2010/12/04/metadata-kwestie-van-vrijheid-van-data-uiting-en-bescherming-part-1/
en hier : http://xmlfreak.wordpress.com/2010/12/05/metadate-kwestie-van-data-uiting-en-bescherming-part2/
Altijd weer bijzonder om te zien dat mensen die niet betrokken zijn bij het project, weten wat het échte probleem is en nog beter: zelfs de oplossing!
Metadata is handig voor het organiseren van content, maar een last voor de gebruikers die het moeten invoeren. Als ik dan ook nog “maatwerk” lees, dan kan ik me voorstellen dat zo’n project mislukt.
Ik ben benieuwd naar die user interface en waarom Alfresco of een ander OSS daar beter in zou zijn.