Demand sensing = marketing tosh; nothing new or clever . . . I can't see evidence to the contrary.
Not to say, of course, that there is no benefit in getting an earlier feed of data on something such as demand, if - and only if - it can result in a better decision that is executed earlier than otherwise - giving an economic benefit.
The use cases do exist though. My (real) example is in the supermarkets world, specifically on the day that a new set of weekly promotions start. On this 'day one' of the promotional week regular and promotional pricing are reset, promotional 'aisle ends' are built as well as other changes in layout being implemented. For all the forecasting that is done beforehand, the actual sales by 11:00 on the first day provide a very accurate view of how all the changes - overlayed with each other - are being interpreted by the customer, resulting in sales. This early read on sales - which is net of all the inter-SKU relationships - 'could' result in a different POs being placed with suppliers a day earlier than if the daily sales were interpreted in an overnight batch process. This 'could' result in availability and sales better in line with demand, and fewer overestimates/overstocks in store which are also negative in terms store productivity. The challenge in this example is not so much 'the software' but rather the data flow and the timing of the execution of the calculation (e.g. purchase order calculation), in line with other time windows that need to be hit in order to get a PO out a day earlier. In this sense there is no difference between 'real time' and 'timely' - e.g. a batch process is perfectly OK as long as it can be executed quickly and when you need it.
Fully agree. The only case which might be relevant for "real time" data is dynamic repricing for SKUs pending stock out or promotion/discounting within the day for perishable goods. This might be relevant for e-groceries and other e-commerce businesses with tight competition where they closely tracking each other and have overlapping highly substitutable assortment.
For replenishment and purchasing "real time" data is overkill and waste of compute power. Daily batches are enough.
Q: Why a new buzzword if it's about repackaging techniques that already have proper names?
A: Occam Razor: to make the tech appear more attractive and valuable than it really is.
According to [1], SAP recognizes 'demand sensing' as 'a forecasting method that leverages [...] near real-time information to create an accurate forecast of demand'.
Why would a 'near real time' provides a forecast that is any less accurate than a batch forecast happening with a lag of, say, 10min?
Why should gradient boosting be even considered as a relevant technical solution for 'near real-time' tasks?
Remove demand sensing from the picture, and you still have the exact same tech with the exact same processes.
The 'real-time' part is an overstatement for sure. What they offer are batch job controlled short term (deterministic) forecasting.
All these buzzwords in planning/forecasting software is just annoying as a customer - its absolutely impossible to get a real sense of what's offered without some sort of PoC. Because only then you start to have the talks that shows, what's under the hood.
Demand sensing = marketing tosh; nothing new or clever . . . I can't see evidence to the contrary.
Not to say, of course, that there is no benefit in getting an earlier feed of data on something such as demand, if - and only if - it can result in a better decision that is executed earlier than otherwise - giving an economic benefit.
The use cases do exist though. My (real) example is in the supermarkets world, specifically on the day that a new set of weekly promotions start. On this 'day one' of the promotional week regular and promotional pricing are reset, promotional 'aisle ends' are built as well as other changes in layout being implemented. For all the forecasting that is done beforehand, the actual sales by 11:00 on the first day provide a very accurate view of how all the changes - overlayed with each other - are being interpreted by the customer, resulting in sales. This early read on sales - which is net of all the inter-SKU relationships - 'could' result in a different POs being placed with suppliers a day earlier than if the daily sales were interpreted in an overnight batch process. This 'could' result in availability and sales better in line with demand, and fewer overestimates/overstocks in store which are also negative in terms store productivity. The challenge in this example is not so much 'the software' but rather the data flow and the timing of the execution of the calculation (e.g. purchase order calculation), in line with other time windows that need to be hit in order to get a PO out a day earlier. In this sense there is no difference between 'real time' and 'timely' - e.g. a batch process is perfectly OK as long as it can be executed quickly and when you need it.
Fully agree. The only case which might be relevant for "real time" data is dynamic repricing for SKUs pending stock out or promotion/discounting within the day for perishable goods. This might be relevant for e-groceries and other e-commerce businesses with tight competition where they closely tracking each other and have overlapping highly substitutable assortment.
For replenishment and purchasing "real time" data is overkill and waste of compute power. Daily batches are enough.
Q: Why a new buzzword if it's about repackaging techniques that already have proper names?
A: Occam Razor: to make the tech appear more attractive and valuable than it really is.
According to [1], SAP recognizes 'demand sensing' as 'a forecasting method that leverages [...] near real-time information to create an accurate forecast of demand'.
Remove demand sensing from the picture, and you still have the exact same tech with the exact same processes.
[1] https://blogs.sap.com/2020/02/09/sap-integrated-business-planning-demand-sensing-functionality/
The 'real-time' part is an overstatement for sure. What they offer are batch job controlled short term (deterministic) forecasting.
All these buzzwords in planning/forecasting software is just annoying as a customer - its absolutely impossible to get a real sense of what's offered without some sort of PoC. Because only then you start to have the talks that shows, what's under the hood.
Fully agree. This is why I abhor those made-up terminologies: it's pure vendor shenanigan's.
Probabilistic forecasting should be considered as state of the art for supply chain planning.
Though, as we recently have shown it is doable to explain supply chain decisions optimization with use of probabilistic forecasts (we explained it using purchasing decisions) even in Excel:
https://www.linkedin.com/posts/alexey--tikhonov_supplychainmanagement-probabilisticforecasting-activity-6962747294081298432-T-OH?utm_source=share&utm_medium=member_desktop
If there is a substance behind Demand sensing - looking forward to see the Excel with simplified approach showing what value this approach adds.
Demand sensing article on Wikipedia:
https://en.wikipedia.org/wiki/Demand_sensing
Compare it with probabilistic forecasting for instance:
https://en.wikipedia.org/wiki/Probabilistic_forecasting