“I would rather have questions that can’t be answered than answers that can’t be questioned.”
Richard Feynman
Picture the scene…
Months developing a simulation model of a support chain, chasing down data, analysing countless sensitivities and what-ifs. A late-stage stakeholder briefing, presenting findings from this analysis, highlighting interesting results to the community, and then a single picture causes a confused look by some of the senior engineers. The picture displays the top ten “worst” items; those which display critical shortages in our simulations. One of the engineers asks about the third item on the list, and explains that they have never previously seen shortages for that item.
We are simulating scenarios with operational conditions that have not been trialled in real life. The analysis is part of early research around the feasibility of these proposed operations, and how the support chain will need to be improved, so to an extent we are expecting to see some unexpected results. No amounts of deep-dives and further analysis, however, can explain why this single item shows such exaggerated behaviours.
So what is the problem?
Is our model wrong, missing some key support chain behaviours that would account for this item? Is it a bug or error, causing the wrong numbers to output? Or are our input data and assumptions incorrect?
It is often explained that all models are wrong, just some are less wrong than others. Models are, by definition, simplifications of reality and therefore inherently limited. We could never claim that our model was a perfect representation of reality, and we were aware of certain areas where the model didn’t reflect real behaviours. But through extensive testing there was confidence that our model provided predictions that matched historic behaviours.
Another oft-quoted statement about models is “garbage in, garbage out”. The most perfect and sophisticated model will still give an incorrect result if the data inputs are wrong.
Eventually, it was found that the data used describing stores held of this item was incomplete. As a result, we were assuming the wrong number of spares being held, and so the model outputs painted a much worse picture than reality.
Is this a failure?
Of course, the analysis presented was not correct, and if it had been accepted unquestioningly then the results could have been disastrous. This false result, however, did uncover true issues in how data was managed (and how it was reported) which allowed the customer to review their processes and avoid future data issues.
Whilst this situation could sound like a simple example of where analysis can go wrong, I think it highlights some important truths about false results:
- You don’t know what you don’t know, but using models might uncover some of these hidden problems. This customer did not know that there were issues in how data was interrogated from their systems (data which was used on a regular basis), and therefore it is entirely possible that day-to-day use of this data was driving incorrect actions. This “wrong” analysis brought this unknown system failure to light.
- If results surprise you, then there is more work to do. Why are results different to expectations? Often models can expose unexpected behaviours that do not follow immediately from the assumptions, what we call “emergent behaviours”. The utility of the model is to expose these behaviours and allow the user to investigate further. When well designed, a model will facilitate these “deep-dives” and enable a more accurate picture of reality to be understood.
- Models need high quality data. The most sophisticated and innovative model is no match for well defined, accurate and curated data. We need to get the latter right before we can make use of the former.
- Don’t focus only on the extreme results. It is all too easy to draw attention to the top and bottom percentiles of our data, analysing the sensitivity drivers within a model. However, the data points which currently sit in the forgotten middle, may produce extreme results in another scenario. Could we have spotted this data error sooner? Initial testing (with historical data) placed this item in the middle of the data set; the small discrepancy was put down to randomness. It was only later, when simulating more extreme scenarios that the difference was amplified, and it became one of these extreme results
Get analysis wrong, and then do something with it.
This scenario explains what I learnt when my analysis didn’t reflect reality. This is a situation we are always going to face; a model is never 100% correct and neither are we who use models. If we remember that our results are always wrong, that we can always learn from ‘odd’ results, then we might just uncover some true insight.