12035PMSP Functional Specification DOA Work Order Approval Rev 1

SAP COMPETENCY CENTRE

SAP PM DOA/Workflow Functional Specification Document

SAP Module Affected: Plant MaintenanceChange Initiator: Martin WagnerOD Impacted: TFRProduction System to be affected: SAP - 002Reference No: 12035

Document Control

Date Author Nature of changes 01.10.2009 Martin Wagner Creation 17.11.2009 Martin Wagner Updated14.12.2009 Martin Wagner Update09.02.2010 Martin Wagner Workflow update11.02.2010 Andrew Motseta Workflow escalation update 16.02.2010 Martin Wagner DOA update

Document Signoff

Name Role Signature Date Andrew Motseta SAP PM Team LeadMatthys Lundall Project DirectorGerhard Wessels ABAP_Workflow Team

LeadJonas Mahlangu INFRA PM SAP Super

User

SAP COE - Functional Specification DocumentPlant Maintenance Standardisation ProjectAuthor: Martin Wagner

Page 2

Table of Content

1. The Goal of the DOA...............................................................................22. Scope of Work.........................................................................................22. Impact on Business.................................................................................23. Testing scenarios.....................................................................................24. Programs affected...................................................................................25. Estimated Timelines and Priority............................................................26. Users required for testing.......................................................................27. Current Issue – “AS IS”............................................................................28. Details of “AS IS”.....................................................................................29. Details of “TO BE”...................................................................................210. Technical Details...................................................................................2

1. The Goal of the DOA

The goal of the DOA is to improve the current non-compliance to the budget management of TFR depots. The DOA does not mean the financial authority of controlling funds expenditure but is based on the value of the orders and the logical levels for their approval ensuring the following goals:

1. Approval to check budget availability and ensure no over expenditure.2. Check for Quality of the PM Orders to improve the standards of data

captured in SAP.3. Highlight expenditure and expenditure changes from the original budget to

management and senior management.

2. Scope of Work

2.1 DOA ApprovalThe new solution will ensure that the process of DOA approval is implemented when a Maintenance order is created but require material activation as part of the approval process for all maintenance order. The activation of Work Orders is Standard SAP functionality and will be enhanced to ensure that when an order requires activation the original requirement for the planned value is approved. The Labour portion of the approval is excluded from the total value. Also any changes made after the initial DOA approval for the material reservations or/and purchases for material and services get the necessary re-approval if the value overrides the original approved value by plus or minus 10 %. This means that the PM order planned value can increase or decrease by 10% which then require the DOA process to start again. This solution will be implemented across all current infra work Order types in table 1 below.

Table1 Type Order Description

I001 Infra - Electrical Equipment

I002 Infra - Signal Equipment

I003 Infra - Track Equipment

I004 Infra - Capital ProjectsI005 Infra - Potential Claims

I006 Infra - Services to external parties

I007 Infra - Non-Network Activities

I008 Infra - Technical SupportI009 Infra - Mechanical Maintenance


Page 4

I010 Infra - Transnet Telecoms

2.2 Workflow

Workflow will be used to manage the status changes as designed using the user status function of SAP. When a Work Order user status is moved from one level to the next and the Order is saved workflow would read the table that defines the user list for approval and then send the work Order using the standard workflow functionality to the user’s inbox in SAP. If the outlook table is maintained with the email address a reminder is sent to user’s outlook inbox asking user to approve the work order. This is especially important for management not always at their desks. The Workflow must be based on the current P2P workflow solution as used by the business for procurement approvals for PR’s and PO’s.

The workflow for planned DOA approval should include escalation to the higher level in the defined tables if the item is not actioned for at least four hours. For emergency/Unplanned order type I005 escalation time should be one hour.

2.3 Substitution

The development must include the ability to do substitution. Substitution should be controlled by profile whereby the person being substituted will only be allowed to receive PM order specific approval.


Page 5

3. Impact on Business

Picture 1

The requirement has a major impact on the plant maintenance process and will result in some delays during the maintenance process because of human factors like people not available for approval.

Planned Orders (All except I005)

As per picture 1 the Order has been created and the requirements like Stock material, Purchases and Services have been created. The business has approved the budget expenditure for the order and the new budget period is starting. (In some cases the activation is needed before budget approval especially items with a long lead-time items which has the highest priority). The Order now needs to be activated for material requirement.


Page 6

Table 2 for User defined profile for Planned Orders:

As soon as any of the “Levels from MCSU to BUPO” is selected and saved the Workflow for approval according to the value defined is started. The Order total planned values are used to identify which level in the organisation need to approve the PM Order as reflected in a Z table (Table 3 below) in SAP.

Example:

Table 3: Relationship for the approval responsible person(s) per Cost Centre

Cost Centre Level 1 Level 2 Level 3 Level 4 Level 5 Level 6 Level 7

Lower Value R - R2,001 R10,001 R200,001 R 600,001 R 1,000,001 R5,000,001 Upper Level

R2,000 R10,000 R200,000 R600,000

R1,000,000 R 5,000,000 >R 5 000 001

A MCTR-1 MCSU-1 MMAN-1 DENG-1 INFM-2 REGE-1 BUPO

B MCTR-2 MCSU-1 MMAN-1 DENG-1 INFM-2 REGE-1 BUPO

C MCTR-3 MCSU-1 MMAN-2 DENG-1 INFM-2 REGE-1 BUPO

D MCTR-4 MCSU-2 MMAN-2 DENG-1 INFM-2 REGE-1 BUPO

E MCTR-5 MCSU-5 MMAN-3 DENG-1 INFM-2 REGE-1 BUPO


Page 7

Table 4: Profile relationship to value per level for Planned Orders.

DOA Levels

User Profile Code Grade R – Value % Tolerance

Level 1 MCTR Maintenance Controller 0 - 2K 10%

Level 2 MCSU Maintenance Control Supervisor 2K – 10K 10%

Level 3 MMAN Maintenance Manager 10K – 200K 10%

Level 4 DENG Depot Engineer 200K – 600K 10%

Level 5 INFM INFRA Manager 600K – 1M 10%

Level 6 REGE Regional Chief Engineer 1M – 5M 10%

Level 7 BUPO Business Process Owner >5M 10%

The initial process of approval for the MCTR user profile will default and the maintenance controller will be able to approve the PM Order if it falls within his level (0 to R2000) of approval. As soon as the Level is higher than the Maintenance Controllers level the full DOA process will kick-in. As soon as the program has identified the amount and the next Level for approval the program must identify the approver(s) in the Table. The workflow will then root the PM order to the inbox of the identified user ID of the approver and be reflected as an outstanding item for him to approve. If the approver is a Purchase Order or Purchase Requisition approver the PM orders will be included in his total list of approvals. Once the item is opened for approval and on acceptance of the PM Order the user status will be updated and move to the net level of approval. The next Level of approval will be the same as the previous described steps. When the last (this could also be the first) approver has approved the PM Order Planned value the system must now change the status of the user to ‘Approved’ which will now allow activation of the material requirements for the specific PM Order. This means that the order is now approved and the business can commence with release and execution of the work according to the requirement of the PM Order.

If one of the DOA approvers decline the approval at any point in the process the PM orders user status will move to the “Rejected” user status. This means that the program will ignore any previous approval and move the user status to “rejected” and let the originator to move from the “created” to “Awaiting Maintenance Controller” now that his order has been rejected. He can change the order to suite the requirements of the approver. This requirement will be part of the reasons that the approver need to give for the rejection of the PM order to continue back to the originator.


Page 8

Planned Changes after last approval:

The Order can be changed after approval as long as the system status of the Order is created with activation, rejected and/or release. If the Status of the PM Order is Technical complete (TECO) no opportunity for approval will be available.

When a Planned change (See Picture 2) is done to a PM order after the activation of the material requirement the tolerance rule for planned value of the order will drive any re-approval using the DOA tables. The plan changes will create the DOA activation as soon as the order increases or de-creases with more than 10% of original planned value at last DOA approval.

Picture 2

Approval Criteria:

The program must look at 2 options to determine the approval hierarchy. The Main Work Centre must be entered in the PM Order and the Planner Group need to be available on the header data of the PM Order

This means that the DOA table must have 2 criteria that will drive the approval hierarch. Only 1 of the criteria needs to be prevalent to identify the approver(s). The Planned value for all expenses on the order will be used to calculate the value for approval

Example:

PM Order I001 with a Reservation, Purchase Requisition for service and material and a contract item for material will result in a planned cost of R1 000 000. The Main Work Centre is ZZ and its Cost Centre is Y within the defined Cost centre field of the main work centre. The planner group from the PM order is AA and has been completed by the maintenance controller or has defaulted from the Functional Location or the Equipment.


Page 9

Table 5

ObjectsCriteria for

any one of 3 Koos Piet Johan Stephen

Below <Below < R 10,001

Below <R500 001

Above R 1,000,001

R 10,000 R 500,000 R 1,000,000 R 5,000,000 Work Centre CoCe ZZ Planner group AA

Piet and Koos is seen as DOA approvers and will now have to approve the PM order to allow for further processing of the order. Workflow will take the user Id’s of Koos and Piet and will then move the PM Order to the inbox of Koos for approval. The workflow for Piet can only happen when Koos has approved his DOA then the PM order is moved to the next level.

Within the approval process the user cannot approve a level that is not his DOA level which makes the responsibility of each PM Order for approval to follow the hierarchy level as defined in the Z- table.

Unplanned Orders (I005)

The big difference when approving the DOA approvals for EmergencyPM Orders is that the Orders is created after the fact and must only be approved by the maintenance controller for the first DOA approval if the value is less or equal to TWP thousand rand OR Deport Engineer for the first DOA approval if the value is above two thousand rand.

For any changes made to total material costs above or less than 10% the DOA must follow the full approval as used with the planned orders.

The User defined profile for the order type I005 will be the same as the other order types .


Page 10

Table 6 for User defined profile for Planned Orders:

Table 7: Unplanned Orders profile relationship per value per level

First round of approval for emergency orders – before activation and Release of order.

DOA Levels

User Profile Code Grade R – Value % Tolerance


Level 2 DENG Depot Engineer >2K 10%

Second round of approval: for emergency orders – after activation and release when additional requirements is needed and more than 10% of initial approved amount.is reached.

DOA Levels

User Profile Code

Grade R – Value % Tolerance


Level 2 MCSU Maintenance Control Supervisor 2K– 10K 10%

Level 3 MMAN Maintenance Manager 10K – 200K 10%

Level 4 DENG Depot Engineer 200K – 600K 10%

Level 5 INFM INFRA Manager 600K – 1M 10%

Level 6 REGE Regional Chief Engineer 1M – 5M 10%


Page 11

Level 7 BUPO Business Process Owner >5M 10%

Reporting for DOA

A list report for all approvers should be available to view all outstanding approvals for a User Id, Planner group, PM order or group of PM Orders. This would allow the person to run the report to get access to a list of approved, unapproved or rejected PM Orders. Selection criteria like date, Cost Centre and plant must be available.

The normal work order list edit/display report will be used with selection by user status.

BW Report

A Business warehouse report must be developed to combine at a cost centre level the Plant Maintenance planned, committed and actual cost to the Cost Centre planned budget, committed and actual cost at a GL levels for CO orders, Cost Centres and PM orders. This report would help all approvers to be able to define the total available cost per cost centre which in turn will help the approvers to make a call on what orders to approve or reject.

Workflow DOA solution

The workflow design for DOA must be structure is such away that at all levels of approval the standard SAP workflow as based on the current TFR P2P design and using the same function within the procurement design. The steps during workflow must be bases on the save of the PM order.

Step 1: Order is opened and a user status is selected by the creator or changer of the order.

Step 2: Order is saved and the workflow will now kick-in. The workflow must now identify the user as the approver for the cost centre, planner group, the value and as per his approval group.

Step 3: The workflow will move a message to the inbox of the specific user to allow user to approve the specific order. If Outlook solution is set-up for the P2P solution this must be implemented.

Step4: Once order is open the user now can select the next level of approval or reject/approve the user status and save the order.

a. If reject is selected the order originator need to receive a message within SAP inbox to tell him the order need re-evaluation.

b. If approved is selected the order originator need to receive a message within SAP inbox to tell him the order ready for release.


Page 12

c. If next level of approval has been selected the inbox message will be sent to user’s inbox and process will continue as above mentioned.

The workflow need to have the option to allow substitutions for users to approval work but only in an upwards level and not down or sideways.

Workflow administration must be implemented to monitor workflow across all steps within the workflow process. A report is required that will show a view of workflow changes and steps done.


Page 13

4. Testing scenarios

1. Full testing of workflow with relationship to the DOA solution.

Process based and need to be with authorisations

The complete table for levels of DOA approval resources

The Planned and Unplanned process for Maintenance including the workflow of the processes.


Page 14

5. Programs affected

New Program will have to be developing within the Bapi(s) of PM orders; and a table with the resource and approval levels with a relationship of Cost Centres and planner group need to be established.

The business processes will look as follows.


Page 15

Picture 3


Page 16

6. Estimated Timelines and Priority

Table 4

Task Resource Days Complete the functional specification Martin Wagner 1Business Signoff functional specification Change Agent 1Estimate of Developers time Stanley Tsimba 1

Technical Changes

ABAP & Workflow resource - Stanley Tsimba 3

Project Team Member Martin WagnerTransport to Quality Assurance Andrew Motseta 2Testing at SAP CC Elphaas Mgiba 4

Testing with super user

Elphaas Mgiba, Andrew Motseta, Martin Wagner and Change Agent 1

Move to Production Elphaas Mgiba 1

7. Users required for testing Matodzi Muthavhatsindi (Business Analyst) Jonas Mahlangu (INFRA PM SAP Superuser)

8. Current Issue – “AS IS”

Audit Finding for PM Order which allow resources to add cost to orders without having the necessary approval from management and creating new planned orders without the correct approval or validation of funds available in the budget by management.

9. Details of “AS IS”

No DOA approval process exist in the As Is


Page 17

10. Details of “TO BE”Program according to section 4 as define.

11. Technical DetailsImplementation Name : ZPMORDERImplementation Short Text: PM Order validationDefinition Name : WORKORDER_UPDATEInterface : AT_SAVE

Technical details of the unplanned order to be updated after the program have been developed.


Page 18

12035PMSP Functional Specification DOA Work Order Approval Rev 1

Documents

process of doa approval

initial doa approval

approval process

doa process

martin wagner page

maintenance order

pm orders

planned value