Business Intelligence and “Tribal Knowledge” – Part 1

Recently I was working with a client and, at the opening of the meeting, I asked the six members of their management team who were gathered around the table the following simple question: "What is keeping your from making more money tomorrow than you're making today?"

Their responses were telling: (approximate quotations)

1. "We don't understand our customers: Who is buying, why they buy, or how they go about the process of getting a purchase authorized."
   
2. "The amount of time it takes us to respond to a lead or prospect. We might get 20 to 300 leads from a trade show, but it might takes us three weeks to six months to get back to them after the leads have gone through all the hands and processes in our organization."
   
3. "We don't have a good way to turn the data we possess into information that would be valuable for decision-making."
   
4. "We don't have a good way to classify accounts in our customer relationship management (CRM) software so we know how to best approach them regarding our products and services."
   
5. "We don't understand the secondary participants involved in our sales process with a prospect."
   
6. "Our customers lack the funds to buy our products."
   

What is interesting about this is that, if we take number 2 out of the mix (this is clearly a policy constraint) the other five responses all have to do with "business intelligence." These folks needed to understand their customers better in virtually every aspect.

Now, in their defense, this firm has a fairly complex sales cycle with, potentially, a number of different parties involved. Here's a brief description of the participants and their relationship to the sales process:

• School District – Usually, it is the school district that will end up "owning" the product after purchase. Frequently it is at the district level, as well, that the purchase commitment must be authorized.
  
• School(s) – The individual schools and school administrators may have an impact on the purchase decision. The school(s) must be willing to take on the product before the school district will authorize the purchase, even if the teacher may have convinced the district administrator and board that it is the right way to go.
  
• Teacher(s) – Teachers function mostly as influencers and catalysts to the sale. The teachers often are sold on the product and then become an advocate to aid in getting the product approved at the school and district levels.
  
• School District IT Department – Since the products generally involve technology, it is not uncommon for the schools' or the district's IT departments to have de facto veto power over any pending purchase of such technology.
  
• Government Programs – Since most of the schools in the U.S. are publicly funded, the funding for many of the purchases flows directly or indirectly from some government program. Such programs often set requirements and seem to have a never-ending series of "hoops" that must be jumped through before funds are made accessible for specific purchases.
  
• NFP or Other Sponsor – When the school districts' ability to access funds for a desired product purchase falls short, sometimes not-for-profit (NFP) organizations become a supplemental source of funds. Sometimes, it is even the NFP, seeking a place for its funds in community projects, that becomes the initiator of the whole process. Other times, the interested teacher may know that the school or school district have no money for the purchase, so he or she will seek aid from a NFP organization simultaneous with presenting the matter to the school and district decision-makers.
  

As you can see, with all of these participants, and no single path for each approach, it is understandable that this organization is discovering some challenges in "understanding" their customers. Add to this the fact that their business itself was changing. They were diversifying from the product around which the business had originally been built – beginning to sell a broader range of related products into the same marketplace.

Tools at their disposal

Now, this firm does have some tools at their fingertips. They purchase the use of data made available from a data aggregator that provides a database of schools, school districts and related parties. Some demographic data is included.

Now, I am not privy to exactly what demographic data is available to them – our discussions didn't go to that level. However, for the sake of this discussion, let us say that they have just the following data points for each school and district (in additional to standard data like addresses, phone numbers, and so forth):

• ZIP code
  
• Number of students
  
• Number of teachers
  

Using a tool as rudimentary as Microsoft Excel's OLAP capabilities, it would be relatively easy to spot correlations in the data between product sales (by dollar or by units) and these demographic characteristics:

• Which regions of the country account for the most sales? The least sales?
  
  • Using the first digits in the ZIP Code gives you 10 regions automatically
    
  • Using the first three digits in the ZIP Code gives you a breakdown by what the USPS call SCF (Sectional Center Facility)
    
• Which states account for the most sales? The least sales?
  
• Which cities account for the most sales? The least sales?
  
• Which districts produce the highest ratio of unit sales to students? Which ones have the lowest ratio? What about the unit-to-teacher ratio?
  

My guess is, if they had graphs of these data – especially TOP and BOTTOM data – their sales and marketing personnel would immediately begin to see some patterns emerging.

Likely, however, they have other data already in their possession that would give them additional insights as to sales patterns leading to a better understanding of their customers' behavior. Take the following examples:

• Which salespersons produced the highest sales in terms of dollars and units? Which ones produced the least?
  
• Within each salesperson's sales, are there significant differences by sales by geographical region or SCF?
  
• Are there correlations between salespersons' sales and the discounts offered? (This would be an indicator of price sensitivity and should be correlated by other factors, like geography or average sale size.)
  
• Do correlations exist between salespersons' sales results and the products or product configurations they sell most frequently?
  

Little of this kind of analysis was being done in a formal way at this firm. However, it seemed that they already knew they needed to "understand their customer" better. They just had not yet thought about how to leverage what they already had in their hands in order to begin segmenting their market and understanding the factors leading to less success or more success (read: Throughput).

We will talk more about this in the next post in this series.

©2010 Richard D. Cushing

ROI is a Responsibility – Part 5

This is Part 5 in a series where we have been reviewing comments made by Jacob Varghese in a 2003 article in which he essentially claims that it does not make sense to try to measure or compare IT initiative based on ROI (return on investment) calculations. In preceding portions we have noted that Varghese called upon Ross and Beath to help him say more about how and why ROI might not be a good way to make determinations regarding IT investments:

"In 'New Approaches to IT Investment,' Jeanne W. Ross and Cynthia M. Beath break all IT investments along two dimensions: (1) strategic objectives (short-term profitability vs. long-term growth) and (2) technological scope (shared infrastructure vs. business solutions)…. Based on those two dimensions, all IT investments can be broken into one of the following four categories:

"Transformational: IT investments that aim to remove the infrastructural barriers to long-term growth across the organization (for example, integrated CRM, enterprise information portals, or end-to-end processing). Given the organization-wide impact and the imperative that such investments must be in line with organizational strategy, the CEO must own these investment decisions. The success of these projects should be his responsibility.

"Renewal: The aim of renewal IT investments (such as legacy modernization and platform conversion) is to improve the service levels of the existing shared infrastructure or reduce the cost of support and maintenance. The ownership of such projects should lie with the CIO, since the boundaries of these projects are well defined and benefits accrued can be quantified up front. Moreover, it is the CIO's responsibility to ensure the service levels from the shared IT infrastructure are constantly improved.

"Process Improvements: The end objective of IT investments that focus on short-term profitability or incremental process improvements might be to speed time to market, lower the cost of operations, or to differentiate services/product offerings. The ownership of such investments should lie with the business unit head, functional head, or the process owner, depending on how the organization is structured.

"Experiments: New technological trends that present significant opportunities for long-term growth should be the focus of IT experiments that use pilot programs to validate the technology's promise and impact. There is no fixed home for these projects. In one the industry, they might reside within the R&D organizations, in another, the enterprise architecture teams of MIS departments might take responsibility." (Varghese 2003)

I have previously concurred that there is, of course, legitimacy surrounding each of these classifications, but I wanted to take a closer look at each since it is my firm belief that business organizations really should be seeking ongoing improvement and, for for-profit organizations, real improvement should lead to making more money. In Part 3 we discussed "Transformational" IT projects. In this portion, we will try to cover, in a more brief way, the other three Ross and Beath categories for IT projects.

Process improvement IT projects

Ross and Beath tell us that "process improvement" IT projects are those "that focus on short-term profitability or incremental process improvements [such as] to speed time to market, lower the cost of operations, or to differentiate services/product offerings."

The Ross and Beath examples for IT "process improvement" projects are most enlightening. They are:

• Accelerating time to market
  
• Lowering the cost of operations
  
• Differentiating of service or product offerings
  

Now, allow me to restate these in the context of the three key metrics that we have been using repeatedly in this series:

Example Project	Key Metric Predicted Effect
Accelerating time to market	Assuming the enterprise's products or services have a market and the firm is doing a reasonably good job of selling the products prior to the "process improvement" project under consideration, then accelerating time to market should lead to increasing Throughput. All that needs to be done by the executive team is to figure out how they will leverage accelerated TTM (time to market) in order to increase Throughput, and then put numbers (estimates) to the question of how much they believe that Throughput can be increased as a result of the improvement.
Lowering the cost of operations	This is a simple exercise in reducing Operating Expenses. The question to be answered by your executive team is just how much Operating Expenses can be reduced without jeopardizing support for increasing Throughput (from other initiatives that are hopefully underway already).
Differentiating of service or product offerings	This should essentially be a ditto of what I said above in the "Accelerating time to market." After all, what is the point of investing in increasing the differentiation of your firm's products or services if doing so does not, in fact, lead to increasing Throughput. Still, managers will need to set their minds to calculations of how and how much the new differentiators will add to Throughput.

Experimental IT projects

In their article, Ross and Beath describe "experiment" IT projects as those that test "[n]ew technological trends that present significant opportunities for long-term growth" in "pilot programs to validate the technology's promise and impact." Since this is purely experimental, it would seem that it would be impossible to calculate their potential effects on T, OE or I.

However, I believe that it would be possible to apply a simple method called "profit expectation" to determine the value of potential benefits that might flow from experimental technologies. Under such an application, the standard ROI formula would be modified to the following:

ROI = ((a% * delta-T) – (b% * delta-OE)) / (c% * delta-I)
where
a% = estimated expectation (as percent) of achieving calculated delta-T,
T = Throughput, b% = estimated expectation (as percent) of actualizing delta-OE,
OE = Operating Expenses, c% = estimated expectation (as percent) of required delta-I,
and I = Investment

It would seem to me that these kinds of R&D projects would not be considered alongside other immediately accessible improvement projects. Therefore, an alternative approach for R&D should be considered. For example, perhaps before investing more than some preset and relatively small amount in any R&D project, the promoters of the project must present an ROI calculation to a review committee based on the formula above. It is up to the backers of the project to "sell" the committee on the validity of their calculations and estimates for a%, b% and c%.

Furthermore, it seems reasonable that as R&D projects move forward and more is learned, the values used in the ROI formula will change. Certainty should increase with each incremental review, but the ROI value will move up or down over time. By reviewing projects on a regular basis – weekly, monthly, quarterly, as may be reasonable for the type of organization – your executive team can maintain a clear and consistent drive toward increasing ROI through the firm's R&D efforts.

The bottom line

We must again be reminded: the bottom line is "the bottom-line." Do not succumb to accepting the concept that it is not possible to calculate ROI for so-called "process improvement" or "experimental" IT projects. There are ways to help your organization stay focused on real improvement – improvement that is most likely to have a positive effect on your enterprise's bottom line.

©2010 Richard D. Cushing

Works Cited

Varghese, Jacob. "ROI Is Not a Formula, It is a Responsibility." Journal of Business Strategy, May/June 2003: 21-23.

ROI is a Responsibility – Part 4

We have been reviewing comments made by Jacob Varghese in a 2003 article. In our Part 3 we noted that he had more to say about how and why ROI (return on investment) might not be a good way to make determinations regarding IT investments. In doing so, he references work by Ross and Beath:

"In 'New Approaches to IT Investment,' Jeanne W. Ross and Cynthia M. Beath break all IT investments along two dimensions: (1) strategic objectives (short-term profitability vs. long-term growth) and (2) technological scope (shared infrastructure vs. business solutions)…. Based on those two dimensions, all IT investments can be broken into one of the following four categories:

"Transformational: IT investments that aim to remove the infrastructural barriers to long-term growth across the organization (for example, integrated CRM, enterprise information portals, or end-to-end processing). Given the organization-wide impact and the imperative that such investments must be in line with organizational strategy, the CEO must own these investment decisions. The success of these projects should be his responsibility.

"Renewal: The aim of renewal IT investments (such as legacy modernization and platform conversion) is to improve the service levels of the existing shared infrastructure or reduce the cost of support and maintenance. The ownership of such projects should lie with the CIO, since the boundaries of these projects are well defined and benefits accrued can be quantified up front. Moreover, it is the CIO's responsibility to ensure the service levels from the shared IT infrastructure are constantly improved.

"Process Improvements: The end objective of IT investments that focus on short-term profitability or incremental process improvements might be to speed time to market, lower the cost of operations, or to differentiate services/product offerings. The ownership of such investments should lie with the business unit head, functional head, or the process owner, depending on how the organization is structured.

"Experiments: New technological trends that present significant opportunities for long-term growth should be the focus of IT experiments that use pilot programs to validate the technology's promise and impact. There is no fixed home for these projects. In one the industry, they might reside within the R&D organizations, in another, the enterprise architecture teams of MIS departments might take responsibility." (Varghese 2003)

I have concurred that there is, of course, legitimacy surrounding each of these classifications, but I wanted to take a closer look at each since it is my firm belief that business organizations really should be seeking ongoing improvement and, for for-profit organizations, real improvement should lead to making more money. In Part 3 we discussed "Transformational" IT projects. In this portion, we will try to cover, in a more brief way, the other three Ross and Beath categories for IT projects.

Renewal IT projects

Ross and Beath describe "renewal" IT projects as "investments (such as legacy modernization and platform conversion) is to improve the service levels of the existing shared infrastructure or reduce the cost of support and maintenance."

It seems clear from this description that most "renewal" projects will not contribute in any significant way to an increase in Throughput (T). However, it is likely that such projects will lead to reducing Operating Expenses (OE), and, in some cases, it may be possible that a "renewal" project could reduce the demand for (other) Investments (I). If this is true, then is it too much to ask for the IT department or the executive team to actually sit down and put some rational numbers (i.e., estimates) to the potential savings from investments in proposed IT "renewal" projects?

For example, if investment in SAN or virtualization technologies will contribute to savings in support or drive down the need for investments in new servers or other types of data storage in the future, then let the IT department bring forth such estimates and present them for consideration by the executive management team. There is a place for such projects, and the more the firm emphasizes and prioritizes around IT projects that increase Throughput (based on calculated ROI for projects competing for the investment dollars), the more cash flow will increase and the less difficulty the enterprise will have in coming up with the funds when ROI calculations show that a "renewal" project makes a lot of sense.

However, I would like to suggest another approach. One of the former managers for the New York Yankees used to have a strict policy: "Put a rookie in the lineup every year." This makes sense because then your team never gets "old" all at once. This approach makes sense, too, in the IT infrastructure world. Organizations should build into their regular annual budgets an Operating Expense amount allocated to "renewal" of their IT infrastructure. Some years the full renewal budget will be spent. Other times the renewal budget will not be spent in full. In that case, any budget balance should roll-over into the next year when a larger renewal project may be required.

If this approach is used, then "renewal" projects in IT become a part of operating expenses necessary to maintain the enterprise's health. In this case, a "renewal" project's ROI is still calculated in the same way using the same formula. The calculations would run along these lines:

ROI = (delta-T – delta-OE) / delta-I
where T = Throughput (Revenue less Truly Variable Costs),
OE = Operating Expenses, and I = Investment

Since, for IT "renewal" projects there is not likely to be rationale for concluding that the project will contribute to increasing Throughput, then that leaves only reductions in Operating Expenses and Investment as factors. If a "renewal" project requiring an investment of $25,000 will reduce annual maintenance and support costs by $6,000, but will also reduce a potential additional investment in year 2 by $18,000, then one can calculate as follows:

ROI (Year 1) = ($0 – (-$6,000))/$25,000 = 24%

ROI (Year 2) ($0 – (-$6,000))/($25,000 - $18,000) = $6,000/$7,000 = 85.7%

Note: When comparing multiple projects that produce multi-year variable cash-flows it may make sense to compare projects based on NPV (net present value) or, potentially, FMRR (financial management rate of return).

The bottom line

To reiterate: the bottom line is "the bottom-line." Do not succumb to accepting the concept that it is not possible to calculate ROI for an IT project destined for "renewal." We have just proven that, if your executive management and IT staff will commit to thinking through estimates and causes for changes in T, OE and I, then it is possible to rationally calculate the benefits to proposed IT projects – "renewal" or otherwise.

We will continue with the other kinds of IT investment from Ross and Beath in future posts.

[To be continued]

©2010 Richard D. Cushing

Works Cited

Varghese, Jacob. "ROI Is Not a Formula, It is a Responsibility." Journal of Business Strategy, May/June 2003: 21-23.

ROI is a Responsibility – Part 3

Jacob Varghese has more to say about how and why ROI (return on investment) might not be a good way to make determinations regarding IT investments. In doing so, he references work by Ross and Beath:

"In 'New Approaches to IT Investment,' Jeanne W. Ross and Cynthia M. Beath break all IT investments along two dimensions: (1) strategic objectives (short-term profitability vs. long-term growth) and (2) technological scope (shared infrastructure vs. business solutions)…. Based on those two dimensions, all IT investments can be broken into one of the following four categories:

"Transformational: IT investments that aim to remove the infrastructural barriers to long-term growth across the organization (for example, integrated CRM, enterprise information portals, or end-to-end processing). Given the organization-wide impact and the imperative that such investments must be in line with organizational strategy, the CEO must own these investment decisions. The success of these projects should be his responsibility.

"Renewal: The aim of renewal IT investments (such as legacy modernization and platform conversion) is to improve the service levels of the existing shared infrastructure or reduce the cost of support and maintenance. The ownership of such projects should lie with the CIO, since the boundaries of these projects are well defined and benefits accrued can be quantified up front. Moreover, it is the CIO's responsibility to ensure the service levels from the shared IT infrastructure are constantly improved.

"Process Improvements: The end objective of IT investments that focus on short-term profitability or incremental process improvements might be to speed time to market, lower the cost of operations, or to differentiate services/product offerings. The ownership of such investments should lie with the business unit head, functional head, or the process owner, depending on how the organization is structured.

"Experiments: New technological trends that present significant opportunities for long-term growth should be the focus of IT experiments that use pilot programs to validate the technology's promise and impact. There is no fixed home for these projects. In one the industry, they might reside within the R&D organizations, in another, the enterprise architecture teams of MIS departments might take responsibility." (Varghese 2003)

There is, of course, legitimacy surrounding each of these classifications, but I want to take a closer look at each since it is my firm belief that business organizations really should be seeking ongoing improvement and, for for-profit organizations, real improvement should lead to making more money.

Transformational IT projects

Ross and Beath describe transformational IT projects as being "IT investments that aim to remove the infrastructural barriers to long-term growth across the organization (for example, integrated CRM, enterprise information portals, or end-to-end processing)." Now, in for-profit organizations, my guess is that the real measure of "growth" is in two realms: revenues and profits. I doubt that there is a desire to grow the balance sheet just to call it "growth."

Another word for "barriers to long-term growth" would be a "constraint." So, "transformational" IT investments should be aimed at exploiting, elevating or breaking a constraint to long-term growth. And, while we are talking about it, let us set forth this axiom: It is not possible to exploit, elevate or break a constraint to long-term growth without the action also opening the door for short-term growth. So whatever investment your executive team makes in so-called "transformational" IT should still be able to be measured in the essential terms we used in earlier portions of this series: namely, increasing Throughput, reducing Inventories or demands for new Investment, and cutting or holding the line on Operating Expenses while supporting significant growth.

Let us look at each of these more closely in the context of "transformational" IT:

Increasing Throughput: Some business executives look at IT investments in, say, a new ERP system as though ROI for such investments were a given. There justification for yanking their present systems out and going through 18 months or more of upheaval in a traditional ERP – Everything Replacement Project is frequently little more than some general sense that "If we do it, things will get better." They hear that other companies have replaced or upgraded their ERP systems and report making more money, and they don't want to be left behind. But these same executives forget that other companies have also gone into Everything Replacement Projects only to be tapped for hundreds of thousands or even millions of dollars and not improved at all. In fact, some companies never recover from traditional ERP implementations and end up on the junk-heap of business history.

In the absence of the willingness or tools to create a valid estimate for their firm's "transformational" IT projects, some executives and IT managers seem to buy into the software vendors' and resellers' theory that somehow "new" or "improved" ERP systems are like oil to an engine – just pour it in and everything will run smoother, faster and with less friction.

Well, oil does that for an engine and we can accurately predict the effects of the lubrication on the engine because we have laws of physics and mechanics to guide us in calculating the predicted effect. Unfortunately, most business executives and IT managers today do not even have an accurate theoretical framework about what the constraint is – or constraints are – to their businesses' making more money tomorrow than they are making today. Instead, they accept the "mystical mojo" theory that "new" or "improved" technology will somehow make their enterprise also run smoother, faster and with less friction.

Would it not be more business-like for your executive management team to actually figure out how just how any investment in IT that is designed to "remove infrastructural barriers to long-term growth" will actually remove barriers to long-term growth? Would it not be more practical for the team to make some rational estimates of the measure of improvement that will result from the removal of these "barriers to long-term growth"? Does it not stand to reason that, if managers believe that implementing new technologies will, in fact, "remove… barriers to… growth" that they be asked also to define just how the technologies will elevate or break existing constraints to business growth?

That is what figuring out how much new technologies will contribute to increasing Throughput is all about. The executive management team should be able to say something along these lines before making a decision regarding any given IT project: We believe that investments in technology X will lead to increasing Throughput (for definitions see related posts) by Y dollars within N months. We base our estimates on the new technology's providing us with the ability to expand our reach into markets A, B and C accompanied by commitments from Sales and Marketing that targeted offers in Product Lines P, Q, R and T.

To do less than this is for your executive management team and IT staff to make a resolution to spend, perhaps, hundreds of thousands of dollars on new technologies based only on "hope" and we all know that "hope" is not a strategy, at all.

Reducing Inventories or other demands for new Investment: Much of what I just said about your executive team setting forth specifics in estimating changes in Throughput applies equally well in calculations regarding potential changes in Inventories or other Investment. If your IT staff or software vendor is encouraging you and your team to consider an investment of potentially hundreds of thousands of dollars, it seems that you would owe it to yourself and to your stakeholders to grapple with just how this investment may help the company with regard to liberating cash or reducing demands for new investments in other areas of the enterprise.

If investing in new supply chain technologies will help slash your $10 million average inventory by an estimated 22%, then that is $220,000 in cash that will be liberated in your operating cash flow. But your management team should figure out, in advance, just how the application of the technologies in your specific environment will lead to this 22% reduction in inventories. The 22% figure should not be grabbed out of the air; nor should it be taken for granted that because the technology vendor has reports from other clients that this number has been achieved that your organization can do the same.

However, on the positive side, if your proposed technology investment can cut your inventories by 22% while simultaneously support significant increases in Throughput, then you and your team are probably also looking at an apparent reduction in demand for new investment, as well. It means that your enterprise may be able to double or triple its Throughput without having to build a new warehouse or invest in the expansion of the existing one. This is all good news and should be calculated in the firm's ROI for the proposed investment in "transformational" IT.

Cutting or holding-the-line on Operating Expenses while supporting significant growth: Again, much of what I have said above regarding your executive team's willingness to "dig out the numbers" and figure out the "how" an investment in "transformational" IT will "remove barriers to… growth" applies to calculating changes in Operating Expenses (OE). Do not rely on rules-of-thumb and reports from technology vendors and resellers regarding the benefits other companies have achieved. If these are going to be real for your enterprise, then the how-to and resulting benefits should not be too difficult for your team to put down on paper.

Actually, in the example given above, we could already calculate at least one portion of the change in OE: If we know the firm's carrying costs for inventory, then the change in Operating Expenses from the reduction in inventory would simply be $220,000 times C%, where 'C' is carrying costs as a percent of inventory. If it costs your business 20.8% to carry inventory, then the change in Operating Expenses would be a decrease of $220,000 times 20.8% or $45,760 per annum.

The bottom line

The bottom line is "the bottom-line." Do not succumb to accepting ROI calculations from your technology vendor or base them on rules of thumb that may or may not be accurate for your enterprise. Besides, it is up to your management team to work out – in advance – precisely how they intend to leverage the proposed new technologies to achieve the ends of increasing Throughput, reducing Inventories or demands for new Investment, and cutting or holding the line on Operating Expenses when "transformational" IT projects claim to be "removing barriers to… growth."

We will continue with the other kinds of IT investment from Ross and Beath in future posts.

[To be continued]

©2010 Richard D. Cushing

Works Cited

Varghese, Jacob. "ROI Is Not a Formula, It is a Responsibility." Journal of Business Strategy, May/June 2003: 21-23.

ROI is a Responsibility – Part 2

As I said in Part 1 of this series, I have, of late, been challenged in my thinking from two quarters: first, in a LinkedIn discussion I had an entrepreneur tell me that entrepreneurs had to be too much "right-brained" and could not be cornered into decisions based on such things as calculated ROI (return on investment).

And next by this excerpt from a May/June 2003 article by Jacob Varghese:

"Basing IT priorities on ROI rankings is a fool's game, a game in which the biggest liar wins. By relying solely on ROI figures to approve a project or decide between projects, managers are shirking their responsibility for understanding how technology will affect their businesses. ROI numbers do not ensure that technology initiatives will be in line with business strategy. The success of any technology initiative depends on whether the person responsible for implementation has the required incentives, authority, and credibility across the span of the organization that would be affected by that initiative. ROI figures should merely be used as a means to ensure that the planning is as comprehensive as possible and the totality of impact has been considered. And managers should avoid approving the entire funding up front. Rather, funding should be an ongoing contingent upon the project team meeting key milestones and realization of planned benefits." (Varghese 2003)

"ROI numbers do not ensure that technology initiatives will be in line with business strategy."

Of course, Mr. Varghese is absolutely correct in this. It is quite possible to calculate an ROI for a project that has nothing to do with your business strategy. In fact, this is eminently possible if you use formulas provided by software vendors and resellers. All you need for some of those formulas are numbers like:

• Number of employees
  
• Number of salespeople
  
• Current Revenues
  
• Number of orders per month
  
• Number of SKUs and so on, ad nauseum. 

Unfortunately, one of the things that you will note about these numbers supplied to standard ROI formulas used by salespeople is that everyone has employees, everyone (or almost everyone) has salespeople, everyone has revenues, and so forth. None of these figures say anything about your business strategy or what will actually make your business better.
If you use these kinds of generic formulas to calculate the ROI of your IT initiatives, then there is no assurance whatsoever that the there will any alignment between IT efforts and your business strategy. So the answer is, do not use such ROI calculations. Go back to Part 1 in this series and see how you and your management team should calculate ROI in order to compare business opportunities that may be supported by IT investments.

"The success of any technology initiative depends on whether the person responsible for implementation has the required incentives, authority, and credibility across the span of the organization that would be affected by that initiative."

Now here is where I'd have to ask Mr. Varghese for the definition of "success." If you ask the typical software vendor or VAR (or, unfortunately, maybe even your own IT manager) the definition of the "success of [a] technology initiative," you are likely to get an answer along these lines: "If the project is completed on-time, within the budget, and delivers the quality anticipated to the end-users, then the project is a 'success.'"

What is missing in this all too typical definition of IT project success is anything having to do with delivery of business value. If that is true – if your IT manager does not relate every effort to delivering business value that is a failure of executive management. Either they hired the wrong kind of person for the job, or they have not taken time to convey across the whole organization – IT staff included – that every expenditure of time, energy or money should be focused on delivering business value.

If, on the other hand, your executive management team is "responsible for implementation" of each IT initiative and if they have prepared their ROI calculations for the project as I have described in Part 1 of this series, then they will have and know everything they need to help guide the project to full business value-delivering success.

"ROI figures should merely be used as a means to ensure that the planning is as comprehensive as possible and the totality of impact has been considered."

I confess that Mr. Varghese has me confused at this juncture. If "planning is as comprehensive as possible and the totality of impact has been considered," then what is wrong with using the ROI figures altogether? I think most readers will concur with me that the ROI in the example presented in Part 1 of this series is "comprehensive" and considers "the totality of impact." So, if such numbers exist, why not use them in a comprehensive way to set IT priorities?

"And managers should avoid approving the entire funding up front. Rather, funding should be an ongoing contingent upon the project team meeting key milestones and realization of planned benefits."

I certainly concur with the general notion that, if proof of concept can be achieved without expenditure of the full budgetary allowance for any given IT initiative then, by all means, get to the proof of concept and make a go/no-go decision at that point. This is common sense.

However, planning, that goes well beyond the IT department, should be responsible for all of the other things that must occur in order to "realize planned benefits." Technologies are tools and only tools. They represent costs, expenses and investment and do not, in themselves, ever represent revenues, Throughput or profit to the organization. It is up the business organization itself to leverage the tools in order to achieve more of the firm's goal – to make more money today and in the future. Executives and managers must have laid the functional groundwork during the planning that was used to calculate the ROI (see Part 1). They must already know what must happen to reach the estimated increase in Throughput, for example. That factor is not in the purview of the IT department.

[To be continued.]

©2010 Richard D. Cushing

Works Cited

Varghese, Jacob. "ROI Is Not a Formula, It is a Responsibility." Journal of Business Strategy, May/June 2003: 21-23.

ROI Is a Responsibility - Part 1

I have, of late, been challenged in my thinking from two quarters: first, in a LinkedIn discussion I had an entrepreneur tell me that entrepreneurs had to be too much "right-brained" and could not be cornered into decisions based on such things as calculated ROI (return on investment).

Next, I was going back through some old articles I had collected and discovered this excerpt from an May/June 2003 article by Jacob Varghese:

"Basing IT priorities on ROI rankings is a fool's game, a game in which the biggest liar wins. By relying solely on ROI figures to approve a project or decide between projects, managers are shirking their responsibility for understanding how technology will affect their businesses. ROI numbers do not ensure that technology initiatives will be in line with business strategy. The success of any technology initiative depends on whether the person responsible for implementation has the required incentives, authority, and credibility across the span of the organization that would be affected by that initiative. ROI figures should merely be used as a means to ensure that the planning is as comprehensive as possible and the totality of impact has been considered. And managers should avoid approving the entire funding up front. Rather, funding should be an ongoing contingent upon the project team meeting key milestones and realization of planned benefits." (Varghese 2003)

Now, I remain at two-minds regarding the Varghese article. On the one hand, I might agree with him on some matters, but I cannot be quite sure because there are other statements that run so outrageously against my inner sense that I cannot be certain of his meaning in the other statements. So, let me break this down sentence by sentence:

"Basing IT priorities on ROI rankings is a fool's game, a game in which the biggest liar wins."

Who is the "liar" here?

I suppose if the ROI figures are coming from a salesperson working for a software vendor or VAR (value-added reseller), then Varghese might have a point. However, it is the firm's executive team that is the "fool" in that case, for believing the ROI numbers provided by the very persons who stand to gain the most – and lose the least – by selling new technology to the firm.

However, if the executives and managers are doing their job properly and they have the right tool set, they should be the inventors of their own ROI figures. Furthermore, those figures should not be predicated on industry averages or "round-numbers" or rules-of-thumb. The executive team should figure out – for each proposed investment in IT – the following three factors (at a minimum):

	Factor	Description	Example
1	Change in Throughput or delta-T	How much will Throughput increase, where Throughput is defined as incremental revenues less truly variable costs (only those costs that will vary directly with the change in incremental revenue change)	Investing $85,000 in technology X should increase our sales of Product Lines A, B and C in the Y market segment by 15% over the next 12 months. We estimate that this will result in $215,000 per annum in additional Throughput when fully up-to-speed. We believe that minimal change in Operating Expenses will be necessary to support this increase it Throughput.
2	Change in Investment or delta-I	How much will total assets change	Of the $85,000 investment in technology X, we expect that $50,000 will be capitalized. We also expect that about $22,000 in additional inventory will be required to support the $215,000 per annum in additional Throughput. Therefore, total change in Investment (first year) is estimated to be $72,000 ($50,000 + $22,000).
3	Change in Operating Expenses or delta-OE	How much will day-to-day expenses increase or decrease	As previously stated, our estimates indicate that we will be able to support the $215,000 in additional Throughput with no additional staffing. However, the carrying costs for the additional $22,000 in inventory are estimated at 23.2% or $5,104 per annum. We also know that software maintenance costs will 18% of $20,000 or $3,600. Total estimated change in Operating Expenses are, therefore, $8,704 per annum. In the first year, we must add the non-capitalized part of the $85,000 IT project, or $35,000. First year delta-OE is, therefore, $8,704 + $35,000 = $43,704.

How, then, do we calculate the ROI for this "technology X" project? Quite simply using the following formula:

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

Or

First-year ROI = ($215,000 - $43,704) / $72,000 = $171,296 / $72,000 = 238%

Now, perhaps Mr. Varghese can explain to us all why comparing various IT projects on this basis is "a fool's game."

"By relying solely on ROI figures to approve a project or decide between projects, managers are shirking their responsibility for understanding how technology will affect their businesses."

Here, again, I guess we need to ask the question: Whose ROI figures? If the figures upon which the executive team is relying come from the vendor or the VAR or are otherwise based on non-specifics, then I would concur with Varghese.

However, if the ROI figures are coming from sound analyses as I just set forth in the examples above, then I would say that it would be managers who do not "rely solely on ROI figures to approve" IT projects, or to "decide between projects" that are "shirking their responsibility for understanding how technology will affect their businesses." In fact, by not preparing an ROI analysis with the kind of stringency suggested by my example above, then managers and executives are simply throwing in the towel and confessing outright that "We do not know how technology will affect our business. Instead, we just have hope that if we spend money on technology, that somehow our company will magically improve."

That, folks, is not a strategy.

[To be continued.]

©2010 Richard D. Cushing

Works Cited

Varghese, Jacob. "ROI Is Not a Formula, It is a Responsibility." Journal of Business Strategy, May/June 2003: 21-23.

The Problem with Manufacturing Software

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

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

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

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

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

So, let me get this right…

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

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

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

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

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

A simpler solution

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

Try this simple formula for any item in your system:

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

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

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

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

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

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

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

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

©2010 Richard D. Cushing

What does “demand-driven” really mean?

Recently I stumbled across a whitepaper entitled Demand-Driven Inventory Management Strategies: Challenges & Opportunities for Distribution-Intensive Companies (Fraser and Brandel 2007) prepared by Julie Fraser and William Brandel, principals at Industry Directions, Inc. What I found amazing about this article is that it doesn't really get to the point of "demand-driven inventory management strategies." Instead the focus is on better systems, better data, better use of the data, and better forecasts at the SKU level (rather than at the "product family" or "product category" levels).

Now, maybe I'm an idealist, but when I think of "demand-driven" inventory, I think of an integrated supply chain that functions in such a way that when an end-user takes a unit of product off the shelf at the retailer's store (or whatever model is being used), that action triggers the production of one unit at the manufacturer's plant with a minimum of mid-stream manipulation.

See the accompanying illustration, and let me describe for you my concept of a demand-driven supply chain. We will start at the bottom of the illustration – where the action begins – at the retail store. Ideally, each retail store should stock just enough product to cover one day's sales plus a "buffer" to allow for expected variability in demand.

At the end of each business day, the retailers should transmit to their associated distribution center (DC) the quantities sold of each SKU in the supply chain depicted. It doesn't matter whether the DC is owned by the retail chain or the distributor, the process would and should work the same.

Next, depending upon the agreed replenishment cycle (although daily is ideal), the DCs would prepare replenishment orders to be shipped to the retail outlets. The goal would be to replenish exactly the quantity that was reported as sold (plus or minus any adjustments for seasonality, special promotions, etc.) at each outlet. Meanwhile, the DCs will have reported to their supplying warehouse how many units of each SKU that they have sold (again, plus or minus any adjustments).

Each DC should stock only enough of each SKU to cover the replenishment cycle from the domestic warehouse plus a "buffer" to cover any variability in demand. On its scheduled replenishment cycle – and, again, daily is ideal – the domestic warehouse should ship out replenishment orders to the DCs. In the meantime, if the replenishment cycle is longer than one day, the domestic warehouse will have transmitted daily sales numbers back to the off-shore warehouse, so that the consumer purchase made at the retail outlet is transmitted all the way back to the manufacturer within one business day.

Following the pattern we have discussed already, the domestic warehouse should carry just enough of each SKU to cover variability in demand and supply (lead-time). The size of the "buffer" should include a calculated allowance for disruptions in the supply chain where it is most vulnerable (e.g., overseas transportation, or other). Naturally, since this represents aggregate demand, estimates of demand will be more accurate at this level than they will be at either the DCs or the retail outlets. As a result, the domestic warehouse inventories will be larger, but not nearly as large as if each lower level in the supply chain tried to estimate (read: forecast) demand for periods into the future. This approach helps keep inventories to a minimum and makes the whole supply chain more responsive to changes in demand.

Likewise, the foreign port warehouse should carry just enough stock of each SKU to cover variability in demand from the warehouse(s) on the opposite shore plus any variability in lead time from the manufacturing plant which, as we shall see, should be near zero.

Since estimates of demand variability will be most accurate at the level that demand is most highly aggregated, the manufacturer is the most reasonable place to keep the largest "buffer" of inventory for the SKUs in the supply chain. The manufacturer should carry enough stock of each SKU to cover production lead time variability. (Typically, this buffer length should be only three times the actual production time for each SKU. That is to say, if a day's aggregate supply of SKU #1001 can be produced in a single day of production, then the buffer for SKU #1001 should initially be set for three days. Then production should be scheduled in batches as small as is practical for the SKU.) Generally, production should be scheduled at the manufacturing plant based on producing the actual demand reported via the supply chain plus enough to fill any "holes" created in the buffer created by unusual demand in a prior period.

Now, that's what I call a "demand-driven" supply chain. It is do-able and it makes life better for everyone. Here's why:

• Lower inventories everywhere
  
• Reduced write-offs due to obsolescence
  
• Lower inventory carrying costs all across the supply chain
  
• Manufacturing is more responsive to changes in market demand – not separated from real feedback by weeks or months
  
• Fewer lost sales due to stock-out (And the value of lost sales are almost always under-estimated in supply chain calculations simply because they are done by "averages," but the items most likely to suffer stock-outs are the most popular selling items, not average performers.)
  
• Reduction or elimination of expediting costs across the whole supply chain
  
• Dramatic reduction in overstocks (and about 73% of companies report overstocks simultaneously with expediting for items that are running short), which leads to less price-cutting to liquidate unneeded inventories
  

©2010 Richard D. Cushing

Works Cited

Fraser, Julie, and William Brandel. Demand-Driven Inventory Management Strategies: Challenges & Opportunities for Distribution-Intensive Companies. White paper, Boston, MA: Industry Directions, 2007.

Kinaxis Supply Chain Expert Community: 21st Century Supply Chain: Top companies empower employees to act on insights

Kinaxis Supply Chain Expert Community: 21st Century Supply Chain: Top companies empower employees to act on insights

Empowering employees to act requires more than just granting them access to data and tools. It requires that they also have a solid theoretical framework by which to make decisions that are beneficial to the whole enterprise, not just the narrow scope of their department or function.

Read the article and the comments.

...

The New ERP – Part 37

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

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

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

What is it about "business requirements"?

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

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

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

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

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

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

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

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

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

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

What "business requirements" should look like

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

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

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

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

Works Cited

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

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

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

The New ERP – Part 36

In December 2009, Eric Kimberling, founder and president of Panorama Consulting Group (Denver, CO), offered his "ERP Software Predictions for 2010". They are as follows (with my comments added:

1. Diligent focus on ERP software benefits realization and ROI. Long gone are the days of spending like it's 1999 and hoping for the best. CIOs and COOs will continue to face pressure to prove that every dime of investment in ERP systems is justified and generates a solid return on investment. Look for more deliberate spending, more phased rollouts, buying licenses only as they're needed, and hesitancy to invest in more expensive advanced enterprise software modules.
   
   Isn't this what The New ERP – Extended Readiness for Profit is all about? We have emphasized the ROI should be a deliberate forethought for you and your management team over and over. We have repeatedly pointed out that spending money on technology – or anything else – based on some "hope" that your organization will improve is pure folly. "Hope" is not a strategy; it's a small town in Pennsylvania, I believe.
   
   
2. SMBs to get back into the ERP software market. The bright spot in any recovering economy is usually small business (SMBs). As the economy emerges from the recession, SMBs will look for small business software to automate their operations and scale for growth. In addition, large software vendors such as SAP and Oracle will continue to focus on the SMB market to reinvigorate their revenue growth in software license sales. [Emphasis added.]
   
   "Growth" ought to be the focus of every business organization. This is also the focus of The New ERP. While cost-cutting is the knee-jerk reaction to trying economic times, there is a limit to the gains that can be made through cost-cutting. I have frequently put this challenge before individuals and groups of businesspeople and have yet to receive a correct response: "Name for me one business enterprise that has become a market leader where its primary business strategy was 'cost-cutting.'" Growth is the only strategy that has no limitations to improvement.
   
   
3. Increased adoption of Software as a Service (SaaS) at SMBs. While SMBs may lead the charge in their small business software investments, it may be difficult for them to make the necessary investments. Given that tight credit markets will likely continue into the new decade, many SMBs will look to SaaS ERP software to help them minimize up front capital IT costs. [Emphasis added.]
   
   Here again we see that this approach falls directly in line with The New ERP – Extended Readiness for Profit. Minimizing up-front capital IT costs means nothing less that holding what we have called delta-I (the change in Investment) as low as possible while driving to maximize delta-T (the change in Throughput). Once again, the strategy we are suggesting is right on the money – literally.
   
   
4. Lots of ERP SaaS talk, but not as much action at large organizations. Larger companies, on the other hand, are likely to consider SaaS options, but are much less likely than their SMB counterparts to commit to these deployment models. As software vendors expand hybrid solutions combining the benefits of SaaS with the flexibility of traditional ERP (e.g. Oracle's On Demand and SAP's Business By Design offerings), larger organizations will continue opting for non-SaaS options that more commonly reduce cost and risk while maximizing business benefits in the long-term. They will, however, be more inclined to leverage SaaS for some niche functions, such as Document Management Systems (DMS), Human Resource Management Software (HRM/HCM), Product Lifecycle Management (PLM), and Customer Relationship Management (CRM). [Emphasis added.]
   
   In this case, I think Mr. Kimberling misses the mark. While his analysis is likely correct as to the reactions of "large organizations" versus "SMB" firms to SaaS offerings, Kimberling is off-base when he makes reference to "the flexibility of traditional ERP." In fact, if "traditional ERP" has fallen into disfavor for any reason in the last decade, it is the sheer weight of evidence that "traditional ERP" is far too rigid that has led to it.
   
   On the other hand, The New ERP's approach to solution design and decision-making is all about taking "traditional ERP," with its inherent rigidity, and finding economically sensible ways to extend its capabilities at low-cost and without (or minimizing) changes to source code.
   
   
5. Increasing focus on organizational change management and ERP benefits realization. As demonstrated by the exponential growth in Panorama's organizational change management practice, companies are directing much of their ERP software investments to areas that ensure they implement effectively and get more out of their existing enterprise investments. The need to more effectively manage organizational and business risk will likely result in a continuation of this trend in 2010. [Emphasis added.]
   
   Bang! The New ERP hits the target again. Imagine the novel idea that companies should "direct much of their… investments to areas that ensure they implement effectively and get more out of their existing enterprise investments." That sounds very much like what we have been trying to hammer home with The New ERP – Extended Readiness for Profit.
   
   
6. With ERP software, it's still a buyers' market. Even in the most optimistic scenario, overall 2010 enterprise software spending will not return to pre-recession levels. This means ERP software buyers will remain in the driver's seat, which will be reflected in aggressive software pricing and shared benefits implementation models, such as that introduced by Epicor late this year. [Emphasis added.]
   
   Mr. Kimberling's statements here suggest – and rightly so – that, in some prior years, the "ERP software buyers" were not "in the driver's seat." If you have read the prior posts in The New ERP – Extended Readiness for Profit, then you will understand when I ask this question: "Why, for goodness sake, has the ERP software buyer not always held his ground and stood fast 'in the driver's seat'?" The New ERP is all about assuring that you and your management team are, and remain firmly ensconced, in the driver's seat.
   
   
7. Enterprise software risk management. As CIOs and executive teams remain on the hot seat to prove the value of their investments, risk management will be the name of the game. Look for more ERP implementations to leverage organizational change management and independent oversight of software vendors to help mitigate business risk. [Emphasis added.]
   
   A survey of the literature surrounding the ERP software industry makes it all too plain that, heretofore, most CIOs and executive teams were not held to metrics that would clearly "prove the value of their investments." In fact, far too many CIOs today still make excuses about how the "benefits" of investments in IT cannot be measured.
   
   However, as The New ERP boldly asserts, if the organization cannot figure out how – and approximate how much – a recommended change in information technologies will lead to increasing Throughput, reducing Inventories or demand for new Investment, and/or cutting or holding the line on Operating Expenses, then maybe – just maybe – the IT change just isn't worth making.
   
   
8. ERP software vendor consolidation. Vendor competition was fierce before the recession and is even more so now. Dozens of smaller vendors are starved for cash and unable to fuel R&D and other product innovations without infusions of capital. Add the fact that larger vendors have cash and some have grown successfully via acquisition to date (e.g. Oracle and Infor), and continued vendor consolidation looks inevitable.
   
   In my opinion, vendor consolidation is neither good nor bad from the perspective you and your management team. If you are applying the concepts set forth in The New ERP – Extended Readiness for Profit you come out a winner no matter who supplies the desired technologies.
   
   
9. Focus on integration rather than major ERP package enhancements. Given corporate aversion to risk, companies are going to be less likely to bet on entirely new products or risky upgrades. As a result, vendors are more likely to invest in incremental product enhancements and tighter integration between modules rather than revolutionary changes to their software. [Emphasis added.]
   
   Once again The New ERP falls right in line with Mr. Kimberling's analysis. Why should an organization undertake a "risky upgrade" or "bet on entirely new [software] products" – traditional ERP (Everything Replacement Project) – when following the guidelines in The New ERP will bring them near-immediate benefits through increased Throughput and/or reductions in Investment demands and Operating Expenses?
   
   
10. Niches, low-hanging fruit, and business value.
    Look for companies to be very deliberate about how they invest in enterprise software, the risk they're willing to take, and how they manage implementations. If executives aren't convinced that their enterprise software investments will deliver measurable business value, they won't invest in it. Areas that deliver immediate value are priorities for the coming year." (Kimberling 2009) [Emphasis added.]
    
    Now this one sounds so good, I almost could have written it myself! What a strange thing it is that it took nearly 30 years from the coining of the term "ERP" to reach the point where companies have become "very deliberate about how they invest in enterprise software" and business executives "won't invest" unless they're "convinced that their… investments will deliver measurable business value." That is far too much wasted time, energy and money. Don't you think so, too?
    

Works Cited

Kimberling, Eric. Top Ten ERP Software Predictions for 2010. December 7, 2009. http://panorama-consulting.com/top-ten-erp-software-predictions-for-2010/ (accessed December 21, 2009).



©2009, 2010 Richard D. Cushing