Facility Management Systems: Where Maintenance Fits

A facility can be several things at once. To a maintenance technician, it is a collection of equipment, systems and locations that need work. To a facilities team, it may also be rooms, occupants, service requests, moves, contractors and building services. To a real-estate team, it may be square footage, occupancy, leases and operating costs. To management, it may be one building inside a larger portfolio.

That is why the phrase facility management system can mislead. Two products can carry the label while organising the world around very different records and decisions.

What version of the facility does this system need to understand?

Maintenance fits inside that answer. It is not always the whole answer.

The short answer

Facility management systems can cover anything from maintenance work orders and preventive maintenance to space management, occupancy, moves, leases, projects, room reservations and portfolio planning. Maintenance is one major facility management function, and different systems give it different depth.

A maintenance-centred system may organise work around equipment, failures, PM schedules, technicians, parts and maintenance history. A broader facility or workplace system may need to connect maintenance with buildings, rooms, occupants, service requests, space plans, leases, projects and organisational assignments. Neither model is automatically better. The buyer's job is to work out which relationships have to survive in the system.

One building, several operating realities

Consider Building A: four floors, 220 rooms and workspaces, 310 occupants, leased and shared spaces, HVAC systems, pumps, electrical equipment, fire and life-safety equipment, furniture, meeting rooms, service requests, preventive maintenance schedules and renovation projects.

Now three questions about the same facility.

• A technician asks: what maintenance does AHU-4 need?
• A space planner asks: which rooms on Floor 3 are vacant or underutilised?
• A facilities manager asks: if Department X moves to Floor 3, what spaces, equipment, service responsibilities and projects are affected?

All three concern one building. They require different models of it. That is the central issue when evaluating facility management systems.

Public buyers show how broad the category can become

Public procurement documents make the overlap visible, because the buyer writes down which records the system has to manage before any vendor answers. The five documents below were read in full.

Eastern Washington University's solicitation is a maintenance-centred procurement that reaches outward into facilities. The requirement list covers work orders and customer requests, preventive maintenance, fleet maintenance for over 100 vehicles, asset and equipment tracking, and space and building management. The training topics the vendor must price include work order management, preventative maintenance setup and management, fleet maintenance, asset management, inventory and warehouse management, and space and facility management.

The VA Office of Inspector General's CAFM requirement runs in the other direction. Its Space and Facilities Management Division supports a portfolio of leased and federally owned space in about 85 discrete office locations totalling approximately 250,000 square feet. The modules currently in use are space management (tracking occupancy and evaluating space utilisation), asset management (integrating asset inventory with physical space planning), project management, a strategic planning module producing future-year space forecasts from headcount projections, percentage growth or total area, and a room scheduling and hoteling module for conference and meeting room reservations through interactive floor plans. The general requirements ask for space management and planning, strategic planning, move management, lease management, real estate management, asset management, facility maintenance and room scheduling in one solution, with chargeback functionality for space accounting to the space, cost centre, division, department or building level, industry standard area calculations, individual spaces assignable to one or more organisational entities, building data trackable by building, floor or room, and bi-directional links to AutoCAD and Revit drawings. The space module separately asks for a distinction between occupancy and ownership of spaces, and for drawings depicting occupancy from past time periods.

In that document, maintenance is one named capability inside a portfolio, space and occupancy model. In the university document, space is one named capability inside a maintenance model.

The City of Houston's integrated workplace management system solicitation separates its scope into four operating areas outright. Project management covers major construction, stacking and relocation projects. Portfolio management covers land, buildings, energy management and building-related assets, and includes lease administration, real estate transactions management, energy tracking, environmental activities and strategic planning; the document states its focus is building-level data, as opposed to space management, which is focused inside the building envelope. Space management covers space allocations, assignments and utilisation, moves, adds and changes, reservation of common spaces such as conference rooms, and stacking and blocking. Facilities and maintenance management covers preventive, demand and deferred maintenance. The detailed space questions go further than a location field: whether space can be allocated to an occupant's organisation or directly to an organisation, whether multiple users or proportional occupancy of shared spaces can be represented, how proportional usage can be allocated by percentage, actual area, shift or time, whether chargeback costs can be calculated by organisation, activity or personnel allocation, whether billing and accounting IDs can be associated with spaces, whether space capacity can be compared to actual usage, and whether an occupancy status indicator can be compared to actual occupancy.

The California Courts CAFM solicitation is useful because it does not treat these worlds as isolated. Its functional areas include property portfolio management, facilities condition monitoring, program and project management, lease administration, space management, CAD integration, planned maintenance management, demand maintenance management, work request management, asset and equipment management, tools, parts and materials management, facilities purchase requisitioning, move management and facilities document management. Its planned maintenance section then states directly that the maintenance management module requires strong ties to the asset, work request and space modules, that integration with the ERP system is also required at many points so that work invoices can be processed, and that there will be a need for cost centre accounting, such as costs accrued against a building.

The University of Maine System's 2026 IWMS addendum shows the opposite edge: where the facility system stops. Its answers state that the IWMS must integrate with the enterprise financial system for cost tracking, chargeback and reconciliation, and that billing in scope means internal chargeback workflows, cost allocation for labour and materials, rental administration and utility chargeback. It states explicitly that this does not include vendor payment processing.

A facility system can carry financial context without becoming the financial system of record.

The category label alone therefore tells a buyer surprisingly little. The operating model matters more.

The Facility Representation Map

A facility system can represent several different kinds of reality. The map below is a CMMSBuyersGuide framework, not an industry standard. It is a way of naming which records a product treats as primary.

Asset → Space → Building → Occupant → Service → Lease → Project → Portfolio

Facility software categories differ partly because they choose different primary records from the same physical world.

Maintenance usually begins with the maintainable object

Return to AHU-4. A maintenance-centred system may need to know equipment identity, parent and child relationships, location, PM schedule, work history, failures, condition, labour, parts, procedures, readings and costs. The primary question is what is happening to the maintained thing.

That depth matters, and it is not implied by the presence of an asset record. A system can hold an asset table without having enough maintenance depth to manage the equipment well. As earlier research on this site sets out, feature presence does not equal process depth, and the same applies to how equipment identity and history survive change.

Facility management can begin with place

Now consider Room 312. The facilities organisation may need to know its floor, square footage, room type, capacity, department assignment, occupant, furniture and equipment, utilisation, availability, service requests, planned moves, and the building systems that serve it.

The primary question is different: what is happening in this place?

Maintenance follows the thing that needs work. Facility management can also follow the place in which work, people, services and obligations intersect.

This is not a category definition. A CMMS can be location-aware. A facility platform can contain deep maintenance functionality. The point is which operating model the product is organised around.

A location field is not the same as a space model

Many maintenance systems allow an asset or work order to carry a location. That does not necessarily mean the system understands space as a managed object.

A space model may need a hierarchy of building, floor, room and workstation, plus relationships from the room to department, occupant, capacity, area, usage, cost allocation and drawing geometry.

Houston's requirements ask about occupancy, organisational assignment, shared spaces, proportional use, capacity, utilisation and chargeback. The VA OIG requirement includes space and occupancy management and strategic space planning. Those are questions about space as a record in its own right.

A location answers where something is. A space model can also answer who uses that place, how much of it exists, what it costs, how it is allocated and how it may change.

Object depth and spatial depth

This distinction is ours. Two systems can both contain assets and locations, while one has far greater object depth and the other far greater spatial depth.

Neither dimension is automatically more sophisticated. They solve different problems, and a product can be strong in one and thin in the other.

Do not confuse knowing where an asset is with managing the place around it.

The Operational Intersection

The Operational Intersection is another CMMSBuyersGuide framework. It names the point where one facility event requires several operating records to remain connected.

An employee in Room 312 reports that the room is too hot.

Service request → Space (Room 312) → Occupancy (department and people) → Building system (HVAC zone) → Asset (AHU-4) → Work (diagnosis and repair) → History (asset and location)

No system needs every relationship for every event. Where those relationships matter to a decision, the handoffs should survive.

The service request exposes the boundary

The person reporting the problem does not know the asset, the failure mode, the trade, the component or the repair procedure. They know where they are and what they are experiencing.

The facility system may need to translate person, place and service problem into location, system, asset and maintenance work.

The requester experiences a place. The technician repairs a cause.

The question to put to a product is whether it preserves the path between the two, and what the requester sees while the work runs. The intake and routing side of that path is covered in the work order software guide and in CMMS compared with work order software.

The Room-to-Asset Test

A user in Room 312 submits a request saying the room is too hot. Ask the vendor to demonstrate, in the product, each step.

1. How the requester identifies the location.
2. How the request is classified.
3. How facilities identifies the system or asset serving that location.
4. How work is assigned.
5. How technician findings are recorded.
6. How the requester receives status.
7. What history remains against the room.
8. What history remains against the asset.

Then move the occupant to Room 418 and ask what changes. The test shows whether the software treats requester, place, asset and work as separate but related things.

Space changes faster than buildings

A building can stand for decades while its internal use changes repeatedly. Departments move, rooms change purpose, workstations are added and removed, shared space changes, renovations alter layouts, and working patterns shift.

The VA OIG procurement asks for future-year space forecasts, occupancy tracking and room scheduling and hoteling. Houston asks for space allocations, utilisation, moves, and stacking and blocking for planning purposes.

The building may be stable while the operating meaning of its space keeps changing.

Facility systems may therefore need history not only for equipment but for space and occupancy. The VA OIG requirement for drawings depicting occupancy from past time periods is one written example of that need.

Physical truth and organisational truth

A room has physical characteristics. It can also carry organisational meaning. Room 312 exists on Floor 3; that is physical. Room 312 belongs to Department A, and later to Department B; that is organisational. Those are different facts with different lifespans.

Likewise, AHU-4 may physically serve several rooms, and those rooms may belong to several departments. Houston asks whether occupancy can be tracked by a department other than the one assigned, and the VA OIG requirement asks for a distinction between occupancy and ownership of spaces.

Facilities management often sits where physical structure meets organisational structure.

That is one reason facility systems commonly require HR, finance, CAD or BIM, real-estate and maintenance integrations.

Space allocation is not maintenance

Knowing that Department A occupies 8,000 square feet does not tell maintenance why AHU-4 failed. Knowing that AHU-4 has repeated bearing failures does not tell management whether Floor 3 is underutilised.

Integration is useful when one decision needs both contexts. It is unnecessary when the contexts merely happen to describe the same building. That is the same minimum-necessary principle set out in the CMMS and ERP guide.

The Facility Context Chain

This chain, also ours, illustrates possible context rather than a mandatory workflow.

Person / organisation → Space → Building → Service → System / asset → Work → Outcome

Not every workflow starts at the top. A PM may begin directly at the asset. A room reservation may never reach an asset. A lease decision may operate above both. The value of the chain is in showing which links your work actually crosses.

Where maintenance should be deep

If maintenance is operationally important, evaluate maintenance depth independently of the platform's breadth. The detail to test is the same as for any facility maintenance system or building maintenance system.

• Asset hierarchy
• Preventive maintenance
• Corrective work
• Planning and scheduling
• Technician execution in the field
• Labour and parts
• Failure information
• Meters and inspections
• Maintenance history
• Follow-up work

Breadth around maintenance does not compensate for shallowness inside maintenance.

Where broader facility context becomes important

Broader context matters when the organisation has to manage relationships between space and occupants, space and departments, space and costs, space and leases, space and moves, space and drawings, space and projects, service requests and requesters, service requests and places, and places and the systems that serve them.

The buyer's task is to identify which of those relationships materially affect decisions, rather than to collect all of them.

The Move Test

Department A moves from Floor 2 to Floor 4. Ask the vendor to demonstrate the occupancy change, the space assignment, the effective date, drawings or floor plans where applicable, equipment and furniture implications, service impacts, move tasks and the historical assignment record.

Then ask whether maintenance history moves. Usually equipment history should stay with the maintained object rather than follow the department. The point is not to prescribe an architecture. It is to expose whether the system distinguishes organisation, space, asset and history.

The Shared-Space Test

Two departments share a laboratory or conference area. Houston asks about exactly this, including proportional occupancy and allocation by percentage, actual area, shift or time.

• Can both relationships be represented?
• Can allocation be proportional where that is needed?
• Can utilisation differ from assigned ownership?
• Can service requests still identify the physical space?
• Can facility costs be allocated according to our policy?

Occupancy, ownership, assignment and utilisation are not always the same fact.

The Drawing Test

Facility systems frequently connect space information to CAD or Revit drawings. A line item reading CAD integration tells you nothing on its own. Ask for a demonstration instead.

1. Show Room 312 on the drawing.
2. Show its database record.
3. Show its area.
4. Show occupancy.
5. Show associated equipment where appropriate.
6. Make a layout change.
7. Show the synchronisation behaviour.
8. Show what happens to history.

Then ask which representation is authoritative when the drawing and the database disagree. That is a source-of-truth question, and it belongs in the demonstration rather than in the contract.

The Cost-of-Space Test

Houston asks whether chargeback costs can be calculated by organisation, activity or personnel allocation of space, whether billing and accounting IDs can be associated with spaces, and whether differential costs can be calculated based on space use such as occupied versus vacant space. The VA OIG requirement asks for chargeback to the space, cost centre, division, department or building level.

The University of Maine System's IWMS answers draw the boundary on the other side: the system integrates with the enterprise financial system for cost tracking, chargeback and reconciliation, and internal chargeback, cost allocation, rental administration and utility chargeback are in scope, while vendor payment processing is not.

A facility system may calculate or allocate the operational meaning of a cost without becoming the financial system of record.

Facility management is not one hierarchy

Maintenance, space, organisation and real estate each use their own structure. They overlap physically and are not interchangeable.

One building can sit inside several hierarchies at once.

Forcing every record into a single location tree is where this usually goes wrong. The buyer's question is which hierarchies must exist, and where they must intersect.

Integration should connect meanings, not merely databases

HR knows that a person belongs to Department A. The facility system knows that Department A occupies Floor 3. The space model knows which room that person is assigned. The maintenance system knows which air handler serves the area. Finance knows the department's cost centre.

Those relationships matter for certain workflows. Duplicating every field everywhere creates synchronisation problems instead of solving them. The create, govern and consume pattern in the CMMS and ERP guide applies directly here, and the same ownership questions appear when asset management software sits beside a maintenance system.

• Who owns employee identity?
• Who owns organisational structure?
• Who owns room geometry?
• Who owns equipment maintenance history?
• Who owns lease accounting?
• Who owns financial postings?

Facility integration should project the context a workflow needs without casually creating a second source of truth for it.

When a maintenance-centred system may be enough

This is a pattern rather than a checklist, and none of these points decides the question alone.

• The primary users are maintenance teams.
• Work orders and preventive maintenance dominate the workload.
• Assets and equipment are the main managed objects.
• Space functions mainly as a location reference.
• Occupancy planning is limited.
• Leases are handled elsewhere.
• Moves and projects are simple or run separately.
• Room reservations are not relevant.
• Portfolio real-estate decisions happen elsewhere.

When broader facility or IWMS context may matter

Broader functionality becomes more important when several of the following have to be managed alongside facility services and maintenance: detailed space inventory, occupancy, organisational assignment, utilisation, moves, drawings, reservations and hoteling, leases, property portfolio, projects, chargebacks and strategic space forecasting.

Even then, it does not follow that all of it belongs in one system.

Integration or consolidation

Suppose the organisation already runs a CMMS for maintenance, HR for employees, ERP for finance, lease software, CAD or BIM, and room reservation tools. Two ambitions are available. Consolidation moves several functions into one facility or IWMS platform. Integration keeps the specialised systems and connects only the information the workflows need.

Neither is automatically superior, and they carry different costs and different failure modes.

Are we trying to eliminate systems, or eliminate broken handoffs?

Do not buy breadth you cannot govern

Every additional operating model requires data ownership. Space requires a room inventory, areas, assignments and occupancy. Maintenance requires assets, PM and work history. Leases require dates, obligations and costs. Projects require plans, budgets and status.

Software breadth creates data-governance breadth.

A system with twelve modules is not useful because twelve modules exist. Someone has to keep the underlying records true.

Context Burden

Context Burden is our term for the ongoing organisational effort required to keep an additional operating context trustworthy. For every facility domain you are considering adding, ask the same six questions.

• What records must exist?
• Who creates them?
• Who owns them?
• How often do they change?
• What other systems also contain them?
• What decisions depend on their accuracy?

Integration creates value only when the connected context remains trustworthy.

The buyer's decision

Start with the operation rather than the software category.

Maintenance

What equipment and systems do we maintain, and how much maintenance depth do we need? The planning and scheduling side of that question is covered in maintenance planning software.

Space

Do rooms, floors, occupancy and utilisation need to be managed as first-class records?

People

Do occupants, departments or tenants need to stay connected to space or to service requests?

Real estate

Do leases, properties or portfolio decisions belong in scope? Where lifecycle and capital decisions are the driver, the questions in the EAM software guide apply as well.

Projects

Do renovations, moves or capital projects need direct relationships to spaces and assets?

Services

How do users request facility services, and do requests begin with people and places or with assets?

Finance

Which costs must be visible, and which system remains financially authoritative?

Drawings

Are CAD, BIM and floor plans operational records, or reference documents?

Integration

Which contexts need to intersect, and which can remain separate?

The demo should cross a boundary

Feature demonstrations are easy to pass. Ask instead for a workflow that crosses operating contexts: Room 312 is too hot, followed from requester to room to building system to AHU-4 to technician to repair to requester communication to asset history.

Then ask for a second workflow: Department A moves out of Room 312. What changes? Then a third: AHU-4 fails again. What stays connected? That sequence exposes far more than a matrix of yes answers.

Final perspective

Facility management software is broad because facilities sit at the intersection of physical assets, places, people, services, projects and financial obligations. Maintenance is one of those realities. For some organisations it is the dominant one. For others it has to coexist with detailed space, occupancy, workplace or real-estate management.

The useful question is therefore not whether to buy facility management software or maintenance software.

Which version of the facility must our system understand, and where must those versions intersect?