When a manufacturer decides to invest in ERP, IoT or automation, the hard part is not choosing the product. A comparison table takes a few weeks to produce. The hard part is getting that product to work with the real processes, the real data and the real people inside the plant. Most projects stall in the second half.
“Turnkey” is a claim to close exactly that gap: to deliver a working system rather than a boxed licence. Because the phrase has been worn thin by marketing, it is worth setting out what it means — and what it does not.
What turnkey means, and what it doesn’t
In a turnkey project the supplier owns the outcome, not just the licence and the installation: data migrated, integrations built, users trained, the system running cleanly in production. Concentrating accountability in one place spares the business the familiar spectacle of the software vendor and the machine vendor blaming each other.
It is equally worth saying what turnkey is not. It does not mean the business will spend no time on the project — no supplier can configure a system correctly without the people who know the processes. And any promise of a “turnkey go-live in 30 days” made before the scope is defined should be treated with suspicion. Duration cannot be known before discovery ends, a point we also made in our guide to choosing an ERP.
Why projects stall
A handful of causes repeat on site. None of them are technological:
- The scope was never written down. A verbal understanding becomes a sixth-month argument about what was supposed to be included.
- The data isn’t ready. Duplicate customer records, inconsistent stock codes, missing invoice history. Cleaning that up was never part of the plan.
- Nobody owns it. No project lead with decision-making authority was appointed on the business side, so every question travels to the owner and every answer arrives late.
- Success was never defined. With no measure of the gap between “the system is installed” and “the system is used”, nobody can say what was gained when the project ends.
- Training was left to the last day. A user who sees the system for the first time at go-live will quietly return to the old spreadsheet.
- Everything at once. Open eight modules, three sites and two integrations on the same morning and tracing the source of an error becomes impossible.
That list reads well as a checklist. If you have an answer to all six before the project starts, the riskiest part is already behind you.
The six stages
1. Current-state analysis and feasibility
Processes are observed on site, data sources are mapped, and the reason each job falls behind is written down. The output of this stage is not a software recommendation but an inventory of problems. Feasibility belongs here too: which line item pays back the investment — labour, scrap, inventory cost, penalty exposure, energy consumption?
2. Scope and success criteria
What is in and what is out gets written down, item by item, with measurable criteria beside it: order entry time halved, month-end close completed within three days, production stoppages recorded. Without a measure, a project never finishes — it merely stops.
3. Data preparation and migration
This is the most delicate step. Customer, stock, bill-of-materials and transaction history are cleaned, mapped and moved into a test environment. Migration is rehearsed at least twice; the first attempt always comes back incomplete. When this step is underestimated and pushed into the final week, that is where most slipped go-live dates begin.
4. Installation, integration and pilot
The system is installed and connected to e-document services, banking, e-commerce and, where relevant, machine communication (M2M). A pilot then runs, limited to one department or one product line. The pilot exists to surface faults; a pilot that produces none was not set up realistically.
5. Go-live and training
Training happens before go-live, using the company’s own data. Not a generic product walkthrough — each user should do their own job on their own screen. A rollback plan is ready for go-live day: no transition should happen without knowing the old system can be restored.
6. Embedding and continuous improvement
The first weeks after go-live need dense support. Question volume, error tickets and adoption rates are tracked. Then the second phase is planned: automation, reporting, energy and emissions tracking. A project nobody touches after go-live loses to old habits within six months.
Who does what
Turnkey does not mean nobody on the business side has a job. In a healthy setup the roles separate like this:
| Role | Held by | Responsibility |
|---|---|---|
| Project owner | Business (senior management) | Budget, priorities, decisions |
| Project lead | Business | Day-to-day coordination, internal comms |
| Process owners | Business (departments) | Validating and testing their own processes |
| Solution consultant | Supplier | Process-to-software mapping, configuration |
| Data lead | Shared | Migration, cleansing, validation |
| Technical team | Supplier | Infrastructure, integration, security |
Leave the three business-side roles empty and no amount of supplier experience will keep the project upright.
What drives budget and duration
A firm number only emerges after discovery. Even so, it helps to know in advance which variables inflate a budget: the number and complexity of processes, the volume and quality of the data being migrated, how many integrations are needed, user count, custom development, and the number of sites. Of these, the most consistently underestimated is data quality; the most consistently overestimated is user count.
Duration follows a similar pattern. At a single-site manufacturer running standard processes, a core implementation typically takes a few months; at a multi-site operation with heavy production and export requirements it lengthens noticeably. A staged rollout looks longer on paper but lowers total risk.
Part of the investment can often be offset through support programmes. KOSGEB and the Ministry of Industry and Technology offer several instruments for digitalisation and green transition, which we collected in our guide to support programmes. Amounts and conditions are revised periodically, so confirm them on the relevant institution’s official pages (kosgeb.gov.tr, sanayi.gov.tr) before applying.
Don’t plan the digital project apart from the green one
Many companies treat ERP as this year’s project and carbon footprint measurement as something for the year after. That means collecting the same data twice. Production volumes, energy consumption, raw material and transport data all enter the system during the first project anyway. If emissions and energy fields are considered while the scope is being written, the second project stops being a data-collection exercise and becomes a reporting exercise on data you already hold.
With CBAM and sustainability reporting obligations approaching, that difference buys real time. This is the practical meaning of the twin transition approach: building the digital and the green on a single data backbone.
İkiz Eksen runs that chain end to end — measurement and data first, then the right software, then compliance and reporting. Drawing on Qera’s experience, we carry more than 100 ERP migrations, over 15 sectors and more than 550 businesses served, with a team of around 35 specialists working across Türkiye on Microsoft Azure infrastructure. Our way of working is set out on the methodology page; you can review our services or get in touch to define the scope of your project.
Frequently Asked Questions
Is a turnkey project fixed-price?
A fixed price is possible once the scope is written and clear. A fixed price quoted against an undefined scope ends with either the supplier or the business absorbing a loss. The sound method is to run discovery as a separate, short engagement and price the work after the scope exists.
How many of our people need to spend time on the project?
No full-time staff are required, but a project lead with decision-making authority and one owner per process are essential. Process owners give a few hours a week during testing and validation; that intensity rises in the go-live week.
Will all our existing software be replaced?
Not necessarily. Some systems — a specialised production application, laboratory software — can be preserved through integration. The decision rests on whether that software’s data can be exposed to other systems and on what it costs to maintain.
Will production stop during go-live?
Not in a well-planned transition. The critical week is usually placed in a low-volume period, the old system runs in parallel for a while, and a rollback plan stays ready. What genuinely raises risk is declaring a start date before the preparation is done.
Could we not run the project with our own team?
You can — if process knowledge, data experience and spare capacity all exist at once. In practice, internal teams buried in daily work push the project into second place. A hybrid model also works: the supplier handles installation and data migration while the business owns process design and testing.