Q&A: Getting Immediate Value from Your ERP System
ERP often doesn’t deliver. We explore why and offer possible solutions.
- By Linda L. Briggs
- August 13, 2008
ERP systems are designed to translate source data about business processes into usable information for the business. Despite their power, the software doesn’t always deliver. In addition, the line between ERP systems and decision support tools -- which have two separate functions -- has been blurred as vendors add features to their ERP suites.
In this interview, we talk with Jim Heatherington, managing director of Cutwater, a provider of decision support software for mid-market distributors and manufacturers, about why so many businesses have trouble getting real value from their ERP systems, and some possible solutions.
BI This Week: Why do so many businesses struggle to leverage their ERP investment?
Heatherington: The most fundamental benefit of a packaged ERP solution is to guarantee the consistency and reliability of source data. In this regard, most transaction systems are designed for a particular industry. They support the business processes that drive transactions, such as handling new orders. Almost all companies do attain this value from their core transaction system, but they’re often investing in these tools for broader capabilities, including performance management.
Stepping into this second benefit area -- decision support -- can be difficult to do because by its very nature, decision support is less defined. We may know we want to report on sales data, for example, but how that data will be used and the degree of flexibility needed will vary from user to user.
What’s the difference between transactions systems and decision support systems?
The line that separates ERP and decision support software tools has been blurred because most ERP vendors now provide decision support features in their core product offering. From a technology perspective, however, transaction systems capture data, while decision support features allow you to make use of this data.
For example, transaction systems enforce how data is captured and handled to follow a defined business process -- from capturing an order to fulfilling it and receiving payment.
Decision support features -- specifically if we’re talking about reporting and analysis capabilities -- provide extended users the ability to analyze and report on data in a way that makes sense to them. It’s not just different software -- there’s a slightly different mentality in implementation.
What’s the first piece of advice you can offer to business trying to get usable data out of their ERP systems?
It sounds like a cliché, but I’d strongly suggest taking an incremental approach to providing data to internal users, then allow what you see and learn to drive expansion. Standard project methodologies would begin by looking at the current management reports and generating user input into a requirements document for software to provide data access.
In many cases, however, this input is asked before there is enough user experience in using data in an unstructured way.
Begin by providing a focused data set -- like sales history -- to a defined user group that would appreciate access to this data. Make it simple: Consider a basic data mart with a simple front end, delaying any large-scale software efforts until there’s been hands-on experience in users having self-service access to data.
I wouldn’t spend a great deal of time in conversations about what should or should not be included in the data offered -- just put out basic fields to users and allow their requests for more (or less) drive what you do next. This learning will resolve issues related to data quality, user reporting needs, and IT architecture questions such as how timely data needs to be.
Should companies consider software alternatives for performance management to those products that already come with their ERP system?
What I routinely tell people is: You’ve made an investment in your ERP system. If you’re getting at the data in a way that meets your team’s needs for information, stick with what you have.
If, however, you’re finding it difficult to report on data, consider an alternative to get you more value from what you already own. Ask not only about cost but how much effort is required to implement and sustain the tool over time.
Most companies I engage with are stretched from an IT perspective -- there just isn’t room for another software project. More often than not, reporting tools are available that can be installed with very little distraction to the business.
In considering alternatives, I’m not a big fan of long lists of features and functions. They make for great software demonstrations, but in reality, people just want to get at data without having to ask for it.
What about the politics of all this -- who should be in charge?
If there’s someone internal to the firm that is accountable for information technology, then that person should manage the project. I’d add that for any given business function, such as finance or operations, that there be an identified business lead who will make sure that the project unfolds in a way that meets the needs of that user team.
Move incrementally so that your solution design develops from experience. That obviously works only if you have someone quarterbacking use and feedback from the user end.