This is the second part of our series of blog posts on the topic of turnaround planning and scheduling. In Part 1 we covered all aspects related to developing the turnaround schedule. In this post we will talk about turnaround schedule optimization, what we mean by this, and why you should care.
As a starting point, we will assume that the shutdown schedule has already been developed with sufficient detail for most items on the scope, the Critical Path (s) is more or less understood and the turnaround team is fairly confident with this schedule. Obviously, there will be a lot of refinement work and last-minute additions to the schedule as the turnaround start date draws near, but, in essence, the team has a robust schedule covering all the known scope with sufficient detail to start doing analysis.
What is optimization?
Optimization is one of those words that is used all over the place, and it has so many different interpretations that it has basically lost its meaning. In this post, the meaning of optimization is mathematical: finding the maximum/minimum of a function. As with any TA there are different goals that need to be managed (duration, resources, cost) there are a number of different “functions” that someone could optimize for:
-
Optimizing for duration = minimizing overall shutdown duration
-
Optimizing resource utilization = minimizing daily resource variance = maximizing resource leveling
-
Optimizing resource quantity = minimizing total resource count
-
Optimizing execution cost = minimizing execution costs = maximizing resource utilization
Traditional approach to optimization problems
Once the optimization goal or goals are clear, the question of “how to achieve” comes up. The traditional approach is to manually introduce selective changes one by one on the schedule (in Oracle Primavera P6 or Microsoft Project), see what the impact is, decide whether the impact is positive or negative for the desired goal, and move on to the next change. Not only is this a very laborious and time-consuming process, but it misses a key point: a turnaround is a massive combinatorial network of interlinked activities. Maybe one small change in crew allocation to a particular heat exchanger makes sense for that work front, but when combined with some other change somewhere else on the schedule, the outcome is negative for the overall event. Any turnaround schedule has thousands of activities. To think that an individual can mentally comprehend such a complex network and the impact of changes on the network is absolutely delusional.
Given the complexity of this exercise, it rarely goes beyond the following two activities:
-
Filtering for the critical path and debating whether some activities can be done faster with more resources
-
Looking at resourcing for 1 or 2 critical trades and making some small adjustments here and there
This is understandable given the complexity of the task for the human brain and the outdated software that is used for such a task.
As a side note, when discussing optimization of turnaround schedules, we refer to making changes to the schedule with a certain goal in mind. Some may call it “what-if” scenario analysis, schedule acceleration, etc. This is different from the traditional concept of schedule risk analysis. Risk analysis is a different animal altogether where statistical analysis, hypothesis, and assumptions come into play. One could carry out a risk analysis on an “optimized” schedule but the outcome of a risk analysis shouldn´t be considered an “optimized” schedule. At least in the context of this blog post.
A new hope
Given the complexity of the task, humans are not the best-suited creatures to solve this problem. But advanced optimization algorithms combined with Artificial Intelligence are. AI can understand the nature of tasks and whether changes can be made or not. Optimization algorithms can run thousands of scenarios in seconds optimizing for minimum/maximum values and finding the best results.
With software solutions such as Frontline´s Optimizer, this can be achieved in minutes:
Once a schedule is uploaded, the turnaround planner can set the boundaries and constraints for the optimization. These can be stacked so that the outcome is as representative and realistic as possible.
One of our clients, a major petrochemical operator, optimized the schedule of their upcoming turnaround by inputting the following constraints:
-
Only 2 activities on the Critical Path could be modified based on certain criteria, all other no changes
-
All activities of 4 hours duration or less to remain unchanged
-
Scaffolding and mechanical crews are capped at a -40% value from the baseline plan
-
All other resources are capped at their max resourcing values
-
Optimization can modify activity durations and lag between activities if resources are not sufficient
Even with such restrictive constraints, they were able to find alternatives to the baseline schedule that optimized for the team's goals (duration, cost, resources):
In the above graph, each dot represents an alternative schedule and each color shows the optimization goal considered (reducing duration, cost, resource leveling, etc).
Not only is duration reduced, but so are resources and the associated cost. Win-win for the turnaround team.
Still skeptical?
Even if you got this far on the post, you may still be asking yourself what is this so-called AI optimization doing to achieve this. It's conceptually simple and very hard to implement given the massive size and complexity of turnaround schedules:
-
For resource-driven activities, what is the impact on the overall duration, cost, and resourcing of adding or removing resources to those activities
-
For noncritical path activities, what is the impact of resequencing/delaying activities on overall cost and resourcing
-
Basically, change thousands of parameters on thousands of activities and see what the result is for 3, 4, 5, or even 6 criteria, and do this thousands of times!
To provide a tangible example, for the turnaround schedule we previously discussed, the reduction in required resources was achieved by delaying non-critical work as follows:
The graph above shows the resource histogram for mechanical fitters throughout the event. In blue is the baseline schedule and in green is the optimized one. The first resourcing peak happens when the unit has battery limit isolation, decon has been done, etc thus the “mechanical work” window can start. But just because work CAN start doesn't mean that it SHOULD start immediately. By postponing some of the mechanical work far away from the critical path, that resource peak is reduced by 20%. Same towards the tail end of the event.
If like most of us planners, you are a true skeptical, most probably you are telling yourself these two things:
-
“Hey, this is obvious, just move around noncritical work and you get these results”
-
“Hey, this is like resource leveling in P6”
To that, we say:
-
Good luck “moving around” hundreds if not thousands of activities to try to reduce a certain resource demand without impacting negatively other parameters.
- Check this out: Why doesn't resource leveling in P6 / MS Project work
And now, if you got to this point it means that this topic is of interest to you. We encourage you to get in contact with us and test this new era in turnaround scheduling. As one of our clients put it:
“Worst case scenario, you end up with the same schedule that you started with, it's a risk-free tool. Any benefits that Frontline unearths are a cherry on top”
Need to test Frontline with your own eyes?
Contact us, we are offering a completely free demo, tailor made to your needs.
