Numbers copied from paper after the shift ends are not enough to manage production. We build a system that sends work orders down to the floor, captures data at the machine and line the moment it is born, records downtime with its cause, and tracks waste and batches. In software terms this layer is called an MES (manufacturing execution system); it is written around the reality of the carpet weaving, textile, plastics and food facilities of Başpınar and Şehitkamil, not from a ready-made template.
Whether a production tracking system works is judged not by its screen count but by whether the operator uses it. So we start not from the software but from the floor: which data can be captured, from whom, when and how. What follows is not the module list of a standard package but the parts we select for your flow after discovery.
A work order opened in the ERP or inside the system lands on the floor by machine and by operator. Start, pause and complete are recorded from the floor screen with a single touch. Plan and actual sit side by side; how far each order has progressed is visible without walking the production hall.
Data is collected where it is born. If the machine's counter or control unit emits data, we pull it directly; if not, we capture it from the operator with barcode scans and a big-button floor terminal. Connecting hardware to software is not a new job for us: we have previously built a system that joined a weighbridge scale and a label printer into a single weighing and labelling station. Screens are designed for gloved hands, dusty environments and getting the job done in two steps; when the network drops, data waits on the terminal and transfers once the connection returns.
Every stoppage and every waste entry is recorded with a cause code: breakdown, setup, mould change, waiting for material, yarn break, shift handover and so on. The cause list is built in the language of your own floor, with the words your foreman actually uses. So at month end the conversation is not about total hours but about where the loss comes from.
The chain from raw material batch to finished product is built on a single number. From a shipped item you can go back and see which raw material, which machine and which shift it came from. This is the foundation that export buyers' traceability demands and the food sector's recall scenarios are looking for.
Production, downtime and waste reports by shift, line and machine are generated automatically; nobody has to fill in Excel in the evening. Actual production is fed back into Logo, Mikro or Netsis as stock and cost movements, so order costs rest on reality rather than the theoretical recipe. We have previously developed a layer beside an installed Netsis system on exactly this logic, without touching it.
The line's live status, shift target and deviation are visible on a large screen on the floor; operators and foremen know where they stand. The manager sees the same picture on their phone. We have previously built an 11-module factory management panel; the approach is the same — plain screens that drive decisions.
We come to your facility and ask one question for every machine and line, one by one: can this data be pulled from the machine, and if not, who will enter it, when and how? We separate the machines with and without control units, and finalise the list of automatically versus manually collected data in this step.
We build the downtime, waste and quality cause codes with the words your own foreman uses. We design the data model for work orders, machines, shifts, batches and quality data, and set down in writing which system is the master for each piece of data.
Before spreading across the whole factory, we install on a single line or group of machines. We test the floor screen, the terminal and any machine bridge in real production conditions, on a real shift, and simplify the screen with the operators' feedback. Pilot numbers are validated by comparing them against your existing records.
We roll the system validated in the pilot out to the other lines step by step; we do not switch everything on at once. The ERP feedback goes live at this stage, and we check together that production movements land correctly on the accounting side.
We train operators, foremen and managers according to their roles. In the first weeks after go-live we stay on the floor and fix the steps that jam in real use. After that, support continues for maintenance and for new lines and new report requests.
It depends — we check machine by machine in discovery. If a control unit or counter emits data, we read it directly. On older machines that emit nothing, we build the same visibility through counter readings, barcodes and operator entry on a floor terminal. What matters is not whether the data comes from the machine or from a person, but that it is recorded the moment it is born, with the right cause.
Yes — this is one of the areas we discuss most in Gaziantep. In carpet, the tracking logic is built around loom speed, yarn breaks, downtime causes, metres produced, roll-based records and pattern-based yarn consumption. Our own field research counts 107 registered carpet companies in the OSB; this sector's tracking needs differ markedly from plastics or food, and the program is written accordingly.
We take this risk seriously from the very start, because an unused production tracking system is the most expensive kind of software mistake. We design the screen to finish a job in two steps, with big buttons and no keyboard required. During the pilot we stand on the floor and watch where the operators get stuck. Entering data must also do something for the operator; a screen where they can see their own shift status delivers that.
No. Floor terminals are set up to hold the data locally when the connection drops and transfer it in order once the connection returns. In a factory environment a network outage is not an exception but the expected case; software that is not designed for it loses the floor's trust.
No. The ERP plans production and manages stock and cost; the production tracking layer measures how that plan actually plays out on the floor and feeds it back to the ERP. Your Logo, Mikro or Netsis backbone stays in place; your e-invoicing and account structures are not disturbed. The two systems complement each other.
No, and we advise against it. We start with one line or one group of machines and do not move to roll-out until the numbers there reconcile with your existing records. That caps both the risk and the budget, and lets you see early whether the system genuinely works.
We do not quote without a discovery visit. What sets the timescale and cost is clear: how many lines, how many machines, how many floor terminals, whether there is machine integration, whether ERP feedback is wanted and how many reports are needed. After walking the floor we present a written scope and a staged budget; the pilot is priced separately from the roll-out.
No. Even on the pilot line, your current recording method keeps running in parallel for a while; the old method is not switched off until the two sources reconcile. Floor installations are scheduled around the shift plan, at times that will not disrupt production.
Let us come to your facility in Başpınar or Şehitkamil and watch a full shift from start to finish; together we will see where data is born, where it falls onto paper and where it gets lost. The resulting list makes clear which data will come from the machines and which from the operators. Starting with a single-line pilot is both cheaper and sounder than wiring up the whole factory.
