Digital transformation: a technology transformation or an IT refresh?
Glyn helps untangle the difference between a technology transformation and an IT refresh, illustrating why it's important not to approach them in exactly the same way.
Name
- Glyn Darkin
Date
- 9th December 2022
Recently, I was wild camping with an old school friend. He was telling me about a purchase he’s made for his business.
He runs a custom kitchen design and fitting business and he just bought a new CNC (Computer Numeric Controlled) machine for cutting the kitchen cabinetry. He said it was the easiest business case he had ever made to his board. It cost £150k and he will cover the cost in three years with the machine only working two days a week.
I sat there thinking about his business. He makes kitchens, but he advertises on Instagram, conducts his client meetings over Zoom, models everything using 3d CAD packages and is now automating his production line.
He is digitally transforming his business, but unlike a lot of digital transformation initiatives his was exciting, because it was directed towards growing his business and transforming how he works to deliver more value to his customers. So, why is his digital transformation so different from many transformations I see, those that are painful, chaotic and problematic?
A digital transformation is really a transformation of value
We have all seen presentations declaring why your business could be the next Kodak, or how you should change your operating models to be more like Spotify’s. Yet these transformations often struggle to deliver value and become multi-year initiatives which burn people out while losing sight of the customer in the challenges and chaos of the transformation.
Reflecting on many of my own personal experiences over the last twenty years, and my friend’s exciting transformation, I came to realise something quite obvious. My friend was transforming the value stream of his business, the systems and processes that add value to how he engages and delivers his product/service to his customers - not the IT systems that he uses to run his company.
The two types of technology projects in enterprises
This epiphany lead me to realise that there are two types of technology change in an enterprise organisation looking to transform.
IT transformation
The first and most common type of technology project is the IT transformation. It’s often lead by the CIO organisation and includes cloud migrations, SaaS services and generally getting rid of things like spreadsheets and automating business processes as well as integrating data sets to produce KPIs and other forms of reporting. The portfolio is focused on the internal systems, which the employees use for the day to day running of the company, the engine house of the organisation.
The projects typically use commercial off the shelf solutions (COTS) and technology refreshes to deliver change. They are cost focused initiatives as the solutions are not differentiated. Its focus is typically on ERP, intranets, CRMs and CMSs in the form of DXPs. These are all important initiatives, but they have start and end dates, requirements which are either out of the box or well understood and delivered using best practise and domain expertise. This work is typically outsourced and price sensitive.
These transformations are run to create better employee experiences, greater organisational and operational efficiency and to reduce overall operating costs. With the three primary internal enterprise level metrics being centred around Lead to Cash (L2C), Trouble to Resolve (T2R) and Concept to Market (C2M). The need for change is obvious, but the business cases may not be as clear cut as buying a CNC machine.
The transformation of the value stream
The second type of transformation, like my friends business, is the transformation of the value stream. That’s the product you sell or how you deliver your service. The classic example being the ecommerce website, once a sideline to a retailers strategy, now typically the number one way a customer interacts with a retailer.
Today, there are many ways a company can transform their offerings using digital technology, from starting your car remotely using your phone, to using analytical data to build better, more value adding, products. It’s about transforming how you do business and the products you sell.
The budget for this type of change sits with the CMO, CPO or CTO and it is time and value sensitive. These projects are about trying to change your business so that it can survive, meet growth targets and stay competitive. All the while you’re looking to build differentiation.
This is accomplished by building custom solutions and solving complex problems, with great uncertainty as to how your customers will interact with your new offering. The business cases for these types of transformation are much clearer, if you build X and sell Y you will make Z. But they have a much greater risk profile, so require a different way of working and thinking.
The value in understanding the two types of technology change
Why do I differentiate between these two types of technology change? Because all too often we treat them as the same type of change. We force IT projects to use agile ways of working when in reality the requirements are well understood and the main priority is delivering on time and on budget, we have all heard the complaints of “this is not agile”.
On the other hand, we treat our technology projects, dedicated to creating or evolving value streams, like IT projects. Ignoring the complexity of customer needs, never conducting any user validation or testing. ‘Go live’ is also treated as the finish line, when actually it’s only the beginning of the journey.
We’ve also all seen projects doomed to fail which were locked in as part of a 3 year budget cycle, despite everybody knowing they will ultimately deliver no value as the product going to market will never be validated.
Get better at knowing when to use the hammer
As the IT and technology industry has matured our toolkit has become expansive. But, with this range comes responsibility, we need to be better at knowing when to use the right approach. Do we just need a hammer, or something more delicate based on the problem we’re solving.
There is no one size fits all approach. We cannot force ways of working that don’t drive value. What’s needed to achieve this is a clearer way of defining the value and validation points on these transformation journeys so that we can identify the right models, processes and talent for the projects we have to hand.
Simply put, the methodology, processes, people and tools used to deliver an intranet Sharepoint migration are not going deliver the same value when used to design an innovative digital product.
Understanding this is how we can deliver value without causing more problems in the process, removing the pain and chaos along the way.