ERP Project 101: Deployment vs Requirements Gathering

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

Reality Check!  There will be ERP requirements conflicts

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

ERP REquirements Conflict

Example of Requirements Conflict for ERP

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

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

Practical Steps to Minimize ERP Requirements Conflict

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

How to address ERP requirements conflicts

Practical approaches to address requirements conflicts

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

 

Logical Business Requirements Model

Logical progression of gathering ERP requirements

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

Summary & Conclusion

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

Advertisements

SaaS ERP is not a push button solution

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

Common Expectations of SaaS ERP

 

  1. Cheap:  The customer does not need to make a huge expenditure to implement and utilize.
  2. Fast: Answer a few questions and have an up and running software in weeks.
  3. Flexible:  Business users can make changes.  Minimize IT involvement.
  4. 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

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:

SaaS ERP Realities

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.

 Summary

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.

BPR, BPM and ERP

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

BPR, BPM, and ERP Revisited

Allow me to establish some basic definitions for our discussion:

  • Business Process Management (BPM) consists of methods, techniques and tools to design, deploy, control, and analyze operational business processes involving humans, organizations, applications, documents and other sources of information.
  • Business Process Reengineering (BPR) is the redesign of business processes – and the systems, policies, and organizational structures that support them – to optimize the work flows and productivity in an organization.
  • Enterprise Resource Planning (ERP) is integrated business software that supports multiple business functions across an enterprise.  ERP implies the use of Commercial Off-The-Shelf (COTS) packaged software rather than proprietary software written by or for one customer.

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

Compare BPM and BPR

Compare & Contrast BPM & BPR

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

 

BPR, BPM within CMMI

BPR, BPM within CMMI

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

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

  1. Move from unique purchasing processes to a common enterprise purchasing model that is flexible enough to address the competitive requirements for each business line
  2. Enable Purchasing to have visibility across the entire supply chain to support a process-oriented management model versus a function-oriented management model.

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

How Do BPR, BPM, and ERP Relate?

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

  1. ERP reduces the effort required to perform tactical business activities so customers can focus on strategic activities. Expanding on our purchasing example, this would include basic functionality like automating the creation of purchase orders, approving purchase orders, and matching purchase orders with receipts & supplier invoices.
  2. ERP provides the opportunity for visibility across business functions to support business process management.  That said, there are several factors that determine the level of visibility. 
ERP Business Process Visibility

Factors Impacting ERP Business Process Visibility

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

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

ERP Evolution within CMMI

Interaction of BPR, BPM, and ERP within CMMI

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

Common ERP Misconception and Mistakes Related to BPR & BPM

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

BPR is part of the ERP implementation.

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

Implementing ERP will give us BPM.

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

Do I need ERP to mature my business processes?

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

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

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

  1. Customer expectations are not appropriate set regarding the limited value realized from mature ERP functionality due to less mature business activities supporting strategic activities.  Example:  A procurement process scorecard measuring standard Key Performance Indicators (KPIs) will have limited value if there is not a standard, enterprise procurement process.
  2. Implementation partners and business solution advisors should provide a short-term strategy and roadmap to evolve the supporting business activities to same level of maturity.   This approach provides a “quick-win” opportunity for customers to drive additional value from the existing ERP investment.

Summary

Understanding how BPR, BPM, and ERP should relate to one another can be a challenge.  Some believe that it is an “either or” proposition.  I do not subscribe to this school of thought but rather believe that BPR and BPM are disciplines that should be interweaved as part of your ERP application strategy.  Knowing and appreciating these interdependencies will put you in a better position for ERP success. 

Business to IT Alignment – A Practical Discussion

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:

Knowledge Map for Alignment

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.

Governance Model

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:

Alignment and Communication Inhibitors

Alignment and Communication Inhibitors

Success alignment requires successful communication.  Successful communication requires the effective use of all the key communication skills

Key Communication Skills

Key Communication Skills

Process is important but the soft skills like communications, emotional intelligence (empathy), and knowledge transfer will have the greatest import on long-term alignment success.

Practical Steps to encourage Alignment

Before you can start implementing practical steps you need to assess the level of alignment within your organization.  The Strategic Alignment Maturity model referenced below was developed by Dr. Jerry Luftman and is based upon the Capability Maturity Model Integration (CMMI).

CMMI - Strategic Alignment

Strategic Alignment Maturity

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 Perspective

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.

PeopleSoft Knowledge Map

Knowledge is power!

Knowledge is also the key enabler for customers to get the most out of their Oracle ERP investment.  I can understand the economic pressures to do more with less. Allow me to share with you the following list of available PeopleSoft information/training resources on the internet.

Available Resources:

Knowledge transfer is a process, not just a milestone task on a project plan.  Customers – insist on a knowledge transfer plan from your SI partners.

If you gain value from this knowledge map then I would consider it an honor if you would consider purchasing my book on ERP implementation best practices.  I promise you won’t regret it.

ERP Project 101: What + Why = How

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

 

Gathering Business Requirements is Just the Beginning

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

Requirements Mgmt 101

Basic ERP Requirements Management

  

Defining What

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

 

Defining Requirements

Generally Accepted Requirements Gathering Methods

 

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

 

Determining Why

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

Confirming Requirements

Requirements validation techniques

 

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

 

Constructing How

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

 

Addressing requirements

Options to address ERP requirements

 

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

 

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

 

Summary

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

Cloud ERP Strategy: Goodbye IaaS, Hello IaaS

One of the first deployment models for cloud computing was Infrastructure as a Service (IaaS).  Currently, there is a price war between the major IaaS providers like AWS and Rackspace to provide the cheapest infrastructure. However, enterprise customers looking to move their ERP solutions to the cloud should focus more on Integration as a Service (IaaS).  Integration, not infrastructure, will have a greater impact to TCO and ERP success.    In the next sections we will briefly compare the influences that infrastructure and integration have on an enterprise solution like ERP.

Cloud Infrastructure versus Integration

In a previous blog I reviewed the key competencies to consider as part of selecting an ERP cloud provider (ERP Cloud: Finding the Right Provider).  Both infrastructure and integration are key considerations yet I view enterprise integration the greater challenge.  Consider the following:

Cloud Infrastructure & Integration

Key Cloud Consideration Factors

Cost

The cloud storage war appears to be getting the most press in cloud computing but consider two factors driving this type of pricing strategy

  1. Vendors cannot provide a material differentiation or competitive advantage.
  2. Technology improvements continue to drive down disk storage costs rapidly.  Combine this trend with the economy of scale that cloud providers generate to continue driving costs down by another 40% in the next 3 to 5 years.

Moore’s Law highlights the computing hardware trend resulting in greater technology capabilities and driving down MIPS costs.  However, the same cannot be said for integration.  As discussed in one of my earlier blogs (Best of Breed vs. Integrated ERP), integration costs can be up to 8 times the cost of the ERP software. 

ERP Integration Considerations

ERP Integration Considerations

We have all heard the proverb “A chain is only as strong as its weakest link.” Applying this concept to business software, we would conclude that a business solution is only as strong as its weakest integration.

Business Value Realization

Allow me to make the general statement that outsourcing IT infrastructure to a cloud provider should result in a cost savings to customers.  However, I believe that IT organizations will quickly learn that providing this cost savings is a short-term value proposition to their business owners.  Ultimately, IT-driven innovation will drive business value realization.  Gartner identifies Integrated Ecosystems and Hybrid IT & Cloud Computing as two of the top 10 strategic technologies for 2013.     Every ERP solution has a portfolio of edge products/3rd-party integrations to external solutions to provide holistic support of business processes.  The only true method of creating business value is through business processes.

Socialization & Collaboration

The ERP software industry is realizing that people have the greatest impact on business results.  It is refreshing to see the increase in socialization and collaboration capabilities.  Infrastructure is necessary but integration is the critical path to success.

Market Trends

In my opinion, I expect to see the market changing for IaaS providers.  Given how important integration is to a viable cloud solution either existing IaaS will grow into a Platform as a Service (PaaS) or will be acquired by PaaS vendors looking to provide global support.   Just take a look at AWS and Rackspace’s transition from an IaaS to a PaaS:

Summary

History always has a way of repeating itself.  Recalling the Y2K problem, storage (infrastructure) was seen as a strategic/limited resource.  This view resulted in the programming practice of representing the year with two digits and we all know how that came back to haunt IT organizations.   Infrastructure is a cheap commodity when compared to a collaborative, enterprise integration framework.  Infrastructure is a key enabler for cloud computing but integration will ultimately determine your success of ERP in the cloud.   

%d bloggers like this: