19
Nov/09
0

No Decision – May You Forever R.I.P. (Part 4)

This is the last installment in a series that has been discussing a problem plaguing many businesses today, and that is the situation of ERP or IT projects being aborted midstream before they accomplish their stated objectives.  In the last issue, we discussed the means by which the project’s financial impacts would be assessed and projected.  In this issue, we will summarize those projections with some commonly accepted evaluation formulas accompanied by the closing arguments for the project.

5.  Get Out Your Calculator.  We have explored the need for completing a thorough justification process and the strategic business imperatives that are driving the initiative.   We have also discussed some of the potential benefits and costs to examine when conducting your justification.  What remains is to simply tally up the projected value of your benefits and costs in a worksheet.  You should then be able to determine the Net Dollar Value of Benefits with the following formula.  With today’s extremely cash conscious business environment, I would focus more on the shorter term horizon measurements.   In other words, focus on items that will have an immediate positive impact on the cash position.

                Net Dollar Value of Benefits = Total Value of Benefits – Costs of Implementation

As the business climate and available credit improves, a longer term horizon measurement such as a simple Return on Investment may be appropriate.

                ROI = (Net Dollar Value of Benefits/Costs of Implementation) x100

Different organizations use different perspectives to evaluate potential investments so I can’t tell you whether ROI is an accepted metric in your organization or not.  However here are a few other measures you may find used to evaluate an investment. 

A)  Internal Rate of Return (IRR).  This can be useful in comparing one investment opportunity in an organization vs. another.  For example comparing an ERP system investment vs. a new factory investment.

B)  Payback period.  A simple determination as to how many months it will require to earn your investment back,

C)  Net Present Value (NPV), this involves a bit of black magic so you may want to leave this to the finance folks

D)  Total Cost of Ownership (TCO), simply looks at costs while ignoring value and benefits

6.  Wrap it Up.   You have now completed a thorough analysis of the strategic elements that are driving the organization to consider this investment.  In addition, you have outlined the chain of events, symptoms and potential problems that are occurring in your existing environment.  You have evaluated the various categories of value and benefits to be derived by the organization, along with supporting details.  On the flip side, you have calculated all the projected costs over a fixed period of time.  Assuming the numbers pencil, you have all the numbers to show that this project has been carefully analyzed for a positive business impact. 

What remains now is to present your business impact analysis to the appropriate decision makes and stakeholders.   When done properly, this process will not only justify the organization’s decision to move forward, but much more importantly provide a solid footing for the project to launch and sustain critical momentum when you get lost in the woods or the occasional storm surfaces on the horizon.

6
Nov/09
0

No Decision – May You Forever R.I.P. (Part 2)

In the last issue, we discussed an extremely costly syndrome that plagues many businesses, namely that of projects that get launched with great intentions and then quietly run out of steam without producing tangible results or meeting stated objectives.   I see this frequently with regard to ERP or IT projects.

Fortunately, there is plenty that can be done to avoid this wasted effort.  However it requires a significant undertaking, careful analysis, clarity and organizational resolve to see it through.  It requires lots of short and long term assumptions, as well as countless questions to be answered.  When completed and properly documented, it results in a comprehensive business case for the project.   This document is a critical tool used to justify the long term investment of organizational assets (people, time, money) to select and successfully implement an ERP system.  It also serves as the foundational rock to guide and encourage the organization to continue pressing forward through the murky process.

Several suggested steps for a successful ERP software selection process are outlined below.  Notice I said successful ERP software selection as opposed to successful ERP software review.  After all we are focusing on ways to complete the project rather than getting halfway through and aborting it.

1.  Determine to Justify.  The first thing you’re probably asking yourself is whether the formal business case justification exercise is really necessary.  After all, isn’t it common knowledge throughout the organization that the existing system is dysfunctional?  If so, then why waste time documenting what is already known?  Can’t we just get on with it and begin the shopping process?  Sure you can, but in all likelihood you will end up regretting it.  The reason is that you do not have a clear business imperative to proceed.  What I mean by that is that you must understand the short and long term business reasons for embarking on the project.  This will likely include the strategic objectives and vision of the company ownership and stakeholders.  You should also consider the organization’s track record on difficult projects, and what other competing short and long term priorities might exist.  In addition, you will need to identify the goals and benefits to be achieved, the measures to be used, and the problems to be overcome.

Conversely, if you are simply focused on certain functions that need improvement, you are looking at this more as a computer or IT project, as opposed to a critical business project.  If it’s cast primarily as an IT project, your bullets will not be nearly potent enough to slay the dragons that lie on the ERP system path.  Those dragons frequently come in the form of undesirable trade –offs, higher than anticipated costs, ambiguity and unclear outcomes. 

Having a well organized and clearly documented business case will provide strong support from management and employees when the going gets tough.  Without it you are merely relying on hope and faith to carry the day.  Based on my experience, I can tell you that faith can go out the window when the challenges start mounting.   The difficulty and risk involved in an ERP project is significant, and therefore in order to assume that risk, there must be clear and compelling reason to do so, and more importantly organizational resolve from top to bottom to succeed. 

2.  Quantify the Need for Change.  Now that you have determined the value of a thorough business case justification project, the question is how to do it.  At its most fundamental level, you are attempting to quantify the value of the benefits to be gained, versus the cost to attain those benefits.  You are examining these benefits and costs  over the perceived life of the ERP system, bearing in mind the timing of when specific costs and benefits are likely to occur.

It is admittedly difficult to determine concrete value from a new ERP system implementation.  But far better to do it now, rather than after the money is spent.  Credibility must be a critical overarching objective in the finished document.  This requires soliciting feedback from several key people and departments, while frequently erring on the conservative side in your estimates.  

Most organizations can readily identify functions in their existing ERP system that are not working well.  However, a deeper inspection will frequently reveal several events occurring in the organization that may be symptoms of a bigger problem.  For example, you may discover a chain of events similar to that illustrated below.

     profits are down

         → sales are down

               → orders are not being fulfilled

                    → excessive stock outs

                         → excessive inventory obsolescence

                              → poor demand and supply chain visibility

                                   → wrong inventory items being replenished ↑

You can see from this example that even though there are a variety of problem events taking place, the likely root cause is that the organization has poor insight relative to their demand and supply.  So they are essentially operating blind in the replenishment area and ordering too much of what they don’t need and too little of what they do.  If they could address that single issue, a number of other issues would disappear or become less of a problem. 

Make a list of all your events and then determine which seemingly unrelated events are in fact actions or reactions to another event in your list.  Being able to address and manage the root cause event more effectively with a new ERP system should yield a cascade of financial value. 

In the next issue we will look at ways to quantify the tangible and intangible financial values and benefits of your project as well as the myriad of costs that will need to be borne.

8
Oct/09
4

What Is This Thing Called ERP Anyway?

I suspect that most, if not all of you, have heard the term ERP system.  And some of you may even know that the acronym stands for Enterprise Resources Planning.   That’s a mouthful that on the surface doesn’t seem to mean much.  But since an entire industry has been developed around ERP systems, and since just about every legitimate business has one these days, there must be something to it.   Let’s take a look and see if we can unravel the mystery.

Tracing ERP’s Ancestors
To understand where ERP got its birth roots, we need to go back to the 1960’s.  That is when an approach called MRP (Material Requirements Planning) was born to handle specific processes for certain types of businesses.  You will note that both ERP and MRP had the concept of planning in common.  But aside from that, one seemed to focus on material requirements, while the other focused on enterprise resources.

Simply stated, the purpose of an MRP system was to assist manufacturers plan and manage inventory (material requirements) so as to meet demand for end finished goods.  In order to do this, it was necessary to know current inventory levels of component parts and raw materials, replenishment schedules, and the total demand being placed on all these items.

While MRP was somewhat effective in meeting its stated objectives, it was also quite limited in reach.  In fact, it was a closed loop that dealt with a very finite set of factors.  When you consider that a typical manufacturing organization has many functional needs and departments apart from the manufacturing process itself, such as A/P, A/R, G/L, customer service, order entry, forecasting, purchasing etc., there were lots of planning and processing needs not being met by MRP.  Consequently, the late 1970’s and early 1980’s saw the birth of Manufacturing Resource Planning (MRP II).

You can see with the transition to MRP II, we were no longer focusing on simply material requirements planning, but now had broadened the focus to include all of the manufacturing resources planning utilized in a manufacturing organization.  MRP II systems did a reasonably good job of performing the necessary functions associated with buying materials, producing goods, selling the goods, and following the movement of money associated with all of those transactions. 

ERP is Born
As time passed in the latter 1980’s and early 1990’s, it was discovered that MRP II was all fine and well if you were a manufacturer.  But what if like the majority of businesses in North America today, you were not a manufacturer?  In that case another approach was required, and thus ERP (Enterprise Resources Planning) was born.  The ERP system set out to expand beyond just manufacturers and encompass the needs of all enterprises regardless of their industry, and the resources required to plan and operate those enterprises.

As ERP systems have evolved over the last couple decades, these systems have embraced and added functional areas such as those shown below.
 

Financial Planning Quality Management
Product Engineering Human Resources
R & D Manufacturing Execution Systems
Customer Relationship Management (CRM) Field Service
Supply Chain Management Logistics and Distribution
Marketing Advanced Planning and Scheduling
Sales and Operations Planning Lean and Full JIT Support

 

As you can see from the table above, lots of potential complexity has been heaped upon the ERP system stack.  In a highly functional ERP system deployment, the ERP system represents a set of sophisticated tools whose reach is deep and wide, yet tightly integrated across all departments and functions so that there is a single set of high integrity cohesive data available for all users.

The People
Unfortunately, all too often, ERP systems are viewed purely in the context of software functionality.   But the real measure of success in terms of an ERP system is the user’s usage experience with the ERP system.  Given that, the notion of people is the other very critical element required in the ERP system discussion.   To what degree does an ERP system recognize and embrace the importance of people and their roles in an organization?  To what degree does it adapt or facilitate varying roles?  To what degree does the ERP system empower the people with the right information at the right time in the right place to make and support informed decisions affecting the organizations tactical and strategic needs?  It’s only when we have successfully incorporated the all important people component of the equation with the software functionality, that a successful process is identified.  The combination of many successful processes constitutes a real ERP system

ERP Maturity Model
We have just covered the last forty years of ERP product evolution at hyper speed, and even though we have barely skimmed the surface, it is probably plenty deep enough for this discussion.  There is one other important concept however that should be considered in an ERP system discussion and that is what is referred to in some circles as the ERP Maturity Model.  The ERP Maturity Model is a means of identifying the various levels of sophistication of an ERP system along with the level of value that it brings to an organization.  While the number of levels can vary from one model to the next, the typical scenario goes something like this. 
 

Level Sophistication and Value
1.  Data Management System Data is collected and organized, but may not be valuable enough to be classified as information.  There may be many sets of data at play at any given time.
2.  Shared Database & Multiple Software Modules Data is shared from a single source across multiple functions and/or departments.  While all users have access to the same data, they may not have control over the data, and therefore may not place significant value on it.
3.  Operational Perspective There are common rules and procedures used for planning, executing, controlling and reporting actions in the system.  Two-way feedback loops exist between the execution elements and the planning elements of the organization.  Tactical and operational components are in harmony.
4.  Business System Incorporates all of the elements of the previous level, and in addition includes exceptions for all to see, as well as more strategic planning elements.  The organization relies on the system information to guide and direct it toward its goals.
5.  Continuous Learning & Knowledge Management The ERP system contains a significant historical knowledge base of information, trends and requests.  The organization embraces the knowledgebase as a catalyst for continuous learning and improvement.  Executive level decisions and daily employee level decisions are made and supported based upon the information in the system.

 
The purpose of the model is to determine where your organization is on the scale.  You may want to ask yourself one or more of the following questions.

  • Are you where you thought you were?
  • More importantly, are you where you want to be?
  • Is there value to be derived for your organization by going to the next level?
  • Could major problems be solved or strategic goals achieved by getting to the next level?

Perhaps you liked what you saw after looking in the mirror, and then again maybe you didn’t.  If not, then you should know that there are plenty of options avaiable for addressing the concerns.  The real question is what action are you going to take to make it happen?  As they say, a journey begins with the first step.