5 Reflections about Digital Deployment at Scale

In this article, guest author John Wilkinson, Independent Consultant across the target operating model/digital arena, talks to Adam Gates, Head of our Insurance Practice, about his observations about digital deployment at scale

Data* has shown that we vaulted 5 years forward in consumer and business digital adoption during the first 8 weeks of lockdown. 75% of people using digital channels for the first time indicate** that they will continue to use them when things return to “normal” though this will hugely depend on the user experience.

In this article, I want to share the top 5 observations from my last 5 years of experience designing digital journeys and operating models and selecting and deploying digital technology.

1. Start with the customer in mind

This sounds obvious but having engaged with 70 companies working in the insurance industry on behalf of a major UK retailer whilst all said that “the customer is at the heart of what we do”, only some were able to demonstrate that clearly.

With that retailer the starting point was identification of what works badly for customers at present (for example the claims process where customers don’t know what is happening, have no clear picture of the path to resolution and feel unable to influence the process) followed by a definition of the ‘customer shifts’ we wanted to achieve, a precise definition of how we wanted things to be different going forward.

When working with the wealth management arm of a major bank who wanted to create a digital target operating model to deliver wealth advice to customers the starting point was to map the desired customer journey and then first look at the technology to deliver this and then the processes and people to deliver the operating model.

2. Early engagement with the technology architects is essential

Financial services companies, in my experience, have a long-term vision for technology often a microservices architected solution where each solution is easily replaceable and connected via an integration layer underpinned by key IT principles (cloud first, everything as a service (SaaS, PaaS etc), API accessible etc) but the challenging question is how to get there when, typically, they are hampered by legacy platforms. A ‘big bang’ change is usually outwith both the risk appetite and resource capability for the companies. At the other end of the scale, I saw one insurer creating a customer layer to sit over the top of the legacy systems. This brought some improvements, but the fundamental legacy issues remained, and it seemed that they were merely ‘papering over the cracks’. The key is to carefully navigate a path through interim states to the target state.

One interesting example I have seen amounted to decommissioning legacy systems by stealth. This involved a methodical process of replacing services provided by the legacy platform with point solutions connected via an integration layer to reduce the reliance on legacy over time.

3. Choosing the right solutions and partners

At a major bank when seeking a SaaS solution, we undertook a rigorous process involving RFI, RFP (written responses to functional and non-functional requirements), model office testing by users, site visits (both the vendor and one of their customers), demos and prototyping. The COO was kind enough to say it was the most comprehensive process he had ever seen.

What was interesting was which assessment categories sorted the wheat from the chaff. Whilst an RFP is necessary, and the requirements can be used within the contract, it did not. It is the most time consuming of all the activities but the high to low spread of vendor scores was just 11%. The best with a high to low spread of 27% was prototyping. We kept the build requirement relatively straightforward but limited the time allowed to complete it. It represented a good test of the agile dev ops capability which some came through with flying colours and some did not.

The comprehensive nature of the overall process also gives good insight into the commitment of the vendors to the partnership.

Establish very clear IT principles for example by choosing highly configurable solutions so you can ‘adopt not adapt’ the technology.

4. Move to a ‘lower code’ environment to avoid IT bottlenecks

At an international financial services company, we had multiple digital tools available but their deployment across a range of clients was limited. We first educated 150 colleagues in terms of the tool and what they could do through a series of virtual webinars during lockdown and as anticipated this created a wall of demand for deployment of the tools which we then prioritised.

We wanted to deploy at scale, but we knew we would quickly hit a pinch point in terms of IT dev bandwidth. We solved this through documenting requirements for a ‘power user’ app that facilitates the deployment of digital tools by non-IT ‘power-users’. We created a (non- IT) Digital Implementation team for this purpose. We were careful in our approach using a modular approach (where the modules can be assembled and reused by the power users) and ensuring maximum configurability (so that client nuances can be catered for without dev resource).

We still needed dev resource (integrations for example) but this ‘lower code’ environment with less reliance on dev resource has obvious benefits.

5. Taking people on the business change journey with you to maximise digital adoption

“We oppose change unless we recognise and accept the need for it.”***
At an international financial services company, we had digital tools available for customers, clients and colleagues. One colleague digital tool enjoyed a 10-fold increase in adoption during 1^st lockdown through necessity. As restrictions eased, usage reduced, though not to previous levels.

For consumers, colleagues and clients, there are a number of models plotting this journey. The most common is Technology Acceptance Model (TAM) developed by Fred Davis and Richard Bagozzi in 1989

• External variables will influence our perceptions before we even get to use the technology.
• There are two key perceptions, perceived ease of use and perceived usefulness.  Perceived ease of use will influence the level of perceived usefulness. Most people are cognitively ‘lazy’ so perceived ease of use is doubly influential.
• If the attitude toward using is negative, then the behavioural intention is likely to be ‘reluctance to use’ or ‘not to use it’.
• The level of adoption and or effort to achieve satisfactory adoption will rely heavily on the behavioural intention.

Successful adoption of change by colleagues is a journey. It is likely to involve

• engagement & communication of the vision and reasons for the change,
• clearly defining the benefits of the tool and addressing any challenges, for example through training or revisiting the way colleague objectives are set,
• highlighting the positives and addressing the negatives,
• appointing change champions, measuring the success, sharing lessons learned and improving,
• Rinse and repeat!

If you found this article helpful or you would like to find out more about how we can help your business achieve the results you are after, please do not hesitate to contact Adam Gates.

*  The COVID-19 recovery will be digital: A plan for the first 90 days, McKinsey, 14^th May 2020

**  McKinsey COVID-19 Digital Sentiment Survey, April 2020

*** Richard Chataway.  ‘The Behaviour Business – How to apply behavioural science for business success’ 18^th February 2020