Biggest challenge in a implemetation

[Former Member]

Hi Gurus,

A non technical question. In your experience, what do you see is the biggest challenge in implementing a complete life cycle for APO?

My answers could be like "The user involvement", "Realization and fixing gaps", "getting APO to deliver what I want etc."

I appreciate your input.

Thanks.

[srinivas_krishnamoorthy · Accepted solution]

Some of the biggest challenges

- User Change Management to make the users embrace APO solution

- User requirements changing post-implementation after they have an adequate feel of the system

- scale out in production could lead to performance and sizing issues not encountered in test/quality system

- inadequate master data preparedness leading to host of queue blocks

there can be many more, however the 3 above stand out.

[Former Member · Accepted solution]

Thanks. I agree with you. The biggest challenge I see is the users embracing the solution. Initially in blue print, they give requirements with half knowledge but by the time they get complete understanding it might be too late.

I also agree with your other challenges.

Thanks.

[Former Member · Accepted solution]

maybe the responsibility is on the consultants/ technical sales ppl for not demonstrating the capabilites.

requirement gathering is a two way process... unless you have a stubborn client

cant expect the business ppl to understand a solution that easily. most requirements are usually based on current cuntionality of the system that is on its way out... its upto the project team to expain the difference in approach.

[former_member188806]

I agree with most of you, but i have a different point here: Look at APO implementations which are successful, you will always find one thing: "Design and expectations are simple" and i have experienced it real life. More complex stuff you expect, you end up in a mess.

So my mantra for all APO clients and partners is please keep it simple and get there gradually.

Regards

Kunal Waghmare

[Former Member]

I agree with all of u.

Most of the time Client expects results to comes after clicking just one button.

Biggest challenge is to connivance client what is possible and what is not, what is beneficial to company (client).

Thanks,

Nikhil

[former_member584840]

Master data! - all the products share the same base unit of measure except a few. How to convert if the other materials do not make sense to all convert to the same base unit for the planning area?

Always a small percentage of materials that have some issue in the master data world.

Make sure you do a prototype with a FULL set of master data - so need a FULL size QA box before going live to pick up all the master data anomalies.

Also, assume that there will always be unseen issues that need resolving, so ensure there is enough time/space to test - eg by full prototype with full data, or ensuring the solution is not on the mission critical path for the day to day running of the business and that there is a fall back option if it takes 5 days to solve a critical problem.

[Former Member]

I agree with all the guys...but in contrast the companies implementing these project they are not hiring for people who are experts of planning in domain and then have expertese in APO. It obviously has to be called as planned to fail!!! I would put the onus on the consulting company management for any failures in the implementation of APO or for that matter even ECC or R/3 system.

The biggest challange in implementing a solution is precisely in picking a right implementation partner!

Regards

Prasanna

[Former Member]

More than the points mentioned by the people above the following can be the major challenges in implementation of APO

1.) Readiness of the Firm for implementing APO

2.) User Discipline and Selection of Correct Strategies

R/3 is a transaction system which directly helps eliminate lot of efforts, paper work and ensures integration and faster communication amongst departments. APO requires a lot of user discipline from the organization perspective. Requirements can be

a.) Correct and adequate data for planning

b.) Selection of correct strategies :- in all modules whether it is DP, SNP, PP

c.) Discipline at the user in terms of usage, extraction and monitoring

3.) Alignment of Business Objectives and APO strategies for Planning

The strategies used in APO should be in alignment with the vision of the company. This doesnt happen most of the time. APO implementation and alignment of business objectives is not present

[former_member1230066]

I would agree with Ian, APO projects are implemented by consultants who probably are more system focussed and I think the gurus would agree that APO is not a transactional tool but an analytical tool, The need for consultants who have extensively worked in the supply chain planning space is a pre requisite for good implementation.

I think more time should be spent in understanding the business requirements than configuring the system.

Another point to add is we must have consultants possesing expertise is one or two modules of APO rather than being APO Consultants. Knowledge of a sub module in APO and Expertise in a sub module of APO needs to be defined and pitched accordingly to the client.

Prashant Kumar

[Former Member]

I have almost 4 years of APO implementations and I have only one point that I think it's the most important one:

- The clients are not prepared for the advanced planning systems. I don't know a client that make the correct use of the MRP, so an optmizer seems to be 20 years ahead.

[Former Member]

Agree with all of the above, however I will just throw one in for Devilment 🐵

This one is obvious, but often overlooked. You must have the right people to do the right job. There’s no getting around it. For example, programmers need to have experience in the technology before you can count on them, so select them wisely. Furthermore, managers can perform poorly if they lead projects that do not match their strengths. Projects dealing with high technology need managers with solid technical skills. In such projects, authority must reside with people who understand the implications of specific technical risks.

However, the best technologists are not necessarily always poised to be the best managers. The skill set for management and programming are disjoint. The larger the project, the more need there is for people with excellent planning, oversight, organisation, and communications skills; all excellent technologists do not necessarily have these abilities.

The solution to skill-driven challenges is easy to define but difficult and expensive to accomplish: Attract and retain the most highly skilled and productive people. A team made up of higher-paid people with the right specialised skills is worth far more per dollar to an organisation than a group of lower-cost people who need weeks or months of fumbling through a new process or technology before they can start being productive.

You get what you pay for.

I have seen many an APO project fail because the level of Consultants on the project was simply not good enough. Good consultants are worth their weight in Gold, a true project environment is not one conjusive for learning on if there is no suitable mentor in place to advise/critique work.

Regards

Ian

[Former Member]

I have been in APO for 7 years ... since Year 2000 and I can tell you some ...

I have not seen SCM 2007 yet ... & not actually gone live on a SCM 5 EndUser Production system ... but the following are my experiences prior.

BluePrint requirements changing has been very common in most SAP Projects that are Enterprise Wide and often decisions for the entire Organization cannot be made upfront during the time of Blueprint. Standardization of Process withing the Enterprise is extremely difficult. So this is more a SAP Issue rather than just APO. Maybe more a ERP issue & not just SAP (eg : Could happen in Oracle, Peoplesoft, MfgPro ... etc also bcoz Process Standardization across the Enterprise is a very difficult job). What Consultants will put in a BluePrint is simply based on what they are told & what the Business Champions know. But they don't know everything about the entire Enterprise.

- Users expect a Lot out of Planning and it takes a Lot of Functionality to Replace a Spreadsheet. APO till date falls short of dealing with some planning issues like storage constraint based planning, alerts not as good as MRP exception messages .. etc. APO Projects still require a lot of developments to be done.

- Horrors of LiveCache Crashes in the releases prior to 4.0. Since then LiveCache has stable up a lot.

- Que Issues that just don't seem to go away since they are caused by incorrect master data that is incompletely set by end users & materials flagged for APO accidentally.

- Que Errors lead to Inconsistancies in R3 & APO data causing in Planning errors due to wrong data represented in APO.

- Many Strong Users need to learn 'Debugging' of RFC Ques to be able to solve issues in time. But they have to stop at the point of a LiveCache call Routine as it is no more ABAP.

- I am yet to see a APO Project in which No User Exit was to be ever coded. Some of the Functionalities of blocking fields in materials, changing ordertypes, changing resources/PPMs all this is non-standard functionality to be put in a User-Exit.

- Till date to replace a Planners Production Scheduling Spreadsheet that takes care of not only Production but also Labour and RM/PM Requirements in their spreadsheets ... there is no report in APO that can plan everythign. We know planning of 'Labour' for sure is never done in APO ... so replacing a Spreadsheet is a very tall order.

- The Analytics of SupplyChain have to be still built in BI as part of the Project. The APO Effort is still quite high on Projects for developing the KPIs.

- Standardization of Planning Process and too Enterprise-Wide in different Geographies is an Extremely difficult thing to do. Usually the Project sponsors & business champions do not know enough about the WORLD before they make Standardized Process designs.

There's a longer list than this ... but this is by far the most painfull. Till date I have not see Que Issues of APO get any better & Inconsistancies between R3 & APO cropping up resulting in incorrect Planning.

Regards,

Ambrish Mathur

[Former Member]

a few of these are from history and might be a bit out of date... but nevertheless...

--> implementing APO with no real motivation but just to bring planning systems into APO landscape

--> not using more of the planning capabilites and using APO as a data transfer point and hence not getting full value

--> lack of innovative solutions on the part of solution architects to meet requirements

--> r3 mindset to understand the real benefits and mostly blaming the solution to cover lack of understanding

--> comparing APO to Excel (not any more since we got cut paste)