Factory IT Asset Management 2026 – Half Your Contracts Are Off the Books

“We want to get factory IT asset management under control. Where do we start?” It is one of the most common questions we hear at Japanese-owned factories in Thailand, and our answer is always the same. Before you count the PCs, build a list of the contracts. IT asset management does not break down because the number of systems goes up. It breaks down because the people who approve those contracts are scattered outside the IT department. In this article we follow a Rayong factory with seven contracts, and trace how half of its annual IT spend ended up sitting outside the register.

Why Factory IT Asset Management Keeps Getting Postponed – Contracts Multiply, the People Managing Them Do Not

Ask a Japanese-owned factory in Thailand whether it does IT asset management and the answer is usually “more or less, yes.” Ask to see the register and what comes out is a list of PCs and servers. Asset number, model name, month of purchase, assigned user, physical location. As a fixed-asset record it is properly built, and it is kept current.

Then ask the follow-up question. “Where is the list of the software and cloud services you are currently paying for?” The mood in the room changes. Everyone knows what the IT department signed. But the chat tool that general affairs signed, the HR and payroll system that accounting signed, the quotation and order system that sales signed: nobody can say on the spot where those contracts are filed, what the annual fee is, or when they renew. The invoices pass through accounting, so payment never stops. There is simply no single place where any of it is aggregated as an IT asset.

This state of affairs is not the result of anyone being negligent. It is structural. Factory systems get signed at the moment they are needed, by the department that needs them, through whatever approval route applies at that moment. The production management system is decided jointly by IT and the plant manager. The payroll system is decided by the accounting manager. The sales cloud service is introduced by the sales manager on instruction from head office. Different approvers mean the contracts are filed in different places and the renewal notifications go to different people.

On top of that, IT asset management has no deadline attached to it. If production stops, everyone moves. If the register goes stale, nobody is inconvenienced. The inconvenience arrives when an audit starts, when a licence violation is pointed out, and when someone says “cut the budget” and you cannot tell where to cut. All three happen once a year at most, so in the daily ordering of priorities this work always slides to the back.

There is one more factor. The IT person at a factory is usually a single individual, and often doing the job alongside accounting or general affairs. With five contracts, memory copes. At seven, at ten, memory stops coping. And the moment you notice the count has grown is normally after memory has already failed. Contracts multiply; the people managing them do not. That asymmetry is the basic shape of how factory IT asset management falls apart.

IT Asset Management Is Not an Equipment Register – You Manage Contracts, Not Things

Factories have excellent equipment registers. Presses, injection moulding machines, compressors, forklifts. Each carries an asset number linked to acquisition value, depreciation, inspection history and the servicing contractor. As organisations go, factories are extremely well practised at managing physical things through a register.

Which is exactly why they start IT asset management the same way. Stick an asset label on the PC, record the server model number, write down where it sits. None of that is wrong, but it is half off from the reality of today’s IT spend.

The reason is simple. The centre of gravity of spending has moved from things to contracts. In the era of buying on-premises servers, the asset really was a physical object. The moment you bought it the amount was fixed, and after that there was only depreciation and maintenance. Cloud services and SaaS have no physical substance at all. What exists is a contract and the user IDs attached to it. The amount is incurred every month, varies with user count and plan, and renews automatically if left alone.

Cybernet Systems lists, among the future challenges of IT asset management, the fact that virtual environments are difficult to map to physical environments by visual inspection, and that cloud services require management at the level of the individual user ID and carry a risk of turning into shadow IT. That is precisely an explanation of why a register built for physical things cannot capture the cloud. There is a column for installation location, but no column for user ID. The format of the register itself is shaped so that it cannot capture the assets you now own.

The practical conclusion is this. In factory IT asset management you need to build a contract register separate from the equipment register. The unit of management is not the asset number but the contract number, and the fields to record are not the installation location but the approving department, the annual fee, the billing unit, the renewal date and the cancellation notice deadline. Try to mix the two into a single sheet and both come out half-finished. Build them separately, and link only where linking is needed. That is the starting point.

Incidentally, the habit of looking at cost per contract works the same way when designing maintenance agreements. Comparing annual fees alone tells you nothing about what is inside them, and we set out that structure in detail in how to read business system maintenance cost.

Why 2026 Forces a Rethink – Cloud and SaaS Have Outrun the Register

To the question “it has always been like this, so why review it now,” our answer is that the composition of the market has changed.

According to Mordor Intelligence’s Thailand IT and Security Market report (updated 7 August 2026), Thailand’s IT and security market is expected to grow from USD 9.92 billion in 2025 to USD 10.26 billion in 2026, with a CAGR of 10.26% from 2026 to 2031. The growth itself is no surprise. The breakdown is the interesting part. In that report, within the 2025 market composition, software accounts for 41.72% by component, and cloud accounts for 55.84% by deployment mode.

Software is more than four tenths of the market by component, and cloud is more than half of the whole market by deployment. Overlay those two facts and you can see where the centre of gravity of managing IT spend in Thailand actually sits. Not in the number of hardware units. In software contracts, and specifically in cloud contracts that run on user IDs and monthly billing rather than on installed equipment.

Most factory IT registers have not kept up with that shift. The format of the register was designed when servers and client PCs were still the centre of spending. Operations continue on that original design philosophy, so cloud contracts do not fit into the available columns and end up placed outside the register. Where they actually end up is somebody’s mailbox, a departmental folder, or nowhere at all.

There is one more circumstance specific to 2026. Many of the business SaaS products adopted over the last few years are now entering their second and third contract years. In year one the price was held down through negotiation at implementation, and the person who signed still remembers the details. From year two onward auto-renewal takes effect, the responsible person is reassigned, and the plan simply continues on its initial settings. Right now is exactly the period in which contracts start to move quietly.

Money Forward Admina, in an explanatory article on optimising SaaS spend (published 30 January 2026, updated 23 April 2026), also addresses the way subscription costs that nobody has a full grip on squeeze the business, and identifies deleting unnecessary accounts, reviewing plans and sorting out overlapping tools as the practical starting points. In other words, the same problem is happening inside Japan too. This is not a peculiarity of Thai operations.

Three Reasons IT Asset Management Breaks Down Faster at a Thai Site

That said, Thai sites do have their own specific fragility. There are three reasons.

The first is that the approval line is doubled. A Thai entity has its own local approval authority, but at the same time some systems are introduced under a policy set by the Japanese head office. Groupware and cloud storage that head office contracted as a company-wide standard never appear on the Thai register, because the cost is booked on the head office side. Yet the people using the IDs are Thai employees, and when someone resigns it is the Thai side that has to tidy up. A contract where “who pays” and “who uses” have come apart lands only half-heartedly on either register.

The second is the speed of staff turnover. Changing employers is normal in the Thai labour market, and it is not unusual for the system owner to change every two to three years. Japanese managers also rotate every three to five years on expatriate assignment. The probability that the person who signed the contract and the person who renews it are two different people is clearly higher than it is in Japan. When the reasoning behind a contract has not been handed over, the renewal decision converges on “same amount as last year, approve it.”

The third is the language and the dispersion of the contract documents themselves. Contracts with local Thai vendors are in Thai or English, contracts with Japanese vendors are in Japanese, and global SaaS amounts to nothing more than clicking agreement to online terms of service. Those three kinds almost never sit on the same shelf. The third kind in particular, services contracted online and paid by credit card, has no paper contract in existence at all, so there is nothing to search for.

What happens when all three stack up? A permanent gap opens between the contracts the IT department knows about and the contracts the company is actually paying for. And that gap stays invisible for as long as the payments keep going through. The invoice arrives at accounting, and accounting reasons that “it comes every month, so it must be correct.” That is how you arrive at a situation where nobody has lied to anybody and yet nobody knows the truth.

For the difficulty inherent in overseas rollout itself, it is worth also reading what happens when you roll a system out to an overseas plant. Decisions made at the implementation stage do a great deal to determine the shape asset management takes afterwards.

Contracts Fall Out of the Register in Three Patterns

Having looked at a large number of contracts that fell out of the register, we categorise the ways they fall out into three patterns. Once you know the pattern, you know where to look.

The first pattern is the departmental contract. General affairs, accounting, sales or quality assurance signs a service on its own to solve a problem in its own work. The amount sits within departmental approval authority, so it never passes through IT. There is no bad intent whatsoever. If anything, these are adopted as a result of the floor improving things on its own initiative. From the IT department’s point of view, though, they are contracts whose very existence is invisible. To find this pattern, the shortest route is not to search by system name but to sort accounting’s payment data by department.

The second pattern is the personal contract. Someone signs up using a personal credit card or personal account and puts it through expense reimbursement. Translation tools, drawing viewers, online storage, AI assistants. The characteristic is that unit prices are small. The amounts rarely become large, but this is the highest-risk pattern of the three, because business data is stored in an account outside the company’s control and access is lost the moment that person resigns. This is exactly the territory dxeco covers in its explainer on shadow IT.

The third pattern is the ancillary contract. These arise attached to a main contract. The main contract is on the register, but the ancillary portion alone is missing. Additional licences for the production management system, a storage expansion option on a cloud service, an extended retention option on backups. As a contract it is one item, so it is easy to overlook, yet the annual fee grows steadily. To find this pattern you have to open the invoice down to the individual line items, because it does not appear when you look at the contract level rather than the line level.

The three patterns all live in different places. Departmental contracts are in accounting’s payment data, personal contracts are in expense reimbursement data, ancillary contracts are in invoice line items. However many times you re-examine the contract folder the IT department holds, none of them will turn up. As the opening move of an inventory, start by requesting the data from those three sources.

Model Case – Taking Inventory of Seven Contracts at a Rayong Factory

From here we work through a concrete model case. What follows is a model calculation of our own and does not represent the figures of any real company. Look past the amounts themselves at the structure, at where the leakage occurs and what moves once you take inventory.

The assumptions are as follows. A Japanese-owned electronic components assembly plant in Rayong Province, Thailand, with 250 employees. Over the past eight years it has signed seven business systems, at different times and through different approvers. There is no dedicated IT asset manager, and an accounting staff member maintains an Excel register alongside their main job. It is a very common configuration.

An inventory was carried out, and all seven contracts were laid out on a single sheet as follows. Annual fees are in THB.

The moment that table existed, the first finding was already there. The four contracts that were on the register totalled 636,000 a year, which is 49.5% of total spend. The three that were off the register totalled 648,000, or 50.5% of total spend. In other words, the IT spend this factory believed it had a grip on was less than half of what it was actually spending.

What deserves attention here is that whether a contract made it onto the register was not determined by how important the system was, nor by how large the amount was. The only thing that separated them was the approving department. All four contracts approved by IT are on the register; all three approved by other departments are off it. And the three off-register contracts are the larger group by total value. Even per contract, the single most expensive item, No. 7, the quotation and order management system at 264,000, sat outside the register.

No amount of diligence on the part of the person maintaining the register can fix this structure, because the IT staff member has no means of learning that a contract they were not involved in even exists. The register is only half filled not because the person is only doing half the work, but because only half the information is reaching them.

Which means that the way to improve the accuracy of IT asset management is not “keep the register more carefully.” It is “build a route by which information about contracts that bypass IT always reaches IT anyway.” That distinction changes the design of the work substantially, because the first is a matter of individual effort and the second is a matter of mechanism.

What Was Happening Inside the Three Off-Register Contracts

When we examined the contract terms and actual usage of the three off-register contracts, all three turned out to be wasting money, each in a different way. What they had in common was that all of it occurred during a period when nobody was looking.

No. 7, quotation and order management system (approved by sales, 264,000 a year). In the second contract year, auto-renewal of the plan had switched it to the premium tier. The original annual fee was 216,000; after renewal it was 264,000. The difference is 48,000, a rise of 22.2% against the original annual fee. The sales department was not aware it had moved to a higher tier, and was not using the additional functions either.

No. 5, internal enquiry chatbot (approved by general affairs, 216,000 a year). General affairs signed it to make handling employee enquiries more efficient. The investigation showed, however, that FAQ and help functionality had been included in the existing production management system contract (No. 1) from the start. The functionality overlapped. Checking actual usage further, of 90 enquiries a month, only 18 (20.0%) were genuine internal enquiries; the rest were test usage or duplicate tickets.

No. 6, payroll and HR system (approved by accounting, 168,000 a year). Billing is per user ID, and 5 seats belonging to former employees had been left in place. Each seat costs 800 THB a month, or 9,600 THB a year. Across five seats, 48,000 THB a year was being paid for accounts nobody was using.

Line the three up and you can see the sources of waste are entirely different. No. 7 was a failure to track a change in contract terms. No. 5 was a failure to check for functional overlap with another system. No. 6 was a failure to link HR transfer and leaver data with system account data. Different causes mean different countermeasures. No single initiative resolves all three at once.

There is exactly one condition the three share. All of them sat outside the register, and none had ever had a single occasion on which they were reviewed annually. Put the other way round, nothing of this kind was found among the four contracts that were on the register. Putting a contract on a register has no direct saving effect in itself, but being on the register at least creates an occasion to look at it. That is where the practical value of IT asset management lies.

The Quiet Price Rise Created by Auto-Renewal

Of the three findings, the hardest to notice is the auto-renewal on No. 7. It is worth looking at on its own.

Cloud and SaaS contracts are almost all designed on the assumption of auto-renewal. Unless you give notice of cancellation or a change of terms, the contract continues on the same terms. That is a rational arrangement that reduces administrative burden for the customer too, and it is not a problem in itself.

The problem is that what “continues on the same terms” contains does not necessarily mean the same amount. Automatic migration to a higher tier, tiered billing that scales with usage, expiry of a first-year discount that was always time-limited, adjustments following exchange rate movement or local price revision. Every one of them is written into the contract terms from the beginning, and a notification email is sent in advance. But that notification goes to the email address of the person who signed the contract. If that person has been reassigned, the email is read by nobody.

In the model case, No. 7 went from 216,000 to 264,000 a year, a rise of 48,000. Taken in a single year it is not an amount that would require formal approval. Nobody noticed it had gone up. But that 48,000 recurs next year and the year after. And once a contract has renewed on a higher tier, it continues on that higher tier at the next renewal too. The cumulative gap widens in proportion to how long it goes unaddressed.

We call this a quiet price rise not because there is no notice of the increase, but because there is no approval of the increase. Normally, when spending goes up, somebody makes a decision. A decision leaves a record, and a record can be verified afterwards. An increase from auto-renewal has no decision step. Spending has risen without anyone deciding, so no trail is left for anyone to follow when they later ask why it went up.

The countermeasure is startlingly simple. Write the renewal date and the cancellation notice deadline on the register. Most SaaS contracts set a deadline stating how many days before renewal you must give notice in order to change terms or cancel. Miss that deadline and you cannot move the terms for that year. Which means the timing for negotiation is not the renewal date. It is the renewal date minus the notice period. Whether that date is written on your register determines whether you can negotiate at all.

One more thing works well in practice. Change the contact address on each contract from an individual’s email address to a shared departmental address. Notifications then keep arriving even after the responsible person changes. As an administrative task it takes a few minutes, and almost no factory has done it.

Why Duplicate Contracts Happen – Functions Overlap, Contracts Do Not

The No. 5 chatbot is a textbook case of overlapping functionality. But concluding that “they should have checked” misreads what actually happened, because there is a certain inevitability in the structure that produces overlap.

Put yourself in the position of the general affairs staff member. Handling employee enquiries is eating their time. Work rules, remaining annual leave, social insurance procedures, how to fill in internal request forms. The same questions come round again and again, so they want something that answers automatically. They research the market, find a chatbot SaaS, and the price sits within departmental approval authority. They adopt it. There is not a single error of judgement anywhere in that sequence.

Meanwhile, the fact that the production management system includes FAQ and help functionality is written in that system’s contract and product documentation. But that documentation is held by the IT department and by the production management owner at the plant, and the general affairs staff member has no occasion to read it. From general affairs’ point of view, the production management system is something the shop floor uses, a product category with no relationship to internal enquiries. The thought “reading the production management system documentation might have solved this” would never naturally arise.

Duplicate contracts, in short, come from information asymmetry. There is no route by which a department that did not sign a contract can learn what that contract already includes. This is not a problem of effort spent investigating. It is a problem of where the information is kept.

And overlap occurs on a second level as well. If the contracts are separate, no system anywhere raises a warning when functionality overlaps. Nothing built into individual business SaaS products can detect that a single company is paying twice for the same purpose. The only things that can detect it are a human being who has laid all the contracts out in one place, or a management tool built for that purpose.

The countermeasure that works in practice is to add a “main functions” column to the contract register and classify each contract with five to ten coarse function tags. Enquiry handling, forms, inventory, production reporting, attendance, approval workflow. That level of granularity is enough. If the same tag appears against two contracts, that is a candidate for duplication. You do not need a rigorous feature-by-feature comparison. You need an entry point that surfaces candidates for checking.

Note that in the model case, the decision was not to cancel the chatbot contract but to reduce it to a lighter plan, because 18 uses a month of genuine activity remained. Finding an overlap does not automatically make full elimination the right answer. Keep the usage that has a real track record and match the scale to reality. That adjustment is another reason you need actual usage data.

Why Engineering Software Is Especially Difficult

The hardest remaining corner of factory IT asset management is engineering software. CAD, CAE and the software used for equipment design and simulation fall into this category.

OpenLM Japan’s 2026 comparison guide to licence management solutions for enterprise IT (published 17 June 2026) positions engineering software such as Autodesk, Bentley, ANSYS, Esri and Dassault Systèmes as a domain requiring particularly expensive and complex licence management. What makes this area difficult in factory asset management is a combination of circumstances.

First, the licence forms are varied. Node-locked licences tied to a specific machine, floating licences that manage concurrent use across the company, subscriptions bounded by a period, module-level add-on licences. Even for the same product, a different contract form means a different unit of management. You cannot answer the question “how many do we hold” without first confirming the form.

Second, it is hard to see whether they are actually being used. With a floating licence you are buying a ceiling on concurrent users, so unless you measure actual concurrent use against that ceiling you cannot tell what the appropriate number is. A licence that has been launched a handful of times in a year and a licence that is permanently pinned at the ceiling appear on the register as the same single unit.

Third, unit prices are high. Because the amounts are large, the impact of holding surplus is large, and so is the impact of falling short and halting work. That is exactly why they are hard to cut, and why the judgement “buy a few extra to be safe” accumulates easily in this domain.

The same guide also points out that licence management itself is evolving beyond understanding who holds what, toward real-time usage analysis, the use of AI, and support for FinOps and GreenOps. That is written with large enterprise IT departments in mind, but the direction applies to factories too. Building the register is not the finish line. Measuring actual usage and feeding it back into the contract is part of the same continuous piece of work.

Even so, you do not have to implement usage analytics from day one. For a factory that holds engineering software, simply getting five fields onto one sheet, product name, licence form, quantity, annual fee and renewal date, already changes the basis for decisions substantially. The model case factory holds no contracts in this domain, but at sites with a design function this is frequently where the largest amounts sit.

How Much Moves When You Take Inventory – The Model Case Savings Breakdown

Here are the actions the model case factory took as a result of the inventory, and the savings. To repeat, this is a model calculation of our own and not the figures of any real company.

Against total spend of 1,284,000, the saving is 216,000, a reduction rate of 16.8%. If the post-inventory state is maintained, the simple five-year cumulative saving comes to 1,080,000 (this calculation does not include the labour cost of performing the inventory).

Work through the breakdown and you notice that the three actions are completely different in nature.

Reducing the chatbot (120,000) was a decision grounded in both functional overlap and actual usage. It is the largest of the three by amount and it also took the longest to reach, because it required confirming whether the FAQ functionality in the existing production management system could genuinely serve the use case general affairs needed, and deciding how to absorb the 18 genuine uses a month. The larger the amount involved, the more an action requires both technical verification and agreement between departments.

Negotiating the plan back (48,000) was a negotiation to reverse the increase caused by auto-renewal. Because there was evidence that the added functions were not being used, the material for the negotiation was clear. But it only works if you know the renewal date and the cancellation notice deadline. Past the deadline, you may get a hearing, but you cannot move the amount for that fiscal year.

Cancelling dormant accounts (48,000) is the simplest of the three and the fastest to execute. It is complete once you match the leaver list against the account list. It requires no technical assessment and no inter-departmental negotiation. If you are starting an inventory, we recommend beginning here. It has the shortest time to effect, and because the result shows up as a number it makes it easier to win the internal understanding you need to move on to the next action.

There is a caveat, however. Deleting a former employee’s account can also mean losing access to past data. For payroll and HR systems, there may be a requirement to retain records covering the period of employment. Before cancelling, confirm the data retention requirements from an HR and legal standpoint. It is a simple task, but skipping that check causes trouble later.

As for how to interpret a reduction rate of 16.8%, the important point is that this is not “an effect that appears once in year one.” The essential value of an inventory lies less in the saving itself than in the fact that, afterwards, an approval step is inserted before spending can rise. Once the register and renewal monitoring exist, quiet increases through auto-renewal stop happening. The benefit appears in two forms, once as a saving and every year as suppression of increases.

The Practical IT Asset Management Flow – Register, Inventory, Contract Consolidation, Renewal Monitoring

Let us organise everything above into four practical stages. The order matters, so do not skip ahead.

Stage one is building the register. The goal is to get every IT-related contract the company currently pays for onto a single sheet. The IT department’s contract folder will not fill it. Request payment data from accounting sorted by department, extract IT-related items from expense reimbursement data, and open invoices down to the line items. This is the work of picking up the three patterns described earlier, departmental, personal and ancillary, from three different places. At this stage you do not assess whether amounts are reasonable. Aim only at completeness. Mixing in judgement stalls the work.

Stage two is the inventory. For the contracts now listed, match contract terms against actual usage. The plan written in the contract against the plan currently applied. The number of users contracted against the number of users actually logging in. The functions contracted against the functions actually used. What you need at this stage is usage data exported from each service’s admin console. Most SaaS products give administrators reports on login history and active user counts. Confirm with data rather than with the feeling that there must be some unused functionality.

Stage three is contract consolidation. Reflect the duplication and excess you found into actual contract changes. Reducing plans, cutting user counts, cancelling or shrinking duplicate contracts, aligning renewal dates. What you run into at this stage is inter-departmental negotiation. To the department that signed the contract, this can look like their judgement being overruled. Do not approach it as “there was wasteful spending.” Approach it as “looked at across the whole company we are paying twice for the same functionality, so we want to decide which one to consolidate onto.” In practice, that difference in framing alone changes how far you get.

Stage four is renewal monitoring. This is the stage most often dismissed, and the one that works hardest. List the renewal date and cancellation notice deadline for every contract, and set an alert 30 days before the notice deadline. Mechanically, a recurring calendar entry is perfectly adequate. What matters is that the alert goes to several people rather than one individual, and that you have decided in advance what happens when the alert fires. Write one sentence into your operating rules along the lines of “for contracts approaching renewal, confirm actual usage and decide whether to continue, reduce or cancel.”

Of the four stages, one and two are one-off work, stage three proceeds contract by contract as renewal dates arrive, and stage four is permanent operation. The common failure is to try to do stages one and two perfectly, run out of energy, and never reach stage four. Eighty percent accuracy on the register is fine. A register that is 80% accurate with renewal monitoring attached functions far better than a register that is 100% accurate and never updated.

On timescale, our sense from the work we have supported is that for a factory with around ten contracts, stages one and two take one to two months, and stage three proceeds over the course of a year as each contract’s renewal date arrives. Those are not figures that generalise into a market benchmark, but the one thing that is common is that you do not need to change everything at once.

Where to Draw the Line Between In-House and Outsourced

Insource all of IT asset management and it stops the moment the responsible person leaves. Outsource all of it and you are placing sensitive contract information outside the company, and your decisions slow down as well. You need a boundary.

What works in practice is this division: holding the register and running renewal monitoring in-house, with inventory analysis and contract negotiation design outsourced.

What to keep in-house. First, the register itself. Which contracts exist, how much you pay, when they renew. This is foundational company information and should not be entrusted outside. Second, the operation of renewal monitoring. Receiving the alerts and running the decision process stays inside. Delegate the decisions themselves and negotiation with departments stops progressing. Third, tidying up accounts on resignation and transfer. It is work that links to HR data, so completing it internally is the natural arrangement. The 48,000 found on No. 6 in the model case would never have arisen had this routine existed.

What can be outsourced. One is the analysis in the first inventory. Laying seven or ten contracts side by side and spotting functional overlap gets faster the more companies’ configurations you have seen. Done internally, the existing way of using things becomes the assumption, which makes the overlap itself harder to see. The other is designing the contract negotiation. Which terms are negotiable, at what moment to raise them, what alternatives can be put on the table. That judgement depends on a sense of market rates, so outside knowledge earns its keep.

Two conditions make the boundary work. The first is not to leave the in-house side to a single person. Changing employers is normal in Thailand, so put at least two people in place who know where the register lives and how renewal monitoring runs. A register held by one person becomes, the moment they resign, a file that exists but nobody can open. The second is to decide in advance what range of information goes outside. Contract amounts and contract terms have to be shared; employees’ personal data does not. Draw the distinction that an inventory needs the number of accounts, not the names attached to them.

The same boundary applies when you add a new system. Organise the contract terms against the register’s fields from the evaluation stage onward, and there is no separate task of adding it to the register after go-live. Do not make implementation and asset management two different jobs. If you want to work back from the structure of implementation cost, what business system development actually costs is also useful background.

Issues That Bite Specifically at Thai and ASEAN Sites

Here are the issues that arise when operating in Thailand and never come up in a domestic Japanese discussion.

Mixed contract currencies and payment methods. IT contracts at a Thai site come in THB, USD and JPY all at once. Global SaaS is billed in USD on a credit card, Japanese vendors invoice in JPY through head office, local vendors are paid by bank transfer in THB. When you build the register, putting those three into one column means you cannot produce a total. In practice, hold a “contract currency” column and a “THB equivalent” column separately, and fix a reference date for the conversion rate. For an annual inventory, aligning on the period-end rate is the easiest method to handle.

The boundary between head office contracts and local contracts. As noted, services head office contracted as a company-wide standard never appear on the local register, yet the people using the IDs are local employees. The one thing to settle here is who disables the account when someone resigns. When the cost sits with head office, the local side has little incentive to disable anything. But leaving it undisabled means a former employee retains access to company data. Separate the cost question from the security question, and make sure the latter is always part of local operations.

Language and contract storage. When contracts are dispersed across Thai, English and Japanese, only a limited number of people can verify the terms at renewal. You do not need to translate the full text, but four items, contract period, renewal conditions, cancellation notice deadline and pricing structure, should be transcribed onto the register in Japanese or English. Whatever language the original is in, the information needed for a decision then becomes readable.

Frequency of staff changes. From what we see on the ground, it is not unusual for the Thai system owner to change every two to three years and the Japanese manager every three to five. Design on that assumption and the register goes into a shared folder rather than an individual’s PC, the contract contact address becomes a shared departmental address, and renewal alerts go to several recipients. All of those are technically trivial, but none of them happen by themselves unless you decide them.

Renewal customs with local vendors. In contracts with Thai vendors, the review of terms at renewal is sometimes less formalised than in Japan. Read the other way, that means there is room for terms to move if you come to the negotiation holding usage data. The 48,000 correction achieved on No. 7 in the model case was possible precisely because there was evidence the added functions were not being used. A negotiation without data becomes haggling over price. A negotiation with data becomes a redesign of the terms.

Local deployment of electronic forms and cloud services. Thai sites mix cases where a product used by the Japanese head office is brought in as-is with cases where the product is procured locally. Some products have licence structures that differ by country, so it is safer to confirm the local offering before signing. In electronic forms, for example, there are products such as i-Reporter, where the pricing and licence structure means that the way licences are counted is itself what determines the cost structure.

Ten Items to Put on the Inventory Sheet

On the format of the register, here are the minimum fields to assemble. Every one of them only starts working once it is written down rather than remembered.

• System name and provider. Write both the Japanese and English names, to prevent naming mismatches when contacting the vendor
• Approving department and current responsible manager. Write the name of the person who can make a decision now, not the person who approved the original contract
• Contract form. Perpetual purchase, annual subscription or monthly billing, and whether auto-renewal applies, in the same field
• Billing unit. Per user ID, per concurrent connection, per site or by data volume. This is the source of variable cost
• Contracted quantity and actual usage. Put the number of contracted IDs and the number of IDs that actually logged in over the last month side by side
• Annual fee and its currency. Hold the THB equivalent in a separate column and state the reference date for conversion
• Contract start date and renewal date. If the renewal date is only known as “one year after signing,” calculate and write the actual date
• Cancellation notice deadline. Write how many days before renewal notice is required, as an actual date
• Main function tags. A coarse classification such as enquiry handling, forms, inventory, production reporting, attendance and approval workflow is sufficient
• Data storage location and treatment on resignation. Where in the cloud the data sits, and who does what when a user leaves

Of the ten, the one that usually stays blank longest is the eighth, the cancellation notice deadline. It cannot be established without opening the contract, and for online contracts it is buried in the terms of service. Filling it in takes effort, but it is the field that determines when you can negotiate, so do not skip it.

The fifth, contracted quantity against actual usage, also stays blank at many factories, because actual usage has to be pulled from the service’s admin console and is not written in the contract. Yet the moment those two numbers sit next to each other, savings candidates surface automatically. The five dormant seats found on No. 6 in the model case would have been discovered in the first inventory simply by placing those two columns side by side.

If you already have a register, count how many of these ten fields are populated. If it is fewer than five, that register may function as a record of assets but it cannot be used to manage cost.

Five Common Failure Patterns

Five failures we have actually watched happen at Japanese-owned factories in Thailand.

Starting from counting PCs. The most common pattern. People hear IT asset management and begin with a hardware inventory. The workload is large and it feels like an achievement, but against the composition of spending the effect is limited. As described above, the centre of spending has moved to software and cloud contracts. We are not saying skip the device inventory, but the order is contracts first. A contract inventory usually finishes in less time than a full device count, and it produces a financial effect sooner.

Building the register inside the IT department only. However carefully you organise the contracts IT knows about, as the model case showed, that is only half of the spending. The entry point for building a register is not IT’s contract folder but accounting’s payment data. Get that wrong and you produce a highly accurate register of half the picture.

Approaching departments with the framing of “wasteful spending.” Departmental contracts were adopted through legitimate judgement to solve a real problem in that department’s work. Deliver the inventory results with the words “there was waste” and the department becomes defensive, and information stops flowing to you next time. IT asset management is a continuous operation, so a relationship in which information keeps arriving is worth more than a single round of savings.

Building the register and stopping there. When the first inventory produces savings, it feels like a natural stopping point. But a register starts going stale the moment it is built. Six months later there are two new contracts, and a year later the renewal terms have changed. Unless you reach the fourth stage, renewal monitoring, you will be back in the same state within two years. Building the register is a task; renewal monitoring is an operation. They are two different things.

Leaving leaver account clean-up entirely to HR. This is the case where the offboarding checklist has one line saying “disable system accounts” without specifying which systems. The HR staff member does not hold a list of all systems, so they disable only the ones they know about. Off-register contracts naturally fall through. The fix is to enumerate the systems individually on the offboarding checklist. Once the register exists, it can be turned into that list directly.

Frequently Asked Questions

What exactly does IT asset management manage?

It is the activity of maintaining a single, consolidated view of hardware, software and the contracts and licences attached to them, as company assets. Factories often enter through device management as an extension of the equipment register, but the centre of spending has moved to software and cloud contracts. Mordor Intelligence’s Thailand market report also puts software at 41.72% of the 2025 market composition and cloud at 55.84% by deployment mode. Factory IT asset management therefore requires a contract register separate from the equipment register, holding the approving department, annual fee, billing unit, renewal date and cancellation notice deadline.

Where should software license management start?

Start from accounting’s payment data, not the contract folder. Organising only the contracts the IT department knows about gets you, as the model case showed, to roughly half of the spending. Sort payment data by department, extract IT-related items from expense reimbursement data, and open invoices down to the line items. From those three places you pick up the three patterns, departmental, personal and ancillary. Once coverage is complete, move on to the inventory that matches contracted quantity against actual usage. Trying to judge whether amounts are reasonable from the outset stalls the work, so concentrate first on simply listing everything.

As a shadow IT countermeasure, what should we shut down first?

Not starting from shutting things down tends to work better. Someone using a personally contracted tool is doing so because there is a genuine work requirement. Ban everything across the board and the activity simply moves somewhere less visible. In practice, first establish what exists from expense reimbursement data, then migrate whatever is genuinely needed onto company contracts. After that, clarify where the data is stored and how it is handled when someone resigns. Cybernet Systems also raises the point that cloud services require management at the level of the user ID and carry a risk of turning into shadow IT. Aligning the unit of management to the ID is the countermeasure that comes before prohibition.

How do we systematise IT contract renewal management?

Manage against the cancellation notice deadline rather than the renewal date. Most SaaS contracts have a deadline stating how many days before renewal you must give notice in order to change terms or cancel. Miss it and the terms cannot move for that fiscal year. Write the cancellation notice deadline on the register as an actual date and set an alert 30 days before it. Send the alert to several people rather than one individual, and change the contract contact address to a shared departmental address as well. Creating a state in which notifications keep arriving after the responsible person changes is what systematisation actually means.

How far do we need to take IT budget visibility before it pays off?

The first effect appears as soon as the annual fees for every contract sit on one sheet and you can produce a total. In the model case, simply laying the seven contracts onto a single sheet revealed that only 49.5% of total spend was on the register, and from there three actions produced savings of 216,000 THB a year, a reduction rate of 16.8%. As the next stage, putting contracted quantity and actual usage side by side makes savings candidates surface concretely. You do not need to build automated usage collection or a dashboard from the outset. One Excel sheet and an alert on renewal dates is enough to make it work.

Summary

Here are the points of this article.

Factory IT asset management does not break down because the number of systems increases. It breaks down because the people who approve contracts are dispersed outside the IT department. Different approving departments mean different filing locations and different renewal contacts, and the information never reaches IT. A register that is only half filled is not the result of insufficient effort. It is the result of no information route having been designed.

What needs managing has changed too. Counting physical things in the spirit of an equipment register will not capture today’s spending. In Thailand’s IT and security market, the 2025 composition puts software at 41.72% and cloud at 55.84% by deployment mode. The unit of management is the contract number rather than the asset number, and what has to be recorded is not the installation location but the approving department, annual fee, billing unit, renewal date and cancellation notice deadline.

In the model calculation, the electronic components assembly plant in Rayong held seven contracts totalling 1,284,000 THB a year, of which only 636,000 THB, or 49.5% of total spend, was on the register. Among the three off-register contracts we found a rise from 216,000 to 264,000 a year through auto-renewal (a difference of 48,000, or 22.2%), a duplicate contract used for only 18 of 90 enquiries a month (20.0%), and 48,000 a year wasted on five dormant former-employee accounts. The three actions taken after the inventory cut 216,000 THB a year, a reduction rate of 16.8%, and a simple five-year cumulative total of 1,080,000 THB. This is a model calculation of our own and not the figures of any real company, so look past the amounts at the structure, at where leakage appears and how you close it.

In practice, proceed through four stages: building the register, taking inventory, consolidating contracts and monitoring renewals. The fourth, renewal monitoring, is the most dismissed and the most effective. A register that is 80% accurate still works if renewal monitoring is attached, while a register that is 100% accurate but never updated is back where it started within two years. The practical boundary is to hold the register, renewal monitoring and account clean-up in-house, and to outsource the first analysis and the negotiation design.

At a Thai site, mixed contract currencies, the boundary between head office and local contracts, contracts dispersed across languages and the frequency of staff changes all push the register toward breaking down. Which is exactly why simple design choices work so well: put the register in a shared folder, use a shared address as the contact, and send alerts to several recipients.

Start by getting every IT-related contract the company currently pays for onto a single sheet. That alone shows you what proportion you had a grip on.

It is perfectly fine to start from not knowing how many contracts you have. TOMAS TECH implements and operates production management and other business systems for Japanese-owned factories in Thailand, and we are happy to begin from simply organising your existing contract list together. Conversations that do not assume a new system are equally welcome, so if you would like to get a clear picture of the current situation first, please get in touch through our contact page.

References

• OpenLM Japan — 2026 Comparison Guide to Licence Management Solutions for Enterprise IT (June 2026)
• Cybernet Systems — Future Challenges in IT Asset Management (IT asset management knowledge base)
• Cybernet Systems — The Importance of Software Licence Management and Key Management Points (IT asset management knowledge base)
• Money Forward Admina — The Definitive Guide to SaaS Cost Reduction and Licence Management (January 2026, updated April 2026)
• Mordor Intelligence — Thailand IT and Security Market Size and Share Analysis (updated August 2026)
• dxeco — What Shadow IT Is, Its Hidden Risks and Causes, and Five Steps from Investigation to Countermeasures (dxeco column)