Ghosts in the ECM Machine

What would make knowledge workers refer to data corruption as “ghost” information? These ghosts are anything but scary. They float in and out of registration, accounting, EMR, and ECM systems. The team that introduces the ghosts is the one that busts them. As information changes, this team updates key metadata in one system, then the same in another, and so on. While making the changes to one system, other users are processing information in another, causing issues with data synchronization.

In a perfect world, a service hub would be managing the synchronization of data and would be considered the source of record.  The individual systems themselves would be equipped to validate against this source of record via another mechanism, such as a database table, to be sure to get the correct information, especially if the service hub is down.

But we don’t live in a perfect world and there never seems to be enough money in the budget to do the right thing in IT. The blame for synchronization issues is not easy to pin point. It is easy to point the interface team and to say it’s their fault, however, it’s really the enterprise architecture that is to blame. Chances are good that this type of “ghost” occurred during a time when there was no one holding the architecture reigns at the enterprise level.

Trying to push a fix to this ghost throughout the enterprise will prove to be challenging. At the point an issue is called a ghost, it has become institutionalized. This means it has been baked into the psyche of the knowledge workers. They take it for granted. “It will cost too much to fix it,” say some; “Good luck moving it up the priority list,” say others.

If there is a change management policy which managers hide behind to justify the status quo, try to find holes in the policy: Is it up-to-date? Are the original signers still working there? Policies should be reviewed every year or so: has it been? Is this how other systems like the accounting system operates?