Main content

Unilever becomes a software provider to digitize its global distributive trade ecosystem

Phil Wainewright Profile picture for user pwainewright April 26, 2024
Unilever has assembled a 'platform of platforms' from Google, Adobe, Mulesoft and others so that it can deliver an integrated set of digital apps to its global distributive trade ecosystem.

Prashaant Huria, Unilever, speaks from behind a podium at Adobe Summit 2024
Prashaant Huria, Unilever (@philww)

Walk into a local store almost anywhere in the world, even in a remote rural or mountain settlement, and you'll most likely be able to buy familiar household brands such as Omo, Persil, Comfort and Dove supplied by global giant Unilever. A worldwide network of sales reps and distributors keeps those consumer packaged goods (CPG) on the shelves at millions of these outlets. To bring digital efficiencies to this distributive trade ecosystem and protect and grow its market share, the company has had to become a software provider, equipping storekeepers, sales reps and distributors with a set of connected digital apps to handle promotions, orders, fulfilment and billing.

The distributive trade is particularly important in emerging markets in Asia and Latin America. Patterns vary in different regions, with distributors in Latin America tending to carry products from a broad range of companies, whereas in Asia the distributors tend to exclusively carry products from a single CPG company. The shift to digital platforms is also bringing new venture-funded players into the market. After trying out various approaches in the past decade, Unilever recently embarked on a project to create a single platform that it could use globally and adapt to the business models and local needs of individual markets. It has already started rolling this out in selected markets — initially the Philippines, Thailand, Indonesia, Bangladesh, Pakistan and Turkey.

Unilever chose to buy rather than build, composing what project leader Prashaant Huria, VP and CTO for Distributive Trade, calls a "platform of platforms." Data and analytics run on Google Cloud, the mobile and web apps run on Adobe Experience Cloud — including functions such as catalog management and merchandising. There's a separate Distributor Management System (DMS), while connections between these components and out to other systems are managed in Mulesoft. He comments:

The buy-versus-build decision was not hard, but it's the work that you have to put in to really ask the right questions for the business — to really understand what are the right design principles, and therefore what should be the ensuing architecture? That is the hard graft, so to speak. Once you've done that, I think the buy-versus-build just falls off it, as as a set of outcomes...

You need to understand how to put things in which are also not just about the costs and flexibility, but also about scalability. You're talking about hundreds and thousands of distributors, sales reps, and you're talking about millions of retailers. So you know that you need to put the right architecture in place. And you have to go fast. And it has to perform. And you need to make sure that the local variations are kept to a minimum, and that it can all integrate into the architecture really well.

Starting from the customer

The system covers the entire demand chain, starting with demand generation, moving through order capture and fulfilment, and including credit and payments. It also has to provide customer support and digital adoption tools and training, while being as simple, efficient and seamless as possible for every individual to use across all these activities. End-to-end visibility is crucial, so that the impact of events such as cash settlement and inventory allocation can be seen straight away. He explains:

If I'm a sales rep or a retailer, then I know how much stock is actually available. When I order, the distributor won't have to make an embarrassing call to say, 'Oh, you ordered so much, but you'll only get half of that,' and then the retailer would cancel the order.

Thinking through user experience issues like these was crucial to getting the design of the system right. He goes on:

The architecture thinking was a very important thing. But to come up with the architecture, you have to ask the right questions ... That entire experience has to be thought through. You need to really think about that first. And then you say, 'Okay, what is the best thing here to do? What do we buy? What do we build? And if we are buying, then how do we make sure everything is integrated?' ...

You start always with the customer problems. What are the problems that they're having today? And then, with the architecture, where do you want flexibility? Meaning, there are known unknowns. We don't know some things around credits and payments. So you need to really think about, 'Okay, do we need to solve for that today? Or do we just provide a platform where we can plug and play in the future?' And what do you want to have control of because of speed or cost, and where you're absolutely okay to have commodity systems? Those things are what actually guided to build the right platform of platforms.

It's about scalability and reach. It's about improved innovation. And ultimately, it's also about working with the ecosystem of right partners, to ensure that you can create a mutually beneficial network.

When integrating the various components, it was important for the architecture — particularly around the front-end and the DMS — to adhere to MACH principles to allow for future flexibility. He explains:

It's not only composable, but it's also got pub-sub components, so you can actually publish and subscribe to which services you want to have. In future, if we want to replace some elements of it, we don't have to re-integrate everything. We just have to change the integration layer. Because the hard part is, you don't want to mess around with re-testing of the downstream systems. We'll have to do some of it, but I think it will be a lot easier. In the olden days, you would hardwire this, and then it becomes like an impossible project to do. So flexibility was the name of the game — speed, and flexibility.

Operating like a SaaS vendor

Even though the major components of the platform come from established technology vendors, Unilever itself has had to take on several of the characteristics of a Software-as-a-Service (SaaS) vendor for the project. For example, instead of the traditional model within Unilever, where IT operates as a separate function that delivers projects to the business, a product-led model was adopted, with cross-functional teams owning each of the activities. He goes on:

We brought together teams of experts from business process, from user experience, technology, and we reorganized the teams altogether — not just temporarily, but actually as a permanent organization change.

We now have squad leaders for each of these activity systems, and we give people who are in each of the squads very clear OKRs. They report into that squad for all intents and purposes. Of course, they come from the engineering team, and they come from user experience teams as well as from process experts. No different to how a modern enterprise software company actually operates.

This product-led model was then further refined by adding a role similar to the customer success function in a SaaS business, to ensure that local market needs are acknowledged. He explains:

While this [squad model] worked in defining the right products, features and capabilities, after a first market launch, we quickly realized that we will need a single point of accountability to partner with the markets. We took a lead from the customer success manager role in many technology and SaaS companies. We instituted a market success team role, who was responsible for the successful deployment needs of the market...

They understand what's happening across the squads and the entire platform and the products, but then they're really focused on one market at a time. They were selected from the squad leads to ensure the end-to-end accountability and ownership was there, from design to deploy.

Any bottom-up input from the market success role about potential design changes is evaluated against various criteria to decide what priority to assign to it. He explains:

It should be solving the retailer pain points. It should be solving for the growth objectives. It should be solving for all of the streamlining of the operations and making life simpler for our sales reps as well.

Once you've done that, then you look at the legal and fiscal aspects in parallel, and you say they absolutely have to follow local legislation, laws, everything has to be done properly. And then you say, 'Okay, what are the different markets asking for?' And if that should be part of the core product?

That's where the top down, bottom up, come together. The top down, you need to have a very clear strategy, at some level, product by product, across these activity systems — what do we want to do? And bottom up, you need to, obviously, understand, engage the markets. But also manage expectations, clearly, that there are some things we need to do now, and you'll get, and some things will come later.

No time for customization

It's important to have everything built into the core product rather than as a custom add-on. As he explains, the business need is to move fast, which means that customization is not an option:

One of the advantages of a platform of platforms approach is, because things need to move so fast, you actually don't have to customize too much, because the business case will not allow you to do that.

Let me explain exactly what I mean by that. If the changes have to be implemented in a very short timeframe, the benefits of making that change and enjoying that change — in terms of the realizing of those benefits — the cycle time is too short for that. You will never have a real case to choose to customize it.

If your cycles are a year long, or two years, then you can say, 'Okay, I'll customize it,' because having that technical debt is worth it. Here, having a technical debt will never be worth it. So actually, you really discourage loads of customizations.

The combination of the squad model with an all-cloud MACH architecture means that in principle changes can be rolled out almost instantly. But making sure that they are understood and adopted by users puts practical constraints on those timescales. He says:

We can now do the releases much faster, from even quarterly down to weeks. And ultimately, because we have a single codebase, we can even do it daily. The problem is actually the change management time in a market. We can go as fast as the market basically can go.

There's a balance to be struck. He goes on:

There is always a balance not to make it overly arduous and complicated, such that nothing gets done. So you have to make calls. That's where I think we have very good squad leaders, who are able to actually have a vision and a strategy and say, 'Does it fit in with that or not?' And if there is a new idea that a market is coming up with, then is that valid just for that market, or actually can it work for other markets as well? So really, it's how enterprise software companies do their product roadmapping.

My take

In the early days of SaaS, one of the predictions frequently made was that enterprises would ultimately themselves become SaaS providers to their customers and to channel partners. To some extent, today that's true of pretty much every business, ranging from the simplest self-service customer service portal through to online banking apps and the like. But what Unilever has done here goes to a whole new level of sophistication, one that's even more impressive in being based on a combination of underlying platforms from the likes of Adobe, Google Cloud, and Salesforce's Mulesoft subsidiary, and delivered globally, almost to every corner of the earth.

What I find fascinating is the extent to which the team building this 'platform of platforms' has had to transform itself to operate just like a SaaS provider, with a cross-functional, product-led development process, a customer success function, and a highly adaptable MACH architecture. It underlines the extent to which the SaaS model is not just about how the software is delivered, but also requires a fundamental change in culture and mindset, one that drives towards frictionless processes and is centered on customer outcomes.

A grey colored placeholder image