The R4 Project
Background
Over the years, we have been collecting a lot of real data from a few big hospitals who use our products - Linen and Dispatcher. And for a long time, I have been dreaming about mining this kind of big data to help improve our customers’ operations and to step closer to the ultimate goal of ours - “To help customers become better decision makers”
This may be a good time that we can start doing something with this by collaborating with fresh-minded students and universities. Although the goals can be adjusted but the intention is still to use the data to answer some questions nobody has asked before. Follow me.
The Better Version of Dispatcher // Dispatcher 2.0
Why Dispatcher? What’s wrong with Linen? Nothing but I think Dispatcher is a better showcase that can link up many big data with real process improvement. It is a great example in which we can look back in the past to understand our customers’ performance, use historical data to optimize real-time productivity and even predict what to happen and suggest a proactive plan.
Understanding What Has Happened
Most of the time, data visualization works with historical data to help us understand more about what has happened. Data turned information and knowledge can enlighten us to think about how well we performed and in which area we could have done better.
The Current Simple Dashboard
The idea of the current dashboard is to help managers see real-time numbers (Job by Status and Porter by Status) and operational trends of the porter team.
| Graph | Description |
|---|
| No. of Jobs | To see job trends in the last 7 days |
| Time of the Day of Jobs | To see peak durations of the day |
| Duration of Jobs (mins) | To see how long most of jobs were |
| Average Jobs per Porter | To see if porters took reasonable no. of job per day |
Is it too simple? - Maybe. It works as it is but it can be a lot better with data. If we look closely to the current dashboard, they provide so little knowledge to the managers about their teams’ performance. The “No. of Jobs” says almost nothing about the fact that their staff were doing OK. The “Time of the Day of Jobs” doesn’t indicate how long the jobs were taken from start to finish. Our dashboard must bring more values to the customers. We need more.
The Enhanced Dashboard - 1
What if we can deliver more to help our customers (managers) understand more about what is happening on the ground? We should introduce “Process Efficiency” dashboard to break down a big process into smaller steps and compare each of them with past performance - be it yesterday’s, or even last hour’s. At least, this gives the managers something they can take action with. For example, if they see the average lead time is 19% worse than the last hour, they may deploy more staff to improve the service level. This kind of data presentation should inspire actions.
We can do better with insights. A time series concept should be employed here to visualize operating trends. No of jobs, Delay jobs, Average jobs per porter, and more are there to compare the current stat (today) with a selected previous period (yesterday).
Then, there can be another kind of graph that shows both time series and performance targets - Average Ontime Percentage for instance. Not only does it shows a time series graph, it also draws a dotted line to help the managers see if how well their teams met a performance target.
The Insight Dashboard
The next one is interesting. It is a bar chart that represents a distribution of factors throughout a predefined spectrum. The “Leadtime Distribution by Minutes” for example, its X-axis shows a set of durations for jobs to be completed. It starts from 0-10 mins, then 11-20, 21-30, 31-40, and so on. Its Y-axis plots numbers of jobs to which were completed in each duration. For instance, there were 468 jobs completed within 31-40 minutes, which was 45% of the total jobs performed in the last seven days. When we add a comparison whether toward a performance target (leadtime target = less than 35 minutes) or historical data (43% of the total jobs performed last week were completed between 41-50 minutes), the managers are equipped with a good analysis that they can design a better operational plan to improve their teams’ performance in a near future and monitor if the new plan effectively brings the leadtime down even further.
To summarize, the first step for analyzing the data we have collected is to help users understand what has happened. The expected result from this task is to implement a better dashboard system, which looks back into the past and visualize key values that are related to general stats, operational performance, and so on.
Making a Smarter Real-Time Decision
The second level is to work with present through the now features. We need to dig deep to find knowledge that can help users answer the following questions:
Should I assign a new job to a porter now or should I wait a little longer for another porter who will be finishing his job in a few minutes?
This question seems simple but it is very complicated to answer from the system’s point of view. Let’s start with the fact that the current algorithm to find the best fit porter for a job is to look at who is the nearest to a pickup point. So, it looks at who is available first and measure how far each available porter to the pickup point and pick the nearest. At a glance, it looks the most effective way to do this but if we consider this a bit deeper, we can still see a flaw.
What if another occupied porter (Porter B) who is a lot more closer to the closest porter (Porter A) on the available list is about to finish job in the next two minutes? Will this porter be a better choice to accept this job?
What do we need at hand in real time in order to answer this question and make a better decision?
- Do we know with an acceptable level of certainty that Porter B is going to finish his job in less than two minutes?
- Do we have enough knowledge about how long (in terms of duration) Porter A is likely to take from his current spot to the pick up point?
- What should be our fall back plan if Porter B doesn’t finish his job as expected?
Let’s assume we know all the answers, here is what we should do. If we are certain that Porter B is going to finish on time (within less than two minutes) and it will take Porter A at least five minutes to arrive at the pickup point, we should be waiting for Porter B to finish his current job and take this one. However, if two minutes has passed and Porter B is still on the job, we need to re-calculate who is the next most fit for this job.
Another fall back idea, which may seems harsh, is to give the job to Porter A first. Let him walk to the pickup point while Porter B is in a short list. Once Porter B finishes the job, the system will decide at that moment if it should re-assign this job from Porter A to Porter B.
From the data science’s perspective, we should be able to predict how long Porter B needs to finish his job. It involves many factors; type of job, pickup and drop off locations, time of day, equipment required, past performance of Porter B, etc. It is very challenging task.
Where should porters go and wait for a job?
Imagine you are on Grab. Would you want to know where the jobs are? Definitely, because you want to be near the jobs. More jobs, more money. Same holds true with porters.
This feature, if we can implement it, will be beneficial not only for porters but for patients and hospitals too. The key idea is to suggest porters periodically where they should stand to ensure he gets more jobs.
In order to do that, we need to be able to predict where the porter service be required at what time based on the past records. If we can do so, we should be able to attract (suggest) porters to go and wait at a location nearby to increase a chance to get a job.
We must make a good balance here too. We cannot suggest a majority of porters to be at some high-demand locations and leave other locations unattended. This means that not all porters get the same recommendation. This is based on the current location of porters, time of day, type of jobs and more.
What we are trying to implement here can be, as I see it, called the “dynamic resource clustering”. With real time information, we can design a flow of porters to provide the best possible service. Let’s imagine that with an intelligent algorithm, the system starts to lead 10 porters to a zone of interest (building, floor, department) at 10.00 AM and keep the 10 porter there until 11.30 AM to only serve jobs created from that zone. In the afternoon, these 10 porters may be brought to another zone serving another high-demand locations.
Instead of a fixed cluster, we are going to introduce a new way of optimization with data, machine learning, and real time tracking technologies. This will make our solution so mobile, flexible and responsive. So cool!
To summarize, this level is to make the whole operations as optimum as possible with real time and historical data. An expected result is to apply this to the current Dispatcher through our Optimizer and Mobile App.
Forecast and Prepare More Effectively
The third level is a promise land, where the system can recommend how to prepare the resource in the best way to handle future’s workloads.
I fancy this as an advanced simulation tool. It should compare, predict and visualize the demand and supply side and see how it affects key performance indicators. We may start with a demand heatmap (day of week and time of day).
A Date and Time Heatmap
Next is to dig deep into each box to understand what results were and what affected such results. As an example, if we look at Fri at 9, we managed to completed 88 jobs within that hour. Can we dissect it to be more comprehensible like this?
The Workload Heatmap
Knowing only traffics is not enough. We should be able to create a heatmap for the daily workload as well. The workload can be calculated as follows:
- Get the total number of porters being on the shift at that particular hour. eg. 38 porters
- Calculate a total serviceable minutes for that hour eg. 38 x 60 = 2280 minutes
- Find a number of fulfillable jobs at 100% workload eg. 2280 minutes / 23.4 minutes per job = 97.4 jobs per hour
- Count total jobs created in that hour eg. 92 jobs
- Predict the hourly workload for that particular hour eg. 92 / 97.4 = 94% in the Green box
This means the current workforce can cope with all jobs created at that particular hour. What follows is as interesting. All the factors (no. of jobs, no. of porters, locations of jobs, etc) affect three main KPIs.
- Assign time (the duration to which a job gets assigned to the next available porter)
- Respond time (the duration to which a porter arrives at a pickup location)
- Total time (the duration to which a porter completes a job)
By theory, if we have more supply (more porters) the KPIs will improve. On the contrary, if we have less supply, everything will start to decline.
The key idea here is to predict, simulate and recommend. Based on the past information, we should be able to predict how many jobs will be created tomorrow in each hour. Throughout the day, we can then visualize the two heatmaps above - a comparison between the No. of Jobs and Staff Workload.
| Time | No. of Jobs | No. of Porters | Workload | Respond Time | Total Time |
|---|
| … | … | … | … | … | … |
| 9.00 | 60 | 20 | 117% | 6 m 13 s | 23 m 24 s |
| 10.00 | 75 | 23 | 144% | 11 m 32 s | 26 m 18 s |
| … | … | … | … | … | … |
It would be great if we could simulate scenarios where No. of Porters is changed. What if we add three more porters at 9.00, what will happen with the workload, respond and total time.
| Time | No. of Jobs | No. of Porters | Workload | Respond Time | Total Time |
|---|
| … | … | … | … | … | … |
| 9.00 | 60 | 23 | 101% | 5 m 25 s | 20 m 11 s |
| 10.00 | 75 | 28 | 117% | 9 m 40 s | 22 m 51 s |
| … | … | … | … | … | … |
We can do this to have the most optimum workload (as close to 100% as possible). See the table below.
| Time | No. of Jobs | No. of Porters | Workload | Respond Time | Total Time |
|---|
| … | … | … | … | … | … |
| 9.00 | 60 | 24 | 98% | 4 m 40 s | 18 m 33 s |
| 10.00 | 75 | 32 | 102% | 9 m 08 s | 21 m 10 s |
| … | … | … | … | … | … |
This will help a manager plan her service plan in the most optimum way. She may decide to deploy 24 porters during 9.00 and increase her workforce to 32 porters from 10.00 onwards. This is great.
To summarize, we aim to create a new web application designed specifically for managers. It will work as an intelligent assistant to help the managers plan their future operations better.
An Execution Plan
We definitely have big data from one of the biggest hospitals in Thailand. We are looking for ones who are inspired by this, and possess some knowledge about statistics, data analytics and computer programming to join our small-but-nimble team.
| Task | Duration | By |
|---|
MUST HAVE
- Get to know the system
- Prepare historical data
- Design data theory | 1 month | Interns |
MUST HAVE
- Model the data
- Build data dashboard
- Present results to customers and partners | 2 months | Interns |
MUST HAVE
- Create data heatmaps
- Simulate scenarios
- Present results to customers and partners | 1 month | Interns |
MUST HAVE
- Build a new web app for manager | 2 months | Dev team |
OPTIONAL
- Design algorithm for real-time job shuffling
- Design algorithm for dynamic resource clustering
- Present results to customers and partners | 2 months | Interns |
OPTIONAL
- Implement real-time optimization features into Web and Mobile App | 2 months | Dev team |
It is a big task with a lot of unknowns. But this is the beauty of doing creative works. We will work as a team with me as a strategist and consultant to deliver something truly amazing (if we succeed) together. We will cross the line nobody else ever did before together. Exciting time!