Demand sensing implementation: the tool is the easy part

supply chainforecastingproject managementreckitt benckiser

It's been almost a year since I moved to Paris to join Reckitt Benckiser France, and for a good part of that year I have been wearing two hats. On paper I am a Senior Demand Planner (Airwick, Veet, Dettol). In practice I am also leading the rollout of a new forecasting tool, a Demand Sensing solution, which is supposed to make our short term forecasts a lot sharper.

We are more or less halfway through. So this is a good moment to write down what I have learned so far, before I forget it or before the second half proves me wrong.

Short version: the software is not the hard part.

The tool is the easy part

When you start a demand sensing implementation, everybody talks about the tool. Which data goes in, how often it runs, how the algorithm weights recent orders against the statistical baseline, how the output flows back into the rest of the planning process. These are real questions and they take real work.

But they have answers. You sit down with the vendor and with IT, you draw the data flows on a whiteboard, you test, something breaks, you fix it, you test again. It's engineering. I studied engineering. I like this part.

What does not have a clean answer is this: who owns the number?

Three functions, three different priorities

The project involves more than 20 people across three functions: commercial, IT and logistics. Each of them is reasonable. Each of them has good reasons for what they want. And what they want is not the same thing.

  • Commercial wants the forecast to reflect their plans: promotions, listings, the deal they are closing with a retailer next month. A machine that "corrects" their number feels like a machine that doesn't trust them.
  • Logistics wants a number that is stable and early enough to plan production, warehouses and trucks. A forecast that moves every day, even if it is more accurate, is a headache for them.
  • IT wants something that runs reliably, fits into the existing systems and doesn't turn into a custom monster they will have to maintain forever.

Demand planning sits exactly in the middle of these three. That's probably why the project landed on a demand planner's desk and not somewhere else. It is also why I think no demand planning software, however good, will fix this by itself. The tool produces a number. The organization has to agree to use it.

The biggest mistake I made at the beginning was to present the project as "we are getting a better forecast". Nobody is against a better forecast, so everybody nodded. Then in the first real working sessions it became clear that everybody had a different idea of what "better" meant and, more importantly, of what would change in their week.

So I changed the pitch. Now I try to answer, for each function, one very boring question: what will you do differently on Monday morning once this is live? When that answer is clear, the meetings get shorter. When it isn't, we go around in circles, often in French, which for me makes the circles even longer.

Running a project while doing the day job

The other thing nobody really prepares you for is doing a cross-functional project management role while the day job doesn't stop. The forecasts still need to be done. Service level still matters. If a promotion goes wrong on Veet, nobody will accept "sorry, I was in a steering committee" as an excuse.

A few things that are working for me, more or less:

  • Protecting the planning cycle. The weeks of the monthly forecast cycle are sacred. Project meetings move around them, not the other way round.
  • Using the day job as a test bench. Since I am a user of the future tool myself, I can check every design decision against my own real work. If something would annoy me as a planner, it will annoy my colleagues too.
  • Writing decisions down. With three functions in the room, the same topic will come back three weeks later with a slightly different memory attached. A short written recap after each meeting saves a lot of arguments.
  • Talking to people one by one. Big meetings are good for confirming decisions, terrible for making them. Most of the real alignment happens at the coffee machine or in a 20 minute call before the meeting.

It is not perfect. Some weeks the project eats the day job, some weeks the opposite. I am also not sure I would recommend combining the two roles in general. On the other hand, I suspect a pure project manager, without the planning background, would have a harder time understanding why logistics gets nervous when the numbers move too much.

What I am watching in the second half

The technical risks are known and they have owners. What worries me more is adoption. There is a real chance we go live with a great tool and people keep overriding it with their old spreadsheets "just to be safe". I have seen this happen with other tools, and in supply chain forecasting the old spreadsheet always feels safer, because it's yours.

So the plan for the next months is less about configuration and more about trust: running the new forecast in parallel with the old process, showing commercial and logistics where it is right and where it is wrong, and agreeing upfront on the rules for when a human override is fine and when it isn't.

Budget and timing are on track for now. I'll knock on wood (or on a baguette, since I'm in Paris) and get back to the forecast. The monthly cycle starts tomorrow.