Chinese whispers in the supply chain

I have just been working on a “one off” report for a customer that required crunching quite a few numbers extracted from various databases to prepare a report requested by one of their customers. Nothing unusual about that – but also – nothing unusual about the fact that the requested data was pretty meaningless. I regularly get asked to report meaningless metrics and statistics.

If I explain the set-up I am sure that you will begin to see where I am coming from. Somewhere in Company A (perhaps a successful retail chain) someone wants some data – it might be senior management reviewing strategy, the marketing department considering a new advertising campaign or it could be a management accountant preparing some statistics for an external requirement. Anyway, the request is passed eventually to the buying department to be passed on to all relevant suppliers – as a “must do” and with a deadline. So the request lands in the sales department of Company B – a manufacturer. The sales department consider the request carefully in case it contains a trap and then as all, or part, of the request is for data regarding items supplied in turn by other companies, a version of the request is passed to the buying department of Company B who send it out to the sales departments of all their relevant suppliers – again as a “must do” and with a tighter deadline. This may be repeated more than once. Eventually the data request ends up at the lowest point in the “food chain” a point from where the request can no longer be passed on.

If the data request posed eventually to my Customer’s sales department has much relevance to the original data requirement I would be surprised. Too many people have received it, misunderstood it and (gratefully) passed it on to someone further down the pecking order. The nature of the pecking order itself is relevant – it is the current practice of purchasing departments to act in a dictatorial manner when dealing with suppliers in almost all markets. “Just do it or lose the business.” is the norm – and let’s face it the buying departments in question don’t have a direct stake in the process anyway.

One of my favourite numbers in a supply chain request is “an average”. A recent request wanted an average unit weight for various categories of supply. Allowing for the fact that the request itself was probably an interpretation (or misinterpretation) of the original data requirement, we are still faced with a number of options. Did “average weight” mean the average of the unit weight of all of the different models in a given category or did it mean a (weighted?) average of the total quantity supplied? Given that numeracy is no longer one of the keys to business life it is entirely possible that the originator of the question does not know the answer in any case. If the alternatives were explained in straightforward terms the originator would probably plump for one meaning or another but that is never going to happen. Without knowing what the end user of the data wants to do with the data it is just about impossible to prepare any usable metrics. Worse – as the data makes it’s return journey up the food chain then it will be combined and aggregated on it’s way. What is going to become of an average? Will it get averaged with other averages? Probably!

Such data requests are a good test of a programmer’s integrity – they are also the darker side of the consultancy business. Motivation is low, as there is no direct benefit to your client in exchange for the money that you charge but you still have to deliver a result that is as honest and accurate as you can make it – no matter how sure you are that the numbers being prepared are unlikely to be what is wanted or needed. Decision will be made and money spent based upon data that is almost certainly irrelevant, wrong and misleading.

One solution would be for all requests for data to be accompanied by a short brief on the intended purpose of that data. However I suspect that in many circumstances such a brief would never survive to make its way down the supply chain. It is perfectly possible that the originator did not know that the original data request was in fact going to make such a journey before it was resolved. An alternative might be to reverse the process and provide a brief on how the data was gathered but, again, I suspect that such a brief would not make the return trip as, at every stage, there would be worries that “getting it wrong” might trigger an unfavourable review and a subsequent loss of business. No, the real problem is a social one and like many social problems very difficult to find solutions to. In the mean time I will keep writing code for “edge cases” and worry about numeric precision – grinding the numbers through the best code mill I can construct in the circumstances.