Off-the-shelf maintenance software encodes somebody else's maintenance process. Where an organisation's workflow differs - and it always differs - the software wins and the process bends, or the software gets abandoned and work goes back to spreadsheets. Usually both, in that order.
Model the organisation's real workflow first, then build to it. Assets and work orders are the shared spine, but the routing, approvals and roles follow how maintenance is actually requested, assigned and closed in this organisation rather than how a product vendor assumes it should be.
Detail
I'm not naming the organisation. I describe it here as an industrial manufacturing organisation in Saudi Arabia.
Building internal software is usually the wrong answer. It is the right answer when the process is genuinely specific, the organisation intends to keep it, and the alternative is paying for a product that will be worked around. I judged that those conditions held here.
Stack
About this system
It is an asset-centric maintenance management system. The asset register is the spine: work orders, history and responsibility all hang off it, and scheduled and reactive maintenance share one history per asset, so "what has been done to this machine" has a single answer. Requesting, assigning, performing and closing work are separate steps, each with its own interface and permissions.
An industrial manufacturing organisation in Saudi Arabia, which I'm not naming. My role was architecture and delivery.
Maintenance management software is a mature category, and most organisations should buy it. The products encode a maintenance process, and here that process did not match the organisation's workflow. Building was justified because the process was genuinely specific, the organisation intended to keep it, and the alternative was paying for a product that would be worked around.
When the process is ordinary, when nobody internally will own the software long term, or when the organisation is likely to change how it works within a few years. Custom internal software is a standing commitment: the build cost is the deposit, and the maintenance is the mortgage.
By adoption. Maintenance software succeeds when technicians use it instead of routing around it, so the honest metric is the proportion of work that arrived through the system rather than around it. Tickets closed measures nothing.
The decisions behind the build
Projects and case studies