Turnaround Scheduling and SAP: Pt. 2
This is the second post on Turnaround Scheduling. Click here to read the first post. Turnaround Scheduling and SAP
In the first post we discussed the history of SAP scheduling and Some of the options / pro’s and con’s.
In this post we will start by defining the scheduling process inside SAP, and introduce some of the applications that support it.
Then we will define the scheduling process outside SAP, and look at the integration options that exist today as commercial (off-the-shelf) software.
It is important to realize that there is no right way or wrong way to schedule turnarounds from a technical / application perspective.
Each company has evolved over many years to the position it is now in. Some will be very happy with their current solution and others will be frustrated.
The purpose of this post is to help decision makers understand the process from an independent perspective so they can help steer their company in the right direction.
Project Scheduling Within SAP
SAP uses the Project System (PS) module to provide the scheduling capability. The Overall Network Schedule supports a critical-path through the turnaround execution.
Standard integration between the PS Network Activities and PM Work Orders allows the work orders to connect to the activities and inherit the schedule dates of the parent activity.
The time analysis aspect of the PS Network works just like any other scheduling software - the early and late dates, total and free float are all calculated as expected however transaction code CN24N needs to be fully understood.
It is easy to get confusing results because of the complexity of the transaction so be sure to practice using it before the event.
Finally the relationship between the network activities and WBS elements is controlled through configuration and can have a negative effect on the basic dates. Use scheduling option 'Bottom-up' or 'Strict Bottom-up' to ensure the network dates drive the WBS dates.
SAP also provides a little-known but powerful application called the Maintenance Event Builder (MEB) that connects the Revision with the Notification, Work Orders and PS WBS / Networks to provide a quick scoping and planning solution.
MEB is a great way to quickly identify and build scope then plan and schedule it using the built-in Gantt scheduler, but it is limited to smaller packages of work rather than major plant-wide turnaround events.
Standard Work Center capacity planning is very production-centric and is not well suited to project resource management, so SAP have provided bolt-on applications like Multi Resource Schedule (MRS) to provide enhanced resource management capability.
Furthermore, work order operations and network activities only support one resource so if you want multiple resource on an activity you are forced to either detail the operations / activities or add sub-operations / activities.
Resource management is definitely a weak spot in the SAP capability. Another weak spot is Turnaround project Earned Value Analysis (EVA). Project System does include powerful and configurable EVA functionality however the minimum reporting period is one month; yet Turnarounds need a once-daily reporting period or even shift-based progress reporting.
SAP Partners offer scheduling bolt-on applications such as Prometheus's Graphical Scheduler which work well for smaller, more repeatable outages but are not so effective for large complex plant-wide turnarounds.
We can summarize SAP's built-in scheduling capability as being adequate for smaller, highly-repeatable outages but is not recommended for major plant-wide turnarounds.
These large events will need a third-party scheduling application like Primavera and the question becomes one of the degree of integration (if any) between SAP and the scheduling application.
Third-Party Application Scheduling
There are many commercially available scheduling applications that integrate with SAP, but the most popular is Primavera.
We implemented the first bidirectional integration between SAP PM / PS and Primavera back in 1997 for Shell, when it was called P3 and ran on a Btrieve database. (Hard to believe it was over 25 years ago. That middleware application was called Primaplan Flint and it managed all the complex transformation rules that are required when moving vast volumes of data between applications.)
The toughest part of this integration is not with the data or technical migration but aligning the user groups in deciding the functionality within each system.
Most common is the schedulers desire to maximize functionality in the scheduling tool, at the expense of SAP. Project Costs are a good example of this.
Primavera has powerful project cost management capability that can be used in the planning and forecasting of project cost, however SAP is the source of all costs and should remain so. By all means send costs across for reporting purposes, but don't try to use the scheduling tool as the primary cost management application. You are almost certainly guaranteed to end up with discrepancies that are difficult to explain away (e.g. overhead cost allocations).
SAP Project cost management and reporting is a complex subject worthy of a dedicated blog.
Similarly, SAP has all the scheduling attributes required to calculate early and late dates, total and free float. But we don't want two separate sets of dates for the same work order operation.
So we need to take a firm position and disconnect SAP scheduling for all work orders that are scheduled by the scheduling application.
If you try to get too clever with the integration flexibility you will end up with very confused user groups (cost controllers, planners and schedulers).
When integrating SAP and a scheduling application it is always best to focus on simply addressing the functionality gap, or 'whitespace' missing from SAP.
Perhaps as your experience and maturity rise you can start to expand capability, but to over-design the interface on day #1 is setting up for an almost guaranteed failure.
Whilst the integration between SAP and the scheduling application can be made to look natural and easy, it is far from both. We like to think of it as 'forcing a square peg into a round hole'.
This is not a project you want to consider going it alone. Spend the money and hire a senior integration consultant from the middleware vendor. These people do this for a living and make it look a lot easier than it is.
The scheduling integration can be broken-down into 3 main groupings: Activity data, Resource data and Relationship data. These sections can be further broken-down, for example Activity Data can be separated into Header data, WBS, Activity Codes and User Defined Fields (UDF)'s
For the purposes of this article on turnaround schedule integration we will focus on Plant Maintenance work orders, but the same rules apply for PS Network Activities.
Activity Data
This covers the work order and operation data mapping to the schedule activity, and vice-versa.
The key thing to understand is that the schedule activity mapping occurs at the work order operation level, but we still want to see the work order number and description in the scheduling tool for grouping purposes - so these fields will need to reside in Activity Codes or UDF's.
Activity data mapping becomes a balance of the order header data needed (Order Number, Description, WBS Element, Revision, Order Type, etc.) and operation data (Operation Number, Description, Duration, Control Key, etc.) as there are a limited number of fields available in the scheduling applications.
The WBS is a field that generates a lot of confusion because the SAP WBS and the scheduling application WBS are not the same thing. The SAP WBS is a PS module object used in the breakdown of project cost and is more accurately described as a Cost Breakdown Structure (CBS) object.
Whereas the scheduling WBS is a true Work Breakdown Structure element. One of the bigger integration challenges is in knowing where to position the activity in the scheduling application WBS and to do that SAP must know enough about the schedule WBS to derive its location.
Another consideration of the activity data integration lies with the scheduling applications Activity Codes and User defined Fields (UDF's). These fields are crucial to the schedule and must be populated, ideally automatically by the interface.
The question is then one of how much of the scheduling activity data fields does SAP know? For turnaround schedules, this is surprisingly large, as the work order meta data (FLOC, EQPT, Classes, Revision, etc.) store a lot of good information that can be read by the interface in the process of deriving activity fields.
The final field mapping specification for activity header data will be a complex document.
In addition to the actual data mapping between SAP and the scheduling application, the business rules governing the field mapping and the behavior of the update (initial update only vs one-direction vs always update) are factors that must be determined.
Resource Data
This covers the mapping of SAP Work Center data to scheduling resource codes.
Once again, the devil is in the detail. SAP Work Centers typically exist as high level crafts whereas scheduling resource codes are much more detailed - typically down to the vendor / craft level.
Now its certainly possible to create vendor-specific work centers in SAP, but vendors change from event to event and sometimes get changed mid-event! SAP work centers are typically inherited from the Functional Location or Equipment Master and are set-up with routine maintenance in mind.
Another challenge with resource mapping lies in the fact SAP work order operations only support a single work center assignment whereas scheduling applications support multiple entries.
Now you can get round this by creating sub-operations underneath each operation, but this significantly complicates things and doesn't address the mismatch in resource detail between work centers and scheduling resource codes.
The one good thing going for turnaround schedule integration is that a large part of the schedule primarily revolves around the 'open-clean-inspect' of major equipment items. So the repeatability of the core activities is very high, and the only real variable is the vendor (resource) performing the work on site for that event.
Opportunity does exists to enhance the resource integration to store generic (i.e. no vendor) resource codes and then to build the resources during each event. This enhancement would exist outside of SAP (e.g. as SQL code that the middleware program interacts with). This way we can automate the resource assignment process for each turnaround event, at least for repeatable equipment items.
Relationship Data
The third and last grouping is by far the easiest. Relationship data includes the logical links between the work order operations and includes Relationship Type (FS, FF, SS, FF) and lead/lag duration.
If you use SAP Equipment Task Lists to store the relationship data through the operations, this is generated in the turnaround work order and can then be mapped to the scheduling application as internal logic.
However after the initial mapping from SAP to the scheduling application, you need to accept that the scheduling application becomes the owner of all relationship data. So the logic only pushes to the scheduling tool with the initial data pass, and thereafter is ignored.
Failing to do this will result in mismatches in the dates between the two applications. As long as you follow clear business rules, the relationship data map is an easy one to setup.
Middleware: Custom vs Homegrown
Scheduling middleware is expensive, and there is a reason for that. The investment made by the software companies is deeply buried within the application and is not visible.
Performance is not an issue with a 10,000 activity schedule, but is always an issue with a 100,000 activity schedule. The application API's need to be carefully managed to support large volumes and the last thing you need is for the middleware to freeze or crash during a schedule update.
Over the years we've witnessed companies making the fateful decision to develop their own interfaces using the available API's. These projects follow a typical lifecycle. Initial results are good, with data moving freely between SAP and the scheduling application, but then things start to go wrong.
Either the performance is not there, or the mapping rules do not support the business requirements and the developers show little desire to build them. Costs grow and frustration mounts and eventually the project gets cancelled.
Undoubtedly there are companies using home-grown integration to manage their schedule interfacing, but the use cases are likely much simpler than those offered by the middleware vendors.
Summary
To summarize this second post, SAP has powerful scheduling functionality but it is not robust enough to manage large plant-wide turnarounds. The resource management is particularly weak.
There are third party middleware solutions available that quickly and reliably move large volumes of data between SAP and the scheduling application, but they are expensive and require great care in setting them up.
Now its time to assess your organization's turnaround scheduling needs. In the next blog post we will address the three scheduling categories that companies typically fall under so you can decide the type of turnaround schedule you need.
