ECM pushes quality up the stack

ECM, being a sea bottom dweller, has many opportunities to detect and fix issues with information architecture. This depends on the breadth of implementation and integration of the system, however, in most cases, applications which rely on metadata accuracy for processing and presentation will route out issue.

Many times an implementation will bump into a information quality issue by chance, for example, in a healthcare setting, billing information is used as the basis of coding patient tests. The source of this information comes from a registration system and if the hospital is large enough, it comes from multiple registration systems. The patient account number needs to be correct for insurance billing. For auditing purposes, the downstream/bottom dweller ECM system needs to be accurate. If it is not, then the exception is sent back up the stack for fixing. This fix more often than not exposes glitches/bugs in the way the integration engine functions. Sometimes it exposes issues from years ago, but a patient's chart information could have many years of visits and discharges associated with it, as well as non hospital related tests add to it. The bottom line is that an ECM system may only be used for scanning and indexing images, but it most likely is driving quality up to the surface of the more mission critical applications.

Recommendations vs. Requirements

I read an email from an IT director a few weeks ago that was explaining how we should proceed with a particularly troublesome issue. The email explained that the User's of the system can "recommend" changes to the website, and that IT will "review" them. It's old school to say "recommend", like really old school, before the concept of documenting requirements to solve a business problem old school.

How does this happen? How can IT management still think that they have the innate ability to understand the intricacies of what business User's want without documenting requirements? It can't and that's the point.

With most information technology, the people who know how the software is designed to solve issues are the first ones to evangelize the usefulness of it. They are usually very familiar with the business processes and at the time know a lot about what the Users need. However, over time these same folks will inevitably lose that edge. That is when they need to start asking their User's what they need. The problem is that pride and prejudice enter into the behaviors and thoughts of the original designers of the system. They are the architects. They feel entitled to dictate what should and should not be included in future designs.

Thus, please be sure there is ample documentation of requirements and functional specifications which solve the issues, and that these docs are updated or superseded. The worse thing that can happen to a system in the long run is to rely on one architect for all design questions and answers because the one person is surrounded by many who have unique perspectives and could potential have more innovated ideas on how to solve problems.