Grouping, Pegging, and Distribution (GPD) Richard Minney, Xansa Rebekah Brooks, Goodrich Aerostructures Xansa was Goodrich’s consulting partner and.

Grouping, Pegging, and Distribution (GPD) Richard Minney, Xansa Rebekah Brooks, Goodrich Aerostructures Xansa was Goodrich’s consulting partner and still provides on-going support e.g. SAP A&D expertise.

GPD Discussion Topics Introduction Basic Concepts Goodrich and GPD
Why Where Basic Concepts Goodrich and GPD Limitations/work-arounds Extended Features Agenda – Richard to cover Introduction, Rebekah will pick up on Concepts and Functions, and Goodrich use of GPD, and Richard will cover extended functions, Rebekah will then give the last bit.

Why GPD ? Defense contractors and other project based manufacturers recognize actual cost to the contract from initiation Long term contract accounting Progress or cost-reimbursable billing Earned value Supply chain efficiencies require co-mingled or consolidated replenishments satisfying multiple contracts Economic make/buy lot sizes Netting and inventory re-use across projects Flexibility without heavy transaction load Explain why A&D companies need to recognize cost to the contract (or project, these are interchangeable terms). Explain why pure make-to-order manufacturing is no longer efficient to compete. “Initiation” means goods receipt/payment for buy parts and labor collection/kitting from company stores for make parts.

So What ? Project stock provides financial control, but leads to inflexible supply chains Sharing/transfer of stock or WIP between projects is manual These transfers can ignore lower-level assembly costs Individual lots are planned and owned per WBS requirement Plant stock provides supply flexibility, but lacks contract specific financial control Cost recognition delayed until consumption to project-specific activity Cost element visibility lacking Actual costing is plant-wide moving average Explain how project stock works, valuated vs. non-valuated. Assume valuated and talk through a goods receipt for purchased part and then stock and issue to WIP and book labor at the next higher level. Good, but no way to transfer, and when you do a manual goods movement, the purchase order $ don’t transfer. Explain how plant stock works, all one planning segment, but cost for inventory is on the balance sheet (company owned material) until consumption not just to WIP, but to WIP which is make-to-order. GPD was developed to overcome this limitation

GPD allows . . . Co-mingling, or grouping, of inventory, purchases and production between multiple contracts (WBS) Logistical barriers can be applied for situations where contracts cannot share stock/WIP for the same part number MRP, stores, purchasing all net across allowed contracts Supply chain replenishments are dynamically allocated / pegged to originating contract requirement Actual supply chain costs are recognized at individual project WBS from initiation Actual quantity part flow in WIP to stores is recorded in the background WIP or stockroom contract transfers are automatic and include actual costs all the way down the bill of material structure Logistical barriers would apply, for example, where commercial and military contracts specify different process, finishing and inspection levels for the same part number and therefore wish to main separate and disconnected supply chains. Best practice = one group at each part. Cost initiation can be receipt for purchase parts, or labor collection for make parts or allocation of overheads (via costing sheet?). Pegging is normally a batch process, so technically the recognition of costs to the individual WBS is not real-time with GPD. Explain that GPD means either 46c2 or IS-DIMP 471, which is in ramp up mode starting July through December 2003

Where should you use GPD
Actual / WBS Individual project stock is used for activities within the network Development and Test Pure make to order manufacturing Sales order Network Co-mingled Use GPD for the “middle layer” GPD can be used down entire BOM GPD is good up to end item level for PP based MTO production Production orders Talk through an example etc. etc. Plant stock is retained for company owned stock, hardware and low-value material Minimal cash impact Actual cost unimportant Purchase orders Production orders

How Does Goodrich Use GPD ? Limitations and work-arounds
GPD at a Glance Basic Concepts of GPD Grouping Pegging Distribution How Does Goodrich Use GPD ? Limitations and work-arounds The next few slides will describe and demonstrate the basic concepts of GPD. I will talk about what the letters stand for and how they relate to each other. I will briefly explain how each section works and give an overview and example of the functionality. During this portion of the presentation, I will talk briefly about the differences between version 4.6c2 and the new 4.71 version, specifically as it relates to cross-plant pegging. I will show you how MRP and GPD work together in a final example that demonstrates all of the concepts in this section. Finally, I will describe why Goodrich uses GPD and what we have accomplished.

Basic Concepts of GPD Grouping Pegging Distribution
Grouping WBS element contains a collection of individual WBS elements from various projects Requirements from these WBS elements are planned together in MRP at the Grouping WBS element Pegging Distribution I will start with the “G” part of GPD, which stands for Grouping. Grouping – refers to combining different individual WBS elements under a single WBS for MRP planning and inventory mgmnt purposes. This allows orders to be lot sized to cover multiple requirements, even though they are for different WBS elements. MRP maintains requirements and replenishments within the Group WBS planning segment, so that each different WBS does not have to be planned in it’s own segment (like MTO does). Receipts of inventory are also managed under the Group WBS. MRP searches for the group WBS for all requirements with a WBS and converts them to the Group, and then plans replenishments to match. This means that all requirements within the same group WBS are available to be planned together, using the given lot size.

WBS Assignment to Group
Grouping Overview Each individual WBS element represents a cost bucket for a customer requirement Replenishments are assigned to the Group WBS Stock is managed under the Group WBS The transfer of replenishments between WBS elements within a Group WBS is automatic The transfer of stock between Grouping WBS elements is manual Grouping supports non-valuated & valuated project stock costing For greatest flexibility, assign MRP Groups to the Group WBS WBS Assignment to Group MRP Group Assignment to Group There are 2 main tables that are used for Grouping. The first table shows the relationship of the individual WBS to the Group WBS. Each WBS represents a cost bucket for a customer requirement and is assigned to a single Group WBS. MRP then plans replenishments with the matching Group WBS assignment and stock stays under the group. The pegging process handles the transfer of replenishments between individual WBS elements dynamically, however, the transfer of stock/replenishments between different Groups is manual. Grouping supports both non-valuated (actual) and valuated (standard) project stock costing. At Goodrich we use the non-valuated model, so the focus of this presentation will be on that model. The second table assigns the plant and MRP group combination to the Group WBS. This assignment allows the highest level of flexibility in determining what will be grouped. There is configuration behind the MRP group which indicates that it will be used for grouping.

Grouping Approaches Single Group Multiple Groups Group WBS 1 Proj 001
All materials assigned to a single Group, regardless of plant or level No Group to Group transfers required Group WBS 2 Proj 002 WBS 001 WBS 002 Multiple Groups Materials assigned to multiple Groups Group to Group transfers required to use inventory from another group Improved run time through concurrent processing Materials can assigned to a nested Group There are a few different approaches in setting up Groups. The simplest approach is to set up 1 Group WBS and then assign every WBS from every project to that Group. This is the approach that Goodrich uses. This simplifies inventory management and MRP planning, because there is only 1 Group. But it also can get very large and difficult to run reports against, so analysis becomes more difficult because every part is using the same Group WBS. Another approach is to set up multiple groups and assign certain projects to certain Groups. So, you have Group 1 that pulls together Project 1 WBSs, and Group 2 that pulls together Project 2 WBSs. This works well if the parts in each group are exclusive. Keep in mind that manual Group to Group Transfers are required if the same part is in multiple groups and you want to use inventory from 1 group to cover requirements in another group. Also, MRP will plan separate replenishments for each Group, so lot sizing is limited to within the same group. Another option is to use nested Groups. This approach assigns multiple Group WBSs to another Group WBS, as in the Group WBS 3. This option allows you to plan each part in a single Group, even though that part actually goes into requirements from multiple groups. Using multiple groups can improve run time because you can process each group independently – assuming no group to group transfers have been done. In the 4.71 version, you can do group to group transfers and still run them independently.

Nested Grouping Group WBS 1 Proj 001 WBS 001 WBS 002 Group WBS 2 Proj 002 WBS 001 WBS 002 Grouping strategy varies by part down the bill of material Narrower Groups (fewer assigned project WBS) for high-level assemblies Group WBS 3 WBS 1 WBS 2 Broader Groups for lower level fabrications and buy parts MRP Group on material master dictates Group WBS assignment Nested Groups are used in situations where parts at the higher levels are unique to a program and parts at the lower levels are shared across programs or contracts. For example, electronic circuit boards might be unique, but the sub-components shared. If the parts at the higher levels are unique, the grouping strategy doesn’t actually make any difference, however as stated previously there is a performance benefit in having more groups so this is a possible way to do this. Another situation might be where contracts want physical segregation of parts in, say, the assembly shop, but do not expect these parts to be segregated (rather they should be co-mingled) in the component supply shop. We would also recommend setting up Grouping by MRP group (grouping strategy “2”) to ensure flexibility, even if you don’t want nested groups to start you might change your mind later !! It is much easier to introduce nesting with strategy 2 than to change the strategy.

Grouping WBS element contains a collection of individual WBS elements from different projects Requirements from these WBS elements are planned together in MRP within the Grouping WBS element Pegging Replenishment elements are planned under the Group and proportionately assigned to initiating requirements (pegged to individual WBS elements) Distribution That concludes the overview and basic concepts of Grouping. Now we’ll move on to Pegging – which is the P in GPD. While the concept is simple, the application and implementation is quite complex, because there are many variables to work with – such as rework orders, scrap, loss, surplus, and cross plant movements. Pegging simply tries to match up all stock and replenishments that are assigned to the Group WBS to past and present requirements in date sequence. Stock gets pegged first, then orders (released and planned). The assumption is that initial requirements will always carry an individual WBS which can be used in pegging no matter how far down the structure the requirement is carried by MRP. The second assumption is that replenishments will always carry the Group WBS and even when they are received into stock, the original replenishment is maintained and stock stays under the group.

Basic Pegging Overview
MRP Results (pre-read) Actual Stock/Issue Quantity Historical Pegging Pegging (1 plant) The pegging algorithm ensures - Every GPD replenishment order is fully pegged to the originating requirement’s WBS so that all costs are distributed Projects which get no pegged quantities get no costs Pegging takes a “snapshot” of all requirements and replenishments and matches the two in date sequence Pegging Result Inherit pegged WBS from parent to child Pegging normally runs after MRP so that it can take a snapshot of all of the requirements and replenishments still being planned by MRP. It then brings in all of the data that has been saved in the pegging tables. The first table is the GPD stock table. This table contains all of the original GPD replenishments that have been received but not issued. Once a GPD part is issued, it moves out of the stock table and carries the same original replenishment to the GPD issues table. This data is no longer in MRP, so the GPD issues table records the individual WBS the part was issued to (if it was issued out of the group) or the next assy order if it is issued within the group (i.e. the next assy is also grouped). Pegging can be configured to follow every change in MRP, or it can stay with historical pegging until it’s issued and then it will update as needed. As part of the pegging process, the pegging from the previous run is brought in and used as needed for historical pegging and rework order pegging results. Since pegging starts at the top of the structure, the highest level parts should have requirements that are dependent on a production order or network with an individual WBS or from a S/O with a WBS. Once that part is pegged, the components at the next level down reads the pegging from it’s parent order and so on down the structure. In theory, every GPD replenishment is fully pegged to the requirements it is planned to cover. If there are no pegging qty’s for a project, then it also gets no costs. Pegging normally changes with MRP but can be “fixed” to adopt history where possible

Pegging Quantity Flow Goods Movements update pegging tables for receipts and issues Goods Receipt (Stock Table): M pc receipt (from supplier) Material Plant Batch WBS Replenishment Unrestricted Quality Blocked Object Use Inspection Stock M GRP-1 PO CONV 10 7 PO CONV PP PC Replenishment Receiving Object Quantity Unit Object M GRP-1 PO CONV This is a simple example of how data flows thru the pegging tables. When a part is received to stock, it is initially stored in the stock table with the original replenishment order number, qty, plant, etc. Prior to receipt, the replenishment is in the pegging results table, based on data found in the basic order tables. In this example, we see a PO for 12 pcs being received into plant 2000. When some of this stock is issued to another order (in this case PP 5670) the qty in the stock table is reduced and the issues table records the original PO from the stock table and the receiving object and qty. In cross-plant situations in-transit stock remains in the stock table, but a new record with the new plant is created at receipt. In this example, 3 pcs are moved from plant 2000 and received into plant 2050. The original replenishment is maintained and the total receipt qty can be accounted for between the 2 tables. These goods movements are recorded for all GPD parts all the way up the BOM, until it is issued outside of the group. Pegging follows the goods issues relationships found in the pegging issues table. Goods Issue (Table): M pc to PP-Order 5670 Pegging for issued parts follows the Actual Quantity flow in issues table

Cross Plant Pegging Overview
MRP Results (pre-read) Actual Quantity Flow Historical Pegging Pegging Plant 1 Plant 2 Substitute inter-plant receipts for real replenishment from supply plant Pegging Result Delete interplant stock transport orders from pegging result Track pegging in-transit between plants Supply plant replenishment is pegged to next higher assembly requirement in receiving plant Ensures original replenishment object (PP orders/purchase orders) is pegged to the original requirement, regardless of plant Ensures actual costs are distributed regardless of plant The custom developed cross plant pegging logic works the same as I have described for single plant pegging, but adds another dimension to the pegging algorithm for 2 different scenarios involving multiple plants. The read of MRP and pegging tables is the same, except that it accounts for stock in-transit between plants and ignores issues to stock transport orders (also found in the issues table). In the pegging process, stock transport orders from MRP are substituted out as pegging attempts to match up requirements in 1 plant to replenishments in another plant, using the STO as a guide between the 2 plants. Stock and orders in the receiving plant are pegged first against actual requirements in the matching plant. Then stock and orders in the sending plant are pegged against the requirements in the receiving plant. Stock transport orders are not pegged as they do not contain actual costs – only the original replenishments which generated the stock are pegged. Production orders with 2 plants (different planning and production plants) are also pegged in multiple plants. While the order is in work, the order is pegged in the production plant. When it is stored, it immediately switches to the planning plant – which is where it must be stored. Exception pegging for scrap is pegged according the plant where it took place. The custom logic ensures that the original replenishment object (order) is pegged to the original requirement (which carries the individual WBS), regardless of which plant the stock/order originated in.

Stock Transfer between Plants Production in Alternate Plant
Cross Plant Pegging Example Stock Transfer between Plants M5 Production in Alternate Plant Here are 2 examples of the pegging results for stock transport orders between plants and production in alternate plants. The first example uses STOs to transfer stock between plans. The original replenishment in this case is a PO for 12 pcs. As you can see by the different plants in the pegging records, the stock is being used in 3 different plants. In each case, a STO was used to transfer the stock to another plant and was therefore pegged to different requirements than it would have done if it had stayed in the original plant (2000). The original qty of 12 is maintained in pegging because the original replenishment order is maintained as it moves across plants. You can see the PO in three different places, but the total of all the records still = 12. In the Goodrich example, S WBSs are for Spares and P WBSs are for Production. In this case, it demonstrates the ability of pegging to associate only the qty needed for production to a P WBS (2 pcs) and the balance to different Spares WBSs (10 pcs), while allowing a single goods receipt of 12 pcs. In the bottom example, production orders are being built in plant 2000 (In procurement status) and then received directly into plant 2020 – showing as stock. They are then issued to another GPD order after reaching plant 2020 (withdrawn in Group). This scenario is simpler in design because parts are never “in-transit” and are never “issued” to an intervening order. The orders simply reside in 1 plant or another, depending on their status. M6

Cross Plant Enhancement
IS-DI version 4.6c2 supports single plant pegging only Cross plant pegging is available via a multi-customer developed enhancement SAP AG and SAP Labs provided technical oversight and assistance for the enhancement SAP endorsed the concept of cross plant pegging following the successful development and customer testing of the custom enhancement SAP Labs supports c46c2 with cross-plant pegging on an internal SAP machine Customer must provide own support or pay partner for support in short term IS-DI Version 4.71 is enhanced to recognize the logistical relationships between plants in pegging SAP Version 4.6c2 supports single plant pegging only Cross plant pegging is available via a multi-customer developed enhancement only. SAP AG and SAP Labs provided technical oversight and assistance for the enhancement SAP endorsed the concept of cross plant pegging following the successful development and customer testing of the custom enhancement SAP Labs supports c46c2 with cross-plant pegging on an internal SAP machine Customer must provide own support or pay partner for support in short term SAP Version 4.71 was enhanced to recognize the logistical relationships between plants in pegging

X-Plant Pegging Comparison
IS-DI version 4.6c2 Custom Cross-Plant Pegging In-transit stock information stored in Stock table at goods issue Reversals are limited Pegging is in sending plant until receipt and status is “Stock” Custom modifications of supporting transactions to function for multi-plants Batch changes are limited IS-DI version 4.71 Standard Cross-Plant Pegging In-transit information is stored in an in-transit table In transit stock has pegging status “In Transit” Reversals are fully supported Single step cross plant inventory movement supported View pegging exceptions Batch changes are fully supported Version 4.6c2 / Custom Cross-Plant Pegging In-transit Stock information stored in Stock table at goods issue Reversals are limited Pegging is in sending plant for in-transit stock until receipt. Status is always “Stock” Some custom modifications to support transactions are needed in order to function properly for multi-plants Batch changes are limited Version 4.71 with Cross-Plant Pegging – here are some of the highlights in the new version In-transit information is stored in an in-transit table In transit stock has pegging status “In Transit” Reversals are fully supported Single step cross plant inventory movements are supported (301Q) Can view Pegging exceptions easily Batch changes are fully supported

Grouping WBS element contains a collection of individual WBS elements from different projects Requirements from these WBS elements are planned together in MRP within the Grouping WBS element Pegging Replenishment elements are planned under the Group and proportionately assigned to initiating requirements (pegged to individual WBS elements) Distribution Cost distribution from replenishment elements based on pegged proportions The final concept is the D part – which is distribution. This the main reason for all of the Grouping and pegging I’ve shown you so far. Distribution does 2 basic things. It reads the WBSs found in pegging for each order and then moves costs from production orders, element by element to the WBSs found in pegging. The total order cost is proportionately split across all of the WBSs found in pegging. Distribution will also move costs off the Group, to the WBSs in pegging. This is the process for GPD purchase orders, because costs are actually transferred to the group at receipt and it is only at distribution that they are moved to an individual WBS.

Distribution Overview
Distribution supports both non-valuated and valuated project stock Both scenarios post to the same receiving object In the case of valuated project stock, the average costs are posted to the Group at goods issue; actual costs are not maintained In the case of non-valuated project stock, actual costs remain with the Group after goods issue Distribution must be modified to support cross plant pegging PO: CONV050878 M EA $ Purchase Order Non-valuated Flow Grouping Project Line Items Table COEP PO/Item Objects Values Elements CONV GRP G CONV GRP G CONV GRP G CONV WBS P CONV WBS S WBS-G-01 Debits Material M Credits Material M Prod Project WBS-P1… Debits Material M Credits Spares Project WBS-S7…. (Multi WBSs) Debits Material M Distribution handles different types of values, including costs, commitments, payments, etc. Here’s an example of how distribution for non-valuated project stock works for actual costs. We begin with a purchase order for 12 pcs. When this PO is received, the Group is debited for the PO value and a A/P is created. The cost table shows the total value against the group and the cost element it was assigned to. When distribution runs, it credits the Group and then puts the debit against the WBSs that it found in pegging. The total cost of the PO is evenly distributed across 1 or more WBSs. In this example the P Project gets the cost for 2 pcs and the Spares Project gets the cost for 10 pcs, but spread across different WBSs within that project. Distribution actually supports both non-valuated and valuated project stock and both scenarios post to the same receiving object. For valuated stock movements, the average costs are posted to the Group at goods issue and actual costs are not maintained. In the case of non-valuated project stock, actual costs remain with the Group after goods issues. Some modifications are required in distribution in order to support cross-plant scenarios. Distribution handles different types of values: actual costs, commitments, payments . . .

Distribution Example Distribution takes the actual costs associated with GPD replenishments and moves them from the group WBS to the individual WBS from the pegging table M5 In this example, pegging is shown in the bottom section. The PO is for 12 pcs and has been fully pegged across production and Spares WBSs. Pegging is only concerned with the relationships of orders, qty’s and WBSs. After distribution, the same PO can be found, showing the cost side. You see the full cost of the order and then how it was distributed from the Group to the individual WBSs. There were 5 different WBSs in 3 different plants for this order and each WBS is found both in pegging and distribution. In the case of production, there was only 2 pcs, and the cost for 2 pcs (2/12) or $ and the balance went proportionally to the other Spares WBSs. This concludes the basic concepts of GPD.

How Does Goodrich Use GPD?
GPD at a Glance Basic Concepts of GPD Grouping Pegging Distribution How Does Goodrich Use GPD? So – why do we use GPD?

How does Goodrich Use GPD?
Work Breakdown Structure PP Orders Material cost based on actual production & purchase order cost The main reason to use GPD is to be able to report actual costs for materials purchased or produced in support of a single WBS. It relies on MRP to explode requirements throughout the BOM structure and plan orders and reservations to the lowest level material . Actual costs are posted to PP orders at the lowest level, including labor and any plant stock used. As these costs are accumulated, they are transferred to the individual WBS directly. As the higher level reservations are satisfied by project stock, the actual cost of that stock is maintained in the pegging/distribution records on a FIFO basis. GPD stock itself carries no value to it’s next assy order, because it is distributed from the order to the WBS. Once issued, it is pegged to the same WBS as the next assy order and is dynamically maintained if MRP changes. There are no accounting documents for goods receipts of production orders or issues because it is handled through pegging. GPD supports detail reporting of actual costs broken down by the main three elements of labor, material and overhead. In the Goodrich example, overhead is actually applied to the project and not to each individual order, so distribution actually only handles labor and materials from GPD orders. Once distributed, project systems reports show the actual costs rolling all the way up through the WBS structure. Actual costs posted to PP order and reported at WBS element through account assignment Distribution of costs from PP order to WBS element

Flexible BOM Structure
Deliverable end item WBS assigned PP Orders Individually planned Actual Cost GPD planned sub-assemblies and bond panels Group planned A flexible BOM structure is possible to use along with GPD functionality. This is an example of how Goodrich implemented GPD in regards to it’s BOM structure. The lowest level parts that are either purchased or made from raw materials use standard cost methodology. These low level parts feed into the next higher sub-assy, which is GPD. At this point, actual costing begins. Using GPD at this interim stage allows a compromise between the need to see actual costs, but still have lot size flexibility. While many of these sub-assys are for qty of 1, they are dynamically assigned to the major assys they support through pegging and require no additional admin. Finally, the top of the BOM structure consists of make to order parts, where costs are collected on orders for individual WBSs. No distribution is needed because of the WBS assignment, but these orders also require a higher level of administration. At this point, the parts are serial controlled and we maintain a 1 for 1 relationship to the original requirement. Changes to the WBS after the order is released must be closely coordinated and are tightly controlled. When GPD parts are issued to these orders, they are considered issued out of the group and pegging remains static. Throughout this process, the trail of actual costs and the orders they originated from is maintained for GPD parts. Each order that goes to stock and where that specific order was issued to is maintained in pegging and shows an audit trail both logistically and financially. Standard cost does not easily support this level of detail, nor does it break down the different costing elements that we report on. While MTO functionality tracks actual costs and keeps an audit trail by WBS, it also requires more resources to support it, so keeping a small number of parts with this designation is desirable. Production order components Standard/ Average Cost Make/Buy to stock piece parts Collectively planned Purchased parts

Limitations Cross-company transactions Subcontract purchasing
Sales returns Consignment inventory Re-order point / safety stock Make-to-order WBS transfers Cross-company transactions: O MRP is supported for cross company planning via stock transport order, though it is priced and two step movement, and the intercompany stock is not tracked when in-transit. O Pegging does not really work that well. If the intercompany order is $0 (unpriced) then the pegging is OK as it follows up the “tree” of the intercompany purchase order to the higher level requirement. There is a need in this situation to potentially change the WBS assignment to one in the correct company code (use the BADI) otherwise distribution fails O Pegging for priced intercompany transports is not designed into the solution. We have developed a work-around at Goodrich to “distribute” the intercompany purchase order price based on some basic assumptions, and additionally to change the assigned WBS for lower level production in the supplying plant to a “cost of sales” WBS once priced intercompany shipments have taken place Sub-contract: O Not sure if the A&D functionality fully works even outside GPD ! O The pegging logic is missing for subcontractor – SAP are working on a solution for us Sales Returns: O Reorder point: O Really an issue with project stock not with GPD O Reorder point and safety stock are plant level fields and not recognized in individual (project, sales order or group WBS) planning O Xansa has built a solution several times for previous customers to create Group WBS assigned planned independent requirements to represent the re-order point, based on the material master data values MTO WBS Transfers:

GPD Summary S/O S/O MRP Proj 001 WBS 001 Proj 002 WBS 001 Group WBS 1
Delivery & Shipment Proj 002 WBS 001 Group WBS 1 Group WBS 2 MRP Requirement Requirement Cost for 1 pc Cost for 2 pcs Replenishment +1 Replenishment +2 Here’s a simplified example of how everything works together and shows the entire process. Grouping strategy is determined and the WBSs are created. Assign the appropriate WBSs to the Groups. In this case, I’ve assigned Project 1 to Group 1 and Project 2 to Group 2 Sales orders are then created which use the WBSs that were created. This can be any high level requirement that carries an individual WBS. The requirements for S/Os are automatically put through the grouping logic and put under the appropriate Group for planning. MRP then runs and creates replenishments under the same group as the requirement. At the next level, MRP again sees a requirement, checks the grouping logic, and finds Group 3 to put all the requirements under. Note that the requirements for project 1 and 2 are both now under group 3 at the lower level. MRP continues to run and creates replenishments under Group 3 to match the requirements. Pegging runs and sees the requirements and replenishments at level 1 and pegs the replenishments back to the separate WBSs. Pegging runs on the lower level part, reads the parent assignments, and copies it to the order. Then we have some order processing activities, which eventually leads to inventory management activities (receipts/issues). At various times in this process distribution runs, and each time that it does, it sees the pegs for each order and takes whatever costs have accumulated on the orders and moves them to the WBSs. Eventually we deliver the highest level part and pegging remains fixed from this point and in theory there will be no more costs to distribute. We end up with the cost for 1 multi-level unit on project 1 and the cost for 2 on project 2 and built all 3 pcs of the lower level part on a single order. Group WBS 3 Work Execution Inventory Mgmt Requirement Requirement Pegging for 1 pc Pegging for 2 pcs Replenishment +3

Cycle-count Differences Group to Group transfers Archiving
Extended Features Valuated Stock WBS Breakpoints Surplus / Scrap Cycle-count Differences Group to Group transfers Archiving Serial effectivity This is really a collective of concepts, not in any particular order, not covered under the GPD Basic Concepts section. Some of these are not fully supported in the current release, even though solutions have been identified and custom developed for all of these items.

Valuated or non-Valuated ?
Valuated Project Stock Cost follows part in real-time Pegging & distribution at single level only Not an actual cost solution Unproven Non-valuated Project Stock Actual cost distributed to project from initiation Distribution runs in batch Multi-level pegging & transfers supported Proven/robust solution Recommendations Use non-valuated for actual cost pegging Consider plant stock in place of valuated/enterprise wide grouping

WBS Breakpoints Requirement Solution
Production costs need to be recognized with greater granularity than at contract/network level Costs to distribute to WBS elements lower down end item structure Solution GPD provides a break-point table to influence pegging GPD provides a break-point call out (BADI) Custom Solution Auto-generate WBS break-points Fill in table Based on user field Explain reasons for wanting to peg and distribute to lower level WBS, e.g. more cost granularity required, separate WBS structure for certain BOM assemblies, different organization different WBS tree etc. Note that the costs can be redirected to another WBS or a network activity via this mechanism. Note that the breakpoints are maintained in a separate table, keyed off (optionally), higher level WBS, material, parent material, project, plant. The breakpoint table maintenance can become complex, particularly for higher volume such as found in spares business, so you need to take that into account.

Surplus and Scrap Requirement Solution
Record scrap in storeroom and production Peg scrap to original cause Peg surplus to canceling contract or share across all contributors Solution Option to peg surplus and scrap to default WBS Option to peg to based on contract allocation for remaining on order Pegging call out provided (BADI) Custom Solution Peg to scrap or surplus WBS per project (based on usage) Copy confirmed scrap fr. operation to order header

Cycle-count Differences
Requirement Recognize gains and losses against appropriate WBS Capture actual costs where possible for stock gains Solution Pegging allocates actual replenishments to losses (FIFO) Gains following a loss “re-instate” previously lost replenishments Pegging call out provided (BADI) Custom Solution Assign dummy order for gains without a corresponding loss

Group to Group Transfers
Requirement Facilitate manual transfers of stock and WIP between Group WBS Control stock availability between Group WBS (e.g. obsolete items only) Solution Transfer/loan borrow/payback (TBLP) transaction provided for store-room transfers Transfers are typically actual cost Custom Solution Multi-level transfer (individual WBS assigned orders) Transfer controls based on user parameters (NG) TBLP mk 2 ! Note that there are a number of restrictions in changing the account assignment. First of all if the order is settled (MTO orders should NEVER be settled) then not all the costs are transferred, which is a big downer. Secondly, if there are lower level MTO parts, these are not transferred. Lower level GPD parts are automatically transferred, based on the solution for pegging, since the originating requirement now comes from a different WBS. For this to work, the account assignment not just on the order header, but also on all the reservations, need to change. Thirdly there is a restriction, even with non-valuated project stock, where the reservation or component account assignment does not change with the header if any activity (goods issue) has taken place. We have built work-arounds for this which are successful, plus a front end to make sure that the whole transaction is managed properly.

Archiving Requirement Solution
Remove replenishment, pegging and cost data for shipped/closed projects from batch runs Improve long-term pegging and distribution performance Solution Use more Group WBS with limited group to group transfers Avoid large lot-sizes Future development in progress . . . Custom Solution Standard solution untested/unproven If a lower level production order has a large lot size it will be pegged and distributed to a large number of contracts. This causes problems in accuracy of actual cost since the actual cost for the order is distributed equally among all pegged WBS. In addition it causes an issue around archiving of data, since the production order may have open costs (returns, late labor approvals etc.) and its pegging is not as yet static, despite many of the pegged projects being closed. In this situation it is not possible to archive or close down the pegging for either this order, or for ANY of it children replenishments. The solution to this problem is to use smaller lot sizes, perhaps using larger lot sizing in planning (further out in horizon) and small lots for execution (closer in) based on the PP MRP scheduling levels configuration.

Serial Effectivity Requirement Solution
Control changes and configuration by end item for GPD planned materials Track serial numbers used in process Solution Combine parameter effectivity, single unit lot sizing and batch/serial based tracking solution in storeroom Roll part number up to individual project stock level for each change Custom Solution Assign reservation batch based on allowed effectivity and configuration requirements Please note that the solution of rolling the part number means the supply chain physically segregrates each part configuration and they are produced, purchased, stored etc. under a different material id. This approach probably requires enhancements to reduce overhead for BOM maintenance as well. The first solution, combining parameter effectivity, lot size and batch tracking, is the most elegant. Typically if FFF does not change the before and after configuration can be mixed, as long as you know what you are using at any given point and can plan the change in at the most effective point. The batch allocation enhancement provides an additional check to stop issuance of the wrong configuration to a higher-level order.

Thank you for attending!
Please remember to complete and return your evaluation form following this session That concludes this portion of the presentation, where I covered the basic concepts of GPD and why it is used. Richard will now address some of the additional functionality that is needed to fully implement GPD. Including G to G transfers Breakpoints Surplus/Scrap/Loss from stock and from production orders – custom enhancements Parameter effectivity and batch control. Finally, there are some limitations which must be fully understood when you use GPD. Cross-company transactions Subcontract Purchase Orders Returns processing via Sales orders Consignment inventory ROP/Safety stock Gains without losses MTO Transfers and lower level GPD components Questions? Session Code: 3205

Grouping, Pegging, and Distribution (GPD) Richard Minney, Xansa Rebekah Brooks, Goodrich Aerostructures Xansa was Goodrich’s consulting partner and.

Similar presentations

Presentation on theme: "Grouping, Pegging, and Distribution (GPD) Richard Minney, Xansa Rebekah Brooks, Goodrich Aerostructures Xansa was Goodrich’s consulting partner and."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Grouping, Pegging, and Distribution (GPD) Richard Minney, Xansa Rebekah Brooks, Goodrich Aerostructures Xansa was Goodrich’s consulting partner and.

Similar presentations

Presentation on theme: "Grouping, Pegging, and Distribution (GPD) Richard Minney, Xansa Rebekah Brooks, Goodrich Aerostructures Xansa was Goodrich’s consulting partner and."— Presentation transcript:

Similar presentations

About project

Feedback