SmartLink
Manufacturing systems

Plant software that matches the shop floor.

Manufacturing ERP in Pakistan is usually bought after one of two conversations. Either the plant and the ledger have stopped agreeing, or a customer has asked for traceability the current system cannot produce. Both are fixable. Neither is fixed by a module list. Working from Karachi, we configure production orders and confirmation, planning, maintenance and quality, joined back to the business system rather than run alongside it, and we scope by walking the site during the shift the design has to serve. What follows answers the questions buyers ask before the technical ones: what it costs, how long it takes, whether an execution system is needed, what the audit trail must prove, and where our work stops.

Scope
Production · planning · maintenance
Quality
Inspection to release
Integration
Back to ERP
Output
Confirmed, not estimated
Overview

If the plant keeps a second set of numbers, the system has already lost.

You can tell how well a factory system fits by looking for the spreadsheet beside it. When supervisors keep a parallel record of output, downtime or rejects, it is because the system asks for data in a shape the floor cannot produce, or gives nothing useful back in return.

We design plant software around what the floor can realistically capture during a shift, and make sure the data flows back to the people who need it. Confirmation happens where the work happens. Planning produces a schedule the plant can actually run rather than an ideal one. Maintenance history lives in the same place as the work orders.

Before any of that, on multi-system sites, we often start with a systems map: every application the plant runs on, who owns it, what it connects to and what stops if it fails. It is unglamorous and it repeatedly surfaces risks nobody had written down.

Scope

What Factory & operations covers

Work spans single-plant deployments and multi-site rollouts, integrated back to ERP rather than run alongside it.

What the work covers

  • Production orders, routings and shop-floor confirmation
  • Demand, material and capacity planning that produces a runnable schedule
  • Preventive maintenance schedules, work orders and spare parts
  • Inspection plans, test results, non-conformance and release decisions
  • Downtime capture with reason codes the floor will actually use
  • A written map of plant systems, owners and dependencies

What you get at handover

  • Configured production, planning and maintenance processes
  • Shop-floor capture designed for shift reality
  • Quality hub with inspection and release records
  • Systems map with owners and failure impact
  • Operator and supervisor training with manuals

Typically involves

Shop-floor terminals Barcode & scanning
Discuss this practice
01

Scoping against a physical site rather than a process diagram

Scoping a plant system begins with a walk, at the time of day the work actually happens. A process diagram tells you that material moves from one operation to the next. Walking the route tells you that the trolley waits by a door for forty minutes, that the operator writes the batch number on tape because printed labels peel off in the wash area, and that one machine is read by a supervisor who transcribes a display into a notebook. Those details determine what can realistically be captured.

Environment constrains design more than software does. Wash down areas, dust, heat, gloves, hearing protection and hands that are wet or oily rule out certain devices entirely. Network coverage is rarely uniform across a site, and the corner where it drops is frequently the exact place goods are received. Establish this early and in writing, because a design that assumes a working connection at every capture point will be abandoned by the floor within a fortnight of go-live.

Layering the scope helps both sides. The ISA-95 model gives a shared vocabulary for what belongs at the control level, what belongs to operations execution and what belongs in the business system, and using it makes the boundary conversation much quicker. In practice most of our work sits at the operations level and above, joined to the business system, with defined interfaces down to whatever equipment can expose data. Drawing that line on paper in week one prevents a great deal of argument in month four.

  • A site walk during the shift being designed for, not a day shift office visit
  • Capture points assessed for environment: gloves, wash down, dust, heat and lighting
  • Network coverage confirmed at every intended capture point before devices are chosen
  • Scope layered against a shared reference model so responsibilities are visible early
  • A written list of equipment that can expose data and equipment that cannot
02

The boundary with plant equipment

This is the practice with the clearest boundary, so it is worth stating without hedging. We deliver software, integration and data. We do not sell, install or commission programmable controllers, sensors, instrumentation, machine level networks or the electrical work around them. Those belong to your automation contractor, your machine builders and your maintenance engineers. What we do is specify what the software needs from them, review what is proposed against that requirement, and integrate with whatever exists.

Integration with equipment is a negotiation with whoever owns it. Where a machine exposes data through an open standard such as OPC UA, the work is well defined and the conversation is mostly about which tags mean what. Where it exposes a proprietary interface, or nothing at all, the options are a gateway from the machine builder, a retrofit sensor from your automation partner, or manual capture. All three are legitimate, and deciding which applies per machine needs the equipment owner in the room.

Safety is a separate discipline and stays that way. Interlocks, guarding, emergency stops and the risk assessments behind them belong to your engineers and your safety advisers. Our systems record and report, and they must never be positioned as a control that prevents a hazardous action. If a proposed design implies otherwise we will say so and decline that part of it. We are not a safety consultancy, and software treated as a safety function without being engineered as one is genuinely dangerous.

  • Controllers, sensors, instrumentation and cabling supplied by your automation contractor
  • Machine integration agreed one machine at a time, with the equipment owner present
  • Open standard interfaces used where available, gateways specified where they are not
  • Safety functions left with your engineers and safety advisers, never implied by software
  • A written responsibility matrix covering every interface between software and equipment
01

Manufacturing ERP pricing in Pakistan

Typical market rates in Pakistan fall into three bands. A focused implementation covering inventory, sales and purchase at a single location is priced at PKR 800,000 to 1,500,000. A mid sized scope, five to seven modules with a mobile element, sits at PKR 1,500,000 to 3,000,000. Enterprise scope with several sites, manufacturing and integrations starts at PKR 3,000,000 and climbs from there. Subscription products are commonly quoted around PKR 2,500 per user per month, which is a different shape of cost rather than a smaller one.

Modules are priced as additions, and the manufacturing ones are the expensive part. Published market pricing puts a manufacturing module at PKR 300,000 to 600,000, accounting and finance at PKR 200,000 to 400,000, HR and payroll at the same, multi location at PKR 200,000 to 500,000 and a mobile application at PKR 400,000 to 800,000. Adding FBR digital invoicing to a system you already run is quoted at PKR 150,000 to 400,000.

Beyond the bands, four things move a plant number. Traceability granularity is the first and the largest, because batch level costs a fraction of serial level and serial level changes what an operator does at every operation, thousands of times a shift. Capture points come next. Each one needs a device that survives wash down, dust, heat or gloved hands, and those devices are procured by you rather than sold by us. Machine integration is third and is priced per machine, since a line that speaks an open standard and a line read from a display are entirely different pieces of work. Data condition is fourth and is the usual reason a quotation and a final invoice disagree. Bills of material and routings that have drifted from the physical process have to be corrected by people who also have a factory to run. We would far rather find that during discovery than during the pilot, and our own figure follows that discovery, written against a scope.

  • Traceability level agreed before pricing, since batch and serial are different projects
  • Capture points counted per line and per shift rather than per site
  • Machine integration priced individually against what each machine can actually expose
  • Devices and terminals specified by us and procured by you, with no margin to us
  • A real figure issued after discovery, written against a signed scope
02

How long a plant rollout takes

Published implementation timelines give three bands worth knowing. A focused scope goes live in two to three months. A mid sized scope with five to seven modules takes three to four. Enterprise scope with several plants and integrations runs four to six months and frequently longer. Reported go live figures across the market agree with that shape: six to twelve weeks for a focused single company, three to six months for an SME, nine to twelve months for a large enterprise. Adding FBR digital invoicing to an existing system is reported at six to twelve weeks.

Plants add their own delays and most of them are physical rather than technical. Bills of material and routings that no longer match the line have to be corrected before a single transaction means anything, and that correction is manual work done by supervisors during production. Machine integration takes exactly as long as the equipment owner takes to answer. Network coverage at the receiving bay gets discovered during the site walk and remediated by somebody else entirely. Peak season stops the project, as it should.

Training is where honest schedules diverge from optimistic ones. Every shift has to be trained, including the night shift, and training the night shift means being on site at night. The pilot needs representative production volume, which means it cannot be quietly run during a slow fortnight to protect a date. We would rather move a date than run a pilot that proves nothing, because a template corrected against real volume is the thing that makes the second site fast.

  • Bill of material and routing correction scheduled as work rather than assumed done
  • Machine integration timed around the equipment owner, not the software team
  • Every shift trained on shift, nights and weekend crews included
  • Pilot run at representative volume rather than during a convenient lull
  • Peak season and annual shutdown treated as fixed points in the plan
03

ERP production module or a dedicated MES

The production module inside an ERP covers more ground than its reputation suggests. Orders, routings, confirmation, backflushing, costing and planning are all present, and because they sit inside the business system the numbers reach finance without an interface anybody has to own. For a discrete or batch plant with batch level traceability and a manageable number of capture points, that is frequently the entire answer. One system, one support arrangement, one place where master data lives.

A dedicated execution system earns its cost where the floor moves faster than the ledger. Capture at each operation as it happens, machine data pulled directly rather than typed, lot and serial verification at every step, and workflow that will not let an operator skip an operation. Regulated products, high mix lines, machine paced production and customers who audit operation level genealogy are where it repays the outlay. What arrives alongside it is a second system to support and an interface between the two that somebody must own by name.

The line between them is genealogy depth and capture speed, not company size. A large plant making simple products with forgiving traceability may never need an execution layer. A small plant making a regulated product for a customer who audits it might need one from the first day. Volume on its own is a poor guide. Ask what a recall question would look like in practice, then ask whether the ERP module can answer it from records the floor can realistically produce during a busy shift.

Where we usually land is the module plus something targeted. A capture layer on the two lines that genuinely need it, or a quality hub holding inspection and release, rather than a platform bought whole and used in part. That is a smaller sale for us and a considerably cheaper system for you to keep running. The list of lines carrying the extra layer should stay short, and it should be revisited whenever the product mix changes rather than only appended to. Where the requirement does need a full execution system, we say so, and we say it before the quotation rather than after the first invoice.

  • Genealogy depth and capture speed decide the question, not headcount or turnover
  • ERP production module first where batch traceability and finance integration dominate
  • A dedicated execution layer where operations must be verified and enforced as they happen
  • The interface between the two owned by a named party from the start
  • A targeted addition preferred over a platform bought whole and used in part
04

Traceability, audit evidence and the plant hardware boundary

Traceability is tested by a question rather than by a feature list. Given a complaint about one unit, can you name the batch, the raw material lots inside it, the operators, the machines, the inspection results, and everything else made from those same lots. Forwards and backwards, out of a system rather than out of a folder. That is the standard, and it is what decides whether batch level records are sufficient or whether serial level is unavoidable.

Audit evidence is a different problem, often confused with the first. An auditor wants to see that a decision was taken by somebody authorised, at a recorded time, on the basis of a recorded result, and that the record has not been quietly amended since. That means release decisions carrying a named approver, non conformance handled through a route rather than a conversation by the line, and retention set deliberately per record type. Calibration certificates for the instruments stay with whoever maintains them.

Sales tax compliance reaches manufacturers who sell direct. Section 3(9A) of the Sales Tax Act requires Tier-1 retailers and other notified persons to integrate point of sale with the FBR computerised system for real time reporting, and FBR returns an invoice reference number and a QR code that must print on the receipt. Sales Tax General Order No. 17 of 2022 addressed Tier-1 retailer integration. Non compliance can mean disallowance of a substantial share of input tax adjustment, currently sixty percent. Whether your operation is notified is a classification question for your own tax adviser. We implement and integrate, and we are not a tax adviser.

The hardware boundary deserves stating plainly. SmartLink does not sell, install or commission plant hardware, sensors, instrumentation or programmable controllers, or the electrical work around them. Those belong with your automation contractor and your machine builders. We specify what the software needs, review what is proposed against that specification, and integrate with what exists. Terminals and scanners work the same way: we specify, you buy, at no margin to us.

  • A recall question rehearsed against the system rather than described in a proposal
  • Release decisions recorded with a named approver, a time and the result behind them
  • Retention periods set deliberately per record type rather than left at a default
  • Plant hardware, sensors and controllers supplied and commissioned by your automation partner
  • Tax classification routed to your own adviser, with implementation and integration ours
05

Cloud or on premise on a factory site

The factory version of this question is not really about servers. It is about what happens to the line when the link drops. A cloud system with no local buffering leaves the floor unable to record anything, and a floor that cannot record falls back to paper within minutes, which is fine when the paper route has been rehearsed and expensive when it has not.

Split designs are common for exactly that reason. The execution layer sits on site so capture keeps working through an outage, and the business layer sits centrally where multi site consolidation, reporting and remote access are easier to run. Power matters too. A site with an unstable supply needs the local part on protected power, and that is an electrical question for your engineers rather than a software one for us.

Cloud wins clearly on multi site rollout, on patching and on not keeping a server in a room next to a compressor. On premise wins where connectivity is genuinely unreliable, where a machine network cannot be exposed, and where a continuous plant cannot accept a maintenance window chosen by somebody else. Local hosting in Pakistan bills in rupees, which removes an exchange rate variable from a five year cost, and a data centre in Karachi is a far shorter round trip than a distant region. Test the link before deciding, during a working shift rather than on a quiet Sunday.

  • Behaviour during a link outage designed and rehearsed before hosting is chosen
  • Execution layer kept local where the line cannot stop recording
  • Business layer centralised where several sites need one set of numbers
  • Local capture hardware placed on protected power by your electrical engineers
  • Connectivity tested during a working shift rather than a quiet period
How we deliver

Delivering Factory & operations

Plant software is scoped against a physical site, so the first two steps happen on the floor rather than in a meeting room. Everything after that is arranged around a production calendar that will not move for us.

  1. 01

    Discover

    Walk the line during the shift being designed for. Where the batch number is written on tape, which machine is read off a display into a notebook, where the network drops at goods-in.

  2. 02

    Blueprint

    Traceability level, confirmation points and the definition of good output, scrap and rework are agreed by production and quality together. Downtime reason codes are written before anybody configures a screen.

  3. 03

    Build

    Screens are built for gloves and a wet hand: few fields, large targets, a scan instead of typing. Terminals go on the line where the work happens, not at a desk in the supervisor's office.

  4. 04

    Test

    Operators run a real order on one line for a full shift, including a changeover and a rejected unit. If a scan needs two hands or a screen times out mid-changeover, we find out here.

  5. 05

    Go live

    One line, one product family, one shift, with the paper fallback printed and rehearsed before the first confirmation is posted. Stock counts reconcile to the ERP before the second line starts.

  6. 06

    Run

    Spare scanners and terminals sit on site with a swap procedure a supervisor can follow. Bills of material and routings get named owners, and somebody walks the line periodically to check the system against reality.

Working together

The test is whether the spreadsheet disappears

There is a simple way to audit this work six months later. Walk the floor and look for the parallel record. If a supervisor still keeps a private tally of output or downtime, the system is not trusted, and the reason will be specific: the number it produces arrives late, or it is wrong, or getting the data in was too slow during a busy shift.

Each element described above exists to remove one of those reasons. Capture designed around gloves and changeovers. Definitions agreed once, across departments. A pilot that corrects the design while correction is still cheap. Fallback that keeps production recorded when the system is unavailable. None of it is complicated, and all of it is easier to do before go-live than to retrofit afterwards.

SmartLink Services builds and integrates the software layer, maps what a plant depends on, and connects it back to your business systems. Equipment, instrumentation and the safety case remain with your automation and engineering partners, and we coordinate with them rather than competing for that work or marking it up.

Credentials

Accreditations behind Factory & operations

Plant systems sit between equipment we do not supply and business systems we do, so accreditation matters most at the joins.

Client words

What Factory & operations clients say

Comments from people who run factory & operations systems day to day.

  • The team spent two days on the floor before they proposed anything, which I did not expect. They noticed that our scrap was being written off as a variance instead of recorded as returning metal, and that one change altered how we look at recovery on every press.
    Plant Manager Aluminium extrusion operation
  • The handover was the part I judged them on. Configuration decisions documented with the reasoning, our administrators trained properly, and a checklist we actually worked through. We run it ourselves now, and calling them is a choice rather than a necessity.
    Head of Shared Services Multi site manufacturing group
  • What sold us was that they argued with our brief. We asked for a reporting layer and they came back saying the reporting was fine, the batch data underneath it was not, and fixing that first would cost less. That turned out to be right. Our first mock recall after go live took an afternoon instead of the better part of a week.
    Finance Director Food manufacturing group, Karachi
Questions

Factory & operations: the questions we are asked

Typical market rates in Pakistan run from PKR 800,000 to 1,500,000 for a focused single site scope, PKR 1,500,000 to 3,000,000 for five to seven modules with a mobile element, and PKR 3,000,000 upwards for multi site manufacturing with integrations. A manufacturing module is quoted at PKR 300,000 to 600,000. Traceability granularity and machine integration move the figure most. We quote after discovery.

Published timelines put a focused scope at two to three months, a mid sized scope at three to four, and enterprise scope across several plants at four to six months or longer. Reported go live figures agree: six to twelve weeks for a focused single company, three to six months for an SME. Correcting bills of material and routings is the usual reason a date moves.

Ask what a recall question would look like in practice. If batch level records answer it, and the floor can produce those records during a busy shift, the ERP production module is usually enough and leaves you one system to support. Verification at each operation, direct machine data capture and enforced workflow are what a dedicated execution layer adds, and machine paced or regulated production is where it pays.

Integration with FBR digital invoicing is standard work for us. Section 3(9A) of the Sales Tax Act requires Tier-1 retailers and other notified persons to report point of sale transactions in real time, with an invoice reference number and QR code printed on the receipt. Adding it to an existing system is quoted in the market at PKR 150,000 to 400,000. Whether you are notified is a question for your tax adviser.

No. We specify what the software needs from a device, review what your supplier proposes against that specification, and integrate with the equipment you already have. Programmable controllers, sensors, instrumentation and the electrical work around them belong to your automation contractor. Terminals and scanners are bought by you directly. Nothing in that purchase carries a margin for us, which keeps the specification honest.

Only if the design assumed it would. Local buffering at the capture points, a rehearsed paper fallback and a defined route for entering the backlog afterwards are what keep a shift recorded during an outage. We design and rehearse those before go live rather than discovering the gap during one. The alternative is a supervisor with a notebook and a reconciliation problem the following morning.

Both are supported, and the choice is a shop floor decision rather than a licensing one. Serial traceability means every unit is identified and scanned at each operation, which changes what an operator does thousands of times a shift. Batch level costs far less to run and answers most recall questions. Decide before go live, because history recorded at one level cannot be upgraded to the other.

One plant first, always. The first site is where the template meets a real shop floor and gets corrected, and those corrections are usually small, specific and impossible to predict from an office. Later sites move considerably faster because the design has already survived a shift. Each accepted difference between sites is recorded with a written reason, so the template does not quietly become five separate systems.

Still reconciling the plant against a spreadsheet?

Tell us what the floor records today and where the numbers stop agreeing. That gap is usually where the work starts.