ERP that fits an Indian plant, not a European textbook

The defining architectural choice in an ERP is whether the modules share a single source of truth or synchronise between separate ones. We always choose the former. Every transaction — a goods receipt, a production entry, a dispatch, a payment — writes to one ledger with one set of masters. There is no nightly reconciliation between inventory and finance, because they are reading the same rows.

That is what makes an ERP different from a collection of applications, and it is what delivers the single most valued outcome our clients report: month-end close falling from around twelve days to three. Not because anything is faster, but because there is nothing to reconcile.

The modules we build are procurement, inventory and stores, production, quality, sales and dispatch, finance, maintenance, HR interface, and reporting. Not every client needs all nine, and we never build one that will not be used.

Job work is the clearest example. Material goes out to a processor under a challan, comes back partly as finished goods and partly as scrap, and the accountability has to hold across the boundary for both GST and costing. Packages model this as an extension; we model it as a core inventory state, which means the stock report always tells the truth about what is physically where.

Multi-GSTIN operation is similar. A company with plants in West Bengal and Odisha moves stock between them as a taxable transfer with e-way bills, and consolidated reporting has to net that out. Building it in from the start avoids the very common situation where consolidated numbers are assembled manually in Excel because the ERP cannot see across entities.

Then there are the small things that are enormous in practice: weighbridge integration with tare and moisture deduction, LR number and transporter tracking on every dispatch, quality claims and rate differences settled as credit notes against old invoices, dealer schemes computed on quarterly slabs with retrospective adjustment, and cash discount policies that vary by customer. Each is a day of design and saves a hundred days of workaround.

Ask most manufacturers what a specific product costs to make and you will get a number derived from a spreadsheet updated last quarter, using an overhead allocation nobody quite remembers deciding. That number then drives pricing decisions worth crores.

A properly built ERP can do better because it already holds the inputs: material issued against each work order, actual machine hours, actual power consumed if you connect the meters, labour booked, and yield. We build costing that computes standard cost from the BOM and routing, actual cost from what was consumed, and the variance between them — broken down into price variance, usage variance and yield variance so it is actionable rather than merely interesting.

The first time a client sees this, the common reaction is that two or three products they had been happily selling are losing money. That single discovery has, in more than one engagement, paid for the whole system.

Big-bang ERP go-lives are the reason ERP has a bad name. Everything changes on one date, nobody has used the system for real, and the first month is chaos that damages customer relationships.

We sequence instead. Usually procurement and stores go first, because they are self-contained and immediately reduce effort. Then sales and dispatch, which is where the revenue is. Then production and quality. Finance is often last, running in parallel with Tally for a full quarter until the numbers reconcile exactly, month after month, before Tally is retired.

Each module goes live with its own pilot, training and hypercare. The organisation absorbs one change at a time and builds confidence. It takes a little longer end to end and it fails far less often.

An ERP that only exists on desktops in the office fails at the point where data is created. Goods receipt happens at a gate. Production entry happens beside a machine. Quality checks happen in a lab. Dispatch happens at a weighbridge. Each of those needs an interface designed for that context — often a rugged tablet or a phone, with large targets, offline tolerance and minimal typing.

For management, we build reporting into the same system rather than exporting to Excel: a daily operations dashboard that arrives on WhatsApp at 7 AM, drill-down from any summary number to the underlying transactions, and exception reports that surface only what needs attention. When a director can see yesterday's production, dispatch and collection before reaching the office, the whole conversation in the business changes.

For process industries the ERP is only half the picture. The other half sits in the DCS, PLC and historian, and the value comes from joining them — energy per tonne by product, downtime attributed to a work order, quality results linked to the batch and the raw material lot.

This is where our data engineering practice connects. We read plant tags read-only via OPC, land them in a time-series store, and join them with ERP transactions in a reporting layer. It is the same architecture as our AURA product, and for cement and steel clients it is usually the highest-value part of the whole programme.