SAP IBP implementation: six lessons from STADA's move off APO, by Ali Oezer

About Ali Oezer

End-to-end supply chain strategy lead at STADA, the German pharmaceutical group, where he first ran global supply planning for in-house operations. Before that, 28 years at Procter & Gamble in customer service, manufacturing, procurement and supply network operations. An industrial engineer by training. Listen to the episode.

Three legs, not one system

SAP postponed the end of life of APO five times. Then it stopped postponing, and every company still planning on it had a decision to make.

Ali Oezer was in the room for that decision at STADA, and he is now running the programme that follows from it: S/4HANA as the one ERP, SAP IBP for tactical planning in-house and across around 500 contract manufacturers, and the Digital Supply Chain module for production planning and scheduling. The pilot went live 14 months after the project started; two rollout waves follow, and the whole rollout is planned to finish within two years.

What makes his account useful is that he refuses to treat it as a system project. "The focus has always been on three areas: systems, the linked processes, and organisation design. Those are the three legs, equally important, otherwise you cannot have a successful supply chain planning process in place."

Here are six lessons from the conversation, for anyone facing the same move.

1. Choose the platform on strategy, not on a feature checklist

STADA did look at the market. "We did a pre-analysis checking on what is out there. The conclusion at the end was that nobody is perfect. Every solution has its pros and cons."

The decision for IBP was strategic: STADA already ran IBP for demand planning, wanted one platform for the other integrated business planning modules, and judged that SAP's size made long-term support more likely than with smaller vendors that would always need to be interfaced to the ERP. Ali is open that response and supply "still has areas which need to be continued in development".

One requirement was non-negotiable: real-time integration between planning and ERP. "We didn't want something which just does overnight jobs. Planners can see the alerts and react to them on a daily basis."

2. Run the planning project on its own timeline, not the ERP's

The IBP and DSC project is linked to the S/4HANA transition but runs separately, with its own timeline. "We are faster than S/4 actually," Ali says. The pilot integrated IBP and DSC to the existing ECC environment; S/4HANA takes over region by region as it goes live.

The lesson for anyone waiting for the ERP programme to finish before touching planning: don't. Planning can go first, on the data you have, and reconnect when the ERP catches up.

3. Pilot the hard site, not the easy one

With 15 in-house operations and about 500 contract manufacturers, a big-bang rollout was never realistic. STADA chose a pilot and two waves. The question was which pilot.

"I wouldn't go with the easiest one, which we didn't do. We selected one of our main sites as a pilot and five or six important CMOs, because that is something which should be re-applicable for the other businesses. If you choose a too easy, less complex environment, the learnings may not be re-applicable and you may get surprises along the way."

The result: "What we developed for the pilot is 95% our global template. It works."

4. Standardise the roles before you standardise the system

The part most rollouts leave until last, STADA did first. In Ali's first three years, before the IBP project, the company replaced local job designs with standard planning roles: production planner (including scheduling), material planner, supply planner, rough-cut capacity planner and CMO planner.

"Before that, STADA had a lot of local designs where roles and responsibilities were not standardised. That is what we did, and now the project benefits from that."

The system then added something the roles had been doing by hand. "In APO we had the visibility, but the tool wasn't helping us to do constraint planning in the tactical horizon. You know that for the next six months something will not be available. All of that was purely manual. Now the system does the calculations and the supply plans around your constraints."

On whether demand and supply planning should sit with one person, Ali is candid: the ideal is end-to-end ownership, but "complexity on the demand side and the supply side is better if you have separated roles" for now. He expects AI and automation to change that "sooner than later" for some companies.

5. Build a centre of excellence so you don't need the consultants

STADA's support model is a pyramid. Key users are level one, subject matter experts level two, IT and SAP level three. "About 80% of issues are managed within level one and level two."

Responsibility shifts wave by wave. In the pilot, the internal team watched the consultants. In wave one they ran the training themselves. By wave two they ran end-user enablement and documentation. "In the next six months, it should be at a level which enables us without external for day-to-day business requirements."

His reasoning is competitive, not just cost. "The more you have in-house capabilities, the better you are in terms of being self-sufficient, but also developing on your own needs. It can be a competitive advantage."

6. Treat change management as the project, not a workstream

"It was not only a system change, it's also a process change, sometimes organisation design change. It's impacting around 400 people." Starting with a pilot rather than a big bang, Ali says, was as much about the change as about the technology: "It was good for the project team to start smaller, to focus more on the change itself."

Asked what he would tell a younger Ali, the answer is the same. "The change management aspect is becoming, in my eyes, the most critical element in this type of environment, independent from system changes."

And on AI, the question every planning team now gets from the board: STADA runs its own chatbot for planner documentation, has no decision yet on SAP's Joule, and keeps AI out of the rollout's critical path. "I personally believe it's the next three to five years where all of the repetitive work, where you have enough data points and higher reliability, AI will take it over."

Your next steps

• Write down the three legs of your rollout, systems, processes and organisation, and check that each has an owner and a timeline. Most plans only have the first.
• Decouple the planning project from the ERP programme. Integrate to what you run today.
• Pick a pilot that is representative, not easy. If the pilot template won't re-apply to 90% of your sites, it is the wrong pilot.
• Define standard planning roles and job descriptions before go-live, not after.
• Design the key user, subject matter expert, IT pyramid on day one, and set the date by which day-to-day runs without external help.

Ali's own summary of 30 years is the one to keep: "Thinking end-to-end means not just looking into your own silo. You need to win at every level. You need to convince your people, you need to master the change." For the method behind the process, see our explainer on integrated business planning.