Search This Blog

Wednesday, March 25, 2009

The Beginning (4)

In my experience, those who can do the least about data quality feel most responsible, while those who have quality literally at their fingertips feel no responsibility whatsoever. This creates many difficulties for one who wants business intelligence.

I'm going to collect receptionists, customer support, sales, anybody who enters data into any of your computer information systems under the heading of "the business." We could also include those who collect or transcribe data to/from paper if it eventually winds up in a computer-accessible data file.

Maybe we have done too good a job in convincing the people seated at computer keyboards that they have nothing to fear. In any event, many simply do not pay adequate attention to what they are doing. There are many reasons for this including:
  • heavy work volumes causing a pace that is too fast for error recognition or for going back to correct errors
  • inadequate training
  • inadequate guidance built into the user interface
  • inattention/distraction

On the other hand, I have encountered way too many instances in which people were actually aware that they were producing garbage but didn't care enough to do anything about it. Sometimes it's sabotaging the people in the next department. Sometimes it's a statement to the supervisor and sometimes it's "so what."

It is true that some data can be repaired after the fact, but the sad fact is that "cleansing" can never be 100% effective and in some applications cleansing isn't even possible--if it isn't captured correctly the first time, there's no going back. Repairing bad data is very expensive for your business. Experts estimate that, for anyone who receives data as part of their work process, from 30-60% of their work day is spent in rechecking or validating or repairing the data so that they can do their job.

The data architect will have worked with the folks to understand their data needs so if we can prove that they have participated in that process and that the architects and developers have complied with their defined processes, then what we are left with is attitude or training as problem sources. These are issues for management to resolve.

One final area for the business to think about: there is a need to include problem recognition in training and provide safe reporting paths for those who do take note and take action. Those at the front line typically have little awareness of the business that they front-end for. They don't know that someone cares or that someone can actually do something to fix a problem that they struggle with on a daily basis.

You will want to include a module on the data resource in the New Employee Orientation. You'll want to take remediation to department meetings to catch all who missed the new employee offering. It must be simple to report a problem and there can be no "grilling" of callers by the support line triage staff. Take the call and send someone to see the problem in person while the reporting employee works. Use a remote desktop capability to watch the problem happen. There are many options, but if the caller is made somehow to feel guilty or foolish or ignorant, they will never call again.

Next time we'll take on the vendors.

No comments:

Post a Comment