Life Cycle Demand Planning in SAP DP Versus Demand Works Smoothie

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

Lifecycle planning in SAP DP is complicated to use. Lifecycle planning in a best of breed application called Demand Works Smoothie works quite a bit differently.
In this article, we compare and contrast how it works in both SAP and Demand Works.

Introduction

Life cycle planning is essential functionality for forecasting software. It also happens to be a serious problem area for support organizations attempting to provide practical life cycle capabilities to the user community. Comparing a few different applications in this area is illustrative.

In this article, I will compare SAP DP versus Demand Works Smoothie.

SAP DP

SAP DP has a cumbersome approach to lifecycle planning instead. DP uses something called phase in and phases out profiles. These profiles are used to increase or decrease the forecast. However, one problem with them is that so many are needed. An increase of 2% is one profile. A rise of 2.2% is another profile. I worked at an account that had over 6000 profiles and another with 11,000 profiles. When so much of something basic like this is required or at least setup, it brings up how well designed this functionality is. More about how DP deals with lifecycle planning can be discussed in this article.

How Are DP Phase-In, Phase-Out Profiles Assigned?

The concept of life cycle management in DP is that profiles will be assigned to the products, but this is difficult to maintain and a lot of manual work for the demand planners. Possibly aware of the base functionality weakness, SAP has introduced an Add-In called the APO Lifecycle Assistant, which is an additional charge. I have seen the screenshots of it, which look well put together, but have never worked at a client that implemented it, so I cannot vouch for it.

What Does It Do?

It allows a date to be entered when the product will be phased out.
It allows weights to apply a historical demand from one product (the predecessor) to another (the successor).

From what I have read about it, it is undoubtedly an improvement over phase-in, phase-out profiles. However, I am still not enthusiastic about it, and I certainly don’t think it’s a best practice in the software design of how to deal with the life cycle planning process. Add-ins are described in this article.

Using APO for Life-Cycle Planning

While the current process within APO DP does work, it takes far more time than is necessary and is overly manual. The project team estimates that it can be vastly improved upon if done within Smoothie.

Using DP for lifecycle planning has the following advantages and disadvantages.

Pros:

Reporting capabilities (everything is in one place)

Cons:

Only one person at a table at a time
Requires maintenance of multiple screens (selection IDs, LCP table)
Cumbersome process
Requires monthly maintenance (snapshots, date range changes)
Limited choice of Phase-In and Phase-Out profiles

Steps involved within APO DP:

Review titles history through reporting or visual analysis and decide on appropriate LCP assignment.
Insert title into the LCP table and LCP selection ID
Run title in interactive mode or wait till following stat run to see desired results

Because the representation of making different changes to the forecast with profiles is inefficient (increasing the forecast by 2% is one profile, increasing by 2.5% is another), there are many thousands of profiles that have been created and are maintained by the company. A screenshot of just one page of these profiles is listed here.

A related issue is that while these profiles are explicitly designed for a phase in – phase profiles because most planners at clients I have worked with are not comfortable with the limited DP user interface, these profiles are the primary mechanism for entering manual changes to the forecast. This is the proverbial “every problem looking like a nail if you only have a hammer.” More controls need to be used by planners to make manual changes to control the plan.

Life Cycle Planning in Demand Works Smoothie

There are several ways to manage lifecycle planning in Smoothie. The first is more of a one-off approach, while the second is a systematic way to apply life cycle changes to product groups.

Method 1: Copy Paste SpreadSheet Functionality in Smoothie for Life Cycle Planning

One way is by grouping the SKUs. You want to increase or decrease in value, copy the time series to a spreadsheet, make the percentage reduction or increase in Excel, and then copy the values back to the spreadsheet in the application data sheet view Smoothie.

However, this only persists the lifecycle out until the date you have selected to perform forecasting.

In Smoothie values, a single field or an entire row can be adjusted and imported from a spreadsheet. Data can be copied back as modified or increased by an absolute value with the Paste Multiply function.

Smoothie then asks you for a value to multiply the copied values by. To increase the values by 10%, one would type in 1.1 in this entry box.

Method 2: Setting Life Cycle as an Attribute

As is described in multiple articles on this blog, Smoothie’s flexible attribute-based forecasting can be used for various purposes. It is a generalized mechanism for grouping, and lifecycle planning is just another form of grouping. You are choosing to treat a group of products differently from the rest of the product database.

An attribute can be created very easily in Smoothie by simply adding a column to the import file titled “Life Cycle” and then populating it with the different categories or names that the company wants to apply to the product. Attribute values such as early-life, mid-life, late-life, soon to be obsolesced, etc.. could be assigned to each product and could be used as a useful grouping technique for lifecycle management.

Which is a Better Method of Life Cycle Planning?

I much prefer Smoothie’s approach here to SAP DP’s approach. So much so that I am recommending that clients stop trying to perform life cycle planning in DP as it is so much easier and more logical to do the same thing in Smoothie. This is applicable even if a company has committed to a big expensive application like SAP DP. This is not because it is not very complicated to integrate forecasting systems and because lifecycle planning is such a consumer of resources at so many companies I visit.

Demand Works already has several clients using Smoothie exactly this way, and the benefits are clear and evident to anyone who had some work in life cycle planning in the past.

Consensus vs. Statistical Life Cycle Planning

Statistical applications are far better known than consensus-based forecasting applications in the marketplace. Most consensus forecasting processes are performed using a statistical application because of errors in forecast software selection. Life cycle planning is required in both categories of forecasting applications, although this is not always the case.

Old products are 100% or nearly 100% statistically forecasted at some companies, while only new products are consensus forecasted. Therefore, consensus forecasting can be seen as the initial phase of the product lifecycle. When a product is in the later stages of its lifecycle, it would naturally no longer be in the consensus-based forecasting process. In these cases, the company may not require as much life cycle planning functionality in its consensus application.

Go to top

Conclusion

Life cycle planning is not that complicated, as long as you use the right tool. I would urge decision-makers in this space to reject complex and high maintenance systems and to feel justified in connecting small and inexpensive forecast applications that are naturally good at lifecycle planning to their central forecasting systems, and that this will result in better and lower maintenance life cycle planning overall.