Tag Archives: transformation

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

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.

 

Five for Friday (29/9/17)

blogphoto

Five for Friday took a little break for a month or so while I settled into my new job(s). If I’m honest, I am still not completely settled – it takes time getting used to a little portfolio having concentrated on a single role for several years – but I am getting there.

Enjoy the links.

  • Mapping service design and policy design – terrific post by Andrea Siodmok on how service design and policy design meet. Quite a lot of the focus on digital transformation misses out the policy element, and understanding what an organisation’s approach to an issue, and why it has that approach, is vital to defining services that deliver the intended outcome.
  • Digital transformation, or digital fossilisation? – good stuff from Andrew Larner talking about the need to use the opportunity of digital transformation to address big strategic issues around the manner in which organisations operate – not just hard baking inefficient and user unfriendly processes using new technology.
  • Defining Aggregators – you are probably bored of me banging on about Ben Thompson and how good he is, but this is another great piece, pulling together his recent thinking on digital operating models, diving deep into the concept of the aggregator. Now, the aggregator model might not be a good fit for public services, but it’s a great way to get thinking about this operating model malarky.
  • Designing for democracyCatherine Howe applies the ladder of participation model to designing services in the digital age. Making this activity democratic involves the political, of courses, and also links up with Andrea’s post linked to above, where understanding the political and policy context is vital to achieving desired outcomes. There’s loads and loads in here (like does an iterative approach mean the big picture can get missed?) and it needs a good read and mull.
  • YC’s Essential Startup Advice – always take stuff like this with a pinch of salt (one shouldn’t ignore the pervasive Silicon Valley ideology that startups will save the world) but there’s some really good advice in here about launching new services. Much of it focuses on keeping things small and not worrying about scale until you know you have a thing that enough people like to require scale.

As always, these have mostly all been tweeted during the week, and you can find everything I’ve found interesting and bookmarked here.

You can also sign up to get them delivered to you by email, if that’s your thing.