CS-04 · Case study · Dealer Management System · India

One system for 500+ dealers: orders, billing and stock

The Opal Labs · India · 2018–21 · Role: Business Analyst

Aditya BankarAditya BankarSenior Business Analyst / Product Owner · 3 min read
500+Dealers on one system
~50%Faster report turnaround
BRD · SRSRequirements owned end to end
APIsIntegration requirements for scale

The context

Companies that sell through dealers need to know what each dealer ordered, what they were billed and what stock they hold. When that information sits in separate tools, planning turns into guesswork and reports take days.

At The Opal Labs I was the business analyst for an integrated Dealer Management System and billing platform serving a country-wide network of 500+ dealers.

The problem

The platform had to solve four problems at once:

  • Orders, billing and dealer stock needed to live in one place, so everyone worked from the same numbers.
  • Inventory planning needed reliable dealer sales data.
  • Reports were slow to produce and errors were hard to trace.
  • The system had to perform across hundreds of dealers as the network grew.

My role

  • Gathered and documented business requirements and processes, and translated them into BRD and SRS documents.
  • Defined data and API integration requirements for scalability and performance.
  • Built reports on dealer sales and inventory to surface ordering patterns.
  • Worked with technical teams and business stakeholders through delivery.

The dealer order flow

Each column is a team or system. Green badges mark the points the design had to get right.

Scroll sideways to see the whole diagram →

Dealer order flow from order to reportingDealerDMSSales teamReportingDealerneeds stockPlace orderin the DMSCheck price listand stockApprove anddispatchBill the dealer,update stock1Sales and stockreports2Plan nextorder
  1. 1Orders, billing and dealer stock live in one system.
  2. 2Reports run on live data and take about half the time.
Start Step Decision End Each column is one team or system. Arrows show hand-offs.

The approach

  1. 1
    Map the dealer order journeyFollowed an order from the dealer's request to billing and stock update, and noted every hand-off.
  2. 2
    Write it down onceCaptured the processes and rules in a BRD for the business and an SRS for the technical team.
  3. 3
    Design for scaleDefined data and API integration requirements so the platform could grow across the dealer network.
  4. 4
    Let dealer data drive planningUsed dealer sales and inventory reports to find ordering patterns and shape planning requirements.
  5. 5
    Speed up reportingReworked report generation and added performance dashboards for tracking errors.

Sample work: requirements extract

IDRequirementPriorityAcceptance
DMS-SO-01Dealers can order only products on their active price listMustAn inactive product is rejected with a clear message
DMS-SO-04Dealer stock updates when an invoice is postedMustStock report shows the new quantity within one minute
DMS-RP-02Monthly sales report by dealer and productShouldReport runs for 500+ dealers without timing out
DMS-RP-05Report errors are logged with the failing recordShouldError log names the dealer, report and field

Illustrative extract written for this portfolio. Real requirements are client-confidential.

Results

  • 500+ dealers on one integrated system for orders, billing and stock.
  • Inventory planning and sales order processing improved.
  • Report turnaround cut by about 50%.
  • Error tracking improved through performance dashboards.

What I learned

  • One source of truth matters more than any single feature.
  • Write the integration requirements early. Scale problems are expensive to fix late.
  • Reports get used when they answer a planner's actual question.

Client details are anonymised. Diagrams are redrawn and all figures are approximate.