Managed hosting door True

'Doc.Loods liep vast op bekend DMS-probleem'

Dit artikel delen:

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.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

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.

Ik snap niet zo goed hoe een functioneel probleem (teveel metadata, teveel en wildgroei van maatwerk) opgelost kan worden door een ander pakket naar binnen te schuiven. Dan heb je toch weer heel snel hetzelfde probleem?

@xmlfreak: zelfs al zou Logica hebben gewaarschuwd en er niet naar zijn geluisterd blijven ze verantwoordelijk. Althans, in een ver verleden heb ik onderwijs in ICT-recht gehad en daar werd aangegeven dat bij ICT wordt uitgegaan van de ondeskundigheid van de opdrachtgever en de deskundigheid van zich als zodanig opwerpende leveranciers en adviseurs. Daaraan werd verbonden dat een leverancier of adviseur daadwerkelijk zijn medewerking aan een project moet opzeggen om mede-aansprakelijkheid bij een eventueel debâcle te ontlopen. Dit was in de 80'er jaren en is weliswaar allang geen staande praktijk meer.

Het zou op zich allemaal niet zo spannend en bijzonder zijn ware het niet dat er met dit leerproces 10 miljoen euro belastinggeld is verbrand.

Gemeente Rotterdam roept al jaren dat ze een Oracle tenzij beleid heeft, deze software is waarschijnlijk naar binnen gesmokkeld. Hadden ze Oracle/Stellent software gebruikt was dit niet gebeurd.

@Erwin van Boven: Toevallig werk ik bij HP, en toevallig gebruiken wij zowel intern als extern heel veel Sharepoint. Denk dat de hoeveelheid informatie die daarin is opgeslagen toch wel van een heel ander orde grootte is dan Gemeente Rotterdam. Vraag me dus af hoe je bij jouw stelling komt

"e gemeente onderzoekt nu de mogelijkheid of er open source oplossingen beschikbaar zijn om tot een vereenvoudiging van de interface te komen."

Dit slaat toch als de spreekwoordelijke tiet op een piano. Wat heeft closed of open source te maken met "een "interface vereenvoudigen"???

Ik ben heel benieuwd naar:
1- Heeft gemeente R`dam eerst rondgekeken en overlegd met andere gemeenten om te weten wat hun ervaring en oplossingen zijn,

2- waarom voor dit product is gekozen, en niet bijvoorbeeld voor een gezamenlijk product met een andere gemeente (Joint Venture)

3- heeft gemeente R`dam een haalbaarheidstoets gedaan om te kijken of dit product het juiste is,

3- Wat Logica te zeggen heeft over wat er gebeurd is! Interessant te weten waarom dit project is misgegaan, los van wat gemeente R`dam zegt.

Het in lijn houden van metadata bij een DMS is an sich geen probleem, maar het goed opzetten is lastig. Archivaris is niet zo maar een beroep geworden. Ik heb laatst een blog hierover geschreven voor de liefhebbers: http://www.invantive.com/invantive/blog/entryid/9/langdurig-rendement-van-je-documenten-dankzij-proces-referentiele-metadata-en-tijdreizen

De heer Guido Leenders heeft gelijk. Metadata bij een DMS hoeft geen probleem te zijn. Men moet alleen wel vanaf de start van het project de juiste vakmensen bij halen; zoals mensen met een archivaris/DIV-achtergrond op HBO-niveau. En die zijn bij de gemeente Rotterdam gemakkelijk te vinden. Die vakmensen kunnen met behulp van een informatieanalist de metadata zodanig beschrijven dat andere ICT-ers ook snappen hoe men digitaal moet omgaan met archieven, postvoortgang- en afdoeninggegevens, zaaknummers, et cetera. Als dat gedaan is, kan de projectgroep een product selecteren dat voldoet aan de eisen van DIV (DIM), het centrale archief en de Rotterdams ambtenaar die gedacht wordt om “zaaksgewijs” te werken.
Door een slechte start door de Bestuursdienst en commercieel geklungel van Logica is men na jaren vastgelopen en frustreert het DMS andere projecten.

Het is overigens fijn om te horen dat de heer Nijman niet meer alleen Microsoft en Oracle propageert, maar ook voor Open Source is (al zijn open standaarden belangrijker).

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.