Sunday, August 1, 2010

Valpak APO Implementation case study

Source: SAPInsider 2008 Volume 4 » Issue 2

Printing Billions: How SAP APO Helps Valpak Market North America

Valpak
Headquarters: Largo, Florida
Industry: Direct marketing
Parent company: Cox Enterprises
Employees: Approximately 1,500
Revenues: Privately held company
Operating highlights:
  • Valpak prints and distributes
    20 billion coupons in more than
    500 million envelopes
  • New facility gives Valpak the capability to produce 54 billion coupons each year
  • More than 60,000 advertisers use Valpak annually
SAP landscape:
  • SAP ECC 5.0
  • SAP BW
  • SAP APO

Every month, households across North America receive a distinctive blue envelope in the mail stuffed with offers for the local pizza restaurant, hair stylist, or insurance agent. Most of the recipients are blissfully unaware that their Valpak mailing is from one of the nation’s largest media companies, which prints and posts 45 million envelopes each month from a manufacturing center in Florida.

Valpak, owned by Cox Target Media, prints and distributes some 20 billion coupons in more than 500 million envelopes each year. During the second half of 2007, the company opened, in St. Petersburg, Florida, a $220 million, 470,000-square-foot, modern production facility with the capacity to more than double production to 54 billion coupons per year.

The new facility gave the company a rare opportunity: Valpak was now able to reinvent its decades-old product ion processes for printing and distribution and redefine its manufacturing and distribution process from end to end. So it did, but to manage the production and tracking of those billions of coupons, the company made what some might consider an unusual choice of a tool — SAP Advanced Planning and Optimization (SAP APO), the flexible, configurable forecasting and planning engine for supply chains.

“From the beginning, it was an ambitious project based on state-of-the-art technology combined with state-of-the-art vision,” says Brick Rossie, systems project manager. “This plant is a real marriage of mechanical technology, printing technology, collation technology, warehouse technology, and computers, and SAP sits right at the core of it. The driving engine is that SAP APO box.”

Made to Order

The new plant is designed to offer the responsiveness of a job shop, make-to-order (MTO) environment while achieving production economies of scale of a make-to-stock (MTS) model. To make this happen, SAP APO pulls from SAP R/3 (SAP ECC 5.0) the unique characteristics of up to 2,000 orders per week and bounces them against the available work center capacity. At the same time, SAP APO considers and optimizes a schedule against the constraints of a limited storage capacity for work in process (thou shalt not exceed) and a required delivery date (sacred), minimizing setup time between jobs (highly prized).

During a scheduling run, which typically happens once or twice a day, the optimizing engine “chews” on the data and attempts to improve the production schedule by moving jobs back and forth in time or to different work centers. For each iteration, the “value” of the schedule is calculated using the optimizing rules and parameters set up by the planners. The optimizing engine runs until either it reaches the time limit that the planner allows, which is typically around 15 minutes, or successive iterations fail substantially to improve the value of the schedule.

The St. Petersburg plant is an ultra-lean manufacturing platform and high-volume print/mail center, featuring the latest technology in plant automation. The printing presses employ “auto-transfer” technology through which they can change the four-color image on both sides of the 77-inch-wide running web press in minutes — and without stopping the presses. A typical print run for Valpak takes 12 to 20 minutes, and in that time, the large-format presses can complete the printing portion of more than two of the 2,000 jobs per week.

In the past, a single print run could run for as long as a few hours and yield only a small portion of dozens (or sometimes hundreds) of jobs. An intermediate warehouse that was full of partially printed envelopes was then needed in order to collect, sort, group, and queue the output of dozens of print runs for a final assembly up to four days after the first components were printed.

Now, Valpak will be able to increase production while reducing cycle times and labor costs dramatically. “Our former production process took four days to create a customer’s product — start to finish,” says David Fox, vice president of manufacturing for Valpak. “Our new manufacturing process will accomplish that in about four hours. From the time paper feeds into the printing press until the postal carrier delivers the blue envelope to consumers, almost no human hand will touch a coupon.”

While Valpak arranged for the new facility to have state-of-the-art technology for printing and collating, it still needed a solution for detailed planning — production planning and scheduling — that would interact with its systems, which falls directly into one of SAP APO’s main objectives. “Also, we were already an SAP R/3 customer and very familiar with the product,” Rossie notes.

No Single Solution

Valpak learned during its due diligence in designing the facility that there was not a single solution that met its needs, even among manufacturers of publishing equipment. It was faced with either creating an application from scratch or configuring SAP using creative workarounds for functionality that wasn’t available. Developing its own custom enterprise software solution would be time-consuming and expensive, as well as difficult to maintain over time.

The advantage of using SAP APO was its sophisticated planning engine that was best capable of handling the detailed scheduling required by the mix of MTO and MTS strategy, which is the nature of the Valpak product. Each custom coupon order is unique, hence the traditional way to handle the production for such an environment is to deploy an MTO process for both planning and production. Such a process, however, is not efficient. The company felt that if some of the planning and production process was modeled after a partly pre-assembled MTS environment, the overall process would be more economical and produce a higher throughput. Therefore, Valpak chose to implement a model where MTO and MTS models co-existed.

The MTO part of production is represented within the printing processes; every coupon printed is specific to a particular job on a specific date and to a specific zip code. The MTS stream comes in the form of coupons supplied by advertisers, which after receipt in Valpak warehouses, are picked to stock in standard box quantities and merged with the in-house print stream during final assembly at the collation machine. “In our old manufacturing process, we optimized around our printing, to make printing efficient,” says Rossie. “In our new process, we optimize around the collation and assembly of the final envelope.”

Early in the project, Valpak brought in SAP to gather requirements and put together a high-level workflow using SAP APO and SAP ERP. The results, according to Rossie, were promising. Subsequent to that exercise, “we went searching for a partner and that’s how we got hooked up with Bristlecone,” Rossie says. Supply chains using SAP are a specialty of Bristlecone, a consultancy based in Milpitas, CA. Valpak’s SAP APO implementation is exactly the sort of project that Bristlecone is known for: “Challenging, the type nobody else will do,” according to George Thomas, director of partners at Bristlecone. He laughs.

The 60/40 Split

“The key to all SAP APO projects is that the integrator needs to understand business requirements at a deep level,” Thomas explains. “You need to understand the functionality of [a] system, need to match that with the requirements, and then you need to come up with smart ways to put this together.” Thomas and the rest of the Bristlecone team spent considerable time at the Valpak facility and immediately began breaking down the requirements. Over a period of several months, Bristlecone developed a prototype that included many “creative” solutions, showing how Valpak could make SAP APO work in the most efficient manner.

Thomas estimates that SAP APO fulfills about 60 percent of the requirements desired by Valpak. During blueprinting, Bristlecone identified the functionality that fell outside SAP APO, developed workarounds or other options, and then presented them to Valpak for validation. “We gave them the pros and cons, so they would know the difference between choosing one option over another. If there was any further doubt, we would demonstrate it by prototyping. There may be issues, but the client understood those issues.”

New Manufacturing Process

Before the blue Valpak envelope shows up in a mailbox, “there’s a lot of science behind it,” says Thomas. “The offers are targeted to ‘Neighborhood Trade Areas’ (or NTAs, Valpak’s trademarked demographic system).” NTAs are Valpak’s proprietary groupings of 10,000 homes that enables advertisers — local, regional, and national — to target a single neighborhood, city, designated market area (DMA), or combination thereof.

While the technology behind the old production processes was not cutting edge, “it wasn’t a group of employees sitting at tables stuffing envelopes,” says Fox. The technology was older, but it wasn’t obsolete. It was, in fact, industry standard: 80 to 90 big long collators that stuffed and stacked envelopes. Those have been replaced by nine machines that not only collate, but wrap the blue envelopes around the stacks and print the addresses. “In the new building, now our people aren’t running machines. They are now monitoring from a control center,” Fox explains.

Managing Complex Sales Orders

“We decided to set up our sales orders using variant characteristics,” Rossie says. Valpak has a “super BOM” (bill of material) that has more than 100 potential components. “We had to configure the system to be able to build thousands of unique sales orders by choosing from the super BOM menu, then passing the order-by-order results through SAP’s Core Interface (CIF) to the SAP APO environment. The other twist that we had was our monster printing presses that can do six jobs simultaneously. The jobs come in different shapes and sizes, so we had to invent a custom program to be able to break up our sales orders into manageable pieces for the printing presses.”

The Bristlecone and Valpak teams determined how to merge the custom process with SAP APO, which then reports initial planning results. A second process groups the results into blocks that represent complete print runs and returns to SAP APO a second time to run through block planning, which is another SAP APO functionality. The result is optimized again and at the end, Valpak has a production schedule that works for the whole shop.

“We have a huge volume running through the plant, [so] we’re planning our productions two and sometimes three times each day,” notes Rossie. “When we get to full volume, we expect to do somewhere between 50,000 and 60,000 orders per year.” It will run 24 hours a day, six days a week

SAP APO then becomes critical because the printing process, once in full production, will have very limited buffers. “We must, at full capacity, move orders through the plant from start to finish in about four hours,” says Chris Cate, director of information systems at Cox Target Media. “If we don’t, we can’t run the plant at all. SAP APO is an instrumental part of that, to figure out how to line up all the pieces, and everything has to be ready to go.”

The Future of SAP APO

“We are collecting huge amounts of information and data from the machines on the floor, and we have reserved that for a future project to move into a ‘balanced scorecard’ type of reporting,” explains Cate. “In the next year or two, we can begin to track and analyze the data using BI.”

“There’s significant competitive advantage in our new process,” says Rossie. “From the pure product standpoint, once the plant is running at full capacity and all of our systems are finely tuned and operating the way they should be, we’ll have advantages as far as the types of products that we can offer and at a competitive price.”

The Sales Order Process

Valpak coupons are sold to advertisers by some 200 franchisees around North America. “After our franchisee places an order, the new system looks at aggregate demand, determining where commonalities across all orders exist,” says Rossie. For example, if a customer in Tuscaloosa and another customer on Cape Cod require compatible numbers and configurations of coupons in their envelopes, their jobs can be scheduled contiguously to save press set-up time and reduce production costs. Similar considerations apply to the collation processes. In addition, Bristlecone has enabled Valpak to create a supply plan that recognizes and works with capacity and material constraints.

“Our NTAs [Neighborhood Trade Areas] consist of 10,000 households, so an advertiser can come to us and choose the NTA or NTAs that make sense for him,” Cate says. “One added feature of the new facility is the advertiser can not only pick the groups of 10,000 he wants, but he can also send a different version of his offer to every area. If he picks 50,000 homes to mail to, that’s five groups of 10,000; he could send five different offers to those groups.”

Sales orders from franchisees are programmatically aggregated, and at the St. Petersburg facility, they come in as specs for the finished blue envelope, which contains anywhere from 20 to 100 different coupons. Each unique coupon is a component. The super BOM (bill of material) looks at all of the possible variations, including coupons and flyers that are printed externally.

Tips for a Successful SAP APO Launch

The secret to SAP APO is modeling. “[SAP] APO is all about modeling,” says Bristlecone’s Thomas. SAP APO’s flexibility and configurability allows a user to model hybrid planning environments extremely well. “Smart modeling is the key to solve issues,” adds Thomas.

Carefully manage expectations throughout the project. Bristlecone never tried to sell the Valpak team that SAP APO would match 100% of its requirements. For every requirement, however, Bristlecone carefully explained what was and what was not possible. During blueprinting, Bristlecone identified the functionality that fell outside SAP APO, developed workarounds or other options, and then presented them to Valpak for validation. “We gave them the pros and cons, so they would know the difference between choosing one option over another. If there was any further doubt, we would demonstrate it by prototyping. There may be issues, but the client understood those issues.” He adds, “Managing expectations — that’s the key to keep[ing] the client’s confidence.”

Plan, plan, then plan again. When tackling an SAP APO implementation, particularly when applying it on the scale that Valpak required, the approach must be very methodical and detail-oriented, “because it’s not a lightweight venture to put all of these pieces together,” says Rossie. “Make sure you hire very, very smart people.”

SAP APO and SAP liveCache's New Backup and Recoverability Features Bolster High-Performance Supply Chain Planning


by Jörg Hoffmeister, SAP AG, source: SAPInsider

Planning and decision-making for a company's supply chain - from determining when your supplier should send the next widget to creating a detailed, long-term production schedule - involves analyzing huge amounts of data from your own business processes and from the partners along your supply chain. In contrast to typical ERP data models, the demands on such planning systems require models designed to process vast amounts of data in near real time.

Thus companies often find themselves in a data-processing dilemma: for any heavy-duty planning solution to achieve acceptable performance under these circumstances, processing must be done where the data is. To get another performance boost, processing must be done on main memory. The first paradigm omits extra network roundtrips, the second one avoids unnecessary disk access. And then, of course, efficient backup and recovery of this critical data is key.

mySAP Supply Chain Management (mySAP SCM) offers a way out of this dilemma: SAP APO (SAP Advanced Planner and Optimizer) with SAP liveCache. SAP APO increases the speed of transactions for supply chain planning many times over. Now, with the newest version of SAP liveCache and SAP APO, SAP customers will continue to see high performance and availability, but they will also find simpler and more powerful tools for full point-of-failure recovery of planning data.

High Performance and Unique Point-of-Failure Recovery

SAP APO offers planning functionality for strategic, tactical, and operational planning of supply chains. Combined with SAP liveCache, it helps SAP customers respond to the data-processing challenges of supply chain planning.

Designed to improve the flow of information, SAP APO offers real-time and collaborative decision processes, advanced planning, and optimization as part of the SAP system to cover long- and short-term planning issues, such as supply network planning, demand planning, and production planning. (For more information, see the article "Supply Chain Planning with mySAP SCM" in this issue of SAP Insider.)

SAP APO pulls data out of your mySAP SCM solution and other applications and transforms and stores it to its own object- and network-based data model, with its own representation in its own database server. The system can either work off the SAP APO database server for more basic planning data, or off SAP liveCache for high-performance, high-memory planning issues. Application servers can also handle multiple connections to the different databases (see Figure 1), meaning that multiple processes and applications can connect simultaneously with different systems during the same session, and can work on data in either SAP liveCache or the SAP APO database server.

Figure 1Architecture of SAP APO Systems with SAP liveCache

SAP liveCache is based on a memory-centric offshoot of the SAP DB technology (www.sapdb.org)1 shipped with SAP APO since Release 2.0. For the most resource-intensive planning questions, SAP APO pushes performance-critical application logic to SAP liveCache. The data required for those processes is also pushed to SAP liveCache, where it is kept persistent. The persistence of both the data and the application logic is a real benefit, since it allows different processes to work on the same data and avoids bottlenecks by following the paradigm "run the logic where the data is."

SAP liveCache 7.4 Also Planned for SAP APO 3.0

SAP liveCache 7.4 is currently delivered with SAP APO 3.1, but a release is also planned for those customers using SAP APO 3.0.

With this scenario, the application logging that customers currently have in place in APO 3.0 will be switched off; logging will be performed by SAP liveCache 7.4 only. To migrate to 7.4, the current SAP liveCache data will be saved back into the SAP APO database. After SAP liveCache is upgraded, that data will be reloaded.

For more information on release and availability, SAP users can log on tohttp://service.sap.com/scmand go to mySAP SCM Technology -->Backup and Recovery.

SAP liveCache and SAP APO's New Approach to Backup and Recovery

With such critical business data, backup and recovery is always a concern. SAP liveCache's self-sufficiency in backup and point-of-failure recovery is one of the unique features that separates SAP APO from its competitors.

Until recently, SAP APO handled recovery through logging on the application level, together with switching log areas and SAP liveCache checkpointing. This required complex synchronization of processes during any restart of SAP APO and SAP liveCache, and involved special treatment to recognize the point where users could return to their work. Furthermore, there was potential for slow-downs at the SAP liveCache checkpoints during normal operation.

In the latest release of SAP liveCache (7.4) delivered with SAP APO 3.1, administrators now have a simpler solution: new, encapsulated logging and recovery capabilities for the persistent data in SAP liveCache. In fact, the applications no longer have to deal with logging and recovery procedures at all.

Although the SAP APO and SAP liveCache databases are independent, they are designed to ensure the consistency of data and transactions. Any open SAP APO transactions whose modifications have been rolled back during an SAP liveCache restart will receive a return code, and will be undone by the application and thus the SAP APO database.

Likewise, SAP APO cannot execute procedures on SAP liveCache data while SAP liveCache is unavailable, so this ensures consistency between the SAP APO core system and SAP liveCache when it comes to transactions. Unlike earlier implementations, users can now go on with their work as soon as SAP liveCache is up and running again, and recovery time is significantly decreased.

With backup and recovery moved away from the applications, administration functions for SAP liveCache are available right within SAP liveCache's own Database Manager tool. Figure 2 shows the backup process displayed in the Database Manager, which provides support for backup and user guidance during recovery, and maintains media definitions, protocols, and backup history.2 (Note that external backup tools are also an option, but be sure to check any third-party tool's documentation regarding compatibility with SAP liveCache's administration functions.)

Figure 2New Recovery Functions in the Database Manager

In Figure 2, the administrator sees SAP liveCache's default recovery route, recommended for optimal performance: a complete data backup is restored (DAT_00001), followed by an additional incremental backup (PAG_00002) for recovery, followed by a log backup (LOG_00008). During log recovery, SAP liveCache will switch from the log backup to its own log volume as soon as it reaches a log page in the backup that is also available in the log volume.

Now, administrators can customize the backup process in the Database Manager. For example, the administrator could choose an alternative recovery strategy, based on log backups only, by checking "LOG_00003." The tool would then mark all logs for recovery and omit the incremental backup.

SAP liveCache - The Technology

As the price of memory chips decreases while performance increases, the driving forces behind SAP liveCache - high availability and increased performance and persistence - have become even more accessible to SAP customers. With these hardware innovations and SAP liveCache technology, data can primarily be processed in main memory, and normally does not have to be moved between the disk and memory during transactional processing. As a result, supply chain management and planning applications can hit even higher performance targets.

For example, moving a typical set of data from SAP liveCache to the application server for processing (see figure, top right) would take at least 1 millisecond (A), compared with the microseconds it would take if processed inside SAP liveCache (B).

Processing of Data with the SAP liveCache Approach

SAP liveCache depends on the enhanced use of stored procedures for persistent stores of C++ class instances. It is designed to speed up processing by dynamically linking application code (in C++) directly to the database kernel code during runtime. As a result, the stored procedures are executed directly in the SAP liveCache address space without switching back and forth to the application server. The application data is completely available in main memory and will only be written to disk to achieve the requisites for recovery and thus persistency. This has no impact on performance because SAP liveCache is supplied with a highly efficient asynchronous I/O system.

Call to SAP liveCache from the Application Server

Consider a stored procedure call to SAP liveCache (see figure, bottom right). In this case, SAP APO is looking to schedule an order via SAP liveCache. The call is performed from the ABAP code layer of an SAP APO application. The procedure "schedule_order" is identified in the code by name; a stored C++ procedure with the same name has been registered to SAP liveCache during startup. An ABAP call will be bound to an SAP liveCache session. When the call occurs, that session runs as a task within a thread. Then, within SAP liveCache, the Object Management System (OMS) within SAP liveCache locates the "schedule_order" procedure code in the external C++ library. Then the OMS adapts the parameters of "schedule_order" to match its own object and network structures. This C++ procedure is executed directly inside the SAP liveCache kernel address space, using the OMS class interface of SAP liveCache. From there, the processing returns to the application server.

Conclusion

By providing a powerful interface to achieve persistence together with a stored procedure model, SAP liveCache solves the data-processing dilemma. For your most resource-intensive planning problems, the application can "run where the data is" - within SAP liveCache - with a minimized number of roundtrips and disk I/O, and a powerful backup and recovery concept to safeguard your supply chain planning data and keep your planning processes running smoothly.

SAP APO is unique in its use of this SAP liveCache technology, which means that users and administrators reap the benefits: high performance, high availability, and simplified, reliable backup and recovery.

SAP liveCache is currently available on Tru64, the 64-bit versions of Solaris, HP-UX, and AIX and Windows Server. SAP liveCache on Windows 2000 also supports AWE. A general release for .NET Server3 is planned for liveCache 7.4 in 2003.

For more information on SAP APO and SAP liveCache 7.4, registered SAP customers can visit the mySAP SCM Technology section at http://service.sap.com/scm. For more on SAP DB technology, on which liveCache is based, visit www.sapdb.org.


1 For more on SAP DB, see "SAP DB, SAP's Open Source RDBMS: Free, Scalable Database Management" in SAP Insider (October-December 2001).

2 The Database Manager is designed as a client/server application and provides a batch interface as well. The user interface is a Windows interface or, for non-Windows platforms, it is a browser-based interface with nearly the same functionality. All interfaces are clients that communicate with the Database Manager server, which runs as an independent program on the same server as the SAP liveCache kernel.

3 Synonymous with Windows IA64.

Wednesday, July 14, 2010

Setting the Planning Strategy

Setting the Planning Strategy Locate the document in its SAP Library structure

You can only use the following planning strategies with the CTP scenario:

· Strategies for Make-to-Order Production

· Planning with Final Assembly or Production by Lot Size (Make-to-Stock Production)

· Subassembly Planning in the CTP Process

Anonymous make-to-order production and planning scenarios such as planning without final assembly are not possible.

Check the following IMG activities:

Defining requirements classes

Starting from Customizing for Sales and Distribution, choose Basic Functions ® Availability Check and Transfer of Requirements ® Transfer of Requirements ® Define Requirements Classes.

If you do not work with one of the standard planning strategies, you have to create your own requirements class for the customer requirement.

Defining the requirements types

Starting from Customizing for Sales and Distribution, choose Basic Functions ® Availability Check and Transfer of Requirements ® Transfer of Requirements ® Define Requirements Types.

If you do not work with one of the standard planning strategies, you have to create your own requirements type for the customer requirement and assign this requirements type to a requirements class.

Determining the requirements type via the transaction

Starting from Customizing for Sales and Distribution, choose Basic Functions ® Availability Check and Transfer of Requirements ® Transfer of Requirements ®Determination of Requirement Types Using Transaction.

Item Category

MRP Type

Reqmts Type

O (Origin of Req.Type)

Reqmts Type Description

TAN

Blank or X0

e.g. 041

Blank (Strategy Material Master then Item Type and MRP Type)

e.g. Order/Delivery Reqmt

The field O Origin of Requirement Type in Requirement Type Determination determines the sequence the system is to use to determine the requirements type. If the setting is blank, the system first searches according to the planning strategy you set in the material master. This strategy contains the requirements type that is then also used. If you have not defined any strategy in the material master, the system then tries to find the requirements type using the item category and the MRP type.

Defining the planning strategy

Starting from Customizing for Production, choose Production Planning ® Demand Management ® Planned Independent Requirements ®Planning Strategy ® Define Strategy.

If you do not want to use the strategies described below, you first have to create your own strategy using the requirements types and requirements classes already defined. You also have to make sure that the sales orders are relevant to MRP. You do this by choosing the setting Requirement Planned in the No MRP field in the section of the screen entitled Requirements Type of Customer Requirements.

Strategy 20 or 25 exists for make-to-order production (available for configurable products). Strategy 40 Planning with Final Assembly or strategy 30Production by Lot Size exists for make-to-stock production.

Examples

Settings for strategy 20 (make-to-order production) / 25 (make-to-order production for configurable material)

Field

Value

Reqmts type of customer requirement

KE (indiv.cust.ord. w/o consumpt.) or

KEK (make-to-ord. configurable mat.)

Requirements class

040 (make-to-ord. w/o consumpt.) / 046 (make-to-ord. for config. mat.)

No MRP

Requirement is planned

Availability check

Indicator set

Requirement transfer

Indicator set

Settings for strategy 30 (production by lot size)

Field

Value

Requirements type of independent requirements

LSF

Requirements class (independent requirements)

100

Consumption

No consumption with customer requirements

Planning indicator

1 (Net requirements planning)

Reqmts type of customer requirement

KL (Sales ord. manufact.by lot size)

Requirements class (customer requirements)

041 (order/delivery requirement)

Allocation indicator

No consumption with customer requirements

No MRP

Requirement is planned

Availability check

Indicator set

Requirement transfer

Indicator set

Ind.reqmts reduction

Indicator set

Settings strategy 40 (planning with final assembly)

Field

Value

Requirements type of independent requirements

VSF

Requirements class (independent requirements)

101

Consumption

1 (Consume planning with assembly)

Planning indicator

1 (Net requirements planning)

Reqmts type of customer requirement

KSV (Sales order with consumption)

Requirements class (customer requirements)

050 (Warehouse consumpt.)

Allocation indicator

1 (Consume planning with assembly)

No MRP

Requirement is planned

Availability check

Indicator set

Requirement transfer

Indicator set

Checking strategy group

The strategy groups 20 and 25 for make-to-order production and 40 for planning with final assembly are provided as standard.

Entering the strategy group in the material master

Enter the strategy group in the MRP data in the material master record of the product to be planned.


source:http://help.sap.com/saphelp_scm41/helpdata/en/ff/b30cc768974095bc7d0e80e8a4540e/frameset.htm