Case Study

Building the foundation for traceability at scale.

Digital Transformation • Enterprise Systems • Product Adoption • Change Management

The Mission

When I joined Olam after business school, I joined the team responsible for Olam Direct — a platform designed to enable direct procurement from farmers.

At its core, Olam Direct existed to solve two problems.

The first was farmer-level traceability. As sustainability and certification requirements became increasingly important, Olam needed visibility into where produce was coming from and how it moved through the supply chain.

The second was pricing transparency. By connecting directly with farmers, the platform aimed to reduce dependence on intermediaries and create a more transparent procurement process.

By the time I joined, the platform had already been rolled out across Indonesia Cocoa and several coffee origins in Latin America. I worked alongside Swaytha Rajagopalan, who led the program, managing a cross-functional team responsible for scaling the platform further.

Learning That Rollout Is Not Deployment

One of the first things I realised was that launching software and achieving adoption were very different things.

The platform was live across multiple origins, but every rollout still required significant engineering effort. Different countries had different procurement processes, languages and operational realities.

Adoption presented an even bigger challenge. In some origins, teams were using the platform primarily at warehouses rather than at procurement centres where many of the intended decisions were actually being made.

I often felt digital adoption was being treated as a vanity metric. Teams were willing to allocate budget to software deployment, but far less attention was being given to training users, building support structures and helping people change the way they worked.

A product isn't rolled out when the software goes live. It's rolled out when behaviour changes.

Brazil Changes The Rules

After spending my first few months supporting ongoing rollouts, migrations and new modules, I was given ownership of Brazil Coffee.

At the time, it was one of the largest digital programs being undertaken within Olam Information Services.

Most earlier deployments served smallholder farmers with relatively simple workflows. Brazil was different.

Our users were large landowners, brokers and sophisticated commercial operators. They tracked commodity markets, negotiated actively and expected a significantly more polished user experience.

We moved from a single daily price to dynamic pricing integrated with coffee trading systems. We expanded from supporting a handful of product variants to dozens of coffee grades, each with its own pricing logic.

The challenge wasn't simply building new functionality. It was understanding that we were now solving a fundamentally different problem for a fundamentally different user.

When Performance Becomes The Product

Brazil also taught me a lesson I still carry today.

At a certain point, performance becomes the product.

We spent months working through API bottlenecks, infrastructure constraints, release management challenges between iOS and Android, and even server location decisions to reduce latency.

It was my first exposure to the reality that users compare software against the best products they use every day, not against the complexity of the systems behind them.

Building A Template For Coffee

The visibility from Brazil led to a new opportunity.

I joined Deepak Kaul's team to help lead digital transformation initiatives across Coffee globally.

Procurement, warehousing and processing each had their own products, workflows and data structures. Many of them solved similar problems independently.

Farmer information existed across multiple systems. Quality parameters were defined differently depending on where they were captured. Pricing calculations lived in separate applications.

One of my first projects was helping define the foundation of a common coffee template and creating an Origin Map module that would act as a bridge between different systems and processes.

Digitising The Warehouse

One of the most impactful initiatives during this period was warehouse digitisation.

At many locations, operational information was still captured on paper and entered into SAP at the end of the week.

The goal was straightforward. Capture information digitally at the point of execution and make it available across the organisation in near real time.

This reduced data latency significantly and allowed traders, operations teams and business leaders to make decisions using current information rather than historical snapshots.

The Hardest Part: Change Management

The biggest challenges were rarely technical.

The hardest part was securing alignment and buy-in across regions.

Every origin had legitimate reasons for why their processes were different. Building a common template required understanding those differences, identifying what genuinely needed flexibility and what could be standardised.

The goal was never to force every business into the same process. The goal was to create a shared foundation while preserving the flexibility required to operate successfully in different markets.

What Olam Taught Me

Understand The Business Before Designing The System

The best product decisions came from understanding how procurement teams, warehouse operators, traders and field teams actually worked.

Don't Force Digital Adoption

If a digital process creates genuine value, people eventually adopt it. If it doesn't, no amount of reporting or dashboards can compensate.

Own The Outcome

What mattered most was taking ownership of the outcome, fixing what needed fixing and continuing to move forward.

Looking Back

When I joined Olam, I expected to spend most of my time working on technology.

Instead, I found myself learning about procurement, agriculture, warehousing, trading, supply chains and organisational change.

The biggest lesson was that digital transformation is rarely a technology problem. More often, it is a people problem, a process problem or an incentives problem.