On Seeking Success

In a recent informal poll I conducted, I asked "Which ERP success is most important to your organization in the long run?" I offered the following options:

1. An ERP project that is on-time and within budget
2. An ERP project that increased throughput (i.e., revenues less truly variable costs)
3. An ERP project that reduces inventories or the need for other investments
4. An ERP project that reduces operating expenses

I was somewhat dismayed when the results were that fully two-thirds of respondents count success in ERP as a project that reduces operating expenses. The only worse answer, in my opinion, would have been "An ERP project that is on-time and within budget."

Here's why I believe that is true.

First, consider that I can dramatically reduce the operating expenses of any business enterprise virtually over night -- saving the organization, perhaps, millions of dollars every year -- and I can guaranty those results. All I have to do close the business. That automatically reduces operating expenses to zero.

If an organization is seeking "success," and they are making progress in that direction. It would seem to me that they would want more and more of whatever it is that they are calling "success." That would just make common sense, would it not?

But executives and managers that pin their "success" hopes on "reducing operating expenses" want only "partial success." Few of them are really endeavoring to reduce operating expenses to the "ultimate prize" of zero dollars.

What is worse is that they constantly face the law of diminishing returns. If they reduced operating expenses last year by five percent, the chances that they can reduce costs this year by another five percent are pretty slim, and even if they do, this year's five percent will still be a smaller actual dollar amount than last year's five percent. And next year will require even more effort for less dollar-savings.

However, for people caught in cost-world thinking, this does not seem foolish. They see no contradiction or futility in these efforts (sadly), ususually because that is all they know or have been taught to think.

On the other end of the spectrum are those one-in-three executives and managers who have discovered that real and enduring success comes from the "throughput" side of the business. If you can increase T (Throughput, which is Revenues less Truly Variable Expenses) this year by five percent -- all else being equal -- then you have made gains. In fact, if operating expenses have not increased, then that five percent increase in T falls directly to the bottom line just like a five percent reduction in operating expenses does.

What is even more exciting is the fact that there is no law of diminishing returns at this end of the enterprise. If you are able to increase T by five percent next year, that five percent will bring more dollars of profit to the bottom line than last year's five percent increase did. And next year's five percent will make an even larger contribution to stakeholders in the business.

Success on this end of the business -- if repeated year after year -- leads to real success, not "closing the business" (as "ultimate success" in reducing operating expenses does).

So, why are not more managers and executives seeking ERP success differently?

Are IT Vendors Driven by the Business Results of Their Customers?

Writing for CIO UK, David Henderson suggests several reasons “Why IT vendors must raise their game”. The second major point he mentions is that “IT vendors tend to be driven by their portfolios rather than business outcomes” for their customers. Henderson points out that IT vendors “continue to make significant investments in their portfolios but aren’t prepared to make the same investment in understanding how these apply to their customers’ businesses,” which can “lead to huge inefficiencies” once implemented at the customers’ sites.

As a result, Henderson continues, “vendors… tend to give poorly defined generic presentations that bear only passing relevance” to the challenges faced by the customer or prospect at hand. Henderson goes on to berate the ERP vendors for “me, too” solutions and their inability to “connect the dots” between their product offering real value for the firm that buys the technology.
I agree that IT vendors need to change. The economic picture is vastly different in 2010 than it was even three years ago.

Where I disagree with Henderson’s writing, however, is who should know what.

Starting off on the wrong foot

Computer-based technologies really were not available to any significant number of SMBs (small-to-mid-sized businesses) until after the introduction of the personal computer (PC) in 1981. Prior to that, computing power available from mainframe and mini-computers was available only to larger firms with significant capital for investment in such technologies.

So, in the early days of the computerization of the SMB market, almost every new prospect was anticipating moving off a system dominated entirely by paper and the necessary manpower to keep the paper flowing. As the price of PC-based technologies fell, more and more companies made the switch. This movement dramatically increased productivity and return on investment (ROI) for such a move was almost a certainty. As a result, many ERP salespeople came in the door talking about increasing productivity and providing rapid ROI for almost every SMB they approached. And, almost without exception, the implementation of that first round of technologies provided consistently rapid payback for the firms.

Unfortunately, as the market changed (i.e., SMBs’ next round of technology purchases were not taking them off paper-based systems but, more frequently, moving them into a comprehensive suite of application modules or moving some SMBs off the high cost of maintenance associated with mainframe and mini-computer systems), the sales approach of most technology vendors did not change. The technology vendors’ salespeople continued to make the same claims about productivity improvements associated with the first round of ERP implementations and the executives and managers at the customers’ sites continued to drink up the claims like Kool-Aid. In many cases, the SMB management was spurred on by the impending arrival of the year 2000 and the Y2K epidemic of fear. Many executives felt they needed to spend the money to upgrade their systems and took little thought as to the ROI of such an expenditure.

Nobody grew up and nothing changed

By the early 2000’s the ERP market had changed yet again. By 2005 or so, almost every CEO or CFO of every SMB had been through at least one – and usually two or three – implementations of new software (or other technologies) in their business environment. Add to that experience the fact that they now had easy access to the Internet by which to explore and make inquiry regarding almost any ERP software on the market, and the ERP-buyer had changed dramatically over a bit more than two decades.

When ERP was starting to be sold (20-plus years earlier), when the technology salesperson first met a prospect, the prospect was hungry for information about products and capabilities. Furthermore, these green-horn technology buyers were more than willing to make the salespeople their de facto “instructors” in the purchase and application of new technologies in their businesses.

In addition, as previously stated, ROI was pretty easy to achieve. Almost any SMB moving off labor-intensive paper-based processes or coming from costly mainframe or mini-computer technologies was bound to reap savings in operating expenses, and was almost equally likely to achieve increases in Throughput. However, by the middle of the first decade of the 21st century, all the easy ROI from traditional ERP – Everything Replacement Projects – was gone and not likely to return. Sadly, much of the technology salespersons’ product positioning remained unchanged and the sales rhetoric and promises from a good many ERP vendors still harkened back to days gone by – without, of course, actually mentioning that fact.

This unwillingness to face the change in the marketplace was not entirely one-sided. As the traditional ERP sales hype continued to make sweeping “rule-of-thumb” claims about delivering ROI for the ERP-buying executives and managers, these executives and managers proved themselves equally willing to accept the claims without taking the time and effort to discover for themselves what they really needed to know about their particular organization and its potential for reaping ROI from any particular foray into new or upgraded technologies.

What every executive and manager needs to know

As Eliyahu Goldratt has put it so well, there are three – and only three – things that every executive and manager needs to know to make effective decisions in every situation. These are they:

1. What needs to change
2. What the change should look like
3. How to effect the change

If, before making the leap to buy technologies based on “rules of thumb” and sales-speak, executives would just take the time to figure out the answers to these three questions, there would be far fewer stories about traditional ERP implementations failing to deliver expected business results.

IT vendors are not necessarily driven by business results for every client. And, as executives and managers, you should be aware that rules-of-thumb may not apply to you and your enterprise – and the ERP vendor or VAR is not responsible for your business’s not fitting the rule-of-thumb by which other enterprises may have achieved return on investment.

As executives and managers in your organization with your particular circumstances and requirements, you – not the technology vendor or reseller – need to know what needs to change in order for your firm to start making more money tomorrow than you are making today. You – not your vendor or reseller – need to know what the change should look like in your particular organization. (The vendor or VAR may help you understand how new technologies may be part of what that change should look like, but you need to understand the precise need in order to effect your desired ROI. (Read more in many articles found right here at GeeWhiz To R.O.I.)

And lastly, as executives and managers it is your responsibility to understand how to effect the change within your enterprise. (Here again, the technology vendor or reseller may help you understand the technology-related components of the change, but you and your team need to take full responsibility for creating a roadmap for change.)

Need help?

Contact me at rcushing(at)GeeWhiz2ROI(dot)com and I can show you a way to unlock your firm’s “tribal knowledge” to discover what needs to change so you can start making more money tomorrow than you are making today, and you won’t spend money needlessly on technologies that don’t bring almost immediate ROI.

©2010 Richard D. Cushing

Change comes through people - Part 1

Today I attended a Webinar on applying “Emotional Intelligence” or “EI” in the implementation of ERP systems. The name of the organizer and presenters shall go undisclosed because it is not they who are the target of my disagreement. Rather, my disagreement is with the thrust of the application of EI.

Definitions

In the presentation, the following definitions were given:

·         ERP Change Management (CM) – refers to identifying, assessing and managing the elements that are needed to move an organization from its current state to a future state when ERP software is the transaction engine.  The goal is to realize ROI of the project.  The areas addressed include change strategy, leadership, envisioning, project team building, change history and readiness, benefits realization, stakeholder management, communications, approach to handling reluctance and sustaining commitment, Knowledge transfer, organization and business impacts, new skills and ways of working, organization restructuring, roles and responsibilities, alignment with HR processes and the enterprise strategy. [sic]

·         Emotional Intelligence (EI) – refers to the ability to recognize and understand emotions and the skill to apply this awareness to manage ourselves and others through transitions.  Emotional Intelligence is made up of 4 unique skills that cover how one recognizes and understands emotions, manages his or her behavior, and manages relationships.  These skills are self-awareness, self-management, social awareness, and relationship management. [sic]

Key points

Some pertinent points were brought in the course of the presentation, not the least of which were these:

·         Only 30% of “change initiatives” succeed, while 70% of “change initiatives” fail

·         “It takes about five years to see ROI from a [typical] ERP implementation”

·         “Change can foster significant confusion for middle managers, which can spur anxiety and stress that impede or even paralyze decision-making”

·         “Middle managers need to implement change while managing their employees’ emotions, including anxiety, resistance and eager but inappropriate behavior”

·         “These managers face the challenge of grasping a change they did not design and negotiating the details with others, equally removed from the strategic decision-making”

·         “Complexity rises for these managers of change as work demands are modified and multiply, which can create conflicts”

·         “Lack of clarity renders new demands uncertain and frequently misunderstood; without clear understanding, managers can be seen as not taking action or taking the wrong action”

These points all raised many, many questions in my mind, and I hope to speak of them in this article. However, here was the real kicker that came in response to a question at the end of the presentation:

"A lot of ERP decisions are made on the basis of executive ego.... [Therefore], there are a lot of cases where the ERP [software selected] is a mismatch [for the firm]."

Mind you: these statements – and, most notably, this final statement – is coming from two professionals serving companies of all sizes in industries including finance, health care, education, and manufacturing. And the presenter’s statement did not stop there. Examples were given in terms of “being the first in an industry,” or “having the biggest Peoplesoft implementation ever,” and more.

Notice also that the presenter did not say, “Sometimes” or “occasionally”; rather, the statement made was that “[a] lot of ERP decisions are made on the basis of executive ego.” And, frankly, my own experience confirms this – if not the original purchase decision, at least the decision to carry on with a project even when the evidence may be almost overwhelming against the net result being a positive one for the firm undertaking a traditional ERP – Everything Replacement Project.

It’s got to work

At an international trade show I attended some years ago, I became involved in a conversation with an executive from a fairly large firm. I asked him if they were considering a new ERP system, at all. His response was, “Oh, no! We are just wrapping up an SAP implementation now – after a little over two years.”

So, I said, “Well, you’re to be congratulated, then. There just aren’t a lot of companies that ever actually ‘wrap up’ a SAP project. It seems that they so frequently become ‘evergreen’ projects for SAP developers and DBAs.”

To this, he chuckled. Then, with renewed earnestness he said, “Well, there are still a few things that aren’t quite right, but we’ve spent so much money already that it’s got to work!”

This is telling, don’t you think? If ego did not initiate this ERP implementation, ego was certainly going to see it through. No executives in that company were going to admit that – after spending some millions of dollars – the ERP solution they selected was not going to work for them!

Dispelling an old myth

Who do you think started the myth that “people hate change” and “people resist change”? Do you think it was started by the people being accused of “resisting” and “hating,” or do you think it was started by those in power – monarchs, politicians, generals and executives – who wanted certain changes to occur, but were having some difficulty in getting “the people” to accept the changes set forth?

I think you will agree with me that it was, most likely, the latter group and not the former that leveled the charge and created the myth.

The following should dispel that myth once and for all – at least for my readers:

The Change	Scope of Change	Comments
Getting married	Monumental	Most people embrace and look forward to this change. They do not resist it. In fact, they dream about it and even plan for it.
Having children	Monumental	Here again, even though this is a huge change in their lives, most people look forward to having children and many even lay out plans in advance for childbearing.
Announcement that one’s salary will be doubled starting next month	Big	This change will likely bring significant lifestyle changes, yet I doubt that many would be found resisting this change.
Announcement that one’s salary will be cut in half beginning next month	Big	The magnitude of this change is equivalent to the magnitude of the change for doubling of one’s salary, yet this change is likely to bring screaming resistance.

The point is, people do not resist change. What people resist are changes about which they are not yet convinced the result for them will be positive. For example, in getting married – even though most candidates for marriage recognize that there may be some down-side to the marriage compact – they are convinced that the change will be a net positive for them in the long run.

With this in mind, in our subsequent posts in this series, we are going to revisit the Key Points raised in the Webinar on “Emotional Intelligence.”

Stay tuned.

©2010 Richard D. Cushing

Contact me!

The New ERP – Part 41

We are wrapping up our discussion of Sue Bergamo's article entitled "Is Your Implementation in Trouble?" Bergamo listed seven "high level categories [in troubled ERP implementations]…. in the order from the highest to lowest number of responses" from her informal LinkedIn survey. Here is her list:

1. A misconception of business expectations
   
2. The lack of top level leadership involvement in the project
   
3. Business processes were not correctly redefined and continued to be inefficient
   
4. The impact of the organizational change was not addressed properly and caused a major upheaval in the company
   
5. The vendor wasn't managed correctly and over-promised, then under delivered [sic]
   
6. Project management was weak and over-customizations lead to increased scope and time
   
7. The integration of diverse applications was harder than anyone expected
   (Bergamo 2010)
   

In the process of our review we are drilling-down on Bergamo's symptoms list and setting them in the context of the New ERP – Extended Readiness for Profit while contrasting them with traditional ERP – Everything Replacement Projects to see if using the New ERP approach would have mitigated the failures.

6. Project management was weak and over-customizations lead to increased scope and time

This is another no-brainer when it comes to traditional ERP – Everything Replacement Projects versus the New ERP – Extended Readiness for Profit. One simple reason is this: the amount of "real estate" to customize.

Think about it. If your organization is going through an Everything Replacement Project there are dozens – if not hundreds – of places in the new technology that could become a target for customizations. However, in a New ERP – Extended Readiness for Profit project, the effort is so targeted and so narrow in scope that there is just not much opportunity for "scope creep."

But, there is another reason as well.

If you will take time to go back (to prior portions in this series), you will discover that the vendor selection and "proof of concept" portions leading up to an implementation under the New ERP approach are likely to expose an requirements for customization early in the process. In fact, such customization or modification necessities will probably be revealed before the purchase agreement is consummated. This is as it should be.

7. The integration of diverse applications was harder than anyone expected

Even though this is where the New ERP – Extended Readiness for Profit should be most vulnerable, this issue is where the New ERP really shines unlike every other approach.

Why?

This is simply because the New ERP approach takes as its number one priority the matter of EAI (enterprise application integration). EAI is fundamental to the New ERP.

Since, under the New ERP scenario, your organization will not be tearing out the central technology engine (core accounting and related modules) and trying to re-integrate several – or even dozens – of necessary applications across the enterprise, the challenge becomes much less complex. The effort you undertake will be concentrated. Your resources will not be diluted. And the work can be planned and accomplished expeditiously.

Furthermore, looking again to the solution and vendor selection process (see earlier posts in this series), the question of integration of the targeted solutions being brought to bear through the New ERP approach – its ease or difficulty – should be and would be addressed prior to making a final decision on the solution(s) and vendor(s) to be employed.

In summary

In this series we have compared and contrasted traditional ERP – Everything Replacement Projects with the New ERP – Extended Readiness for Profit in addressing seven factors that have lead many organizations to failure or dissatisfaction with their ERP system and implementation as reported by Sue Bergamo in her article "CIO Update: Is Your ERP Implementation in Trouble?"

It should be clear to you and your management team now the many advantaged afforded you by applying the New ERP methods. This is a great way to avoid troubled ERP implementations.

©2010 Richard D. Cushing

Works Cited

Bergamo, Sue. CIO Update: Is Your ERP Implementation in Trouble? Feb 01, 2010. http://www.cioupdate.com/features/article.php/3862056/Is-Your-ERP-Implementation-in-Trouble.htm (accessed Feb 02, 2010).


 

The New ERP – Part 40

We are continuing our discussion of Sue Bergamo's article entitled "Is Your Implementation in Trouble?" Bergamo listed seven "high level categories [in troubled ERP implementations]…. in the order from the highest to lowest number of responses" from her informal LinkedIn survey. Here is her list:

1. A misconception of business expectations
   
2. The lack of top level leadership involvement in the project
   
3. Business processes were not correctly redefined and continued to be inefficient
   
4. The impact of the organizational change was not addressed properly and caused a major upheaval in the company
   
5. The vendor wasn't managed correctly and over-promised, then under delivered [sic]
   
6. Project management was weak and over-customizations lead to increased scope and time
   
7. The integration of diverse applications was harder than anyone expected
   (Bergamo 2010)
   

In the process of our reveiw we are drilling-down on Bergamo's symptoms list and setting them in the context of the New ERP – Extended Readiness for Profit while contrasting them with traditional ERP – Everything Replacement Projects to see if using the New ERP approach would have mitigated the failures.

5. The vendor wasn't managed correctly and over-promised, then under delivered

This exposes another important advantage of the New ERP – Extended Readiness for Profit over traditional ERP – Everything Replacement Projects: namely, that the New ERP takes several specific steps to minimize such an occurrence –

Traditional ERP – Everything Replacement Project	The New ERP – Extended Readiness for Profit
Since the vendor in a traditional ERP project is going to touch so many facets and functions in the enterprise, this fact allows the vendor great latitude to make promises about the benefits and gains to be made without ever declaring the specifics about those gains. The benefits to the organization are frequently stated so broadly as to remain essentially without a corresponding metric for evaluation.	The New ERP, in contrast, requires that the executive and management team of the organization determine in advance the three critical matters we have already mentioned several times: What needs to change – That is, to identify what very specific functions in the enterprise are keeping the firm from achieving its goal of making more money tomorrow than it is making today. What the change should look like – The management team must determine in advance what the changes in the specific functions (identified in item 1 above) should look like in order to assure that, after the change is made, the enterprise will, in fact – or with a very high probability – make more money tomorrow than it is making today. This should be measurable in some manner. We have previously used the example (see earlier portions in this series) of an increase in the number of orders that could be picked, packed and shipped with the same number of personnel working in the warehouse. How to effect the change – This is the one area in which the technology vendor may play a part. They may offer suggestions about which technologies to apply and how these technologies should deployed to achieve the greatest effect. Note that if this approach is taken, the management team of the buying organization is setting the specific performance standards expected. This leaves little room for the vendor to exercise his "bragging rights" and thus "over-promise." The vendor either can meet (or exceed) the stated standard or performance, or it cannot. It is as simple as that.
In most cases where traditional ERP is undertaken, there is no up-front establishment of performance standards with the vendor. And, of course, in the absence of a specific and measurable standard, how can one effectively "manage" the vendor. By what measure are you managing them? If the traditional "project success" standards are applied (i.e., on-time, within the budget, and of acceptable quality) then, I suppose, you can count your project a success. However, if that "success" does not result in your company's ability to make more money tomorrow than it is making today – if there is no measurable R.O.I. (return on investment), then that is a hollow victory indeed.	Since the New ERP begins with the executive management team establishing and articulating clearly to the vendors the measurable results expected from them, then "good management" of the vendors means achieving those results that have been predetermined to deliver increased Throughput, reduced Inventories or demands for new investment, and/or lower Operating Expenses while sustaining significant growth. Such an approach greatly reduces the likelihood that a vendor will be incorrectly managed.
Most traditional ERP projects include "demonstrations" of the software. In many cases, such demonstrations are even carefully scripted. However, if you look at the section of this series that references product demonstrations, you will see that product demonstrations rarely constitute proof of concept tightly focused around metrics correlated to critical functionality.	On the other hand, the New ERP required participating vendors provide, not only proof of concept, but also a budget to achieve that proof of concept in the production environment. Furthermore, that budget is compared by your executive management team with the estimated benefits (changes in Throughput and Operating Expenses) to help assure that the projects planned ROI is likely to be attained as a result.

 
This side-by-side comparison of traditional ERP with the New ERP should make it abundantly clear that the "incorrectly managed vendor" failing is far less likely to occur when organizations adopt the New ERP as their method for evaluating both improvement projects and the vendors they hire to supply and implement technologies for them.

[To be continued]

©2010 Richard D. Cushing

Works Cited

Bergamo, Sue. CIO Update: Is Your ERP Implementation in Trouble? Feb 01, 2010. http://www.cioupdate.com/features/article.php/3862056/Is-Your-ERP-Implementation-in-Trouble.htm (accessed Feb 02, 2010).


 

The New ERP – Extended Readiness for Profit – Part 39

We are continuing our discussion of Sue Bergamo's article entitled "Is Your Implementation in Trouble?" She listed seven "high level categories [in troubled ERP implementations]…. in the order from the highest to lowest number of responses" from her informal LinkedIn survey. Here is the list:

1. A misconception of business expectations
   
2. The lack of top level leadership involvement in the project
   
3. Business processes were not correctly redefined and continued to be inefficient
   
4. The impact of the organizational change was not addressed properly and caused a major upheaval in the company
   
5. The vendor wasn't managed correctly and over-promised, then under delivered [sic]
   
6. Project management was weak and over-customizations lead to increased scope and time
   
7. The integration of diverse applications was harder than anyone expected
   (Bergamo 2010)
   

In this process we are drilling-down on Bergamo's symptoms list and setting them in the context of the New ERP – Extended Readiness for Profit while contrasting them with traditional ERP – Everything Replacement Projects to see if using the New ERP approach would have mitigated the failures.

2. The lack of top level leadership involvement in the project

This is a no-brainer for the New ERP – Extended Readiness for Profit, and the reason is simple: "Top level leadership" are always interested and involved in those things that are going to lead to increasing profit. They are less likely to be interested and involved in "housekeeping" and "maintenance" matters.

For better or worse, top-level executives frequently consider IT either "a necessary evil" – like paying the janitorial staff; or they see it a "necessity that no longer delivers a business advantage" – like maintenance on well-worn manufacturing equipment on the shop floor. It may have been a competitive advantage when it was purchased (several years ago), but now it is only an "expense."

If top-level leadership had begun their search by looking for improvement leading to a competitive advantage, or improvement leading to significant increases in Throughput they would be "involved" in the project. Not only so, but if they had followed the New ERP – Extended Readiness for Profit approach, their application of the Thinking Processes (see prior posts) would have led executives and managers to uncover the answers to the three critical questions we have so frequently reiterated:

1. What needs to change (Current Reality Tree)
   
2. What should the change look like (Future Reality Tree)
   
3. How to effect the change (Transition Tree)
   

What could be simpler or more effective in gaining top-level leaderships involvement with the project at hand?

3. Business processes were not correctly redefined and continued to be inefficient

This is another problem easily created when traditional ERP – Everything Replacement Project methods are employed and even more easily avoided when taking the New ERP – Extended Readiness for Profit approach. Here is why:

If the executive management team has discovered what needs to change, then they have already automatically "correctly defined" the business processes involved. They know exactly what specific business processes are acting as a constraint or bottleneck to making more money. By using the Thinking Processes' CRT (Current Reality Tree), the firm's leadership has already unlocked and decoded tribal knowledge so as to precisely what business process should be improved.

And, if they are following the New ERP methods, then their next step likely would be (depending on certain factors) the creation of a Future Reality Tree (FRT) or a Transition Tree (TrT). Either of these logical trees would help them understand what the change should look like and how to effect the change. Specifically, the FRT would define for them what their business processes should look like after the proposed change, and the TrT would become the management team's roadmap for change management. [Note: For Theory of Constraints purists, there are other portions of the Thinking Processes that might become a part of this (e.g., Negative branches, Prerequisite Trees) that I have left out of this discussion for the sake of simplicity.]

I think you can see from this that, by employing the New ERP methods, there is simply no way to leave behind "inefficient processes" that remain unchanged. Fundamental to the Thinking Processes and the planning that results from the logic of the trees is the inherent roadmap to changing whatever it is that was defined in "what needs to change" (the CRT).

In the traditional ERP – Everything Replacement Project so much change is happening all across the organization, it is no surprise that all that some processes get overlooked and remain unchanged and, as a result, inefficient as well. 

4. The impact of organizational change was not addressed properly and caused a major upheaval in the company 

This cause sounds sort of redundant, does it not? This is a symptom that has its roots in the whole philosophy of traditional ERP – Everything Replacement Projects. After all, it is really hard to avoid a "major upheaval in the company" when your approach is to "replace everything" in their core IT systems.

That is precisely why the New ERP – Extended Readiness for Profit is not only vastly more likely to provide a sound and significant return on investment (ROI), it is also likely to produce an ROI at lightning speed. Many traditional ERP projects take years to produce a return and, sadly, some never do.

[To be continued]

©2010 Richard D. Cushing

Works Cited

Bergamo, Sue. CIO Update: Is Your ERP Implementation in Trouble? Feb 01, 2010. http://www.cioupdate.com/features/article.php/3862056/Is-Your-ERP-Implementation-in-Trouble.htm (accessed Feb 02, 2010).


 

The New ERP – Part 38

Yet another "Why ERP implementations fail"

Sue Bergamo, former CIO at Aramark's WearGuard & Galls companies, recently posted an article entitled "Is Your Implementation in Trouble?" (Bergamo 2010) In her writing, she listed seven "high level categories…. in the order from the highest to lowest number of responses" from her informal LinkedIn survey. Here is how the list shaped up:

1. A misconception of business expectations
   
2. The lack of top level leadership involvement in the project
   
3. Business processes were not correctly redefined and continued to be inefficient
   
4. The impact of the organizational change was not addressed properly and caused a major upheaval in the company
   
5. The vendor wasn't managed correctly and over-promised, then under delivered [sic]
   
6. Project management was weak and over-customizations lead to increased scope and time
   
7. The integration of diverse applications was harder than anyone expected
   (Bergamo 2010)
   

We are going to drill-down on these and put them into the context of the New ERP – Extended Readiness for Profit, contrasting them with traditional ERP – Everything Replacement Projects to see if using the New ERP approach would have mitigated the failures.

1. Misconceptions of business expectations 

Ms. Bergamo does not explain in her short article precisely who had the misconceptions of business expectations. We do not know whether, in the Bergamo survey, the misconceptions were held by all or part of the management team involved in the ERP acquisition, by the vendors and resellers involved, and/or by third-party consultants that may also have been a part of the ERP project. My experience tells me, however, that if persons were involved in a traditional ERP – Everything Replacement Project the likelihood is very high they had and held "misconceptions of business expectations."

Why do I say this so boldly?

Because, unfortunately, most organizations do not begin their search for traditional ERP with clarity on the three critical factors we have discussed earlier in this series:

Management Factor Number 1: What needs to change

If executives and managers applied rational tools to determine precisely – not vaguely – what needs to change so that the business could make more money tomorrow than it is making today, the "business expectations" would be clear.

Sadly, many organizations today still pour in traditional ERP like some kind of "miracle-working additive" that is supposed to make their whole enterprise run smoother, cleaner, faster and, as a result, produce more profit. It seems that 20 or 30 years of experience with ERP not delivering its supposed miracle-working power in so many implementations is not yet enough to convince some. Such executives continue to drink the proverbial Kool-Aid offered by ERP software vendors and VARs just as if the hundreds of bad experiences being reported are only mirages and the same could not and would not happen to their firm.

I have walked into dozens of traditional ERP projects where, if asked, no one in executive management could tell me what measurable improvements were expected when the implementation was complete. If they were able to reply at all, their answers sounded more like they were drawn from a séance than from a the mouth of an executive. They might sound something like these:

"We expect that this new ERP system will enable us to grow while holding down our operating expenses."

"We are counting on this new system to help us ship more efficiently."

"Our ERP vendor told us that this new system should help us reduce our inventories without sacrificing customer service. Plus, it will help us build 'best practices' into our back-office."

Now, I have no problem with "We expect that this new ERP system will enable us to grow…" provided that statement is followed by specifics like:

• How much is it likely to "help us to grow"?
  
• What specific changes will the new ERP system bring about that will lead to the expected growth?
  

In the absence of specifics, how can those who complained in Ms. Bergamo's study even complain that they had a "misconception of business expectations"? Was their expectation that they would mystically grow, but they did not, in fact, achieve their concept of mystical growth? Did they expect that profits would mystically improve, but the mystical improvement in profits never appeared?

Just what were their "business expectations"?

If "business expectations" were not defined in clear cause-and-effect terms up front: if the executives and managers could not – in advance – link specific anticipated changes in the "system" (i.e., how the organization itself functions) to the anticipated and measurable improvement, then they have no one to blame for "misconceptions of business expectations" other than themselves. If they drank the vendor's or reseller's Kool-Aid about ROI (return on investment) and did not establish for themselves the metrics for specific and measurable change, they cannot blame the vendor or reseller. It is management's job to know these things and not to simply take a salesperson's (or even a consultant's) word on such matters.

Management Factor Number 2: What the change should look like

If executives and managers have proactively worked out rational cause-and-effect relationships, and have determined clearly and specifically what needs to change, the next step become relatively easy. That step is for the management team to establish what the change should look like.

If applying new technology in the organization (i.e., the system) will "increase Throughput by an estimated 12.5% over 12 months by providing improved market segmentation for Product Line C," then what the change should look like will be described in terms of the changes required to "improve market segmentation for Product Line C." That change might take the form of new market data collection techniques, new automated surveys, or some other form. Nevertheless, there should be no confusion in the management team members' minds as to what the change should look like when it has been implemented.

Similarly, the management team should understand the changes necessary to leverage "improved market segmentation" into "an estimated 12.5%" increase in Throughput over 12 months. The executives and managers should have a clear understanding of how the new market segmentation data will lead to new "offers" in the marketplace that will, in turn, lead to the anticipated growth.

Management Factor Number 3: How to effect the change

What we have described above are real and concrete "business expectations." There is no easy way to misconceive "business expectations" that are so clearly articulated. This kind of "expectation" can be the basis of concrete action. These kinds of "expectations" can become a guide for how to effect the change.

The meaningless séance-induced "business expectations" so frequently articulated by executives and managers surrounding traditional ERP hold little hope of functioning as a guiding light for concrete action on the part of anyone in the organization. It is no wonder that "expectations" are only met in so few traditional ERP implementations.

[To be continued]

©2010 Richard D. Cushing


 

Works Cited

Bergamo, Sue. CIO Update: Is Your ERP Implementation in Trouble? Feb 01, 2010. http://www.cioupdate.com/features/article.php/3862056/Is-Your-ERP-Implementation-in-Trouble.htm (accessed Feb 02, 2010).


 

Constrained by your ERP?

Are you feeling that your ERP "solution" is more constraining than liberating?  Maybe it's your approach?  Maybe its the way your ERP reseller or vendor treats you?  Maybe your "systems integrator" has no vision -- no ability to "think outside the box."  Click on the link or the title of this post and watch a very funny video on this subject.

Whatever it is, you'll get a kick out this (click the link), and you'll find answers by reading more posts right here at GeeWhiz To R.O.I.

Thanks.

...

The Problem with Manufacturing Software

Maybe I am just too cynical. It is likely that I am. However, whenever I work with clients who are implementing (or thinking about implementing) ERP software that includes a manufacturing suite and further, when this client is implementing the manufacturing suite because they "need to get a better handle on manufacturing costs," I warn them: "The problems with implementing software that helps you calculate your cost of manufacturing are two-fold: first, the system will produce a lot of numbers and reports for you and, second, you will believe the reports!"

"So, why is this a problem?" I hear you ask.

In order to answer that question, let me take you through the steps that a client is going to go through in order to implement their new manufacturing suite before they are going to start getting reports and numbers coming out of the system.

In even a relatively simple manufacturing suite, there are dozens of parameters involved. These parameters are used in various places. However, for our purposes, we will just concern ourselves with the few parameters that might be found on a typical "routing" or "router" – the part of the data that tells the system what steps must be executed – and in what sequence the steps must occur – in the manufacture of any given item. Consider the following table:

	Parameter	Purpose	Source and Comments
1	Move Hours	Used by APS (advanced planning and scheduling) to calculate the time it will take to move a unit of production (piece) between operations	Most organizations have never tracked this, nor even given much consideration to "move time" in their operations. Therefore, this is usually a very round "guess-timate" provided to the new manufacturing suite from "tribal knowledge."
2	Queue Hours	Used by APS to calculate the time a unit of production will sit in its queue waiting for the pending operation to actual work on this particular piece	Again, this is usually a very round "guess-timate" provided to the manufacturing suite from "tribal knowledge."
3	Set Up Hours	Used by APS for scheduling purposes, but also used by manufacturing costing to calculate the labor costs and fixed overhead that should be allocated to a production run for the time spent setting up to run a particular operation	The values provided to the new manufacturing suite for the time it takes to set up for a particular operation will probably be pretty close, even if they do come from "tribal knowledge" with no formal calculations underlying them. Likewise, the dollar-costs for the variable labor will also probably be pretty close to the dollar-amounts per set-up. The problem area is going to be fixed overhead absorption rates. These are problem because the actual amount of fixed overhead dollars that should be absorbed will be dependent upon the number of set-ups that occur. If there are more actual set-ups than the number of set-ups used to make the calculations, fixed overhead (and variable labor) will be over-absorbed, and if there are fewer actual set-ups, fixed overhead (and variable labor) will be under-absorbed. One thing of which you may be pretty certain – the number will never be the right number. That is, the actual number of set-ups and the actual duration of the set-ups will virtually never coincide precisely with the numbers used to set the parameters in the software.
4	Reset Hours	See Set Up Hours above	The problems with Reset Hours are precisely the same as with Set Up Hours above.
5	Pieces per Reset	Used by APS and manufacturing costing to determine how many "resets" were performed during each reported production run	This is just one more parameter that contributes to the calculation of manufacturing costs. The relative accuracy of the calculated cost versus the true cost will be entirely depend on the following factors: Was the number of "resets" actually performed exactly as estimated in the creation of the routing? Did the "resets" actually take the precise number of hours allotted for each "reset"?
6	Scrap Pieces	Used by APS and manufacturing costing to determine how many pieces had to be "processed" in order to produce the number of usable pieces required	This parameter also is based on averages. Therefore, if the actual scrap was different from the averages, incorrect costs will be assigned to WIP and, ultimately, to finished goods. If methods are provided by the manufacturing software to capture actual scrap by production run then, most likely, the differences will show up in variances – yet another confusing data point to unravel for decision-making.
7	Production Rates (pieces/hour or hours/piece)	Used by APS for scheduling purposes, but also used by manufacturing costing to calculate how much labor and fixed overhead should be calculated into the manufacturing cost of each operation	Even if the averages used for this parameter are pretty accurate, they are just that – averages. This means that, while they may be reasonably accurate on average over a large sampling of data, the factor will be actually wrong (inaccurate) for virtually every actual production run (which will almost never hit precisely on the average used to set the parameter in the software).
8	Production Effective Rates (percent of "standard" rates)	Companies frequently have "standard" rates per manufacturing operation based on some (frequently unknown) factors. However, they realize that in the process of actual manufacturing the operations generally do not hit this rate. As a result, they may apply a "effective rate" factor to the "standard rate." This factor is used by both APS and manufacturing costing.	Since this factor is taken into account in the calculation of manufacturing costs, it is subject to the same weaknesses previously listed for other parameters.

So, let me get this right…

All right. Let us start with this sampling of eight data points in a typical routing for manufacturing. Remember, these eight data points are repeated for each labor step in the routing. So, if a complex item has, say, 30 labor steps, that means that these data points are going to be used in 240 calculations associated with determining what will appear on reports and may be affecting the value of inventory, as well.

These eight data points – most of which are "guess-timates" or averages to begin with, will next be mathematically compounded against other data points related to:

• Variable labor absorption rates
• Variable labor overhead absorption rates
  
• Fixed overhead absorption rates
  

Since these absorption rates must be calculated based on other "averages" or "guess-timates" as to production quantities per period (e.g., month, quarter, year), we may safely assume that these absorption rates themselves will never be correct. We may say this in a mathematical sense that, in order to be mathematically correct the actual production during the period must match precisely the estimated production during upon which the absorption rates were calculated for the whole organization. Furthermore, the actual fixed overhead or variable labor expenses destined for absorption must match precisely the estimated fixed overhead or variable labor expenses used to calculate the absorption factors. The statistical likelihood of this occurrence is so close to zero as to be the statistical equivalent of zero. Therefore, we may properly say, these calculations will never be "correct" in actuality.

Unfortunately, having populated their new manufacturing suite with "averages" and "guesses," when the official-looking reports come out the other end, far too many executives and managers actually believe what the reports say. Worse! They actually begin taking action on the results presented by their costly manufacturing software as though the data reported is "God's truth" in print.

A simpler solution

Before you invest from $100,000 to $1 million or more in the purchase and implementation of a manufacturing suite of software, allow me to suggest some calculations that you and your management team can do simply in a spreadsheet (or on a napkin at lunch).

Try this simple formula for any item in your system:

T = R – TVC
where T = Throughput,
R = Revenue, and
TVC = Truly Variable Cost

Now, for almost any item in your manufacturing operations, you – or someone on you management team – can come pretty close to calculating the Throughput (T) value without getting up from the table. Many times this calculation can be done with reasonable accuracy without ever going to your present accounting system to get "costs."

Forget about all those "allocations" and "absorptions" of fixed overhead! They don't really happen and they can make you believe things that aren't true. Your payroll and fixed overhead do not vary directly with each unit of production – even though that's what most manufacturing software wants to make you believe in their costing and variance reports.

The previous formula is good for looking at a individual product or product family, but how about looking at overall operations?

Here's another simple formula to help you do that:

P = T – OE
where P = Profit,
T = Throughput, and
OE = Operating Expenses

Operating Expenses are, essentially, everything that you pay out that is not TVC.

We will look into this further in another post. Stay tuned.

©2010 Richard D. Cushing

The New ERP – Part 37

In an article posted on the Web in October 2009, Carol Francum states, "A quick search of CIO magazine's website turns up more than 200 entries for the term 'Project Plan' and even more for 'Project Success' and 'ERP Project.' Many of these articles point out that 'scope creep' and the failure to assess customers' real requirements are the biggest reasons projects fail. Other articles focused on selling users a particular tool for project management. A recent blog asserts that ERP project success may be defined as completion, regardless of the ROI or performance improvements which may or may not have been achieved." [Emphasis added.] (Francum 2009)

Apparently, from what Ms. Francum reports later in the same article, there is not really much agreement among traditional ERP – Everything Replacement Project project managers as to which factors are, in fact, "critical" to project success:

• Just over 1 in 5 traditional ERP project managers said that "accurate requirements definition" was a primary success factor
  
• About 1 in 6 each cited one of the following as "critical" to traditional ERP project success –
  
  • Upfront project planning
    
  • Stakeholder commitment and alignment
    
  • Subject matter expert involvement
    
  
  
• And, about 1 in 7 traditional ERP project managers seemed to think that understanding and documenting the "as-is" versus the "to-be" business processes was "critical" to success
  

What is it about "business requirements"?

Another author, Todd Boehm, tells us this about "requirements gathering" in a traditional ERP – Everything Replacement Project: "One of the most important steps of any software project, especially the choice of an ERP system, is to gather requirements. You need to know what is needed, what is wanted, and what you can do without…. The definition of ERP is very loose, and could include modules that you don't need, or not include modules that you will eventually want." (Boehm 2010)

Now there's an encouraging word: If you opt for traditional ERP, you might end up buying "modules that you don't need" on the one hand; or the application may "not include modules that you will eventually want." There are two problems with this statement:

1. Buying "modules" – or any functionality – that your organization does not need to add or change in order to increase Throughput, reduce Inventories or the demand for new Investment, or cut or hold the line on Operating Expenses while sustaining significant growth is pure waste. It certainly should not be done because someone in the organization, no matter how influential or how highly ranked, simply says they "want" or "need" the additional functionality.
   
   
2. This brings us to the other problem with the statement, and that is the use of the word "want" with regard to the modules that may potentially be missing in a traditional ERP offering. Decisions intended to bring improvement – that is, decisions focused on helping a for-profit organization make more money tomorrow than they are making today – should not be predicated on "want." It makes no difference the title of the one "wanting" the capabilities. If the capability cannot pass must when scrutinized under the R.O.I. (return on investment) challenge, it should not be purchased – now or ever.
   

The good news is that at least someone writing for Wikipedia seems to have gotten the basic concept right. Here's the definition of "business requirements" from Wikipedia:

"Business requirements describe in business terms what must be delivered or accomplished to provide value." (Wikipedia.org 2007)

I confess: I really like this definition. It is too-the-point and leaves nothing essential out.

In almost all of the literature surrounding traditional ERP – Everything Replacement Projects the missing element is a strong connection between the changes being effected through the deployment of the new – and costly – technology and "what must be delivered or accomplished to provide value." And this critical element for "business success" – not to be confused with "project success" – is missing despite the fact that traditional ERP consultants frequently make a point about involving business owners and managers in the "requirements gathering" process.

My strong sense, in speaking with a large number of executives and managers over the last 25 years, is that they calculate ROI on traditional ERP something along these lines:

"Our business is presently growing at X% a year and we believe (or "think") that if we replace our existing ERP system with a newer and fancier ERP system that we can make more money."

This "make more money" part is usually predicated on more rumination about "making more sales" or "reducing expenses" in some ethereal form. There are almost never any hard facts or numbers put on paper as to the expected results.

What "business requirements" should look like

No.	What must be delivered or accomplished?	What is the expected business value to be delivered as a result?
1	Implement a supply chain integration and visibility solution directed at reducing stock-outs in among the top 20% of SKUs (rated by Throughput) to fewer than 5 per month	Increase Throughput by 12.5% where 9.5% (over 9 months) of the increase comes from recapturing what would have been "lost sales" and the remaining 3.0% (over 6 months) come from Sales Management's commitment to regain customers previously lost due to what customers deemed to be our lack of reliability as a supplier for these SKUs
2	Implement a business intelligence (OLAP) solution to provide the Sales and Marketing Departments with visibility into sales data by customer, salesperson, sales manager, region, and other demographics for the express purpose of establishing viable "market segmentation" for use in the development of "irrefusable offers" by market segment (to a single customer, if required)	Increase Throughput by 22% (over 12 months) in accordance with estimates and concepts outlined by the Sales and Marketing Departments without increasing Operating Expenses
3	Eliminate paper-based picking, packing and shipping in the warehouse with the goal of being able to accurately pick, pack and ship 16 average orders (~117 lines) per hour in order to support increasing Throughput without increasing Operating Expenses	Hold-the-line on Operating Expenses while increasing the capacity of the warehouse shipping function to an average of 16 orders per hour with greater than 99% accuracy

Please note that the "business requirements" in the examples above contain all of the key elements listed in the Wikipedia definition. Further, note that these are all measurable. And because they are all measurable, it is not only possible for the management team to determine whether the resulting IT project was a "success" based on project-related measures such as on-time, within the budget (for establishing budgets, see other posts in this series), and of acceptable quality. The management team can also measure whether the "improvement project" was a success from the standpoint of having achieved its forecast business objectives.

There is no way to write a comprehensive set of "business requirements" that would be parallel to this in a traditional ERP – Everything Replacement Project. The reason is simply that the traditional ERP approach results in too large a project covering too many changes within the organization. Some of the changes will, undoubtedly, produce negative results if reduced to such definable metrics.

Think about this next time you are asked to write "business requirements" for someone's proposed IT project. What will be your management team's measure of "success"?

Works Cited

Boehm, Todd. Gathering ERP Requirements. January 01, 2010. http://worldclasstech.wordpress.com/2010/01/01/gathering-erp-requirements/ (accessed January 02, 2010).

Francum, Carol. Revving your engines: Tuning up your ERP project plan. October 26, 2009. http://searchoracle.techtarget.com/news/1372186/Revving-your-engines-Tuning-up-your-ERP-project-plan (accessed November 18, 2009).

Wikipedia.org. Requirement. October 2007. http://en.wikipedia.org/wiki/Requirement (accessed January 07, 2010).