# Firmicore — full site text > Firmicore is a multi-tenant, mobile-first CMMS (computerised maintenance management system) for manufacturing and process plants, covering machine registry, breakdown tracking, work orders, preventive maintenance, spare parts, contractors, shift handovers, training, safety, and reporting in one system. Canonical site: https://firmicore.com/. Generated from the site's own content at build time. # Product - **Product:** Firmicore, a multi-tenant CMMS for manufacturing and process plants - **Category:** Computerised maintenance management system (CMMS) - **Made by:** Lumora Ventures Pvt Ltd, Kuliyapitiya, Sri Lanka - **Deployment:** Cloud-hosted on Firebase; no on-site servers - **Platform:** Web and mobile browsers, including shared floor tablets - **Pricing:** 4 tiers: $29, $59 and $249 per month, plus Enterprise (contact sales); 20% off annual - **Feature modules:** 20+, including 12 core modules - **Role workspaces:** 9, from plant manager to trainee - **Triage languages:** English, Sinhala, Tamil, Bengali - **Typical industries:** Food & beverage, dairy, pharmaceuticals, packaging, textiles, chemicals - **Reporting:** 15+ report types, exportable to PDF, Excel, and Google Sheets - **Time to first value:** Pilot on one line or site, then scale across sites # Frequently asked questions ## What is Firmicore? Firmicore is a multi-tenant, mobile-first CMMS (computerised maintenance management system) for manufacturing and process plants, covering machine registry, breakdown tracking, work orders, preventive maintenance, spare parts, contractors, shift handovers, training, safety, and reporting in one system. ## How much does Firmicore cost? Firmicore has four tiers. Basic is $29/month for 10 machines and 5 users, Workshop is $59/month for 100 machines and 20 users, Factory Pro is $249/month for 1,500 machines and 100 users, and Enterprise is quoted by sales for unlimited machines and users. Annual billing takes 20% off the monthly rate. Prices are indicative; confirm exact figures with sales before quoting a customer. ## Is Firmicore priced per machine or per user? Firmicore tiers are scaled by both registered machines and user seats, so a plant with many operators but a modest asset fleet is not billed per head the way a purely per-user CMMS would bill it. Each tier states its machine limit, inventory limit, preventive maintenance limit, and user limit. ## What makes Firmicore different from other CMMS products? Guided Triage. Firmicore ships branching, multilingual troubleshooting trees as a core workflow, so a floor operator can safely diagnose and react to a fault before a technician arrives, and supervisors can author the flows per machine without engineering help. Most CMMS products in this price class treat troubleshooting as an attached document rather than a guided workflow. ## What languages does Firmicore support? Guided Triage flows run in English, Sinhala, Tamil, and Bengali, which covers the operator languages common on South Asian and Southeast Asian plant floors. ## Who uses Firmicore? Manufacturing and process plants running mid-to-large equipment fleets: food and beverage, dairy, pharmaceuticals, packaging, textiles, and chemicals. Inside a plant, Firmicore has nine role-based workspaces for plant managers and admins, maintenance supervisors, technicians, store keepers, HR and training officers, safety officers, floor operators, and trainees. ## Can an operator report a breakdown without logging in to a desktop? Yes. Every machine in the registry carries a QR code, and scanning it opens breakdown reporting for that specific asset, so the report is attached to the right machine without anyone typing an asset number. This is designed for shared floor tablets where operators rotate and there is no persistent personal login. ## How is one plant's data kept separate from another's? Firmicore is multi-tenant by design: each tenant's data is isolated, and role-based access control is enforced on every route and every write, not just in the interface. The platform runs on Firebase Auth, Firestore, Storage, and Cloud Functions. ## How long does a Firmicore rollout take? The standard path is a 30-minute discovery call, a guided demo tailored to the role that will use it most, a pilot on one line or one site, then full deployment across sites with roles pre-configured. Plants go live in days rather than months because there is no on-site infrastructure to rack, patch, or maintain. ## Does Firmicore replace spreadsheets and WhatsApp groups? That is the intended replacement. Firmicore consolidates the maintenance records that usually live in notebooks, Excel sheets, and messaging groups into one connected system, so machines, breakdowns, work orders, preventive maintenance, spares, contractors, handovers, training, and safety share the same real-time record and the same audit trail. ## What reports can Firmicore produce? More than 15 report types export in one click to PDF, Excel, or Google Sheets, alongside a cross-module KPI dashboard, a preventive maintenance compliance dashboard, and an MOE (Machine Overall Effectiveness) score that blends availability, maintenance compliance, reliability, and machine health into one composite per machine. ## Is there a free trial? Basic, Workshop, and Factory Pro start with a trial you can begin from the pricing section. Enterprise is quoted and provisioned through sales because it includes multi-site management, SSO/SAML, custom integrations, and an SLA. # Maintenance glossary ## CMMS A CMMS (computerised maintenance management system) is software that records maintenance assets, work orders, preventive maintenance schedules, and spare-parts consumption in one connected system. The test of whether a plant needs one is not headcount: it is whether questions like which machine failed most, what it cost, and whether PM was done can be answered without relying on someone's memory. See also: https://firmicore.com/blog/what-is-a-cmms/ ## EAM An EAM (enterprise asset management) system covers the full asset lifecycle, including acquisition, depreciation, and disposal, where a CMMS covers maintenance operations only. EAM is typically bought by asset-intensive enterprises that need the finance side of the asset, not just its repair history. ## Work order A work order is the record of a single maintenance job: what is to be done, on which asset, by whom, with which parts, and what was found when it was done. A work order without a sign-off step is a to-do list. The sign-off is what turns it into an audit trail. See also: https://firmicore.com/blog/work-order-software/ ## Preventive maintenance (PM) Preventive maintenance is work scheduled by elapsed time or by meter reading to prevent a failure, rather than work triggered by a failure that already happened. Calendar-based PM is simpler to run; meter-based PM tracks actual usage and avoids servicing an idle machine on schedule. See also: https://firmicore.com/blog/what-is-preventive-maintenance/ ## Reactive maintenance Reactive maintenance, also called run-to-failure, is repair work that starts only after an asset has already failed. It is not automatically wrong. It is wrong when it is the default for critical assets rather than a deliberate choice for cheap, non-critical ones. ## Condition-based maintenance Condition-based maintenance triggers work from an observed asset condition, such as vibration, temperature, or a health score crossing a threshold, rather than from a fixed schedule. ## MTTR MTTR (mean time to repair) is total downtime across incidents divided by the number of incidents, measured over a defined period and asset set. The clock should start at failure, not at technician arrival. Starting it late is the most common way plants flatter the number without improving anything. See also: https://firmicore.com/blog/what-is-mttr/ ## MTBF MTBF (mean time between failures) is total operating time divided by the number of failures, and measures reliability rather than recovery speed. MTBF and MTTR answer different questions: MTBF asks how often an asset fails, MTTR asks how long it takes to get back. ## MTTA MTTA (mean time to acknowledge) is the average time between a fault being reported and someone accepting responsibility for it. A high MTTA with a low repair time means the problem is dispatch and alerting, not the technicians. ## Unplanned downtime Unplanned downtime is production time lost to a failure that was not scheduled, measured from the moment output stops to the moment it resumes. The reported figure is almost always lower than the real one, because short stops, slow restarts, and scrap made during the ramp back up rarely get logged. See also: https://firmicore.com/blog/the-real-cost-of-unplanned-downtime/ ## OEE OEE (overall equipment effectiveness) is availability multiplied by performance multiplied by quality, expressed as a single percentage of perfect production. ## MOE MOE (Machine Overall Effectiveness) is the Firmicore composite score that blends availability, maintenance compliance, reliability, and machine health into one number per machine. Where OEE is a production metric, MOE is a maintenance metric: it is designed to flag which machine the maintenance team should look at next. ## Machine health score A machine health score is a 0-100 rating derived from an asset's failure history, maintenance compliance, and open issues, used to rank risk across a fleet. ## PM compliance PM compliance is the percentage of preventive maintenance tasks completed within their scheduled window over a period. Compliance measured without a window is meaningless, because a PM done two months late still counts as done. ## Maintenance backlog Maintenance backlog is the total volume of identified but incomplete work, usually expressed in crew-weeks rather than job count. A backlog of zero is a warning sign, not a triumph: it usually means work is not being identified. ## Guided triage Guided triage is a branching troubleshooting flow that walks an operator through safe diagnostic steps one question at a time, so a fault can be narrowed or made safe before a technician arrives. On a plant floor it has to survive shared devices, gloves, poor light, and weak connectivity near the machines, so each step has to be a single screen that queues offline. See also: https://firmicore.com/blog/guided-operator-safety-triage/ ## Shift handover A shift handover is the structured transfer of open maintenance context from the outgoing crew to the incoming one: pending work orders, ongoing breakdowns, low stock, and machines to watch. Handovers done verbally lose the items nobody thought to mention, which are reliably the items that cause the next incident. ## Permit to work A permit to work is a documented authorisation that a specific high-risk job may proceed, listing the precautions taken and the person who accepted them. ## Near miss A near miss is an incident that could have caused injury or damage but did not, recorded so the underlying condition can be fixed before it repeats with a worse outcome. ## Lockout/tagout (LOTO) Lockout/tagout is the practice of physically isolating and locking an energy source before maintenance work, with a tag identifying who applied the lock. Isolation instructions only work when they name the actual isolation point for that asset; generic safety text is ignored because it is identical everywhere. ## Root cause A root cause is the underlying condition whose removal prevents a failure from recurring, as distinct from the visible symptom that stopped the machine. Root-cause fields are only useful when the option list is short and specific to the plant; a free-text box produces a hundred spellings of the same cause. ## Asset registry An asset registry is the authoritative list of maintainable equipment, each entry carrying its identifier, location, documents, linked spare parts, and maintenance history. Every other maintenance number in the plant inherits its accuracy from this list, which is why an incomplete registry quietly invalidates the reporting built on it. ## MRO inventory MRO (maintenance, repair, and operations) inventory is the stock of spare parts and consumables held to support maintenance work rather than to be sold. The cost of MRO stock is visible on a balance sheet; the cost of a stockout that idles a line is not, which is why MRO is chronically under-held. ## QR-triggered reporting QR-triggered reporting attaches a fault report to the correct asset by scanning a code fixed to the machine, removing the step where an operator has to identify the asset by number. Misattributed reports are the main reason paper and chat-based logs cannot produce per-machine history, so removing the typing step is what makes the history usable. See also: https://firmicore.com/blog/why-qr-reporting-beats-paper-logs/ ## Multi-tenancy Multi-tenancy is an architecture where one application instance serves many customer organisations while keeping each organisation's data fully isolated from the others. Isolation has to be enforced on every read and write on the server, not by hiding data in the interface. # Articles ## CMMS Pricing Explained: Per-Machine vs Per-User Models Compared Source: https://firmicore.com/blog/cmms-pricing-per-machine-vs-per-user/ Published: August 20, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Pricing Per-user pricing quietly caps how many people you let into your maintenance system. Per-machine pricing ties cost to the thing you are actually maintaining. Here is the arithmetic for both, plus the hidden costs that neither pricing page mentions. ### Key takeaways - Per-user CMMS pricing scales with headcount, so the cost of adding an operator to the system is the same as adding a technician - even though the operator may log in twice a month. - Per-machine pricing scales with your asset register, which is the thing maintenance work is actually attached to, and it makes unlimited users economically safe. - In a modelled 50-seat deployment at $65/user/month, per-user licensing runs about $39,000 a year. The same plant with 60 machines on per-machine pricing lands in a very different bracket. - Per-user pricing genuinely wins when you have very few machines and a small, fixed maintenance team - a workshop with 8 assets and 3 technicians is not the per-machine case. - The costs that break budgets are usually not the headline rate: seat minimums, annual-only billing, feature gating by tier, storage overages, and paid onboarding. Almost every established CMMS on the market charges per user, per month. It is a familiar SaaS pattern borrowed from CRM and project management tools, and for those categories it makes sense: the person using the software is the person creating the value. Maintenance software does not work that way. The value sits in the machine history, and the people who produce the most valuable data - the operators standing next to the machine when it stops - are the least frequent users of the system. Per-user pricing charges you most for exactly the users you most want to add. This post walks through what each model actually costs, using transparent assumptions you can re-run with your own numbers. ### What per-user CMMS pricing actually costs at scale Take a mid-sized plant: 50 people who need some level of access. That is not an aggressive number. It is a maintenance manager, two supervisors, eight technicians, a storekeeper, a couple of planners, and roughly 36 machine operators across three shifts. At a mid-tier rate of $65 per user per month - broadly where the premium tiers of the larger vendors sit at list price - that is $3,250 a month, or $39,000 a year, before implementation, integrations, or overage. Every new hire adds $780 a year. Every seasonal shift adds a line item. > **Check the current rate:** Vendor pricing moves, and published rates are list prices before negotiation. Treat every figure in this post as a model you re-run with quotes you have actually received, not as a price quote. The predictable outcome is seat rationing. Plants buy 12 seats instead of 50 and route everything through supervisors. The operators - the people with the most direct evidence about what failed and why - end up reporting breakdowns verbally, and the machine history you are paying for gets thinner rather than richer. - **$39,000** — modelled 50-user annual cost - **$780** — cost of adding one user per year - **3** — shifts that each need floor access - **0** — operators most plants can afford to license ### How per-machine pricing works and why it changes the incentive Per-machine pricing charges for the assets you register in the system, and leaves user accounts unmetered. You pay for the 60 machines on your floor. Whether 12 or 200 people log in against those machines does not change the invoice. The practical effect is that the economics stop fighting the workflow. There is no reason to withhold access from a night-shift operator, a new hire, or a line lead who only needs the system when something breaks. Adoption stops being a budget decision and becomes a training decision. - Cost tracks the asset register, which changes slowly and predictably, rather than headcount, which churns. - Unlimited accounts make QR-code and shop-floor reporting viable, because casual reporters cost nothing. - Decommissioning a machine reduces cost, which gives you a reason to keep the asset register accurate. - Budgeting is easier: capital planning already tracks machines, so the finance conversation uses numbers that already exist. The trade-off is real and worth stating plainly: if you have very few machines and a lot of people, per-machine pricing costs you more. That case is covered further down. ### Side-by-side cost comparison at three factory sizes The table below models annual licensing cost only - not implementation, training, or integration work - at three plant profiles. User counts assume roughly 0.8 users per machine, which is typical for a plant that wants operators reporting directly. _Modelled annual licensing cost. Per-user column assumes $65/user/month list pricing; per-machine assumes a mid-tier asset rate. Re-run with your own quotes._ | Plant profile | Machines | Users needing access | Per-user model (annual) | Per-machine model (annual) | | --- | --- | --- | --- | --- | | Small factory | 20 | 16 | $12,480 | Scales with 20 assets | | Mid-sized plant | 50 | 40 | $31,200 | Scales with 50 assets | | Multi-line plant | 100 | 80 | $62,400 | Scales with 100 assets | _Per-user annual licensing cost by plant size (modelled at $65/user/month)_ - 20 machines / 16 users: $12,480 - 50 machines / 40 users: $31,200 - 100 machines / 80 users: $62,400 _The curve is driven by headcount, not by how many machines you maintain._ The pattern that matters is not the absolute number - it is the slope. Under per-user pricing, the cost of running maintenance software rises every time the plant hires, and rises fastest in exactly the scenario you want to encourage: more of the floor participating in reporting. ### When per-user pricing actually makes sense Per-user pricing is not a trick. There are configurations where it is straightforwardly the cheaper and simpler option, and it is worth being honest about them. - Asset-heavy, people-light operations are the wrong shape for it - but people-light, asset-light operations are fine. A workshop with 8 machines and 3 technicians will pay less per user. - Facilities and property maintenance, where the 'asset' is a building with hundreds of ambiguous line items, is easier to price per user than per asset. - Teams that deliberately want a closed system - where only trained planners touch the CMMS and operators report through a supervisor - are not paying for access they wanted anyway. - Free tiers with low user caps are a legitimate way to trial a tool before committing to any model. The decision rule is simple: divide your machine count by the number of people who would ideally have access. If that ratio is well below one - many more people than machines - per-user pricing deserves a serious look. If it is near or above one, per-machine pricing usually wins, and wins by more every year the headcount grows. ### Hidden costs to watch for in either model The headline rate is the part of the contract vendors compete on, which means it is rarely where the margin is. These are the line items worth pulling into the open before you sign. 1. **Seat minimums and annual commitments** — A $20/user/month rate with a 25-seat minimum is a $6,000 floor, whatever your actual usage. Ask what happens if you need 11 seats. 2. **Feature gating by tier** — Preventive maintenance scheduling, custom reports, API access, and mobile offline mode are common upsells. Price the tier that contains the features you actually need, not the entry tier. 3. **Storage and attachment overages** — Photo-heavy breakdown reporting produces a lot of data. Check whether image and document storage is metered, and at what rate. 4. **Onboarding and data migration** — Asset register import, historical work order migration, and training are frequently priced separately as a one-off, and can exceed a year of licensing. 5. **Integration and API limits** — If you need ERP or inventory integration, confirm whether the API is included, rate-limited, or an add-on tier. 6. **Read-only and light users** — Some vendors offer cheaper viewer seats. Confirm exactly what a viewer can and cannot do - if they cannot submit a breakdown report, the seat does not solve your access problem. > **Firmicore note:** Ask every vendor the same question: what does it cost to give a night-shift operator the ability to report a breakdown from the machine? The answer to that one question tells you more about the pricing model than the pricing page does. ### Frequently asked questions **Q: What is per-machine CMMS pricing?** A: Per-machine pricing charges based on the number of assets registered in the maintenance system rather than the number of user accounts. User access is unlimited, so the cost of the software tracks the size of your asset register instead of your headcount. **Q: Is per-machine pricing always cheaper than per-user pricing?** A: No. If you have far more users than machines - for example a facilities team maintaining a small number of large assets - per-user pricing can be cheaper. The rough test is your machine-to-user ratio: below one favours per-user, near or above one favours per-machine. **Q: How much does a CMMS cost per year?** A: It depends entirely on the model. Modelled at a $65/user/month list rate, 40 users costs roughly $31,200 a year. Entry tiers of most vendors start far lower but gate preventive maintenance scheduling and reporting features. Always price the tier that includes the features you need. **Q: Why do most CMMS vendors charge per user?** A: Per-user pricing is the default SaaS convention, and it is simple to meter. It fits categories where every user is a heavy user. Maintenance is different, because the most valuable data often comes from occasional users - operators reporting a breakdown once or twice a month. --- ## MaintainX Alternative: Why Manufacturers Are Switching to Per-Machine Pricing Source: https://firmicore.com/blog/maintainx-alternative/ Published: August 14, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Comparison MaintainX is one of the best-known names in maintenance software, and for good reason. This is a straight comparison of where it wins, where a per-machine alternative wins, and how to tell which side of the line your plant sits on. ### Key takeaways - MaintainX is genuinely strong on brand maturity, integration ecosystem, and its free tier - if those are your priorities, it is a reasonable choice. - Its pricing is per user, so cost scales with headcount. Plants that want every operator reporting breakdowns hit that wall first. - Firmicore's differentiators are per-machine pricing, guided operator triage during the wait for a technician, and multilingual floor-level interfaces. - Switch if you are rationing seats, running multilingual shifts, or need operators to act safely in the gap between breakdown and repair. - Do not switch if you depend on a specific MaintainX integration, or if your team is small enough that per-user pricing is cheaper. Comparison posts written by vendors are usually worthless, because they are written to reach a conclusion. This one tries to be useful instead: MaintainX is a capable product, we lose deals to it, and there are plants where it is the right answer. What follows is the actual decision framework - what each tool is built around, and which constraint decides it. ### Quick verdict: who should switch and who should not > **Switch to per-machine pricing if:** You have more machines than licensed users, you are deliberately limiting seats to control cost, your floor runs in more than one language, or you need operators to take guided safe actions before a technician arrives. > **Stay on MaintainX if:** You have a small fixed maintenance team and few assets, you rely on a specific MaintainX integration that has no equivalent elsewhere, or you are running successfully on the free tier and have not hit its limits. The rest of this post is the reasoning behind those two boxes. ### Feature-by-feature comparison The table below compares the dimensions that actually decide manufacturing deals. Vendor capabilities change - verify current behaviour in a trial rather than taking any comparison table, including this one, at face value. _Comparison focused on manufacturing use cases. Verify current vendor capabilities directly before deciding._ | Dimension | MaintainX | Firmicore | | --- | --- | --- | | Pricing model | Per user, per month, tiered | Per machine, unlimited users | | Cost of adding a shop-floor reporter | Another paid seat | No incremental licence cost | | Free tier | Yes, with feature limits | Free trial rather than a permanent free tier | | Guided operator triage | Not productised as a distinct workflow | Core workflow with per-machine safe-action flows | | Breakdown intake | Mobile app and work request forms | QR scan, WhatsApp, browser, and supervisor-mediated | | Contractor management | Supported | Supported, with document expiry and compliance blocking | | Localisation for floor staff | Multi-language interface | Multi-language including regional South Asian languages | | Integration ecosystem | Broad and mature | Narrower, growing | | Brand maturity | Established, large customer base | Newer entrant | ### Where MaintainX is genuinely better Three areas, and they are not small. - Maturity. MaintainX has been deployed at scale across many industries for years. Edge cases have been found and fixed. A newer product has not had that many chances to be wrong in public. - Integrations. If your requirement includes connecting to a specific ERP, procurement system, or sensor platform, MaintainX is more likely to already have that connector built. - The free tier. A permanently free plan with real functionality is an excellent way to start. If you are a two-person maintenance team getting off paper, that is a legitimate reason to start there. If any of those three is your binding constraint, this comparison is over and MaintainX is your answer. The interesting case is when none of them is. ### Where Firmicore wins 1. **Per-machine pricing removes the seat ceiling** — The most common failure mode we see in per-user deployments is deliberate under-licensing. Twelve seats get bought, operators report verbally to supervisors, and the machine history that justified the purchase never fills in. Per-machine pricing makes it free to add the fiftieth reporter. 2. **Guided operator triage covers the waiting gap** — Between the moment a machine stops and the moment a technician arrives, something happens - usually undocumented, sometimes unsafe. Firmicore turns that window into a guided sequence of safe, machine-specific actions with an audit trail. 3. **Multilingual floor interfaces, not just multilingual admin** — Reporting works in the language the operator speaks, including regional South Asian languages, while supervisors and managers work in English. This matters in plants where floor staff and management do not share a first language. 4. **Multiple intake channels including mobile-banned floors** — QR scan at the machine, WhatsApp for plants where that is already the habit, browser for shared terminals, and supervisor-mediated capture where personal phones are prohibited on the floor. ### Migration considerations Changing maintenance systems is not free, and anyone who tells you otherwise has not done it. Plan for these. 1. Export the asset register first. It is the backbone of everything else and the piece most likely to need cleaning before import. 2. Decide how much work order history you actually need to migrate. Most plants need one to two years for trend analysis, not everything. 3. Re-print QR codes if you are moving to machine-level scanning, and do it line by line rather than plant-wide in one weekend. 4. Run both systems in parallel for two to four weeks on one line before cutting over the rest of the plant. 5. Rebuild preventive maintenance schedules deliberately rather than importing them. Migration is the best chance you will get to delete the PM tasks nobody has done in a year. > **Firmicore note:** If you do trial both, use the same real breakdown on the same machine in each system, with the same operator. Feature lists compare badly; a single real incident compares well. ### Frequently asked questions **Q: What is the best MaintainX alternative for manufacturers?** A: It depends on your binding constraint. If it is cost as headcount grows, look for per-machine pricing. If it is integration coverage, MaintainX is hard to beat. If it is floor-level adoption in a multilingual plant, prioritise localisation and intake channels over feature count. **Q: How does MaintainX pricing work?** A: MaintainX prices per user, per month, across tiered plans with a free tier at the entry level. Cost therefore scales with how many people you give access to, not with how many assets you maintain. **Q: Is it hard to migrate from MaintainX to another CMMS?** A: The asset register and open work orders are the critical pieces and both export cleanly. The realistic effort is in data cleanup, re-labelling machines with new QR codes, and rebuilding preventive maintenance schedules - typically a few weeks of part-time work for a mid-sized plant. --- ## Cryotos Alternative: WhatsApp Breakdown Reporting Without the Per-User Trade-off Source: https://firmicore.com/blog/cryotos-alternative/ Published: August 7, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Comparison If you are evaluating Cryotos, you have probably already worked out that intake channel matters more than feature count. This compares the two platforms on the things that decide adoption on an actual factory floor. ### Key takeaways - WhatsApp intake works because it requires no new app, no login, and no training - operators already use it every day. - Cryotos covers WhatsApp reporting and a broad CMMS feature set, and it is priced per user. - Firmicore matches the WhatsApp intake channel, adds QR and supervisor-mediated capture for mobile-restricted floors, and prices per machine. - The clearest functional gap we have found is guided operator triage - a structured safe-action flow for the minutes between breakdown and technician arrival. - For plants with more machines than maintenance staff, the pricing model is usually the deciding factor rather than any single feature. Most maintenance software is designed on the assumption that a technician will open a purpose-built mobile app. On a lot of factory floors - especially across South Asia - that assumption breaks immediately. The app is not installed, the login is forgotten, and the breakdown gets reported by shouting down the line. Cryotos understood this and built WhatsApp into the intake path. That is a genuinely good decision and it is worth saying so before comparing anything. ### Why WhatsApp intake matters for factory floors The hardest problem in maintenance software is not scheduling or reporting. It is getting the first message into the system at all, quickly, from someone who is not paid to use software. - Zero install friction. The app is already on the phone and already logged in. - Zero training cost. Nobody needs to be taught how to send a photo on WhatsApp. - It survives shift churn. A new operator on their first night does not need an account provisioned before they can report a stopped machine. - Photos come for free, and a photo of the failure taken before the machine is cleaned is often the most valuable field in the whole record. The counterweight is that many plants ban personal phones on the floor - for safety, for contamination control, or for quality reasons. A WhatsApp-only strategy fails completely in those plants, which is why intake needs more than one channel. ### Cryotos vs Firmicore: feature comparison _Comparison as we understand the products at the time of writing. Verify current capabilities directly in a trial._ | Dimension | Cryotos | Firmicore | | --- | --- | --- | | Pricing model | Per user, per month | Per machine, unlimited users | | WhatsApp breakdown reporting | Yes | Yes | | QR-code reporting at the machine | Supported | Core intake path | | Supervisor-mediated capture for mobile-banned floors | Not a documented workflow | Built-in | | Guided operator safety triage | No productised equivalent found | Core workflow | | Regional language support | Multi-language | Multi-language including regional South Asian languages | | Preventive maintenance scheduling | Yes | Yes | | Contractor management | Yes | Yes, with document expiry blocking | > **On the triage row:** We describe this as 'no productised equivalent found' rather than 'not available' deliberately. It reflects our review of public documentation, not access to an internal roadmap. If you are evaluating, ask the vendor directly. ### What Cryotos does well - A broad, conventional CMMS feature set covering work orders, preventive maintenance, assets, and inventory. - WhatsApp intake, which puts it ahead of most global vendors on the specific problem of getting reports started. - Regional presence and support in markets where many CMMS vendors have no local footprint at all. - An established customer base, which means the product has been through real deployments rather than only demos. If your evaluation comes down to WhatsApp intake plus standard CMMS coverage, and your user count is small, Cryotos is a sensible shortlist entry. ### Where Firmicore differentiates 1. **Guided operator triage** — A structured, machine-specific sequence the operator is walked through while waiting: isolate, verify, capture evidence, and record what was and was not attempted. It turns an undocumented gap into an auditable step. 2. **Intake that survives a phone ban** — WhatsApp when phones are allowed, QR scan from a shared floor tablet when they are not, and supervisor-mediated capture where even shared devices are restricted to a station. 3. **Per-machine pricing** — If the point of WhatsApp intake is that anyone can report, then charging per user works against the reason you chose WhatsApp intake in the first place. Per-machine pricing keeps the two consistent. The strategic argument is simple. Low-friction intake and per-user pricing pull in opposite directions. Any tool that solves intake properly should not then meter the people using it. ### Frequently asked questions **Q: Can you report a machine breakdown through WhatsApp?** A: Yes. Several maintenance platforms, including Cryotos and Firmicore, accept breakdown reports through a WhatsApp bot that captures the machine, a description, and a photo, then creates a work order in the CMMS automatically. **Q: What happens if personal phones are banned on the factory floor?** A: WhatsApp intake alone will not work. You need a shared-device path - a wall-mounted or handheld tablet with QR scanning at each machine - or a supervisor-mediated flow where the operator reports verbally and the supervisor captures the structured record. **Q: Is Cryotos or Firmicore cheaper?** A: It depends on the ratio of machines to users. Cryotos prices per user and Firmicore prices per machine, so plants with many operators relative to assets favour per-machine pricing, while small teams with few assets may find per-user cheaper. --- ## SAP Plant Maintenance Alternative for Factories That Don't Need a Full ERP Source: https://firmicore.com/blog/sap-plant-maintenance-alternative/ Published: July 31, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Comparison SAP Plant Maintenance is a module inside an ERP system of record. A CMMS is a floor-operations tool. They solve different problems, and confusing the two is how factories end up with a nine-month implementation for a job that needed three weeks. ### Key takeaways - SAP PM is part of the broader SAP ERP and S/4HANA suite. It is not sold or deployed as a standalone maintenance product. - Its licensing and implementation costs are shaped by that ERP context - systems-integrator involvement is the norm, not the exception. - For a single factory with no existing SAP footprint, the cost and timeline are frequently disproportionate to a maintenance-only requirement. - SAP PM is the right call when you already run SAP for finance and procurement and want one system of record across the business. - A purpose-built CMMS trades cross-module ERP consistency for floor-level speed: mobile-first technicians, QR reporting, and go-live in weeks. We meet this objection regularly in Sri Lanka: a group runs SAP for finance and procurement, and someone has proposed extending it into maintenance. The question on the table is whether the plant should adopt SAP PM or a dedicated CMMS. It is a fair question with a genuinely context-dependent answer, and it deserves better than a sales pitch. What follows is the comparison we would give if we were not selling anything - including the cases where SAP PM is clearly correct. ### What SAP Plant Maintenance actually is SAP Plant Maintenance is a functional module within SAP ERP, and its successor functionality sits inside S/4HANA Asset Management. It handles equipment master data, maintenance orders, notifications, task lists, and maintenance planning - and it does so in tight integration with materials management, procurement, controlling, and finance. That integration is the point of the product. A maintenance order in SAP PM is not just a repair record; it is a cost object that flows into controlling, consumes stock through materials management, and can trigger procurement. If your accounting team wants maintenance spend to reconcile automatically against plant cost centres, this is the architecture that gets you there. - It is a module, not a standalone product. You do not buy SAP PM without the surrounding SAP landscape. - The typical buyer is a large, multi-site enterprise with an existing SAP finance and procurement footprint. - Implementation is normally delivered through a systems integrator rather than self-service configuration. - Configuration decisions are shared with other modules, so maintenance rarely gets to move independently. ### The real cost of SAP PM for a maintenance-only need Enterprise ERP licensing is negotiated, bundled, and confidential, so nobody can honestly quote you a number in a blog post. What can be described is the cost structure, which is where the surprises live. 1. **Licensing is tied to the ERP contract** — Maintenance module access is negotiated as part of a broader SAP agreement, typically involving named users and engine or usage metrics. It is not priced as a maintenance-specific subscription you can size against your asset count. 2. **Implementation is a project, not a signup** — Equipment master data structures, functional locations, order types, and planning strategies all need to be designed before anything goes live. That work is normally scoped in months and delivered with external consultants. 3. **Systems-integrator cost is often the largest line** — In enterprise ERP projects it is common for services to equal or exceed first-year licence cost. Budget for the integrator, not just the software. 4. **Change requests have ERP-wide blast radius** — Adding a field to a maintenance notification is a change to a shared system with its own governance and testing cycle. The cost is process, not code. _Typical elapsed time to first productive use (illustrative ranges, not vendor commitments)_ - SAP PM greenfield module rollout: 6-12 months - SAP PM extension to an existing SAP landscape: 3-6 months - Mobile-first CMMS pilot on one line: 1-3 weeks - Mobile-first CMMS plant-wide rollout: 4-8 weeks _Ranges reflect commonly reported implementation patterns rather than a specific quoted project. Your figures will vary with scope, data quality, and integrator._ ### What you lose by using SAP PM for factory-floor maintenance SAP PM was designed for asset accounting rigour and cross-module consistency. Those are real virtues. They are also not the qualities that make an operator report a stopped machine within thirty seconds. - No mobile-first technician experience by default. Mobile access typically requires additional SAP mobile products or a third-party front end - another project, another licence line. - No guided operator triage. There is no built-in concept of walking a machine operator through safe actions while they wait for a technician. - No QR-code or WhatsApp intake out of the box. Reporting is designed around a notification created by trained users, not a scan at the machine. - Terminology and screens built for planners. Functional locations, order types, and task lists are precise and powerful, and they are not what a line operator on a night shift will navigate. - Configuration speed. Adding a new machine type with its own checklist is a governed change, not a five-minute admin task. > **The honest framing:** These are not defects. SAP PM is not trying to be a floor-reporting tool, in the same way a CMMS is not trying to close your month-end. The mistake is expecting either one to do the other's job. ### When SAP PM is genuinely the right call There are three situations where we would tell a plant to use SAP PM, and we have said so in real conversations. 1. You already run SAP for finance and procurement, and a single system of record is a stated corporate requirement. Fighting that policy to save a maintenance subscription is a bad trade. 2. You are a multi-site enterprise with dedicated IT and integrator resources. The implementation cost is amortised across sites, and you have the internal capability to own it. 3. Deep integration with SAP inventory and procurement is a hard requirement - for example, maintenance orders must reserve stock and raise purchase requisitions automatically, with full controlling traceability. Note what these have in common: the driver is enterprise architecture, not maintenance workflow. If your reason for considering SAP PM is any of the three above, that is a sound reason. ### What a purpose-built CMMS gets you instead _Different tools, different design centres._ | Dimension | SAP Plant Maintenance | Purpose-built CMMS | | --- | --- | --- | | Design centre | ERP system of record | Floor operations | | Primary user | Maintenance planner | Operator, technician, supervisor | | Time to first productive use | Months | Days to weeks | | Pricing basis | Enterprise ERP licensing | Per machine or per user subscription | | Breakdown intake | Notification created by trained users | QR scan, WhatsApp, browser, supervisor-mediated | | Finance integration | Native across modules | Via export or API | | Change to a checklist | Governed change request | Admin edit | - Mobile-first technician and supervisor experience, designed for gloves, glare, and patchy plant Wi-Fi. - Per-machine pricing that maps to your asset register rather than to an enterprise licence negotiation. - Live in days or weeks. The pilot is one line, one week, and you find out whether operators actually report before you commit the plant. - Integration where you need it rather than everywhere: push completed work orders and parts consumption to finance via API, and leave the rest alone. ### How to decide, in one question Ask what problem is actually being solved. If the answer is 'maintenance spend must reconcile automatically inside our corporate system of record', that is an ERP answer and SAP PM is the direction. If the answer is 'we do not know why line three keeps stopping and nobody writes anything down', that is an operations answer, and no amount of ERP will fix it - the data has to start at the machine. Plenty of groups run both, deliberately: the CMMS captures floor reality at speed, and a scheduled export pushes cost and consumption into the ERP. That is a perfectly respectable architecture, and it is usually cheaper than forcing either tool to do both jobs. ### Frequently asked questions **Q: What is the difference between SAP PM and a CMMS?** A: SAP Plant Maintenance is a module inside the SAP ERP suite, designed for asset accounting rigour and integration with finance, procurement, and materials management. A CMMS is a standalone maintenance application designed around floor operations - reporting, work orders, and technician workflow. They overlap in function but differ in design centre, cost structure, and implementation time. **Q: Do I need SAP for maintenance management?** A: Only if a single enterprise system of record is a requirement, or if maintenance must integrate natively with SAP inventory, procurement, and controlling. A standalone factory with no existing SAP footprint generally does not need it for maintenance alone. **Q: Is SAP PM overkill for a single factory?** A: Usually, if the factory has no existing SAP landscape. The implementation effort and licensing structure are designed for multi-site enterprises with dedicated IT resources. A single site with a maintenance-only requirement typically reaches productive use far faster with a purpose-built CMMS. **Q: Can a CMMS integrate with SAP?** A: Yes, commonly through API or scheduled export - pushing completed work orders, parts consumption, and cost data into the ERP while the CMMS remains the system of engagement on the floor. This hybrid pattern is widely used and avoids duplicating either system's strengths. --- ## How to Report a Machine Breakdown: From Paper Logs to QR Code Reporting Source: https://firmicore.com/blog/how-to-report-a-machine-breakdown/ Published: July 24, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Guides Most maintenance data problems are not analysis problems. They are intake problems. This is a practical guide to the five ways breakdowns get reported, what a good report captures, and how to make it work on floors where phones are banned. ### Key takeaways - A good breakdown report captures machine, timestamp, reporter, symptom, severity, and a photo - in under a minute, at the machine. - Paper logs and verbal reports fail on timestamp accuracy and audit trail, which makes MTTR and root-cause analysis unreliable. - QR-code reporting works because the machine identity is scanned rather than typed, eliminating the most common data error. - On floors where personal phones are prohibited, supervisor-mediated reporting from a shared station preserves the structured record. - Once intake is digital, MTTR, failure frequency by machine, and parts consumption become measurable rather than anecdotal. Ask a plant manager what their mean time to repair is and you will usually get a number. Ask where that number comes from and the answer is often a spreadsheet built from a logbook filled in at the end of a shift, from memory. The problem is not the analysis. It is that the first record - the moment someone noticed the machine had stopped - was never captured accurately. Everything downstream inherits that error. ### Why paper and verbal breakdown reporting fails Paper logs are not stupid. They are fast, they survive power cuts, and everybody understands them. They fail for structural reasons that no amount of discipline fixes. - Timestamps are reconstructed, not recorded. A log filled in at shift end contains estimates, and the estimate is always rounder and later than reality. - Machine identity is typed or written, so the same asset appears three different ways and machine-level trends never emerge. - There is no evidence. By the time anyone investigates, the machine has been cleaned, restarted, and the visual clue is gone. - There is no audit trail. Nobody can show who reported what, when, and what was done in response - which matters as soon as a safety incident or a customer audit occurs. - The handoff is lossy. Verbal reporting through a supervisor drops detail with every retelling, and detail is precisely what root-cause analysis needs. The cost is not the paper. It is that six months later you cannot answer a simple question: which machine cost us the most downtime, and why. ### The five common breakdown-reporting channels _Each channel has a floor condition it suits. Most plants need two._ | Channel | Best for | Main weakness | | --- | --- | --- | | QR scan at the machine | Plants where a device is available at or near the machine | Requires labels to be printed, mounted, and kept legible | | WhatsApp bot | Floors where personal phones are allowed and already used | Fails entirely where phones are prohibited | | Browser form on a shared terminal | Line-end stations and control rooms | The walk to the terminal delays the report | | Supervisor-mediated capture | Mobile-banned and contamination-controlled floors | Depends on supervisor availability at the moment of failure | | Automated IoT or sensor trigger | High-value assets with existing instrumentation | Detects the stop, not the reason - a human still has to describe it | > **Firmicore note:** Do not pick one channel and mandate it. Pick the primary channel your floor conditions allow, then add one fallback for when it is unavailable. Reports that cannot be filed do not become delayed reports - they become no reports. ### Step by step: what a good digital breakdown report captures The target is a complete structured record in under sixty seconds. Anything longer and reporting quality degrades during exactly the incidents you most want documented. 1. **1. Identify the machine without typing** — Scan the QR label. The asset, line, and location are attached automatically, and the single largest source of data error - a mistyped or invented machine name - disappears. 2. **2. Stamp the time automatically** — The report time is recorded by the system, not entered by the reporter. This is what makes response time measurable later. 3. **3. Capture the symptom in the reporter's own language** — A short structured symptom list plus a free-text field, available in the operator's own language. Do not force a diagnosis at this stage - the operator knows what they saw, not what failed. 4. **4. Take a photo before anything is touched** — One photo of the failure state is worth more than a paragraph written afterwards. Make it a prompt, not an optional extra field at the bottom. 5. **5. Set severity against a shared definition** — Three levels are enough - line stopped, degraded output, safe to run until scheduled. Publish the definitions so severity means the same thing on every shift. 6. **6. Record who reported it** — Not to assign blame, but because the technician arriving in eight minutes needs to know who to ask what happened. - **6** — fields for a complete report - **<60s** — target time to submit - **1** — photo before the machine is touched - **0** — typed machine names ### Supervisor-mediated reporting for mobile-banned floors This is the case most maintenance software ignores, and it is common: food and pharmaceutical production areas, plants with contamination controls, and sites where personal phones are prohibited for safety or quality reasons. The usual advice - 'just give everyone the mobile app' - is not available. What works instead is a deliberate two-step flow that keeps the structured record without putting a device in the operator's hand. 1. The operator raises the breakdown verbally or with a physical signal, exactly as they do today. Nothing changes at the point of failure. 2. The supervisor captures the structured record at a shared floor station or handheld device, with the operator present and named as the reporter. 3. The report is timestamped at capture, and the delay between failure and capture is itself recorded rather than hidden - so you can see how much of your response time is intake lag. 4. The photo is taken by the supervisor's shared device, which is permitted on the floor where personal phones are not. > **Why the intake lag field matters:** If you do not measure the gap between failure and report, every improvement you make to technician response time will be invisible - because the reporting delay dominates and nobody is looking at it. ### What changes downstream once reporting is digital Digital intake is not an end in itself. It is what makes the following possible, none of which is reliably available from a logbook. - MTTR becomes real, because both the start and end timestamps are system-recorded rather than remembered. - Response time separates from repair time, which turns a vague 'maintenance is slow' complaint into a specific staffing or routing question. - Failure frequency per machine emerges, because every report is attached to a scanned asset rather than a typed name. - Root cause analysis has evidence - photos, symptom descriptions, and what the operator had already tried. - Parts consumption ties to specific assets, which makes spares stocking a calculation instead of a guess. The sequence matters. Plants that buy analytics before fixing intake end up with dashboards built on reconstructed data, which is worse than no dashboard because it looks authoritative. ### Frequently asked questions **Q: How do you report a machine breakdown properly?** A: Capture six things at the machine, in under a minute: the machine identity (scanned, not typed), an automatic timestamp, the symptom in the reporter's own words, a photo of the failure state before anything is touched, a severity level against published definitions, and the reporter's name. **Q: What is QR code machine reporting?** A: Each machine carries a printed QR label. Scanning it opens a pre-filled breakdown report already attached to that asset, so the reporter only describes the symptom. It removes machine-identification errors and cuts reporting time to well under a minute. **Q: How do you digitise breakdown reporting when phones are banned on the floor?** A: Use supervisor-mediated capture from a shared, permitted device. The operator reports verbally as they do today, the supervisor records the structured report with the operator named as reporter, and the system logs the intake delay separately so it stays visible. --- ## What Is a CMMS? The Complete Guide for Manufacturing Teams Source: https://firmicore.com/blog/what-is-a-cmms/ Published: July 17, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Guides Everything a manufacturing team needs to understand before evaluating maintenance software: what a CMMS is, what the core modules actually do, how it differs from EAM and ERP maintenance modules, and how to evaluate one without being sold to. ### Key takeaways - CMMS stands for computerised maintenance management system: software that records assets, work orders, preventive maintenance schedules, and parts. - The four core modules are the asset registry, work order management, preventive maintenance scheduling, and inventory - and they only produce value when connected. - A CMMS is a maintenance operations tool. EAM extends across the whole asset lifecycle; an ERP maintenance module is a component of a corporate system of record. - Pricing models differ fundamentally: per-user pricing scales with headcount, per-machine pricing scales with your asset register. - The strongest signal that you need one is not company size - it is that nobody can answer which machine cost you the most downtime last quarter. This is the hub page for everything else we write about maintenance software. If you are new to the category, start here; the linked posts go deeper on each piece. ### What CMMS stands for and what it does CMMS stands for computerised maintenance management system. It is software that keeps a structured record of the physical assets you maintain, the work done on them, the schedule of work planned, and the parts consumed doing it. That definition sounds administrative, and the administrative framing is why so many implementations fail. The useful way to think about a CMMS is as an operating loop: something breaks or is due, the work gets routed to someone, the work gets done and recorded, and the record changes what happens next time. A CMMS that only files records is a filing cabinet with a subscription fee. > **The test that matters:** A CMMS is working if the answer to 'which machine failed most often last quarter, and what did it cost us' takes thirty seconds and does not require anyone's memory. ### Core CMMS modules explained 1. **Asset registry** — The list of what you maintain, with hierarchy: plant, line, machine, and component. Every other record attaches to this, which is why an inconsistent asset register poisons every report you will ever run. Get this right first, even if it is boring. 2. **Work order management** — The record of work: what needs doing, who it is assigned to, what state it is in, what was actually done, and how long it took. Breakdown reports, preventive tasks, and inspections all become work orders so they can be tracked in one place. 3. **Preventive maintenance scheduling** — Rules that generate work before failure - either calendar-based (every 90 days) or meter-based (every 5,000 running hours). The scheduling engine is what turns maintenance from reactive to planned. 4. **Inventory and spare parts** — Stock levels, reorder points, and consumption tied to specific work orders and machines. Because consumption is linked to assets, stocking decisions stop being guesses about what might be needed. Most vendors add reporting, contractor management, and mobile access on top. Those matter, but they are downstream: none of them produce reliable output unless the four modules above are connected and the asset registry is clean. ### CMMS vs EAM vs ERP maintenance modules These three categories overlap enough that vendors use the terms loosely. The practical difference is scope and design centre. _Three categories, three different design centres._ | | CMMS | EAM | ERP maintenance module | | --- | --- | --- | --- | | Scope | Maintenance operations | Full asset lifecycle including acquisition and disposal | Maintenance as one module in a corporate system of record | | Primary user | Technicians, supervisors, operators | Asset managers and reliability engineers | Maintenance planners working inside the ERP | | Typical buyer | Single plant or small group | Asset-intensive enterprise | Company already committed to the ERP suite | | Time to value | Days to weeks | Months | Months, with integrator involvement | | Strength | Floor-level speed and adoption | Lifecycle cost and reliability analysis | Native finance and procurement integration | If your company already runs SAP for finance and procurement, the ERP-module option deserves genuine consideration and the trade-offs are covered in detail in our SAP Plant Maintenance comparison. If your problem is that nobody records breakdowns properly, none of the three fixes that by itself - but a CMMS is the only one designed around trying. ### How CMMS pricing models differ Pricing is not a commercial detail in this category. It shapes who is allowed to use the system, which shapes the quality of the data, which determines whether the software works at all. - Per-user pricing charges per named account per month. Cost scales with headcount. It is the market default and it creates a direct financial incentive to limit how many people can report a breakdown. - Per-machine pricing charges by registered asset, with unlimited users. Cost scales with the asset register - the thing maintenance work is actually attached to - and makes floor-wide reporting economically free. - Tiered feature gating cuts across both. Preventive maintenance scheduling, API access, and custom reporting are frequently reserved for higher tiers, so always price the tier that contains the features you need. - One-off costs - onboarding, data migration, training - are commonly quoted separately and can exceed the first year of licensing. The full worked comparison across three factory sizes is in our post on per-machine versus per-user CMMS pricing. ### Who needs a CMMS Company size is a weak signal. These are stronger ones. - You cannot say which machine caused the most downtime last quarter without asking someone to remember. - Preventive maintenance exists as a schedule on a wall or in a spreadsheet, and compliance against it is not measured. - Spare parts are stocked by intuition, and you have both stockouts and dead stock at the same time. - Breakdown reports arrive verbally and get written down later, if at all. - You are being asked for maintenance records by a customer audit or a regulator and assembling them is a project. - The same failure keeps recurring and nobody can prove it, because each instance was recorded differently. Two or more of those and the question is no longer whether to adopt a CMMS - it is which constraints on your floor decide the choice. ### How to evaluate a CMMS: a buyer's checklist Feature-list comparisons reward the vendor with the longest feature list, which is not the same as the best fit. Evaluate against your floor conditions instead. 1. How does a breakdown get reported on your floor specifically - including on the night shift, in the area where phones are banned, by an operator who does not read English? 2. What does it cost to give one more person the ability to report? If the answer is a paid seat, model that cost at full plant adoption before you sign. 3. How long from contract to a real work order closed on a real machine? Ask for a one-line pilot, not a demo. 4. Can you change a preventive maintenance checklist yourself, or does it require a support ticket? 5. Does the mobile experience work offline? Plant Wi-Fi coverage is worse than the site survey claims. 6. How does data get out? Confirm export and API access on your tier, so the asset history stays portable. 7. What does the audit trail look like - who reported, who acknowledged, who repaired, with system timestamps rather than typed ones? 8. Does the pricing model still make sense in three years at your projected headcount and machine count? > **Firmicore note:** Run the trial on your worst line, not your best one. The line that fails often will tell you in a week whether the tool fits; the well-behaved line will tell you nothing for a month. ### Frequently asked questions **Q: What does CMMS stand for?** A: CMMS stands for computerised maintenance management system - software that records maintenance assets, work orders, preventive maintenance schedules, and spare parts consumption in one connected system. **Q: What is the difference between a CMMS and an EAM?** A: A CMMS focuses on maintenance operations: work orders, schedules, and repairs. An EAM (enterprise asset management) system covers the full asset lifecycle including acquisition, depreciation, and disposal, and is typically bought by asset-intensive enterprises. **Q: How much does a CMMS cost?** A: It depends on the pricing model. Per-user vendors charge per account per month, so cost scales with headcount; per-machine vendors charge by registered asset with unlimited users. Entry tiers are cheap but commonly gate preventive maintenance scheduling and reporting, so price the tier that contains what you need. **Q: Do small factories need a CMMS?** A: Size is a weak indicator. The stronger signal is whether you can answer basic maintenance questions - which machine failed most, what it cost, whether PM was done - without relying on someone's memory. If you cannot, a CMMS pays for itself regardless of headcount. --- ## Work Order Software: What It Is and How to Choose One Source: https://firmicore.com/blog/work-order-software/ Published: July 10, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Guides Work order software is where maintenance intent becomes maintenance record. This covers the eight work order types every plant deals with, what a complete lifecycle looks like, and the features that decide whether technicians actually use the thing. ### Key takeaways - A work order is the record of a specific piece of maintenance work: what, where, who, when, and what was actually done. - Paper work orders fail at the handoff and the close-out, which is exactly where the data you need for analysis lives. - Most plants deal with eight distinct work order types, and treating them identically is what makes reporting useless. - A complete lifecycle is creation, assignment, acknowledgement, execution, close-out, and sign-off - skipping acknowledgement is the most common gap. - The single best feature test: can a technician close a work order properly with gloves on, in poor light, with no signal? The work order is the unit of account in maintenance. Everything you eventually want to measure - response time, repair time, cost per asset, PM compliance - is derived from work order records. If the work order is sloppy, no dashboard rescues it. ### What a work order is and why paper tracking breaks down A work order is an instruction plus a record. It says what needs doing, on which asset, by whom, by when - and then it captures what was actually done, how long it took, and what was consumed doing it. Paper handles the instruction half acceptably. It fails on the record half, and it fails predictably. - The close-out is written at the end of the shift, so duration is an estimate and detail is thin. - Parts used are recorded on the store issue slip, not the work order, so consumption never links to the asset. - The paper travels with the technician, which means status is unknowable until it comes back. - Nothing prevents two people being dispatched to the same fault, or a fault sitting unassigned for an hour. - Historical search is manual. 'Has this happened before on this machine?' is a filing exercise nobody performs mid-breakdown. ### The eight common work order types These deserve separate types because they have different urgency, different approval paths, and different meaning in reporting. Lumping them together is why 'we closed 340 work orders' tells you nothing. _Eight types, and what each one is for._ | Type | Trigger | Typical urgency | | --- | --- | --- | | Breakdown / reactive | Asset has failed and stopped production | Immediate | | Corrective | Fault found during inspection, asset still running | Scheduled soon | | Preventive | Calendar or meter schedule reached | Planned | | Predictive / condition-based | Sensor or inspection reading crosses threshold | Planned, urgent if trending | | Inspection | Routine check with no work expected | Planned | | Installation / commissioning | New asset or modification | Project-scheduled | | Safety / compliance | Regulatory requirement or safety finding | Fixed deadline, non-negotiable | | Contractor / external | Work assigned outside the in-house team | Varies, needs document checks first | > **Why the split matters:** The single most useful maintenance ratio is planned versus reactive work. You cannot compute it unless breakdown and preventive orders are distinct types from the moment they are created. ### What a complete work order lifecycle looks like 1. **1. Creation** — From a breakdown report, a PM schedule, or an inspection finding. The asset is attached at creation - not typed in later - and the timestamp is system-generated. 2. **2. Assignment** — Routed to a person or a trade group, with priority set against published severity definitions rather than whoever shouted loudest. 3. **3. Acknowledgement** — The technician confirms they have picked it up. This is the step most plants skip, and it is the one that separates 'nobody responded' from 'the repair was hard' when response times are poor. 4. **4. Execution** — Work is done, with parts issued against the order, notes captured, and photos attached. Offline capability matters here more than anywhere else in the system. 5. **5. Close-out** — Root cause and resolution recorded against a controlled list, plus free text. Duration is derived from timestamps, not entered by hand. 6. **6. Sign-off** — Supervisor or production confirms the asset is back in service. For safety and compliance orders this step is the audit evidence. - **6** — lifecycle stages - **2** — timestamps that define response time - **1** — asset attached at creation - **0** — hand-entered durations ### Features to evaluate in work order software 1. Offline mode that genuinely queues and syncs, tested in the worst-covered part of your plant rather than in the office. 2. Distinct work order types with separate reporting, not a single free-text category field. 3. Parts issue against the work order, so consumption links to the asset without a separate stores process. 4. Photo capture at both creation and close-out, because before-and-after is the cheapest root-cause evidence available. 5. Controlled root-cause and resolution lists - free text alone cannot be aggregated, and aggregation is the whole point. 6. Assignment to trade groups as well as individuals, so work does not stall when one person is on leave. 7. Acknowledgement as a distinct state with its own timestamp. 8. Contractor access without a paid seat or an app install, if you use external technicians. 9. Export and API access on the tier you are buying, not two tiers up. ### How work orders should feed machine history and analytics A work order system that only shows open work is a task list. The value appears when closed orders accumulate against assets and start answering questions. - Failure frequency per machine, which is what identifies the assets worth investing in rather than repairing repeatedly. - Planned versus reactive ratio, tracked over time - the clearest single indicator of whether maintenance is gaining or losing control. - Mean time to repair and mean time between failures per asset, both derived from work order timestamps. - Parts consumption by asset, which turns spares stocking from intuition into a reorder calculation. - PM compliance, measured as preventive orders completed on schedule rather than eventually. None of this requires an analytics product. It requires that every work order attaches to a real asset, carries a real type, and closes with system timestamps. Get that right and the reporting is arithmetic. ### Frequently asked questions **Q: What is work order software?** A: Work order software creates, assigns, tracks, and closes maintenance jobs against specific assets. It records who did what, when, how long it took, and which parts were consumed, so that maintenance history and metrics build up automatically. **Q: What is the difference between a work order and a work request?** A: A work request is a report that something needs attention - typically raised by an operator or production. A work order is the approved, assigned job created from it. Keeping them separate lets you measure how long requests wait before becoming assigned work. **Q: What are the main types of work orders?** A: Eight are common in manufacturing: breakdown, corrective, preventive, predictive, inspection, installation, safety or compliance, and contractor work orders. Keeping them as distinct types is what makes the planned-versus-reactive ratio measurable. --- ## How to Reduce Machine Downtime: A Practical Guide for Plant Managers Source: https://firmicore.com/blog/how-to-reduce-machine-downtime/ Published: July 3, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Operations Reducing downtime is not one problem. It is five sequential delays - report, acknowledge, assign, repair, resolve - and the repair segment is usually not the longest one. This guide covers what to measure and which levers move first. ### Key takeaways - Downtime cost is dominated by lost output, overtime, scrap, and late orders - not by the repair invoice. - The downtime clock has five segments: report, acknowledge, assign, repair, resolve. Most improvement effort targets repair, which is often not the longest. - MTTR is the metric that matters most, but only if it is measured from failure to resolution rather than from the technician arriving. - The fastest-payback levers are usually reporting delay and parts availability, not technician skill. - Track the planned-versus-reactive work ratio over time - it is the clearest indicator of whether you are gaining control or losing it. Every plant manager has been asked to reduce downtime, and most respond by pressing the maintenance team to work faster. That is the wrong end of the problem, because the technician is usually not the bottleneck. The productive approach is to break the stoppage into measurable segments, find out which one is long, and fix that. Usually the answer surprises people. ### The real cost of downtime, beyond the repair bill The maintenance invoice is the smallest and most visible component. It is visible because it arrives as a document with a number on it. The larger components are distributed across other departments and never get consolidated. - Lost contribution margin on the output that was not produced, which for a constrained line is the whole margin, not the variable cost. - Overtime and weekend running to recover the schedule, at premium rates. - Scrap and rework from the ramp-down and ramp-up around the stoppage, which is often larger than the scrap during normal running. - Expedited freight and late-delivery penalties when the order still has to ship on time. - Supervisor and management attention diverted into recovery, which has a real cost even though nobody invoices for it. - Customer confidence, which is not quantifiable in a single incident and is entirely quantifiable across a year of them. > **A useful exercise:** Pick your worst stoppage from last quarter. Add up all six categories above with the relevant department heads in the room. The gap between that number and the maintenance invoice is the argument for everything else in this post. ### What MTTR is and why it is the metric that matters most Mean time to repair is the average elapsed time from failure to the asset being back in service, across a set of incidents. It is the metric that matters most because it is the one that directly converts into lost production hours. The common measurement error is starting the clock when the technician arrives. That measures the repair, not the downtime, and it hides the segments where the delay usually is. Measure from the failure, and separate the segments so you can see which one to attack. A full definition, the formula, and how MTTR relates to MTBF and MTTA are covered in the companion post on MTTR. _Illustrative distribution of a two-hour stoppage across the five segments_ - Report (failure to logged): 25 min - Acknowledge (logged to accepted): 15 min - Assign and travel: 20 min - Repair (including parts wait): 50 min - Resolve and restart: 10 min _Proportions vary by plant. The point is to measure your own distribution rather than assume the repair segment dominates - in plants without digital reporting, it usually does not._ ### Six practical levers to reduce downtime 1. **1. Cut the reporting delay** — The cheapest minutes available. QR-code or WhatsApp reporting at the machine removes the walk to the supervisor and the wait for someone to be free. This lever needs no new headcount and no new parts budget - it is the first one to pull. 2. **2. Make acknowledgement explicit** — If nobody has to accept a job, nobody owns it. An acknowledgement step with its own timestamp turns 'maintenance is slow' into a specific, addressable number - and the act of measuring it usually shortens it. 3. **3. Give operators guided triage** — Between the report and the technician arriving, the operator is standing there. Guided safe actions - isolate, verify, capture evidence - shorten the repair when the technician arrives with a photo and a symptom already recorded, and prevent the unsafe improvisation that happens in unmanaged gaps. 4. **4. Fix parts availability** — A repair that waits four hours for a bearing is a stores problem, not a maintenance problem. Linking parts consumption to assets through work orders makes critical-spares stocking a calculation rather than an argument. 5. **5. Raise PM compliance before adding PM tasks** — Most plants have more preventive tasks defined than they complete. Adding more does nothing. Measure completion on schedule, cut the tasks nobody does and nobody misses, and get compliance high on the remainder. 6. **6. Close the root-cause loop** — Recurring failures are the cheapest downtime to eliminate, because you have already paid for the diagnosis several times. This only works if each instance is recorded against the same asset with a controlled cause code - free text cannot be aggregated. ### How digital tools shrink each stage of the downtime clock _Which capability addresses which segment of the clock._ | Segment | What causes the delay | What shortens it | | --- | --- | --- | | Report | Finding a supervisor, waiting for a form | QR scan or WhatsApp intake at the machine | | Acknowledge | No owner, no notification | Push routing with an explicit acceptance step | | Assign | Wrong trade dispatched, no context | Symptom, photo, and machine history attached to the order | | Repair | Parts wait, missing history, unclear cause | Asset-linked spares data and searchable machine history | | Resolve | Restart approval, no sign-off path | Structured close-out with supervisor sign-off | Note that only one row is about the repair itself. This is the reason plants that invest solely in maintenance skills and tooling see smaller gains than expected: they optimised the segment that was already the best managed. ### Benchmarks worth tracking Published industry benchmarks are close to useless for a specific plant - the definitions differ, the asset mixes differ, and the incentive to report favourably is strong. Benchmark against your own baseline instead, and track these five. - MTTR by asset class, measured failure to resolution, trended monthly. - Reporting delay as a distinct number, so improvements in intake are visible. - Planned versus reactive work ratio, trended over quarters rather than months. - PM compliance: preventive orders completed within their scheduled window, as a percentage. - Repeat failure rate: the share of breakdowns on assets that already failed for the same cause in the last 90 days. > **Firmicore note:** Set the baseline before you change anything, even if the baseline data is poor. A poor baseline you can improve on beats a clean baseline you started collecting after the improvement. ### Frequently asked questions **Q: How can a factory reduce unplanned machine downtime?** A: Break the stoppage into five segments - report, acknowledge, assign, repair, resolve - and measure each. In most plants the reporting and acknowledgement segments are the longest and the cheapest to fix, through machine-level digital reporting and an explicit acceptance step. **Q: What causes machine downtime?** A: Component failure is only the trigger. The duration is usually driven by delays around the repair: time before the failure is reported, time before anyone accepts the job, dispatch of the wrong trade, and waiting for spare parts. **Q: What is a good MTTR for manufacturing?** A: There is no useful universal figure, because definitions and asset mixes vary too much for cross-plant comparison to mean anything. Benchmark against your own baseline by asset class and track the trend rather than chasing a published number. --- ## What Is Preventive Maintenance? A Beginner's Guide Source: https://firmicore.com/blog/what-is-preventive-maintenance/ Published: June 26, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Guides Definitions, the difference between calendar-based and meter-based schedules, how to build a checklist that technicians will actually complete, and a realistic first 90 days. ### Key takeaways - Preventive maintenance is scheduled work performed before failure, triggered by calendar date or by usage such as running hours or cycles. - Reactive maintenance responds after failure; predictive maintenance responds to a measured condition trend. Most plants need all three, in different proportions. - Meter-based scheduling suits assets whose wear tracks usage; calendar-based suits time-driven degradation such as lubricant ageing or seasonal contamination. - A PM checklist that cannot be completed in the scheduled window will not be completed at all - fewer, better tasks beat comprehensive ones. - PM compliance, not PM coverage, is the number that correlates with fewer breakdowns. Preventive maintenance is one of the few areas of plant operations where the theory is genuinely simple and the practice genuinely difficult. Nobody disagrees that servicing a machine before it fails is better than after. Everybody has a preventive schedule. Very few plants complete it. ### Preventive vs reactive vs predictive maintenance _Three strategies, distinguished by what triggers the work._ | Strategy | Trigger | Strength | Weakness | | --- | --- | --- | --- | | Reactive | The asset has failed | No planning overhead; correct for low-consequence assets | Unplanned downtime, secondary damage, overtime | | Preventive | A date or usage threshold is reached | Predictable, plannable, easy to staff | Some work is done earlier than necessary | | Predictive | A measured condition crosses a threshold | Work happens only when needed | Requires instrumentation, data, and interpretation skill | The right mix is not 'all preventive'. Running a non-critical, cheap, redundant component to failure is a legitimate and often optimal decision. The mistake is making that decision by accident rather than deliberately - which is what happens when there is no schedule at all. > **A practical rule:** Sort assets by what happens when they stop. Anything that stops a line or creates a safety or compliance exposure gets a preventive schedule. Everything else can be justified case by case. ### How PM schedules work: calendar-based vs meter-based Every preventive task needs a trigger rule. There are two, and picking the wrong one is why schedules drift out of line with reality. - Calendar-based: every 30, 90, or 365 days. Correct when degradation is time-driven - lubricant ageing, seal perishing, seasonal dust or humidity - or when a regulation specifies an interval. - Meter-based: every 5,000 running hours, 100,000 cycles, or 10,000 units produced. Correct when wear tracks usage, which covers most mechanical wear items. - Hybrid: whichever comes first. Common for assets with both a usage-driven wear path and a time-driven one, such as a gearbox that needs an oil change either every 4,000 hours or annually. Meter-based scheduling is more accurate and harder to run, because it requires a meter reading to arrive reliably. If nobody is capturing running hours, a meter-based schedule silently stops generating work. Start calendar-based where meter data is not yet trustworthy, and convert as the readings become reliable. ### Building a PM checklist template The checklist is where preventive maintenance either becomes real work or becomes a tick-box exercise. The difference is mostly length and specificity. 1. **Start from failure history, not from the manual** — The manufacturer's manual describes ideal maintenance for an ideal environment. Your failure history describes what actually breaks in your plant. Where they conflict, the history wins. 2. **Write tasks as observable actions** — 'Check belt tension' is not checkable. 'Measure belt deflection at midpoint; record mm; replace if over 12mm' is. If a supervisor cannot verify the task was done from the record, the task is not specified. 3. **Capture readings, not just ticks** — A recorded value creates a trend. A tick creates nothing. Numeric fields on the two or three most diagnostic measurements turn your PM into a data source. 4. **Time-box it honestly** — Estimate how long the checklist takes and compare it against the window the line is actually available. If it does not fit, the checklist is fiction. Cut it. 5. **Include the safe-shutdown steps** — Isolation and lockout are part of the task, not a precondition assumed to be known. For audits, this is the part that gets inspected. 6. **Attach photos of the reference state** — A photo of what correct looks like resolves more ambiguity than three paragraphs of description, especially across language differences. ### How PM compliance connects to breakdown frequency There are two different numbers and plants routinely confuse them. Coverage is the share of critical assets that have a preventive schedule defined. Compliance is the share of preventive work orders completed inside their scheduled window. Coverage is easy to raise - you write more schedules in an afternoon. Compliance is hard, because it competes with breakdowns for the same technicians. And compliance is the one that plausibly relates to failure frequency: a schedule that exists but is not executed does not prevent anything. > **On causation:** Be careful reading this correlation in your own data. Months with fewer breakdowns free up technicians to complete more PM, so high compliance and low breakdown counts reinforce each other in both directions. Track both over quarters and treat sharp single-month movements with suspicion. - Measure compliance against the scheduled window, not against 'eventually completed'. - Track overdue PM as a count and an age, so a growing backlog is visible before it becomes a breakdown. - When compliance falls below target for two consecutive months, cut tasks rather than exhorting the team. A schedule nobody can complete produces guilt, not maintenance. ### Getting started: your first 90 days of PM scheduling 1. Days 1-15: build a clean asset register with a consistent hierarchy and a criticality rating on each machine. Everything else depends on this and nothing else should start first. 2. Days 16-30: pick the ten most critical assets. Only ten. Pull their failure history from whatever records exist, however imperfect. 3. Days 31-45: write one checklist per asset, time-boxed to the window the line is genuinely available, with numeric readings on the two most diagnostic measurements. 4. Days 46-60: run the schedules and measure completion honestly. Expect the first cycle to expose that some windows do not exist in practice. 5. Days 61-75: cut and revise. Remove tasks that were skipped without consequence; fix the ones that were skipped for lack of time or parts. 6. Days 76-90: extend to the next tier of assets only once the first ten are running above 90 percent compliance. Extending before that just distributes the failure more widely. - **10** — assets to start with - **90%** — compliance before extending - **2** — numeric readings per checklist - **90** — days to a working baseline ### Frequently asked questions **Q: What is preventive maintenance?** A: Preventive maintenance is maintenance work performed on a schedule before a failure occurs, triggered either by elapsed time (calendar-based) or by usage such as running hours or production cycles (meter-based). **Q: What is the difference between preventive and predictive maintenance?** A: Preventive maintenance is triggered by a fixed schedule regardless of the asset's condition. Predictive maintenance is triggered by a measured condition - vibration, temperature, oil analysis - crossing a threshold, so work happens only when the data indicates it is needed. **Q: How often should preventive maintenance be done?** A: Start from the manufacturer's interval, then adjust using your own failure history. If the asset repeatedly fails before the scheduled service, shorten the interval; if services consistently find nothing, lengthen it rather than continuing to spend the window. **Q: What is PM compliance?** A: PM compliance is the percentage of preventive work orders completed within their scheduled window. It differs from PM coverage, which is the share of assets that have a schedule defined at all. Compliance is the number that relates to breakdown frequency. --- ## Guided Operator Safety Triage: A New Approach to Factory Floor Response Source: https://firmicore.com/blog/guided-operator-safety-triage/ Published: June 19, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Engineering Every CMMS on the market treats the minutes between breakdown and repair as dead time. On a real floor, that is when an operator improvises. Guided triage turns that window into a structured, auditable, safer sequence. ### Key takeaways - The window between a machine stopping and a technician arriving is real, routinely 15 to 40 minutes, and almost entirely unmanaged by maintenance software. - Operators do not stand still in that window. They investigate, sometimes open guards, and sometimes restart the machine to see what happens. - Guided triage replaces improvisation with a machine-specific sequence: isolate, verify, capture evidence, record what was and was not attempted. - The output is both safety and speed - the technician arrives with a photo, a symptom, and a list of ruled-out causes already recorded. - No major CMMS vendor appears to productise this as a distinct workflow, which makes it a genuine category gap rather than a feature comparison. Maintenance software is built around two actors: the person who reports and the person who repairs. The design assumption is that nothing meaningful happens between them. Anyone who has spent time on a factory floor knows this is false. What happens in that gap is unrecorded, occasionally unsafe, and frequently determines how long the eventual repair takes. ### The gap between breakdown and technician arrival A machine stops. The operator reports it. Then they wait - typically fifteen to forty minutes depending on shift, plant size, and how many other things are broken. During that wait, in our experience of factory floors, some combination of the following happens, and none of it is in any system. - The operator looks for the obvious cause: a jam, a tripped sensor, an empty hopper. - They try restarting the machine, sometimes several times, occasionally causing secondary damage. - They open a guard to see inside, sometimes without isolating the machine first. - A colleague from another line comes over and offers a diagnosis based on a different machine. - Someone clears the jam or wipes the failure evidence away before anyone photographs it. - By the time the technician arrives, the machine state has changed and nobody can reconstruct what it looked like at failure. > **The core observation:** This window is not idle time being wasted. It is unmanaged activity being un-recorded. Those are very different problems, and only the second one is solvable with software. ### What guided operator triage actually looks like Guided triage is a short, machine-specific sequence presented to the operator immediately after they submit the breakdown report. It is not troubleshooting and it does not ask the operator to repair anything. It asks them to make the situation safe and observable. 1. **1. Stop and isolate, explicitly** — The first screen is the isolation step for that specific machine, with its actual isolation point named and pictured. Not a generic safety reminder - the lockout point for asset PR-04, with a photo of where it is. 2. **2. Capture the failure state before anything changes** — A prompt for one or two photos of the machine as it stopped. This is the highest-value thirty seconds in the whole incident, and it only happens if something asks for it at the right moment. 3. **3. Answer a short list of observable checks** — Three to six yes/no questions written for this machine: is the guard interlock lit, is there material in the feed, is the air pressure gauge in range. Observable facts only - nothing requiring diagnosis or tools. 4. **4. Record what is explicitly not permitted** — The flow states plainly which actions the operator must not take on this machine: do not restart, do not open the rear guard, do not clear the jam manually. Written per machine, because the answer differs per machine. 5. **5. Log what was attempted** — If the operator did try a restart before reporting, the flow captures it without blame. A technician who knows the machine was restarted twice is diagnosing a different problem than one who does not. 6. **6. Hand over a complete picture** — The technician's notification carries the photos, the check answers, and the attempted actions. They arrive knowing something, rather than arriving to be told a story. - **15-40m** — typical unmanaged window - **3-6** — observable checks per machine - **2** — photos before anything is touched - **1** — auditable record of the gap ### Why no major CMMS productises this This is not a gap because the idea is bad. It is a gap for structural reasons worth naming, because they also explain why it is defensible. 1. The category was designed around technicians. CMMS products are bought by maintenance departments and designed for maintenance staff. The operator is modelled as a request submitter, not as a participant. 2. Per-user pricing works against it. If every operator needs a paid seat, the vendor's own commercial model discourages building operator-facing workflows nobody will license. 3. The content is machine-specific. A triage flow for a knitting machine is not a triage flow for a boiler. That means configuration work per asset, which is harder to sell as a shrink-wrapped feature. 4. It sits at the boundary between maintenance and safety, and neither department's software budget naturally owns it. We describe this as a gap based on our review of publicly available competitor documentation, not on access to anyone's roadmap. If you are evaluating vendors, ask them directly what happens in the fifteen minutes after a breakdown is reported. The answers are informative. ### The safety and audit-trail case Set the productivity argument aside for a moment. There is a separate case that stands on its own. - Machine-specific isolation instructions delivered at the moment of failure are more likely to be followed than the same instructions delivered in an induction six months ago. - An explicit, per-machine list of prohibited actions is a control, and controls that are delivered at the point of risk are the ones that work. - The record is auditable. You can demonstrate that the operator was instructed to isolate, saw the prohibition, and confirmed it - with timestamps, on the specific occasion. - Near-misses become visible. When operators log attempted actions honestly, the pattern of unsafe improvisation stops being invisible to management. - The evidence supports incident investigation. If something does go wrong, the reconstruction is a record rather than a set of interviews. > **On regulatory framing:** Guided triage supports good practice under general machinery-safety and lockout obligations, but no software makes you compliant with OSHA, HSE, or a local equivalent. Compliance is a function of your procedures, training, and enforcement. Treat the audit trail as evidence for a programme you already run. ### Building triage flows for your own machines The per-machine content is the work. It is also less work than it sounds, because the people who know the answers already work in your plant. 1. Start with the five machines that stop most often. Frequency, not criticality - you want the flows exercised quickly so you can fix them. 2. Sit with the technician who fixes that machine most often and ask one question: what do you wish you knew before you walked over here? 3. Ask the operators the opposite question: what do you normally do while waiting? The honest answer is the list of behaviours the flow needs to address. 4. Write no more than six checks. A flow that takes longer than the walk from the maintenance office will be abandoned. 5. Photograph the isolation point and the reference state. Photographs cross language barriers that text does not. 6. Review after ten incidents. Cut checks that never produced useful information, and add the one question the technician kept having to ask on arrival. After the first few machines, the pattern is reusable across similar assets and the marginal effort drops sharply. The first five are the investment. ### Frequently asked questions **Q: What is guided operator triage?** A: Guided operator triage is a structured, machine-specific sequence presented to a machine operator immediately after they report a breakdown. It covers isolation, evidence capture, a short list of observable checks, and explicitly prohibited actions - turning the wait for a technician into a safe, recorded step. **Q: Is operator triage the same as troubleshooting?** A: No. Troubleshooting asks someone to diagnose and fix. Triage asks the operator only to make the situation safe and observable, and to record what they see. No tools, no repair, no diagnosis. **Q: Does guided triage help with machinery safety compliance?** A: It supports it by delivering machine-specific isolation instructions at the point of risk and creating a timestamped record that they were given and acknowledged. It does not by itself make an operation compliant - that depends on your procedures, training, and enforcement. --- ## Contractor Management Software for Manufacturing: A Buyer's Checklist Source: https://firmicore.com/blog/contractor-management-software-manufacturing/ Published: June 12, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Operations Contractor work is the part of maintenance that most often escapes the system entirely - assigned by phone, tracked on WhatsApp, invoiced against nothing. This is the workflow that fixes it. ### Key takeaways - Contractors need accountability without access: full job records, no app install, no login, no paid seat. - The lifecycle has five stages - registration, document tracking, job assignment, invoice comparison, rating - and most plants only manage the middle one. - Document expiry tracking with compliance blocking is the highest-value feature: an expired insurance certificate should prevent assignment automatically, not be caught during an audit. - Invoice comparison only works if the quoted scope and the completed work order are the same record. - This is a well-served category - several vendors do it competently, so evaluate on workflow fit rather than expecting differentiation. Every plant uses external contractors for something: refrigeration, electrical, calibration, specialist machine service. And in most plants that work sits outside the maintenance system, because the system assumes a user account and the contractor does not have one. The result is predictable. Nobody can say what the contractor did last visit, whether their certification was current, or whether this invoice is consistent with the last one. ### Why contractor work needs its own workflow An in-house technician has an account, a phone with the app, and a supervisor. A contractor has none of those and cannot be given them - you are not going to onboard an external electrician's whole company into your maintenance system for two visits a year. But the accountability requirement is higher, not lower, than for internal staff. - Their insurance and certifications are your liability exposure if they are not current. - Their work is billed, so scope creep is a direct cost rather than a scheduling problem. - They are not present day to day, so an undocumented visit is genuinely unrecoverable - nobody in the plant knows what happened. - Site induction and permit-to-work status has to be verifiable before they reach the floor. > **The design constraint:** Full record, zero access. Contractors should receive and complete jobs through a link rather than an account - no install, no password, no licence cost - while the plant retains a complete work order record. ### The contractor lifecycle 1. **1. Registration** — Company details, trade categories, contact people, rates where applicable, and the site areas they are approved to work in. This is a one-time record, not a per-visit form. 2. **2. Document tracking** — Insurance, licences, certifications, and site induction records, each with an expiry date the system watches. This is where the real value is, and it is covered in its own section below. 3. **3. Job assignment** — A work order is issued to the contractor with scope, asset, access requirements, and expected completion. They receive it as a link - viewable and completable without an account. 4. **4. Completion and evidence** — Work performed, parts supplied, time on site, photos, and any findings, captured against the same work order the plant sees. Sign-off by the plant supervisor closes it. 5. **5. Invoice comparison** — The invoice is checked against the quoted scope and the completed record. Discrepancies become visible at the moment they occur rather than at month-end. 6. **6. Rating** — A simple score on responsiveness, quality, and price consistency after each job. Over a year this produces the data for a supplier conversation that is currently based on impressions. ### Document expiry tracking and compliance blocking This is the feature worth paying for, and the one most often implemented as a passive list of uploaded files with dates. A passive list requires someone to check it before every assignment, which means it will eventually not be checked. The useful version is active. 1. Every document carries an expiry date, and the system counts down against it. 2. Notifications go out at a configurable lead time - 30 and 7 days is typical - to both the plant and the contractor. 3. When a mandatory document expires, assignment is blocked. Not warned: blocked, with an explicit override that is itself recorded and attributed. 4. The override record is the compliance artefact. Auditors are not asking whether you ever assign work to a contractor with a lapsed certificate; they are asking whether you know when you did and who authorised it. 5. Expiry status is visible on the contractor record before you start assigning, so scheduling can work around a renewal in progress. > **Firmicore note:** The blocking behaviour is what turns document tracking from an archive into a control. If a vendor's document module cannot prevent an assignment, it is storage, not compliance. ### Evaluation checklist for contractor management features Work through these with any vendor. They are ordered roughly by how often we see them missing. 1. Can a contractor receive and complete a work order without installing an app or creating an account? 2. Does contractor access consume a paid seat? Model the cost at your real contractor count before signing. 3. Does document expiry actively block assignment, with a recorded and attributed override? 4. Are contractor work orders the same object as internal ones, so reporting covers both without reconciliation? 5. Can the contractor attach photos and parts-supplied details from the field? 6. Is there a distinct plant-side sign-off step before the job closes? 7. Can you compare the invoice against quoted scope inside the system, or is that a separate spreadsheet? 8. Does rating history persist across jobs and roll up per contractor company? 9. Can you restrict a contractor to specific site areas or asset groups? 10. Does the audit export include the document status at the time each job was assigned, not just current status? Point ten catches more vendors than any other. Current document status is easy; historical status at assignment time is what an audit actually asks for. ### An honest note on differentiation Unlike operator triage or pricing model, contractor management is a well-served category. Several established CMMS vendors handle it competently, and we would not tell anyone to switch platforms for this capability alone. What we would say is that the checklist above separates competent implementations from checkbox ones, and that the two questions worth insisting on are seat cost for contractor access and active expiry blocking. Those two are where implementations differ most. ### Frequently asked questions **Q: What is contractor management software in manufacturing?** A: It manages external maintenance contractors across their full lifecycle: registration, insurance and certification tracking with expiry dates, work order assignment without requiring a system account, completion evidence, invoice comparison against quoted scope, and performance rating. **Q: How do you assign a work order to a contractor without giving them a login?** A: Through a tokenised link. The contractor opens the work order in a browser, sees the scope and asset details, and submits completion evidence - without an account, an app install, or a paid seat. **Q: What contractor documents should a factory track?** A: Public liability and employer insurance, trade licences and certifications, site induction records, and any permit-to-work qualifications. Each needs an expiry date, advance notification, and ideally automatic blocking of new assignments once lapsed. --- ## Best CMMS Software for Small Manufacturers in 2026 Source: https://firmicore.com/blog/best-cmms-for-small-manufacturers/ Published: June 5, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Comparison A 40-machine factory with no IT department has different constraints from a multi-site enterprise, and the vendors that serve it well are not always the biggest names. What to prioritise, what to shortlist, and the red flags that show up in month seven. ### Key takeaways - Small manufacturers are cost-sensitive and IT-light, so setup speed and self-service configuration matter more than feature depth. - The machine-to-user ratio decides the pricing model: more machines than office staff favours per-machine pricing. - Free tiers are a legitimate starting point, but check what they gate - preventive maintenance scheduling is the most commonly withheld feature. - Prioritise mobile-first reporting, fast setup, and no IT overhead over integrations you will not build. - The red flags that hurt later are seat caps, feature gating on reporting, annual-only billing, and storage overages on photos. Most CMMS buying advice is written for plants with a maintenance planner, an IT function, and a procurement process. If you are a 40-machine factory where the production manager also owns maintenance and the 'IT department' is whoever is best with computers, that advice does not apply. This post is written for that case. ### What small manufacturers need that enterprises do not - Setup you can do yourself. If go-live requires a consultant, the project will not happen - there is no budget line for it and nobody to manage it. - Configuration without tickets. Adding a machine, changing a checklist, or creating a user should take minutes and require no vendor involvement. - Cost that scales with the plant, not the headcount. A seasonal hiring spike should not change the software bill. - Mobile-first reporting, because there is no maintenance office with a desktop in it - the supervisor is on the floor. - Fast, visible payback. Enterprises can justify a two-year reliability programme; a small manufacturer needs the tool to be obviously useful in the first month or it gets abandoned. - Genuinely no IT overhead: hosted, no server, no VPN, no on-premise database to back up. Notice that none of these are features. They are properties of how the product is delivered and priced, which is why feature-comparison tables mislead buyers at this size. ### Comparison shortlist These are the options we most often see on small-manufacturer shortlists, including our own product. Vendor plans and pricing change frequently - confirm current terms directly before deciding. _Shortlist for small manufacturers. Verify current plans and pricing with each vendor._ | Option | Pricing basis | Best for | Watch out for | | --- | --- | --- | --- | | Firmicore | Per machine, unlimited users | Plants with more machines than office staff that want operators reporting directly | Newer product with a narrower integration ecosystem | | MaintainX free tier | Free, then per user | Getting off paper with a very small team | Feature limits on the free plan and per-user cost as you grow | | UpKeep entry plans | Per user | Small teams wanting a mature mobile app | Reporting and PM features often sit on higher tiers | | Limble entry plans | Per user | Teams that value fast setup and a clean interface | Cost scales with every additional user you add | | Spreadsheet plus a shared drive | Free | Fewer than about ten assets with one person maintaining them | No audit trail, no scheduling, no history you can query | > **The per-machine callout:** Run one calculation before shortlisting: divide your machine count by the number of people who should be able to report a breakdown. If that number is below one - more potential reporters than machines - per-user pricing will cost you more every year, and will quietly push you into rationing access. We are a vendor on this list, so weigh the entry accordingly. The comparison criteria above are the part worth taking - apply them to any shortlist, including one that excludes us. ### What to prioritise at this size 1. **Time to first closed work order** — Ask each vendor for a trial where you close one real work order on one real machine. If that takes more than a week, the full rollout will take months you do not have. 2. **Mobile-first, offline-tolerant reporting** — Test it in the worst-covered corner of the plant, not in the office. If the app cannot queue a report offline, floor adoption will be inconsistent in exactly the areas with the most machines. 3. **Self-service configuration** — During the trial, add a machine and edit a checklist yourself. If you need support to do either, you will stop maintaining the system within a quarter. 4. **Preventive maintenance in the tier you can afford** — PM scheduling is the most commonly gated feature. Confirm it is included at your price point before you build the business case on it. 5. **Data portability** — Check that export is available on your tier. It is cheap insurance, and its absence tells you something about the vendor's posture. ### Red flags: seat caps, feature gating, and hidden overages These are the things that do not hurt during the trial and do hurt in month seven. - Seat minimums. A low per-user rate with a 25-seat floor is not a low price for a team of nine. - Reporting behind a higher tier. If you cannot run the reports that justify the purchase, you will end up upgrading and the real price is that tier. - Annual-only billing on entry plans, which removes your ability to leave cheaply if adoption fails. - Storage or attachment overages. Photo-based breakdown reporting accumulates quickly, and metered storage turns good reporting behaviour into a cost. - Paid onboarding that is presented as optional but is functionally required to get the asset register in. - API access reserved for enterprise tiers, which forecloses the integration you will want in year two. - Read-only seats that cannot submit a work request - a viewer licence that cannot report a breakdown does not solve the access problem it appears to solve. > **Firmicore note:** Ask every vendor to quote the total annual cost at your projected size in three years, including the tier that contains the features you need. Then compare those numbers rather than the entry prices on the pricing pages. ### Frequently asked questions **Q: What is the best CMMS for a small manufacturer?** A: There is no single answer, but the selection criteria are consistent: self-service setup, mobile-first offline reporting, preventive maintenance included at your price tier, and a pricing model that matches your machine-to-user ratio. Shortlist against those rather than against feature counts. **Q: Is there a free CMMS for small factories?** A: Several vendors offer free tiers, MaintainX being the best known. They are a legitimate way to get off paper, but check what is gated - preventive maintenance scheduling and reporting are the features most commonly withheld from free plans. **Q: How many machines do you need before a CMMS is worth it?** A: Machine count is a weaker signal than record quality. If you cannot say which machine failed most last quarter or whether preventive work was done on schedule, a CMMS pays for itself at almost any size. Below roughly ten assets with one maintainer, a well-kept spreadsheet may still be enough. --- ## CMMS for Regulated Manufacturing: Textile, Food & Beverage, and Pharma Source: https://firmicore.com/blog/cmms-for-regulated-manufacturing/ Published: May 29, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Case study Compliance requirements do not change what maintenance software does - they change what counts as a complete record. This covers what auditors actually look for in three verticals, and the common thread across all of them. ### Key takeaways - Regulated manufacturing does not need different maintenance workflows - it needs the same workflows with audit-grade records attached. - Textile and garment plants are driven by machine criticality, heavy contractor use, and customer social-compliance audits. - Food and beverage plants tie preventive maintenance to sanitation, and need traceability from a maintenance action to affected production. - Pharmaceutical plants need documentation rigour, calibration tracking, and attributable, timestamped records. - The common thread: a record that is complete at capture is audit-ready; a record reconstructed later is a project. The question we are asked most often by regulated manufacturers is whether a CMMS is 'compliant'. It is the wrong question. No maintenance system is compliant or non-compliant on its own - your procedures, training, validation, and record-keeping are what get audited. The right question is narrower: does this system capture, at the moment work happens, everything an auditor will later ask to see? Below is what that means in three verticals we work in. ### Why regulated manufacturing needs maintenance-specific compliance features In an unregulated plant, an incomplete maintenance record is an operational inconvenience: you cannot analyse a trend. In a regulated plant it is an audit finding, and audit findings have commercial consequences - a delayed certification, a customer withdrawing an order, a batch under investigation. What changes is the standard for what counts as a record. - Attribution: who performed the work, verified by more than a name typed into a free-text field. - Contemporaneity: recorded when the work happened, not reconstructed at month-end from memory. - Completeness: the whole chain from detection to sign-off, with no undocumented gaps in the middle. - Immutability: changes to a record are visible as changes, with the original preserved and the edit attributed. - Retrievability: a specific record for a specific asset on a specific date, produced during an audit rather than after it. > **The practical implication:** Every one of those five properties is a property of how data is captured, not of what is done with it afterwards. Which is why the intake design decides whether you are audit-ready, and no reporting module can retrofit it. ### Textile and garment: machine criticality and contractor exposure Textile and apparel plants are not regulated in the pharmaceutical sense, but they are audited constantly - by buyers, by social-compliance schemes, and by the certification bodies their customers require. In Sri Lanka this is amplified by export-zone requirements and the buyer audit regimes that come with international brands. - Machine criticality varies enormously across the floor. A stopped knitting machine and a stopped boiler are not the same event, and the maintenance record needs criticality attached to the asset, not inferred by the reader. - Heavy contractor use for electrical, boiler, refrigeration, and specialist machine service. Contractor certification currency is an audit exposure, so document expiry tracking is not administrative housekeeping here. - Machine safety and guarding findings arrive through buyer audits. A record showing that a guard fault was detected, reported, isolated, and repaired - with dates - answers the finding directly. - High workforce turnover across shifts means training assumptions do not hold. Machine-specific instructions delivered at the point of failure are more reliable than induction-based knowledge. - Multilingual floors are the norm rather than the exception, so the language of the reporting interface is a data-quality issue. The practical priority for this vertical is contractor document control and a complete detection-to-repair chain on safety-related faults. ### Food and beverage: sanitation-linked PM and traceability Food and beverage plants operate under HACCP-based food safety systems and customer schemes such as BRCGS or similar. Maintenance touches food safety directly, which changes what the maintenance record has to prove. 1. **PM tied to sanitation windows** — Preventive work frequently has to happen inside the clean-down window, and the record needs to show that post-maintenance sanitation was completed before production resumed. That sanitation step belongs on the work order, not on a separate sheet. 2. **Traceability from maintenance to production** — If a maintenance action on a filler is later implicated in a quality issue, you need to identify which production ran after it. That requires accurate completion timestamps and asset linkage, not an approximate date. 3. **Foreign-body control on repairs** — Tool accountability and parts control around an open machine are inspection topics. A close-out checklist that includes tool reconciliation turns a procedure into an evidenced one. 4. **Lubricant and material control** — Food-grade specification for anything used in contact zones, recorded against the work order so the specification used on a given repair is retrievable. 5. **Root cause tracking on recurring faults** — Repeat faults in contact-zone equipment attract scrutiny. Controlled cause codes make the pattern - and its resolution - demonstrable rather than anecdotal. The priority here is PM compliance evidence and completion timestamps accurate enough to correlate with production runs. ### Pharmaceutical: documentation rigour and calibration Pharmaceutical manufacturing operates under GMP, and its data-integrity expectations - commonly summarised as ALCOA principles: attributable, legible, contemporaneous, original, accurate - apply to maintenance records as much as to production ones. - Attributable and contemporaneous capture. Records created at the time of work by an identified individual, not transcribed later from notes. - Calibration tracking as a first-class function: instrument, standard used, tolerance, result, next due date, and blocking of use when overdue. - Audit trails on record changes, preserving the original value and attributing the edit - a corrected entry must remain visibly a correction. - Change control interaction. Maintenance that alters equipment function is a change-control matter, and the maintenance record needs to reference it. - Retention periods that outlast your software subscription, which makes export and archival format a real procurement question. > **Be careful with vendor claims:** Software cannot be 'GMP compliant' in itself, and any vendor claiming otherwise should be treated cautiously. Systems supporting GMP records typically require qualification and validation in your environment, against your procedures. Ask what validation documentation the vendor supplies to support your qualification effort - that is the answerable question. ### The common thread: audit-ready records from day one Across all three verticals the requirement reduces to the same thing. The record has to be complete when it is created, because nothing added afterwards has the same evidentiary value. _Same capability, different reason it matters._ | Capability | Textile | Food & beverage | Pharmaceutical | | --- | --- | --- | --- | | Contractor document expiry blocking | Buyer audit exposure | Hygiene training currency | Qualified-supplier requirement | | System-generated timestamps | Response-time evidence | Correlation with production runs | Contemporaneous record requirement | | Photo capture at failure | Guarding and safety findings | Foreign-body investigation | Deviation investigation support | | PM compliance reporting | Machine criticality management | Sanitation-linked scheduling evidence | Preventive programme evidence | | Attributed change history | Audit credibility | Traceability integrity | Data-integrity expectation | The plants that find audits easy are not the ones with the most documentation. They are the ones whose everyday capture is already good enough that no preparation is required - the audit is a query, not a project. ### Frequently asked questions **Q: Does a CMMS make a factory compliant?** A: No. Compliance depends on your procedures, training, validation, and enforcement. A CMMS supports compliance by capturing complete, attributable, timestamped maintenance records at the moment work happens, which is what auditors ask to see. **Q: What maintenance records do food safety auditors look for?** A: Evidence that preventive maintenance was completed on schedule, that post-maintenance sanitation occurred before production resumed, that tools and parts were accounted for around open equipment, and that food-grade specifications were used where required - all with accurate completion timestamps. **Q: What is required for maintenance records under GMP?** A: Records should be attributable, legible, contemporaneous, original, and accurate. In practice that means capture at the time of work by an identified person, an audit trail that preserves original values when entries are corrected, calibration status tracking, and retention that outlives the software subscription. --- ## What Is MTTR? How to Calculate and Improve Mean Time to Repair Source: https://firmicore.com/blog/what-is-mttr/ Published: May 25, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Operations A short reference on mean time to repair: the formula, how it differs from MTBF and MTTA, what counts toward it, and the measurement mistakes that flatter the number without improving anything. ### Key takeaways - MTTR is total downtime across incidents divided by the number of incidents, over a defined period and asset set. - The clock should start at failure, not at technician arrival. Starting late is the most common way plants flatter the number. - MTBF measures reliability between failures; MTTA measures acknowledgement speed; MTTR measures recovery. They answer different questions. - Cross-plant MTTR comparison is close to meaningless because definitions and asset mixes differ - benchmark against your own baseline. - Lowering MTTR usually means shortening the segments around the repair, not the repair itself. This is a companion reference to our longer guide on reducing machine downtime. That post covers what to do; this one covers what the number means and how to calculate it correctly. ### MTTR definition and formula Mean time to repair is the average elapsed time to restore an asset to service after a failure, across a set of incidents in a defined period. > **Formula:** MTTR = total downtime across incidents / number of incidents. Downtime for each incident runs from the moment of failure to the moment the asset is back in service. Worked example: a packing line stops four times in a month, for 45, 90, 30 and 75 minutes measured from failure to restart. Total downtime is 240 minutes across 4 incidents, so MTTR is 60 minutes. - **240m** — total downtime - **4** — incidents - **60m** — MTTR - **1** — asset set, defined Always state the asset set and period alongside the number. 'MTTR is 60 minutes' is not a fact until you say for which assets, over what window. ### MTTR vs MTBF vs MTTA _Four related metrics, four different questions._ | Metric | Full name | Measures | Question it answers | | --- | --- | --- | --- | | MTTR | Mean time to repair | Failure to back in service | How fast do we recover? | | MTBF | Mean time between failures | Uptime between consecutive failures | How reliable is the asset? | | MTTA | Mean time to acknowledge | Report to someone accepting the job | How fast do we respond? | | MTTF | Mean time to failure | Operating life of non-repairable items | How long does this component last? | The pairing that matters most is MTTR with MTBF. Falling MTTR with falling MTBF means you are getting faster at fixing an asset that is failing more often - which is not an improvement, it is a machine heading toward replacement. Either metric alone can hide that. ### What counts toward MTTR, and common measurement mistakes Almost every implausibly good MTTR figure comes from one of these. - Starting the clock at technician arrival. This excludes reporting delay and dispatch, which in many plants are the largest segments. It measures repair speed, not downtime. - Excluding parts wait time. If the machine is down waiting for a bearing, it is down. Track the wait separately if you want to manage it, but do not remove it from the total. - Stopping the clock at 'repair complete' rather than 'back in production'. Restart, changeover, and quality confirmation are downtime for the line. - Mixing asset classes. A boiler and a labelling machine in the same average produce a number that describes neither. - Silently excluding long incidents as outliers. If you exclude them, say so explicitly and report how many - they are usually the incidents that cost the most. - Hand-entered durations. Any duration typed by a person rounds to the nearest convenient number and drifts optimistic. Derive it from system timestamps. > **Firmicore note:** The definition you choose matters less than applying it consistently. Write it down, apply it to every incident, and never change it mid-year without restating the prior period. ### How to actually lower MTTR Break the total into its segments and attack the longest. In plants without digital reporting, the repair segment is frequently not the longest one. 1. Shorten reporting delay with machine-level QR or messaging intake, so the clock starts when the failure does rather than when someone finds a supervisor. 2. Make acknowledgement an explicit step with its own timestamp, which makes ownership visible and MTTA measurable. 3. Give the technician context before they arrive: symptom, photo, and machine history attached to the work order. 4. Attack parts wait by linking consumption to assets, so critical spares stocking follows actual failure history. 5. Reduce repeat failures through controlled cause codes - the fastest repair is the one that is not needed again. The full treatment of each lever, with the downtime-clock breakdown, is in our guide on reducing machine downtime. ### Frequently asked questions **Q: What is MTTR?** A: MTTR, or mean time to repair, is the average elapsed time to restore an asset to service after a failure. It is calculated as total downtime across incidents divided by the number of incidents, over a defined period and asset set. **Q: What is the MTTR formula?** A: MTTR = total downtime / number of incidents. Each incident's downtime should be measured from the moment of failure to the moment the asset is back in production, not from technician arrival to repair completion. **Q: What is the difference between MTTR and MTBF?** A: MTTR measures how quickly you recover from a failure. MTBF, mean time between failures, measures how long an asset runs between failures. MTTR is a maintenance responsiveness metric; MTBF is a reliability metric. Read them together. **Q: What is a good MTTR?** A: There is no useful universal target, because definitions and asset mixes differ too much for cross-plant comparison to be meaningful. Establish your own baseline by asset class with a written definition, then manage the trend. --- ## The Real Cost of Unplanned Downtime Source: https://firmicore.com/blog/the-real-cost-of-unplanned-downtime/ Published: May 21, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Operations The visible repair bill is only the top layer. The real damage hides in lost throughput, scrap, overtime, missed orders, and the trust your team loses when every shift starts in reactive mode. Unplanned downtime is usually discussed like a repair problem. A bearing failed, a motor tripped, a valve stuck open. Someone asks how long it took to fix. Someone else asks what part was replaced. The invoice gets filed and everyone moves on. ### The downtime iceberg The most expensive parts of a stoppage rarely show up on the maintenance invoice. They sit in production schedules, quality rejects, overtime, customer penalties, and supervisor attention. In most factories, those costs are scattered across teams and never consolidated into a single number. - **3-5x** — hidden cost multiplier - **42m** — average MTTR target - **17** — active tickets - **99.2%** — uptime goal ### What to measure Start with a minimum reliable dataset: machine, line, timestamp, reporter, severity, technician response time, parts used, root cause, safe actions taken, and final resolution. If your system cannot capture this under pressure, it will not survive a real breakdown. - Use QR codes so reports start at the machine, not in a spreadsheet. - Capture operator evidence before memory fades or the machine is cleaned. - Separate response time from repair time so staffing issues become visible. - Attach parts usage to work orders so inventory planning follows reality. > **Firmicore note:** The goal is not more forms. The goal is a lightweight operating loop where every breakdown makes the next response faster. ### A better operating loop A modern maintenance flow should work like a control room: report instantly, route clearly, guide the first safe actions, log the repair, update the machine history, and recalculate the dashboard without manual reconciliation. 1. **Report** — Capture the failure at the machine, with a scanned asset and a system timestamp. 2. **Triage** — Guide the operator through safe actions while the technician is on the way. 3. **Assign** — Route to the right trade with symptom, photo, and history attached. 4. **Repair** — Record work, parts, and duration against the asset as it happens. 5. **Learn** — Close with a controlled cause code so the pattern becomes visible. ### Closing the loop Downtime cost only becomes manageable once it is tracked consistently, not just remembered anecdotally. Teams that log every stoppage against the same fields - machine, timestamp, cause, and resolution - start noticing patterns within weeks: which lines fail most often, which parts wear out early, and which shifts are under-resourced. That visibility is what turns maintenance from a reactive cost center into a lever for uptime. The technology matters less than the discipline of capturing the same data every time a machine goes down. --- ## Why QR Reporting Beats Paper Logs Source: https://firmicore.com/blog/why-qr-reporting-beats-paper-logs/ Published: May 14, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Product QR reporting is not a technology upgrade. It is a data-quality fix - it removes the one field operators get wrong most often, and it starts the clock at the machine. Paper logbooks survive because they work under pressure. Nothing needs charging, nothing needs a password, and everybody already knows how. Any replacement has to be at least as fast at the moment a machine stops, or it will not be used. ### The machine identity problem The single most damaging error in maintenance records is the machine name. Written by hand or typed under pressure, the same asset appears as three or four different strings across a year, and machine-level trends never emerge from the data. A scanned QR label removes the field entirely. The asset, line, and location attach themselves, and the operator is left describing only what they actually observed. ### What changes on the floor - The report starts at the machine rather than at a desk, so the timestamp reflects the failure rather than the walk. - A photo of the failure state is captured before anything is cleaned, restarted, or cleared. - Severity is set against published definitions rather than tone of voice. - The record is visible to the supervisor immediately, which removes the phone call that usually follows. > **Firmicore note:** Keep the paper log for the first month. Running both in parallel on one line tells you exactly which fields operators skip when they are in a hurry, and those are the fields to redesign. ### Rolling it out without disrupting the floor 1. **Label one line first** — Print and mount durable labels on a single line. Placement matters more than the label - eye level, on the side the operator stands. 2. **Keep the flow under a minute** — Six fields is the ceiling. Anything longer degrades during exactly the incidents you most want documented. 3. **Provide a fallback channel** — Where phones are banned, supervisor-mediated capture from a shared device keeps the structured record without a device in the operator's hand. 4. **Review after ten reports** — Cut the fields nobody fills in, and add the one question the technician keeps asking on arrival. --- ## Guided Triage for Shared Factory Tablets Source: https://firmicore.com/blog/guided-triage-for-shared-tablets/ Published: May 8, 2026 · Author: Tharindu Jayasekara, Founder, Lumora Ventures · Category: Engineering Shared devices break most of the assumptions mobile software is built on: no personal login, no persistent session, and a different user every few minutes. Here is how triage flows have to change. A shared floor tablet is not a phone with more users. It is a public terminal in a hostile environment, and designing for it means giving up several conveniences that single-user mobile apps take for granted. ### The constraints a shared device imposes - No persistent login. Whoever picks the device up next must not inherit the previous user's session or see their draft. - Identity has to be lightweight. A password on a greasy screen with gloves on will be shared, written on the wall, or bypassed - a scanned badge or a short PIN is more honest. - Sessions must expire fast and reset cleanly, because devices are put down mid-task constantly. - The screen is read at arm's length in poor light. Type sizes and contrast that pass in the office fail on the floor. - Connectivity is worse near the machines than anywhere else in the building, so every step must queue offline. ### Designing the triage flow 1. **Identify by scan, not by typing** — Badge or QR identification attaches the reporter without a keyboard, which is what makes attribution survive contact with the floor. 2. **One decision per screen** — Shared devices get put down. A flow with one question per screen resumes cleanly; a long form does not. 3. **Machine-specific isolation first** — Name and picture the actual isolation point for that asset. Generic safety text is ignored because it is always the same. 4. **State prohibited actions explicitly** — Do not restart, do not open the rear guard, do not clear the jam by hand - written per machine, because the answer differs per machine. 5. **Auto-reset on completion** — Submit, confirm, and return to the idle screen without leaving anything behind for the next user. > **Firmicore note:** Test with gloves on, in the darkest corner of the plant, on the oldest device you own. Every shared-device design failure we have seen was invisible in the office and obvious within ten minutes on the floor. ### Designing for shift rotation Operators rotate across shifts and lines, and turnover is high. Any flow that assumes accumulated familiarity with the software will degrade every time the roster changes. The practical consequence is that the flow must be self-explanatory on first use, in the reader's own language, with photographs doing the work that instructions cannot. If a new operator on their first night shift cannot complete it unaided, it is not finished. --- Content may be quoted with attribution to Firmicore (https://firmicore.com/).