Continuous improvement remains a high priority across many industries as companies seek to increase flexibility and dampen rising costs. As these efforts mature and expand through an organization, they can take many forms. For information technology professionals in a manufacturing company, it may mean ensuring the company is getting the best use out of its software tools by identifying valuable, unused functionality. For material and inventory managers, it may mean reviewing replenishment methods and tools to be sure that they support Lean principles and fit the current business.

As one of the largest providers of Enterprise Resource Planning (ERP) software, SAP^® is widespread in the manufacturing community. However, SAP’s features that relate to consumption-based pull replenishment, namely reorder point planning and part-specific kanban, are often not well known. The consumption-based replenishment functionality in SAP can help companies who are struggling to expand their Lean implementation beyond a handful of manually managed items. Many practitioners will find that even with this capability built into SAP’s core ERP, questions often remain about how best to set the reorder points or size the kanban loop.

Supply chain groups in complex, highly variable environments – with thousands of products and significant demand variability – will likely run into limitations of SAP’s ability to directly support optimal replenishment processes. In this case, the paper will suggest when to investigate add-ons that can allow execution of other options, such as part-generic kanban and Constant Work In Process (CONWIP).

Many companies implementing Lean Manufacturing find themselves trying to balance the desire for simplicity and visual management with the appropriate use of the ERP system that serves as the transaction system, financial record, and data repository. Typically ERP is in place to help manage the complexity of the business, such as geographic separation and transactional volume. Some practitioners of Lean Manufacturing might dispute the need for software altogether, and in the case of highly repetitive environments, it makes sense to emphasize simple techniques than can be adopted without the benefit of technological solutions. However, as the scope broadens, practitioners have difficulty realizing the full benefits of implementing Lean techniques without the help of software. There are ways that “systems” can help. This paper will focus specifically on SAP: how it can be configured to assist your lean processes/approach, and what to do
when you run into limitations of its functionality.

SAP’s core ERP was previously referred to as SAP R/3 (such as versions 4.6 and 4.7), and is now known as SAP Enterprise Central Component (ECC) with versions such as 5.0 and 6.0. The name R/3 is a reference to the three-tier hierarchy of the client/server architecture: database servers, application servers, and the client/GUI. R/3, now known as ECC or simply SAP ERP, is the basics—the core functional and transactional modules of the ERP suit—including Financial Accounting (FI), Materials Management (MM), Production Planning (PP), and Sales & Distribution (SD). For simplicity, it will be referred to here as SAP ERP or core ERP.

Pull is a key principle of Lean, where the overriding goal is the elimination of waste, in this case avoiding over-production and excess inventory (two of the eight wastes). Rather than pushing inventory to the floor whether it is needed or not, as some computer –based ‘push’ methods do, pull relies on inventory signals to replenish parts when and where they are needed in just the right amounts required to replenish customer demand. New material is produced or procured only after old material has been consumed. SAP ERP supports two primary methods of consumption-based replenishment: Reorder Point Planning and Kanban.

Reorder Point Planning is a way to implement basic consumption-based pull replenishment. Materials can be set to Reorder Point Planning (ROP) in the core ERP with little setup, using just a few parameters as shown in Table 1. There are two common inventory policies:

• (s, Q), an order-point, order-quantity policy. With this approach, replenishment is triggered after actual demand causes inventory to fall below the reorder point (s). The replenishment is triggered for multiples of a fixed quantity (Q). This approach is good for processes with fixed batch sizes.
• (s, S), an order-point, order-up-to policy. With an (s, S) policy, a replenishment is also triggered when the inventory position falls below the reorder point (s), but in this case the quantity requested is the amount required to raise the inventory position up to the maximum level (S).

SAP offers implementation of both an (s, Q) inventory policy and an (s, S) inventory policy. The user can choose to manually specify the reorder point and safety stock or to let the system automatically calculate these values. The automatic option requires additional setup and is dependent upon the existence and maintenance of forecast data for the material.

Table 1: Details for Configuring Reorder Point Planning

Many companies implementing lean use card-based kanban systems to execute pull replenishment. Card-based systems work very well and are the preferred method when the number of parts/SKUs is low and proximity is close. Electronic kanban (e-kanban) can be helpful in overcoming two obstacles to scaling the use of card-based kanban replenishment:

• Overcome geographical separation that makes physical kanban difficult or impossible to use
• Address problems created when the number of items and corresponding number of “cards” is very large.

SAP can implement some kanban replenishment methods within its core Production Planning (PP) module. Implementation in this manner can be used to keep SAP inventory and appropriate transactions in sync with execution of a physical kanban, or the use of e-kanban can replace traditional cards or bins. One advantage of using SAP to support the kanban execution is that SAP captures transactions that can be useful for analysis and decision making. SAP’s functionality supports the following three part-specific kanban variations.

Classic Kanban: multi-card kanban loop between a demand point and a supply source. Each kanban is for a defined quantity, and consumption makes the kanban “EMPTY”, which triggers replenishment. If demand increases, the kanbans will cycle more quickly. If demand slows, the kanbans will cycle more slowly. There is never more material in circulation than is defined by the number of kanbans in the control cycle.

• Cycle is FULL-> EMPTY -> FULL

Event-driven Kanban: Also called one-time or temporary kanban. Event-driven kanbans might be used when an upcoming spike in demand is detected in advance. The user can define rounding quantities, fixed quantity (e.g. to ensure pallet quantities), and a default quantity.

• Cycle is FULL -> EMPTY -> DELETED

Kanban with Quantity Signal: special case of Classic Kanban. Withdrawal quantities are entered, and the system subtracts the withdrawal quantities so the remaining quantity in the active kanban is known. When the kanban quantity gets to zero the system sets status to EMPTY. It then selects the kanban that has been “FULL” the longest, marks it “IN USE” and subtracts withdrawal quantities. As the user does not tell the system which kanban is IN USE, and the user may not know which physical kanban has been at FULL status the longest, it would seem that the physical kanban and system kanban could get out of sync.

• Adds an IN USE status, so cycle is FULL -> IN USE -> EMPTY -> FULL

A control cycle is a pre-requisite for KANBAN. It is basically the definition of the kanban loop. The user creates control cycles with transaction code PK01. A control cycle defines the Demand Source-Supply Source relationship and includes

• Replenishment type (in-house production, external, stock transfer)
• # of Kanbans
• Quantity per Kanban
• Additional fields depending on Replenishment Type

The user can specify both the number of kanbans and the quantity per kanban, or the user may select Automatic Kanban Calculation. When Automatic Kanban Calculation is chosen the user specifies EITHER the number of kanbans OR the quantity per kanban, enters the replenishment lead time (if blank, the value from the material master will be used), and sets a safety factor. Then the system calculates the other value based on dependent requirements in the associated supply area (from long-term planning or MRP, e.g. forecast-driven).

The Automatic Kanban Calculation isⁱⁱⁱ:

• K Number of Kanbans (from control cycle)
• CONT Contents per Kanban (from control cycle)
• RT Replenishment lead time per kanban (from control cycle or material master record)
• AC Average consumption per time (from dependent requirements)
• SF Safety factor (from control cycle, default 1)
• C Constant (from control cycle, default 1), which corresponds to when the replenishment is triggered
  • Constant = 1 if a kanban is reported empty when the kanban is completely empty
  • Constant = 0 if a kanban is reported empty as soon as the first part is withdrawn

The Safety Factor (SF), defined by the user in the control cycle for Automatic Kanban Calculation, is used to buffer fluctuations in requirements. As discussed later, determining the correct safety factor can be quite difficult, especially in environments with significant demand variability, forecast error, and/or supply/process variability.

Planners may be surprised to learn that SAP allows kanban to be set up without MRP (expected) or with MRP (a bit unexpected). In the case of kanban without MRP, planned orders or purchase reqs are not created – the user must indicate which storage location to exclude from planning runs. Consequently, lower level components can only be procured by kanban or consumption based planning (like ROP). However, the item/storage location can still be included in long term planning. Alternatively, when an item is set up on kanban with MRP, planned orders or purchase reqs are created during the planning run; however, they are not intended to trigger  replenishment. This does give a preview of supply that may be needed, which is perhaps helpful for capacity planning, but it will require increased discipline to take action only.

While SAP has the capabilities discussed above, there are three areas where SAP users can struggle while configuring SAP to implement pull:

Setting reorder point levels and kanban sizing

There are challenges with both the manual and automatic Reorder Point and Kanban functionality. To set up manual Reorder Point or Kanban, the user must first determine the right inventory levels/parameters to use. Unfortunately, users are often uncertain how to select the right values and would need to look beyond SAP for guidance. For automatic calculation, SAP is dependent on forecast and ignores any variability in supply when determining the right Reorder Point level or Kanban size. This can create problems for companies who struggle with forecasts, or for companies whose reality includes late supplier deliveries or inconsistent internal production times.

Table 2: Challenges Configuring Reorder Point Planning

When using the Automatic Kanban Calculation, users will have difficulty finding information from SAP regarding what the kanban safety factor should be. Many users will likely leave it at the default of 1, which provides no protection against variation in demand or supply, which could lead to stock outs if demand or supply is variable. Other users might use some basic rules of thumb to apply a value greater than 1 across large swaths of items, which results in too much buffer for some items/products and too little for others depending on the variation experienced by each item. It can be challenging to determine the right size of the kanban loop to buffer against the variation in demand and supply for each individual item. Supply chain planners and inventory management groups will need to look to other tools for assistance.

Use of part-specific kanban in high-mix, make-to-order or engineer-to-order companies.

As complexity of the manufacturing environment increases – with thousands of parts, shifting bottlenecks, and highly variable demand for individual items – part-specific kanban becomes less and less appropriate because it might not even make sense to have inventory on the floor at all times. If the processes or the mix in the environment do require something other than part-specific pull replenishment, such as generic kanban or CONWIP, then the user will find SAP inadequate for implementation of these other flavors of pull. In these cases, companies should look to add-on tools, such as Flowlytics Pull Manager, to set up and execute the process in conjunction with standard transactions from SAP.

Transactional data might not be available within SAP.

Within your own plant or division, some transactions may be in other systems. This might also be the case if a sister plant or division, or a key supplier, does not use SAP and you need to combine the non-SAP data with your SAP data for the replenishment process. In these cases, SAP users will either need to persuade their supply chain partners to add additional data into SAP, or they will need an SAP add-on to consolidate their SAP data with data from non-SAP sources.

Where possible, utilize SAP to support your Lean implementation. If your company already has part-specific kanbans in place, or is ready to implement them, consider using the PP module’s kanban functionality to keep your inventory and transactions in sync with the physical process, or to overcome challenges with scaling to large numbers of items or overcoming geographic distance. However, as described above, there are three known limitations to be aware of:

1. SAP is dependent on forecast and ignores any variability in supply when automatically determining the right Reorder Point level or Kanban size. Both of these aspects can be hurdles, especially for companies that experience inconsistent replenishment lead times (e.g. suppliers that don’t deliver as scheduled or internal production times that vary).
2. SAP ERP only supports part-specific kanban. This type of pull is not well suited to high-mix make-to-order or engineer-to-order companies.
3. Transactional data must be available in SAP. This can be a problem for companies that have some data in non-SAP systems, or companies who want to create tighter linkage with a customer or supplier who does not use SAP.

To download the full whitepaper, click the button below.

Invistics provides consulting services and supporting software that allow manufacturing companies and distributors to configure SAP to be “lean friendly” and to implement consumption-based pull replenishment. If you’d like to learn more or schedule a no-commitment demo, call us at 800-601-3456.