Document management: Many organizations still store growing numbers of digital documents in multiple locations or personal file-sharing accounts.
As the amount of digital information grows at an ever-faster rate, this chaotic approach to document management leads to frustration and wasted resources. From tedious and time-consuming search for the correct document version, to slowed business processes, more mistakes occur and expenses go up.
Image: Yan Krukau
Although Document Management Systems (DMS) can play an important role in facilitating effective collaboration between employees, their implementation not always runs as smoothly as expected. The reasons are often a mixture of wrong expectations and bad project approaches. In this post we share our experience on document management project implementations and suggest best practice solutions to the most common problems we’ve found.
Meet John. John is the IT manager of GrowBig, a fast-growing company which prides itself on being digital. Until now, GrowBig’s contracts, invoices, reports and other digital documents were managed on a file server. But GrowBig is getting larger and employees have started to complain about the file server becoming a mess, that documents are lost and never retrieved, and that final versions are hard to identify.
John knows the answer: he selects a top-notch Document Management System, hires a consultant to define document types and metadata and provides access to all employees. Case solved.
A few weeks later, however, it turns out the system fails to attract users. Most employees are still using the file server, a few are using the new DMS, and some used it for 3 weeks and then switched back to the good old file server. John is shocked, angry even at the ungrateful employees who don’t seem to appreciate his swift action to save them from document chaos.
What went wrong? Are those employees really ungrateful? Well, maybe John made some typical mistakes when launching the DMS in GrowBig. Let’s analyze those common mistakes in more detail and check which document management best practices could have helped avoid them.
Some IT departments still roll out their DMS as if it were an application, like MS Office. They buy the DMS, install it and then just throw it at the employees. What’s wrong with this approach? Well, a DMS is a platform and not an application. This means that a DMS offers a bunch of features for managing documents (version management, search, metadata and others) which can then, by means of configuration and/or coding, be used to build applications with it.
But hey, a DMS typically comes with a default application and user interface, no? Yes, that’s true. But the default application for a DMS only covers a very limited use case — typically project collaboration, such as in SharePoint and Alfresco — and it would be quite surprising if all your document management requirements can be efficiently accomplished with it.
Just think about GrowBig’s need for contract management, where you would typically need to have the system notify you some period before the contract expiry date in order to stop or renew it. This kind of useful business feature would never be offered by default, but would need to be configured based on the platform features in the interest of creating a powerful contract management application.
Develop a Document Management roadmap: identify the document-centric applications for your organization and then prioritize them based on impact and feasibility.
By doing so, the AmeXio consulting team has already revived a number of document management systems after failed first implementations. In such cases, it’s taking a step backwards to move forward again.
So, a DMS is a platform with a bunch of pre-built document management features. In that sense it is often compared to a Swiss army knife. But a knife can cause dirty wounds when used wrongly, and the same goes for document management systems. Some document management implementations aim to use the available features to the fullest: they define plenty of document types with lots of metadata, develop workflows that span multiple walls and create user interfaces with a dazzling number of options.
In fact, mistake #2 can be considered the opposite of mistake #1: while in #1 the implementation was too simple, in #2 it’s much too complex. Some DMS implementations seem to presume all users are trained archivists who love categorizing documents.
But in fact, 99% of employees just want to get their work done and are not interested in filling metadata or handling workflow tasks if there’s no added value for them. So, let’s hope John’s consultant is aware of that, and was experienced enough to avoid useless complexity.
Strike the right balance between simple and complex.
This requires expertise from the business analyst: knowing when to stop squeezing in that extra function or button. A successful track record in similar implementations, knowledge of user experience design and some technical background create the perfect mix in this case.
So often preached and so rarely performed: change management.
A DMS implementation often touches a large segment, if not all, of your employees. To make things worse: there’s nothing simpler for your employees than dragging and dropping document on a file share (even if that leads to chaos in the long term). Both facts make change management essential. No matter how well-designed the document-centric application was, I’ve rarely seen success without true change management. If we return to John’s DMS woes, this was probably his main mistake. If you don’t involve employees, they will most probably stay with what they’re used to: the file server.
Just do it.
Organize that change management, not just by providing some end-user trainings but by involving end-users from start to finish. Explain the plans to them, involve them in the analysis phase, have them test the implementation after each sprint and show them the value.
