There are not many methods on how to maximize ERP utilization. There are approaches that do a commendable effort in identifying some of the factors that influence ERP utilization. What is lacking are predictability, repeatability and harmony across the key components of a business solution. In my 25 years of ERP consulting experience, I have never encountered a single customer that utilized over 60% of the ERP software. Given the lack of utilization and the money needed for cloud ERP implementations, I am convinced this is a problem that finally must be solved! We are in the second generation of ERP software and the only advancement that we in the ERP implementation arena have made is to retract our initial recommendation of customizing ERP for greater customer value.
The purpose of this article is to provide an overview of my theory on predicting ERP utilization. The scope of this article will focus on the cloud ERP deployment model. I have yet to complete the rigors of the scientific method to verify my theory. However, I would like to share my concepts with you and partner with you in growing the collective knowledge.
ERP Utilization requires all components of a business solution
First we need to revisit the concept of a business solution, the key components, their relationship, and influence on ERP utilization.
Just as technology has a part to play in ERP implementation success, business process maturity and the organization’s ability to change have a greater impact on ERP utilization. To elaborate on this thesis I will make use of two models:
I find that Organizational Change Management (OCM) is more of a project-based effort to enable an organization to meet a specific event. This approach works very well with an on-premise ERP solution where upgrades are measured in years. However, in the more dynamic Cloud ERP solution model, change is more rapid. ERP cloud updates and upgrades happen in months, not years. What I really like about OCC is the greater focus of providing the organization with the skills and flexibility to handle known and unknown changes.
OCC is an emerging model, thus there is limited content regarding how to assess and measure OCC for an organization. There for 4 key attributes for defining OCC levels (Saylor Academy, 2012):
It refers to how much front-line workers trust middle managers and senior executives to watch out for their interests.
Focuses on getting things done across organizational units and functional areas of expertise. Fisher and Sharp (2004).
Systemic knowledge is the degree to which members of an organization understand and are focused on the overall organizational system.
Change-capable organizations balance accountability with innovation. If the organization overemphasizes accountability, innovation suffers. And if innovation is the sole focus, accountability is ignored.
Given the above definitions, I have created a level definition to support my ERP utilization prediction model.
ERP Utilization Model
With all that said, consider the following conceptual model:
I propose a multivariate linear regression relationship between business process maturity, organizational capacity model for change with potential ERP utilization. This simplified model is based on the following assumptions:
A set of ERP features require a certain level of organizational and business process maturity for a successful experience. For additional information, see my article on Business Leads and Technology Supports.
Based upon the CMMI level and OCC for the customer, we can infer the ERP features required for maximum ERP effectiveness.
OCC has a direct influence on effective ERP utilization.
Software changes will happen more rapidly in an ERP Cloud delivery model versus a tradition ERP On-Premise model. Therefore, OCC must become an ongoing competency (versus a one-time effort) for long-term ERP success.
“It is generally not fruitful to impose a very sophisticated process on an organization whose maturity is low. The maturity of an organization not only depends on the skill sets of the individuals, but also on the chemistry of the team.” (Alexia Leon, 2012)
Based on the above model, I conclude that customer enablement must be an ongoing exercise that runs in parallel or even precedes ERP automation.
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 heavily relying on consulting services.
As we continue with the model elaboration, we find that there are regions that are not practical for a given CMMI and OCC values. Consider the following:
Key Points and Observations:
Circles represent a subset of possible values given that the scenario occurrence is highly improbable. For example, an organization with a CMMI level 1 maturity cannot expect to utilize 100% of the features available for a Cloud ERP service.
The permutations of CMMI and OCC levels indicate a linear relationship for targeted ERP utilization.
What Role can Machine Learning Play?
If we can define a logical model with reliable predictive results, then we can begin the journey of providing free consultative guidance to ERP customers and prospects. Let’s start simple with a prediction formula and a structured learning test set.
Following are the assumptions that I used for building the formula and training set:
Business process maturity (CMMI) and organizational maturity (OCC) have a linear relationship with potential ERP utilization.
Certain permutations of CMMI and OCC does not reflect reality (ex. Business process cannot be at a high level of maturity and a low level of organizational maturity).
The minimal boundary of ERP utilization is 20% and the maximum boundary is 80%.
Next, I performed individual regression analysis for each variable separate and together in order to determine if the predicting equation should use one or both variables.
Based upon the above analysis, it appears that the prediction formula utilizing both business process maturity and organizational maturity best aligns with the training set. Next step is to calculate the coefficients for both variables.
In an act of transparancy, I am sharing my data model. Feel free to review and provide feedback/correction.
So what is the application or value add this model can provide?
Even with a cloud delivery model, the implementation costs associated with ERP have not dramatically decreased. The ratio of ERP software cost to ERP implementation cost has increased from 3:1 to 6:1. It is only a matter of time before the ERP market forces ERP vendors to drastically reduce implementation costs while maintaining a sufficient level of customer enablement. Given the rise and general adoption for cloud ERP services, ERP utilization is becoming more strategic competitive advantage for cloud ERP vendors. What I see as an emerging demand from the ERP market is a reliable, repeatable method for maximizing ERP utilization. I hope that my efforts move the discussion forward.
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.
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!
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!