Don’t Forget The “Why”: What A Fax Machine Taught Me About Process Improvement.
Recently, for the first time in years, I had to fax a multi-page document through to a company I was dealing with.
Of course, I don’t own a fax machine as it’s not 1995 anymore, but I do still have a USB fax modem which just about did the job. As I listened to the computer dial and heard the old familiar beep and screech of the fax being sent it brought back memories of a time when faxes were common.
As I waited the 20 minutes (yes, really) for the thirty three page document to send, I couldn’t help but consider the ludicrousness of the situation. It is 2021, we have the Internet, we can video-call anyone in the world, yet the only way I could get documents to this particular company was via fax (or by regular post/mail). The issue was of security: They didn’t have any other secure means of me getting the information to them.
As I was watching the progress bar slowly move as page after page slowly got sent, it made me think about how processes are defined in organizations, and specifically how handovers work. In many situations it is information that needs to flow between actors, or put differently, one person (or IT system) provides information to another so that a decision can be made or some work can be undertaken. In this example, I needed to securely get some information into a process, as a customer, from outside the organization.
Think Beyond Format & Channel: Focus on Why
When looking to improve existing processes, it’s very easy to get caught up in thinking too much about the format of the information and focus on improving the channel of communication, instead of asking the fundamental question “why is this information required, and what is the recipient going to do with it?”.
Let’s take my fax example: I was faxing a series of receipts and pieces of correspondence to my credit card company as a supplier did not deliver the service they promised, and had delayed issuing a refund. Imagine we were redesigning this process, with a view to making it more effective and efficient. We might ask: how else could that documentation get to us? We might suggest that the scanned evidence is uploaded to a portal, or perhaps we might center upon an encrypted e-mail solution. Yet doing so would be focusing on a solution too soon…
Let’s imagine instead we ask the recipient why they want the information. Perhaps, for example, they say that they need to:
- Validate details of the items or services purchased
- Establish that the cardholder has contacted the merchant to request a refund which hasn’t materialized
A logical next question would be “what do you do with the information once it’s received?” and “why do you do that?” We might find out that they:
|
# |
What |
Why |
|
1 |
Attach it to a case management system |
In case it’s necessary to refer to the documentation in future |
|
2 |
Read the detail from the scans, and manually key relevant pieces of information against the record (e.g. nature of product/service, price, merchant details) |
To ensure the record is up to date. It is this record that will assist with the final decision making. |
|
3 |
Find the merchant, contact them to validate that the information is correct (as receipts can easily be forged) |
To establish the merchant’s versions of events so that a decision can be made. Often information from customers will be incomplete. |
|
4 |
Ask the merchant why they are refusing to refund the customer |
As above |
|
5 |
Make a decision and either refund the customer or not (and claw back funds from the merchant as appropriate) |
To ensure that customers are refunded when they are entitled/when it is fair to do so. |
In this example there is work being created simply because a historical assumption has been made over the format of the information. It’s been assumed that it must be ‘documentary evidence’, PDF copies of scanned receipts and so forth. Yet (in this hypothetical example) the minute that information comes in, it is rekeyed and checked with the merchant anyway as the documentation itself isn’t trusted.
Ask The Provocative Questions
This is where we can really earn our money as analysts. We might ask the provocative but illuminating question “if we don’t trust the documents, why ask for them at all?”. If we’re going to check the details with the merchant in 100% of cases, why not just ask for a smaller subset of information, e.g. transaction date, time and a brief description of the issue. Perhaps this could be quickly vetted and then automatically directed to the merchant so that they can add their version of events. Supplementary information could be asked for when needed. Rather than asking for “everything we might conceivably need” up front, the process changes to “let’s make everyone’s life easier, ask for the minimum amount, and streamline things as much as we can”. A risk based approach could be taken, a single five dollar refund from a customer who has never requested a refund before is probably going to be treated differently from a ten thousand dollar refund.
Of course, this is just one example, and it’s probably a while since you last saw a fax machine. Yet I’m sure you’ve seen similar patterns on the processes you are working with, where old constraints have become ‘baked in’. It’s our job to question them!
If this topic is of interest to you, you may also be interested in seeing the ‘Brown Cow Model’ by James & Suzanne Robertson, which I am certain indirectly inspired this post!