The Saga of the Safeway Sandwich
I’ve had a few epiphanies in my career – sudden realizations that changed or significantly reinforced my viewpoints. One in particular occurred while attending a tutorial at Enterprise Data World presented by my good friend Bob Seiner of KIK Consulting. Bob knows a LOT about data governance, data stewardship, and data quality. In this particular case, he was talking about how many of the data quality issues we run into are caused by a disconnect between “data producers” and “data consumers”. In a nutshell, the people who provide or input the data don’t understand (or don’t care) what the data will be used for, and thus the either the wrong data is collected or the right data is not collected. There are many reasons for this – the data producers weren’t told what “their” data would be used for, weren’t trained properly, or are just incented to be fast but not accurate. And it can be hard to get that behavior changed, because management doesn’t understand the issue, or may ALSO be incented incorrectly. The key can often be to find the right level of management – people who have reasons to need accurate data.
This disconnect between data producers and data consumers really rang true for me. After spending time at a pharmacy retailer, a large bank, and an insurance company, I’ve seen this behavior, and Bob is right: it is very often the reason why data quality suffers.
Its Lunch time!
The disconnect between data producers and data consumers was brought home to me last Friday, when I stopped by my local Safeway market to get a sandwich. Every Friday the deli makes up a bunch of really huge submarine sandwiches, stuffed full of meat, cheese, and veggies. They wrap the sandwich in cellophane and slap a bar-coded label on it to make it easy to purchase. It’s a good deal, and I expect they sell quite a few of them.
The trouble started when I got to the checkout stand with my lunch. Try as she might, the checker could not get the scanner to read the label, as it was largely obscured during the wrapping process. She couldn’t read the bar code numbers (which allow for hand-input of unscannable items) because those were hidden too. As the lunchtime crowd backed up behind me, she called out over the intercom for the manager to come over with a special key needed to override the scanner so she could put the price in by hand. As we waited, she commented that this was the fourth sandwich today (out of five) which would not scan. The checker at the next station allowed as how she was having the same problem as well.
After about a minute, the manager showed up and I was able to purchase my sandwich. Since I didn’t have to be anywhere special (and maybe because I don’t HAVE a life), I told the manager the story – how the sandwich wouldn’t scan, causing delays and annoyance to the customers. He responded that it was no big deal that one sandwich out of the 150 or so they expected to sell hadn’t scanned (clearly not caring that it was a big deal to ME and the people who had to wait). At that point the checker responded that most of them had this problem, but that didn’t seem to impress him either. All he seemed to care about what that the sandwiches got made so they could be sold and contribute to overall store sales – which impacted his bonus. The light was beginning to dawn.
Talking to the Data Consumer
The checker line had disappeared and she was idle for a moment. I questioned her about the situation and found out that:
- This was an ongoing problem which had been commented on by all the checkers.
- The number of sandwiches sold seemed to be dropping off.
- The number of people complaining that there were no sandwiches to buy seemed to be increasing.
- The store manager was aware but wasn’t concerned.
I asked her if anyone had spoken to the Deli manager about it, and she didn’t think so. I guessed that he probably wouldn’t care anyway, as he just wanted to make lots of sandwiches to sell. “Oh no” she replied “he would very much care because he gets credit for each sandwich sold”. AHA!
Talking to the Data Producer
The Deli manager just happened to be going on break, so I told him about the experience I’d just had, and the comments from the checkers. You could see the light beginning to dawn. “Well, that explains a lot” he said. He told me how, even though the sandwiches all seemed to disappear, the store records showed that they hadn’t sold very many. As a result, they cut way back on the number they made so they wouldn’t go to waste. The issue, of course, was that when the checkers used the override key, the transaction was not logged properly, simply showing up as “miscellaneous”. Thus, the counts were off, the deli manager wasn’t properly compensated, and there wasn’t enough product to satisfy the customers. Oh yeah – and the hours of one of the deli employees was cut back because they didn’t need as many sandwiches. All because of bad data and the disconnect between the data producers and the data consumers.
Fixing the problem turned out to be a matter of making the data producer aware of it. This worked because the data producer was incented to get the data right – if the sandwich didn’t scan, he didn’t get credit for it. Of course, if the data producer got credit based on the count of sandwiches MADE rather than the count of sandwiches SOLD, he probably wouldn’t have cared either, and then the only recourse might be to justify improving the data to improve the customer and employee experience. This would have been a matter for the store manager, who, as I said earlier, didn’t seem to care.
I guess I could have found a different place to buy my lunch, but that seemed a bit extreme.