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!
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!
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!
SaaS ERP is the latest effort in the ERP industry to provide a rapid, cost-effective solution for customers who want an enterprise solution. A SaaS deployment model does provide the potential for greater value realization; however, the value proposition is dependent upon appropriate expectations and implementation approach. The purpose of the following article is to provide insight to ensure customers make realistic and informed decisions.
General Expectations for SaaS ERP
I firmly believe that one of the key reasons for failed ERP implementations is that expectations were not correctly established and managed throughout the implementation. Consider the following:
Common Expectations of SaaS ERP
Cheap: The customer does not need to make a huge expenditure to implement and utilize.
Fast: Answer a few questions and have an up and running software in weeks.
Flexible: Business users can make changes. Minimize IT involvement.
Intuitive: Quick to learn and easy to navigate.
We can all agree that the above targets are worthy goals of any ERP solution. However, this is only part of the story. The next section discusses the efforts required to achieve the goals listed.
Desired Results of SaaS ERP
To better understand ERP SaaS expectations we need to elaborate on the desired results that should be realized by customers.
Elaborating on SaaS ERP Expectations
Some of the desired results are directly addressed by the SaaS model but the majority of results are addressed either by (a) the ERP software architecture or (b) the delivery model. Example: SaaS ERP does not require an initial outlay of funding for capital expenditures for hardware and related infrastructure. SaaS ERP eliminates the need for a separate effort for ERP software installation and certification. Yet, it is important to remember that ERP software installation represents at most 5% of the total time required to implement an ERP solution. Therefore the SaaS model by itself does not have a dramatic impact on accelerating ERP implementations.
SaaS ERP Realities
Allow me to share some observations I have regarding the ERP SaaS model that may not appear to be readily evident:
Let’s take one of the above desired results to elaborate on the above diagram. A goal for SaaS ERP is to reduce the Total Cost of Ownership (TCO). One of the key ERP design strategies is to enable business users to tailor the functionality to meet requirements without having IT to make a costly customization. However, it is important to understand the shift of effort from IT to functional users. There may be a reduction in the effort or a change in the nature of the work but the effort is still required. There is no “push button” to eliminate this work.
For another example let’s take the ERP value stream. ERP vendors can create additional value to customers by providing new and enhanced functionality. The leading SaaS ERP delivery model should provide a 3:1 ratio increase in the software release cycle. Yet, it is important to realize that more frequent ERP software releases require additional testing and deployment (organizational change) work. It is interesting to note that many of the leading SaaS ERP vendors do provide an out-of-the-box testing automation solution. Again, the customer will experience a shift from technical to functional effort.
Sorry if I burst your bubble, but I rather have an informed customer that will have reasonable expectations versus a customer with unrealistic expectations. SaaS ERP is one of many delivery models that ERP vendors offer to customers. While it is true that SaaS ERP provide customers with new options not available previously, it is not a slam dunk for all customers. Developing the customer’s use case and understanding all technical and organizational impacts will better ensure an informed decision is reached.
Join the community! 10k followers across 100 countries!
With the initial release of ERP, one of the key “game changers” was the ability of business users to access data and generates reports without direct IT involvement. This empowerment of the business user had a significant impact on business agility. Today, we continue to see ERP vendors focus on providing business-friendly tools for reporting and analysis. Yet, I can see a new evolution brewing in the ERP industry what I like to call “Adaptive ERP” where business users can perform on-demand actions to meet business changes real-time. In the next sections we discuss the key capabilities of Adaptive ERP and a practical assessment of where the ERP industry is today.
What is Adaptive ERP?
Adaptive ERP would enable business users to configure, simulate, test, and implement business technology changes with limited traditional IT services (ex. software development). Predictive analysis will become a reality. Logical thinking and search methods will be more valuable than technical syntax. Information will become context and even transactional specific. Following is an illustration of the major domains that Adaptive ERP should address:
Conceptual Model of Adaptive ERP
Domain: Logical Development
Too often a change in the business model requires an IT development effort. Any competent IT development will require the following activities:
Business requirements gathering
Unit, System testing
In general, the greater the number of individuals involved in a project the greater the coordination/communication effort resulting in a greater time commitment. Enabling business to become agile will require an evolutionary change in how ERP supports business activities. However, simply removing people out of the equation is not the answer. What is required is providing business owners the tools and experience required to become more self-sufficient.
Logical Development for ERP
Following is a brief list of the capabilities required to enable business users to perform logical development
Business models must be defined as metadata within the ERP software.
Business rules are separate from technical components and are exposed directly to business users.
Business scenarios are defined separate from the respective business models. Business exceptions are variations to a specific business scenario.
Business users should have the ability to run simulations in production (i.e. parallel testing)
ERP must provide automated testing support
Automated unit and system testing (self-learning via business model metadata).
Automated business process test scripting.
Test scripts are a results-oriented view of business requirements.
Automated impact analysis with logical development change.
Business users should be trained in logical and structured thinking. There has to be a prescribed process to effectively conduct knowledge transfer with the ERP software. Business users should be able to directly educate (i.e. configure) the ERP software on how they run their business.
Today, there is interest in Big Data and Enterprise 2.0 technologies but they are not the final destination.
At the end of the day, business decisions have an impact on business results. Enterprise 2.0 and Big Data are supportive technologies. Enterprise 2.0 focuses on the utilization of Web 2.0 standards in developing collaborative technologies like blogs, RSS, social bookmarking, social networking and wikis. Enterprise 2.0 emphasizes employee, partner and consumer collaboration for creating knowledge. Big Data is the next evolution in Knowledge Management where it is now viable to manage and utilize both structured and unstructured data. However, the key challenge remains – how to effectively leverage all the information we are collecting. We need to flip the following time paradigm:
Business Information Cycle
Changing this paradigm will require inference engines that streamline analysis generation and enable predictive analysis. Following is a brief list of capabilities that will support predictive analysis:
Case-Based Inference will provide recommendations based upon data and transactional patterns.
Rules-Based Inference will provide tactical, operational decision support based upon standard business principles.
Big Data will facilitate the assimilation of structured and unstructured data to identify patterns and provide operational context.
Collaborative ERP 2.0 will support collaborative discussions and provide transactional context for decision support.
Advancements like this in analytics will enable business users to focus on the value-add activities of reviewing analysis and drawing conclusions for effective business decisions.
Whether or not you are sold on open source ERP, you have to admire the new paradigm and simplicity that open source ERP promotes. As we continue to see the consumerization of legacy ERP technologies, the market will continue to drive individual user enablement and vendor independence. Following is a brief list of capabilities that will promote a more open ERP industry
BYOD (Bring Your Own Device)will enableemployees are able to bring their own computing devices – such as smartphones, laptops and PDAs – to the workplace for use and connectivity on the corporate network.
BPMN compliance will ensure that ERP business process definitions will agree with business process definition standards outlined in the Business Process Modeling Notation (BPMN) model. This model is governed by the Object Management Group (OMG). In my humble opinion, the OMG is in the best position to define a global standard for business process models. This advancement will be a key enabler to the holy grail of true enterprise system interoperability. This is no small task and will require significant market demand to promote this standardization initiative.
Collaborative Shared Development is a key benefit of an open community. Sometimes it takes a village of developers to support an ERP solution. Today, I can go to the Apple App Store to purchase an app for my iPhone. In the future, we should see an ERP App Store when a customer or an individual business user can download an object (software, report, role-based feature) to customize their ERP experience.
Open Partner Network. The more integrated your ERP is within your business value chain (suppliers, vendors, customers, providers) the more powerful your ERP system can be. I expect we will see the ERP market put more value in delivered integrations with partner, supplier, and provider networks over software product features. SOA will be a key enabler for making open partner networks a reality.
Openness is about creating flexibility and the freedom for a customer to respond to the changing business environment in the most effective manner.
Domain: Viable Solutions
A profound lesson I learned the hard way is that regardless of how many features and products an ERP vendor can provide (even for free); it will all be all in vain if the software is unmanageable. It is unacceptable that a customer has to pay triple and even quadruple the original software cost to maintain their ERP investment. Some may argue that ERP vendors have not acted in the best interest of their customers by building features upon features without providing tools to significantly reduce the Total Cost of Ownership (TCO).
Simplifying Technical Support
Following is a brief list of capabilities that will significantly reduce TCO:
Automated testing (self-learning tools).
Automated master data management (information awareness tools).
Eliminate the need for multiple instances.
Assimilated, holistic solutions– loosely coupled point systems will not work and result in greater costs and possible failures.
Minimize the technical stack.
Higher Quality Assurance
Upgrades/Software Maintenance releases included the test cases and results performed by the ERP vendor.
Software architecture can support either single or multiple tenants.
On-Premise, Hosted, Public Cloud, Private Cloud for either applications and/or data.
Example: Customer decides to store mission-critical data on-premise and internal data on the public cloud.
It should no longer be acceptable that an ERP customer has to totally shoulder additional implementation and upgrade costs. This is not indicative of a true partnership.
Challenge to ERP Industry for Adaptive ERP
Today, we continue to see a consolidation of the ERP industry. With these acquisitions some ERP vendors provide some limited capabilities of Adaptive ERP but these capabilities are spread across multiple software products and platforms. An ERP solution is only as strong as its weakest link (integration). More technologies loosely coupled together usually mean (a) more IT resources, (b) additional points of failure, and (c) a more complicated experience for business users. We have witnessed where ERP software has become bloated with features upon features without any logical progression. ERP customers are forced to deal and pay for unused features resulting in more frustration than simplicity.
Many top-tier ERP software solution packages use a systems configuration concept to set up the business environment for some time but please allow me to challenge the industry a little more. I agree that several ERP software packages provides configuration concept yet there is no clear decrease in implementation schedule (ex. SAP) or cost savings associated with this approach because the currently exposed configurations do not change that frequently (ex. Earning Codes, GL Accounts). Objects like business rules, scenarios, and exceptions change more frequently. This is a challenge for some ERP software (ex. PeopleSoft) where many business rules are encapsulated within the technical object. Pre-configurations are only a beginning – it adds value in the short-term but ERP is a long-term proposition. In my humble opinion, the key is to expose the underlying business model to business users for greater real-time interaction.
Also, there are Master Data Management (MDM) solutions available to support a tactical level of data governance by removing duplicates, standardizing data and, incorporating rules to eliminate incorrect data from entering the ERP system. For Adaptive ERP, MDM must advance in what I call “information awareness”. Information awareness means two things (1) MDM is able to automatically detect and define new information sources within the enterprise ecosystem via data polling, and (2) MDM is able to determine how data is used. These capabilities will be key enablers for automated impact analysis.
What we need to have is a mature, open, holistic solution where all the individual software platforms are assimilated into a robust, uniformed solution. This is not simply building a dashboard that brings together two separate user sessions together or an orchestration level that adds another level of technology abstraction and performance overhead. A viable solution is a manageable solution.
I’m a firm believer in performing non-competitive business activities as competent and cheap as possible. In that end I am a firm believer in ERP. However, the ERP industry has come up short in the areas of total cost of ownership and business adaptability. Many on both sides of the aisle have wrongly concluded that more software features and increasing the technical stack are the answers for making ERP adaptable. Putting more power in the hand of business users is the strategic answer for business agility. People are the most important and adaptive component of a business solution.
To customize or not to customize – that is the question which continues to be a source of contention and confusion. On one hand, customization(s) can result in an expensive ERP solution. However, ERP software enhancements can provide a competitive advantage or cost reduction that is customer-specific. The challenge is not in the question itself but rather how the answer is justified. Unfortunately, many business cases for ERP customizations are either too short-sighted or do not fully comprehend the impacts to the ERP investment. In the next section we will discuss the key components required for an ERP business case for customization(s).
Business Case Overview
Following is a business case template I’ve used as a consultant to justify ERP customizations.
Let’s briefly discuss each section in greater detail. The Problem (or Opportunity) section should clearly define the issue(s) as well as the target audience who will benefit from addressing the problem. The problem section should also explain the compelling reason (s) why the problem should be addressed. The Solution section should speak directly to solving the problem or addressing the opportunity. The solution section must include the method(s) used to validate that the proposed solution solved the defined problem.
The Approach section details the viable methods available to implement the solution. The approach section should not be a theoretically exploration of all possible options. Too often I have observed where unrealistic approaches were defined, which did more to confuse decision makers rather than create a focused, compelling argument. In general, I typically provide three approaches when pitching an ERP customization:
Full Customization (Extreme)
Partial Customization (Middle of the Road)
Out Of The Box (OOTB) (Extreme)
Following is a generic example of comparing the above options:
Moving back to the business case, the Risk Assessment section outlines the risk(s) associated with each approach option defined in the previous section as well as identifying the risk(s) of doing nothing to address the problem/opportunity. The final section is the Value Analysis section. The key challenge I have noted is that short-term value methods (examples: benefit/cost analysis, payback period) are used to support a decision with a long-term impact. In the next section we will discuss the unique considerations one must address in developing a valid ERP software customization value analysis.
Value Assessment Considerations for ERP
In addition to the short-term costs associated with ERP customizations one must consider the following areas to calculate the long-term costs:
Impact to Upgrade and Maintenance: What is the impact that the customization will have to the ERP maintenance and upgrade process. Is the software customization intrusive? – Meaning is it an add-on enhancement or a fundamental change to how the ERP software works? The more intrusive the customization is the greater the costs required for ERP support and upgrades. Frequent ERP upgrades are a key strategy for driving additional business value.
Impact to IT Resource Sourcing: The more you customize the ERP software the more customer-specific ERP knowledge an IT resource requires to provide an effective level of service. Additional customizations will have a shrinking effect on the IT resource pool and may have the potential of driving up related IT support costs.
Cumulative Impact to the IT Footprint: Too often we consider customizations individually and not part of the total ERP software changes made. A field change here or a new application page may not seem like a big deal but you must remember that you must support everything you customize.
The above areas will ensure that you generate a holistic set of information for an informed decision. Too often, short-sighted decisions are made to customize ERP without completely understanding the potential impacts. The next section will shed more light on some of the less obvious risks associated with not having a holistic business case.
Risks of not developing an effective ERP customization business case
Incomplete information results in incomplete decisions and more importantly – missed expectations and business results. Following are a few of the key risks generated from over-customizing your ERP software:
Greater operational costs: There is an additional cost associated with customizations –typically required from the IT organization to support and manage the software changes.
Slower deployments of technology: With additional technology dependencies generated by ERP customizations come the additional planning and testing activities required to deploy new ERP functionality.
Lost opportunity costs: This is an area that is typically overlooked in customization value analysis. It is more than just comparing one ERP customization to another but also identifying the potential reduction in flexibility ERP software can provide to the business.
ERP is a long-term proposition and requires a long-term business case and value analysis for any change in the ERP’s value proposition. Too often decisions on ERP customizations are based upon partial information and are made in isolation. ERP is only one component of a business solution. Business processes and People have a greater impact on business results.
Granted, the full impact of a customization decision may not be fully appreciated in the short-term but poor decisions will build into a formidable wave that will keep you from experiencing value from your ERP investment.
Join the community! 10k followers across 100 countries!
Instinctively, we all try to avoid or minimize pain. This is true for individuals as well as business organizations. However, in our attempts to reduce pain, we too often focus on eliminating the symptoms without addressing the underlying root cause. We may feel temporary relieve but our short-term decisions only lead us to a point were the pain resurfaces and the available options to address the pain become more limited and costly. In the next sections, we will discuss how to address business pain by effectively utilizing your existing ERP investment.
Step #1 – Take an appropriate problem solving approach
Following is a standard problem-solving approach as defined in the Project Management Institute’s Body of Knowledge (PMBOK).
Root Cause Analysis
Seems easy enough! The challenge I’ve observed is that many organizations do not execute the problem-solving process effectively. To compound this challenge many customers believe that having an ERP system somehow accelerates or simplifies the problem-solving process. Following are some of the common misconceptions that cause ERP customers to miss the mark in solving problems.
Missing the Mark
The misperceptions and inappropriate expectations surrounding ERP can cloud your view of the real problem. However, the greater hindrances to effective problem solving are the views that (a) pain is bad, and (b) quick-fixes are more desirable (demanded) than permanent solutions to business problems. For an ERP perspective, the typical end-result to quick fixes will be more customizations. Greater customizations result in less flexibility and more costs. If unchecked, your organization can build band aid fixes on top of one another,which may ultimately result in a catastrophic event. The key to eliminating this quick-fix mentality is to change the perspective of how pain is viewed.
Step #2 – See business pain as an opportunity
My daughter loves to play volleyball. Recently, she has experienced some pain with her ankles as well as experienced some falls that caused my wife and me to have concerns. I suspect that I’m a little over-sensitive given that our daughter has Type-1 diabetes. We took our daughter to see a sports physician specialist to identify the problem. “Your daughter has a good problem to have.,” said the specialist, “she is still growing! Your daughter is still figuring out how to coordinate her changing limbs.” Whew! What at relief yet what a good life lesson. Too often, organizations can’t see past the present pain. We focus only on the symptoms (negatives) without looking for the opportunities (positives).
Many times, IT organizations are motivated by addressing problems by taking a “triage” or ‘fire-fighting” mentality. IT performance metrics can support this mentality if the focus is only on cycle-time and response-time metrics. Don’t get me wrong, if a production system goes offline unexpectedly, you can bet that a quick response is warranted. A red flag to look for is when ERP support problems are seen as an inconvenience rather than an opportunity. This can be especially frustrating to IT when the problem is a recurring issue. When viewed as a hindrance there is the natural human tendency to deal with the issue as quickly as possible to move on to the next problem. To get out of the above support rut first we need to eliminate or minimize reoccurring problems through effective problem solving. Once performed the IT organization can spend the time to evaluate viable options for greater ERP value generation.
Step #3 – Use business pain as a driver to increase ERP value generation
During my career as an ERP consultant, one of the key challenges I faced with every one of my customers was how to drive additional value from their ERP investment. As I did additional analysis, a common theme across my customers was that they did not realize the rapid deployment of new ERP functionality. Based upon my experience, I have identified the top three strategies that support long-term, rapid delivery from ERP.
Rapid Deployment Strategies for ERP
As seen from the illustration above the single largest driver for long-term, rapid delivery of addition value from a customer’s ERP investment is frequent upgrades. However, in the effort to address tactical business pain quickly IT organizations built customizations as quick fixes instead of allowing these opportunities to drive the value proposition for an ERP upgrade. It is important that the internal IT organization resist the temptation for a quick win and illuminate the IT roadmap that will provide the opportunity for greater value from their ERP investment. In the next section, we will briefly discuss the price to be paid if one uses ERP as a means to a quick fix.
The price of ERP quick fixes
There is a price associated with every decision made. In the case of ERP, the short-term gains will eventually result in limiting your ERP strategy. ERP quick fixes are typically implemented as customizations. Customizations require a greater level of support from the customer’s IT organization (because ERP vendors do not support customizations). IT spends more time performing support activities (indirect business value) versus building new enhancements (direct business value).
Second, customizations add to the upgrade effort. Third – and most important – performing quick fixes send a signal to customers that counters the basic value proposition of ERP (packaged) software. The price of ERP quick fixes may be small at first but they will have a compounding effect on the Total Cost of Ownership (TCO).
Pain is the way our bodies (and organizations) communicate that something is wrong. It defines the gap between where we are and where we want to be. Effective root-cause analysis is the first step to correctly diagnoses the pain and identify viable solutions. ERP can play a positive or sometimes negative role in addressing business pains. The key to understand how to correctly apply ERP technology to transform business pains into opportunities for greater business value.
Every customer I assisted in their ERP implementation wanted an ERP solution that would be flexible and adaptable. One of the key challenges and disappointments customers have with ERP are around flexibility and adaptability. We also need to address the common misinterpretations associated with the concepts of a flexible and adaptable ERP solution. Referring back to a previous blog we know that ERP is only one component of a business solution. There are three key areas to address as part of developing a flexible and adaptable business solution.
Know The Limitations
Technically speaking, there are two key methods to enable packaged software like ERP to be flexible and adaptable:
Programming (addresses flexibility or the ability to change)
Configuration (addresses adaptability or the ability to easily change)
Each of these methods has inherent advantages and challenges associated with them. Configuration has been a key area of focus for ERP vendors to create greater software adaptability. Configurations enable less technical, business-oriented users to determine how ERP behaves to specific events and conditions. Configuration provides the opportunity for cost-effective flexibility to meet the unique business requirements. However, where there is no option for configuration then programming must be used to enable ERP software the flexibility to meet the unique requirement.
Programming provides an exact prescription to address a specific business event, condition, or activity. There are programming techniques and add-on utilities that provide some level of technical flexibility (examples: object-oriented programming, services-oriented architecture) but business flexibility is extremely limited at best (unless an ERP vendor can devise a practical means of applying artificial intelligence – fuzzy logic to their software). There are limitations with the amount of flexibility and adaptability you can create via software. What is important to remember is that there are other components of a business solution that better suited to address flexibility and adaptability.
Know Your Strengths
Let’s revisit the components of a business solution along with their inherent strengths.
Business Solution Strengths
Too often we do not effectively utilize the strengths of the key components of a business solution. ERP software is good at automating consistent, repeatable activities based upon a prescribed logic (business rules). ERP software is not a sustainable, cost-effective option for dynamic activities based upon fuzzy logic (business rules). People are more flexible and adaptable than ERP software. Please do not take the above statement to an extreme and infer that every customer should conform their business activities to the ERP software. ERP implementations should include software enhancements to address the unique value-add requirements of a customer.
Flexibility and adaptability only have value within the context of enabling ERP to position itself optimally in supporting key business drivers. Next, we will discuss the common drivers that must be coordinated as part of addressing flexibility and adaptability.
Every customer will have unique business drivers that must be managed in a balanced approach. Given my implementation experience following are what I consider the common business drivers that we might address as part of an ERP implementation.
A balanced ERP solution
Can we have a flexible and adaptable ERP solution? I believe that the answer is yes. Can we have an efficient and effective ERP solution? Yes. Can we have a scalable and efficient solution? Yes, however we can only experience both characteristics to a certain level. The challenge I observed is when an extreme position is taken in one of these areas. Like a ball on a flat table once we start tilting the table (taking an extreme position) the ball will roll off the table – – along with your ERP implementation.
Finding balance is an ongoing exercise to find the right level of applying the influence of the specific business driver upon the ERP project. It is also important to know and understand at what level of influence will business drivers start conflicting with one another.
Flexibility and adaptability are reasonable expectations for a business solution. The key challenges in this area tend to be around inaccurate expectations and not effectively utilizing the individual components of a business solution. What is required is a practical analysis of the strengths, weaknesses, and business drivers to develop a balanced approach for success. This analysis is not a one-time event but a continuous effort that is triggered when emerging pain is experienced. Experiencing pain provides the opportunity for rebalancing your ERP solution.