<img alt="" src="https://secure.doll8tune.com/223485.png" style="display:none;">

Je organisatie mobiliseren voor IBP: agile of waterval?

Je organisatie mobiliseren voor IBP

In het eerste blog in onze reeks In acht stappen van S&OP naar IBP hebben we een aantal bouwstenen voor IBP geïntroduceerd. Handig, want we kunnen maar één stuk van de grote IBP-koek tegelijk eten. Sommige van deze bouwstenen zijn op zichzelf al een hoop werk, dus als we alles in één keer willen ontwerpen, opzetten en implementeren, gaat het geheid mis. Deze bouwstenenstrategie is op zich echter geen wondermiddel, maar slechts een poging om IBP op te delen in behapbare stukken. Waar moeten we nog meer rekening mee houden?

Zorg voor buy-in

De bouwstenenstrategie is grotendeels gericht op het ontwerp. Een goed ontwerp is beslist een randvoorwaarde, maar zoals we in deze blogpost; Sales & Operations Planning; veranderaanpak cruciaal voor succes al beschreven, is het maar één van de vier aspecten die op orde moeten zijn. S&OP of IBP invoeren is als schaken op meerdere borden. Alleen aandacht voor het aspect ‘Logic’ is misschien wel de bekendste valkuil en een van de belangrijkste redenen dat veel initiatieven op dit gebied nauwelijks echte businesswaarde opleveren. We moeten de organisatie ook mobiliseren, voor buy-in zorgen en alle stakeholders in staat stellen hun eigen rol te spelen!

Klassieke top-down-aanpak: schijnbaar gevoel van controle

Onlangs ontvingen we een RFP (Request for Proposal) voor een IBP-project in een internationaal bedrijf. De projectaanpak was al vastgesteld en begon met een voorbereidingsfase van drie maanden, gevolgd door een ontwerpperiode van acht maanden en tenslotte een gefaseerde implementatie. Het bedrijf bestaat uit een aantal business units met verschillende marktkenmerken, productportfolio’s en supply chain footprints.

Hoe groot is de kans dat deze aanpak een haalbaar en effectief ontwerp oplevert? En nog belangrijker: hoe waarschijnlijk is het dat de business units zo'n top-down-ontwerp kritiekloos accepteren?

Toch geven nog behoorlijk wat bedrijven de voorkeur aan deze aanpak, met name bedrijven met een sterke hiërarchie. Maatregelen, mijlpalen en resultaten zijn nu eenmaal duidelijk vast te stellen en te volgen, wat een duidelijk gevoel van controle geeft. Maar…

…er zijn bijna evenveel gevallen waarin deze aanpak heeft geleid tot tal van PowerPoint-decks en gedetailleerde processtroomdiagrammen die hebben liggen verstoffen sinds de laatste stuurgroep ze goedkeurde voor de uitrol. Natuurlijk niet altijd, maar het risico is levensgroot.

Download IBP Roadmap


Bottom-up of agile: geen risico op een ivoren toren ontwerp

Hoe zou de aanpak er dan uit moeten zien? Een voorbereidingsfase is zinvol en moet ook duidelijke resultaten opleveren: een goed inzicht in de organisatie en haar ambities en een duidelijke visie op het ‘waarom, hoe en wat’ van het toekomstige IBP-proces. Maar ook niet tot in het kleinste detail, want dat kost alleen maar tijd en energie en zal hoogstwaarschijnlijk niets toevoegen. Anderzijds moet er al voldoende inhoud zijn om een begin te maken met een aangepast proces. Noem het een ’Minimum Viable Product’, het minimaal vereiste detailniveau om het IBP-proces te beginnen.

Van hieruit zijn er twee overkoepelende strategieën mogelijk:

1. Continue verbetering: begin zo snel mogelijk met een licht aangepast proces en leer aldoende. Blijf het proces elke cyclus aanpassen; controleer, begeleid, voer telkens formele evaluaties uit en zorg ervoor dat elke cyclus je dichter bij het einddoel brengt: de overkoepelende visie op IBP die je in de voorbereidingsfase hebt bepaald.

2. Agile: vergelijkbaar, maar niet hetzelfde. Formeler, met kleine maar duidelijke resultaten voor elke ‘Sprint’, die toewerken naar even duidelijke ‘Epics’ of ‘Themes’. Een agile aanpak is de norm bij softwareontwikkeling en kan zeer effectief zijn. Deze strategie biedt vooral veel mogelijkheden bij IBP-projecten waarvoor aanzienlijke data- en/of IT-ontwikkelingen vereist zijn.

Hoewel de bottom-up-aanpak je het gevoel kan geven minder controle te hebben, is het tegendeel het geval. Het grote voordeel is dat het risico op ivoren toren ontwerpen wordt weggenomen. Zulke ontwerpen zien er weliswaar indrukwekkend uit, maar schieten het doel voorbij en zorgen niet voor de buy-in en het eigenaarschap van de uitvoerders.

Dus: schaken op meerdere borden

Een IBP-proces ontwerpen en implementeren is als schaken op meerdere borden. Een goed ontwerp is een randvoorwaarde, maar daarmee wordt maar één van de vier hoofdaspecten aangepakt: ‘Logic’, de harde logica. Het is dan verleidelijk bij het ontwerp een klassieke top-down-aanpak te volgen. Hoewel die in sommige bedrijven succesvol kan zijn, worden de toekomstige IBP-uitvoerders niet gemobiliseerd en is de kans groot dat er een gedetailleerd en indrukwekkend ontwerp uit voortkomt dat in de praktijk niet aan de verwachtingen voldoet en niet wordt geaccepteerd. Een bottom-up aanpak kan eveneens nadelen hebben, maar als een IBP-project met als overkoepelende strategie ‘Continue verbetering’ of ‘Agile’ goed wordt beheerd, wordt de top-down valkuil vermeden en is de kans van slagen veel groter.

Ontdekken wat IBP voor jouw organisatie kan betekenen?

Lezen over IBP is nuttig, maar het met eigen ogen zien is pas echt waardevol. Als je de kracht van IBP wilt ervaren in een virtuele omgeving en van de experts over best practices wil leren, meld je dan aan voor de IBP Boost Camp van Involvation. Voor meer informatie, neem contact op met Hans van der Drift, h.vddrift@involvation.com.

 

Everything should be made as simple as possible, but not simpler
einstein
Albert Einstein