Image by: Mile Atanasov, ©2016 Getty Images
The electronic document management system (EDMS), as we know it, has been available for almost 20 years. In the early days, all projects involved simple, out-of-the-box deployments or customized projects. Specialized EDMS projects serving specific industries or processes emerged in the late 1990s. Today, these specialized systems provide mature and full-featured solutions to many business problems, managing the content and associated processes for engineering, manufacturing, regulatory compliance, legal contracts, human resources and much more.
A successful implementation of an EDMS yields organization improvements and cost benefits. An EDMS can standardize and streamline the content management processes, reduce or eliminate paper use, improve records management for corporate and legal purposes and allow for access control and other security features to protect intellectual property and comply with privacy regulations and practices.
So why are many EDMS projects still unsuccessful? Many organizations still fail to understand the discipline necessary for success. Understanding and adhering to five key practices when implementing an EDMS can dramatically increase the likelihood of delivering a successful solution.
1. Mandate for use
No matter how much attention is paid to the user experience for an EDMS, users are often not motivated to use them. The reason is simple — the benefits accrue in the organization but not to the individual user. Successful deployment of an EDMS requires executive buy-in, but that alone is not sufficient. In addition, a mandate for use must be issued and supported at every level.
For example, a typical user might not benefit directly from using standardized templates, authoring processes or digitally signing documents. Instead, it's the organization that benefits from standardization, the decreased costs of handling paper, improved records management and the ability to implement records retention. Without complete understanding of its importance across the entire enterprise, users can be tempted to cut corners and "work outside the system," leading to inaccessible or inaccurate content, circumventing of agreed workflow processes, security breaches and records management issues.
It's the responsibility of executive management to ensure that the institutional benefit of an EDMS is understood by everyone affected. Executive management must also communicate the necessity of embracing the system and consequences of failure to do so. Management might want to consider including initiatives and rewards tied to the success of the program to reinforce the EDMS throughout the company.
2. Maximized use of out-of-the-box software
Most packaged EDMS products are highly configurable and extensible through customization. Many organizations begin EDMS projects believing, or at least stating, that they expect to adopt the best practices and standards of these packaged solutions. However, soon after starting a project, companies often succumb to user demand to adapt the system extensively to very specific requirements (more often than not carried over from content management processes developed for managing paper documents and their associated processes).
For this reason, the need to avoid customization is clear. However, companies often have trouble avoiding excessive specializations, but significant configuration carries with it a substantial test burden and the potential for complications during future upgrades. For example, a company requires the configuration of 5,000 different overlay templates (combinations of text and metadata fused to PDF documents). Although the system can be configured to accommodate this requirement, it is essentially unable to be tested or maintained over time. This is because of the inability to perform valid impact analysis when changes are necessary, in addition to the complexity and volume of testing needed. This is unlikely to be supportable within reasonable project schedules and budgets.
A best practice in handling any customization and significant configuration is to require justification. Justification should include the specific problem, the solution and how the request is needed to improve efficiencies, achieve compliance or both. It should also describe the impact of not addressing the request (for example, a claim that an additional 200 hours per year for manual processes would be needed in place of customization or configuration). In addition, it should explain if any work-around, such as the use of a manual process or unconnected IT system, is available. A defined process should be put in place to adjudicate these requests.
3. The Pareto principle (the 80-20 rule)
At least 80% of your common outcomes are the result of 20% of your processes. This Pareto principle comes into play through the design of your EDMS.
Are you engineering elaborate life cycles or workflows for conditions that rarely occur? If so, you are probably expending more effort in design, configuration, documentation, test and validation than you would ever save by automating processes. These fringe conditions should be managed by the system only when failing to do so leaves no alternative for meeting crucial business or compliance needs. Plus, manual processes remain viable alternatives to handling those infrequent conditions. Keep the focus on core processes and don't worry about rarely used features, as the usability benefit of "turning them off" might even exceed their usefulness.
4. Simplicity
In the words of Albert Einstein, "Everything should be as simple as possible, but not simpler." Just because a system can automate an elaborate life cycle or workflow process doesn't mean that it should. For example, you might have a standard operating procedure (SOP) that calls for a specific process for document approval, including the exact sequence of the necessary signatures. Often, a system can be configured to automate the process with a single click, which sounds appealing. However, consider how you will handle an unexpected deviation, such as a change in the order of signatures, plus the need to re-configure and re-test the system if the process or order of signatures should change. Building a system to automate extremely specific steps often results in a system which is fragile and inflexible.
Simplicity is especially important when defining a security model for an EDMS. Security is an area where users often insist on elaborate configurations for different types of documents and conditions. Vendors and system integrators might accommodate the requests when they fall within the capabilities of the EDMS product. But after the system has been put into production, users frequently realize that no one understands or remembers the requested security model and are blocked from documents they need to read or contribute to. A good rule of thumb is that a security model should be explainable to the whole user population using a single PowerPoint slide.
5. The voice of experience
For many years after a project is completed, customers might complain that their vendor should have prevented them from implementing a complicated, over-configured system. Often the vendor may have tried, but the project's managers or users did not want to listen to the recommendations. When an experienced vendor, system integrator or user expresses concern about the project's direction, take them seriously, and take the time to understand why they advise a simpler approach.
At the same time, stay alert for practices that are simply carryovers from legacy or paper systems. This includes collecting multiple electronic signatures for document approval — a practice that dates from the paper world to prove who reviewed a document. In today's world, review or approval can be captured in an audit trail and reviewed at a later date.
For many years after a project is completed, customers might complain that their vendor should have prevented them from implementing a complicated, over-configured system. Often the vendor may have tried, but the project's managers or users did not want to listen to the recommendations. When an experienced vendor, system integrator or user expresses concern about the project's direction, take them seriously, and take the time to understand why they advise a simpler approach.
At the same time, stay alert for practices that are simply carryovers from legacy or paper systems. This includes collecting multiple electronic signatures for document approval — a practice that dates from the paper world to prove who reviewed a document. In today's world, review or approval can be captured in an audit trail and reviewed at a later date.
Keep in mind that an EDMS is a tool, not a panacea. It won't address inefficient or broken processes, dysfunctional organizations or communications issues. It's best to address those issues before implementing an EDMS. Then, concentrate on modeling core processes in a straightforward and streamlined manner in your EDMS. Following these five steps will help an organization achieve the discipline necessary for success with an EDMS in place.
KATHIE CLARK is director of Product Management for NextDocs. Ms. Clark has an extensive background in document management and electronic submissions for the global life sciences industry and has written extensively about industry challenges in blog postings, journal articles and white papers.
