Turnaround Scheduling and SAP: Pt. 3
This is the third post on Turnaround Scheduling. Click here to read the first post.
In the first post we introduced the history and options for scheduling in SAP and some of the pro’s and con’s.
In the second post we looked at SAP scheduling capability, its strengths and weaknesses. We also discussed integrating from SAP to external scheduling applications like P6.
In this post we will look into what kind of turnaround scheduling is the best-fit for your organization.
So what kind of turnaround scheduling works best for you?
The answer depends on many factors such as the size and duration of the outage, the degree of repeatability of the work scope, your use of SAP process and master/transactional data.
For companies with small, highly repeatable outages and an extensive use of SAP maintenance and project process, coupled with full use of equipment master data task lists, BOM's and plans; you could schedule in SAP perhaps using a partner solution like Prometheus Graphical Scheduler.
For large plant-wide turnarounds spanning many weeks or months, with a high degree of project work and complex vessel repairs, you will need a third-party scheduling application like Primavera.
The next question is 'should you even bother integrating your schedule with SAP?' The answer to that question depends on the benefit you can derive from the integration investment.
In order to benefit from the integration of SAP PM work order operations in the scheduling tool, you will need to have a full set of turnaround equipment task lists with detailed activity steps, relationship logic and turnaround BOM's. Further, you will need to map detailed scheduling resource codes, Activity Codes and UDF's in a custom table.
If you have all this, and up to date maintenance plans to trigger the creation of the notifications or work orders, then you are well positioned to benefit in the passage of SAP work order operation detail to the scheduling tool. In this scenario you will use the scheduling application to drive dates and resource levels and pass the dates back to SAP as constraint dates on each operation.
But that only takes care of the planning phase, so what happens during the execution phase when progress is being collected, growth work is being identified and schedules are being changed? In reality you are going to need web applications to help the site users perform their jobs in an efficient manner.
Turnaround Scheduling Maturity Matrix
We developed this chart to quickly help you determine where you fit in the scheduling options.
There are 3 options across the 4 quadrants:
1) Only Use SAP for Scheduling
2) Only Use a 3rd Party Scheduling Application
3) Integrate SAP and Scheduling Application
1) Only Use SAP for Scheduling
Companies in this category have an SAP-first ethos that pervades across the enterprise. They have taken time and care to understand and maximize SAP functionality as it applies to their shutdowns and turnarounds.
In addition to core ECC products they have adopted new SAP web apps and bolt-on's that provide much-needed functionality in the SAP product line.
They maximize equipment master data objects such as Task Lists, Maintenance Plans, Equipment BOM's, etc. and their collection of equipment cost during outages is high.
They use notifications to scope the turnaround and the work orders are fully populated with operations defining the detailed schedule steps. They may even extend to sub-operations to further detail the resources.
Overall Network Scheduling is used to control the turnaround critical path and they may have customized SAP or adopted custom web apps to include planning and execution whitespace capability as we discussed earlier in a previous post on the Integrated Turnaround.
However to manage their scheduling in SAP means their outages tend to be smaller and highly repeatable.
2) Only Use a 3rd Party Scheduling Application
Companies in this category do not use SAP in any aspect of the turnaround scheduling process.
They will use SAP Notifications for scoping the turnaround, and will use work orders to plan turnaround materials, but they won't attempt to detail the work order operations or develop turnaround task lists.
Companies in this category focus on the scheduling application to drive the turnaround planning, execution and reporting, with integration to supporting applications where necessary. SAP is strictly a background system providing input to the turnaround and financial / logistics management and does not play an active part in the management of the turnaround.
3) Integrate SAP and Scheduling Application
Companies in this category are advanced SAP Turnaround data users but need the power of the scheduling application to resource level and manage the work.
They have invested heavily in SAP and have fully detailed work orders with task, resource and relationship logic and use SAP to store Turnaround Equipment BOM's.
They will have learned that each application has unique strengths and weaknesses, and have tailored their integration to reflect those.
Additionally they will have solved the known data inconsistencies between SAP and scheduling applications such as the mapping of work centers to resource codes and the storage of activity codes and user defined fields.
The work is planned in SAP then interfaced across to the scheduling application where it is logically linked to external predecessor and successor activities. Dedicated Turnaround Task Lists store the planning data and Maintenance Plans call the work at the appropriate time. Equipment BOM's embedded within the Task Lists store all the materials required (e.g. Gaskets, Studs, etc.)
Conclusion
At Xytalis we are all about the data and less about the toolset. Turnaround teams are project-centric and treat turnarounds as projects. They are correct to do so!
But turnarounds happen to be predominantly maintenance projects and the bulk of the cost of the outage is equipment maintenance cost that should flow back to the equipment master record in SAP.
Considering a large plant-wide turnaround can account for 4 years of plant reliability budget, to not record these costs at the equipment level is an admission that your reliability budgets are inaccurate.
Sadly most turnarounds are stuck in the heroic, get-it-done-at-all-cost mindsets and the ability to think strategically in these situations is low.
The majority of turnaround teams will not consider using SAP for any aspect of the schedule, and this is probably a correct decision.
However for those companies with highly mature SAP maintenance master and transactional data processes, there is sufficient benefit to make the high initial investment worthwhile.
If you are considering integrating SAP with your scheduling application be aware that it is not 'plug-and-play'.
First, there is the high initial software cost and maintenance agreement.
Then there are the mapping challenges, especially around resources and activity codes / UDF's.
Finally you need to train and retain support expertise that can provide second level support to the business.
Whatever scheduling approach you end up pursuing, we hope you find this information useful.
If you have any questions or comments we'd love to here them. Use the comments section in the blog or contact us via our website.
