Excel Limits in Manufacturing｜How Thai Factories Move Beyond Spreadsheet Management

Plenty of factories in Thailand run production planning, inventory and shipping records entirely on Excel. There is nothing unusual about that. But once a company adds a second site, takes on more customers and starts handling a wider range of part numbers, most of them hit the same wall. When people talk about Excel limits in manufacturing, the issue is not that Excel is a poor product. It is that Excel was never designed to be the tool an organisation runs its operations on. This article looks at how those limits actually show up, which turning points make them impossible to ignore, and in what order to tackle duplicate data entry, key-person dependency and paper-based workflows, all from the perspective of day-to-day operations in Thailand.

Why Excel limits in manufacturing are being questioned now

The plants that have “done it this way for ten years” are usually the last ones to revisit their spreadsheet habits. Since the start of 2026, however, the environment around Japanese-owned manufacturers in Thailand has been shifting in a way that makes putting this off harder. There are three main reasons.

Digital adoption in Thailand is no longer just for the front-runners

In the Business Outlook Study 2026 released by UOB on 30 June 2026, based on responses from senior executives at 265 companies, more than 70% of Thai SMEs reported that they had already adopted AI, a share the study describes as above the ASEAN average. In the same survey, the proportions naming each area as a management priority were 37% for ESG, 33% for customer acquisition, 27% for digitalisation and 25% for cost reduction.

What matters here is less the size of each figure than the ordering. Digitalisation sits above cost reduction. IT investment in Thailand used to be discussed almost entirely as a way to cut labour costs. It is now being treated as a precondition for staying in business. Once your Thai customers and suppliers start operating on that assumption, a Japanese-owned plant sitting inside the same supply chain cannot stay unaffected.

Policy is pushing SME digital adoption as well

The SMEs Growth 2026 programme run by ETDA expanded in 2026 to 16 provinces across four regions, covering the north, northeast, east and south. It targets three sectors — commerce, services such as tourism and hotels, and manufacturing — and works as a framework for matching SMEs with public agencies, financial institutions and IT vendors. In other words, digital adoption is no longer being left to each company’s own effort, and the connective infrastructure around it is being built out.

Investment incentives point the same way. The Thailand Board of Investment announced a new set of investment promotion measures dated 15 January 2026, shifting the focus of manufacturing support clearly toward Industry 4.0, meaning smart factories, AI-enabled production and automation. The yardstick is moving from “install equipment and you qualify” toward “use equipment well, on the assumption that your data is connected”.

Excel is a spreadsheet program, not an operations management system

This is the most fundamental reason of all. Excel was designed for an individual to calculate figures, roll them up and check the result on the spot. Simultaneous editing by many people, retaining a change history as an auditable record, and keeping data consistent across departments were never among its primary design goals.

That is exactly why spreadsheet operations turn painful so abruptly once business scale, site count and the number of people involved pass a certain point. The three symptoms people usually name are key-person dependency, not knowing which file is current, and human error from duplicate entry. None of these come from staff being careless. They arise inevitably from a mismatch between how the tool was designed and what the work actually demands. Whether your team shares that starting point changes the quality of every discussion that follows.

How Excel limits show up in practice

The limits do not arrive one morning out of nowhere. In most cases four symptoms appear in sequence, or all at once. It is worth counting how many of them apply to your own operation.

Symptom 1 — Files only their author can touch

Key-person dependency comes first. A production schedule with VLOOKUP formulas buried in it, deeply nested IF statements, named ranges pointing at a different workbook. To the person who built it, every one of those choices was reasonable. To everyone else, it is a black box nobody can read.

In Thailand this weighs heavier than it does in Japan, because staff turnover is higher. When an administrative staff member moves on, nobody is left who can maintain the file. If the file was built by a Japanese expatriate, the same thing happens when their assignment ends. The result is a vicious circle where nobody touches the file because they are afraid of breaking it, and every new requirement gets handled by creating yet another file. Only the file count grows.

There is a simple test for key-person dependency. On the day the person responsible is out, does the work stop? If it does, that is an individual’s task, not the organisation’s process.

Symptom 2 — Nobody knows which version is current

The second symptom is the collapse of version control. A shared folder holding “production_plan_v3”, “production_plan_v3_revised”, “production_plan_v3_final” and “production_plan_v3_final_Tanaka_edit” side by side is a sight most factories will recognise.

The awkward part is that this looks like a tidiness problem. It is considerably worse than that, because it undermines the basis on which decisions are made. The number quoted in the meeting, the number the shop floor is looking at and the number reported to head office are all different. Working out which one is correct takes time in itself, and by the time you have finished checking, the situation has moved on. The hours spent on this checking-the-check work appear in no daily report and on no timesheet, so management never sees them.

Symptom 3 — Human error from duplicate data entry

The third is duplicate entry. Sales enter the order into Excel, production control copies it into the schedule, the shop floor writes results on paper, an administrator keys those into a different workbook, and finally accounting re-enters them into yet another format. The same information passes through human hands again and again, changing shape each time.

Every transcription step creates a fresh opportunity for a mistyped digit, a shifted row or a missed copy. And because source and destination live in separate files, you get the hardest kind of inconsistency to spot, where one side is corrected and the other quietly stays stale. Responding with “let us add more checking to reduce input errors” leaves the duplicate entry in place and simply adds hours on top, so it never resolves anything at the root.

Symptom 4 — Paper and Excel coexist, giving you three sets of records

The fourth symptom is surprisingly easy to overlook. In many factories the shop floor runs on paper daily reports and work instructions, the office runs on Excel, and management reporting uses a third set of documents entirely. It feels like digitalisation has happened, but in reality paper-based and spreadsheet-based management run in parallel, and a new transcription task has been created to bridge the two.

In this state, dropping the paper does not remove the Excel limits, and replacing Excel does not remove the paper. Because touching only one side produces no visible result, this is fertile ground for the “we put in a system and nothing got easier” experience.

The turning points where the limits suddenly bite

While the operation is small, the symptoms above stay within tolerable bounds. The problem is that beyond a certain turning point the load stops growing in a straight line and starts climbing sharply. For Japanese-owned plants in Thailand, three moments are typical.

Turning point 1 — Going from one site to two

While there is only one site, a great deal gets settled by calling across the same building. The moment a second site exists, that stops working. Emailing files back and forth, putting them on a shared drive, letting one site hold the master copy. Whichever approach you take, situations will arise where somebody makes a decision based on information that is not current.

More troublesome still is that files evolve separately at each site. The head office plant near Bangkok and the second plant in Chonburi both have a file called “production schedule”, and the columns are different. Before you can consolidate anything, you first have to reformat. That reformatting work multiplies with every additional site.

Turning point 2 — More customers, and more required formats

As the customer list grows, so does the number of documents and data formats you are asked to produce. Delivery note layouts, the way forecasts arrive, the granularity of traceability information, submission deadlines. A dedicated Excel file and macro accumulate for each one, and because each is specific to a single customer, none of it can be generalised.

Given that the BOI has moved its incentive focus to Industry 4.0 and that Thai companies themselves now name digitalisation as a management priority, it is reasonable to expect more customers asking for information as a data feed rather than a document. A spreadsheet workflow built on the assumption that a human reads figures and types them in is structurally weak against that kind of request.

Turning point 3 — More people involved, and training costs jumping

The third is people. When the number of people involved goes from 10 to 30, the communication paths required do not triple. They grow far faster than that. In a spreadsheet operation, that increase converts directly into time spent teaching people how to use the files and time spent fixing incorrect use.

At Thai sites, training is often delivered in more than one language, typically Japanese, English and Thai. If the field labels inside the file are still in Japanese, Thai staff end up memorising cell positions rather than meaning. That produces an extremely fragile way of working, where changing the layout once stops everyone in their tracks.

A quick self-check on how close you are to the limit

Count how many of the following apply to your operation.

• The same information is keyed in by hand in two or more places
• Files are distinguished by adding dates, version numbers or staff names to the filename
• There is at least one reporting task that stops when a particular person is away
• Producing the monthly report figures takes two days or more
• Shop-floor results are collected on paper and typed in afterwards by someone else
• Similar but not identical files exist for each site or each customer
• You cannot trace who decided on a past change, or why
• A newly hired administrative staff member takes three months or more to work independently

Three or fewer means you can still compete perfectly well by improving your spreadsheets. Four to six means it is time to start considering carving out part of the workflow and putting it into a system. Seven or more suggests there is a strong chance the spreadsheet operation itself has become the bottleneck in your business.

What it costs to leave the limits in place

Spreadsheet costs are usually recognised only as licence fees, while the real burden turns up somewhere else entirely. The table below sets out the costs that tend to accumulate when the limits are left unaddressed.

The key point is that each of these costs is small on its own, and each of them can be absorbed if people simply try a little harder. So the shop floor absorbs them, and they never reach management as a problem. Being unable to express the limits in numbers, and letting them be handled as overtime by whoever is responsible, is the classic mechanism by which spreadsheet operations get their life extended.

The first thing to do is measure these invisible costs, even just once. Asking the people involved to log the time they spend on transcription and verification for one month gives you a number solid enough to build a discussion on.

What to settle before you move away from Excel

One important premise belongs here. You do not have to throw out all of your spreadsheets. In fact, experience suggests that the migrations aiming to abolish Excel entirely are the ones most likely to fail.

Separate the Excel you keep from the Excel you retire

Excel is good at one-off calculations, at simulations where you vary the assumptions, and at analysis done by one or two people. It is bad at ledgers that many people update at once, at work that must retain an auditable history, and at processes that keep data consistent across departments.

The criterion is therefore simple. Keep the Excel that one person uses in order to think, and target for migration the Excel your organisation uses to run its operations. Try to migrate everything in one sweep without drawing that line and you end up confiscating the analysis tools people are comfortable with, which is a reliable way to generate resistance.

Consider AI automation before you consider a system

There is a second option worth weighing. For the routine transcription, reformatting and consolidation inside your spreadsheet workflow, some of the burden can be removed through automation without replacing any systems. We have set this direction out concretely in our article on AI automation for Excel work, so it is worth reading alongside this one.

As a rule of thumb, automation works when the shape of the work is settled and the procedure can be written down. Where nobody has decided which file is authoritative in the first place, or where each department defines terms differently, automation will only mass-produce the same errors faster. In that case you need to start with the data consolidation covered in the next sections.

Where to start when eliminating duplicate data entry

Eliminating duplicate entry is the theme where the effect of moving off spreadsheets is easiest to see. Get the approach wrong, though, and all that changes is the screen people type into, while the workload stays exactly where it was.

The principle is enter once, reference as often as you like

The starting point is identifying where each piece of information is first created. For order information that is the order registration in sales, for production results it is job completion on the shop floor, for inventory it is the moment goods move in or out. Enter data only at that point of origin, and build every downstream document and report by reference. That is the only principle that removes duplicate entry.

Put the other way round, as long as each department keeps its own ledger, no tool you introduce will make duplicate entry go away. Before you select a tool, you need to agree who owns the registration of which data, and when.

How to design shop-floor input

The hardest part of capturing data at the point of origin is the shop floor. A design that requires operators to walk over to a PC and type will not stick. In practice the following measures work.

• Cut the number of fields so a single operation finishes within 10 seconds
• Use barcodes or touch selection instead of keyboard entry
• Place the terminal close to where the work happens so nobody has to walk
• Reflect what was entered on screen immediately so the result is visible
• Allow the display language to be switched to Thai

That last point is decisive in Thailand. If operators cannot use a system in their own language, somebody will end up entering the data on their behalf, and transcription comes straight back.

Reduce it in stages

Getting duplicate entry to zero is the final goal, not the initial one. Realistically, pick the single process with the highest number of entry steps and switch only that one to point-of-origin capture. Expand once the effect shows up in numbers. Follow that order and building internal consensus becomes far easier.

How manufacturers can end key-person dependency

Key-person dependency cannot be solved by introducing a system alone. The sequence is to make the work visible, standardise it, and only then put it into a system. Three stages.

Stage one — Take stock of the work

Start by listing who updates which file, at what point, and for what purpose. This exercise alone uncovers, in most factories, at least one document that is produced every month and read by nobody. There is no need to systemise work nobody uses. Taking stock is also a process for shrinking the migration scope.

Work at the level of input, processing and output rather than at the level of files. Looked at file by file, the content is too tangled to get started on. Only when you break it down to individual tasks does it become clear what you can stop doing.

Stage two — Standardise first, systemise second

Do not load procedures that differ by site and by individual into a system as they are. A system that implements every local requirement simply reproduces your key-person dependency in an expensive new form. Unify field definitions, code structures and cut-off timing first, then load. Reverse that order and cost overruns on customisation are all but guaranteed.

Any standardisation discussion will produce the claim that “our site is a special case”. The productive response is not to deny the differences but to draw an explicit line between what goes onto the standard and what stays site-specific. If you can standardise 80% of the whole, the remaining 20% can be handled through operating practice.

Stage three — Make it run regardless of who is in the seat

Loading it into a system does not end key-person dependency by itself. To finish the job, aim for the following state.

• Business rules are expressed as configuration inside the system
• When the person responsible changes, following the on-screen prompts produces the same result
• Change history is recorded automatically, so who changed what and when can be traced
• Master data registration rights are separated from day-to-day entry rights
• The handover document is almost identical to the system operating procedure

Of these, the separation of rights is the one most often skipped. A setup where everyone can edit anything is not fundamentally different from a shared folder full of spreadsheets.

A workable path away from paper on the shop floor

Any attempt to eliminate paper forms head-on will meet resistance. What works is first identifying why the paper is still there.

Break down the reasons paper survives

Ask the shop floor why they use paper and you will usually get one of the following. Different reasons call for different responses.

• Physical reasons, such as gloves or oil making a terminal unusable
• Task-related reasons, where recording happens alongside another job and both hands are occupied
• Regulatory reasons, where audits or customer requirements demand signed paper
• Equipment reasons, such as too few terminals or no network coverage
• Habitual reasons, meaning simply that this is how it has always been done

Physical reasons can be handled with dust-proof and splash-proof terminals or barcode-based workflows. Regulatory reasons split in two. Where the requirement comes from a customer, it becomes a negotiation about whether an electronic record is acceptable. Where it comes from statute or tax rules, it becomes a matter of checking with a specialist against Thai record-keeping requirements. Habitual reasons are in fact the easiest to remove. Issue a blanket “let us stop using paper” without breaking the reasons apart, and even that easiest portion goes untouched.

A staged roadmap

Moving away from paper works better as a series of stages than as an attempt at total abolition on day one.

For many factories, moving from stage 0 to stage 1 alone substantially reduces both the waiting time introduced by routing everything through a transcriber and the mix-ups that occur during transcription. Stage 2 onward involves capital expenditure, so it is perfectly reasonable to advance only as the results are confirmed.

How to run the migration

With all of the above in place, here is how to approach the migration itself.

Sort requirements into three tiers before you evaluate products

A common failure in system selection is starting from a feature comparison. More features look better, but features you never use are nothing but operational overhead. Sort your requirements into these three tiers.

• Must-have requirements, without which there is no point in implementing at all
• Important requirements, high value if present but survivable in the initial phase
• Future requirements, checked as headroom for more sites or more customers

With this split in place, the evaluation discussion shifts from “does it have the feature” to “is it in the initial scope or deferred”, and decisions get made faster. We cover the main comparison criteria for the leading products in detail in our article on comparing production management systems.

Start small and expand as results appear

The other important principle is keeping the initial scope narrow. A project that migrates every process at once loses shop-floor energy as it drags on, and the environment shifts partway through, leaving the requirements stale.

What works is picking the single most painful process and getting it running in roughly three months. We have set out the procedure in our article on small-start system implementation, but it comes down to carving out, before anything else, the slice where the effect can be seen as a number.

Getting to something real in three months

Once the initial scope is fixed, the standard progression looks like this.

• Month 1, take stock of the target process and unify field definitions and code structures
• Month 2, configure and trial-run, validate and refine shop-floor input operations
• Month 3, run in parallel, measure the effect, decide on stopping the old spreadsheet workflow
• Month 4 onward, extend to adjacent processes and standardise across sites

The step most often taken lightly in this schedule is the decision in month 3 to stop the old workflow. Leave it vague and the new system will coexist with Excel, bringing duplicate entry back in a new form. Fixing the shutdown date in advance is what separates success from failure.

Points specific to operating in Thailand

Running this in Thailand raises several issues that do not arise in Japan.

• Multilingual support, whether shop-floor screens work in Thai and admin screens in Japanese
• Workforce mobility, whether the design keeps the operation running when staff change
• Support structure, whether there is a local maintenance contact you can reach without a time difference
• Statutory and tax requirements, whether the records will stand up to Thai document requirements and audits
• Alignment with incentives, whether the investment plan reflects the BOI’s shift toward Industry 4.0

Support in particular has a direct bearing on adoption after go-live. Whether people can raise a problem in their own language decides whether the system stays in use or everyone quietly drifts back to spreadsheets.

A practical checklist before you implement

Finally, here are the items worth confirming internally before you take the discussion further. Simply reading through them at the start of a meeting will keep the conversation from going in circles.

• Have you listed your current Excel files with the purpose and owner of each
• Have you decided to stop the documents nobody uses and the reports nobody can explain
• Can you identify the point of origin for each type of information
• Have you identified terms and codes that are defined differently by department
• Do you have agreement on unifying code structures for part numbers, customers and processes
• Is shop-floor input designed to complete within 10 seconds
• Have you decided whether Thai-language shop-floor screens are needed
• Have you classified the reasons paper survives into physical, regulatory and habitual
• Have you narrowed the initial scope to a single process
• Have you fixed the success metrics and how to measure them before go-live
• Have you set the date on which the old spreadsheet workflow stops
• Have you separated master registration rights from daily entry rights
• Have you drawn the line between what is standardised across sites and what stays site-specific
• Will the operation continue if the person responsible resigns
• Have you confirmed the post-go-live support contact and the hours you can reach them

You do not need to satisfy every item before you begin. But the relationship is clear enough. The more items you cannot answer, the more rework you will face after implementation.

Frequently asked questions

At what size do Excel limits in manufacturing start to appear

You cannot draw the line on headcount alone. The useful indicators are the number of people who touch the same information and the number of sites and customers. As a guide, if five or more people update the same ledger, if you have two or more sites, or if document formats differ by customer, you are at the stage where the symptoms start to appear. The same applies if four or more items in this article’s self-check apply to you.

Where should we start in order to eliminate duplicate data entry

The first thing to do is not to select a tool but to decide the point of origin for each type of information. For orders, production results and goods movements, decide which department owns the data and at which moment it registers it. Then pick just one process, the one with the most entry steps, and switch that to point-of-origin capture. Trying to change everything at once concentrates the load on the shop floor and nothing sticks.

What is a realistic way for a manufacturer to end key-person dependency

Take stock, standardise, then systemise, in that order. Reverse the sequence and load individualised procedures into a system, and you have built expensive key-person dependency. Stop the unused work during the stock-taking stage, unify field definitions and code structures next, and load it into a system after that. Finish by separating master registration rights from daily entry rights and ensuring change history is retained automatically, and you are close to an operation that runs regardless of who is in the seat.

Are tablets essential for a factory moving away from paper

They are not essential. The right answer depends on why the paper is there. On processes where gloves or oil make terminal operation difficult, a combination of barcode scanning and fixed terminals works well. Where audits or customer requirements demand signed paper, start by checking with the customer whether an electronic record satisfies the requirement. Even just advancing to the stage where the shop floor digitises its own paper records substantially reduces both the hours spent routing everything through a transcriber and the mix-ups that occur during transcription.

Do we have to give up Excel entirely

No. The Excel one person uses in order to think, such as scenario calculations with varying assumptions or one-off analysis, is a use case you should keep. What belongs in scope for migration is the Excel your organisation uses to run its operations, meaning ledgers many people update at once and processes that need data consistency across departments. Aim for total abolition without drawing that line and you will strip people of the analysis methods they are used to, which hardens resistance.

Summary

Excel limits in manufacturing surface not because of any shortfall in your staff, but because the design philosophy of a spreadsheet program diverges from what an organisation needs once its sites, customers and headcount grow. The symptoms appear as key-person dependency, collapsed version control, human error from duplicate entry, and paper coexisting with spreadsheets, and the load jumps sharply when you go from one site to two, when customer format requirements multiply, and when the number of people involved rises.

The order of the remedies is clear. Measure the invisible costs once, then draw a line between the Excel you keep and the Excel you migrate, then decide the point of origin for each piece of information and cut duplicate entry. In parallel, take stock of the work, standardise it, and only then load it into a system. Break the paper down by reason and reduce it in stages. And narrow the initial scope to a single process while fixing in advance the date the old workflow stops. Follow that order and the symptoms ease steadily, without a large investment.

Digital adoption in Thailand is accelerating from both the policy side and the market side, and the BOI has moved its incentive focus to Industry 4.0. Rethinking how you use spreadsheets is no longer only a cost-reduction exercise. It is increasingly about building the foundation you need in order to keep doing business.

If you are at the stage of working out where your own operation stands and what to tackle first, you are welcome to get in touch through the TOMAS TECH contact page. We are happy to talk without any assumption that an implementation follows. We will listen to how your spreadsheets are used today and help you separate what improvement alone can fix from what is worth putting into a system, answering from the perspective of day-to-day practice in Thailand.

References

• UOB Business Outlook Study 2026 on AI adoption and digitalisation priorities among Thai SMEs
• ETDA SMEs Growth 2026 programme regional expansion
• Thailand BOI manufacturing investment incentives and the shift toward Industry 4.0
• Practical commentary on the limits of production management with Excel, Evort
• Analysis of key-person dependency and duplicate entry in spreadsheet management, Anomaly Inc