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.
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.
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.
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.
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.
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.
Join the community! 10k followers across 100 countries!
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
Let’s focus on some specific areas that are typically overlooked or under appreciated.
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 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.
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.
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
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.
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!
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.
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:
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:
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.
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.
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:
Greater operational costs: There is an additional cost associated with customizations –typically required from the IT organization to support and manage the software changes.
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.
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.
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.
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!
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:
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:
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:
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.
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.
Join the community! 10k followers across 100 countries!
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
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
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.
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).
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.
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
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
For brevity sake, I would like to focus on two key activities that are typically overlooked during the development ERP application strategies:
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
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:
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
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.
Every customer I assisted in their ERP implementation wanted an ERP solution that would be flexible and adaptable. One of the key challenges and disappointments customers have with ERP are around flexibility and adaptability. We also need to address the common misinterpretations associated with the concepts of a flexible and adaptable ERP solution. Referring back to a previous blog we know that ERP is only one component of a business solution. There are three key areas to address as part of developing a flexible and adaptable business solution.
Know The Limitations
Technically speaking, there are two key methods to enable packaged software like ERP to be flexible and adaptable:
Programming (addresses flexibility or the ability to change)
Configuration (addresses adaptability or the ability to easily change)
Each of these methods has inherent advantages and challenges associated with them. Configuration has been a key area of focus for ERP vendors to create greater software adaptability. Configurations enable less technical, business-oriented users to determine how ERP behaves to specific events and conditions. Configuration provides the opportunity for cost-effective flexibility to meet the unique business requirements. However, where there is no option for configuration then programming must be used to enable ERP software the flexibility to meet the unique requirement.
Programming provides an exact prescription to address a specific business event, condition, or activity. There are programming techniques and add-on utilities that provide some level of technical flexibility (examples: object-oriented programming, services-oriented architecture) but business flexibility is extremely limited at best (unless an ERP vendor can devise a practical means of applying artificial intelligence – fuzzy logic to their software). There are limitations with the amount of flexibility and adaptability you can create via software. What is important to remember is that there are other components of a business solution that better suited to address flexibility and adaptability.
Know Your Strengths
Let’s revisit the components of a business solution along with their inherent strengths.
Business Solution Strengths
Too often we do not effectively utilize the strengths of the key components of a business solution. ERP software is good at automating consistent, repeatable activities based upon a prescribed logic (business rules). ERP software is not a sustainable, cost-effective option for dynamic activities based upon fuzzy logic (business rules). People are more flexible and adaptable than ERP software. Please do not take the above statement to an extreme and infer that every customer should conform their business activities to the ERP software. ERP implementations should include software enhancements to address the unique value-add requirements of a customer.
Flexibility and adaptability only have value within the context of enabling ERP to position itself optimally in supporting key business drivers. Next, we will discuss the common drivers that must be coordinated as part of addressing flexibility and adaptability.
Every customer will have unique business drivers that must be managed in a balanced approach. Given my implementation experience following are what I consider the common business drivers that we might address as part of an ERP implementation.
A balanced ERP solution
Can we have a flexible and adaptable ERP solution? I believe that the answer is yes. Can we have an efficient and effective ERP solution? Yes. Can we have a scalable and efficient solution? Yes, however we can only experience both characteristics to a certain level. The challenge I observed is when an extreme position is taken in one of these areas. Like a ball on a flat table once we start tilting the table (taking an extreme position) the ball will roll off the table – – along with your ERP implementation.
Finding balance is an ongoing exercise to find the right level of applying the influence of the specific business driver upon the ERP project. It is also important to know and understand at what level of influence will business drivers start conflicting with one another.
Flexibility and adaptability are reasonable expectations for a business solution. The key challenges in this area tend to be around inaccurate expectations and not effectively utilizing the individual components of a business solution. What is required is a practical analysis of the strengths, weaknesses, and business drivers to develop a balanced approach for success. This analysis is not a one-time event but a continuous effort that is triggered when emerging pain is experienced. Experiencing pain provides the opportunity for rebalancing your ERP solution.
Many have come to know that ERP projects never really end. An ERP implementation is only the beginning of a journey with many twists, turns and – unfortunately – missed opportunities. The majority of business value ERP can generate happens during the maintenance life-cycle. Many customers never realize the full potential of ERP due to the maintenance strategy employed. What can we do to stay the course and ensure that customers can realize the value articulated in the ERP sales cycle?
We must address the above points throughout the entire ERP life-cycle. Too often I have observed customers applying their existing IT governance policies predicated on developing custom software for ERP packaged software. This overlooked problem can lead to significant ERP pains and limitations. Periodically conducting an ERP assessment can help the customer stay on track to maximizing their ERP investment.
Performing an ERP Assessment
An ERP assessment is a set of activities to determine how the organization is utilizing their ERP solution and identify opportunities for generating additional value from the investment. It is also a chance for the customer’s IT organization to develop an ERP roadmap to align with business objectives. Following is a brief overview of how to perform an ERP assessment.
Step #1 – Conduct a ERP software assessment
Knowing how the business is using their ERP software provides insight into possible opportunities and risks that should be part of an overall ERP roadmap. The ERP software checklist should identify all Out-Of-The-Box (OOTB) functionality that is available for use. I recommend that we complete the checklist by completing the following interviews:
Conduct interview(s) with key IT resources for business. This will give us the opportunity to pre-populate the checklist before meeting with the key business users.
Conduct interview(s) with key business users (owners). Highlight differences between IT and the Business so we can realign the understanding.
I also suggest that you highlight opportunities and concerns like the following:
What are the Functionality/Business activities performed outside the ERP software?
Identify functionality that may be a future requirement.
Identify functionality that the Business does not know exists in the ERP software.
Following is an example of an ERP software checklist for a specific module (Asset Management).
Understanding business maturity provides insight into what ERP OOTB functionality that business should be utilizing. However, do not get caught up in the trap that technology alone matures a business model. The business process assessment should identify all business activities. We also need to define a scale or rating to determine the maturity level. I typically utilize the Capability Maturity Model Integrated (CMMI) to define the level of maturity.
I recommend that we should complete the assessment by completing the following interviews:
Conduct interview(s) with key IT resources (pre-populate) for business.
Conduct interview(s) with key business users (owners). Highlight differences between IT and the Business so we can realign the understanding.
I also suggest that you highlight opportunities and concerns like the following:
Business maturity capability gaps greater than 1.0 level.
Following is an example of a business maturity assessment.
Now, we need to focus on the most important part of a business solution – people. The last step looks at identifying resource capacity supporting your ERP investment.
Step #3 – Conduct a People assessment
If your organization does not have the resources or knowledge to effectively leverage your ERP investment. The skills checklist should identify all relevant software and process knowledge required to support the business. We should also identify the required knowledge/skill level required across the business solution. Complete the assessment by completing the following interviews:
Conduct interview(s) with dedicated Business and IT resources.
Review results with appropriate Business and IT management. Highlight differences between resource and manager evaluations.
Following is an example of an ERP skills assessment template.
Another strategic area to investigate is demand management. Reviewing the wants and needs communicated by the business will provide you insight regarding their expectations of ERP software.
Step #4 – Conduct a Helpdesk request assessment
Managing user expectations are constantly challenging. Technology may not be the answer for every business requirement. In addition, we need to be practical and understand that users naturally would like to address both their needs and wants for ERP. Regardless of the tool you use for ERP helpdesk management you need to categorize and analyze ticket volume and underlying drivers. Consider the following analysis:
From this summary we can see that the IT organization spent time an inordinate amount of effort due to no formal training being performed. Regardless of the ERP software capabilities, if users do not have sufficient ERP knowledge then business value is not generated. If the ERP software is of poor quality then we will see a significant increase in issues. IT support analysis for ERP software is a key indicator of how well the business is experiencing value from their ERP investment.
What is the purpose of doing an ERP assessment? At the end of the day the purpose of conducting an ERP health check assessment is to understand how to generate additional Return On Investment (ROI) from ERP. It is the first step in generating a holistic ERP application strategy.
Conducting an ERP health check can provide us the insight and knowledge we need to made informed decisions regarding governance, opportunities, risks, and investments.
Join the community! 10k followers across 100 countries!