SYSTEM ANALYSISFEATURED

Mapping an Agricultural Supply Chain into BPMN 2.0

Mapped an agricultural supply chain from farmer registration to export into BPMN 2.0 for PT Mitratani Dua Tujuh — including a weighing process recorded three times for the same shipment, simplified to one.

Screenshoot of for PT Mitratani Dua Tujuh Information System

CONTEXT / PROBLEM

A supply chain that existed only in people's heads.

PT Mitratani Dua Tujuh runs a partnership model with farmers, from registration through cultivation to export. The operation worked. The documentation didn't exist. Processes lived as institutional knowledge, which makes a system impossible to design against, an audit hard to satisfy, and a handover to new staff a matter of hope.

I mapped it into BPMN 2.0 using Draw.io: 16 core supply-chain processes documented across 18 diagram pages — farmer registration, planting programme, survey, farmer contract, TC, planting, official minutes, agricultural inputs, cultivation, pesticide mapping, residue analysis, raw-material analysis, harvest, expedition, weighing, manual mutation, and DPU, plus an overarching user flow.

APPROACH

Elicit from the people who run the process, then draw what they actually do.

Run elicitation module by module

Sessions with the project lead and the client's process owner, one module at a time. Each module took one to two weeks from first session to an agreed diagram. Findings and recommendations were raised in the review discussion for that module rather than saved for a final report, so corrections landed while the process was still fresh for everyone in the room.

Model the process nobody could afford to get wrong

DPU governs advance payment and receivable settlement between the company and its farmers. It draws data from multiple other modules to arrive at a figure, which means every upstream simplification I'd made had to hold here or the arithmetic would break. Model it wrong and the company doesn't get a confusing screen — it gets a real financial loss. This is the process where I stopped trusting my own reading of the flow and went back to the source for every branch.

Carry the logic through to the build

Once diagrams were agreed, I briefed the UI/UX designer and developers on the underlying business logic and checked the resulting mockups against it before handoff. I stayed with the engagement through pre-UAT preparation.

RESULT / IMPACT

Sixteen processes, one shared source of truth — and one recorded three times.

Core supply-chain processes mapped to BPMN 2.0

Diagram pages, from farmer registration to export

3 → 1

Weighing entries per shipment, after simplification

The finding I'd lead with: weighing was recorded three times for the same shipment. An estimate entered in the field, actual data entered at the weighing point, then re-entered at the factory. Three entries, three opportunities to diverge, and no single authoritative figure — on the process that determines what a farmer gets paid. I simplified it to a single weighing event carried through the system. The resulting BPMN documentation gave the company a shared, auditable reference for processes that previously lived only in individual stakeholders' heads, and a guide for the system build that followed. The constraint worth being honest about: I had one subject-matter expert. Source triangulation — the thing you're supposed to do — wasn't available to me in the way a textbook describes. What I had instead was per-module review with the project lead and a client sign-off step, which catches contradiction between modules even when it can't catch a single expert's blind spot. If I ran this again I'd push harder for a second voice on the financial processes specifically.

HAVE SOMETHING SIMILAR?

Let's talk about the scope