Key Principles for Delivering AI Outcomes in Large Enterprises By Walid Mehanna

You have first-hand experience of working through various tech hype cycles – the internet, distributed computing, blockchain and now GenAI. What’s your take on the GenAI hype cycle? All hype cycles occur because of human nature: we get overly excited, and then we get overly critical. And often the truth is somewhere in the middle. So what tends to happen with every cycle is there is always a period of hype followed by a period of awakening. And the question is: how significant is the awakening; how useful, and how timely?

So blockchain, for example, is a very exciting technology but I believe its time hasn’t come yet. Maybe it will be mainstream one day, but maybe it’ll remain niche. We’ll eventually find out. But when we look at GenAI, there will always be substance that’s brought in, and there will be waste in terms of attention, money and investment that went into the technology but didn’t lead anywhere.

So the first key challenge for me and my teams is to identify the right inception point. When does a technology become relevant for us, and could it be a competitive differentiator? We need to be ready to leverage it at that point. For example, in the case of quantum computing, there’s a lot to observe. We’re actively being involved in discussions and we have a solid foundation of understanding what works, what doesn’t work, and what’s happening in the market where we have investments. So we double-down when it becomes relevant for our operations and business models.

For GenAI, after ChatGPT in November 2022 –that was the inception point for us, because it was becoming mainstream.

It’s always a question of finding a good balance between the over-selling and the over-hyping, versus leveraging the potential and the substance that is already there. And for me that’s a leadership challenge, not a technology or sales challenge. It’s a leadership challenge to separate the hype from the substance and put the substance to good use.

Could you talk us through how you utilise data and AI at Merck?

I strongly believe in two things: one is that you can’t separate data and AI. If you want to succeed with AI, you need quality data that’s specific to your business and your processes. Quality is the key word here. Everyone has data, but if your data is a waste product or a side product, it won’t help you with the AI. So, if you’re really interested in leveraging AI to gain a competitive advantage, you must take good care of your data.

The second thing is that data and AI can’t be an ivory tower capability. Obviously, you need central organisations – global organisations like mine – as a catalyst, a governance entity, strategic entity, cultural change entity. But it can’t be a delegation of accountability. The accountability for data and AI needs to be embedded in everything we do as an organisation.

We want to have our understanding and capabilities as deeply embedded as possible in the organisation. But we also want economies of scale, and need to be very disciplined in our usage of technologies that can easily become very expensive.

When you approach a data product, you think in three different dimensions. Can you explain that approach?

Historically, we would have different scenarios: either a new system we’re building, an application, or even just a dashboard. People would look into the source systems and identify which data they need, then they source this from different systems. Because the data doesn’t directly connect to each other, people would then build mappings and clean the data. Alternatively, there would be a data set somewhere they get access to from a data warehouse, a data lake, or some other application. That’s the shortcut.

But then they find out that this data is not complete, and they need additional data. So, they start to build what I like to call Frankenstein data sets, because essentially it’s a second-hand data set that’s then enriched by firsthand data. Nobody has a lineage of that data.

So, a data product is a more strategic approach for us. Currently we’re going top-down with different data domains and what we’re trying to do in the future is to push responsibility for the data as close as possible to the point of creation. We haven’t implemented data contracts; we have limited data lineage for a lot of systems, but for others we do have good lineage.

So we want to establish that transparency, and most importantly, the right accountability and responsibility across the organisation. We’re also aiming to support it with the platforms available to deliver good quality, to monitor the data and pipelines.

Sometimes there’s the need for a quick fix. We like to call it ‘stop the bleeding.’ Obviously, that’s a priority, and that’s okay. But after you stop the bleeding, there’s a tendency to stop even more bleeding, put more patches on it. But that’s not a sustainable or healthy solution.

So the second part of the journey – the more strategic part – should be to heal the patient. So, how do we get to these healthy behaviours and healthy setups? Ultimately the solution lies in those who create the data, and who have awareness that this data is an asset to the organisation. That should be part of their daily job, and should ideally be incentivised as such. And they need to be transparent about what happens with their data.

This is why I’m also a big fan of data marketplace approaches, because with these you can see how that data is used. People are generating business value with it, and customers are delighted because my sales reps have that information that I made available to them.

At the moment, we don’t have a real economy of data; we just have people trying to make gold out of coal, which is no easy task. But again, it’s a journey and it’s an organisational transformation at scale. They bring everybody on board.

We always like to talk about what I like to call the holy trinity: people, ways of working and technology. And you have to start with the people.

How about these other two dimensions that go with the data product: the platform and the analysis aspect?

To a certain degree, the data generation is the first mile of our journey. And getting there isn’t typically something data folks have in mind. When we talk about data, people always start with the extraction of the data, but they don’t pay any attention to the creation of the data.

So we need to introduce the quality mindset at the point where the data is created: where people put something into systems, or where interfaces are built, or where data models are designed, or when a company is acquired, for example.

That’s the first mile. And when we talk about the second, third, fifth, tenth mile, that’s essentially how data is made available for secondary use in the organisation or shared between systems.

This is where the platforms come in. Because I don’t believe in one size fits all, and I don’t believe in the Highlander principle when it comes to technology, because that would be too much of a lock-in. I’m a big fan of global standards, I’m a big fan of open source. I’m super excited about Apache Iceberg, to see that become a relevant piece of our architecture and our global standard.

The platforms for me are fundamental parts that must be effective and efficient in scale across the company. And because of that, we decided to take our key platforms and integrate them into what we call the data and AI ecosystem. We even gave it a name: UPTIMIZE.

UPTIMIZE is essentially our brand promise to our organisation. We called it UPTIMIZE because it’s well integrated and it’s safe, secure and compliant. And the different components work as seamlessly as possible together.

It’s a journey: our ecosystem isn’t yet perfect, but it is improving significantly. It’s growing with every product increment, every three months. And we also have a multitude of analytics and AI products that are built on top of that ecosystem. They can be fully-fledged applications, simple dashboards, API services that we make available to our organisation. That’s what our community of people, our practitioners, our sector hubs, and also our individual contributors leverage and build.

You often say: ‘AI has both a first-mile and a lastmile problem.’ Can you tell us what you mean by that?

So, the first-mile problem is the creation of data. This creation is governed by data specialists. Often, there’s this detachment between the data creators and the other employees in the business, who say: ‘that’s nice, but that’s not my reality. I still have to write stuff down and somebody else maybe types it up if he can read my handwriting.’ Or: ‘I have to put in the same information in four different systems and I don’t know where they ever end up.’

That’s our first-mile problem. If you start the data journey on the extraction of data from operational systems, you’re already at a disadvantage. If you’re serious about it as an organisation, you have to start at the creation. And that’s the people on the ground and the systems we give them.

Discipline, good systems, and ideally automated data capture – those are the things that can solve our firstmile problem and could also ease a lot of pain further down in the value chain of data and analytics AI.

Currently, only a handful of companies have that strong foundation, and really think about data this way, and expose data so that every team in the organisation has to do it. Consider the API mandate by Jeff Bezos at Amazon. That’s one of the very few examples of companies that have these first principles in place and can reap the benefits of data mindset literacy, and consequently have quality data available at scale.

How does a large, complex company tackle that problem?

Step by step. You have to preach, to sell the concept, and you have to collaborate. And at first you have to put some kind of Band-Aid on it. When somebody has to input data into four different systems, you can build a ‘plaster’ powered by AI to make sure the data is pushed into four different interfaces but is consistent. That’s an emergency solution that ‘stops the bleeding’.

But if you want to heal the patient, obviously you have to talk about enterprise application architecture and interfaces. You have to start talking about data languages and data models that people agree on. So, if you have three, five, ten thousand applications globally, which large corporations typically have, none of them have ever been built with a target state in mind.

These always have been built based on what the new data model is for this system. We take either what’s coming out of the box or alternatively we do a project, and we start to think about how a data model should look.

But these approaches aren’t strategic. There isn’t a data domain, an ontology in place, and there’s no mapping available. Or, you do it as acquisition, and end up with another 500 systems you’re inheriting where you don’t have a fighting chance to integrate them.

So, ultimately what you want to do is to define your target state, your strategy, your semantics ontologies, your data domains, and then you need to get disciplined to map to them.

But you also need to be prepared to continuously evolve them, because your business might change. You might acquire companies who have a different business or that know more about you, about the single domain, and therefore it’s a journey. And the question is: do you know where you want to go, and do you have a plan of how to get there? Or are you just firefighting and putting Band-Aids on everything to stop the bleeding?

How would you describe the last-mile problem?

Well, the last mile is essentially how we translate it into the day-to-day running of the organisation. We’ve seen so many dashboards and reports that are fancy and look enticing, but then are not used regularly and become outdated.

So, how do we really get to scale? How do we embed this in our routines? And for that, obviously, we need to talk about user experience and user interfaces, but we also need to talk about things like responsiveness, data availability, and processes.

When you have a new fancy analytics in AI product, a new application, you need to consider: how do I need to work differently to utilise this? It boils down to what we mean by digitisation. Does digitisation just mean that we do everything the way we did previously, but with a tool that maybe gives us 5 or 10%? Or do we rethink the way we do business because of the new possibilities that we have?

This is the one thing where, because of our federated setup, I need to rely on my partners on the ground in the sector hubs, but also in the spokes. Because our remit is so broad, we can’t be an expert in all fields we operate in like all fields we operate in, like material science and electronics, and also with key opinion leaders, and doctors in neurology, in healthcare. So, that’s exactly where our federated approach comes in.

But ultimately, this is a team sport, so the senior leaders and the middle management must understand digitisation as an opportunity that can help us to up our game.

We can be an early follower, we can be a late follower, we can be a laggard, but ultimately things will change and it’s up to us to find out how they can change. And we’re coming back to the experimentation and how we really make a difference for those we serve.

Can you describe your thoughts on the term ‘use case’ and why it can be problematic?

The central technology where we document is still called ‘the use case portal’, but I’m not a big fan of this term. Because when looking at it from a business perspective, the term use case feels to me like an old man with a hammer looking for a nail. I saw an interview yesterday with Tim Cook, the Apple CEO, and he was asked: ‘Apple has never used the term ‘AI’. Why?’ And his response was: ‘As a company, we don’t focus on the means to an end, we focus on the end. We don’t need to tell our customer that it’s AI, and that’s why we’re not actively using the term.’

Similarly, for me, ‘use case’ is about the application of technology, but I’m not interested in showcasing the technology – that’s the sales mindset. I’m interested in the business impact and the value for the people we serve, for our patients; our customers.

I prefer to have the mindset of a solution builder, someone who understands a pain, an opportunity, and builds a solution to cater to it, rather than applying a technology in a use case to showcase that technology. So, we try to establish the product mindset across all categories. We talk about platform solutions, things like AWS, Snowflake and Foundry. We talk about data products to make sure that a data set is high-quality, actively managed and governed.

Then we talk about the last mile, which is the analytics and AI products, which are solutions to ensure that we’re delivering the insight and the functionality needed to solve a business problem or realise an opportunity.

Do you have any final thoughts that you’d offer to current data and AI leaders, or aspiring leaders of complex organisations, who are trying to make data and AI work at scale?

My recommendation would always be: don’t worry too much about scale. Focus instead on the impact and value – the difference that you can make in the lives of those that we serve. Our patients; our customers. And if you make sure you’re delivering on the promise, either directly or indirectly, depending on your responsibility, then you’ll be on the right trajectory.

The second thing is, as you’re doing this, also try to think about the future and try to minimise the proliferation and diversity of technological depth. Try to limit the technological complexity, process complexity and process depth. Because ultimately that complexity will hinder your attempts to scale at a later point in time.

But I believe scale shouldn’t be the only priority. Scale is only useful when it’s built on top of the impact and value that you give to the organisation. Otherwise, scale will be unachievable.