Integration Trumps Functionality for Enterprise ERP

By design, ERPs are created to act as the “source of truth”.  This design becomes a challenge when the customer has multiple ERP solutions.  Each ERP wants to be the master.  Most ERP vendors provide an integration to most popular ERP systems but these integrations are point integrations at best.  “Best of Breed” may be a viable option.  However, many ERP integration cost analyses only focus on a small area and do not calculate the true cost of ownership.  The purpose of this article is to elaborate on the Total Cost of Ownership (TCO) for integrating multiple ERP systems to ensure informed decisions are made by customers.

Clearing up the Myth of Seamless Integration

Seamless integration is more of a marketing label and is not a technically accurate statement that defines Out-Of-The-Box (OOTB) integrations between multiple ERPs.  This is based on my hands-on experience and scars earned from ERP implementations across on-premise and cloud deployment models.  For our discussion, I will focus on the two extremes of ERP integration maturity.  Consider the following illustration.

To create a seamless integration between different ERP solutions with different propriety data models requires each ERP solution to “think” they are the source of truth.  This requires synchronization across setup (i.e. configuration, workflow, security) and transactions (originating in source ERP system and confirmation/completion transactions in target ERP system). 

Deep integration enables the ability to synchronize and transfer data at multiple layers required for an enterprise ERP solution.  Point integration only provides the basics to send and receive business transaction data.   In general, point integration has limited support across the entire enterprise level.  Therefore, additional efforts (manual) are required to keep configuration, workflow and security data synchronized between the multiple ERPs.

ERP configuration is an integration level that is typically understated in terms of importance.  Many point integration designs leave configuration synchronization as a manual task that the customer performs. Consider the following illustration:

Given the cost of developing a deep integration between separate ERP systems, a majority of implementations go with the manual route to keep configurations in sync.  This tactical decision will have an impact to business users moving forward.

Calculating Total Cost of Ownership for Integration between Multiple ERPs

Another area that is typically underestimated is the true cost of integrating multiple ERP systems.  Most estimates focus on only one phase of the TCO for ERP integration:

PhaseDescription
Initial CostEven with ERP vendors providing SOAP/REST wrappers or web services, effort is required for configuration, testing and validation. 
Configuration CostThe majority of OOTB ERP integration does not include Master Data Management (MDM) features required to keep multiple ERP systems in sync.  This requirement is typically addressed manually.  Manual updates involve time in data entry and coordination.  Manual updates provide an opportunity for data error. 
Technical Maintenance CostAssuming a Cloud delivery model, ERP updates are more frequent then traditional on-premise delivery models.  On average, a competent Cloud ERP vendor will provide two updates per year.  In general Cloud ERP vendors will provide an update that has been tested on a “general” configuration and transaction profile.  Thus, a “mature” customer will perform some level of testing with each release.
Functional Maintenance CostThis can be an area with a potential of wild speculation.  Taking a pragmatic approach, I will only consider the additional manual effort required to coordinate key enterprise functionality including: data analysis, workflow administration, security administration, and data integrity.   I understand that there are additional software solutions (i.e. cogs) that you can add to address the gap(s).  However, I consider the additional costs as a missed opportunity to invest in innovation.  Besides, just as with a physical machine, the more technical cogs you add to a solution the greater number of potential failures you create.

Given the above elaboration, consider the following TCO analysis:

Consider what other ERP industry experts have stated:

“Integration costs, which include both year zero installation and continued operational expenses, can be as much as 40x each application’s initial cost.” IDC

“Corporate developers spend approximately 65 percent of their effort building bridges between applications.” Gartner

“Mixed-vendor environments can cost 4x as much as a single-vendor.” IDC

“In a survey of 100 CIOs and IT managers from 84 companies by software vendor intersystem, 67 percent answered “yes” to whether strategic integration project have been held back due to excessive software and services cost.” ComputerWorld

Far too often, ERP business cases only capture the initial cost(s) of multiple ERP integration, which is a disservice to key decision makers.  Yet, I want to be transparent to you the reader in stating that my above analysis is a broad, general estimate at best.   I have attached the cost model I used for this analysis.   Feel free to prove it out for your environment.

Limited ERP Integration Results in Limited ERP Functionality and Added Complexity

Implementation services are by far one of the largest costs of an ERP solution.  As such, customers will inherently look to keep implementation costs as low as possible.  Corners will be cut and scope will be kept to a minimum. The tragedy here is that decisions are made without all the facts and limitations fully elaborated.

Let’s frame our discussion around a frequent ERP deployment scenario.  Let’s say that we have a customer selecting two separate ERP systems for a best-of-breed approach.   We also assume that the customer is not interested in building a deep integration between the ERP systems and will only utilize the OOTB point-integration services.  The customer has a vague understanding that they are required to perform some manual synchronization of configuration setups across both ERPs.  Both ERPs go live and functional business tasks are handled competently by both ERPs.  The constraints reveal themselves when business activities and decisions cross multiple business processes.  In general, these constraints make themselves evident in the following functional categories:

Granted, there are plenty of technical solutions out in the market to address these functionality gaps.  However, consider the IT technology complexity considerations:

Just because there is a technical fix to solve the gap does not validate the need.  Not convinced?  Consider the following customer comments regarding the limitations that ERP integrations can impose:

“We purchased about 3 best-of-breed solutions in the areas of Asset management, Financials and Human Resource management. We have spent over ~N25M, over 12 months to implement, N2M+/yr for support/upgrades per solution, a whooping N35M for integration and it still does not do what we want.

This is the second time we have gone through the integration cycle yet our systems cannot deliver the real-time, asset-driven, consolidated information that narrows the horizon of data into seconds/minutes, not batched hours/days or a week’s worth of data whose latency effectively negates the ability to react with any effectiveness.

The CEO has asked that we look for a single source ERP that is highly flexible and extensible. He is seriously searching for a LONG TERM solution. At this point, he does not care if it is the ‘best’ in a specific area; he wants a robust, single source ERP that can meet all the needs of the company without the headache of integration.” Source:  Infoware.

The bottom-line question you need to ask yourself is “Are the additional complexity and dependencies worth the effort?”    This is a question that should be answered at the enterprise level, not the business functional (siloed) level. 

Recommendations for Customers

Customers should challenge their ERP vendors and System Implementation (SI) partners on their 3rd party integrations.    Following are key points for consideration:

  • Understand exactly what is provided and not provided with OOTB ERP integrations.
  • Quantify the effort required on the customer to address the gaps in OOTB integrations.
  • Reducing technology complexity is the greatest enabler for reducing business costs and maximizing business agility.
  • Warning!  Short-term thinking usually results in siloed thinking, which typically results in business limitations and lack of flexibility.

Challenge to ERP Vendors and SI Partners

I can appreciate that providing additional information and guidance may potentially slow down the ERP selection cycle.  However, I believe that we (including myself) are duty bound to provide complete guidance to ensure a customer makes an informed decision.  Following are key points for consideration:

  • Identify the functional limitations within your solution for a multiple ERP environment.
  • Explicitly define the levels of support for multiple ERPs across all levels (configuration, security, workflow, originating transactions, closing transactions).
  • Explicitly quantify the level of effort for customers to support OOTB point integrations for ERP systems.
  • Quantify the TCO for ERP point integrations versus ERP deep integrations.

Summary

In general, enterprise ERP solutions inherently support deep integration between their modules based on their design on a common data model.  Regarding whether to pursue a multiple ERP versus a single ERP approach, I take a results-oriented approach – whichever strategy adds the greater impact (%) to the Income Statement is the right choice.

On a practical note, when ERP vendors state their solutions integrate with competitor’s ERP products/solutions, it is important to understand to what level of integration is provided OOTB.  Put yourself in the shoes of ERP vendor.  How easy would you make your ERP system integrate with a competitor’s offering?  Due diligence is required on every party (ERP vendor, SI Partner, Customer) to ensure that a complete set of information is provided to make an informed decision.

Join the community! 10k followers across 100 countries!

Using AI/ML to Build Customer-specific ERP Roadmaps

How much does it cost to create a customer-specific ERP roadmap?  $50k, $200k, $1m+?  This effort typically requires the higher end consultative guidance and advisory role(s).  It also requires a significant amount of customer leaders’ effort/time to support this activity.  What if I can show you an approach where one can automatically generate a custom ERP roadmap? If interested then allow me to elaborate.

Are you a Believer?

Before we start, I will ask you to make an investment.  I have a habit of repeating myself therefore I will ask you to review the following blog postings before I begin:

Now, if you are still interested then I will ask you to stretch a little further.

Model versus Reality

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

Key Points and Observations:

  1. In a majority of cases, there is a difference between potential ERP utilization and actual ERP utilization experienced by customers.
  2. In order to promote repeatability, there should be a logical progression that enables customers to maximize ERP utilization (i.e., roadmap).
  3. To minimize ERP Total Cost of Ownership (TCO) and eliminate cost constraints, ERP cloud vendors should provide customers with the ability to increase ERP utilization without heavy reliance on consulting services ($$).

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

ERP Utilization Roadmap Model

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

Key points and observations:

  • Any deployment of ERP features that require a significant organization change is not a quick win.  People do not change overnight.
  • An incremental approach like Business Process Management (BPM) is required when deploying new ERP features at the same CMMI level for a given business process.
  • Set A includes the BPM enablement activities and ERP feature deployments required to align with the logical maturity path.  Note that only incremental change is required to implement targeted ERP features (thus, a quick-win).
  • Set B includes the Business Process Re-engineering (BPR) enablement activities and ERP feature(s) deployment required to align with the logical maturity path.  Set Y is not a quick win.

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

Automating Implementation Guidance & ERP Roadmap

I will utilize the following illustration to put the previous concepts into view.

There are 3 key automation players in the mix. 

  1. ERP Configuration Manager:  This is a feature of the ERP software that provides an ordered list of data and functional configurations required to implement a feature set within the ERP solution (aka table loading sequence).   A competent ERP vendor should provide this capability out of the box.  Unfortunately, most ERP vendors only provide ERP configuration manager functionality that only provides the “technical” guidance for configuration.
  2. Implementation Advisor:  The implementation advisor compliments the existing ERP configuration manager by providing functional and organizational guidance to the customer during the implementation.  The guidance is harvested utilizing AI/ML recommendations based upon findings and trends identified across the ERP vendor’s customer base.  The implementation advisor would utilize both structured and unstructured learning to provide the most relevant guidance.
  3. Solution Advisor: The solution advisor focuses on providing the iterative and progressive ERP product feature set(s) required to attain the targeted CMMI level for a business process.  The solution advisor must have access to current ERP features implemented but also how effectively business users are utilizing ERP features

The key strategy of the ERP Utilization model and the solution advisor is to provide an incremental, progressive maturity path that is risk adverse and minimizes huge organizational change.

What’s Missing? Challenge to ERP Vendors

As stated earlier, the majority of ERP vendors provide business process models that highlight how ERP vendors define business processes within their software.  The gaps I’ve observed with most ERP business models are there are no relationships defined between the business activity and the corresponding CMMI maturity level and ERP product feature(s).  Adding this metadata to the model will enable an automated approach to implementation and roadmap guidance.

Summary

Implementation costs remain the largest part of an ERP TCO analysis.  The cloud delivery model has greatly reduced the hardware/software/infrastructure costs.  Unfortunately, the ERP market places more focus on vendor capabilities and emerging technologies versus ease of implementation and customer self-sufficiency with ERP services.   No technology adds any business value until its in production.  Second, an automated ERP solution advisor provides real-time guidance to customers versus periodic, manual feedback that generally results in “leap-frog” implementations that have greater risk(s) and cost(s).   Stay safe!

P.S. – Despite my sincere attempt, I did repeat myself.

Join the community! 10k followers across 100 countries!

Disrupting the ERP Cloud market with Business Value Realization

“In a survey of 1,322 global organizations who had implemented ERP in the previous three years, only 21% of respondents said that they had realized 50% or more of the expected benefits.” (Source: Lumenia). 

Total Cost of Ownership (TCO) and Return On Investment (ROI) are the outdated, traditional indicators of ERP success.   These metrics have been turned on their heads with the new Cloud ERP subscription based model.  Even with cost reduction, the subscription model does not solve the issue of unrealized business value.

It begs the question when will Vendors and the System Implementation (SI) Partners provide a more equitable risk/reward agreement via a business value based pricing model?  In the current Vendor-SI-Customer model, the customer assumes the majority of the business risk(s) & cost(s).    Given that the Cloud ERP market is still open for domination, customers should consider a business value based agreement where all parties share in the rewards and risks associated with a transition to an ERP cloud subscription service.

Paradigm Shift from Vendor SLA Compliance to Business Value Realization

The traditional “On-Time, On-Budget” KPIs have no direct impact on Business Value Realization (BVR).  The KPIs are more of a Vendor-Service Provider metric to demonstrate that the Vendor-SI Partner completed the delivery of services.  This approach assumes that the Vendor-SI Partner knows “exactly” what the customer needs for BVR.  Also consider that the “On-Time, On-Budget” metrics is more aligned with a commodity-based service.  As a customer, do you want a commodity-based implementation approach or a custom customer-based approach for your Cloud ERP transition?

With current subscription and professional services contracts, there are no financial incentives to ensure all stakeholders focus on the true objective of value realization. 

Building a Business Value Based Agreement

The first and most important step in aligning partner(s) focus on BVR is developing a Statement Of Work (SOW), Service Delivery Agreement (SDA) that focuses on attaining business value.  Consider the following example:

Business Value Realization (BVR) is a mutual responsibility between the Customer, the Vendor, and the SI Partner.  This agreement does not infer that the Customer will get the cheapest price for an ERP transition to the Cloud.  In fact, this agreement will cost the Customer more than a “commodity-approach” ERP transition to the Cloud.  “You get what you pay for.”   Contrary to marketing hype, there is nothing inherently “intuitive” about the Cloud model.  The implementation effort is the same to the SI Partner. 

Smart Transition to a Business Value Realization Agreement Model

Every ERP Cloud Vendor and SI Partner will say that their #1 priority is your company’s business success.  Yet, this is not always true “in the heat of the battle”.  Customers also need to step up their investment and capacity for change with this agreement approach. 

I cannot count the number of times where customers did not know what they purchased or they did not purchase every individual product to support their business process(es).   Keep the focus on business results, not product(s) and feature(s). Second, ERP service training must be available and easily accessible across multiple delivery platforms.  Vendors should also make formal training as cheap as possible.  Consider the following quote:

“Untrained (or under trained) users may end up needing three to six times as much support as end-users who have been trained.” ERP: Tools, Techniques, and Applications, Carol Ptak, Eli Schragenheim.

ERP Vendors, it is as simple as this.  Either you take a smaller profit hit now by providing free formal training or you will pay in buckets of operational support costs down the road.  In the next illustration, we will discuss key responsibilities and maturity activities for SI Partners.

 

In my humble opinion, SI Partners have two key responsibilities for competent delivery of ERP implementation services: (a) maximize the value of the Cloud ERP service purchased and (b) complete knowledge transfer for Customer enablement.  It is also important that the Customer defines an accurate KPI baseline on existing business activities in order to compare against business results experienced in new Cloud ERP service.  SI Partners should be able to assist and guide Customers in this exercise.

Now, let’s have a practical discussion regarding the customer’s responsibilities:

Customers have to align their expectations to their executive’s decision to move to an ERP Public Cloud service.  There are non-competitive business activities and reporting that should be eliminated.  ERP software changes will accelerate by a factor of 5 in an ERP Public Cloud delivery model.  Either you can make an investment in Organizational Change Management (I recommend Prosci  (ADKAR) or your company can expect to maintain/grow their IT budgets given all the ERP extensions they have to test and maintain with every service update.   

Money Talks – Consider Retentions to Promote Shared Success

The traditional approach of using go-live as the key event for ERP service delivery is not an effective indicator for business value realization.  Is the event a prerequisite? – Absolutely!  In a previous post I discussed how true business value realization is not possible until you are past the stabilization phase.   I would recommend that you create retention of 25% for both professional services fees and vendor subscriptions to promote focus and delivery from every provider until business value is realized. 

Summary

Gartner estimates that companies are achieving only 43% of their technology investments’ full potential value. 

In my humble opinion, an overriding driver for this gap is the traditional approaches Vendors, SI Partners, and Customers are clinging to in driving business value from technology.  ROIs and TCOs are extremely high level estimates based on a huge number of assumptions and constraints that are not fully defined in the sales cycle.  ERP Cloud vendors and SI Partners are more concerned with transaction efficiency and commodity repetitiveness versus unique customer business success.    A Business Value Realization agreement is not easier, or cheaper and will require a greater investment from all three players.    

Don’t expect any ERP Cloud Vendors or SI Partners adopt this approach any time soon given where we are at in the Cloud ERP market cycle:

As the market reaches its apex and competition continues to grow, disruptive agreements based on BVR will become a strategic competitive advantage.  Customer will make a decision on whether they want a Vendor or a Partner.  ERP Cloud Vendors are transactional and replaceable.  ERP Cloud Partners are long-term relationships critical to your success.

Join the community! 10k followers across 100 countries!

Using AI/ML to create a Customer-specific ERP Business Process Maturity Model

In this post, I will define a case study where my utilization model is applied for a customer.    A key point to be made here is that the health and effectiveness of the business process is directly related to the performance and utilization of ERP features that support the business process.

Case Study – Procurement Business Process

For our discussion, we will focus on the procurement business process.  Following is a generic definition of the procurement business process.

To continue this illustration,  I will define the key business activities associated with the procurement functions highlighted.  I will also define how business activities are likely executed based upon the business process Capability Maturity Model Integrated (CMMI) level.

Legend:

  • Manual:  The business activity is performed manually.  We can assume that since the process is manual that the organizational capacity (resources) is lower for adopting mature business activities.
  • Partially Automated:  The business activity is partially automated.  Manual effort is still required to complete the business activity.  Integration is performed manually.
  • Automated: The business activity is completely automated.  However, the inputs and/or outputs for the business activity are point integrations at best.  Example of this scenario is when a customer utilizes an isolated point solution for a specific activity.
  • Integrated:  The business activity is automated with limited integration.  Integrations are limited to the immediate input and output business activities.
  • Closed Loop:  The business activity is both automated and integrated across the entire business process.  The customer has visibility to data and metrics across all business activities.

Disclaimer: Now, you may not completely agree with all the information presented in the above illustration, but please do not let that derail you from our discussion. 

A key premise of the above model is that mature business activities will provide very limited to no business value until the underlying business process maturity levels are implemented.  There are two key factors that directly influence business process maturity levels: technology and people.  Practically speaking, we can agree that reaching a CMMI Level 4 or Level 5 requires an integrated and closed loop technical infrastructure that supports the entire business process.

To complete the model we need to answer the following question: “How does this relate to ERP product features?”  There are two aspects to consider.  First, what appropriate ERP feature(s) support the business activity.  Second, to what level of functionality should the feature be deployed.   For example, a standard feature in the accounts  payable function is matching.  Matching is an audit performed for goods and services through the entire process.

Continuing the discussion, if I am working with a customer with a procurement CMMI Level 1 then my focus (scope) will be on implementing either 2-way or possibly 3-way matching in accounts payable.  For many of my seasoned colleagues in ERP consulting, this conclusion would appear self-evident.  However, to an emerging customer or a new millennial in ERP consulting or sales, this automated guidance would be insightful.

Application in the Real World

Let’s say I am a customer performing research of ERP vendors for a procurement solution. Today, I have two options:

  1. I can gather information via the ERP vendors’ websites. Generally speaking, there are at least 4 ERP products (purchasing, inventory, account payables, and supplier management) that support the procurement business process. For argument stake, let’s assume that each ERP product has 20 features and most ERP vendors provide a feature list for each of their product offerings.  If my math is right, that means that I would have to wade through 80 features to determine if the ERP product(s) are a possible fit.
  2. I contact a sales representative or presales assistant to gather information. Next is a series of business need assessment questions I have to answer before I can get the information I need.  Most likely, I would also have to involve business users in the ERP vendor’s information harvesting to get any value from the activity.

I would prefer a self-service option that would ask me two key questions:

To expand on this scenario, I provide the following information to the above questions:

  • Procurement CMMI Level: 2
  • Organizational Capacity for Change (OCC): Low

We can leverage the above information to quickly refine our ERP product focus to the area highlighted

The power in this approach is to quickly focus on the business activities and corresponding ERP product features that can mature the customer’s procurement business process.  Instead of asking a battery of questions that add little value, we can focus on the “low hanging fruit” that can generate quick wins for the customer.  However, keep in mind that the customer responded that they have a low OCC.  This indicates that we should implement ERP product features that aligns to the customer’s current business activities/maturity.  Technology alone does not mature a business process.  Keep it simple!  Keep it fast!

Value Proposition

Customers are looking for a specific, cost-effective ERP adoption roadmap that will enable them to mature their business model in a rational manner.  Today, this guidance is created by outside consultants costing thousands of dollars and time commitments from business executives.  Using the above model gives us a solid foundation that we can enhance versus rebuilding the wheel for every customer.  Automating this model and improving guidance via machine learning enables ERP vendors and consultants to accelerate guidance delivery to customers.

Summary

Even with the cloud, ERP implementation services and guidance are still the largest costs that make up Total Cost of Ownership (TCO) for customers.  As the cloud delivery model continues to squeeze TCO, ERP vendors and consultants have to find most cost effective methods to deliver specific value and guidance to customers.  Machine Learning, CMMI Business Models and ERP Utilization Models can be key enablers to automate business solution guidance.

Join the community! 10k followers across 100 countries!

The Next Evolution of ERP: Adaptive ERP

With the initial release of ERP, one of the key “game changers” was the ability of business users to access data and generates reports without direct IT involvement. This empowerment of the business user had a significant impact on business agility. Today, we continue to see ERP vendors focus on providing business-friendly tools for reporting and analysis.  Yet, I can see a new evolution brewing in the ERP industry what I like to call “Adaptive ERP” where business users can perform on-demand actions to meet business changes real-time.  In the next sections we discuss the key capabilities of Adaptive ERP and a practical assessment of where the ERP industry is today.

What is Adaptive ERP?

Adaptive ERP would enable business users to configure, simulate, test, and implement business technology changes with limited traditional IT services (ex. software development).  Predictive analysis will become a reality.  Logical thinking and search methods will be more valuable than technical syntax. Information will become context and even transactional specific.   Following is an illustration of the major domains that Adaptive ERP should address:

Adaptive ERP

Conceptual Model of Adaptive ERP

Domain:  Logical Development

Too often a change in the business model requires an IT development effort.  Any competent IT development will require the following activities:

  • Business requirements gathering
  • Technical design
  • Technical construction
  • Unit, System testing

In general, the greater the number of individuals involved in a project the greater the coordination/communication effort resulting in a greater time commitment.  Enabling business to become agile will require an evolutionary change in how ERP supports business activities.  However, simply removing people out of the equation is not the answer.  What is required is providing business owners the tools and experience required to become more self-sufficient.

Logical Development

Logical Development for ERP

Following is a brief list of the capabilities required to enable business users to perform logical development

  • Business models must be defined as metadata within the ERP software.
  • Business rules are separate from technical components and are exposed directly to business users.
  • Business scenarios are defined separate from the respective business models. Business exceptions are variations to a specific business scenario.
  • Business users should have the ability to run simulations in production (i.e. parallel testing)
  • ERP must provide automated testing support
    • Automated unit and system testing (self-learning via business model metadata).
    • Automated business process test scripting.
    • Test scripts are a results-oriented view of business requirements.
    • Automated impact analysis with logical development change.
  • Business users should be trained in logical and structured thinking.  There has to be a prescribed process to effectively conduct knowledge transfer with the ERP software.  Business users should be able to directly educate (i.e. configure) the ERP software on how they run their business.

Remember that a key value proposition for ERP is to reduce software development.  This is not an argument to eliminate IT but rather to refocus IT from tactical support to strategic activities.  IT will play a very important role in enabling business users in logical and structured thinking.

Domain: Predictive Analysis

Today, there is interest in Big Data and Enterprise 2.0 technologies but they are not the final destination.

Predictive Analysis

Predictive Analysis

At the end of the day, business decisions have an impact on business results. Enterprise 2.0 and Big Data are supportive technologies.  Enterprise 2.0 focuses on the utilization of Web 2.0 standards in developing collaborative technologies like blogs, RSS, social bookmarking, social networking and wikis.  Enterprise 2.0 emphasizes employee, partner and consumer collaboration for creating knowledge.  Big Data is the next evolution in Knowledge Management where it is now viable to manage and utilize both structured and unstructured data.   However, the key challenge remains – how to effectively leverage all the information we are collecting.  We need to flip the following time paradigm:

Data Analysis Cycle

Business Information Cycle

Changing this paradigm will require inference engines that streamline analysis generation and enable predictive analysis.  Following is a brief list of capabilities that will support predictive analysis:

  • Case-Based Inference will provide recommendations based upon data and transactional patterns.
  • Rules-Based Inference will provide tactical, operational decision support based upon standard business principles.
  • Big Data will facilitate the assimilation of structured and unstructured data to identify patterns and provide operational context.
  • Collaborative ERP 2.0 will support collaborative discussions and provide transactional context for decision support.

Advancements like this in analytics will enable business users to focus on the value-add activities of reviewing analysis and drawing conclusions for effective business decisions. 

Domain: Open

Whether or not you are sold on open source ERP,  you have to admire the new paradigm and simplicity that open source ERP promotes.  As we continue to see the consumerization of legacy ERP technologies, the market will continue to drive individual user enablement and vendor independence.  Following is a brief list of capabilities that will promote a more open ERP industry

  • BYOD (Bring Your Own Device)will enableemployees are able to bring their own computing devices – such as smartphones, laptops and PDAs – to the workplace for use and connectivity on the corporate network.
  • BPMN compliance will ensure that ERP business process definitions will agree with business process definition standards outlined in the Business Process Modeling Notation (BPMN) model.  This model is governed by the Object Management Group (OMG).  In my humble opinion, the OMG is in the best position to define a global standard for business process models.  This advancement will be a key enabler to the holy grail of true enterprise system interoperability.  This is no small task and will require significant market demand to promote this standardization initiative.
  • Collaborative Shared Development is a key benefit of an open community.  Sometimes it takes a village of developers to support an ERP solution.  Today, I can go to the Apple App Store to purchase an app for my iPhone.  In the future, we should see an ERP App Store when a customer or an individual business user can download an object (software, report, role-based feature) to customize their ERP experience.
  • Open Partner Network.  The more integrated your ERP is within your business value chain (suppliers, vendors, customers, providers) the more powerful your ERP system can be.  I expect we will see the ERP market put more value in delivered integrations with partner, supplier, and provider networks over software product features.  SOA will be a key enabler for making open partner networks a reality.

Openness is about creating flexibility and the freedom for a customer to respond to the changing business environment in the most effective manner.

Domain: Viable Solutions

A profound lesson I learned the hard way is that regardless of how many features and products an ERP vendor can provide (even for free); it will all be all in vain if the software is unmanageable.  It is unacceptable that a customer has to pay triple and even quadruple the original software cost to maintain their ERP investment.  Some may argue that ERP vendors have not acted in the best interest of their customers by building features upon features without providing tools to significantly reduce the Total Cost of Ownership (TCO).

Simplifying Technical Support

Simplifying Technical Support

Following is a brief list of capabilities that will significantly reduce TCO:

  • Automated testing (self-learning tools).
  • Automated master data management (information awareness tools).
  • Eliminate the need for multiple instances.
  • Assimilated, holistic solutions– loosely coupled point systems will not work and result in greater costs and possible failures.
    • Minimize the technical stack.
  • Higher Quality Assurance
    • Upgrades/Software Maintenance releases included the test cases and results performed by the ERP vendor.
  • Implementation Wizards
  • Support for Hybrid Deployments
    • Software architecture can support either single or multiple tenants.
    • On-Premise, Hosted, Public Cloud, Private Cloud for either applications and/or data.
      • Example:  Customer decides to store mission-critical data on-premise and internal data on the public cloud.

It should no longer be acceptable that an ERP customer has to totally shoulder additional implementation and upgrade costs.  This is not indicative of a true partnership.

Challenge to ERP Industry for Adaptive ERP

Today, we continue to see a consolidation of the ERP industry.  With these acquisitions some ERP vendors provide some limited capabilities of Adaptive ERP but these capabilities are spread across multiple software products and platforms.  An ERP solution is only as strong as its weakest link (integration).  More technologies loosely coupled together usually mean (a) more IT resources, (b) additional points of failure, and (c) a more complicated experience for business users. We have witnessed where ERP software has become bloated with features upon features without any logical progression.  ERP customers are forced to deal and pay for unused features resulting in more frustration than simplicity.

Many top-tier ERP software solution packages use a systems configuration concept to set up the business environment for some time but please allow me to challenge the industry a little more. I agree that several ERP software packages provides configuration concept yet there is no clear decrease in implementation schedule (ex. SAP) or cost savings associated with this approach because the currently exposed configurations do not change that frequently (ex. Earning Codes, GL Accounts). Objects like business rules, scenarios, and exceptions change more frequently. This is a challenge for some ERP software (ex. PeopleSoft) where many business rules are encapsulated within the technical object. Pre-configurations are only a beginning – it adds value in the short-term but ERP is a long-term proposition. In my humble opinion, the key is to expose the underlying business model to business users for greater real-time interaction.

Also, there are Master Data Management (MDM) solutions available to support a tactical level of data governance by removing duplicates, standardizing data and, incorporating rules to eliminate incorrect data from entering the ERP system.  For Adaptive ERP, MDM must advance in what I call “information awareness”.   Information awareness means two things (1) MDM is able to automatically detect and define new information sources within the enterprise ecosystem via data polling, and (2) MDM is able to determine how data is used.  These capabilities will be key enablers for automated impact analysis.

What we need to have is a mature, open, holistic solution where all the individual software platforms are assimilated into a robust, uniformed solution.  This is not simply building a dashboard that brings together two separate user sessions together or an orchestration level that adds another level of technology abstraction and performance overhead.  A viable solution is a manageable solution.

Summary

I’m a firm believer in performing non-competitive business activities as competent and cheap as possible.  In that end I am a firm believer in ERP.  However, the ERP industry has come up short in the areas of total cost of ownership and business adaptability.  Many on both sides of the aisle have wrongly concluded that more software features and increasing the technical stack are the answers for making ERP adaptable.  Putting more power in the hand of business users is the strategic answer for business agility.  People are the most important and adaptive component of a business solution.