There are not many public theories on how to maximize ERP utilization. There are approaches that do a commendable effort in identifying some of the factors that influence ERP utilization. What is lacking are predictability, repeatability and harmony across the key components of a business solution. In my 25 years of ERP consulting experience, I have never encountered a single customer that utilized over 80% of the ERP software. Given the lack of utilization and the money needed for Cloud ERP implementations, I am convinced this is a problem that finally must be solved! We are in the second generation of ERP software and the only advancement that we in the ERP implementation arena have made is to retract our initial recommendation of customizing ERP for greater customer value!

The purpose of this article is to provide an overview of my theory on ERP utilization. The scope of this article will focus on the Cloud ERP deployment model. I have yet to complete the rigors of the scientific method to verify my theory. However, I would like to share my concepts with you and partner with you in growing the collective knowledge.

Before we jump into the model there is a fundamental assumption that must be addressed. First and foremost, services trump software in an ERP cloud delivery model. If the customer does not have any reliance or trust on the available ERP services, the window for greater ERP utilization is exponentially reduced. Given the assumption that the ERP Cloud vendor provides a competent level of cloud ERP services (prerequisite), I will explain my theory on ERP utilization.

ERP Utilization Is More about Enablement and Less about Automation

First we need to revisit the concept of a business solution, the key components, their relationship, and influence on ERP utilization.

Business Solution Defined

Just as technology has the smallest part to play in ERP implementation success, ERP software has a smaller role to play in ERP utilization. Business process maturity and the organization’s ability to change have a greater impact on ERP utilization. To elaborate on this thesis I will make use of two models:

The reasons why I selected CMMI as the business process maturity model are (1) general adoption and acceptance, and (2) business process maturity characteristics can be observed. I appreciate the fact that CMMI primarily focuses on software development activities and unfortunately ignores business process re-engineering. However, I believe that the CMMI model as effective model to elaborate on my themes on ERP utilization.

I find that Organizational Change Management (OCM) is more of a project-based effort to enable an organization to meet a specific event. This approach works very well with an On-Premise ERP solution where upgrades are measured in years. However, in the more dynamic Cloud ERP solution model, change is more rapid. ERP Cloud updates and upgrades happen in months, not years. What I really like about OCC is the greater focus of providing the organization with the skills and flexibility to handle known and unknown changes. Organizations change one person at a time and if every person has the capacity to be a change agent, then naturally the organization will adopt and manage change faster. OCC is an emerging model, thus there is limited content regarding how to assess and measure OCC for an organization.

If an organization has to wait on an ERP Cloud vendor or a Systems Implementation (SI) consultant to provide guidance on ERP utilization strategies then there is a high probability that the organization will never reach their ultimate goal of effective ERP utilization. The organization’s ERP experience will be more reactive than proactive.

With all that said, consider the following conceptual model:

Linear Regressive Model for ERP Utilization

I propose a multivariate linear regression relationship between business process maturity, organizational capacity model for change with potential ERP utilization. This simplified model is based on the following assumptions:

A set of ERP features require a certain level of organizational and business process maturity for a successful experience. For additional information, see my article on Business Leads and Technology Supports.

Based upon the CMMI level and OCC for the customer, we can infer the ERP features required for a maximum ERP effectiveness.

OCC has a greater influence than CMMI on effective ERP utilization.

Software changes will happen more rapidly in an ERP Cloud delivery model versus a tradition ERP On-Premise model. Therefore, OCC must become an ongoing competency (versus a one-time effort) for long-term ERP success.

“It is generally not fruitful to impose a very sophisticated process on an organization whose maturity is low. The maturity of an organization not only depends on the skill sets of the individuals, but also on the chemistry of the team.” (Alexia Leon, 2012)

Based on the above model, I conclude that customer enablement must be an ongoing exercise that runs in parallel or even precedes ERP automation.

Model versus Reality

I consider myself more of a pragmatist than a theorist. Models are great to elaborate upon concept(s) for discussion and argument. However, conceptual models are limited in the value they provide to customers if there is no method to align reality (i.e., “as is”) with the optimal path. Consider the following illustration:

Actual Versus Model

Key Points and Observations:

In a majority of cases, there is a difference between potential ERP utilization and actual ERP utilization experienced by customers.

In order to promote repeatability, there should be a logical progression that enables customers to maximize ERP utilization (i.e., roadmap).

To minimize ERP Total Cost of Ownership (TCO) and eliminate cost constraints, ERP Cloud vendors should provide customers with the ability to increase ERP utilization without heavily relying on consulting services.

As we continue with the model elaboration, we find that there are regions that are not practical for a given business process maturity and organizational capacity change values. Consider the following:

Potential Values for CMMI & OCC for ERP Utilization prediction

Key Points and Observations:

Areas in red represent a subset of possible values given that the scenario occurrence is highly improbable. For example, an organization with a CMMI level 1 maturity cannot expect to utilize 100% of the features available for a Cloud ERP service.

The goal is to define an ERP utilization approach that is repeatable and reliable. Far too often, customers spend thousands of dollars on a “point in time” ERP strategy that requires additional funds to revise the strategy as the ERP technology changes. The ERP utilization strategy must start with “where the customer is at” and provide a series of ERP features and prerequisite enablement activities in order to increase utilization.

ERP Utilization Roadmap

I propose that long-term ERP utilization should be a series of incremental quick-wins (i.e., Business Process Management) and paradigm shifts (i.e., Business Process Re-engineering). Consider the following illustration:

ERP Utilization Roadmap

Key points and observations:

Any deployment of ERP features that require a significant organization change is not a quick win. People do not change overnight.

An incremental approach like Business Process Management (BPM) is required when deploying new ERP features at the same CMMI level for a given business process.

Set X includes the BPM enablement activities and ERP feature deployments required to align with the logical maturity path. Note that only incremental change is required to implement targeted ERP features (thus, a quick-win).

A radical approach like Business Process Re-engineering (BPR) is required when deploying new features across multiple CMMI levels for a given business process.

Set Y includes the BPR enablement activities and ERP feature(s) deployment required to align with the logical maturity path.

The practical aspects of this model are (1) the roadmap must start where the customer is at in their business process maturity, (2) utilize an increment (agile) approach to build organization momentum, and (3) realize that organizational momentum will carry a customer through the radical changes required for maximizing ERP utilization.

Leveraging the CMMI model as an example of business process maturity, there are incremental organizational change required to process from one maturity level to the next level. However, based upon my experience, there are two key paradigm shifts that must happen in the collective mind of the organization. Consider the following illustration:

Paradigm Shifts for ERP Utilization

Key Points and Observations:

Z represents the paradigm shift from a functional business function focus to a business process focus for organizational optimization.

Z’ represents the paradigm shift that competitive advantage only comes from revenue-generating business processes. Organizations have a limited amount of resources and should prioritize business process maturity priorities accordingly.

Next, I will elaborate on why these paradigm shifts must happen within the CMMI maturity model. Let us refer back to the specific level definitions within the CMMI model:

CMMI Level Characteristics

I conclude that a prerequisite for a business process to mature to a CMMI level 3 (Defined) requires the organization to acknowledge and manage across multiple functional areas (Z). The ability to be more proactive requires a robust communication and coordination of business activities across multiple functional departments. It signifies the first step of an organization to evolve from the traditional management philosophy of “division of labor”.

The next paradigm shift (Z’) requires the customer to understand that (1) some business process (es) are more important than others (i.e., revenue-generating vs revenue-supporting), and (2) an organization has only so many resources (constraint). As we move forward in a hyper-competitive market environment, additional pressures will continue to minimize costs. The model states that all business processes can mature to a CMMI level 5 but the cost realities suggests a greater focus on the competitive, revenue-generating business process (es).

Speaking from practical “hands-on” experience, if customers never breaks through these paradigms then the customer’s Cloud ERP experience will be frustrating rather than enabling. There is no such thing as a “steady state” for Cloud ERP. Either the customer is moving forward with deploying new ERP Cloud features or fixated on the limitations of their ERP Cloud services.

Summary

Even with a cloud delivery model, the key cost associated with ERP has not dramatically decreased. The ratio of ERP software cost to ERP implementation cost has increased from 3:1 to 6:1. It is only a matter of time before the ERP market forces ERP vendors to drastically reduce implementation costs while maintaining a sufficient level of customer enablement. Given the rise and general adoption for Cloud ERP services, ERP utilization is becoming a more strategic competitive advantage for Cloud ERP vendors. What I see as an emerging demand from the ERP market is a reliable, repeatable method for maximum ERP utilization. I have cast the first stone – let’s see what evolves from the ripples in the pond.

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 3000 quotes on ERP-related topics (pains, success, best practices, failures, mistakes, implementations, selections). Here are my top 300 quotes.

#

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.

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.

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.

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).

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

“Certified consultants are able to translate business requirements into software configurations far more effectively than non-certified consultants. They can also provide a much more realistic forecast of what your CRM will entail in terms of time and resource requirements. “

During a period of organizational change, a company’s reward structure should be linked to achievement of the goals mandated by the change. The policies and procedures for rewards and censures must be made known to all employees at all levels, and must be implemented fairly and impartially.

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.

The cost of complexity isn’t offset by what you can charge. Complexity creates opportunities for you to fail your customer.

Wall Street Journal, 9-17-2002)

Gerand Arpey – American Airlines President

110

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).

Are the business processes that will be automated clearly understood and documented? An adage says, “If you don’t know where you’re going, any road will take you there.” The software equivalent is less positive “If you don’t know what it is you’re automating, no system will help”.

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.

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.

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.

When data lacks high quality, it is useless regardless of the supporting IT infrastructure in place. There is where data governance comes in. Data governance involves the creation and management of the organization structures, policies and processes needed to define, control, and ensure the quality of enterprise data.

To ensure rapid and smooth implementation, team members must be capable of dedicating 60 to 100 percent of their time to the ERP project. Lower committed times of 20 to 30 percent, or less, do not work well because of the high learning curves required for ERP implementations.

Regarding methodologies, there is nothing new under the sun. Every methodology is based upon a set of rules, environmental conditions and assumptions. All have strengths and challenges that must be addressed for success.

Given that we are well in the third decade of ERP implementations, I still observe ERP implementations following outdated/misguided concepts that do not utilize limited resources to the fullest. One of these misapplied concepts is Just-In-Time (JIT) training. End user enablement continues to be an implementation challenge primarily due to the limited investment made for the most important component of an ERP business solution. This limitation must be addressed in order to realize the value of ERP in the Cloud.

Evolving Traditional ERP Testing for Cloud ERP

Consider the following illustration that highlights the tradition user involvement model:

Traditional User Involvement

Traditional ERP implementation approaches view end users as an audience versus an active participant to leverage during the entire implementation. End users by far make up the largest stakeholder group in an ERP implementation however; they have the least amount of involvement and responsibility. Let’s further contrast and identify opportunities where end-user involvement can have a positive influence on ERP implementations.

The majority of testing and hands-on experience occurs with a limited group of users leaving a small window for direct users to gain confidence and experience with the ERP system.

The limitation with direct user involvement is based on the premise that a working system is not available until the end of the implementation. This is not the case with a Cloud ERP system that can be provisioned early during the implementation life cycle.

JIT End User training is a big bang approach – one time shot to get end-user training right. It also gives end users limited time to internalize the change. This approach naturally requires additional support and creates a greater potential for user errors.

Waterfall is based upon software being developed from scratch – i.e. you could not actively involved end users until the software existed. When ERP came to the market many approach/processes designed for software development were incorrectly applied to ERP implementations. The next section we will discuss how to involve the target audience sooner during a Cloud ERP implementation.

Increasing End User Involvement

There are two key value propositions for increasing end-user involvement:

Additional validation of the solution via testing.

Greater user adoption and enablement.

For robust testing business users should first be trained on the ERP Cloud service. Remember that testing can be “hands-on” learning for business users. Consider the following illustration:

Incremental User Involvement with ERP Implementations

Let’s expand on some key themes. First, education/learning is an iterative process where new information needs to be assimilated by users before knowledge is created. Second, an educated user is a better contributor to the project. Third, it is easier to manage and support educated end users. A forward-thinking end-user enablement process drives greater participation and ownership.

Consequences of Not Evolving your User Enablement Approach

As ERP Cloud adoption continues we will see an increase in the following implementation drivers:

Market Drivers for ERP Cloud Implementations

Consider that traditional ERP implementation approaches do not effectively leverage the largest resource pool available. I can appreciate that with additional resources comes greater coordination and communication channels (N * (N-1) / 2) yet I have witnessed that the business value outweighs the associated project risk. With the above said I do not recommend we start involving end users without some level of enablement and guidance. Just as an individual user learns a new system over time the end-user training approach should incrementally prepare the user for greater involvement during the ERP Cloud implementation.

Following are key consequences if we continue with a JIT user involvement strategy:

Potential issues/risks from take a JIT user enablement approach

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

Challenge to Cloud ERP Service Providers and Implementation Partners

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

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

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.

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:

Information Source

Comments

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:

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.

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

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.

I had a customer ask me about the relationship between BPM and ERP. Does ERP implement BPM or do you need to have BPM before ERP? Is an ERP implementation a BPR project? Who’s on first? As the ERP industry evolves it has become evident that additional disciplines like Business Process Management (BPM) and Business Process Reengineering (BPR) must be employed for a successful ERP experience. In the following blog posting I plan to define and demonstrate the roles that BPM/BPR play in the ERP lifecycle.

BPR, BPM, and ERP Revisited

Allow me to establish some basic definitions for our discussion:

Business Process Management (BPM) consists of methods, techniques and tools to design, deploy, control, and analyze operational business processes involving humans, organizations, applications, documents and other sources of information.

Business Process Reengineering (BPR) is the redesign of business processes – and the systems, policies, and organizational structures that support them – to optimize the work flows and productivity in an organization.

Enterprise Resource Planning (ERP) is integrated business software that supports multiple business functions across an enterprise. ERP implies the use of Commercial Off-The-Shelf (COTS) packaged software rather than proprietary software written by or for one customer.

There are a couple of key concepts we should review to compare/contrast BPR and BPM.

Compare & Contrast BPM & BPR

BPM focuses on the business process model to monitor, identify, and implement incremental improvements. These improvements or eliminations fall within the fundamental rules, parameters, and culture established by the existing business model. However, there comes a point in time where the law of diminishing returns applies and a transformation to the underlying business model is required. A more aggressive approach like BPR must be utilized to evolve to the next level of business process maturity. Consider the following illustration to demonstrate how BPM and BPR interact along the Capability Maturity Model Integration (CMMI):

BPR, BPM within CMMI

Allow me to provide an example. Company A performed a CMMI assessment of their purchasing process. Results from the assessment showed that the purchasing process was defined for certain business sales (revenue stream) but not for all purchasing events (direct & indirect). Another key finding was that there was no formal integration between demand planning, supply planning and purchasing which resulted in reactive purchasing. From the above CMMI reference, it was determined that Company A’s purchasing process is at the Managedlevel. Company A implemented several incremental initiatives (BPM) to improve process execution including documenting purchasing tasks for all purchasing events and conducting periodic purchasing planning meetings with operations.

Company A realized process improvement yet the value was limited by following model constraints: (1) each revenue stream (business line) had its own unique purchasing process & rules and (2) Purchasing had limited visibility across the entire supply chain. Two fundamental mindsets have to change:

Move from unique purchasing processes to a common enterprise purchasing model that is flexible enough to address the competitive requirements for each business line

Enable Purchasing to have visibility across the entire supply chain to support a process-oriented management model versus a function-oriented management model.

Implementing these changes will require a formal, projectized (BPM) effort that will redefine existing business rules, culture, and business process activities. As Company A continues to evolve their purchasing process they will conduct both BPM within the CMMI maturity level and BPR as they move to the next CMMI maturity level.

ERP reduces the effort required to perform tactical business activities so customers can focus on strategic activities. Expanding on our purchasing example, this would include basic functionality like automating the creation of purchase orders, approving purchase orders, and matching purchase orders with receipts & supplier invoices.

ERP provides the opportunity for visibility across business functions to support business process management. That said, there are several factors that determine the level of visibility.

Factors Impacting ERP Business Process Visibility

A competent ERP solution should provide robust, closed-loop integration between the functional modules provided out-of-the-box. As a practical note, there is always a need to integrate ERP to legacy systems and this requirement should be not overlooked. A business solution is only as good as its weakest integration. Process consistency will enable a relevant comparison of results and management of business processes.

A mature ERP solution should provide automation and integration support for both tactical and strategic business activities across the CMMI model.

Allow me to address some common misconceptions and mistakes made during ERP implementations related to BPR and BPM.

BPR is part of the ERP implementation.

While I agree that the initial ERP implementation will result in major changes with existing business functions, BPR will not happen unless there is a concerted effort to redefine the holistic business model and organizational structure to be successful with the ERP software.

Implementing ERP will give us BPM.

The direct answer is no. ERP does provide an information foundation that can support BPM. BPM is more about a discipline for managing processes and less about software.

Do I need ERP to mature my business processes?

Technically speaking, ERP is not a hard requirement for BPM. However, manual routine tasks and limited visibility hinder strategic activities. ERP can play a key support role in automating business tasks and provide visibility through integration.

Should I implement ERP features that support business activities at different maturity levels?

Business realities will necessitate that customers implement ERP features supporting different CMMI maturity levels. The problem lies in two areas:

Customer expectations are not appropriate set regarding the limited value realized from mature ERP functionality due to less mature business activities supporting strategic activities. Example: A procurement process scorecard measuring standard Key Performance Indicators (KPIs) will have limited value if there is not a standard, enterprise procurement process.

Implementation partners and business solution advisors should provide a short-term strategy and roadmap to evolve the supporting business activities to same level of maturity. This approach provides a “quick-win” opportunity for customers to drive additional value from the existing ERP investment.

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.

Business to IT alignment is an objective that most technology and business leaders would agree as essential for agility. However, ask for a definition of Business to IT alignment or how to implement an alignment strategy and the likely results are conflicting information and vague guidance. In the following blog I will try to add clarity to this topic as well as provide practical guidance.

Definition

Let’s start with a basic definition of Business to IT alignment by addressing some common misconceptions. Business to IT alignment is far more than just Project Portfolio Management (PPM). Business to IT alignment consists of several domains:

Business – IT Alignment Domains

Several Tier I & Tier II ERP software vendors provide software solutions to address certain Business to IT Alignment requirements, including PPM and Communications (social collaboration). However, it is important to remember that technology alone is not the answer. Collaboration tools can be used to generate more noise than effective communication. Also consider that having strategic initiatives stored in a common platform (ex. PPM) does not mean the all stakeholders share a common interpretation.

Just as Business – IT alignment is more than just PPM, enterprise governance is much more than just IT governance. In simple terms, enterprise governance is a process that ensures that enterprise capacity (Business, Operations, IT) are working on the right things at the right time to enable business goals. It’s a set of guidelines that focuses on organizational success while managing associated risks. Alignment is hard to achieve when governance is not consistent across the enterprise. Knowledge transfer is the most underestimated and misunderstood area. Effective knowledge transfer is more about education and trust than software and templates. Before one can be successful with Business – IT alignment it is important to fully appreciate the scope and breadth of effective alignment. A viable alignment strategy must address the key challenges listed in the next section.

The Challenges of Business to IT Alignment

Consider the following alignment model. This is a very simple model that I would like to use for discussion purposes.

Business – IT Alignment Governance Model

Allow me to highlight some key challenges associated with the traditional alignment model provided. First is the notion that Business and IT operate separate silos. Notice in the example above that there are separate Business and IT goals. Thus, there must be an exercise to reconcile Business goals and IT goals to identify commonalities and gaps. Practically speaking, given the level of effort required to align these separate strategies, a reasonable conclusion is that alignments occur periodically based upon corporate milestones. This is where the model breaks down because effective alignment must be a daily activity. Every business request from strategic initiatives to daily support tickets is an opportunity to reinforce alignment. Another possible concern implied in this model is that the majority of alignment effort happens at the enterprise level. Sustainable alignment must happen at every level within the organization.

A results-oriented alignment strategy must address the inhibitors of alignment. Consider the following relationship between alignment and communication:

Once you have identified your current maturity level then you can devise realistic, increment steps to move forward to the next maturity level. It is also important to periodically assess your organization’s alignment. What gets measured gets done!

Summary

Why is Business to IT Alignment so hard? Consider the following statements to highlight the key challenge with alignment.

Business vs IT Value Drivers

Is Business to IT alignment an impossible goal? No, as long as a practical, measured approach is taken to achieve tangible results. Business to IT alignment is a strategic goal that can only be reached by taking tactical steps to bring Business and IT closer together to generate mutual understanding and trust. When alignment is achieved communication is effective resulting in valued partnership.