Você está na página 1de 10

10 Tips for Implementing SAP APO

SNP
by Plan4Demand Solutions
October 15, 2007
SAPexperts/SCM
As you implement Advanced Planning and Optimization
Supply Network Planning, consider these 10 preparation
and setup tips to help you maximize your system
resources and eliminate potential data problems.
Key Concept
Supply Network Planning (SNP) in SAP Advanced
Planning and Optimization (APO) provides a link between
Demand Plannings (DPs) forecasting functionality and the
more detailed scheduling that takes place either in the
Production Planning component of SAP ERP Central
Component or in APOs Production Planning/Detailed
Scheduling module. SNP takes the forecast provided by DP
and nets it against existing inventory to generate
replenishment requirements for an organizations entire
supply infrastructure.
Although Demand Planning (DP) is the most frequently
implemented module of Advanced Planning and Optimization
(APO), Supply Network Planning (SNP) is almost as common.
SNP is a natural hand-off from DP because the forecast from
DP is the key input for SNP. The main benefit of SNP is the
projection of mid- to long-term large volume loads for facilities,
machines, labor, or raw materials based on the forecast. Here
are 10 tips gleaned from the experience of numerous
installations to consider when implementing APO SNP.
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.
Note
For tips about implementing APO DP, see David Healeys
article, 10 Tips for Implementing SAP APO DP, in the
SCM hub of SAPexperts.

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 dont 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).
Note
Non-VMI customers are irrelevant to SNP and should only
exist in ECC. The map should ignore these sites.

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, onhand 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 teams 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 subteam 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., onhand 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 doesnt 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 roughcut 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 fields 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 nonworkdays, 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.