The 60-Day Warning Signs: How to Tell Your IFS Cloud Implementation Is in Trouble Before Your Dashboard Does

Sixty days after go-live, your dashboard says the implementation succeeded.

Work orders are closing. Login numbers look healthy. The steering committee got its green light and started meeting every other week instead of every day.

On paper, you made it.

Then you walk the floor, and it tells a different story.

Here is the thing almost nobody in an asset-heavy operation understands until it is too late. By the time an ERP implementation shows up as failing on a report, it has been failing on the for weeks. The dashboard is a lagging indicator. It measures what already happened.

The warning signs are a leading indicator. And they do not show up in a metric.

They show up in language. In what your people say, and in what they stop saying, long before anything turns red on a slide.

Sixty days is the moment to listen. Not because the problems start there. Because sixty days is the last window where they are still reversible.

Why 60 days is the window that matters

Give a new system to a workforce and the first few weeks are noise. Everyone is adjusting. Mistakes are expected. Nobody reads much into a rough first two weeks, and they are right not to.

But somewhere around day sixty, the adjusting stops and the settling begins. The team stops figuring out how they are supposed to work and starts deciding how they are actually going to work. Habits form. Workarounds find their footing. The gap between what the system was designed to do and what the crew actually does begins to set.

At sixty days that gap is still soft. You can still close it.

At ninety days it hardens. The workarounds stop being temporary and become how we do it here. And once something becomes how we do it here, you are no longer fixing an implementation. You are fighting a culture.

So the sixty day mark is not a checkpoint for congratulations. It is the last exit before the patterns lock in.

Here is what to listen for.

Warning sign 1: "The system won't let me" becomes background noise

Early on, this phrase is a real question. Someone hits a wall and asks for help.

By sixty days, watch what it becomes. A shrug. A thing people say to each other on the way to doing it a different way. Nobody is escalating it anymore, because escalating it the first three times changed nothing.

What it actually means, this is almost never a software limitation. It is a training gap. Your people hit a step they were never shown how to complete, found a way around it, and quietly stopped reporting the wall because reporting it did not help.

At sixty days these are still individual frustrations. Catch the phrase, trace it to the specific task, and close the gap with role-based training aimed at that workflow, and it never becomes a shared workaround. Wait, and it will.

Warning sign 2: A workaround gets a name

Listen for a proper noun that is not part of your system. The tracker. The real spreadsheet. The master list.

The day a workaround gets a nickname is the day it stops being a workaround and starts being infrastructure. A named thing has a maintainer. It has a constituency. People defend it.

What it actually means is the system is not capturing something your operation needs, so your operation built a shadow for it. Usually the system can do the job natively. Nobody was ever trained to see that it could.

The window at sixty days the named workaround is real but not yet load-bearing. You can still fold what it does back into the system before the whole crew depends on it. After ninety days, taking it away feels like taking away a tool, and you will get resistance you did not expect.

Warning sign 3: One person becomes the answer to everything

"Just ask Linda."

You hear it in the hallway. You hear it on the radio. Every question about the system routes to one person who happens to understand it.

You trained one person extraordinarily well. And the rest responded by never learning the system at all, because they did not have to. Linda was faster.

What it actually means. You do not have adoption. You have a single point of failure with a pulse. Linda is carrying the whole implementation on her back, and she is getting tired.

At sixty days you can still redistribute that knowledge deliberately, train a second and third go-to, and turn one overloaded expert into a support structure. If you wait until Linda burns out or leaves, the knowledge leaves with her and the floor discovers it never actually learned the system.

Warning sign 4: The questions stop

This is the most dangerous sign, because it looks like good news.

The support tickets drop. The hands stop going up in the stand-up. The floor goes quiet. Leadership reads that quiet as competence and relaxes.

It is almost never competence. It is surrender. People stopped asking because asking did not get them anywhere, so they went back to whatever worked before, off the system, out of sight.

What it actually means silence is not the same as adoption. Sometimes silence is a workforce that has given up on the system and stopped telling you.

At sixty days, silence is recoverable, because the people who went quiet still remember how the work is supposed to flow. Go ask them directly. Not in a survey. On the floor. At six months, the silence has become disengagement, and disengagement is a much harder thing to reverse.

Warning sign 5: Your data starts defaulting

Go read a sample of work orders your crew closed last week.

If they all say the same thing, completed, no further action, whatever the first option in the dropdown happens to be, you are watching your asset history get written as noise.

What it actually means your people are feeding the system the minimum required to move on. Not because they are careless. Because nobody ever showed them that the comment field they are rushing past is the only place decades of judgment can actually live. To them it is a box to clear. They were never trained on what happens to that data downstream.

Sixty days of thin data is a fixable habit. Twelve months of it is a corrupted baseline, and you will be making capital and reliability decisions on an asset record that was half invented at the end of a shift. The cost of this one compounds quietly, which is exactly why it is worth catching early.

Warning sign 6: New hires learn the workaround, not the system

Anyone you hired after go-live never saw the training. They learned the job by watching the person next to them.

Which means they did not inherit your system. They inherited your workarounds, as if the shortcut were the process.

This means the problem is now self-propagating. Every workaround that took root in the first sixty days is being taught to new people as the right way to work. The gap is no longer holding steady. It is growing on its own.

At sixty days, only a handful of your workforce came in post-go-live. Every week you wait, that number climbs, and each one is being trained wrong by default. Build onboarding that teaches the system before the floor teaches the shortcut, and you stop the spread.

Every one of these is an absorption problem, not a software problem

Read the six signs back to back and notice what none of them are about.

Not one is about the software.

The system is rarely the reason these implementations go sideways. The reason is almost always that the people who have to carry the system were handed it without the preparation to absorb it. They were trained on the screen, not on the job. Trained once, at go-live, and then left to figure out the rest in the middle of doing their actual work.

That is not a failure of your people. It is a gap in how the change was delivered to them.

And it is the gap that role-based, workflow-first training exists to close. Not training on where the buttons are. Training on how the work moves through their asset, their crew, their shift, so that when they hit the wall at 2am they understand what the system needs and why.

How to read the signs before day 60

You do not need a report to catch any of this. You need to be listening to the language, in the first two months after go-live, even before when the patterns are still soft.

That listening can be done by instinct. A good operations leader who walks the floor and asks the right questions will feel most of this.

It can also be done systematically. Reading these early signals deliberately, in the language and behavior of a team, before they ever reach a status report, is the core of the EPI-Change™ methodology we bring to client engagements. It is built to surface exactly this kind of readiness gap early, when there is still a window to act.

Stop waiting for the dashboard. Start listening.

Because the difference between a rough start and a failed implementation is not the size of the problem. Every implementation has problems.

The difference is how early you caught it. At sixty days, you still can.

Charlie Shephard spent more than twenty-five years in field service operations before becoming a consultant. CLER Solutions builds role-based IFS Cloud training and team enablement for asset-heavy organizations, so your people can do their actual job in the system on day one, and every day after.

If you are inside that sixty day window right now, the gap does not close by itself. Book a call and let's talk before the patterns harden.

Subscribe to Mission Critical for the field notes we do not publish anywhere else.