Unified TAG for Maintenance Equipment (TOiR): Coding and Labeling

Why a unified TAG is needed and what breaks without it

A unified TAG is a short code that uniquely identifies a specific object in the maintenance system: the installation location, an asset or an assembly. When a TAG is missing or keeps changing, repair history fragments: some requests are tied to one name, others to another, and reliability figures become unreliable.

Breakdowns often start from small inconsistencies: “Pump No.2”, “Pump-2”, “P2”, “PUMP2” look like the same thing, but for the database they are different objects. Duplicated cards emerge, and repairs and costs get spread across them. This directly hinders MTBF/MTTR analysis, work planning and finding recurring failures.

Attachment errors quickly affect downtime and spare parts. If a repair is recorded on an assembly instead of the asset, the downtime will be attributed to the wrong unit. If a spare-part issue is posted to a duplicate card, inventory statistics will show the part consumed “to nowhere”, and it becomes hard to link it to specific failures.

Confusion often starts from mixing different object types:

• Installation location — where the equipment sits (workshop, line, cell).
• Asset — the specific unit that operates (pump, compressor, machine tool).
• Assembly — a part of an asset (motor, gearbox, bearing assembly).

The rule “one object — one TAG” is simple: each real object has a single permanent identifier that does not depend on each shift’s naming habits or how an engineer likes to call the equipment. The description can be refined, and model and serial numbers can be added, but the TAG stays unchanged. Then repairs, downtimes and spare parts always collect into one chain and the data stops contradicting itself.

What we actually tag: locations, assets, assemblies and components

For a unified TAG to work, first agree what you are tagging. In maintenance projects people often confuse two different objects: the place where something is installed and the equipment unit itself. If you don’t separate them from the start, later it’s hard to link repairs, downtimes and spare-part consumption.

Location (functional location) is the site “address”: workshop, line, cabinet, rack, pipeline section, switchgear cell, room. A location can exist even when equipment is removed or replaced. Its value is that it’s convenient to attach operational events to it: line downtime, shutdowns, access restrictions and safety requirements.

Asset is a specific unit that can be installed, removed, moved and retired: a pump with a serial number, an electric motor, a server, a UPS, a compressor. An asset has datasheet information, run-hours and repair history. The same asset can be installed at different locations over time.

Further levels of detail:

• Assembly — a part of an asset that makes sense to service and replace as a block (gearbox, power supply, pump module).
• Component — a smaller item often tracked in stock with a part number (bearing, belt, filter).

Make the installation location a separate TAG when you actually need accounting by that place: you record downtimes and responsibilities there, equipment is frequently changed (rotation, standby, rental), you report by line/area/rack, and the location outlives individual assets.

If the difference is only a parameter (for example, the same model in different rooms), sometimes an attribute like “room” or “section” in the asset card is enough.

In databases the usual binding logic is: repair is linked to the asset (what was fixed), downtime — to the location (what stopped), and spare parts — to an assembly or component (what was replaced). Example: line L-01 (location) is down, pump P-101 (asset) is repaired, a bearing BRG-6205 in the “support” assembly (component) is replaced. Then the chain “event — cause — consumption” forms without manual explanations.

How to start designing the TAG system

Start not with the code format but with an inventory of what already exists. Names typically live in multiple places: nameplates, datasheets and forms, floor plans, Excel lists and the maintenance database (EAM/CMMS). The first task is to consolidate sources into a single draft register and find where the same object is called differently.

Then agree what counts as an accounting object. This is critical: if one workshop treats a pump as an asset while another splits it into motor, coupling and bearings without a unified rule, honest repair and spare-part statistics won’t be possible.

A good starting minimum:

• Define object types (installation location, asset, assembly, component).
• Specify mandatory attributes (site, workshop/line, function, manufacturer, model, serial number, criticality — per your list).
• Assign data owners: who creates the card, who approves it, who may modify it, who archives it.
• Choose the level of detail: how deep you actually manage repairs and stock.
• Fix the rule: if an object never has its own request, downtime or spare-part write-off, it usually does not need a separate TAG.

A simple example: there is a pumping station in building B and pump N-3. If requests and downtimes are filed for the pump as a whole, the pump needs a TAG as an asset. If motors are regularly swapped and tracked as separate inventory items, the motor can be a separate object — but only if the accounting discipline supports it.

Data owners should be named. Typically cards are created by foremen or maintenance engineers, approved by the reliability lead or chief mechanic, and archived by the system administrator. Even when implementing a CMMS with an integrator, these roles belong to the customer — otherwise rules quickly drift.

Principles of a good TAG: structure, length, readability

A TAG must be equally usable by a fitter, a planner and an analyst. If the code is hard to read or constantly “accrues” exceptions, people start writing whatever is easiest and the database diverges again.

A practical approach is to build the code from general to specific: Site — Zone — Line/System — Type — Number. Then the TAG immediately hints where the object is and what it belongs to, even for someone seeing it for the first time.

Basic rules that usually work:

• No spaces or special characters: only Latin letters, digits and hyphens.
• No Cyrillic in TAGs, but keep a local-language “Name” field in the card.
• Fixed blocks (for example, SITE2-ZONE2-SYS3-TYPE2-NNN).
• One meaning — one block: don’t mix location and type in a single fragment.
• Numbers with leading zeros (001, 002, 010) so sorting is correct.

Separate fields matter. TAG is the key for links (repairs, downtimes, spare parts). “Name” is the convenient human name (“Boiler feed pump 1”). “Description” contains details (model, parameters, notes). “Parent” is the hierarchy link (installation location or asset) that ensures correct roll-ups in reports.

Plan for growth. If there are currently 12 pumps in a zone, agree on numbering ranges (e.g., 001–199) and system codes (WTR, AIR, HVC) now so you don’t have to change many TAGs after expansion.

Example: KZ01-B2-WTR-PU-007. In the card this may be “Circulation pump №7”, and the parent is “KZ01-B2-WTR” (system in building B2).

Example naming rules: TAG formats for different objects

A consistent TAG reads well on a tag and in the database. The easiest approach is to agree on a fixed block order and a single separator (for example, a hyphen).

One practical format: country/site - city/site - zone/line - type - sequential number.

Example for an asset:

KZ-ALM-PL1-PMP-001

Here KZ — country, ALM — site/city, PL1 — line/area, PMP — type (pump), 001 — unique number within line and type.

For installation locations avoid mixing “address” and “equipment type”. Make the TAG a short address visible on plans and doors:

KZ-ALM-B01-RM12

B01 — building (or block), RM12 — room (optionally include floor: B01-F02-RM12).

For assemblies or components it’s convenient to add a suffix type to the parent TAG:

KZ-ALM-PL1-PMP-001-MTR (motor as a pump assembly)

Type codes: short, stable, no creativity

You need a type reference and assignment rule. A minimal set could look like:

To avoid variants, keep a few strict rules: one type — one code, choose the code by function (not by brand), number always one length (e.g., 001–999), all letters uppercase, and do not change the TAG when replacing manufacturer, model or serial number.

Serial and inventory numbers: keep separate from TAG

TAG handles hierarchy and linking in maintenance. Serial number (SN) and inventory number (INV) should be stored in separate fields: they change more often, can be long and are not always unique across sites. This preserves history by TAG while keeping traceability of supplies.

Step-by-step: how to build the hierarchy in the maintenance database

Hierarchy ensures every repair, downtime and spare-part consumption falls into the right place. Then TAG works like an address: you know where it is and what it belongs to.

5 steps that usually give predictable results

1. Define the top level: site, branch, plant, data center, hospital. Fix code rules now to avoid duplicates like “Almaty-1” and “ALM01”.

2. Build the installation location hierarchy to a practical level. Often 3–5 levels suffice: building → floor → room → rack/line/area. If a level doesn’t help search or analysis, don’t add it.

3. Add assets and link them to locations. Ensure an asset has one “home” at a time, otherwise downtimes and reports easily duplicate.

4. Add assemblies and components only where needed for work and spare parts. If the power supply will never have its own request and write-off, splitting it down provides no benefit.

5. Configure lifecycle statuses and transition rules. This prevents nonexistent objects from “living” in the database.

Example: in a data center there’s installation “Hall 2, row B, rack 12”. It contains asset “Server S200-05”. You create an assembly “Power supply 2” only if it is actually replaced via requests and tracked as a spare.

Minimal rules for statuses

• Planned: in plans, not participating in repairs.
• In operation: available for requests, downtimes and spare-part movements.
• Mothballed: physically present, but new requests are forbidden.
• Retired: history only, no new work or stock movements.

How to check for duplicates when adding new objects

Duplicates arise not only as identical TAGs. Often you see “almost the same” codes due to different formats (001 vs 01), confusing characters (O vs 0, I vs 1), extra hyphens or spaces. Another common case is the same object name under different codes, e.g. “Feed pump” created twice for one location.

Minimal set of checks

Checks should run before saving the card, not “sometime later”. Before creating a new object verify:

• TAG uniqueness across the entire database (ignore case and leading/trailing spaces).
• Serial number uniqueness within a type/model. If no serial exists — record factory or inventory number.
• Uniqueness of the pair “installation location + functional role” (e.g., “Area 3 / Feed pump”).
• Compliance with TAG format (length, allowed characters, hyphen positions).

Similarity checks

Besides strict matching, a “find-similar” search is useful: it doesn’t have to block entry but should show potential duplicates.

A practical rule: when entering a TAG the system normalizes the string (removes extra spaces, converts to a single case, replaces ambiguous symbols by rule) and compares it to existing ones. Separately check leading zeros (001 vs 01), O/0 and I/1 pairs, double hyphens and accidental block reorderings.

An organizational principle: once an asset is commissioned, its TAG cannot be edited manually. If an error is found, create a correction request with a reason so history of repairs and stock movements isn’t broken.

To confirm an object is truly new, use a short approval flow: the initiator creates a draft and attaches a photo of the nameplate or datasheet, the register owner reviews similar records and format, the location owner confirms installation, and only then the object receives its final TAG.

Common mistakes and traps in coding

The most costly mistake is confusing what you are tagging: location or asset. If “Pump-1” is created as an asset and later another pump is placed there, repair history, downtimes and spare-part records begin to “travel” and lose meaning.

A related trap is changing the TAG when equipment moves. TAG should travel with the asset (or assembly); a move is recorded by changing the location and date. Otherwise reliability and cost reports turn into a list of different objects that in reality were the same pump.

Another pitfall is baking manufacturer, model or specs into the TAG. Today a 15 kW motor from one brand is installed, tomorrow an equivalent from another brand — the code becomes incorrect. Store model, serial number and parameters in the card and keep TAG stable.

Physical labeling issues also start problems. If the code is too long it won’t fit on a nameplate, will wear off, or people abbreviate it by eye. As a result the database and the workshop have different versions of the same object.

Typical symptoms:

• TAG mixes location and asset (e.g., “WORKSHOP2-PUMP-1” without a separate location card);
• TAGs are changed on transfer or when a base/frame is replaced;
• brand/model are embedded in the code (“SIEMENS”, “ABB”, “P-2000”);
• code is too long to print or read on site;
• no statuses or archiving, so retired objects remain active.

Example: pump N-014 is removed from line A and put on line B. If you rename it to “B-pump-03”, past repairs remain tied to line A and spare-part write-offs no longer match history. It’s better to keep the pump’s TAG unchanged and change only the location and hierarchy link.

Short checklist before go-live

Before mass object entry and tag printing do a quick check. It saves hours hunting for “missing” repairs and spare parts.

Check that:

• The TAG is unique and fits the format (length, separators, block order).
• The object has a parent in the hierarchy and a correct installation location.
• Minimum attributes are filled (type, criticality, responsible unit).
• Serial and inventory numbers are in separate fields, not used as the TAG.
• There is a clear rule for moves: what changes (installation location) and what stays immutable (the asset TAG).

If a pump moved from line A to line B, the pump TAG stays the same to preserve repair, downtime and replacement history. Only the installation link and, if needed, the parent in the hierarchy are changed.

Real-life example: repair, downtime and spare parts in one chain

Filling plant, line L1. A water supply pump sits on the line. To link repair, downtime and spare parts, each level gets its own TAG and links are recorded in the cards.

Example structure:

• Installation location: PLT01-ROZ-L1 (plant 01, filling workshop, line 1)
• Asset: PLT01-ROZ-L1-PMP-0101 (pump 0101 on the line)
• Assembly (pump motor): PLT01-ROZ-L1-PMP-0101-MTR
• Warehouse spare position: WH01-MTR-7K5-2P-IE3 (warehouse 01, motor 7.5 kW, 2-pole, class)

When the line stops, the operator creates a request for PLT01-ROZ-L1-PMP-0101 and marks a downtime code (e.g., “Pump failure”). The technician opens a work order and records the defect at the assembly level: “Motor bearing overheating” on ...-MTR. The work order links the work object, cause, task (bearing or motor replacement), spare-part write-off and the line downtime duration (on location PLT01-ROZ-L1, but related to the asset).

If the asset is replaced, keep the old pump’s TAG and move it to status “withdrawn/in storage”, assign a new TAG to the new asset and record the replacement as an event. To avoid duplicates, when adding a new object check the pair “installation location + type + serial number” and search for similar TAGs by mask.

Next steps: rollout, labeling and support

After agreeing TAG rules the goal is simple: the register should live not in a separate Excel but truly link repairs, downtimes and spare parts in the CMMS/EAM.

Inventory and migration

Start with data inventory in accounting systems, drawings and on site. Often the same pump exists as “Pump 1”, “P-01” and “Circulation pump”. Before import consolidate this to a single object and keep a mapping table from old designations to new TAGs.

Imports usually follow this order: first installation locations, then assets, then assemblies and components. After loading, pick 20–30 objects and manually follow the chain “request — repair — spare part — downtime” to ensure links work.

On-site labeling

Labels must be readable and durable. Many combine a visible TAG on a nameplate/label with a machine code (QR or barcode) for quick capture. Decide in advance where to place the label on the asset, cabinet or pipe so it isn’t removed during maintenance.

To keep quality from degrading run regular checks: duplicates and matches on key attributes, orphan objects without a parent, objects without work history for a period, work orders without object links, spare-part write-offs to “unknown object”.

If rolling out a CMMS/EAM with integrations (warehouse, procurement, monitoring, accounting), plan infrastructure: servers, workstations, scanners, label printing and support. A system integrator can help — for example, GSE.kz supplies servers and workstations and performs system integration, which is convenient when you need to build the maintenance system and its infrastructure in one scope and then support operations.