Het onderzoeksverslag van de Rotterdamse Rekenkamer verschijnt rijkelijk laat na het onderzoek uit 2010, zodat eventuele positieve ontwikkelingen sinds die tijd niet zijn meegenomen. Maar ‘Baat het niet dan kost het wel’, een onderzoek naar de kosten en baten van ICT-projecten van Gemeente Rotterdam, geeft voldoende boeiend materiaal om er alsnog aandacht aan te besteden. Ook vanwege de verschillende berichten die er sindsdien in de vakpers zijn verschenen, onder andere ‘Doc.loods liep vast op bekend DMS-probleem’ en ‘Rotterdam
vertilt zich aan DMS-project’.
De wereld van document management systemen (DMS) en recordsmanagement applicaties (RMA) is enorm in beweging de laatste paar jaren. Hummingbird, dat ver voor de doorbraak van Microsoft Sharepoint en de fusie van Hummingbird met OpenText gold als de top van de DMS/RMA systemen is links en rechts ingehaald. Implementaties duren in grote organisaties soms zo lang, dat nieuwe, meer geavanceerde en gebruiksvriendelijke producten al lang en breed op de markt zijn als proven technology. Zonder hier te willen twisten over de specifieke kwaliteiten van het product is er duidelijk een kentering zichtbaar: waar tussen 2000 en 2005 een ‘zwaar RMA’ als Hummingbird en EMCDocumentum de voorkeur verdiende van grotere Archiefwetplichtige organisaties, zie je na enige aarzeling tussen 2007-2010 nu menig gemeente of rijksinstelling de Sharepointimplementaties door voor- of achterdeur (!) naar binnenloodsen.
Over loodsen gesproken. De implementatie van Hummingbird/OpenText, in Gemeente Rotterdam bekend onder de projectnaam ’Doc.loods’, is niet zozeer mislukt, maar de geplande uitrol naar stadsdelen en diensten is blijven steken. Een stadsdeel, het Gemeentearchief en nog een tweetal gemeente onderdelen hebben het in gebruik genomen. Tien miljoen euro verder blijkt de klacht nu te zijn dat ‘ingewikkelde metadata’ (‘een bekend DMS-probleem’) het project zouden hebben laten klappen. Het probleem zou dan vooral de interface voor de eindgebruiker zijn, aldus de CIO in het artikel. En uiteindelijk komt dan als een soort konijn uit de hoge hoed, dat de gemeente (als oplossing van deze problematiek?) nu naar opensource oplossingen zou kijken, waarbij het product Alfresco met naam wordt genoemd. Er zijn meer opensource DMS producten dan alleen Alfresco, zodat het aanbestedingstechnisch al een twijfelachtige opmerking is. Maar als de redenering in het artikel daadwerkelijk zo gevolgd zou worden in Rotterdam, dan zijn er toch wel meer dingen mis.
Na zes jaar ontwikkelen en vier implementaties zou het onmogelijk moeten zijn om te concluderen dat de metadata te ingewikkeld zijn voor eindgebruikers of dat de interface niet prettig genoeg werkt. Welke testmethode – zoals TMap – je ook hanteert om een ICTproduct in productie te gaan nemen, een functionele test en een gebruikersacceptatietest maken al vele jaren deel uit van het vaste arsenaal aan imlementatiemethoden in de ICT. Uit ervaring weet ik dat de druk groot is om tests snel af te doen als een vervelende bijkomstigheid of formaliteit, maar deze mislukkingen geven aan dat een geformaliseerde testmethode, met heldere rapportages en acceptatiemomenten na afloop ook veel van de projectrisico’s kunnen wegnemen of reduceren.
Een ander maar wel gerelateerd punt is de betrokkenheid in deze testfase vanuit de organisatie. Het is bekend dat implementatietrajecten van een DMS/RMA systeem veelal begeleid of zelfs gestuurd worden vanuit archief- of DIVafdelingen. Natuurlijk zit daar vaak de expertise die onmisbaar is voor een succesvol traject. Maar behalve dat archivarissen en DIVers geen moeite hebben met een metadata-element méér bij hun documentregistraties, maken ze met hun ondersteunende rol in de organisatie en hun expertise geen deel uit van de overgrote meerderheid aan documentgebruikers. Want al die andere kenniswerkers in de primaire processen zijn een stuk minder geïnteresseerd in dossierinrichting en classificatie. Het document moet weg te zetten zijn met een paar klikken en hoe meer er automatisch gebeurt zonder menselijke tussenkomst, hoe beter (David Ferriero, de rijksarchivaris van de VS zei dat pas nog zo mooi, toen het over emailarchivering van het Witte Huis ging, als er te veel menselijke tussenkomst vereist was bij archivering van electronische berichten, dan werd hij pas echt ongerust, dat vond ik wel grappig voor een archivaris, maar dit terzijde).
Dus eigenlijk hadden de mankementen aan Doc.loods veel eerder onderkend moeten zijn in de testfases bij de eerste oplevering en daaropvolgende uitrolmomenten. Waarom dat niet gebeurd is, of waarom de resultaten niet deze conclusie aangaven wordt helaas niet helder uit de Rekenkamer rapportage of het artikel. Zeker is wel dat een nieuw aan te schaffen product, hoe opensource dat ook is, niet vanzelfsprekend tot minder ingewikkelde metadata zal leiden.
