It is generally accepted that user adoption and user engagement are key critical success factors for ERP business value realization. However, a majority of ERP implementations take a cursory approach where a qualitative method was utilized for measuring user adoption and user engagement. A qualitative approach focuses on data that is subjective, interpretive and exploratory. Let’s see how successful this soft approach has been in the past.
According to a 2014
survey from Panorama Consulting Solutions of 192 businesses, 66 percent of
respondents reported receiving 50 percent or less measurable benefits from
their ERP implementation, and less than 40 percent were satisfied with the rate
of user adoption. In the US, a recent study
estimates that over half of all Accounting, ERP, and CRM
implementations fail to meet their objectives. In Europe, the corresponding
statistic is 70%–80 %! An oldie but goodie
is what was learned
from the 1999 Hershey’s ERP failure (user adoption). A recurring theme from the ERP failures
listed above is a lack of actively tracking and managing user adoption and user
engagement. Traditional approaches of
End User Testing (EUT), Just-In-Time (JIT) training and user surveys are
insufficient for a reliable, effective user adoption and engagement process. In the following sections, we will discuss
practical steps that you can take to better quantify user adoption and user
User Adoption vs.
The first step to take in implementing a measured and
repeatable approach is to understand the difference between user adoption and
user engagement. User adoption is
when users adopt a system that works to fill a specific need. User engagement measures how effectively a
system is utilized. A user can adopt an
ERP solution but yet the user is not making the most of the ERP functionality
available. In my humble opinion, I
believe that we in the ERP industry too often try to broadly address these
specific areas with qualitative surveys which are translated into quantitative
data with some level of bias.
Don’t get me wrong, using surveys and statistics as a tool to provide some level of quantification of qualified user feedback is an established approach. The problem occurs when user surveys are the ONLY method we use to manage user adoption and user engagement. Surveys were necessary in what I call the 1st generation of ERP given that the technology and availability of user data was not a primary objective for ERP vendors. However, now that we are in the 2nd generation of ERP, user data is more available for consumption. We in the ERP industry have to leverage this new capability in addition to conventional means.
What data should we go after to highlight user adoption and user engagement? Consider the following illustration as a starting point.
Starting with user adoption metrics:
Test cases executed: Quantify how many end-user test cases are executed by ERP users. There is no better method for training and fostering user adoption than “hands-on” experience. Automating testing may not always be the best option for all scenarios.
Number of users: Quantify how many users are provisioned for the ERP solution. An increase in ERP users could be an indicator that organizations see the ERP solution as an enabler. Conversely, a decrease in ERP users may highlight a risk.
Consumed training: There are three attributes to capture in the area of training: (1) Total # of hours consumed, (2) Total $ spent on training and (3) Average training hours per user. An “intuitive” user interface is not a substitute for user education and training.
Number of ERP sessions by connection type: Another perspective of measuring ERP user adoption includes (1) number of user sessions by connection type (online, mobile). Mobility can be a huge enabler for greater data visibility and accelerating approvals. Capturing this data will provide customers deeper insight regarding how their users consume their ERP service.
Continuing with user engagement metrics:
Number of manual transactions: “A major overhead in operating ERP systems is entering transactions. Transactions take time, cost money and introduce the possibility of errors.” Making ERP Work, Sam Graham. If you are interested in process efficiency and ERP business value realization then the customer should take a hard look at these scenarios and have a plan to minimize these activities.
Number of correcting transactions: Correcting transactions are rework of existing transactions. If you are a student of Lean Six Sigma like I am, then customers want to do everything they can to minimize rework. This type of rework may seem insignificant at the individual user level, yet the customer will be surprised when (1) the rework summarized across the organization and (2) the customer quantifies the impact(s) to business process cycle time(s).
Number of exception transactions: Any competent ERP solution allows some level of exception transactions. Example: At month end, the user makes an Accounts Payable journal entry in the General Ledger and then the ERP solution automatically accounts for the journal entry in the Accounts Payable sub ledger. Another example of an exception transaction is when a transaction is rejected (Expense Report). Exception transactions are a necessary evil. However, it is important to note that exception transactions generally require (1) additional user effort (costs) and (2) slows down the business process cycle. Tracking this type of data will provide insight regarding the root cause for cycle time exceptions.
Decision support transactions: A common value proposition that all ERP vendors are making today is enabling users to have more time to focus on making business decisions by automating tactical business transactions and consolidating data into meaningful information. Therefore, we should be able to measure this effect by categorizing and capturing this information via the ERP solution. For example, if we observer that the number of manual transactions are decreasing and the number of decision support transactions increasing then we can feel confident that the organization is effective in utilizing the ERP solution.
Following is an example of an ERP solution user engagement model.
Let’s elaborate on a couple of points. First, user adoption does not equate to effective user engagement. The majority of ERP solutions provide the customer the ability to perform transactions efficiently (automated) and inefficiently (manual, exception, corrections). As a customer, part of your responsibility is to identify inefficient use of the ERP solution and create an improvement plan. From the above profile, we can identify the following:
There is an unhealthy volume of manual transactions. As the volume of manual transactions increase, it is reasonable to conclude that there will be a greater increase in exception and correction transactions (resulting in additional cost/cycle time).
It is possible that the increase in manual transactions is due to a limited configuration of the ERP solution and the user’s knowledge of the ERP’s features. Configuration issues can be identified by the customer’s support team and the ERP vendor’s support resolutions.
As the customer performs user enablement analysis, it is
important to note that a visible pain may be a consequential result of an
Practice Makes Perfect
User efficiency with an ERP service is not a Just-In-Time event but an incremental process. Given that people are the most important component of a business solution, it is negligent not to involve users thought out the ERP service implementation. Sorry for the tough love but this is a gap that no one wants to address head-on. It has been identified as a critical success factor but is typically handled as a “negotiation play” during the sales process. If a customer is smart, then they can use data like user adoption and user engagement as leverage with the ERP vendor and SI partner.
Incremental user involvement during the ERP solution implementation requires greater project management coordination and guidance. Second only to the ERP vendor, end users directly impact business value realization for a customer.
Rising to the Challenge of Creating Reliable User Adoption and Enablement
Referring back to my previous article, effectively business value realization will require an investment from the following stakeholders.
Challenge to SI Partners
User Adoption and User Engagement should be generally accepted as key project management metrics (On-time, On-budget, In-Scope).
Customer should make an investment of at a least 20% investment in user training and user enablement. Consider the following guidance:
IDC Learning Services Research shows that organizations, on average, spent 15% of their total ERP budgets on training, while indicating that a 17-20% investment yields better results.
Gartner Group research shows similar averages and an interesting fact: organizations that spent less than 13% of their total ERP cost on training were three times more likely to see their ERP projects exceed deadlines and run over budget when compared to organizations that spent 17% or more.
Aberdeen Group says that ERP is not a “set it and forget it” tool. Implementing a continuous learning strategy will help users complete their tasks successfully pre- and post-launch.
Challenge to ERP Vendor
ERP vendors should deliver out of the box user adoption reporting and user engagement reporting as described above to enable customers in actively managing ERP service utilization.
ERP vendors should provide support service analyses that are a result of incorrect configuration or lack of training.
Challenge to Business Users
Business users must be open to change and innovation. Sticking to the legacy process and keeping things the way they are at all costs reduces the chance of real optimization with the new ERP solution.
Users must broaden their horizon from a functional job focus to business process focus. This requirement is not just for super users. Every individual ERP user should have an understanding of how their input impacts the overall business result(s).
For far too long, ERP user adoption and engagement
management has been strictly a qualitative exercise given that there has been
limited services provided to easily quantify user metrics. One type of data is objective, to-the-point,
and conclusive. The other type of data is subjective, interpretive, and
exploratory. Given how important user
adoption and engagement are to ERP solution success, there should be a
comprehensive approach including both qualitative and quantitative data for ERP
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!
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.
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 that 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
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.
Join the community! 10k followers across 100 countries!
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.
Join the community! 10k followers across 100 countries!
I had a customer ask me about the relationship between BPM and ERP. Does ERP implement BPM or do you need to have BPM before ERP? Is an ERP implementation a BPR project? Who’s on first? As the ERP industry evolves it has become evident that additional disciplines like Business Process Management (BPM) and Business Process Reengineering (BPR) must be employed for a successful ERP experience. In the following blog posting I plan to define and demonstrate the roles that BPM/BPR play in the ERP lifecycle.
BPR, BPM, and ERP Revisited
Allow me to establish some basic definitions for our discussion:
Business Process Management (BPM) consists of methods, techniques and tools to design, deploy, control, and analyze operational business processes involving humans, organizations, applications, documents and other sources of information.
Business Process Reengineering (BPR) is the redesign of business processes – and the systems, policies, and organizational structures that support them – to optimize the work flows and productivity in an organization.
Enterprise Resource Planning (ERP) is integrated business software that supports multiple business functions across an enterprise. ERP implies the use of Commercial Off-The-Shelf (COTS) packaged software rather than proprietary software written by or for one customer.
There are a couple of key concepts we should review to compare/contrast BPR and BPM.
Compare & Contrast BPM & BPR
BPM focuses on the business process model to monitor, identify, and implement incremental improvements. These improvements or eliminations fall within the fundamental rules, parameters, and culture established by the existing business model. However, there comes a point in time where the law of diminishing returns applies and a transformation to the underlying business model is required. A more aggressive approach like BPR must be utilized to evolve to the next level of business process maturity. Consider the following illustration to demonstrate how BPM and BPR interact along the Capability Maturity Model Integration (CMMI):
BPR, BPM within CMMI
Allow me to provide an example. Company A performed a CMMI assessment of their purchasing process. Results from the assessment showed that the purchasing process was defined for certain business sales (revenue stream) but not for all purchasing events (direct & indirect). Another key finding was that there was no formal integration between demand planning, supply planning and purchasing which resulted in reactive purchasing. From the above CMMI reference, it was determined that Company A’s purchasing process is at the Managedlevel. Company A implemented several incremental initiatives (BPM) to improve process execution including documenting purchasing tasks for all purchasing events and conducting periodic purchasing planning meetings with operations.
Company A realized process improvement yet the value was limited by following model constraints: (1) each revenue stream (business line) had its own unique purchasing process & rules and (2) Purchasing had limited visibility across the entire supply chain. Two fundamental mindsets have to change:
Move from unique purchasing processes to a common enterprise purchasing model that is flexible enough to address the competitive requirements for each business line
Enable Purchasing to have visibility across the entire supply chain to support a process-oriented management model versus a function-oriented management model.
Implementing these changes will require a formal, projectized (BPM) effort that will redefine existing business rules, culture, and business process activities. As Company A continues to evolve their purchasing process they will conduct both BPM within the CMMI maturity level and BPR as they move to the next CMMI maturity level.
ERP reduces the effort required to perform tactical business activities so customers can focus on strategic activities. Expanding on our purchasing example, this would include basic functionality like automating the creation of purchase orders, approving purchase orders, and matching purchase orders with receipts & supplier invoices.
ERP provides the opportunity for visibility across business functions to support business process management. That said, there are several factors that determine the level of visibility.
Factors Impacting ERP Business Process Visibility
A competent ERP solution should provide robust, closed-loop integration between the functional modules provided out-of-the-box. As a practical note, there is always a need to integrate ERP to legacy systems and this requirement should be not overlooked. A business solution is only as good as its weakest integration. Process consistency will enable a relevant comparison of results and management of business processes.
A mature ERP solution should provide automation and integration support for both tactical and strategic business activities across the CMMI model.
Common ERP Misconception and Mistakes Related to BPR & BPM
Allow me to address some common misconceptions and mistakes made during ERP implementations related to BPR and BPM.
BPR is part of the ERP implementation.
While I agree that the initial ERP implementation will result in major changes with existing business functions, BPR will not happen unless there is a concerted effort to redefine the holistic business model and organizational structure to be successful with the ERP software.
Implementing ERP will give us BPM.
The direct answer is no. ERP does provide an information foundation that can support BPM. BPM is more about a discipline for managing processes and less about software.
Do I need ERP to mature my business processes?
Technically speaking, ERP is not a hard requirement for BPM. However, manual routine tasks and limited visibility hinder strategic activities. ERP can play a key support role in automating business tasks and provide visibility through integration.
Should I implement ERP features that support business activities at different maturity levels?
Business realities will necessitate that customers implement ERP features supporting different CMMI maturity levels. The problem lies in two areas:
Customer expectations are not appropriate set regarding the limited value realized from mature ERP functionality due to less mature business activities supporting strategic activities. Example: A procurement process scorecard measuring standard Key Performance Indicators (KPIs) will have limited value if there is not a standard, enterprise procurement process.
Implementation partners and business solution advisors should provide a short-term strategy and roadmap to evolve the supporting business activities to same level of maturity. This approach provides a “quick-win” opportunity for customers to drive additional value from the existing ERP investment.
Understanding how BPR, BPM, and ERP should relate to one another can be a challenge. Some believe that it is an “either or” proposition. I do not subscribe to this school of thought but rather believe that BPR and BPM are disciplines that should be interweaved as part of your ERP application strategy. Knowing and appreciating these interdependencies will put you in a better position for ERP success.
Join the community! 10k followers across 100 countries!
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:
Basic ERP Requirements Management
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:
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:
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!
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:
Options to address ERP requirements
Automation: Developing a technical solution to address need.
Business Process: Creating business process to address need.
Acceptance: Do nothing and handle as the need arises.
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.
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.
Join the community! 10k followers across 100 countries!
There are several documented examples of ERP implementations that went over budget or did not hit the original go-live date. There are also many explanations out there to explain why these ERP implementations did not meet budget or timeline. Instead of repeating common information out in the ERP blogosphere, I would like to speak to a root cause that is typically overlooked by our industry – inaccurate ERP implementation estimations. In the next sections we will take a closer look at building a better ERP estimate.
Rule #1 – Have the right type of information to calculate an ERP Estimate
Developing a competent estimate for an ERP implementation or major customization can be a challenge for both seasoned consulting partners and a new ERP customer. In a previous life I developed ERP implementation estimators for one of Tier-1 ERP software vendors. I also developed both Time & Materials as well as Fixed-Price ERP implementation estimates – some good, some not so good.
Simply stated – an ERP implementation estimate is based upon your current understanding of the following areas:
Information Drivers for ERP Implementation Estimates
Let’s focus on some specific areas that are typically overlooked or under appreciated.
Implementation partners are generally good about estimating their level of effort to support ERP implementations but fall far short in estimating the effort for the customer. In the majority of ERP implementations, customer must make available their best and brightest resources to support the implementation. Odds are that these resources play a major role in current operations. The ERP estimate should include any need to backfill existing business resources.
Project scope refers to the implementation activities that need to be performed and who is responsible for performing the task(s). Unfortunately, customers see this as an area to reduce implementation costs by taking on activities that they do not have the skills/resource availability to complete (ex. Organization Change Management). People make ERP successful.
Too often business processes and product scope is defined only at the product level (example: we are implementing the ERP’s Purchasing module). How can I tell what business activities and features are out of scope? Developing focus is much harder to develop and maintain.
Implementation Partner Constraints
Every implementation partner has constraints! It is a just a reality that should be factored into any ERP estimate. For example, how much lead time should be given for an Implementation partner to replace a consultant?
You can never hope to create a realistic estimate without having valid information on the drivers that influence scope, schedule, and resources. The next step is to understand your level of comprehension of the information that drives the ERP estimate.
Rule #2 – Understand the type of ERP Estimate you are calculating
Per the Project Management Institute’s Body of Knowledge (PMBOK) there are three types of estimates for a project. These estimates are based upon your level of understanding for project scope, constraints, and assumptions.
How Understanding Drives Estimate Accuracy
Simply stated – the more you know about the task(s) at hand the greater the probability of calculating a realistic estimate! The trouble is that too many ERP implementations do not generate a definitive estimate. A majority of implementation partners generate estimates during the sales cycle where estimates may approach a budgetary accuracy – at best. To compensate for the estimation accuracy (-10% to 25%) many implementation partners incorrectly utilize contingency reserves and management reserves to plug the potential estimate gap. This is just a bad estimating practice which will most likely result in budget challenges further down in the implementation. Fortunately, there are steps we can take to develop better ERP estimates.
Rule #3 – Drive to validate and refine your ERP estimate
Estimates can and should change as you learn more about the project. However, there is an expectation out there that estimates should be defined once and they should be completely accurate. Here is where I see the process break down. Once an Implementation partner communicates an estimate too often the customer will latch and consider it an iron-clad promise. The key driver for this phenomenon has more to do with the Implementation partner setting the wrong expectation when an estimate is communicated. Customers encourage this behavior by focusing on cost as the key competitive differentiator. Also, there is a perception in the market that if an implementation partner cannot provide a single estimate then the Implementation partner does not have the experience. Customers, this may be the case but do not blindly jump to that conclusion.
Best Practices for obtaining ERP Estimates from your Implementation partner
Over the years I have been asked by customers what is the best approach to get a reliable, cost-effective estimate from Implementation Partners. When should a customer request a fixed price estimate versus a time & materials estimate? Following are some general guidelines I would like to communicate based upon my experience:
Fixed Price versus Time & Materials: Have the Implementation partner provide a Time & Materials estimate for project planning, requirements gathering, and fit/gap. Once the Fit/Gap is performed you should know exactly what you are up against and then ask for a competitive bid/fixed price estimate to complete the remaining work.
Complete Information: Always ask the Implementation Partner to provide an estimate with the following information
FTE Hour Requirements for both the Implementation Partner and customer resources
Estimate accuracy – let customers know up-front that the estimate will change
Quantify Reserves: Ask the implementation partner if the estimate contains either a contingency or management reserve. If so then ask what % of the total estimate is for reserves. If this % is greater than 10% then this is a sign that the Implementation partner did not gather enough information to generate a realistic estimate. If the implementation partner does not calculate a reserve then consider this estimate suspect (red flag).
Knowledge Transfer: Just as important it is for an Implementation partner to perform knowledge transfer to enable customer resources to support ERP, it’s as important for the customer to educate the Implementation partner on the unique aspects of their business model. The better the understanding the better the estimate.
There are many of my peers who would consider ERP estimation more of an art than a science. In my humble opinion, this is a bad philosophy that either results in generating an unrealistic estimate or the customer spending more money than is required. Customers should also be realistic and understand that estimates created in the early stages of an ERP implementation will change and focus on making the right decisions for mutual success. Level of effort estimations for ERP implementations are based upon the current understanding of the ERP implementation. Some ERP estimates are easier to calculate given a predefined implementation scope, however, there will always factors unique to a customer that must be explored, defined, and refined during key milestone implementation activities.
Join the community! 10k followers across 100 countries!