Replace months of CMMS configuration with a conversation

We deploy in sixteen weeks. That number has been on our proposals for years, and it is honest: it covers data migration, hierarchy build, PM plans, checklists, workflows, roles, ERP and SCADA interfaces, and training. This piece is about which of those sixteen weeks are necessary and which are a symptom of how maintenance software has always been configured.

Engineering versus authoring

Split the deployment plan into two piles.

The first pile is engineering: migrating the old CMMS export, mapping asset identifiers to the ERP, building the SCADA alarm interface, setting up single sign-on and data residency. This work is done by engineers, it has real dependencies on the client’s IT, and it takes the time it takes. Nothing in this piece shortens it.

The second pile is authoring: deciding what the PM plans are, writing the checklists, defining the workflows (when this closes, open that), and describing who is allowed to do what. This is where the calendar goes. Not because it is technically hard but because it requires humans to convert documents and tacit knowledge into structure, one workshop and one template at a time, through an interface built for implementers.

The claim is that the second pile can be a conversation. The first pile cannot, and a vendor who tells you otherwise is describing a demo.

The three conversations

The first is about the maintenance programme. “Here is our asset register. Here are the manuals and the standards we work to.” What comes back is a draft programme, per asset class, every plan cited to a manual page or a regime entry, with a coverage report listing the assets for which nothing was found. The reliability engineer reads it, corrects it where the site knows better than the manual, approves per plan or in bulk. The workshop still happens, and its job is to review the draft.

The second is about rules. “When a quarterly inverter service closes with a reading out of tolerance, open a thermography follow-up in the electrical queue and notify the site lead.” The sentence is compiled to a rule, read back in unambiguous structured English with every assumption listed, and backtested against the last twelve months of the site’s own history before it is switched on: it would have fired this many times, here is each one. The operations manager approves the read-back. No one opens a boxes-and-arrows builder.

The third is in the field, and it is the one that makes the other two worth having. The technician speaks the report, in whatever language they speak, against the checklist item they are standing in front of. The form fills in the tenant’s language, with each value pointing to the speech or the photo it came from. The technician confirms with a few taps and signs. The record arrives structured, because the person who did the work described it in their own words and the software did the typing.

What the conversation cannot do

It cannot sign. Anything with a permit, an isolation step, a pressure system or a statutory signature is signed by a named person, and the software cannot be configured otherwise.

It cannot guess. A required field with no reading spoken and no reading visible in a photo stays empty and becomes a question, asked at the end of the job in the technician’s language. A gap stays a gap.

Statutory intervals are floors. Thirty-six clean tests do not move one.

Its own performance is not self-certified. Every regime flagged statutory is checked by a practitioner before it is marked as such. Every corrected field, edited draft and rejected proposal is recorded, and over time those corrections are published per tenant as a scorecard of how often the software was right. We would rather show that than claim it.

What still takes time

The engineering pile. The domain review. The first quarter of real work orders, which is what the tuning proposals need before they are worth reading. And the decisions that were always the client’s: which owners get which reports, which subcontractors are allowed to close what. The conversation makes those decisions easier to express. It does not make them for you.

Where we are

The sixteen-week programme is what Facterra runs today, on an asset model in production since 2017. The three conversations above are what we are building, in that order, on the same model. The target we are building towards is a register and a folder of manuals on a Friday, and a reviewable, cited draft programme on the Monday. That is the target. We will say when it has been met.