Tag: transformation

Three levels of digital change

Photo by UX Indonesia on Unsplash

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.

Just what is a digital operating model?

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!

jeshoots-com-632498-unsplash

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.

Remember – you can get things like this every Monday by email if you sign up to Digital Digest.

Photo by JESHOOTS.COM on Unsplash

Buying new software won’t save you money

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.

Photo by Taduuda on Unsplash

There are no digital silver bullets

In a fairly complex world, everyone yearns for a simple solution. The one thing they should do to make things better. The single solution to all their problems. Digital transformation is no different, and many of the marketers working in this space know it – that’s why they usually claim that their ‘platforms’ will deliver everything an organisation needs to change itself for the digital age.

Sometime people read a single solution into things when it isn’t there. A good example would be my post the other day talking about the uses of low code platforms. Several people got in touch questioning my assertion that it was the answer to all of local government’s problems. I replied pointing out that it wasn’t my assertion, and low code won’t fix everything. It might help for quite a few things though.

Overall, I am always very nervous of transformation programmes that have a single view of the operating model of an organisation, particularly when we are talking local government, which delivers such a bewildering array of services that it would surely be impossible to have just one way of changing and organising them all. Are there really that many similarities between running a theatre and processing benefits? Or picking up waste and community development?

Instead, part of laying the foundations of an approach to digital transformation should be developing an openness to trying new tools, techniques and technology, and an awareness of all the possibilities that are out there.

On the tools and techniques side, this means having a really good knowledge of ways of doing human centred design, innovation and delivery. Check out IDEO’s resources on this, along with the 100% Open toolkit, and of course the GDS service manual.

For technology, really consider the capabilities needed to deliver the outcome your users and your organisation want to achieve. See if you can match those to what you already have, but don’t shoe-horn them in. Think about the maturity of the capability you need: if it is really cutting edge, you may need to build it yourself (whether in-house or outsourced); for everything else there ought to be something on the market to suit. Whatever you do, don’t get bogged down trying to build silver bullets – a universal case management system for everything, or some kind of middleware utopia that makes everything talk to everything else. You’ll end up tying yourself into knots and running a huge IT programme, which is nobody’s idea of fun.

As I said, by all means re-use capabilities wherever you can. It might be that you do end up using one case management system for everything, because it works. Great! But find your way there by iteratively re-designing your way through services, matching capabilities to outcomes, and not through the implementation of a grand technology project.

So is there an operating model that can be applied to everything an organisation does? Probably not.

Is there a change process that can be applied to every service you deliver? Probably not.

Is there a technology platform that will enable you to replace every other system currently in use? Probably not.

Should you try things out, find some alignment between the outcome you want to achieve and the stuff you use to get there? Probably, yes.

Photo by Jens Lelie on Unsplash

How low (code) can you go?

There’s an increasing amount of talk in digital circles about low code. These are systems for building systems: ways of using simple drag and drop interfaces to build out workflows and databases to deliver business processes. Some low code platforms of note include Matssoft, Mendix and Outsystems amongst many. There are also a number of more traditional forms and workflow packages that market themselves as low code – whether they are or not I’m never entirely sure. Perhaps it doesn’t matter.

At Adur & Worthing, Paul introduced Matssoft. The team there has built a range of apps, including ones handling HR processes, waste services, asset management, FOI and complaints handling, and a range of housing services. There’s details on Paul’s blog, and it is a great example of how a corporate commitment to a new way of building software to deliver services can see real improvements and innovation.

One of the marketing messages many low code vendors like to trot out is that around the idea of being able to do away with developers. Having managed a rollout of low code and attempted various projects myself, I am not convinced of that. I’m reasonably tech savvy, and yet have never personally been able to build a functioning bit of software with a low  code platform. My brain just isn’t wired in the right way. Largely this is because, at a fundamental level, most low code is a front end to a database, and designing databases well is a skill, if not an art.

So I don’t think low code is a way for organisations to dispense with developers. Instead, it can change what developers do, and speed up the process of getting ideas made into working software. They are especially useful, I think, at the beginning of a transformation programme, perhaps when one is looking for some pilot projects to prototype approaches and methods. Buying handful of licences for a low code platform and churning out a few apps saves a lot of bother compared to procuring some heavy IT designed for some future model that may or may not ever happen.

Low code, in my view, is best suited as a way of quickly building out bespoke workflows that don’t fit easily into an existing line of business system or platform.

For example, most organisations are chock full of spreadsheets and databases (whether made in Access, or a Visual Basic/SQL server concoction) doing small but vital pieces of work. These are often stored in network drives and digital or IT teams may not even be aware of their existence. They also don’t have the advantage of being cloud native apps, with reduced capability when it comes to mobility, usability on a range of devices and can have a high maintenance overhead.

So overall I am a supporter of low code and encourage organisations to explore how it can help consolidate that morass of unknown Excel and Access based workflows into a more modern, usable and less risky platform. But don’t expect necessarily to be replacing big line of business systems overnight, nor saving money by reducing your developer headcount.

Photo by Helloquence on Unsplash

LINK: “Broken words and why they matter”

Digital – as a word – is broken. We have slapped it onto the front of two many old world applications in an attempt to normalise and ‘make safe’ new concepts that at this point saying something is digital is a bit like saying water is wet

Original: http://www.curiouscatherine.info/2018/04/15/broken-words-and-why-they-matter/

Be your own best customer to advance your transformation

One thing that has been taking up quite a bit of my attention lately is how, in the real world, an organisation can do the kind or big picture, strategic transformation that’s almost certainly needed whilst making progress on what might be termed everyday digitisation – the sort of thing that makes peoples lives easier but doesn’t dramatically change the core operating model of the organisation.

I’ve imperfectly defined three ways to attack digitisation before:

  • Access – taking a paper or telephone based process and whacking it online with an e-form (quick to do, few benefits except a bit of convenience for web savvy users)
  • Efficiency – taking that process and digitising it end to end, involving the replacement or integration with back office systems, removing unnecessary admin touch points an so on (takes longer, more difficult, but yields better results)
  • Transformation – taking an entire service and rethinking it from the ground up, knowing what we know about networks and connectivity (really hard, but could ensure the relevance of that service for the next 20 years).

The problem is that transformation is where the real action is, but it is hard, so hard in fact that it’s difficult in my experience to get people to even talk about it. In the meantime, you’ve got folk shouting at you to increase self service or decrease unnecessary demand.

In a recent conversation with Catherine Howe I reminded myself about Ben Thompson’s great analysis of the Amazon purchase of the Whole Foods supermarket chain (Amazon is, I think, by far the most interesting company of our times). In it he describes the concept of Amazon being its own best customer. When building the AWS service for cloud based computing infrastructure, they had a huge customer ready and waiting to use it (and more importantly, test the hell out of it): the Amazon.com e-commerce site. Likewise, having its own in house supermarket would be a great way to build and test Amazon’s emerging logistics business.

This I think gives a hint towards the way an organisation (I’m thinking of my usual local government context, to be clear, although it could work in other sectors too) could start laying the foundations for genuine transformation whilst doing some of the quick wins stuff in efficiency, and maybe a bit of access if they really have to.

By having an idea of what the future big picture might look like, it’s possible to start building things in the here and now in such a way that it delivers the short term gain whilst creating the capabilities, the building blocks, for making the future happen too.

The danger is to drive yourself into a technical cul-de-sac delivering on the immediate requirements which leaves you hamstrung in your ability to execute on the much greater strategic win of genuine transformation when that opportunity arises.

As always the difficulty with this conversation is figuring out what that future looks like. It’s easy to write posts saying “digital isn’t about tech! It’s about changing your fundamental operating model!” but such posts rarely tell you what one of those operating models might be. I don’t necessarily have an answer to that myself (the consultant in me screams “it depends!” at this point) but I’ll post a few thoughts another time.

What I would say though is that the ‘be your own customer’ part of this does point to an organisation in the future being the provider, or perhaps steward, of technical capabilities that can be shared and re-used across a wider (perhaps local) system. However other assets could also play a part in this and it doesn’t need to be a technology focused discussion.

Photo credit: Jomjakkapat Parrueng on Unsplash

Two blockers to radical (digital) change

I was asked this morning for the two main blockers to progress in the various attempts at technology enabled change over the years, whether titled e-government or digital transformation.

Here’s what I came up with – it would be interesting to get your thoughts:

Two main challenges for me would be two elements of core capability. The first would be technology, and specifically software. The main line of business systems in use in most local councils is simply not fit for purpose for the digital age. They are horrible to use, don’t interoperate, work poorly on mobile, don’t offer great customer experience for self service and are dogs for the IT team to maintain. Time and time again, otherwise excellent initiatives at e-government or digital transformation are scuppered because of issues relating to core back office systems. What’s more, the market seems to find it impossible to have an impact on the situation, and so driving the incumbents out is very hard to do.

Second, and possibly more important, are the people issues. First is culture, which is risk and change averse, often because of the role of middle managers, many of whom are ‘experts’ in their service area and extremely dedicated to preserving the current way of doing things. Folk on the front line can often easily diagnose problems and suggest solutions, and senior executives are usually well up for a bit of disruptive change. However those in the middle can slow things down and block progress. The other bit of the people problem is capability, in that there aren’t enough really good people around in organisations to drive the change needed forward, which takes guts and stamina as well as intelligence. Without a reasonably sized army of these people in place, initiatives can get run into the ground very quickly.

Blogged elsewhere: Why tech SMEs are Crucial to Public Sector Digital Transformation

I was asked by my friends at AdviceCloud to write something for the TechUK blog about how small to medium sized enterprises (SMEs) can support public sector organisations in their efforts to transform.

Technology is not the be-all and end-all of digital transformation. However, any organisation looking to disrupt itself in this way must have a sufficiently flexible technology stack to support the radical change that is needed – and tech SMEs are in the perfect place to deliver what digital transformation demands.

Read the whole thing on the TechUK website.