top of page
Back
Back

Reading time : 20 mins

Untangling Field Procurement & Logistics in a Tobacco Supply Chain

Led the design of a field-ready procurement system that transformed fragmented manual processes into a scalable digital workflow, accelerating approvals, improving data reliability, and enabling cross-team efficiency across the enterprise.

Domain

ERP,  Supply chain,

Procurement,

Field Operations.

My Role

Lead Product Designer

Duration

~75 Days

Client

ITC INDIVISION LTD (IIVL)

Team Structure

Product Manager,

Business Analyst,

Frontend Backend Developers,

IIVL field team.

Pink Gradient Background

20 Second Impact Overview

4× faster procurement cycle, Reduced from 4 days to 1.

100% manual paperwork eliminated across buying, approval, & dispatch workflows.

3× operational scalability, supporting growth from 850MT to 2500MT.

Higher data accuracy, lower operational risk

Offline-first field operations,
Uninterrupted purchasing in low-connectivity rural areas.

Reduced training and supervision dependency

This case study is structured using the 7C – Concerns of Innovation framework, taught as part of the Design & Innovation program at IIT Bombay by Prof. B. K. Chakravarthy.

Timeline view (super clear) - visual selection (1).png

Cause

Why this innovation was necessary

IIVL’s field procurement and logistics operations were entirely manual and paper-driven, involving :

  • Physical purchase slips

  • Handwritten UBC tracking

  • Manual approvals

  • Physical TLPV documents

  • Spreadsheet-based reconciliation

  • Phone calls between field agents, buyers, and warehouses

As procurement volumes grew, the system began to fail:

  • Purchase cycles took 4+ days

  • Paperwork was frequently misplaced or delayed

  • Errors surfaced only at dispatch or warehouse stages

  • Scaling operations meant scaling people and supervision, not efficiency

  • Zero real-time visibility for buyers and warehouses

  • Complete breakdowns in low-connectivity rural areas

  • Multi-day delays between purchase and approval

Digitisation was not a UX upgrade — it was an operational necessity to sustain growth.

Context

The reality we were designing for

Before proposing any solution, it was critical to understand the real operational environment, constraints, and stakeholders involved in field procurement and logistics.

Site image 2
Site image 4
Site image 3
image 102.png

Key constraints identified through requirement gathering and stakeholder interviews:

  • Remote rural procurement with poor or no internet connectivity

  • Entire workflows dependent on manual paperwork and Excel sheets

  • SAP handling inventory and payments, but disconnected from field operations

  • Multiple handoffs across field agents, buyers, logistics, and warehouses

  • Scaling procurement from 850 MT to 2500 MT with the same manual setup

These constraints defined the boundaries within which any digital solution had to operate.

Context mapping revealed a critical insight:

Any digital system that depended on constant connectivity or memory-based training would fail in practice.

The design needed to absorb complexity, not expose it.

As-Is procurement and approval flow highlighting manual dependencies, informal coordination, and late discovery of errors.

as is process flow.png

Comprehension

Understanding the real problem

Focus was on understanding how work actually moved across people and stages, not on individual screens or features.

Through user research and on-ground walkthroughs, it became clear that paperwork was not the core issue.

Site image 2
Site image 4
Site image 3
image 102.png

The deeper problems were not about missing features, but missing system intelligence:

  • Field agents rarely knew what state a task was in

  • The system provided no feedback or guidance

  • Errors were discovered late, often during approval or reconciliation

  • Training depended on tribal knowledge and constant supervision

  • Progress relied more on people than on the process itself

Most steps worked not because of the system, but because of informal coordination:​

  • “Rajesh knows how this works”

  • “Call the buyer to confirm”

  • “We’ll fix it during reconciliation”

Core Insight

The real opportunity was not just digitisation, but to design a system that:

Guides the field agent, enforces correctness, and makes progress visible at every step — even offline.

A single primary persona anchored the problem space

IIVL.jpg

Check

Validating feasibility and risk

Before designing interfaces, it was essential to validate whether the proposed system would actually survive real-world conditions.

Early walkthroughs of the end-to-end flow—from purchase creation to approval, dispatch, and reconciliation—were used to pressure-test assumptions about how work was expected to happen versus how it actually happened.

These walkthroughs surfaced critical risks like:

  • Decisions were happening earlier than expected, often at the point of submission

  • Field actions needed to work reliably without connectivity

  • Uncertainty led users to retry actions, causing duplicates

  • Ownership of progress relied on people instead of the system

  • Lack of feedback caused hesitation and workarounds

Proposed User–System Interaction Flow Diagram

proposed flow.png

Instead of relying on people to remember steps, confirm progress, or avoid mistakes, the system was designed to take ownership of correctness and sequence. It defined when users could proceed, when actions were final, and when the system needed to step in.

Only after this responsibility was clearly owned by the system did screen-level design begin.

Conception

The core innovation idea

With a clear understanding of field constraints and failure points, the next step was to explore how the system could fundamentally change the way procurement worked — not just digitise existing steps.

The goal at this stage was divergence, not refinement.

How ideas were generated

I used structured ideation techniques to deliberately challenge legacy assumptions around procurement, approvals, and data entry. This ensured the solution didn’t inherit inefficiencies from the manual process.

Two techniques were central:

  • SCAMPER — to systematically rethink each part of the workflow

  • Worst Possible Idea — to surface hidden risks by imagining what would fail hardest in the field

These methods helped move thinking away from screens and forms toward system behavior, ownership, and flow design.

SCAMPER was used to challenge legacy procurement assumptions

scamper iivl.png

Used as a risk-identification tool to define what the system must explicitly prevent.

Timeline view (super clear) - visual selection.png
Key directions that emerged

Across both exercises, a few strong directions consistently surfaced:

  • Replace free-text entry with QR scans, controlled inputs, and pre-filled data

  • Combine fragmented steps (scanning, receipt entry, validation) into single, guided flows

  • Shift error handling earlier in the process through inline validation

  • Reverse approval dynamics — enable correction over rejection

  • Design for offline-first execution, not as an edge case

  • Remove technical jargon to reduce training dependency

These ideas directly informed later decisions around state-driven workflows, role clarity, and irreversible action design.

Outcome of this phase

This phase produced a clear set of system principles and constraints that guided all subsequent flow design, validation logic, and offline behavior — before any screens were designed.