How to replace APO

Whether it is in a few years’ time, by 2027 when general maintenance for SAP APO is due to expire, or several years beyond that, all organisations that use APO know that within the next decade or so they are going to have to turn APO off. This is a significant challenge. For all its shortcomings, many critical planning and executional processes are supported by APO, and in many cases these processes have been underwritten by large investments in detailed, bespoke features. Furthermore, the large, decades long budgets that fueled this complexity in APO no longer exist in many organisations. We are now in an era of heavily scrutinized business cases, with returns demanded in the short term.

So, with the example of “APO replacement” in mind, I would like to present some broad, related perspectives that I believe would be helpful as part of the discussion around the transformation of planning capabilities and planning technology in general. I have divided these perspectives into four categories: the solution roadmap, the project approach, and the software vendor strategy and assessment.

Solution roadmap approach: outside-in versus inside-out

Project approach: agile versus waterfall

Vendor strategy: partnership versus best-of-breed

Vendor assessment: holistic versus detailed

Solution roadmap

The solution roadmap perspective involves whether to focus first on the white spaces in a planning solutions landscape (what I have called the outside-in approach) or to focus on the core planning capabilities already supported in the legacy tool (the inside-out approach). An outside-in approach would involve introducing new capabilities via a new planning platform and then gradually expanding the solution footprint of this platform “inwards” to eventually replace the entire legacy solution scope. The inside-out approach would start with a renovation of the core planning processes already covered in the legacy solution, introducing enhancements for poorly supported processes (such as scenario planning in the example of APO). Obviously, the specific priorities in an organization will to a large extend drive the direction around which approach makes the most sense. However, it may be helpful to be aware of some underlying consequences of the chosen approach. One of the main consequences is in scope control, and this strongly relates to the perspective on project approach. The outside-in approach lends itself to incremental implementation, and hence scope flexibility. Business value can be achieved at relatively low cost and in a short timeline. The inside-out approach, however, requires a relatively large initial investment (the replacement of a mature planning feature set) to achieve any business value at all. A further consequence is in risk management. With the outside-in approach the risk in each increment, and, in particular, the initial implementation, is relatively small. Whereas with the inside-out approach the risk of the initial implementation, particularly, is higher.

Project approach

This perspective involves whether to adopt an incremental approach, starting with a “minimum viable product” (MVP), or to pursue the traditional large initial implementation approach. Now, the literature on the benefits of agile versus traditional approaches is vast, and frameworks like Open Agile Architecture and SAFe do a much better job than I can of describing how and why to bring agile approaches to organisational endeavours. I think what is important here is to stress the advantages of delivering solutions with a certain measure of scope flexibility. In these times of intense budget scrutiny and demanding timelines, having scope flexibility is important. However, replacing any substantial portion of the core of an existing planning solution does not leave much flexibility in functional scope. There is a large feature set that simply must be delivered in the new solution for it to have any value. So, if the inside-out roadmap approach is an organisation’s choice, then it is important firstly to plan better, and secondly the organisation needs to be prepared to modify scope aspects besides functionality (for example business scope) and possibly even be flexible on the timelines. It goes without saying that stakeholder expectations should be set accordingly at the time the solution roadmap approach is decided upon.

Vendor strategy

No vendor of supply chain planning solutions on the market today offers the complete, best solution. So if an organisation wants a single, best, complete solution then they are going to have to help develop it. That implies a partnership approach with a single vendor. The advantage with this approach is that you have a better chance of ending up with exactly what you want, and in a unified solution landscape. The disadvantage is that it takes time. If there is a level of urgency in an organisation in any particular area, then this would drive the strategy towards best-of-breed. Now, in this perspective it may help to take an organisation-wide philosophy, bearing in mind that it takes time to cover a significant portion of business scope with a new solution anyway. This means that maturity in solution features is not something that is necessarily required immediately. Obviously, some degree of solution maturity is required in some areas in order to provide sufficient business value for the initial use cases. However, full solution maturity is something that should be aimed to be achieved at the time the whole organisation is ready to adopt the full solution, and not necessarily before that time.

Vendor assessment

This perspective involves whether software vendors are assessed based on broad capabilities and vision versus detailed function and features, and this is strongly tied to the vendor relationship strategy. Clearly, if an organisation intends to cover the specific planning capabilities with the best vendor in each area then they will have to assess each vendor’s functionality in the respective areas in considerable detail. And since the focus is on specific, narrow functional capabilities there is less value in assessing other aspects such as the vendor's vision, even within that particular field. If another, better vendor emerges in that field they can just move to the new vendor. On the other hand, if an organisation is going to bank on a single vendor, then they better be sure that this vendor has sound technology foundations and a vision in which they will be a leader in areas of importance on an ongoing basis.

I will leave things abruptly there because the vendor assessment approach, including the running of proofs-of-concept, is a whole topic in its own. I’d be interested to hear other perspectives on the transformation of planning solutions and certainly be happy to share more from my own journey in this exciting field.