Modelling Complex Management Systems: EasyBeds Revisited
© 2004 by Stefan Scholtes (Cambridge)
MODELLING COMPLEX MANAGEMENT SYSTEMS: EASYBEDS REVISITED
Background
Most students find the EasyBeds case very complicated, although it is still an order of magnitude
simpler than most real-life management analysis cases. The reason why students find it difficult is
that they approach it wrongly. They want to “solve it in one go”. They want to write the right model
from scratch and use it to find the right answer. This approach will not work in practice, not least
because there is no right model, let alone a right answer. Such attempts lead to lengthy models that
provide little managerial insight, are very difficult to communicate, and not trust-worthy, even to the
modellers themselves. If a “linear” approach from start to finish is all you got to analyse a realistically
complex situation, the task will often seem so overwhelming that you may not even attempt a serious
analysis but base your decision entirely on un-tested intuition.
We have seen in class how misleading intuition can be in the presence of uncertainty. There is
further evidence. The management consulting company Capgemini has recently released a report on
business decision making in the UK, based on a survey of 270 top level executives 1. The average
senior executive in the sample makes about 20 critical business decision each year, valued at
around £160,000 each, with a self-reported failure rate of 24%. The annual cost of such wrong
decisions amounts to about £800,000 per senior executive and I am sure it shows considerable
variation. Therefore: Don’t give up on analysing complex cases! Doing a thorough analysis of a
complex situation could be your biggest competitive advantage.
This note has been written to give you some guidance on analysing complex business situations.
Making sense of complex systems
How can we make sense of a complex business situation? The only way I can deal with complexity
is by starting with a simplistic understanding of the system (intuition) and improving this
understanding step-by-step by
a) breaking the system into suitable parts
b) investigate the parts separately (as systems in their own right)
c) investigate how the parts fit together to create the performance of the overall system.
This process adds layers of complexity as we increase the level of granularity. Think of taking a car
apart. Bigger parts, the motor, the chassis, the gearbox, are themselves broken into smaller parts,
which are again broken into even smaller parts and so on. In this way, we move further and further
up on the complexity ladder, gaining a better understanding of the individual parts of the system. But
there is a downside to moving up the complexity ladder: The further up we are the more we loose
contact with the system as a whole. It becomes more and more difficult to understand and bear in
mind how the parts interact and communicate to provide the overall system performance. At some
point on the ladder we are wasting energy trying to gain detailed knowledge of particular parts that
are not terribly important for the overall performance of the system.
Trying to understand a complex system will always force you to trade off drilling deep for a better
understanding of the detail and maintaining a bird eye’s view of the system as a whole admitting to a
simplistic, possibly overly simplistic, understanding of its parts. It seems to me that it is best to start
with the whole system in mind and separate it step-by-step into a few subsystems, making sure that
the connection to overall system performance is always well understood, even if you know your
understanding of the sub-systems themselves is rather superficial. The more you disintegrate the
system, the higher you climb on the complexity ladder with the danger of loosing sight of the overall
system and, even more importantly, loosing the ability to communicate your understanding of the
system.
Indeed, a key difference between the understanding of an engineering system, such as a car or an
airplane, and the understanding of a management system is the importance of communicating your
understanding of the latter. To run an engineering system, for example a nuclear plant, it is enough
for a few specialists to understand the system in detail. Communication can be done in a highly
specialised language, involving only few people. With that assumption, you can climb high up on the
1
http://www.uk.capgemini.com/news/pr2004/pr1487.shtml
1
Modelling Complex Management Systems: EasyBeds Revisited
© 2004 by Stefan Scholtes (Cambridge)
complexity ladder. In a management situation you have to be able to communicate your
understanding of the system more widely to make an impact. Whilst it is equally important to climb
up the complexity ladder to gain a better understanding of the system, in a management context you
will have to climb down again and communicate your improved understanding and intuition on a
lower level to a broader audience. Every step up on the complexity ladder means that you loose an
order of magnitude of audience.
Another important difference between engineering and management systems is that the former are
essentially physical, i.e. they can be decomposed with a spanner, falling into their natural parts, while
the latter are organisational with no screws and no natural physical parts. The “parts” that we use to
understand them are mental or conceptual, such as “demand”, “customer satisfaction”, “costs”,
“revenues”, etc. I am focusing here on “parts” with associated metrics because we want to use a
computer to model system performance. These conceptual “parts” of a management system are
highly complex subsystems in their own right. Demand, for example, has an entire sales and
marketing department as a driver, but also depends on external factors such as competitor moves,
innovation, fashion, network-effects, etc.. How can I think of these parts working together to produce
the system performance? This is not as obvious as in the case of a physical system. It is here, where
modelling has a main role to play. Modelling forces you to take the organisational system apart and
put it together again in the model world. As with physical systems, this is best done step-by-step – it
cannot be achieved in one go. Also, remain modest: The model will never fully replicate reality. But it
will help you understand reality much better. Don’t forget: The purpose of Management Analysis is
not to give a right answer - there is none - but to help you ask the right questions.
What does this all mean for practical work? The key to modelling complex systems is step-by-step
modelling of the overall system under investigation, without getting hung up too early in detailed
modelling of any of its parts. Begin with an overly simplistic but working representation of the system,
based on simplifications and projections. Then improve the model step-by-step, including
randomness where appropriate. Be prepared to discard the model and start fresh when you realise
that you are on the wrong track; don’t stick to a conceptually wrong model on the grounds that you
have put so much effort into it. The effort is sunk cost – look forward.
Let’s see how such step-by-step “taking-apart-and-putting-together-again” modelling can be done in
the EasyBeds case. The Excel workbook EasyBedsSimple.xls contains the corresponding models.
Bill’s task
Bill wants to understand whether or not overbooking is an interesting untapped business opportunity
for EasyBeds. His intuition says “yes” – but he needs sound evidence to present his intuition to the
board. He is not being asked to set up a sophisticated overbooking system for the company but only
to make a case that overbooking is an interesting business opportunity. He may want to argue that
the company should spend money on a feasibility study on overbooking, e.g. by running a pilot
scheme in Shanghai.
Why is overbooking a business opportunity?
The first thing we need to understand is what characterises the performance of an overbooking
system? Two metrics come to mind immediately:
-
Financial performance: additional revenue minus additional costs
Customer dissatisfaction: percentage of bumped customers
We want financial performance to be high, customer dissatisfaction to be low. Let’s focus on financial
performance first and begin by building a simple model.
Overbooking would potentially increase revenues but may cost us if we have to bump customers.
We are interested in the value added through overbooking. Let’s take the total system apart, step-bystep:
Step 1: Get the logic right
What measures system performance? Added value
2
Modelling Complex Management Systems: EasyBeds Revisited
© 2004 by Stefan Scholtes (Cambridge)
Added value: How is it generated?
Added value = Additional Revenues – Additional Costs
 Part 1: Additional Revenues: How are they generated?
Additional Revenues = Additional Bookings * Room Rate
 Part 1.1: Additional Bookings: How are they generated?
Additional Bookings = max(bookings-capacity,0)
 Part 1.1.1: Bookings: How are they generated?
Bookings = min(Demand, Booking Limit)
 Part 1.1.1.1: Demand
 Part 1.1.1.2: Booking Limit
 Part 1.1.2: Capacity
 Part 1.2: Room Rate
(EXTERNAL)
(CONTROL)
(KNOWN)
(EXTERNAL)
 Part 2: Additional Costs: How are they generated?
Additional Costs = Bumped customers * Bumping Rate
 Part 2.1: Bumped customers: How are they generated?
Bumped customers = max(Bookings – No Shows – Capacity,0)
 Part 2.1.1: Bookings
(Already determined)
 Part 2.1.2: No Shows
(EXTERNAL)
 Part 2.1.3: Capacity
(Already determined)
 Part 2.2: Bumping Rate
(CONTROL)
The bold-faced variables are inputs to the system. The system then generates the added value. This
is easily implemented in a spreadsheet (Worksheet Model Logic).
Step 2: Fill the logical model with a first set of sensible projections.
Demand Projection. The average booking number last year was 139. If we use this as demand
figure, we will not get any value from overbooking because we will never overbook. The problem with
the average booking number is that it does not tell us what demand would have been on the days
when we were fully booked. It reflects sales, not demand. A better proxy for demand is the number of
enquiries. The average number of enquiries last year was 1253. The average conversion rate from
enquiries into bookings for the days when we were not fully booked, i.e. when bookings equal
demand, is 11.6%. This would lead us to estimate average demand to be 1253*11.6% = 146, still
below capacity, i.e., overbooking on the basis of this demand figure does not add value. The key
issue is that we benefit from overbooking only in high demand scenarios. To see the added value of
overbooking, we have to take demand variations into account. Let’s do that in a simplistic manner
first. We were fully booked on about 50% of the days last year. These were the days when we could
have actually benefited from overbooking. What was the average demand on those days? The
average number of enquiries on those days was 1415, considerably higher than the average
enquiries over all days. If we multiply 1415 by the average conversion rate of 11.6%, we obtain 164
as average demand during 50% of the year. Let’s work with this demand projection.
Booking Limit: How many additional customers can we accommodate? The commercial capacity
of a hotel on a fixed day is its physical capacity (number of rooms) plus the number of no-shows.
This commercial capacity fluctuates from day to day. The average number of no-show in Shanghai
over the past year was 19, which gives an average commercial capacity of 169 in this hotel. Let us
use 169 as booking limit for the time being.
Room Rate Projection. What would we earn per additional booking? The average price per room is
$55. This seems too low as an estimate of the marginal revenue because overbooked customers will
enquire late and ask for days of stiff demand. The data shows that the average price on days when
the hotel was fully booked was $62. Even this price might be too low and it might be better to look up
the average maximal price quoted on fully booked days (data not provided). For the time being, we
will work with the conservative estimate of $62 per additional booking.
3
Modelling Complex Management Systems: EasyBeds Revisited
© 2004 by Stefan Scholtes (Cambridge)
No-show Projection. We use last year’s average no-show rate of 14%.
Bumping Rate. To be conservative we use as bumping rate the high-end cost of a 5* hotel and
assume that the customers will be allowed to stay their for the entire duration of their booking period,
i.e. 3.5 days on average. This results in a bumping rate of 3.5*$180 = $630.
If we use these projections, we arrive at a projected added value of $868 per fully booked day. Given
that about 50% of days are fully booked we project the added value to be around $434 per day. Last
year’s average revenues were $7694 per day, i.e. according to this first model the overbooking
strategy increases expected revenue by more than 5%, a considerable upside in a situation with
negligible variable costs (Worksheet Projection-based Model).
Step 3: Perform a sensitivity analysis
The next step in our analysis is to look at sensitivity of the added value on the two key uncertainties,
demand and no-shows. This is easily done in a data table is displayed in the following graphs:
No-shows fixed at 23
1400
Added Value
1200
1000
800
600
400
200
0
-200
130
140
150
160
170
180
190
Demand
Added value
Dem and fixed at 164
2000
1000
0
-1000
-2000
-3000
-4000
-5000
-6000
-7000
-8000
-9000
0
5
10
15
20
25
30
35
40
No-show s
First of all, we realise immediately that the added value is quite sensitive to both, demand and
number of no-shows. The next thing that we realise is that the relationship is not a straight line. This
is a warning signal! Such non-linearities are sure indications of the flaw of averages. They result in 4
Modelling Complex Management Systems: EasyBeds Revisited
© 2004 by Stefan Scholtes (Cambridge)
“out-of-balance” projections, i.e. the projected added value based on averages is not the average
added value.
Here is the next big mistake: Many students will now just carry on with the analysis without making
sure they have straightened their intuition and are able to communicate the flaw of averages in this
situation. So where does the imbalance come from?
On the demand uncertainty there are two “kinks” in the sensitivity. The lower kink means that we are
not capturing added value if the demand is so low that we are not overbooking anyway. This means
that we are benefiting from upside demand and are sheltered against downside demands. That’s a
good thing! On the upside, however, there is also a kink. This is where the booking limit constraint
kicks in. If demand is higher than the booking limit, we cannot reap the benefits because of the
booking limit.
On the no-show uncertainty there is one kink. Where does that come from? If no-shows are low then
we are more likely to bump customers. This is costing us – that’s why the left curve is highly
negative. On the other hand we are not benefiting from a high number of no-shows because if the
no-show number is so high that we are not bumping any customers then an additional no-show is not
going to help our added value.
Having convinced ourselves about the intuition behind the sensitivity graphs, we will now move on to
include uncertainty, which we believe is important here due to the non-linearity leading to a potential
flaw of averages.
Step 4: Investigate the effect of uncertainty
A simple way of generating random demand is to sample an enquiry from the historic data and
multiply it by the average conversion rate from enquiries to bookings on non-fully booked days,
which was calculated earlier at 11.6%. No-shows are generated by sampling from historic no-show
rates and multiplying the no-show rate on the number of bookings. A parametric simulation with
booking limits of 150,155,160,165 and 170 shows that a booking limit around 160 is optimal, leading
to an expected added value of around $120/day or about 1.5% of average daily revenues. The
simulation produces the following histograms for the added value:
100.00%
90.00%
80.00%
70.00%
60.00%
Frequency
50.00%
40.00%
170
30.00%
165
160
20.00%
155
10.00%
150
1683 : 2000
1049 : 1366
-220 : 98
170
415 : 732
-854 : -537
-1488 : -1171
-2122 : -1805
-3390 : -3073
150
-2756 : -2439
-4659 : -4341
-4024 : -3707
-5927 : -5610
-5293 : -4976
-7195 : -6878
-6561 : -6244
-8463 : -8146
-7829 : -7512
-9732 : -9415
-9098 : -8780
-11000 : -10683
-10366 : -10049
0.00%
It is very important to always check the outcome of your analysis against your intuition and to do
everything you can to validate your model. You can, for example, change the inputs to the model to 5
Modelling Complex Management Systems: EasyBeds Revisited
© 2004 by Stefan Scholtes (Cambridge)
values that you know the result for (e.g. everything is zero). Here we can use the histogram shapes
to validate our model. Can we explain the shapes intuitively? If not then either our intuition about the
problem is flawed or the model is flawed (or both). The histograms show, as expected, that we make
more than 150 bookings only in about 55% of the cases as seen by the peak in the middle of the
diagram. The smaller peak on the right-hand side of the histogram gives the percentage of days that
used up the full booking limit. This percentage decreases with an increased booking limit, as
expected. The histogram also shows that, whilst there are some days when we incur large costs,
those days are rare.
Can we specify this further? Recall that we were also interested in the impact on customer
satisfaction. The model allows us to calculate the percentage of customers we bump. It is simply the
number of bumped customers over the number of booked customers minus no-shows. Re-running
the simulation for this performance measure shows that we only bump about 1 in 1000 customers
and only bump on about 4% of days.
Climbing up the complexity ladder
A much more complex model has been developed, taking many other facets, such as trends, price
dependence on demand, etc, into account (EasyBedsSim.xls). The results of this complex model
confirm the results obtained by our simple model. Climbing up this complexity ladder is important to
make sure that we are not missing a major point in our analysis. However, we then have to climb
down again and explain our analysis using the simplest possible model that conveys the
message. Only then can we help our audience, e.g. the board, to build good, well-tested intuition
about the management problem.
Further issues
Our analysis is conservative. Overbooking will become more profitable and higher booking limits may
be advisable if demand increases over time, in which case we are making more use of the
overbooking facility, or if the trade-off between marginal revenue and bumping costs can be
improved, e.g., through bulk deals with 5* hotels to reduce bumping costs or through a better
estimate of the marginal revenue of a customer when the hotel is fully booked, which is likely to be
higher than the average room rate of $62 used in our model.
The overbooking process needs to be carefully designed to make sure that we are not loosing
customers, in particular, the high-revenue business customers.
In summary, the analysis indicates that careful overbooking could well be an interesting untapped
profit opportunity and should be further investigated, e.g., through a pilot project involving a few
hotels.
6