Global Schedule for Intercompany Transfer

Executive Summary

• The Planning Runs
• The Specifics the Active Version Planning Runs
• Intercompany Transfer
• The Logic for Different Scopes Between the Global and Regional Planning Runs
• The Global Schedule
• The Daily Regional Schedule
• Problems With Developing a Global Schedule
• Multiple Region Discovery

Introduction

What follows is both the explanation of design for implementing the planning runs of a three “pole” global implementation of SAP SNP using the SNP Optimizer. These planning runs are set up to enabled intercompany transfer. Intercompany transfer moves material between company codes in SAP and has two components. One is the scheduling of the physical movements of goods in the supply chain system, and the second is the accounting documents created from the transfer of goods between company codes within one multinational.

Secondly, there is a document also that explains some issues that face companies as they attempt to develop the logic and assumptions for the global batch schedule.

The Planning Runs and the Global Schedule

SNP uses a variety of planning runs to meet supply planning and initial production planning requirements. These are both planning runs in the active version (the version that integrates and shares information with SAP ERP) and for simulation versions, such as S&OP and rough-cut capacity planning. The simulation versions are not part of the global batch schedule as they can be run ad hoc and can be run offline. Therefore, this document will only focus on active planning runs.

The Specifics the Active Version Planning Runs

The planning runs for a global implementation at one company were set up like the following.

1. Weekly Global SNP Network Optimizer Run
2. Weekly Global SNP Deployment Optimizer Run
3. Daily Europe SNP Deployment Optimizer Run
4. Daily North America SNP Deployment Optimizer Run
5. Daily Asia SNP Deployment Optimizer Run

There are both global planning runs – which are triggered once per week on the weekend, and regional planning runs, which are activated once per day during the week. The global SNP optimizer runs to create STRs between regions. This is necessary for companies that perform intercompany transfer movements – or STR movements between the regions. Each region has a different company code, so intercompany transfers can be conducted with either billing STOs or a customized solution if the relationship between the interacting locations is “asynchronous.”

Intercompany Transfer

Intercompany transfers are quite common and typically result from the movement of finished goods or assemblies or components between the regions. A

This is the simplest form of intercompany transfer. But it also gets far more complex than this.

Some companies have moved to more specialization in their factories (co-locating specific manufacturing in global locations), intercompany transfers have become increasingly common.

The Logic for Different Scopes Between the Global and Regional Planning Runs

When processing all products for all locations in a single planning run, mainly when a time-consuming planning method is used (such as the optimizer or CTM), it can become time infeasible in that there is insufficient time during the nightly runs to perform the optimizer processing. Therefore…

1. Some companies can only plan the global or between regional STRs during the weekly global SNP planning runs. The sections below provide more details.
2. Companies may also decide that it is not a requirement to plan production weekly (in the network optimizer), but that deployment must be planned daily.

The Global Schedule for the Weekend

The weekend optimizer runs will naturally be scheduled when the final regional planners’ day ends (whichever region the physical hardware is located). These planning runs using both the network and deployment optimizers constitutes a “full run” because it includes the following:

1. Both (network and deployment) optimizers
2. All product location combinations in the supply network.

The planning runs generate the following:

1. Regional planned orders for production and rework as well. (Unlike STRs, planned orders do not move between locations, so planned orders are always within the region)
2. Regional and between region STRs and, of course, purchase requisitions.

The Daily Regional Schedule

The daily SNP Deployment Optimiser run for each region is based on the location master data selections for only locations within each region.

The following design elements apply:

• The region confirmed. STRs will naturally not be overwritten or re-planned by the regional daily SNP Deployment Optimizer planning run.
• The between region sources of supply locations can be excluded from location master data selection of the optimizer in the transaction. Execute the SNP Deployment Optimizer in the background (see the screenshot below). What this means is that the between region STRs are observed as confirmed STRs[1] while only the regional confirmed and unconfirmed STRs will be re-planned daily. But this leads to the complication that is described below.
• When out of region locations are excluded from the master data selection of the optimizers’ execution program (the execution of background variant), this creates STRs with a destination but without a source of supply. To rectify this situation, customization is necessary that essentially deletes all STRs after an optimization run that lack a source of supply.

• Therefore the plan between regions will not be re-planned daily but remains stable until the next global run. Any changes in demand will be reflected within the region only, but will not cascade between the regions until the next weekly global run.
• Any alerts arising out of between region misalignments may be resolved on a case-to-case basis through an escalation process.

Problems With Developing a Global Batch Schedule

A global batch schedule is dependent on many complex assumptions, which in actual practice, cannot be known until at least one region has been live for some time. And in fact, I have seen companies have been live in one region for years and still do not have a global batch schedule that is even close to accurate for all of the regions combined.

There are multiple and multidimensional assumptions that drive how long the SNP optimizer will take to process. And provide an output that will meet the business requirements. It’s difficult to say how the processing times can be known when many implementing companies would like to know them (Which is often during the initial hardware purchase)[2].

Multiple Region Discovery

What implementing companies will frequently find is that the second region to be implemented will learn that individual decisions and limitations had been built into the SNP optimizer settings, that would need to be changed for the second region. Furthermore, the third region will often find the same issue, in which the first and second regions have not set up the optimizer in a way that meets all of the third region’s requirements.

Therefore while the concept is that a “global blueprint” is performed that works out all of these issues in advance, and while it certainly sounds appealing, it is not, in fact, possible. The truth is that there is a constant discovery process as the company transitions through its regional implementations.

Several examples of unexpected issues that surfaced at one company, which significantly increased the length of duration of the optimizer run and changed the assumptions of the global batch schedule are the following:

• Discrete Optimization Horizon: The first implemented region configured individual discrete optimization constraint horizons, which would need to be lengthened to meet the second region’s requirements. (This is covered in more detail at this link)
• Full Optimizer Log Trace File: The first region had elected not to write out a full optimizer log trace file, which was also done to save processing time. This substantially impacted the company’s ability to diagnose the optimization runs. This is covered in this link.

Conclusion

This document described a way to set up the SNP optimizer in two different ways that allow the application to meet both the business requirements of the business and the processing time requirements of the global batch schedule.

The second portion of this document described the fact that on actual projects, it is tough to know all of the factors that drive the global batch schedule. And that as APO is rolled out to subsequent regions, that a perpetual discovery tends to occur, which requires changes to the settings of the optimizer runs, and significantly impacts the optimizer run times, which in turn affect the timing and overall logic of the global batch scheduled itself.

[1] This applies to the deployment planning horizon, but not outside this deployment planning horizon – which is set on the in the global deployment optimizer planning run.

[2] Therefore, there is a question of how realistic it is to be able to make hardware purchases for the global instance at the beginning of the project.

References