I just read Niels van Hove’s recent post “A New Definition for Integrated Business Planning” on Supply Chain Movement (Click here to read), and it made me stop and think more carefully about what Integrated Business Planning (IBP) is and isn’t, and how our software products fit into it.
I appreciate van Hove’s attempt to better define a phrase that is widely used by many people and that means something slightly different to all of them. He considers how to classify IBP. Is it a process? Systems thinking? A philosophy? And I like where he lands: it’s a planning philosophy. That designation recognizes that IBP is a way of thinking first and foremost, which I agree with. After some additional considerations, van Hove ends up with the following definition:
Integrated Business Planning (IBP): A holistic planning philosophy, where all organizational functions participate in providing executives periodically with valid and reliable information, in order to decide how to align the enterprise around executing the plans to achieve budget, strategic intent, and the envisioned future.
I agree that the overarching idea behind IBP is to bring together all of the organizational functions to get aligned about how they collectively can achieve the budget, strategy, and vision set forth by executive management. If you’ll indulge the Operations Research reference, IBP is about promoting global optimization vs. local optimization. If each function makes decisions that myopically improve its own area of the business but those decisions negatively impact other areas, the organization might suffer overall. At the same time, the organization might improve. But without the functions working together to understand that, no one will know for sure until it’s too late.
However if the functions collaborate to understand how their respective decisions impact one another (good or bad), they can collectively develop and execute plans that ensure improvement to the organization as a whole. In this way, a given function might agree to be negatively impacted for the greater good of the organization; something they might not have agreed to (or even known about) because they could not see the bigger picture. Of course, where internal politics and protectionism might impede such noble decisions, executive management can always make the final decision.
One part of his definition that I’m uncertain about is that IBP is designed to “[provide] executives periodically with valid and reliable information”. While that is part of IBP, this phrase implies that operational teams always need executive approval for their decisions. Perhaps that’s not what van Hove meant to imply, but it’s how I read it. Executives set the strategies and goals and then everyone else works to achieve them. Executive approval might be required for strategic, maybe even some tactical, decisions, but a CEO typically doesn’t care about how about an inventory optimization policy at one of the warehouses impacts procurement volatility with one of the suppliers. Understanding those impacts is part of IBP for sure, but do they need to feed all the way back up to executive management as “valid and reliable information”? In general, I agree that information and decisions that can have material impact on the business (be that financial, operational, or even brand/image impact) should be communicated at the executive level as part of IBP. If for nothing else, to keep key stakeholders informed.
Overall though, I like van Hove’s self-admittedly working definition of IBP. While Vanguard Software doesn’t talk about ourselves or our products in the context of IBP (at least not from a marketing perspective), I couldn’t help but think about how we support IBP (and S&OP) in our Forecast Server platform. Overall, I think we do a good job supporting IBP as a philosophy. We link together various plans in a good way so that each team/function can easily see exactly how their planning integrates and impacts other plans, from executive budget/targets to sales plans to demand plans to supply plans to financial plans (that’s a lot of plans…). I like how we help visualize gaps between plans and the reasons for those gaps. I like how we have small, but impactful ‘nods’ to IBP in key places in our software, and in ways that we wouldn’t even highlight as an ‘IBP feature’. For example, we show a profitability metric in our supply planning module so that supply planners and inventory analysts can see how their inventory planning decisions impact the profitability of the item. As they make tweaks to the inventory plan, they can see that metric go up (which is good) or down (which is bad). And even if their change decreases profitability, their might be a good reason for making it if it serves the greater good. In this example, Vanguard supports IBP by making it easier for the supply chain team to understand how their operational decisions can impact the financials and therefore the finance team.
As a closing note, I like that Niels van Hove welcomes feedback on his definition and calls it ‘open source’. It seems rare these days to have someone encourage dialog instead of claiming to have drafted the world’s best and final definition of something.
Brian Lewis, Ph.D.
Vanguard Software Corporation
Executive Vice President
San Francisco, CA
About Vanguard Software
Vanguard Software introduced its first product for decision support analysis in 1995. Today, companies across every major industry and more than 60 countries rely on Vanguard Software’s Integrated Business Planning (IBP), forecasting and advanced analytic cloud platform. Vanguard Software is based in Cary, North Carolina.