Latest Blog Entries

06 Jan Key To a Successful APO Implementation? A Reality Check.

(By Mike Raftery)

Why is this so hard? Why does it feel like I’m the first one to implement? Every APO project has a moment, or two, (or three?) where you ask yourself these type of questions, ‘What are we doing wrong?’ Commonly when these issues pop up, the best thing to do is take a step back, figure out where you are, and refocus on where you want to go.

But how do we end up here in the first place? There are usually two probable causes to this issue. The first happens when an organization overextends themselves and tries to run before they walk. The second occurs when a team tries to layer their old legacy solution onto the APO platform. Either way the root cause comes down to a disconnect with reality.

A truly successful APO implementation means truly knowing where you are, and where you are going. An organization that is too optimistic or in denial about the journey ahead of them will face more issues than needed. An honest assessment of what to expect, and what your organization can actually handle will mean a smoother release than any top notch developer or pricey enhancement.

There are some projects that reach for the stars. These companies see the glossy PowerPoints from SAP and want all of it. Optimization? Sure I want to be optimal. Detailed scheduling? The more detail the better, thank you very much. And while you’re at it, I would like to see all of the alerts possible. These implementations can work in time, however, with a new APO implementation, that is a lot for a company to digest all at once. If the planning organization is not used to managing a complex planning application, the scope and detail required will be overwhelming. They will be stretched too thin, and will do everything “ok” rather than mastering anything at all. These implementations end up stretched too thin, expecting too much and never quite get traction to realize the benefits that the organization expects. As a result, the team gets frustrated, scattered and overworked. Eventually they start looking elsewhere and the project stalls, moves to work-arounds and never realizes a fraction of those glossy PowerPoint promises.

A different type of reaction ends up with an organization with its head buried in the sand. The fear of change leads to one requirement: “give me what I had before.” This is not only short sighted, but also very risky from a project perspective. The fact is, the organization did not have APO before, so the solutions that worked in the past need to be reconsidered into the APO landscape. Not only does this add unnecessary development and customization, it usually ends in a worse solution in total. The ‘carbon-copy’ project plan wastes time and money faster than any other strategy, when the intent is to do the exact opposite. In the end, after months of frustration and arguments, the organization realizes that this is a new world and will evolve eventually. Usually by that point, the money is spent, the project has pulled up stakes, and you end up making due with what you have, rather than getting what you need.

In both of these situations, the biggest issue is refusing to see the situation as it is. You must know yourself as an organization, your capabilities, strengths and weaknesses in order to truly layout expectations, and benefits that can be achieved. In the same way, you must also understand that the past is not coming back and the faster you can adapt the existing processes to the new application, the better and cheaper the project will be. In both scenarios, a good long look in the mirror will do more for your project than any developer or architect ever could.

Differentiating the Differences in APO requirements
SNP and PP/DS Planning Horizons