The Parallels Between RPA and Fax Automation

Fax Machine

There are times when the cheap and nasty solution is so economically efficient that it can preclude doing it properly later on.

Background – The Fax

Just under a decade ago, I was working with a local authority client and their NHS hospital partner. The interpretation of the law at that time was that email was considered a non-secure channel. Fax was at the time the chosen channel since it was considered to be secure.

So documents were sent from the hospital, via the fax machine to the fax machine in the social care offices. Continuing Health Care panels met to decide on whether the NHS or the local authority paid for the care, based on whether the primary need was a health need or a social care need. That’s simplifying the logic behind the process and the decision but it’s enough detail for this article.

To be able to make that decision on tens or hundreds of thousands of pounds per year per person, that panel needed to review the data about that individual carefully. So this meant that 40-150 pages per person would be faxed from the hospital to the social care office.

The process for this was relatively convoluted:

  • the hospital professional (therapist, nurse, discharge planner, etc) collates the documents
  • they ring the social care office and tell them they’re about to send the documents
  • they feed the documents into the fax machine
  • they’re sending more than the fax machine can fit into its auto-document feeder, so they have to standby to top it up
  • at the other end, the fax machine starts printing
  • the social worker picks up the paper before it falls onto the floor
  • the fax machine runs out of paper (several hundred pages per panel and it’s likely that you’ll have to refill the paper)
  • the social worker obtains blank paper, loads the fax machine with the new paper
  • the social worker collates all the faxes
  • the hospital professional rings the social worker to confirm that they have the documents.

The First Proposal – Email

Naturally, the partners want to make this more efficient so the design conversation usually reverts to proposal of email. But, as mentioned earlier, that’s not considered secure. Or at least the email solutions available at that time were not secure.

But there is a strange alternative.

The Implemented Solution – Fax Gateway

We used fax gateways at either end. It turns an email into a fax to be communicated on the phone line, to then be converted back to an email at the other end. The revised process was a lot more efficient:

  • the hospital professional (therapist, nurse, discharge planner, etc) collates the images ready to be sent (e.g. prints to file or scans in the remaining few that they don’t have electronically)
  • they send an email containing the fax header and the documents to their fax gateway
  • at the other end, the fax gateway converts the received fax into an email for the social worker.
  • the social worker reads the email and downloads the attachments ready for the panel

It’s a solution that shouldn’t have existed. It relied on old technology but until the law caught up with the technology (or the technology caught up with what it had to do to be secure, e.g. nhs.net accounts, etc), then it was the cheap, workable solution. But it was messy and I shudder every time I think of it as a solution. However it made it better for the clients, making the process simpler for them as end-users and freeing up time to do more important work.

Front-End RPA

That’s what the current state of RPA feels like to me. Not the whole of RPA, but the element that’s involved in the user front-end of systems. It’s like the fax gateway. So instead of the better solution of orchestrations between the various IT systems involved, we’ll automate the front-ends.

The Parallels

Now I’m wondering if we’ll see the same situation with RPA as we did from implementing the fax gateways. We found ourselves with a cheap and nasty solution which then made the business cases for full integration prohibitive.

Why would you spend hundreds of thousands of pounds on a better solution when the cheap one works adequately?

So if that angle of RPA solves the automation from a front-end, replacing the mundane tasks performed by employees, why would we look to orchestrate the back-end?

Will initial RPA implementations deter us from better integration of products? And, more importantly, is that necessarily a bad thing? After all, my NHS and LA client were still able perform better with the cheap solution than they were able to without it, and they also avoided a costly integrated solution. In the end, it was a temporary measure until secure email became a practical solution for them and their partners. I’d expect to see parallel initiatives nowadays with RPA, with clients improving their efficiency through the introduction of RPA, but avoiding more costly integration. Especially, as a temporary measure that will likely have a longer-than-intended lifespan.

Look at the Evidence – the Spike and Delay Pattern in Social Care

signature
A number of years ago, I was transforming a city’s social care directorate and, as part of that transformation, we aimed to reduce the time it took to do anything when interacting with the service. The transformation was based on a more fundamental need to free up workers to be able to do the work they were meant to do rather than having to fight the fires caused by delays and resulting failure demand. I instigated a methodical approach for identifying which cycles to focus on first. As the team progressed through the cycles, I noticed a pattern; it’s the spike of activity followed by a lengthy delay as discussed in a previous article.
As we looked in particular at a few cycles of spike followed by a delay, I routinely advised the team to question the need for that common feature of bureaucracy: the signature.

Why require a signature?

In the case of social care, signatures are often required from service users or their representatives. This can be as proof that the content of a form is accurate or as a record of the service user providing consent (either for data to be shared from the form or for the authority to request data from other agencies).
These signatures create the spike-delay pattern in which a short spike of activity is followed by a lengthy delay while the authority sends the form to the customers and waits for the return of a signed copy. Part of that delay is caused by the postal service in both directions. Part will be the time it takes the service user to open the letter, read the form, make amendments, find an envelop and stamp and then go to the post box. Considering the high percentage of infirm service users compared to the general population, that sequence of activities can take a long time. Then we have the additional wait time caused by processing the response as it arrives into the authority.

First approach

So, my first instinct is to remove the need for a signature and thereby remove the need for the spike-delay round. This could be changed from requesting a signature to providing information on the form that the data will be used. If you don’t agree, don’t submit the form. The response from staff was that we needed the signature as a record of consent and/or accuracy, depending on the form in question.
On the fact of it, that seems a reasonable and fair response.

What does the evidence say?

However, the data showed a different reality. What actually happened is that, even if the form wasn’t returned, the process could still go ahead. True, it didn’t go ahead for every service user, but the fact that it could proceed implied that the signature wasn’t always required. Or rather, wasn’t required all of the time. We were able to look at the data to understand how many service users progressed without signature, we were able to look at common characteristics, etc.
By presenting this understanding back, we ended up moving forward in our joint understanding of the process; joint in that the consultant and the team had the same understanding. Before that point, they had had different interpretations.

So where does that leave us?

An undocumented process or exception is a risk. In the above case, we had uncovered that some of the cases were allowed to progress without signature, but there was no documentation defining which cases could proceed and which cases had to stop. Instead it was left to individual judgment, but again without defined criteria. So what happens if the usual staff members weren’t present? Were the decisions they made equal and equitable to all involved? How did we measure the outcomes?
Depending on the type of organisation and service involved, there will be a different focus regarding the risk involved.
In this case, we had a process with an unclear gateway, e.g. do we continue or do we halt and wait?
  1. Complete the analysis in terms of understanding when the process can continue.
  2. Engage with service users to understand what they need out of the process, what their engagement should be
  3. As a team, choose a default option, either they progress by default or they pause by default
  4. Help the team define the rules that govern the exceptions
  5. Implement a training and induction programme for ensuring that everyone knows how to apply the rules
I always prefer the default option to be the one that improves efficiency, e.g. the one that’s the most common option or the one that removes a spike-delay pattern.

Impact

The wider understanding that, in most cases, the signature wasn’t required let us to a better solution. Had we not challenged either with data or further questioning, we would have been left with the difficult situation of lack of signatures stopping the process and the resulting action of requiring signatures in order to proceed. Instead by challenging the assumption and developing solutions to the issues of the spike-delay caused by several signatures for a sequence of documents, we were able to reduce the expected time from 6 months down to just over one day (actually 2.5 completions per week). That’s a massive difference in expectations for customer and the organisation serving the customer.
Anything to say, get in touch at @alanward.

Designing for Everyone

Crowd of lego people
Crowd of lego people

Whatever system, process, technology we’re implementing, shouldn’t we be designing for everyone? Or at least everyone in the target customer segment?

Background

In the last couple of weeks, I’ve read a number of articles that have consolidated and made me reflect on my thinking about designing for disabilities and what counts as normal.

Having spent a number of years working in the health and social care sector, I’m well-versed in the practicalities of working with people with disabilities. But I still hate the phrase “people with disabilities” and every other similar phrase I’ve ever seen. I don’t like the word inclusion, not that I don’t like the concept itself, but that I don’t like that the concept has to exist. Hence the title of this article as “Designing for Everyone”.

What’s an average person?

I read The Atlantic’s article on how we’ve ended up with a definition of a normal person. That’s at the crux of a lot of the disparity that we can see in the thinking of a lot of designers; they design for the average person or people similar to themselves. By using the term designer here, I’m not necessarily thinking of an artist or a creative, but rather the person responsible for delivering a changed process, a changed organisation or a changed way of working. They may have a creative background, but often are from their own professional background, e.g. in the front-line work or a change management professional. Fortunately, a more creative influence is coming into the change profession, for example we’re seeing newer methodologies such as Design Thinking, Service Design and Inclusive Design.

The problem with most of these approaches is that they develop solutions for the average person. There may be several average people in the target. These personas should have been based on the likely customers that the service wants to attract/serve. But considering how many conditions and disabilities there are in the world, there’s no way to account for all of them. Instead, we’re back to averaging again and possibly some Pareto analysis to account for 80:20 of the target population. That still leaves 20% who are not included in the thinking behind the design.

And that’s part of the theme of the article; that by defining a normal, we start to react towards the average as the ideal and the non-average as divergent.

How can we be completely inclusive?

Microsoft have released their Inclusive Design toolkit. The start of the toolkit is a touch simplistic, especially if you’re worked in health and social care, but it gets interesting part-way through. I’m also aware that the beginning portion could still be a incredibly valuable education source for those not used to having think from this perspective. So for that reason alone, I’m grateful to Microsoft for having released it to the world.

But more than that, there are a few nuggets of quality information in that method that I haven’t seen written down anywhere else. I’ve had to reign in proposals by pointing out difficulties of interacting in the proposed manner, so the 2 points below resonate with me.

The first is the potential to abstract away from individual conditions and dis(abilities) to perform tasks and instead focus on the interact between the person, the technology and the environment. That way, you can focus on resolving issues or improving the interaction between the person and other people in the context of the environment and the technology used.

The second is that disabilities do not need to be permanent. There’s a description of a spectrum from permanent through temporary through to situational. And there are more people in situational or temporary with difficulties than with permanent disabilities.

I’ve cropped the slide here and clicking on the image will take you to Microsoft Design Practice.

Disability Spectrum showing difference between permanent, temporary and situational disabilities
Disability Spectrum

How do we include views of everyone?

This is an old source for me, but one that I still point people to when they’re thinking of how to approach their change programme. Beware though, it only becomes inclusive if you included a wide range of people in the interviews and in the service design. It’s a concept of Experienced-Based Design that I’ve seen from the health sector. It’s the best example of a co-production/co-design methodology that I’ve seen.

There are two sources for this: The King’s Fund and the archived NHS Institute for Innovation and Improvement.

Conclusion for Designing for Everyone

Implementing changes for people with disabilities is difficult to achieve since you’re already on the back foot with that perspective. We can see this by the difficulties involved in making websites accessible when that’s been added as an afterthought. Instead, by bringing the focus on a more inclusive design up-front in the process, we have the opportunity to design changes that suit many more people.

Above, I’ve listed a few articles and methods that could help influence others around you. The main item to take away concerns perspective; anyone involved in change has to be able to shift perspective to include that of all customers in the target segment.

Applying Lean Startup in the Public Sector

Yesterday, I presented at #Leanconf 2013 in Manchester. It was the first Lean Conference covering Lean Startup in Europe. There was a great energy to the 2-day event with a variety of planned and unplanned talks plus lots of opportunity to network without the usual tradeshow conference feeling of being stalked by sales managers.

I don’t think I’ve seen a community spirit like that in a long time; every attendees helped someone else no matter how far along their own ideas were.

Pivoting as used in Lean Startup in Public Sector
Pivoting as used in Lean Startup in Public Sector

In the spirit of the energy that I encountered at the conference, I’ve placed the slides on slideshare. If you download the presentation, you can read the notes which will help you make more sense of the slides. Hopefully the video will be online as well soon. When it is available, I’ll update and post a link to it. The slides are at bottom of this article.

Background to the Programme

The programme I discussed in the presentation was a 2+year programme with a large city council in England. The programme was internal to the portfolio that handled Adult Social Care. It had a £1m+ budget with a team ranging from programme manager, business analysts, data analysts and communications officer, plus a governance structure and other associated stakeholders.

The aim was to make Adult Social Care more efficient, by removing waste, focussing on flow and reorganising around the value to the customer. All typical lean concepts. We did this with a mixed method that I’d developed specifically for this client. The method merged elements of Lean with Lean Startup with DSDM and Theory of Constraints, all under a typical local authority governance framework using  Prince 2.

The scale of change was to alter the way of working of 200-300 social workers/care managers, their team managers, their business support plus associated teams. Most were involved in the change and took the opportunity to steer the change in ways that would benefit their service users. Additionally partner teams (e.g. those responsible for 1000+ support workers within the council, NHS staff, payments and contact centre staff) were brought into the process and contributed to the changes where possible.

Customer Development in Social Care

Due to the time available for the talk, I didn’t discuss Customer Development. I’d like to address that here. Firstly, my customers and those of the programme, were the workers on the frontline of social care. However, we also had a duty to their customers, i.e. the service users of the city and, wider still, the overall population of the city.

We used common Lean and Six Sigma techniques (e.g. Kaizenblitz, Voice of the Customer, Gemba plus interviews, workshops, etc) for understanding the wishes and activities of the frontline workers. The default position was always to go and visit the workers where they worked including a visit out to service users where possible and where permitted. There was no “ivory tower” mentality and as little desk-based research as possible.

I did want to get to the wishes of the end user, i.e. getting the answers to what mattered to the service users. We were able to do this through a service user forum and similar activities. Just to clarify, the forum is actually a real meeting, not an online forum. However the typical customer-development approach of “get out of the building” isn’t necessarily a good idea in this case. The reason is that any change has to be ethically sound; it can’t introduce discrimination nor can experiments (or MVPs from Lean Startup) that make the situation worse for those on that trial path.

The ethical dilemma is exacerbated further when you consider the concept of equitability in that any change has to be able to be applied to the entire population of service users if appropriate to them. So if you make a change to services in October, you’d better think about how you’re retrospectively going to apply those changes to service users referred back in April onwards. That could be as simple as a rule stating that they’d change at the next review point or it could be a specific project to apply it now.

A good example of the fundamental ethical issue can be found in the simple concept of asking customers “what can we do to improve?”

I love that question; it encapsulates the whole point of speaking to customers about what they want without biasing them towards a particular solution. It usually turns any negatives about current experiences into positive actions for change.

However, frontline staff wouldn’t want to ask that question of their service users in all circumstances, e.g. those with a current likelihood of being violent, those recently bereaved or in any situation where the service user or social worker is likely to come to harm. That means that the results from a survey of such a basic question would already be biased.

Similar nuances were found in almost every typical method for achieving customer development, whether phone surveys, online questionnaires, paper-questionnaires, focus-groups, questions tagged onto the end of a visit, etc.

Now, as mentioned in the slides, greenfield opportunities such as those found in newly-commissioned projects whether within local authorities or within NHS CCGs (Client Commissioning Groups) are ripe for Lean Startup and may benefit from a more thorough application of Customer Development.

What Messages Can you Take Away from the Presentation?

  • That you can successfully apply Lean Startup in the public sector
  • That if you can do it in local authority (which is about the worst-case scenario for successful implementations), then it should be implementable in other large, existing organisations, whether private or public.
  • That you may not benefit from applying all of Lean Startup; the corollary is true in that you can benefit from using some elements of Lean Startup. It depends on what you are trying to accomplish.
  • That the behaviour of staff (inherited from the culture of the organisation) will likely be your biggest obstacle.

The Slides

 

Any Thoughts

I’d like to hear your comments, so leave a comment below or contact me