The Backlog Trap
Following this week's CBCI Certification Course, Charlie shares his thoughts on the backlog trap.
This week I have been teaching the CBCI Certification Course. After the course finished on Thursday evening I went to London City Airport to get my plane home. All went well until I was sitting at the gate and the plane was promptly cancelled. As it was about 6:45pm, there was no other transport which I could catch back to Scotland, either by plane or train, so I joined the long queue for rebooking home the next day. Eventually after an hour wait, I got to the front of the queue and was offered a flight at 9:15am the next morning to Edinburgh from Heathrow, a Glasgow flight at 2pm or a flight from City Airport to Glasgow at 6pm. I opted for the overnight stay in Heathrow and am travelling to Edinburgh as I write the bulletin. Always a man to turn a crisis into an opportunity, I thought I could at least use this inconvenience for some benefit, and it gave a me an idea for something to write this week.
One of the things my adventure got me thinking about was how long I had to wait for the next available flight to Glasgow. It is obvious that British Airways doesn’t have half empty planes just in case three planes are cancelled. They run as full as possible, so it takes quite a long time to get the passengers booked on existing flights, as there are a very limited number of seats available on each flight, hence the limited options.
When I was teaching Analysis this week, we had lots of discussion on defining RTOs and defining the resources and assets we need to keep the activity going at a minimum level. Could we cope with 10%, 40% or 70% of staff? After discussing this for a while I remembered to tell them that sometimes after a disaster, we need to have more staff carrying out the activity, rather than less. Examples I gave were:
1. After a major IT outage or cyber incident, you may need more staff to man the IT help desk as they are likely to be taking more calls.
2. In a similar way, if you have a general call centre as a help desk, you are likely to get more calls during an incident. Failure to answer calls can lead to further bad press and criticism of the company.
3. During an incident where there is a need to rebuild IT applications, you may need more staff than you normally have.
Around the year 2010, the idea of the backlog trap was a new and exciting concept, often mentioned in BC guides and brochures. It basically said that if you had downtime on your systems you may have to resort to manual processing, with the idea that these would be typed into the system once it is up and running. The issue was that if orders continue to come in at the same rate after the incident, then you would struggle to type up previous orders manually as all your staff are working on new orders. You then had to hire extra staff to deal with the backlog. You continue to hear about this today, as perhaps for many systems there is no real workaround.
Today’s businesses are perhaps much more susceptible to backlog and volume issues. In terms of efficiency savings, we have just the right amount of call handlers to the numbers of calls we receive. In supply chain we also operate to ‘just-in-time’ delivery, so we have minimal stock in warehouses as we have no space for any contingency stock, and the whole system has very little slack. This is fine and efficient until you have an incident and struggle to cope with the extra volume of calls or you run out of stock.
So back to my flight home, I am a victim of BA’s efficiency and I have had to just put up with it. My suggestion for you this week is to look at your agreed level of recovery and check whether instead of coping with less staff, you actually need to organise more. Look at your supply chain and understand the scenarios which would cause it to stop and how quickly that would happen. The better we can understand the impacts and requirements during an incident, the better we can prepare for them.