Supply Chain change management: what happens to planners?

‍

The objection that always comes at the end of the demo

There is a moment in every planning project that you learn to recognize. The demo went well, functional coverage checks out, the data is available. And yet the person across the table pauses, then says something like: “This feels like a big step.”

It is almost never a technical objection. It is a change management objection, and a perfectly rational one. Moving from a collaborative process, where every forecast is checked line by line and cell by cell, to management by exception, where the tool produces most of the plan on its own, is not an interface change. It is a job change. And nobody breaks that kind of news to their team lightly.

A word on roles, since they often get mixed up in these conversations. Two distinct jobs are affected: the demand planner, who builds and defends the demand forecast, and the buyer, who turns that forecast into purchase orders. Their fears sound alike, but they concern different tasks, and they call for different answers.

Here is the paradox: this fear is overwhelming during the sales cycle but gone once the tool is live. At Flowlity, we see it project after project: concerns about cultural fit vanish once users work in the tool every day. So the problem to solve is not the tool. It is the path to get there.

‍

What teams are really afraid of

“If the system decides, what is my team for?”

The question comes up word for word in most projects, often from a Supply Chain director asking on behalf of the team. It actually hides three separate fears, and they are best handled one at a time.

The first is the fear that the job will disappear. It is the most visible and the least justified. In an organization where buyers spend most of the day approving lines and settling quantities, automation does not eliminate the job. It eliminates the clicking.

The second is the fear of losing control. A demand planner whose internal credibility rests on explaining every number in the forecast will struggle with a model they cannot defend in front of a sales director. This fear deserves to be taken seriously, because it is about something real: professional legitimacy. The way to defuse it is to explain the mechanism rather than promise performance, and a probabilistic approach to planning is easy to walk an executive committee through.

The third is the fear of running out of bandwidth. Many stretched organizations have no slack: the project lead and the key user are often the same person. A transformation project then lands as extra work on a team that cannot absorb it, and any talk of future benefits falls on deaf ears.

The fear of abandoning a process you just designed

There is a fourth fear, subtler and especially common in mature organizations. A company that has just invested in redesigning its demand planning process, with a well-documented monthly cycle, a forecast review and a formal consensus step, suddenly faces a tool that recalculates everything automatically every week and makes part of that cycle optional.

The natural reaction is to feel you are moving away from the target you just defined. The better question is whether that target was designed around today's technology or yesterday's constraints. A monthly consensus process built around a shared Excel file is a rational answer to a tool limitation, not an end in itself. Once the limitation is gone, it makes sense to rethink the process, not just digitize it as it is. That is exactly what is at stake in the shift from calendar-driven S&OP to continuous, AI-driven planning.

‍

What the planner stops doing, and what they start doing

From transactions to exceptions

Almost every organization we meet tells the same story: the overwhelming share of a supply team's time goes into approving lines and settling quantities, with automation rates stuck very low. That is not a skills problem. It is a tool design problem.

With management by exception, the nature of the work changes. The plan is generated automatically for the entire portfolio and every site, built around real constraints: supplier lead times, minimum order quantities, pack size rounding, free shipping thresholds, order grouping families. Users no longer open a list of items to work through; they open a list of anomalies to resolve. Their day focuses on two tasks: approving suggested orders and handling the alerts that fall outside the acceptable range. That is the heart of what Supply Chain planning automation makes possible, and what turns the role change from theory into practice.

The payoff is not just time. It is consistency. In many purchasing departments, three people facing the same situation will settle on three different quantities, with no guardrails on the amounts committed. Moving to rules that are configured once, then supervised, standardizes and secures practices, which is often a far bigger goal for leadership than the raw productivity gains.

What teams say once they are in the tool

Here, customer voices carry more weight than any sales pitch. At Plum Living, a French interior design brand managing 630 SKUs across two warehouses, the logistics manager sums up the change in one sentence:

‍

“When Flowlity arrived, it truly changed my day-to-day life.”

Axel Moulhiac, Logistics Manager, Plum Living

‍

At SupplyCaddy, a US foodservice packaging manufacturer that plans around 250 custom products with Flowlity Lite, the co-founder makes the same point in terms of capacity:

‍

“Flowlity has enabled us to do the job of three or four people without needing three or four people.”

Bradley Saveth, co-founder and President, SupplyCaddy

‍

The nuance matters, and it is the message to bring to your teams: in a growing company, automation did not replace anyone. It saved the company from hiring three or four people to absorb the workload.

Where the freed-up time goes

Saved time does not land in the same place in every organization, and that is precisely the question to settle during scoping, not at signature. Depending on context, it goes to proactive expiry management, rebalancing stock across sites, preparing decisions for leadership, cleaning up item master data, or supporting sales teams on product launches. Every organization has projects it shelved for lack of time, and those are the ones that rise to the top.

A concrete example, framed clearly as a project goal and not yet a measured result. At a multi-site distributor we work with, one of the stated objectives is to redeploy part of the buyers' time toward supplier performance management.

The logic is simple. A team that spends its days recalculating quantities has no consolidated view of its suppliers: actual service level, systematic gaps between quantities ordered and delivered, recurring delays by item or by site. Once the platform produces that data automatically, a buyer can call a supplier with a factual track record instead of a gut feeling, and turn a complaint into a joint improvement plan. That conversation was simply out of reach before, for lack of both time and evidence.

What makes this example useful is not that it applies everywhere, but that it can be named. The planner does not become vaguely “more strategic”. They take ownership of a specific, measurable topic their organization had flagged as important and never managed to tackle. That is the level of precision to aim for when talking with your teams, whatever the topic.

Parameter tuning as a new skill

The third shift is less often anticipated. In a probabilistic tool, the quality of the output depends directly on the buffering strategy set for each item: target service level, risk appetite, expected supplier behavior. These settings are not a one-off technical setup. They are a permanent management lever, and it belongs to the business, not to IT.

A planner who masters these levers now makes trade-offs between inventory value and availability across an entire product family, and can simulate the outcome before committing. That is real upskilling, and it is what to put forward with the team, rather than the number of hours saved.

‍

Change management support: four phases, a deliberately short timeline

One objection always surfaces when organizations compare vendors: does a short project mean poor support? Flowlity's integration effort is often lighter than that of legacy vendors, and the gap worries buyers as much as it reassures them.

The answer lies in how the deployment is structured: four phases for each go-live wave.

Business scoping kicks off the project. Flowlity runs workshops with key users to understand current practices, capture every supply constraint and define the target process. This is not a technical specification phase; rather, it is about aligning on what teams will do differently, and it is where most of the change management happens, long before training.

Data integration follows, often in parallel. It deliberately starts with manually shared files, so nobody waits for automated interfaces, and teams quickly get a platform running on their own data rather than a demo dataset.

Configuration and model training is the phase the customer sees least and the one that matters most for adoption. This is where the exception-based work views are built: which alerts show up, for whom, at what trigger threshold. A user who starts the morning with 30 items to review adopts the tool. If they are confronted with 3,000, they will go back to Excel.

User testing, training and go-live close the loop. On multi-wave projects, we always plan a period of testing and training in real conditions before going live, during which teams work on their actual data without their decisions being binding yet.

These timelines are not theoretical. Plum Living went live on the full platform in 3 months, covering 630 SKUs across two warehouses, with a 9-month replenishment horizon and a supplier portal. SupplyCaddy, which plans around 250 custom products with Flowlity Lite, was up and running in 2 weeks. In both cases, support was not sacrificed to the schedule:

‍

“At the beginning of the project, we were looking for a user-friendly, easy-to-implement tool to support us in our daily activities. Flowlity checks all the boxes; moreover, we are accompanied by a professional and available team.”

Ananda Lliteras, Head of Operations, Plum Living

‍

A short timeline is not a sales shortcut. It is a change management decision. A project that drags on for 18 months wears out user buy-in long before it delivers anything visible. A fixed-price engagement, on the other hand, makes it possible to add business workshops when the field shows they are needed, without renegotiating. Flexibility comes from the intensity of support, not the length of the calendar.

‍

Can a planning project succeed without reorganizing the team?

Yes, and it is actually the most common scenario. Reorganization is not a prerequisite for deployment; it is a gradual, deliberate consequence of it. Gartner sees the same thing: in a survey of 140 Supply Chain leaders, 83% of organizations are rolling out AI incrementally rather than through immediate transformation, and the obstacles they cite are organizational and human, not technological.

Organizations that succeed start by keeping their existing process, continuously measure the value added by manual forecast overrides, then gradually restrict those overrides to the cases where they truly add something. The role change is built on internal evidence, not on a vendor's promise.

Plum Living's trajectory shows this gradual progression in the results: inventory value first fell 21% at go-live, then 38% as the configuration was fine-tuned, moving from €598k toward a €367k target. The full story of this transformation shows that the biggest gains come after go-live, once teams have taken ownership of the levers.

‍

The planner does not disappear, they operate at a different scale

Fear of change in a planning project is legitimate, and brushing it aside is the surest way to see it resurface six months after signature, as workarounds and shadow Excel files.

What defuses it is not a speech. It is a precise answer to the question being asked: here is what your team stops doing, here is what they do instead, here is when in the project we talk about it. Time saved on approving lines does not vanish into a table of theoretical gains; it is reinvested in identifiable topics, specific to each organization.

That is also why a fast deployment is not the enemy of good support. The sooner teams see their own data in the tool, the sooner the conversation shifts from “what will happen to me?” to “what can I do better?”

Preparing to switch planning tools and wondering what it means for your team? Request a personalized demo on your own scope.