Troubleshooting ERP Projects

During my career in ERP consulting I  had several opportunities to be involved in deployment of emerging ERP products and services.  As with any innovation rollout there are challenges to overcome and I had to learn how to quickly triage ERP projects for success.  Troubleshooting an ERP project is more than just performing an assessment – it’s implementing a realistic action plan and making it work for all stakeholders involved.   Following is a tested and proven approach to jumpstart stalled ERP projects.

Method

Similar to a Forest Fire Hotshot I typically got dropped into a “hot” ERP project that had stalled or had serious show stoppers.   Time is always against you.  However, you must first put in the effort to objectively understand the situation and establish your credibility:

Troubleshooting ERP Challenges

Troubleshooting ERP Projects

Too often I see project managers jump into the details (WBS, Risks, Issues, CPI, SPI, Cost) without first understanding the context.  You cannot be perceived as a busy body looking for who dropped the ball.  Vendors, Customers, and System Implementers are made up of people.  People make mistakes – especially me.  People don’t care what you know until they know you care.   It will be people - not technology – that will play the biggest role in getting the ERP project back on track.

Before hitting the ground running you first need to do your homework.  As part of an ERP assessment it is important to review the key project artifacts generated and updated throughout the project.

Key Project Documents

Key Project Documents

This is the easy part and it is usually a simple process to review and evaluate.  If a project scope statement does not exist or is not well-defined then chances are this absence is contributing to the problem.  Creating or refining the project scope statement is a very small part of the action plan you need to execute.  Now, let’s turn our attention to the implicit artifacts and information that are harder to identify and resolve.

Understand the Underlying Drivers

ERP vendors,  System Implementers (SIs), and Customers want their ERP implementation to be successful.  Yet there are fundamental drivers for each stakeholder  appears to be in contradiction.  Consider the following illustration:

ERP Stakeholder Implicit Drivers

ERP Stakeholder Implicit Drivers

Understanding the fundamental drivers of your stakeholders enable you to relate, empathize and align the efforts of all project stakeholders.  It is important to note that you need the efforts from ALL stakeholders for success – regardless of who is at fault.  I humbly submit that it is extremely rare when a single stakeholder is responsible or is at fault.  On the flip side it is even more extreme to have a single stakeholder solely responsible for saving the day.

Strategy & Execution

It is a straight-forward exercise to develop a plan for troubleshooting an ERP project but providing a plan by itself does not add business value.  How you execute and implement the plan is more important than the plan itself.  Many of my project management colleagues may not agree with my assessment but I am  convinced that this is true.  Following are my guiding principles for ERP troubleshoot efforts:

  1. Create quick wins.  Triage is required to stop the bleeding.  You need to quickly seize the initiative  and  create positive events.
  2. Attack problems from multiple angles.  If you have one approach get stonewalled you still have other ongoing activities to continue the march forward.  This means that you have contingency plans in flight.  Be aggressive.
  3. Triage is not the time for lessons learned.  There will be opportunity for reflection after the immediate problem(s) have been addressed.
  4. Problem solving is not about assigning blame.  You need every individual to have laser focus on resolving the problem and not on how to protect them own interests.
  5. All stakeholders must be willing to stretch outside their comfort zone.       Customer and vendors limit their response based upon contractual arrangements.  Partners think outside the box for mutual success.
  6. The answer lies within the team.  Many times the greatest impact you can have is to enable the  key players to recognize the solution. Communication skills will be vital to your success:
Communication Skills

Survival Skill – Communications

Summary

There is a fair amount of information available in books, articles, and blogs related to avoiding ERP problems and I agree that you should take reasonable steps to minimize known ERP problems.  However, I believe that it is prudent to be prepared for the “unknown unknowns” that always occur with any ERP project.  Troubleshooting ERP projects require process knowledge of project management fundamentals, problem solving techniques, and most importantly – perseverance.  Just like the rudder steers the ship, finding small success(es) can get your ERP project back on the path for success.

ERP Project 101: Deployment vs Requirements Gathering

Customers, System implementers and ERP vendors are always looking for ways to accelerate ERP implementations.  One popular approach is to take a phased deployment approach based upon criteria such as location, ERP module or feature set.   Requirements are gathered, validated, and tested based upon a limited scope.  Unfortunately, many ERP projects utilizing this approach result in failure given requirements conflict and misaligned expectations.  In the following blog posting we will discuss how to minimize challenges associated with phased ERP deployments.

Reality Check!  There will be ERP requirements conflicts

A reality with any cross-functional or multi-site deployment is that there will be requirement conflicts as part of an ERP implementation.  In our focus for rapid results and simplifying ERP deployments we forget the fundamental result – an ERP implementation is the implementation of a business solution.  Consider the following illustration:

ERP REquirements Conflict

Example of Requirements Conflict for ERP

Let’s assume that we want to accelerate an ERP HR implementation by deploying ERP solution by region.   To further streamline our efforts the project only gather requirements from the North America HR stakeholders (Phase I). The above approach appears to work for the initial ERP deployment; however; these short-sighted decisions can have a negative impact to future deployments.   Remember that correcting problems and limitations are more costly once an ERP system is deployed in a production environment. 

With the above said, I appreciate that ERP vendors are evolving their ERP software to provide additional flexibility in configurations to allow variances based upon industry, line of business, country and even user preferences.  However, we should understand that all ERP solutions leverage a common data model with specific data dependencies.  We can address this constraint in one of two methods.  Either we take a risky approach of gathering requirements in silos hoping that we clearly define all ERP configuration dependencies or take the practical approach of gathering requirements across all HR operational areas. In the next section we discuss several practical steps to ensure requirements conflicts are minimize.

Practical Steps to Minimize ERP Requirements Conflict

Let’s brief speak to some common-sense approaches to deal with the reality of ERP requirements conflicts.

How to address ERP requirements conflicts

Practical approaches to address requirements conflicts

The first step of requirements management is to perform a stakeholder analysis to identify the appropriate business owners and subject matter experts in include in requirements gathering.  It is important to note that we always implement to a business process not simply to the software (ex. module, feature). Utilize solution modeling to analyze business requirements from multiple perspectives.  Too often I observe ERP projects spend more time on defining exceptions to standard business scenarios versus defining a common requirements set that can be leverage to isolate and manage unique requirement criteria.  Consider the following illustration:

 

Logical Business Requirements Model

Logical progression of gathering ERP requirements

There should be a logical progression of business requirements from the global level to the specific user level.  Isolate requirement exceptions to effectively quantify frequency, impact, and cost.  Utilizing this approach will provide the customer with greater insight for an informed decision.   Finally, let’s not forget the Lean principle that states process efficiency is gained when variability (exceptions) is minimized.

Summary & Conclusion

The ERP industry is hyper-competitive where every ERP vendor and System Implementer is looking for an edge to accelerate and reduce the costs associated with ERP implementations.  This desire is intensified by the entrance of ERP SaaS offerings with lower entry costs for a growing target market.  The challenge is to identify competent options for accelerating ERP implementations without putting long-term customer success at significant risk.  Requirements management (gathering, validating, and testing) is the critical discipline that impacts all downstream implementation activities.  Taking a technology-oriented approach results in (a) unclear requirements, (b) requirements conflicts, and (c) additional rework to support future deployments.  Making the right investments in requirements management will be the best chance to accelerate downstream activities including deployments.                    

BPR, BPM and ERP

I had a customer ask me about the relationship between BPM and ERP.  Does ERP implement BPM or do you need to have BPM before ERP?  Is an ERP implementation a BPR project?  Who’s on first?  As the ERP industry evolves it has become evident that additional disciplines like Business Process Management (BPM) and Business Process Reengineering (BPR) must be employed for a successful ERP experience.  In the following blog posting I plan to define and demonstrate the roles that BPM/BPR play in the ERP lifecycle.

BPR, BPM, and ERP Revisited

Allow me to establish some basic definitions for our discussion:

  • Business Process Management (BPM) consists of methods, techniques and tools to design, deploy, control, and analyze operational business processes involving humans, organizations, applications, documents and other sources of information.
  • Business Process Reengineering (BPR) is the redesign of business processes – and the systems, policies, and organizational structures that support them – to optimize the work flows and productivity in an organization.
  • Enterprise Resource Planning (ERP) is integrated business software that supports multiple business functions across an enterprise.  ERP implies the use of Commercial Off-The-Shelf (COTS) packaged software rather than proprietary software written by or for one customer.

There are a couple of key concepts we should review to compare/contrast BPR and BPM.

Compare BPM and BPR

Compare & Contrast BPM & BPR

BPM focuses on the business process model to monitor, identify, and implement incremental improvements.  These improvements or eliminations fall within the fundamental rules, parameters, and culture established by the existing business model.  However, there comes a point in time where the law of diminishing returns applies and a transformation to the underlying business model is required.  A more aggressive approach like BPR must be utilized to evolve to the next level of business process maturity.  Consider the following illustration to demonstrate how BPM and BPR interact along the Capability Maturity Model Integration (CMMI):

 

BPR, BPM within CMMI

BPR, BPM within CMMI

Allow me to provide an example.  Company A performed a CMMI assessment of their purchasing process.  Results from the assessment showed that the purchasing process was defined for certain business sales (revenue stream) but not for all purchasing events (direct & indirect).  Another key finding was that there was no formal integration between demand planning, supply planning and purchasing which resulted in reactive purchasing. From the above CMMI reference, it was determined that Company A’s purchasing process is at the Managed level.  Company A implemented several incremental initiatives (BPM) to improve process execution including documenting purchasing tasks for all purchasing events and conducting periodic purchasing planning meetings with operations. 

Company A realized process improvement yet the value was limited by following model constraints: (1) each revenue stream (business line) had its own unique purchasing process & rules and (2) Purchasing had limited visibility across the entire supply chain.  Two fundamental mindsets have to change:

  1. Move from unique purchasing processes to a common enterprise purchasing model that is flexible enough to address the competitive requirements for each business line
  2. Enable Purchasing to have visibility across the entire supply chain to support a process-oriented management model versus a function-oriented management model.

Implementing these changes will require a formal, projectized (BPM) effort that will redefine existing business rules, culture, and business process activities.   As Company A continues to evolve their purchasing process they will conduct both BPM within the CMMI maturity level and BPR as they move to the next CMMI maturity level. 

How Do BPR, BPM, and ERP Relate?

ERP provides the automation of business activities.   There are two fundamental value propositions that ERP provide to customers looking to move up the CMMI maturity model

  1. ERP reduces the effort required to perform tactical business activities so customers can focus on strategic activities. Expanding on our purchasing example, this would include basic functionality like automating the creation of purchase orders, approving purchase orders, and matching purchase orders with receipts & supplier invoices.
  2. ERP provides the opportunity for visibility across business functions to support business process management.  That said, there are several factors that determine the level of visibility. 
ERP Business Process Visibility

Factors Impacting ERP Business Process Visibility

A competent ERP solution should provide robust, closed-loop integration between the functional modules provided out-of-the-box.  As a practical note, there is always a need to integrate ERP to legacy systems and this requirement should be not overlooked.  A business solution is only as good as its weakest integration.  Process consistency will enable a relevant comparison of results and management of business processes.

A mature ERP solution should provide automation and integration support for both tactical and strategic business activities across the CMMI model.   

ERP Evolution within CMMI

Interaction of BPR, BPM, and ERP within CMMI

I am a firm believer that business should lead and technology supports.  Therefore, as the business model evolves it is important to identify the corresponding ERP functionality to support the business activities.   This model also communicates that the best approach to implement ERP is to follow a logical maturity path for business processes.

Common ERP Misconception and Mistakes Related to BPR & BPM

Allow me to address some common misconceptions and mistakes made during ERP implementations related to BPR and BPM.

BPR is part of the ERP implementation.

While I agree that the initial ERP implementation will result in major changes with existing business functions, BPR will not happen unless there is a concerted effort to redefine the holistic business model and organizational structure to be successful with the ERP software.

Implementing ERP will give us BPM.

The direct answer is no.  ERP does provide an information foundation that can support BPM.  BPM is more about a discipline for managing processes and less about software. 

Do I need ERP to mature my business processes?

Technically speaking, ERP is not a hard requirement for BPM.   However, manual routine tasks and limited visibility hinder strategic activities.  ERP can play a key support role in automating business tasks and provide visibility through integration.

Should I implement ERP features that support business activities at different maturity levels?

Business realities will necessitate that customers implement ERP features supporting different CMMI maturity levels.    The problem lies in two areas:

  1. Customer expectations are not appropriate set regarding the limited value realized from mature ERP functionality due to less mature business activities supporting strategic activities.  Example:  A procurement process scorecard measuring standard Key Performance Indicators (KPIs) will have limited value if there is not a standard, enterprise procurement process.
  2. Implementation partners and business solution advisors should provide a short-term strategy and roadmap to evolve the supporting business activities to same level of maturity.   This approach provides a “quick-win” opportunity for customers to drive additional value from the existing ERP investment.

Summary

Understanding how BPR, BPM, and ERP should relate to one another can be a challenge.  Some believe that it is an “either or” proposition.  I do not subscribe to this school of thought but rather believe that BPR and BPM are disciplines that should be interweaved as part of your ERP application strategy.  Knowing and appreciating these interdependencies will put you in a better position for ERP success. 

ERP Project 101: What + Why = How

One of the reasons why I am a consultant is that I enjoy solving business problems with technology. ERP provides a technical foundation that I can utilize to solve problems.  However, during my career I came to the realization that simply throwing technology at a business need is not in the best interest of the customer.  This is especially true when you do not completely understand the requirement.   There is a difference between an evolving requirement and an evolving understanding of the requirement.  In the next sections we will briefly review a practical approach for ERP requirements management.

 

Gathering Business Requirements is Just the Beginning

I think we all can agree that gathering business requirements is a key activity that will have a significant impact on ERP implementation success.  However, it is as equally important to focus on requirements validation before proceeding to implementing a solution for addressing requirements. Too often we jump from gather to design before we have a full appreciation of the business need.  When it comes to formal requirements management, I keep the following simple equation in mind:

Requirements Mgmt 101

Basic ERP Requirements Management

  

Defining What

Sounds simple enough but how you gather requirements sends a message.  Also, it is important to understand if the requirement is the result of a new opportunity or addressing an existing business pain.  The source should play a factor in your approach to gathering information.  Consider the following commonly accepted approaches utilized for gathering ERP business requirements:

 

Defining Requirements

Generally Accepted Requirements Gathering Methods

 

Please allow me to state that the above methods are valid and have their inherent advantages and disadvantages.  The challenge I find is not gathering the requirement but rather the limited effort spent on understanding how the requirement supports business process results. 

 

Determining Why

It is hard to provide a solution when you do not understand the business.  Asking why is less about challenging business requirements and more about gaining a better perspective of the requirement.  What are the desired result(s)?  How do the result(s) add value to the overall business process?   Odds are that you will have only a superficial understanding of the requirement if you do not understand the context (environment) of the business need.  Also note that asking why is the first step to validating your understanding of the business need.  Following is a list of the common validation activities for business requirements:

Confirming Requirements

Requirements validation techniques

 

I firmly believe that all four validation methods should be employed as part of defining business requirements.  Unfortunately, not all of these validation steps occur during the deployment.  The advantage with ERP is that you have working software that you can easily demonstrate and confirm how business requirements would be handled.  Do not guess – prove what is possible!

 

Constructing How

This process is typically an area that is not executed well when it comes to ERP.  In the rush for faster results many assume that the solution must be implemented via technology.   Technology is good for many activities (repeatable, logical) but it can also be a costly option for conflicting requirements across a business process.  As a rule of thumb, I typically consider 4 options for addressing business needs:

 

Addressing requirements

Options to address ERP requirements

 

  1. Automation: Developing a technical solution to address need.
  2. Business Process: Creating business process to address need.
  3. Acceptance:  Do nothing and handle as the need arises.
  4. Avoidance: Eliminating the source of the business need.

 

Understanding both the What and Why will provide you the right insight to select the most viable approach for implementation of the requirement.  It provides you with the perspective and context for effective decision-making.

 

Summary

An enterprise technology platform like ERP is an empowering toolset for addressing business needs across an organization.  Yet, soft skills like requirements management have a greater impact on business solution success.  It seems like every couple of years there is a “new” ERP methodology that will address the challenge of gathering ERP requirements.   Often I observed too much focus on the methodology and not enough effort focused on the end result.  I’m sure that I may receive some criticism from my peers in regards to my attempt to “dumb down” requirements management.  However, I have found that the best approach is a simple approach that every stakeholder can understand and recall instantly versus having to go to a methodology book.  

Building a Better ERP Estimate

There are several documented examples of ERP implementations that went over budget or did not hit the original go-live date.  There are also many explanations out there to explain why these ERP implementations did not meet budget or timeline.  Instead of repeating common information out in the ERP blogosphere, I would like to speak to a root cause that is typically overlooked by our industry – inaccurate ERP implementation estimations.   In the next sections we will take a closer look at building a better ERP estimate.

Rule #1 – Have the right type of information to calculate an ERP Estimate

Developing a competent estimate for an ERP implementation or major customization can be a challenge for both seasoned consulting partners and a new ERP customer.   In a previous life I developed ERP implementation estimators for one of Tier-1 ERP software vendors.  I also developed both Time & Materials as well as Fixed-Price ERP implementation estimates – some good, some not so good.

Simply stated – an ERP implementation estimate is based upon your current understanding of the following areas:

Information Drivers for ERP Implementation Estimates

Information Drivers for ERP Implementation Estimates

 Let’s focus on some specific areas that are typically overlooked or under appreciated. 

Area Description
Customer Participation Implementation partners are generally good about estimating their level of effort to support ERP implementations but fall far short in estimating the effort for the customer.    In the majority of ERP implementations, customer must make available their best and brightest resources to support the implementation.  Odds are that these resources play a major role in current operations.  The ERP estimate should include any need to backfill existing business resources.
Project Scope Project scope refers to the implementation activities that need to be performed and who is responsible for performing the task(s).  Unfortunately, customers see this as an area to reduce implementation costs by taking on activities that they do not have the skills/resource availability to complete (ex. Organization Change Management).  People make ERP successful.
Product Scope Too often business processes and product scope is defined only at the product level (example: we are implementing the ERP’s Purchasing module).  How can I tell what business activities and features are out of scope?  Developing focus is much harder to develop and maintain. 
Implementation Partner Constraints  Every implementation partner has constraints!  It is a just a reality that should be factored into any ERP estimate.  For example, how much lead time should be given for an Implementation partner to replace a consultant?

You can never hope to create a realistic estimate without having valid information on the drivers that influence scope, schedule, and resources.  The next step is to understand your level of comprehension of the information that drives the ERP estimate. 

 Rule #2 – Understand the type of ERP Estimate you are calculating

Per the Project Management Institute’s Body of Knowledge (PMBOK) there are three types of estimates for a project.  These estimates are based upon your level of understanding for project scope, constraints, and assumptions.

Levels of ERP Estimate Accuracies

How Understanding Drives Estimate Accuracy

Simply stated – the more you know about the task(s) at hand the greater the probability of calculating a realistic estimate!  The trouble is that too many ERP implementations do not generate a definitive estimate.   A majority of implementation partners generate estimates during the sales cycle where estimates may approach a budgetary accuracy – at best.  To compensate for the estimation accuracy (-10% to 25%)  many implementation partners incorrectly utilize contingency reserves and management reserves to plug the potential estimate gap.   This is just a bad estimating practice which will most likely result in budget challenges further down in the implementation.  Fortunately, there are steps we can take to develop better ERP estimates.

Rule #3 – Drive to validate and refine your ERP estimate

Estimates can and should change as you learn more about the project.  However, there is an expectation out there that estimates should be defined once and they should be completely accurate.  Here is where I see the process break down.  Once an Implementation partner communicates an estimate too often the customer will latch and consider it an iron-clad promise.  The key driver for this phenomenon has more to do with the Implementation partner setting the wrong expectation when an estimate is communicated.   Customers encourage this behavior by focusing on cost as the key competitive differentiator.  Also, there is a perception in the market that if an implementation partner cannot provide a single estimate then the Implementation partner does not have the experience.  Customers, this may be the case but do not blindly jump to that conclusion.

Best Practices for obtaining ERP Estimates from your Implementation partner

Over the years I have been asked by customers what is the best approach to get a reliable, cost-effective estimate from Implementation Partners.  When should a customer request a fixed price estimate versus a time & materials estimate?  Following are some general guidelines I would like to communicate based upon my experience:

  • Fixed Price versus Time & Materials: Have the Implementation partner provide a Time & Materials estimate for project planning, requirements gathering, and fit/gap.  Once the Fit/Gap is performed you should know exactly what you are up against and then ask for a competitive bid/fixed price estimate to complete the remaining work.
  • Complete Information:  Always ask the Implementation Partner to provide an estimate with the following information
    • Product Scope
    • Project Scope
    • Assumptions
    • Constraints
    • FTE Hour Requirements for both the Implementation Partner and customer resources
    • Estimate accuracy – let customers know up-front that the estimate will change
  • Quantify Reserves: Ask the implementation partner if the estimate contains either a contingency or management reserve.  If so then ask what % of the total estimate is for reserves.  If this % is greater than 10% then this is a sign that the Implementation partner did not gather enough information to generate a realistic estimate.  If the implementation partner does not calculate a reserve then consider this estimate suspect (red flag).
  • Knowledge Transfer:  Just as important it is for an Implementation partner to perform knowledge transfer to enable customer resources to support ERP, it’s as important for the customer to educate the Implementation partner on the unique aspects of their business model.  The better the understanding the better the estimate.

Summary 

There are many of my peers who would consider ERP estimation more of an art than a science.  In my humble opinion, this is a bad philosophy that either results in generating an unrealistic estimate or the customer spending more money than is required.   Customers should also be realistic and understand that estimates created in the early stages of an ERP implementation will change and focus on making the right decisions for mutual success.  Level of effort estimations for ERP implementations are based upon the current understanding of the ERP implementation.  Some ERP estimates are easier to calculate given a predefined implementation scope, however, there will always factors unique to a customer that must be explored, defined, and refined during key milestone implementation activities.

Developing a Business Case for ERP Customizations

To customize or not to customize – that is the question which continues to be a source of contention and confusion.  On one hand, customization(s) can result in an expensive ERP solution.  However, ERP software enhancements can provide a competitive advantage or cost reduction that is customer-specific.  The challenge is not in the question itself but rather how the answer is justified.  Unfortunately, many business cases for ERP customizations are either too short-sighted or do not fully comprehend the impacts to the ERP investment.  In the next section we will discuss the key components required for an ERP business case for customization(s).

 Business Case Overview

 Following is a business case template I’ve used as a consultant to justify ERP customizations. 

Valuation and Justification for ERP customization

Business Case Format

Let’s briefly discuss each section in greater detail.  The Problem (or Opportunity) section should clearly define the issue(s) as well as the target audience who will benefit from addressing the problem.  The problem section should also explain the compelling reason (s) why the problem should be addressed.  The Solution section should speak directly to solving the problem or addressing the opportunity.  The solution section must include the method(s) used to validate that the proposed solution solved the defined problem.

The Approach section details the viable methods available to implement the solution.  The approach section should not be a theoretically exploration of all possible options.  Too often I have observed where unrealistic approaches were defined, which did more to confuse decision makers rather than create a focused, compelling argument.  In general, I typically provide three approaches when pitching an ERP customization:

  • Full Customization (Extreme)
  • Partial Customization (Middle of the Road)
  • Out Of The Box (OOTB) (Extreme)

Following is a generic example of comparing the above options:

Possible Approaches for ERP Gaps

Possible Approaches for ERP Gaps

Moving back to the business case, the Risk Assessment section outlines the risk(s) associated with each approach option defined in the previous section as well as identifying the risk(s) of doing nothing to address the problem/opportunity.  The final section is the Value Analysis section.  The key challenge I have noted is that short-term value methods (examples: benefit/cost analysis, payback period) are used to support a decision with a long-term impact.   In the next section we will discuss the unique considerations one must address in developing a valid ERP software customization value analysis.

Value Assessment Considerations for ERP

In addition to the short-term costs associated with ERP customizations one must consider the following areas to calculate the long-term costs:

  1. Impact to Upgrade and Maintenance:  What is the impact that the customization will have to the ERP maintenance and upgrade process.  Is the software customization intrusive? – Meaning is it an add-on enhancement or a fundamental change to how the ERP software works?  The more intrusive the customization is the greater the costs required for ERP support and upgrades.   Frequent ERP upgrades are a key strategy for driving additional business value.
  2. Impact to IT Resource Sourcing:  The more you customize the ERP software the more customer-specific ERP knowledge an IT resource requires to provide an effective level of service.  Additional customizations will have a shrinking effect on the IT resource pool and may have the potential of driving up related IT support costs. 
  3. Cumulative Impact to the IT Footprint:  Too often we consider customizations individually and not part of the total ERP software changes made.   A field change here or a new application page may not seem like a big deal but you must remember that you must support everything you customize.

The above areas will ensure that you generate a holistic set of information for an informed decision.  Too often, short-sighted decisions are made to customize ERP without completely understanding the potential impacts.  The next section will shed more light on some of the less obvious risks associated with not having a holistic business case.

 Risks of not developing an effective ERP customization business case

Incomplete information results in incomplete decisions and more importantly – missed expectations and business results.  Following are a few of the key risks generated from over-customizing your ERP software:

  1. Greater operational costs:  There is an additional cost associated with customizations –typically required from the IT organization to support and manage the software changes. 
  2. Slower deployments of technology:  With additional technology dependencies generated by ERP customizations come the additional planning and testing activities required to deploy new ERP functionality.
  3. Lost opportunity costs:  This is an area that is typically overlooked in customization value analysis.  It is more than just comparing one ERP customization to another but also identifying the potential reduction in flexibility ERP software can provide to the business. 

Summary

ERP is a long-term proposition and requires a long-term business case and value analysis for any change in the ERP’s value proposition.   Too often decisions on ERP customizations are based upon partial information and are made in isolation.   ERP is only one component of a business solution.  Business processes and People have a greater impact on business results. 

Key Drivers for Business Results

Key Drivers for Business Results

Granted, the full impact of a customization decision may not be fully appreciated in the short-term but poor decisions will build into a formidable wave that will keep you from experiencing value from your ERP investment.

 

Viable – Manageable ERP

Several ERP implementations suffer from what I call a “fast-food” mentality of delivering value.  Customers feel that they need to get functionality that addresses both existing needs but also future needs given long implementation cycles.  Business needs and business wants get blurred together during requirements gathering which make it harder to differentiate and validate.  Finally, more analysis and effort is spent trying to fit one more feature or capability into the ERP implementation versus understanding the support requirements after the implementation.  Typically, the result is a solution that causes more problems than it solves because the ERP solution is not sustainable.  In the next sections, we will discuss some principles to prevent your ERP project from delivering an unmanageable solution.

Set REAL Expectations for Executives (i.e. There is no such thing as a “push button” solution)

How many time(s) have you heard an executive say “All I want is a button to push so I can produce what I need!”  That statement is enough to indicate that there is a huge “expectation gap” and no matter what you do it will be a losing battle.  To establish expectations for success I use the following strategy:

Setting Realistic Expecations

Setting Realistic Expectations

The first and most important step is to establish realistic expectations.  This effort will require educating your executives on the organizational effort, potential business value, and possible risks involved in meeting an executive mandate.  Be prepared to articulate in layman’s terms what is you can do and what should not do with technology.  Second, use the language that every executive knows and understands: money!  Quantifying business value, costs, and risks in an executive business case can quickly align executive wishes with business reality.  Third, come to an agreement on expectations.  This agreement should be formalized via a signed project charter.  Finally, there should be boundaries (limits) on the agreed upon expectations.  These limits should be defined within a scope statement with constraints and assumptions.  Next, we need to further define and refine expectations for key business personnel that will enable you to meet executive expectations. 

Set REAL Expectations for Business Users (i.e. theoretically correct vs. practically accurate)

Today’s ERP software has increased the amount of data that business users can capture.  In addition, naturally business users see this as an opportunity to drive more business value.  However, capturing additional data does not automatically equate to additional business value.  Consider the following illustration:

theoretically correct vs. practically accurate

theoretically correct vs. practically accurate

It is important to challenge the assumption that more data creates greater value and better decisions.  In the illustration above what is the level of precision required to get to the right answer?  In the pursuit of driving better decisions we can easily start down the path of creating a data-gathering monster that cannot realistically be maintained.  The result is bad or missing data and the goal of driving better decisions is unattainable. 

Set REAL Expectations for IT (i.e. developing software is not the most valuable thing IT performs)

I’m sure if you ask a majority of IT personnel how they generate business value that software development is right there at the top. However, this value generator is in conflict with a core ERP value proposition.  Organizations purchase packaged software like ERP to minimize internal software development.    Internal IT organizations that support ERP solutions must change their definition of value generation for their customers.  Consider the following illustration: 

ERP Service Categories for ERP

ERP Service Value Chain

As you can see above the highest level of services that IT organizations can provide are advisory services that assist internal customers in how to best leverage technology.  Another key concept that is a huge mind shift for IT organizations is to utilize ERP as the fundamental driver for generating additional value versus utilizing a traditional requirements-driven approach.  Let’s look at the implications of IT organizations do not adapt to take full advantage of their largest software investment (ERP).

Impacts of an Unmanageable Solution (i.e. we are not getting value from ERP)

I don’t know about you but I’m guessing that you are being asked to do more with less.  I have a very small IT staff that is responsible for both ERP support and ERP-driven enhancements/transformations.  The IT staff spends the majority of their time (up to 70%) on ERP support.  Even though ERP support is at the lower end of the ERP value chain the activty is a very high priority.   However, this leaves us with a small level of capacity to support higher services.  A high maintenance ERP solution limits your ability to generate greater perceived value to business users.  Business users usually do not perceive value from ERP support services unless something goes wrong. 

Summary

As the ERP industry continues to mature we are observing the rise of more functionality and capabilities to capture even more data.  However, nothing is free. Additional functionality and data capture requires additional discipline and support requirements from both IT and Business users.   Please do not take an extreme approach and stifle innovation.  Business is all about take risks.  My point is – take calculated risks.

Creating a Flexible and Adaptable ERP Solution

Every customer I assisted in their ERP implementation wanted an ERP solution that would be flexible and adaptable.   One of the key challenges and disappointments customers have with ERP are around flexibility and adaptability.  We also need to address the common misinterpretations associated with the concepts of a flexible and adaptable ERP solution.  Referring back to a previous blog we know that ERP is only one component of a business solution.  There are three key areas to address as part of developing a flexible and adaptable business solution.

Know The Limitations

Technically speaking, there are two key methods to enable packaged software like ERP to be flexible and adaptable:

  1. Programming (addresses flexibility or the ability to change)
  2. Configuration (addresses adaptability or the ability to easily change)

Each of these methods has inherent advantages and challenges associated with them.  Configuration has been a key area of focus for ERP vendors to create greater software adaptability.  Configurations enable less technical, business-oriented users to determine how ERP behaves to specific events and conditions.  Configuration provides the opportunity for cost-effective flexibility to meet the unique business requirements.  However, where there is no option for configuration then programming must be used to enable ERP software the flexibility to meet the unique requirement.

Programming provides an exact prescription to address a specific business event, condition, or activity.  There are programming techniques and add-on utilities that provide some level of technical flexibility (examples: object-oriented programming, services-oriented architecture) but business flexibility is extremely limited at best (unless an ERP vendor can devise a practical means of applying artificial intelligence – fuzzy logic to their software).   There are limitations with the amount of flexibility and adaptability you can create via software.  What is important to remember is that there are other components of a business solution that better suited to address flexibility and adaptability.

Know Your Strengths

Let’s revisit the components of a business solution along with their inherent strengths.

Strengths of Business Solution

Business Solution Strengths

Too often we do not effectively utilize the strengths of the key components of a business solution.  ERP software is good at automating consistent, repeatable activities based upon a prescribed logic (business rules).  ERP software is not a sustainable, cost-effective option for dynamic activities based upon fuzzy logic (business rules).  People are more flexible and adaptable than ERP software.  Please do not take the above statement to an extreme and infer that every customer should conform their business activities to the ERP software.  ERP implementations should include software enhancements to address the unique value-add requirements of a customer.

Flexibility and adaptability only have value within the context of enabling ERP to position itself optimally in supporting key business drivers.   Next, we will discuss the common drivers that must be coordinated as part of addressing flexibility and adaptability.

Finding Balance

Every customer will have unique business drivers that must be managed in a balanced approach.  Given my implementation experience following are what I consider the common business drivers that we might address as part of an ERP implementation

Balancing ERP

A balanced ERP solution

Can we have a flexible and adaptable ERP solution?  I believe that the answer is yes.  Can we have an efficient and effective ERP solution?  Yes.  Can we have a scalable and efficient solution?  Yes, however we can only experience both characteristics to a certain level.  The challenge I observed is when an extreme position is taken in one of these areas.  Like a ball on a flat table once we start tilting the table (taking an extreme position) the ball will roll off the table – – along with your ERP implementation.

Finding balance is an ongoing exercise to find the right level of applying the influence of the specific business driver upon the ERP project.  It is also important to know and understand at what level of influence will business drivers start conflicting with one another.

Summary

Flexibility and adaptability are reasonable expectations for a business solution.  The key challenges in this area tend to be around inaccurate expectations and not effectively utilizing the individual components of a business solution.  What is required is a practical analysis of the strengths, weaknesses, and business drivers to develop a balanced approach for success.  This analysis is not a one-time event but a continuous effort that is triggered when emerging pain is experienced.  Experiencing pain provides the opportunity for rebalancing your ERP solution.

Customers – Insist on an ERP Knowledge Transfer Plan

What Gets Tracked and Measured Gets Done

How do you measure knowledge transfer?  Customers – have you ever received a report or completed checklist that demonstrated the Implementation Partner conducted knowledge transfer?   Knowledge transfer is a process, not just a milestone task on a project plan.  Consider the following illustration to identify the importance of knowledge transfer.

ERP Business Solution

Business Solution Defined

In a previous article I referred to this view and also identified people as the component with the largest impact to a successful business solution.  A key enabler for people being successful is Implementation Partners conducting effective knowledge transfer.  For many ERP implementations, knowledge transfer is a process that is loosely managed which results in the Implementation Partner providing support long after the go-live date. For an area so important it demands that we formalize this process to ensure completeness.

Best Practice: Knowledge Transfer Plan

Simply put, if you want to ensure that an objective is reached then you need a plan.  A knowledge transfer plan first defines the knowledge transfer process and the methods that will be used to conduct knowledge transfer.    Second, it defines all the customer’s roles & responsibilities that are required to support the entire business solution – both from a functional and technical perspective.  Third, the knowledge transfer plan should act as a checklist for each individual role validating that effective knowledge transfer has taken place.    Following is an example of a knowledge transfer plan.

Knowledge Transfer Process for Consultants

Knowledge Transfer Plan

Effective knowledge transfer is more than just training or having a user sit next to a consultant.  It requires a holistic approach in using several methods (training, mentoring, knowledge generation, and interactions) to be successful.  The end result of knowledge transfer is enabling the customer to support their new business solution.  

Implications for Implementation Partners

Knowledge is power!  Knowledge can be money and a key source of competitive advantage for an Implementation Partner.  For an Implementation Partner a key concern is balancing knowledge transfer to ensure customer success versus providing too much knowledge resulting in the customer terminating services early.  It’s important for customers to keep in mind that knowledge sharing happens more freely in a trusted environment.

There are two broad categories of service that an Implementation Partner can provide: staff leadership and staff augmentation.

Broad categories for ERP implementation services

ERP Implementation Service Spectrum

To achieve greater customer enablement Implementation Partners should play more of a staff leadership role during the implementation.  Customers, there is a price associated with effective knowledge transfer.  Also keep in mind that there are greater resource requirements (i.e. knowledge, experience, advisory) for staff leadership services.  Price should not be the only consideration when comparing staff leadership versus staff augmentation services.

Summary

True enablement is based upon customers selecting consulting firms that act as a true partner and not just staff augmentation.  If customers only require staff augmentation then I suggest customers get it as cheap as possible, yet don’t expect any reliable knowledge transfer to occur. If this is the first ERP implementation for the customer then I would recommend that the customer selects an Implementation Partner that not only assist your project team but more importantly train and enable your project team to be successful on your own.  That is what a true partner would do.  To maximize knowledge transfer the customer needs to foster a trusted work environment.  Customers – it’s in your best interest to take the lead in creating this environment.

Embrace Changing Requirements for ERP Implementations

Business is Changing!  Don’t Fight it – Embrace It!

A key challenge with any ERP implementation is changing business requirements.  Yet many project teams are surprised when business requirements change.  Think about it, the scope of an ERP implementation is based upon a “point in time” solution.  Competitive business models are constantly evolving to meet customer demands.  Today, the majority of ERP implementation approaches discourage changing requirements by having laborious scope change control procedures that tends to be more of a roadblock than an enabler.   What is required is a more proactive approach to identify differentiated requirements that can provide a competitive advantage to ERP customers.

What Are Differentiated Requirements?

Differentiated requirements are business requirements that will support a business solution that is uniquely different from another business solution.  They allude to a significant, comparative difference.  Differentiated business requirements are very useful in ERP software selections because they focus on the unique differences between the ERP software packages.   In the context of an ERP implementation differentiated business requirements refer to unique business requirements that are different from company’s peers or competitors.  Consider the following illustration:

How ERPs address business requirements

How ERPs address Business Requirements

Allow me expand on a couple of thoughts:

  • Differentiated requirements are not best practices.  Best practices are common and generally accepted business practices across a specific industry and/or country.  Best practices are generally available in the market and therefore are not competitive (or no longer competitive).
  • Differentiated requirements should focus on competitive business requirements that uniquely position a customer’s offerings in the market.  Practically speaking, a customer should be more concerned about being competitive in revenue-generating business processes (i.e. Order to Cash) rather than revenue-supporting business processes (i.e. Expense Reporting).
  • Competent ERP software is designed to address generally accepted best practices.  ERP software will not address the unique competitive business requirements of an individual customer.

 

Handling Differentiated Business Requirements Late in the Game

Now comes the challenge of handling differentiated business requirements late in the implementation.   If you notice I did not say we should address all requirements.  There are risks associated with addressing business requirements at the end of an implementation cycle.  The question you need to ask is whether the business requirement will create more business value than the implementation risk generated.  There are four steps you can take to address differentiated business requirements:

  • Reduce the possibility for late competitive business requirements by proactively searching for these requirements during earlier stages of the implementation.  This will require a competent understanding of business processes, their key results, and how they can be competitive.
  • Maintain a business solution modeling environment to quickly determine how the differentiated requirement can be addressed.  Business solution modeling will enable simulations on how the three components of a business solution could support the competitive requirement.  The simulation may take several iterations.
Modeling ERP against business scenarios

Business Solution Modeling

  • Plan for this scenario to happen.  Let me restate that the scope for an ERP implementation is based upon a point in time solution.  This scenario should be formally listed as a risk and managed as such.  This scenario is almost a certainty for a revenue-generating business process (ex. Order to Cash) given the external competitive forces at work.
  • Develop a roadmap during the implementation to articulate how new or advanced business requirements will be handled in the future.  Too often a customer may believe that they have only a single opportunity to get both their needs and wants addressed in the ERP software. 

Summary

Just as we expect a customer’s organization to adopt change with an ERP implementation, project teams need to expect and embrace change for differentiated requirements.  The key challenge is identifying which requirements are competitive and strategic.   Too often we narrowly focus on functional areas and not the entire business process.

  

Project team focus during ERP implementations

Silo Functional Focus vs. Business Process Focus

 

This is a challenge that all three key players of an ERP implementation (software providers, implementation partners, customers) must address.   Please do not underestimate this under-appreciated challenge.  It can be a huge mindset change for business owners that focus more on functional optimization rather than strategic customer advantage.  The best strategy for addressing late requirements is to plan for this scenario and have the appropriate iterative processes in place to quickly define, assess, and implement requirements that have competitive value to the customer.

Follow

Get every new post delivered to your Inbox.

Join 4,139 other followers

%d bloggers like this: