Enterprise Content Management (ECM)
I recently asked my insider group of “AIIM Evangelists” for their take on things they wish they knew when they first implemented a content management project. So here you go – learn from the experts!
-
The importance of spending more time on the planning end of the project before hopping into vendor roulette.
-
We should have spent more time thinking about the best FIRST project -- not too difficult, but not trivial.
-
We should have spent more time "preselling" senior management on the project so that they could help us drive change.
-
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.
-
We should have narrowed the scope of our first project.
-
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.
-
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.
-
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.
-
We should have focused on the user experience (training and UI), not just getting the toolset 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.
-
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
-
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
-
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.
-
Not all content should be migrated into a new system.
-
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.
-
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.
-
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.
-
Know going into the implementation that there is a HUGE learning curve for everyone. Consider purchasing additional training for staff.
-
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.
-
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.
-
The vendor should follow up with users at 30 days, 90 days, 6 months after implementation to ensure they are using it as intended.
-
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.
-
Implement first, optimize later. Don't go for the perfect RFP with 200+ pages. Keep it simple, get it live, and then optimize.
-
Focus on getting the strategy right, not the technology.
