Wednesday, August 20, 2008

How to report on ERP data

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.

Bron: http://www.tdwi.org/News/display.aspx?ID=9071

 

No comments: