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.

Join the community! 10k followers across 100 countries!

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. 

Join the community! 10k followers across 100 countries!

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.  

Join the community! 10k followers across 100 countries!

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.   

Join the community! 10k followers across 100 countries!

Building a Business-Aware Cloud Solution

In a recent study conducted by Forrester Consulting “Enterprise Cloud: Lessons Learned From Early Adopters” a key conclusion made is “A complete, application-centric, business-aware cloud solution is needed.”  Let’s say that your C-level executive stops by your office and asks you to lead a project to develop a business-aware cloud solution.  To be successful it is important to understand what you are building.  In the following blog I will attempt to define a business-aware cloud solution.

Defining a Business-Aware Cloud Solution

Your project objective is to develop a business-aware cloud solution.  As you are a competent project manager one of the first areas you want to define is the project scope.  As your humble project assistant, I have searched the internet for you and have leverage greater minds from the University of Edinburgh:

“What different employers mean when they talk about business awareness varies, however their views broadly fall into two areas: (1) understanding an occupation, and (2) understanding the business environment.”

What is Business-Awareness?

I would like to elaborate upon on this definition with the following model.

Defining Business-Awareness

Defining Business-Awareness

There are three key areas that enable business awareness. The business process area includes the business functions, related-activities, and the individual tasks that must be performed in order to generate the desired business results.  The business role(s) area includes the concatenation (grouping) of business activities into responsibilities that can be competently accomplished.  Finally, business awareness also requires an understanding how an industry operates and how it is influenced by local, national and global economics.

Now, your experience as a project manager tells you that a well-defined project scope statement not only explains the end result but also elaborates on what is considered out of scope.  With this best practice in mind let us clearly articulate on some areas that may misalign the focus on business.

 

Losing Focus on Business-Awareness

Blurring Focus on Business-Awareness

Please allow me to elaborate. A business function is a necessary structure resulting in a concatenation of activities/tasks that aligns with the skills/experiences of the organization to best support business processes.  The ERP software industry started as discrete, functional applications that continue to evolve into enterprise-wide, business process solutions.  In general, software applications focus more on business functions requiring the implementation of multiple applications to support an entire business process.  As a veteran project manager, you understand that an application focus may result in gold-plating or poor support of functional hand-offs (integration).  You also appreciate that technology is only one component of a business solution.

We are halfway to having a better understanding of our project objective.  Now, let’s focus on what some may consider the mystical realm of the cloud.

What is a Cloud Solution?

Forgive my “tongue-in-cheek” response above but it is hard to define a clear picture given the varied information available in the marketplace.  Once again, I refer to brighter minds (NIST) to provide a definition.

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”

I would like to focus on what’s not in this definition that may be perceived expectations of moving business software to the cloud

Implied Expectations for Cloud

Implied Expectations for Cloud

The immediate, short-term savings will be reduction in capital expenditures required for IT infrastructure requirements. As correctly pointed out in the book “Cloud Computing – Assessing the Risks“, there is a general misnomer that there is a risk reduction with the cloud.  There is a transference of risk from the IT organization to the Cloud Provider.  Technology results (reliability, response, availability, scalability)  may lead to business benefits – but it is not a guarantee. 

Now that we have a little better understanding of project objective, let’s briefly review the role that the key enablers will play in the implementation of a business-aware cloud solution.

Enablers for a Business-Aware Cloud Solution

As a competent project manager, you know that the project must address all three components of a solution in order to be successful in meeting all expectations.  For the sake of brevity we will only focus on a key expectation for each component.

ERP Business Solution

Business Solution Defined

  • People:  People innovate.  People accept.  People resist.  People ultimately drive project success. 
  • Process: Innovation is a process and not just a brainstorming event.  IT needs to move up the business value chain with a rapid, iterative delivery method.  Governance is not an acceptable substitute for properly educating users on the effective use of cloud technology.
  • Technology: A reasonable expectation is to select a cloud vendor that provides a  reliable, secure, scalable IT infrastructure solution on par (or better) than existing services.   For business software like ERP to be business-aware, the software must have access to business model, roles, and rule metadata that is maintained by business users.

Summary – Are We There Yet?

Do all the technical components exist in the marketplace today to build a business-aware cloud solution?  Technically speaking, the answer is yes if you want to seamlessly integrate multiple technical components with multiple UI experiences, data sources, and training requirements.  Will it be a practical and viable solution?  I suspect that there is room for improvement.  If you wait for a complete solution then it may be too late for your business users.  But you are not just a project manager, you are a project leader!  You know that this effort is a project program with iterative projects that incrementally build upon the individual project results.  Start planning, start delivering!

Join the community! 10k followers across 100 countries!

ERP Cloud: Finding the Right Provider

I recently attended Oracle’s OpenWorld Conference in San Francisco this October.  There was a huge volume of information on the Cloud.  As I walked through the Exhibitor’s halls at the Moscone Center, I observed that every SI partner had ERP in the Cloud or could get customers to the Cloud seamlessly.  What I did not see is any offering or advisory service to guide ERP customers through the storm clouds to find the right provider.  In the next sections we will discuss the key competencies to consider as part of making an ERP Cloud provider selection.

Capabilities for ERP Cloud Providers

ERP Cloud Provider Key Competencies

Hardware Competence

Typically, this is the first area that customers think of when evaluating Cloud providers.  For this discussion, hardware includes servers, processors, network, processors, and storage.  Now, I may be chastised by my technology peers but I take a very practical approach to hardware.  Business users are more concerned about technology results (reliability, response, availability, scalability) versus what hardware configuration is being used.  I’m all for engineered solutions if they provide a material impact to technology results.  I would not consider millisecond improvement on response time as a material impact on response time nor would I pay an additional $100 per hr /month for special hardware.  Remember to keep the end in mind – you are moving an ERP solution to the Cloud.  Review and identify Cloud providers that offer hardware configurations that best aligns to the hardware specifications and recommendations made by ERP software vendors.

Software Competence

For this discussion, software competence focuses on software and standards that enable a viable Cloud solution.

Selecting Cloud Providers - Software Considerations

Selecting Cloud Providers – Software Considerations

For brevity sake, we will focus on a few of the key software enablers for the Cloud.

Software Area Considerations
Open Standards & Technology Open Standards promotes interoperability and data exchange among different products or services and are intended for widespread adoption.  This area will be a key enabler (and indicator) of portability.
Integration A viable ERP Cloud solution must provide a robust toolset for integration back to the customer’s on-premise supporting systems.  Integrations can be a potential point of failure that must be addressed with a cost-effective solution.  Cloud + Poor Integration = Failure. 
Load Balancing Load Balancing is vital for effective distribution of work across a multi-tenant hardware environment.   Optimal resource utilization, maximize throughput, minimize response time, and avoiding overloads are not possible without a robust load balancing capability.  Be leery of simple load balancing algorithms like random choice or round robin.
Virus Protection Viruses can live in the Cloud.  Malware known as Crisis can infect VMware virtual machines.  Moving to the Cloud does not end the need for antivirus protection.
Virtualization Virtualization is a key enabler for Cloud computing.    In order to realize the technology benefits associated with virtualization, Cloud providers must be able to provide a robust solution for the following capabilities: Elasticity – dynamic scalability is an integral feature (enabler) for agility and fundamental IT cost savings. Logical isolation for data protection. Hypervisor management for VMs.VMs replications.
ERP Software Not all ERPs are created the same for the Cloud.  Following are areas to review in determining how “Cloud-Friendly” is your ERP solution.     Single-Tenant vs. Multi-Tenant – Single-Tenant provides a more formal logical isolation for customer data.  Multi-Tenant reduces duplicate upgrade efforts and technology resources. SOA Compliance – How well does your ERP solution expose methods and related data components to external solutions via SOA services? Network Latency – High data volume transfer between Cloud server and the on-premise client. ERP Experience – Also ask if the Cloud provider has “hands-on” experience with supporting your ERP solution. A leading Cloud provider will have a competent level of technical support knowledge for your ERP software.

 Security Competence

Security is a key selection criterion for Cloud providers.  A realistic expectation is that Cloud providers should have a greater level of security than your current on-premise IT environment. Following is an illustration of the key security areas you should consider as part of your ERP Cloud provider. 

Cloud Provider Selection - Security Considerations

Cloud Provider Selection – Security Competence

 There are three key areas that I would like to further discuss.

  1. Identify Relevant Security Standards:  Viable Cloud providers should be able to assist their customers in identifying and applying relevant security standards for their specific industry.  
  2. Security Validations:  Leading Cloud providers are able to demonstrate their security competence via (a) audit and evidence gathering, (b) providing security audit findings for customer review, and (c) enabling customers to perform independent security audits if desired.
  3. Data Encryption:  Encryption of customer data either in transit or at rest should be a non-negotiable requirement for Cloud providers.

 Value-Add Partner Network Competence

 Every ERP solution has a portfolio of edge products/3rd-party integrations to external solutions.  It stands to reason that customers should consider the portfolio of ERP edge products that a Cloud provider can host as part of the selection process.

Cloud Providers - Value Add Partnerships

Cloud Providers – Value Add Partnerships

Selecting a Cloud provider is not a short-term relationship so ensure that you can grow and generate greater value from your ERP investment within the Cloud.

Services Competence

A strategic competency that I feel is being overlooked in the Cloud market is the service portfolio that a Cloud provider should deliver.   Consider the following reality check: 

Reality Check for ERP Cloud

Reality Check for ERP Cloud. Used by permission.

Technology is only part of the solution.  What is the value of providing new ERP features if end users are not formally trained?  Who will perform regression testing for both technical and functional upgrades?  In my mind, a leading ERP Cloud vendor should provide both an automated testing solution and on-demand training solution to facilitate rapid deployments.   Cloud providers should have a services framework such as ITIL or ITSM.  This is a validation that your Cloud provider is committed to delivering reliable professional services.

Summary

Overall, I am very excited about the opportunities that Cloud can offer to existing ERP customers and potential customers who could not afford a Tier 1 ERP solution.  Yet, we must not forget that there are advantages and challenges that we must address in order to provide a reliable solution for ERP customers.  It is also important that we keep realistic expectations for the Cloud.  Cloud is more about a new way of delivering computing resources versus being a new technology.

Join the community! 10k followers across 100 countries!

Building a Better ERP Estimate

There are several documented examples of ERP implementations that went over budget or did not hit the original go-live date.  There are also many explanations out there to explain why these ERP implementations did not meet budget or timeline.  Instead of repeating common information out in the ERP blogosphere, I would like to speak to a root cause that is typically overlooked by our industry – inaccurate ERP implementation estimations.   In the next sections we will take a closer look at building a better ERP estimate.

Rule #1 – Have the right type of information to calculate an ERP Estimate

Developing a competent estimate for an ERP implementation or major customization can be a challenge for both seasoned consulting partners and a new ERP customer.   In a previous life I developed ERP implementation estimators for one of Tier-1 ERP software vendors.  I also developed both Time & Materials as well as Fixed-Price ERP implementation estimates – some good, some not so good.

Simply stated – an ERP implementation estimate is based upon your current understanding of the following areas:

Information Drivers for ERP Implementation Estimates

Information Drivers for ERP Implementation Estimates

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

Area Description
Customer Participation Implementation partners are generally good about estimating their level of effort to support ERP implementations but fall far short in estimating the effort for the customer.    In the majority of ERP implementations, customer must make available their best and brightest resources to support the implementation.  Odds are that these resources play a major role in current operations.  The ERP estimate should include any need to backfill existing business resources.
Project Scope Project scope refers to the implementation activities that need to be performed and who is responsible for performing the task(s).  Unfortunately, customers see this as an area to reduce implementation costs by taking on activities that they do not have the skills/resource availability to complete (ex. Organization Change Management).  People make ERP successful.
Product Scope Too often business processes and product scope is defined only at the product level (example: we are implementing the ERP’s Purchasing module).  How can I tell what business activities and features are out of scope?  Developing focus is much harder to develop and maintain. 
Implementation Partner Constraints  Every implementation partner has constraints!  It is a just a reality that should be factored into any ERP estimate.  For example, how much lead time should be given for an Implementation partner to replace a consultant?

You can never hope to create a realistic estimate without having valid information on the drivers that influence scope, schedule, and resources.  The next step is to understand your level of comprehension of the information that drives the ERP estimate. 

 Rule #2 – Understand the type of ERP Estimate you are calculating

Per the Project Management Institute’s Body of Knowledge (PMBOK) there are three types of estimates for a project.  These estimates are based upon your level of understanding for project scope, constraints, and assumptions.

Levels of ERP Estimate Accuracies

How Understanding Drives Estimate Accuracy

Simply stated – the more you know about the task(s) at hand the greater the probability of calculating a realistic estimate!  The trouble is that too many ERP implementations do not generate a definitive estimate.   A majority of implementation partners generate estimates during the sales cycle where estimates may approach a budgetary accuracy – at best.  To compensate for the estimation accuracy (-10% to 25%)  many implementation partners incorrectly utilize contingency reserves and management reserves to plug the potential estimate gap.   This is just a bad estimating practice which will most likely result in budget challenges further down in the implementation.  Fortunately, there are steps we can take to develop better ERP estimates.

Rule #3 – Drive to validate and refine your ERP estimate

Estimates can and should change as you learn more about the project.  However, there is an expectation out there that estimates should be defined once and they should be completely accurate.  Here is where I see the process break down.  Once an Implementation partner communicates an estimate too often the customer will latch and consider it an iron-clad promise.  The key driver for this phenomenon has more to do with the Implementation partner setting the wrong expectation when an estimate is communicated.   Customers encourage this behavior by focusing on cost as the key competitive differentiator.  Also, there is a perception in the market that if an implementation partner cannot provide a single estimate then the Implementation partner does not have the experience.  Customers, this may be the case but do not blindly jump to that conclusion.

Best Practices for obtaining ERP Estimates from your Implementation partner

Over the years I have been asked by customers what is the best approach to get a reliable, cost-effective estimate from Implementation Partners.  When should a customer request a fixed price estimate versus a time & materials estimate?  Following are some general guidelines I would like to communicate based upon my experience:

  • Fixed Price versus Time & Materials: Have the Implementation partner provide a Time & Materials estimate for project planning, requirements gathering, and fit/gap.  Once the Fit/Gap is performed you should know exactly what you are up against and then ask for a competitive bid/fixed price estimate to complete the remaining work.
  • Complete Information:  Always ask the Implementation Partner to provide an estimate with the following information
    • Product Scope
    • Project Scope
    • Assumptions
    • Constraints
    • FTE Hour Requirements for both the Implementation Partner and customer resources
    • Estimate accuracy – let customers know up-front that the estimate will change
  • Quantify Reserves: Ask the implementation partner if the estimate contains either a contingency or management reserve.  If so then ask what % of the total estimate is for reserves.  If this % is greater than 10% then this is a sign that the Implementation partner did not gather enough information to generate a realistic estimate.  If the implementation partner does not calculate a reserve then consider this estimate suspect (red flag).
  • Knowledge Transfer:  Just as important it is for an Implementation partner to perform knowledge transfer to enable customer resources to support ERP, it’s as important for the customer to educate the Implementation partner on the unique aspects of their business model.  The better the understanding the better the estimate.

Summary 

There are many of my peers who would consider ERP estimation more of an art than a science.  In my humble opinion, this is a bad philosophy that either results in generating an unrealistic estimate or the customer spending more money than is required.   Customers should also be realistic and understand that estimates created in the early stages of an ERP implementation will change and focus on making the right decisions for mutual success.  Level of effort estimations for ERP implementations are based upon the current understanding of the ERP implementation.  Some ERP estimates are easier to calculate given a predefined implementation scope, however, there will always factors unique to a customer that must be explored, defined, and refined during key milestone implementation activities.

Join the community! 10k followers across 100 countries!

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.

Summary

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.

Developing a Business Case for ERP Customizations

To customize or not to customize – that is the question which continues to be a source of contention and confusion.  On one hand, customization(s) can result in an expensive ERP solution.  However, ERP software enhancements can provide a competitive advantage or cost reduction that is customer-specific.  The challenge is not in the question itself but rather how the answer is justified.  Unfortunately, many business cases for ERP customizations are either too short-sighted or do not fully comprehend the impacts to the ERP investment.  In the next section we will discuss the key components required for an ERP business case for customization(s).

 Business Case Overview

 Following is a business case template I’ve used as a consultant to justify ERP customizations. 

Valuation and Justification for ERP customization
Business Case Format

Let’s briefly discuss each section in greater detail.  The Problem (or Opportunity) section should clearly define the issue(s) as well as the target audience who will benefit from addressing the problem.  The problem section should also explain the compelling reason (s) why the problem should be addressed.  The Solution section should speak directly to solving the problem or addressing the opportunity.  The solution section must include the method(s) used to validate that the proposed solution solved the defined problem.

The Approach section details the viable methods available to implement the solution.  The approach section should not be a theoretically exploration of all possible options.  Too often I have observed where unrealistic approaches were defined, which did more to confuse decision makers rather than create a focused, compelling argument.  In general, I typically provide three approaches when pitching an ERP customization:

  • Full Customization (Extreme)
  • Partial Customization (Middle of the Road)
  • Out Of The Box (OOTB) (Extreme)

Following is a generic example of comparing the above options:

Possible Approaches for ERP Gaps
Possible Approaches for ERP Gaps

Moving back to the business case, the Risk Assessment section outlines the risk(s) associated with each approach option defined in the previous section as well as identifying the risk(s) of doing nothing to address the problem/opportunity.  The final section is the Value Analysis section.  The key challenge I have noted is that short-term value methods (examples: benefit/cost analysis, payback period) are used to support a decision with a long-term impact.   In the next section we will discuss the unique considerations one must address in developing a valid ERP software customization value analysis.

Value Assessment Considerations for ERP

In addition to the short-term costs associated with ERP customizations one must consider the following areas to calculate the long-term costs:

  1. Impact to Upgrade and Maintenance:  What is the impact that the customization will have to the ERP maintenance and upgrade process.  Is the software customization intrusive? – Meaning is it an add-on enhancement or a fundamental change to how the ERP software works?  The more intrusive the customization is the greater the costs required for ERP support and upgrades.   Frequent ERP upgrades are a key strategy for driving additional business value.
  2. Impact to IT Resource Sourcing:  The more you customize the ERP software the more customer-specific ERP knowledge an IT resource requires to provide an effective level of service.  Additional customizations will have a shrinking effect on the IT resource pool and may have the potential of driving up related IT support costs. 
  3. Cumulative Impact to the IT Footprint:  Too often we consider customizations individually and not part of the total ERP software changes made.   A field change here or a new application page may not seem like a big deal but you must remember that you must support everything you customize.

The above areas will ensure that you generate a holistic set of information for an informed decision.  Too often, short-sighted decisions are made to customize ERP without completely understanding the potential impacts.  The next section will shed more light on some of the less obvious risks associated with not having a holistic business case.

 Risks of not developing an effective ERP customization business case

Incomplete information results in incomplete decisions and more importantly – missed expectations and business results.  Following are a few of the key risks generated from over-customizing your ERP software:

  1. Greater operational costs:  There is an additional cost associated with customizations –typically required from the IT organization to support and manage the software changes. 
  2. Slower deployments of technology:  With additional technology dependencies generated by ERP customizations come the additional planning and testing activities required to deploy new ERP functionality.
  3. Lost opportunity costs:  This is an area that is typically overlooked in customization value analysis.  It is more than just comparing one ERP customization to another but also identifying the potential reduction in flexibility ERP software can provide to the business. 

Summary

ERP is a long-term proposition and requires a long-term business case and value analysis for any change in the ERP’s value proposition.   Too often decisions on ERP customizations are based upon partial information and are made in isolation.   ERP is only one component of a business solution.  Business processes and People have a greater impact on business results. 

Key Drivers for Business Results
Key Drivers for Business Results

Granted, the full impact of a customization decision may not be fully appreciated in the short-term but poor decisions will build into a formidable wave that will keep you from experiencing value from your ERP investment.

Join the community! 10k followers across 100 countries!

Cloud Can Bring Out the Best of ERP

Previously, I discussed some of the hard realities customers have to manage as part of a Cloud ERP solution.  However, these challenges should not deter customers from looking at a Cloud ERP deployment model.  There are broad advantages for Cloud ERP including incremental scalability and smaller start-up investment.  I would like to speak to some of the less known advantages that a cloud model can provide to ERP customers.

ERP Value Proposition Revisited

In a previous blog article (ERP Makes for an Expensive Custom Solution); I outlined the key advantages and challenges associated with ERP software.

ERP Pros and Cons

ERP Advantages and Challenges

 

For a successful ERP implementation, it is vital that the approach address both the inherent advantages and challenges.  The right cloud deployment model can address many of the ERP advantages/challenges in a more effective manner than a traditional On-Premise model. 

How Cloud Can Make ERP Value a Reality

Let’s briefly discuss how a Cloud ERP model can have an advantage over an On-Premise ERP model using the inherent ERP advantages and challenges as the context for the comparison.

How Cloud can support ERP Advantages

Cloud ERP vs On Premise ERP

Let’s discuss some of the less obvious advantages in more detail:

  • Standardization:  Cloud ERP will have an advantage over an On Premise model simply because the costs tend to be more visible to business users.  Traditional internal IT organizations in general do not have a service-oriented price model for their internal customers.  The cost of not standardizing business processes gets lost in the general IT overhead allocated back to internal businesses.
  • Share IT Development Costs:  as far as short-term capital expenditures and scalability costs, I can see where Cloud ERP has a definite advantage.  Longer-term or Total Cost of Ownership may swing the advantage to an On Premise model given factors like (a) customer size and (b) level of software customization required.

Next, let’s review a comparison between Cloud ERP model and On-Premise model on which model can better address inherent ERP challenges.

Cloud vs On Premise ERP Challenges

Cloud vs On Premise ERP Challenges

Let’s discuss some of the less obvious challenges in more detail:

  • Organizational change:  When you own the change the more likely you are to accept the change.  Even though there may be a divide between business users and an internal IT organization, they are both part of the overall organization.   A rapid deployment of functionality does not necessarily mean a rapid user acceptance and effective use of technology.
  • Requirements gathering:  Requirements gathering and business analysis is a gap that most ERP Cloud providers have not addressed effectively.  Onsite, face-to-face interactions is still the most efficient means of gathering and validating business requirements.

 Regardless of the advantages that Cloud ERP may have over an On Premise ERP model, a customer with unrealistic expectations for Cloud ERP will result in a disappointing experience.

 Beware Of Unrealistic ERP Cloud Expectations

Cloud ERP is an evolving solution model with as many misconceptions as hype.  In fact, many have labeled these misconceptions as cloud washing.  Following are common perceptions and misconceptions that customers may have with Cloud ERP offerings:

  1. Huge cost savings:  This can be a huge misconception if customers expect to run on the latest/greatest/fastest possible hardware.
  2. Quick solutionsThere can be a perception of a real-time, on-demand value generation for customers.  It is important to remember that Cloud ERP is only one component of a business solution.
  3. Greater collaboration: Cloud ERP or any technology does not automatically result in greater interconnection between people, departments, and companies.

Be careful of expectations that go far and beyond what the cloud is actually capable of providing.  Customers may want everything automated without having the discipline and effort to utilize technology appropriately.   As the saying goes “You can’t have your cake and eat it too!”

Summary

Cloud ERP is a maturing deployment model that may provide a greater opportunity to capitalize on an ERP investment.  A Cloud ERP model encourages standardization through visible economic drivers and provides the opportunity for greater focus on strategic activities. However, we need to balance our enthusiasm for Cloud ERP with realistic expectations.  There is no such thing as a push button solution. 

Join the community! 10k followers across 100 countries!