Context
Refinery supply chains depend on ships arriving at the right time. Vessel scheduling, turnaround time, and resource allocation are connected decisions: change one, and the rest moves. The planning process was manual and hard to compare across scenarios, while demurrage costs and the continuity of biofuel production raised the stakes.
I joined Enilive as a Cloud & AI intern for five months. The brief was to turn that planning problem into a digital platform the logistics team could actually use.
The problem
The goal was not a perfect optimiser. It was a repeatable way to compare schedules, forecast arrival times, understand the trade-offs, and free the team from rebuilding the same spreadsheet. The output had to be explainable enough for planners to trust it.
An optimiser is only useful if the people who run the operation can understand why it chose a route.
Port schedule, turnaround, demurrage risk.
Berth, storage, and production constraints.
Feedstock arrives without breaking the chain.
What I built
- AI and algorithm development. Developed optimisation algorithms in Python to model complex objective functions, forecast arrival times, and allocate resources across vessel scheduling and turnaround.
- Cloud platform. Built the data and application layer on AWS, with a web platform for data management and visualisation, so the tool could run reliably outside a laptop.
- Operational efficiency. Streamlined port schedules to reduce demurrage costs and protect continuity of biofuel production; worked with domain experts to turn operational constraints into model inputs.
- Predictive models. Used AI/ML and advanced analytics to compare scenarios and improve supply-chain resilience.
Result
The platform reduced planning time and improved resource allocation across vessel scheduling and turnaround optimisation. It also brought demurrage and biofuel continuity into the same planning conversation. More importantly, it made the process repeatable: the same inputs could be compared, and the discussion moved from rebuilding a spreadsheet to evaluating the actual trade-offs.
What I would change
I would add tests around the optimiser's edge cases earlier, a monitoring layer for the AWS job, and a simple explainability view that shows why a schedule was chosen. Those are the pieces that turn a working algorithm into a tool a team can depend on.
Notes
This was an internal project. I have kept the description generic and omitted client data, routes, and commercial details. I am happy to talk through the approach in a call.