GD SCM EM Approach Doc

7/31/2019 GD SCM EM Approach Doc

1/23

ECO, Ltd. Project AIM

TABLE OF CONTENTS

1 APPROACH NOTE 2

PROCESS DOCUMENT6

DELIVERY TRACKING 6

REVISION HISTORY 7

2 BUSINESS PROCESS SUMMARY 9

3 BUSINESS REQUIREMENTS 10

4 BUSINESS PROCESS DESCRIPTION 11

5 BUSINESS OBJECTS AND MASTER DATA 15

DESIGN DOCUMENT17

DELIVERY TRACKING 17

REVISION HISTORY I



8 OBJECT DEFINITION 5

Copyright 2005 SAP AG. All rights reserved 1


2/23


1 APPROACH NOTE

SAP SCEM implementation through Global Delivery Methodology

Global Delivery is a part of ASAP methodology for SAP Solution implementations. This approach note

aims at providing certain guidelines and considerations for carrying out the SAP SCEM (Supply Chain

Event Management) solution implementation as per ASAP involving Global Delivery.

The approach has been divided into sections that reflect various ASAP phases and are marked with the

corresponding Global Delivery Involvement in each section. This note also includes or includes links to

accelerators that may be used to expedite the implementation.

Above figure shows the flow of activities, the extent of Global Delivery based activities marked in color.

Each of the steps are described below.

1.1 Level -1 Questions

Global Delivery Methodology has a set of standard questions that are useful in understanding the broad

profile of requirements or customer expectations from the Supply Chain Event Management.

Depending on the functions and processes involved in the tracking scenarios, the standard content

provided by SAP will be evaluated to assess the extent to which it can be used. Also depending on thesystems involved, an integration strategy will need to be developed.

See Appendix A for Level 1 Questions Accelerator

1.2 Level 2 Questions

After above has been done, a level two set of questions will be prepared. This will contain a set of

standard questions as well as some specific questions based on the actual scenarios. This shall be

Level 2Questions

Level 1Questions

ProcessDocument

Evaluation /Confirmation

DetailedDesign Doc.

Realization /Developments

Test ScriptsGeneration

Final testingand UAT

Done at a GDC Location



3/23


done in coordination with other concerned entities working on the project and customer responsible.

This can be done either from Global Delivery location or customer location depending on theassessment made by the SCEM consultant.

1.3 Process Documentation

After understanding the requirements and the landscape, the Global Delivery team will prepare a

process document that will highlight the Event Management related aspects in the business process. It

will clearly mention the activities that will be tracked, the statuses that will need to be monitored, what

will be system reaction to the events, what data will be captured and what channels will be used for

gathering and distributing event related information. In short, this document will describe the process ofevent management without yet getting into the configuration or technical design.

See Appendix B for Process Documentation Accelerator

1.4 Evaluation & Confirmation

The Customer will evaluate and confirm the processes recorded in the process document.

1.5 Detailed Design Document

The Global Delivery team will prepare a detailed design document. This shall list down the configuration

guidelines. For example it will list the Event Handlers to be configured, Naming Convention, Status

Profiles to be configured, Standard Objects to be used from Visibility Scenarios, Development

requirements, etc.

See Appendix C for Detailed Design Document

1.6 Realization / Developments

The actual configuration and developments related to ABAP and J2EE will be done by the Global

Delivery team from the Global Delivery locations. Some examples of the key objects are following:

Configuration of SAP Application Systems

o Application Object Types with all Extractors

o Event Types with all Extractors

Configuration of the SAP Event Management System

o Event Handlers



4/23


o Alerts

o

Status Monitoringo Expected and Unexpected Events

o BW profiles

Configuration for Web based monitoring and reporting through WCL

o WCL Transaction configuration

o User Profiles for WCL

o Look and Feel related developments for WCL

Etc.

1.7 Test Scripts

After the configuration phase is complete, the testing will follow. This step before testing involves

developing test scripts that represent the actual business scenario. This will obviously depend on the

extent of dependencies on other solution component. The test scripts will list down the step by step

transactions to be carried out and the expected results.

Appendix D for Test Scripts Accelerator

1.8 Testing / UAT

(User Acceptance Test)

Once the test scripts are ready, the first round of testing will be carried out by the designated testers at

Global Delivery Locations. Next level will be testing by the actual business users. The recorded method

of carry out the process during testing may be provided to the users from the customer site. There will

be template provided to the users to record any observations or issues. The issues will be resolved by

the Global Delivery Team along with the other concerned teams. More rounds of testing may be needed

if there are significant changes suggested during testing.



5/23


Appendix A. Level 1 Questions

It is assumed here that the participants from Customer side will have conceptual understanding of Event

Management, if not that will be taken up taken up in the form of training by the implementation team

before gathering these requirements.

Q. Do you want to use SCEM for monitoring only? Or you want certain automatic actions to be

triggered by SCEM System.?

Q. Which are the functions that will be involved in tracking?

Q. Which are the processes that will be involved in tracking?

Q. List down all tracking scenarios (a string or set of events that you want to view together or want

to have a status of) that you would like to have.

Ex: Tracking of delivery process from Delivery creation till proof of delivery.

Q. For each of above scenarios list down following..

a. All the expected events that will be part of the tracking scenario

b. All the unexpected events that may occur under the scenario

c. For each event, what is the source of information? It could be own system or a partner

system, SAP or Non-SAP system. It could also be a manual recording of an event.

d. For each expected event, if you would like to have an expected date and time, what will

be the source of this information.

e. What would be the reaction for reporting expected or unexpected event? Similarly

reaction to an overdue expected event? Reaction could involve, sending e-mail alerts

to partners or customers, updating statuses or carrying out some activity in the

systems.

f. What status would you like to monitor? Statuses can be managed independent of

events and are updated as a result of event reporting.

Q. Would you like to extract the SCEM data into BW system for analysis?

Q. What is data you would want to extract from each of the tracking scenarios?Q. Would you require status monitoring on the internet or Portal?



6/23


Appendix B. Sample Process Documentation

Sample ProjectSample Project

PROCESS DOCUMENTPROCESS DOCUMENT

DELIVERY TRACKINGDELIVERY TRACKING

Version 1.0

Steve Balmer



7/23


REVISION HISTORY

VersionNumber

AmendmentNumber

Date Description Author

1.0 1 Initial Release



8/23


TABLE OF CONTENTS

1 APPROACH NOTE 2

PROCESS DOCUMENT6

DELIVERY TRACKING 6

REVISION HISTORY 7





DESIGN DOCUMENT17


REVISION HISTORY I






9/23

2 BUSINESS PROCESS SUMMARYVarious business processes have been described in detail in other documents. Its being described herefrom the Event Manager (EM) perspective.There are three entities involved in the whole process. HUB, Drop Off Point (DOP) and Client 1customer. The Customer places an order on a HUB for the equipment. The HUB delivers the material tothe DOP which is geographically suitable to the Customer. The DOP can make a partial receipt of adelivery. Ie it can accept some handling units of all the handling units in a delivery. The DOP then putsaway the HUs in the storage area. Receipt of incomplete deliveries (not all HUs being there) is handledas an exception.

The Client 1 customer engages one or more installation partners for installing the equipment across

various sites. An installer can work for more than one customer and can install equipment at more thanone site for the same customer. The respective installer, representing the customer, fixes up anappointment by calling up the DOP and then picks up the material at a pre-agreed time. The DOP canissue only complete deliveries to the Installer.Delivery cant be made to the installer even if one HU is missing or is not in deliverable condition due todamage etc.

In case the installer does not find any HU as expected, he has to reject the complete delivery. Theinstaller can return complete deliveries to the DOP for temporary storage, in which case he can pickthem again at a later point of time.Only complete deliveries can also be returned to the DOP due to rejection.

The DOP can initiate the process of sending back the HUs to the HUB.

Event Manager will also collect information in the process which needs to be stored somewhere on aregular basis so that it can be analyzed later or can be used for activities like billing etc. Hence EventManager will keep sending the required information to the Business Information Warehouse.

Following events have been identified for tracking. (U= unexpected event)

Inbound Outbound

1. PGI from Client 1 1. Installer arrival2. Departure from HUB* 2. Pickup by installer3. Arrival at DOP ` 3. Installer no-show (U)**4. PUT away 4. Installer rejection (U)**

5. Return to HUB (U) 5. Installer return (U)**

* The event of Departure from HUB will not be separately tracked; PGI from Client 1 will be taken as departurefrom HUB.

** Three unexpected events of No-show, Rejection and return will be combined into one unexpected event.



10/23


3 BUSINESS REQUIREMENTS

In the business process described above various users need to know the status of various events inorder to coordinate the work. The DOP needs to know when a delivery is dispatched from the HUB.They also need the information about who is the ultimate receiver of this material and when is he goingto come and collect this material. The Installer needs to know when his order has been dispatched fromthe HUB and when its arriving at the DOP. He needs the information about when his material is readyfor pickup from the DOP. The DOP needs to know, in case the Installer has changed his plan of pickingthe material. And on the overall level, CLIENT 1 needs to know about the material movement from andto the DOP.

Broadly the business requirement from the Tracking point of view can be divided into fourcategories

1. Ability to see an online and up-to-date status of various business objects (Ex. Delivery etc) andvarious events (Ex. Arrival of truck at DOP, Delivery pickup by the Installer )

2. Ability to get automatic alerts as a result of occurrence of different events. (Ex. An alert to Client1 when a delivery reaches the DOP )

3. Various data points generated in the process of tracking should be available for use later. (Ex.Time which a Handling unit spends at the DOP )

Proposed Solution

Event Manager Solution in SAP SCM 4.0



11/23


4 BUSINESS PROCESS DESCRIPTION

There are several places in the processes chain where capturing of specific events is a businessrequirement. At most of the places the business requirement is to record and report the status ofprocesses at a delivery level. However at some places for example partial receipt of a delivery, thestatus capturing needs to be done at handling unit level. Hence both HU level and delivery level trackingwill be provided as per business requirement.The Business process has been described below from the point of view of occurrences of events atvarious stages. Entire process has been divided into two parts:

4.1 Inbound Logistics

HU comes into existence before the shipment process in Client 1 system. After the packing Client 1sends out a Shipment request to CLIENT 2. CLIENT 2 takes a delivery and transports it to thedesignated Drop off point.

In above process the event to be noted is handing over of the Shipment to CLIENT 2. Hence thisshould form the first event in the series. The shipment from the HUB may not leave at the same time asthe shipment creation. Hence the actual departure of the delivery from the HUB forms another importantevent. After remaining in transit for some time, the delivery reaches the DOP and arrival of delivery atthe DOP marks another significant event.

Delivery is received at the DOP and handling units are checked for correctness. Correct HUs /Deliveries are put away into the warehouse. Once a delivery is completely put away, its technicallyready to be picked up by the recipient of the delivery. Hence this forms another important event.There can be a scenario where an HU or entire delivery is to be returned to the HUB after receiving it at

the DOP, which is an unexpected event and hence should be tracked.

Thus following are the key events on the inbound side of the process...

4.1.1 Expected Events

The expected events by definition are events that are expected to take place in the normal flow ofactivities. Based on above understanding of the process and discussions with CLIENT 2 and Client 1following expected events have been identified.



12/23


4.1.1.1 PGI from Client 1

Its actually sending of the Shipment request but due to convention being followed in the project, itsbeing called so.

4.1.1.2 Departure from HUB (Proposed not to be separately tracked)

Since a manual entry will be required to specifically mark the departure from the HUB, its beendecided that the event PGI from Client 1 will be taken as the indicative of departure from the HUB.

4.1.1.3 Arrival at DOP

Arrival of the HU at the DOP is recognized by the system, however at this time the HU has still notbeen taken into the storage space.

4.1.1.4 Put away at DOP

When the HUs is taken into the storage space and are put away into specific storage bins, the event ofHU put away is marked.

4.1.2 Unexpected Events

Unexpected events are not part of normal flow but are expected to occur due to some abnormalconditions. Hence a provision is to be made to track such occurrences. Following have been identifiedas unexpected events.

4.1.2.1 Return to the HUB (Unexpected Event)

There can be instances where a handling unit is returned to the HUB after being received into the DOP

or after having been returned by the installer.

4.2 Outbound Logistics

Once all the HUs of a delivery have been put away in the DOP the outbound side of the DOP processstarts. From here on, the transaction happen only at complete delivery level. The respecting installerreceives a notification about the arrival of his goods at the DOP. The installer then calls up the DOP andfixes an appointment for picking up the delivery from DOP.

The DOP records the proposed pickup time against the name of the installer, the customer it representsand the delivery he intends to collect. The DOP brings the Handling units corresponding to the deliverywhich Installer intends to collect, into the delivery area. This is done before the installer arrives. TheInstaller then comes to pickup the delivery. At this time the Instance of Arrival of the Installer is manuallyrecorded along with the time of arrival. This forms an important event because this determines howmuch time passed between arrival of the delivery at the DOP and its pickup by the installer. The installerpicks up the goods and then the PGI for the delivery is carried out. This marks the Goods picked up byInstaller event.

In case of unexpected Installer no-show, an unexpected event is reported. After which Installer can re-fix an appointment and collect the delivery as a normal process.



13/23


There can also be a case of one or more handling units being rejected by the installer, after inspection.This results in complete rejection of the delivery by the installer. This event of rejection is recorded as

an unexpected event.And if after rejection, the HUs are sent back to the Hub, this is also reported to the EM.

Hence the events in the outbound chain are as follows.

4.2.1 Expected Events

4.2.1.1 Installer arrival

Actual arrival time of the installer is recorded and marked as an event of Installer Arrival.

4.2.1.2 Pickup by the installer

When installer picks up the corresponding delivery this event is marked.

4.2.2 Unexpected Events

Following unexpected events have been identified on the outbound side of DOP processing.

4.2.2.1 Installer No-show (Unexpected)

In case the Installer doesnt turn up at the agreed time, the DOP records this event manually. Since

there can be situations where the Installer might call up some time before the scheduled pickup timeand change the appointment time. Its on the discretion of the DOP operator to record this event.

4.2.2.2 Rejection (Unexpected)

4.2.2.3 Return by Installer(Unexpected)

4.2.2.4 HU returned to the HUB(Unexpected)

In Return to HUB process remains the same as in the case of return to Hub in the inbound side.

Its been decided that all unexpected events related to the Installer will be recorded as one event

in the phase 1 of the project.



14/23




15/23


5 BUSINESS OBJECTS AND MASTER DATA

5.1 Business objects in R/3

5.1.1 Business Process type

A Business process type is defined as a segregation of areas of tracking. For example finance relatedtrackings need to be kept separate from logistics related trackings. Application object types and Eventtypes are defined under a Business Process type.

5.1.2 Application Object Types

The application object type is used to determine the supply chain event management relevance (SCEM

relevance) of objects or processes in the application system. The Handling unit & the Deliveries willhave to be defined as Application Object type.EM relevance of an AOT is decided by the conditions or functions assigned to the AOT. Creation of anAOT in the R/3 system will typically trigger creation of an Event Handler which is a counterpart of theAOT in the EM system.

5.1.3 Event Types

Various events that occur in the application system (Ex. Completion of packing for a delivery) aredefined as event types. Each event type is tested for Event Management relevance by applying therelevance conditions. A relevant event sends an event message to the EM system and correspondingevent is reported in the suitable event handler.

5.1.4 Tracking IDs

Tracking ID group: A tracking ID group, is basically a type of tracking IDs. For example in order to tracka Handling Unit, one can use either the HU number or the Delivery number. Hence HU number is onegroup and Delivery number is another group. Within a group a particular number (Ex. HU no. 87349200)is called a Tracking ID.When we enter a tracking ID, the system needs to be told whether the number being entered is a HUnumber or a Delivery number, hence tracking ID group is specified.Following tracking ID groups are proposed to be used...

1. Client 1 Delivery Number2. Client 1 Handling Unit number

3. CLIENT 2s internal Handling unit no.4. CLIENT 2s internal SO number.

5.2 Business objects in EM

5.2.1 Business Process type

Business Process type is defined in EM similar to R/3. The Business Process type is common in both the systems. The eventhandler types are defined under a business process type.



16/23


5.2.2 Event Handler type

Event handler is the smallest unit at which tracking is done. Event handler in EM corresponds to the application object type. Eventhandler types shall be defined for HU and Delivery.

5.2.3 Internal Event codes

Codes will need to be defined for various events that are expected to be tracked, both expected andunexpected.

5.2.4 Expected Event Profile

An expected event in EM corresponds to the milestones in the R/3 system. These milestones for anapplication object type are identified by the Expected Event Extractor of the AOT.

An expected event profile is to be assigned to an event handler type.

5.2.5 Status profile

A status profile is assigned to an Event Handler type. A status basically contains a list of statusmessages and possible values for every message. For example one of the status message in a profilecan Delivery status and possible values of the same can be Not started, In transit & Completed

Following status profile is proposed

Message Possible Values

HUB to DOP Transport To start; In transit; Completed

Put away at DOP To Start; Completed

Pickup by Installer To Start; Going on; Completed

HU status To reach DOP; Lying at DOP; Picked up by installer; Returned to HUB

5.2.6 Authorization Profiles

An authorization profile is assigned to a user and the user can display or change the data, post eventmessages etc based on the assigned profile. Initially standard profiles will be defined, once the systemis configured, profiles can be assigned to the actual users as per CLIENT 2s need.



17/23


Appendix C. Sample Design Documentation

Sample ProjectSample Project

DESIGN DOCUMENTDESIGN DOCUMENT

DELIVERY TRACKINGDELIVERY TRACKING

Version 1.0



20/23


6 BUSINESS PROCESS SUMMARY

Various business processes have been described in detail in other documents. Its being described herefrom the Event Manager (EM) perspective.

There are three entities involved in the whole process. HUB, Drop Off Point (DOP) and Client 1customer. The Customer places an order on a HUB for the equipment. The HUB delivers the material tothe DOP which is geographically suitable to the Customer. The DOP can make a partial receipt of adelivery. Ie it can accept some handling units of all the handling units in a delivery. The DOP then putsaway the HUs in the storage area. Receipt of incomplete deliveries (not all HUs being there) is handledas an exception.

The Client 1 customer engages one or more installation partners for installing the equipment acrossvarious sites. An installer can work for more than one customer and can install equipment at more thanone site for the same customer. The respective installer, representing the customer, fixes up anappointment by calling up the DOP and then picks up the material at a pre-agreed time. The DOP canissue only complete deliveries to the Installer.

Delivery cant be made to the installer even if one HU is missing or is not in deliverable condition due todamage etc.

In case the installer does not find any HU as expected, he has to reject the complete delivery. Theinstaller can return complete deliveries to the DOP for temporary storage, in which case he can pickthem again at a later point of time.Only complete deliveries can also be returned to the DOP due to rejection.

The DOP can initiate the process of sending back the HUs to the HUB.

Event Manager will also collect information in the process which needs to be stored somewhere on aregular basis so that it can be analyzed later or can be used for activities like billing etc. Hence EventManager will keep sending the required information to the Business Information Warehouse.

Following events have been identified for tracking. (U= unexpected event)

Inbound Outbound

1. PGI from Client 1 1. Installer arrival2. Departure from HUB* 2. Pickup by installer3. Arrival at DOP ` 3. Installer no-show (U)**4. PUT away 4. Installer rejection (U)**5. Return to HUB (U) 5. Installer return (U)**

* The event of Departure from HUB will not be separately tracked; PGI from Client 1 will be taken as departurefrom HUB.

** Three unexpected events of No-show, Rejection and return will be combined into one unexpected event.



21/23


7 BUSINESS REQUIREMENTS

In the business process described above various users need to know the status of various events inorder to coordinate the work. The DOP needs to know when a delivery is dispatched from the HUB.

They also need the information about who is the ultimate receiver of this material and when is he goingto come and collect this material. The Installer needs to know when his order has been dispatched fromthe HUB and when its arriving at the DOP. He needs the information about when his material is readyfor pickup from the DOP. The DOP needs to know, in case the Installer has changed his plan of pickingthe material. And on the overall level, CLIENT 1 needs to know about the material movement from andto the DOP.

Broadly the business requirement from the Tracking point of view can be divided into fourcategories

4. Ability to see an online and up-to-date status of various business objects (Ex. Delivery etc) andvarious events (Ex. Arrival of truck at DOP, Delivery pickup by the Installer )

5. Ability to get automatic alerts as a result of occurrence of different events. (Ex. An alert to Client1 when a delivery reaches the DOP )

6. Various data points generated in the process of tracking should be available for use later. (Ex.Time which a Handling unit spends at the DOP )

Proposed Solution

Event Manager Solution in SAP SCM 4.0



22/23


8 OBJECT DEFINITION

8.1 APPLICATION OBJECT AND EVENT TYPES

Application Object Types

ZDN_DEL_IN Inbound delivery processZDN_DEL_OUT Outbound delivery processZDN_HU_AOT Handling unit

Event Types

ZDN_HU_TO_CREATE Transfer order creation for an HU in inbound deliveryZDN_HU_TO_CONFIRM Transfer order confirmation for HU in inbound delivery

8.2 EXPECTED EVENT CODES

Expected Events

ZDN_PGIDON_DH PGI doneZDN_LEFHUB_DH Delivery left the HUBZDN_ARRDOP_DD Delivery arrived at the DOPZDN_ARRDOP_HH Handling unit arrived at the DOPZDN_PUTDOP_DD Delivery put away done at DOPZDN_PUTDOP_HH Handling unit put away done at DOP

ZDN_ARRINS_DH Installer arrived at DOPZDN_DELDOP_DD Delivery picked up from DOPZDN_DELDOP_HH Handling unit picked up from DOP

Unexpected Events

ZDN_NOINST_DH Installer doesnt arriveZDN_INSREJ_DD Installer rejects the deliveryZDN_INSREJ_HH Installer rejects the HUZDN_RETHUB_HH Handling unit returned to HUBZDN_RETHUB_DD Delivery returned to HUBZDN_INSRET_DD Installer returned the Delivery

ZDN_INSRET_HH Installer returned the Handling Unit



23/23


8.3 STATUS PROFILE DEFINITIONS

Status profile for the Inbound Delivery Event Handler

Status Profile: (ZDN_INBDEL: Inbound Delivery status profile)

Attributes of profile:

ZDN_ARR_DEL_IB: Arrival of delivery at the DOPIn transitPartially arrived at DOPFully arrived at DOP

ZDN_DEL_PUT_IB: Put away of delivery at DOPNot startedPartially put awayFully put away

ZDN_PICKUP_IB: Delivery pickup by InstallerPick up not donePick up completed

Status profile for the Outbound Delivery Event Handler

Status Profile: (ZDN_OUTDEL: Outbound Delivery status profile)

Attributes of profile:

1. ZDN_STAT_OB: Status of outbound delivery

Delivery created

Delivery handed over to the Customer


Documents

GD SCM EM Approach Doc