Making Organizational Decisions Post ERP Go Live

The hardest part about making the right organizational decisions related to post go-live ERP is convincing leadership that there is a need to make any organizational decisions. Because nothing about the fundamental business model has changed, there is natural resistance to believing there is a valid reason to discuss organizational changes.

In its simplest form, “making organizational decisions” about ERP means designating without ambiguity the individuals who have authority to (a) establish priorities for non-critical help tickets (b) establish priorities for IT development items (c) define, test, and prioritize the development of business reports and ERP business intelligence tools, and (d) organize and coordinate local regression testing for patches and upgrades.

Establishing priorities for tickets received by an ERP help desk and development objects requires a good understanding of the cost/benefit relationships behind each. In the absence of financial or strategic assessments, solutions are often prioritized according to who is complaining the loudest and most frequently. Because each functional area is going to have a punch list of enhancements they want, the person or team establishing the priorities must be seen as fair, and acting in the best interests of the business. If someone does not act in this role of coordinator, then each group will begin negotiating independently with the ERP development group. Before long, the development group throws up their hands in frustration, and begins working on the things that they think are important, and the last thing you want is for IT to assume responsibility for prioritizing business needs.

Organizing Data

The development of business reports and business intelligence is a thankless but much needed task. Most people have little appreciation for how messy business data is, and how much patience it takes to define the right combination of data to answer a question accurately. There are strategic choices that can be made that reduce the amount of time required to manage business reporting – like using out of the box reporting, or providing users with their own query tools. But if there was an immediate need for ten new reports, which in your organization would be responsible for prioritizing and verifying them? If you know the answer immediately, this is a non-issue; if it isn’t clear to you, then someone needs to be designated.

Regression testing is an additional after ERP go-live task that no one really warns you about. Because of the integrated nature of ERP, applying changes – improvements from developments, vendor patches and upgrades, or third party *ERP bolt-ones – requires careful testing and evaluation in all modules and functional areas. Seemingly minor changes can have large effects, and you have to have a robust plan to perform and evaluate this testing.

You do not necessarily have to add to complement for these post ERP go-live tasks to be competently managed, but they must be competently managed, one way or another. Otherwise, you will likely leave a significant amount of ERP potential untapped.