Production management system implementation failure is almost always discussed after go-live. Operators bypass the screens, paper stays in circulation, spreadsheets come back. Those are symptoms, not causes. Survey data from JUAS shows that quality, cost and delivery outcomes are largely explained by project size and by how the plan was built, and most of that is settled more than a year before go-live. This article works backwards from the plan rather than the launch date, and sorts the five fault lines by how much control the buying organization actually has.
Production management system implementation failure is decided in the planning stage, not on go-live day
Project retrospectives are almost always held after the system is live. Walk the floor three months after go-live and you will find a production reporting screen nobody enters data into, work instructions that were printed out and then annotated by hand, and a production schedule someone rebuilt in a spreadsheet on their own PC. From this comes the usual verdict, that resistance on the shop floor was strong and that training was insufficient.
That verdict is accurate as an observation and useless as a course of action. The fact that people are not using the system is an outcome. It does not explain why the specification became something they could not use. More training will not produce reporting data if the process contains no time in which to enter it. Calming resistance will not make the screen show correct numbers if the master data does not match physical reality.
Trace these things back in practice and every symptom observed after go-live lands on a decision made twelve to eighteen months earlier. How large a slice the project was cut into. Who defined the acceptance criteria for go-live, and how. Who put current operations into words. Whether master data and the point of capture for production reporting were included in the design. Whether the site had someone able to take over day-to-day ownership. Four of these five are settled within a few months of kickoff at the latest. Only the last one, operational handover, can still be worked on close to go-live, and even there the time available has already been fixed by how the other four were decided.
The point that matters most is this. Of the five, only two are genuinely free for the buyer to move before the project starts. How the project is sliced, and who writes the specification. The remaining three follow tightly from those two. Put differently, deciding these two yourself is a bigger fork in the road than the skill with which you select a vendor.
Here is the summary of the five fault lines covered in this article. Each following section takes one row of the table and goes deeper.
| Fault line | What gets decided | When it is settled | Symptom after go-live if skipped |
|---|---|---|---|
| 1. Purpose | Whether acceptance criteria for go-live were defined in numbers | Concept and budget approval | Reported as a success because it runs, with nobody able to explain the benefit |
| 2. Size | Where one phase was cut in person-months and elapsed time | Budgeting and contracting | Schedule slippage, cascading loss of spec freeze, every decision pushed backwards |
| 3. Specification | Who wrote current operations down as a document | Requirements definition | Frequent specification changes, budget growth, customization that never stops |
| 4. Data | Whether master accuracy and the reporting entry point were designed in | Basic design through migration planning | Numbers on screen are not trusted, and a month later nobody looks at them |
| 5. Operations | Whether the site has an owner and written procedures | Three months before go-live through post-launch | An expatriate props it up, and operations collapse when that person rotates home |
These five are not independent. Slice the project badly at fault line 2 and the time to write the specification at fault line 3 disappears, the master data cleanup at fault line 4 gets pushed into a later stage, and the training window at fault line 5 is the last thing cut. Failure does not happen in one place. It progresses as upstream decisions close off downstream options.
What the data says | QCD outcomes track project size
Rather than starting from impressions, here is the published survey data. The primary source is the Corporate IT Trends Survey Report 2026, released in April 2026 by the Japan Users Association of Information Systems (JUAS), covering the fiscal 2025 survey with roughly 950 to 1,000 responding companies. It tracks user organizations in Japan over a long time series, and it consistently tabulates how well system development projects hold to quality, cost and delivery (QCD).
According to that survey, QCD adherence in system development has broadly declined over the past ten years. What deserves attention is that the breakdown splits clearly by project size. Small projects fare comparatively well, while for projects of 500 person-months or more, 30 to 50 percent of responses are negative on quality, on cost and on delivery alike.
That single finding carries a large practical implication. Building everything at once and finishing in one go is not the pursuit of efficiency, it is the accumulation of risk. Splitting the work is not a compromise. It is one of the few effective levers that shows up in the statistics.
Overseas research points the same way. A 2024 Gartner survey cited by Nomura Research Institute reports that more than 70 percent of ERP package implementation and replacement projects end without meeting their original business objectives. Note carefully what this failure means. It does not mean the system did not run. The system runs. It runs, and it still falls short of the business goals set at the outset. The purpose fault line covered below is exactly the problem this number describes.
| Survey | Scope | Key figures | How to read it in practice |
|---|---|---|---|
| JUAS Corporate IT Trends Survey 2026 | User companies in Japan, approx. 950 to 1,000 | QCD adherence broadly declining over ten years. At 500 person-months or more, 30 to 50 percent negative on quality, cost and delivery alike | Slicing the scope is itself a risk-reduction measure |
| Same survey, in-house capability issues, n=953 | User companies in Japan, n=953 | Insufficient understanding of current operations 38.2%, weak system planning capability 34.5%, specifications of the current system unknown 25.9% | Not knowing your own organization is the main upstream obstacle |
| Gartner 2024 survey, cited by NRI | ERP implementation and replacement projects | More than 70% end without meeting original business objectives | Going live and succeeding must be treated as different things |
The same JUAS survey also reports that 52.6 percent of companies increased their IT budget in fiscal 2025, with a diffusion index of 43.3 points marking a fifth consecutive year of increase, and a forecast index of 39.9 points for fiscal 2026. The leading reasons given for the increase were updating, replacing and enhancing existing systems at 66.3 percent, the weak yen together with rising personnel and vendor costs at 46.6 percent, and growth in cloud services at 45.0 percent (multiple answers were allowed, so each figure is the share of companies citing that reason). Budgets are growing, but the main motives behind the increase sit on the side of maintaining existing systems and absorbing unit-price inflation. Room for new initiatives is not automatically expanding. When something fails once, the second attempt waits for the next budget cycle.
The top causes are planning gaps for schedule, specification churn for cost, and vendor skill for quality
The same JUAS fiscal 2025 survey summarizes the leading cause behind each deteriorating QCD dimension as follows.
| Dimension that deteriorated | Leading cause | Note |
|---|---|---|
| Delivery | Insufficient consideration at planning time | Work that was never assumed during estimation surfaces later |
| Cost | Frequent specification changes | Development starts before requirements are settled |
| Quality | Insufficient vendor skill | Cited by 60 percent of companies dissatisfied with quality |
Those three lines quietly invalidate most of the binary debates people are fond of having.
First, the claim that choosing a package removes the risk of failure. The fact that the top cause of schedule deterioration is a planning gap, and the top cause of cost deterioration is specification churn, is independent of whether the implementation approach is package or custom build. Choose a package and the schedule still slips if the plan never allowed effort for absorbing the gap against your business processes, and specification changes still pile up if someone discovers just before go-live that shipment is impossible without a particular document. The package-versus-custom debate does not solve either of those.
Second, the claim that a large vendor is a safe pair of hands. The top cause of quality deterioration is insufficient vendor skill, cited by 60 percent of companies dissatisfied with quality, which means vendor selection remains the single largest quality risk. What actually matters in practice, though, is not the size of the company but whether the individuals assigned to your project understand the production mode of your industry. Under the shared label of a production management system, the functions required for engineer-to-order and for repetitive manufacturing are entirely different.
Third, the claim that starting small only leads to rebuilding later. Given that JUAS shows QCD adherence improving as project size falls, the conclusion more consistent with the data is that slicing is itself a primary means of risk reduction. Choosing to build everything at once out of fear of rework is choosing to move yourself into the 500-person-month band.
Fault line 1 | Purpose — going live becomes the goal in itself
Nomura Research Institute groups the failure factors in ERP implementation and replacement projects into three. Absence of a vision, described as a north star. A perception gap between the shop floor and management. And the difficulty of integrated management across multiple parallel projects.
The first of those, the missing north star, is fault line 1. It is the phenomenon in which the purpose quietly shifts, as the project proceeds, from solving a business problem to going live on the scheduled date.
The shift follows a pattern. Kickoff material almost always states admirable objectives. Shorter lead times, lower inventory, visible costs. Then requirements definition drags on, testing turns up defects, the go-live date approaches, and the only agenda item left in meetings is what is not finished yet. At that point nobody raises the original objectives any more. The moment every function runs on go-live day, the project is reported as a success. The Gartner finding that more than 70 percent fail to meet their original business objectives is that gap between the report and the reality, expressed as a number.
The second failure factor, the perception gap between the shop floor and management, also derives from the purpose fault line. What management talks about is business metrics. What the shop floor receives is more data entry. Without an intermediate language bridging the two, a system implementation means nothing to the floor beyond an event that adds work.
Change the go-live test from did it run to what was reduced
There is only one way to close this fault line. Define the acceptance criteria for go-live in terms of a change in operations rather than the behaviour of functions, and commit that to a document during the concept stage.
Concretely, decide in advance which indicators will be measured a set period after go-live, together with target numbers and measurement methods. What matters more than the indicators themselves is deciding first who measures them and how. An indicator with no defined measurement method will never be measured after go-live.
| Element of the go-live test | Weak version | Version that works in practice |
|---|---|---|
| Target operation | Production management in general | Producing and distributing the weekly production plan |
| Current value | (not stated) | Two people, eight hours per week to build the plan. Measured from the staff daily work log |
| Target value | Improve efficiency | One person, four hours per week. Measured from the same work log three months after go-live |
| Owner of measurement | (not stated) | Production control section manager |
| Handling if missed | (not stated) | Classify the cause and roll it into requirements for the next phase |
Filling in three to five rows of this table during the concept stage changes the character of the project. When someone asks for an additional function during requirements definition, you now have a question to put to them, which of these target values does that function move? Requests that cannot answer it can be deprioritized without anyone suffering. A substantial share of the specification churn discussed at fault line 3 stems from that question never having been prepared.
Target values may be modest. It is more important to restrict them to what can be measured in the first phase. An indicator such as company-wide inventory value will not move within three months of go-live, and too many non-system factors are involved to explain causation. Choose indicators that can be measured, whose movement can be explained, and that the shop floor can feel.
Fault line 2 | Size — how to slice implementation time and person-months
Asked how long a production management system implementation takes, the honest answer is that there is no single number. Scope, number of sites, production mode and the state of existing systems move the answer by an order of magnitude. The question can, however, be restated as one that does have an answer. Where should one phase be cut?
What the JUAS data showed was the relationship between size and QCD. At 500 person-months or more, 30 to 50 percent negative on quality, cost and delivery alike, while small projects fare comparatively well. In other words, designing the implementation timeline is not an exercise in estimating a total. It is an exercise in dividing the total so that each piece sits outside the risk band.
Suspect that a phase needs splitting once it passes 50 person-months and six months
As a working rule, when a plan comes in at more than 50 person-months and six months for a single phase, we first examine whether it can be split. This is not a JUAS figure, it is an operational threshold from field experience. There are three reasons behind it.
First, how long people remember the reasoning behind a specification. Once more than six months pass between requirements definition and go-live, the participants can no longer recall why an early decision was made. When the reason a specification exists is lost, the only way to handle the discomfort that surfaces during testing is to process it as a specification change.
Second, personnel rotation on the business side and turnover in the product mix. Over six to twelve months, the person who gave the requirements moves to another role, the target product reaches end of life, and a new line starts up. A long project ends up aiming at a moving target.
Third, the granularity of decision-making. The larger a phase, the harder it becomes to decide midway to stop or to change direction. Because the money already spent is large, the project does not halt even when it is visibly heading somewhere unwise. The essential value of slicing small is not cost reduction, it is having more than one occasion on which a decision can be made.
For the cut itself, dividing by where a business process closes works better than dividing by function.
| Basis for splitting | What it means | Where it fits | Watch out for |
|---|---|---|---|
| By business process | Take only a closed range out of order entry, requirements calculation, work instruction, production reporting and costing | Current operations only work partially | A manual bridge to upstream and downstream steps has to be tolerated for a while |
| By site | Build at one site, then roll out horizontally | Several sites share the same production mode | Care is needed not to freeze the pilot site’s local requirements as the standard |
| By product or line | Start with the main line and a representative product family | Processes differ greatly between product families | Confirm that deferring exception products will not break the design |
| By data | Production reporting and visibility first, planning functions in the next phase | The current numbers cannot be trusted | Indicators must be designed so the result is not dismissed as visibility that changes nothing |
The last of these, splitting by data, is particularly effective at plants with a previous failure behind them. Planning functions depend on the accuracy of shop-floor reporting data, so building planning functions while reporting data is not being captured produces nothing that works. Putting reporting and visibility in the first phase means clearing fault line 4 below before moving on to planning.
On the design of the split itself, starting small with a system implementation covers how to set the scope of the first phase and how to build the connection to the next one. The hard part of splitting is not making things small, it is making them small while still connecting.
One thing must be decided before any split. The master data and coding scheme shared across phases. Decide these separately in each phase and integration will force a rebuild of all data, erasing the benefit of splitting. The schemes for item codes, process codes, business partner codes and site codes should be fixed company-wide before the first phase begins.
Fault line 3 | Specification — nobody can describe current operations
The JUAS survey includes a question about the obstacles to building capability in house (multiple answers, n=953). The top entries are a shortage in the quantity of development staff at 52.7 percent, a shortage in their quality at 49.6 percent and a shortage of project management staff at 44.4 percent, but the items just below carry more weight in practice.
| Obstacles to building capability in house (n=953) | Share |
|---|---|
| Insufficient quantity of development staff | 52.7% |
| Insufficient quality of development staff | 49.6% |
| Shortage of project management staff | 44.4% |
| Insufficient understanding of current operations | 38.2% |
| Weak system planning capability (cannot turn business requirements into system specifications) | 34.5% |
| Specifications of the current system are unknown | 25.9% |
Insufficient understanding of current operations at 38.2 percent. Inability to turn business requirements into system specifications at 34.5 percent. Not knowing the specifications of the current system at 25.9 percent. None of these is a shortage of development capability. They describe a state in which the organization cannot explain how it currently does its work.
The same survey reports that roughly 60 percent of companies are bringing some or all of system development in house, seeking to combine internal work with external contracting, and that the target of that internal shift is mainly the upstream stages such as system planning and requirements definition. Companies are trying to reclaim the upstream while lacking the understanding of current operations that the upstream requires. That is the structural position user organizations are in today. The same survey says this from another angle when it lists the capabilities most lacking in IT organizations, namely recruitment and development of IT staff at 73.9 percent, data utilization and data management at 71.9 percent, and exploration and evaluation of new technology at 69.5 percent (n approximately 946).
Hand requirements definition wholesale to a vendor from this position and the outcome is predictable. The vendor does not know your operations, so it designs around a standard process flow. When the shop floor first touches the system during testing, objections arrive all at once that this is not how we do it here. That is the substance of the top cause of cost deterioration, frequent specification changes. Specification changes are not shop-floor wilfulness, they are the deferred bill for current operations never having been documented at the time of requirements definition.
The remedy is unglamorous. Before you place the order, write down current operations yourself. There is no need to draw exhaustive process flow diagrams. One page per target operation covering the following four points is enough.
| What to write | Content | Common omission |
|---|---|---|
| Who decides what, when, and looking at what | The decision-maker and the input information | It says the system calculates it, and omits that a person actually adjusts the result from experience |
| The actual forms and spreadsheets in use | The real formats being used, not idealized ones | The standard format is submitted and the modified version the floor actually uses never appears |
| How exceptions are really handled | Rush orders, walk-ins, modified specifications, rework after defects | Exceptions account for a non-trivial share of volume yet drop out of the requirements |
| Fields nobody uses | Columns that exist on the form but are never read | They get rebuilt in the new system simply because they exist in the old one |
The fourth is easy to dismiss and has a direct effect on cost. When the estimate is built on the assumption of porting current forms as they are, effort is priced in for fields nobody actually reads. Taking stock of the current state is not an exercise in adding functions, it is an exercise in building the case for removing them.
Where customization and custom development part ways
Only once current operations exist as a document can you decide whether to go with package customization or with custom development, including in-house build. Far too many projects run this in reverse, selecting a product and only then starting to count the gaps against the business, so that by the time the size of the gap is clear neither budget nor schedule can move.
Make the decision by functional area rather than for the system as a whole. Even within one system, there will always be areas where standard functionality is fine and areas that need something built for your organization.
| Functional area | Often fine on standard functionality | Where gaps tend to appear | Practical guideline |
|---|---|---|---|
| Item and bill of materials (BOM) management | Yes | Revision control of structures, handling of substitutes | Confirm up front only whether revision control is needed |
| Requirements calculation (MRP) | Yes | Consolidated ordering, handling of forecasts, definition of available stock | Modifying the calculation logic is a last resort |
| Work instruction and progress | Depends on production mode | Heavy engineer-to-order work or many process branches | Gaps tend to be larger in engineer-to-order manufacturing |
| Production reporting | Depends on the shop-floor environment | Entry terminals, barcodes, automatic capture from equipment | This is where building something specific most often pays |
| Costing | Yes | Allocation rules unique to the company | Decide after reconciling with accounting requirements |
| Forms and labels | No | Almost always needs specific work | Customer-specified forms belong in the requirements from the start |
The principle is clear. Areas that do not drive competitiveness, and where doing it the same way as everyone else is fine, move to standard functionality. Areas where your strength actually lives, and areas where the format is dictated by customers or regulators, are worth building. Build everything and you cannot maintain it. Standardize everything and the shop floor stops functioning.
Customization carries two ongoing costs beyond the price. One is the revalidation load at version upgrades. Anywhere standard functionality was modified needs a behaviour check every time the product is updated. The other is key-person dependency. If the modification specification is not documented, the change becomes a black box nobody will touch once the responsible person moves on. When you decide to customize, write receipt of the modification specification and a list of modified areas into the contract as deliverables.
On the axes for comparing products themselves, comparing production management systems covers fit by production mode and the evaluation criteria that never appear in comparison tables. Product selection is a stage that comes after fault line 3, and respecting that order is the most cost-effective decision available.
Fault line 4 | Data — a system with no reporting data dies the following month
When a live production management system stops being used within a few months, the cause is almost always data. Either the numbers on screen do not match physical reality, or the numbers never arrive in the first place. It is one of those two.
Once numbers lose credibility, the sequence runs in one direction. First the shop floor starts checking the figures on screen by hand. Then a parallel spreadsheet appears to support that checking. Finally the spreadsheet becomes the authoritative record and the system becomes a place where data is merely entered. This progression is fast, and it is not unusual for it to begin the month after go-live.
The data fault line splits into two, the master side and the reporting side.
Measure master accuracy before migration
Master migration is treated in many projects as the work of moving data, and placed in a later stage. In reality, master accuracy is the quality of your current operations made visible, and moving it does not repair it.
Four things must be measured before migration. Measuring means pulling a sample and checking it against physical reality.
| Target | What to measure | Commonly found on site |
|---|---|---|
| Item master | Share of active items that actually moved in the past year | Discontinued items were never deleted, making the selection list unusable |
| Bill of materials (BOM) | Share of sampled items whose BOM matches the physical structure | Design changes were never reflected, so requirements calculation does not add up |
| Process master and standard times | Divergence between standard times and measured times | Not updated for years, so load calculation departs from reality |
| Inventory | Actual stocktaking variance | Book and physical stock disagree, so allocation is not trusted |
Of these, BOM and standard times are the premises for requirements calculation and load calculation. Bring planning functions live on broken premises and nobody trusts the plans the system produces, so everyone reverts to adjusting by experience. That state gets described as the system being unusable, when what is unusable is the master data.
If the measurements come back poor, there are two options. Clean the data before migration, or take that function out of the first phase. Cleanup takes time, so decide this together with the split design at fault line 2. Leaving a function whose data cleanup will not finish inside the go-live scope is the choice most worth avoiding.
The reporting side is simpler still. Everything comes down to whether the person entering data has time inside the process to do it. An operating model in which everything is entered in one batch at the end of the day always loses accuracy, because it relies on memory. Reporting data must be entered where the work finished, as part of the work.
| Reporting entry method | Load on the floor | Accuracy | Where it fits |
|---|---|---|---|
| Write on paper, key into a PC later | High, because it is duplicated work | Low, from memory and transcription errors | Keep it to an interim arrangement |
| Enter at a process terminal as work completes | Medium | Medium to high | Where terminals can be placed at the process |
| Barcode or 2D code scanning | Low | High | Where item, process and operator can be identified |
| Automatic capture from equipment or PLC | Close to zero | High, though limited to what can be captured | Processes where equipment signals are available |
Automatic capture is ideal but not achievable at every process. Realistically the answer is a combination, automating where capture is possible, moving the rest to barcode scanning, and confining manual entry to exception handling.
One more item is integration with core business systems. When connecting accounting or sales management to production management, the thing to decide before the technical interface method is which side holds the authoritative data. For the item master, the business partner master and inventory quantities, decide line by line which system is authoritative and which holds a copy. Integrate while this is ambiguous and both sides become updatable, leaving nobody able to say which is correct. The integration cycle, real time or daily, and the way a failed integration is detected, are also items to settle at design time.
Fault line 5 | Operations — at a plant in Thailand, adoption is the final gate
The first four apply equally in Japan and at overseas sites. Fault line 5 is the one whose weight changes overseas, and particularly at the Thai operations of Japanese manufacturers.
When a system designed at headquarters in Japan is rolled out to a site in Thailand, an assumption is quietly built in. That the people operating it will read a manual in Japanese or English and will understand the reasoning behind the business rules. Not many sites satisfy that assumption. What follows is not statistics but structure observed repeatedly in practice (on the business environment surrounding Japanese companies in Thailand itself, see the JETRO survey of Japanese business expansion listed in the references at the end of this article).
First, language. If screen labels and error messages remain in Japanese or English, local operators cannot read them. What people do with a screen they cannot read is always the same. They memorize positions, pressing buttons in a set place in a set order. In that state, a small change to the screen layout requires retraining, and when an exception occurs nobody can make a judgement.
Second, the scope of training. In Japan, teaching the operation of the system is often enough, because the reasoning behind the business rules is already shared. At an overseas site, the explanation has to start from the business context, why this entry is required and what the number will be used for downstream. Deliver operating drills alone and entry becomes a formality, with no gain in accuracy.
Third, turnover. Once you assume that operators and floor supervisors will change, the operating model has to live in written procedures rather than in individual familiarity. Whether the procedures prepared at go-live exist in the local language, and whether someone owns updating them, determines the quality of operations a year later.
Fourth, the boundary between headquarters standards and local optimization. Coding schemes and form layouts fixed as a company-wide standard have to be respected, but push headquarters standards over local commercial practice and customer requirements as well and the floor will always build a spreadsheet behind the scenes. Draw the line explicitly before go-live between what must be preserved and what is delegated locally. In practice, the split that holds up best keeps coding schemes, master structures and accounting integration fields as headquarters standards, while the reporting entry method, shop-floor form layouts and language are local decisions.
Fifth, the support arrangement immediately after go-live. For the first month, unforeseen exceptions arrive daily. If nobody on site can answer questions during that period, the floor starts inventing its own way of working, and that is what sticks. Correcting it later costs more than building it right the first time.
How to fold these points into a plan is covered in rolling out systems to overseas plants, together with the division of roles between headquarters and the local site and how to sequence the rollout.
The implementation sequence that avoids failure | six things to decide before ordering
Turned into pre-order actions, the five fault lines become six items. The order matters. Decide them top down, or the lower items cannot be decided at all.
| Order | What to decide | Concrete deliverable | If you proceed without deciding it |
|---|---|---|---|
| 1 | Acceptance criteria for go-live | Three to five indicators, each with current value, target, measurement method and owner | It ends at the system runs so it worked, and the next investment cannot be justified |
| 2 | Scope of the first phase | Boundaries by operation, site and product, plus the connection point to the next phase | Scope swells and the project enters the 500-person-month band |
| 3 | Description of current operations | One page per target operation covering decisions, actual forms, exceptions and unused fields | Requirements definition is left to the vendor and specification churn follows |
| 4 | Boundary between standard and custom | A list by functional area, with a one-line reason for each custom item | Customization never stops and the result becomes unmaintainable |
| 5 | State of master and reporting data | Accuracy measurements and a cleanup plan for items, BOM, processes and inventory | Numbers are not trusted after go-live and spreadsheets return |
| 6 | Who takes over operations | The site owner, the language of the procedures and who updates them, and support for the first month | An expatriate props it up and operations collapse at repatriation |
Even when implementation support for a packaged product is contracted out, not one of these six can be decided on your behalf. What a support partner can do is assemble the material for deciding, lay out the options and their consequences, and shape the result into documents. The decision itself stays with the buyer.
Conversely, take quotations with these six items filled in and the differences between vendors’ numbers become readable. The differences will come from the scope of work assumed, the experience of the people to be assigned, or how risk was priced. Take quotations with the six undecided and each vendor prices on the assumption that it will absorb the open items itself, so the numbers scatter and comparison stops being meaningful.
As a matter of sequence, set aside an explicit period for settling these six items as a stage preceding requirements definition. Treat it as preparation sitting outside the plan and it will in practice be done in parallel after kickoff, which produces exactly the deferred bill described at fault line 3.
Frequently asked questions
What is the failure rate for production management system implementations?
There is no established public statistic on failure rates specific to production management systems. Two figures come closest. One is the JUAS Corporate IT Trends Survey Report 2026, where QCD adherence in system development has broadly declined over the past ten years and, for projects of 500 person-months or more, 30 to 50 percent of responses are negative on quality, cost and delivery alike. The other is the 2024 Gartner survey cited by Nomura Research Institute, reporting that more than 70 percent of ERP package implementation and replacement projects end without meeting their original business objectives. What to take from these is not the failure rate itself but the structural point that failure is distributed by size. Small projects fare comparatively well and negative assessments rise with scale. In other words, the probability of failure is not a given condition, it is a variable the buyer can move through how the project is sliced. Note also that no region-specific statistic such as a failure rate for Thailand exists, so if you encounter such a number, check its source.
How long does a production management system implementation take?
Because scope, number of sites, production mode and the state of existing systems move the answer by an order of magnitude, quoting a general duration means almost nothing. The more practical question is where to cut a single phase. Our own rule is to examine whether a split is possible as soon as a plan exceeds 50 person-months and six months for one phase. That is an operational threshold rather than a JUAS figure, and it rests on three reasons. First, beyond six months participants can no longer recall the reasoning behind early specification decisions, so discomfort surfacing in testing gets processed as specification change. Second, within six to twelve months people rotate and product families turn over, leaving the project aiming at a moving target. Third, the larger the phase, the harder it becomes to decide to stop partway. The essential value of splitting is not cost reduction but having more than one occasion to decide. Shortening the individual decision cycle produces results sooner than trying to shorten the total duration.
Which is less likely to fail, a package or custom development?
The question itself sits outside the main causes of failure. In the JUAS fiscal 2025 survey, the leading causes of QCD deterioration were insufficient consideration at planning time for delivery, frequent specification changes for cost, and insufficient vendor skill for quality, the last cited by 60 percent of companies dissatisfied with quality. All three are independent of the implementation approach. Choose a package and the schedule still slips if the plan never allowed effort for absorbing gaps against your business, and specification churn still follows if development starts before requirements settle. What needs deciding is not the product category but, area by area, whether to move to standard functionality or to build. Areas that do not drive competitiveness and can work the same way as everyone else move to standard. Areas where your strength lives and areas where customers or regulators dictate the format are worth building. Make that call by functional area, after documenting current operations. If you are considering an in-house build, first check whether the obstacles JUAS identifies apply to you, namely insufficient quantity of development staff at 52.7 percent, insufficient quality at 49.6 percent and a shortage of project management staff at 44.4 percent.
How much customization is acceptable?
Decide by whether you can carry the ongoing cost, not by a spending cap. Customization brings two continuing costs beyond the initial price. One is revalidation at product version upgrades, since anywhere standard functionality was modified needs a behaviour check at each update. The other is key-person dependency, because an undocumented modification specification becomes a black box nobody will touch once the responsible person changes. Only the areas where you have the capacity to carry both are areas you may customize. In practice, customer-specified forms and labels, and the production reporting entry point that depends heavily on the shop-floor environment, are where building something specific most often pays, while modifying the requirements calculation logic itself should be the last resort. In addition, at the moment you decide to customize, put receipt of the modification specification and a list of modified areas into the contract as deliverables. A function built under a contract that does not give you the source or design material becomes an asset nobody can touch a few years later.
If an implementation has already failed, is rebuilding the only option?
Rebuilding is rarely the first option in practice, because the remedy depends on which fault line the symptoms come from. If the reason the shop floor is not using the system is master accuracy, rebuilding the system produces the same result unless the master data is fixed, so master cleanup comes first. If reporting data is not arriving because of when and where entry happens, revisiting the entry method, barcode scanning or automatic capture from equipment, can solve it. If the benefit cannot be explained because no purpose was ever defined, you can define the go-live indicators after the fact and start by measuring. Rebuilding becomes necessary when the business itself has changed to the point that the current data structure cannot represent it. To make the call, first classify the failure by fault line rather than by symptom. It is not unusual for that classification to show that the next area to work on is only part of the current system. Establishing how much of the existing asset can be kept, then cutting a small scope to start from, is more reliable than a full replacement.
What deserves particular attention when implementing at a plant in Thailand?
Five things. First, the language of screens and error messages. What people do with a screen they cannot read is memorize positions, which means retraining after every layout change and nobody able to judge when an exception occurs. Second, the scope of training. Teaching operation alone is often enough in Japan because the reasoning behind the rules is shared, whereas at an overseas site the explanation has to start from why this entry is required and what the number is used for downstream. Third, written procedures. Assume turnover, and settle both the local-language procedures and who owns updating them before go-live. Fourth, the boundary between headquarters standards and local optimization. In practice, the split that holds up best keeps coding schemes, master structures and accounting integration fields as headquarters standards while leaving the reporting entry method, shop-floor form layouts and language to local judgement. Fifth, support during the first month after go-live. Without someone on site to answer questions in that period, whatever the floor invents for itself is what sticks. These are structural patterns observed repeatedly at sites in Thailand, offered as practical experience rather than as regional statistics.
Summary
Production management system implementation failure does not happen on go-live day. It is settled twelve to eighteen months earlier. The symptoms observed afterwards, people not using the system, paper staying in circulation, spreadsheets coming back, are all the result of upstream decisions having closed off downstream options. Listing symptoms does not produce a course of action.
What the JUAS Corporate IT Trends Survey Report 2026 shows is that QCD adherence has broadly declined over the past ten years, and that while projects of 500 person-months or more draw negative assessments from 30 to 50 percent of respondents on quality, cost and delivery alike, small projects fare comparatively well. The leading causes of deterioration were insufficient consideration at planning time for delivery, frequent specification changes for cost, and insufficient vendor skill for quality, cited by 60 percent of companies dissatisfied with quality. All of these are independent of the choice between package and custom build, and they resolve back to how size is sliced and how requirements definition is done. The 2024 Gartner survey cited by Nomura Research Institute, in which more than 70 percent of ERP projects end without meeting their original business objectives, likewise shows that going live and succeeding are different things.
The five fault lines set out here are purpose, size, specification, data and operations. At the purpose fault line, change the go-live test from did it run to what was reduced, and write current value, target, measurement method and owner as a set. At the size fault line, suspect that any phase exceeding 50 person-months and six months needs splitting, and cut by business process, site, product or data. At the specification fault line, write down current operations yourself. That JUAS lists insufficient understanding of current operations at 38.2 percent, weak system planning capability at 34.5 percent and unknown current-system specifications at 25.9 percent shows that this is work which cannot be contracted out. At the data fault line, measure the accuracy of items, BOM, processes and inventory before migration, and design reporting entry as part of the work in the process. At the operations fault line, put in place a site owner, procedures in the local language and a support arrangement for the first month after go-live.
Of these five, only two are genuinely free for the buyer to move before starting. How the project is sliced, and who writes the specification. Vendor selection is a later stage, and taking quotations with these two open means the numbers scatter and comparison stops being meaningful. Settle the two and the options for the remaining three narrow sharply. Avoiding failure may not be the most accurate description of what this is. What you are actually doing is creating a state in which decisions can still be made, before failure is settled.
It is fine if you have not yet decided where to start. If you can show us your current process flow and the forms and spreadsheets the shop floor actually uses, we can look at which of the five fault lines are unaddressed and suggest ways to cut a first phase that preserves your opportunities to decide, even if that is all we provide. We are also happy to talk with plants that have been through an implementation that did not go well. Feel free to get in touch through our contact page.
References
- Japan Users Association of Information Systems (JUAS), “Corporate IT Trends Survey Report 2026” (April 2026, in Japanese)
- JUAS, “Corporate IT Trends Survey 2026” first press release (2026, in Japanese)
- Nomura Research Institute, “Realizing Business Transformation through ERP Implementation and Replacement — Keys to Success Read from Three Failure Factors” (August 2025, in Japanese)
- Nomura Research Institute, NRI Management Review No.24, “The Difficulty of ERP Package Implementation and Replacement Projects, and the Prescription” (January 2026, in Japanese)
- i Magazine, “JUAS Releases Preliminary Figures from the Corporate IT Trends Survey 2026” (February 2026, in Japanese)
- Japan External Trade Organization (JETRO), “Survey on Business Expansion of Japanese Companies in Thailand, FY2024” (February 2025, in Japanese)
