How to prepare for a new EPM solution (or a switch)

· EPM

EPM projects rarely fail on the software - they fail on preparation. A practical readiness guide covering process, pain points, data quality, people and scope, before you configure a single cube.

Most EPM projects that go wrong did not go wrong at go-live. They went wrong months earlier, in the preparation, or the lack of it. After years of building planning, consolidation and reporting on Jedox, the pattern is consistent: the software is rarely the hard part. The hard part is the process nobody wrote down, the data nobody profiled, the owner nobody named, and the scope nobody defended.

So this is a readiness guide for finance leaders and FP&A teams about to bring in a new EPM tool, or replace one that has stopped serving you. It leans hard on the unglamorous parts - process, pain points and data - because that is exactly where projects are won or lost. If you only take one thing from it: the preparation is the project, and the configuration is the easy 20% at the end.

1. Start with the process, not the platform

New tooling is a magnifier. Point it at a clear process and it makes finance faster and calmer; point it at a mess and it makes the mess faster and harder to change. (I've written separately on why process comes before platform - this is the practical version.)

Map the process as it actually runs, not the org-chart version. The documented process and the real one are almost never the same. The real close and budget cycles live in shadow spreadsheets, side emails, and the one analyst who "just knows" how the allocation works. If you gather requirements only from managers describing the ideal flow, you build for a process that does not exist. Sit with the people who do the work, during a real cycle, and capture every spreadsheet opened, every file emailed, every manual keying step, and who does it when. A swimlane per process, with handoffs and timing, is worth more than any slide deck.

Document pain points and their root cause, not just the symptom. "The close takes 12 days" is a symptom. Keep asking why until you hit the cause: late data from source systems, a manual FX step, intercompany that only reconciles at consolidation, or one CFO who signs off everything. This matters because the tool fixes some causes (recalculation, workflow, audit trail) and is powerless against others (dirty source data, unclear ownership). For each pain point, write a short "5 whys" chain and tag the root cause: fixable by tool, fixable by process, or fixable by upstream data. Only the first becomes a tool requirement. The rest are dependencies you must solve in parallel, or the pain survives go-live.

Do not pave the cowpath. The single most common failure is lifting a broken, spreadsheet-era process and faithfully rebuilding it inside the new tool, now with the same 40-tab logic, just locked in and harder to change. A tool project is your rare licence to redesign: kill the reconciliations that only exist because two systems disagreed, collapse redundant approval layers, and standardise your account, entity and driver structures before anyone builds a cube.

Automating a bad process only gives you a faster bad process that is harder to fix.

Turn pain points into prioritised, testable requirements. Pain points are anecdotal; requirements must be specific and verifiable. "We need better reporting" is not a requirement. "FP&A produces the actual-vs-budget variance pack by entity within one day of close, with drill-to-transaction" is. Prioritise ruthlessly with MoSCoW (Must / Should / Could / Won't), because every pet report is a "must" until someone has to defend it against the timeline. Keep a single requirements register where each row traces back to a business pain, has a priority, an owner, and an acceptance test. If a requirement has no acceptance test, it is a wish - send it back. And guard your "Won't do" list as fiercely as your must-haves; it is your scope shield.

2. Get the data honest

This is where readiness succeeds or fails, and it is almost always underestimated. An EPM tool is a mirror: feed it clean, well-owned data and it reflects the truth; feed it garbage and it reflects garbage, and everyone up to the board will see it.

Profile every source before you design anything. You cannot model data you have not looked at. Before a single dimension is built, run a structured profiling pass on every feeder: the ERP/GL, subledgers (AR, AP, fixed assets, payroll), HR, and the pile of spreadsheets people actually plan in. You are hunting for row counts, distinct member counts, null rates, orphaned codes, duplicate keys, inconsistent date and currency formats, and how far back usable data really goes. In practice the spreadsheets are often the real system of record for planning while the ERP only holds actuals, so profile both, or you will discover the gap during UAT. Produce a one-page profile per source (owner, extraction method, refresh frequency, volumes, quality issues) and get the source owner to sign it.

Design dimensions around reporting need, not the ERP structure. The biggest structural mistake is cloning the ERP chart of accounts and cost-centre tree straight into the EPM tool. The GL is built for statutory posting; your model needs analytical hierarchies, alternate rollups, and a clean split between base and calculated members. Design the target dimensionality (entity, account, cost centre, product, time, scenario, version) deliberately, then build mapping tables from ERP codes into it. That mapping seam is also what saves you when the group later restructures or acquires a company on a different chart.

Clean at the source, not in the load layer. Every project is tempted to patch dirty data inside transformation scripts because it is faster. That debt compounds: the ERP keeps emitting bad data, your load silently fixes it, and nobody upstream ever learns. Decide explicitly per defect: fix at source (preferred for master data) or normalise in the load (only for genuine format issues), and log anything patched with an owner and a date to fix it properly.

Treat mapping tables as living master data. New GL accounts appear every month. If nobody owns the maps, loads silently drop unmapped records and your numbers quietly drift. Route every unmapped member to a visible "Unmapped" suspense bucket with a rejection report, never let it fail silently, and make reviewing that bucket a standing item on the close checklist.

Name the single source of truth per domain. "Single source of truth" is a slogan until you assign it. Actuals truth is the GL. Headcount truth is HR. FX truth is treasury. The EPM tool becomes the source for plan, forecast and consolidated management reporting, not for everything. Write a one-line ownership statement per domain and get finance leadership to confirm it before build.

Load the history you need, archive the rest. Bringing ten years in "just in case" bloats the model, slows every calculation, and drags a decade of data-quality sins into a clean system. Two to three years usually covers trend, seasonality and prior-year comparatives; older periods often predate your current chart anyway. Ask reporting exactly which historical comparatives appear in live reports and load only that, plus a buffer.

Lock a reconciliation baseline so you can prove the new system ties out. The moment that kills go-live confidence is when the new system produces a number that does not match the old one and nobody can explain why. Before migration, freeze a closed period's output at several levels (total P&L, per entity, per major account), and make matching it the explicit acceptance criterion. Reconcile top-down, then drill to where any variance lives, and document every legitimate difference (rounding, FX, deliberate mapping changes) so a variance is a known decision, not a mystery.

No green reconciliation, no cutover. The recon workbook is your go-live gate, not a formality.

3. People decide whether it sticks

Technology rarely sinks these projects. People do. A tool switch asks finance to give up something familiar, and that is a change-management job long before it is a technical one.

Get a sponsor who owns the budget and the pain. The best predictor of success is an executive sponsor whose planning cycle is personally broken, usually the CFO or a VP of Finance. Their real job is to unblock cross-functional data access, break scope ties, and publicly signal that the new tool is not optional. A sponsor in title only, who never shows up, is worse than none. If IT is sponsoring an FP&A tool, that is already a red flag: the pain owner and the budget owner are different people.

Name one empowered decision-maker, not a committee. Projects stall on design decisions: how many cost-centre dimensions, driver-based or line-item, what the account hierarchy looks like. If every call needs consensus across five department heads, you miss every milestone. You need one business decision-maker who can settle 80% of design questions on the spot and escalate only the genuine 20%. Keep a light, one-page RACI, and enforce exactly one Accountable per decision.

Two names in the Accountable column means nobody is accountable.

Separate process owners from data owners, and name both. The process owner owns how a cycle runs and signs off that the model reflects reality. The data owner owns a source and is accountable for its accuracy and timeliness. When actuals do not tie out at go-live, it is almost always an unnamed or disengaged data owner upstream. Naming them early forces the uncomfortable data conversations into month one, not UAT.

Embed super-users during the build, not at go-live. Two to four respected practitioners who co-own the model become your evangelists and your first line of support. Handed a finished tool in the final week, they are just end users with a bigger login. Give them protected time (15-25% of their week, in writing, with their manager's agreement), or you get neither a super-user nor their day job.

Retire Excel, do not bash it. Excel resistance is about control, speed and fear of looking incompetent in something new. Acknowledge what Excel did well (flexibility, familiarity) and be honest about what it cost (no audit trail, version chaos, key-person risk, days lost to consolidation). Then draw a firm line: shadow spreadsheets that replicate the system of record get actively retired, not tolerated in parallel.

Parallel Excel is not a safety net. It is how the implementation quietly gets abandoned.

Train around real tasks, at real timing. A feature tour three weeks before go-live is theatre. Effective enablement is role-based and just-in-time, on your own data, and reinforced by sitting next to users during the first real cycle. Assume people need training again when the live cycle actually hits, and budget for it.

Measure adoption, not go-live. Going live is a milestone, not success. Success is sustained use: people planning in the tool, shadow-Excel traffic dropping, the cycle genuinely faster. Agree three or four adoption KPIs at kickoff (cycle time, active users per cycle, spreadsheets retired, on-time submission rate) with a baseline you can beat, and put a 90-day post-go-live review on the calendar with the sponsor's name on it.

4. Choosing the tool (or the switch)

Write requirements before you watch a single demo. Vendors win with demo theatre: slick canned scenarios on clean data that quietly reframe your needs around their strengths. Walk in with a weighted scorecard of 20 to 40 concrete requirements and make every vendor demo against your scenarios, not theirs. You will buy what you need instead of what they demoed well.

Insist on a proof of concept on your real data and your ugliest use case. Every tool looks good on the vendor's tidy sample cube. The truth comes out when you load your actual chart of accounts, your 14-level product hierarchy, your messy intercompany eliminations. Make finalists build your two hardest use cases in a time-boxed POC with your extracted data. If a vendor resists a paid POC on your data, that resistance is your answer.

Price the total cost of ownership, not the licence sticker. Over five years the licence is often the smallest line. Implementation (commonly one to three times first-year licence), an admin owner, maintenance uplift, infrastructure, and the inevitable phase two all dwarf it. Model TCO over five years and compare finalists on the total.

Phase it: MVP first, big-bang never. All entities, all processes, all reports on day one is how you burn 18 months before delivering a single win. Ship one valuable, defensible slice into real users' hands in a quarter, build credibility, and learn the tool before you scale. And time the plan against your team's real capacity, not the integrator's Gantt chart - the binding constraint is almost never the software, it is your finance team's bandwidth to define logic and make decisions.

Treat every customisation as a future upgrade tax. Bending the tool to mirror your old spreadsheet exactly, quirks and all, creates the thing that breaks on every upgrade and that only one person understands. Favour standard, configurable functionality; make each deviation earn its place in a customisation register with a justification and a standard-functionality alternative.

5. If you are replacing an existing EPM

Switching tools carries its own trap, because you are haunted by the reasons for the last migration.

Write down why you are leaving, first. If you cannot name the specific failures of the incumbent (slow close, unmaintainable rules, no version control, a single hero who owns everything), you will unconsciously rebuild them because they feel familiar. Run a blameless retro, produce a ranked one-page "reasons we are leaving" list, and re-read it at every scope decision.

Migrate the intent, not the artifacts. A new tool is your one licensed chance to kill complexity, and that window shuts the moment you promise "it will work exactly like before." For every legacy report and model, force a written verdict: KEEP (redesign clean), KILL (prove nobody uses it), or MERGE. Get a sponsor signature on the KILL list so it cannot quietly resurrect.

Excavate tribal knowledge before the people leave. The dangerous logic in an old system is never in the documentation. It is in a macro, an undocumented allocation, a hard-coded FX override, or the head of one analyst. Interview the two or three people who actually run the incumbent and build a rules register of every calculation, allocation, adjustment and manual override, with its business reason. Treat "I'm not sure why we do that" as the start of an investigation, not an acceptable answer.

Run parallel and reconcile to the number. You do not trust the new system because it is new. You trust it because it tied to the old number for two or three cycles running, to an agreed tolerance. Parallel run is where the undocumented rules you missed finally introduce themselves as variances. It doubles the workload for a period, which is exactly why teams skip it and exactly why skipping it detonates at the first board pack. Budget for the double-run explicitly.

Freeze scope during cutover, and plan the decommission. You cannot reconcile a moving target, so no "while we're in here" enhancements during changeover; they go to a post-go-live backlog. And a migration is not done at go-live, it is done when the old system is safely dark and its data archived per your retention and audit obligations. Set a hard decommission date tied to a clean close plus sign-off, and confirm the archive is actually restorable before you cancel the licence.

6. The things teams forget

A veteran refuses to start without these, and they are the items most often skipped:

A readiness checklist

Before you sign the statement of work, you should be able to point to:

None of that requires the software to be chosen yet. That is the point. Get the process, the data and the people right, and any decent EPM tool will succeed. Get them wrong, and the tool will not compensate. The build is the easy part - if you have done the hard part first.

Back to all posts