How to get a supply chain project approved: data, business case and context, with Sandra Patino

About Sandra Patino

Supply chain leader with three careers in one: process engineer, production manager and project manager at Danone in France and the US; four years at McKinsey in Canada after an INSEAD MBA; then industrial performance director at Danone in Russia after a major acquisition, VP supply chain at Coty in Dubai after the merger with P&G Beauty, and end-to-end supply chain at Upfield under private equity ownership in the Netherlands. Listen to the episode.

Three things she kept from consulting

Ben asked what Sandra Patino took from four years at McKinsey into a career running supply chains through acquisitions, mergers and a private equity carve-out. She named three.

First, "an obsession with clarity and specificity. In consulting, your credibility is all the time in jeopardy if the data you present is inconsistent from paper to paper, because that's what you sell." Back in industry she saw the same inconsistency, "and this was not about our reputation, but about the quality of our decisions. That became a mantra: the data, the data, the data, and the quality and consistency of it."

Second, communication: "the ability to communicate your points sharply, shortly, effectively. When you are an engineer, which I am, you like to explain exactly how the machine works. The audience, particularly for CapEx decisions, is not keen on hearing all the micro details."

Third, a reflex for the business case. "Of course we have business cases in corporate. But the way it was an automatic mechanism at McKinsey, working for clients on their projects, stayed with me."

Not all data matters, and proxies are allowed

Wim pointed out that real supply chains rarely have the data a data-obsessed leader wants. Sandra's reply is that the obsession is about the right data, not all data. "Not all data is important and not all data needs to be retrieved. There is a necessary understanding of which data you want and what for. Then you look at how you can get it."

Two cases follow. Either the data is on the floor, on the shelf, in a source, and easy to capture. Or it isn't, and consulting taught her proxies: "What is the closest correlated data that can be a good proxy for what you are trying to observe? You work with that, knowing it's not the ultimate data but good enough." False precision gets short shrift: "I see business cases with details to the cent of spend. Nobody believes that. It's never accurate."

The trickier failure is definitions. Her example is truck fill: everyone thinks it is obvious, until the numbers don't correlate with cost and it turns out one team measures against a standard 33-pallet truck and another against the actual vehicle. "What you thought was an obvious definition was not the same definition for everyone. First make sure that you speak the same language."

Nothing is obvious: reformulate

Her first communication rule comes from the factory floor. "Nothing is obvious. Never assume that everybody has the same understanding as you of a topic, as simple as it seems. The method is always reformulation: I say something, tell me what you understood." She applies it to data and business cases the same way, playing the other side and rephrasing the case through their logic and history.

Why good projects don't get approved

Wim raised the most common complaint he hears: a great idea that never gets funded because the team can't make the case. Sandra's answer starts with the basics, a case that "stands on its two legs", and then moves to what engineers usually miss.

"Your projects are part of a big basket of projects. One bit is to understand how this is impactful across the whole value chain, not only for operations or supply or logistics. The other thing is context. Sometimes we present a very good project, but it's not the right moment. The executive committee just put all the money on a big push on promotions. There is cash, but not cash for this. A project is never good just on a standalone basis in a company." Expanding her own scope over the years showed her the other side: "When I look at the full picture, this project is nice, but it's not the nicest one I have in my hands."

Credibility, strategy and a partner in crime

Ben pushed back: isn't context exactly the barrier, with every function fighting for its turf? Sandra doesn't accept the premise. "The world is not just a competition of egos. People are smart; the more you go up in the company, they didn't get there just by luck."

Three things move a project through the door. Credibility: "the track record you bring around your results, your ability to deliver, is always something that adds to the naked project", because executives have seen too many cases that never delivered what the post-mortem expected. Strategic fit: "If the company says we are a sustainability-driven company and your project will decrease carbon emissions, you are right in the strategy. A fantastic project about operational efficiency can be done next year. Find a way to adjust your project so it meets the things that really are on the agenda." And association: "If it can benefit finance, the sustainability team, R&D, whatever team, finding alliances helps. Get a partner in crime, or two."

In a multinational there is one more variable: where you are. "An initiative that comes from France is maybe not as important as one from the US, because the pie is smaller. Local initiatives are never as much a priority as initiatives that are scalable." So a local idea needs a sponsor on the executive committee who will call it a pilot, and an answer to why it matters at scale.

Integrating a company that had only merged its brands

After McKinsey, Sandra joined Danone in Russia a year after it bought the country's number two dairy producer, a company assembled from post-Soviet factories by one owner. Danone had bought brands, shelf space and access to milk. "Internally, nothing was integrated." Her job was industrial performance: bringing the factories into a Danone way of working. Planning was equally improvised, and as Danone started matching factory capabilities to the distribution footprint, "we needed integrated methods to do supply planning".

The systems story is instructive. The acquired company ran a Russian ERP, for finance only, and Excel for everything else. "We went into a big SAP implementation, but not on year one. We started on year four after the acquisition. There were many other things to do before, and many things we could do without SAP", including viable factory planning tools in the meantime.

Entrepreneurial versus process: the Coty merger

At Coty in Dubai she ran everything outside Europe and North America, soon after the "merger of equals" with P&G Beauty. "Everybody knows P&G as this big process-oriented, well-oiled machine, with support activities driven in hubs. Coty praised itself for being very entrepreneurial. Entrepreneurial and process-oriented are strictly opposite. We had a clash of cultures, and this was underestimated." On top of that: re-implementing SAP, and closing and rebuilding hubs in a region that imported most of its products.

The planning organisation that emerged kept demand planning local, one to three planners per cluster under the local supply chain manager, with the hubs doing mid- and long-term supply planning and a local supply planner only for customisation: stickering, language repacks, local trade marketing.

Private equity: no reward for effort

Upfield, the spread business carved out of Unilever, implemented SAP on HANA with IBP for demand and supply. The cultural clash there was different. "The way of working in a private equity world is much more results-oriented, much more fact-based. There is no reward for effort. You have to deliver results to get the reward, and the pace is very demanding. A lot of people left in the first two years. The ones who stayed were very motivated by this type of culture."

After go-live: dialogue, not tickets

Wim asked how you keep people when their framework is taken away by a system change. Sandra won't claim a method, only what she did. From day one, she and a few leaders asked for every obstacle people hit, then sorted them honestly: "This will never come back, we eliminated that tool. Or: that's a real problem, we missed it, we should have put it in the system. So now we have a change order." That took about nine months of post-go-live change-order management, with a weekly, then monthly drumbeat through team leaders.

What it must not run on is a ticket queue. "SAP and Accenture would love that we all put it through a ticket system, but this is dehumanised. You have to have dialogue, the explanation live, the real feeling of the person, then give that back to the project team and relentlessly get resolution." It is, she says, ingrat, thankless. "To tell you I found the magic wand would not be true. The only magic I have found is work, hard work and more work."

And one thing has to be clear before any of it: "You have to understand your process and why you are doing things. Understanding the process itself is not the most important, because your process can be flawed. But why is it going from here to here? Understand that this is really what you want, and not something you received as an inheritance."

Your next steps

• Before collecting data, write down which data you need and for what; use a proxy where the real thing is hard to get, and drop the false precision.
• Check definitions across teams for every KPI in a business case; truck fill is the classic trap.
• Present a project in its context: value across the whole chain, fit with this year's strategic agenda, and timing against what else is on the executive table.
• Recruit a partner in crime from another function and, for a local idea, a sponsor who will call it a pilot.
• After a system go-live, run a weekly obstacle review through team leaders for the first months, and keep it a conversation rather than a ticket queue.

Sandra's reading: McKinsey's public change management articles, The Goal ("if you're an operations person, you have to read it"), How Big Things Get Done, and Daniel Pink's Drive, "because it approaches the diversity of what motivates us. I've recommended this book to many people who all have liked it."