PeopleSoft Knowledge Map

Knowledge is power!

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

Available Resources:

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

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

IT Should Move Up the ERP Value Chain

A key challenge in my role as an IT ERP Director was to maximize business value with a shrinking budget.  It was quite an education for a person with the majority of his experience in Tier I ERP Consulting.  There are many options competing against IT organizations in providing ERP services (SaaS, Cloud, Off-shore and Near-Shore support models).  Two key battlegrounds are ERP software development for customizations and ERP support.

Show me an IT organization whose key competitive advantage is that they are internal and I will show you a shrinking IT department!  There must be a major shift in IT’s value proposition for ERP support.  In the next sections we will discuss some of the shifts IT ERP shops need to make to stay competitive and relevant.

IT ERP Support Can Be Done Cheaper

For the purpose of this blog discussion let’s broadly assume that there are three tiers of ERP support.

ERP System Support Model

Levels of ERP Support

There has been much discussion regarding outsourcing IT support along with noted advantages and disadvantages.  I will not join the debate on one side or the other but I do consider myself a realist.  Generally speaking, you are looking between 30% to 50% reduction in costs (depending on the study) which just can’t be ignored.  Instead of fighting the change I prefer to control the change in such a manner as to enable my ERP IT support team to generate greater value for our customers. 

Also, consider that there are just some activities you should not outsource.  Referring to above model I have been very cautious with outsourcing Tier I support.  Nothing is more reassuring to a business user with a critical issue than to see their IT support partner face to face and have a real-time discussion.  Cost cannot be the only consideration – just like Dell learned the hard way.    If the activity is not strategic and highly valued by your customer then look for a cheap and competent (not world-class) option that will free your IT resources for greater value-add activities.

Trend:  Competitive Advantage for ERP is Configuration over Customization

With the initial release of ERP, one of the key “game changers” was the ability of business users to access data and generate 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 will be able to perform on-demand configurations to meet business changes real-time.  This would go way beyond simple user preference configurations.  Adaptive ERP would enable business users to configure, simulate, test, and implement business technology changes with limited traditional IT services (ex. software development).    Today, some Tier I ERP vendors provide some limited capabilities of Configurable ERP but these capabilities are spread across multiple software products and OS platforms.  It’s a great topic for discussion (and future blog) but not what I would consider a sustainable, viable solution for today. 

Key Evolutions of ERP

Major ERP Development Milestones

 

Advice for ERP IT Departments – Focus on Moving up the Value Chain

In my previous experience, I had an opportunity to work for a Tier I ERP vendor developing new service offerings and consulting practices.  A key lesson I learned the hard way was when a service offering is facing significant commodity pressures either you can (a) reduce the cost or (b) move up the value chain where you can generate a strategic competitive advantage. 

Service Categories for ERP Support

ERP Service Categories

In order to move up the value chain not only will include training but more importantly a fundamental change in what IT considers their strategic business value. Remember that a key value proposition for ERP is to reduce software development.  Therefore, software development should not be the key IT value proposition for the IT ERP team.  Many perceptions and expectations must be carefully managed through this organizational transition.  The goal is to evolve IT software developers into IT business technology advisors.  One only needs to look at the ERP professional services industry to observe what the market will bear for software development roles versus technology advisory roles to confirm the above recommendation.  With this move, internal IT organizations will be able to support more advisory and consultative roles once reserved for external consulting organizations.  Just think of the potential cost savings and knowledge retention to your business.

Summary

Is this the end for internal IT support for ERP?  Hardly! However, more will be asked of internal ERP support teams with limited resources.  This may result in a more challenging and stressful work environment.  What use to be considered valuable has become generally accepted and expected from business users.   To remain a strategic partner, IT ERP support teams should look for opportunities to free up their staff to focus higher up the value chain.       

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.

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.

 

Viable – Manageable ERP

Several ERP implementations suffer from what I call a “fast-food” mentality of delivering value.  Customers feel that they need to get functionality that addresses both existing needs but also future needs given long implementation cycles.  Business needs and business wants get blurred together during requirements gathering which make it harder to differentiate and validate.  Finally, more analysis and effort is spent trying to fit one more feature or capability into the ERP implementation versus understanding the support requirements after the implementation.  Typically, the result is a solution that causes more problems than it solves because the ERP solution is not sustainable.  In the next sections, we will discuss some principles to prevent your ERP project from delivering an unmanageable solution.

Set REAL Expectations for Executives (i.e. There is no such thing as a “push button” solution)

How many time(s) have you heard an executive say “All I want is a button to push so I can produce what I need!”  That statement is enough to indicate that there is a huge “expectation gap” and no matter what you do it will be a losing battle.  To establish expectations for success I use the following strategy:

Setting Realistic Expecations

Setting Realistic Expectations

The first and most important step is to establish realistic expectations.  This effort will require educating your executives on the organizational effort, potential business value, and possible risks involved in meeting an executive mandate.  Be prepared to articulate in layman’s terms what is you can do and what should not do with technology.  Second, use the language that every executive knows and understands: money!  Quantifying business value, costs, and risks in an executive business case can quickly align executive wishes with business reality.  Third, come to an agreement on expectations.  This agreement should be formalized via a signed project charter.  Finally, there should be boundaries (limits) on the agreed upon expectations.  These limits should be defined within a scope statement with constraints and assumptions.  Next, we need to further define and refine expectations for key business personnel that will enable you to meet executive expectations. 

Set REAL Expectations for Business Users (i.e. theoretically correct vs. practically accurate)

Today’s ERP software has increased the amount of data that business users can capture.  In addition, naturally business users see this as an opportunity to drive more business value.  However, capturing additional data does not automatically equate to additional business value.  Consider the following illustration:

theoretically correct vs. practically accurate

theoretically correct vs. practically accurate

It is important to challenge the assumption that more data creates greater value and better decisions.  In the illustration above what is the level of precision required to get to the right answer?  In the pursuit of driving better decisions we can easily start down the path of creating a data-gathering monster that cannot realistically be maintained.  The result is bad or missing data and the goal of driving better decisions is unattainable. 

Set REAL Expectations for IT (i.e. developing software is not the most valuable thing IT performs)

I’m sure if you ask a majority of IT personnel how they generate business value that software development is right there at the top. However, this value generator is in conflict with a core ERP value proposition.  Organizations purchase packaged software like ERP to minimize internal software development.    Internal IT organizations that support ERP solutions must change their definition of value generation for their customers.  Consider the following illustration: 

ERP Service Categories for ERP

ERP Service Value Chain

As you can see above the highest level of services that IT organizations can provide are advisory services that assist internal customers in how to best leverage technology.  Another key concept that is a huge mind shift for IT organizations is to utilize ERP as the fundamental driver for generating additional value versus utilizing a traditional requirements-driven approach.  Let’s look at the implications of IT organizations do not adapt to take full advantage of their largest software investment (ERP).

Impacts of an Unmanageable Solution (i.e. we are not getting value from ERP)

I don’t know about you but I’m guessing that you are being asked to do more with less.  I have a very small IT staff that is responsible for both ERP support and ERP-driven enhancements/transformations.  The IT staff spends the majority of their time (up to 70%) on ERP support.  Even though ERP support is at the lower end of the ERP value chain the activty is a very high priority.   However, this leaves us with a small level of capacity to support higher services.  A high maintenance ERP solution limits your ability to generate greater perceived value to business users.  Business users usually do not perceive value from ERP support services unless something goes wrong. 

Summary

As the ERP industry continues to mature we are observing the rise of more functionality and capabilities to capture even more data.  However, nothing is free. Additional functionality and data capture requires additional discipline and support requirements from both IT and Business users.   Please do not take an extreme approach and stifle innovation.  Business is all about take risks.  My point is – take calculated risks.

Business pain can be good for ERP

Instinctively, we all try to avoid or minimize pain.  This is true for individuals as well as business organizations.  However, in our attempts to reduce pain, we too often focus on eliminating the symptoms without addressing the underlying root cause.  We may feel temporary relieve but our short-term decisions only lead us to a point were the pain resurfaces and the available options to address the pain become more limited and costly.   In the next sections, we will discuss how to address business pain by effectively utilizing your existing ERP investment.

Step #1 – Take an appropriate problem solving approach

Following is a standard problem-solving approach as defined in the Project Management Institute’s Body of Knowledge (PMBOK).

Root cause analysis

Root Cause Analysis

Seems easy enough!  The challenge I’ve observed is that many organizations do not execute the problem-solving process effectively.  To compound this challenge many customers believe that having an ERP system somehow accelerates or simplifies the problem-solving process.  Following are some of the common misconceptions that cause ERP customers to miss the mark in solving problems.

Missing the Mark

Missing the Mark

The misperceptions and inappropriate expectations surrounding ERP can cloud your view of the real problem.  However, the greater hindrances to effective problem solving are the views that (a) pain is bad, and (b) quick-fixes are more desirable (demanded) than permanent solutions to business problems. For an ERP perspective, the typical end-result to quick fixes will be more customizations.  Greater customizations result in less flexibility and more costs. If unchecked, your organization can build band aid fixes on top of one another,which may ultimately result in a catastrophic event.  The key to eliminating this quick-fix mentality is to change the perspective of how pain is viewed.

Step #2 – See business pain as an opportunity

My daughter loves to play volleyball.  Recently, she has experienced some pain with her ankles as well as experienced some falls that caused my wife and me to have concerns.  I suspect that I’m a little over-sensitive given that our daughter has Type-1 diabetes.  We took our daughter to see a sports physician specialist to identify the problem.  “Your daughter has a good problem to have.,” said the specialist, “she is still growing!  Your daughter is still figuring out how to coordinate her changing limbs.”  Whew!  What at relief yet what a good life lesson.  Too often, organizations can’t see past the present pain. We focus only on the symptoms (negatives) without looking for the opportunities (positives).

Many times, IT organizations are motivated by addressing problems by taking a “triage” or ‘fire-fighting” mentality.  IT performance metrics can support this mentality if the focus is only on cycle-time and response-time metrics.  Don’t get me wrong, if a production system goes offline unexpectedly, you can bet that a quick response is warranted.  A red flag to look for is when ERP support problems are seen as an inconvenience rather than an opportunity.  This can be especially frustrating to IT when the problem is a recurring issue.  When viewed as a hindrance there is the natural human tendency to deal with the issue as quickly as possible to move on to the next problem. To get out of the above support rut  first we need to eliminate or minimize reoccurring problems through effective problem solving.  Once performed the IT organization can spend the time to evaluate viable options for greater ERP value generation.

Step #3 – Use business pain as a driver to increase ERP value generation

During my career as an ERP consultant, one of the key challenges I faced with every one of my customers was how to drive additional value from their ERP investment.  As I did additional analysis, a common theme across my customers was that they did not realize the rapid deployment of new ERP functionality.  Based upon my experience, I have identified the top three strategies that support long-term, rapid delivery from ERP.

Strategies for Rapid Delivery via ERP

Rapid Deployment Strategies for ERP

As seen from the illustration above the single largest driver for long-term, rapid delivery of addition value from a customer’s ERP investment is frequent upgrades. However, in the effort to address tactical business pain quickly IT organizations built customizations as quick fixes instead of allowing these opportunities to drive the value proposition for an ERP upgrade.  It is important that the internal IT organization resist the temptation for a quick win and illuminate the IT roadmap that will provide the opportunity for greater value from their ERP investment.  In the next section, we will briefly discuss the price to be paid if one uses ERP as a means to a quick fix.

 The price of ERP quick fixes

There is a price associated with every decision made.  In the case of ERP, the short-term gains will eventually result in limiting your ERP strategy.  ERP quick fixes are typically implemented as customizations.  Customizations require a greater level of support from the customer’s IT organization (because ERP vendors do not support customizations).  IT spends more time performing support activities (indirect business value) versus building new enhancements (direct business value).

Second, customizations add to the upgrade effort.  Third – and most important – performing quick fixes send a signal to customers that counters the basic value proposition of ERP (packaged) software.  The price of ERP quick fixes may be small at first but they will have a compounding effect on the Total Cost of Ownership (TCO).

 Summary

Pain is the way our bodies (and organizations) communicate that something is wrong.  It defines the gap between where we are and where we want to be.  Effective root-cause analysis is the first step to correctly diagnoses the pain and identify viable solutions.  ERP can play a positive or sometimes negative role in addressing business pains.  The key to understand how to correctly apply ERP technology to transform business pains into opportunities for greater business value.

ERP Application Strategy Roadmap for Maximizing Long-Term ROI

You have just implemented your ERP solution – congratulations!  Now what?  Will your ERP experience become an endless cycle of applying maintenance patches and upgrades?  Many customers only realize a fraction of the business value that ERP can provide.  Too often customers rely on their ERP vendor to provide the long-term vision and strategy for increasing ERP ROI – which is general as best. In the next sections, I would like to speak to you about internally creating the vision and strategy for maximizing your ERP investment over the long-term.  It all starts with having an ERP application strategy roadmap.

What is an ERP Application Strategy Roadmap

The ERP application strategy roadmap documents the application strategy that enables the stated business goals, strategies, and processes to be achieved given the IT goals, governance, and capacity.  Generating and maintaining ERP application strategy roadmaps will ensure alignment between business goals, strategies, and performance targets to the required ERP functionality.  In addition, the application strategy roadmap provides the framework for a shared prioritization mechanism for conflicting business and IT priorities. Consider the following illustration:

ERP Application Strategy Roadmap

ERP Application Strategy Roadmap

Practically speaking, there will always be two different  perspectives for ERP strategy and prioritization.  What is important is that your organization has an ongoing process to align business priorities and IT priorities for your business solution.  Having an ERP application strategy roadmap is a deliverable that will support the alignment process.  In the next section, we will address the activities for creating an ERP application strategy roadmap.

Creating an ERP Application Strategy Roadmap

The following illustration outlines the key activities to perform in creating an ERP application strategy roadmap.

ERP Application Strategy Process

ERP Application Strategy Process

For brevity sake, I would like to focus on two key activities that are typically overlooked during the development ERP application strategies:

  1. Step 2 – Inventory Current State Solution
  2. Step 3 – Define Gaps, Duplication, & Inefficiencies

Once your organization defines the business goals and strategies (Step 1), the next analysis is to determine what components are in place to support the business needs.

Mapping ERP Features to Business Objectives, Goals, and Strategies

Mapping ERP Features to Business Objectives, Goals, and Strategies

In the illustration above you see that the business objectives are supported by a series of business strategies that provides the first level of support for meeting the agreed upon objectives.  Business strategies are further elaborated into the individual business processe(s), people, and ERP capabilities that will support the implementation. Performing this experience is important in order to identify the required interdependencies between the components of a business solution.

Once the above analysis is performed, the next step is to conduct an ERP assessment.  The ERP assessment will provide you with the insight needed to understand how your organization utilizes your ERP system. This analysis will enable you identify opportunities to better align with business objectives and goals.   In additional to finding opportunities your organization should identify gaps and duplicate functionality that should be addressed.  Consider the following:

Highlighting ERP System Gaps and Duplicate Functionality

Identifying ERP System Gaps and Duplications

An important exercise that needs to be performed is to map business requirements to the existing ERP solution(s).  The above illustration is an example of mapping business objectives to the individual systems that would said objectives.  This exercise is very useful for identifying gaps and functionality overlap (Step 3).

The Price of Not Having an ERP Application Strategy Roadmap

Performing a current assessment (Step 2) and identifying opportunities and gaps within the current ERP environment (Step 3) is no small feat of effort.  Many times these activities are perceived as “looking back” and generate no real value of moving forward.  I humbly disagree and say that these activities are vital to enabling customers to move forward with a realistic and achievable strategy.  Without an ERP application strategy customers are “blindly following” the ERP vendor’s application strategy – which may not be in the best interest of a single individual customer.

ERP Return On Investment Analysis

ERP Return On Investment Analysis

It is important to realize that your ERP solution will have incremental costs (red arrows) throughout the ERP life-cycle.  Without an ERP application strategy in place, your organization is taking a gamble that business benefits from ERP will continue to outpace the corresponding operational costs.

Summary

Maximizing your ERP investment is a process – not a milestone.   Not only do you need to understand the ERP functionality implemented but also how that functionality supports business results.   To achieve long-lasting value from ERP you need to have a long-term strategy to incrementally generate additional value because you will generate additional incremental cost over the ERP life-cycle.

Follow

Get every new post delivered to your Inbox.

Join 4,404 other followers

%d bloggers like this: