Fact or Fiction: Hybrid ERP Deployments

With cloud computing and cloud ERP gaining additional attention in the marketplace, ERP vendors, resellers, and solution providers are quickly positioning their products and services as “cloud-enabled”.  However, in my humble opinion, to simply put ERP software on a hosted server and provide subscription-based pricing does not a cloud solution make.    A key value proposition for cloud ERP is the ability to support a truly hybrid ERP deployment.  In the next section we will discuss what is an ERP hybrid deployment including the opportunities and challenges this type of deployment presents.

What is an ERP Hybrid Deployment

A hybrid deployment method has the potential to enable customers the flexibility to deliver ERP capabilities in the most cost-effective manner to users. Hybrid deployments would allow for an optimal mix of the major ERP delivery models.

ERP Deployment Types

ERP Deployment Types

An ERP solution that can support a hybrid deployment must be architected in a manner to support multi-platform environments simultaneously.  In general, following are the opportunities that a hybrid ERP deployment can provide to customers:

Advantages for Hybrid ERP Deployments

Advantages of Hybrid ERP Deployment

Opportunity Description
Rapid Implementation A hybrid ERP model may give you the flexibility to quickly implement a new ERP module or feature set.  Even if you decide to deploy on-premise having a hosted site for prototyping and development can give you the opportunity to start design/configuration activities faster.
Shorten Maintenance Cycles As an IT Director I am faced with the reality that IT maintenance cycles are being reduced given increase demand for ERP availability by business users.  Given this fact, I am looking a cost-effective, on-demand IT infrastructure resources (ex. Infrastructure As A Service) to help shorten the ERP maintenance window.
Load Balancing As part of any ERP solution you will have both real-time and batch processing.  There are different performance requirements for real-time versus batch processing. A hybrid model may provide you the opportunity to have unique performance tuning configurations better suited for specific processes.
Greater Vendor Independence I’m not a huge fan of the “single point of accountability” value proposition because I have rarely seen it work.  If an ERP solution can truly support a hybrid ERP deployment then we all should have greater flexibility in choosing the right partners to be a part of our IT value chain to business users.

Challenges with ERP Hybrid Deployments

As the ERP industry moves to a true ERP hybrid model there are several challenges that must be addressed as we take to next evolutionary leap.

Challenges to address as we move to hybrid ERP

Challenges with moving to Hybrid ERP Deployments

Challenge Description
Coordinating Support Activities Coordinating software development and maintenance activities across the ERP platform.  Since ERP support business processes and business processes will cover multiple functional areas (modules), coordination and prioritization of ERP support activities will be critical to reliability.
Integration & Orchestration Integration is a given but business process orchestration will be extremely important to support a seamless business solution execution.
Seamless UI Simply stated, the end-user should not be able to see a notable difference in appearance and performance across the deployment models.
Master Data Management As long as an ERP hybrid deployment requires multiple database instances then Master Data Management will be a key enabler to keep instances in sync.

As one looks across the ERP industry we are observing some real signs of movement with hybrid ERP deployments.  However, at this point I personally would not conclude that the ERP industry has reached the final destination.  In the next section I will list a  few of the core characteristics for assessing an ERP vendor’s ability to support hybrid deployments.

Assessing Vendor Solutions to support ERP Hybrid Deployments

A hybrid deployment approach enable customers to have a more scalable ERP solution versus limiting their sizing options to a single deployment model. Four major factors determine how viable a vendor’s hybrid ERP deployment offerings are:

  • ERP Architecture: Is the ERP solution constructed in such a way that allows software components to reside in multiple delivery platforms (on premise, hosted)? Integration and orchestration of ERP activities are key software enablers to support hybrid delivery
  • ERP Partner Ecosystem: Does the ERP vendor have consistent, reliable partners with a portfolio of hardware/software and professional services to support multiple hybrid delivery models?
  • ERP Pricing Model: Does the ERP vendor allow customers to utilize multiple delivery methods concurrently? Are there any price penalties or legal restrictions imposed on customers from moving between delivery models?
  • Portability: Customers have the ability to move data and customizations from one deployment model to another as needed.


My view of a true ERP hybrid solution is a software solution that enables the customer the flexibility to deploy both modules and major features across multiple platforms seamlessly.

Hybrid ERP Deployment

Hybrid ERP Deployment Model

A hybrid ERP deployment is a great way to explore the cloud in an iterative, risk-adverse approach.  Hybrid ERP may provide the opportunity for greater innovation, rapid deployment, or isolating batch intensive processes from self-service applications.  The greatest value of a hybrid ERP solution is the additional flexibility it can provide customers to support business processes.  Let’s hope that the wait is not too long.


SI Partner for PeopleSoft ERP

Blog Sponsor – Cardinal Point Solutions, LLC.


Defining Scope for ERP Implementations

I know that everyone whole-heartedly agrees that having a well-defined ERP implementation scope statement is strategic to success.  However, there are few articles or other resources that provide detailed guidance on building scope statements.  I would like to focus on one key area that is typically not clearly articulated for ERP implementations.

Components of a Scope Statement

There are many tactical objectives for a scope statement (defining a statement of work, supporting change control processes) but the strategic objective for a scope statement is to define focus!  Without focus all other ERP implementation best practices are done in vain.  It is important to not only define what should be the focus of the project team but also to define what should be out of scope.  Following is a summary of the key areas to address in a scope statement.

ERP Scope Definition

ERP Scope Areas

Now granted the above list is not a mind-sweeping revelation with most experience ERP implementors.   However, the challenge I’ve observed has been in clearly defining ERP product scope.   In the next section I will briefly discuss one of the key challenges.

Key Challenges with Scope – Product Features

An area this is typically not defined well is the business processes and ERP product features that are part of the implementation.  Too often business processes and product scope is defined only at the product level (example: we are implementing PeopleSoft Purchasing module).  How can I tell what business activities and features are out of scope?  Developing focus is much harder to develop and maintain.  Following is an illustration of how product scope should be defined our example above .

ERP Product Feature Scope

ERP Product Features – In Scope

Key points:

  • Important that you designate which ERP product functionality is in scope.
  • You need to briefly explain how the product feature supports the business activity.  A scope definition provides less value if the project team and project stakeholders do not understand how ERP will support the business.
  • There may be situations where an ERP product feature is in scope but only limited functionality will be used (example: The project manager cannot be the only role responsible for scope management.  The project team and project stakeholders must take an active role in focusing on scope.
ERP Product Scope - Out of Scope

ERP Product Features – Out of Scope

Key points

  • Important that you designate which ERP product functionality is not in scope.
  • You should define all software features associated with the ERP product.  This exercise will ensure that you have a complete product scope statement.

Project Scope

Project scope refers to the individual implementation tasks that must be performed as part of the ERP implementation.  The challenges I typically see with this area are (1) the implementation activities are not specific and (2) there is no clear, quantitative evidence regarding which party is responsible for performing the activity.  I recommend that the Implementation Partner should provide a detailed project scope statement with responsibilities clearly defined.

ERP - Implementation Activities Scope

ERP – Project Activities Scope

Please do not fall into the trap that ERP scope can be reduced by eliminating implementation tasks (ex. organization change).  Project tasks can be applied at different levels but disregarding activities is a recipe for failure.

Risks of not clearly defining ERP implementation scope

A best practice for any ERP implementation is having a defined scope change control process.  Unfortunately, having a scope change control process without also having a well-defined product scope statement will most likely result in failure.  How can any one identify scope creep no one understands the scope?  It has been my experience that the majority of scope creep starts as discussions outside the standard project meetings where unclear expectations result in losing focus on the prize.  If the first time you hear of scope creep in a change request then you are being more reactive than proactive.  I’m not saying that scope change is wrong or not necessary but I am saying we should do everything in our power to minimize exploring requirements that do not align with the project objectives.  As Barney Fife would say “nip it in the bud”.


An effective ERP scope statement has to be more than just a document – it has to be a clear vision and expectation in the mind of your project team and business stakeholders.  Scope change control has to be more than a trigger for an Implementation Partner to create a contract attachment to their Statement of Work.  A clearly defined scope statement is a filter that enables business stakeholders, internal IT groups, and the Implementation Partner to align focus for mutual success.

Decisions – Not Documents – Move ERP Implementations Forward

Information Alone Does Not Generate Value 

I grew up in a time when information was hard to obtain.  Generating information was seen as a valuable exercise because information was a scarce resource.  The first software development life cycle (SDLC) I learned was Waterfall.  One of the key focus areas for the Waterfall SDLC was documentation (i.e. information).  However, there is a limit regarding what value information can provide.  In our enthusiasm to create information we sometimes go to an extreme and generate so much information that it becomes a roadblock.  What we often forget is that the key purpose of gathering information is to make decisions!

There is a direct relationship between the speed of customer decisions and the speed of ERP implementations.   The faster a customer can make a decision results in a faster implementation cycle.  Naturally, customers want to make right decisions therefore the project team must gather the right information.  To gather the right information we first need to understand the key decisions that must be made as part of the ERP implementation.

Decision-Oriented Information Gathering

Before the project team begins gathering information they first should consider what key decisions the project must make.  The ERP implementation scope will determine both the information gathering scope and key decisions to be made.  Consider the following illustration:

Gathering information to support decisions

Decision-Oriented Information Gathering

Simply stated, the scope for an ERP implementation consists of the software features that will be deployed (product scope) and the project activities and audience for the deployment (project scope).  Once the implementation scope has been defined, the project team can better identify the information requirements.   Gathering the required information and presenting that information in the appropriate context will enable the customer to make both software configuration and fit/gap decisions.  

Utilize Best Practices to Drive Decisions

A best practice is a process, method, or approach that is considered the most effective at delivering a desired outcome.   A best practice is repeatable and has proven itself over a period of time.   For ERP implementations there are two areas of best practices that should be considered:

  1. Industry best practices
  2. Configuration best practices

Once the implementation scope has been clearly defined, the project team should leverage industry best practices to assist the customer in making decisions.  Providing these best practices up-front to the customer will streamline the information gathering process.  As the project team moves from gathering information to driving decisions on ERP configurations and Fit/Gap, configuration and gap decision best practices can be referenced to provide proven knowledge to key decision makers.   Having the right Implementation Partner can have a significant impact on effective information gathering and decision support.  An Implementation Partner may not know every single decision that the customer must make as part of their ERP implementation but they should be able to identify up-front the key decisions required based upon the scope. 

Consequences of Not Driving to Decisions

The ability to make informed decisions is fundamental to ERP implementation success.  I would like to encourage the two key players that impact the decision-making process for ERP projects:


We live in a society where we like to keep our options open.  Many say that keeping your options open will make one flexible to future opportunities.  Many customers have applied this concept to technology and business systems.  I have seen this philosophy trickle down into a customer’s decision-making approach for ERP implementations.  Customers desire to have a business solution that is both adaptable and flexible.  It is an understandable and legitimate requirement.  However, customers need to keep two things in mind:

  • Keeping your options open (i.e. not making decisions) will slow down the implementation project and increase your risk for failure.   
  • People, not technology, is the most flexible and adaptable component of a business solution.
Strengths of Business Solution

Business Solution Strengths

Implementation Partners

Implementation Partners should be able to provide industry and ERP configuration best practices to their customers.  These best practices should be formally documented and provided early in the implementation where they have the greatest benefit.  These documents will provide evidence that the Implementation Partner can provide a repeatable and reliable service.


As a project manager, I’ve observed where project team members focused more on producing information and focused less on producing decisions.     Producing information (i.e. documents) is far easier than driving decision(s).    There is a false perception that generating more information will result in more knowledge and enable customers to make better decisions.  Nothing is further from the truth.  Only when the right information is communicated in the right context then knowledge is created for making informed decisions.

Accelerating ERP/COTS Implementations

Accelerating ERP/COTS implementations have been an elusive goal of vendors, implementation partners, and customers. For five years I worked for the #2 business software maker focusing on accelerating implementations. During those five years I chased the dream and learned many lessons along the way. Following are some of the key lessons I would like to share with you.

If you did a search on accelerated or rapid implementation you would most likely find the following enablers for rapid implementations:

  • Software with built-in best practices
  • Industry preconfigurations
  • Implementation tools and templates (Needs Assessment, Fit/Gap summary)
  • Deployment (ex. SaaS, Hosted)

Notice anything missing? It’s interesting to note that these accelerators are software-focused. Not to say that the above tools/templates are not important, however, there are more important factors that can have a greater impact on accelerating implementations.


It’s a known fact that the customer needs to provide the right resources (Business, IT) with deep knowledge and experience with the existing business solution. What I see lacking is guidance to customers regarding what they need to do to prepare for a rapid implementation. If the implementation partner and software vendor is serious about accelerating implementations then they will provide customers with a preparation checklist that enables the implementation partner to “hit the ground running” with the customer. At a minimum the customer should perform the following:

  • Take all required software training BEFORE the implementation partner arrives. This activity will enable the customer to effectively and clearly communicate with the implementation partner.
  • Document your existing business processes. For effective collaboration with the implementation partner the customer needs to EDUCATE the implementation partner on their current business solution. A picture is worth a thousand words and accelerates knowledge transfer!

Implementation Partner

Consultants that are successful at accelerating implementations are an elite group. These individuals are business solution experts that are both functional and technical. They have the ability to help the customer make both software and business decisions. At a minimum the consultant should understand how the ERP/COTS software supports an ENTIRE business process (Order to Cash), not just a specific business function (Expense Reporting).

Decision Making

The ability to make decisions quickly is one of the most overlooked aspects of accelerating implementations. Decisions move implementations forward. Following are the recommended methods you can use to speed up decisions:

  • Conduct prototyping during the sales cycle to define core requirements, validate software results, and eliminate options. The more questions you can answer during the sales cycle the faster the implementation can move.
  • A rapid implementation approach requires full-time dedication from business owners. Business owners will be the key decision-makers and must be empowered to make decisions within hours, not days or weeks.
  • Need to have a clearly defined scope. This includes (a) what’s in scope, (b) what’s out of scope, (c) and who’s doing what. Just as important to scope definition is to define constraints and assumptions.

At a minimum the ERP/COTS scope statement should contain the following sections:

  • Packaged software features in scope (product scope). This also includes restrictions on software features in scope (example: only five customer types will be included in the rapid implementation).
  • Packaged software features out of scope (product scope).
  • Implementation activities and party responsible (project scope).
  • A clearly defined scope allows the project team to focus on the activities that have a direct impact on the project objective(s) while filtering out “out of scope” work.

Methodology and Approach

I have observed two areas that slow down ERP/COTS implementations: customizations and evolving requirements (even with a predefined scope). From my experience my approach has been to minimize these areas by the following:

  • Only implement the software functionality that supports the business activity the customer performs TODAY. New business activities typically result in evolving requirements because the customer has no detailed experiences or agreed-upon expectations.
  • Take a solutions-driven approach to gathering requirements. Using a traditional requirements-driven approach will result in identifying more gaps (both value and non-value-add).


Not every project or customer is a candidate for a rapid implementation. Implementation partners and software providers should conduct an assessment to determine the FIT for a rapid implementation. One thing you can bet on is that there is no such thing as a STANDARD rapid implementation. Each instance is unique and requires an experienced implementation partner that understands rapid implementations.

%d bloggers like this: