Skip navigation
2010

Show me the R.O.I.

One of the things that amazes me, in my more than 25 years in working with PC-based technology solutions for small-to-mid-sized business enterprises and my review of literally hundreds of articles covering traditional ERP – Everything Replacement Projects in trade publications and on the Web, is the near total absence of any substantive discussions regarding return-on-investment (ROI). Sure, there are some articles and some vendors that give lip-service to ROI. Generally, whenever they do, however, they do so sometimes by simply implying that the buyer, indeed, should be concerned about ROI and they, as the seller, will somehow mystically deliver "ROI," if you buy and implement their software. In some cases, they go a step further. They offer ROI calculations based on averages and factors built into formulas that, generally, will calculate an ROI no matter what numbers you plug into their spreadsheets or Web forms.

 

Unfortunately, business enterprises are systems that do not necessarily respond in ways that will make the averages and predetermined factors applicable. While an "average" ROI may be calculated, the fact is, no matching "average" company exists to achieve the ROI.

 

Some R.O.I. is intuitive

No, I am the first one to admit that some actual ROI cannot be reduced to hard numbers. For example: Let us say (as we have seen in earlier posts – see Part 12 of this series) we calculate our planned ROI based on the saving of 0.5 FTE (full-time equivalents) through the deployment of integrated barcode printing, 1.2 FTEs by adding integrated ASN processing, and another 1.7 FTEs through paperless picking, packing and shipping while growing the Throughput 18% over twelve months. These "savings" are based on actions the company will not have to take – namely, at some point following deployment, the company will not have to hire some new employees.

 

It is impossible to determine the date at which the firm did not have to hire an employee. It is impossible to determine exactly how much the firm would have paid the employees it did not have to hire. So, while it is possible to determine that the firm did (or did not) successfully grow Throughput by the planned 18%, it is not possible to determine exactly how much money was saved through not hiring additional employees.

 

At least two aspects, however, are likely proof-positive that the planned ROI was reasonably accurate:

 

  1. Bottom-line profits should reflect values that would approximate the net effect of the increased Throughput and the reduced Operating Expenses
  2. Executives and managers can probably intuit that, had the changes not been made, additional employees would have been necessary to support the activity resulting from the increase in Throughput

A business initiative

Eric Kimberling, president and founder of Panorama Consulting Group, an independent ERP consulting firm, in his blog post entitled 7 Steps to Choosing the Right ERP Software, points out that "ERP is first and foremost a business initiative…." (Kimberling 2008) Kimberling goes on to say that ERP buyers should "[u]nderstand the total cost of ownership," and they should "[t]rack the potential business benefits of the new system." Nevertheless, although Kimberling shows some keen insight, he does not suggest that in looking for "the right ERP software," that the business enterprise should a) actually determine in advance what specific changes in the firm's current reality will lead to measurable improvements, or b) actually calculate an ROI based on reaching specifically measurable outcomes in terms of increases in Throughput, reductions in Inventory or demand for other Investment, or cutting or holding the line on Operating Expenses while sustaining significant growth.

 

Kimberling is right. IT decisions should be, "first and foremost a business initiative." While the IT department should be keenly aware of new technologies appearing on the horizon, their mental processes should be entirely synchronized with the organization's primary goal of making more money tomorrow than they are today (in for-profit enterprises). When they bring forward to executive management concepts for applying new or different technologies in the enterprise, these ideas should be thoroughly subjected to review in light of managements "framework" as defined in their Current Reality Tree (CRT), Future Reality Tree (FRT), and Transition Tree (TrT) as part of the firm's POOGI (process of ongoing improvement). (See prior posts, especially Part 5 in this series.)

 

Whenever anyone – even the CEO – in the organization wants to spend money for the "improvement" of this process or that one, the expenditure should be considered in light of the basic formula we have used previously and reiterate here:

 

 

 

Where T = Throughput (Revenue less Truly Variable Costs only),
OE = Operating Expenses, and I = Investment

If this is not done routinely, there is a great likelihood that precious time, energy and money will be spent with no benefit being reflected on the bottom line of the company's financial reports. This is nothing but waste.

 

Works Cited

Kimberling, Eric. 7 Steps to Choosing the Right ERP Software. May 30, 2008. http://blogs.techrepublic.com.com/tech-manager/?p=517 (accessed December 15, 2009).

What makes technologies valuable?

Let us stop for a few moments to think about just what it is that makes new technologies valuable to a business enterprise. If we take this time to think, it should occur to us that there is no inherent value in new technologies. Just like everything else that resides within your enterprise, new technologies only add to Operating Expenses (OE) in and of themselves. It is only in the application of technologies to business processes that value may be found.

 

Interestingly, the value delivered through the application of technologies to business processes may be broken down into three elementary categories – categories that we have discussed on numerous occasions elsewhere in these posts:

 

  1. Increasing Throughput (T)
  2. Reducing Inventories or driving down the demand for new Investment (I)
  3. Cutting or holding-the-line on Operating Expenses (OE) while sustaining significant growth

If you and your management team are going to purchase new technologies as part of a process of ongoing improvement (POOGI), you will know – or should recognize – automatically that you will either increase Investment (capitalized purchases) or increase Operating Expenses (in at least one year), or both (since any capitalized purchase will be amortized as an expense over multiple future periods. Therefore, it is also important that your team has compared this proposed improvement project with other improvement options using this simple formula:

 

ROI = (delta-T – delta-OE) / delta-I

Where ROI = Return on Investment,

T = Throughput (Revenue less Truly Variable Costs only),

OE = Operating Expenses, and

I = Investment.

 

As you can see from this simple formula, the ROI is maximized by achieving the highest value for delta-T while holding delta-OE and delta-I as low as possible. This leads to a very simple set of priorities:

 

  1. Projects that increase Throughput are generally a top priority
  2. Projects that reduce Investment (including reductions to inventories – being the most common reduction in Investment) should be considered next
  3. Projects that reduce Operating Expenses are generally reserved for last for consideration

The Technology Value Matrix

If you will review carefully the accompanying figure you will see immediately something about what makes new technologies or, more appropriately, new applications of technologies valuable. In this matrix, the lowest value values are to the lower left - "Commodity Technologies." Commodity technologies are those that are widely available, they tend to have a "standardizing" affect on the enterprise, and they are generally applied in a typical (read: non-innovative) way. Examples of such technologies include desktop computers, graphical user interfaces (GUIs), network servers, relational or other databases, and so forth.

 

 

 

So, what would a "Wasteful Technology" or technology application be?

 

Consider a small business that has a typical range of departments. They do everything from R&D to shipping and receiving, invoicing, and general ledger accounting. In the shipping department is a bright young lad that never completed college, but he is a hard worker. He is effective, full of good ideas, and does whatever it takes to keep customers happy inasmuch as it lies within his power to do so. The president and founder of this young company still works in the R&D department helping to design the next generation of products. This firm generally introduces four to six new products a year, so the president doesn't even work in R&D on a full-time basis. On the other hand, the young man in shipping is constantly working 50 or 60 hours a week trying to assure that the firm's customers' orders are filled on-time.

 

While this scenario is not based on any particular client with whom I have worked in the past, the general scene is not all that distant from far too many clients in my experience. All too frequently, if an investment is going to be made in technology, the president and R&D 'guru' is far more likely at having $10,000 thrown toward a high-end CAD workstatation, while the guy working 50 or 60 hours a week in shipping remains stuck doing his work on a six-year-old machine that is long past its prime. Or, worse, the guy in shipping is still filling out paperwork on shipments by hand, and these data are then being keyed by someone else into the firm's accounting software.

 

Let's compare these two options based on the following (usually true) assumptions:

 

  • The firm does not expect the technology investment in R&D to accelerate time to market, the frequency by which new products are introduced to the market, or have any other affect leading directly to increased throughput

  • The firm will not include in its calculations any supplementary beneficial effects on Operating Expenses that my accrue through increased accuracy, support for significant growth, or the elimination of potential data redundancies under the old regime

  • Investment (delta-I) will be the same for each option

Improvement Option

Effect on Throughput

Effect on Investment

Effect on Operating Expenses

New CAD workstation for President in R&D

No increase in Throughput

Increase by $X

Increase by $Y

New automation for shipping

Yes, increase Throughput

Increase by $X

Increase by $Y (amortization of investment) LESS

decrease in overtime wage expense

 

 

Time and time again I have spoken with companies that make just such foolish expenditures on new applications of technologies. Why would a company make a decision to spend money for what is clearly zero-dollars in net benefit to the organization?

 

The answer is usually found in one of two areas:

 

  1. Company politics – the investment goes to the person or department with the greatest "pull" in the organization

  2. The company's management team simply considers all IT expenditures an "expense" and, therefore, never calculates a return-on-investment

Such an approach is folly on multiple counts, but considering that time, energy and money are all limited resources within a firm, it seems blatantly silly to "spend" any of them where there is no return on the "investment."

 

That, in a nutshell, is a display of "wasteful technology." Since the firm had no deliberate plan to do anything particularly "differentiating" along with the purchase of the new CAD workstation for the president, and since CAD in itself is "standardizing" (not "differentiating"), the high expense for an engineering "workstation" made about as much since as the purchase of a $10,000 Rolodex™ for one of the secretaries.

 

[To be continued]

Strategic alignment is the "best determinant" of success

According to writer and researcher Meridith Levinson, "Many factors influence project success and failure…. But new project management research from training company Insights Learning and Development, the Project Management Institute and a strategic execution consultant suggests that the single most important factor influencing project success is the project's link to the organization's business strategy and the project manager's understanding of how the project supports the business strategy." (Levinson 2009) [Emphasis added.]

 

This should be an encouragement to any executive or manager who has been following along with us in our development of The New ERP – Extended Readiness for Profit. I say this because we have emphasized the following THREE SIMPLE STEPS:

 

  1. Discover what needs to change, which we have helped you do by applying the Thinking Processes (TPs) and leading you and your management team to the creation of your own Current Reality Tree (CRT). By looking to the roots of your CRT, you were able to see clearly those few things (usually fewer than a half-dozen) that need to change in order for your business to reach more of its goal of making more money tomorrow than it is making today.

  2. Work through what the change should look like. Here again, we suggested that you apply the Thinking Processes to build a Future Reality Tree (FRT) and Transition Tree (TrT). These two logical trees will help you and your management team understand with considerable clarity what the changes should look like if your "system" is going to improve.

  3. Last, how to effect the change must be considered and, actually, if you have built your Transition Tree, you already have determined how to go about making your changes. It is worth mentioning, however, that sometimes the evidence at the "roots" of the CRT is so plainly evident that it is not necessary to build either an FRT or a TrT. (We do not advocate this approach, but some matters are so plain and so easily changed, that the actual work can be documented later, or a new CRT is drafted immediately following the implementation of the "simple" changes.)

 

You will note immediately that, having applied the TPs, you and your management team have already addressed the next element Levinson mentions: "Strategic value alone is not enough to ensure project success…. Project managers need to understand the business strategy and how the project supports it." (Levinson 2009) Having built your logical trees (i.e., CRT, FRT, TrT), you have the tools in your hand to quickly, accurately and effectively communicate "how the project supports" your business strategy of ongoing improvement to anyone involved in any part of the improvement projects that might be set forth.

 

A strategic road map for the improvement project

Here is a terrific side-benefit you get by having used the Thinking Processes to guide your New ERP – Extended Readiness for Profit project up to this point: For no additional investment of time, energy or money you and your team have a ready-made road map to keep yourselves and your project leads on target with the projects.

 

Levinson states that under traditional ERP scenarios, "[P]roject managers lack 'the context required to flag when the project is veering from its original intent and course-correct towards the intended outcome,' [write Suzanne Dresser and Mark Morgan, authors of a report published by Insights Learning and Development and the Project Management Institute]. And that's when cost and time overruns begin and when projects start to veer from business requirements." (Levinson 2009)

 

Your Thinking Processes diagrams provide not only the crystal-clear rationale for your efforts, the logic has already helped your management team set unambiguous metrics by which to compare outcomes with desired results. No fumbling around is required or allowed. Furthermore, the budget that you team has set is equally unambiguous.

 

Summary

In short, if alignment of IT projects with "business strategies" is, indeed, the "best determinant" of project success, you and your management team are well on their way to success if you have been following along with us in applying The New ERP methods. Plus, you have provided for yourself and those involved at every level with a clear, concise road map to keeping the entire effort – or even multiple efforts – on target for the desired ROI (return on investment) and within a budget that makes sense.

 

 

References

Levinson, Meridith. Business Strategy: The 'Best Determinant' of Project Success. Nov 17, 2009. http://www.cio.com/article/508018/Business_Strategy_The_Best_Determinant_of_Project_Success (accessed Nov 17, 2009).

Recap

This is Part 27 in our series, so let's take a moment to briefly recap what The New ERP – Extended Readiness for Profit has done for us so far in contrast to traditional ERP – Everything Replacement Project.

 

Aspect

Traditional ERP

The New ERP

Setting the goal

Lack of focus: Traditional ERP often has several goals (read: lack of focus) or a goal that is entirely generic (read: lack of focus). Therefore, ROI is frequently predicated on little more than hope that throwing new technology at the organization will somehow lead to improvement and better profits.

Laser-like focus: In The New ERP began with uniting executives and managers around a singular goal (in for-profit organizations that is typically making more money both now and in the future). Next, The New ERP applies the Thinking Processes to help management understand what is keeping the organization from achieving more of its goal. This gave management a clear view of:

 

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

Linking ERP objectives to financial goals (IT alignment)

Loosely bound to financial goals: Far too many traditional ERP projects are bound to financial goals only by a tenuous thread of hope in the hearts of managers and executives. Others may calculate an ROI (return on investment) based on broad estimates of overall "improvement," but these are generally not tied to specific effects and measurable expected outcomes.

Tightly bound to financial goals:

The New ERP – Extended Readiness for Profit uses what is learned through the application of the Thinking Processes to tightly aid managers and executives in linking measurable execution metrics to the achievement of financial goals. If "revenue is to increase by 12% in the first year," then the management team knows precisely which actions and improvements are expected to lead to these results.

Invention of the "solution"

Solution is a "package" brought from the outside:

Traditional ERP frequently revolves around the organization defining their "needs" or "requirements," and then seeking a "package" brought to them from the outside (by a vendor or value-added reseller) to provide them with the "solution." If the executive team or the vendor cannot achieve enterprise-wide "buy-in" by the end-users, then the implementation of the "solution" may be more costly or less effective than intended, or it may fail entirely.

"Solution" is invented by the executives and managers in charge: By applying the Thinking Processes and determining with precision "what needs to change" and "what the change should look like" in order to achieve more of the organization's goal, the management team employing The New ERP becomes the inventor of their own "solution." By inventing their own solution, and by doing so using a rational toolset, "buy-in" becomes automatic. No one fights against their own invention.

Budget setting

See "Linking ERP objectives to financial goals" above

See "Linking ERP objectives to financial goals" above.

The New ERP allows your management team to set rational budgets for specific, highly-targeted and measurable improvements so that the budgets make sense relative to the return on investment calculations. All of this is done with relative simplicity and paralysis by analysis is avoided entirely.

Software selection

Wholesale replacement:

Traditional ERP – Everything Replacement Project does just what you would expect. It leads to replacing everything – or almost everything – in the organization. It is not focused on alleviating or eliminating organizational "bottlenecks."

Targeted Extensions:

The New ERP – Extended Readiness for Profit is focused on effecting change in specific areas that have been rationally identified as being constraints ("bottlenecks") that are keeping the organization from achieving more of its goal. This focused approach means that the whole organization need not be disrupted to bring about effective improvement. Furthermore, very specific technologies selected to achieve very specific ends is the objective in software selection.

Vendor demonstrations

Unfocused review of functionalities: Vendor demonstrations under traditional ERP approaches often occupy days or weeks, sapping time, energy and money from all of the various departmental silos involved. This process alone may increase operating expenses by driving up overtime costs for "catch-up" work.

Tightly focused "proof of concept": Under the New ERP, vendors or resellers are invited to present proofs of concept around improvements that are very narrowly defined. They are also asked to speak specifically – and convincingly – about how their technologies will allow the "client" organization to achieve its goals within the budget prescribed.

 

 

What has been accomplished to date under the New ERP concept for the organization applying it (as in the table above) has likely saved the entire organization no small amount of time, energy and money. In addition, they are in a far better position to see actual results in the near future – results predicated on sound logic and real strategies, not hope and guesswork.

 

[To be continued]

 

(c)2009, 2010 Richard D. Cushing

Vendor demonstrations

It is an unfortunate fact that, if our foundation is wrong, chances are the rest of the building will not be too great either. This is certainly the case as we come to the matter of vendor demonstrations in a traditional Everything Replacement Project. Consider the typical steps that have been taken to get the firm to the "vendor demonstrations" stage in traditional ERP:

 

 

 

As we have been discussing all along (see prior posts), none of these steps, when undertaken in with traditional ERP in view, are designed to focus the effort on those few things that need to change in order to make the enterprise more effective at producing profit. Instead, an almost egalitarian approach is assumed in which the "concerns" expressed and "requirements" supplied by department X carry equal weight with those expressed by department Y. After all, it is only fair.

 

This remains precisely why traditional Everything Replacement Projects so seldom deliver really dramatic results in terms of increase profit. And, when they do, it is mostly serendipity that delivers the improvement. Likely it was because three or five things that actually needed to change got some or all of the change they required, and the remaining several hundred things that also changed in the traditional ERP effort did not do enough harm to overwhelm the benefits delivered.

 

When we, then, extrapolate this lack of focus down from "requirements gathering" through "software selection," and "vendor selection," we arrive at the prospect of sitting through vendor demonstrations that are equally unfocused. People from several – perhaps dozens – of departmental silos are invited down to view essentially redundant demonstrations of how the proposed new software will replace the way they presently execute the same basic tasks.

 

Vendor demonstrations in the New ERP – Extended Readiness for Profit

If you and your management team have been following along with us (see prior posts), then you will immediately see that preparing for vendor demonstrations in the tightly focused environment of the New ERP would be and should be dramatically different. Rather than sitting through long and (usually) somewhat boring vendor demonstrations of how General Ledger, Accounts Payable, Accounts Receivable, or Purchasing works, or even generic (though somewhat more exciting) demonstrations of how the warehouse will operate with the new software in place, the management team in our example company has laser-like focus on crystal clear and measurable objectives. For this team, the vendor demonstrations are not generic, at all. Instead, the vendors are called upon to demonstrate "proof of concept" around tightly-defined metrics.

 

Rather than giving the selected vendors a 32-page "demo script" that covers elements of every module to be part of the traditional Everything Replacement Project, your well-prepared executive management team has handed off "Proof of Concept" requirements to the selected vendors. A "Proof of Concept" requirement might read something like the following (in our example company):

 

  • Demonstrate how your bar code printing solution can be integrated with our existing inventory system and how bar code label printing will be performed in connection with receipt of goods and manufacturing production operations. Explain how leveraging your existing APIs (application program interfaces) will hold the cost of development and deployment of your bar code printing solution below $X.

  • Demonstrate how ASNs (advanced shipping notices) will be automatically generated via integration with our existing technologies. Furthermore, demonstrate how ASNs will be transmitted to the appropriate destinations by retrieving data from our existing back-office accounting and sales order entry software. Explain how you will leverage your integration engine to hold total cost of development and deployment below $Y.

  • Demonstrate how your combination of hardware and software will lead to essentially paperless pick-pack-ship operations. Further, demonstrate how your solution will permit us to process (on average) N orders per hour through the entire pick-pack-ship process. Show how you will keep the total cost of development and deployment below $Z.

 

Notice that the goals of discovery for vendor demonstrations under the New ERP are two-fold: results within budget. Of course, this implies something on the part of your organization, as well. You should note, for example, that there is no "touchy-feely" language in these "Proof of Concept" requirements. This lack of UI (user interface) formulation suggests that, if you can get to the results you require within the budget you have established – based on return on investment (ROI) – then your organization is willing to adapt their business processes to the demands of the new technologies.

 

This really makes superabundant economic sense from a business perspective. You and your management team have already identified what needs to change and what the change should look like using the Thinking Processes (see earlier posts). You have also set rational budgets for Investment (I) based on the ROI formula. Now it is up to the technology vendors to demonstrate how they intend to effect the required changes within the Investment budget.

 

Once your management team has reviewed the "proofs of concept" offered by the vendors, you can make determinations if any adjustments need to be made in the benefit or ROI calculations. Such adjustments, however, should be relatively minor – not a major overhaul of the intended target.

 

[To be continued]

 

(c)2009, 2010 Richard D. Cushing

Choosing a vendor or reseller

In the traditional Everything Replacement Project, there are several different paths that a firm may take to decide which reseller they wish to employ in the project. (Here I will use the term "vendor" or "reseller" interchangeably to some extent. There is real distinction, and I do not mean to minimize that difference. If your firm is choosing from among value-added resellers – "resellers" – then they have a greater opportunity to select the actual personalities that will be involved in the deployment. On the other hand, if you are dealing with a national or international vendor directly, it is quite likely that you will be "stuck" with whomever is assigned to your account by the vendor barring, of course, what could be a contest of wills over the personnel.)

 

The simplest and most straightforward approach is the one most often followed by small- to mid-sized firms. This one-step process may be flatly stated as: Decide which software you are going to buy, and then take whatever reseller happens to come along with that software. This simple, single-step process makes decision-making very easy, but it may not necessarily garner for your organization the best-qualified persons for achieving success in your Everything Replacement Project.

 

Other organizations recognize the risks inherent in not placing some kind of hurdle between themselves and a potential traditional ERP reseller. Therefore, either their management team or their hired consultant will create a vendor screening process. While the process itself takes various forms, it usually includes gathering seemingly important data about the potential field of resellers like:

 

  • How long the reseller has been in business
  • How many clients the reseller has
  • How many times the reseller has implemented the software under consideration
  • How financially stable the reseller is
  • How many references the reseller can supply

 

Now, as important at these various aspects might be in selecting any vendor with which your firm wishes to do business, only one of these elements even approaches what might be important in helping you and your team achieve more of your goal of making more money today and in the future. Specifically, that would be the last point – client references.

 

Unfortunately, when most organizations get their hands on client references from a vendor or reseller, they squander the opportunity asking questions like these:

 

  • "Was your project completed according to schedule?"
  • "Was your project completed within budget?"
  • "How were you treated by the reseller?"
  • "How long did your project take to complete?"

 

Now, never mind that the differences between the project being considered by your company and the project undertaken by the reference company may be as different as night from day, what do these questions really tell you about the things you should actually be considering? Why are not there questions like the following included in the mix? Are not these the really important questions to be answered?

 

  • "Before selling you the software, did the reseller really help you come to clear understanding of the very specific areas where improvement would lead to your firm's ability to make more money tomorrow than you are making today?"
  • "Have you seen real and measurable improvements in your organization's ability to make more money since the reseller sold and implemented the technology in your business – over and above your preexisting growth trajectory?"
  • "What is your calculated return on investment for the money you paid to this reseller?"

I am compelled to reiterate (see prior posts): Any traditional ERP effort – or any other kind of improvement project on which a firm spends its precious and irrecoverable time, energy and money – for which there is no measurable improvement in Throughput, Investment or Operating Expenses is a failure whether or not it was completed on-time, within the budget, or with huge self-congratulations.

 

The Toyota measure of quality

Toyota, a company that emerged from the rubble of post-World War II Japan to become the world's leading supplier of cars and light trucks, developed a very interesting concept regarding "quality." For Toyota, quality is not about defect rates or meeting specifications. Toyota's management agrees that there is only one measure of quality that counts, and that is the customer's measure.

 

Toyota's management principle is that the customer measures quality in two ways: the first metric is the customer's experience. Note that all of the questions in the traditional ERP's reference checking were related to the customer's experience. Toyota's second customer-centric measure of quality is the customer's results. Now, with a car or light truck for personal use, the results sought may be nothing more than ego-satisfaction (like the guy that goes out to buy a Titan pickup, or the ecology-centric individual that buys a new Prius. But, in business – in your enterprise – real results are not so ethereal.

 

Note that none of the questions in the traditional ERP's reference checking list of questions dealt with the vital results that drive business improvement. In my opinion, limiting reference-checking to such vain questions is only a waste of time for executives and their teams. Consider instead additional questions along these lines:

 

  • Did the reseller demonstrate keen insight into the core business issues that are keeping you from making more money, causing inventories or demand for new investment too high, or creating undue upward pressure on operating expenses while your business is growing?
  • Was the reseller able to work competently with your management team to unlock "tribal knowledge" so that both you and the reseller's team were able to easily comprehend what was working and not working in your organization?
  • Did the reseller help you create a set of rational metrics by which to measure the success of your ongoing improvement efforts?
  • Were the reseller's consultants able to help you focus your efforts and investment on the critical areas that could and would lead to making your firm more profitable in the near term, or did they replace everything and hope for the best?
  • In short, do you feel like your organization is more profitable today – having engaged the reseller's team – than you were before?
  • Did the reseller leave you with something truly valuable to your organization other than hardware and software?

 

Asking questions like these would surely bring to light differences between those resellers and consultants engaged in traditional Everything Replacement Projects from those delivering value-based approaches like the New ERP – Extended Readiness for Profit.

 

[To be continued]

 

(c)2009, 2010 Richard D. Cushing

It is all academic

We have covered several aspects in the matter of developing a "requirements list" so far. (See prior posts.) Of course, whether you are developing your requirements list in-house or your firm is retaining as traditional Everything Replacement Project consultant to do it for you, it is entirely academic and suffers from the same bad assumptions and lack of focus.

 

As I am writing this, I have before me a real-life "Request for Information" (RFI) stemming from a real-life traditional Everything Replacement Project. This particular document presents 286 "requirements." Sadly, it is quite likely that the folks behind this RFI – because they are employing traditional ERP concepts and methods – have absolutely no idea which of these "requirements" reflects the small handful of things that will actually permit their organization to improve by increasing Throughput (T), reducing demand for new Investment (I), or cutting or holding the line on Operating Expenses (OE) as their firm grows. In fact, they probably "hope" – but cannot state with any certainty – that any of these requirements will actually aid the firm in growing beyond its natural trajectory as of today.

 

The danger of lack of focus

It is precisely this lack of focus as reflected in a 286-item "Requirements List" that drives firms to undertake an Everything Replacement Project rather than identifying and changing that very small number of things that will actually deliver results by permitting the firm to elevate or even break a constraint and, thus, to increase Throughput – or to make significant improvements in I or OE, for that matter.

 

The firm that unwisely elects to spend half-a-million dollars on an Everything Replacement Project when a more focused investment of some (likely, significantly) smaller amount would deliver effective and valuable improvement has wasted capital that it will never be able to reclaim.

 

The Everything Replacement Project approach is supported by the false underlying assumption that, if we just throw enough money and technology at our organization, our organization will somehow improve. As evidence, I quote a gentleman who once said to me the following regarding a time-consuming and costly implementation of SAP that he had ongoing in his organization: "We've spent so much money already, it's got to work." (Emphasis is his.)

 

This unfortunate lack of focus in a traditional Everything Replacement Project, is to be contrasted with the New ERP – Extended Readiness for Profit approach that we are introducing here. The New ERP encourages you and your management team to focus on "what needs to change" (by looking at the roots of your Current Reality Tree [CRT]) – that relatively small handful of things that will actually lead to measurable improvement. Then, and only then, should you take your precious cash and other resources to apply them in a focused way, knowing in advance the measurable outcomes you expect from each critical investment.

 

What does all this have to do with "software selection"?

While traditional Everything Replacement Project methods will have you and your organization searching for software (and, potentially, other technologies) to replace – well – "everything" based on the all too traditional "Requirements List," the focusing steps of the Extended Readiness for Profit method will direct your team to consider only those particular technologies that will actually lead to real and rapid improvement (read: return on investment). Rather than a shotgun approach – throwing time, energy, money and technology – at everything – the New ERP gives your management team the option to become sharpshooters for improvement and new profits.

 

The New ERP approach will

 

  • Conserve cash
  • Provide more targeted uses for capital
  • Avoid the waste of spending on IT projects that result in little or no real value-add to the "system" – the organization, as a whole

 

Going back to the example company (see early prior posts in this series), since the management team understands precisely "what needs to change" in order to improve the "system" – the organization – as a whole (namely, integrated bar code printing, integrated and automated ASN generation and transmission, and reducing or eliminating paper-based pick-pack-ship operations), they do not need to look at replacing everything. Rather, this wise team is prepared to turn to vendors and do "software selection" based on a very small domain of critical functions.

 

Rather than spending several hundreds of thousands of dollars on an Everything Replacement Project, our example team can set – as we previously described – a reasonable budget for the accomplishment of just the critical changes they have identified and for which they have already created measurable objectives.

 

[To be continued]

 

(c)2008, 2009 Richard D. Cushing

T-mobile's MyTouch 3G Fender Limited Edition Sells Out

 

This is an outstanding example of why lost sales due to out-of-stocks (OOS's) are generally under-estimated. Frequently, when estimating the damaging impact of lost sales from OOS's, managers and executives base their estimates on averages or slighted adjusted averages of the sales of other items -- especially similar (but, of course) necessarily different items.

 

The problem is companies invariably suffer the highest impact on OOS merchandise on the most popular items. Seldom to they suffer OOS's on mediocre sellers and almost never on the truly poor selling items.  However, if calculations of the impact are made from averages of other items, one may be almost certain that the impact of the lost sales will be under-estimated by a factor 2, 3, 5 or maybe even 10.

 

However, because the actual number can never be known, managers and executives are willing to live by their short-sighted estimates rather than make the investment to improve replenishment across their supply chain. They are willing to do so even though actually spending the money to accelerate replenishment might return profits of 2, 3, 5 or even 10-fold.

 

Think about it.

 

...

The software selection process

Actually, in this section, we will discuss the selection of any technology that your management team intends to deploy as part of your ongoing improvement process. Of course, that may include hardware, software, services and other infrastructure components. However, in order to keep the language simple – and because "software" is typically the focus of most technology acquisitions – we are going to use the term "software selection" to cover the entire gamut. We also engage the "software selection" to cover everything typically included in a traditional ERP – Everything Replacement Project effort because this is the term most often applied to the product selection phase.

 

Of course, in the traditional Everything Replacement Project approach, the "software selection" stage generally follows the "requirements gathering" work. However, since the traditional ERP approach to requirements gathering has so great a lack of focus on what will really help the organization (the "system") become more effective at increasing Throughput (T) and profit, employing the freshly generated "Requirements List" as a tool provides little in the way of value in the "software selection" process.

 

The consultant-assisted software selection

One of the possibilities that we did not mention earlier (see prior posts) when discussing the traditional Everything Replacement Project approach to requirements gathering is that the firm undertaking the traditional ERP may elect to hire a consultant to assist them. One of the big things that changes when a consultant schooled in traditional ERP comes to the helm is how thing happen.

 

You may recall that we sad when commencing an internal requirements gathering effort, the CEO or some other executive of the firm would announce to all that the firm is considering replacing its present accounting or ERP software and that, therefore, he wants each departmental silo to create a list of "requirements" for their particular functions. This process may be radically altered by the arrival of a traditional ERP consultant on the scene.

 

With a traditional ERP consultant ensconced in the organization, typically one of two paths will be followed:

 

Option 1

 

 

 

Of course, this dramatic departure from the simpler in-house approach we described earlier does one very important thing – it adds cost to the project while delivering (in most cases) little or no additional benefit to the organization. There are, however, two potentially redeeming reasons for involving the traditional ERP consultant:

 

  1. Doing so may free up time that could be used by executives and managers to deliver real benefit to the organization through increased Throughput or over value metric.

  2. The consultant, if she has been through this process before, may be able to shorten the "requirements gathering" process because, if you compare typical "requirements lists" across multiple and diverse organizations, at their core, these documents have more in common than they have diversity.

Option 2

 

 

 

The outstanding advantage of this approach is clear: You have no rank amateurs involved in creating your "requirements list." Instead, you have a professional "requirements list" developer hard at work and on your side. Permit me to give you some real life examples to show you just how much this might benefit your organization.

 

Requirement No. 1 as prepared by mere amateurs
"We need to be able to import and export data from the new software"

Requirement No. 1 as prepared by a real professional consultant
"Need ability to import and export data in a meaningful way…. Ability to export meaningful data to the reporting database"

 

 

 

Requirement No. 2 as prepared by mere amateurs
"We need a flexible chart of accounts"

Requirement No. 2 as prepared by a real professional consultant
"Flexible chart of accounts, such as multiple levels of accounts"

 

 

 

Requirement No. 3 as prepared by mere amateurs
"We need to be able to print production reports"

Requirement No. 3 as prepared by a real professional consultant
"Production reporting capabilities do exist"

 

 

 

From these few real life examples, I am certain that it is now abundantly clear to you how important it may be to the success of your firm that you not let amateurs entangle themselves in the complex task of "preparing requirements" – as the real pro's prefer to call it (as opposed to "requirements gathering"). After all, who wants to buy software that allows you to import or export "meaningless data" or to import or export "in a meaningless way"? Moreover, I am certain that every accountant knows the significance of the term "multiple levels of accounts" versus the crude description of simply needing "a flexible chart of accounts."

 

Nevertheless, like a late-night TV advertisement – Wait! There's more!

 

Without the advice of a real professional in traditional ERP, those responding during the traditional ERP "software selection" cycle might not have the opportunity to scale their responses. The following is an excerpt from a real life "Requirements Document":

 

Application Requirements

In each of the categories [in the Requirements List], please rate your software's capability to meet the requirement on a scale of 1-5:

 

  • 5 = the requirement is fully met in the base package
  • 4 = the requirement is 80% covered in the base package
  • 3 = the requirement is partially met or may require additional expense to purchase
  • 2 = the requirement can be met with light modification
  • 1 = the requirement is not met or would take significant (> 24 hours) effort to modify

There are several problems with this approach. The most glaring, of course, is that by reading a one or two sentence description of a "requirement," it is impossible to know what the requirement-writer envisions as to the precise form or function in question. Therefore, how is it possible to say at the requirement is "fully met" or the other scale metrics? And what, on earth, does it mean to meet a requirement "partially" or "80%"?

 

All too many times, a respondent to a "Requirements List" may say, "Yes"; but when it comes down to matching the software to the end-users expectations, there remains a great chasm yet to be bridged. For example, a vendor or reseller responding to "Requirements List" may answer with an honest "Yes," to a requirement that "a cash receipt from a customer may be applied to multiple customer invoices and memos." No deception is intended. However, the prospective end-user functions in a business where they must apply customer payments to accounts that may have several thousand open invoices at any one time. The end-user, in such a case, has one concept of how this function should work and it is likely that that vision does not align with the reality to be found in the software being offered by the vendor or reseller.

 

[To be continued]

What else might change the value proposition of a technology initiative?

We have already pointed out the foibles of the traditional "aim-and-shoot" approach to IT initiatives and their proclivity toward considering every matter in terms of "cost," rather than "value." (See prior post in this series.) We even pointed out some of the factors that may change the value proposition for an IT initiative well after the project launch. But, what else might have an effect on the value proposition of an IT project aimed at "improving" a company like yours?

 

Earlier we mentioned things like the introduction of new products, changes in the economy, or even public policy changes that might change the value proposition for a technology deployment. Now, however, we need to turn our eye to technology-specific elements that might also affect the value proposition of a project already underway.

 

I am not sure why, but my more than 25 years in dealing with business technologies has clearly proven to me that firms reaching out to make technology purchases assume (far too frequently) some measure of clairvoyance on the part of their technology vendors. It is clear, and the purchasing companies' management teams seem to recognize, that they cannot know everything there is to know about the technology they are buying. However, that same management team will somehow come to the tacit conclusion that the technology vendor must know and understand all there is to know about the company that wishes to buy and deploy their technology.

 

Okay! Maybe I'm exaggerating; but just a tiny bit.

 

The managers on the buying side may not actually assume that the vendor's team understands or knows everything about the buying company's firm and operations, but they generally do assume that the vendor's team knows and understands enough about the prospective purchaser's company and operations to ask every possible question in order to assure that every facet of the product or services provided will fit precisely the customer's expectations. Never mind that "expectations" are never plainly visible to either party in the transaction. Expectations far transcend anything placed in any agreement or "requirements" document. Expectations may be reduced to the number of mouse-clicks it takes to navigate a certain transaction, or the "look-and-feel" of screens, or where data is placed in the user interface. The list of expectations is, literally, without end. In fact, the purchasers themselves may not know or be able to articulate their expectations. They only know when their expectations have not been met.

 

The point is this: As a buyer, you and your management team need to recognize that, when first engaging a technology vendor, the vendor knows proportionately as little about every facet and detail of your enterprise as you know about every facet and detail of their technology and services. In essence, you have witnessed "a demo" of their technology and they have experienced "a demo" of what your company is like. Therefore, it is incumbent upon you, as the buyer, to beware – caveat emptor. You and your team must thoroughly and precisely know what you want and need the technology vendor to do in order to effect the change you have in mind – the change derived from your Current Reality Tree that will help your company reach more of its goal of making more money.

 

At this point, an "on the other hand" would be nice to hear. Am I right?

 

On the other hand, there actually is an upside to this mutual blindness between technology seller and technology buyer. Frequently I have experienced situations where, as the vendor and the buyer learned more about each other's technologies (on the one side) and operational requirements (on the other), fresh new insights emerged about how the buying firm could leverage to great advantage previously undisclosed features or functions in the technology. A management team employing the value-based New ERP approach can readily see that the presence of some unanticipated feature, function or capability might radically increase the value proposition to the organization. Unfortunately, this kind of value serendipity is sometimes missed entirely by tradition-bound managers and vendors totally enmeshed in "meeting documented requirements," deadlines and budgets.

 

[To be continued]

 

©2008, 2009 Richard D. Cushing

Getting to the "system" view of technology deployment projects (continued)

Sometimes there is an even a selfish motive lurking beneath the surface of one applying the traditional approach to IT deployment projects. If the organization – whether it be your own organization, or the vendor's or reseller's – rewards those responsible for IT implementations based on their projects being on-time or on-budget rather than basing rewards on the value returned to the target organization as measured in terms of beneficial changes in Throughput (T), Investment (I) or Operating Expenses (OE), then it is not only possible, it is highly likely that there is a personal and selfish motive to how these managers plan and implement.

 

Now, I am by no means suggesting that managers of IT deployment should be frivolous in the treatment of available time or funds for project completion. Far from it, for from a "system" improvement point of view, delays mean reduced Throughput and additional money carelessly spent on an IT project drives Investment higher. Both of these are absolutely negative in my view.

 

However, what I am saying is, executives and managers holding only a cost-world view of the IT deployments will likely miss opportunities to produce even better results (in terms of T, I and OE) if they hold to the traditional aim-and-shoot approach.

 

The holistic value-view of technology projects

A management team with a holistic value-view of any change involving technologies should hold a much different view of the one we have described (in Part 20 and above) as the traditional IT project view. If your managers, vendors or resellers want to participate as an active partner with you in an Extended Readiness for Profit – the New ERP program, they need to have a clear understanding of all of the tools that have brought you and your team up to this point. They need a clear framework through which to view and understand what is happening across all of the departmental silos in your organization. In short, they need to understand have a "system" view, not a departmental or functional view. Working through your Current Reality Tree (CRT) with these stakeholders in your project's success should help them gain this essential footing and view.

 

 

 

Next, since (hopefully) no one on the project team is relying upon a set of nearly meaningless "requirements" prepared either by internal silos or external consultants, each of the team leaders should have a clear set of measurable objectives with regard to any initiative being undertaken. (A clear and measurable objective might be: "To increase the number of shipments able to be picked, packed and shipped from the current 20 per hour to a minimum of 40 per hour at current staffing levels.") These participants will know precisely how much a specific IT initiative is to deliver in terms of increased T or reduced OE. There is no guesswork about value creation under the New ERP – Extended Readiness for Profit approach.

 

Armed with a clear, controlling framework and measurable objectives for the IT initiative at hand, such managers are armed and able to make effective value-based judgments throughout the entire duration of the project. The reasons this is necessary are several:

 

  • "Today" – whatever day that is in the project – the managers have learned something they did not know "yesterday" that will affect delivered value

  • "Today" – whatever day that is in the project lifecycle – the managers do not know some things that they will learn "tomorrow," and these unknowns may also affect the value proposition of the project

  • Making changes in the immediate future (say, within a week, or a month, depending on the project) to the technology is very likely more difficult and more costly that making the same changes at some later date (the increased costs and difficulty being caused by factors such as lack of time for planning, current workloads, potential overtime pay requirements)

  • Having the liberty to make changes incrementally into the future, as the value proposition changes and unfolds, allows the managers to guide the overall IT project to the highest value optimized against the lowest total cost of ownership (TCO)

This is really where the traditional approach falls down so dramatically. If the IT initiative under consideration is going to last more than 30 or 45 days, it is almost a certainty that something will change – or something not changed, but only lately coming to light for consideration – that will affect the value proposition of the proposed deployment. New products are introduced – if not by your company, then by your competitors or your suppliers. Changes in the economy or public policy may affect the way or with whom you can or must do business. These and likely some 10,000 other factors could change the value proposition of the IT project that is underway.

 

This means that the "target" that you and your team were originally aiming for on Day One of the project may not be the target you really want to hit on your scheduled completion date. The value-based manager is prepared to take those revelations in stride and to make effective adjustments as soon as new estimates of T, I and OE can be made. (And, if you recall from our earlier posts, estimates of T, I and OE can be done pretty rapidly meaning no paralysis by analysis for the team.) Then, the team will apply the simple formulas we have previous supplied using the new estimates:

 

Benefit ($) = delta-T – delta-OE

 

Or

 

ROI = (delta-T – delta-OE)/delta-I

 

The value-based manager should always understand that the value he beholds today in any given improvement initiative (technology-based or not) may not be the value of the same initiative tomorrow. The further into the future the manager tries to see, the less certainty there is that today's value proposition will still hold true.

 

[To be continued]

Getting to the "system" view of the organization

We will talk more about this when we get to the matter of customizations and modifications; however, if the organization is brought together to see that what is needed is an improvement in the effectiveness of the whole organization – i.e., the "system" – in order to achieve more of the goal of making more money, then many of the petty so-called "requirements" may quite naturally fall away.

 

When I am applying the New ERP – Extended Readiness for Profit with my clients, I frequently have a very frank discussion with the management team about our holist (or "system") view of the organization. In the course of these discussions, I try to point out that, in general, the goal of any improvement is to achieve at least one of the following three things for the whole system:

 

  1. Increase Throughput (T)
  2. Reduce Inventories or demands for new Investment (I)
  3. Cut or hold the line on Operating Expenses (OE) while sustaining substantial growth

The caveat to that statement is that achieving that end as the result of any given change in the system (i.e., the organization) will not necessarily mean that the level of effort in every functional area will be decreased. In fact, although it is rare, it is possible that a change may lead to some increase in level of effort in a department or departments that already have excess capacity.

 

I find that, if the executive management team has created and has a full understanding of the impact of their own Current Reality Tree (CRT) – and maybe a Transition Tree (TrT) – the executives' use of the CRT (and TrT) in explaining what needs to change and why to the whole organization usually results in excellent buy-in on the matter of any workload redistribution that may result.

 

Getting to the "system" view of technology deployment projects

While we are on the subject of seeing your organization as a "system" – that is, from a holist point of view – we want to compare another important difference between the traditional – Everything Replacement Project approach to technology deployments with the approach we take with the New ERP – Extended Readiness for Profit.

 

The traditional method applied in most IT deployments under management internally or by vendors or resellers is what we call the aim-and-shoot approach. In a (usually vain) effort to minimize risk, the general concept is to get all the details "nailed down" before management turns vendors and resources loose on the work. Executives and managers who hold to this approach sincerely believe that they are acting in the best interests of their firm. Managers from vendors and resellers also generally hold with all sincerity that this approach is the "safest," if nothing else. But let us take a look at just what risk it is that this approach seeks to minimize.

 

 

 

As we said, the way the traditional approach is formulated, the project leadership attempts to "nail down" or "cast in concrete" all the pertinent details as early in the project as possible. Frequently, executives and managers on both sides try to get every detail settled before the final agreement is signed for services. From that point, their thinking is, all they have to do is follow what has been defined to the letter and they will hit their "target" of success at the end of the project.

 

It is possible that taking this approach minimizes the risk of cost-overruns. (Although, there is a virtual plethora of data available from the experience of thousands of companies over the last 25 years that militates strongly against this concept that this approach actually does reduce the frequency or size of cost-overruns.) More importantly, however, is the very fact that applying the term "cost-overrun" strongly suggests that the project is being measured solely by "cost" and not by "value delivered." Rather than thinking about the value created through increasing T, or reducing I or OE (if you don't know what T, I and OE mean, yet, then go back and read some earlier posts in this series), such managers and executives can conceive of no concept greater than "cost" by which to set goals and measure "success."

 

Let me assert right now: Any project that is ON-TIME, ON-BUDGET, and of HIGH QUALITY is still a failure – not a "success" – if it fails to increase the system's production of T, or fails to reduce the system's values of I or OE while sustaining significant growth.

[To be continued]

Another reason traditional "requirements gathering" approaches may be unnecessary

As we have already discussed (see prior posts in this series), some of the reasons that traditional ERP – Everything Replacement Project approaches to "requirements gathering" – whether internal or as performed by a vendor or VAR (value-added reseller) – fail to deliver real value or results for the organization purchasing new technologies. Now we want to turn our attention to one other matter that we believe will help you see why traditional approaches to "requirements gathering" may be a huge waste of time, energy and (in some cases) money.

 

Think back to the scenario we described (in a prior post) where some executive makes the announcement regarding his firm's intent to replace their existing ERP software, sending off silo leaders to develop a list of "requirements." Two or three weeks later the firm has assembled a list of 300 or so "requirements."

 

Unless the organization is very unusual, the truth is that more than 80 percent of the typical "requirements list" contents will be found in some form or other in almost all of the contending software packages to be considered. In the middle market – software designed for small- to mid-sized businesses – there are far more similarities in features and functions across the different packages than there are differences. Furthermore, most of the distinctions (i.e., differences) between the most common competitors in mid-market ERP are to be found around the edges of the application software, not in its core functions. For this reason, it is quite likely that about 80% of the "requirements" collected will be present and therefore little value was added to the process by collecting and documenting such "requirements."

 

Next, it is worth noting that many of the so-called "requirements" listed by staff from the various organizational silos will not be genuine "requirements" at all. Many so-called "requirements" will be nothing more than what the silo staff is used to in their existing software application. Stating these as "requirements" merely fixes in the mind of staffers from the various functional silos that they can and will all get a relatively precise duplication of existing functions plus added features in their functional domains. This sets many wrong expectations and may lead to demands for modifications and customizations where, in a more open-minded environment, adaptation to new methods or processes would have been perfectly acceptable or even an improvement in itself. Never mind whether any of these now cast-in-concrete "requirements" will actually have any effect on increasing Throughput (T), reducing Inventories or demand for new Investment (I), or cut or hold the line on Operating Expenses (OE) while allowing the firm to sustain significant growth.

 

[To be continued]

Post-sales requirements gathering

As we continue our review of traditional ERP – Everything Replacement Project methods and processes, while comparing them to the New ERP – Extended Readiness for Profit, we have been discussing the various aspects of "requirements gathering." So far we have covered both in-house and pre-sales requirements gathering. However, even if one or, indeed, both of the preceding forms of "requirements gathering" have been performed, it is not at all unusual for yet another aspect of "requirements gathering" to be done following the close of the software sale. We refer to this, naturally, as post-sales requirements gathering.

 

Many technology vendors and value-added resellers (VARs) maintain a process that looks something like this:

 

 

 

What's wrong with this picture?

 

The problem is that, most likely, it was the salespeople that did the pre-sales high-level requirements gathering. Then, they sold your company the technology!

 

Now, after you and your organization have already made what is probably a non-refundable purchase commitment of their technology, the vendor is sending in the people that really know whether the technology is "a good fit" for your specific organization and its application of it. Only now are they discovering your real and practical requirements.

 

Of course, the vendor's technical team's analysis will still not be based on a holistic view of your organization – they will not be looking at your entire organization as a "system." They will be looking at individual organizational silos and functional areas, frequently assigning different personnel to oversee "requirements gathering" in the different silos. Supposedly, this is to make things "better," because the different persons will each be "specialists" in their respective assignments. But, if they are like far too many vendors and resellers, no one has the training or experience to really see how your organization functions as an integrated "system" or "chain" of dependent events and actions. Thus, their "requirements gathering" will also fail to seek out and discover how to optimize the "system" in order to help your organization achieve more of its goal to make more money tomorrow and in the future.

 

In the best-case scenario, this post-sales "requirements gathering" process will stumble upon one or more of the things that must change to increase Throughput (T), reduce Inventory or demand for new Investment (I), or hold the line on Operating Expenses (OE) while permitting your organization to sustain substantial growth. Absent a holistic – a "system" view and theory – this new "requirements gathering" team will still be operating entirely under the assumption that if, in the Everything Replacement Project, they improve every functional area or even some functional areas as a result, the whole organization will benefit and be more successful at achieving its goal. As we have seen, since an organization is a "chain," only strengthening the weakest link will improve the organization as a whole. Time, money and energy spent elsewhere are substantially wasted.

 

That was the good news. Here's the bad news:

 

In the worst-case scenario, this new "requirements gathering" team will complete their more detailed "requirements gathering" and determine that, yes, they can make the technology that you have already purchased "fit" your firm's "requirements," but it is going to take a whole lot more time and money than you and your management team had anticipated. But, what can you do? You've already made an irrevocable commitment to purchase the vendor's technology.

 

If your team has been working along with us up to this point, you may have recognized that the work you have done in creating your own Current Reality Tree (CRT) and the analysis of the "roots" of your CRT was your "requirements gathering." If you have done your work correctly and effectively, you already know the critical requirements you must address with technology (where it applies). In the example company we have been using (see prior posts), the management team has already identified (among others) the following critical requirements that will require technological support in order to improve the performance of the whole "system":

 

  1. Integrated bar code printing
  2. Integrated ASN (advanced shipping notice) generation and processing
  3. Reduction or elimination of paper-based picking and shipping processes

Our example firm's management team is already well prepared to seek from vendors and resellers specific and targeted "requirements" focused on the specific and targeted functions that must be improved (changed) to increase Throughput (T), reduce Inventories or the demand for new Investment (I), or slash or hold the line on Operating Expenses while sustaining substantial growth. They do not feel the need to do an Everything Replacement Project – traditional ERP, because they are already well aware of the few and limited things that need to change to bring effective improvement in moving toward their goal of making more money.

 

[To be continued]