Equipment Maintenance Management System ｜ The Two Design Variables That Decide Whether It Gets Used

Most factories evaluating an equipment maintenance management system start from a feature comparison sheet. Six months after go-live, the paper checksheets are usually back on the maintenance desk, and the cause is almost never a missing feature. What was never decided is two things — how finely the asset register is sliced, and which path a job takes to become a work order. This article sets product selection aside and works through those two design variables, together with an illustrative cost model built around a mid-sized factory in Thailand.

Why maintenance software ends up installed but unused

Factories that have failed at digitising maintenance tend to look the same. The system is live. The licence fee is still being paid. And yet the paper checksheets are back on the maintenance desk, breakdown records live on a whiteboard and in individual notebooks, and only a handful of work orders are raised in the system each month.

Calling this a failure to embed makes the cause look like a mindset problem on the shop floor. What is actually happening, almost without exception, is a design problem. Open the asset register of a factory where the system never took hold and you will find equipment codes mixed with process names, or the same machine registered under a new code every time it was relocated. Breakdown records accumulate, but nobody can say what has accumulated against what. Because nobody can say, nobody looks at the summaries. Records that are never read stop being written. The collapse follows that order every time.

The problem with selecting on features is that the axis of comparison becomes the count of things the product can do. What the shop floor actually touches every day is three screens — raise, record the work, close. Whether those three screens match the way maintenance actually flows in your plant is what decides adoption, and that information does not appear on a comparison sheet. What appears there is barcode support, drawing attachment, multilingual UI, budget control. All useful, none of them the deciding factor.

The scale of unplanned downtime itself keeps being confirmed by outside research. As of 2026, 79% of manufacturers are still reported to be struggling with unplanned downtime. Even as management tooling has spread, that share has stayed high. It is closer to the truth to say the shortfall is in record design than in tooling.

What deserves attention in that table is not the absolute cost but the ratio to revenue moving from 8% to 11%. As equipment gets more sophisticated and lines become more tightly coupled, the blast radius of a single machine stopping widens. Left alone, the loss per stoppage grows. Meanwhile the CMMS market is expanding at 9.3% a year. Tooling is increasing while the loss ratio is also increasing. That divergence is the starting point of this article.

Analysis of stoppage time itself, and in particular the way short stoppages accumulate, is covered in our article on minor stoppages and OEE. This article deals with the step before that — designing the vessel the records go into. However good the analytical method, a factory without that vessel never generates the data the method is supposed to analyse.

Compressed into a sentence, the failure looks like this. An equipment maintenance management system is decided not by feature count but by two things: the granularity of the asset register, and the number of intake paths for work orders. Choose a product before settling those two and you end up with a register from which neither MTBF nor MTTR can be calculated. The next two sections design them in turn.

Design variable one — how finely to slice the asset register

Register granularity is the decision about which unit failures, hours and costs accumulate against. Most factories treat this as a field-design question for the register. In substance it is the choice of a unit of measurement, and it determines what can be measured later.

A real factory can be described in five levels, getting finer from top to bottom.

Laid out like this the hierarchy looks obvious, but in real registers those five levels are often collapsed into two or three. The two common patterns are lines and machines sitting at the same level, and a register with no unit level at all, where the level below the machine is immediately the part. In the first case, a whole-line stoppage and a single-machine stoppage land in the same table, which breaks the denominator of any availability calculation. In the second, failures cannot be grouped by sub-assembly, so the same hydraulic problem survives as three unrelated entries — pump replacement, seal replacement, pipework repair — and root cause analysis never becomes possible.

Slicing too shallowly and slicing too deeply fail in opposite directions. A shallow register is easy to write into and tells you nothing afterwards. Stop at the machine level and you cannot identify which sub-assembly failures are concentrating in, so the only countermeasure anyone can propose is to increase inspection frequency. Make part-level entry mandatory from day one and the burden of raising a work order jumps. If a technician responding to a night-shift breakdown cannot close the ticket without entering the model and serial number of a hydraulic pump, the shop floor stops raising tickets and handles it verbally instead. At that moment the system is dead.

The practical answer is to build all five levels and then vary which level is mandatory according to purpose. Concretely, put cost against the machine and failure modes against the unit. Make the machine code and the unit the only two mandatory fields at intake, and attach parts optionally at the work-record stage. With that design, a night-shift breakdown can be raised in fifteen seconds and the part information is filled in the next day when the work record is entered. This is the only way to keep the depth of the register without raising the cost of raising a ticket.

The key detail in the recommended option is fixing the list of units for each machine at ten or fewer. Free text for units breaks aggregation through spelling variation, while forcing selection from a full parts master makes the choice slow. A dropdown of ten or fewer can be tapped once on a tablet. In our experience the boundary where aggregation granularity and entry speed both survive sits somewhere near that number.

The other register decision that cannot be reversed later is the equipment coding rule. The principle is simple — a code belongs to the asset, not to the place. Issue codes that embed a process name or an installation location, such as a code meaning the third station on Assembly Line 2, and every layout change or relocation forces a code change. Change the code and the history breaks. MTBF cannot be calculated for a machine whose history has been broken.

With asset-based codes, line membership and installation location are held as register attributes with a change history. That lets you track lifetime maintenance cost for a machine while also aggregating every stoppage that occurred on Assembly Line 2 in the first half of 2026. The reverse does not hold. Reconstructing an asset’s lifetime history from location-based codes becomes manual work as soon as there has been a single relocation. Coding is a day-one decision and also the item with the highest cost of change once you are running.

As register attributes, hold at minimum equipment type, manufacturer, model, year of manufacture, year of installation, line membership, criticality class and whether a service contract exists. Of these, criticality is used both in the intake design below and in the spare parts design, so always include it with roughly three grades. Defining the grades by whether the line stops when the machine stops causes the least argument. Splitting into “an alternative machine exists”, “the line can be bypassed” and “everything stops” tends to align the shop floor and the maintenance department quickly.

Design variable two — there are three intake paths, not one

The second design variable is how work appears in the system at all, which is to say the intake path. Maintenance work splits into three paths according to what triggers the work order. The three are entirely different in character, yet most implementation projects push them into a single work request screen.

The reason to separate them is that the management metric differs. What you want from BM is a downward trend — fewer is better. What you want from PM is adherence — the closer the completion rate is to 100%, the better. What you want from CBM is accuracy — a loose threshold misses events, a tight one generates false alarms. Mix all three into one table and none of those three metrics can be computed. A figure such as “120 work orders this month” carries no management meaning at all once you cannot tell whether BM went up or PM went up.

The question “what is the difference between preventive and predictive maintenance” is usually answered in terms of philosophy or sophistication. From a system design standpoint the answer is simple. The difference is one thing only — whether the trigger for the work order is time or condition. PM is raised automatically on a time axis, such as three months since the last execution, 2,000 running hours, or 100,000 shots. CBM is raised on a condition, such as vibration exceeding a limit, motor current rising, or oil temperature reaching its ceiling. Both are “do it before it breaks”, but the trigger design and the data required are completely different.

What matters practically in PM design is not making the calendar the only trigger. Calendar-based PM generates work in months when the machine barely ran, and runs at the same frequency in a busy month when utilisation doubled. A system that also accepts running hours and production counts as conditions produces a frequency that matches reality. Using running hours as a condition assumes you can capture a running signal from the machine. For machines where you cannot, run them on calendar triggers for now and convert them as monitoring is added — designed in stages, this works in practice.

The third path, CBM, is a case where threshold design is the operation. False positives are guaranteed immediately after go-live, so run the first three months in a notify-only mode that raises no work orders, observe what proportion of alerts were genuinely abnormal, and only then fix the thresholds. Skip that run-up and false-positive tickets pile up until technicians start ignoring notifications altogether. Threshold and routing design is covered in detail in our article on equipment alert notification design.

Having separated the three paths, design their status transitions separately as well. BM needs five stages — raised, started, restored, cause recorded, closed. Splitting restored from closed is the point. The moment a temporary fix got the line running and the moment the permanent countermeasure was finished are usually different days. Collapse them into one status and MTTR silently absorbs the countermeasure lead time, inflating the number several times over. PM needs only three stages — planned, executed, closed. CBM runs detected, assessed, forwarded to BM or PM, closed, and needs a route at the assessment stage for closing out false positives.

Loading sophisticated machinery onto a factory that has not separated these three produces no benefit. It simply increases total intake volume and consumes technicians’ available hours. The correct order is to consolidate BM, then add automatic PM intake, then introduce CBM on a limited set of machines. Later in this article that order is converted into a day count.

The minimum conditions for MTBF and MTTR to actually come out

Once register granularity and intake paths are settled, the next problem is timestamps. MTBF and MTTR are not numbers that appear because a product has the feature. If the required timestamps are not being captured, no product can calculate them.

There are four timestamps to capture.

Most factories capture only two of these, occurred and restored. MTTR can still be calculated, since MTTR is restored minus occurred. But with only two points there is no way to identify which interval should be shortened. When MTTR comes out at 4.5 hours, nobody can say how much of that was time nobody noticed, how much was time someone knew but nobody had arrived, and how much was actual repair. Issue an instruction to reduce MTTR without that breakdown and the floor tries to repair faster. In most cases repair is not the longest interval.

Capture all four timestamps and downtime decomposes into three intervals — occurred to detected is awareness delay, detected to started is mobilisation delay, started to restored is actual work. Of these, detected to started is the interval most likely to be long and least likely to be measured. The reason is simple: there is no mechanism to stamp the start. A technician runs to the machine and begins work, with no incentive to record anything at that instant. Capturing it requires either a one-tap start on mobile or an operational rule of scanning a QR code on the machine.

Availability is defined as MTBF divided by MTBF plus MTTR. What is easily overlooked in that formula is that the MTTR in the denominator is not repair time but total time to restoration. Awareness delay and mobilisation delay therefore reduce availability directly. Put the other way round, availability rises when detection and mobilisation get faster, without any improvement in repair skill and with almost no capital expenditure. This is the first benefit available from digitising maintenance.

MTBF needs its definition fixed in advance too, or the number drifts. MTBF is mean operating time between failures, so the result changes depending on whether planned stoppages are included in the operating time in the numerator. Divide by calendar time that includes holidays and changeovers and MTBF comes out longer than reality. The principle is to count only time made available to production in the numerator. And for the failure count in the denominator, count only BM intake. Mix PM work into it and you get the perverse result that MTBF falls the more inspection you do. Here again, separating intake paths is what makes the metric work.

These definitions should be documented internally before a product is selected. Some products only allow certain items to be set during initial configuration, and changing a definition later makes comparison with historical data impossible. Conversely, once the definitions are fixed, the aggregation itself is achievable in more or less any product. Once again, the decisive party is the buyer, not the vendor.

Spare parts inventory and the boundary where cost becomes visible

Maintenance cost is invisible in a great many factories, and the reason is usually that work and parts are not linked. Parts are ordered in the purchasing system, received into the warehouse, and drawn out by technicians. All of that is recorded. What is not recorded is which machine and which job the part was consumed on, so part cost never accumulates by machine. Maintenance cost ends up known only as a single line for the whole factory, and which machines are eating the budget is never established.

Solving this is not technically difficult. The work-record screen simply has to ask which parts were used. The difficulty is operational — without a maintained parts master, there are no options to select. In practice, start by mastering only the top 20% or so of parts by value and letting everything else be entered as a miscellaneous part with an amount only. On a value basis a small number of high-cost parts account for most of maintenance spend, so this alone brings cost by machine roughly into view.

Spare parts inventory behaves differently from production material inventory. Managing it with the same logic reliably fails.

Given that difference, the stocking policy for spare parts must not be driven by turnover. A part that moves once a year is still worth holding if it is a critical component of a machine whose failure stops the whole line. The criterion is not turnover but the product of downtime on stockout and the hourly value of that downtime. This is where the criticality class in the register earns its place. Holding standing stock only for parts on top-criticality machines whose procurement lead time exceeds tolerable downtime is the rule that is easiest to defend.

Once inventory and work live in the same system, a secondary benefit appears. Actual consumption history accumulates from work records, so reorder points can be revisited against real data. Standing quantities that were previously set by memory and instinct can be computed from twenty-four months of actual consumption. That helps cost, but the larger gain is being able to explain why the quantity is what it is. Few factories can defend the level of their standing stock with numbers in an audit or a budget negotiation.

What the system costs and where quotations diverge

Pricing comes in three broad shapes — cloud priced per machine, cloud priced per user, and on-premise. The structure of upfront and recurring cost changes completely between them, so the advantage flips depending on the ratio of machine count to user count.

Five line items are where quotations reliably diverge. Licence fees themselves land close together across vendors, so the difference in totals is generated by these five.

Of these, the initial register build moves the total most. Slicing 100 machines down to unit level produces several hundred unit records. Whether that is outsourced or done internally creates a difference measured in hundreds of thousands of baht. In practice the best value is to decide the hierarchy design and the coding rule internally and outsource only the data entry. Outsource the design and an external party ends up choosing your unit of measurement, which means giving away the core of the argument in this article.

What follows is an illustrative model for a mid-sized Japanese-owned factory in Thailand. It is a model built from public information and general market rates, not a client result. That qualification applies to every figure below.

The THB 8,000 per hour is a deliberately conservative figure set on the gross margin of a single line. Real factories often see a larger number once subcontracted recovery and overtime are included, but a low value is used here to avoid overstating the case. On these assumptions the current loss calculates as follows. 10 stoppages per month at 4.5 hours is 45 hours per month; 45 hours at THB 8,000 is THB 360,000 per month, or THB 4,320,000 per year.

Benefit arrives through two routes. The first is on the MTTR side, shortening the detected-to-started interval described earlier. With notifications reaching technicians’ mobiles directly and a start timestamp being tapped, that interval falls from 0.9 hours to 0.3 hours. At 0.6 hours saved per stoppage, 10 stoppages a month at 0.6 hours is 6 hours, and 6 hours at THB 8,000 is THB 48,000 per month. Downtime per stoppage after the improvement becomes 4.5 minus 0.6, or 3.9 hours.

The second route is on the MTBF side, through the completion rate that automatic PM intake makes possible. PM completion under a paper inspection plan is set at 68%, rising to 92% with automatic intake and due-date management. That improvement is assumed to reduce unplanned stoppages from 10 to 8.5 per month, a fall of 15%. The 1.5 stoppages removed at 3.9 hours is 5.85 hours, worth THB 46,800 per month. Total benefit is 48,000 plus 46,800, or THB 94,800 per month and THB 1,137,600 per year.

The important property of this model is that the benefit side does not move when the vessel changes. Cloud or on-premise, the benefit is the same THB 94,800 per month as long as register granularity and intake paths are the same. Only the cost side moves.

Which of the two cloud models wins is decided by the ratio of machines to users. In this model 100 machines cost a fixed THB 25,000 per month, while 26 users on per-user pricing cost THB 31,200, so per-machine pricing wins. The crossover sits at roughly 21 users; below that, per-user pricing is cheaper. Conversely a factory with 300 machines and 20 users would pay THB 75,000 a month on per-machine pricing, so per-user pricing wins there. Reading market rates therefore requires applying your own machine and headcount ratio rather than comparing unit prices.

The ramp-up of benefit also has to be built in. Nothing accrues until the register is built and operations are consolidated, so year one is counted as six months’ worth, THB 568,800, with years two and three at the full THB 1,137,600. Cumulative three-year benefit is 568,800 plus 1,137,600 times two, or THB 2,844,000.

The spread in net benefit is 1,594,000 divided by 234,000, roughly 6.8 times. Identical benefit, and yet the three-year return differs by that much purely through the choice of vessel. On-premise at this scale also leaves a three-year net of THB 234,000, under eighty thousand baht a year, which currency movement or a support fee revision can erase without difficulty. At 100 machines, the only remaining rationale for on-premise is a security requirement that forbids external connectivity entirely.

To repeat, all of the above is an illustrative model, not a client result. To apply it to your own plant, replace two inputs with measured values — lost profit per hour of downtime, and your current PM completion rate. Requesting competing quotations before those two are known leaves no basis for comparison, which is how selection ends up being made on monthly price alone.

Where to draw the line against systems you already run

Digitising maintenance always triggers an argument about overlap with existing systems. The production system already has an equipment master; IoT monitoring already shows stoppages. Leaving the boundary vague here creates duplicate entry, and duplicate entry breaks operations.

The boundary becomes clear when each system is described by the question it answers.

Production control and maintenance may share an equipment master, but their purposes differ. The production-side master represents process capability, carrying capacity, changeover time and cost centre. The maintenance-side master represents an asset, carrying year of manufacture, service contract and part composition. Merging them produces a master that serves neither purpose well. The stable arrangement in practice is to align only the machine code as a shared key and let each system hold the attributes it needs.

The line against IoT monitoring is even cleaner. Monitoring is the entrance for detection, not the execution layer for maintenance. What monitoring returns is the fact of a stoppage and its timestamp; everything after that — intake, assignment, work records, cost — belongs to the maintenance system. A single interface is enough between them, converting stoppage events into BM work orders automatically. With that one interface in place, the occurred timestamp becomes a machine record rather than a human recollection, and MTTR accuracy improves a step. Introducing monitoring itself is covered in our article on factory IoT monitoring implementation.

More advanced failure forecasting is best positioned as an extension of CBM, the third intake path. That territory is worked through in our article on predictive maintenance systems, but the sequence needs care. Introduce it into a factory where the first and second paths are not running and all it does is add intake volume. A forecast announcing that a machine is likely to fail within three weeks moves nobody if there is no mechanism to fold that into the PM work plan. The output of a forecast is a PM work order, and the vessel that receives it has to exist first.

One more practical boundary question is where drawings and procedures live. Whether to store drawings in the maintenance system or link to an existing document repository is a recurring argument. The criterion is update frequency — drawings revised a few times a year belong in document management with a link, while inspection procedures revised at every job are easier to handle inside the maintenance system. Using a maintenance system as a file server inflates the monthly fee on any product with capacity-based pricing.

Four conditions that get added in a Thai factory

Transplanting a design built for Japan into a Thai factory unchanged requires additional thought on four points. None of them are technical; all are questions of people, contracts and policy.

The first is securing maintenance talent. Thailand’s manufacturing workforce is deep, at 6.24 million as of December 2024, but supply and demand do not meet in skilled trades such as maintenance. Against 87,000 manufacturing vacancies there were 25,000 job seekers, and 16,500 placements actually concluded. Roughly eight in ten vacancies went unfilled. In that environment, the risk of leaving maintenance know-how in individual heads is higher than in Japan. A single resignation can remove the entire method for handling a particular machine.

That is precisely why an operational rule of recording what was actually done in the work record pays off. Building procedure documents takes time, but records of how similar past failures were handled accumulate automatically with every ticket. Make past work on the same unit visible from the intake screen and even an inexperienced technician can take a correct first action. What makes this work is the unit granularity chosen back in the first design variable. Record only at machine level and the past-work list returns several hundred entries and is useless. At unit level it narrows to a dozen or so. Register granularity pays off not only for aggregation but for searchability on the floor.

On the policy side, the government is moving on skills development, with a BOI upskilling framework indicated at a scale of THB 5 billion covering 100,000 people. Whether or not you use the scheme, the fact that skilled areas such as maintenance are inside the policy perimeter is worth holding as an assumption when planning headcount.

The second condition is language. In a Thai factory, the person doing the work, the person reading the record and the person reading the numbers speak different languages. Forcing one language through all three thins out the record somewhere.

Select on a “multilingual supported” checkbox without thinking about these three layers and you end up with a translated UI but reports in English only. What has to be verified is how far each of four things can be localised — the UI, master names, printed reports and notification text. Master names are the most commonly missed. If machine and unit names can only be registered in Thai, the summary tables on the Japanese side come out in Thai. Confirm early whether names can be held in multiple languages.

The third condition is the boundary with equipment vendors’ service contracts. In Thailand it is common for imported machinery to be covered by an annual contract with the manufacturer’s local entity or an agent. Unless you decide how contracted work is handled, the register develops holes. If a failure repaired by the vendor never enters your records, that machine’s MTBF comes out longer than reality. The principle is that the work order is raised internally even when the performer is external, with only the performer class set to external. Where the cost is inside the contract, record it at zero and enter an amount only when separately invoiced. Do that and you can state, in numbers, how many jobs the vendor handled over the year when the contract comes up for renewal.

The fourth condition is the relationship with BOI schemes. Under the BOI’s Smart and Sustainable Industry category, the first half of 2026 saw 132 applications worth THB 17.2 billion, with investment in machinery renewal and automation continuing. Replacing machinery creates a generation-management question in the register — whether to carry the old machine’s history forward or cut it. The principle is to issue a new code for the new asset while holding the replacement relationship as an attribute. That allows stoppage counts before and after replacement to be compared, which becomes the evidence for the investment case. If a machinery replacement plan under one of these schemes is on the table, getting the register vessel in order first is the correct order of operations.

A 90-day sequence to get it running

Finally, the order in which this design is actually put into motion. Ninety days is the guide, and narrowing the scope is a precondition.

The largest consumer of time in the first thirty days is internal agreement, not system configuration. The coding rule and the way units are divided will split opinion between maintenance, production engineering and finance. Finance wants alignment with asset numbers, production engineering wants process order, maintenance wants the names used on the floor. The only workable resolution is the principle that the code belongs to the asset and the shop-floor name is held as an alias. Compressing these thirty days damages the following two years.

From day 31 to day 60, consolidating BM means one substantive task — stopping the parallel paper process. The longer the overlap runs, the less the system embeds. In practice, set a date for the target line, collect the paper forms, and switch to accepting no intake outside the system. If raising a ticket is heavier than writing on paper, the floor will resist, without exception. That is exactly why the design from the register section — no more than two mandatory fields, machine code and unit — matters. Being faster than a paper checksheet is the absolute condition for the switch.

Automatic PM intake from day 61 starts by transferring the existing inspection plan as it stands. Reviewing frequencies can wait. First load the paper annual inspection plan into the system and run due-date management and execution records. That alone produces a PM completion rate as a number for the first time. In most factories that number is lower than expected when first seen. It usually means only that plans existed without execution records, but improvement begins the moment it becomes visible. Keep CBM to three machines. The three are not about how many sensors to fit, but about learning how to operate thresholds.

Projects that choose all machines and all features at once fail because irreversible decisions accumulate before any feedback returns. Build masters for all 100 machines before starting operations and you discover that the unit split does not match the floor six months later. By then several hundred records have accumulated and correcting it requires reclassifying historical data. Narrow to one line and the same realisation arrives in three weeks, with dozens of records to correct. Narrowing scope is not an expression of caution but a technical choice that lowers the cost of correction.

After the ninety days, expansion runs in two directions — more lines, or more features. Take lines first. Spreading the same design sideways puts the second line live in about thirty days. Add features once every line is running on one design. The reverse order, stacking features on a single line and then rolling out, replicates the complexity of that design across every line.

Frequently asked questions

What is an equipment maintenance management system

It is a mechanism for managing maintenance work through four things — the asset register, work orders, work records and cost. It is commonly called a CMMS. At the core is the asset register, to which work orders attach and against which hours, parts and cost accumulate as work records. Only with that accumulation can MTBF, MTTR and maintenance cost be calculated. Put the other way round, a system whose register unit has not been decided cannot produce metrics however many features it has.

What is the difference between preventive and predictive maintenance

The trigger for the work order is time in one case and condition in the other. Preventive maintenance is raised automatically on a time axis — elapsed time since last execution, running hours, production count. Condition-driven maintenance is raised when vibration, current or temperature crosses a threshold. Treating them as two paths with different data requirements and different design, rather than as a hierarchy of sophistication, matches practice better. In sequence, get the time-based automatic intake running before adding the condition side.

How does CMMS differ from EAM

CMMS covers the execution of maintenance work; EAM covers the entire asset lifecycle. EAM includes asset management from purchase through depreciation, replacement and disposal, plus budget planning, procurement and contract management. What a 100-machine factory needs first is the CMMS scope, and choosing a product that also carries EAM functionality sharply raises the initial build burden. If there is a chance of extending to EAM later, issuing machine codes on an asset basis is the only preparation required.

What does an equipment maintenance management system cost

For cloud products, per-machine pricing runs roughly THB 200 to 400 per machine per month and per-user pricing roughly THB 1,000 to 2,000 per user per month. Initial register build and data migration are added on top. In the illustrative model in this article, a factory with 100 machines and 26 users reached three-year totals of THB 1,250,000 on per-machine cloud, THB 1,473,200 on per-user cloud and THB 2,610,000 on-premise. What moves the total is the scope of the initial build rather than the monthly unit price.

Can we migrate from a spreadsheet maintenance register

You can, but importing it as it stands carries the problems forward. A spreadsheet register usually has one row per failure record and no hierarchy of equipment. Before migration, the coding rule has to be decided and new codes assigned to the existing rows. Skip that and import spelling variations unchanged, and the same machine ends up registered under several codes, so aggregation is broken from day one. As for how many years of failure history to bring, the last two years is generally sufficient. Older data usually was not recorded at the same granularity as today.

Where should digitisation of maintenance records start

With BM intake for unplanned stoppages. Many factories start by digitising inspection sheets, but inspection sheets already work on paper, so digitising them produces little felt benefit. BM intake, by contrast, makes all four timestamps available the moment it goes live, which makes the interval decomposition of MTTR possible. Starting where the benefit shows up as a number makes the next investment decision easier to pass. Limit the scope to one line, and set a date to stop the parallel paper process.

Summary

Whether to digitise maintenance is not decided by a product comparison sheet. What has to be decided is two things — how finely the asset register is sliced, and whether intake is separated into three paths. Hold the register in five levels, put cost against the machine and failure modes against the unit. Split intake into breakdown, preventive and condition-based, with separate status transitions and separate metrics for each. Capture the four timestamps of occurred, detected, started and restored on top of that, and MTBF and MTTR come out on their own.

In the illustrative model, the benefit side came to THB 94,800 per month and THB 2,844,000 over three years, and it does not move when the vessel changes. Only the cost side moves, and the three-year net ranged from THB 1,594,000 down to THB 234,000, a spread of roughly 6.8 times driven purely by the choice of vessel. The meaning of that structure is straightforward. The major variable in the investment decision sits on the buyer’s side, not the vendor’s. Deciding register granularity and intake paths internally is itself the substance of the investment decision.

How finely to slice the register and how to divide intake paths are questions that come before choosing a product. TOMAS TECH works on production and equipment systems for Japanese-owned factories in Thailand, and we are happy to talk at exactly this stage. How far to split units given your own equipment mix, or what to keep and what to discard from an existing spreadsheet register, are perfectly reasonable things to discuss. You are welcome to get in touch through our contact page.

References

• CMMS comparison for manufacturing maintenance management (IT trend)
• How to choose an equipment maintenance system (Yachiyo Solutions)
• What is MTBF (Yachiyo Solutions)
• Why Thailand’s Manufacturing Sector Is Facing a Talent Bottleneck (aplus career)
• Thailand FDI Surges in H1 2026 (Thailand Business News)
• The Cost of Unplanned Downtime in Manufacturing (reliamag)
• How Unplanned OT Downtime Is Silently Draining Industrial Profits (Acronis)
• Computerized Maintenance Management Systems Market (Future Market Insights)
• Why 79% of Manufacturers Still Struggle with Unplanned Downtime in 2026 (ManWinWin)