Treat your customer as valuable

Hospital
Treating your customer as valuable could be the first step to understanding what your customer values.
 
Shopping Carts
Shopping Carts

I went shopping in my local supermarket. It was eventful for the number of things that went wrong for me, all of which could have been prevented with some foresight and some real-world gemba.

 
It was early in the morning so I had chance to see the store operate with fewer customers. This also meant that I could move around the store quicker than usual. So from that perceptive, the shopping expedition was a success….at least until the checkout process.
 
For a large supermarket, there were no checkout assistants at that time in the morning. Instead, there was a bay of 4 self-service checkouts. That’s not too bad, I find them very useful when I have a handful of items. However on this occasion I had a full trolley and had no choice but to use the self-service checkouts. The first issue with this is that there is very little space to put items once you’ve scanned them. To keep scanning more items, I had to swap out each bag once I’d filled it. Every time I did this, the machine told me off. This meant that a checkout supervisor had to come across and tell the machine to ignore the missing bag. That dance occurred several times since the trolley was full.
 
I valued the speed and efficiency of being able to pick my items at my convenience. I didn’t mind whether I scanned the items or whether they were scanned by a checkout assistant. However I did mind the lack of planning for catering for shoppers who had more than a basket. And I minded being reprimanded by a machine for solving a problem that it was creating. I’m confident enough that I have zero issues with being reprimanded by a machine; it’s just a set of algorithms encoded by another human. In this case, a human that didn’t foresee the machine being attached to a tiny tray and being used by a shopper with a trolley. But I did mind the rigmarole that it created.
 
Discharge
Discharge

I had a brief stay in hospital a few years ago. Everything ran smoothly until I was discharged. From my perspective, I was still a patient regardless of the official status. I was in hospital, feeling lousy and weak after 5 days of little to no food or drink and due to continue with medication for a further 7 days. Nothing major, but enough that I was allocated a hospital bed (if you’re familiar with the UK’s NHS, that’s a good measure of a condition). I was discharged in the morning, roughly 9:30am and was due the following dose of medication at 10:30am. Unfortunately, medication after discharge isn’t dispensed by the ward staff, it comes from the hospital pharmacist. I spent 3 hours waiting for the hospital discharge to deliver my medication to the ward so I could go home. That meant I couldn’t arrange transport since I didn’t know when I could leave. More importantly to me, the medication I was due at 10:30am didn’t arrive until the afternoon. During this time I occupied a hospital bed, although I think I would have been moved to a day room had the ward been full to capacity.

 
 
 

Analysis

At that time, NHS hospitals in the UK had a 28 day return policy, in that they were fined for patients who were readmitted for the same condition within 28 days of discharge. That goes some way to ensuring that discharges are medically appropriate. Unfortunately it doesn’t go to check that the discharge process itself is appropriate. It’s still focussed on the condition that the person was originally admitted for, rather than the smoothness of the discharge process. It’s as if the patient is no longer a patient once medically discharged, assuming they will be safe in their environment (e.g. home). The actual situation is somewhat more intricate than that but the effect on the discharged patient isn’t any different. To them, they’re still in hospital, still expecting the rest of the hospital services to be working to achieve the full discharge (not just the medical discharge).
 
Similarly, for the supermarket. The main experience was great but marred by the part of the process where I actually get the goods I pay for.
 
In neither of those cases did I feel fully valued. In the case of the hospital, I can forgive easily. However, from the perspective of efficiency, there’s a lot to be said for getting me out of the hospital as quickly as possible, so as to free up resources for others who need them. The more time I spent in the hospital following the medical discharge, the more failure demand I created (simply by being there, not that I created it on purpose). And the more risk of something happening while I was on the hospital grounds.
 
This leads onto the peak-end rule where we attribute a large portion of our memory of the experience based on the peak and the end of the customer journey. So no matter how good a service you provide to your customers, they’ll remember how it ends.
 

How much is too much training?

Hospital ward
I’m divided in this, but lean towards only brief training, just enough to inform them, rather than enough to practice.
 
On one hand, it pays to understand why change in general is necessary and specifically, why the change that you’re about to implement is necessary. Often I see professionals who spend time with the person sat in front of them (and so they are patient-centred) but ignore the mass of people also requiring the same service. It’s not that they can’t see the queue (whether a real standing queue or a waiting list), it’s that if they recognise the queue then they realise that they can’t serve everyone to the same level. For some, it’s a question of professional ethics, where their professional body demands that they treat the person in front of them to the best of their ability, regardless of the needs of others. There are good reasons for that approach.
 
Usually, someone, e.g. a manager or budget holder, recognises the capacity issue and so increases the eligibility threshold or reduces the professional time available for that treatment. This is an attempt to average it out. However it misses the point that some treatments take time to work, if you half the time available, then you may get zero results, not 50% of the results had you allowed the necessary time for full treatment. It also leads to a worsening service as the capacity gets further reduced through a series of cuts, so that wouldn’t be the answer that we’d choose given a choice.
 
More fundamentally, the communities that the local and regional health providers serve are different to those that existed 30 years ago and the changed communities have different needs. So, it seems obvious that we have to adapt the service to meet the changed needs.
 
On the other hand, the health professionals are just that; professionals in health. There will be some with additional skills; some complementary, some tangential. I wouldn’t expect health professionals to be experts at change. However they do need to be aware of the change and why they have to contribute. As do we all, no matter what job we perform, no matter which sector we work in.
 
By recognising the above issues, we can more easily understand why we have to continually change. It’s a matter of adapting to needs. However that doesn’t feel like it requires a formal training in the guise of a university module, more an hour or so during induction combined with some questions during the interview to assess their attitude to change. I expect the professionals to know the service best, so they should be best placed to change it rather than having budgetary changes applied without thought to impact on patients.
 
To get this message across and gain acceptance and commitment from the group, I usually go through the need for change at the start of any change programme and definitely before each intervention.
 
One area where I think some training could be useful is in negotiating and debating how services will change. The changes will happen, but being able to influence the changes could be invaluable. Oddly enough though, it’s probably not the health professionals who need the training, instead it’s for anyone who’s trying to change the service, e.g. performance improvement staff, HR/OD, commissioners, etc.
 
I think the reason for my varied opinions above is that I see a difference between management and change management. I acknowledge that management techniques should be taught in advance as well as broad concepts of changes management, whereas the required, more detailed parts of change management can be taught as required.
 
I don’t believe we should conduct changes without speaking to the end customer. Taking on the role of patient, I’d much prefer the consultant to have spent their time learning how to treat patients, rather than learning how to manage change. Let’s permit some degree of functional specialisation, with front-line professionals continuing to be good at what they do and change professionals helping them create/design the service that the patients need.
 
However, I recognise that many front-line professionals either don’t have access to change professionals or do have access but that they’re not listened to. Hence the need for a book that’s applied for front-line staff.

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.

xTech – Part 1 – Why I’m fed up with tech

server

xtech for Sector x

  • Fintech is challenging the Finance sector
  • Insurtech is challenging the Insurance sector
  • Healthtech is challenging the Health sector
  • Will we see Techtech challenging the Tech sector?

And since new technology is developed every month and every year, would we be looking at a Techtechtech sector in a decade?

It’s seems ludicrous to think of it that way and it is indeed ludicrous. The reason it sounds so odd to have a Techtech sector is that we’re allowing ourselves to be focussed on the technology that’s enabling us to replace the older business models.

Analysis

If you get a nice interface to your banking account and that bank account has a different charging model to the older high street banks, does that make it fintech? According to the hyped world, then yes. But it’s stilll banking. It’s still finance. In reality, the newer entrants are just doing what the incumbents should have been investing in more heavily a few years ago.

In some cases, newer entrants who are smaller are working out how to make a profit without the expectations of having to pay the large salaries of traditional banking, without having to pay large, multiyear leases for high street premises, etc. The main lever they’re using is initially technology, but sometimes it’s other elements of the business model that are being altered. That’s a critical point to realise; it’s not always the technology that is being used as a lever for change.

Customer Channels

Let’s take the example of First Direct, the HSBC bank that had no high street branches and regularly received excellent customer satisfactions scores compared to its high-street cousins. Mint, Smile and Egg all followed with variants of similar business models. They had changed one element of the business model. They had focussed on the channel of interaction, forcing a channel shift from face-to-face to telephone (at the time) and online (later when the technology caught up). Everything else (apart from perhaps some of the branding/marketing) was the same as the high-street.

Business Models

What we’re seeing now is other entrants prepared to look at other components of the business model, such as where the revenue is generated (e.g. subscription versus visible transaction vs bundled transaction cost vs bundled products and so on).

Here’s a simple concept: Take the Business Model Canvas and apply SCAMPER to each section. It’s that easy to generate new ideas and that’s what seems to be happening in every sector.

But this isn’t really fintech. Yes, tech is opening up opportunities and provides the ability to change different elements of the business model that would have been more awkward or at least not cost-effective to change before. But, again, it’s still banking. So let’s just call it finance. The big question for incumbent banks is, rather than relying on their current business working in the future, they’ll have to accept that different models will emerge. And it’s their choice if they want to be delivering those models, enabling others to deliver them on their behalf, or simply be swept away as their market share is eroded by competitors.

Conclusion

Let’s get this straight. I’m not against the concept of Fintech. I’m against the fact that the concept exists separate to the Finance sector (or rather a subset of it). I believe that every sector has a duty to innovate, improve and invent. For sector x, we don’t need xtech.

  • There’s an additional angle to this which I’ll cover in the next article.

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.

Lean Cost Benefit Analysis of a Quick Improvement

Kanban prototype for an NHS Acute service
Kanban prototype for an NHS Acute service
Kanban prototype for an NHS Acute service

Last week, I was provided with the short opportunity to improve a service within an NHS Acute Trust. I had 5 minutes to understand the problem and then I suggested a quick improvement. I’d like to take you through how we arrived at a solution and the resulting lean cost benefit analysis of that solution.

I don’t get that involved in the individual solutions anymore, instead I’m usually engaged for more strategic issues and end up mentoring others to make the changes across the whole organisation or enterprise. So it was fun to roll up my sleeves and suggest a solution that could work in a hospital. I fully expect the team to modify it to suit their specific needs and I’ll be on hand to help them improve it.

So let’s get to the calculations:

Lean cost benefit analysis

Analysis Investment

  • 5 minutes x 1 health professional explaining the problem
  • 5 minutes x 1 consultant listening to the problem
  • 5 minutes x 1 consultant developing a solution
  • 10 minutes x 1 consultant describing how the solution could work and what could be changed to make it more suitable
  • 15 minutes x 1 health professional understanding the solution
  • 1 x flipchart paper
  • 1 x pen

Potential Savings

  • 3.5 hours per day x 4 health professionals across a 5 day week = roughly 2,800 hours a year
  • The 3.5 hours is based on a reduction from 4 hours to 30 minutes for handover and prioritisation.
  • At roughly 1,400 working hours per year (based on 200 days per year and 7.5 hours per day), that equates to 2 FTE (full-time equivalent) posts saved per year.
  • So that could mean the service treating a lot more patients,  a potential cashable saving of roughly £70,000-£90,000 per year or – as is often more likely – a mix of the two

Not bad for a 15 minute session.

Practicalities

Implementation

The solution would need installing, but that’s the easy part. It would require some pens and a whiteboard or similar. That’s probably £200-£400 for a board and magnetic strip and counters plus £20-£50 per year for pens.

The implementation would usually rely on a critical core of the staff wanting to implement the change. In this case, by applying Lean Startup concepts, just one staff member could do it and then the others will learn about how it could affect their working lives and the impact on their patients.

What was the solution?

My suggestion was based on Lean, using a Kanban board. It relies on the principle of visual management. In this case, it’s easy to see at-a-glance where the work lies. It seemed a perfect fit for the problem. Due to the small amount of time spent with the service, there is a significant risk that the solution may not work for all the health professionals involved. I’d have liked more time with more of the team to mitigate this risk.

My aim was to improve flow. There was a blockage in the handover stage of the day and that’s what I wanted to eliminate. With more time, I’d have taken a more relaxed view of the entire process, involving other stakeholders, referring teams and teams that are being referred to. As it was, engaging with only one health professional, I focussed on what could be achieved quickest to remove the blockage.

The kanban board isn’t the end of the solution; it’s the start. I expect the therapists to find that the bulk of their work is being stuck in one or two stages or that they are not able to provide services to low priority cases. I don’t actually know what they’ll find, but that’s what I would be looking for. After the therapy team have been running the board for a week or two, they should be able to see patterns. Then they can act on those patterns.

Perspective

So which appeals more; the lean solution itself or the numbers in the lean cost benefit analysis?

From my perspective, they’re two sides of the same improvement and I teach analysts to remember both sides (and some others) when engaging with teams and their stakeholders.