In Gaziantep the ERP question usually starts as 'which package should we buy', when the real question is this: does the existing ERP need replacing, or is writing a production layer alongside it enough? The two paths differ completely in cost, risk and timescale. It is not a decision to make without seeing the shop floor — so we work it out with you, on site at your facility in Başpınar.
There is no single right answer here. In some companies the right move is to leave the ERP untouched and write a layer alongside it; in others the existing installation is so far gone that rebuilding from scratch comes out cheaper. We make the call based on what we see on the floor, not on our sales target. Below is what each path looks like and what we concretely do.
The path we recommend in most cases. Your Logo, Mikro or Netsis backbone stays in place; e-invoicing, e-ledger and account structures are never disturbed. We write work orders, machine data, waste, subcontracting, quality and batch traceability as a separate layer and feed it back into the ERP as stock and cost movements. Because it leaves the current installation in place, this is the path you can reverse.
Rebuilding comes up when the current installation can no longer be maintained, the data model has drifted away from the reality of the business, or licence and user costs have outgrown the job. When we propose this path, we put the cost, the timescale and the data-migration risk in writing in the same document; we do not dress it up. A ground-up ERP is an expensive decision and can only be defended where path one is not enough.
The layer we write talks to your ERP at database, service or file level. Stock, accounts, orders, delivery notes and invoices stay in one authoritative source; production and subcontracting data flow into it. What decides the approach is not the ERP's brand but which access routes you have been given; we do not say 'we will integrate' before establishing this in discovery. Whether the integration is one-way or two-way is also fixed in writing from the very start.
We have done this before: we developed a production layer that runs alongside an installed Netsis system without touching it at all. The aim was not to replace the ERP but to connect the shop floor the ERP could not see. The same approach can be applied to Logo and Mikro installations; in every installation we first check which routes into the data are available.
Keying the same information into three systems is not just lost time — it is lost trust. For every data item we set the rule 'this is the master source' and feed the other systems from there. Because the rule is written down, which number is authoritative stops being a matter for debate.
We build a dashboard that merges the ERP's and the production layer's data into a single screen for the owner: open work orders, deadline deviation, waste, subcontracting status, and the gap between actual and theoretical cost per order. We have previously built an 11-module factory management panel; the approach is the same — plain screens that drive decisions.
Which ERP, which version, which modules are active, how many users, which customisations have been made, is there database access, is a maintenance contract still running. No recommendation is realistic before this inventory exists; most of the bad ERP decisions we see are born from skipping this step.
We come to your facility and compare the picture on the ERP screen with the reality in the production hall. We identify, item by item, which information never enters the ERP, which enters late, and which gets distorted on the way in. The output is a concrete list of the gap between what the ERP sees and the reality of the floor.
We compare writing a layer alongside versus rebuilding the ERP from scratch in a single document: scope, timescale, estimated budget range, data-migration risk and how production keeps running during the transition. The decision is yours; our job is to lay out, in full, the information needed to make it.
On the chosen path we start with a single narrow scope; usually one production line or one flow. We build the integration bridge and verify the data against the ERP. We do not move to roll-out until the numbers reconcile.
We roll the verified scope out to other lines and departments step by step. We train the accounting, production and floor teams according to their roles. Afterwards support continues for maintenance, monitoring and new report requests; the source code and the data stay with you.
In most cases, no. In the typical picture we see in Gaziantep, the ERP's accounting side works fine and what is missing is the production side. The right move then is not to rip out the ERP but to write a production layer alongside it and feed the ERP back. We only recommend replacement when the current installation can no longer be maintained or the data model has completely drifted from the reality of the business.
On the Netsis side we have done it without touching the installed system at all. How it works, though, depends on the ERP's version and the access you have been given: some installations connect through official services, some at database level, some by file exchange. In discovery we first establish which route is possible, and only then make a commitment. Saying 'we will integrate' without seeing the access would not be right.
Rarely, but in some situations yes. It makes sense where the existing package never fitted the core of the business, customisation costs keep accumulating year after year, and the company has bent its way of working because of the package. Without all three, building from scratch is expensive and risky. Before deciding, we recommend reading our off-the-shelf ERP vs custom software guide.
No — this is a priority for us. We do not do single cut-overs; the old method and the new system run in parallel for a while, and the transition is not considered complete until the numbers reconcile. We only touch the live environment with your approval and in maintenance windows agreed in advance.
A module being enabled and a module being used are different things. In discovery we check whether the module is genuinely in use; if it is and it is enough, we do not write anything new, and we say so openly. If it is not used, we look for the reason: usually the module does not fit the flow on the floor, the operators cannot reach a screen, or licensing is the constraint.
We do not quote without seeing the shop floor and the current installation. What sets the price is clear: how many integration points, how many screens, how many users, how many terminals on the floor and whether data migration is involved. After discovery we present a staged budget together with a written scope. For a general framework, see our custom software pricing guide.
The source code of the layer we write and all of the data are yours. The data sits on your own server or in a cloud account opened in your name. Your ERP's own data continues to stay with you as it always has; we do not put a second lock on it.
Physical proximity. The most expensive part of ERP work is misunderstood requirements, and that misunderstanding mostly comes from never seeing the shop floor. We come to the Başpınar OSB and to Şehitkamil and stand next to the machine. We have also mapped this city's industrial profile company by company through our own field research.
Let us come to your facility in Başpınar or Şehitkamil and map your current installation, the access routes into your data and the flow on the floor in person. You end up with a written document that puts the two options side by side in scope, timescale and risk. You can use that document with another supplier too; getting the decision right matters more to us than winning the job.
