How to prepare your organisation for an EAM project
Most EAM projects that go wrong do not fail during implementation. They fail because they started before the organisation was genuinely ready to start.
Kickoff is a symbolic moment: meeting rooms, slides, enthusiasm. But the work that determines the outcome of the project is largely what was done in the preceding weeks — and it has nothing to do with the software. It has to do with your data, your processes and your people.
Here is what is worth having in order before day one.
Your asset hierarchy is the decision that shapes everything else
Before configuring anything at all, you need to know how you intend to structure your assets: how many levels, following what logic, grouped by what criteria. It looks like a technical decision but it is an organisational one, because the hierarchy determines how you will read costs, how you will aggregate indicators and at what level of detail you will be able to analyse.
Changing it after go-live is possible but expensive: it means remapping work orders, recalculating history and rewriting reports. It is worth spending a few extra weeks beforehand, discussing it with the people who actually do the maintenance, rather than discovering six months in that the structure does not answer the questions management is asking.
Take an honest look at your data quality
Every organisation believes its master data is “more or less fine”. Almost none is. Duplicated spare part codes, suppliers recorded three times under slightly different names, asset descriptions written by different people across a decade, mandatory fields filled in with “N/A” just to move on.
An EAM project does not clean data by magic: it transfers it. If it goes in dirty, it comes out dirty — and the new system quickly earns a reputation for being unreliable, when the problem was upstream all along.
Pull a real extract of your main master data and look at it honestly before kickoff. It does not all have to be perfect; you need to know where you stand badly, how much cleansing work lies ahead and who will do it. It is one of the few activities you can start months in advance without depending on your vendor.
Decide now how much history you are bringing across
The temptation is to bring everything. Twenty years of work orders, every meter reading, every stock movement. It sounds prudent, but it rarely is: migrating history is one of the most underestimated cost and risk items in an implementation, and much of that data will never be looked at again.
Ask yourself what you actually need that history for. If it is failure analysis, three years may be enough. If it is regulatory or certification obligations, the scope is set by the rules, not by preference. If it is “just in case”, you probably do not need it, and you can leave it accessible in the legacy system in read-only mode.
This is a decision management must take explicitly, not one that should emerge by default halfway through the project.
Establish who decides, before there is anything to decide
During an implementation, dozens of choices come up that have no technical answer: which approval workflow to adopt, who can close a work order, which fields to make mandatory, how to handle exceptions. Each of these touches the balance between maintenance, production, procurement and finance.
If it is not clear from the outset who has the final word, every choice becomes a negotiation and the project slows down. Worse: you end up with compromises that satisfy nobody and that nobody then defends during adoption.
Before kickoff, appoint a project lead with a real mandate and a small decision-making group that meets on a fixed schedule. “Real” means that person can decide without having to escalate every time.
The right people have to be genuinely available
This is where more projects stall than anyone cares to admit. Key users are nominated, their names appear on a slide, and then they stay a hundred per cent committed to their day job. The result is that design sessions happen with whoever is free, not with whoever knows.
If your best maintenance planner is the right person for the project, they are also the person the workshop cannot do without. There is no shortcut: either you free up their time formally and cover the gap, or you accept that the system will be designed on a partial understanding of your processes.
Quantifying that commitment up front — days, periods, people — and budgeting for it is as much a part of preparation as data cleansing.
Do not automate processes you already know are broken
An EAM project is one of the rare occasions when an organisation stops to look at how it actually works. If you know your purchase requisition approval cycle is cumbersome, or that fault reports arrive through three different channels, now is the moment to act.
Moving a dysfunctional process into a new system makes it more rigid, not better: what used to be worked around with a phone call becomes a formal blocker. And then the software gets the blame.
You do not need to redesign everything — you need to identify the two or three points that already cause friction today and decide deliberately whether to fix them before, during, or never.
Prepare the ground before you ask for change
Everything above is material. But there is a part you cannot prepare with a spreadsheet, and that is how the organisation receives the news.
When a maintenance technician first hears about a new system, the question they ask is not “what features will it have”. It is: will I be monitored more closely? Will I have to fill in more forms? Who will teach me to use it while I still have my jobs to close? If nobody answers those questions, they answer them among themselves, and usually in the worst possible way.
Communicating early, concretely and without spin about what will change and what will not is an almost cost-free investment that greatly reduces later friction. The same goes for involvement: people who took part in a design session defend the system, people who had it imposed on them criticise it.
Preparing is not the same as postponing
There is an opposite risk, which is using preparation as an alibi for never starting: one more round of analysis, one more cleansing exercise, one more alignment meeting. Preparation makes sense as long as it is time-boxed and has verifiable objectives.
The practical test is simple: you are ready when you know how your asset base is structured, you know what state your data is in and who will fix it, you know who decides, and your key people have time assigned. Nothing else is needed to start well.
If you are still upstream of this stage and need to work out which platform to go for, the starting point is a different one: how to choose the right EAM system for your organisation.
Considering an EAM project and wondering how ready your organisation really is? Get in touch — we can help you take stock before you start.
