ERP Utilization Series: Business Value Realization

Implementing a Cloud ERP solution does not guarantee business value, regardless of the Cloud ERP provider (vendor).  There are countless examples of customers that have not experienced the expected business value articulated in the sales cycle.  Why is this? 

  1. Cloud ERP software could not deliver on the business benefits promised.
  2. Customers could not adapt to the delivered public Cloud ERP delivery model.
  3. System Implementation (SI) partner could not implement Cloud ERP correctly or SI partner could not enable the customer to support their Cloud ERP solution.

Naturally, when things go wrong every stakeholder will point the finger at each other.  As each stakeholder has a share in the success of a Cloud ERP implementation, so is there a share of responsibility in the failure of realizing business value from a Cloud ERP implementation. 

A common theme I’ve observed in my ERP implementation experience is the lack of defining business value goals to be managed during the ERP implementation cycle.  The majority of time, business value goals are assumed as a “natural” result from the project.  Many consider business value an area that is managed after the initial implementation.  The inherent flaw in this approach is that the cost to manage business value is greater when the Cloud ERP solution is live.  This statement is a corollary to the rule that fixing bugs in design is 15x less than the cost of fixing bugs in production.

For example, let’s say you want to consolidate individual functions into a shared service model to leverage economies of scale and promote greater process efficiency (business value). However, this transition is not easy given that the implemented enterprise configuration only considered a “point-in-time” structure. Addressing the functional configuration limitation in production requires greater effort/discipline in a public Cloud ERP model versus an on-premise model (no more direct SQL updates in a public Cloud production environment).

I recommend that business value is front and center throughout the implementation and that business value is the ultimate indicator of Cloud ERP implementation success.  Unfortunately, the majority of Cloud ERP implementation methodologies are based on “traditional” approaches of on-time, on-budget and in-scope. 

What is Business Value Realization?

Do you know how many definitions there are for business value realization?  The number is far more than I can count!  I pride myself at being a pragmatist versus a theorist.  Therefore, the definition must support a repeatable and realistic process given the reality of resource constraints.  I am not arrogant enough to say that I have it all figured out, but the following is my working theory as I interact with ERP customers:

Business value realization is the observed evidence that the customer experiences either as a positive or a negative impact on business process execution.  Consider the following points:

  • Business value is in the eye of the customer.  I humbly believe that the vendor and the SI Partner are responsible in assisting the customer to see the business value created. Simple cost reduction does not equate to business value. 
  • From the customer perspective, business value unnoticed is business value unrealized.   Education is a key requirement in business value realization.
  • Without a baseline, how can one quantify the business value realized? As the Cloud ERP market continues to become more competitive, realized business value will become a competitive differentiation for Cloud ERP vendors. 

Now that we have defined the problem, let’s spend some time discussing how to best address business value realization during the implementation.

Business Value Realization Framework during the ERP Implementation

I have done an exhausted search of business value realization frameworks.  The majority of the frameworks do not address the implementation phase of an ERP solution.  I contend that these approaches should be updated given the apparent level of dependencies that business process execution has with technology today’s environment.  I’ve only found one framework that addressed business value realization during the implementation.

This is a great framework from an IT perspective from the academic world.  I would recommend the above framework to any IT leader looking to create more of an advisory service versus being a traditional service provider (IT should move up the value chain).   In general, I agree with the Lean Six Sigma approach to focus first on process efficiency then process effectiveness for most revenue-supporting and compliance processes.   However, for revenue generating processes, it may be best to focus on process effectiveness first to create market share/disruptance before focusing on process efficiency.

Now, allow me to provide a more detailed framework for business value realization during an ERP implementation.

Performance metrics including KPIs are the definitive “evidence” that the ERP implementation added business value.  Therefore, it is very important that you take a baseline or “snapshot” of your business KPIs before and after the ERP implementation to measure the business value.   My recommendation is to capture the baseline business KPIs during the sales cycle.  Hint: Leverage the ERP vendor to assist you in defining the specific business value you will experience with the purchase of their ERP software.

As you progress thru the Cloud ERP implementation, broad vision and objective(s) becomes specific siloed tasks.   It is important that you reassess your project progress to the agreed upon vision and objective(s).  An iterative approach is best to ensure that you have to opportunity to perform course corrections during the implementations versus more costly corrections after the implementation.

Capturing the post KPIs should be done after stabilization.  The duration of the stabilization phase depends on several factors that I addressed in a previous blog.  Once you have captured the performance metrics and KPIs, you should be able to provide an accurate picture of success and improvement gaps. 

Summary

Going live is only the beginning to business value realization.  Second, traditional ERP implementation project metrics (On-time, In-Scope, and On-budget) only have an indirect relationship on business value.  Generating business value is the primary objective of an ERP implementation, not just moving to the cloud or replacing an outdated system.  Business value must be an iterative and recurring theme in your Cloud ERP implementation approach.

Business value must be a continuous focus for all key stakeholders.  Failure to do so will result in a longer period to business value realization.

Join the community! 10k followers across 100 countries!

IT to Business Alignment for ERP implementations

You’ve decided on the ERP software you need, the Business side has bought into it, and you’ve even picked your Implementation Partner. Now the hard work begins: Making sure that your software deployment strategy sets your company up for success, and that means making sure Business, IT and the Implementation Partner are all speaking the same language.

 

Increasing knowledge transfer and collaboration between business and IT

Driving IT to Business Alignment

First, we need to understand that Business, IT, and the Implementation Partner are coming from different perspectives.   Every party has a knowledge gap to address.  Business best understands their existing business model and the underlying success drivers.  The Implementation Partner understands the ERP software and has multiple years of implementation experience.  IT best understands how technology supports the existing business model as well as how best to utilize existing corporate IT technologies.  Alignment is generated only when a common understand of the business model, ERP software, and technology capabilities are shared by all three parties.  When this alignment occurs there is effective communications and faster decision-making.  Decisions move implementations forward. 

Following is a recommended set of steps to develop a common understanding for effective collaboration:

  • Document existing business processes

It is an area that I see many ERP implementations lack.  The typical challenge I hear is “Why document my existing business processes if I know they are changing?”  Here are my reasons:

  1. Business users usually do not have a consistent understanding of their business model.   Going through the exercise of documenting business process will highlight these differences and drive deeper understanding.
  2. Documenting the existing business model will enable you to highlight the EXACT organizational changes that will occur.  How can you manage organizational change when you do not have a clear understanding of what’s changing?
  3. Business process maps can be a key source of information to quickly educate IT and the Implementation Partner on the existing business process model.
  • Educate IT and the Implementation Partner on the existing business model

Business should take a formal, iterative process to educate IT and the Implementation Partner on the existing business model.  The entire project team should be involved in this training and should progress from a solution-level overview to a detailed business-role level.   Following is a suggested approach for conducting this training:

Level Description Suggested Duration
Business Solution Provide an executive overview of the existing business processes, systems, and organizations that make up the existing business solution. 4 hours
Business Process Provide a work flow of business activities that result from a business event.  Key variations and exceptions should be noted. 2 hours for each business process
Business Activities grouped by Role Provide a “day in the life” experience for key roles that support the business solution. 1 hour for each role
  • Complete ERP software training BEFORE the Implementation Partner arrives

Just as it is important for your Implementation Partner to understand your business model and your language it is important that Business and IT have an understanding of the ERP software and its language.  Effective communication is a two party effort.  Taking the required ERP training before the arrival of your Implementation Partner will enable you to more effectively work together.

  • Have the Implementation Partner conduct supplemental ERP software training

Education is an iterative process – you will never learn everything you need to know for supporting ERP  in one training class.  ERP vendors only provide foundational training.  I always say that the Implementation Partner completes ERP training for the customer.  Implementation Partners have hands-on experience with configuration and maintenance of ERP solutions. 

  • Implementation documentation should be more business-oriented

Nothing encourages alignment more than being able to think like your end customer.  Too often we create project documentation that focuses more on technology than business reasoning and justification.  There are times were I am guilty of moving too quickly from what needs to be done to how will it be done without understanding why does it need to be done.  At the end of the day we build software to drive business results.

 Summary

Business to IT alignment is a strategic goal that can only be reached by taking tactical steps to bring Business and IT closer together to generate mutual understanding and trust.  Implementing ERP software is an opportunity to generate greater alignment by developing a common language for effective collaboration.  When alignment is achieved then decision-making is effective resulting in a greater opportunity for success.

From the book “Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations” by Brett Beaubouef.

Join the community! 10k followers across 100 countries!

When ERP methodologies go wrong

Webster defines a methodology as a body of methods, rules, and postulates employed by a discipline: a particular procedure or set of procedures.  Methodologies add tremendous value to the implementation team by providing a process to guide the team through the implementation.  Methodologies have inherent assumptions, risks, and constraints.  For an ERP implementation multiple methodologies are involved.

Methods, Disciplines required for ERP implementations

Disciplines for ERP projects

Now I believe that methodologies are not the issue; it’s how they are applied that is the issue.  Following are typical problems I’ve observed with applying a methodology to an ERP implementation:

  1. Try to use one methodology for all disciplines.
  2. Execute methodologies in silos.
  3. No taking into consideration the inherent advantages and challenges associated with a methodology.

With several methodologies for each discipline to choose from the question becomes “Which one should I choose?”  Following is a list of the key factors you should consider as part of your methodology selection.

 Factor: Size of the implementation

What is the size of the ERP implementation?  When considering size we need to look not only at the financial perspective (cost) but also from an organizational perspective (users impacted).

Factor: Personnel Capabilities

A methodology is only as good as the people using the methodology.  It is very important that the people on the project team (Business, internal IT, Implementation Partner) have the necessary abilities and training to successfully apply a selected methodology to an ERP implementation. 

Factor: Risk

What are the risk(s) associated with the ERP implementation?   How risk-tolerant is the customer?  Does the customer have experience with ERP implementations?  If there is a high level of risk associated with the ERP implementation then you may want to select a methodology that is more risk-adverse (ex.  iterative).

Factor: Business IT Relationship and Culture

The customer should perform a realistic assessment of the relationship between the business and the internal IT organization.  If the relationship does not foster effective collaboration or there is a known alignment challenge then an iterative approach should be considered.

Iterations provide a dramatic increase in feedback over sequential software development, thus providing much broader communication between customers/users, and developers.

Factor: Business Model Dynamic

The more dynamic a business model is the greater opportunity for evolving requirements.  A dynamic business model requires a method that is rapid and flexible.  Traditional approaches that focus on a reasonable stable set of requirements may not be the best choice for this environment.

Factor: Assumptions for a Methodology

As stated earlier every methodology is based upon an “environment”.  It is very important that you understand the basis for the methodology as well as determine the assumptions made.  Making an objective evaluation of the methodology will determine its advantages, challenges, and assumptions made. 

Summary

The first step of effectively using the required methodologies for an ERP implementation is first understanding the methodology integrations.

Methodology integrations for ERP projects

ERP Methods

 The second step is to consider the key environmental needs that the methodologies must support.  Implementation size, personnel capabilities, risks, and relationships are factors that will have a material impact on how successful a methodology can be applied to an ERP project.  In addition, Implementation Partners should be able to support multiple methodologies in order to provide the best approach for the customer‘s unique implementation.

Join the community! 10k followers across 100 countries!