On bloatware and data quality


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.


What say you?

Tags ERP

About Author

Phil Simon

Author, Speaker, and Professor

Phil Simon is a keynote speaker and recognized technology expert. He is the award-winning author of eight management books, most recently Analytics: The Agile Way. His ninth will be Slack For Dummies (April, 2020, Wiley) He consults organizations on matters related to strategy, data, analytics, and technology. His contributions have appeared in The Harvard Business Review, CNN, Wired, The New York Times, and many other sites. He teaches information systems and analytics at Arizona State University's W. P. Carey School of Business.

Leave A Reply

Back to Top