SAP EWM The Good , the Bad and the Ugly

The good, the bad and the ugly, one of the greatest westerns ever made considering that it was a so-called ‘spaghetti western’

How does this apply to SAP EWM ?

The Good

SAP realized shortcoming within the existing SAP Warehouse Management system ability to satisfy complex business needs for warehouse operations. Many customers resorted to best of breed products integrated with SAP requiring complex interfaces. Initially, EWM was released with Service Parts Execution and subsequently evolved to its own product known as Extended Warehouse Management. Started with release 5.0 and currently reached 9.5 (Jan 2019) . SAP EWM solution capability eventually matured to easily compete with best of breed solution in most cases more effective due to the tight integration with SAP ERP system. EWM basically can support a complex high volume warehouse that requires an efficient operating solution to satisfy business needs.

Subsequent with the migration to SAP 4/HANNA SAP offer embedded EWM solution reducing the need of having a separate server with installed SAP SCM system to operate EWM system.  Many multinational organizations might continue to operate EWM on a separate decentralized server system due to transactional volumes and performance needs.

The Bad (or rather the difficult):

Achieving warehousing operational efficiency requires top-notch skill set not only within SAP space but also warehousing processes and integrating technology. Warehouse technology may consist of extremely complex automated systems such as Swisslog autostore , to automated crane systems and coveyor systems. Then we have Radio frequency , bar-code labels , packaging ect… Complex make up of technological elements integrated within SAP processes.

Swisslog autostore

In order to achieve operational excellence in terms of efficiency and effectiveness some form of bespoke custom development is required. Most project implementation require bespoke developments increasing risk and costs. Right skill set fundamental for efficient implementation and off-shoring rarely provides good outcomes.

The Ugly:

With the migration to SAP 4/HANNA embedded EWM system, EWM is now also offered which consists of basic EWM and advanced EWM.

Advanced EWM is only available at additional extra licensing costs and the following is not available within basic EWM license

• Material Flow System (MFS)
• Wave Management
• Transportation Units/YARD mgt
• Labour mgt
• Value added service
• Warehouse Billing
• Kitting
• Dock appointment scheduling
• Slotting

Wave mgt and Transportation units are fundamental in 90% of warehousing operations and having basic EWM license the installed EWM system will fail to provide real operational business benefits and leverage operational efficacy. This shortcoming can be overcome by means of bespoke enhancement: using shipment instead of TU and using PPF for scheduling and automating picking in place of waves.

The lack of MFS in the basic EWM license is less of an issue in that many operations, the automated system PLC driven hardware normally controlled by operating system provided by hardware supplier. Most cases, the hardware suppliers usually support the system and guarantee a certain percentage uptime . The service level agreement then becomes an issue with utilizing EWM MFS, most prefer interfaces to the existing PLC operating system. Basic EWM has full ability to generate IDOC to interface hardware.

With respect to kitting, not many warehouse systems carry-out kitting therefore not a major impact. Where it is needed, simple workaround is to simply set-up IM triggered movements: 1 for receipt of kit header and 1 for issue of kit components mapped to respective delivery documents. Simple low cost effort, a custom programme can be done to trigger kitting in order to keep reference between incoming header and outgoing components, the same custom can either require manual insert of components or read a BoM of the header to derive components.

Additional information with respect to SAP 4/HANNA: not only there is EWM embedded but also the availability of advanced production (technically APO PPDS embedded) and Advanced Available to Promise  (partially old APO gATP) but lacking CTP and rule-based availability check. They all require separate license implying that to work efficiently basic SAP 4/HANNA will not be sufficient to work smart 

How to Leverage SAP Extended Warehouse Management to Increase Volume, Efficiency, and Accuracy for Production Processes.

http://www.slideshare.net/bev41078/ewm-howtoleverage-sap

Traceability in complex Supply Chain structure

Traceability within a Complex Supply Chain flow and Distributed System Architecture (multiple EWM systems) and multiple software platform (SAP ERP, TM, legacy ect…).

OVERVIEW:

Organization’s require traceability either due to legal requirements or due to quality control requirements.

Traceability normally consists of defining detailed characteristics of a handling Unit and it its product, batch characteristics (expiry date, certificate ect..) and as well tracking across their micro (within plant) and macro (extra plant) supply chain.

Furthermore, in most cases traceability data must be kept for a number of years and must be available even though data has being archived.  Further complexity is to be able to track within the pipeline based on specific characteristics such as batch number, mould number to determine its location and its association (production order, sales order )

Most organisations have complex supply chain flows, they can normally be within plant flow where batches / Handling units are received and processed across multiple steps. The characteristics of the batch and Handling unit may change as they are processed through various nodes of the supply network. Typical example would be temperature controlled items, expiry date ect…In this physical flow from a Micro physical flow.

Micro Flows

Furthermore, a Handling Unit can also be processed externally across multiple Supply Chain Units, across many organisations units such as other distribution centres, customer etc..as show in the macro physical flow.

Macro Flow Physical Flow

The above Supply Chain flows may also be supported by distributed IT network that are managed by  individual SAP systems such as ECC , EWM and TM systems as well as legacy system. In each of these system there are processes that are specific to their relevant supply chain and have to be tracked. There are further situation where macro flows jump from one system to the other. Typical example is a Handling Unit produced and processed in one plant that is manage in System X, it then is sent to another plant via ship, the shipping is managed by system Y and eventually received in relevant plant system Y.

These multiple system creates a traceability dilemma in that having a single point view with respect to traceability becomes a serious problem.  

Traceability update

This can be resolved with a centralized traceability system where its update is based on update rule from the various system. Update rule must contain the relevant event’s that should update the traceability system. This can be when a handling Unit is received from production, the traceability system will then be updated with the handling unit characteristics , its relevant status and its process status. An update rule could apply if handling blocked by quality department.

The ability of updating characteristics allows tracing of handling units based on characteristics of the Handling unit.  The traceability not only will provide a full history of its process events and the latest status.

SOLUTION

Having provided a view on Supply Chain complexity with respect to Traceability and technology elements that are present in a complex supply chain, the solution would be a single point of data storage and extraction (reporting). This can be done by using SAP BW  whereby traceability data is stored in relevant cubes and can be updated via updates rules from multiple systems.

 

The traceability system will be updated from the various system based on common updates rules defined for relevant process events that are critical for traceability.

The fundamental design requires two critical definitions:

• The characteristics of the Handling Unit. In the definition of the characteristics it is imperative to define the critical key data elements that need to be maintained in the traceability. The data elements will be critical for tracking and reporting. From a reporting perspective data elements such as batch number, usability of the batch, tool number, certificate ect..This will then allow searching for related HU, example; search for usage of HU that was manufactured by a specific tool, or search all semi finished product HU where in put product was part of a specific batch.

• The update rules that will update the characteristics; only key saupply process need to be controlled and updated in the traceability system. Typcial update rule if when HU is born, when received from production, when shipped out to another manufacturing plant.

The update of the centralized traceability system will then provide a central repository system that will contain complete flows thorough supply chain. This system will also provide status of each Handling unit and will allow the relevant user to take the required action should need arise due to specific requirement. Possible example relates to pharmaceutical environment where due a specific batch all Handling Units have to be traced through its pipeline. The traceability system will also provide a multi dimensional flow from raw materials, to semi-finished to completed manufactured item. This is critical should search  for a specific batch of a raw material right through its usage up their final state (finished product).

The above shows how  the traceability system is updated via the update rule as a Handling Unit is processed through the supply chain.

Although RFID system may provide this kind of traceability, it will still have a narrow views and will not have the flexibility of a custom traceability that one can define characteristic unique to one’s business.

CIF Management for eWM

The eWM SCM platform is connect to the ECC system using CIF (qRFC) integration. The same integration technology used for APO.
The CIF is used both master data and transaction data.


Data is transferred using buffered qRFC technology:

Master data via standard CIF master data model, for eWM consideration/limitation must be made around vendor and customer replication as well batch managed products. Further consideration relates to managing batch determination in eWM. Critical to understand how characteristics and class are replicated and very critical to consider that it is not possible to use a SCM system for eWM batch management if set-up for configurable materials. This could be a problem if decision is made to use same SCM/APO development system for APO and eWM.
Changes are automatically updated for active models depending on Application Component (APO) flagged as well as change pointers set-up.
Transaction data, deliveries replicated to eWM system. From eWM delivery confirmation and goods movement. It is important that correct queue name is assigned to QIN scheduler.

One of the fundamental aspects regarding the CIF between ECC and eWM is related to monitoring and model management.

Queue must monitored for errors, job’s set-up to re-activate queue in error due to locking.

For active models, jobs must be set-up to de-activate a activate in order to include newly created master data objects. It is important in the CIF not to specify actual vendor or product codes but rather use other selection criteria such as plant / material types. For product material status is very useful to manage timing of replication in order avoid replicating a product that is still in the process of being updated in ECC.

SCM EWM Skill Set

What is needed to manage a EWM project ?

R3 WM skills ?

In order to effectively manage a EWM implementation the following skill set is need:

1. Strong Core Interface (CIF). This is because EWM runs on the APO platform, all interface are managed via qRFC

2. Strong ERP Delivery processing, this is because interfacing between ERP and EWM is via Deliveries.

3. WM experience helps, limited benefit from WM considering that eWM is totally new solution, not an upgrade. Therefore you need Functional EWM resources that know eWM processes around delivery processing, RF, yard mgt, cross docking, Warehouse tasks/order, Quality Inspection engine and maybe interface PLC. This functionality is not present in std SAP R3 WM, totally new, 10 x more complex than old WM.

4. ABAP, BADI know how. Most EWM projects are enhanced. Must be able to provide guidance to ABAP developers.

5. SAP Architecture. Knowing how to manage distributed architecture, change request transportation, sizing ect…

The above defines the Functional EWM Consultant. For technical parts regarding developments, any senior ABAP developer will be OK. The EWM technical platform is no different to APO or R3. What is critical is that the Functional EWM Consultant must provide guidance to the developer in terms of which direction the custom development should go, it could be sufficient that a BADI will do the job. A weak functional consultant normally leads to excessive developments, complex developments and in certain cases modification to SAP standard resulting in excessive support effort.

Bottom line, a WM consultant without the above requirements will take some months to get up to speed. The training courses provided are quite limited.

Focus on strong functional EConsultant and good ABAP developer (don't look at the low cost, you pay for what you get)

A simple WM consultant is suitable for junior role, a person that can cover all above 5 requirements is ideal for project lead.

Supply Chain Execution, WM, LES & eWM

WM, LES and eWM

Purpose, usage and benefits.

The SAP platform offers a quite a selection with respect to Logistics Execution (warehousing, delivery and transportation)

It is critical to understand each one.

Warehouse Management WM:
The warehouse management module in SAP ERP is as we all know it since the days of R3 3.0. The warehouse management module is suitable for simple and low volume warehousing environment that is fully integrated with the rest of the SAP modules such as IM, PP, QM as well as SD. The module has followed an evolution whereby Handling Unit Management, Radio Frequency and in later releases Task and Resource Management (limited success) was included in its offering. The SAP ERP WM modules usage is also influenced by the SAP architecture. Normally a SAP architecture for a local single company environment.

Logistics Execution System: LES (decentralized platform)

The Logistics Execution System which includes WM, shipping, transportation is also available in a centralized SAP architecture as well as decentralized architecture connected via standard ALE (IDOC’s).
The decentralized architecture is suitable for multi-national organization that have central ERP environment and require high volume distribution in many countries. The benefit of the decentralized architecture is to have separate server in a country, example Japan where main ERP server is in Germany to manage 24 hours a day 7 days a week warehousing and distribution functions without disruptions and high system availability. A further benefit relates to radio frequency response time. A distributed LES server allows quick (sub second) response time.
One of the shortcomings to the decentralized architecture relates to close integration to other modules (example QM) and process autonomy is very limited. Inbound and Outbound in LES are only possible if they were replicated from main ERP system. Quality management only worked if HU assigned in Inbound delivery in ERP system limiting the system independence.

Extended Warehouse Management: eWM

SAP has progressed warehousing and distribution development with the development of Extended Warehouse Management with the introduction of SCM 5.0 (APO platform). This solution was developed within the Service Parts solution and enhanced.
The eWM operates in a separate platform (SCM server) and is integrated with ERP (from SCM51) via the Core Interface (CIF, same technology as APO) using qRFC Inbound and Outbound.
The key design feature with respect to eWM are:
Suitable for multi system, multi customer and multi partner technical landscape
True operating autonomy, allows processing inbounds in EWM without the presence of Inbound Delivery Notifications from ERP system
Quality Inspection engine to manage QM
Integrated with RFID
The weakness of Task and Resource Management has being replaced by a totally integrated design with respect to processing, movement and resource management assignment. The eWM support both layout or process orientated movements of pallets within the warehouse
Native integration with Material Flow doing away with costly middleware.

What now ?

Where to, what solution should be chosen ?

First consideration is the business requirement, complexity, volume and SAP environment.

If single client low complexity and low volume then choosing standard WM solution is more than adequate.

Where the requirements are for high volume, complex environment and distributed warehousing based on single SAP ERP system, then either LES or eWM should be chosen.
The eWM solution is the obvious choice if the ERP environment is based on SAP Enhancement Package 3 for SAP ERP 6.0. The eWM offering provides more advanced functionalities than LES and will be the main focus for technology investment by SAP.