Picture a mid-sized manufacturer that has been running an MRP (material requirements planning) system for years. Production scheduling works, inventory gets tracked, and the team knows every screen by heart. Then management decides it is time to bring accounting, sales, and purchasing under one roof and invest in an ERP (enterprise resource planning) system. On paper the logic is sound. In practice, surprises start arriving before the installation discs are even opened. Knowing these problems before they hit is the difference between a painful project and a manageable one.
The gap between MRP and ERP is not simply one of scale. MRP focuses on production and materials. ERP is designed to connect every department in the company — production, finance, sales, purchasing, and human resources — inside a single system. Merging all of that means the old MRP data cannot be moved across as-is. Stock codes, customer records, supplier cards, bills of materials — each of these has to be converted into a format the new system understands. That conversion is where the first major problem lives, and most companies underestimate how messy it turns out to be.
Data migration is the most frustrating stage of any ERP transition. When you pull records out of an old MRP system, inconsistencies surface fast. Stock codes entered by hand over the years carry accumulated errors. Some items appear under two different codes because a product was renamed but the old record was never deleted. Customer names are spelled three different ways across the database. Some supplier cards are missing phone numbers or addresses. If you load all of this into your new ERP without cleaning it first, the new system inherits every problem the old one had. Think of it as pouring dirty water into a clean container — the container does not purify the water. A thorough review of existing records before migration is not optional; for a company of even moderate size, that review takes weeks.
The second major obstacle is staff resistance, and it is more predictable than most managers want to admit. The warehouse supervisor has been opening the same inventory screen every morning for three years. She knows where every column is, how far to scroll, which shortcut saves a minute. A new program puts different menus in different places. By the end of the first week she is leaving work with half her tasks unfinished. By the second week she is telling anyone who will listen that the old program was better. This reaction is not obstruction — it is a natural response to disruption. If management treats it as personal defiance, the project turns into an internal conflict that slows everything down. A more effective approach is to identify one capable person in each department before the go-live date, involve that person in testing alongside the software vendor, and give them the informal role of local resource. Colleagues ask questions more freely when the person answering sits three desks away.
The third problem is process mismatch. ERP systems are built around structured workflows. The purchasing module may expect a request, an approval, an order, a goods receipt, and finally a payment — five distinct steps in sequence. But in many Turkish SMEs the owner calls the supplier directly, the goods arrive, and accounting finds the invoice three days later. The ERP does not accommodate that flow; it requires each step to be completed before the next one opens. At that point the company faces a choice: adapt its working habits to fit the software, or pay the vendor to customize the software to fit existing habits. Neither is painless. Changing habits means convincing the owner to follow a process he has ignored for years. Customization costs extra money upfront and creates compatibility headaches when the vendor releases a new version down the road.
During the transition, the old and new systems typically run side by side for a period. Every transaction gets entered into both programs and the results are compared to confirm accuracy. This parallel-run phase is necessary but exhausting. Staff enter the same data twice, which doubles the time on routine tasks and increases the chance of entry errors. On top of that, technical support for the old MRP system may have already ended, meaning any problem that surfaces in the legacy software has nowhere to go. To be realistic: a parallel run rarely lasts less than two months, and during those two months the company operates at reduced efficiency. A project budget and timeline that does not account for this extra load will run short before the finish line.
Before signing anything, an SME manager preparing for this transition should answer three honest questions. First: is the existing data clean enough to migrate, and if not, who will clean it and how long will that take? Second: which staff members will carry the change internally, and how will they be prepared before the go-live date? Third: does the contract with the software vendor specify data migration support and a defined parallel-run period in writing? These are not details to settle after the project starts. An ERP transition that is planned with open eyes about its difficulties has a real chance of working. One that is launched on optimism alone tends to stall somewhere between the first data export and the second month of parallel running.
This article was originally written in Turkish by Gökhan MERCANOĞLU on May 22, 2000 and has been automatically translated into English and other languages using machine translation.