Skip to content
Nij Web Solutions LLP — Business Operations & Workflow Automation

By process

An Inventory System Where Stock Updates Because Work Happened

Inventory accuracy is not a discipline problem. It is a design problem. If updating stock is a separate task from doing the work, it will be skipped — so the system has to make the work itself the thing that updates the stock.

Who this is for

  • Companies whose system stock and physical stock differ meaningfully
  • Operations where stock is maintained in a spreadsheet updated once a day
  • Manufacturers needing stock by lot, batch, grade, size or location
  • Businesses holding material at several stores, plants or with processors

The problem

Why inventory data drifts

Named specifically, because a problem described in general terms produces software that solves nothing in particular.
  • 01

    Recording the movement is a second job

    Material is issued because the line needs it; the entry happens later, if at all. Every skipped entry is a permanent divergence between the record and the rack.

  • 02

    Consumption is derived, not recorded

    When issues are not booked against jobs, consumption is back-calculated at month end. Yield problems and quiet losses both hide in that calculation.

  • 03

    Returns and rejections have nowhere to go

    Unused material returned to stores, or rejected material set aside, is handled physically but not systemically — so it is either double-counted or lost.

  • 04

    Lot and grade detail is not held

    Two rolls of the same item in different shades are not the same stock. When the system cannot tell them apart, the right material cannot be reserved.

  • 05

    Physical counts are a shock, then forgotten

    A count reveals a difference. It is adjusted without a cause, so the same difference returns next year.

  • 06

    Material with processors is invisible

    Stock sent out for job work is still yours, but frequently sits outside the system — so total stock is understated and ageing at the processor is unknown.

How the system works

What we build into an inventory system

  • Movements as the natural by-product of work

    Issuing to a job, recording output, returning material and receiving goods each post the movement as part of doing the thing — not as a separate data-entry chore.

  • Stock at the level you actually trade

    By item, lot, batch, grade, shade, size, location and bin as your operation requires. Reservations against orders so committed stock is not issued elsewhere.

  • Multi-location and inter-store transfers

    Several stores, plants and yards, with transfers recorded as movements including material in transit.

  • Job work and material with processors

    Stock lying outside tracked as yours, aged per processor, and reconciled on return with yield and loss.

  • Reorder levels driven by consumption

    Reorder points calculated from actual consumption and lead time rather than set once and forgotten, triggering a purchase request with its history attached.

  • Blocked, quarantined and rejected states

    Material that exists but must not be used, visible as such — so it is neither issued by accident nor lost from the count.

  • Cycle counting with variance analysis

    Counts by area or class on a rotation, with variances recorded against a cause, so the same discrepancy is not adjusted away every year.

Automation

What stops being somebody's job

Every rule below is a thing a person currently has to remember. Written into the system, it happens whether anyone remembers or not.
  • Material is issued to a job

    Stock, consumption and job cost update together

  • Production records output

    Finished stock is created and inputs are consumed

  • Stock falls below its reorder level

    A purchase request is raised automatically

  • Material is reserved for an order

    It cannot be issued against anything else

  • A lot fails inspection

    It moves to blocked and leaves available stock

  • Job-work material is overdue from a processor

    It is flagged with its ageing

  • A count variance is recorded

    It requires a cause and an approval before adjustment

None of these need a person to remember them. That is the whole point.

Management visibility

What management can see once this runs

  • Stock by item, lot, grade and location — available, reserved and blocked
  • Consumption against standard, per job and per period
  • Ageing and slow-moving stock, ranked by value
  • Items below reorder level, with lead time and open orders
  • Material lying with each job-work processor, and for how long
  • Count variances with causes, and whether they are recurring

In practice

Situations this is usually bought for

  • Issue against a job, on the floor

    Stores issues material on a tablet against a specific job. Stock, consumption and job cost all update from that one action.

  • Reorder that happens without being watched

    Consumption drives the reorder level; crossing it raises a purchase request with history attached, so purchase acts early rather than urgently.

  • Reserving the right lot

    An order needing a specific shade or grade reserves those lots, so they are not issued to another job in the meantime.

  • Counts that reduce the next variance

    Cycle counts by class, with causes recorded, so the process that creates the difference gets fixed instead of the number.

Before / after

What changes

The specific shifts this work produces — stated narrowly enough that you could check whether they happened.

Before

After

  • Stock updated by a separate data-entry task

    Stock updated by the work itself

  • Consumption back-calculated monthly

    Consumption recorded per job

  • Rejected material sitting in available stock

    Blocked material visible and excluded

  • Annual count shocks

    Cycle counts with causes and shrinking variance

How it works

From operational chaos to a connected business system

Five steps, in this order, every time. The first two produce no software at all — and they are the ones that decide whether the software will be used.
  1. 01

    Understand

    We sit with each department and learn the process as it is actually run — including the workarounds, the informal exceptions and the things people do because the official way does not work. This is where most of the value of the project is decided.

    You getA written map of your current processes, departments and bottlenecks

    1–2 weeks

  2. 02

    Map

    We trace how information moves between people, departments and systems: where it is created, where it is re-entered, where it is lost, and where a decision waits on something nobody can see. The re-entry points are almost always the expensive ones.

    You getAn information flow map, with every handoff and duplication marked

    1–2 weeks

  3. 03

    Design

    We design the target workflow — owners, rules, gates, automations and the screens each role needs — and agree it with the people who will live in it. We also agree what we are deliberately not building yet, and say so plainly.

    You getA workflow design, screen list and phased build plan with scope you have signed off

    2–3 weeks

  4. 04

    Build

    We build in phases, so one department is genuinely using something early rather than waiting for a full system. Each phase is delivered, tested with real data and put into use before the next begins — which is also how the awkward details get found while they are still cheap.

    You getWorking software in real use, phase by phase, with integrations and reports

    Phased, typically 4–12 weeks per phase

  5. 05

    Optimize

    After go-live we look at what is actually being used, which alerts are being acted on and which are being ignored, where people are still keeping a parallel sheet, and what the data now reveals that nobody could see before. Then we improve it.

    You getUsage review, workflow refinements, new reports and ongoing support

    Ongoing

Questions

Frequently asked questions

Still unsure whether your processes are a fit? Walk us through one of them.

Book an Operations Automation Consultation

How accurate can inventory realistically get?

High, but not by decree. Accuracy follows from every movement being a by-product of work someone was already doing, plus cycle counting that records causes rather than just adjusting numbers. Any system that depends on a separate daily data-entry task will drift again, however good it looks at go-live.

Do we need barcodes or QR codes?

They help most where you already label material — lots, rolls, pallets, bins — because they remove typing errors at issue and receipt. They are not a precondition. We often start with selection from a short, filtered list and add scanning once labelling is consistent.

Can it handle stock in different units of measure?

Yes. Purchase in one unit, store in another, issue in a third, with conversions held against the item rather than done in someone's head. This matters in textiles, chemicals and packaging, where it is a common source of dispute.

What about material lying with job-work processors?

It is tracked as your stock, held at that processor, aged, and reconciled on return with yield and loss. Leaving it out of the system is one of the more common reasons total stock never reconciles.

Can we use this alongside stock in our accounting software?

Yes, and one of them has to be the system of record — usually the operational system for quantity and the accounting system for value. We agree that explicitly, build the flow in one direction, and provide a reconciliation report so drift is visible rather than discovered.

Next step

Your business has a process. Let's turn it into a system.

From manual workflows and disconnected departments to connected operations, automated processes and real-time visibility.