“23 Things I Wish I Knew When I First Implemented an OCR / Data Capture / Content Management (ECM) Project”

DATA CAPTURE TIPS

According to highly-respected industry expert John Mancini and a group of AIIM experts, who have provided their feedback and after-thoughts about large enterprise implementations, the following is a set of “lessons learned”.  In our opinion, nearly every one applies to an OCR and Data Capture implementation projects.  I encourage you to wise-up and learn on others’ mistakes.

1. The importance of spending more time on the planning end of the project before hopping into vendor roulette.
2. We should have spent more time thinking about the best FIRST project — not too difficult, but not trivial.
3. We should have spent more time “preselling” senior management on the project so that they could help us drive change.
4. That documenting the work processes is the top priority for cost justifying any implementation – AND the broader you deploy, the bigger the benefits will be.
5. We should have narrowed the scope of our first project.
6. Anesthesiology, because then I wouldn’t have had to do ECM!  Seriously, I wish I had known that taxonomies are obsolete the second you create them.
7. We should have more clearly defined the roles of IT and the business so that IT operates more like a cloud vendor (internal or external) and the business sets the priorities and the strategy of what gets managed.
8. First of all everyone involved should know what is ECM — the technologies, the steps of a project, the benefits that you could obtain and mainly the changes and impacts resulting from the implementation.
9. We should have focused on the user experience (training and UI), not just getting the tool set on the network without breaking it and building out overly complex records and metadata requirements.  We gave users a bumpy ride, which ultimately discouraged adoption.
10. If you are replacing a legacy system, beware of poor information quality!  Garbage in, garbage out.  If the information is bad, you will lose the support of the business even if the system is great
11. If you don’t have ECM expertise in-house and cannot find or don’t have time to hire an ECM expert and/or someone with the ECM project implementation experience, hire an independent consultant who won’t be vendor biased, to help you with the strategy and roadmap definition
12. Clearly define your business goals and objectives as a first step — why the company needs ECM and what you are trying to achieve with ECM – before choosing a vendor. Your high-level business requirements, integration points and expected outcomes will help to draft the RFP and define what functionality you want to see in a vendor product.
13. Not all content should be migrated into a new system.
14. I would have done a site visit with a current ECM user and met the people.  That would help understand the benefits, and the way the operation changed – both the good and the bad.  It would have allowed my team to met real people and ask for feedback from users, not vendors.
15. The importance of email! The early ECM projects dealt with “documents” first and MAYBE tackled email in a future phase…but our clients are using email both as their repository and workflow system.  It should be included in the initial scope.
16. Don’t assume your users know how to use the technology tools they have been given. I was astonished at the general lack of basic skills in using tools in place to support the business.
17. Know going into the implementation that there is a HUGE learning curve for everyone.  Consider purchasing additional training for staff.
18. Regularly schedule follow-up meetings post-implementation between the ECM vendor and the customer. Many service calls and end user frustration could be kept manageable that way.
19. Taking the “pistons” conversation off the table.   We are delivering policies, tools and technologies to improve the business, security, and help manage risks — we are delivering a solution for the business, not for the IT department.
20. The vendor should follow up with users at 30 days, 90 days, 6 months after implementation to ensure they are using it as intended.
21. Schedule biweekly lunch and learns – an opportunity to raise questions and ideas as users begin “playing” with the system. This would identify training issues and new projects.
22. Implement first, optimize later. Don’t go for the perfect RFP with 200+ pages. Keep it simple, get it live, and then optimize.
23. Focus on getting the strategy right, not the technology.