In the first blog in this series, Eight steps to evolve S&OP into IBP, we introduced a number of IBP building blocks. Useful, as we should eat the IBP elephant one bite at a time. Some of these building blocks will be a lot of work in themselves, so trying to design, build and implement them all in one big bang will certainly fail. This building block approach in itself is not the magic bullet though, it just tries to divide Integrated Business Planning in manageable pieces. What else do we need to consider?
Create buy-in
The building block approach focuses largely on the content. Good content is certainly a prerequisite, but as we described in the blogpost: Sales & Operations Planning; change management is the key to success, it is only one of four aspects that need to be addressed. Implementing S&OP or IBP is like playing chess on multiple boards. Focusing on the “Logic” only is probably the most common pitfall and one of the main reasons that many initiatives in this area struggle to deliver real business value. We will need to mobilise the organisation, create buy-in and enable all stakeholders to play their parts as well!
Classic top-down approach: apparent sense of control
Recently we received an RFP (Request for Proposal) for an IBP project at an international company. The project approach had already been defined and started with a 3-month Preparation Phase, followed by an 8-month Design period and finally a phased implementation. The company is organised in several Business Units with different market characteristics, product portfolios and supply chain footprints.
What is the probability that this approach will deliver a feasible and effective design? And even more importantly: what is the likelihood that the business units will unquestioningly adopt such a top-down design?
Quite a few companies still prefer this approach though, specifically the ones with a strong hierarchy. Actions, milestones and deliverables can be clearly defined and monitored, which gives a clear sense of control. However…
…there are almost as many instances where this approach has resulted in massive PPT decks and detailed process flow diagrams, which have been collecting dust ever since the last Steerco approved them for the roll-out gate. Surely not always, but the risk is phenomenal.
Bottom-up or agile: avoid risk of ivory tower design
So what should the approach look like? A Preparation Phase is useful and should have clear deliverables: a solid understanding of the organisation and its ambitions, and a clear vision on the “why, how and what” of the to-be IBP process. Not to the nth level of detail though, as this will take time and energy and will most likely prove to be useless afterwards. On the other hand, there should be sufficient content already to make a first start of running an adjusted process. Call it a ’Minimum Viable Product’, the minimum required level of detail to start the IBP process.
From here, there can again be two high level approaches:
- Continuous improvement: start running a slightly adjusted process a.s.a.p. and learn as you go along. Keep adjusting the process every cycle, monitor, coach, do formal evaluations every time and make sure that each cycle brings you closer to the end goal: the high level vision on IBP that you defined in the Preparation Phase.
- Agile: similar but not the same. More formal, with small but clear deliverables for each “Sprint”, that work towards equally clear “Epics” or “Themes”. An agile approach is the norm in software development and can be highly effective. It is particularly powerful in IBP projects that require significant developments in data and/or IT.
Although these bottom-up approaches may give a feeling of less control, the opposite is the case. The huge benefits are that they avoid the risk of ivory tower designs, which look impressive but miss the point and lack the buy-in and ownership of the practitioners.
Wrap-up: playing chess on multiple boards
Designing and implementing IBP is like playing chess on multiple boards. A good design is a prerequisite, but it addresses only one of the four main aspects: the “Logic”. The temptation is to create this design in a classic and top-down approach. Although this may work in some companies, it fails to mobilise the future IBP practitioners and carries a substantial risk of creating a detailed and impressive looking design, that in practice does not meet expectations and does not get adopted. Bottom-up approaches may have their disadvantages too, but well managed “Continuous Improvement” or “Agile” IBP initiatives avoid the top-down pitfalls and have a way higher likelihood of success.
Would you like to experience IBP?
Reading about IBP is useful, but experiencing it is much more powerful. If you want to feel the power of IBP in a virtual environment and learn best practices from the experts, then please join Involvation’s IBP Boost Camp. For more information, contact Hans van der Drift, h.vddrift@involvation.com.
