Scheduling equipment and people for testing in labs can be a time consuming process. Most of the time, it’s a simple task, but it somehow still takes a ton of time out your day. It always involves a lot of back and forth between screens (hopefully you have at least two) checking availability between the person assigned and the equipment assigned. It doesn’t have be such a manual process does it? Isn’t helping automate some of our mundane tasks are what computers are good for?
The basic idea of how the scheduling will work is for every task you define the following:
- How long will this task take?
- Which technicians are capable of working on it?
- What equipment do we need for this task?
Based on the above information, LIMSey will automatically look at the schedule for the resources you’ve selected and automatically schedule it where there’s open time in all the required resources. Of course, as priorities change, or other tasks from other jobs take longer than expected, LIMSey may change the assignments to other resources who have earlier availability.
The basic concept above is just that, basic. In practice there is more to ensuring that the scheduling is effective while remaining simple and easy enough to use. That last point is very important. If too complex to use, it doesn’t matter how good it is since no one will use it.
The first additional detail is that there are really two different “times” to each task. If a task takes 3 days, that’s usually how long the equipment will be used for. For the person assigned, the time needed is a different story. For example, a long running task that takes days or weeks of equipment time generally doesn’t take the same amount of time for a technician. In practice, they may have to check on the task an hour a day. They check to make sure it’s still running properly, verify it’s still within spec, enter it into a log, then they work on other tasks for the reminder of the day. For this reason each task has two timing entries:
- Daily technician time needed. This is how much time each day the technician has to “work” on the task. This is usually an hour or two a day.
- Equipment time needed. This is how long the equipment be occupied for, which is generally from the time the task starts to the time the task actually ends. This could be days, weeks, months, or more.
The second detail is rethinking how tasks should be defined. From the above, you may be thinking that “daily technician time” is a bit too simplistic. Some tests have long setup and teardown times, and the “daily technician time” is different at the beginning, in the middle, and at the end. You’re right, so in those cases, it’s better to create three separate tasks.
- Task setup. This might have 8 hours of equipment time AND technician time since this is how long it takes for the equipment to be setup.
- Task running. This has the one hour daily technician time and 3 weeks of equipment time.
- Task teardown. Like the setup task, this might have 8 hours of equipment time AND technician time too.
Breaking down some tasks this way not only helps clarify the timing of resources, but it’s also the way a lot of technicians already think about these tasks in their head.
The final detail is task dependencies. Some tasks within a job can run parallel, while others have to wait for previous tasks to finish. For this portion, our goal is to make it quick, easy, and very intuitive to setup these dependencies.
Estimated Release Date
Our targeted goal for the release of this automated scheduling is September or October of 2023.