You sign up for an ERP transformation because of the view from the other side: cleaner data, faster closes, processes that don't live inside three people's heads. It's worth it.
One thing you rarely hear in the sales cycle or at kickoff, though: it gets worse before it gets better. Productivity doesn't jump on go-live day. It dips. Every routine your team ran stops working the way it used to. Everything is new. Some of that surfaces on day one, some midmonth, some in the first close. For a few weeks everyone is slower (and grumpier) than they were the month before. The dip is part of every project.
Every project has the same curve
We've never seen a software go-live avoid it. You can't turn on a new system and ask people to develop a new set of habits without paying for it in productivity first, and your strongest people pay right along with everyone else. It's a question of jumping out of your familiar grooves.
Whoever runs your finance operation today has years of those grooves, processes they've done hundreds of times without thinking about them. That fluency is how they get good results out of a crusty system, and it's the exact thing a transformation tears up. The project team comes in and re-cuts the grooves, and for a while old habits fight the new way of doing things.
Ironically your newest people usually have the easiest time. They haven't worn their grooves deep yet, so there's less to undo.
Whatever it feels like, the dip is what change looks like while it's happening. If you're feeling it, the thing is working.
Why we call it despair
The valley itself isn't an issue per se. The problem is the implementer who takes you to go-live, celebrates the win, and moves onto the next job while your productivity is still sliding downward. You get left at the bottom on your own, and that's how a valley turns into despair.
The depth of your valley gets decided before you ever feel it, by who you pick to cross it with you. So ask any firm you're evaluating one question: what happens a month after go-live? The ones who only have an answer for launch day are telling you where they'll be when the floor drops out.
The same valley can be two different trips
You're going through it either way. There's no path around, same as there's no way to get good at anything without being bad at it first. But not every valley is the same size.
A good one is shallow and narrow. You're a little lower for a cycle, and then you're climbing back out. A bad one is a canyon, where the floor falls away and you can't see the other side.
How deep your valley gets, and whether you're stuck alone at the bottom, comes down to three things a partner does. Two of them set the shape. The third decides who's in it with you.
Design. The less your team has to relearn, and the fewer ways there are to screw it up, the shallower the valley. Good design routes the work down a handful of clean paths and rips out the one-off processes that collect in every old system like cobwebs. When there's one obvious way to do something instead of nine you inherited, people get their footing back faster.
Training. By go-live your team should be performing, not rehearsing for the first time. You put them in a sandbox first and make them work through the real steps by hand, with no live customers, no real money, and no one's job riding on it. The reps they get there are what keep them steady once they're doing it for real under pressure.
Enablement. This is the guide who walks you through the valley and away from despair. We stay after launch instead of packing up. We sit with your team, catch every "this doesn't work how we thought it would," and drop each one into one of two piles. One pile hurts because it's new, and it gets better on its own once people get used to it. The other pile hurts because we built it wrong, and that's a bug we go fix. We've had users call us on day one screaming "everything is broken!" only to get on a Zoom with them and resolve their issue with a single click. Sorting real issues from "everything is new and different!" panic is most of the job at go-live.
Running two systems at once
You almost never move a whole operation over in a single night. The clean break is often for new work. Anything already in motion completes in the old way. So for a while (sometimes months), you're on both at once. Old projects wrap up the old way, new ones start the new way, and everybody in the middle is working in both worlds at the same time. This is temporary. The last old project finishes, the old system goes quiet, and the team gets to live in one place again.
It's fine if you're mad at us
We tell every client this straight, before we start: for a while the job is going to feel harder, and you and your team are going to be mad at the people who did this to you. Good. That anger is the fuel the whole thing runs on. Every complaint that comes out of it is a piece we can sort. When your controller corners you sure we broke something, that's the work happening out loud. Bring it to us and we'll tell you which pile it lands in, and whether it heals with reps or gets a fix.
It helps to make it smaller in your head, too. Nobody's launching a rocket here. Whatever breaks on day one, everyone's still breathing at the end of it. It's fine to hit something that doesn't work, or do it wrong, or not have it figured out yet. That's what the first few weeks are for.
Final thoughts
The valley is what you pay for the view. You don't get to skip it, and anyone who tells you otherwise is lying. The only things you get a say in are how rough it gets and who's down there with you.
Getting you live is the easy part. The partner worth having is the one still standing next to you at the bottom, helping you climb the other side. Get the plan, the prep, and the people right, and it stays a valley. You can leave the despair out of it.
