A recent experience brought home to me the critical importance of good quality data in even the simplest of processes, particularly as processes become more automated and data driven.
Before I went on vacation last month, a new team member joined Castlebridge. Equipment for them was ordered to be shipped to the office, and I rostered staff to be at the office to take delivery on the days forecast by the shipping company, and shared the tracking details with the team so that they could plan days to go to the office around that.
When placing the order with the company we were buying from, I provided a full address, including the Eircode (Ireland’s equivalent of a zip code which, in theory at least, uniquely identifies an address). Eircodes are a funny Irish solution to an Irish problem of non-unique addresses. Basically, the concept behind them was to create a unique identifier for addresses and mail delivery points to make it easier for courier companies to find delivery points and to generally help navigation around the physical world.
In that context, it’s worth noting that our postal service doesn’t use them (they have their own long standing address coding system) and it’s been a slow burn in driving adoption of the Eircode in Ireland. In addition, some of the data in the Eircode system is inaccurate as it was built from historic legacy data sets that might not reflect changes of use of data. (I’ll come back to this question of change management later).
Also, eircodes are a bit like SKUs in physical goods shipping. Our office is in a building. The building has an Eircode. Our office has an Eircode. The other offices in the building have their own eircodes. The apartments that are in the building have their own eircodes. To paraphrase Mark Twain: “You can’t fool me, it’s eircodes all the way down.”
Having taken you on a scenic tour of Irish address data elements, I will return to the narrative. But trust me, this background information will be important later.
In total, I had placed two orders for equipment with one supplier (let’s call them Microsoft, because it was). The supplier then split one of those orders into two different shipments. Therefore, the carrier (let’s call them UPS, because that’s who it was) had three packages to deliver. All three were being shipped to the same address.
They managed to deliver one, which was one of the packages split from the first order. Another item was returned to sender and shipped back to Microsoft. A third, I was able to get redirected early enough in the process so it got to an address where a person could receive it. But all three packages were originally going to the same address and to the same Eircode. And I found myself on my vacation talking with UPS customer service as my family glared at me for breaking my promise to unplug for a few days.
Being a data quality geek, I wanted to get to the bottom of this mystery. For this article I’m going to focus just on the address data issue. I’m going to do a Castlebridge webinar later in October where I go through the full story and the other data issues that appear to have arisen.
So, if one package got delivered and two didn’t, and they were all going to the same address and Eircode, what happened?
Thankfully my persistence with UPS customer service paid off and I got a screenshot sent to me of the original shipping address on the package that was returned to sender. The address was largely complete. It was just missing the Eircode. This had been corrupted and a random string of letters and numbers was in its place.
My good luck in getting the second package redirected meant I was able to meet with my colleague this week and get the package and take a look at the address label. Imagine my surprise[1] when I found that the Eircode had been replaced with the same apparently random string of letters and digits.
And as my colleague and I were both in the office, we took a look at the one package that had successfully made it to the building. My hypothesis had been that this one had an Eircode on the label and something had happened with the others that had corrupted the data. So, I was pleasantly surprised when I found that that package too had the exact same random string of letters and digits.
A critical piece of data that would have enabled any other missing or mis-formatted address elements to be identified by the carrier was corrupted. But it was not something that I, as the customer, would have been able to correct. Because the address was correct when it was input. Somewhere along the data supply chain from order to shipping label it got corrupted. And the fact that it was corrupted the same way three times suggests a systemic error.
The Outcome
In the Enterprise Information Model that I have developed over the years, first with the phone company and then with Castlebridge, we call out explicitly the idea of outcomes as the focus of data management. After all, why do we process data other than to produce some form of outcome for some category of stakeholder? We break these out into Information Outcomes and Process Outcomes.
In this case, the expected Information Outcome was that the address, including the Eircode, would be processed correctly onto the shipping address label that was to be used by the carrier to handle the delivery and to inform their status updates and delivery date estimates. The expected Process Outcome was that an order placed with Microsoft would result in things being delivered by UPS to the right address on the date they forecast for delivery.
The experienced Information Outcome was that an address element was corrupted in the same way on two separate orders affecting three packages. The experienced Process Outcome was that UPS had a 33% hit rate on delivery to the original address. But that Process Outcome had a series of knock-on effects and costs.
- I did manage to get one of the packages redirected. But that involved a time cost for me. A time cost that was multiplied by the fact I was on vacation and was stealing that time back from my family.
- The redirection involved person-hours in UPS to find and extract the package, relabel it, and put it out for delivery again. This was an “avoidable cost of scrap and rework” as Larry English would have described it.
- The environmental impact of packages being returned to the sender or redirected cannot be ignored. On an individual scale it is a drop in the ocean, but at scale, this is avoidable waste that has an impact on our environment. As we all increasingly look to our ESG goals in business, every little helps.
Muda, Mura, Muri
Quality management systems seek to eliminate Muda (wastefulness), Mura (non-conformity or defects), and Muri (excessive burdens). The philosophy and experience are that improving one of these factors can lead to an improvement in others.
In my little story, Mura is the non-conformity of the data to the required standard or format. The corruption of the Eircode data created a defect in the address label. This leads to an increase in Muda, specifically the wastefulness of excessive transportation and the excessive movement of people, all caused by the impact of a simple address data element being corrupted (which is itself a category of Muda – the wastefulness of defects). We also see the Muda of Waiting as the delivery date for the items moved out.
Finally, this all contributes to Muri – overburden. I found myself having to spend an unreasonable amount of time chasing down these items while on vacation. However, at scale, a failure to address the causes of the Muda and Muri in the process has a bigger excessive burden on people and on the environment.
Let’s Sweat the Small Stuff
As we all face the grim reality of climate change, we all need to look at how every aspect of our data processing activities can contribute to the cause or the mitigation of the challenges we face.
Scrap and rework of data does not come for free. Prevention of defects means we avoid Information and Process Outcomes that can have a cumulative effect on our consumption of energy, fossil fuels, and human capital.
The correct
format of an Eircode and the correct transposition of data to an address label
is small stuff. But small stuff can add up.
[1] Dear Reader, I’ve been doing this for almost 25 years. I was not surprised. Not surprised at all. Now, imagine that.
