Dr. Jack G. Nestell and I discuss some key influences on ERP organizational change success including the definition of success, ERP success rates, critical keys to project management, ERP expectations, the role of corporate culture, common challenges and pitfalls, Learning and Development (L&D), ERP organizational change conflict, Leadership styles, critical success factors and more!
Suppose you are leading a kickoff meeting for an organization that is just starting an ERP implementation. How would you describe for them “success” in terms of an ERP organizational change?
Why do you think many ERP projects fail to deliver on expectations? There have obviously been countless papers written highlighting all sorts of reasons for ERP failure.
What about training and learning & development (L&D) in the organization? To what extent do you suggest and encourage opportunities for training and learning? Before implementation? During? Post?
What leadership styles, or attributes, would you say were most prevalent during the best of your ERP implementation experiences?
You stated in a LinkedIn post that “An ERP project manager is a necessary evil. An ERP project leader is an influencer and success generator.”. Tell our listeners more.
“I have a go-live coming up soon and the customer executive asked me how I felt about our readiness for go-live. I said “Technically, I am not concerned. Functionally, I’m a little concerned and emotionally I am “$%#****!””. 7 functions (modules) across 13 countries. God help me for being an empathic project manager.”
If you were going to give advice to an organization preparing for an ERP implementation what little golden nugget would you like to leave our listeners?
The latest ERP cloud marketing trend is telling value stories and creating a value hypothesis. Everyone likes a good story and creating a value hypothesis sounds more like a “scientific/evidence based” approach. However, new labels do not automatically improve the ERP sales & selection process.
Consider the definition of a hypothesis within the context of the scientific method.
“a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.”
Given that an ERP value hypothesis is based upon limited information, it is important to know the level of accuracy and assumptions made to derive the ERP vendor’s value assessment.
The key question you need to ask is “Is the ERP value hypothesis based on reasonable/realistic evidence and assumptions?” Consider the following:
Are there any project assumptions that are problematic?
In the sales cycle, there is an “information gap” between the vendor and the customer which can only be addressed during the implementation. A best practice is to have the ERP vendor generate multiple value estimates based on multiple scenarios (best case, most likely, worst case).
Validate your expectations with the ERP vendor by providing specific value statements. Collaborate with the ERP vendor to determine the corresponding KPIs for the agreed upon value statements.
Do not have unrealistic expectations. For example, reducing headcount by combining and standardizing business activities is more of a function of a shared service model and not the ERP service.
Value stories and value hypothesis are the latest marketing trend that ERP vendors are using to persuade customers. These tactics are not inherently wrong, however the customer needs to use the same discipline in selecting the right ERP vendor. With an ERP cloud service, repeatability can not be assumed as given with the additional updates applied by the ERP vendor. Remember that transitioning to ERP cloud results in outsourcing your ERP IT services to the lowest bidder. Quantifying how well the ERP cloud vendor supports their customers is an important consideration which have a direct impact on realized business value.
When asked, just about every ERP vendor will say they provide Key Performance Indicator (KPI) reporting. Yet there still remains confusion between metrics reporting and KPI reporting. Unfortunately, using terms like KPI and metrics interchangeably does not help. In the following blog cast and posting I will provide practical guidance regarding KPIs and the role ERP play in supporting KPI management.
Let’s expand upon the above blog cast. Another method to identify KPIs is to take a bottom-up approach. Consider the following illustration:
In this scenario, we have a defined scope (i.e. business process) where we desire to improve business process performance from a Capability Maturity Level Integrated (CMMI) level 3 to level 4. Allow me to simply summarize the key characteristic of CMMI levels 3 and 4:
Level 3: The specific business process has “best practices (i.e. common) deployed.
Level 4: The management of the business process is data-driven. Decisions are based on facts.
First, KPIs should be our focus at the end of the performance gap requirements analysis. The first area should be understanding the organizational change required to mature to a CMMI Level 4. Becoming a data-driven organization does not happen at a “flip of a switch”. ERP users and business leaders must trust the ERP solution and building that trust requires time and ERP reliability.
Second, request the ERP vendor to provide the ERP feature set (i.e. features, reports) that will enable our business process to mature from a CMMI Level 3 to Level 4. If the ERP vendor cannot provide us with this information then I would question how “invested” is the ERP vendor in assisting us in being successful. There is a vast difference between an ERP vendor and an ERP partner. A true ERP partner should be able to easily provide this information (sorry for the tough love).
Third, identify all the relevant operational metrics that we can leverage in monitoring business process performance. Again, the ERP vendor should be able to provide the metrics and Out-Of-The-Box (OOTB) reporting.
Finally, identify the subset of operational metrics that we will actively manage as KPIs. Practical guidance I give to my customers is that you should have no more than 3 KPIs per business process. KPIs are metrics that we actively manage. KPIs should ONLY be forward looking, in my humble opinion. Now please do not misunderstand me that I suggest we disregard lagging and trending indicators. I typically use a car analogy with my customers regarding KPIs and lagging metrics. My dashboard window represents my KPIs. KPIs are forward looking. KPIs should be tied to an incentive compensation plan. KPIs should be a stretch goal and not “status quo” maintenance. Just with the rear-view mirror and side mirrors in a car, operational metrics are artifacts we need to view on an “exception” basis. It is important that we have an ERP solution that can establish an acceptable range for operational metrics and provide OOTB reporting on performance exceptions. This is a reasonable expectation of any competent ERP vendor.
Key Capabilities ERP can provide to identify KPI performance gaps
Recall the question I asked in the blog cast “What if ERP could automatically identify the gaps?”. Having done this activity using traditional methods (i.e. manual), following is what I would consider as the foundational requirements that will enable ERP to provide a preliminary KPI gap assessment:
This is by no means a comprehensive list but it does highlight some of the “critical path” requirements that we can use to evaluate how committed are ERP vendors to customers’ operational success.
I download an app on my iPhone called “36,000 KPIs”.
Now, the appropriate name should be “36K Metrics” but I digress. It is a neat little (free) application that provide a definition of the metric. I cannot speak to the complete accuracy but it is a good reference that I have utilized as a metrics dictionary. The point to make here is that competent ERP solutions must provide a comprehensive set of operational metrics that can be utilized for exception and KPI reporting. Without metrics, one will have a hard time defining performance baselines. The greater the OOTB ERP metrics provided to your business, the more flexibility one has in business process management and strategies.
How much does it cost to create a customer-specific ERP roadmap? $50k, $200k, $1m+? This effort typically requires the higher end consultative guidance and advisory role(s). It also requires a significant amount of customer leaders’ effort/time to support this activity. What if I can show you an approach where one can automatically generate a custom ERP roadmap? If interested then allow me to elaborate.
Are you a Believer?
Before we start, I will ask you to make an investment. I have a habit of repeating myself therefore I will ask you to review the following blog postings before I begin:
Now, if you are still interested then I will ask you to stretch a little further.
Model versus Reality
I consider myself more of a pragmatist than a theorist. Models are great to elaborate upon concept(s) for discussion and argument. However, conceptual models are limited in the value they provide to customers if there is no method to align reality (i.e., “as is”) with the optimal path. Consider the following illustration:
Key Points and Observations:
In a majority of cases, there is a difference between potential ERP utilization and actual ERP utilization experienced by customers.
In order to promote repeatability, there should be a logical progression that enables customers to maximize ERP utilization (i.e., roadmap).
To minimize ERP Total Cost of Ownership (TCO) and eliminate cost constraints, ERP cloud vendors should provide customers with the ability to increase ERP utilization without heavy reliance on consulting services ($$).
The goal is to define an ERP utilization approach that is repeatable and reliable. Far too often, customers spend thousands of dollars on a “point in time” ERP strategy that requires additional funds to revise the strategy as technology changes. The ERP utilization strategy must start with “where the customer is at” and provide a series of ERP features and prerequisite enablement activities in order to increase utilization.
ERP Utilization Roadmap Model
Based on my experience, I recommend that long-term ERP utilization should be a series of incremental quick-wins (i.e., Business Process Management) and minimal paradigm shifts (i.e., Business Process Re-engineering). Consider the following illustration:
Key points and observations:
Any deployment of ERP features that require a significant organization change is not a quick win. People do not change overnight.
An incremental approach like Business Process Management (BPM) is required when deploying new ERP features at the same CMMI level for a given business process.
Set A includes the BPM enablement activities and ERP feature deployments required to align with the logical maturity path. Note that only incremental change is required to implement targeted ERP features (thus, a quick-win).
Set B includes the Business Process Re-engineering (BPR) enablement activities and ERP feature(s) deployment required to align with the logical maturity path. Set Y is not a quick win.
The practical aspects of this model are (1) the roadmap must start where the customer is at in their business process maturity, (2) utilize an increment (agile) approach to build organization momentum, and (3) realize that organizational momentum will carry a customer through the radical changes required for maximizing ERP utilization.
Automating Implementation Guidance & ERP Roadmap
I will utilize the following illustration to put the previous concepts into view.
There are 3 key automation players in the mix.
ERP Configuration Manager: This is a feature of the ERP software that provides an ordered list of data and functional configurations required to implement a feature set within the ERP solution (aka table loading sequence). A competent ERP vendor should provide this capability out of the box. Unfortunately, most ERP vendors only provide ERP configuration manager functionality that only provides the “technical” guidance for configuration.
Implementation Advisor: The implementation advisor compliments the existing ERP configuration manager by providing functional and organizational guidance to the customer during the implementation. The guidance is harvested utilizing AI/ML recommendations based upon findings and trends identified across the ERP vendor’s customer base. The implementation advisor would utilize both structured and unstructured learning to provide the most relevant guidance.
Solution Advisor: The solution advisor focuses on providing the iterative and progressive ERP product feature set(s) required to attain the targeted CMMI level for a business process. The solution advisor must have access to current ERP features implemented but also how effectively business users are utilizing ERP features.
The key strategy of the ERP Utilization model and the solution advisor is to provide an incremental, progressive maturity path that is risk adverse and minimizes huge organizational change.
What’s Missing? Challenge to ERP Vendors
As stated earlier, the majority of ERP vendors provide business process models that highlight how ERP vendors define business processes within their software. The gaps I’ve observed with most ERP business models are there are no relationships defined between the business activity and the corresponding CMMI maturity level and ERP product feature(s). Adding this metadata to the model will enable an automated approach to implementation and roadmap guidance.
Implementation costs remain the largest part of an ERP TCO analysis. The cloud delivery model has greatly reduced the hardware/software/infrastructure costs. Unfortunately, the ERP market places more focus on vendor capabilities and emerging technologies versus ease of implementation and customer self-sufficiency with ERP services. No technology adds any business value until its in production. Second, an automated ERP solution advisor provides real-time guidance to customers versus periodic, manual feedback that generally results in “leap-frog” implementations that have greater risk(s) and cost(s). Stay safe!
P.S. – Despite my sincere attempt, I did repeat myself.
Join the community! 10k followers across 100 countries!
a Cloud ERP solution does not guarantee business value, regardless of the Cloud
ERP provider (vendor). There are
countless examples of customers that have not experienced the expected business
value articulated in the sales cycle.
Why is this?
Cloud ERP software could not deliver on the business benefits promised.
Customers could not adapt to the delivered public Cloud ERP delivery model.
System Implementation (SI) partner could not implement Cloud ERP correctly or SI partner could not enable the customer to support their Cloud ERP solution.
when things go wrong every stakeholder will point the finger at each
other. As each stakeholder has a share
in the success of a Cloud ERP implementation, so is there a share of
responsibility in the failure of realizing business value from a Cloud ERP
A common theme I’ve observed in my ERP implementation experience is the lack of defining business value goals to be managed during the ERP implementation cycle. The majority of time, business value goals are assumed as a “natural” result from the project. Many consider business value an area that is managed after the initial implementation. The inherent flaw in this approach is that the cost to manage business value is greater when the Cloud ERP solution is live. This statement is a corollary to the rule that fixing bugs in design is 15x less than the cost of fixing bugs in production.
For example, let’s say you want to consolidate individual functions into a shared service model to leverage economies of scale and promote greater process efficiency (business value). However, this transition is not easy given that the implemented enterprise configuration only considered a “point-in-time” structure. Addressing the functional configuration limitation in production requires greater effort/discipline in a public Cloud ERP model versus an on-premise model (no more direct SQL updates in a public Cloud production environment).
I recommend that business value is front and center throughout the implementation and that business value is the ultimate indicator of Cloud ERP implementation success. Unfortunately, the majority of Cloud ERP implementation methodologies are based on “traditional” approaches of on-time, on-budget and in-scope.
What is Business
you know how many definitions there are for business value realization? The number is far more than I can count! I pride myself at being a pragmatist versus a
theorist. Therefore, the definition must
support a repeatable and realistic process given the reality of resource
constraints. I am not arrogant enough to
say that I have it all figured out, but the following is my working theory as I
interact with ERP customers:
value realization is the observed evidence that the customer
experiences either as a positive or a negative impact on business process
execution. Consider the following
Business value is in the eye of the customer. I humbly believe that the vendor and the SI Partner are responsible in assisting the customer to see the business value created. Simple cost reduction does not equate to business value.
From the customer perspective, business value unnoticed is business value unrealized. Education is a key requirement in business value realization.
Without a baseline, how can one quantify the business value realized? As the Cloud ERP market continues to become more competitive, realized business value will become a competitive differentiation for Cloud ERP vendors.
Now that we have defined the problem, let’s spend some time discussing how to best address business value realization during the implementation.
Business Value Realization
Framework during the ERP Implementation
I have done an exhausted search of business value realization frameworks. The majority of the frameworks do not address the implementation phase of an ERP solution. I contend that these approaches should be updated given the apparent level of dependencies that business process execution has with technology today’s environment. I’ve only found one framework that addressed business value realization during the implementation.
This is a great framework from an IT perspective from the academic world. I would recommend the above framework to any IT leader looking to create more of an advisory service versus being a traditional service provider (IT should move up the value chain). In general, I agree with the Lean Six Sigma approach to focus first on process efficiency then process effectiveness for most revenue-supporting and compliance processes. However, for revenue generating processes, it may be best to focus on process effectiveness first to create market share/disruptance before focusing on process efficiency.
Now, allow me to provide a more detailed framework for business value realization during an ERP implementation.
Performance metrics including KPIs are the definitive “evidence” that the ERP implementation added business value. Therefore, it is very important that you take a baseline or “snapshot” of your business KPIs before and after the ERP implementation to measure the business value. My recommendation is to capture the baseline business KPIs during the sales cycle. Hint: Leverage the ERP vendor to assist you in defining the specific business value you will experience with the purchase of their ERP software.
As you progress thru the Cloud ERP implementation, broad vision and objective(s) becomes specific siloed tasks. It is important that you reassess your project progress to the agreed upon vision and objective(s). An iterative approach is best to ensure that you have to opportunity to perform course corrections during the implementations versus more costly corrections after the implementation.
Capturing the post KPIs should be done after stabilization. The duration of the stabilization phase depends on several factors that I addressed in a previous blog. Once you have captured the performance metrics and KPIs, you should be able to provide an accurate picture of success and improvement gaps.
Going live is only the beginning to business value realization. Second, traditional ERP implementation project metrics (On-time, In-Scope, and On-budget) only have an indirect relationship on business value. Generating business value is the primary objective of an ERP implementation, not just moving to the cloud or replacing an outdated system. Business value must be an iterative and recurring theme in your Cloud ERP implementation approach.
Business value must be a continuous focus for all key stakeholders. Failure to do so will result in a longer period to business value realization.
Join the community! 10k followers across 100 countries!
Transitioning from an on-premise ERP system to a new cloud ERP service will result in a short-term reduction in ERP user efficiency. This is less of a theoretical discussion but a practical reality that we need to manage. There is never enough hands-on training or testing because we live in a reality of resource constraints. Moving to an ERP cloud service model is a business risk and no ERP cloud service provider will ever eliminate that risk! The purpose of this blog is to provide recommendations to minimize the business risks associated with your transition to the cloud.
I would like to define stabilization (i.e. “shake out”) with the following illustration:
Stabilization is the period of time required for ERP users to acquire the same level of efficiency in supporting business transactions. It is more than just having the new cloud ERP service support the existing business transactions but also that the user can process the business transactions with at least the same level of efficiency and reliability.
In general, following are some of the key factors that
directly influence the stabilization duration:
End User Training.
Any competent Systems Implementation (SI) Partner must realize
and plan for stabilization activities.
In the next section, we will briefly discuss how to manage this
How to Minimize the Stabilization
I’ve been fortunate to have been involved in over 100+ on-premise ERP customer transitions to an ERP Cloud service. I have also reviewed twice as many SI Partners’ implementation approaches to opine on their approach. Based on this hands-on experience, I have summarized the following recommendations:
Recommendation #1: Increase User Involvement
Hands-on experience is the best trainer. A single week for user involvement is simply not enough time to ensure the same level of ERP user efficiency. Users should be involved in prototyping activities before User Acceptance Testing (UAT). Just In Time training is just plain wrong for cloud ERP.
“Although consultants may participate in testing to some extent, employees should drive the majority of testing. Doing so maximizes knowledge transfer and readies them for real life under the new system.” Why New Systems Fail. Phil Simon.
Recommendation #2: Comprehensive Testing
To reduce testing resources and time
commitments, some ERP cloud implementations may reduce testing scope to only
focus on business activities that will occur in the first week of go-live (bad
I recommend that key business milestones (ex.
month-end, quarter-end processing) are part of the implementation testing
Recommendation #3: High Volume/Frequency (Load) testing
Loading testing is the most accurate method to
determine if the new cloud ERP model can handle the daily activities required
to support the customer’s business. If
the cloud ERP provider is truly invested in the customer’s success, then this
service should be a standard offering and not an additional cost.
Test scenario priority should be based upon two
factors: (a) frequency and (b) business impact.
This recommendation is based upon the fact that there is typically no
appetite to conduct a complete parallel financials test with the current
production ERP environment.
Recommendation #4: Accelerate Root Cause Analysis
A cloud ERP go-live best practice is to have a dedicated help desk to support. The main purpose of the help desk is to perform a high level assessment of the root cause of the user issue (3 broad categories):
Cloud ERP service-related.
One of the unforeseen challenges with an ERP cloud service is that there are more complexities (dependencies) with identifying root cause.
The first step to issue resolution is to identify the primary area that is causing the problem. Without this initial assessment, additional cycles will be spent to identify the root cause. Following are key tools and resources that cloud ERP projects must have available for rapid root cause analysis:
Copy of Production environment: A copy of the production ERP Cloud environment to replicate and perform additional analysis on issues. This copy environment should be updated from the customer’s production environment at least on a quarterly basis.
Diagnostic and Logging Tools: Customers should have access and hands-on experience with the vendor’s ERP Cloud diagnostic and logging tools. Granted that the majority of the ERP Cloud diagnostic and logging tools are executed by the ERP Cloud service provider, there is a subset of client-level tools that is also required for root cause analysis.
Customer Specific Extensions & Configurations: In order to keep ERP Cloud services cost low, Cloud ERP providers will employ a shared support model where support resources are allocated to multiple customers. The conclusion here is that customers may have to work with ERP Cloud provider support personnel that only have a cursory understanding of their unique configurations and extensions. Therefore, it is in the best interest of customers to develop a high-level customer profile that highlights the key configurations, transactions, and extensions deployed by the customer.
Do not assume that every cloud ERP providers’ support personnel
have this detailed level of understanding.
Without this summary information, support personnel will ask additional
questions which will increase the issue resolution time. A best practice is to provide this
profile information every time a critical support ticket is created with the
ERP service provider.
Recommendation #5: Continue to engage the SI Partner until the end of the stabilization period
Having access to a competent SI Partner is strategic for customer enablement during the go-live event and transition period. Consulting resources can be available to augment the customer’s help desk resources, address user training gaps, assist with issue resolution and complete knowledge transfer.
Recommendation #6: Dedicated Go-Live ERP service provide support
Cloud ERP service providers should provide an
additional level of support during the go-live event thru the stabilization
Cloud ERP service providers should provide a dedicated
support team versus utilizing a shared pool of support resources during
this critical transition.
Customers should validate what “24 x 7” support
means. Do not assume that same cloud ERP
support resources will continually work on your product issue(s). “24 x 7” support may also require that the
customer’s users have to be available “24 x 7” to collaborate with cloud ERP support.
Recommendation #7: Go live during Business Down Time
By timing cutover during slow business periods,
a company can use slack time to iron out systems kinks. It also gives
employees more time to learn the new business processes and systems.
Recommendation #8: Over Estimate Production Sizing
Capacity planning is an estimate. How dynamic is the sizing of the customer’s production
environment? Is this real-time or batch?
(i.e. if the customer has to create a service request for resizing then the resizing
service is not real-time). If batch then
the best practice is to oversize at least 125% of recommended sizing. This will ensure that you have extra capacity
to spare to complete your first accounting close.
Warning Signs for
The stabilization phase has a huge impact on user experience
throughout the entire cloud ERP service lifecycle. It is self-evident that we have one chance
to make a first impression. While it is
possible to recover from a bad experience, it will take double the effort to
recover. Given this potential impact, I
will provide some “rules of thumb” that customers can leverage to highlight
concerns during stabilization.
The above flags may be categorized as tactical challenges or “shake down” issues after the go-live event but do not underestimate the impact to the user experience. Please remember that users will have the greatest impact on cloud ERP utilization. If the above are not addressed in an aggressive manner, then the following utilization path will become more probable:
The longer the stabilization phase the less trust is created
between the ERP cloud service provider and the customer. As trust declines so will ERP cloud service
adoption and utilization decline.
I’m a firm believer that the cloud model can bring out the best of ERP. However, there is no guarantee that the above will happen. It requires a cloud ERP service provider and SI Partner that proactively address the challenges as part of the transition process. Stabilization is a key phase as part of this cloud journey.
In my humble opinion, the stabilization phase not only is a technical assessment of the ERP cloud service availability and reliability; it must also include an assessment of the usability of the ERP cloud service to efficiently process business transitions.
Join the community! 10k followers across 100 countries!
Not sure if I’m wiser but as part of my knowledge sharing efforts, I would like to share 200+ quotes from over 50 books/resources that have influenced/guided my ERP journey. Nothing beats “hands-on” experience but trust you may find some value. These quotes are grouped into the following areas:
Join the community! 10k followers across 100 countries!
“For any organization there are just a few key processes that handle the core business. All the other processes support the key processes on a certain aspect.” ERP: Tools, Techniques, and Applications, Carol Ptak, Eli Schragenheim.
“To maximize a revenue-supporting process is illogical as it will take effort away from revenue-generating business processes.” Bill Curtis.
“Not all process-integration problems are technical and not all about IT. Integrating computer systems is not the same as integrating the business.” Business Process Management – the Third wave, Howard Smith and Peter Fingar.
“Adaptive approaches are good when your requirements are uncertain or volatile.” Agile Project Management, Agile Software Development.
“A common mistake is to design and configure the system for only the first site and worry about the others later.” Control Your ERP Destiny, Steven Scott Phillips.
“The cost of complexity isn’t offset by what you can charge. Complexity creates opportunities for you to fail your customer.” Gerand Arpey – President of American Airlines.
“Customers tend to interpret requirements broadly, and developers tend to interpret them narrowly.”, Rapid Development, Steve McConnell.
“The ability to trace requirements flow from their source (originator), through the various project phases (design, prototyping, customizations, testing, piloting, and delivery) is a requirements generation best practice.” Directing the ERP Implementation, Michael Pelphrey.
“When managers of a company select an ERP package to implement, they are “buying into” the ERP vendor’s view of a certain industry’s best practices and relying on the system to support their efforts to embrace these practices.” Modern ERP. Marianne Bradford.
“Paralysis through analysis” is a futile attempt to develop the perfect solution. Control Your ERP Destiny. Steven Scott Phillips.
“Iterations systematically reduce the trade space, grow the knowledge of the solution, and increase stakeholder buy-in. At the same time, each iteration, or spiral, is planned to mitigate specific risks in the project.” Evolutionary Process for Integrating COTS-Based Systems (EPIC), Carnegie Mellon – Software Engineering Institute.
“Requirements creep must first be differentiated from requirements evolution (elaboration).” Agile Project Management. Jim Highsmith.
“If you’re using a waterfall model, forgetting something can be a costly mistake. You don’t find out until you get down to a system testing that one of the requirements was missing or wrong.” Rapid Development, Steve McConnell.
“The advantage of the incremental approach is that the company can get feedback on the implementation and how it is received and possibly fin tune the implementation strategy.” ERP Demystified, Alexis Leon.
“There is no direct relationship between a company size and the complexity of its (ERP) software requirements.”, Control Your ERP Destiny. Steven Scott Phillips.
“From a financial perspective, for every $1 not spent on requirements analysis: $10 is spent on extra implementation cost and delayed ROI, $100 is spent in business disruption costs on going live, $1k is spent in hidden costs of not meeting expectations over the life of the software.”, Rethinking Enterprise Software Selections, Chris Doig.
“Often the problem lies not with the ERP concept. But in the demand for quick fixes and rapid cures to underlying structural problems.” e-Business Roadmap for Success, Dr. Ravi Kalakota & Marcia Robinson.
“A company may employ the most sophisticated software in the world, but unless information is managed, timely, accurate, and complete, the system serves little purpose.” ERP Lessons Learned – Structured Process, Wayne L. Staley.
“One guiding tenet is every present: any change we administer should add more value, cost less, or deliver services more rapidly.” Transitioning the Enterprise to the Cloud, Ed Mahon, CIO at Kent State University.
“You give me good people and a great process, and we’ll beat any organization with the best technology but a poor process and under motivated people.” Information Week – Focus on the Process. Doug Patterson, VP and CIO.
“Experience shows that the greater employee involvement in the change, the greater the positive response in understanding the compelling need for the change and the sharing of the vision.”Managing the Change Process, David K. Carr, Kelvin J. Hard, William J. Trahant. Coopers & Lybrand Center of Excellence for Change Management
“People are one of the hidden costs of ERP implementation. Without proper training, about 30 to 40 % of front-line workers will not be able to handle the demands of the new system.” Consider, Select & Implement an ERP system, O’Sullivan, Rico, Goldensohn.
“The users of the ERP will be confronted with a huge amount of data; most of the data will have no relevancy to any decision that needs to be considered.”ERP: Tools, Techniques, and Applications, Carol Ptak, Eli Schragenheim.
“Operation and maintenance phase begins with a period of initial struggle until people become comfortable in their roles and tasks. The duration of this stage depends on how effective the training was.” Enterprise Resource Planning, Alexis Leon.
“People can’t be controlled like machines: Service processes are far more dependent on the interaction of people (both internal handoffs and working with customers) than are manufacturing processes.” Lean Six Sigma for Service, Michael L. George.
“There are limits to how much change an organization and its end users can stomach at once.” Why New Systems Fail. Phil Simon.
“In an organization undergoing change, building a resilient work force by widely disseminating the change vision and strategy and by minimizing disruption is essential.” Managing the Change Process, David K. Carr, Kelvin J. Hard, William J. Trahant. Coopers & Lybrand Center of Excellence for Change Management.
“If you think education is expensive, try ignorance.” Derek Bok.
“Although consultants may participate in testing to some extent, employees should drive the majority of testing. Doing so maximizes knowledge transfer and readies them for real life under the new system.” Why New Systems Fail. Phil Simon.
“Gartner Research recommends allocating 17 percent of the project’s budget for training. Those companies spending less than 13 percent on training are three times more likely to have problems.”, Concepts In Enterprise Resource Planning, Ellen Monk and Bret Wagner.
“A big mistake made with (ERP) software purchases is leaving user buy-in until the implementation phase. When this happens, users feel the sofware is being foisted on them without their input.”, Chris Doig, Rethinking Enterprise Software Selections.
“In order to do rapid implementations, trade-offs must be made.” E-Business and ERP, Murrell G. Shields.
“Rapid Implementations: The data cleanup must start early in the project for the organization to be prepared for the data conversion.” E-Business and ERP, Murrell G. Shields.
“Rapid implementation cannot be done with a massive project team.” E-Business and ERP, Murrell G. Shields.
“Deliver sooner rather than later. It is rare to get 100% support for any project; “fence sitters” will wait to see how things turn out before giving their support.” Modern ERP, Marianne Bradford.
“The training in a rapid implementation should be hands-on.” E-Business and ERP, Murrell G. Shields.
“Good people can make a bad system work; bad people can’t make a good system work”. The Reengineering Handbook. Raymond L. Manganelli, Mark M. Klein.
“The “Train the Trainer” Pitfall: It is not realistic to assume someone can be trained several weeks before the go-live and expect him/her to deliver quality training.” Control Your ERP Destiny. Steven Scott Phillips.
“The data migration phase of a project can consume up to 30% of the total project resources. The most common flaw in data migration planning is that too few resources are invested in it.” Top 10 Reasons Why Systems Projects Fail. Dr. Paul Dorsey.
“Extracting and cleansing the data from the existing system can be the single largest task in the project.” ERP Demystified. Alexis Leon.
“Bait and switch. This is the practice of displaying certain consultants, during the sales process, to show the sales company understands business and the ERP implementation process to ensure a successful outcome.” Enterprise Resource Planning (ERP) The Great Gamble, Ray Atkinson.
“Have successful project managers who are capable of anticipating what can go wrong.” ERP Demystified, Alexis Leon.
“Overspend on consultancy is often compensated for by a cut-back in training. This is not helped by the fact that training costs tend to be under-estimated in the first place.” ERP – The Implementation Cycle, Stephen Harwood.
“(ERP) Service organizations are essentially big “people machines”, where having a high level of turnover is just as deadly as if a manufacturer was constantly asked to change machine parts.” Lean Six Sigma for Service. Michael L. George.
“Implementation audits are necessary to keep the project on track. Audits should be conducted to compare project results, business objectives, systems objectives, and project objectives.” Directing the ERP Implementation. Michael Pelphrey.
“Claims of ‘proven paths’, ‘best practices’, and simplistic implementations methodologies, that fail litter the ERP landscape as each software company seeks to gain some form of advantage over its rivals. “Enterprise Resource Planning (ERP) the Great Gamble. Ray Atkinson.
“What businesses need is not a one-time fix for individual processes but an environment that combines business and technical systems to produce processes that flex and recombine as required by changes in the market.” Business Process Management – the third wave, Howard Smith and Peter Fingar.
“As Tom DeMarco and Tim Lister (2003) so pithily state, “If a project has no risks, don’t do it.” Risk is an essential characteristic of innovation”.”, Agile Project Management, Jim Highsmith.
“Cost overruns are manageable if the project will achieve worthwhile benefits; however, failing to satisfy business goals is always unacceptable.” Principles of the Business Rule Approach, Ronald Ross.
“Customers like rapid delivery. Rapid delivery means companies can deliver faster than customers can change their minds.” Lean Software Development, Mary Poppendieck & Tom Poppendieck.
“One of the biggest mistakes during ERP projects is not taking the time to build a common understanding of how business is conducted today and potential improvement opportunities.” Control Your ERP Destiny, Steven Scott Phillips.
“If the project becomes all things to all people, it will fail to meet anyone’s expectations.” Control Your ERP Destiny, Steven Scott Phillips.
“A consultant with software knowledge is one thing, but if the consultant is a poor communicator, it undermines the transfer of knowledge.” Control Your ERP Destiny, Steven Scott Phillips.
“Job 1 is to run the business. Very close to that in importance should be implementing ERP.” ERP: Making It Happen, Thomas Wallace & Michael Kremzar.
“A methodology will help ward off risk, but a contingency plan is still absolutely necessary.” ERP Demystified, Alexis Leon.
“There are literally thousands of decisions that must be made on these projects. The project team must be empowered to make most of them. That is one reason organizations must put their best people on these teams.” E-Business and ERP ,Murrell G. Shields.
“The rumor mill and grapevine are active in most companies, and it is in the project team’s best interests to preempt them by providing clear, consistent, targeted, and ongoing communications.” Successful Packaged Software Implementation, Christine B. Tayntor.
“But technology is not reengineering. Reengineering changes the business processes – the way the work is done.” The Reengineering Handbook, Raymond L. Manganelli, Mark M. Klein.
“Projects that skimp on upstream activities typically have to do the same work downstream at anywhere from 10 to 100 times the cost of doing it properly in the first place.” (Fagan 1976; Boehm and Papaccio 1988). Rapid Development, Steve McConnell.
“The success or failure of a new system hinges directly on the acceptance of that system by the organization’s end users.” Why New Systems Fail, Phil Simon.
“The goal of an integrated enterprise is to reduce information float, that is, the time between when data is captured in one place in the system and when it becomes available and usable. e-Business Roadmap for Success. Dr. Ravi Kalakota & Marcia Robinson.
Chris Koch of CIO.com writes, “Blank sheet reengineering can lead to unrealistic business process designs that can’t be implemented through enterprise software.”.
“A major cause of this difficulty (failures) is that organizations building these systems tend either to assume that components can be simply thrown together or they fall back on the traditional engineering skills and processes with which they are familiar-skills and processes that have been shown not to work in the building of COTS- based (ERP) system.” Evolutionary Process for Integrating COTS-Based Systems (EPIC) Carnegie Mellon – Software Engineering Institute.
“Agile methods universally need close relationships with the customer and users of the systems under development.” Balancing Agility and Discipline. Barry Boehm, Richard Turner.
“The truth is, no organization plans to fail – rather, they fail to plan…” Control Your ERP Destiny, Steven Scott Phillips.
“Two overriding criteria that mast be present if the implementation of a COTS solution are to be successful: realistic expectations and organizational flexibility.” Successful Packaged Software Implementation. Christine B. Tayntor.
“The longer a team, large or small, goes without delivering an integrated product to a review process, the greater the potential for failure.” Agile Project Management. Jim Highsmith.
“Inclusion of end users promotes acceptance of the solution and helps break down “us versus them” barriers. Working together, the two groups will provide a balanced evaluation.” Successful Packaged Software Implementation, Christine B. Tayntor.
“For an ERP implementation to go smoothly and provide value, it is critical that a company understand both its current processes and the state of the process after implementation.” Concepts in Enterprise Resource Planning, by Ellen Monk, Bret Wagner.
“Making partners of customers means they become more likely to understand technical constraints. You start to get rid of the “I need it all now” phenomenon, and customers begin cooperating to find realistic, mutually satisfying technical solutions.” Rapid Development, Steve McConnell.
“Don’t try to fool yourself that you will be able to catch up (project schedule) just by trying harder. It won’t happen.” Making ERP Work, Sam Graham.
“ERP systems will not exhibit their full potential unless they are properly integrated with other enterprise software applications.” ERP Demystified. Alexis Leon.
“ERP is a philosophy for operating a business model. If your company does not want to adapt to this philosophy, save yourself the headache and don’t pursue ERP.” Directing the ERP Implementation. Michael Pelphrey
“Implementing the ERP system and realizing the promised benefits are two different ball games. Implementation can be a success, but if the operational phase is not planned and organized properly with the support of all the people involved, then the promised benefits will not materialize.” ERP Demystified. Alexis Leon.
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.
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.
Join the community! 10k followers across 100 countries!
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:
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:
Template to identify possible organizational changes based upon predefined ERP roles/responsibilities
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.
Join the community! 10k followers across 100 countries!
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.
Too often we focus on putting 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.
Join the community! 10k followers across 100 countries!