Fix what's broken. Or rebuild what should have been.
Some Anaplan and Pigment models can be saved. Some can't. Before we quote anything, we tell you which one you're looking at, and why.
By the time a company calls us about a broken implementation, the model has usually stopped working for a while.
The team knows. The person who built it is tired of holding it together, numbers get double-checked in spreadsheets, and faith drains quietly while everyone waits for someone else to say the platform was a mistake. That statement usually comes late.
There are two honest paths from where you are. Rescue the model when the foundation is sound and the failures are fixable. Rebuild it when the architecture was wrong from day one, when the business has moved beyond what the model can hold, or when the users have already given up on it.
A rescue that should have been a rebuild is worse than either. So we start with the diagnostic, before we scope anything else.
Five questions that decide it
Most rescue-or-rebuild calls come down to how these five questions land. We answer them before we quote anything, so you know what you're actually buying.
Dimensions, hierarchies, and calculation flow. If the foundation matches your business, rescue is possible. If the model treats regions as products, or shoehorns your sales team into a hierarchy that doesn't match how you actually sell, the foundation isn't there to build on.
A model nobody understands is not a rescue candidate. Documentation, whether the original build team is reachable, and how much the current owner actually comprehends all matter. If the model is a black box, the first phase of a rescue is reverse-engineering it, and at that point you're paying for most of a rebuild anyway.
Businesses change faster than models. A build that fit the org three years ago might be wrong for the one you have now. If the business has moved beyond what the model can flex to, no amount of patching brings it back into shape.
If the team has already given up and rebuilt everything they need in Excel, a rescue is technically possible and practically dead on arrival. Sometimes the political cost of asking users to trust the platform again is higher than starting fresh, and that reality has to be part of the call.
If the data coming from your ERP, CRM, HRIS, and payroll matches what the model needs, the integration layer is usually rescuable. If the data was mapped wrong at the source, the integration layer is a rebuild whether the top of the model is or not.
What each path actually looks like
Two engagements with different scope, timeline, and risk. Same senior consultant on both.
What we doDiagnose the specific failures, fix them in place, validate against known numbers, document what's now working, retrain the team on the parts that changed.
- Architecture stays
- Integrations preserved where they work
- Broken calculations rebuilt correctly
- Documentation brought current
- Team retrained on the fixed model
When it worksThe foundation is sound, the business hasn't outgrown the model, and users are still willing to trust the platform once it stops breaking.
What we doTake what your team learned from the failed build, redesign the model to fit the business you actually have, build it in phases you can see, and hand off with the documentation missing the first time.
- Architecture designed from scratch
- Integrations rebuilt to fail loudly
- Model designed to flex with the business
- Users involved as the build takes shape
- Handoff planned from day one
When it's honestThe architecture was wrong, the business has moved, the team has given up, or the political cost of the current system outweighs the cost of starting over.
How we work when the model is already broken
A rescue-or-rebuild call is where the incentive to oversell is highest. Four things we do that other firms don't.
A rescue is less revenue than a rebuild. If we say your model can't be saved, it's because it can't. We'd rather do a rebuild we can stand behind than a rescue that fails a second time. The diagnostic is honest work, and it stays honest even when the honest answer costs us the smaller project.
Sometimes the honest answer is that you're on the wrong platform. If Anaplan is fighting your use case, we'll say so, even though we build in Anaplan. Same for Pigment. We hold no reseller agreement with either vendor. The rescue-or-rebuild call is never a platform-loyalty call.
The person who tells you what's wrong is the one who fixes it. There's no diagnostic team followed by a delivery team followed by a handoff. Same person, same context, from the audit through go-live. Which is the only way the diagnostic actually means anything.
Rescue or rebuild, you leave the engagement with documentation you can actually work from, training on your model, and a team that can maintain it. If you'd rather we stay on for managed services, that's a choice, not a dependency we engineered. The whole point of fixing a broken build is not to end up in the same position again.
Complex builds that held up
Evidence of the depth we bring to models that other firms would have called too complex, too messy, or too far gone.