Skip navigation
2010

Requirements Gathering

Now, let us consider some of the other aspects of what the management team from another firm that is following the traditional ERP – Everything Replacement Project model. One of those, of course, would be the standard "requirements gathering" effort.

 

In the traditional ERP – Everything Replacement Project, most organizations go through some form of requirements gathering. The method may vary and, in fact, may happen multiple times over the life of a single project. Here are some typical ways in which requirements gathering may be carried out.

 

In-House Requirements Gathering

The leadership in an organization that is considering an Everything Replacement Project (traditional ERP) may decide to do their own requirements gathering. If they do, this typically entails senior management announcing to functional managers all across the organizational silos that the firm is thinking about replacing their ERP software. "Therefore," the executives opine, "management needs to have each silo create a list of all the features and functions that they believe will be 'required' (hence the term: 'requirements gathering') in the new software."

 

The silos may also be at liberty to add to the "requirements list" features or functions that are, in fact, not requirements at all. We know that they are not requirements because these features and functions are to be specifically designated with some useful term such as "Nice-to-haves" or "Wish list items."

 

Even the "requirements" (so-called) may not necessarily be actual requirements. (This gets confusing, does it not?) In some organizations, the silos may be permitted to "rank" requirements in a "1-2-3" fashion. By this the organization intends to suggest that everything on the "Requirements List" with a ranking of "1" is a real and actual "requirement." Items with rankings of "2" or "3" are sort of "requirements – if we can get them and they don't cost too much."

 

So, what is the problem with this approach?

Let us assume that your organization has ten departmental silos and each of these silos comes up with 30 "requirements." Forget about whether these are real requirements or just maybe requirements.

 

You and your management team now have a list of 10 times 30, or 300, "requirements." However, the list, by itself, assumes that each "requirement" bears an equal responsibility for aiding the organization in effectively reaching its goal of making more money tomorrow than it is making today. No manager or executive can look at the list and empirically assign priorities based on the dollar-benefits or ROI of having or not having each one of the 300 so-called "requirements."

 

To make matters worse, since ERP software today is more alike than it is different in most aspects of its functionality – that is to say, the genuine differences between ERP applications today are found around the edges and not at the core – a good many of the 300 "requirements" that have been diligently gathered by the organization will likely exist (in one form or another) in almost every competing product. That may mean that only ten percent (say, 30 of the 300) really have any significance in the search for a product in the traditional Everything Replacement Project.

 

Next, consider the fact that the very nature of the announcement from the executives that each silo was to submit a list of "requirements" suggests that the management team holds to the concept that improvement anywhere in the organization will somehow improve the "system" (i.e., the organization) as a whole. This is a false assumption. As we have previously stated: Only improvement in the weakest link will strengthen a chain – and your organization is "chain" of dependent functions.

 

Of course, the management team could be admitting something even worse. They could be admitting that they really don't intend to improve everything, because we really don't know what to change to bring effective improvement or how to reach more of their goal. So, instead, they are going to undertake an Everything Replacement Project – yanking everything out and replacing it with "new and improved" – in the hope that, in the end, they get better results. Such "hope" is not a strategy.

 

While it is true that some silo-based changes may contribute to some positive aspect changes within an organization, that is not what should be of concern to an executive management team. What executive management should be concerned with is this: What few things need to change in our organization in order to effectively increase Throughput (T), decrease Inventories or drive down or out demand for new Investment (I), and reduce or hold the line on Operating Expenses (OE) while the firm grows?

 

By now you may have recognized that by using the Current Reality Tree (CRT – see prior posts) from the Thinking Processes, the real and practical "requirements" that will have an immediate effect on T, I and OE are made plainly evident in the roots of the tree. That is a key and critical difference between the traditional ERP – Everything Replacement Project approach and the New ERP – Extended Readiness for Profit program.

 

[To be continued]

RDCushing

The New ERP - Part 15

Posted by RDCushing Jan 25, 2010

Setting priorities

If you and your management team have been working along with this series on The New ERP – Extended Readiness for Profit, then you have already created your organization's CRT (Current Reality Tree) and discovered what needs to change. Also, you have determined some potential courses of action – some answers to what the change should look like and how to effect the change – based on the roots found in your CRT. Now it is time to start setting priorities between the options that lay before you.

 

As we pointed out earlier, your organization's "bottleneck" is the choke-point in your system that reduces the flow of Throughput (T) into your organization. If you have identified your "bottleneck" or constraint, then you should always address your constraint first. In effect, you want to strengthen the weakest link in your chain of Throughput-producing functions. However, how should you and your management team prioritize multiple improvement projects that may each lead to improvement in organization's "bottleneck"?

 

There are two basic formulas to apply in making such evaluations and setting priorities. For proposed initiatives that require no additional investment (I), simply comparing the Benefit value is generally sufficient, and the following formula should be applied:

 

Pre-Tax Profit = delta-T – delta-OE

Where, T = Throughput (Revenues less Truly Variable Costs)

OE = Operating Expenses

 

Where additional Investment (I) is required to make the proposed changes, then apply this formula:

 

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

Where, I = Investment

(including increases or decreases in inventories)

 

[Also, see definitions in Part 1 of this series.]

 

You will undoubtedly notice that the value of "Benefit ($)" is nothing more than the top portion of the "ROI" calculation formula. Therefore, while initiative-specific ROIs may be calculated only for those changes that will require a change in Investment (i.e., delta-I is not zero), the "Benefit ($)" value for any number of change initiatives may be compared. (This is also true for the Net Present Value [NPV] of the estimated multi-year series of "Benefit ($)" calculations for an array of different proposed initiatives.)

 

Once your team has calculated the Benefit or ROI, or both, for the potential change initiatives suggested by the analysis stemming from your Current Reality Tree, you can then set them in priority order. Those initiatives that reap the greatest estimated "Benefit ($)" or greatest relative ROI should be undertaken first, then the initiatives that produce lesser values may be considered for action.

 

My recommendation, however, is that before your team takes on subsequent improvement projects, they should reassess the Current Reality Tree to be certain that changes made in prior initiatives did not have unexpected affects that change other aspects of your reality. Addressing new or slightly different roots may be required, or perhaps you will discover that having dealt effectively with one root, your system has reaped unexpected positive results in other areas, as well.

 

[To be continued]

Compare with Traditional ERP – the Everything Replacement Project – approach

Let us stop to compare where our management team is now in its decision-making process with what an organization that embraces traditional ERP – the Everything Replacement Project – might be going through in their processes.

 

How do most small- to mid-sized businesses go about setting budgets for their major or minor IT initiatives? We will take a look at a few of the methods I have run into over the years:

 

  • Don't set a budget: Far too many firms simply find out what the executives and managers think needs to be done, and then get quotes from some vendors or resellers on what it will cost. This gives them the "cost" – assuming it is accurate, but many times it is not. As for "benefits," may management teams just "expect improvement" in some unquantified and unquantifiable way. They don't have a "budget" and they don't have an "ROI." Furthermore, they generally don't measure the results of "improvement" afterwards either.

 

  • Educated "guess": In such cases, frequently the CFO, the president, or someone from IT is simply asked to "put together some numbers." Frequently, these almost exclusively "cost" numbers come from telephone conversations with vendors or resellers, Internet searches, or conversations with people from other companies that have done something similar. Again, in far too many cases, the management team does not even attempt to quantify the "benefits" or calculate an ROI for the proposed initiative.

  • How much can we afford? Naturally, this attempt at "budget"-setting comes directly from cost-world thinking and entirely neglects the fact that, if the organization is going to see no increase in Throughput (T), no decrease in Inventory or Investment demands (I), and no significant decrease or future savings in Operating Expenses (OE), then the budget that should be assigned to the project is zero-dollars.

  • Find out: This approach is almost equivalent to "Don't set a budget" above inasmuch as the method (if you can call it that) amounts to "finding out" how much an Everything Replacement Project will cost, then factoring it for "overruns," which have come to be expected in the industry. Again, this approach has no bearing on the value the traditional ERP project will bring to the organization, only the anticipated "cost" to the firm accompanied (frequently) by only the vaguest of notions as to how the change will actually increase Throughput (T), or reduce Inventories or demand for new Investment (I), or drive-down or hold the line on Operating Expenses (OE) while sustaining growth. Unfortunately, often times even the "growth" itself is merely assumed.

  • Comparatives: This approach is simply a variation on "Don't set a budget" or the "Educated 'guess'" methods. Here the way it's done is to get the CEO or other executives to ask their golfing buddies or other industry friends (and maybe even relatives) how much their companies paid for their last Everything Replacement Project. Once again, no focus is placed on specific areas of improvement and the far too frequently the estimates of "benefits" and "ROI" are vague – to say the least.

Now, I know you probably laughed out loud (or at least chuckled to yourself) when you read some of the above "methods." The fact is, it is funny to read these when the truth is laid out in some embarrassingly plain language. However, as sad as it may be, many of the budgets for IT initiatives I have run into over the years have no more substantial basis in reality or value for the enterprise what I have described above.

 

Of course, given the scenario for "budget setting," it can hardly be a surprise to find that many owners, executives and managers make many, many wrong decisions about what kinds of investments their firms should make in information technologies – or other improvement efforts, for that matter. They also frequently make wrong decisions regarding how much to spend on improvements in any given functional area, since they are quite often at a loss to link daily execution improvements with financial results.

 

By the way, as you can see from the approach we have laid out in our radically new Extended Readiness for Profit – the New ERP, it may be as foolish for a CEO to under-invest in technology (or other improvements) – because she does not understand the dollar-benefits that would be delivered by such investments – as it is to over-spend on technologies. (Here I draw the clear distinction between investing and spending. An organization is investing if they have calculated the benefit relative to the expenditure; whereas, an organization is only spending if they have not calculated the benefit relative to the expenditure or no actual increase in Throughput, reduction in other Investment, or decrease in Operating Expenses will likely result from the expenditure of time, energy and money.) Either way, the CEO is probably doing long-term damage to her own organization – making it less capable, not more capable, of delivering more profit today and in the future.

 

This clearly highlights the value of the Current Reality Tree (CRT) (see prior posts) in helping your management team identify "what needs to change" before taking any steps toward assuming that new technology – applied in a general way – will deliver some general, but unquantifiable, benefit to your organization.

 

If you and your management team are following along in our Extended Readiness for Profit – the New ERP approach for your own organization, then you now need to take some time to calculate the values for the changes in T, I, and OE with regard to the actions you may have under consideration – whether they are technology-related or not. Your proposed actions, of course, should be based on the findings at the roots of your CRT. (For those of you just catching up, you will probably need to go back and read prior posts on The New ERP.)

 

[To be continued]

 

(c)2009, 2010 Richard D. Cushing - all rights reserved

Calculating an ROI for a specific improvement initiative

Here is something that is rarely done effectively in preparing for traditional ERP – an Everything Replacement Project: our management team at the example company (see prior posts) now has everything it needs to calculate ROI for the specific warehouse and pick-ship initiative they have under consideration. Here is the formula they will apply:

 

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

 

Where T = Throughput
OE = Operating Expenses
I = Investment

 

Substituting into this formula the numbers calculate by the team (see prior post), we get:

 

ROI = $0 – (-$168,942)/$75,000 = 225.3% in the first year

 

"But," you say, "this company will not experience the full $168,942 in savings in the first year!" And, of course, you are correct. The management team recognizes this also. So, they quickly do some "napkin" calculations and estimate that, as revenues grow, they may reap about 40% of the calculated annual savings through deferred hiring of additional FTEs (full-time equivalents) in the first 12 months following the implementation. This means our first-year calculations need to be adjusted as follows:

 

ROI (first year) = (0.4 * $168,942)/$75,000 = 90.1% ROI in the first year

 

What these calculations tell the management team is this: "If we invest up to $75,000 in an initiative to improve processes highlighted by our Current Reality Tree (CRT) (see prior posts) in the areas of bar code printing, ASN (advanced shipping notice) processing, and picking-shipping operations; and our Throughput continues to grow; then we ought to see about 90% of the money invested in this initiative returned in savings to the organization within the first 12 months following deployment." (Note: The real firm upon which this scenario is predicated had been experiencing double-digit growth in sales for more than five consecutive years when I was introduced to them.)

 

This also tells the team that, in subsequent full years, since no additional investment is required (unless they should wish to capitalize some portion of the software maintenance), the company should continue to reap about $169,000 in annual savings as a reward for this effort. (Note: If anyone wishes to extrapolate further from these figures, it would be possible to calculate the Net Present Value [NPV] of the series of estimated cash flows resulting from this or any other particular Extended Readiness for Profit – the New ERP – initiative. While this is not generally required for initial decision-making, the true value of the initiative – and, indeed, the value of the firm as a whole – is best represented by the NPV of "the system.")

 

[To be continued]

Jeepers! Creepers! Where'd you get those numbers?

In the last post, I said that the management team in our unnamed example company had estimated the following for a change proposed in their warehousing operations:

  • Change in Throughput (delta-T) = $0
  • Change in Operating Expenses (delta-OE) = $168,942
  • Change in Inventory/Investment (delta-I) = $75,000

 

Let us now take a look at a relatively quick way to get to numbers such as these without suffering paralysis by analysis.

One shorthand way to estimate changes in OE is the use of the value of a typical or average FTE (full-time equivalent) in the department or area being affected. This effective and rational method allows us to create estimates of potential savings (or added costs, if that be the case) even if no actual employees are going to be laid off or hired as a result of the proposed change. Here is how: While firms seldom layoff employees as a result of process improvements – and we highly endorse such acts of employee retention – if the firm is focused first and most importantly on increasing Throughput (T), the organization will actually experience these savings over time by being able to support growth in Throughput of 30%, 60% or even 100% or more without adding to Operating Expenses by forestalling the hiring of additional personnel.

 

So, here's how our example company's team calculated FTE values for their warehouse operations:

 

By extrapolating from this calculated FTE value ($49,686), here is how the management team took the next step to estimate annualized savings from the proposed changes in the warehouse and picking-shipping operations:

At this point, our example management team also made an arbitrary decision. They established a preliminary investment budget of $75,000 to cover the cost of technologies to provide (at a minimum) the three critical functions of:

 

  1. Integrated bar code printing

  2. Integrated ASN processing, and

  3. Paperless (or near paperless) picking and shipping operations

Since our management team has no predisposition for an Everything Replacement Project (traditional ERP), they have many options open to them. They are focusing solely on Extended Readiness for Profit – my radical new approach to ERP. Therefore, they could take advantage of any one or more of the following courses of action:

 

  • Develop integrations between existing bar code applications and their inventory management software. Most of the better bar code applications on the market today already provide APIs (application program interfaces) and ODBC (open database connectivity). These capabilities would help keep the cost of development reasonably low and permit relatively easy and low-cost changes as demands on the organization change over time.

  • Purchase and integrate an EDI (electronic data interchange) engine with their existing inventory management and sales order processing software in order to generate and deliver ASNs (advanced shipping notices) for them. This project would have to be coordinated with the solution chosen to handle the paperless picking and shipping operations, however.

  • Acquire a paperless shipping and manifesting application and leverage its APIs to integrate it with the firms existing inventory and sales processing application. They might even hit the jackpot and discover a shipping and manifesting solution that includes ASN processing as part of the package, or has already been successfully integrated with their existing inventory and sales processing application.

  • Roll their $75,000 budget into a large project that may be part of replacing an existing inventory or sales processing application.

If they choose the last option, they should still predicate their purchase and implementation budget on the sum total of all measurable improvements and savings anticipated from all outcomes when compared to their Current Reality Tree (CRT). They should not arbitrarily throw money into the budget "kitty" based on some vague feeling that "more technology" or "newer technology" will automatically make the organization more profitable or stop losses. That is to say, never substitute a traditional ERP (Everything Replacement Project) for a focused and measurable Extended Readiness for Profit (the New ERP) program.

[To be continued]

Evaluating alternatives

Based on the management team's analysis in our example company (see prior posts in this series), they have come to the conclusion that their system's current "bottleneck" – or, constraint – is in their pick-pack-ship operations. Since they have already agreed that there are so many crossovers in personnel and functions between general warehousing operations and picking-shipping, they are going to consider CRT roots 1, 2 and 5 together.

 

This makes a lot of sense inasmuch as any technology that might be applied to the warehouse is likely to include functionality that will supplement multiple areas. The areas of concern, as determined by the CRT roots, are:

  • Integrated bar code labeling

  • Integrated ASN generation

  • Reduction or elimination of paper-based processing of picking, packing and shipping operations

Using this list of critical factors generated directly from the organization's CRT, the management team knows already "what needs to change" and, by implication, the key functions that any technology must supply to help the organization actually move toward increasing Throughput while holding the line (or maybe, cutting) Operating Expenses.

 

While intuition alone might bring some organizations to this point, if the management team has not documented (I mean literally written down) the logic that brought them to these decisions, they are in a far poor position to evaluate the failure or success of any implemented changes that may flow from their decisions. (It is beyond the scope of this present discussion to cover these matters in more detail, it is at this point that other Thinking Processes tools – like the Transition Tree and Future Reality Tree – might be applied by our example company's management team to determine what the change(s) should look like and how to effect the change(s) required.) This means, of course, that if the team were to take the approach of Traditional ERP – an Everything Replacement Project – it is quite likely that the project will lose focus and end up not having metrics by which to guide decision-making or measure success or failure.

 

Taking the next step of putting numbers to their intuition and the logic they have mapped out using the Thinking Processes will further sharpen the focus of the management team. Here is one way they might go about developing metrics around the proposed changes.

In order to begin, the team will need to come up with valid numbers related to two factors: If they make the proposed changes by applying new or expanded technologies in their warehousing and shipping operations, how much more Throughput (T) will they be able to support while holding the line on Operating Expenses (OE)? Of course, they already know the key features that they are looking for in their search for supporting technologies, too. These were identified also by the Current Reality Tree (CRT): 1) integrated bar code labeling, 2) integrated ASN generation, and 3) reduction or elimination of paper-based processing.

 

These folks are already far ahead of any company that has started their search for a new ERP system by the traditional "requirements gathering" from all the departments. Plus, they are looking only at creating an Extended Readiness for Profit (the New ERP) by focused technology selection and deployment, not the wholesale approach that comes with traditional ERP – an Everything Replacement Project.

 

Well, this firm's management team is as honest as the day is long! So, even though they realize that the improvements they propose in the warehouse and shipping operations will allow these departments to support dramatic increases in Throughput, none of the changes being made will actually add Throughput to operations. They acknowledge that they are already getting almost every shipment out the door every day. The problem is that they are doing it using extra personnel and a lot of overtime. Of course, all that falls under the category of Operating Expenses.

 

The management team thus concludes the following:

  • delta-T = $0
  • delta-OE = $168,942 per year
  • delta-I = $75,000

 

I hear you ask: "Where did they ever come up with numbers like those?"

 

[To be continued]

Setting priorities in The New ERP

 

So, how does the Thinking Processes and the Current Reality Tree (CRT) we've just built tie in with ERP decision-making?

 

Well, let us imagine a firm (taken from an actual case) that has completed their first CRT and they have at the root of their tree the following entities:

 

  1.     Non-integrated software applications are used to generate bar codes for various purposes
  2.     An ASN (advanced shipping notice) cannot be automatically processed by existing systems
  3.     Production schedules are created and maintained in Microsoft Excel rather than in an integrated data environment
  4.     Manual flags must be set in our contact management system if a sales order goes on hold for any reason
  5.     Order processing documents are presently reproduced in multiple copies for distribution on paper to various parties and departments
  6.     Data in existing software applications (e.g., Purchase Order expected receipt dates) are unreliable

 

By following this firm's relatively complex CRT to the top of the tree, the management team is able to see that their current reality is driving Operating Expenses (OE) that are too high – growing at a faster rate than Revenues or Throughput (T). They are also experiencing higher than desired Inventory levels, and since carrying costs for Inventory contribute to Operating Expenses, excess inventory is a double-whammy – putting upward pressure on Operating Expenses, as well. Of course, higher Operating Expenses lead to a lower NPBT (net profit before taxes). The management team also recognizes that much of the fire-fighting they have been doing over the last years – caused by their treating UDEs as "problems" and a failure to manage their organization as a "system" – has limited the time, money and energy available to spend on new business development. Therefore, they see that they have actually missed out on potential growth opportunities – thus reducing Throughput.

 

Our company's management team now turns to reviewing the several "roots" and they determine the following:

 

  • Roots 1, 2 and 5 predominantly affect the warehouse and shipping department. In this particular case, many of the functions between warehouse operations and shipping overlap, so these will be considered together.

 

  • Root number 6 is also a warehouse issue, but it affects receiving and there are separate people who handle that function. Therefore, this root will be evaluated separately.

 

  • Root number 3 primarily affects the Production Management Team – a group of people that work together to try to keep the work flowing through the factory as smoothly as possible. However, it also has some implications for sales ("If I take a big order, what date can I promise to my customer for shipment?") and for customer service, too ("What's the status on the production of the products for order number N that's supposed to ship tomorrow?").

 

  • Root number 4 affects accounts receivable personnel, who must notify the appropriate customer service people whenever an order goes on hold. There are also other functional areas that must be aware of potentially delayed orders and must guard against accidentally releasing an order that should not be shipped. It gets complex quickly.

 

Finding your "bottleneck"

 

In The Goal, Eliyahu Goldratt points out that any "system" or organization is like a "chain." It is not a collection of loosely related functional groups – shipping, receiving, production, accounting, and so forth. Rather, like a chain, if you want to strengthen the "system," it is imperative that the weakest link be identified and efforts made to strengthen that link. If the weakest link is not strengthened, then the chain itself will not have been strengthened (improved) at all. Your effort may have added weight to the chain, but will have done nothing by way of improvement.

 

For simplicity's sake, let us say that the management team in our example organization has determined that the sales department is doing great. Sales and customer service are presently able to continue to sell more products, so the firm's bottleneck does not appear to be in sales or customer service. Let us also say that, despite the firm's rather primitive reliance upon weekly production meetings and spreadsheets, production has not yet become a bottleneck for producing goods to meet known demand.

 

On the other hand, warehousing and shipping operations are having an increasingly difficult time keeping up with picking, packing and shipping all the orders. There are several factors at work, it seems. One is that the sheer volume of orders of every kind is increasing. More importantly, the company has just opened an e-store on their Web site and has started selling some products direct to the consumer.

 

While this move has proven to be a good one and is quite profitable for the organization, it has dramatically changed picking-pack-ship operations. Since the firm used to sell mostly to dealers and distributors, they generally picked and packed large quantities into a smaller number of shipments. All of their processes were configured to handle this kind of order processing.

 

Now, however, with the e-store in operation, shipping finds that, in addition to picking and shipping the large orders with large quantities in each order, they must also pick, pack and ship hundreds of small orders every day. Some of these orders are just a single item in a box. They must do this every day; and this change has had a dramatic impact on them since all the shipping, manifesting and labeling is presently a very time-consuming, paper-based process. Clearly, the pick-pack-ship operation is this firm's bottleneck to reaching more of its goal.

 

If you and your management team have been following along and you have completed your own Current Reality Tree, you will need to take similar steps to those described above. You will need to look at the roots of your CRT and consider which parts of your organization need to be changed (i.e., what needs to change) and, more specifically, try to identify your "bottleneck" operations – those operations in particular that represent the weakest link in your system's chain of actions that result in producing Throughput.

 

Note: If you determine that your "bottleneck" is – as is it is sometimes stated – "in the market," then what you are saying is that you have more capacity internally (within your system) do supply and deliver products or services than the market is willing to buy from you at this time. It is important to note that while the terminology is often applied to say, "The constraint or bottleneck is in the market," this is really a misleading misstatement.

 

If your team comes to the conclusion that your bottleneck is "in the market," then the real internal bottleneck is still internal and will likely be found in functions like

 

  • Research and development – timely production of innovative products or services that provide a sustainable market advantage

 

  • Marketing – development of new modes of communicating value to prospects and customers around your product or service offerings

 

  • Sales – creation and execution of a sales process and innovative new "un-refusable offers" that deliver more sales while sustaining Throughput

 

  • Elsewhere – quality, lead-time, packaging, and other factors can lead to customers or prospects not being interested in buying your products or services

 

[To be continued]

 

(c)2009, 2010 Richard D. Cushing

The three things every executive needs to know

 

If you and your team have completed a Current Realty Tree (CRT), then you have taken the first valuable step in moving toward Extended Readiness for Profit -- the New ERP. You have begun the your revolt against traditional ERP and its Everything Replacement Project approach with all its foibles and pitfalls. And, you will notice, that you have not yet spent one thin dime on new technologies -- unless, of course, you went out to buy a copy of Microsoft Visio to neatly document your CRT.

 

The really good news is that, having created your CRT, you and your team have also taken a vital step toward understanding the "theory" that underlies how your organization -- your "system" -- presently works and does not work (when it doesn't). You likely also understand better how your system interacts with its environment -- that is, your supply chain and the economy in general.

 

Your Current Realty Tree is the new "framework" by which you will begin to evaluate all of your future actions for Extended Readiness for Profit.

 

Remember, there are three -- and only three -- things that every executive or manager must know in order to handle any situation and to bring improvement effectively to any organization:

  1. What needs to change

  2. What the change should look like

  3. How to effect the change

 

By looking at the "roots" of your Current Reality Tree, you and your management team now know exactly what needs to change. If you CRT is accurate and you have been honest with yourself in its development, then your CRT is the answer to number 1 above -- what needs to change.

 

Furthermore, if you've followed along in all the steps to this point, you have also determined which of the things that need to change will required some investment in technology in order to see significant improvement. More importantly, however, you have likely also uncovered one or more things (roots) that can be addressed immediately and at little or no cost, and these things can start bringing real improvement to your organization to beginning tomorrow. You are already on your way to achieving more of your goal -- to making more money tomorrow than you are today.

 

One or more of the things you have already discovered may require an investment of zero dollars and may be capable of delivering dramatic increases in Throughput or significant decreases in Inventory -- either of which can be a boon to cash flow and cash velocity.

 

There is real work involved, however. Looking at the roots of your CRT will tell you what needs to change, but it will still be up to your team to lay out effective means of achieving the change. And, while the CRT is a great starting place, you should likely consider applying more of the Thinking Processes to help you build a logical "road map" for change. Consider building a Transition Tree (TrT), which can really function as that "road map," even though all the ground must still be covered to get to your destination of achieving more of your goal.

 

[See prior posts for links to more information about the other Thinking Processes.]

 

[To be continued]

Creating your Current Reality Tree (CRT)

 

STEP 5:

Once you have completed your CRT, take a close look at the "roots." Roots are those entities at the bottom of the tree that have no arrow leading into them. Generally speaking, you will find that the roots of your CRT will fall into two very broad categories:

 

  1. Things you can change or affect in some way, and

  2. Things you likely cannot change or affect (de facto roots).

 

When classifying entities into the latter category (de facto) take great care. Do not allow yourself or your team to make excuses by simply saying that "we have no control over that." For example, quality issues from outside suppliers may not be in your direct control, but they are certainly within your realm of influence -- especially if you are a major customer of the vendor.

 

Once your team has identified all of the roots that fall into the first category, you will likely find that these roots may be further subdivided into three more categories:

 

  1. Root causes for which improvement requires no new technologies

  2. Root causes where you may achieve some improvement without the aid of new technologies, but further improvement may also be achieved by applying new technologies as part of an ongoing improvement process

  3. Root causes where the most logical and most effective action toward improvement will involve the deployment of new technologies

Most of the organizations we work with find that more of the things they need to change for improvement do not involve investments in new technologies. If this is your case, then "Congratulations!" In less than one day (most likely) you and your management team have discovered how to begin system-wide improvement that

 

  • May be commenced immediately

  • May involve little or no cost

  • Will likely deliver improvements that increase Throughput, reduce Inventories or the demand for new Investment, and/or will probably help you hold the line on Operating Expenses while you grow your business

 

Equally as important, however, is the fact that if you find the need for new technologies, the cash flow from the non-technology early-win improvements can help pave the way for the investment in new technologies in the near future.

 

[To be continued]

 

(c)2009 Richard D. Cushing - all rights reserved

 

For more information, go to GeeWhiz to R.O.I..