I think we can all agree that organizational fit is a key consideration for successful ERP selections and implementations. However, mention the phase “fit/gap” or “gap analysis” and most people will fixate on the ERP software. There are several examples of functional/software fit-gap templates/activities but very few organizational fit-gap templates/guides. The goal of this blog is to shed some light on this very important activity.

What is an Organizational Fit/Gap?

An organizational fit/gap analysis is a comparison of the customer’s existing organizational model that supports the business to the defined organizational model supported (or assumed) by the ERP system. Consider the following illustration:

Organizational Fit Gap Analysis

If you do not know what is changing in the organization then how can you manage organizational change? Too often I see ERP projects only focus on the “To Be” model and expect business users to figure out how to transition. I have also observed that customers see organizational change activities as an opportunity to reduce implementation costs by performing the activity themselves – regardless of their capabilities.

In order to effectively conduct an organizational fit/gap analysis there are two key sources of information that are required:

Information Source

Comments

Customer’s Organizational Structure and Business Processes

A majority of peers and customers believe that this exercise is a non-value-add activity given the imminent organizational change that will occur as part of the ERP implementation.

ERP Business Process Maps

Consider ERP business process maps as a demonstration by the ERP vendor to show how their ERP software supports business processes.

Just as you perform a formal Fit/Gap analysis on ERP functionality you should also consider performing a formal organization Fit/Gap analysis as illustrated below:

An organizational fit/gap analysis should be performed during the ERP selection stage and refined during the early design stages of the ERP implementation. Do not limit yourself to performing this exercise only once. The analysis performed during an organizational Fit/Gap will drive future decisions and implementation activities.

What Activities should an Organizational Fit/Gap Influence?

The organization fit/gap analysis will have a direct impact on your organization change management plan and communication plan. In addition, this analysis will provide insight into user security requirements. Utilizing this approach will highlight how well the predefined ERP user security profile(s) align to the organization’s existing users. As a general rule, the majority of predefined ERP workflows are based upon predefined user security roles; therefore keep in mind that ERP user security profile changes may require additional testing for related ERP workflows.

Predefined ERP implementation tools, templates, roles can provide limited value to an implementation. Too often the ERP market wrongly perceives that these predefined components result in faster implementations. This misconception is most pronounced in the ERP SaaS/Cloud arena. At the end of the day, an ERP implementation should only move as fast as the customer can handle the change. Conducting a formal organizational fit/gap can enable the customer to adapt faster by focusing on the specific changes required for success.

Given that we are well in the third decade of ERP implementations, I still observe ERP implementations following outdated/misguided concepts that do not utilize limited resources to the fullest. One of these misapplied concepts is Just-In-Time (JIT) training. End user enablement continues to be an implementation challenge primarily due to the limited investment made for the most important component of an ERP business solution. This limitation must be addressed in order to realize the value of ERP in the Cloud.

Evolving Traditional ERP Testing for Cloud ERP

Consider the following illustration that highlights the tradition user involvement model:

Traditional User Involvement

Traditional ERP implementation approaches view end users as an audience versus an active participant to leverage during the entire implementation. End users by far make up the largest stakeholder group in an ERP implementation however; they have the least amount of involvement and responsibility. Let’s further contrast and identify opportunities where end-user involvement can have a positive influence on ERP implementations.

The majority of testing and hands-on experience occurs with a limited group of users leaving a small window for direct users to gain confidence and experience with the ERP system.

The limitation with direct user involvement is based on the premise that a working system is not available until the end of the implementation. This is not the case with a Cloud ERP system that can be provisioned early during the implementation life cycle.

JIT End User training is a big bang approach – one time shot to get end-user training right. It also gives end users limited time to internalize the change. This approach naturally requires additional support and creates a greater potential for user errors.

Waterfall is based upon software being developed from scratch – i.e. you could not actively involved end users until the software existed. When ERP came to the market many approach/processes designed for software development were incorrectly applied to ERP implementations. The next section we will discuss how to involve the target audience sooner during a Cloud ERP implementation.

Increasing End User Involvement

There are two key value propositions for increasing end-user involvement:

Additional validation of the solution via testing.

Greater user adoption and enablement.

For robust testing business users should first be trained on the ERP Cloud service. Remember that testing can be “hands-on” learning for business users. Consider the following illustration:

Incremental User Involvement with ERP Implementations

Let’s expand on some key themes. First, education/learning is an iterative process where new information needs to be assimilated by users before knowledge is created. Second, an educated user is a better contributor to the project. Third, it is easier to manage and support educated end users. A forward-thinking end-user enablement process drives greater participation and ownership.

Consequences of Not Evolving your User Enablement Approach

As ERP Cloud adoption continues we will see an increase in the following implementation drivers:

Market Drivers for ERP Cloud Implementations

Consider that traditional ERP implementation approaches do not effectively leverage the largest resource pool available. I can appreciate that with additional resources comes greater coordination and communication channels (N * (N-1) / 2) yet I have witnessed that the business value outweighs the associated project risk. With the above said I do not recommend we start involving end users without some level of enablement and guidance. Just as an individual user learns a new system over time the end-user training approach should incrementally prepare the user for greater involvement during the ERP Cloud implementation.

Following are key consequences if we continue with a JIT user involvement strategy:

Potential issues/risks from take a JIT user enablement approach

The JIT approach is being used to squeeze pennies out of an ERP Cloud implementation when the potential risk that results is far greater and eventually must be solved through additional dollars or lost opportunities.

Challenge to Cloud ERP Service Providers and Implementation Partners

Cloud ERP Service Providers and Implementation Partners should take the lead in promoting and supporting end-user involvement earlier during the implementation. Unfortunately, Cloud ERP Service Providers are not providing a robust set of tools and services for incremental user enablement. Test cases should be business process focused and not just business function oriented.

Implementation Partners must also adapt to this new paradigm. It is unfortunate that many implementation partners choose to address ERP Cloud Implementation drivers (mostly cost) by reducing project leadership and transferring user enablement to the customer – regardless if the customer have the required tools/competencies for incremental user involvement. This short-sighted approach ultimately leads to an unfavorable customer experience with Cloud ERP.

Summary

Just in Time (JIT) is an operations management approach for improving ROI by minimizing inventory and related carrying cost for a production process. JIT is a viable strategy given that the process is production quality and all input variables are within controlled tolerances. Implementing a Cloud ERP solution is not a production quality process nor are all input variables can be controlled. This concept has been applied to ERP end-user training with the intent of maximizing training investment. JIT training reduces the need for refresher training due to ERP knowledge loss experienced if training precedes the go-live event over a long period of time. JIT training may be a valid approach for end users after the ERP Cloud service is in Production but it is a limited strategy to employ during an ERP implementation. Make the end-user an active partner not a passive customer.

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:

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 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.

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.

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.

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 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

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

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:

Create quick wins. Triage is required to stop the bleeding. You need to quickly seize the initiative and create positive events.

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.

Triage is not the time for lessons learned. There will be opportunity for reflection after the immediate problem(s) have been addressed.

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.

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.

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:

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.

How many ERP SaaS offerings are in the market today? The number depends on who you ask but it is a fair statement to say that all Tier I and the majority of Tier II ERP vendors have a SaaS offering. A majority of the market and many ERP analysts still take an on-premise approach to evaluating ERP SaaS offerings. Services, not software, will have the greatest impact on ERP SaaS success. The purpose of this article is to examine the impact services will have in a SaaS model.

Installation Is Not an Implementation

Ah, the battle cry of ERP SaaS “You can be up and running in a matter of minutes!” Now, it is a fair statement you will have a running system but it is a far cry from a configured business solution. Consider the key activities required for this transformation:

SaaS Technical Services

Even though ERP software and infrastructure can be provided in an accelerated fashion, the business value realization of an ERP SaaS model can only be achieved through the effective delivery of technology services. SaaS ERP is not a push-button solution. I submit that technology services should have an equal or greater emphasis on ERP SaaS selection than ERP SaaS software.

Great Services Can Cover a Multitude of Software Gaps

ERP SaaS software installation is a very small step in ERP SaaS experience. Consider the following illustration:

ERP SaaS Lifecycle

Following are a few points I would like to elaborate. First, installed ERP software does not provide any business value own its own. Business value is only realized when software is configured and implemented in a production environment. Second, let’s not forget that an ERP SaaS model is outsourcing technical services to the ERP vendor. Third, ERP SaaS software release cycles will be at least three times faster than traditional on-premise ERP software. That means that a SaaS software model will address gaps in a shorter term. As more customers look at SaaS ERP I believe that services not software will be the emerging competitive differentiator.

Majority of ERP SaaS Offerings are Non-Competitive Differentiators

For purposes of this discussion please allow me to broadly categorize business processes into three areas:

ERP supporting key business process groups

There are some key concepts that should factor in the ERP SaaS selection process. First, competitive advantage only comes from revenue-generating business processes. For example, would having the best of breed solution for SOX compliance enable you to gain market share? Also consider if you would highlight your Payroll system as a competitive advantage to your customers. A best practice is not a competitive practice. Organizations, just like individuals, cannot be the best in everything but it makes sense to be the best in your revenue generating activities. A best-of-breed SaaS solution is of little value if the ERP SaaS provider does not provide competent technical services for reliable integration across multiple environments.

Summary

Too often we focus on the cart before the horse. I believe that we are experiencing this misalignment with the emerging ERP SaaS market. The best ERP software is of little value if you cannot implement a viable, manageable solution. Technical services provided by the ERP vendor’s SaaS operations will have the greatest, long-term impact for business success. Pick an ERP vendor that will focus on improving both their ERP software and SaaS technical services.

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:

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.

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 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.

SaaS ERP is the latest effort in the ERP industry to provide a rapid, cost-effective solution for customers who want an enterprise solution. A SaaS deployment model does provide the potential for greater value realization; however, the value proposition is dependent upon appropriate expectations and implementation approach. The purpose of the following article is to provide insight to ensure customers make realistic and informed decisions.

General Expectations for SaaS ERP

I firmly believe that one of the key reasons for failed ERP implementations is that expectations were not correctly established and managed throughout the implementation. Consider the following:

Common Expectations of SaaS ERP

Cheap: The customer does not need to make a huge expenditure to implement and utilize.

Fast: Answer a few questions and have an up and running software in weeks.

Flexible: Business users can make changes. Minimize IT involvement.

Intuitive: Quick to learn and easy to navigate.

We can all agree that the above targets are worthy goals of any ERP solution. However, this is only part of the story. The next section discusses the efforts required to achieve the goals listed.

Desired Results of SaaS ERP

To better understand ERP SaaS expectations we need to elaborate on the desired results that should be realized by customers.

Elaborating on SaaS ERP Expectations

Some of the desired results are directly addressed by the SaaS model but the majority of results are addressed either by (a) the ERP software architecture or (b) the delivery model. Example: SaaS ERP does not require an initial outlay of funding for capital expenditures for hardware and related infrastructure. SaaS ERP eliminates the need for a separate effort for ERP software installation and certification. Yet, it is important to remember that ERP software installation represents at most 5% of the total time required to implement an ERP solution. Therefore the SaaS model by itself does not have a dramatic impact on accelerating ERP implementations.

SaaS ERP Realities

Allow me to share some observations I have regarding the ERP SaaS model that may not appear to be readily evident:

Let’s take one of the above desired results to elaborate on the above diagram. A goal for SaaS ERP is to reduce the Total Cost of Ownership (TCO). One of the key ERP design strategies is to enable business users to tailor the functionality to meet requirements without having IT to make a costly customization. However, it is important to understand the shift of effort from IT to functional users. There may be a reduction in the effort or a change in the nature of the work but the effort is still required. There is no “push button” to eliminate this work.

For another example let’s take the ERP value stream. ERP vendors can create additional value to customers by providing new and enhanced functionality. The leading SaaS ERP delivery model should provide a 3:1 ratio increase in the software release cycle. Yet, it is important to realize that more frequent ERP software releases require additional testing and deployment (organizational change) work. It is interesting to note that many of the leading SaaS ERP vendors do provide an out-of-the-box testing automation solution. Again, the customer will experience a shift from technical to functional effort.

Summary

Sorry if I burst your bubble, but I rather have an informed customer that will have reasonable expectations versus a customer with unrealistic expectations. SaaS ERP is one of many delivery models that ERP vendors offer to customers. While it is true that SaaS ERP provide customers with new options not available previously, it is not a slam dunk for all customers. Developing the customer’s use case and understanding all technical and organizational impacts will better ensure an informed decision is reached.