systems fail
Whether solving a paper problem, implementing
an automated work flow, or simply improving
the way electronic files are handled, the right
document management system can provide a
wide range of benefits for businesses large and
small. However, when implementing a
document-management system, companies need to be
mindful of a number of pitfalls.
Many implementations focus on the technology—
the technology selection and the features and
functions of the vendor or integrator. While
these factors are important, we have found that
document-management system implementations
fail because teams overlook some of the primary
success factors outside of technology and
proven project-management implementation
methodologies.
Described below are 13 primary factors that
should be considered prior to a
document-management system implementation. Not all
factors are relevant to every implementation.
On the other hand, some factors are so vital,
companies will need to address them eventually
to gain adopters—even years after the system’s
initial rollout.
The 13 reasons
1. The “culture” factor: Many companies have developed a unique culture for how work is done, and document-management implementations must work within this culture to be successful. It takes time and effort to come to know a culture and to work within it. It is not necessary to change it. Effective implementations will evolve it.
2. The “How it really works” factor: The project-management team must be committed to allowing the ultimate stakeholders to participate in the overall design and implementation of the project. We have seen clients fail in their rollouts because they were focused only on the technology and not on its effects on the daily work lives of the stakeholders. Remember, the implementer and vendors may be involved intensively for a short time during implementation, but the daily users will integrate the technology into the processes that are working behind the scenes.
3. The “We know more about technology, so we know what they need” factor: The project-implementation team must avoid an “us versus them” attitude about the ultimate stakeholders and users. Teams must always refer to the other group with respect and dignity. Everyone is at a different level in their personal understanding of the technology, existing processes and new processes. The synergy of bringing everyone’s contributions to the project’s success is key. Never correct ultimate stakeholders by telling them, “This is how you should be doing it,” or, “You’re doing it all wrong.” Individuals arrive at where they need to be at their own pace. An arrogant attitude can contribute to the surreptitious torpedoing of an implementation.
4. The “Hidden emotions” factor: Another consideration is being sensitive to the hidden emotions and attitudes of the stakeholders. Stakeholders’ concerns, fears, and reservations about new project implementations need to be addressed. Project-implementation teams often will focus only on implementing the technology and ignore or belittle how stakeholders feel about the project. If stakeholders have accepted the justification for the project, they may not work as a team to ensure its success. If stakeholders fear the implementation will cost them their jobs or make their jobs more difficult, they may hold back information, create and circulate untruths, or inadvertently sabotage the project.
5. The “Poor data model” factor: Missing critical
metadata will impede a successful document-management implementation. Metadata data are “data about data.” In this case, it is data about the content or electronic document. Teams need to ensure that the information about the systems and documents is complete. The most successful implementations are those that take the ultimate users and stakeholders at all levels and across departments through a data-modeling exercise. This may seem trivial or redundant to
the technology and project side, but it is essential to achieve stakeholder buy-in and the feeling of project ownership from the ultimate users of the implementation.
Many implementations today limp along because the data model is incomplete, gaining the reputation that “What we need is not there,” or “The system doesn’t reflect how we do business.” Even if the amount of metadata identified is ultimately fewer than five attributes, the exercise is key to the end-users’ acceptance and feelings of project ownership. This exercise also will facilitate cross-organization communications to identify synonyms, antonyms, homonyms, and metonyms within the departmental lexicon that may be misrepresented in the data model. A word of caution: if you fail to get this right (or close to right) the first time, you will be recreating the data model in the future or compromising the attributes of the model to mean other things.
6. The “They didn’t ask me and it’s not my stuff” factor:
The specific needs of individual users must be addressed within the scope of the project. If these specific needs cannot be addressed, then the associated parts of the implementation should be declared out of the project’s scope. If certain stakeholders are excluded, but are not explicitly declared out of scope, then those individuals may undermine the positive attitude within the project. Not all stakeholders can envision their specific work as part of the system. During the initial joint development sessions, care must be taken to ensure that specific documents relative to the specific work activity are included to ensure stakeholder buy-in at all levels.
7. The “Finding the best work flow” factor: Teams must identify relevant work flow at the stakeholder level to ensure reengineered processes that encompass the scope of what actually needs to be accomplished. Document-management software vendors will reiterate the importance of work flow
and process reengineering to ensure the most return on investment(ROI) of an implementation. The challenge is that the real work flow and processes happening within an organization may not always be known by middle management or upper management for a variety of reasons. One must ask the right people to understand the real answers.
8. The “I need more power and it’s too slow” factor: The implementation must provide sufficient resources for the server, storage, workstation, viewing portal, and network infrastructure to ensure stakeholder satisfaction. People can view the next page of a physical file instantaneously. Fair or not, this benchmark is what document-management systems will be measured against. Without sufficient capacity, implementations will be labeled as “too slow.” Many stakeholders will return to the proven historic paper approach and be reluctant to adopt the electronic approach. Be sure to increase the network infrastructure to support binary large objects (BLOBs). Network bandwidth is sized primarily to handle data transfers in smaller blocks. Unfortunately, bandwidth is increased only with cash capital investments and often is not considered in the cost of the rollout. Another important performance-tuning exercise is to increase network data blocking sizes so that complete objects may be served in a single transfer instead of waiting for protocol handshakes to paint the image. Systems and software may appear to be slow and suffer from poor reputations and internal discussions, but the reality may be that the network bandwidth or tuning parameters are not yet implemented.
9. The “Right size” factor: Supply vendors should avoid overselling their solution’s ROI. The ROI doesn’t ultimately materialize until the majority of documents are in the repository. The effort to create high-quality, useful scanned images with accurate metadata is huge. It is painstaking and
requires effective quality control in the implementation of the document-imaging component of the overall solution.
10. The “Silo” factor: Stakeholders must admit if a silo factor exists. Enterprises benefit from effective sharing across departments, business units, countries, and functional areas. But despite best efforts, silos often do develop within organizations, hindering effective information sharing. From time to time, cultural issues must be addressed to share information.
11. The “Need more person-power” factor: Understand the person-power required for document preparation. A 200 pages-per-minute (PPM) scanner takes about 40 person-hours of preparation time to ensure that it’s running at optimum capacity for an hour. A rate of 200PPM is 12,000 pages an hour. How long does it take to prepare 12,000 pages collated with the indexing codes, removed from file folders and removed staples/clips? Scanners that open letters and remove them from the envelopes should be considered.
12. The “Process consensus” factor: Understand that current processes may have evolved over time and may not be the most efficient. The routes to completion may have had reasons in the past, but sometimes those reasons are no longer relevant and the process has yet to be revisited. A new improved reengineered process may be obvious immediately to an outside consultant, but not to internal stakeholders, and thus will not be successfully implemented. The requirement is that the current stakeholders, middle management, and executive management need to come to a consensus over
time. They will not likely come to an agreement, but consensus is achievable. Typically, the stakeholders doing the current process have the best understanding of better ways to accomplish tasks if they had the right tools and understand how to take advantage of them.
13. The “Because it’s there” factor: Have a well thought out and specifically designed plan for implementation. Be careful not to allow a system designed and implemented for a particular solution to be twisted and “force fit” to partially solve another problem. Systems are designed for specific use: Human Resources, Accounts Payable, or Operations for example. Employees in other organizations may say, “Hey there’s a system is there?… and it does… some stuff, let’s use it!” This creates a partial delivery of the functionality but introduces the poor data model factor. Knowledge workers compromise the integrity of the value of the attribute. For example, they may store part information in an attribute designed to store volume information. If system’s misuse grows, the system gets to a critical mass where partial business value is provided at a substandard return. People use the tools they have available to them and that they understand. Ease of use is what you know.
Final
The U.S. space program cost $400 billion over 40 years. U.S. businesses spend $1.5 trillion on paper costs in one year. The costs are staggering.
At the same time, the notion that disk storage is cheap is a myth. This myth has led clients to store more unstructured data (document image data) without managing that data. Unmanaged unstructured data with duplicate convenience copies of that same information can become very costly to an organization. Magnetic storage media may not be as expensive as it was a few years ago, this is true. But the real expense comes from not properly managing the unstructured data and information on that media. If not managed and disposed of properly, the unmanaged data stored on that disk can be so expensive it can cost the entire worth of a company during litigation or e-discovery cost.
Document-management systems bring order to unstructured data, allowing organizations to take full advantage of data and analytic tools.
As outlined above, buying software alone is not the solution. Getting the implementation right is key. It’s true that not all implementations suffer from all factors, but all failed systems suffer from some.
Ideally, these factors should be addressed head on before implementation. But even after the fact, these issues can be identified and corrected.
Document-management systems can allow businesses to gain efficient and effective use in their data management initiatives while lowering cost. But, this is only when the implementation is sound and facilitates adoption by most of the stakeholders throughout the organization.
Dean Larsen II is a manager with KPMG LLP’s Forensic Advisory Services practice, where he is a member of the Forensic Technology Services group focused on
Information Governance and Records Management. Larsen has more than 20 years of experience in IT project execution and client service delivery for technology process improvements. He began his career in imaging and document management and has advised on deploying enterprise content management solutions, data modeling, database applications, ERP systems, web site strategies, and records management. Larsen has architected solutions from mainframe data centers to distributed network server environments to cloud-based computing infrastructures.
About KPMG
KPMG Forensic helps clients prepare for the identification, preservation, production, retention, and disposition of records and information for regulatory and discovery matters. KPMG provides end-to-end technology and program support for clients and their counsel in response to a discovery or regulatory event.
Additional information in Univers
45 Light 12pt on 16pt leading
kpmg.com
Credits and authors in Univers
45 light 12pt on 16pt leading
Contact us
For more information, please contact KPMG Forensic at
1-877-679-KPMG (5764) or visit us at www.kpmg.com/us/forensic.
Steven Stein
Principal – Forensic Technology
T: 1-312-665-3181 E: [email protected] Dean Larsen, II Manager, Advisory T: 1-858-750-7096 E: [email protected] kpmg.com/us/forensic kpmg.com
