I write about what’s stuck with me when I sit down to write my weeknote. I don’t want to assume what’s important, or interesting enough to weeknote while it’s happening, so I don’t take notes during the week to feature in my weeknote. If I’ve forgotten it by the time of writing then it wasn’t worthy of inclusion in a weeknote.
As part of my accidental blogging break this year, I also didn’t open my news reader (yes I am old school). This means I currently have over 8,000 unread articles in NetNewsWire (I told you I was old school). I probably ought to mark all as read and start over, but there’s bound to be some good stuff in there that I don’t want to miss.
So I will scan it all a bit every day and pick out some gems, and post them here for posterity.
Even if we adopt Tom Loosemore’s definition of digital – and we should – it’s still necessary to interpret it in the context of the service you are looking to digitise.
I’ve worked out a really simple framework for thinking about this, by dividing the options into three distinct levels, or approaches to, digital change. None is necessarily right or wrong, but it’s always likely that one is more appropriate to achieving the outcome you desire for a particular service, in a particular context. Moreover, they shouldn’t be seen as fixed – instead, you can evolve a service through the levels as context changes. The levels are digital access, digital redesign and digital transformation.
Digital access
Digital access simply means taking a process that currently doesn’t work on the internet, and making sure that it does. Much of the digital work before around 2012 was of this nature, often called things like ‘e-government’ or, later, ‘channel shift’. A lot of the early efforts were based on putting electronic versions of forms on a website, often as a PDF, which would have to be printed out, filled in with a pen and then returned, either by scanning and emailing or, most likely, sticking it in the post.
That sort of thing isn’t really good enough these days, and so the more modern approach is to have online web-based forms that the user can complete there and then. It’s quick and simple and does one of the most important things – it makes things convenient for the user, at least at the start of the process.
The downside is that these forms when used just for digital access tend to email details to the back office, where a human has to read them, process them, enter details into the line of business system and so on. Also, the user won’t be aware of the progress of their transaction unless they phone up and ask. More troubling is that if services never evolve beyond digital access, it masks a lack of progress and ambition.
Pros
Cheap
Fast
Demonstrates progress
Convenient for users (especially if they are used to paper)
Cons
User will be frustrated with what is still a fundamentally manual service
No efficiency gains for the organisation
Can be a mask for a lack of progress (we’ve digitised all of our services! errrr…)
Digital redesign
Digital redesign cranks things up a notch, and I suspect it is the area where most attention is being paid at the moment. It goes beyond digital access by creating real changes to services when they are digitised. These come in two main flavours:
redesigning processes and user experiences
making the technology work smarter, through integrations and introducing new capabilities
Digital redesign takes longer than access, but the rewards are greater in terms of better meeting people’s expectations and potential for savings and other efficiencies. The outcomes are also less certain, which means risk levels are a little higher – so taking an agile approach is definitely a good idea.
To make this work, you’re also going to need to do things like user research and employ some service design thinking – considering the whole service from end to end from the user’s perspective to ensure it meets their needs, as well as those for the organisation.
Pros
Greater returns from your effort
It’s actually properly changing something, rather than just sticking forms on the web
It’s not so ambitious that people won’t understand what you’re trying to achieve
Cons
Needs more people, more skills, potentially new technology, which means more money
Can take a while, so unless you manage the work in an agile way, it might take time before seeing results
Integrating into back office systems can take years off your life
Digital transformation
So what, then, is digital transformation? Well, when a service is truly transformed for the internet era, it takes a completely blank piece of paper approach to its design. You take as first principles that the majority of your users have access to the internet, wherever they may be, and design around that.
This is the bit of Tom’s definition of digital that refers to business, or operating, models. One of the best ways to describe this idea is to think about some of the new, digital age companies that have come to have such an impact on our lives:
AirBnB is a global hotel company that owns no hotels
Uber is a global taxi firm that owns no cars
Amazon is a global retail empire that has no (or very few!) actual shops
These companies base their operating model design on the fact that the majority of people have access to the internet the majority of the time. It’s what makes hailing a cab via a smartphone app viable.
True digital transformation does the same thing, but with existing services. Note that this is much harder than it sounds – coming up with workable, transformative operating models isn’t an easy thing to do in the first place, but even less so when a service is live and working already, in a mature organisational setting.
Another issue is that some of the rather trite ways that this is presented – “What is the Uber of social care?” – can be rather off putting – over-simplifying what is an incredibly complex web of interlocking services, providers and funding mechanisms. Nonetheless, sometimes a rather blunt way of expressing a problem space like this (“the AirBnB of emergency accomodation!”) does help people start to think a bit deeper about how they might redesign a service from the ground up in the digital era.
The final consideration I would raise here is that many of the business models of these modern internet companies is also based on their access to many billions of dollars of venture capital funding, which is used to fund fast growth, soak up early losses, and establish brand recognition and market dominance. Public services have no access to such funding, although they do often have a natural monopoly – which while is not the same thing, it could perhaps be leveraged to make an operating model redesign more likely to succeed.
To sum up, true digital transformation is extremely rare, but is the pinnacle of what can be achieved when completely redesigning a service for the internet age. As local public services become increasingly cash-strapped, it’s something that more organisations must start seriously thinking about.
Pros
Genuinely transformative, creating services built for the digital age that meet users’ expectations
The kind of change that is needed to protect local public services in the future
You’re likely to attract great people to work on such a project
Cons
A lot of work. You’ll have to go back to first principles and design out from there, which will take time and effort
Risky, there are a lot of opportunities to make missteps, so taking an agile approach will be key to minimising the impact
This requires organisation-wide buy in and support, so building a coalition to commit to this will be a massive job
Summing up
Hopefully that helps. The important thing to remember is that there are different ways of approaching digitisation, each with its own balance of risk and reward. Which you choose will depend on a number of factors, including the digital maturity of the whole organisation and the service itself, the people and tech you have access to, the amount of time you have, and the outcomes you need to achieve.
Also, bear in mind that you don’t have to take just one approach. It’s perfectly plausible to start with applying digital access to a service, then evolving it into a digitally redesigned service, all the while plotting a complete transformation further down the line.
This was originally published as the lead article in my weekly email newsletter. If you’d like to get more of this sort of thing on a regular basis, sign up!
I’m sure folk get bored of people like me banging on about digital transformation being more than web forms, or fancy integrations with back office systems. “It’s about fundamentally redesigning your operating mode for the internet age!” I bellow. “What on earth does that actually mean?” thinks everyone to themselves.
Coming up with a digital age operating model for a service means redesigning it in the knowledge that the majority of your service users, and colleagues that deliver the service, have access to internet enabled devices. It means mapping your value chain, identifying all the components that make up a service, and removing any elements that could feasibly be replaced by networked computing capabilities.
That probably makes no sense. Think of it this way:Â a lot of the value add for services as they are currently delivered involves some kind of intermediary performing a role – linking people up, checking things, making decisions about things. In many (not all, of course!) cases, these days activities such as these can be done by software, connected to the internet, that users and service providers can both access, whether through the phone in their pocket or the corporate laptop on their desk (or lap).
Here’s an example. It’s a somewhat trite one, and over simplified, but has the benefit of being comprehensible. To book a cab, traditionally, one phoned the cab company (where you got the number from is another story, but not an irrelevant one), where someone took details of you and your journey, and they then got in touch with the cab drivers to find who was free and nearby, and then they made their way towards you while you hang around waiting, and hoping. Oh, and you needed to go to the cashpoint so you could pay – and might not know how much til you reach your destination.
Now, in recent times, cab companies have done stuff to reduce some of the friction in this process by enabling online bookings, booking via an app, SMS notifications of likely arrival times, and so on. All these are examples of digital efficiency, not transformation. The service remains essentially the same, and the intermediaries retain their role.
Uber, however, disrupted this by starting from scratch, assuming that everyone (passengers and drivers) have phones with internet connections, apps and GPS. Users can now log the journey they want to make on their phone, and see themselves the drivers available to them, and choose the one they want based on a number of criteria (feedback ratings for the driver, the type of car they drive, how nearby they are etc). Users also know the prices, their payments are handled online with no cash changing hands, and they can track their driver’s progress as they make their way to them. Afterwards they can rate their driver and also receive feedback on how they conduct themselves.
In this way, Uber has removed a whole section of the value chain (the cab dispatcher role) in such a way that makes the whole process both more efficient and delivers a far better user experience, because it takes as a core assumption the fact that the internet and smartphones exist.
So to apply this to a public service, first map your value chain. Identify those areas where you are just providing an intermediary role, which could be replaced by an internet enabled service, that adds little value and just slows things down. Design those roles out of the process, then assemble the tech needed to deliver the new services.
Too often transformation processes skip the value chain mapping element. This leads to fundamental misunderstandings about what benefits services actually deliver to users, and thus miss huge opportunities to improve user experiences and reducing the cost of service delivery. As I have said before, there’s no shortcut around truly understanding the service you are meant to be delivering.
This was originally published as the lead article in my weekly email newsletter. If you’d like to get more of this sort of thing on a regular basis, sign up!
Most of the stories about what organisations are doing on digital transformation tend to get published in the form of case studies, and most of those case studies are written and published by vendors of either technology products or services.
That’s fine, but I do tend to get slightly grumpy with them as they focus so much on the purchase of the technology and what it might deliver in terms of better and cheaper services. “Council X to save ÂŁ300m by investing in the Norpita customer experience platform” – that sort of thing.
Partly the issue is the jumping ahead nature – none of those savings have been realised yet, no software implemented, no services redesigned. All that’s happened is that a purchase order has been approved.
But mostly, it’s because it leaves the impression that the technology is the panacea, that buying the tools delivers the outcomes. Also that this is a quick process, which it isn’t.
First, implementing new systems is hard and takes much longer than anybody cares to admit. Second, the real benefits can only come when radically redesigning the way a service runs, and that takes even longer – particularly as you’ll likely need several stabs at it. Thirdly, those much trumpeted savings? Don’t forget where they are coming from, which is mostly what the organisation spends on people. That means restructures, which will mean more time, and more pain.
This isn’t a reason not to do this stuff – of course not! But sometimes it’s easy to get stuck into the mindset that if we just buy this thing, everything will be ok. You might need to buy that thing to ensure everything’s ok, but you’ll also have a do a load of other stuff, which the case studies never seem to mention.
Remember – you can get things like this every Monday by email if you sign up to Digital Digest.
