The Oracle Value Chain Planning Specialists

Basic Demantra Analytics Concepts –

Input Data Overview

Demand Management

Copyright © Inspirage 2011 Private and confidential. All rights reserved Page 1
The Oracle Value Chain Planning Specialists
 Data Overview

• This document will discuss basic data requirements for a reasonable

statistical forecast.

• The data requirements for DM (and AFDM) and PTP implementations will
be discussed separately

The Oracle Value Chain Planning Specialists

Demand Data Stream
• Demantra can handle any form of demand stream: (i) POS (Point of Sale) (ii) Orders
and (iii) Shipments

• It is good to have POS data since it represents the true end customer data; But, in

most of the implementations it is hard to obtain data at the POS level

• However, POS data is not always the right input. POS data serves best when we
need to forecast at the retailer or the store level.

• When the purpose of Demand Forecasting is to plan for inventory at the DC level,
we need to be forecasting demand and demand variability at the DC level. Having
POS data at downstream stores is not going to be helpful, especially if the stores are
not within the control of the company holding the DC
The Oracle Value Chain Planning Specialists
 Why is POS not always the right data
• When Planning upstream in the supply chain (DC/ShipFrom/Production Plant), we
need to know the demand at that point in the supply chain
• Having POS data downstream is not helpful, as this needs to be converted to
upstream demand data. The difficulties that could come in
– Would have to take into account lead times. Demand on Day x down stream in the supply
chain would have materialized as Demand on Day x – n upstream in the Chain
– Lead times would be different by DC. Even within the same DC, demand streams from
different end customers would have different lead times.
– Even if lead times are known, end customers might not be operating in a 100% demand
driven lean environment. In other words, while placing orders they would be hedging for
uncertainty and adding in a safety stock/buffer component to their demand. So a POS
quantity of X would not translate to a DC order X, n days (lead time) prior
– Different end customers might have different inventory and replenishment planning logic
and so this further muddles the picture

The Oracle Value Chain Planning Specialists

 Demand Stream Suggestion
• POS Data
– When planning location is Retailer or Store
– VMI Implementations
– Essentially when the planning location represents the place where end customer demand
happens

• Order Data
– When planning location is upstream of the supply chain
– Example – Customer-DC, Ship From DC, Production Plant etc
– However Order data might not be available at all times.
– In a lot cases, the data we might have is Shipment data. Shipment data is not often a
healthy proxy to order data for reasons we would discuss on the next slide

The Oracle Value Chain Planning Specialists

 Issues With Shipment Data
• Shipment Data is Supply Chain constrained data.
– Shipment Dates: Due to Supply chain constraints like inventory unavailability,
the shipment might have been made later than when it was requested for. If, we
are planning on using the forecasts for things like Production Planning or
Inventory or Replenishment Planning, it is better that we use Planned Shipment
dates instead of actual shipment dates

– Shipment Locations: Due to Supply chain constraints like inventory

unavailability, the shipment might have been done from a different
ShipFrom(DC) location than the intended one. This needs to be rectified and the
shipment mapped back to the original shipment location. Not rectifying this can
result in the tool trying to forecast the demand at the ‘wrong’ location, thereby
leading to more inventory being piled up at this location, thereby leading to more
orders being shipped from the alternate location
The Oracle Value Chain Planning Specialists
 DM/AFDM – Some Data Pointers
• History Length: It is good to have at least 2 years in the case of seasonal parts or
parts that have holiday dependencies. It is advised that we have at least 2 data
points for every causal factor that we consider in the system.

• Intermittency: At the lowest level of forecast (min_fore_level) history should not be

extremely sporadic/intermittent. If the history is very unstable at the lowest, re-check
business reasons for identifying this to be the lowest level at which forecast should
be generated.

• Causal Factors: The Causal Factor history should be in sync with Sales History. For
example, it is not optimal to have 2 years of sales history and only 1 year of price or
event history. This will lead to bad correlation.

The Oracle Value Chain Planning Specialists

 PTP – Some Data Pointers
• Length of Sales Data and Promotion Data: This is a typical issue in PTP
implementations. We might have Sales/Shipment history available for 2 or more
years, but promotion data (with causal factor values) populated only for the last one
year. In such cases, having the extra year of sales data really does not help and in
fact would be detrimental in that the engine will treat these buckets as non
promotional periods and use the values for baseline estimation (leading to potentially
inflated baselines).

• Disconnects Between Sales Data and Promotion Data: This is another typical
issue in PTP implementations. The consultants should eyeball the data and ensure
that whenever a promotion data is recorded, it ties in with a sales uplift in the sales
data table. There is bound to be some level of disconnects, but it should not be
glaring/predominant.

The Oracle Value Chain Planning Specialists

 PTP – Some Data Pointers
• Promotions with No uplifts: This might/might not be an issue resulting from the
earlier cause. Either way, a promotion should typically result in a sales peak.
Absence of a sales peak either points to data invalidity or to the in-effectiveness of
the promotion. If latter, it would be beneficial to discuss these promotions with the
business users.

• Uplifts with no promotions: This might/might not be an issue resulting from the
earlier cause. For a non-seasonal sku we should typically not see a sales peak
(especially if it is POS data) unless there were some promotions (that caused odd
buying patterns). In any case, the consultant should collect such records and discuss
with the business users as to whether promotions were potentially run during these
periods but have not been recorded in demantra due to some reason.

The Oracle Value Chain Planning Specialists

 PTP – Some Data Pointers
• Completeness of Promotional Attributes: This is again an issue in most of the
implementations. The business users might have decided on a set of promotion
causal attributes. However, it is quite possible that some/most of these attributes
have no data or have missing data. In such cases, the consultant on site would have
to discuss with the business team to come up with business rules to designate
default values for each of these attributes. .

The Oracle Value Chain Planning Specialists

Question & Answers?

Rajeev Shirguppi

rajeev.shirguppi@inspirage.com

Copyright © Inspirage 2011 Private and confidential. All rights reserved 11

The Oracle Value Chain Planning Specialists