ERP Project 101: Challenging ERP Requirements

I am not arrogant enough to believe that ERP software vendors are the guardians of best practices.  Nor do I blindly subscribe to the notion that the customer is always right.  What I do know and believe is that a good implementation partner will balance customer needs and wants with the fundamental value proposition of the ERP software to ensure customers have relevant information to make informed decisions.  The following blog posting will discuss some practical guidance that implementation partners can utilize to vet business requirements.

You must be given permission to challenge customer requirements

Regardless of your previous experience or how smart you think you are in order to be effective as an ERP implementation partner, you must be given permission by the customer to challenge their ERP requirements.  It is rare to receive this permission automatically but rather it must be earned by the implementation partner.  Following are core principles I use to earn that permission:

Vetting ERP Requirements

Earning the Right to Challenge Requirements

 

Knowing ERP functionality is simply not good enough.  A competent implementation partner is able to advise and influence their customers to draw the right conclusions and make informed decisions.  Next we will discuss how a good consultant guides the customer towards making an informed decision.

Lead by asking informed questions

In my early days of ERP consulting, I was taught to ask open-ended questions to prompt the customer to provide as much information as possible.  I agree with this approach as long as the information is value-add and guides the customer down the right path.  Too often I see ERP consultants mindlessly ask the customer 100+ ERP functional questions that focus more on “how” than “what” and “why”.  The following illustration provides key concepts that questions should drive customers to consider: 

Asking the Right Questions

Asking Informed Questions

 

Use questions to educate.  Use questions to persuade.  Questions should lead your customer to challenge assumptions and perceptions in their current environment.  A perceived requirement may be a limitation of the current system or organizational structure.  Just remember that asking the right questions is just the beginning to changing minds.

The best pressure is peer pressure

As a third-party external resource with limited knowledge of the customer’s business model, there are limitations implementation partners will have on generating customer ownership and adoption.  What consultants should do is facilitate and promote a process where relevant information is presented and evaluated.    Do not evaluate business requirements in functional silos but as part of the larger business process across all business stakeholders.  Visibility across the business process creates accountability – especially with peers within the customer’s organization.

Results of Business Requirements

Understanding the Impact of Business Requirements

 

The basic value proposition of ERP systems is providing the automation of best practices – that is common business practices – across a broad market/industry.  A direct contradiction against this key benefit is when a business requirement has to be addressed via a software customization.    Additional scrutiny listed above should be undertaken to validate the additional investment required.

Not challenging business requirements is a disservice to customers

A fundamental expectation that customers have for ERP solutions is to have a flexible and cost-effective business solution.  A key assumption required for cost-effectiveness is that ERP “out of the box” functionality addresses the majority of the customer’s business model.  Customizations have both a short-term and long-term impact on cost effectiveness.   I am not arrogant enough to state that ERP software addresses all the best practices a customer may be utilizing.  However, I have observed too many ERP implementation partners take the easy option of catering to user requests without leading the customer through a critical analysis to determine both the short-term and long-term implications of a specific customization. There are legitimate needs for customizations.  It is not an ERP implementation partner to prevent customizations but rather to ensure that customers have appropriate expectations and conclusions as a result of their implementation decisions.

Summary

In my humble opinion, good ERP implementation partners educate their customers in how to best utilize ERP software to support their business.  This not only requires ERP software knowledge and but more importantly requires the business acumen to understand current requirements and advise on future requirements.  Customers, if you are looking for an implementation partner that can act as a leader then you will have to pay a higher rate versus a staff augmentation partner.   ERP vendors play a very important role during an implementation - especially where it comes to best practices that are not delivered out of the box by the ERP software.  ERP vendors should provide multiple processes and examples of working with customers to influence software roadmaps and/or co-develop automated solutions.  Action speaks louder than words!  True partnership requires an investment from every player.

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.                    

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.  

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.

ERP Application Strategy Roadmap for Maximizing Long-Term ROI

You have just implemented your ERP solution – congratulations!  Now what?  Will your ERP experience become an endless cycle of applying maintenance patches and upgrades?  Many customers only realize a fraction of the business value that ERP can provide.  Too often customers rely on their ERP vendor to provide the long-term vision and strategy for increasing ERP ROI – which is general as best. In the next sections, I would like to speak to you about internally creating the vision and strategy for maximizing your ERP investment over the long-term.  It all starts with having an ERP application strategy roadmap.

What is an ERP Application Strategy Roadmap

The ERP application strategy roadmap documents the application strategy that enables the stated business goals, strategies, and processes to be achieved given the IT goals, governance, and capacity.  Generating and maintaining ERP application strategy roadmaps will ensure alignment between business goals, strategies, and performance targets to the required ERP functionality.  In addition, the application strategy roadmap provides the framework for a shared prioritization mechanism for conflicting business and IT priorities. Consider the following illustration:

ERP Application Strategy Roadmap

ERP Application Strategy Roadmap

Practically speaking, there will always be two different  perspectives for ERP strategy and prioritization.  What is important is that your organization has an ongoing process to align business priorities and IT priorities for your business solution.  Having an ERP application strategy roadmap is a deliverable that will support the alignment process.  In the next section, we will address the activities for creating an ERP application strategy roadmap.

Creating an ERP Application Strategy Roadmap

The following illustration outlines the key activities to perform in creating an ERP application strategy roadmap.

ERP Application Strategy Process

ERP Application Strategy Process

For brevity sake, I would like to focus on two key activities that are typically overlooked during the development ERP application strategies:

  1. Step 2 – Inventory Current State Solution
  2. Step 3 – Define Gaps, Duplication, & Inefficiencies

Once your organization defines the business goals and strategies (Step 1), the next analysis is to determine what components are in place to support the business needs.

Mapping ERP Features to Business Objectives, Goals, and Strategies

Mapping ERP Features to Business Objectives, Goals, and Strategies

In the illustration above you see that the business objectives are supported by a series of business strategies that provides the first level of support for meeting the agreed upon objectives.  Business strategies are further elaborated into the individual business processe(s), people, and ERP capabilities that will support the implementation. Performing this experience is important in order to identify the required interdependencies between the components of a business solution.

Once the above analysis is performed, the next step is to conduct an ERP assessment.  The ERP assessment will provide you with the insight needed to understand how your organization utilizes your ERP system. This analysis will enable you identify opportunities to better align with business objectives and goals.   In additional to finding opportunities your organization should identify gaps and duplicate functionality that should be addressed.  Consider the following:

Highlighting ERP System Gaps and Duplicate Functionality

Identifying ERP System Gaps and Duplications

An important exercise that needs to be performed is to map business requirements to the existing ERP solution(s).  The above illustration is an example of mapping business objectives to the individual systems that would said objectives.  This exercise is very useful for identifying gaps and functionality overlap (Step 3).

The Price of Not Having an ERP Application Strategy Roadmap

Performing a current assessment (Step 2) and identifying opportunities and gaps within the current ERP environment (Step 3) is no small feat of effort.  Many times these activities are perceived as “looking back” and generate no real value of moving forward.  I humbly disagree and say that these activities are vital to enabling customers to move forward with a realistic and achievable strategy.  Without an ERP application strategy customers are “blindly following” the ERP vendor’s application strategy – which may not be in the best interest of a single individual customer.

ERP Return On Investment Analysis

ERP Return On Investment Analysis

It is important to realize that your ERP solution will have incremental costs (red arrows) throughout the ERP life-cycle.  Without an ERP application strategy in place, your organization is taking a gamble that business benefits from ERP will continue to outpace the corresponding operational costs.

Summary

Maximizing your ERP investment is a process – not a milestone.   Not only do you need to understand the ERP functionality implemented but also how that functionality supports business results.   To achieve long-lasting value from ERP you need to have a long-term strategy to incrementally generate additional value because you will generate additional incremental cost over the ERP life-cycle.

Best approach for gathering ERP requirements

How You Gather Requirements Sends a Message!

Let’s us go through an analogy together.  You are the customer and I am the consultant working with you to develop some software changes for your packaged software.  As the consultant I can take two approaches for gathering requirements:

Option #1:  “What would you like?” An open-ended question that will generate a lot of feedback from you the customer.  Yet it communicates several underlying messages:

  • You as the customer will get a turn-key, custom solution.  Software changes require a minimal effort.
  • I as the consultant may not have sufficient knowledge of your business – or not enough to lead with a recommendation.
  • You as the customer know exactly what you want.
  • I as the consultant appear to be more customer-focused.

Option #2:  “Here is the delivered functionality. Please explain why this is not sufficient?” A question that will generate less feedback from you the customer.  Yet it communicates several underlying messages:

  • You as the customer may not get what you want.  Software changes should not be required.
  • I as the consultant may not have sufficient knowledge of your business – especially if I did not know of the gaps beforehand.
  • You as the customer may feel to be put on the defensive and not treated appropriately as the key stakeholder.
  • I as the consultant appear to be less customer-focused.

Both options are valid approaches for gathering ERP requirements.  However, the challenges I see today are due to how project teams apply requirements gathering strategies to their ERP implementations.  Project teams typically confine themselves to only one approach and do not account for the challenges associated with the selected requirements gathering method.

Multiple Methods for Requirements Gathering

Based upon my experience there are three main strategies for gathering ERP business requirements:

Requirements-Driven Strategy

A pure requirements-driven strategy focuses on defining all business requirements independent of organizational and technology constraints.  This approach is the most widely used method today.  This is also the slowest approach to gathering requirements and will require the most time from business users to articulate requirements.  We can anticipate gathering non-value-added business requirements that must be filtered through the requirements section process.  With additional gaps business stakeholders will have to spend more during Fit/Gap to make decisions.

Solution-Driven Strategy

On the other end of the spectrum, a pure solution-driven strategy focuses on the gap business requirements (requirements that cannot be met with delivered functionality).  This approach is highly popular in for rapid ERP implementations.  This approach requires the least amount of time from business users; however, business activities must conform to the packaged business software.  This could have a significant impact on organizational acceptance and impact because ERP software designs are based upon a market-driven set of requirements and not the specific requirements of an individual customer.

Configuration-Driven Strategy

The configuration-driven strategy is based upon the premise “The new system needs to do what the existing system does today”.  It may be a situation where a customer simply needs a replacement system because the existing system is nearing the end of its license and may become decommissioned software.  Starting with what the customer knows helps to expedite requirements gathering.  Business user time is minimized because IT can provide insight into the existing business system capabilities and configuration.    However, this approach will surface requirements based upon existing system limitations as well as legacy non-value-add business requirements.

Each requirements gathering approach has its strengths and challenges.   This fact does not invalidate the approaches described.  What is required is the right application of these methods to encourage – not force – customers to maximize their ERP investment.

Best Practice: Use Multiple Methods for Requirements Gathering

What if there was a way to take the best from all the approaches mentioned above and produce a strategy that took full advantage of ERP software?  What if we could bring in different approaches in such way as to complement and progressively elaborate (iterate) business requirements?   This is the aim of the blended approach – to leverage different techniques in the process where they can generate the most value.  The project team gathers business requirements from different perspectives which enable the team to create a holistic requirements definition set. Finally, the approach will naturally filter out non-value add business requirements.  Let’s review how we would execute on a blended approach for requirements gathering.

Gathering ERP requirements

Gathering Requirements for ERP

Iteration #1 – Listen to your customer

In the first iteration we will utilize the requirements-driven approach to gather high-level requirements.  The difference in applying this approach is the level or degree that we execute in this iteration.  The objective is to gather enough business requirements that will enable the project team to develop a competent system for business solution modeling.  A key concept here is that your customer needs to feel that they are being listened to and engaged, yet not being promised a custom solution.  The project team wants to be able to develop a system that will convincethe customer that the packaged software will support their business.  Focus on gathering the main business scenarios and relevant data that will enable the project team to produce a realistic solution to utilize during business solution modeling.

Iteration #2 – Lead your customer

Here in this iteration the project team transitions from listening to leading with a business solution.  During business solution modeling the project team will demonstrate the ability of the packaged software to support the main business scenarios to your customers.  During business solution modeling the project team also focuses on gathering exceptions to the standard business process scenarios defined.  You will also note that this activity will provide the project team with the opportunity to validate business requirements and software configuration during the requirements gathering process.

Iteration #3 – Negotiate with your customer

This final iteration is a confirmation that all value-add business requirements are defined and all business exceptions and scenarios have been addressed.  Looking at the configuration of your customer’s legacy system(s) not only is another source of validation but also can be the first iteration of defining legacy data migration requirements.

Summary

One of the key techniques the project team can use to detect and resolve business requirements conflict is to gather requirements from different perspectives.

Gathering ERP Requirements from different prespectives

Different Views of Requirements

Driving to define your business requirements from different perspectives will naturally identify potential conflicts.  Starting off with a requirements-driven approach lays the foundation for effective requirements gathering as well as promotes collaboration.  Next, taking a solution-driven approach enables the project team to quickly identify the boundaries of the packaged business software.  Third, utilizing the configuration-driven approach provides a validation of results from both the requirements-driven and solution-driven activities.  And finally taking a results-driven approach ensures that the business results support the desired business results.

Source:  This hybrid approach is further defined in my book Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations.

ERP Makes for an Expensive Custom Solution

The Allure of Technology

Think of the possibilities!  Rapid delivery of new functionality!  Reduce development cost by quickly deploying prebuilt solutions!  If the software does not meet your needs then use the delivered, user-friendly development tools to customize the ERP software.  We have the technology to make your business more flexible and adaptable.  Most customers do think about the possibilities quickly but have a hard time taking that vision and incorporating it into the realities that are involved with using ERP.

The Challenge: Customer Expectations Not Aligning with ERP Strengths

A key area that causes conflicts during an ERP implementation is the misalignment between the customer’s expectation of business software and key ERP value drivers.  Consider the following illustration.

ERP Advantages and Challenges

ERP Advantages and Challenges

 

It is important to understand the customer’s business owner/user expectations of enterprise business software. If customers expect ERP to adapt to current business activities then there is an increase risk of developing a custom solution that cannot support the fundamental value drivers for ERP. When an organization makes the decision to implement ERP they are making the decision (consciously or unconsciously) to realign business processes with delivered ERP functionality. This is a significant mind shift for key business owners and end users! It’s not a “light switch” that you can turn on and customers think differently. There must be an evolutionary process to better align customer expectations with ERP strategy and direction. Let me provide a real life example to further elaborate.

The No Win Situation

I was a functional consultant for an ERP implementation to replace a customer’s legacy time reporting system. The customer’s process consisted of Microsoft Excel spreadsheets coupled together with a data load process to a custom staging table for time approval and payroll processing. When I started working with the customer to define their business requirements it was apparent that there was a difference between executive and business stakeholder expectations. The payroll manager insisted on having the exact functionality that they current have in their systems today. I knew that no matter how good our developers were we would not be able to cost-effectively build Microsoft Excel flexibility into the ERP software. It would totally invalidate the justification for going with an ERP software solution in the first place. The payroll manager was used to getting exactly what they wanted from software to the point where software replaced the need for training (ex. dummy-proofing). I did an initial gap analysis and identified over twenty (20) gaps that required changes to the ERP software.  Addressing the gaps via software would require additional resources (costs) to design, develop, test, and implement software changes.  In addition the customer would have to allocate resources to re-analyze their software changes against new ERP software updates.  These activities will reduce the ability of rapid delivery and increase Total Cost of Ownership (TCO).

I came to the realization that if I proceeded with a traditional approach to gathering requirements that (a) I would spend a lot of wasted effort gathering non-value-add business requirements and (b) the fit/gap session would be much longer than planned, (c) and I was in a non-win situation unless I changed the game. If I provided a custom software solution then I would have a happy payroll manager but I would have disappointed executives because the ERP solution increases costs. On the other hand, if I ruled out customizations and only used delivered functionality then I would get happy executives and an upset payroll manager! The only way I could be successful was to move from a traditional requirements and implementation approach to a new approach that addresses the realities of using ERP.

SEI Evolutionary Process Integrating COTS-based Systems

Source: SEI Evolutionary Process for Integrating COTS-based Systems

 

The approach I took was to reset software expectations. I met with the payroll manager to discuss the reasons for selecting ERP software and the inherent advantages and disadvantages with ERP software. This was not a one-time discussion and required several additional discussions with the entire project team. In the end the payroll manager’s expectations were adapted which enabled us to accelerate our fit/gap session. We still identified a few gaps. Of the three gaps we negotiated to have only one addressed via a software change and the other gap was handled via training. Our negotiations resulted in a significant reduction of effort and were only made possible by establishing the right environment for effective negotiating. If either party has unrealistic expectations then effective negotiations will be extremely difficult.

Summary

The fundamental design of ERP is to provide a common software solution across a broad customer base. ERP is maturing to enable more custom capabilities via configuration, but the fact remains that ERP can make for an expensive custom solution. The marketplace has realized that ERP requires a different implementation approach (ex. Software Engineering Institute’s EPIC methodology). Consider the drivers for purchasing an ERP software package. What was the business justification for purchasing packaged software? Remember that ERP targets customers across multiple geographic locations and industries. Two key implied statements that executives make when they select an ERP software solution are (1) having a custom software solution is not strategic to the organization, and (2) we expect our organization to adapt to the ERP software – specifically non-competitive, non-strategic areas. Strong words I know, however, I have seen a lot of grief and anxiety created during packaged implementations because this message was not clearly articulated to the project team and the organization.

The software vendor, implementation partner (consultants) and the customer’s IT department have the opportunity to play an important advisory role to the business user community by defining the best approach to leverage technology in creating a business solution. This advisory role can be a challenge given the high technology expectations of ERP software; however it is in the best interest to our customers!

Follow

Get every new post delivered to your Inbox.

Join 4,409 other followers

%d bloggers like this: