Old Tech = Unhappy Employees

Are you losing employees because your technology is old and outdated?  Wherever you are in the world, whatever your industry, technology laggards are more likely to have frustrated staff that feels hamstrung by their tools.  Do you think they are as productive as they can be?  I recently wrote this entry for a partner’s website.  It is based on this research that my current employer, Unisys, released in 2018.

 Case management platform, workflow, and process automation tools can help your organization turn that around quickly. Similarly, development and operations approaches including Agile and DevOps can help you develop and sustain custom built solutions more effectively with improved security and a higher quality of code (fewer code problems with deployed code results in less rework and less impact on the user base).  Combining the two can further expedite your modernization efforts, and often reduce the costs of change.

When undertaking technology improvements, consider modernizing your business technology to extend your application reach to smartphones and other mobile devices.  This can help ensure security and governance where it otherwise might not exist – a potential risk for your organization and its data.  Finally, automating your business processes, or modernizing those that already are, can also improve data quality through reduced manual data entry and new data management tools.

 

Bad Data – When to Let it Go?

My friend Cliff recently approached me with a problem.  His organization has tasked him and his team with analyzing, amongst other things, the depth of their bad data problems in advance of replacing their financial systems.  Initial indications are that their data is not just bad, it is very, very bad.  His question?  When is it ok to leave the data behind and not port it over to the new system?  When should he just “let it go”?

In looking at his problem, it is obvious that many problems stem from decisions made long before the current financial system was implemented.  In fact, at first glance, it looks like decisions made as long as 20 years ago may be impacting the current system and threaten to render the new system useless from the get-go.  If you’ve been around long enough you know that storage used to be very costly so fields were sized to just the right length for then current use.  In Cliff’s case, certain practices were adopted that saved space at the time but led to – with the help of additional bad practices – worse problems later on.

When we sat down to look at the issues, some didn’t look quite as bad as they initially appeared.  In fact, certain scenarios can be fixed in a properly managed migration.  For example, for some reason bank routing numbers are stored in an integer field.  This means that leading zeros are dropped.  In order to fix this, scripts have been written to take leading zeros and attach them to the end of the routing number before storing in the field.  Though I haven’t seen it, I’ve got to assume that any use of that same field for downstream purposes includes the reverse procedure in order to creat a legitimate bank routing number.  Of course, when a real bank routing number and a re-combined number end up being the same, there are problems.  He hasn’t yet identified if this is a problem.  If not, then migrating this data should be relatively easy.

Another example is the long-ago decision to limit shipping reference numbers to 10 digits.  There are two challenges to this problem for him.  The first is that many shipping numbers they generate or receive today are 13 digit numbers.  The second is that they generate many small package shipments in sequence, so the last 3 digits often really, really matter.  When reference numbers’ size expanded beyond the 10 the original programmers thought would be enough, a bright soul decided to take a rarely used 3-digit reference field and use that to store the remaining digits.  Probably not a bad problem when they had few significant sequential shipments.  However, since the current system has no way to natively report on the two fields in combination – and for some reason no one was able to write a report to do so – every shipment must be manually tracked or referenced with special look-ups each time they need to check on one.  Once again, this problem should probably be fixable by combining the fields when migrating the data to their new system although certain dependencies may make it a bit more difficult.

Unfortunately, there are so many manual aspects to the current system that 10 years of fat-fingering data entry have led to some version of data neuropathy – where the data is so damaged the organization has trouble sensing it. This numbness becomes organizatoinally painful in day-to-day functioning.

Early on in my data quality life, another friend told me “Missing data is easy. Bad data is hard.”  He meant that if the data was missing, you knew what you had to do to fix it.  You had to find the data or accept it was not going to be there.  But bad data?  Heck, anything you look at could be bad – and how would you know?  That’s difficult.

So, this is Cliff’s challenge.  The data isn’t missing, it is bad.  But how bad?  The two scenarios above were the easy fixes – or could be.  The rest of the system is just as messed up or worse.  Being a financial system it is hard to imaging getting rid of anything.  Yet bringing anything forward could corrupt the entire new system.  And trying to clean all the data looks to be an impossible task.  Another friend was familiar with an organization that recently faced a similar situation.  For them, the answer was to keep the old system running as long as they needed to for reference purposes – it will be around for years to come.  They stood up the new system and migrated only a limited, select, known-good set of data to help jump-start the new system.

This approach sounds reasonable on the surface, but there may be years of manual cross-referencing between the systems – and the users of the old system will need to be suspicious of everything they see in that system.  Still, they have a new, pristine system that, with the right data firewalls, may stay relatively clean for years to come.  How did they know when enough was enough?  How did they know when to let their bad data go?

I’d love to see your thoughts and experiences in this area.

Data Quality and “Damn You, Auto Correct!”

This past week a Georgia high school student sent a text message that was supposed to read “gunna be at west hall today”.  Unfortunately the auto-correct feature on his smart phone changed the first word to “gunman”.  To make matters worse, he evidently fat fingered the address he sent the text to so the person receiving it didn’t know who he was so they took the appropriate cautionary step and contacted the police.  The result?  A high school was shut down for a few hours until things were straightened out.

There are so many directions to go with this.  We could focus on the auto-correct feature and how this tool seems to have caused much frustration and laughter by automatically mistyping things for people – though I do question how many items at a site like “damnyouautocorrect.com” (DYAC) are truly accidental.  Or we could focus on the myriad of interesting things I found while researching this blog.  How about the site that teaches you How to Make Siri Curse Like a Sailor (careful if you are easily offended) or Tips to Add Words to iPhone’s Dictionary (for older versions of iPhone) and iOS 5: How to add words to the auto-correct dictionary for iOS5.  Or, if you like the way the Android presents predictive text with the keyboard bar, Enable iOS 5’s Android-Like Autocorrect Keyboard Without Jailbreak does just what it says it does.

Or we could discuss the fat fingering of the address.  This actually is of most interest to me.  I’ve researched keystroke error rates in the computer space before and concluded the average typist fat fingers a keystroke about 5% of the time while professionals might do so 1%-2% of the time.  The thing about these percentages is they can be very deceiving.  5% error rates can explode in the wrong situations.  For instance, imagine a 10 character-long field.  If you had to fill that field in 10 times and you averaged 5% error rate in your typing, the best effective ongoing error rate you could achieve would be 10% because across 10 fields you make all the errors in one field (5 of the 10 characters are wrong in that one field) but all the other fields are correct.  1 in 10 fields being incorrect is a 10% error rate.

At worst your effective error rate would be 50%.  This would occur if you made one keystroke error in each of 5 fields since you will be typing 100 characters and you have a 5% error rate.  If 5 of 10 fields each have 1 error, your overall error rate across the fields is 50%.  Corporate data can go really bad really quickly in this scenario.  Of course most systems have found ways to limit these types of issues through check boxes and drop-down lists and other validations.  But sometimes data entry can’t be avoided.  Entering customer contact information is one such situation.  Get 5 in 10 email addresses wrong and there goes your email marketing campaign.  Even if you are careful error rates can be significant.  I read a study some time ago that indicated that careful typists often catch their mistakes, so professionals usually average only 1 in 300 unfound errors.  That’s much better, but still can translate into problems for your enterprise.  Using the same 10 character field, 1 in 300 errors would equate to 1 in 30 fields being erroneous.  That’s over 3% – still pretty bad, but I know some organizations that would love to have data quality problems with only 3% of their data.

So this, now, brings me back to where we started.  I’ve got to believe that without autocorrect, the keystroke error rates on smart phones is significantly higher than it otherwise would be.  Typing on those tiny keyboards is always a pain for me.    I’ve found on my phone that the right place to touch in order to get the letter I want is just to the left of the letter – not right on it.  I’m constantly back-spacing and retyping.  Perhaps this is why there are so many bizarre autocorrect examples in the world (no, I’m not saying I’m responsible for all of them – just that other people must have similar challenges to mine, don’t they?).  I miss the Blackberry keypad!

I think organizations should be very wary of leveraging smart phones for serious business apps that require data entry, unless they have extremely strong user data validation methodologies. Because I expect few developers to be so vigilant in their app development, I believe the future could bring some very unfortunate results from using business apps on smart phones.  While DYAC entries sure can be funny (warning, they can also be quite vulgar) the same errors in business transactions could be catastrophic for your enterprise.  Imagine things going terribly wrong and facing a lawsuit and having to use the “damnyouautocorrect” defense.  You might end up in a much worse situation than a couple hours of high school lockdown.

Data Quality – How Much is Enough?

I read Henrik Liliendahl’s blog post today on “Turning a Blind Eye to Data Quality”.  I believe Henrik and those that commented on the post have some very, very good points. For data quality professionals, the question might be “How much is enough?” when it comes to data quality.  And the answer to that question really depends on the nature of your business and how the leaders in your organization view the value that data quality can bring them.  The question we will most often be asked is “how does DQ help my bottom line?”  If we as  data quality professionals can’t tie DQ initiatives directly to bottom line impact, it will be hard to get serious attention.  And believe me, we want serious attention or our own value to organizations will be questioned.

This means we probably need to change the conversation away from DQ as a means to its own end and towards a conversation about how selected projects can have a positive impact on the bottom line. That conversation may be happening within many organizations at levels above our pay grades. Our first goal should be to ask our direct managers if the conversation is going on and how can we help in real, meaningful, tactical, financially relevant ways.  If that conversation is not happening, we need to ask what can we do to get the conversation going in the same real, meaningful, tactical, financially relevant ways.  We must abandon the mythical goal of a single version of the truth for all attributes.  Our goal needs to be about making the business more successful in incremental tangible ways and thus making ourselves more successful in incremental tangible ways.  After all, as Henrik points out, our businesses are being successful today despite bad data.

In comments to Henrik’s post, Ira Warren Whiteside mentioned that “As with everything else in order to convince an executive to “fix” something it has to be really easy to do, not involve a lot of collaboration and be cheap”.   I would argue with this perspective.  I think that the decision to go forward with the project should be easy, not necessary the project itself.  This means clear, unquestionable value to the business (most likely directly to the bottom line) is needed.  And I think such a project should show impact quite quickly.  You can’t have a 12, 24 or 48 month project without value being realized within, say, the first six months or so.  Thus, it is best if the initiative can be absorbed in bite-sized chunks so initial benefits can be quickly realized to help reinforce a culture of DQ. Don’t wait too long to deliver or you will lose your audience and your chances for any future projects will diminish – greatly.

In the retail supply chain, suppliers end up paying, on average, 2% of gross sales in penalties to their retail customers. This is 2% that is taken directly from the bottom line and is usually tied back to inaccuracies in delivering orders – problems with being “on time”, “right quantity”, “right product”, “right location”, “broken products”. Each supplier has people (often a whole team) focused on resolving these issues.  There are two key ways they tackle these problems.  The first is that they identify the dollar amount below which it is too costly for them to address the problem.  In short, it costs them more to fix it than it does to just pay the penalty.  The second is deep root cause analysis of those issues that are too costly not to fix – either in aggregate (ie. the problem occurs frequently) or as stand alone problems.

I think DQ practitioners could learn a lot from what is done to address these retail supply chain problems.  The first is to identify what is ostensibly “noise”.  The data that costs too much to fix based on its low impact on the business.  The second is to take that bad data that is too costly to ignore and identify initiatives to resolve the DQ problems – and tie that back to tangible business benefits.  The challenge is easy with “perfect order” delivery problems in the retail supply chain.  Companies know that the penalties are directly impacting the bottom line.  Fix a problem and the resulting money goes straight back to the bottom line.

I’m not so sure its that easy for DQ professionals, at least not with all our DQ problems.  But I’ve been around long enough to know that there are some low hanging fruit that exists in just about every business.  As a hint, if your company or customers are suppliers to retailers, you might start your quest for a promising DQ project with your compliance team since often supply chain problems can be tied back to DQ problems.  Imagine that!

 

 

 

 

Single Version of the Truth VS Single Interpretation of the Truth

The recent Data Quality Blog Olympics  with Charles Blyth,  Jim Harris, Henrik Liliendahl Sørensen got me thinking about this more in depth. From a pure technical standpoint, can you have a single version of the truth? Does it necessarily have to be a shared version of the truth? I’m thinking you can have a single version of the truth but it doesn’t have to be a shared version of the truth. I think what you can’t have is a single interpretation of the truth.

In simplistic terms, data is the data – wherever you get it from. You need to define it and define it well. For instance, the color of the product – as I define it – is “blue”. The height is 6 inches. I define my fields for the height and the unit of measure for that height as well as the color. Those are absolute values. They are the truth, per se.

Let’s try a few more relatively simple ideas. Pretend I am run a store. In my store I like to assign a “customer number” to each of my customers because that’s what I started doing dozens of years ago. My preference is to use their social security number (yes, I know it is a bad practice, but I choose to do this). However, some customers don’t have a social security number. I need to have another method of assigning them a number so that I can uniquely identify them. I now have to have a method to

1. capture and store the social security number
2. identify that the social security number is the customer number (perhaps I store it twice – once in SS# field and once in the customer number field, perhaps I use a pointer, perhaps my business logic looks to the SS# field and only looks to customer number field if SS# is blank)
3. create a customer number if SS# is not available.
4. make sure that the created customer number can be uniquely identified as not being a SS#

Now, I know what the customer’s SS# is if they have one (assuming they gave it to me). I also know that my customer number is – which may or may not be their social security number. My single version of the truth for the customer number is whatever number I have for them – SS# or my created number. I need to interpret – perhaps – whether it is a SS# or not.

Perhaps that’s not a good example. What about transient data like “ship to address”. Is the current address accurate? By accurate do we mean “do they live their now?” or do we mean “did we spell it correctly?” Do we keep previous versions of the address so we know history? Still, the information is absolute – whatever the answer is. And we know it is kept separately from “billing address” though the two might be the same. If we want to know who we ship products to, we can know based on ship to or billing address – and doing sales analysis separately against both can yield different results. But the actual data is absolute. And we know when each sale was placed for each ship to and billing address.

Marketing, sales and the finance department might all look at the same data set and interpret it to mean different things, but the absolute numbers are still the same thing. They may aggregate different pieces of information – like color, size, and price by ship to address or color size and cost by customer number. All those pieces of data may be absolute, but the end result of the use of that data is a different interpretation of the impact to the business.

I’m still having problems with the various case studies for why you can’t accurately and definitively assign absolute values – a single version of the truth – to a field of data. Perhaps its free form text fields that are left to interpretation? Perhaps it is that some of the data entered may be inaccurate? If it is only entered in one place and then electronically shared to other secondary instances of the field (in other systems) you still have a single version of the truth – it just may not be accurate. Is it because we just don’t want to capture the same information in 5 different ways to satisfy the different usages people will have for it? I know that different states and different railroads refer to rail crossing information fields differently. But if the authoritative body defines the meaning of the fields that it uses, the various other entities may interpret this information in their own “language” but it is still defined by the authoritative body.

Perhaps I’ve been lucky in my work so far, as the problems seem to always be in executing on the rules once defined (someone put width in the height field).  Yes, initial agreement on definition can be tough, but agreement can and should be reached.  It may be a leadership issue rather than a data issue if you can’t.

What are your thoughts? Give me some examples of where you can’t have a uniquely defined field in your line of work. Are there different industries, lines of business, or organizations where this is more difficult?