menu icon

Supply Chain Transformation: Top-down or Bottom-up?

By Bernard Milian
Choosing to go up or down?

The need to make manufacturing and distribution operations more agile and resilient is no longer in question. How to do it is another matter. In global companies, ambitious transformation projects are emerging, often with two opposing approaches.

Or it is a group program, initiated by the general management, led by a central team, with a significant budget, and internal and external resources, and pushed from the top of the organization to the various entities, in a “top-down” approach.

Or it is a question of experiments carried out in the field in one or two sites, which demonstrate results and spread, in a “bottom-up” approach.

What are the advantages and disadvantages of these two approaches? Is there a third way?

The top-down approach.

This approach has an obvious advantage: the commitment of the management behind the project is demonstrated – there are dedicated resources, a budget – often significant – expectations of results, messages disseminated in the organization, a methodological framework and technological solutions that are imposed, a time-bound deployment program is established.

The different functions of the company – sales, finance, operations, and R&D – are required to be involved and support the initiative, as well as the managers of the industrial or commercial entities.

According to the Project Management Institute, about 75% of projects fail: they don’t run on time, within budget, or don’t deliver the expected results. From my observation – not statistically representative but supported by multiple real-life examples – this is indeed often the case for large supply chain transformation initiatives conducted top-down.

I see several recurring reasons for this.

Failure Factor #1: Trendy Initiative

The management teams of large enterprises are subject to a network of dedicated influencers – analysts like Gartner, large consulting firms, and major software vendors – ERP and APS in particular. It is these influences that will help define the next big initiative. Unfortunately, too many management teams lack members who are experienced and pragmatic supply chain specialists. Shareholders and management can be lulled by the sirens of trendy technologies. The consequence is to commit the company to a big project… which is not the right one… 

Common examples are the deployment of APS focused on improving forecast reliability (with AI in it of course), or the new group ERP system. How many of these projects are on time, on budget, and above all, deliver the expected results?

Failure Factor #2: Disconnection from the Field

When these major initiatives meet the reality on the ground – the specificities of different product lines, industrial processes, and commercial business models – there is often a mismatch and we try to adapt the system by shoehorning it in, when we don’t embark on costly customizations that deviate from the initial objective of a group approach.

Failure Factor 3: Resistance and Dilution

A large part of the success of a transformation is that the team members take ownership of the methods and technological solutions. The fact that the solution “comes from headquarters” can be off-putting and create resistance, explicit or passive. Let’s drag our feet until the next initiative comes… 

Let’s not forget that the operational teams are permanently torn between multiple priorities: improvement projects, the next quality audit, the launch of the new product line, the layout of the site, and the current operational crisis.

Failure Factor #4: Inconsistency

A company is an organization in constant motion. Teams change. Managers change jobs or companies. A branch is divested, or a new entity joins the group. This hinders the beautiful deployment program. If the program lasts more than 2-3 years, there is a high risk that the environment has changed dramatically – e.g. newcomers to the management team want to make their mark on the company’s trajectory. Perhaps the next initiative is about to start, while the previous deployment is still in progress, or stalled… 

The bottom-up approach.

In this approach, one entity of the company (a factory, for example) implements a particular approach. In this context, it is easier to be innovative and to break out of a conventional framework, because the experimentation is on a small scale – the stakes and risks remain contained. Coming from the field, there is also a good chance that the teams will be strongly involved and the approaches will be very “practical”. But this approach also has its flaws and risks of failure.

Failure Factor #1: Lack of Group Support.

By definition, it is an experiment. It does not have a significant budget and resources, and the attention of the group’s management team is elsewhere. The local team has to fight its own battle when it comes to getting the required support – for example, some IT resources, a rare ingredient these days.

Failure Factor 2: Remaining in an experimental stage.

We see a lot of pilot projects that stretch out over time, that deliver very good results but remain isolated. The transition from a pilot to a spin-off deployment is not always in the company’s DNA – sometimes the sites are more in competition than in collaboration, which does not facilitate the sharing of good practices.

In many pilot approaches, the transition to deployment was simply not planned upstream. We’ve got a pilot that’s working well, so what do we do now? Oh heck, we haven’t budgeted for this year.

Failure Factor #3: It’s not representative.

The first project is a success, but it does not cover our use cases on other flows. The experience gained by the teams on this site is not relevant to our other sites. What should we do? Another experiment elsewhere? Months and years go by and only a few islands of transformation are deployed.

Don’t also forget that in the company community, there will be supporters and detractors – this is mandatory in society – the more time passes, the more the detractors will be affirmative: “You see, this is a limited thing”… 

The third way: a hybrid approach

The challenge is to orchestrate bottom-up and top-down to achieve a rapid and effective transformation.

  • Give top-down directions: what are the major stakes, the macro result objectives, and the heuristic view of the end-to-end supply chain of tomorrow? Without forgetting to specify when “tomorrow” is …. Do not aim for more than 2 years!
  • Encourage experimentation at different sites or portions of flows – making sure there is enough variety and representativeness in the scopes. Allocate resources to these projects so that they can be done efficiently and quickly. Let local teams experiment, but establish a roadmap with lessons learned from these experiments.
  • Make sure that these experiments are followed up at the group level, and put healthy pressure on them to move forward quickly and well – if you put the right resources in you can expect results. Have defined next steps: if the experiments are successful, have a pre-approved budget and roll-out organization, so that you don’t let the momentum die down.
  • Encourage exchanges between sites, and benchmark visits: you will make other sites want to do it, and desire is a key factor for success!

Here is the challenge: to combine the flexibility and pragmatism of a “bottom-up” approach and to accelerate/deploy in “top-down” mode, without it taking years because during the construction works the sale continues and the world changes…

Get in Touch

Share This Story, Choose Your Platform!


Recent Posts

Sign up to our Newsletter

You may also enjoy

Kanban DDMRP Buffer

Kanban loop or DDMRP buffer? 

When you mention a Kanban board to the younger generation, they immediately think of a visualization board for to-do / in-progress / completed tasks –