This is the third post on Turnaround Scheduling. Click here to read the first post. http://www.elitesto.com/blog/turnaround-scheduling-and-sap-part-1-preface In the first post I shared my own scheduling experience that predated scheduling systems, and also discussed my SAP PS Network scheduling background. In the second post we looked at SAP scheduling capability, it's 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 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 QuadrantsWe 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 SchedulingCompanies 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 ApplicationCompanies 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.) ConclusionAt EliteSTO 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.
0 Comments
This is the second post on Turnaround Scheduling. Click here to read the first post. Turnaround Scheduling and SAP - ELITE STO In the first post I explained my own scheduling experience that predated scheduling systems and also briefly discussed my SAP PS Network scheduling background. 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 SAPSAP 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 SchedulingThere 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 almost 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. month-end cost allocations). SAP Project cost management and reporting is a complex subject and 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 DataThis 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.
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 DataThe 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 HomegrownScheduling 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. SummaryTo 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. Preface
One of the most common questions I get asked is about turnaround scheduling, which is fine because I started my career as a scheduler and is a subject close to my heart. Younger professionals call us old, but older professionals prefer to call ourselves 'experienced'. Let us just say that I refer to myself as 'experienced'. To give you an idea how 'experienced' I am, allow me to relate my earliest memories of scheduling with you. It was early 1990 and Madonna was #1 in the music charts with Vogue! I was working at an oil rig fabrication yard in the Scottish Highlands as a planner/scheduler on a contract master schedule for a large oil rig construction project. Back then, before Microsoft Windows had reached the Scottish Highlands, we used a mainframe system called Artemis 6000 to control the schedule. There was no GUI, just a flashing green asterisk on a dark green screen. Every command needed to be known by memory, and it took a long time to learn all those commands. But before you started entering data into the mainframe system, it was necessary to manually draw the schedule out on a large conference room wall. All 2000 activities! First to be added were the key milestones. Normally these had financial payments (and occasionally penalties) attached to them. Our job was to fill-in the detail - add all the infill activities from the contract award milestone through IFC drawings, materials on site, etc. etc. all the way to load-out and sail-away. For a 20-year-old fresh out of college this was an incredible time and I got to learn from some of the best in the business. All the activities would get drawn on the wall using an erasable ink pen (changes and mistakes were frequent), and the relationship logic added. After a few days, the wall would look like a spider's web of boxes and lines, coming and going from the key milestones. Then began the process of calculating the schedule. This was a manual task, involving doing a 'forward-pass' through the entire network. Essentially working from left-to-right across the network, calculating early dates for each activity and then fine tuning the activity durations and relationship leads and lags until all the dates aligned with the key milestone dates. Whilst this activity took a long time to complete, it was the easy part! The hard part was the 'backward pass' which involved starting at the end of the schedule and working backward until the start milestone, calculating late dates, total and free float and determining the critical path. Further schedule tweaks were required to ensure the critical path accurately reflected the true build schedule. It took a week or longer to calculate the backward pass and arrive at the first baseline. I say all this to give younger schedulers an impression of what things were like before Primavera and Microsoft Project became readily available. MSP had just come out, but it was nowhere near ready to handle such a complex undertaking. Only Artemis could manage that. I hear people complain about how long their project plan takes to schedule and I laugh to myself. Times are much easier today but one thing I got that few others get these days was a deep respect for the scheduling process and details. I also developed the ability to visualize the schedule. Something required back in the early 1990's. It is fair to say that scheduling is in my blood and a major reason for my pursuing a career in SAP consulting, which began in 1997 at Shell Expro in Aberdeen. Planner/schedulers in the UK were also expected to manage the project cost reporting in all but the largest projects. In addition to keeping the schedule progress up to date, I had to provide the project cost report to the project manager. Whereas I could issue the weekly schedule reports within one day of the progress cut-off, it took 4 or 5 weeks to get the project cost report issued. Costs would drip in from a variety of sources over the weeks that followed the monthly cut-off date. Project costs were out of date by the time the project manager got to see them. SAP changed all that overnight. Project costs could now be available within a few days of the monthly cut-off, giving project managers accurate cost and schedule data that supported good decision-making. Since 1997 I have been working hard to improve the lives of project personnel through effectiveness gains and efficiency improvements inside and outside of SAP. "SAP can schedule projects" That's the first thing you will hear from a PS consultant, and they are correct! It can. PS Networks have all the components of a scheduling application like Primavera. They have activities, durations, relationships, constraints, resources and all the other elements needed to create a time-analyzed schedule. I have implemented network scheduled solutions to over a dozen customers since 1997. I know this area of SAP inside and out. But there is an old saying 'just because you can, doesn't mean you should' and this applies perfectly to SAP when it comes to scheduling turnarounds and large construction projects. In the last ten years SAP has developed Portfolio and Project Management (PPM) to also manage project activities. I know this area very well, having deployed it back when it was called xRPM and cProjects. PPM is not the right tool to schedule turnarounds and large capital projects either. To be honest - only external scheduling tools like Primavera can handle the complexity, volume and performance of turnaround schedules. And SAP recognized this when they acquired the Enterprise Project Connect (EPC) software back in 2010. This is a good place to end part 1 of this blog series on scheduling. In the upcoming blogs we will look at the options open to companies that use SAP to run their turnarounds but need powerful scheduling capability to deliver them. After such a lengthy career in this field I intend to document my experience in a way that you can relate to and learn from. Frequently I had to figure things out on my own, therefore mistakes were common. My ultimate objective with this blog is to help you avoid the mistakes I made along the way. I also encourage dialog and feedback so use the comments section to ask questions or make statements, etc. I look forward to sharing my insights and collaborating with you in the future. Please check back soon for Part 2 of Turnaround Scheduling and SAP. Turnaround Process and Application Overview and an introduction to WhitespaceThe vast majority of Chemical, Oil & Gas (COG) and large capital-intense companies use SAP to power their core business processes. SAP data plays a major, albeit behind-the-scenes role in turnaround management, and it’s important to know when to integrate with SAP and when not to. In 2021 it’s possible to integrate just about every software application with SAP. The question is: should you? Before we dig deeper into this discussion, lets take a step back and define a high-level integrated Turnaround business process that covers SAP and non-SAP process steps. SAP Turnaround Process StepsSAP offers significant strength in the following areas:
But SAP is not a one-stop-shop for all Turnaround management processes The key objective is to maximize SAP where it makes sense to do so, but not follow an SAP-first approach anywhere else. A good example is scheduling. While you can schedule your TAR event in SAP, we certainly don’t recommend it. SAP Turnaround ApplicationsSAP offers a full suite of applications covering all aspects of Turnaround and Capital Project Management. They’re a mix of core apps (ECC), web apps and bolt-on’s. We have implemented all of them over the last 25 years. But what looks good on a conference room screen does not always translate to what’s best for the shop floor! At best, these tools can work with low-complexity/highly-repeatable outages. SAP solutions for turnaround management include:
Introducing Turnaround WhitespaceWe know that SAP has the core capabilities needed for managing the turnaround equipment lifecycle. We also know that SAP has capabilities that do meet the need but are not the best options (e.g., scheduling). But what is the correct balance of SAP vs non-SAP software that meets the needs of turnaround management at your company? In order to figure this out, first let's identify the processes that work well and the processes that don’t. Those processes that don’t make the cut still need to be provided by other methods. We will call these process gaps ‘white spaces’, so called because they appear as blank spaces in the process map. We are going to break down the turnaround process into six distinct phases:
Each Phase is further broken down and designated as SAP or non-SAP (i.e. whitespace): Now lets take a look at each of these phases in more detail: ConclusionSAP is the most critical turnaround management application from an equipment master data and history perspective but is not the right system to handle the complexities and volume of planning and execution (incl scheduling). Whitespaces are the areas in a process lifecycle that are not addressed by off-the-shelf software. However, this is beginning to change, and solutions are becoming available from companies such as Procore, Toadfly, Prometheus and Mobideo, to name a few. We will look at these applications in future blogs, but for now, focus on optimizing the most critical turnaround application of them all: SAP. About EliteSTOEliteSTO is a niche specialist consultancy focused exclusively on Shutdown, Turnaround and Outage (STO) system integration, design and deployment.
We have combined our process knowledge of turnaround planning and execution with our technical knowledge of SAP, Prometheus, Primavera and the other supporting applications. Our unique value engineering formulas help you calculate the business benefits applicable to your company and can be used to support capital budget requests. We have developed a custom methodology to rapidly move through the entire implementation project lifecycle. We are independent and are not partnered with any software company. This allows us to focus exclusively on your needs. Contact us at [email protected] to schedule a free, no-pressure discussion. This is the first in a series of blogs on optimizing SAP for Turnaround and Project Procurement.
One of the biggest business benefits of implementing SAP is the integrated supply chain, spanning from material demand through purchase requisition, purchase order, goods receipt, warehouse management, goods issue ad finally installation. These benefits are magnified where we see high volumes, high material costs and high risks. Plant Maintenance is a perfect example of this trifecta. Managing the routine and corrective maintenance of a large plant such as a refinery is an incredibly complex operation. Hundreds of skilled technicians, engineers and operators collaborate on a daily basis to maintain optimized operation. Thousands of work orders are generated every year, requiring labor resource, equipment and materials. We take this for granted now, but that wasn't always the case. During my early years of SAP implementation in the 1990's I heard horror story after horror story of things that went wrong in plant maintenance materials management, and I want to recall a couple of these stories here. In one example, a paper mill was about to commence the replacement of the main roll - a very costly piece of equipment. To his horror, the maintenance manager realized they had actually purchased two of these rolls in what can be best described as a 'career limiting move'! Rather than own up to the expensive error, he elected to hide the evidence and promptly had a huge hole dug and buried it. In other examples, warehouses were being filled with surplus materials from closed projects, turnaround materials were being 'taken' by projects and routine maintenance technicians, resulting in delayed startup. The examples are endless and the consequences always the same. And the sad thing is - they are easily rectified. So what are the biggest challenges of turnaround material management? 1 - Turnaround / Project materials are not reserved for the project, meaning they are available to everyone 2 - Project materials are not held as inventory in the system. They are expensed upon goods receipt and recorded in a spreadsheet thereafter 3 - Turnaround / Project Planners order materials through a free text purchase requisition. This is done for convenience, yet turnarounds have a virtually unlimited planning timeframe. 4 - Turnaround materials are not updated, resulting in the wrong materials being ordered. Gasket specs are a good example. The cost and schedule impacts can be significant. 5 - The warehouse is not cleared-out after a turnaround event or major project, resulting in a build-up over time of surplus stock that can become a significant cost impact. In the next blog we will look at solutions to these common problems that are available as standard to customers using SAP to manage their turnaround and project materials. Turnaround and Project Procurement /2 - ELITE STO Controlling the scope of your turnaround is critical to its success. With turnarounds, the onus must be on reducing scope to what is absolutely needed, and rejecting everything that can be done outside the maintenance window.
It’s definitely a case of the straw that breaks the camels back when it comes to turnaround scope control. Unnecessary scope is a threat to the event success. In SAP you will need a priority code for shutdowns and turnaround outages. Notifications and work orders should be assigned the outage priority and that gets them into the scope review process. Regular scope reviews will look at all notifications and work orders associated with that priority and the decision will be taken to accept the scope or reject it. User status is a good option for controlling this process (submitted, approved, rejected). Rejected work should have the priority downgraded immediately. Work orders are the best method to plan a turnaround in SAP but some companies use network activities to manage construction project work. This is fine but I certainly do not recommend implementing network activities if you don’t have them already. Work orders suffice because I do not advocate using the standard SAP scheduling solution in PS. This is probably common knowledge to you but we need to start at the beginning and define the STO Management lifecycle in SAP.
Shutdowns and turnarounds are planned many years in advance. Frequently 5 but as many as 10 years before oil out. At this time it is just a milestone on a Gantt chart and a budget line item. Only when you get close to 18 months to 2 years out do things really start to get going. There is a huge disparity between a small routine shutdown costing a few million and a huge 300 million monster turnaround. It stands to reason that the large event needs a lot more planning. Whatever the size of the event, the first step in SAP should be to create a Revision. There are two ways to create Revisions in SAP. The old way - transaction OIOB, and the newer way - transaction IWR1. IWR1 includes the Revision Type field and that is the one I recommend to use, although OIOB also works fine. The revision should be created as early as possible so that findings from the most recent turnaround can be assigned to the revision before they get forgotten about. This process of properly closing an event is one we will come back to in more detail. When you fly at a high enough altitude, everything appears flat and peaceful below.
And so it is when you view SAP’s application suite for the management of shutdowns turnarounds and outages from the executive whiteboard, it all looks so simple and straightforward. Now imagine being back in the plane flying at 40,000ft when you unexpectedly lose power! Suddenly the ground below is of utmost concern as you start planning where to land. And so it is when we leave the conference room and put on the hard hat and safety glasses and step into the Alky Unit, we see that the slick software we saw on the seventh floor is not so slick anymore, and the technicians struggling to perform their daily actions curse whoever imposed this on them. That was my experience five years ago having spent the previous 20 years mastering the design and deployment of complex STO management systems inside and connected to SAP. I decided to set an ambitious goal - design and build an entire STO process lifecycle using only web apps running on a browser, with no need for any technician or site user to log into SAP. It's been a tough last few years, but with over 3000 users spread across the American continent now logging in daily to perform a billion dollars worth of annual time-critical maintenance, we can safely claim mission accomplished. This blog is my attempt to share that journey with you. I promise to keep each post short but we will will dive into detail where needed, so you too can share the same journey as me, but hopefully with much less difficulty. But first things first. We need to set up SAP correctly to manage the turnaround data. |
AuthorI have over 30 years hands-on developing Turnaround management systems, including SAP, Primavera, Prometheus and many others Archives
March 2023
Categories
All
|