ERP and BI: Chicken & Egg?

At the recent ERP Connect conference in London one of the industry speakers, presenting their ERP implementation case study, made a comment that in hindsight they might consider starting their ERP journey from the viewpoint of what reports they wanted to be able to get at the end of the journey.

I thought this comment highlighted two almost contradictory challenges of selecting and implementing ERP systems.

The first is the need to ensure BI capability is available as soon as ERP goes live coupled with the difficulty of eliciting reporting requirements before new ERP driven process are seen in action.

The second is the importance of knowing what you want at the outset of your implementation.

The first point suggests that knowing what you want is very difficult, yet the second suggests it is very important. How can these be reconciled? How can you know what analysis you want before you know what data your ERP will generate? How can you know what your ERP should do if you don’t know what you want to analyse? Sounds like a classic chicken and egg conundrum.

Let’s consider each challenge individually…

Identifying your reporting requirements up front

Most ERP solutions come with some level of integrated or accompanying Business Intelligence capability. Typically this will include some out of the box reports and sometimes out of the box data cubes too. However, because most ERP implementations involve significant configuration and often some customisation, it is rare that out of the box BI is sufficient. It is sensible therefore to allow for some BI development during the implementation. Two common challenges arise during this effort.

• To begin with it can be very difficult to get users to “think outside of the box” and define reporting requirements that are not merely a re-creation of their existing reports. Sometimes users will say this is because they do not yet know how the processes will operate in the new system and why their reporting requirements might be different from the current ones. This can be because users do not have an understanding of the benefits that the ERP is expected to bring and the process changes that will enable those benefits.
• Secondly, users sometimes define complex control reports designed to ensure that the ERP is doing what it is supposed to do. This tendency can be easily understood - for example, where a business process was controlled by manual controls in the past, it may have been appropriate to run reports to ensure that the controls were being applied correctly. If a business benefit of the new ERP is that that manual control is to be automated, then the control reports may not be required and in fact may run counter to the process efficiencies that the ERP was supposed to deliver.

In both of the above examples, a focus on the expected benefits of the ERP project, coupled with an effective change management communication strategy that ensures users understand the benefits and their enablers, can help to shortcut these challenges.

This leads us neatly to the second challenge in the chicken/egg conundrum …

Knowing what you want from your ERP

At Lumenia we always argue that the starting point for any ERP effort should be to identify what business benefits it will deliver. As a starting point this will tell you what impact you want from your ERP. This impact may be made up of different benefits, some abstract or intangible (e.g. improved customer service), some tangible and easily quantifiable (e.g. reduced inventory holding). Read here a recent blog on 'Benefits Focused ERP: A balanced Approach'.

Identifying these benefits should inform every subsequent effort on your ERP journey. When selecting your system it should help you identify what your key functional requirements are (or at least which ones to focus on), when implementing your system it should provide a framework for ensuring that your design efforts align with delivering the identified benefits.

Moving from design though build and subsequent implementation phases to system usage post go-live, reporting will come more into focus. Having maintained your benefits focus throughout you should be well positioned to prepare detailed reporting requirements that relate to benefit enabling processes. Furthermore you know what benefits are quantifiable and can develop reports to measure your success in achieving those benefits.

Thinking back to the speaker suggesting that it might be wise to identify reports required before defining ERP requirements, I think the motivation behind the comment was in fact that the business should really understand clearly the desired outputs of an ERP project at the outset. At a micro level reports are among the outputs of ERP, at a macro level the key outputs are business benefits.

Having a clear benefits-focus throughout the journey can ensure that as you move from the macro to the micro, that misalignment is avoided. The expected macro output (benefits) helps define the input (process) which in turn helps define the micro output (report requirements).

This blog was written by Ian O’Toole, Principal Consultant. If you would like further information on ERP and Business Intelligence please send an e-mail to Ian O’Toole.