Automation blues

System failures often lead to comical situations. I was in a queue at the office canteen counter, having picked-up my pretzel and orange juice for breakfast, when the computer that was used for billing stopped working. It simply “hung”, and then the system restarted (I could see Windows XP starting up). The lady at the counter, trained at nothing more than pressing large icons on the touch screen, had little idea on how to proceed. As the queue grew longer she turned progressively jittery, until a colleague came to her rescue by suggesting we all move to a counter nearby.

The queue moved (it was a bit like a train of people moving in unison, each one with their bananas, croissants, apples, sandwiches, fruit-salads, juices – the Breakfast Express, if you like) and the lady came behind this new counter, only to find that this system was not turned on at all.

It took a while for the counter to start functioning again, and by then the queue was so long that the security guard came around to see what the problem was. Some people were amused, some were not. The poor lady at the counter was still bemused.

It is a tricky thing, automating processes like these. To the end user – people buying snacks at a counter – it seems quite unnecessary: the transaction is very simple and hardly seems to justify anything more than a cash register at the counter. Why have a computer here? The reasons are not so apparent: there may be a need to store all transactions digitally (as a company policy) and it may also be useful to gather statistics (to plan inventory).

While it is nice, in general, to have a manual process that works as a backup for the automated one, this becomes quite crucial in areas where the end user sees no direct benefits of automation. You may tolerate a system delay at an airport booking counter (it is difficult to imagine a world without computerized ticketing systems), but if the same happens at a bakery in your neighborhood, you’d seriously consider baking your own bread.