From manufacturing to market: how Ambika Foods runs the whole chain on Exactlly

Ambika's production environment is defined before any run begins. Processes, work centres and the rights attached to each are held as masters. A process flow describes the order in which work happens, and an item is mapped to the flow that makes it. Resources, machines and skills are recorded and mapped to the work centres and processes that use them.

The bill of materials sits on top of that structure. Each finished and semi-finished item carries its own production formula, and the formula is not limited to material. Labour components, electricity where it applies and overhead cost elements are held against the item, and the whole thing is maintained production batch wise rather than as a single standing recipe.

That matters more in food than the description suggests. A formula that only counts material describes what went into the product. A formula that also counts labour, power and overhead describes what the run cost, which is the number the business needs when it prices into a distribution market.

Production moves through a defined set of transactions: a production order, a work order under it, material issue requests and issues against that work order, production entries as output is recorded, and transfers between work centres where the item moves. Where a run does not go to plan there are recorded routes for that too, in issue adjustments, excess returns and ad hoc production, so the exception is captured rather than absorbed.

Quality control sits in the sequence rather than beside it. Stock receipt follows, and the production or work order is closed explicitly.

Because every one of those steps is a transaction rather than a note, the reporting is a consequence of the work rather than a separate exercise. Raw material planning, material shortage, work order status, the QC register, stock receipt, production order tracking and summary, and raw material consumption against actual variance all read from the same record the plant created while it was running.

Inventory is managed across multiple warehouses, godowns and depots. Movement in and out is transacted: stock dispatch, stock receipt, finished goods receipt, and inventory issue for both production and non production use. Each item carries its own control levels, with minimum stock, maximum stock, reorder level, reorder days and reorder quantity held against it.

Depot replenishment is implemented rather than left to judgement. A depot's requirement is derived from what it is holding, what it has already promised and what it must not fall below:

• stock on hand at the depot,
• less pending sales orders already committed against it,
• less the minimum stock the depot has to keep.

What is left is the stock request. This is the point where the manufacturing half and the distribution half of the business meet, and it is the reason the two do not have to negotiate: the depot's request is calculated from the same record the plant and the field team are writing to.

Ambika's field team works on an integrated Android application rather than on paper collected later. A salesperson raises sales orders against their own mapped customers, primary and secondary, and records retailer orders on the route. Distributor and retailer mapping, route management and retailer geofencing define where that work is expected to happen and validate that it did.

The application synchronises with exactllyERP in real time. When an order is accepted, stock is reserved against it, which is what connects a visit to a shop with the allocation logic running behind the warehouse.

The same application carries the commercial position of the customer being visited: account statement, customer statement, party ledger and ageing. Sales return requests can be raised, collections tracked and a memorandum cash receipt issued on the spot.

The salesperson's own working record sits in the same place, with expenses and local conveyance, attendance, location tracking, and target against actual for both sales and collection.

The effect is that a field visit stops being an order-taking exercise and becomes an account conversation. The person at the counter can be asked about an overdue balance because the balance is on the screen, not back at head office.

A group that manufactures in one entity and sells in another has to record the same commercial event twice, once on each side. Done by hand, that is two documents that are meant to agree, entered by two people, at two times, with two chances to be wrong. The disagreement is usually found at month end.

At Ambika the counterpart document is generated from the first one. One transaction is entered, and the matching entry appears on the other side of the group. The reconciliation between the two entities stops being a monthly exercise, because there is nothing that was typed twice to reconcile.

Ambika runs exactllyHRMS across the employee lifecycle: recruitment and onboarding, employee information, attendance with biometric integration and a mobile application, leave, payroll with salary statements, bank advice and payslips, travel and reimbursement, appraisal and KRA, transfers, promotions and increments, and full and final settlement. Employee self service covers attendance regularisation, leave approval, loans and investment declaration, and statutory reporting covers PF, ESI, PT and TDS.

It is worth one paragraph rather than a section of its own because of where it sits. The field team whose attendance, expenses and targets are handled here are the same people raising orders on the sales application, which is the point at which people operations and the operating chain touch.