How to Get More From SAP APO

Executive Summary

• Companies that generally try to get more from SAP APO tend to fail.
• We explain why APO typically only is maintainable without enabling its upper end functionality.

Video Introduction: How to Get More From SAP APO

Text Introduction (Skip if You Watched the Video)

With the negative ROI of so many APO implementations, it’s critical to get the most from your SAP APO investment. And because SAP APO has more applications and functionality within each release than ever before, figuring out the appropriate area of functionality to leverage can make the difference in your SAP APO projects. This chapter focuses on how to improve the utility of your SAP APO implementation and how to stay away from APO project failures. So whether you’re just considering it or you’re already up and running with SAP APO, you’ll find valuable insights about how to get the most out of the applications.

Where to Look for Improvement

The question of where to look in terms of improving, expanding, or enhancing an existing implementation is easier in some ways than the question of which application to initially install and how to implement it. The primary reason is that your company is already familiar with SAP APO. You have the experience to know how long SAP APO implementations take, their level of complexity, resource commitments, and so on. However, there are still several unknowns because your company may not be familiar with other applications you want to evaluate, or there may be new functionality within new releases of applications you’re already using. When assessing how to improve your SAP APO implementation, you can take an offensive or defensive approach. So if you need to try to salvage an SAP APO implementation that fell short of expectations, you’ll need to look at it defensively. But if you want to improve on a current successful implementation, or you just want to add another application to continue the momentum and bring advanced planning into other parts of a company’s supply chain, you’ll be taking an offensive approach. Let’s begin by looking at ways to salvage an unsuccessful implementation.

Recovering Failed SAP APO Implementations

This is the most challenging position for any company to be in: After some promises, the implementation didn’t have its intended effect. The software has lost credibility with the user base and the executives. In this situation, the implementation recovery must fix the problem and improve the reputation of the software. So the first thing to do is make sure that everyone understands that not every attempt to implement a complex system succeeds the first time, but your company is dedicated to getting it right. But before we look at how to recover, let’s step back and look at the possible reasons why the implementation might have failed. There are several reasons for SAP APO implementations to fail. This list is by no means complete but comes from real-world situations:

• ››The solution is not designed correctly during prototyping. The most common problems are –– Development of an overly complex solution. –– Believing the representatives from within the company who declared, “If the system can’t do XYZ, the entire implementation is useless.” –– Not incorporating maintenance into the design decision.
• ››Picking an implementation partner more focused on monetizing the account than in getting the software implemented correctly ››Not correctly understanding the importance of user acceptance
• ››Not understanding how the new system is supposed to be used and interface with existing systems (both technically and functionally)

Steps in APO Recovery

The first step in recovering an SAP APO implementation is correctly diagnosing what went wrong. Often this process is short-circuited entirely because instead of a logical process of forensics being applied, the weakest departments are singled out for blame. Companies that take the politically convenient route and engage in finding scapegoats have a significantly lower chance of being successful the second time around. If the problem is misdiagnosed, the likelihood of fixing the implementation is low. This is where outside assistance can be helpful. The Recovery Analysis Team The most effective recovery team will be small and unaffiliated with any of the players from the original implementation or planned implementations to have no conflicts of interest. This team needs access to everything, every document, and every person and group involved in the original implementation. It’s also essential that the team not be comprised of generalists, and at least one of the team members should have content experience in the application in question. It’s unlikely that the most senior member of this team will have this experience, but that isn’t a problem as long as one of the junior members does. When the team is in place, they’ll determine the root causes of the failed implementation and guide how to get it back on track. One key to getting back on track, however, is being sure that those accountable for the initial problems that led to failure are held liable, and systems are put in place to avoid the mistakes they made.

Accountability of Partners

It’s surprising how infrequently implementation partners are held accountable for below par implementations. If a partner unsuccessfully manages an implementation, your company shouldn’t feel uncomfortable about switching out the partner. Also, the degree to which many firms are specialized isn’t well understood. Some partners can implement SAP NetWeaver BW or SAP ERP very well, but that doesn’t mean the same partner can implement SAP APO. Meeting the team that will be actually on your account is essential to improve project success. The consulting partner may control its pool of consultants, and subcontractors and other firms may be involved, but ultimately, the money comes from the client. It’s vital that the client actually oversee the consulting partner and not only outsource the project to the partner. While it’s simple, convenient, and less of a political headache to depend entirely on the consulting partner, this won’t necessarily lead to the best outcomes. Small, focused SAP APO consulting firms or even a team of contractors can work alongside a major implementation partner effectively. But the focus of the team, regardless of their size, should be on the implementation and not gaining future contracts.

An implementation partner is doubly at fault if an unsuccessful implementation goes live. They are most likely guilty for mismanaging the implementation, but also, no implementation should go live and then fail in adoption without the implementation partner knowing. It’s the partner’s responsibility to inform the client of the problem beforehand. If the partner doesn’t perceive the problem, then that partner lacks the proper experience or instincts and shouldn’t have been selected for the implementation in the first place. If the partner does perceive the problem but doesn’t bring up the issue to the client, the partner is abrogating its responsibility as an advisory team. If things aren’t going as expected, it’s best to postpone the implementation rather than go-live with a system with little chance of being adopted. If either the client or the consulting company lacks confidence as the go-live date approaches, there’s likely a good reason for the feeling, and the project needs to be analyzed for postponement. Postponement is appropriate because it’s easier to fix an implementation that isn’t yet live than to go back and recover a failed implementation.

To help you identify when you might be having consulting partner issues, we’ve compiled the list in Table 15.1 of “warning signs.”

Finding Implementation Partners

The best implementation partners are nearly impossible to find, as the consulting market for SAP is so corrupt.

Improving or Enhancing Successful Implementations

SAP APO Implementations Expanding or enhancing a currently successful SAP APO implementation is an excellent position to be in. This isn’t to say that adjustments in terms of implementation approach shouldn’t be made for the next phase, but the company now has the momentum to build on what’s working well. After the application has proven its capability, your company and team will have confidence in the system and be open to enhancing it.

It’s important not to get overconfident, though, because the new application or new functionality won’t be the same as the last application. You may have new team members who aren’t as familiar with the process. But after you decide to enhance the system, it’s just a matter of applying what worked to a new area of the supply chain or simply enhancing the current supply chain area with extra functionality. Areas to look at for enhancing a successful SAP APO implementation include the following:

• ››Areas of functionality that were desired but not included in the previous implementation due to budgetary or complexity reasons.
• ››New functionality that wasn’t available during the previous implementation.
• ››New processes implemented in your company that require new tools.

So let’s look at some of the areas that you can work with to address these issues.

Areas of Functionality Worthy of Analysis

What follows is an analysis of some of the promising areas of SAP APO that you should evaluate and analyze if your company is attempting to get more from SAP APO. Some of these areas of functionality are new as of this writing, so you may not be thoroughly familiar with them. However, whether old or new, all of these areas are particularly effective functionalities that have a high potential for providing a strong return on your investment.

Subcontracting in SAP APO

Subcontracting can be a difficult concept because often it’s confused with simple outsourced manufacturing. However, there’s more to it than that, and SAP has provided a definition that we’ll base this discussion around.

“Subcontracting is a form of procurement in which the manufacturer orders a product from a subcontractor (vendor) and provides the vendor with certain components needed to make the ordered product.”

The optimizer is appropriate for when multiple procurement decisions can be made. The company is indifferent, and the main differentiator is the price or can be represented with costs.

When subcontracting is enabled in SAP APO, it allows your company to better meet demand because the subcontract manufacturer is essentially competing against the in-house manufacturing to fulfill the sales order. This is especially useful if costs are set correctly in the SNP optimizer (assuming the optimizer is used) because then the company can allocate demand to capacity most efficiently. As you’ll recall from earlier in the book when the optimizer is used in either Supply Network Planning (SNP) or Production Planning and Detailed Scheduling (PP/DS), the system chooses the lowest cost production process model (PPM) or production data structure (PDS) that can meet the time and quantity requirements of the order. So if your company is under capacity at the time of the sales order subtracted from the production lead time, it makes sense to manufacture the order internally. If, however, your company is overcapacity at the date of the sales order subtracted from the production lead time, giving it to a subcontractor can be a better alternative over either postponing the customer request or having the customer go to a different source.

Subcontract Purchase Requisition

A subcontract purchase requisition is connected to the subcontract purchase order through the material that the company is receiving and the material that the company is providing to its subcontractor. The planned order shows all of the requirements for the subcontract components. In SAP, subcontractor agreements are brought into SAP APO through the CIF, SAP ERP, or SAP SNC (Figure 15.1), where they are put to use in both SNP. This allocates batched requirements to them, and Global Available to Promise (GATP), which allocates real-time requirements to them.

The next area of enhancement to consider is in collaborative forecasting.

• ››All of the planning methods have advantages and disadvantages.
• ››Although the SNP optimizer is still not the best solution for high prioritization levels; it can now do limited prioritization.

Prioritizing Demand for the SNP Optimizer

If you’ve implemented the SNP optimizer and had to give up the concept of prioritizing customers, it’s now possible to use optimization with prioritization. As of SAP APO 5.1, priorities can be set per customer by assigning customer-dependent penalty costs. The higher the penalty cost, the higher the importance of the customer. This is defined in the Business Add-In (BAdI) (/SAPAPO/SDP_RELDATA ) and assigns penalty cost groups to forecasts and sales orders. With a relatively small amount of data creation and configuration, this allows the provision of a priority to customers that didn’t exist before. Companies that benefit from this need to use the optimizer for procurement or make or buy decisions but want to have some limited prioritization. Until release 5.1, the only real way to allocate according to the priority of customers was to use CTM. However, the prioritization capabilities of SAP APO have now expanded; optimization and prioritization can be used together so that those customers that choose the optimizer aren’t left out of prioritization functionality.

In addition to enhancing older applications such as SNP, SAP APO has seen rapid development and functionality enhancement of the new applications such as SPP.

Repair Functionality in Service Parts Planning (SPP)

SPP added repair planning functionality as of release 5.1 and was discussed in Chapter 10. This is one of the functionalities that made SPP competitive in the market for service parts planning. With repair planning, SPP can compare the cost and lead time of bringing new parts versus repairing unserviceable parts at any location. This is a powerful functionality that can be used by service organizations and isn’t duplicated in any other area of SAP APO. Repair or buy functionality is well suited to high-value service parts that are cheaper to repair than procure. Almost every company that manufactures or supplies this type of service part has a repair planning program (in various states of effectiveness); this functionality systematizes the repair planning function. This functionality can be used for both service parts sold to customers and parts that are used to maintain equipment in the supply chain. In the second case, the parts may be inducted into repair by SAP Plant Maintenance (PM). This functionality requires the maintenance of several types of data:

• ››Unserviceable (i.e., to be repaired) inventory per product location
• ››Repair lead times per product location
• ››Repair costs per item

Buy Versus Repair

Buy versus repair functionality allows the company to keep the item at the location it’s needed in an unserviceable state, without incurring repair costs, until either a forecasted need increases to a certain level of probability or until an actual order comes through for the item. Because companies couldn’t do this before in SAP APO, it requires considerable effort on your part to implement and employ this functionality. But again, this is chiefly a master data exercise in developing repair lead times and costs per product location, so this is quite a bit of work. An important step is developing a method for adequately identifying unserviceable items and coding them appropriately in the location product master (which we demonstrate later). However, the benefit is that once complete, the company can let SAP APO make the buy or repair decisions. Based on the forecast, SAP APO can induct parts into repair to be brought into a serviceable state in time to meet demand.

The functionality works in the following way. When this functionality is activated, the system checks whether enough unserviceable products to be repaired are available and how the costs compare with procuring new products. Alternatively, the system can be configured to skip this analysis and instead always schedule a repair (which is processed as a repair order or refurbishment order by the execution system). A product location can have two statuses concerning repair or buy functionality. They are listed in Table 15.2.

To get to where the serviceable field is set, you need first to configure the SPP product location tabs to appear. As we discussed, there’s a lot of master data work to get to the point where buy versus repair can be used, but once it’s active, it can make decisions much easier.

Backward Consumption

Enhancement for GATP For those clients that have already implemented Global Available to Promise (GATP), there’s an added ability to specify the period consumption strategy that companies may want to evaluate. SAP’s definition of backward consumption is:

“This defines the sequence in which periods are consumed by product allocations during backward consumption.”

This means GATP looks for the planned independent requirement quantity that lies directly before the sales order. Backward consumption means that the company can provide available to promise quantities before customer need dates, which may be acceptable to the customer. If the customer accepts the new date, this is a more efficient use of capacity. Backward consumption allows the system to look back even a short period before the current date, scheduling resources that are unscheduled or under capacity.

The company can gain business at a low cost because the production takes place on resources that would have otherwise sat idle. As Figure 15.2 shows, product availability can be evaluated for products whose lead time end date is before the current time of the check, or for products whose lead time spans prior and post the current time.

The nice thing about this functionality is that there’s little that needs to be done to execute it. The functionality is merely opening up to allow GATP to consume more flexibly.

Another area that should be leveraged by companies and that is always a topic of interest is the more advanced methods of safety stock management. Improving Safety Stock Management Safety stock is the quantity of redundant inventory held to mitigate variability in the supply chain. Its existence is necessary to manage the lead-time variability from suppliers to customers. The formula for safety stock is:

Safety Stock = {Z*SQRT(Avg. Lead Time*Standard Deviation of Demand^2 + Avg. Demand^2*Standard Deviation of Lead Time^2}

Problems with Mismanagement

An old concept and elementary to implement in its more simple forms, safety stock is still significantly and surprisingly mismanaged in the industry. So, implementations of SAP SNP should pay considerable attention to safety stock settings. To stabilize safety stock, there’s a rule regarding safety stock that really shouldn’t be broken but often is. Safety stock needs to be either kept stable or depending on the method used, and the parameters shouldn’t be changed. This means it’s not a quantity that is to be altered to meet short term objectives, and reductions in safety stock values shouldn’t be decreed from on high to meet short-term financial goals. When safety stock is manipulated this way, it’s always very damaging for the company. We recommend using dynamic methods for safety stock, which means that safety stock can flex depending on the variability of supplier lead time or the forecast error. For some reason, safety stock isn’t well understood in corporate America, at least. If lower inventory levels are desired (which they almost always are), either forecast accuracy must be improved, or supplier lead times or variability must be reduced. There are ways to work on improving both the forecast and supplier reliability through any number of methods. If these inputs are improved, the safety stock (under dynamic methods) will naturally improve with no interference whatsoever. So the rule with safety stock is don‘t put the cart before the horse. Safety stock is the cart, not the horse.

Safety Stock Functionality

Offered by Supply Network Planning (SNP), SNP provides a high degree of flexibility in safety stock management. The functionality is complete and unusually straightforward to configure for SAP APO. The biggest challenge is understanding what it’s doing to supply chain inventory and having the discipline to implement it properly. There are two high-level ways in SAP APO to implement safety stock and then several derivations of each. The two high-level methods are listed in Table 15.3.

Common Methods of Setting Safety Stock

The most common method of setting safety stock is static safety stock, in which the value is hard-coded into the product location master. This value may or may not be an externally calculated value (it may be calculated in Excel or a third-party inventory management software package), or it may simply be entered based on the planner’s experience with the product. The more advanced safety stock methods in SNP are categorized as enhanced, and this uses some of the same inputs as in standard dynamic forecasting. It allows for the incorporation of service levels in the setting of safety stock levels. As with many areas related to safety stock, the settings for this are on the product location master. However, safety stock can also be set using a safety stock profile (Figure 15.3 ).

The problem with simply hard-coding safety stock is that if it lacks a transparent and consistent method, safety stock has an extreme tendency to become altered in an inconsistent fashion to meet short-term financial or inventory objectives (as just discussed). The second problem is that static safety stock settings don’t allow for flexing in the supply chain, which is the primary point of safety stock. If lead times, forecasts, or other input factors change, the safety stocks can rapidly become out of date, causing the company to store either too much or too little inventory. For these reasons, we recommend using the dynamic method or, better yet, the enhanced method (based on service level) of determining safety stock. The dynamic method provided within standard safety stock functionality does allow for the safety stock to flex along with the supply chain as input factors change over time.

There are many options to set for the safety stock profile, and this is just a small sample, but we can’t cover them all here.

The basic things you need to do when implementing safety stock planning include the following:

• ››Determine if you can work from service levels. If you can, and they can be assigned per product location, SAP can drive the safety stock from the service level.
• ››Find out if you can provide SAP the inputs it needs to perform dynamic safety stock calculation as it enables the system to auto-flex to the changing environment.
• ››If static methods must be used, make sure that the external system, and the external method, is very robust. The policy for setting safety stock is well documented and not subject to manual overrides or constant changes based on management trends or short-term financial objectives. Companies involved in frequently manually changing their safety stock, or changing their safety stock policies, lose many of the benefits of stability that a planning system can provide.

Production Planning/Detailed Scheduling (PP/DS)

Implementation Tips Because master data can always be improved, this topic should be one of the first places to investigate when a planning project begins. PP/DS projects are driven by the need to improve the production process. PP/DS is one of the most detailed of the applications in SAP APO because PP/DS provides the capability to plan for the many work centers (known as resources in SAP APO) in the factory. Another reason for PP/DS’s detail is because the time intervals being planned are short and numerous. The rule of modeling is the higher degree of details modeled, the faster the model can become out of sync with reality, and the more maintenance the model requires to stay in synch.

Production process models (PPMs) and production data structures (PDSs) (the SAP APO containers for the resources) require accurate and continuously updated constraint information. This shouldn’t be considered part of the SAP APO implementation, but instead needs to be understood as a different project altogether or at least a separate endeavor. That is, one is a planning project, and the other is part of master data maintenance. The planning project sets up a model of the supply chain, while the master data maintenance project declares what the network looks like, what the lead times are between locations, what the constraints of the model are, and so on. The most expertly configured planning system can’t substitute for accurate master data maintenance. The less precise the master data, the less effect the SAP APO has in improving the condition of the implementing company. Also, the emphasis on master data should increase when a planning system such as SAP APO is installed. Only on rare occasions is the pre-existing level of master data maintenance acceptable before a planning system installation.

Gaining Constraint Information

Constraint information should be developed before the SAP APO project begins and needs to be continuously monitored and updated after the SAP APO system is live. If a company has not implemented constraint-based production planning in the past, it probably won’t have this data and will have to engage in a parallel project to build this master data. SAP APO can’t provide your company with a feasible production plan without quality constraint data. The way to check the validity of the production plan produced by PP/DS is simple. The first question is whether the factory managers are following the plan or merely using it as a “guideline.”

We worked with one client where the factory plan generated production batch sizes that were so small that they would have seriously compromised the productivity of the plant. These batch sizes were set by the inventory management group that resided at headquarters and participated and gave input to the implementation. But the production managers, who were out in the factories, were not able to provide input. So, the plan became the expression of the will of the inventory management group. But what was forgotten was that the plan doesn’t control how the plan is executed. Using perfectly rational logic, the plan managers simply aggregated the individual batch sizes into larger production runs. And unfortunately, it’s not uncommon during implementations for the team to forget that if one group is given extra influence on the system configuration, they might use this power to steamroll the other departments. This happens with such frequency that it’s pretty safe to say it will continue to happen. So it’s essential to consider that plans that are seen as unreasonable by the people that execute the plan will probably not be followed. Real

Constraints for Real Planning

We say “real constraints” because it’s possible for PPMs and PDSs to exist and be configured in the system, but not to be constrained. This was an issue with a company we worked with. Because they had “implemented PP/DS,” they thought they were performing constraint-based planning. More in this case study is covered in Chapter 5. PP/DS can be configured without constraints to schedule an infinite number of unconstrained PPMs and PDSs. This is how the system is run if heuristics are used. However, if there are no constraints, that capacity must be leveled. This client neither constrained the resources nor ran capacity leveling and thus ended up with an infeasible plan. To increase the likelihood of getting accurate PPM and PDS information, you can follow these approaches.

• ››Address the master data maintenance issue early. Begin asking questions as to work center, routing, and BOM accuracy. There will be areas of improvement. These need to be addressed as soon as possible and need to continue to be addressed. Business groups will always have the content knowledge to update their business information. But they need the assistance of a data-oriented team, a master data maintenance team, to help them systematically manage their master data. This team can ensure consistent processes between business groups, provide tools for master data entry, perform archiving of the master data, and keep the business out of some technical details that are not their forte. If you don’t have a master data maintenance group that interfaces between IT and the business, consider very strongly creating one.
• ››Many times factories are distributed internationally, or in areas of the country far from where the planners and those that maintain the SAP APO system work. In many cases, factories believe that corporate headquarters doesn’t take enough input from them. Don’t let this happen to your PP/DS project. Stay in constant communication with factories in terms of their constraints, and for SAP APO, the planned constraints, and update the model to match what the factories are saying. There are several methods for implementing this, but they don’t need to be complex to be effective.

Don’t Rely Too Heavily on the Planning Book for SAP APO Success

The planning book does some things well. However, it has a learning curve so, planners shouldn’t be blamed for not readily and enthusiastically adopting it. If the planning book is holding up user adoption, work around it. There are all types of customized reports that can be developed to support planners. This will mean more work on future upgrades, but planner acceptance is critical to all of the hard work and expense put into the configuration being accepted. One way of doing this is allocating enough money for this activity during the project planning stage. During the implementation, there’s often an option between selecting a simple and straightforward solution versus a more complex but fully featured solution. If the more complex and fully featured solution doesn’t leave sufficient post-implementation money for system adjustment and employee education, the company is almost always better off selecting the simple answer. This is dramatically the case at not just a few, but at every company, we’ve consulted for.

Provide Ample Non-consulting SMEs or Super Users

While consultants can provide specific expertise, there’s a difference in approach and style between a consultant and planner. Consulting firms tend to hire two types of people to help users: those with SAP APO configuration experience and those with change management experience. Neither is generally best suited (although there are exceptions) for providing long-term support to planners and users. Secondly, it’s quite expensive to use consultants to support company users continually. SAP APO reduces the amount of work to be done. So we recommend that one to two of the “line” planners be converted to SAP APO SMEs (a.k.a super users) to serve as a training and support resource for the other planners. This SME continues in the role after the planners become comfortable with SAP APO in training new hires, serving as a liaison to first-level and second-level support, and in producing cross planner or cross-material research on a continual basis.

While the concept of a superuser isn’t new, transforming them into SAP APO SMEs and removing their line responsibilities, have several advantages. Freed up from day-to-day planning responsibilities, they can focus on making the other planners better. They also can become valuable conduits for information to support managers. However, if their day-to-day planning responsibilities aren’t removed, and their compensation isn’t changed, there is little reason to expect them to take their SME “responsibilities” seriously.

Planner Acceptance

Individuals need to be courageous and vocal enough to be viewed as advocates for planners. If it’s one person, that person must represent all of the planners (if there are two or more people in this role, then each must represent a portion of the planners). This individual must keep good relations with all of the planners and not merely represent the interests of the materials they used to plan. This is a bigger and more complicated job with political implications, and thus their pay should be increased accordingly. The reason we’re so particular in defining this role is that one of the most common reasons for lack of planner acceptance is a combination of insufficient support and planners thinking no one is addressing their issues and concerns to either support or management. In our experience, companies most often expect planners to simply pick up a complex new system with very little tutoring and with little appreciation for the effort they have to put in to learn the system.

The Myth of Instant Use

The previous discussion leads to a discussion of one of the great myths of product adoption. New technologies, particularly significant technologies, take time to be effectively adopted. For instance, the seatbelt was invented in the 1920s (on the race track). It wasn’t introduced into passenger cars until the mid-1960s. However, its use was extremely low until the mid-1980s. The same holds true of the printing press. It takes a while for any new technology to go from curiosity to being generally accepted. Full acceptance and adoption come when the item or concept is no longer seen as an innovation. One example is the arch. At one time, the arch was considered very innovative. Now, it’s just part of the backdrop of architecture.

After the Implementation

Implementing companies and outside observers place a great deal of focus on the countdown to go-live. After the go-live and the system is rolled out, there’s a tendency to underestimate what happens.

A frequent question for SAP consultants interviewing for new projects is how many full lifecycle implementations they’ve been involved in. This question assumes that the significant work happens during the implementation. However, what is often missed is that much of the diagnostic work efforts occur after the project has gone live. This allows a consultant to get into many issues that were passed over or even incorrectly designed during the actual implementation. Consumer software is the best example of how inaccurate this general understanding is. For instance, after consumers install Excel or Word on their computer, do you think that the most interesting part of the process is over and that the users simply begin using the software at the optimal level? No one would propose this. Having the software available is just the beginning. There’s a learning curve with all software, and because SAP is far more complex than Excel or Word, the learning curve is much steeper. And the learning curve isn’t limited to the users of the system because gradually, as the system is put into use, information about its capabilities and limitations are communicated up to the executive level. Hence, they begin to think about what other functionality they want to get out of the system in the future.

Improving Usage Efficiency with Model Maintenance Methods

One of the biggest challenges for maintaining an SAP APO system is to understand the master data simply. When a user or consultant approaches the SAP system, he must be mindful of the location and product combinations, at a minimum, to progress through the transactions. This information isn’t well documented or easy to find, and employees and consultants end up wasting valuable time hunting and pecking through the system trying to find the right combinations. As anyone who has used SAP can attest, without the right combination, it’s impossible to progress through transactions. Finding master data such as the product names in the model, the location names, and so on is very important, and the master data for the SAP APO application can be found using the methods in Table 15.4.

However, neither solution is optimal. Using tables takes significant SAP experience and isn’t efficient even for technical experts or the supply chain engineer. It has a difficult-to-use interface and is rarely used on projects. It also doesn’t appear to have received any development in years. Far more preferable to either approach is creating a simple website on the company intranet that presents the model setup both in text and graphical form. This way, the model design can be accessed with or without SAP access, which means it can be used by non-SAP resources to understand what has been modeled. It’s surprising how infrequently we’ve seen this at companies, and yet how comparatively easy a site like this is to set up. We’re also not aware of any consulting companies that offer creating a web-based model as a service. While some may consider using SAP Solution Manager for this, Solution Manager is a document management solution, which primarily focuses on storing project documents. It’s not a replacement for what we’re discussing here. It’s something a company would have to either build itself or contract with a non-SAP consulting company to build.

Doing this for many years, we’ve become very familiar with the WordPress blog platform. In our view, WordPress is one of the best information management software applications currently available. Either WordPress or other similar software (such as Typepad, which is also quite good) should be the first choice when selecting a platform to manage information about SAP APO configuration or master data about the implementation. Blogging software is typically free (although there are some minor costs for upgrading to extra functionality) and continually improving. It’s incredible to us that Microsoft SharePoint has taken over the corporate information/ document market. Unfortunately, this is entirely counter-effective for information management. However, because Microsoft’s relationship with companies is so strong, it’s likely to take more than a decade to realize they are migrating their documents to an inefficient platform. We have a hard time convincing either consulting companies or clients that you can’t have an efficient and cost-effective implementation with inferior document and information management tools. This is a massive blind spot for the vast majority of companies engaging in IT implementations. However, this blind spot doesn’t exist outside of companies as few take information management seriously. There is no such confusion on the web. Many millions of people have started their own blogs. We often find that blogs started by individuals who have better content and more reliable (less promotional) material than nonblog websites.

Conclusion

The SAP APO applications can be connected in many different ways to address client needs. As SAP APO has grown, it has meant more applications addressing more areas of functionality. Having a high-level understanding of the overall architecture of SAP APO is vital to making right decisions about which are the best applications, as well as the best areas of the application to configure for a particular company.

Companies often don’t realize how much time consultants and users spend simply finding combinations of master data that allow the individual to proceed. So every company implementing SAP APO (and SAP ERP for that matter) should invest in an intranet website that provides detailed information on the basic master data of the configuration (locations, products, planning areas, planning objects, etc.). From all of the information we’ve covered in this chapter, it should be clear to you that SAP APO implementations are not finished when they go live. Significant knowledge is gained after implementation if your company is open to understanding how the solution is behaving. Finally, after a system goes live, companies should not cut off the opportunities to learn as the system progresses.