SmartLink
Manufacturing systems

Factory systems mapping and management in Pakistan

Factory systems mapping in Pakistan usually starts with a question nobody in the room can answer: how many systems does this plant actually depend on. SmartLink Services documents the application estate from Karachi, covering applications, versions, owners, interfaces, dependencies and end of life dates, then manages the software layer of it under a written scope. This page covers what a mapping exercise costs at published market rates, how long walking a working plant takes when production will not stop for a survey, and the decision most sponsors face at the outset: whether to map the estate first or replace its worst part first. Infrastructure is advisory only.

Discuss this service
Deliverable
Systems register & map
Scope
Applications & interfaces
Infrastructure
Advisory only
Overview

Most plants cannot name every system running on the floor.

Ask a plant manager to list the software running in the plant and the obvious answers come quickly. The rest do not. There is a label printing application on a machine in dispatch that one person knows how to restart, a weighbridge system whose maintenance contract lapsed, a spreadsheet with macros that reconciles two systems every morning, and a supervisory package on a version the vendor stopped supporting some years ago. None of this is negligence. It is what accumulates when systems arrive one project at a time.

The risk is not that the estate is untidy. It is that nobody can answer what breaks if a given system stops, who to call about it, and whether anybody is still entitled to call them under a live contract. That question tends to be asked for the very first time during an incident, at the worst possible hour, and the answer is assembled from whoever happens to be reachable that night. A written map turns that from an emergency search into a lookup that takes a minute.

We document the estate and then manage the software layer of it. Applications, versions, owners, interfaces, dependencies, licences, support contracts and end of life dates, all in one place. Where the finding is that a system is unsupported and quietly holding a critical process together, that goes into the risk register with a mitigation attached rather than a recommendation to replace everything at once. Most estates cannot be rationalised in a single move, and pretending otherwise produces a document that gets filed and never opened.

Scope

What Factory systems mapping & management covers

Everything below is agreed in writing before any factory & operations work starts, so both sides know what is in and what is not.

What the work covers

  • Inventory of applications, versions and owners across the plant
  • Interface and data-flow diagram between systems
  • Dependency and single-point-of-failure analysis
  • Licence, support contract and end-of-life register
  • Software layer management, patching and vendor coordination
  • Infrastructure advisory: requirements defined, vendors coordinated, no hardware supply

What you get at handover

  • Systems register with named owners
  • Interface and dependency map
  • End-of-life and renewal calendar
  • Risk register with mitigations
  • Managed-service scope document

Typically involves

CMDB tooling Diagramming standards Monitoring integrations Vendor coordination
Discuss this service
01

Finding the systems nobody mentions in the kick off meeting

Inventory work is fieldwork. The list you are given at the start is the list of systems with budget lines, which is not the same as the list of systems the plant depends on. The rest are found by walking, by watching what people open during a shift, by asking what they do when a particular screen is down, and by looking at what is actually connected to the plant network rather than what the network diagram says should be.

Certain categories are reliably missing. Machine embedded software supplied with equipment, where the vendor holds the only copy of the configuration. Departmental tools bought on a card and never registered. Spreadsheets that have become interfaces, which are systems in every sense that matters except that nobody calls them one. Remote access left in place by a supplier after a commissioning visit. Each of these is a dependency and each needs an owner recorded against it.

The register itself should be small enough that somebody can realistically keep it current. Name, purpose, version, owner, support arrangement, criticality, what it depends on and what depends on it. A register with dozens of fields per system is accurate for about a month and then quietly rots. We would rather have a handful of fields that are still true a year later, with a review trigger attached to change control, to procurement and to any new equipment arriving with software inside it.

  • Discovery by walking the plant and observing use, not only by collecting a stated list
  • Machine embedded software recorded, including who holds the configuration
  • Spreadsheet interfaces treated as systems, with owners and a dependency entry
  • Supplier remote access identified and either removed or brought under control
  • A short register designed to stay current, with a defined review trigger
02

Drawing the interfaces before you need them at three in the morning

Data flow between plant systems is where most of the surprises live. A count moves from a machine to a supervisory package, from there into a spreadsheet on a shared drive, and from the spreadsheet to the ERP by an overnight job running on a workstation under somebody's desk. Each hop is reasonable on its own and was signed off by someone sensible. The chain is not reasonable, and it stays invisible until the workstation is switched off during an office move and production reporting stops for a week.

Mapping it means recording direction, mechanism, frequency, the account it runs as, and what happens when it fails. That last column is the useful one and the one most often left blank. Does the data queue, is it lost, does anyone find out. A flow that fails silently and loses data is a different risk from one that stops loudly, and the mitigation differs too. Single points of failure become obvious once the map is drawn, which is much of why the exercise pays.

Dependencies should then be tested rather than assumed. Asking what would happen if a particular server were unavailable produces confident answers that are often wrong. Where it can be done safely during a planned shutdown, verifying a failover or a manual fallback is the only way to know. Where it cannot, a written and rehearsed manual procedure is the honest alternative, and it belongs with the people on shift rather than in a folder in the office.

  • Every flow recorded with direction, mechanism, frequency, account and failure behaviour
  • Silent failure distinguished from loud failure, because the mitigation differs
  • Single points of failure identified from the map rather than from memory
  • Fallback procedures written for the flows that cannot be made resilient
  • Verification during planned shutdowns wherever a test can be run safely
01

What factory systems mapping costs in Pakistan

No published market band exists in Pakistan for estate mapping, and anybody quoting one is quoting themselves. Factory systems mapping is sold as time. Market hourly rates here run PKR 3,500 to 8,000 for full stack technical work, with senior specialist time at the top of the band and junior work published at PKR 500 to 1,000. Mapping sits with the senior figures for a straightforward reason: an interview conducted by somebody who has never run these systems produces a list, and a list is not a map. Knowing which follow up question to ask when a supervisor mentions that the weighbridge PC also prints something is the whole skill.

Effort is driven by people rather than by technology. Site count and shift pattern come first, since the interviews have to reach the night shift and the night shift knows about systems nobody on days will mention. Application count follows, and it always exceeds the estimate given at kick off, because spreadsheets moving data between two systems are systems and belong in the register. Interface count is third and it is the part with no documentation, so each one is traced by finding both ends. Vendor contact is fourth: establishing a version and a support status can take weeks, and some vendors no longer exist. Whether licence and contract records survive anywhere decides how much of the commercial picture has to be rebuilt from invoices.

Scale the fee against the decision it informs rather than against the day rate. The replacement programme it usually precedes carries published market bands of PKR 800,000 to 1,500,000 for a focused single site scope, PKR 1,500,000 to 3,000,000 for a mid sized scope and PKR 3,000,000 upwards for multi site manufacturing with integrations. A map that changes what gets replaced, or the order in which it happens, has paid for itself well before anything is bought. Ongoing management of the software layer is quoted separately as a retainer, because it is a different commitment with a different shape. All rates above are market context. A real figure follows a short scoping conversation.

  • Sold as senior time, since the value is in the follow up question rather than the questionnaire
  • Interviews planned to reach every shift, because the night crew names systems days never mention
  • Spreadsheets carrying data between systems counted as systems and entered in the register
  • Interfaces traced by finding both ends rather than by accepting a diagram
  • Ongoing software layer management quoted separately from the mapping exercise
02

How long a systems mapping exercise takes

Elapsed time is set by access to people, not by the size of the estate. The technical part of documenting a system is an hour. Getting an hour with the person who knows why it was configured that way, on a plant where they are also running production, is the constraint.

Reported delivery timelines in Pakistan give the frame for whatever follows the map: a focused single company scope at six to twelve weeks, an SME programme at three to six months. The mapping itself is shorter and sits at the front of that, but it has a tail nobody plans for. Vendor confirmations arrive slowly. A version and support status request to a large vendor takes weeks, and for a small local supplier it sometimes takes a site visit, or reveals that the company has closed and the product has no owner at all.

The site walk is where the schedule earns its length. Systems nobody mentions in a kick off meeting surface only when you are standing in front of them: the weighbridge PC running an operating system three versions past support, the label printer with its own database, the attendance terminal, the boiler logger writing to a share, the standalone laptop in the laboratory that holds ten years of results. Each of those is a real dependency and each takes a conversation to place properly. Contract files typically live in three places, so the licence and renewal picture is assembled from finance records as much as from IT ones. We would rather extend the walk by a week than hand over a register that is confidently incomplete.

  • Interview time with the people who know treated as the binding constraint
  • Vendor version and support confirmations chased early, since some take weeks to arrive
  • A physical site walk included, because the undocumented systems only surface in front of you
  • Licence and renewal records assembled from finance files as well as from IT records
  • Systems with no surviving vendor recorded as risks with owners rather than left off the register
03

Mapping the estate first or replacing it first

The pressure is always to replace first. Something is visibly broken, there is budget for it this year, and a mapping exercise looks like paperwork standing between the business and a fix. Sometimes that instinct is right and we will say so rather than sell a document nobody needed.

Replace first is defensible where the failing system is genuinely isolated, where its interfaces are few and already known, and where the replacement is close to a like for like swap with a supported product. A standalone attendance system usually qualifies. A label printing package that talks to nothing else qualifies. What makes those safe is not their size but the fact that somebody can name everything they touch, in the room, without checking.

Where it goes wrong, it goes wrong in one specific way, and that way is worth describing because it repeats. The system being replaced turns out to feed three others, one of which nobody remembered, and the discovery happens during a cutover weekend. The cost then is not the software licence. It is the shift that could not record output, the despatch that went out without a document, and the fortnight afterwards spent reconciling what happened. On a plant that has grown by accretion over fifteen years, with several vendors involved and interfaces running as files dropped on a shared drive, that outcome is likely rather than possible.

Map first is the right default in those conditions, and what it actually buys is a sequence rather than a document. Once dependencies are visible, the replacement order usually changes, and it tends to change towards retiring a spreadsheet or fixing an interface before buying anything at all. The compromise we most often recommend costs less than either extreme: map narrowly and deeply around the system you intend to replace rather than mapping the whole plant first. That takes a fortnight instead of a quarter and answers the question actually blocking the decision. Whichever route is chosen, the register needs a named owner and a review date, or it becomes a document that was true once. Our scope stays on the software layer: applications, interfaces, versions, licences and vendor coordination. Network, servers, electrical work and plant hardware remain with your infrastructure and automation partners, and we define requirements and review what they propose.

  • Replace first where the failing system is isolated and everything it touches can be named
  • Map first where the plant has grown by accretion and interfaces run through shared drives
  • A narrow deep map around the system due for replacement offered as the cheaper middle route
  • The register given a named owner and a review date, or it dates within a year
  • Software layer mapped and managed by us, with infrastructure and plant hardware left to your partners
How we deliver

Delivering Factory systems mapping & management

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

A map is only useful if it is current

The failure mode of this work is a good document that ages. A systems register produced as a one off is accurate on the day it is signed and misleading within a year, because plants change constantly and nothing in the process obliges the register to change with them. That is why the deliverable is a register plus a trigger: a new system, a version change, a contract renewal, or equipment arriving with software inside it, each of which prompts an update.

Kept current, it answers the questions that matter under pressure. What does this depend on, who owns it, is it supported, what happens if it stops, and what do we do in the meantime. Most plants can already answer those about their largest systems. The purpose of this work is to be able to answer them about all the others, which is where the unpleasant surprises actually live.

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.

Oracle

Partner

Oracle SCM and EBS manufacturing modules for work orders, routings and costing, with the plant reporting database tuned so a shift report returns while the supervisor is still standing at the terminal.

Microsoft

Partner

Dynamics 365 Supply Chain Management where that is the platform, plus Power BI dashboards showing downtime by reason code on a screen the plant manager sees each morning.

Google

Partner

Google Cloud is where multi-site plant data gets consolidated when each factory runs its own instance, so group reporting stops depending on spreadsheets emailed in from each site after close.

FBR digital invoicing

Compliant integrations

Despatch from the plant triggers the sales invoice, so the goods issue, the invoice and the FBR submission stay in step. Gate passes carry the same document number as the tax invoice.

HIPAA

Compliant practices

Contract manufacturing of patient specific products puts a patient name on a batch record. Those fields are restricted on the shop floor terminal, logged, and covered by a business associate agreement.

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

Questions about Factory systems mapping & management

There is no published band for it, so it is quoted as time. Market hourly rates in Pakistan run PKR 3,500 to 8,000 for full stack technical work, with senior specialist time at the top. Site count, shift pattern, application count and how many vendors have to be contacted drive the effort. Ongoing management of the software layer is quoted separately as a retainer. We quote after a scoping conversation.

Access to people sets the pace rather than the size of the estate. Documenting a system takes an hour; getting that hour with the person who knows it, on a plant that is also running production, takes longer. Add a tail for vendor confirmations, which arrive slowly and occasionally reveal that a supplier no longer exists. The site walk is where undocumented systems surface.

Where the failing system is isolated and you can name everything it touches, replace it. Where the plant has grown by accretion, several vendors are involved, or interfaces run as files on a shared drive, map first. The usual middle route is cheapest: map narrowly and deeply around the system you intend to replace, which takes a fortnight rather than a quarter.

It goes in the risk register with a named owner and a decision date rather than a shrug. The practical questions are whether the source or the database schema is accessible, whether anybody can still rebuild the server it runs on, and what the business does the week it stops. Answering those honestly usually settles the replacement priority on its own.

No. We map and manage the software layer: applications, versions, interfaces, licences, patching and vendor coordination. Servers, network, electrical work and plant hardware including sensors and controllers stay with your infrastructure and automation partners. We define what the software requires, review what they propose against it, and coordinate. Nothing in that purchase carries a margin for us.

At least annually, and after any change that adds or removes a system or an interface. A register with no owner and no review date is a document that was true once, and it is more dangerous than no register at all, because people trust it. We hand the register over in an editable form so it stays yours to maintain.

More in Factory & operations

More Factory & operations services

Manufacturing systems

Factory & production software

Production orders, routings, shop-floor confirmation and output reporting tied back to ERP.

Open service page → Manufacturing systems

Production planning & scheduling

Demand, material and capacity planning that produces a schedule the plant can hold to.

Open service page → Manufacturing systems

Plant maintenance systems

Preventive schedules, work orders, spare parts and downtime history in one maintenance record.

Open service page → Manufacturing systems

Quality & testing hub

A single hub for inspection plans, test results, non-conformance and release decisions.

Open service page →

Can you name every system your plant depends on?

Tell us what you run today and where factory systems mapping & management is causing you trouble. The first conversation is a consultation rather than a pitch.

Book a consultation All factory & operations