The importance of experience

Three lessons were drummed into us as students of O.R., and I have tried to pass them on to my students.

(1) do not analyse numerical data by machine before you have looked at that data by hand; the analyst needs to have a "feel" for the numbers.
(2) do not assume that the decision-maker who is identified for you by the management is actually the decision-maker; somebody on the spot may actually take decisions which the management do not know about.
(3) observe as much of the system as possible, first hand. Walk the line!

On our trip last week to South Wales, the importance of number (3) became clear. But I doubt if the organisation actually has an O.R. team, but they needed O.R. advice.

We went out to an inn for our evening meal. Like most inns serving food, there was one queue for ordering food, and another for drinks. Food orders were passed to the kitchens and waiting staff, and drinks, of course, were served at once. However, on Wednesday evenings, it was Curry Night. If you ordered a curry at the food counter, then you could have a drink included in the price. This meant that the young lady at the food counter had to leave her place and collect the drink that you had ordered from her. Hence she had to do an increased workload on an evening when there was increased demand at the food queue. Customers for food had long queues, while there were no queues for drinks. Service time could be speeded up in various ways ... passing a token to the drinks bar ... having an extra person to serve at the food queue, all or some of the time. It could also be reduced by having a printed list of what "free drinks" were available, rather than for the staff to have to recite them. All of this could have been noticed if someone with authority had actually observed the queue process, rather than assume that the normal system could cope on the Curry Night.

Result: two very nice curries, reasonable drinks, but lost profits because we didn't go back to the long queue for a sweet.

Back to the blood donor session

I have written about the sequence of queues in a blood donor session earlier. Yesterday my appointment was later in the session and the system had reached a steady state; so I could observe where the bottlenecks were in the system. I had to wait a long time for the initial medical assessment, but I think that this was because the person in charge was operating a sort of feedback so that he didn't have too many people waiting at the next queue -- or too few either. What surprised me was that there was a long delay once I was on the couch; but I realised that it was a combination of rare events which meant that the nurses were busy elsewhere.

I wonder whether anyone in the blood donor service in the U.K. -- or elsewhere -- monitors where there are bottlenecks in sequences of queues. Not the long delays between doctors and hospitals, but the process within one system?

O.R. at the blood donor session

When I taught queue models in O.R. at the university I encouraged students to give blood at the regular donor sessions held on campus. It was a good example of queues in series -- arrive -- register -- health check -- give blood -- refreshments, and I urged the students to observe and consider how the system could be improved.

Yesterday when I gave blood, I arrived before the system had reached a steady state and there was little delay. Wonderful! As I lay on the couch, it was possible to watch the donor next to me and the machinery used to shake the blood. The plastic bags holding the donated blood rested on a tray which was programmed to rock. What was odd was that the rocking was intermittent. Up, down, up, down, pause. Repeat. Someone had designed it so that it rocked twice and then paused. Why? Was this an optimal way of rocking the blood? Someone had designed the mechanism, and that design had involved finding a numerical solution to "Rock N times, at rate R per minute, pause S seconds"

More about queues

This is simply a link to a wonderful account of how Disney and other theme parks in the USA manage their queues.
How do you disguise the fact that you are in a queue which zigzags in a snake? You make it zigzag through something that is part of the attaraction. Read about it here.

Queues, psychology, and collapsing websites

One of the problems of queues which involve people is to forecast when and at what rate the customers will arrive. Recently, the UK supermarket giant, Tesco, made a spectacular mistake in the run up to the Christmas rush and the holidays. Here's the story:
---------------
The Tesco Big Christmas Exchange
Back in November 2010, Tesco announced it was launching a Big Clubcard Voucher Exchange. Lasting four weeks, it gave collectors of Clubcard points the opportunity to double the value of their vouchers on a large range of non-food items, ranging from wine and computers to Christmas decorations.

A similar scheme was launched earlier in the year. However, Tesco trumpeted the fact that this time the scheme had been revamped, so now customers would be able to exchange their vouchers online.

But it went wrong

The scheme was launched around the time that most customers received their November points statement, early in November. If you wanted to double up your vouchers, the closing date was Sunday 5 December.

Clearly Tesco expected the bulk of interested shoppers to take part once they got their statement through, rather than leave it to the last minute. This was very much a mistake, as news reports and Internet message boards are awash with tales of shoppers facing enormous queues to exchange their vouchers, only to give up and try and do it online. With predictable results, the Tesco website collapsed under the weight of so many users.
------------------
Yes, it was bad understanding of psychology, leading to not enough provision of servers for the customers. There is a great deal of literature about call centres and the behaviour of customers, so someone should have been aware of the likely rush at the end. And, I suspect, there should have been some monitoring of the rate of redemption of the vouchers, which might have given advance warning of the changing rate of redemption. If only 10% of the customers redeemed their points in the first half of the offer, then it might be foreseen that there would be a great demand in the second half.

The greatest invention for queues

Twice, in the last month, I have been caught in unorganised multiserver queues. In one, long lines formed for each server, and people at the back jockeyed as they watched thelines move. Those in the middle simply were stuck in the queue they had selected.

In the other, people milled around until there was a free server, and by mutual agreement identified the leading person in the line.

Both queues could have been improved by the use of snake barriers, as used in theme parks and at many airports (but not in Madeira, the first place I noted). Surely these are one of the great inventions of queue management?

EURO XXIV (EURO24) in Lisbon

I spent some time in Lisbon this week for the 24th EURO conference. EURO is the association of national OR societies from Europe (plus those in Israel and Africa). It was based on the university campus, running from the evening of Sunday 11th July and ending late on Wednesday 14th July. For various reasons I couldn't stay for the last day.

As usual, I have come away from the conference with mixed feelings. It was a huge event, with about 2,700 delegates from the European nations and beyond. Many of them were research students presenting their work in a forum related to Operational Research.

As usual, when things went wrong, I stopped to wonder how things could be improved. So here are some general suggestions for any conference ....

1) Learn from the mistakes of other people. Some things go wrong every time, in different details. One of the disadvantages of EURO is that there is insufficient corporate memory. Each conference is arranged without much having beenlearnt from earlier ones.

2) Consider all the bottlenecks in the queues and points of service associated with a conference. Delegates need service with their registration and need to be able to use the conference website to answer a range of questions quickly and without having to go thorugh too many hoops. So the website should be simple to use and comprehensive. Registration on site is the first queue most people encounter and it should be as simple and quick as possible, which means that efforts should be made in advance to make service times as short as possible OR to have lots of people to give service. To complete my registration I needed to join three queues (for my badge, for my confernece bag and papers, for my banquet ticket). If I had gone on the excursion, there would have been another queue. At other events, these queues could be replaced by one. Similarly, catering queues need to be minimised. It doesn't take advanced use of queue theory to work out that 2,000 people gathering for a buffet meal need a lot of service points. 100 servers perhaps?

3) Help the delegates to find their way around. The home team knows its way around the buildings, but everyone from elsewhere doesn't so they need signs that can be found easily and read quickly.

4) Make sure that the rooms are suitable for the meetings. I spent an afternoon in a room directly underneath the waste pipes of the ladies' toilets, so there were regular sounds of flushing. Another session was in a warm room, and the window opened in such a way that the screen was obscured by the frame.

5) For presenters. Do think about what you should put in your presentation. Nobody will take in your equations and constraints with a hundred variables -- my record was seven different subscripts in the equations on one screen. And large tables are too much to take in during a fifteen minute presentation. There is only time for two or three main points, and then these need to be put simply and clearly.

6) Also for presenters. Do rehearse the presentation, and do it with an audience who will be honest with you. Because the presenters come from all over the place, some of them are less fluent in English than the Brits and other English-speaking countries. Going through the presentation several times before will deal with nervousness, and keep the talk to its time slot.

7) For session chairs. Keep strictly to the timetable and follow your instructions carefully. At EURO the majority of sessions lasted 80 minutes with four papers. They were supposed to keep to 15 minutes presentation, and 5 minutes discussion. Chairs were to keep an eye on the time and stop the speaker. That allowed delegates to move between sessions at those 20 minute intervals. And if presenters didn't show up, then there should be a gap, because there could be people switching sessions to hear the talks at their scheduled times. Did this happen? No ... talks over-ran, chairs failed to stop them, and if there were no-shows, they just went on with the next paper.

8) For everyone, especially those with major responsibilities; there is a time and place for everything, and some plenary sessions are not the times for unnecessary announcements and speeches. For many EURO delegates, a lasting memory of the conference will be the description of how to adjust the conference souvenir bag that was given after the conference banquet!

Queues in Nationwide Building Society

I suspect that the problem of queue control is the most obvious area where O.R. has made impacts on everyday life. Certainly, it is the example that I use in my "cocktail-party" explanation of what O.R. models.

Last week, the U.K.'s largest building society, the Nationwide, announced that any of its card customers wishing to withdraw less than £100 would have to use a cash machine (ATM = Automatic Teller Machine). This was an attempt to cut queues. The building society, like most others, offers numerous financial services, such as mortgages, savings accounts and insurance. Already, there are attempts to reduce the queues at the tellers, by filtering the customers according to the type of transaction. In Exeter's branch, there are four tellers, and a single queue, with several assistants on the customer side of the tellers who ask people who are queueing whether their transaction could be handled in some other way.

But the latest move has attracted criticism, as the customers who are most affected are thought to be those who are least comfortable with the ATMs -- the elderly, the disabled .... Maybe those customers could be encouraged to sabotage the scheme by carrying (say) £80, queueing to deposit it, and then withdrawing £100 at once. That way they will get the £20 they need, and without facing the (to them dreaded) ATMs.