Systemisation is the process of dividing a facility into functional systems and subsystems that can be completed, tested, commissioned and handed over as independent units. Every tag, cable, line and instrument is allocated to exactly one subsystem, and the boundaries between subsystems are marked on the P&IDs and single line diagrams. It is the structure the whole completions and commissioning effort hangs on.

Get systemisation right and early, and construction can be sequenced to deliver whole subsystems, ITRs roll up into meaningful progress, and certificates can be issued in the order commissioning needs them. Get it wrong or late, and you spend the back end of the project re-allocating tags, reissuing certificates and arguing about who owns a valve.

Why commissioning is organised by system, not by area

Construction naturally works by area: a module, a pipe rack, a floor of a building, a substation. That makes sense for cranes, scaffolding and labour. Commissioning cannot work that way, because a system is defined by what it does, not where it is. A cooling water system may run through every area on the plot. It cannot be flushed, energised or tested until all of it is complete.

When construction finishes by area and commissioning needs systems, you get the familiar pattern: overall progress looks high, but no single subsystem is complete, so commissioning cannot start anything. Systemisation bridges the gap. It gives construction a list of subsystems to complete in priority order, and gives commissioning a unit of work it can actually test.

It also underpins the certificate chain. MCC, RFC, RFSU and handover certificates are issued against defined boundaries. If the boundaries are vague, the certificates are too. Our guide to commissioning certificates explains how each stage depends on this.

Systems vs subsystems

  • A system is a major functional grouping: instrument air, firewater, a crude oil export system, LV power distribution, HVAC for a building.
  • A subsystem is a part of a system that can be completed, tested and commissioned on its own: the instrument air compressor package, the dryer, the distribution header to one area.

Subsystems are the working unit. They are what mechanical completion is declared against, what pre-commissioning packs are built from, and usually what certificates are issued for. A good subsystem is small enough to complete early and big enough to be meaningfully tested.

Below subsystems sits the tag level: individual equipment items, instruments, cables, lines and valves, each with its own ITRs. The resulting hierarchy is project, system, subsystem and tag, which is the backbone of any completions management system.

How to define system boundaries

Boundaries are where most systemisation arguments happen. A few practical rules:

Follow function first

Group equipment by the service it provides. A subsystem should have a clear purpose you can describe in one sentence, and a commissioning test that proves that purpose.

Put boundaries at isolation points

A boundary should sit at a physical point where you can positively isolate one subsystem from another: a valve, a spectacle blind, a spool, a breaker, a fuse or a terminal. If you cannot isolate at the boundary, you cannot safely commission one side while the other is still under construction.

Allocate every tag once

Each tag belongs to exactly one subsystem. Boundary valves are the usual source of trouble: decide a rule (for example, the boundary valve belongs to the upstream subsystem) and apply it consistently.

Treat utilities and support systems as their own subsystems

Power, instrument air, nitrogen, cooling water, drains, fire and gas, and control systems are needed before process systems can be commissioned. Systemise them separately so they can be completed and handed over first.

Think about sequence

Boundaries should allow the commissioning sequence you intend. If the plan is to bring power in substation by substation, the electrical subsystems need to match that plan.

Handle shared and multi-discipline items deliberately

Electrical supplies to a mechanical package, instruments on process lines, and control system I/O all cross disciplines. Decide whether they belong to the process subsystem, the utility subsystem or their own subsystem, and record the decision.

Numbering conventions

There is no universal numbering scheme, and owners often impose their own. Most follow a pattern like:

ElementExampleMeaning
Unit or area code20Process unit or plant area
System number20-43Instrument air system in unit 20
Subsystem number20-43-02Instrument air dryer package
Discipline suffix (optional)20-43-02-EElectrical scope of that subsystem

Whatever the convention, it should be:

  • Defined in writing in the systemisation procedure or completions philosophy
  • Stable, so numbers do not change when descriptions change
  • Consistent with the tag numbering and document numbering systems
  • Short enough to use on labels, test packs and certificates

Where the owner requires a data standard for handover, such as CFIHOS, check early how system and subsystem data needs to be delivered alongside the asset taxonomy.

Marking up P&IDs and single line diagrams

Systemisation is not complete until it is drawn. The usual deliverables are:

  • Marked-up P&IDs with each subsystem highlighted in a distinct colour and boundary points clearly flagged.
  • Marked-up single line diagrams for electrical subsystems, showing boundaries at breakers or feeders.
  • Layout drawings or plot plans showing subsystem extents, useful for construction sequencing.
  • A system and subsystem register listing number, description, boundaries, responsible engineer and priority.
  • Tag-to-subsystem allocation in the completions database.

Marking up is best done jointly by the commissioning team and the relevant discipline engineers. Process engineers know the functional intent; commissioning engineers know what they need to test. Walk the marked-up drawings through with construction, too, because they will be working to them.

Systemisation process

  1. Agree the systemisation philosophy and numbering convention with the owner.
  2. Define systems from the process and utility flow schemes.
  3. Break systems into subsystems on the P&IDs and single line diagrams.
  4. Identify and mark boundary and isolation points.
  5. Build the system and subsystem register.
  6. Allocate every tag, line and cable to a subsystem in the completions database.
  7. Check for orphans (tags with no subsystem) and duplicates.
  8. Agree commissioning priority and hand construction a required-at-site sequence.
  9. Freeze, then manage changes through formal change control.

When to freeze systemisation

Systemisation should start during detailed design, as soon as P&IDs are stable enough to mark up, and be frozen before construction starts generating completions records in volume. Freezing too early means redoing it when design changes; freezing too late means ITRs and punch items are raised against the wrong boundaries, and construction has already built by area.

After the freeze, change will still happen. A late design change may add a line or move a boundary valve. Treat these as formal changes: update the marked-up drawings, re-allocate affected tags, check whether any certificates already issued are affected, and record who approved it. Unmanaged boundary changes are one of the most common reasons a certificate turns out to be invalid at handover.

Common systemisation mistakes

  • Subsystems too big. Nothing completes until everything completes.
  • Subsystems too small. Hundreds of certificates, each with more administration than substance.
  • Boundaries without isolations. You cannot commission one side safely.
  • Utilities not systemised first. Process systems are ready but have no power or air.
  • Tags left unallocated. They never get inspected, then turn up at the walkdown.
  • Systemisation owned by one person in a spreadsheet. Nobody else can see changes or trust the current version.

Managing this in Accord

Accord is built around a project, system, subsystem and equipment/tag hierarchy, with completion metrics rolling up automatically so you see progress by subsystem rather than by area. Each system progresses independently through enforced stages, and certificates are issued against that hierarchy. Its dual data model holds CFIHOS asset taxonomy alongside functional systemisation, and change requests with impact assessment and approval workflows help keep boundary changes controlled. Equipment and items can be bulk imported and exported, which helps when loading an initial tag-to-subsystem allocation.

Frequently asked questions

What is systemisation in commissioning?

Systemisation is dividing a facility into functional systems and subsystems, each with defined boundaries, so they can be completed, commissioned and handed over independently. Every tag is allocated to one subsystem, and boundaries are marked on P&IDs and single line diagrams.

Is it systemisation or systemization?

Both refer to the same process. "Systemisation" is the UK spelling and "systemization" the US spelling; you will see both in project procedures depending on the owner.

Who is responsible for systemisation?

Usually the commissioning team leads it, working with process, electrical and instrument engineers and the owner's commissioning representative. The owner often sets the numbering convention and approves the final breakdown.

How big should a subsystem be?

Big enough to be meaningfully tested as a functional unit, and small enough to be completed early without waiting on unrelated work. If a subsystem cannot be isolated from its neighbours or has no clear commissioning test, the size is probably wrong.

What happens if systemisation changes after certificates are issued?

The affected certificates may no longer match the physical boundary they describe. The change should go through formal change control, tags should be re-allocated, and any affected certificates reviewed and, where necessary, revised or reissued.