How to Set up Regional S&OP Process Threads
Executive Summary
- Background on Planning Versions and Simulation
- Some Common Reasons for Using Different Versions
- Version Copy In APO
- Copying Back Changes to the Active Version from the Inactive Version
- Process Issues of the S&OP Thread
- Security Issues and Simulation Version
- Report Generation and Extraction from the S&OP Version
- Beyond the Standard APO Problem Decomposition
Introduction
When setting up regional S&OP process threads, it’s necessary to discuss the version copy. An S&OP planning run is typically performed in a simulation version – a non-live version in APO.
Background on Planning Versions and Simulation
Planning systems typically have a standard ability to make duplicates of a supply chain planning model and its transaction data. This means that the planning system can have multiple “versions.” These versions may often be only slight variations of one another. In a planning system, a slight variation input can make huge differences in the planning output. In technical terms, a version is a separate schema, which resides on the same database. Therefore, the schema is copied, and pointing is used to control the schema, but it is on the same server, the same database, and communicates with the same processor. One reason that maximizes the use of the resources (for instance, a simulation version can be processed when the live version is not being processed). It is also easiest to perform a version copy from the same database. This is shown in the graphic below.
More resources are required when one uses a duplicate version. It means more data, and the version copy itself takes processing resources and must be scheduled for light periods of system use.
Only the 000 version is integrated with SAP ERP; all other versions are kept in APO. Typically simulation versions begin with a version copy of the live version. Versions can be flexibly named any three-character combination. So a version could be named “SOP,” as you can see from the screenshot below:
Version Copy In APO
The version copy is the most important part of the process. The version copy allows the company to leverage all of the hard work in setting up the version to make a perfectly pristine copy of all of the configuration, master data – and, if desired, the transaction data. When the transaction data is included as well – the version can be referred to as a snapshot in time. It should be remembered that the inactive version cannot communicate with the ERP system, so whatever is brought over regarding the transaction is all the transaction data the version will ever have. As time passes, the version copy becomes less and less current. New version copies can be performed to bring the offline version up to date.
This is transaction /SAPAPO/VERCOP.
The copy is mostly from the active version or 000 to an inactive version such as 001, 002, etc. But there are two exceptions.
- It is possible, of course, to copy from an inactive version to another. This would be done if some changes had been made to an inactive version and the first inactive version needed to be kept as is, and more changes made to another version.
- Master, data can be copied from an inactive version to an active version. The reason for doing this is described in the following section.
In this screen’s scope area, one can decide to bring in just a portion of the overall model. This, of course, can reduce the size of the version copy. But it is also more work. A version copy essentially creates a new version. But it can also be deleted, which is done with the transaction /N/SAPAPO/MVM. That way old versions that are not being used can be deleted to reduce the size of the database.
Copying Back Changes to the Active Version of the Inactive Version
A nice feature of version management in APO is the ability to copy master data from the inactive version to the active version. This is a major time saving because it means that changes that were made to master data in inactive version. Say due to simulation, can be directly copied over to the active version. This is both an issue of reducing the effort required but is also provides a quality control benefit. Because it is not necessary to go through and check all the areas that were changed in the inactive version and ensure that the exact changes are also made in the active version.
Processing Issues of the S&OP Thread
Simulation runs such as the S&OP thread tend to be run on an ad hoc basis. This planning thread is infrequently run – particularly for the entire model. No batch jobs need to be scheduled for the S&OP run. Smaller ad hoc runs can be performed at any time, and because of their small size, tend to not significantly or adversely impact system performance. Therefore the main impact of the S&OP planning thread tends to be on disk space and as will be discussed, in several paragraphs, in the effort to write reports from the S&OP thread.
Security Issues and Simulation Version
S&OP versions tend to be region specific. Therefore in a global instance of APO, it can be desirable to restrict access to the simulation version only to those individuals with APO access that are within the region. The SAP role authorization model does allow for users to be assigned a role, which only allows them to go into specific versions.
Report Generation and Extraction from the S&OP Version
S&OP versions also need to have data extracted from them to be useful. There are in fact extremely few supply chain planning applications that can provide this functionality, and SAP APO is not one of them. SAP has tried over time to present several different S&OP solutions and has never been able to introduce a successful S&OP application. SAP has a new S&OP application under the “HANA” moniker. But I have yet actually to see it, it’s considered experimental and does not have a very high likelihood of being successful. See more at this link
