Maximizing ERP Implementation Impact through Outcome-driven Strategies

ERP implementations are anything but simple. A reasonable sized implementation would last anywhere from a year to three and has various moving parts and complexities.

However that’s not even the hardest part of an implementation. It’s the phase after the go live when the actual challenges start.

The first and foremost problem is to get everyone to agree that you are on the right path and there is a bigger purpose to have done this. Right from the time you go live when the non believers would find multiple reasons why the system is designed wrong going months or years later when there will be questions on what was the benefit or outcome of the huge investment that went into the ERP implementation.

Then there is the people element. Whether you are moving from a greenfield to a new ERP or whether you are changing from one to another if you have gone through a transformation journey, your team has most likely taken a massive hit. They would have been torn apart between BAU and project during the implementation and most likely still finding their footing with the new technology and tools while having to support the new system in production

Then there is the speed of innovation! If you are on the latest technology, cloud etc. and the speed of tech evolution, let’s say, were the speed of light, then the speed of adoption is like the speed of sound. While you are running faster than normal (~300+m/s), the technology is moving a million times faster!

Lastly there is the constant fight to drive costs down while you adjust to all of the above changes. Someone somewhere had called out at the start that by the end of it all you would be able to start seeing visible cost drop in your IT spend and now everyone wants you to deliver to that promise.

Each of these challenges need a post of their own, but in this one would like to deep dive into how we can try to drive our implementations to specific and targeted benefits and manage to get the most of our implementations without loosing sleep or even your mind over it!

Drive your ERP implementations to a defined outcome.

Large transformational (or even smaller) projects need to have measurable outcomes. While this helps drive the project successfully and keep it on track it also ensures that as a project team you have tangible outcomes to show to the rest of the organization, executives and leadership teams.

Benefits analysis and business outcomes are common measures used to define business cases for ERP implementations and measure success. But the most mature implementations are the ones that build benefits into the core of the implementation journey. Let’s see what this means for an organization before and after the go live.

Start with the end in sight!

When defining the requirements look at them from multiple perspectives. These perspectives gives different lens to the process and what you are getting out of it.

Operational Requirements

The most obvious one is the operational requirements. This is a basic requirement that is needed from the system. For example this could be something like I want the system to be able to allow users to create orders with details like customer, sales channel, items and the system should allocate inventory and provide a scheduled ship date. I would tag this requirement as an Operational requirement. This should not be confused with a MoSCoW list. This is not classifying the requirements as must have or nice to have, rather classifying the nature of the requirement.

Benefits Requirement

But now look at what are my opportunities to improve? Do I want to improve my service level to the customer or do I need to reduce my cost to serve. Based on this you would want to elaborate this requirement further by saying I want to be able to allocate stock from the warehouse or store that has stock available and has the least lead time to deliver to the customer. I also want to elaborate to say that for certain channels (say my distribution network or resellers) I want to be able to shop the stock from central warehouse and optimize shipping cost by grouping shipments to minimize LTL shipping. Now these requirements came about because we are looking at 2 key metrics customer service level and cost to serve. I would take these requirements as benefits driven requirements and tag it to a specific benefit initiative.

Metrics Requirements

We now have a list of operational requirements which are needed to get the system to function and support my business process. We also have benefits driving requirements that we need from the system to ensure that the project delivers value to the business. But what we don’t still have is the definition of what is needed to ensure we can track the business metrics and allows us to quantify it. We call these as metrics driven requirements.

Lot of times we make the common mistake to deprioritize these requirements as reporting requirements. But in many cases these reports cannot be delivered unless there is a foundation built to support the reports. Let’s look at some examples.

Few years back I had worked with a client who wanted to measure their fill rate (on time in full) across each of their process steps (scheduling, picking, loading to truck, shipping and last mile). This requires us to have a systematic way to define the orchestration to capture each of these steps clearly and track estimate and actuals. Now this is beyond just reporting and requires the underlying design to cater to this.

Similarly in another engagement, the client had requirement to move to 100% same day delivery for certain zones and next day delivery for the rest of the country by a particular time. Hence they needed to measure their shipping and delivery lead times by specific channels and zones to analyze and compare against their objectives and take strategic actions to adjust their shipping networks or realign stock levels. This requires that the system is able to track each demand by it channel and zone and record the lead time and the supply source to holistically identify any planning issues or potential need to adjust shipping network or add distribution points.

Adding Sustainability to the Mix

While we can classify all requirements under the 3 categories we just discussed, given the focus and need for sustainability, you could go a step further and identify your sustainability requirements separately. It could again be something that is formatting your sustainability goals like say a system needs to be able to prioritize shipping methods using electric vehicles than regular fossil fuel or need to be able to record offset liabilities based on the supplier sustainability data for all material purchases.

There could also be requirements to measure and report on sustainability like ability to report on carbon emissions from the shipping transactions or to measure renewables / recycled materials in the production process.

In Short – Create a framework that works for you

What you need to do is define a framework that helps put the benefits tracking right in the middle of everything. Key things to achieve this would be

1. Have a clear classification of your requirements as operational, benefits driven and metric driven.
2. While it is common to tag requirements with specific operational processes (L1-L2-L3-L4). Similarly tag them to specific business objectives (they can be hierarchical or flat depending on your business needs).
3. Quantify the outcome where and if possible. But even if you cannot quantify have the classification to help analyze later
4. As a part of the reporting process track the progress by the business objectives to help visualize the outcome. Have a summary of the on track / delayed items by benefits initiatives.
5. It’s a common process to mark defects against requirements. When this is done right, this can then also help identify defects impacting specific benefits to help prioritize defect fixes and determine readiness or give a view to the stakeholders to make better go/no go decisions

What if I am not there yet!

Now it’s not uncommon to be in a situation where we cannot articulate the business benefit and the focus is predominantly operational.

In such a situation it helps to keep it simple and try to measure everything. Focus on the metric driven requirements, by splitting the process into logical groups and define what you want to measure. What you cannot measure cannot be improved.

Keep it simple and pragmatic. It can be anything like need to measure number of orders booked per unit of time or time taken to approve POs, actual vs estimated lead times for purchase orders.

This will help the project team get into a habit of creating that strategic view rather than being tactical and help build an ecosystem to measure everything.

Define a Minimum Viable Product

Now when creating the requirements you should be as unconstrained as possible but we all know that as we get through the various stages of the project we need to start deprioritizing

This is where this framework helps to manage the “Minimum Viable Product” (MVP). Tagging requirements as operational or benefits based help identify the high value ones vs low value ones. Using this technique we can

1. Prioritize the requirements that give more yield
2. Reset stakeholder expectations based on what is moving to the backlog to align on the expected outcomes

Driving continuous focus on benefits post go live

When you go live you by now have a view of the backlog and the segregation of this backlog. Starting from here you can prioritize your backlog and have a roadmap for benefits realization.

Now a key difference from how we tracked this during the project is that there are no more operational requirements. We should classify issues or requirements as having a business impact, driving a business benefit or enabling better recording.

Measure the size of the price as in the $ impact on the business or $ value to the benefit. If the pre implementation classification had been implemented correctly by now you should be having metrics that can help you measure this.

It’s never too late to start

Now everything said and done, not all implementations are so meticulously managed. We all learn as we get on the journey. But that doesn’t mean we cannot start doing these. Below are a few steps that I think may help you get going

1. Go back to the drawing board look at 3 key things
   • What needs to be measured? Do we have metrics that we are measured on? You could call them KPI or OKR or any other term.
   • Are we able to measure it through the system? If yes that’s a great starting point to start defining your roadmap and projects based on these
   • If not then lets define what is needed to allow you to measure this
2. The next thing to do is look at the system you are using to track the backlog. This could be a ticketing system or MS planner or Jira or any other tool.
   • Look at your backlog, see how you are classifying and tracking it.
   • Enable fields or tracking mechanisms, these could be defining tags, labels, epics or whatever works for you to map them to your business initiatives.
   • Track impact in terms of $ or like with effort you can track them like t-shirt sizes (S, M, L) if actual $ impact is not known or too difficult to measure.
3. Once you have defined your baseline data setup regular cadence to track these macro indicators. If possible assign initiative owners within your team to own and manage the backlog impacting their initiatives. This will help you provide specific focus to specific areas
4. Finally incorporate this into your planning cycle, work with your business stakeholders to identify the key metrics or business outcomes expected of them in the planning period and drive your planning cycle by drilling down into your outcomes to identify initiatives and plan for them.

In summary

With the move to industry 4.0 and now 5.0 technology is becoming a central part of the process with focus on driving integration, automation, data exchange and now collaboration between humans and machines. There was a time when IT was a support function, but now the leading organizations are seeing IT or technology as drivers to create new business models, disrupt their industry or even create new revenue streams. With cloud, AI / ML, IoT, blockchain and other evolving technologies this is becoming more of a norm than exception. Hence there is a need for IT teams to move from being reactive to proactive, create opportunities drive business outcomes. This starts by incorporating an outcome driven mindset

This is my attempt at articulating how I think this can happen. Keen to hear your thoughts and also how have you driven such business transformations in your own projects.