Small Start System Implementation – How to Phase a Factory System Rollout

A small start system implementation is usually described as the thing you settle for when the budget will not stretch. The primary data points the other way. The larger the project, the higher the share that ends up rated poor on quality, on budget and on schedule. Which means the decision about how big to cut each phase is itself the largest piece of risk management in a factory core system replacement. This article walks through the actual figures from published surveys, then sets out where to cut, and where you must never cut.

Small Start Is Not a Compromise, and Here Is the Conclusion First

When a Japanese-owned plant in Thailand or elsewhere in ASEAN begins looking at replacing its production management system, the first idea on the table is almost always some version of “if we are going to do it, let us do all of it at once.” Order intake through shipping, plus inventory, costing and quality records, all migrated in one move. On paper the logic holds. A phased rollout means old and new run alongside each other through the transition, and that costs effort.

Yet when you look at a survey that tabulates completed projects by size, that intuition is contradicted by the numbers. Chapter 7, System Development, of the report published by the Japan Users Association of Information Systems (JUAS), Kigyo IT Doko Chosa Hokokusho 2026 (Corporate IT Trends Survey Report 2026, covering the 2025 survey year), describes QCD compliance (quality, cost, delivery) by project size as follows.

The share rated poor is below 10.0% across all of QCD at the project size ‘under 10 person-months’, whereas at the project size ‘500 person-months or more’ it is high, at 29.6% for quality, 42.2% for budget and 47.8% for schedule.

The report goes further and states that across all of QCD, the smaller the project size the higher the share of good outcomes, and the larger the project size the lower. Lining up only the two extremes gives this.

This table needs to be read with care. The quality and budget figures come from an exhibit that splits project size into five bands. The 47.8% for schedule comes from a different exhibit that splits size into three bands. A band called “schedule for under 10 person-months” does not exist in the three-band exhibit, and it can only be inferred from the summary statement in the report text. That is why the bottom-left cell above carries the wording rather than a number.

Even so, what comes through is unmistakable. Attempt to build something in the 500 person-month class in one go, and roughly four in ten projects overrun the budget while roughly five in ten run late. This is not an exception you can dodge by executing well. It is the average picture across a large body of tabulated projects. Cut the work into pieces under 10 person-months, on the other hand, and the poor share on every one of the three dimensions falls below one in ten. Slicing is not an admission that you lack capability. It is the choice to place yourself on the statistically favourable side.

This article carries that single point all the way through. Cutting small is not a compromise. There is a relationship between project size and QCD failure rates that primary data supports, and how you cut is itself the largest piece of risk management you have.

What the Data Says About Project Size and QCD

Start with the underlying numbers, in full. The source is Exhibit 7-1-4, QCD Compliance in System Development by Project Size, in the JUAS report Kigyo IT Doko Chosa Hokokusho 2026 (2025 survey year). All units are percent, and n is a count of projects.

Quality compliance

The dissatisfied share for quality climbs monotonically from 5.4% to 29.6% as size increases. Divide the two extremes and you get 29.6 divided by 5.4, which is 5.48 times. Unrounded it runs to 5.481, so quoting 5.48 to two decimal places is the honest way to put it. The temptation is to say about six times, but the division yields 5.48, not 6. This article treats it as 5.48 times, without rounding.

Budget comes next. Here is the budget side of the same exhibit.

Budget compliance

The extreme-to-extreme ratio for budget overrun is 42.2 divided by 6.0, which is 7.03 times. The gradient is steeper than the 5.48 times seen on quality, so size bites harder here. For anyone signing off capital in a plant, this is the more painful of the two. Dissatisfaction with quality leaves some room to paper over the gap in daily operation. A budget overrun sends you straight back through the approval process.

One thing to avoid is manufacturing ratios between the intermediate bands. Asking, for instance, how many times 19.6% budget overrun at 50 to under 100 person-months is relative to 6.0% at under 10 person-months is arithmetically possible, but what the report is giving meaning to is the monotonic pattern that failures rise as size rises, not any individual multiple. The only two ratios this article treats as figures are the two above.

For schedule, the size bands change. Exhibit 7-1-3 in the same report, Schedule Compliance in System Development by Project Size and Year (2025 survey year), uses three bands.

Schedule compliance, three bands

It is worth reconciling the band counts here. The quality and budget tables use five bands, the schedule table three bands. Because the counts differ, rows from the five-band table must not be set alongside rows from the three-band table. The project counts confirm it. The sums below are this article adding up the n values printed in the report’s tables. Adding the n values in the quality table gives 688 plus 562 plus 405 plus 319 plus 223, or 2,197 projects. Adding the n values in the schedule table gives 1,647 plus 317 plus 226, or 2,190 projects, a gap of 7. On top of that, the three smaller bands of the quality table (688 plus 562 plus 405, or 1,655 projects) and the under 100 person-months band of the schedule table (1,647 projects) differ by 8. The tabulated populations do not match exactly, and so the two tables cannot be joined to derive a schedule-delay rate for under 10 person-months.

A few conditions apply when reading these numbers. First, this is a survey of user companies in Japan, not a tabulation of projects run by Thai entities. Applied to a Japanese-owned plant in Thailand, it should be used as a reference for the direction of the effect, not adopted as a forecast for your own site. Second, n counts projects, not companies. The survey as a whole has 957 valid company responses, but a single company answers for multiple projects, so the n values in the tables should not be confused with the 957 companies. Third, from the 2025 survey year the answer options gained three new entries: exceeded expectations, completed under plan, and completed early. The report itself cautions that an additional option has been added on the favourable side and that the effect of this needs to be taken into account, so year-on-year improvement cannot simply be discussed as a comparison. What this article uses is strictly the comparison between size bands within the same survey year.

Some rows do not sum to 100.0% because of rounding. It is also better not to add or subtract the printed values to manufacture new indicators.

Why Big Projects Break, and How Requirements Fail to Reach Specification

So there is a relationship between size and QCD failure rates. Why do big projects break? Another exhibit in the same report hints at the cause that sits one step upstream. It is Exhibit 7-2-7, Challenges in Advancing In-House System Development (multiple response, 2025 survey year, n=953).

Because this is a multiple-response question, adding the column gives you nothing. The total exceeds 100%. What to read is the ranking and the level.

The top three are about headcount and proficiency, that is the quantity and quality of developers plus project managers. But in the context of this article the fourth and fifth entries carry more weight. Insufficient understanding of current operations sits at 38.2%, and weak system planning capability, meaning business requirements cannot be turned into system specifications, sits at 34.5%. As a challenge in advancing in-house development, more than one company in three names a stumble in the step that translates their own operations into a specification.

This connects directly to the size problem. The larger the project, the longer the distance between freezing requirements and seeing the first screen actually run. At the 500 person-month scale, the line in the requirements minutes saying “this is how we want to operate” only becomes something you can try on the shop floor many months later. In the meantime there is no way to check whether the requirement was translated into the specification correctly. Errors in that translation surface during testing, or in the worst case after go-live. Trying to fix them at that point means a wide blast radius, because surrounding functionality has already been stacked on top. This is the main route by which budget overruns and schedule slips are generated.

Cut instead into pieces under 10 person-months and the distance from writing a requirement to seeing something run is short. Translation errors are found early, while the blast radius is still small. The essence of a small start is not reducing the volume you build. It is building a mechanism that finds translation errors early. The total volume you build may well end up the same. What differs is the distance you travel while carrying an error.

In the summary of the same chapter, the report also states that a shortage of skills, in employees and in vendors alike, has become a more prominent factor behind deteriorating QCD. Skills do not rise in the short term. If you are going to change your design on the assumption of something you cannot raise, the available move is to reduce the amount of complexity handled at one time.

One more point: the headcount problem is not confined to surveys in Japan. In the 2025 DX Trends Survey by the Information-technology Promotion Agency, Japan (IPA), with 1,799 responses collected between 17 April and 12 June 2026, the combined share answering somewhat short and severely short on the quantity of staff driving DX was 85.5%. This is a separate survey from JUAS, however, with a different sponsor, a different period and a different set of companies. Its figure cannot be set beside the JUAS numbers to compute a ratio, nor can the two be discussed as larger or smaller on the same scale. It is referenced here only as background for the point that the perception of a people shortage is widely shared.

Where to Cut, and How to Choose the Unit

Once you have decided to slice, the next question is how. For factory business systems, the cuts that work in practice sort into roughly four kinds.

Of these, the two with the fewest failures are cutting by process and cutting by form. In both, who on the floor will use it is clear, and whether go-live succeeded can be judged by what the floor actually feels. Cutting on period alone, by contrast, is dangerous. Trimming functionality to fit inside a three-month box sometimes trims away the parts you could not afford to lose. The right order is to hold period as a constraint and let the operational side decide the unit you cut.

Cutting by site calls for one further caution. When practice varies across several plants in Thailand, that variation mixes differences that are inevitable because the products and equipment differ with differences that are just gradual drift each time a person handed over the job. Keep the former, and align the latter in phase one. Roll out across sites without doing that sorting, and per-site customisation multiplies until you are carrying the same complexity as one big all-at-once project.

The practical steps for cutting by form are set out in the article on electronic form systems. For the order in which to replace things when you are getting out of a paper-based operation, see How to Break Away From Paper Operations in the Factory With an Electronic Forms System. For the scope and cost picture when cutting by process, Process Management System Costs and How to Choose One is a useful reference.

Once the unit is decided, always write down at the same time what gets added from phase two onward. The question is whether the phase one design document lists, even as names only, the fields, screens and interfaces that phase two will bring. Build phase one with that section blank and phase two will mean rebuilding the foundations. This is the entry point to the failure pattern described later as having no design for horizontal rollout.

The Places You Must Not Cut, Namely Masters, Numbering and Permissions

This is the part of the article that matters most. Plenty of articles recommend a small start, but few of them spell out the places you must not cut. And in practice, accidents nearly always happen in these three.

Slicing means dividing functionality. But divide the shared foundation that sits underneath the functionality as well, and duplicate management is guaranteed from phase two onward. Concretely, that foundation is three things: masters, numbering and permissions.

Do Not Split the Masters

Item masters, business partner masters, process masters, equipment masters, unit masters. Build these to match the scope of phase one, holding only what this round uses, and a second master will appear in phase two without fail. The usual way it breaks looks like this.

Phase one covered incoming inspection only, so the item master was loaded with purchased parts only. Phase two took on assembly results, and manufactured items now had to be registered. But the phase one item master had no fields for holding a manufactured item, meaning process, standard time and bill of material, so a separate master was created for phase two. From that moment there are two ledgers for the same concept of an item. Every subsequent addition or change to an item means editing in two places, and items updated in only one of them will certainly appear.

The way around it is simple. Do the field design of the masters against the final scope, not the phase one scope. Loading actual values only for what phase one uses is perfectly fine. Build the vessel at final size and fill the contents in stages. The effort to build the vessel is small next to the effort of building functionality. Economise here and it comes back multiplied later.

One more thing to settle fully in phase one is the code scheme for the masters. Digit counts and semantics for item codes, site codes and process codes. Change these later and the whole of the existing data needs converting. Locking them down at phase one, while data volume is still small, is the cheapest moment available.

Do Not Split the Numbering

Production order numbers, lot numbers, document numbers, work order numbers, inspection numbers. Divide the numbering rules and the entity that issues numbers, and you get duplicates or gaps.

A typical case. Phase one covered packing and shipping, and packing numbers were issued by the new system. Phase two took on inventory movements, but the existing Excel was also assigning numbers in the same scheme, so both issued the same number. In the warehouse there are now two labels bearing the same number, and the correspondence between physical goods and data breaks down.

What makes this accident nasty is how late it is detected. A duplicated number does not surface until two records happening to share it are processed at the same time. It shows up as a stocktake six months later that simply does not reconcile. By then the only remedy is chasing by hand to work out which record is correct.

Always designate a single issuing authority for numbering. If the phase one system is to be the issuer, then the numbering schemes for everything handled from phase two onward belong inside it too. Even for areas not yet systemised, reserve the scheme up front. That reservation costs one page in the design document.

At plants where traceability matters, this point carries particular weight. Break the continuity of lot numbers and a retrospective investigation cannot be constructed at all. Slicing and traceability are not in conflict, but that holds only where the numbering was not split.

Do Not Split the Permissions

User registration, the organisational hierarchy, approval routes, visibility scope. Hold these independently per phase and accounts belonging to leavers will remain.

At a Thai site this problem bites harder than it does in Japan. In an environment with turnover among local staff, separate user ledgers per system inevitably produce the state where an account was deleted in system A but still lives in system B. An account able to enter production results that still belongs to someone who has left is hard to explain, whether the audience is an auditor or quality assurance.

Put users and permissions in one company-wide place from phase one. If an authentication platform already exists, consolidate onto it. If there is none, build one in phase one and have every subsequent phase reference it. Looked at through phase one alone it reads as over-investment. Looked at through three phases it is reliably cheaper.

What May Be Split and What May Not

Set out in order, it comes to this.

The lower half of that table is, in effect, phase zero. Put it in place as the shared foundation before building any phase one functionality. As a share of effort it is a small part of the whole, but run without it and the effort in phases two and three swells. Sliced the work and still ended up with all the pain of building big is, in most cases, exactly this pattern.

For the cost structure when integration with a core system is assumed, Business System Development Costs and How to Think About ERP Integration breaks it down layer by layer. It is useful for checking which layer the phase zero equivalent lands on.

Why Slicing Works Especially Well at a Thai Site

Everything so far has been general reasoning grounded in survey data from Japan. Japanese-owned plants in Thailand and ASEAN have further circumstances that make slicing more advantageous still.

The first is that a long project spans changes of personnel. According to RECRUITdee’s Thailand Job Market 2026 Outlook, the average salary increase budget for 2026 is around 4.7%, and in high-skill fields the uplift in compensation on changing jobs is given as 15 to 30%. These two are numbers of different kinds. The 4.7% is an annual rate for someone who stays in post. The 15 to 30% is a one-off step taken at the moment of a job change. They are not in a relationship where they can be divided or added. Set side by side, though, they do show where the incentive to move sits for people with skills. The same report gives attrition in the region at around 17.5%. That figure is written as a regional number, and it is not stated as a Thailand-only figure, so it cannot be asserted as Thailand’s attrition rate. It still serves as a reference for the general level. The report contains no salary amounts, so this article does not go into monetary figures.

Suppose a project of 18 months (this duration is an assumption used for illustration). There is no guarantee that the local staff who took part in requirements definition are still in post at go-live. Japanese expatriates, too, sometimes rotate mid-project at the end of an assignment. The reasoning behind a decision, the part not written in the requirements minutes, usually lives only in the heads of the people who were in the room. When people change, that context is lost. Looking at the surviving specification, the team concludes that it cannot tell why the design is this way, and stops to check. This is the amplifier of schedule delay that is specific to a Thai site.

Slice into three-month phases and the chances rise that the same people carry a phase from requirements through to go-live. The deliverable is finished before the context is lost. This is not organisational theory, simply a matter of elapsed time.

The second circumstance is that the venue for decisions is dispersed. The plant manager at the Thai entity, the head of administration, the information systems department at the Japanese head office, and in some cases a head office business division. A big project tries to line all of them up on a single agreement at once. Building that agreement takes time, and the cost of changing anything once agreed is high. With small phases, the scope of approval stays small too. Being able to take the results of phase one into the approval for phase two is another advantage.

The third is uncertainty in the economic environment. The same report puts the outlook for Thailand’s 2026 economic growth at around 1.6%, attributed explicitly to the IMF. In a phase of modest growth, approval for large investment is harder to obtain, and even where it is obtained there is a risk of review partway through. A small start, where the investment decision can be cut every three months, sits well with that environment.

On selecting a supplier in Thailand, How to Choose a System Development Company in Thailand sets out the criteria. If you are proceeding in slices, continuing with a partner who understands the shared foundation works out cheaper in the end than switching supplier for each phase.

How Small Starts Typically Fail

None of this says that slicing guarantees success. Small starts have their own characteristic ways of failing. Four are common.

1. It ends at the PoC. A trial is run to confirm the benefit, everyone is satisfied that it was confirmed, and it stops there. The usual cause is that the trial was designed without conditions for moving to production. What has to be true to proceed to production rollout, who decides, and where the budget for that comes from. Fail to settle those three at the start of the trial and the trial stays a trial.

2. It is too small to produce a benefit. One form was digitised, but everything before and after that form is still on paper, so transcription remains. Worse, there is now an extra place to key data into and the workload has grown. The unit you slice should be the smallest unit in which the work makes a complete circuit, not the smallest unit of functionality. If you are digitising the daily work report, close the loop from the report through aggregation to results posting. What you avoid is a design that reverts to paper partway through.

3. There is no design for horizontal rollout. Phase one succeeded, but the attempt to extend it to plant 2 failed because phase one had been fitted too tightly to how plant 1 operates. Observing the places you must not cut from the previous section prevents most of this, but on top of that the phase one design has to state explicitly which settings vary by site and which do not.

4. The vendor changes every phase. Competitive quotes each round look cheaper, but because understanding of the shared foundation is not carried over, phase two onward adds effort for investigating the previous phase’s specification. Intent behind masters and numbering includes parts that cannot be fully written into documentation, and those parts live in the heads of the people who built the previous phase.

What these four have in common is the error of optimising phase one in isolation. A small start is not doing one small project. It is decomposing a large objective into a sequence of small projects. Without a design for the sequence, what you have is simply small-scale development, and the benefit available from the relationship between size and QCD only reaches you in part.

Choosing Phase One by Starting From the Symptom

So what do you choose for the first phase? The difficulties talked about on a factory floor nearly always fall into one of four symptoms.

The easiest thing to handle as phase one is eliminating double entry. There are three reasons. First, the scope is clear. The target can be listed out as the fields entered into both this paper form and this spreadsheet. Second, measuring the benefit is simple. It is judged on whether the number of keying passes and the time taken went down. Third, resistance on the floor is low. Double entry is wasted work for everyone, and almost nobody objects to removing it.

If you are starting from Excel hitting its limits, separate out what the limit actually is. Files fragmenting so that nobody knows the current version is a sharing and permissions problem. Calculations being slow is a data volume problem. Aggregation requiring manual steps is a structural problem. Each has a different remedy. Lump them together as let us stop using Excel and build a system, and the requirements broaden until phase one has grown large.

Removing key-person dependency matters, but it is often a heavy theme for phase one. Being key-person dependent means the procedure is not documented, and that means an inventory of the work itself is required before systemisation. As seen earlier, the share of companies naming insufficient understanding of current operations as a challenge is 38.2%. This is a step that takes time. A realistic approach is to take only the entrance to key-person dependency in phase one, for example putting into the system only the part of the judgement criteria that can be expressed numerically.

One commitment is worth making when you talk about benefits. Fix the baseline as a single definition and declare it. Write, for example, that the reference is the total time from entry to completed aggregation for daily work reports on process A across one month in June 2026. Measure after the improvement using the same definition. Change the reference month to month, or reselect a convenient month, and you can produce numbers but they carry no meaning.

On monetary estimates, the published data does not include per person-month rates or going prices for implementation, so this article gives no absolute amounts. If you want to estimate for your own company, the procedure is as follows. First, measure the total monthly hours for the work in scope. Next, multiply by your own actual labour cost rate to obtain the monthly labour cost equivalent. Measure the post-improvement total hours using the same definition and take the difference. Compare that difference against the implementation cost actually quoted to you. The rate used here is your own real figure, not an external market rate. All of this is a procedure for calculating with your own values, not a set of figures presented by this article.

Once you reach the stage of selecting a product, Comparing and Selecting a Production Management System sets out the evaluation criteria. When you are proceeding by small start, what matters in product selection is less the breadth of functionality and more whether the structure lets you widen scope in stages.

Drawing the Line Between In-House and Outsourced, and How It Meets the Small Start

Deciding how to slice also settles who builds. In the summary of the same chapter, the JUAS report raises the following points.

• Roughly 70% of companies aim, as a matter of policy, to use in-house development and external outsourcing selectively
• In practice too, upstream steps such as system planning and functional requirements definition have a high in-house share, while system building such as design, implementation and testing has a high outsourced share
• In the 2025 survey year, cost reduction ranked above knowledge accumulation among the benefits expected from in-house development, and the report surmises this reflects vendor price increases

This structure meshes well with the design of a small start. Holding the upstream in-house means deciding for yourself where to cut. Where to cut, and what belongs in the shared foundation of phase zero, can only be judged by people who understand your own operations. The insufficient understanding of current operations at 38.2% and the weak system planning capability at 34.5% seen earlier are precisely challenges in this upstream step. Hand it wholesale to an outside party and where to cut ends up being decided by ease of building, producing a phase in which the work does not make a complete circuit.

Design, implementation and testing, by contrast, are the parts where outside capability can be used. Proceed in slices and the implementation volume per phase is small, so the management load of outsourcing is small too.

The line itself, meaning who owns which layer, is covered in AI Insourcing Support and How to Decide Which Layers Stay In-House. That article cuts vertically, asking who owns each layer. This one cuts horizontally, asking where to divide a single project. The two are complementary, and in practice both need to be decided together. Settle only the vertical line and the size of each phase remains undecided. Settle only the horizontal slicing and who owns the upstream remains undecided.

This overlaps with the observation about skill shortages noted earlier. It is not a simple matter of leaning in-house to solve it, or leaning on outsourcing to solve it. Whichever way you lean, the remedy of lowering the amount of complexity handled at one time works.

A 13-Week Path, About 90 Days, to Run Phase One

Finally, here is how it plays out on a timeline. The following is a standard structure proposed by this article, and the durations and allocations are assumed values. Adjust them to your own organisation.

The key point in this structure is that phase zero sits in weeks 3 to 4. The urge is to skip it and start requirements definition in week 5, but the bill for skipping it always arrives in phase two. Put the other way, whether you can spare two weeks for phase zero is the dividing line for whether a small start works.

The other key point is that enumerating field names for phase two onward sits in weeks 5 to 6. It is not designed. The names are simply listed. Even so, it tells you whether the master vessel is missing fields. The task finishes in a few days, and whether you did it changes the effort required in phase two.

There is intent behind setting the week 11 test as the floor staff can run it for a day on their own. Running while project members are standing next to the operators does not mean the system is live. Whether it turns over once hands are off is the substantive pass or fail.

And when the 13 weeks are done, always hold a review before entering the next phase. Was the unit of slicing right, what was missing from phase zero, will the benefit measurement definition still work next time. That review is the mechanism by which accuracy improves the more phases you stack.

Frequently Asked Questions

Where should factory DX start?

First, pick one symptom. Out of double entry, transcription errors, Excel hitting its limits and key-person dependency, take whichever the floor calls most painful. Then check whether that symptom can be cut at the smallest unit in which the work makes a complete circuit. If it can, that is phase one. If it cannot, for instance where no benefit appears unless the whole process is covered, widen the scope a little. The order runs symptom identification, baseline measurement, shared foundation design, phase one implementation. Entering through the word DX makes the scope diverge, so entering through the difficulty is the practical route.

Where do the limits of Excel management show up?

There are three kinds of limit, and they arrive in a different order with different causes. The first is the sharing limit, the state where files have split into several and nobody knows the current version. The second is the capacity and speed limit, the state where row counts have grown and files take time to open. The third is the structural limit, the state where every aggregation requires manual copy and paste. The one that bites most often in practice is the third, and it occurs even at low row counts. Judging that you are fine because the row count is still small may mean you have mistaken which kind of limit you are facing. Note that the sources referenced by this article do not include any published threshold for row counts or record counts at which the limits arrive.

Where do you start when eliminating double entry?

Start by writing out on paper the fields that are being entered twice. A diagram that simply draws arrows from which field on which form to where it is transcribed is enough. Then pick the arrows that are most numerous, or the ones that take longest per pass. If one side can be abolished, that is the cheapest solution. Where both are genuinely needed, make the entry happen once and have the other generated automatically. This work can be done before you buy any system. Doing it first actually clarifies the assumptions behind the quotes you receive.

In manufacturing, where do you start on breaking key-person dependency?

Key-person dependency comes in a type where the procedure is not documented and a type where the judgement criteria are not put into words. The former largely resolves once procedure documents are written. The latter requires expressing the judgement criteria numerically before systemisation. The question is whether something judged by eye can be replaced with something judged as passing when this value falls in this range. Loading the parts that can be replaced, in stages, is the realistic route. Attempt to put everything into words at once and that is where it stalls. In the JUAS survey, 38.2% of companies named insufficient understanding of current operations as a challenge for in-house development, and that is the flip side of key-person dependency.

Should the move away from paper be done all at once?

Not all at once is safer. The reason is that paper often carries functions beyond recording. Posting on a noticeboard, approval by circulation, writing on it at the workstation, submission to an outside party. Try to replace all of those in one move and the omissions surface after go-live. Choose one form, enumerate every function that form performs, and then replace it. Establish that procedure on one form before moving to the next, and the ground stays firm.

Does a small start end up costing more in total?

The effort of running old and new side by side during the transition does increase. But the comparison to make is not against an all-at-once implementation that went well. It is against the expected value of what actually happens. In the JUAS survey, the share of projects of 500 person-months or more whose budget overran the plan was 42.2%, against 6.0% for under 10 person-months. The ratio between the extremes is 42.2 divided by 6.0, which is 7.03 times. Schedule delay also runs at 47.8% for 500 person-months or more. Overruns and delays under an all-at-once approach need to be priced in before the comparison is made. Note that this survey covers user companies in Japan and is not a record of Thai entities. Use it as a reference for the direction of the effect.

Should production workflow improvement come before or after system implementation?

Before. That said, not all of it needs to come before. The same applies when driving factory improvement through systems: write the current flow only for the scope of phase one, remove the obvious waste, and then load it. Systemise with the waste left in and the waste is set in concrete. On the other hand, insisting on perfecting the flow improvement before entering the system work means never starting. Improving within the bounds of phase one, running it for real, then moving to the next improvement is the practical back and forth.

How big should phase one be?

What the published data shows is the tendency for QCD failure rates to be lowest in the band under 10 person-months. The JUAS report states that at the project size under 10 person-months, the share rated poor is below 10.0% across all of QCD. That said, this is a survey in Japan, and the 10 person-month boundary is a tabulation band in the survey rather than a recommended figure. In practice the sound order is to take the size that emerges naturally when you cut at the smallest unit in which the work makes a complete circuit, and to revisit how you are cutting if that turns out to be extremely large. In terms of elapsed time, whether requirements definition through go-live fits within roughly three months is one rule of thumb (the three-month figure is an assumption made by this article and is not based on a source).

How do you secure the budget for phase two onward?

You use the results of the phase one benefit measurement in the approval for phase two. Which is exactly why fixing the baseline definition at the outset matters. Start thinking about how to measure only after phase one has finished and no comparable numbers can be produced. That is the reason the baseline measurement step sits in weeks 1 to 2. Also, in organisations that operate on annual budget cycles, aligning the phase boundaries to quarters and running several phases within the year makes course correction easier than aligning them to the fiscal year.

Summary

A small start system implementation is not a choice made to skimp on investment. As the JUAS report Kigyo IT Doko Chosa Hokokusho 2026 shows, there is a clear relationship between project size and QCD failure rates. Dissatisfaction with quality runs at 5.4% under 10 person-months and 29.6% at 500 person-months or more, a ratio of 5.48 times. Budget overrun runs at 6.0% under 10 person-months and 42.2% at 500 person-months or more, a ratio of 7.03 times. Schedule delay, in a tabulation with different bands split three ways, is 47.8% for 500 person-months or more. Slicing is the decision to place yourself on the favourable side of that relationship, and it is itself the largest piece of risk management available.

At the same time, there are lines to observe in how you slice. Screens, forms and business logic may all be divided. But field design for the masters, code schemes, numbering, users and permissions, handling of dates and times, and the retention policy for history must not be divided. Divide these and the bill arrives later in the form of duplicate ledgers, duplicated numbers and leaver accounts. Put the shared foundation in place first, as phase zero. That is the dividing line that turns a small start from just small-scale development into the decomposition of a large objective.

At sites in Thailand and ASEAN, there is the additional circumstance that a long project spans changes of personnel. Whether the people who decided the requirements are still in post at go-live is determined by how long the project runs. On this count too, slicing into phases of around three months is the reasonable move.

Finally, every figure referenced in this article comes from published surveys in Japan or across the region, and none of them are forecasts for an individual plant. Monetary amounts and per person-month rates are not included in the sources, so they are not given here. Base your own decisions on a baseline built from your own real numbers.

TOMAS TECH is based in Bangkok, Thailand, and builds production management, IoT and factory automation systems for Japanese manufacturers. Where you should cut, and what belongs in phase zero, depends on your operations on the floor and the state of your existing systems. If you would like to talk through the scope of phase one or the design of the shared foundation, get in touch through our contact form. We cover the initial fact-finding and a proposed way of slicing the work at no charge.

References

• JUAS Kigyo IT Doko Chosa Hokokusho 2026, Chapter 7 System Development – Japan Users Association of Information Systems. Exhibits 7-1-3, 7-1-4 and 7-2-7 referenced
• JUAS Kigyo IT Doko Chosa 2026 press release, second instalment – Survey outline, 957 valid company responses, survey period 5 September to 24 October 2025
• JUAS Corporate IT Trends Survey, survey overview page – Positioning of the survey and a list of past years
• IPA DX Trends Survey 2025 press release – Information-technology Promotion Agency, Japan. 1,799 responses collected, 85.5% reporting a shortage in the quantity of DX staff
• Thailand Job Market 2026 Outlook – RECRUITdee. Average salary increase budget around 4.7%, regional attrition around 17.5%, economic growth outlook around 1.6% attributed to the IMF
• JUAS Kigyo IT Doko Chosa 2026 press release, first instalment – First announcement of the survey publication