A pattern keeps repeating itself across mid-sized Turkish companies: the digital transformation strategy wins applause in the boardroom, the consulting firm’s roadmap gets approved, the budget is allocated. Six months later, the project team presents a ‘pilot successfully completed’ report. A year later, nobody can explain why that pilot never spread to the rest of the organization. This gap is not a coincidence — it is a symptom of a structural problem that most transformation projects are not designed to address.
Failure in digital transformation rarely comes from a bad technology choice. ERP systems, e-Invoice and e-Ledger integrations, cloud infrastructure — these tools work as advertised. The breakdown happens because the processes sitting beneath the technology, and the people running those processes, do not change alongside the system. A strategy document describes a ‘target state.’ But who will walk the path between the current state and that target, which resistance will they encounter, and which decisions will need to be made on the ground in real time — none of this appears in the presentation deck.
The inability to scale pilots deserves closer examination. A pilot runs under controlled conditions: a hand-picked team, willing users, close consultant support, direct management attention. Under these conditions, almost any system will perform. But when a pilot succeeds in one department, rolling it out to the rest of the organization requires an entirely different kind of engineering. Different business units carry different process habits; units excluded from the pilot have no sense of ownership over the system; the IT team is left handling technical issues that emerge at scale without the same level of support. Pilot success is not a guarantee of scaling success — yet it is routinely treated as one.
The role of middle managers is the most consistently underestimated variable in this equation. In digital transformation projects, senior leadership sets the vision, consultants draw the roadmap, and frontline employees are expected to use the new system. Middle managers fall somewhere in between — neither fully inside the project nor outside it. Their existing workload continues uninterrupted, they are expected to train their teams on the new system, yet no time or resource is formally allocated for this extra responsibility. When the new system makes their department’s performance metrics more transparent, a natural defensive reflex kicks in. Without ownership, there is no sustainability; and ownership does not emerge on its own.
The fact that process change is harder than technology change is rarely reflected in project budgets. A company invests heavily in ERP licensing and technical implementation, while the share allocated to process redesign, change management, and user training often remains a small fraction of the total budget. Yet integrating an accounts payable process into an e-Invoice workflow is not simply a matter of making a technical connection — it means redefining approval hierarchies, exception handling, error correction procedures, and reporting responsibilities. This work needs to happen in parallel with the technical rollout, not after it. When it is deferred, the system runs technically but never integrates into the actual business process; users layer old habits on top of the new system and the expected efficiency gains never materialize.
In Turkey’s SME and mid-market segment, an additional factor deepens this problem: project teams are rarely permanent. Team members assigned during the transformation project return to their previous roles or move to other projects once the engagement closes. Institutional memory disperses. The people who understood the system best are no longer responsible for maintaining it; the incoming team tries to reconstruct knowledge from documentation. Mobile ERP access, cloud infrastructure, and real-time reporting add genuine technical capacity to the organization — but converting that capacity into embedded institutional knowledge requires a different kind of organizational design than most companies put in place.
When evaluating a digital transformation initiative, there are a few concrete questions every manager should ask before signing off. Is the team that succeeded in the pilot the same team that will carry the rollout to the rest of the organization? Were middle managers genuinely involved in shaping the project, or were they only informed of decisions already made? Is the budget and time allocated to process redesign proportionate to the technical implementation budget? After the project closes, is there a permanent internal structure in place to own the system, develop it further, and resolve issues as they arise? The answers to these questions are not formed in the presentation room — they are formed in the field. The technology may be the right choice; but the transformation only becomes real when these answers are clear.
This article was originally written in Turkish by Gökhan MERCANOĞLU on June 5, 2017 and has been automatically translated into English and other languages using machine translation.