Supply Chain Management Blogs by SAP
Expand your SAP SCM knowledge and stay informed about supply chain management technology and solutions with blog posts by SAP. Follow and stay connected.
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
“When you give a five year old a hammer, the world suddenly becomes filled with things that need to be hammered”  I think credit for this goes to Abraham Kaplan…

I love that quote. It’s one I’ve used many times in many situations, but perhaps nowhere does it fit better than when discussing scope management (aka scope creep) associated with an IBP project.

That’s the topic of the third blog in this series.

In part one, we talked about change management.  Part two builds excitement as we “begin with the end in mind”.  Now it’s time to ensure we properly rein in the excitement and manage scope to ensure we give something of value to each key stakeholder in the first go live.

That means everyone gets something, but perhaps no one gets everything.  At least not in the first phase.  If you’ve enough interest in managing an IBP project to have read this far, you no doubt know that the approach is a series of sprints, or scrums, or whatever term your methodology uses.  That’s part of the beauty of the tool, and as we discussed in part 2 earlier, you will want to begin with a good sense of the full content in the first few phases.  But you won’t get it all immediately.

Determining what makes the cut is the next step after the brainstorming and design.

At a high level, it’s simple.  There was a reason, or reasons,  you chose to start this project.  Somewhere therein is your phase 1 deliverable.  It might be something like:

  • Understand the impact of changing production plans over a six month horizon on labor requirements so we can smooth utilization and avoid the costs of engaging and disengaging contingent staff, or

  • Utilize a combination of statistical, deterministic, and management inputs to increase forecast accuracy by 10% and stabilize our supply chain as a result,

  • Leverage known variation and service level commitments to reduce working capital through better inventory management, or

  • Share material and capacity requirements with our extended supply chain to ensure advance visibility of challenges and enable remediation without incurring premium freight, or..

  • Ensure congruence between our monthly operating plan and the relevant annual operating plan to avoid surprises – positive or negative – at month end through development of a robust and tested demand and supply plan

  • You get the picture… this could be quite a list.

Ultimately, each of the above are delivered by part of an overall model of your business and supply chain that will include demand, supply, inventory, and financial aspects.  But each is achievable with implementation of only a subset of the model that will eventually be deployed.

So pick the most important one and focus, particularly if the team that owns the most important deliverable is also funding the project.

Sounds a little too easy, doesn’t it?  And of course it is.  IBP is a wide open, flexible, adaptable, configurable tool.  The five year old with a hammer.  And, if your organization is like most I talk to, there is plenty of pent up demand for better planning to go around.  You’ll be saying “yes” a lot, but also saying “not yet”.  Which isn’t easy with a process that features “Integrated” in it’s name.

To achieve any objective of value will require crossing organization silos and contributions from multiple stakeholders.  In fairness, those who are asked to contribute should be getting something back from the process.  At minimum, seek to include a dashboard with relevant plan / actual KPI’s, or enable alerts based on operating data that may not be directly connected to the model itself.  Both of these are easily accomplished as a peripheral activity to the foundation implementation.

But decide up front how much resource will be allocated to each, ideally in alignment with the demands imposed.  And communicate clearly when more significant value drivers will be delivered in future phases.

The other area where scope needs to be managed is in “how much of the business do we include”?

Again, the answer is simple.  Personally, I’m not in favor of artificially segregating components of a business during implementation.  If it’s not viable to include the full enterprise, pick a subset of the operation that can easily be compartmentalized, ideally reporting to a single executive, and that is consistent with achievement of the critical phase 1 deliverables.

For example, if your objective is to improve forecast accuracy but there are too many products, regions, customers, locations… to do so all at once, perhaps pick your top customers, who may already roll into a key accounts VP.  Or a region, particularly viable if your customers are cleanly aligned with regions.  The answer may not always be simple, but it’s usually obvious.

Finally, to set up a compelling case for the next blog in this series, I’ll close with one last thought.

No one needs to be reminded about the importance of managing scope in any project.  With an IBP project, it has to be done to ensure delivery of the phase 1 value and keep excitement going.  But each phase requires not just model configuration, it also consumes data.  As we’ll see in the next blog in this series, managing data integration is “the long pole in the tent” (a cliché I don’t like near as much).  Each incremental deliverable requires data.  That’s what can slow you down, and one key reason to manage scope effectively as it multiplies the impact of any changes.