Please stop using the term "Digital Transformation" because:
It's a lazy, hackneyed attempt to get eyeballs on your consultancy/conference/linkedin page so henceforth I am piping all email containing the phrase to /dev/null. Do not send me a connection request if you have it on your Linkedin page. Just don't. Let's put "Data Transformation" to bed. For reasons of indolence or prescience (you choose) I quote myself in this short blog with the added benefit that I get to kill it quickly (but not softly), plus I also get to make a serious point at the end about data storage, rendering and delivery being the real challenge for everyone.
In 2019 I wrote a blog entitled "Cloud is old news. Discuss." where I noted "...the cloud consultancy business is relatively mature now and most of the aforementioned charlatans quickly ran off to rebrand themselves as Blockchain Consultants and are currently plying their meagre wares as Digital Transformation Consultants." [From <https://financialreasoning.com/cloud-is-old-news-discuss/> ]
Bad news, we haven't hit the Gartner "Trough of Disillusionment" with this one yet so they are still amongst us peddling their snake oil.
To fit with the zeitgeist here’s what ChatGPT replies to the request to “Explain Digital Transformation”:
”Digital transformation refers to the process of using digital technologies to fundamentally change how an organization operates and delivers value to its customers. This can include things like automating manual processes, using data and analytics to make better decisions, and developing new digital products and services. The goal of digital transformation is often to improve efficiency, drive revenue growth, and stay competitive in a rapidly changing business environment.”
Ie. Exactly what folks have been doing with IT for the last 70 years or thereabouts. So let's deconstruct "Digital Transformation". Aggregating a collection of references trawled from the internet I got to a view that it is:
Digital_Transformation={process+business_model+domain+cultural}*transformation
[I know - scientific eh? And not at all contrived… 
]
Here's a succinct synopsis of what that really means:
1. Process transformation - doing the stuff you already do only more efficiently/effectively.
2. Business model transformation - doing stuff you didn't previously do, such as going after new markets.
3. Domain transformation - using new tech - generally all the waffle out there boils down to "moving onto cloud". See earlier comment re "Cloud is old news", and recall it's from 2019.
4. Cultural/organisational transformation - explain why #1/#2/#3 is happening so everyone in the organisation understands why you're doing it.
So essentially "Digital Transformation" is just using IT to improve your business processes and do new stuff. Again, just what we’ve been doing with IT these past 70 years. Didn't the Lyon's LEO machine automate the routing of deliveries (amongst other things) in the 1950s so we could have our Battenberg cake and eat it (pre-staling)?
RPA ("Robotic Process Automation" for the troglodytes) was relatively pertinent, although I made the point that RPA was the "corporate drug of choice" (https://financialreasoning.com/431-2/) in 2018 and that its premise was flawed even then. I fully accept that the automation of some processes has been bungled in some cases, often by a rote codification of the existing (semi-)manual process rather than reviewing it from first principles. That's just poor specification, it doesn't require a magic "Digital Transformation Consultant" pixie dust to fix it, just some common sense to fix what was a bad IT project functional specification.
Now that we've cleared that up please point it out to all the Digital Transformation Emperors out there that their new clothes are translucent and they can now stop clogging the channels with generic, content-free hand-waving. None of "Digital Transformation" is new or revolutionary so just stop.
To anyone that persists with using the term:
From now on if you continue to bang on about "leveraging synergies", taking us on a "journey" and “addressing business agility" then you should note that your only contribution to our day will be to provide a quasi-stochastic feed for a game of BS bingo(*), and we will know that you are probably:
1. An IT Consultant that wanted a new self-aggrandising job title;
2. A bodyshop sales rep that wants to push staff;
3. A consultancy skilled at interviewing as many of a firm's staff as possible then writing up everything they were told in a glossy document and presenting it back to the client for a large fee.
I'm prepared to give some of you the benefit of the doubt and consider it possible that you were simply misled and may actually have something genuine to offer. In which case, to help you to stand out from the Translucent Emperors, consider these points:
• Be specific regarding your offering - how is it differentiated?
• Is there a genuine technological edge to what you do?
• Do you have specific domain knowledge that distinguishes your service?
• Can you roll out some convincing case studies where you are able to elucidate exactly what you did on the project and have it backed up by a reference call with the client?
Where we really need focus:
Let's move to where the pain really lies in organisations. We need to talk about "Data Resolution" not "Digital Transformation" because if any industry has issues to resolve it's in the provision of a single ratified source of their data via timely distribution channels, and data, by definition, is already machine readable - so digital. Firms are bedevilled by replicated, dissonant datasets that cannot be rendered in an appropriate form in the required location in a timely fashion. They are swimming in cess pits of data. Every firm that has been around more than a year or two will have legacy datasets scattered across data lakes and SQL warehouses that demand reconciliation and ever more complex joins and views to deliver the required data to consumers. This data then gets transformed and copied around through various ETL operations to satisfy different hungry consumers and before you know it you have an overly complex data monster that nobody can control. In the same way that process automation requires a first principles approach data frameworks need to be based on a few immutable rules.
• It must be possible to store any data we want to keep
• It must be possible to retrieve any data we stored from anywhere in our organisation
• There can only be one logical internal source location for any single item of data
• There must be a thesaurus to resolve synonyms - think RICs, ISINs, CUSIPs, tickers, …. (hello Magtia!)
• Any data item we store must be owned by someone, preferably someone who understands it
First we had data warehouses which were lossy, then we had data lakes which became swamps, then we fed warehouses from lakes which kinda worked but duplicated data, now we have lakehouses, fabrics and meshes which (variously) remove the duplication but also row-level permissioning and further reduce the query capabilities. I am yet to hear of a production instance instance of a lakehouse/mesh where data storage is distributed and unstructured, access is fully abstracted and self-service, and governance is centralised. There is much work to be done. Let’s focus on this instead of clunky wordplay.
* Note: we play BS (Business Speak!) bingo with your pitches so tread carefully.