The tips are categorized into two sections: “Preparation” and “Technical Setup.” The “Preparation” section offers tips for the project planning phase. Topics include scope, team roles, and deadlines. Before customization/configuration begins, the five preparation tips can help teams focus and avoid potential headaches down the road. The “Technical Setup” section provides tips for configuring SNP.

Preparation

Tip 1. Focus on master data. Master data is the foundation for SNP. Most companies use SNP in conjunction with R/3 or SAP ERP Central Component (ECC) as the execution system. One major benefit is the ability to integrate both transactional data and master data. However, you must combine the ECC and SNP requirements to maintain master data in an organized and effective manner. Master data represents the various switches and buttons that allow a planner to modify plans, projections, and scenarios. If the switches and buttons are erroneous or out-of-sync with ECC, then planners encounter inaccurate plans or potentially serious performance issues.

The two main areas of master data that you need to maintain are the product and transportation master data. To access the settings for these, follow SAP Easy Access menu paths Master Data>Product and Master Data>Transportation Lane, respectively. Figure 1 shows an example of the master data that you need to maintain for a product. The impact of absent master data processes is more visible after go-live. During the configuration and validation phases, master data in the testing environments is more static. Team preference — constantly updating master data is a hassle to a development team — and the fact that you don’t have master data changes from other departments are contributing reasons for this. Generally, implementations focus more on executing a process or handling a scenario than maintaining data. When go-live occurs, the SNP team jumps right into an environment in which master data — such as new products, bills of material, and plants —changes often.

Figure 1

SNP maintenance screen for product master data

For example, the transportation lane in SNP is equivalent to the shipping route in ECC. In both, the company establishes transportation duration between two sites, such as a plant and a distribution center. When Transport Load Builder (TLB) in SNP creates a stock transport order, it sends the order to ECC, which re-determines actual shipping and delivery dates based on its shipping route. It ignores any transportation lane settings in SNP. If a user changes the transportation duration in ECC but ignores such a change in APO, then corresponding stock transport orders show different dates in ECC than intended. When creating the stock transport order in SNP, the user may intend for the delivery to occur on a certain date, but the end result differs.

Focus on master data by either:

• Designating staff to collect and audit master data and to ensure proper cross-departmental compliance
  
  
• Implementing a master data management tool that allows the disparate groups to enter their data without sacrificing the needs of other departments

Regardless of the method, it is critical that the team employ a proactive approach to avoid master data issues after go-live.

Tip 2. Map the network. SAP Solution Manager recommends mapping the supply network for implementing SNP. You can take this map to another level and make it the heart of replenishment planning discussions and changes.

The map provides a focus for setting up the network in SNP. It also prompts for discussions regarding necessary transportation lanes. Using the map, the SNP team may address synchronization issues and set-up issues with other teams. The Sales and Distribution (SD) team may have input regarding shipping and delivery data such as shipping calendars and delivery calendars. The Materials Management (MM) team may have updates and comments about stock transport orders. The DP team can discuss forecast placement changes.

Another benefit of the network map is that it simplifies communication of network changes after go-live. Plus, you can use the map to validate the network in SNP.

To design the map, create a drawing in a large and accessible area. The drawing should contain any SNP manufacturing sites, distribution centers, Vendor-Managed Inventory (VMI) customers, co-pack sites, sub-contracting sites, and vendors. Include arrows that show replenishment routes between the sites (Figure 2).

Figure 2

A simple supply network map

Tip 3. Organize functionality development in phases. An advantage of implementing SNP is the layers of available functionality. SNP helps planners guess mid- to long-range capacity situations and react to those guesses. Much of the functionality in SNP is like a toolbox intended to make the guesses and reactions more to the planners’ preference. Each tool works with other tools to assist planners. Many of these tools function independently of each other, so the company may choose to prioritize the implementation of the tools.

For example, heuristics is the lowest risk, yet lowest benefit planning engine in SNP. Heuristics assumes infinite capacity, so planners use exception management (Alert Monitor) to find and deal with overloads. Capable-to-Match (CTM) is a more complex planning engine that is riskier than heuristics, yet it may provide more planning options and benefits. CTM allows planners to prioritize demand elements (products, customers, and order types) and supply elements (planned orders, on-hand stock, and production orders) to match the demand. Heuristics is easier to implement than CTM, so a business could focus on heuristics first to allow themselves time to adapt to using SNP and all of its common processes such as deployment, TLB, Alert Monitor, and master data maintenance. A company might implement CTM after going live with heuristics.

By organizing functionality rollouts into phases, a company may see a clear picture of priorities and timing regarding functionality. Imagine a circle. Declare mandatory functionality within the circle. This functionality could include APO Core Interface (CIF) or planning environment management (area, version, books, views, and model). Draw a larger circle outside of the original one. Within this outer ring, declare the next highest priority functionality such as manufacturing site heuristics (Figure 3). In the next phase, you could state that distribution site heuristics is next along with some alerts. In another phase, deployment/TLB, additional alerts, and capacity leveling are options. Using the phases, a team may organize priorities of SNP functions to support the team’s use of resources.

Figure 3

Prioritize when planning your implementation

Tip 4. Avoid over-burdening SNP. SNP assists in creating rough-cut mid-term and long-term plans for bottleneck or critical resources. A common mistake that some SNP teams make is to plan for the short term or for high-capacity resources.

For instance, in the pharmaceutical industry, the active ingredients usually dominate costs. In fact, 85- 90% of the cost of a branded drug is the active ingredient. This encourages companies making branded drugs to plan for active ingredient raw materials as well as finished goods in SNP. The inventory cost (and probably long lead times) of the active ingredients calls for close monitoring in its phases of procurement and planned production. However, long-term planning for raw materials, such as packaging, aluminum, and water, is unnecessary in SNP because the materials are easily obtainable and capacity is not an issue compared to active ingredients.

True SNP work is done after the short-term scheduling horizon to optimize large volumes rather than minute details. Trying to duplicate detailed scheduling or model against all variables in SNP is nearly impossible and unadvisable. Modules such as Production Planning (PP) assist short-term planning. The one exception to this is deployment and TLB, which is discussed in tip 5.

Tip 5. Regard deployment and TLB as separate from SNP. Deployment is an APO tool that draws on user-established policies to create replenishment orders, whereas TLB uses deployment orders to generate vehicle load recommendations. Technically, deployment and TLB are separate functions within APO. Most SNP projects include the two sub-modules because they are natural progressions from the SNP plan and have fewer functionality options compared to the rest of APO. Deployment and TLB qualify as near-term planning and often fall within the short-term planning horizon.

By organizing the implementation team into sub-teams that segregate the short-term deployment and TLB team from the long-term planning group, the SNP team benefits from the ability to execute parallel project plans: one for rough- cut plans and one for deployment/TLB. The project manager may designate people to focus solely on the two sub-modules while others work on the rough-cut network plans and capacity leveling.

Also, companies often have designated staff that handles replenishment and stock transports. Having a separate sub-team to work with this replenishment staff allows for more awareness of replenishment issues involving deployment/TLB. The same occurs for the SNP sub-team that concentrates on capacity leveling and rough-cut long-term plans. Segregating the teams helps debunk the myth that the SNP, deployment, and TLB tasks are purely sequential when in fact deployment and TLB are mini-modules in APO. It also allows you to combine both teams via a single status and management thread to ensure maximum resource flexibility while both work toward a joint design.

Technical Setup

Tip 6. Manage CIF queues in APO rather than in ECC. CIF is the main conduit for both transactional and master data between APO and ECC. Managing and monitoring the CIF is a significant activity. If problems occur in CIF, then erroneous data may exist in APO or ECC. Also, some errors could block CIF, which would shut down the interface.

CIF administers data movements between APO and ECC using queues, which are sequences of data processing. Each queue may have multiple data objects within it. The system orders the queues and then acts on them in the set order. If one queue encounters a block, then all other queues encounter the same block. In other words, the CIF has a bottleneck risk within queues.

When processing the queues, ECC and APO require settings to manage them. One such setting is the Queue-In Scheduler (QIN Scheduler), which determines which system handles the load of queues. For example, if ECC sends 10,000 planned orders to APO, then the system sends the planned orders in queues (blocks of data). The queues can move between systems faster than the systems can process the data. If you set APO to manage the queues instead of ECC, then ECC sends the 10,000 planned orders to APO and allows APO to administer the data. Basically, the bottleneck resides in APO rather than in ECC.

Having APO manage queues over ECC is a prudent step in CIF system administration. ECC has more critical activities occurring. If a queue bottleneck occurs on the ECC side, then ECC may react by dedicating valuable processors to address the bottleneck. This problem could shut down the system or render it extremely sluggish. Any slowdown is more welcome in a planning system (APO) over an execution system (ECC). To avoid placing that burden on the execution system, manage CIF queues in APO.

Tip 7. Minimize event and default macros. When designing planning books and data views, users often request certain functionality between key figures that is outside the default setup in the planning book. Usually APO analysts look to macros to fulfill those requirements. Macros are functions that may contain calculations or decisions with a focus on key figures. Key figures are groups of transactional data (e.g., on-hand stock, planned orders, forecast, deployment orders, and planned receipts). With macros, SNP may use default key figures, change key figures, or create key figures with an exceptional purpose. For example, a planner wishes to add all planned receipts and certain planned order types together in a key figure. Using a new key figure, the planner creates a macro to add both key figures.

A serious drawback to using macros is APO resource limitations. Macros have multiple ways of executing. One way is by event. If a planner looks at new data in a planning book, saves data, or re-loads data, certain event macros may trigger. Specifically, one execution method for a macro is by default. When the planning book opens, default macros trigger. As the list of default macros grows, APO must execute each one. Eventually, the data loaded and the macros executed take their toll, and the system experiences significant slowdowns.

Try to minimize macros, especially if they are default macros. If the macro is crucial for constant plan changes and monitoring, then limit that macro to only those data views in which it is required. Also, use manual macro execution or background macro execution as options. For example, if a macro simply requires one execution per week or per day for a large query of data, then schedule it in a background job during non-working hours so it doesn’t interfere with routine planner work. The goal is to reduce the burden that macros place on the system to allow for quicker data processing and response times.

Tip 8. Use parallel processors for background jobs. Background jobs in SNP help reduce manual work for ongoing executions of functions such as heuristics, capacity leveling, CTM, deployment, or alerts generation. When performing activities in the background or foreground, SNP uses APO processors, but APO has a limited number of processors. Although foreground jobs take much longer for the system to complete, APO may choose to use a large number of processors to complete background jobs, which leads to system performance drain.

Parallel processes help organize system resources to complete background jobs. A parallel process is the concept of using multiple and designated processors to handle a certain event. In other words, APO sets aside a certain resource capacity when executing a job using a parallel processor. By declaring a specific space of resources, APO saves room for users to perform other tasks.

Declaring parallel processors also speeds up background jobs. When SNP executes a command, such as heuristics or capacity leveling, the application searches for free processors and uses them on an as-needed basis. With parallel processing, SNP automatically realizes that it has multiple processors for the task and uses them all at once. This results in a significant run time improvement.

One more benefit of using parallel processing is containing the effect of errors against system performance. For example, if a heuristics job encounters a major bottleneck, then only the declared processors are affected, which allows you to use the system freely while the error happens. Without the declared processors, the system may try to use other resources in an attempt to expedite the job run. This slowdown affects everyone using APO regardless of the module. Use parallel processing profiles for large or comprehensive background jobs such as heuristics, deployment, CTM, or capacity leveling.

Tip 9. Build transportation lanes within APO. Transportation lanes are a core data object for a supply network. The lanes contain transportation attributes, such as mode of transportation, duration, lot sizes, rounding, and transportable products. A transportation lane is a one-way connector between two existing sites. Both upstream (demand aggregation) and downstream (deployment) activities require the lane to exist for targeting products and sites. The lanes are exclusive to APO, so the SNP team must build them within APO and populate the necessary fields, such as validity date and duration.

SAP offers a potential shortcut to creating products within transportation lanes. By populating the special procurement key in the ECC material master Material Requirements Planning (MRP) view, users can automatically trigger a transmission to APO to place a product on a transportation lane, using the specific attributes within the Special procurement key (Figure 4). Although this functionality may seem like an appealing time saver, you should carefully consider its use.

Figure 4

Special procurement field to trigger transmission to APO

Automating the maintenance of transportation lanes through the use of the special procurement key can make sense if you have a great number of lanes and maintenance of the lanes is required frequently. An example of the latter would be for businesses whose networks undergo seasonal variations.

However, a counter argument stems from the fact that it is a typical best practice to employ strict control of master data. Using the automated creation feature for the transportation lanes can disrupt this control over time. As an example, when a planner manually modifies a lane in APO (a typical planning activity), ECC overrides the changes with the next master data transmission. Furthermore, unwanted inclusion of products to a lane may have an impact on network plans. SNP is a rough-cut planning tool, so planners may avoid creating transportation lanes used in exceptional and on- demand occasions rather than in everyday or common planning. All the above examples are either avoided or minimized when you maintain the transportation lanes in APO rather than in ECC. The moral of this story is to evaluate this tip in light of your particular situation.

Should you decide to maintain your transportation lanes within APO, be aware that the special procurement key origin of transportation lanes is default functionality. You have two options to bypass the interference of the field in R/3. One option is to create business processes to ignore the population of the field for APO-relevant materials. The other option is to create a user exit that blocks the field’s CIF impact. The latter option is the safest, yet calls for more work and indiscriminately shuts down the relationship of the special procurement key to APO. Either of these approaches limits the maintenance and creation of transportation lanes to the SNP team.

Tip 10. Time streams are a hidden master data object. Failing to recognize the significance of APO time-stream maintenance can cause plan inaccuracies in SNP. The time stream in APO is the equivalent of a calendar (or factory calendar in ECC). SNP planners may only create time streams within APO. Their purpose is to determine available days for production, shipping, receiving, storing, or handling. You can attach time streams to locations and resources. If you do not attach a time stream, then the location or resource assumes an open calendar.

One advantage of time streams is the option to reference a factory calendar from ECC. The ECC factory calendars are calendars that display available workdays by marking non-workdays, such as weekends and holidays. CIF provides automatic transmissions of factory calendars for APO. Planners may create time streams from these factory calendars to eliminate data redundancy. Also, planners may further modify those calendars to either simulate or make adjustments based on projections. Whereas changing calendars in ECC is a configuration ordeal, time streams in APO are more like master data and are easily changeable.

By ignoring time streams, an SNP team may run into serious issues with functions such as heuristics, deployment, or TLB plans. For example, an absence of a receiving time stream on a receiving location that has a Monday through Thursday availability means SNP regards Friday, Saturday, and Sunday as available receiving days.

The SNP team should address time streams as a significant element of the SNP project. Coordinate the determination of these APO calendars with other teams (such as the MM, SD, and PP teams). Every receiving, shipping, production, and storage site should consider the appropriate time streams and processes to maintain the time streams. In other words, approach time streams as a required master data object.