365 Quotes for ERP Implementations

Brett's Hobby

Brett with his personal ERP library

I consider myself an ERP/Cloud implementation practitioner on the road to becoming a better ERP advisor and leader.  I have been on this path for 20 years and believe that I have much to share with my peers.  I also believe that I still have much to learn on this journey.  My hope is that you will partner with me in the never-ending quest for ERP implementation success.  During my ongoing research I have collected a database of over 2000 quotes on ERP-related topics (pains, success, best practices, failures, mistakes, implementations, selections).

As part of that partnership I would like to share 365 quotes from valuable books/resources that have influenced/guided my ERP journey.

# Quote Resource Author(s)
1 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
2 Putting yourself on the same side as the customer is one of the best ways to avoid the massive rework caused by the customer deciding that the product you just spent 12 months on is not the right product after all. Rapid Development  Steve McConnell
3 Reliability is results driven. Repeatability is input driven. Agile Project Management Jim Highsmith
4 One of the most important areas in enhancing the value added to clients is designing the presentation of information so that it can be readily assimilated and internalized as knowledge. Developing Knowledge-Based Client Relationships Ross Dawson
5 All of the work that goes into development is not adding value until the software is in the hands of the customer. Lean Software Development Mary Poppendieck & Tom Poppendieck
6 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
7 “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
8 “The truth is, no organization plans to fail – rather, they fail to plan…” Control Your ERP Destiny Steven Scott Phillips
9 Many ERP implementations proceed without sufficient knowledge of the possibilities or potential in the new systems. This relegates the design process to a discussion of repeating the current design (the only thing the client knows) or implementing a process that the consultants happen to know (limited to what the consultants have experienced). Maximize Return on Investment Using ERP Applications Worster, Weirick, Andera
10 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
11 Achieving early wins and optimizing user buy-in can pave the way for controlling both political and fiscal costs down the road and increase the chances of delivery project on time and on budget. Total Cost of Ownership: A strategic tool for erp planning and implementation Richard West, Stephen L. Daigle – California State University
12 In making design decisions, the entire process should be considered, not just the individual steps, in isolation. As in many things, the business process is only as good as its weakest subprocess. Most of the attention should be focused on the process bottlenecks. Managing the Change Process

 

David K. Carr, Kelvin J. Hard, William J. Trahant. Coopers & Lybrand Center of Excellence for Change Management
13 To integrate business processes, there is a tendency to employ a bottom-up technical integration, stitching together application components that were never intended to work together at the business level. Business Process Management – the third wave Howard Smith and Peter Fingar
14 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
15 Requirements creep must first be differentiated from requirements evolution (elaboration). Agile Project Management Jim Highsmith
16 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
17 Every organization that implements an ERP system is, in effect, reengineering. Modern ERP Marianne Bradford
18 Remember that if you fail to implement, who cares what the software (ERP) does? Modern ERP Marianna Bradford
19 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
20 Having an ERP system is not a luxury but a necessity. It is a must for survival in this competitive world. ERP Demystified Alexis Leon
21 A major cause of this difficulty 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 a COTS-based (ERP) system. Evolutionary Process for Integrating COTS-Based Systems (EPIC) Carnegie Mellon – Software Engineering Institute
22 The acquisition of the tools, of and by itself, will not make you proficient in their use and thus will not provide a competitive advantage. ERP: Making It Happen Thomas Wallace & Michael Kremzar
23 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
24 “Planning can become mechanistic and succumb to a checklist mentality.” Balancing Agility and Discipline Barry Boehm, Richard Turner
25 Good design can’t fix broken business models – Jeffrey Veen Why New Systems Fail Phil Simon
26 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
27 The gap between a person’s current knowledge level and the knowledge requirement associated with the change will directly impact the probability of success for those individuals. ADKAR – A Model for Change in Business, Government and Our Community Jeffrey M. Hiatt
28 Prototypes are generally designed to handle only the nominal cases; they aren’t expected to handle the exceptional cases. Rapid Development Steve McConnell
29 The development of knowledge is an iterative process, in which experience and lessons provide the basis for deeper understandings in ongoing feedback loops. Developing Knowledge-Based Client Relationships Ross Dawson
30 Organizations are now in a business environment where their success will depend on their ability to rapidly respond to changing business requirements. E-Business and ERP Murrell G. Shields
31 ERP is commonly misperceived as a computer system. Not so.   It’s a people system made possible by the computer software and hardware. ERP: Making It Happen Thomas Wallace & Michael Kremzar
32 The starting step for business-driven implementation is the creation of business process maps. Secrets to a Successful COTS Implementation Nick Berg
33 It is better to know all the questions than some of the answers. – James Thurber Why New Systems Fail Phil Simon
34 Ironically, customizations don’t add value by default.   By default they subtract value, at least in the short run through costs associated with analysis, design, and development. Modern ERP Marianne Bradford
35 In general, the more comprehensive the system, the more complex configuration will be. Successful Packaged Software Implementation Christine B. Tayntor
36 There is often a level of arrogance in ERP consultants who are taken with replacing existing systems, a level of arrogance that is generally counter-productive. Maximize Return on Investment Using ERP Applications Worster, Weirick, Andera
37 Companies should be careful not to automate non-value-added processes in the new system. Optimize Your ERP System: How to Avoid the Implementation Sins

 

Sage ERP X3 Whitepaper
38 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
39 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
40 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
41 A time-tested maxim in training is always to build on what you know. Principles of the Business Rule Approach Ronald Ross
42 Standardization is the key antidote to low productivity. Lean Six Sigma for Service Michael L. George
43 Off-the-shelf solutions also do not provide a competitive edge for long – any technology your company can buy today your competitors can buy tomorrow. Senior executive must consider a new set of questions: What business processes bring us our identity and competitive advantage? e-Business Roadmap for Success Dr. Ravi Kalakota & Marcia Robinson
44 The way to reduce the impact of defects is to find them as soon as they occur. Lean Software Development Mary Poppendieck & Tom Poppendieck
45 Tools like Enterprise Resource Planning, Lean Manufacturing, Total Quality Management, and others are all essential.   Each one alone is insufficient ERP: Making It Happen Thomas Wallace & Michael Kremzar
46 Implementations must shift from “design and build” unique products to “buy and integrate” standard products. Secrets to a Successful COTS Implementation Nick Berg
47 It is recognized that information accuracy is not a system problem, but rather a management problem. Directing the ERP Implementation Michael Pelphrey
48 Do it once, right at the source. Principles of the Business Rule Approach Ronald Ross
49 At the end of the day a computer problem is probably a business problem. e-Business Roadmap for Success Dr. Ravi Kalakota & Marcia Robinson
50 There is an inclination when implementing packaged applications to use new technologies to implement the same old ways of doing things. E-Business and ERP Murrell G. Shields
51 ERP SaaS requires greater discipline and control for success than on-premise implementations. Cloud Can Bring Out the Best of ERP Brett Beaubouef
52 There is no such thing as a stand-alone ERP module.   ERP is designed to work in concert with other modules as part of a business process. ERP Business Solution Manifesto Brett Beaubouef
53 ERP systems will not exhibit their full potential unless they are properly integrated with other enterprise software applications. ERP Demystified Alexis Leon
54 Successful implementations are done internally.   In other words, virtually all of the work involved must be done by the company’s own people. The responsibility can’t be turned over to outsiders, such as consultants. ERP: Making It Happen Thomas Wallace & Michael Kremzar
55 Chris Koch of CIO.com writes that “Blank sheet reengineering can lead to unrealistic business process designs that can’t be implemented through enterprise software. Why New Systems Fail Phil Simon
56 A common mistake made by many business leaders is to assume that by building awareness of the need for change they have also created desire. ADKAR – A Model for Change in Business, Government and Our Community Jeffrey M. Hiatt
57 Collectively employees do understand the processes, but individually, they do not. Control Your ERP Destiny Steven Scott Phillips
58 Optimizing a business function is futile and non-value-added if it is not part of a revenue/competitive business process. Maximize Return on Investment Using ERP Applications Worster, Weirick, Andera
59 Discipline creates well-organized memories, history, and experience. Balancing Agility and Discipline Barry Boehm, Richard Turner
60 Unsuccessful companies start their ERP implementation effort with automation, bypassing the critical steps of understanding and simplifying their processes. These companies believe that automation alone will improve performance and lead to productivity gains. Automating complex or nonvalue-added processes, however, will not increase productivity or provide measurable improvements in performance. e-Business Roadmap for Success Dr. Ravi Kalakota & Marcia Robinson
61 Teams proceed in a linear fashion with little reliable feedback – they have good ideas, but they don’t test them in the cauldron of reality. Documents don’t work. Products do. Effective simulations or models of the actual product. Agile Project Management Jim Highsmith
62 The Standish Group found that the number one reason that projects succeed is user involvement. Easy access to end-users is one of the three critical success factors in rapid-development projects. Good relationships with customers improve actual development speed. Good relations with customers improve perceived development speed. Rapid Development Steve McConnell
63 The four key characteristics or enablers of knowledge transfer in communication are: (1) Interactivity, (2) Bandwidth, (3) Structure, (4) Reusability Developing Knowledge-Based Client Relationships Ross Dawson
64 The underlying philosophy is that in smaller, less rigid structures, employees are closer to the customers and can respond faster. Managing the Change Process David K. Carr, Kelvin J. Hard, William J. Trahant. Coopers & Lybrand Center of Excellence for Change Management
65 Business rule solution: Real-time delivery of business logic to knowledge workers as errors actually occur creates a seamless, never-ending, self-training environment. Principles of the Business Rule Approach Ronald Ross
66 (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
67 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
68 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
69 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
70 There is no such thing as an easy implementation of an ERP project. Enterprise Resource Planning (ERP) The Great Gamble Ray Atkinson
71 Selecting the consultants (and an implementation methodology) is as important as selecting the (ERP) package. ERP Demystified Alexis Leon
72 The big bang approach promised to reduce the integration cost in conditions of thorough and careful execution. This method dominated early ERP implementations and it partially contributed to the higher rate of failure in its implementation. ERP Demystified Alexis Leon
73 There is no such thing as a competitive ERP implementation methodology. Only thing competitive for implementation partners are its people. Self-Quote Brett Beaubouef
74 It may take months to adjust learning curves with an organization. A major challenge in ERP implementation is the selection of the adequate training for the end-user and education. ERP Implementation Challenges & Critical Organization Success Factors Rajeshwar Vayyavur
75 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
76 In the absence of knowledge and ability you can expect lower utilization throughout the organization, incorrect usage of new processes and tools, a negative impact on customers and sustained reduction productivity. ADKAR – A Model for Change in Business, Government and Our Community Jeffrey M. Hiatt
77 If the project should start to derail, consultants are the easiest to blame. Why New Systems Fail Phil Simon
78 The organizational culture and the nature of projects will be different from company to company. Thus, two ERP implementations can never be identical. ERP Demystified Alexis Leon
79 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
80 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
81 Information and intelligence are half of the equation.   The other half is flexible and adaptive production processes that can swiftly respond to threats and/or opportunities. ERP Lessons Learned – Structured Process Wayne L. Staley
82 The rule is efficiency never trumps effectiveness. ERP Lessons Learned – Structured Process Wayne L. Staley
83 “Paralysis through analysis” in a futile attempt to develop the perfect solution. Control Your ERP Destiny Steven Scott Phillips
84 Companies need a systematic method of analyzing the impact of business processes and a more reliable way of introducing new process designs. Business Process Management – the third wave Howard Smith and Peter Fingar
85 When failure is not blamed but considered part of the learning process, people feel secure in taking bold steps outside their narrow territory, and that is when things start happening. Managing the Change Process David K. Carr, Kelvin J. Hard, William J. Trahant. Coopers & Lybrand Center of Excellence for Change Management
86 Where knowledge transfer is a key objective, project handover should be formalized, rather than just letting the engagement end. Developing Knowledge-Based Client Relationships Ross Dawson
87 Some people mistakenly assume that agility connotes a lack of structure, but the absence of structure, or stability, generated chaos. Conversely, too much structure generates rigidity. Agile Project Management Jim Highsmith
88 In order to manage these changes, it is important for the implementation team to document changes that must be made to individual jobs and execute plans to help people transition to their new jobs. E-Business and ERP Murrell G. Shields
89 ERP SaaS 101: Great customer service can overcome a multitude of software sins. Self-Quote Brett Beaubouef
90 ERP 101: How you gather business requirements sends a message. Self-Quote Brett Beaubouef

 

JIT is Just Plain Wrong for Cloud ERP

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:

Limited User Involvement

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.

Rethinking the Waterfall Testing Paradigm

If we take a stroll down memory lane we can recall the standard testing approach we learned from the Waterfall Software Development Lifecycle (SDLC):

Limited ERP Testing

Traditional Testing Approach

Consider the following:

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

  1. Additional validation of the solution via testing.
  2. 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:

Increasing User Involement

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

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:

JIT User Enablement

Potential issues/risks from take a JIT user enablement approach

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

Challenge to Cloud ERP Service Providers and Implementation Partners

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

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

Summary

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

Troubleshooting ERP Projects

During my career in ERP consulting I  had several opportunities to be involved in deployment of emerging ERP products and services.  As with any innovation rollout there are challenges to overcome and I had to learn how to quickly triage ERP projects for success.  Troubleshooting an ERP project is more than just performing an assessment – it’s implementing a realistic action plan and making it work for all stakeholders involved.   Following is a tested and proven approach to jumpstart stalled ERP projects.

Method

Similar to a Forest Fire Hotshot I typically got dropped into a “hot” ERP project that had stalled or had serious show stoppers.   Time is always against you.  However, you must first put in the effort to objectively understand the situation and establish your credibility:

Troubleshooting ERP Challenges

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

Key Project Documents

This is the easy part and it is usually a simple process to review and evaluate.  If a project scope statement does not exist or is not well-defined then chances are this absence is contributing to the problem.  Creating or refining the project scope statement is a very small part of the action plan you need to execute.  Now, let’s turn our attention to the implicit artifacts and information that are harder to identify and resolve.

Understand the Underlying Drivers

ERP vendors,  System Implementers (SIs), and Customers want their ERP implementation to be successful.  Yet there are fundamental drivers for each stakeholder  appears to be in contradiction.  Consider the following illustration:

ERP Stakeholder Implicit Drivers

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:

  1. Create quick wins.  Triage is required to stop the bleeding.  You need to quickly seize the initiative  and  create positive events.
  2. 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.
  3. Triage is not the time for lessons learned.  There will be opportunity for reflection after the immediate problem(s) have been addressed.
  4. 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.
  5. 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.
  6. 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:
Communication Skills

Survival Skill – Communications

Summary

There is a fair amount of information available in books, articles, and blogs related to avoiding ERP problems and I agree that you should take reasonable steps to minimize known ERP problems.  However, I believe that it is prudent to be prepared for the “unknown unknowns” that always occur with any ERP project.  Troubleshooting ERP projects require process knowledge of project management fundamentals, problem solving techniques, and most importantly – perseverance.  Just like the rudder steers the ship, finding small success(es) can get your ERP project back on the path for success.

ERP Project 101: Deployment vs Requirements Gathering

Customers, System implementers and ERP vendors are always looking for ways to accelerate ERP implementations.  One popular approach is to take a phased deployment approach based upon criteria such as location, ERP module or feature set.   Requirements are gathered, validated, and tested based upon a limited scope.  Unfortunately, many ERP projects utilizing this approach result in failure given requirements conflict and misaligned expectations.  In the following blog posting we will discuss how to minimize challenges associated with phased ERP deployments.

Reality Check!  There will be ERP requirements conflicts

A reality with any cross-functional or multi-site deployment is that there will be requirement conflicts as part of an ERP implementation.  In our focus for rapid results and simplifying ERP deployments we forget the fundamental result – an ERP implementation is the implementation of a business solution.  Consider the following illustration:

ERP REquirements Conflict

Example of Requirements Conflict for ERP

Let’s assume that we want to accelerate an ERP HR implementation by deploying ERP solution by region.   To further streamline our efforts the project only gather requirements from the North America HR stakeholders (Phase I). The above approach appears to work for the initial ERP deployment; however; these short-sighted decisions can have a negative impact to future deployments.   Remember that correcting problems and limitations are more costly once an ERP system is deployed in a production environment. 

With the above said, I appreciate that ERP vendors are evolving their ERP software to provide additional flexibility in configurations to allow variances based upon industry, line of business, country and even user preferences.  However, we should understand that all ERP solutions leverage a common data model with specific data dependencies.  We can address this constraint in one of two methods.  Either we take a risky approach of gathering requirements in silos hoping that we clearly define all ERP configuration dependencies or take the practical approach of gathering requirements across all HR operational areas. In the next section we discuss several practical steps to ensure requirements conflicts are minimize.

Practical Steps to Minimize ERP Requirements Conflict

Let’s brief speak to some common-sense approaches to deal with the reality of ERP requirements conflicts.

How to address ERP requirements conflicts

Practical approaches to address requirements conflicts

The first step of requirements management is to perform a stakeholder analysis to identify the appropriate business owners and subject matter experts in include in requirements gathering.  It is important to note that we always implement to a business process not simply to the software (ex. module, feature). Utilize solution modeling to analyze business requirements from multiple perspectives.  Too often I observe ERP projects spend more time on defining exceptions to standard business scenarios versus defining a common requirements set that can be leverage to isolate and manage unique requirement criteria.  Consider the following illustration:

 

Logical Business Requirements Model

Logical progression of gathering ERP requirements

There should be a logical progression of business requirements from the global level to the specific user level.  Isolate requirement exceptions to effectively quantify frequency, impact, and cost.  Utilizing this approach will provide the customer with greater insight for an informed decision.   Finally, let’s not forget the Lean principle that states process efficiency is gained when variability (exceptions) is minimized.

Summary & Conclusion

The ERP industry is hyper-competitive where every ERP vendor and System Implementer is looking for an edge to accelerate and reduce the costs associated with ERP implementations.  This desire is intensified by the entrance of ERP SaaS offerings with lower entry costs for a growing target market.  The challenge is to identify competent options for accelerating ERP implementations without putting long-term customer success at significant risk.  Requirements management (gathering, validating, and testing) is the critical discipline that impacts all downstream implementation activities.  Taking a technology-oriented approach results in (a) unclear requirements, (b) requirements conflicts, and (c) additional rework to support future deployments.  Making the right investments in requirements management will be the best chance to accelerate downstream activities including deployments.                    

BPR, BPM and ERP

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 BPM and BPR

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

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 Managed level.  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:

  1. Move from unique purchasing processes to a common enterprise purchasing model that is flexible enough to address the competitive requirements for each business line
  2. 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. 

How Do BPR, BPM, and ERP Relate?

ERP provides the automation of business activities.   There are two fundamental value propositions that ERP provide to customers looking to move up the CMMI maturity model

  1. 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.
  2. 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. 
ERP Business Process 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.   

ERP Evolution within CMMI

Interaction of BPR, BPM, and ERP within CMMI

I am a firm believer that business should lead and technology supports.  Therefore, as the business model evolves it is important to identify the corresponding ERP functionality to support the business activities.   This model also communicates that the best approach to implement ERP is to follow a logical maturity path for business processes.

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:

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

Summary

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. 

ERP Project 101: What + Why = How

One of the reasons why I am a consultant is that I enjoy solving business problems with technology. ERP provides a technical foundation that I can utilize to solve problems.  However, during my career I came to the realization that simply throwing technology at a business need is not in the best interest of the customer.  This is especially true when you do not completely understand the requirement.   There is a difference between an evolving requirement and an evolving understanding of the requirement.  In the next sections we will briefly review a practical approach for ERP requirements management.

 

Gathering Business Requirements is Just the Beginning

I think we all can agree that gathering business requirements is a key activity that will have a significant impact on ERP implementation success.  However, it is as equally important to focus on requirements validation before proceeding to implementing a solution for addressing requirements. Too often we jump from gather to design before we have a full appreciation of the business need.  When it comes to formal requirements management, I keep the following simple equation in mind:

Requirements Mgmt 101

Basic ERP Requirements Management

  

Defining What

Sounds simple enough but how you gather requirements sends a message.  Also, it is important to understand if the requirement is the result of a new opportunity or addressing an existing business pain.  The source should play a factor in your approach to gathering information.  Consider the following commonly accepted approaches utilized for gathering ERP business requirements:

 

Defining Requirements

Generally Accepted Requirements Gathering Methods

 

Please allow me to state that the above methods are valid and have their inherent advantages and disadvantages.  The challenge I find is not gathering the requirement but rather the limited effort spent on understanding how the requirement supports business process results. 

 

Determining Why

It is hard to provide a solution when you do not understand the business.  Asking why is less about challenging business requirements and more about gaining a better perspective of the requirement.  What are the desired result(s)?  How do the result(s) add value to the overall business process?   Odds are that you will have only a superficial understanding of the requirement if you do not understand the context (environment) of the business need.  Also note that asking why is the first step to validating your understanding of the business need.  Following is a list of the common validation activities for business requirements:

Confirming Requirements

Requirements validation techniques

 

I firmly believe that all four validation methods should be employed as part of defining business requirements.  Unfortunately, not all of these validation steps occur during the deployment.  The advantage with ERP is that you have working software that you can easily demonstrate and confirm how business requirements would be handled.  Do not guess – prove what is possible!

 

Constructing How

This process is typically an area that is not executed well when it comes to ERP.  In the rush for faster results many assume that the solution must be implemented via technology.   Technology is good for many activities (repeatable, logical) but it can also be a costly option for conflicting requirements across a business process.  As a rule of thumb, I typically consider 4 options for addressing business needs:

 

Addressing requirements

Options to address ERP requirements

 

  1. Automation: Developing a technical solution to address need.
  2. Business Process: Creating business process to address need.
  3. Acceptance:  Do nothing and handle as the need arises.
  4. Avoidance: Eliminating the source of the business need.

 

Understanding both the What and Why will provide you the right insight to select the most viable approach for implementation of the requirement.  It provides you with the perspective and context for effective decision-making.

 

Summary

An enterprise technology platform like ERP is an empowering toolset for addressing business needs across an organization.  Yet, soft skills like requirements management have a greater impact on business solution success.  It seems like every couple of years there is a “new” ERP methodology that will address the challenge of gathering ERP requirements.   Often I observed too much focus on the methodology and not enough effort focused on the end result.  I’m sure that I may receive some criticism from my peers in regards to my attempt to “dumb down” requirements management.  However, I have found that the best approach is a simple approach that every stakeholder can understand and recall instantly versus having to go to a methodology book.  

Building a Better ERP Estimate

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

Information Drivers for ERP Implementation Estimates

 Let’s focus on some specific areas that are typically overlooked or under appreciated. 

Area Description
Customer Participation 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 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.
Product Scope 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.

Levels of ERP Estimate Accuracies

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
    • Product Scope
    • Project Scope
    • Assumptions
    • Constraints
    • 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.

Summary 

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.

Follow

Get every new post delivered to your Inbox.

Join 6,549 other followers

%d bloggers like this: