It may be time to pull out the old Milo Optimisation Post. It was trivial 5 years ago and it’s still intended as funny rather than serious, but the sad, sad thing is that the lesson still hasn’t been learnt in our airports and probably a range of other entities.

The security check point is a bottleneck. More specifically, the number of scanners open at certain rush times isn’t enough to cope with the arrival rate of passengers at the check point.

The bottleneck is the small number of open scanners. The bottleneck could be fixed and throughout increased by having more scanners. No amount of hurrying up the process to inspect tickets will change the bottleneck. No amount of directing people to stand in queues at each scanner will change the rate at which people go through the scanners (as long as there is always a queue at each of them). None of this changes the throughput of the sytem.

But it does mean that there are extra people employed to inspect tickets and extra handlers directing people to queues – these employees could presumably operate an extra scanner and massively increase throughput. This might in turn create a bottleneck somewhere else, but if that happens it shows that throughput has already been increased. It also presents an opportunity for the next stage of optimisation.

2 Replies to “Bottlenecks”

  1. But are the extra employees and hardware worth the time they’re not necessary, i.e. during non-rush hours. You still have to pay those employees and there is a break-even point where their overall cost is worth the benefit. Same logic goes for why SARS, Computicket, etc can’t just throw in *more* hardware to handle the few times they need to cater for a Lady Gaga ticket sale.

    1. No sure, I’m not saying more employees (ACSA costs are already amongst the highest in the world). What I am saying is, move them to help with the bottleneck where they can actually increase throughput rather than use them to speed up the processing of people into the queue at the bottleneck!

Comments are closed.