MUFI Rating & Risk – SAP APO DP

MUFI Rating & Risk – SAP APO DP

MUFI: Maintainability, Usability, Functionality, Implement ability

VendorSAP (Select For Vendor Profile)

Introduction

This is SAP’s demand planning application, which is out of the SAP APO or Advanced Planner and Optimizer suite.

Application Detail

SAP DP shares an unfortunate technological heritage with SAP BW/BI, SAP’s data warehouse. This is because both applications use the Data Warehouse Workbench to enable the created of data structures. Demand planning applications are built on top of business intelligence platforms. The SAP Data Warehouse Workbench has the lowest efficiency of any application data modeling functionality that we have ever tested.

Interestingly, in the business intelligence space (which demand planning is strongly related as it is primarily a reporting system or business intelligence data platform, but with demand planning functionality added on top), is moving in the opposite direction of where both BW and DP are present. That is easier to use applications, more self-optimized data structures. In this way, BW and DP are dinosaurs and are primarily sold to low information customers where the IT department are mere “SAP shops,” and has little interest in participating in an actual software selection.

DP has problems with managing hierarchies, with disaggregation, with best-fit functionality, with lifecycle planning, and the list goes on from there. SAP DP has the lowest scoring user interface of all the forecasting applications we test. SAP APO consultants seem to live in a bubble concerning DP. Those that specialize in DP rate that their clients are satisfied with DP and that DP is a very functional application. Manual adjustments can be made with something called phase in and phase out profiles (although users prefer not to use this functionality), but this, unfortunately, requires the creation of often thousands of profiles.

We have first-hand experience-configuring DP and in troubleshooting the application and we do not think it is possible to get very much from the application, and it is even more challenging to maintain the application after the consultants leave. In addition to all of this, SAP DP has the most extended implementation timelines of any forecasting application that we cover, as well as having the most frequent re-implementations of the software. Some clients have asked us if future versions of SAP DP will be better. In fact, we have been asked these questions regarding SAP DP for around seven years now. However, DP has stabilized, and most of the development is going into other modules in APO such as SPP and EWM. Furthermore, development effort seems have been pulled away from APO in general, as other areas such as Hana have increased in importance for SAP versus advanced planning. This, unfortunately, leaves a lot of broken functionality in APO that may never actually get fixed.

For companies that have don’t have SAP DP, the best move is not to purchase it. What to do if your company has purchased it is covered in our Project Planning Package for SAP APO DP.

MUFI Scores

All scores out of a possible 10.

Vendor and Application Risk

Software Decisions Risk Defined: (See This Link for Our Categorization of Risk)

SAP DP has all types of functionality problems, which are aside from just the Data Warehouse Workbench, and companies that use SAP DP are dissatisfied with the product, and when we review SAP DP implementations, the implementing company is almost always forecasting at a very low level of sophistication.

When we interview customers of DP that are live with DP, we are unable to find a single satisfied account, and while DP may be running on an account, we see that most users are exporting the data and then performing forecast adjustments with Excel. Consultants are repeatedly brought in to fix DP, but both SAP and their partners in crime the major consulting companies hide the universality of problems with DP from clients.

Likelihood of Implementation Success

This accounts for both the application and vendor-specific risk. In our formula, the total implementation risk is application + vendor + buyer risk. The buyer specific risk could increase or decrease this overall likelihood and adjust the values that you see below.

Risk Definition

See this link for more on our categorizations of risk. We also offer a Buyer Specific Risk Estimation as a service for those that want a comprehensive analysis.

Risk Management Approach

The best approach to implementing SAP DP is to keep expectations low and keep the configuration as simple as possible. One approach we have recommended many times is to combine DP with a far less expensive application that is much more capable than SAP DP, and then to integrate the applications. Demand Works Smoothie, and Forecast Pro are two good examples of applications that can be used, as A) they are both capable forecasting systems, and B) they are inexpensive and therefore it can be justified to have another demand planning application in addition to SAP DP. Both applications are quite functional in many areas that are DP’s weaknesses. A perfect example of this attributes and in hierarchies. We have done this several times, and if you require solution architecture assistance and how to configure these systems to work together contact us.

Finished With Your Analysis?

To go back to the Software Selection Package page for the Demand Planning software category. Or go to this link to see other analytical products for SAP APO DP.

References

Brightwork Forecast Explorer for Error Calculation

Improving Your Forecast Error Management

Did you know that most companies don’t know what their forecast error is? If a company knows an error percentage but not the interval or the aggregation level measured, that means they don’t know. Most forecasting applications make getting a weighted forecast error extremely difficult. That is why we developed a SaaS application that allows anyone to find out their forecast error with a simple file upload.

The Brightwork Forecast Explorer is free to use in the beginning. See by clicking the image below:

Software Selection Book

SELECTION

Enterprise Software Selection: How to Pinpoint the Perfect Software Solution Using Multiple Sources of Information

What the Book Covers

Essential reading for success in your next software selection and implementation.

Software selection is the most important task in a software implementation project, as it is your best (if not only) opportunity to make sure that the right software—the software that matches the business requirements—is being implemented. Choosing the software that is the best fit clears the way for a successful implementation, yet software selection is often fraught with issues and many companies do not end up with the best software for their needs. However, the process can be greatly simplified by addressing the information sources that influence software selection. This book can be used for any enterprise software selection, including ERP software selection.

This book is a how-to guide for improving the software selection process and is formulated around the idea that—much like purchasing decisions for consumer products—the end user and those with the domain expertise must be included. In addition to providing hints for refining the software selection process, this book delves into the often-overlooked topic of how consulting and IT analyst firms influence the purchasing decision, and gives the reader an insider’s understanding of the enterprise software market.

This book is connected to several other SCM Focus Press books including Enterprise Software TCO and The Real Story Behind ERP.

By reading this book you will:

  • Learn how to apply a scientific approach to the software selection process.
  • Interpret vendor-supplied information to your best advantage. This is generally left out of books on software selection. However, consulting companies and IT analysts like Gartner have very specific biases. Gartner is paid directly by software vendors — a fact they make every attempt not to disclose while consulting companies only recommend software for vendors that give them the consulting business. Consulting companies all have an enormous financial bias that prevents them from offering honest advice — and this is part of their business model.
  • Understand what motivates a software vendor.
  • Learn how the institutional structure and biases of consulting firms affect the advice they give you, and understand how to properly interpret information from consulting companies.
  • Make vendor demos work to your benefit.
  • Know the right questions to ask on topics such as integration with existing software, cloud versus on-premise vendors, and client references.
  • Differentiate what is important to know about software for improved “implement-ability” versus what the vendor thinks is important for improved “sell-ability.”
  • Better manage your software selection projects to ensure smoother implementations.

Buy Now

Chapters

  • Chapter 1: Introduction to Software Selection
  • Chapter 2: Understanding the Enterprise Software Market
  • Chapter 3: Software Sell-ability versus Implement-ability
  • Chapter 4: How to Use Consulting Advice on Software Selection
  • Chapter 5: How to Use the Reports of Analyst Firms Like Gartner
  • Chapter 6: How to Use Information Provided by Vendors
  • Chapter 7: How to Manage the Software Selection Process

Solution Architecture Package – 100% SAP Versus 100% Best of Breed Calculator

Introduction

It is commonly stated that tier 1 ERP systems are very advantageous, particularly for large buyers. One of the reasons that is often presented is that using both tier 2 ERP systems as well as other applications from the same software vendors saves buyers money – and in fact, that while it is well recognized that the major vendors provide inferior functionality to best of breed vendors (although the term “inferior” is rarely used), the trade off of accepting this inferior functionality is well worth it when one considers the substantial cost savings that are assumed to be available from buying most of one’s software from one vendor. This is the standard logic presented by both large software vendors and large consulting companies that are essentially their partners. Most often the single software vendor is either SAP or Oracle, but other software vendors such as Infor, which have grown through acquisitions, will make essentially the same argument to their potential buyers.

Software vendors will often grow because they anticipate that the profit margins available for them, if they can offer “full suites”, is higher significant than if they provide more narrow and targeted solutions. As is explained in our book Gartner and the Magic Quadrant: A Guide for Buyers, Vendors, and Investors, IT analysts also tend to promote large software vendors as more stable and preferred vendors for their readers. In fact, because of how the Magic Quadrant is configured, the simple act of one software vendor acquiring another software vendor will move the acquired vendor’s products up in the ranking because so much of Gartner’s Magic Quadrant criteria are merely a proxy for the size of the software vendor.

The (Lack of) Evidence for the Single Vendor Hypothesis

While the logic or reasoning presented above has been highly influential and purchasing decisions for decades, in our research we could find no entity that every demonstrated, or even attempted to quantify the total cost of ownership for following a single vendor approach versus a best of breed approach. Considering how commonly the logic of the single software vendor purchasing strategy is invoked, we found this curious. Before reviewing our quantification of this issue, several characteristics of the single vendor argument should be understood.

  1. Financial Bias: Most of the entities that propose the single vendor argument have a financial bias. They are either large vendors with many applications, and therefore the advice they provide to purchase as much software from a single vendor (that vendor curiously enough always being “them”) is self-serving. The other major proponents of this purchasing strategy are large consulting companies. However, they have built their IT consulting practices around specific large vendors, and have resources trained in the applications of the large vendors. SAP and Oracle trade away a great deal of their consulting business to the major consulting companies in return for recommendations to purchase their software to the client of the major consulting companies.
  2. No Attempt to Provide Evidence: The single vendor argument neither has any evidence to support it nor do any studies exist to support it. Furthermore is not designed to be proven or disproven, it is instead part of a marketing program to increase sales of the software vendor and the consulting companies that propose the hypothesis.
  3. The Research Problem: No entity that would be traditionally relied upon to perform research on this topic would be able to complete the study without financial bias influencing their results, as they are in some way compensated by the large software vendors. For instance, even IT publications receive a disproportionate percentage of their advertising from either large software vendors or large consulting companies – both of which would push against any research which showed that the single vendor approach was less effective/more costly (etc.) than a more diverse approach. Publishing such research would be an excellent way to have one’s advertising revenues cut. Entities do not publish research, which contradicts their financial model. The one entity that could research this topic is the academic system, and there is no record of this type of research every being performed by an academic institution or published in an academic journal. This should not be surprising; academics do not investigate every issue that is of interest in the industry.

This Analysis and Assumptions

This analysis is based upon the individual application TCO Calculators that we sell as individual detailed analysis that breaks down the TCO into software, hardware, implementation and maintenance costs. This 100% SAP Versus 100% Best of Breed Calculator brings the analysis up a level of abstraction and only lists the overall TCO of each application – but lists the TCO for multiple applications, and then compares competing solution architectures. In our application TCO Calculators, there are inputs, which change the predicted TCO including the sophistication level of the implementation and the degree of customization among other factors. To produce an apples to apples comparison as well as to simplify the analysis, all applications are listed as their purest state.

  1. The Uniqueness of Analysis: This is the only analysis of this kind that we are aware exists. We believe we are the only source that compares the costs of the single vendor strategy versus the best of breed strategy in a published form.
  2. The Underlying Research: The TCO analyses are based upon rigorous and detailed analysis of each application. This is a bottom-up analysis where first the TCO is estimated for each TCO component, then added per cost category, and then finally aggregated to account for the overall TCO. For those interested in the detail below that shown in this analysis for any specific application, we recommend our application specific TCO calculators. Those offerings have adjustments that can allow them to be matched to the actual implementation environment.
  3. Estimated Integration Costs: We do not break out integration costs separately. A primary reason for this is that when dealing with software vendors, they also do not break out integration costs. But instead, they quote the overall implementation effort. Therefore integration costs are included in the overall TCO costs.

The Comparisons

Our first comparison shows all SAP applications versus all best of breed applications. The first comparison, or Alternate One, which follows, has no ERP system but instead uses a best of breed application in each category. In our 100% best of breed application grouping, Rootstock would perform the non-financial ERP functions, and Intacct would provide the financial functionality. Arena Solutions provides bill of materials and PLM functionality, which is much greater than any similar functionality inside of an ERP system.

Alternate One - 100% SAP VS 100% Best of Breed (Small to Medium)

CategoryApplicationTCOUser #
Total$ 48,292,838324
ERPSAP ERP/ECC/R/3$ 27,895,000200
Financial & AccountingSAP ERP/ECC/R/3Costs Accounted for in ERPCovered by ERP
Inventory ManagementSAP ERP/ECC/R/3Costs Accounted for in ERPCovered by ERP
Bill of Materials/PLMSAP ERP/ECC/R/3*Costs Accounted for in ERP Covered by ERP
Demand PlanningSAP DP$ 4,367,87612
Supply PlanningSAP SNP$ 3,272,58012
Production PlanningSAP PP/DS$ 4,078,70010
Business IntelligenceSAP BI/BW$ 6,430,23040
CRMSAP CRM$ 2,405,95250

*Bill of materials/PLM functionality exists in SAP ERP, but only the bare minimum necessary to support accounting and MRP. Therefore it is listed above as partially covered by the ERP system. However, we do not recommend attempting to manage the bill of materials in any ERP system. 

CategoryApplicationTCOUser #
Total$ 21,791,622311
ERPN/AN/AN/A
Financial & AccountingIntacct$ 3,218,40075
Inventory ManagementRootstock$ 4,350,500100
Bill of Materials/PLMArena Solutions Arena PLM$ 1,167,47212
Demand PlanningDemand Works Smoothie$ 1,167,47212
Supply PlanningToolsGroup$ 2,726,90012
Production PlanningPlanetTogether$ 1,479,60510
Business IntelligenceTeradata$ 5,440,95640
CRMSalesforce Enterprise$ 2,191,20550

This analysis is for a small to medium sized environment with a total of roughly 300 users.

We have selected some of the better value best of breed applications. As one can see the cost savings by TCO is quite significant.

Now we will show the same applications for a larger environment.

Alternate One - 100% SAP VS 100% Best of Breed (Large)

CategoryApplicationTCOUser #
Total$ 113,332,4251330
ERPSAP ERP/ECC/R/3$ 67,625,688800
Financial & AccountingSAP ERP/ECC/R/3Costs Accounted for in ERPCovered by ERP
Inventory ManagementSAP ERP/ECC/R/3Costs Accounted for in ERPCovered by ERP
Bill of Materials/PLMSAP ERP/ECC/R/3*Costs Accounted for in ERP Covered by ERP
Demand PlanningSAP DP$7,294,80130
Supply PlanningSAP SNP$ 5,803,72630
Production PlanningSAP PP/DS$ 4,971,07720
Business IntelligenceSAP BI/BW$ 21,892,800300
CRMSAP CRM$ 5,744,334150

This analysis is for a larger environment with a total of roughly 1300 users.

CategoryApplicationTCOUser #
Total$ 63,197,5211314
ERPN/AN/AN/A
Financial & AccountingIntacct$ 9,667,936300
Inventory ManagementRootstock$ 13,340,810400
Bill of Materials/PLMArena Solutions Arena PLM$ 5,152,85284
Demand PlanningDemand Works Smoothie$ 2,665,12830
Supply PlanningToolsGroup$ 3,804,80730
Production PlanningPlanetTogether$3,531,95120
Business IntelligenceTeradata$ 19,289,704300
CRMSalesforce Enterprise$ 5,744,334150

There is some user aggregation on the SAP side because multiple user licenses fall under the same overall ERP application. Again the cost savings by TCO is quite significant. It is less of cost savings than applying the best of breed strategy in the smaller environment. 

Conclusion

According to our research following a single vendor, strategy is not only more expensive than following a best of breed strategy but is significantly more expensive. It also is important to be emphasized that this analysis included all integration costs. However, even if they had been left out, it is impossible that the costs of the best of breed strategy would have come anywhere near the costs of the single vendor strategy.

Other critical points – in addition to the cost analysis presented above is that the best of breed strategy results in the following attributes:

  1. Much Higher Functionality: All of the large vendors score significantly below the best of breed vendors. The more software is purchased from one vendor; the more uncompetitive the overall grouping of software will be.
  2. Much Lower Implementation Risk: Targeted best of breed solutions have lower risk than software purchased from a single vendor. It’s not hard to see why. Best of breed applications are a better natural fit for the implementation environment and require far less customization. The traditional way to manage risk is to listen to advice from major consulting companies and to purchase software from major vendors. This does reduce the perception of risk, or the political implications of a failed implementation as the executive can say “We bought from SAP and used Accenture – what else can one do?” However, this strategy increases the probability that any one implementation will fail.

Our analysis leads to the conclusion that the official logic of purchasing from a single software vendor is flawed, and that it is flawed in every dimension – cost being just one dimension that it turns out to not be true.

Our TCO studies show, and it is no great secret, that vendors with the broadest product lines have the highest TCOs. Furthermore, broad product lines do not just sit on one platform or use one database. The applications have adapters that connect the applications, in the same way, that best of breed vendors have adapters. Of course, the major software vendors have advantages in integration as they own all the applications when a buyer follows a single vendor purchasing strategy – but these hypothetical benefits are not anywhere near as significant as generally thought, and cannot come close to making up for the higher TCOs of large software vendors. It should not be surprising that when one purchases software from vendors that have the highest TCOs per application, that a buyer’s overall enterprise-wide TCO will also be higher.

This is not to say no applications should be purchased from large software vendors – only that the proposal that buyers should purchase their applications from a single vendor to reduce costs and to reduce implementation risk is not supported by research. Our research shows exactly the opposite that buyers should pick and choose the best software from the best application provider.

We have analyzed this issue from multiple dimensions, and it is difficult to see how the single vendor strategy is even a serious proposal. Our best guess is that it simply began as marketing hyperbole proposed by large vendors, and developed a life of its own after this point. It is repeated merely without anyone noticing that it only would make sense if integration costs were truly enormous. This is apparently without anyone seeing that the logic is repeated merely without ever evidence provided to support the claim.

Enterprise Software TCO Calculator – SAP APO DP

How it Works

Fill out the form below for a your TCO estimate. The form does not have a “beginning or end.” The form is constantly calculating, so feel free to make constant changes and the application will auto-adjust.

Details

  • Vendor Name: SAP (See for Vendor Rating)
  • Software Category: Demand Planning
  • Company Headquarters: Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany
  • Site: http://www.sap.com
  • Contact number: 49.6227.747474
  • Delivery Mechanism: On Premises

Finished With Your Analysis?

Once complete, goto this link to see other analytical products for SAP DP.

Project Planning Package – SAP APO DP

How it Works

Fill out the form below for your project planning estimate. The form does not have a “beginning or end.” The form is constantly calculating, so feel free to make constant changes and the application will auto-adjust.

Details

  • Vendor Name: SAP (See for Vendor Rating)
  • Software Category: Demand Planning
  • Company Headquarters: Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany
  • Site: http://www.sap.com
  • Contact number: 49.6227.747474
  • Delivery Mechanism: On Premises

Finished With Your Analysis?

Once complete, go to this link to see other analytical products for SAP DP.

References

Risk Book

Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

Better Managing Software Risk

The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.

Finding What Works and What Doesn’t

In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.

Chapters

Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model

Software Category Analysis – Demand Planning

Introduction

When forecasting applications were first developed external to the ERP system, a narrow spectrum of applications was developed for demand planning and these were primarily designed for the statistical forecasting process. However, statistical forecasting is only one of several forecasting processes, and over the years the variety of demand planning applications has increased significantly. Therefore, attempting to force all of a company’s forecasting needs through a single application is no longer necessary or desirable. The diagram below represents the various forecasting processes:

Major Forecasting Processes

A common mistake companies seem to make is trying to use statistical forecasting packages to manage the other forecasting processes. Part of the reason that companies do this is because both the major vendors (who tend to only offer statistical packages) and the major consulting companies incorrectly advise companies that statistical demand planning software can be used to manage non statistical process forecasting. This analysis package will primarily be focused on statistical forecasting applications, but where the application can branch out into other areas, we will point this out.

It is important to understand where demand planning fits among the different supply chain applications, as shown in the graphic below.

Common Supply Chain Application Categories Demand Planning

Demand planning one of the major categories of supply chain software. When companies implement an external supply chain planning module to be connected to their ERP system, they most often start with demand planning.

If you read most forecasting books they tend to focus very heavily on the mechanics of forecasting. They talk about forecasting methodologies (simple exponential smoothing, regression, etc.), however not enough get into the business process or how forecasts are used in real life. The first wave or generation of applications leveraged the ability to place not so sophisticated and quite sophisticated forecasting methods in software. These applications had high failure rates because they were generally not designed to be easily implemented or easily maintained. Applications in this category are what we refer to as first generation advanced planning products. A good marker of a first generation advanced planning forecasting application was if it expended most of the development effort in the application of complex methods and would often have a proprietary forecasting algorithm. During the period when first generation the prevailing wisdom was that the application mostly came down to how complex forecasting methods could be applied in an automated fashion. This period in software, which has been the dominant software development approach lead to some very bad habits. In fact, there little evidence that sophisticated mathematics can improve the forecast of difficult-to-forecast products, and this is a problem. Some studies do not show improvement from more advanced methods, but firstly the improvement is never very large, and secondly other studies come by later to contradict the original studies. In addition, complex methods should have to exceed a higher bar. Academics can apply complex methods in a laboratory environment over a few products far more easily than can be done by industry. This fact, along with the point that sophisticated methods are much more expensive for industry to implement than simple methods, is rarely mentioned. This point is made very well by J. Scott Armstrong:

Use simple methods unless a strong case can be made for complexity. One of the most enduring and useful conclusions from research on forecasting is that simple methods are generally as accurate as complex methods. Evidence relevant to the issue of simplicity comes from studies of judgment (Armstrong 1985), extrapolation (Armstrong 1984, Makridakis et al. 1982, and Schnaars 1984), and econometric methods (Allen and Fildes 2001). Simplicity also aids decision makers’ understanding and implementation, reduces the likelihood of mistakes, and is less expensive.

This idea, that forecasting software just came down to most sophisticated forecasting algorithm has been incredibly durable, especially since the research into this area clearly demonstrates that when actually implemented (that is not in a controlled academic environment where only a small number of items are being forecasted), more complex methods have a hard time defeating simple methods. The major limiting factor that companies face in leveraging forecasting functionality? That would be getting these types of applications to be understandable and to work consistently. That is making them easier to use. Unfortunately, statistical forecasting software vendors do not tend to compete on the basis of how easy their applications are to use, instead the competition tends to center around the sophistication of the mathematics that is within the forecasting methods. Having covered this subject extensively and worked in the field for quite a few years, we can say with confidence that simply having sophisticated mathematical forecasting algorithms/methods within the application is nowhere near enough to obtain consistent forecast accuracy. This leads many companies to have a false sense of security with regards to their statistical forecasting application – and it leads to companies asking themselves “We have statistical forecasting software, why can’t we get a decent forecast?” A certain cynicism has crept into statistical forecasting – however, forecasting is a disciplined endeavor and many implementing companies are not used to performing the type of data accuracy and discipline and testing that is required for forecasting. Forecasting vendors have also been responsible for overselling the ease by which a forecast can be improved by a system without the required work. Finally, many forecasting software vendors have been let down by major consulting companies who seem to primarily be able to staff IT resources for forecasting – that can configure the system, but lack very much experience or an understanding of forecasting beyond textbook knowledge.

Attribute-based Forecasting

Attribute-based forecasting is one of the most important developments since enterprise demand planning software began being used. I know this is a big statement to make, but I make it based upon research into the history of demand planning and in light of my research I am quite confident that my statement is true. After one uses an application capable of attribute-based forecasting, it’s difficult not to come to the same conclusion. And perhaps most interesting is the fact that attribute-based forecasting is still only used in a minority of companies (even though so many vendors say their applications are good at dealing with attributes). Attribute-based forecasting can allow different groups and departments to perform forecast aggregation as they are interested in seeing the data, and does not require that one single static hierarchy be used for all users. With attribute-based forecasting systems, the implementation approach for forecasting and analytic projects, which currently focuses on the technical details of complex database setup, can be changed. Instead of explaining the concept of realignment and spending seemingly endless hours debating what the “one” static hierarchy should be, that time can now be refocused onto determining and explaining how the business can get the most out of the forecasting application. This is an enormous benefit to forecasting system implementation projects, which have tended—along with many other supply chain planning software implementations—to become overly technical affairs with more emphasis on meeting deadlines and IT objectives than on adding value to the business.

Is the Word Out on Attribute-based Forecasting?

I cannot find a good explanation for why the term is searched for in search engines so infrequently. According to SEOMoz.com, the number of searches typed into Google per month for either the term “attribute forecasting,” or “attribute-based forecasting” or other derivations of these terms is negligible. There few Internet articles on this topic as well. Even a search through Google Books does not bring many results (this is usually a very comprehensive way to search for a topic). Attribute-based forecasting may not be used that commonly now; but I predict it will be in the future.

Forecast Disaggregation

Every statistical forecasting vendor that I am aware of states that they can perform forecast aggregation and disaggregation; however, there is a large gap between statistical forecasting vendors in terms of capability. This functionality is too important for clients to simply accept the statement from a vendor that “our product can do that.” In fact, aggregation and disaggregation should both be extensively demonstrated and tested by the company’s planners prior to selecting an application for purchase, in order to discern how easy the aggregation functionality is to use in competing systems. Aggregation and disaggregation capability cannot be an afterthought. Instead these capabilities must be designed into the application from the database layer up. The following quote on this topic is instructive.

Demand Sensing

We point out all trends in each software category that we cover, the valid and invalid. One of the invalid trends that we have been tracking is called demand sensing. The information on the definition of demand sensing is currently and primarily controlled by software vendors. Demand sensing did not come out of the academic community, so there have been few unbiased descriptions of what demand sensing is. Demand sensing is the adjustment of forecasting inside of the lead-time of the product, and therefore when the supply plan cannot respond. If our lead-time is 2 weeks, then demand sensing means changing the forecast less than 14 days out. Demand sensing is the adjustment of forecasting inside of the lead-time of the particular product, and therefore when the supply plan cannot respond. Because demand sensing changes the forecast within the lead-time, demand sensing cannot be considered a forecasting approach. To understand this, its important to understand that while broadly speaking a forecast is a prediction of a future event; in practical terms a forecast is a prediction of a future event that is given with sufficient advanced notification to be worthwhile. For instance, a forecast could be improved for a football game by waiting until 1/2 the game is over. However, when half the game is over, it’s too late to place a bet on the game. Therefore the forecast is not particularly useful because it occurs within the lead-time of when a some benefit from be received from it. The forecast of the game could be further improved by waiting until the minute before the game ends, but again its hard to see how anyone would accept this as a forecast. One could not want to compare the forecast accuracy of a person who forecasts games while in progress versus those that forecast the game before the game begins. This of course brings up the topic of demand sensing and forecast accuracy “improvement.”

So Where Does Demand Sensing Belong?

Instead, it is a method of creating the illusion of improving the forecast accuracy by change the forecast in way that can never translate into an improvement in supply chain performance. This is extremely appealing to any demand planning group that cannot meet its forecasting goals (which is not to say they are realistic or unrealistic).  Interestingly, the vast majority of articles on demand sensing describe it as a method of improving the forecast, and categorize it as a forecasting approach. While its true that forecast accuracy can be improved by waiting until the last minute, this is blurring the line of what forecasting actually is. Vendors and IT analysts like Gartner have completely confused the issue by combining demand sensing with demand shaping.

The list of basic things that most companies cannot do in their forecasting systems is often amazing. A company that should start with doing proven things like those above to improve the forecast, will instead choose to go with the latest “trend,” and buy demand sensing software. They prefer to use an approach that is untested and has no academic research to support the contentions that the vendors in this area (notably Terra Technologies and SAP) make about it.

Software Category Summary

All companies would like to improve their forecast accuracy. Forecasting continues to be one of the great areas of opportunity within companies. Many companies are still using some combination of ERP (which is not a good platform for forecasting) combined with Excel. This is a difficult way to improve forecast accuracy. There have been many mistakes made on demand planning projects, and gaining value from a demand planning application means analyzing those mistakes and adjusting the implementation methodology. Application of the same approaches will lead to the same outcomes.

Overall this software category has several very compelling applications, and also a growing application where we are not sure how it will develop in the future.

The links to the specific research you have paid for is included at the beginning and end of this Software Category Analysis. You will only be able to access the pages that apply to your subscription.

MUFI Rating & Risk

See the MUFI Ratings & Risk below for all of the applications we cover.

Vendor NameApplication
Big ERP
SAPMUFI Rating & Risk – SAP ECC
OracleMUFI Rating & Risk – JD Edwards EnterpriseOne
EpicorMUFI Rating & Risk – Epicor ERP
SageMUFI Rating & Risk – Sage X3
InforMUFI Rating & Risk – Infor Lawson
Small and Medium ERP
SAPMUFI Rating & Risk – SAP Business One
OracleMUFI Rating & Risk – JD Edwards World
ProcessProMUFI Rating & Risk – ProcessPro
RootstockMUFI Rating & Risk – Rootstock
ERPNextMUFI Rating & Risk – ERPNext
OpenERPMUFI Rating & Risk – OpenERP
MicrosoftMUFI Rating & Risk – Microsoft Dynamics AX
Financial Applications
IntacctMUFI Rating & Risk – Intacct
IntuitMUFI Rating & Risk – Intuit Quickbooks Enterprise Solutions
FinancialForceMUFI Rating & Risk – FinancialForce
NetSuiteMUFI Rating & Risk – NetSuite OneWorld
PLM
SAPMUFI Rating & Risk – SAP PLM
Arena SolutionsMUFI Rating & Risk – Arena Solutions Arena PLM
Hamilton GrantMUFI Rating & Risk – Hamilton Grant Recipe Management
Demand Planning
SAPMUFI Rating & Risk – SAP APO DP
TableauMUFI Rating & Risk – Tableau (Forecasting)
Business Forecast SystemsMUFI Rating & Risk – Forecast Pro TRAK
Demand WorksMUFI Rating & Risk – Demand Works Smoothie
JDAMUFI Rating & Risk – JDA Demand Management
ToolsGroupMUFI Rating & Risk – ToolsGroup SO99 (Forecasting)
Supply Planning
SAPMUFI Rating & Risk – SAP SNP
SAPMUFI Rating & Risk – SAP SmartOps
ToolsGroupMUFI Rating & Risk – ToolsGroup SO99 (Supply Planning)
Demand WorksMUFI Rating & Risk – Demand Works Smoothie SP
PlanetTogetherMUFI Rating & Risk – PlanetTogether Galaxy APS Superplant
Production Planning
SAPMUFI Rating & Risk – SAP APO PP/DS
DelfoiMUFI Rating & Risk – Delfoi Planner
PreactorMUFI Rating & Risk – Preactor
AspenTechMUFI Rating & Risk – AspenTech AspenOne
PlanetTogetherMUFI Rating & Risk – PlanetTogether Galaxy APS
BI Heavy
SAPMUFI Rating & Risk – SAP BI/BW
SAPMUFI Rating & Risk – SAP Business Objects
OracleMUFI Rating & Risk – Oracle BI
SASMUFI Rating & Risk – SAS BI
MicroStrategyMUFI Rating & Risk – MicroStrategy
IBMMUFI Rating & Risk – IBM Cognos
TeradataMUFI Rating & Risk – Teradata
ActuateMUFI Rating & Risk – Actuate ActuateOne
BI Light
SAPMUFI Rating & Risk – SAP Crystal Reports
QlikTechMUFI Rating & Risk – QlikTech QlikView
TableauMUFI Rating & Risk – Tableau (BI)
CRM
SAPMUFI Rating & Risk – SAP CRM
OracleMUFI Rating & Risk – Oracle RightNow
OracleMUFI Rating & Risk – Oracle CRM On Demand
InforMUFI Rating & Risk – Infor Epiphany
Base CRMMUFI Rating & Risk – Base CRM
SalesforceMUFI Rating & Risk – Salesforce Enterprise
SugarCRMMUFI Rating & Risk – SugarCRM
MicrosoftMUFI Rating & Risk – Microsoft Dynamics CRM
NetSuiteMUFI Rating & Risk – NetSuite CRM