Upload
sonja-mccoy
View
8
Download
2
Tags:
Embed Size (px)
DESCRIPTION
Root Cause Analysis
Citation preview
0
SAP AG 2006
Unit 8 - Overview Diagramm
Preface
Recap Customer CaseBusiness Process and Interface Monitoring
Data Volume ManagementJob Scheduling Management
Data ConsistencyManagement
Introduction to E2E Business Process Integration and Automation Management
Business Process Performance Optimization
Introduction to End-To-End Solution Support
© SAP AG E2E300 8-1
0.2
SAP AG 2006, Customer Case Recap / 1
Storyline
Business Process
Request to change Job Schedule for MRP
Changes to Business Process Monitoring for MRP
run
Detecting Alerts
BPPO for MRP Run
Long Runtime caused by Data Volume
Insufficient Outcome caused by data inconsistencies
Schedule Consistency Checks
Adjust Monitoring concept
Adjust Job Schedule
© SAP AG E2E300 8-2
0.3
SAP AG 2006, Customer Case Recap / 1
Initial Customer Situation – Scenario Business Process “Order to Cash”
CRM - C00
Create Sales Order
SAP ECC - TT5
Create Sales Order
Check Availability
Run MRP
Procurement Process
Manufacturing Process
Create Outbound Delivery
Post Goods Issue
Create Billing Document
Warehouse - TT5
Create Outbound Delivery
Create Picking Transfer Order
Confirm Picking Transfer Order
Post Goods Issue
SAP ENTERPRISE
PORTAL - EPP
Create Sales Order
Company IDES sells Pumps, Motorcycles, PC’s and light bulb. The company is located in Frankfurt /Germany and has subsidiaries within Europe, Asia, and North- and South America
Business Process “Order to Cash” describes the sales process for pumps:
Orders for pumps can be placed by customers directly via the Company Portal or via the Call Center that uses a non-SAP CRM system and are replicated to the ERP system via BDocs.
The availability of the ordered material is checked on the ERP system. The MRP determines how the material requirement can be satisfied. Materials that are not available can either be procured or manufactured in separate business processes.
Once the material is available the Outbound Delivery is created on the ERP system. During the creation of a delivery, the system establishes whether it is relevant for distribution or not. If it is, a BAPI is called when the delivery is saved. This BAPI starts the creation of an IDoc and via this IDOC sends the delivery to the Warehouse system.
In the Warehouse system the Picking Transfer order is created. Once the material is physically put into the Goods Issue zone the Warehouse Operator confirms the Picking Transfer Order. By this the posting of the goods issue is triggered, calling a BAPI. This BAPI confirms the data, that was created or changed in the WMS (e.g. quantities, packaging, batches, ...) to the ERP system.
When the confirmation is received in the ERP system the goods movement is executed in Inventory Management. Based on this the Goods Issue the billing document is created.
© SAP AG E2E300 8-3
0.4
SAP AG 2006, Customer Case Recap / 1
CRM - C00
Create Sales Order
SAP ECC - TT5
Create Sales Order
Check Availability
Run MRP
Procurement Process
Manufacturing Process
Create Outbound Delivery
Post Goods Issue
Create Billing Document
Warehouse - TT5
Create Outbound Delivery
Create Picking Transfer Order
Confirm Picking Transfer Order
Post Goods Issue
SAP ENTERPRISE
PORTAL - EPP
Create Sales Order
Technical Details for the Business Process
Job PP_MRP_0001_D runs once per day at 22:00
© SAP AG E2E300 8-4
0.5
SAP AG 2006, Customer Case Recap / 1
Structure of Support Organization
Business Department
Sales
Business Process Champion
IT Department
Business Process Operations Team
Business DepartmentProduction
Business Process Champion
© SAP AG E2E300 8-5
0.6
SAP AG 2006, Customer Case Recap / 1
CRM - C00
Create Sales Order
SAP ECC - TT5
Create Sales Order
Check Availability
Run MRP
Procurement Process
Manufacturing Process
Create Outbound Delivery
Post Goods Issue
Create Billing Document
Warehouse - TT5
Create Outbound Delivery
Create Picking Transfer Order
Confirm Picking Transfer Order
Post Goods Issue
SAP ENTERPRISE
PORTAL - EPP
Create Sales Order
Scenario Business Process “Order to Cash” – J ob Scheduling Management
Job PP_MRP_0001_D runs daily
We would like to change the schedule of the MRP from once per day to four times a day.
Business Process Champion
© SAP AG E2E300 8-6
0.7
SAP AG 2006, Customer Case Recap / 1
Use J ob Request Form for Requesting Change
See job documentation for PP_MRP_0001_DBusiness Relevance
See job documentation for PP_MRP_0001_DError Handling
Mr. MeyerBusiness Contact
......
5:30 and then every 6 hoursScheduling
TT5:800System/Client
PP_MRP_0001_DSubstituting which job
RMMRP000Report
PP_MRP_0001_6HJob name
So next steps to consider: planning, scheduling, monitoring!
Remark: documentation of technical parameters & business information, error-handling procedures, monitoring information
© SAP AG E2E300 8-7
0.8
SAP AG 2006, Customer Case Recap / 1
Planning - Check if new J ob Request fits into existing schedule
HW & time restrictions!! scheduling at 5:30 might be a problem other less important jobs might need a rescheduling
For job distribution over time use BATCH_JOB_ANALYSIS tool
© SAP AG E2E300 8-8
0.9
SAP AG 2006, Customer Case Recap / 1
CRM - C00
Create Sales Order
SAP ECC - TT5
Create Sales Order
Check Availability
Run MRP
Procurement Process
Manufacturing Process
Create Outbound Delivery
Post Goods Issue
Create Billing Document
Warehouse - TT5
Create Outbound Delivery
Create Picking Transfer Order
Confirm Picking Transfer Order
Post Goods Issue
SAP ENTERPRISE
PORTAL - EPP
Create Sales Order
How does Change in Scheduling influence Monitoring tasks?
Job PP_MRP_0001_6H runs every 6 hours starting at 5:30
The business process should never stand still. If material is available at the time of the order creation and the order is created before 12:00, the material itself should leave the yard at 16:00.
Business Process Champion
Which business process specific objects have to be monitored to ensure that possibly business critical situations are recognized and solved before the have an impact?
© SAP AG E2E300 8-9
0.10
SAP AG 2006, Customer Case Recap / 1
Incorporate into existing Business Process and Interface Monitoring concept
Step 3 Identify business requirements
Step 4Define monitoring objects, alerts and thresholds
Step 5Define monitoring activities
Step 6Define communication and escalation procedures
Step 7 Assign monitoring activities to responsibles
Error situations should be recognized:
Dumps within MRP Run, Cancellations
MRP run has to start within 30 minutes of scheduled start time and has to be finished within 15 minutes, otherwise resources for other activities are allocated
MRP run cancellation: Red alert
Dumps within MRP: Red alert
MRP Start Delay: 15 minutes for yellow and 30 minutes for red
Maximum Duration: 10 minutes for yellow, 15 minutes for red
Use SAP Solution Manager for automated monitoring
in case of problem check job log for MRP run for problems
Job Status is directly observed in external job scheduling tool
In case of problems contact business department (Mr. Meyer)
If you can’t solve the problem open ticket
Monitoring is supposed to be carried out by Mrs. Hampert in Business Process Operations Team
© SAP AG E2E300 8-10
0.11
SAP AG 2006, Customer Case Recap / 1
Monitoring set up according to Documentation (especially Roadmap and Setup Guides) available in Quicklink /BPM in SAP Service Marketplace
Monitoring functionalities as they are available in ST-A/PI on Satellite system or within ST-SER on SAP Solution Manager
Link to Error Handling procedures and Analysis Tools in Satellite System
Remark: Data Collection specific for each monitoring object, normally not more frequent than every 5 minutes
SAP Solution Manager used for Monitoring MRP Run
© SAP AG E2E300 8-11
0.12
SAP AG 2006, Customer Case Recap / 1
CRM - C00
Create Sales Order
SAP ECC - TT5
Create Sales Order
Check Availability
Run MRP
Procurement Process
Manufacturing Process
Create Outbound Delivery
Post Goods Issue
Create Billing Document
Warehouse - TT5
Create Outbound Delivery
Create Picking Transfer Order
Confirm Picking Transfer Order
Post Goods Issue
SAP ENTERPRISE
PORTAL - EPP
Create Sales Order
IT Department detects Alert Situation
MRP Run takes 30 minutes each time it runs Red alert
Business Process Operations Team
© SAP AG E2E300 8-12
0.13
SAP AG 2006, Customer Case Recap / 1
Example for Process Flow for Business Process Monitoring
IT Department
Business ProcessOperations
Application Management
Detect Alert Situation
Execute Initial Analysis
Assign Service Desk message to issue
RCA process
Create Service Desk message
Alert for Job Duration
Initial Analysis does not solve the situation
Business Process Performance Optimization is triggered for the MRP run
© SAP AG E2E300 8-13
0.14
SAP AG 2006, Customer Case Recap / 1
MRP run has shown increasing runtime over the last weeks
A performance analysis is considered as an urgent issue as the business process step is considered to be critical as KPIs a given with regards to time restrictions an throughput requirements.
Initial error handling did not solve the problem, detailed root cause analysis is required Business Process Performance Optimization
Business Process Performance Optimization for MRP Run
© SAP AG E2E300 8-14
0.15
SAP AG 2006, Customer Case Recap / 1
Procedure for finding cause of longer runtimes for MRP run
Analysis via transaction ST03N shows that the increasing runtime is mainly caused by an increasing DB time share.
Further analysis via ST03N shows that the amount of sequential reads is constantly growing perhaps a Data Volume problem
An SQL trace analysis (transaction ST05) shows that no significant tuning potential is given, e.g. no identical selects, no unsuitable indexes used
© SAP AG E2E300 8-15
0.16
SAP AG 2006, Customer Case Recap / 1
Data Volume Management triggered by MRP
So in order to improve the runtime of the MRP run the DB table RESB should be analyzed via transaction DB02 (size 20GB).
Can the size be reduced and/or the growth slowed down? So can you avoid, delete, summarize or archive data?
For RESB data avoidance and archiving is possible.
Archiving production orders using archiving object PP_ORDER is especially helpful if table RESB contains many order reservations (field BDART = AR). Archiving these noticeably reduces the data volume in RESB. This also improves the performance of reading order reservations.
A good indicator for deciding whether archiving table RESB would make sense or not is the number of “old” (for example older than three months) reservation entries, for which the final issue indicator (field KZEAR – final issue) has been set. If your system has a large number of these kind of reservations, you should check, whether it would be possible to flag them for deletion and then remove them from table RESB when the production orders are archived.
© SAP AG E2E300 8-16
0.17
SAP AG 2006, Customer Case Recap / 1
Database Size and Growth
No indication for establishing Data Volume Management, but nonetheless DVM can solve the long runtime
Database Size < 500GB
Database Growth < 20GB/month
© SAP AG E2E300 8-17
0.18
SAP AG 2006, Customer Case Recap / 1
Archiving Objects for table RESB
Operative Structures PS_PROJECT
Process OrdersPR_ORDER
Production OrdersPP_ORDER
Service & Maintenance OrdersPM_ORDER
Purchasing DocumentsMM_EKKO
Purchase Requisitions MM_EBAN
Archived Application DataArchiving Object
Can be checked in /nDB15.
© SAP AG E2E300 8-18
0.19
SAP AG 2006, Customer Case Recap / 1
Storyline
Business Process
Request to change Job Schedule for MRP
Changes to Business Process Monitoring for MRP
run
Detecting Alerts
BPPO for MRP Run
Long Runtime caused by Data Volume
Insufficient Outcome caused by data inconsistencies
Schedule Consistency Checks
Adjust Monitoring concept
Adjust Job Schedule
© SAP AG E2E300 8-19
0.20
SAP AG 2006, Customer Case Recap / 1
Stock Difference between IM and WM – Effects for MRP run
Business Process Champion
Root Cause Analysis: MRP only considers stock in Inventory Management (on ERP system) and not on the warehouse system
Check for inconsistencies between IM and WM via transaction LX23
Business complains that throughput for business process is not good enough Materials are not sent out immediately even though they are physically available on the shelf
© SAP AG E2E300 8-20
0.21
SAP AG 2006, Customer Case Recap / 1
Recognizing Inconsistencies – Possible Causes
Possible Reasons:
Missing Error Handling
Business Process not followed by end users
Implicit COMMITS within customer coding (ignoring SAP LUW principle)
© SAP AG E2E300 8-21
0.22
SAP AG 2006, Customer Case Recap / 1
Solve Inconsistency
1. Execute Error Handling
2. Confirm open transfer orders to should already have been confirmed
3. Use LX23 to correct stock information
© SAP AG E2E300 8-22
0.23
SAP AG 2006, Customer Case Recap / 1
Adjust Monitoring Activities to recognize potentially critical situations proactively
Step 3 Identify business requirements
Step 4Define monitoring objects, alerts and thresholds
Step 5Define monitoring activities
Step 6Define communication and escalation procedures
Step 7 Assign monitoring activities to responsibles
Error situations in interface should be recognized
Open TOs older than 5 days should be recognized
Error status for IDocs of type DESADV, one for yellow, 5 for red
Open TOs older than 5 days: 100 for yellow, 50 for red
Use SAP Solution Manager for automated monitoring
In case of problems contact business department (Mr. Meyer)
If you can’t solve the problem open ticket
Monitoring is supposed to be carried out by Mrs. Hampert in Business Process Operations Team
Include monitoring of open transfer orders and of IDocs between ERP and WHS into the BP+IMon concept
© SAP AG E2E300 8-23