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?

Going Beyond ECM Nostalgia

The days of big, expensive Enterprise Content Management solutions are over. These were the golden days in the late 90's and 2000's. Now, we are all aware that information and content are interchangeable: scanned images need index values, general ledgers sometimes need invoice images, EMRs need links to images, process automation needs it all.

Facebook shows us one way to mash all of this together, but it doesn't have the industry focus, legal regulations, or corporate learned behaviors. Every application has content and information management. ECM might still be on the bottom system layer, filling in the cracks, but it's purpose has changed. It is either focused on specific industry solutions, or acting as a change agent to sweep up the final paper processes. Whether it will be used in the long term doesn't really matter. What matters is that it still has an important role in IT.

We all content manage
We all move information
Our end goal is efficiency
Helping communication along the way
Yet truth struggles with greed

What is Throw Away Work Really?

Every information management project has a certain amount of waste; it is inevitable. Throw away work that is staging as a means to an end, in other words, a goal’s goal’s goal. The larger picture trumps what seems to be stupid at the doing level. Doers occasionally need to visualize their work as scaffolding. It is there to support the process temporarily, making it possible to work on the actual project. As the image suggests, no work is throw away, there’s always the experience and learning that is invaluable the next time.

The whole goal might be to move off of one platform and on to another. If you stay long enough at one company, you will experience this at least a few times… This type of goal depending on the size of your user dependency and content could be a Mt. Everest climb. The staging would be all of the interim work.

Interim Nuts and Bolts Stuff

Here’s a typical list of necessary Interim throw away activities:

• Upgrade the OS and database to meet the new software’s support requirements.
• Export content and metadata to a temporary storage area
• Map and process data to conform to the new build
• Train Users on new platform

Here’s what might not be necessary:

• Rewrite existing customizations to work on the new platform. The new software’s functionality will most likely leap frog these. A thorough analysis is warranted here.
• Migrate to a half-way point to meet a C’s deadline

1%er Deadline

If you are lucky enough to be a part of incentives to meet your company’s goals, then this may not interest you, but for the rest of us it should. For large projects, the incentives increase as you go from the doers, to the managers, directors, and C’s. These are usually tied to deadlines whether they are realistic or not. As I have said in other posts, quality and overall costs suffer when deadlines are imposed without total buy-in from parties involved. Capital is used for contractors who estimate work based on previous jobs and have a huge list of assumptions. Basically, it’s a trap of change orders within the big project’s budget.

What was really thrown away?

As the scaffolding is taken down, revealing the latest and greatest solution, we have to feel a sense of pride in completing it. No work is completely useless, it has worth; at least I like to tell myself that. Maybe you learned a new framework, or a coding language, or how to do a traceability matrix.

In retrospect, a project is never really finished anyways. There’re always follow up phases; “Nice to haves” put off until after go live. So try to take solace in being a cog in the process and look to the future of doing it with more coordination and influence the next time.

Budget Black Hole

Why is it that almost every IT project has a budget based on guestimates, bound by fuzzy scope, and goals that are usually too constricted? Every time a project methodology is executed, the budget is in the books, not to be revisited. It is just a given, not flexible and not based on specific enough goals. Management will assure us that changes can be made, but how often does that happen, and which projects take priority by the end of the quarter (or bonus time)?

Goals

You can’t just say, for example, that our goal is to do “x” to content by the end of the first quarter. The first you hear about a project, it’s your responsibility to ask, “What are the specific goals?” and “Were these goals fully funded?” Asking questions like these will give your project manager pause, especially if you ask, “What are the success criteria?”

Success Criteria

Large companies have ways to pay for projects from other capital budgets to assure some form of success. The issue is does this success include all of the long-term aspects associated with a strong solution. When it comes down to the wire, we know that testing and quality will suffer if corners are cut from lack of money.

Here are some tips on creating success criteria.

• Combine at least two aspects of success together, for example, migrate all content with 100% accuracy and on time. Notice I didn’t include how much it will cost.
•  Include a stabilization period after go-live because there are always unanticipated issues after a large deployment. This will give the extra confidence that managers and Users need that issues will be resolved in a timely manner.
• If a project is large, then don’t just break out the normal parts, breaking it out to smaller projects which can fulfill smaller goals, with the common understanding that whole will be larger than the parts.

Scheduled Scripting Jobs: from Documentum to OnBase 11

One of the biggest surprises of working with OnBase was when I couldn’t find a way to run a scheduled job to execute a script. As simple as it sounds, there’s way out of the box way to run a script when you want.

So here’s what I did to work around this:

First Solution: scheduling a scan queue sweep to fire off a VB script

Steps

• Put an empty file in a shared directory
• Set up a scan queue to sweep in the file
• Hooked the VB script to run on commit of the scanned batch which was configured to go through automatically
• Scheduled the scanning to run every 10 minutes

Outcome:

This worked ok, but was a kludge.

Second Solution: create a looping lifecycle with one doc in it that went in circles

Steps:

• Create a lifecycle with a work queue and a timer
• Add a Unity script to the timer’s action
• Add a doc to the workflow to trigger the timer and script execution

Outcome:

So far, so good

Hope this helps those of you who are stumped like me why this is not built into the product.

What Makes ECM Last Longer?

"The significant problems we face cannot be solved at the same level of thinking we were at when we created them" -Einstein

On first reading of this, I thought it meant we need to think outside the box to solve future problems. However, after reading a few more times, I realized that he is also implying that solutions now are problems in the future, in other words, the effectiveness of the solution is directly related to the level of forethought given to it.

How does this relate to ECM issues? Take for example, storage. Why is it assumed that storage will always need to be expanded to accommodate new content? What if a better compression algorithm reduced the total size of the files by 100%? Or, a retention policy actually kicked in after many years of waiting and disposed of files? Thus, plan for 10 years of expansion, 10 years of Moore’s Law lowering storage costs, 10 years of fluctuating goals, and finally after 10 years, storage will shrink for retention policy content.

How about workflow? If you have a complex process which was “automated” in a workflow a few years ago and is now very expensive and time consuming to update, what do you do? You could simplify it by stripping out the parts that are not worth the hassle of updating. The “parts” are usually exceptions to the main purpose of the workflow. The exception will change, so a little change management forethought could save a lot of money in the long run.

So, what happens with ECM implementations when problems occur and the folks charged with fixing them were the ones who designed it? It depends of course on the issue, however the larger the issue, the more it makes sense to have an outside party analyze it to provide different logic on how it occurred and possible remedies. The nature of contracting is to get the next phase of work, so that is up to you. Given the analysis and options of fixing the problems, the in-house resources are usually the best folks to work on them, given the negative effects of not engaging them.

Where does data quality start in Healthcare IT?

You don't see anyone commuting with a muscle car from the 60's on the highway, so why do we tolerate old, upstream applications like patient registration, accounting, and interface hubs which introduce major data quality issues that cascade downstream to other dependent applications. Let’s try to frame these issues in the following ways:

1.       Historic Applications

a.       A patient registration system can be the oldest system in a healthcare setting, along with billing and accounting. This is the frontend system which feeds most other systems, why is it neglected?

b.      Any tier 1 applications which were deployed at a company were designed with requirements that lack the proper enterprise expanding capability. This is just inherent in any pipeline application.

c.       These apps are the most expensive and are most difficult to change. They have the oldest looking UIs.

2.       Over the wall responsibility        

a.       The application administrators work in their own silos. Take for example the typical groupings of IT: Financial/HR, Clinical, Imaging, Administrative, LIS, ECM, etc.

b.      Each of these has its own management hierarchy, therefore each has its own agendas and objectives.

c.       Differing departmental goal priorities often clash between these application groups. One Director has a goal which is aligned while another does not.

3.       The interface cannot hold everything together

a.       To accommodate the “historic” application’s lack of flexibility or expense to customize, the interface takes on the role of tracking and rules for filtering and routing data.

b.      In addition, to fill in the gaps that the “over the wall” mentality introduce between applications, interfaces help, however, on the flip side they create problems as requirements and applications change.

4.       Infrastructure Attitudes

a.       Systems admins don’t have the time to review new requirements, they are busy with storage and performance issues.

b.      DBAs can’t be bothered by development questions

c.       Storage and asset management manager only care about keeping the lights on.

It’s no wonder data quality suffers as historic applications become more rigid, departmental priorities clash, interfaces act as super glue, and infrastructure have their heads in the sand. There is not enough transparency and cooperation between the application “owners” to work as a true enterprise system. Of course, some companies are better at managing quality of information and have more resources to do so. However, a few foundation changes could make a difference:

1. Make sure the first applications which introduce information integrity are the best in market (change the budget if needed to achieve this!).
2. Create a system of living documentation for application requirements for all to see, understand, and modify.
3. Encourage sharing of ideas on how to reduce the amount of interface custom rules, pushing the business rules back closer to Users and front ends.
4. Reorganize through a program/project management office the influence that business analysts have on change management and how they can get results quicker from infrastructure and application engineers.