Understand the operation
How work comes in, who decides, what gets billed and what actually hurts today. Without this, configuration is a gamble.
Services
Most CMMS projects don’t fail: they get abandoned
Rarely because of the software. Almost always because someone tried to build everything at once, because no one decided the workflow before starting, or because the technicians never saw the point of it.
Who it’s for
For companies rolling out a CMMS for the first time and for those who already tried and it didn’t stick. Also for anyone coming from a previous tool who has to migrate years of history without losing it. It’s not a mandatory service: some rollouts succeed on their own, especially when the inventory already exists and the workflow is clear.
Why it stalls halfway
The reasons repeat with suspicious regularity.
- The decision is made to build the full inventory before starting anything, and four months later no one remembers to finish it.
- The status workflow gets configured on the fly and then has to be changed with a thousand orders already in it.
- Managers get trained and technicians don’t, even though they’re the ones who decide whether the system gets used.
- The entire history gets migrated without cleaning it up, and the old data contaminates the new.
- No one defines what "the rollout is finished" means, so it never finishes.
How we approach it
Four phases, and the first one isn’t configuring anything.
Decide the workflow
Statuses, roles and permissions, before entering any data. It’s the cheapest thing to get right at the start and the most expensive to change later.
Start with one part
One contract, one plant or one line. With a minimal inventory and real preventive plans, so orders are flowing within weeks, not months.
Bring the team along
Training technicians on their own app, with their own jobs. It’s the phase that determines the outcome the most, and the one most often neglected.
Migrating from what you already have
Almost no one starts from zero: there’s a spreadsheet, a previous program, or five years of paper work orders. What’s worth bringing over isn’t everything, it’s what’s actually going to be used: the asset inventory with its identification and location, active contracts, technical documentation and, from the history, just enough for the metrics to make sense. Bringing over ten years of poorly closed work orders doesn’t improve the analysis, it makes it worse, because it mixes poor records with good ones and you can no longer tell them apart. There’s an importer for bulk uploads from files, the standard route for inventory and master data.
Shall we look at it with your way of working?
Leave your details and we will get in touch to see whether we fit. No commitment, no lock-in period.
The technician decides whether this works
It’s the part almost no rollout takes as seriously as it deserves. A manager will use the system because it’s their job; a technician will use it if it makes theirs easier, and if not, they’ll find a way to keep doing it the old way. That’s why useful training isn’t a two-hour session about the product, it’s accompanying the first few days with their own actual orders and resolving the specific friction that comes up: material not being where they look for it, a missing status they use every day, a checklist asking for something that makes no sense on that machine. Those first-week fixes are worth more than any manual.
What we look at before configuring anything
The part that determines a rollout’s outcome the most happens before touching the system, and it mostly consists of listening to whoever does the work. Where a report comes in today and how many different paths it can take. Who decides what gets handled first and on what basis. What information a technician looks for before heading out, and where they find it today. What they’re asked to record versus what they actually record, which almost never match. What questions management asks every month and how they get answered now. That map usually reveals two or three things no one had put into words: a step done twice, information that exists but never reaches whoever needs it, a decision always made by the same person out of habit rather than by design. Configuring without that map just moves the problems you already had into the system, with the difference that now they’re written down.
The goal is for you to stop needing us
There’s a simple way to know whether an implementation engagement was well designed: whether, once it’s over, your team can register an asset, set up a preventive plan, create a work-order template and change a permission without calling anyone. When that’s not the case, the system ages badly for a purely practical reason: the operation changes every week —new equipment, new sites coming on board, people leaving— and if every adjustment requires an outside request, the adjustments stop happening. Two years in, the system describes a company that no longer exists, and no one trusts what they see. That’s why the engagement has to explicitly include the handover, and not as a course at the end but by doing the work with the team from the start, the only way it actually sticks.
Frequently asked questions
Can we do it ourselves without support?
Many companies do, and it goes well when there’s someone with dedicated time and knowledge of the facility. Where it usually goes wrong is in the first-month structural decisions —how the inventory is organized, what counts as an asset, how permissions are split— because those are the hardest to change later and the ones made with the least experience.
Is hiring implementation support mandatory?
No. Some rollouts succeed on their own, especially when the inventory already exists and the workflow is clear. It’s most worthwhile when starting from paper, when migrating from another tool, or when you already tried once and it didn’t stick.
How long does it take?
It depends more on the state of your data than on the software. With a usable inventory, you can start within weeks; if it has to be built in the field, the sensible approach is to start with one part and replicate. We won’t give a fixed timeline without seeing the case, because that would just be making it up.
Can you migrate the history from my current system?
You can import inventory, master data and part of the history from files. What we don’t recommend is bringing all of it: poor records mixed with good ones ruin the metrics instead of enriching them.
Do you train the technicians?
It’s the part we give the most importance to, because it’s what decides the outcome. Useful training means accompanying the first few days with their own actual orders and fixing the specific friction that comes up, not a general session about the product.
Tell us where you stand
If you’ve already tried once, even better: knowing what failed then saves half the work now.