1 post tagged “erp reporting”

In my last blog I talked about the use, or sometimes, overuse, of Excel as a business system. I suggested that spreadsheets can grow in complexity and expose the business to some risk. My proposal was to consider an ERP system if you didn’t already have one, or investigation of the functionality of the ERP system if you did own one.

Sometimes a company may have an ERP system but a culture has grown up whereby people spend endless hours extracting data and then manipulating it in Excel or Access (er… I did). They then produce reports for use by the business. This happens quite frequently - particularly where the standard reporting from the ERP system is basic or poor.

The reason a lot of standard reporting is basic is that businesses do have their own view on how they want to see reports so there is little point in producing a plethora of reports that will never satisfy the end users. There are cynics who would argue that some ERP vendors don’t provide easy to use and good looking reporting out of the box as it would kill a revenue stream for their separate reporting and business intelligence software. Not me.

The problem sometimes is, that the vendor selling the ERP won’t mention the need for a good reporting tool, at extra cost, because they know that the buyer is simply at their limit in terms of spend or that their product will be seen as expensive against the competition.

So by the time the implementation of reporting is tackled there can be a realisation that ‘something needs to be done’. That ‘something’ can be the buying of a reporting add on (frowned upon by the project budget holder), the development by an internal IT team (if one exists) of a suite of reports (which probably still require some software investment) or finally the ‘something’ that is ‘done’ is ‘nothing’.

After a while the more demanding people will decide that the standard reporting isn’t good enough and will, if they have the wherewithal, use either an extract from the system or connect via ODBC to take data and read it into the aforementioned Excel or Access. And this is where the problems start!

As part of our business review service we often attend internal business meetings where we witness some of the results of the situation outlined above. It’s this: participants turn up to the meeting and spend more time arguing about who has got the right data rather than what the data is telling them about the business. The truth is if you take raw data and then start manipulating it in spreadsheets there is likely to be a difference in the way each person interprets the data – it’s maybe because of grouping, or dates, for instance. It may even be that there are faults in the formulae within the spreadsheet – which is very common.

So what to do? Well, I’d suggest putting together a team to agree what the key metrics are. Then, as a team, design and deliver reports that are ‘the same’ to each person that needs them. Ensure you are comparing apples with the proverbial apples. At least at that point you can address the problems (if there are any) in the business.

This is an activity that can be relatively low cost – and it will ensure that if you do decide later to invest in a reporting application you will have a jump start to your project and shorten the time to realising value. I’ll talk next time about the advantage of formal ‘reporting packages’.