I'm just leaving our 2017 Kickoff meeting and talked with many colleagues and partners who have customers launching IBP projects shortly. So it seems like a great time to expand on content in my book (
https://www.sap-press.com/sap-integrated-business-planning-how-does-sap-ibp-fit-into-scm-processes_4... ) with a little more detail on topics to keep in mind as your team starts this important journey. This will be first of several blogs in a series over the next week or two.
So I'll start with the simplest to say, and hardest to do: Be prepared for challenges in change management.
Brilliant, right? We took an informal survey in on of our sessions to rank risk factors in any transformational project, and Change Management was the consensus number one by a large majority.
While this applies to any implementation, the team launching an IBP project needs to take special care in this area.
Why? Simple - almost every company starting a project using SAP's IBP tools already has an S&OP, or SIOPS, or some other acronym-identified process in place. So how tough can it be to migrate to IBPas a tool?
Not very tough, actually. The tool is straightforward and - as you'll see - provides a broad set of easily understood and deployed capabilities.
But there's that pesky letter "I" in the mix. IBP is INTEGRATED. A key driver of the value you'll realize is access to a single source of truth in the data used to drive the plan, and a clear understanding of the process by which forecast is turned to demand, and demand to supply. A second, and a result of the integrated data and process model the tool provides, is the speed with which this happens. The impact of changes in input assumptions can be visible immediately.
You might guess that this can cause heartburn in some cases. And it does. IBP can and should remove any "hiding places" where Excel is currently used to manipulate data, and expose weak processes and gaps in understanding all too clearly.
IBP will also demand timely and accurate input data, some of which - particularly in demand management - cannot be sourced from some other system because it doesn't exist. Salespeople, and potentially distributors, channels, and customers may be given the "opportunity" to provide input. Which of course means they can be held accountable for the quality and timeliness of the input in the context of the planning process cadence, which may also be a new concept. (side note - consider using Key Figure alerts to test for the absence of data to automate polite reminders to provide input).
Finally, remember one of the primary purposes of an IBP deployment is to create an environment that invites and responds to Executives' questions during the plan review phase. Answers will be expected.
So what do we do? Your systems integrator and internal project leads will no doubt have some ideas, but I'll share a few here too:
- Don't underestimate the importance of change management. Well, you're reading this blog, so that's probably covered
- Ensure the key stakeholders are engaged and involved from the start, and have a chance to express concerns and ideas to enable them to contribute with minimal impact
- Obtain clear executive support immediately and have it clear that participation is not optional
- If one or more executives are "the problem", address this immediately before proceeding. Exactly how to do so is beyond our scope here
- Ensure each key stakeholder sees value in the quick wins associated with the first phase of the project (that'll be another blog in this series) and articulate the vision and values driving the project to all.
- Make it clear that the project is a journey and perfection is not expected immediately. This is particularly important in collecting input for demand planning. Forecast accuracy measurements are a tool to plan (inventory) and enable continuous improvement, not a stick to punish an incorrect forecast, for example.
To net it out, the project will be breaking silos that many may have grown comfortable in. Some may need to be prodded, others coaxed, while others will jump right in. Nothing new in that, right? You and your team know how to do change management, and my point here is don't let the other aspects of IBP that suggest a simple implementation project lull you into complacency about this critical element.
