I often think of the reasons that so many organizations suffer from such poor data quality. To be sure, many of the culprits are internal–careless employees, broken business processes, cultures that don't value data, decisions routinely based upon hunches in lieu of information, and the like. Still, I'd argue that many software vendors should probably receive at least some of the blame.

Here I'm talking about bloatware. Over the course of my career, I've seen software vendors add overly complex functionality ostensibly for the sake of doing so. At the very least, this functionality seems to have been rolled out sans a great deal of customer input. Perhaps the most salient example took place about six years ago. An ERP vendor (call it XYZ Software) revamped its time-and-attendance module.

Now, to be fair, XYZ's legacy application was a bit long in the tooth. (The marketing folks had tried to make it sexier with a new name, but the functionality  remained the same.) XYZ's new module, called Absence Management, without a doubt contained a swath of new features relative to its predecessor. In theory, XYZ users could operate with fewer workarounds and manual transactions after the Absence Management application had been properly set up. (This was no small feat, I can assure you. I once created a 120-page user guide for one of my clients for just this module, and it still didn't account for every conceivable contingency!)

To create this new functionality, XYZ Software now required the creation of a series of additional codes and classes, or sets of codes. But here's the rub: many of these codes did not interest organizations with relatively simple sick, vacation, and holiday plans. Still, to make Absence Management work, those codes would need to be set up. These codes generated a good deal of additional transactional data every two weeks--or however often XYZ users ran payroll. New tables– and forms accessing them–were introduced, more often than not confusing XYZ users. As a result, records often became out of sync and data quality suffered. It wasn't uncommon for people to have difficulty answering what should have been very simple questions like, "Do I qualify for FMLA or not?"

Simon Says

Understand the inherent tension between increased functionality and data quality. Simple applications may be a breeze to configure and run, but they'll likely leave you wanting for additional data–and the questions that that data can answer. Conversely, more involved applications can probably provide more meaningful analytics, but the amount of work involved in keeping them running smoothly is certainly greater.

Feedback

What say you?