18-03-21 Entry: Delay Suggestion for Overlapping Jobs

Today, our client G posted a good challenge for us:

How Does System Suggests Delays For Overlapping Jobs?

When 2 vessels (RVs) arrive around the same time, and would be bunkered by the same bunker barge (BV A), usually what the user will do is to supply the earlier RV first, and then supply the later RV with some delays.

Once the user keys in the estimated time of arrival (ETA) for the RV, system would generate an estimated alongside timing for the BV. Currently, it's set to 2 hours.

Outside the system, the user will know that delays for the later RV is inevitable. But inside the system, issue arises when the user keys in the ETA for the 2nd RV and then assigns to the same BV A.

Currently, we will display that there is timing clash for that particular BV, but still allow users to assign. The assumption is that the user will later update the alongside timing to a logical one, one that will be after the completion of the first job.

The user, however, presumes that the system will automatically suggest a delay in such case when it was not communicated to them in the first place.

This would usually not cause any issues when it comes to manual assignment and tracking of jobs. it comes when the user wishes to run the Auto-Scheduler to get an optimized schedule.

It throws an error saying that there are some issues with the jobs and the function could not be run. The system doesn't know what issue it is because we've not catered to this edge-case scenario.


While we feel it's the user's responsibility to ensure the logical timings are entered for the Auto-scheduler to run properly, we agree that the system could have done more the inform the user about possible delays and automatically updates the timings when that happens.

The other reason is that it is currently not visually clear on the job list page when timing clash occurs, thus the user assumes that it has been taken care of. Would they have been displayed, the user could follow up to resolve the issue.

So it's one issue cascading to the other.

Proposed Solution

1st part of the solution tackles the issue when the user wishes to assign the job to a BV.

Apart from showing that there is timing clash for that BV, it will also show the earliest alongside timing for this job should the user insists to use this BV.

The user will also be informed of the delay in hours and minutes. The delay duration is important because it our mind can decipher hours and minutes better than having to calculate it when given 2 timings.

Delay in alongside timing suggested to user to allow easier decision making.

2nd part is a bit trickier.

When we were planning the screens for displaying the timing clash on the job list table, we discovered out that there are more scenarios than just having 2 RVs with different ETAs.

What if the 2 RVs have the same ETAs? What if they so coincidentally have the same required quantity?

Eventually, we came up with 4 scenarios:

  1. RV1 has earlier ETA than RV2;
  2. Both RVs have same ETA, but RV1's required quantity is larger than RV2's;
  3. Both RVs have same ETA, but RV1's required quantity is smaller than RV2's;
  4. Both RVs have the same ETA and required quantity.

Scenario 1: RV1 has earlier ETA than RV2

This is easy to tackle. RV2 will be suggested for delay in alongside:

Bay Bridge's ETA is earlier than APL Paris's.

Scenario 2: Both RVs have same ETA, but RV1's required quantity is smaller than RV2's

In this case, RV2 will be suggested for delay because it will be shorter than having to delay RV1.

RV2's estimated time to completion (ETC) will be later because it takes more time to supply a larger quantity, as compared to RV1's ETC.

However, we still provide the freedom for the user to choose otherwise:

Scenario 3: Both RVs have same ETA, but RV2's required quantity is smaller than RV2's

Then the pre-selected option will be reversed: RV1 will be suggested for delay.

Scenario 4: Both RVs have same ETA and required quantity

After some debate, we've decided for it to follow Scenario 2's flow: by suggesting to delay RV2.

The reason is that even though both these 2 jobs are having same ETA, how it's displayed on the job list table is by which job was added into the system earlier.

Constraints

What was left out from this problem statement is what happens if the user adds in a job with an earlier ETA, one that will overlap with the later job when assigned to that same BV that's been assigned to it.

We will think about this scenario next, while we send this proposed solution off to Client G for their feedback.