From Spreadsheet Chaos to Strategic Command:

Every enterprise planning horror story starts the same way: "We were doing it in Excel."

This one was no different. Our client is one of the largest HR and workforce outsourcing firms in Europe, managing around 3,000 employees and thousands of outsourced workers across the region. They had SAP as their source of truth for operational data, and they had Excel for everything else.

Planning? Excel. Forecasting? Excel. Scenario modeling? Excel, with extra steps and a prayer that no one saved over the wrong tab. Reporting to the parent group in another country? Export the data, manually remap it to fit headquarters' format, attach to email, send, and repeat next quarter.

There was no version control. No single source of truth for agreed-upon targets. No audit trail worth the name. When decisions were made, the supporting numbers lived in someone's personal spreadsheet on a local drive. Whether that spreadsheet was the final one was, in practice, a matter of faith.

It's worth noting that this wasn't a small or unsophisticated company. They knew the problem existed. They knew Excel wasn't a planning system. What they didn't have was a clear path out that didn't involve months of requirements work with an implementation partner who had never dealt with workforce planning at this scale, or who would arrive with a templated product and spend the engagement trying to make the business fit the software rather than the other way around.

That's where we came in. And unlike a lot of implementations in this space, we started with a blank page.

This was not an optimization project. There was nothing to optimize.

When we came on board, initially alongside a management consultancy handling requirements and stakeholder alignment, the mandate was straightforward: build a modern enterprise planning platform from scratch, for a business that had never had one.

That meant four things.

A complete ETL pipeline. We designed and built a full data ingestion and transformation layer, pulling from the client's ERP system, cleaning it, structuring it, and loading it into TM1. Apache Airflow became the orchestration backbone, our first deployment of Airflow at this scale, and a capability that has since carried over into other engagements.

A multi-dimensional planning model. The TM1 model handles workforce planning across thousands of employees: individual target-setting, performance ratio configuration, compensation outcome modeling, rolling forecasts, and scenario simulations. All queryable, all auditable, built to support up to 500 concurrent users without performance degradation.

A fully custom front-end. TM1's native interface works. It's not something users tend to enjoy. We built a JavaScript-based UI layer on top: clean, role-aware, with predefined filters, real-time simulation previews, and immediate target feedback. The goal was zero training overhead for new users, and we got close.

A downstream data mart for reporting. Every relevant output gets exported to a SQL layer, from which the client's BI team pulls into their own visualization platform. We own everything up to that handoff. What happens downstream is theirs.

The management consultancy stayed for roughly the first year, then left. Since mid-2022 we've been the sole external partner on the project. At this point we know their data, their processes, and their organizational logic better than most of the people inside the company do, and we mean that literally: stakeholder turnover has been high enough over five years that we've outlasted the majority of the original project team on the client side.

There's one process at this company that used to define a particularly painful stretch of the financial year: the annual budgeting cycle.

Each year, the business sets individual performance targets for all employees. These aren't simple numbers. They involve two configurable target levels, performance ratios between those levels, and compensation outcome modeling tied to achievement. The whole thing cascades through a management hierarchy from team leads up through business unit heads. It's genuinely complex, and it involves a lot of people who all need to contribute data on a tight timeline.

In Excel, this process took two to three months.

In the current system, it takes three weeks. And even that is mostly constrained by human factors: deadline stragglers, approval chains, the kind of coordination overhead that no software can fully eliminate. The system itself could theoretically compress it to one or one-and-a-half weeks if everyone moved at the same pace. They don't. Three weeks it is, and three weeks is still a 4-6x improvement on a process that used to consume an entire quarter.

For the roughly 30 daily active power users, the efficiency gains show up differently. Our conservative estimate is that what they now do in a day would have taken twice as long without the system. Across a full year, for 30 people, that's a significant number of hours redirected toward work that actually requires human judgment.

Here's something that wasn't in the original project requirements: the new system made every dirty data problem in the source ERP visible almost immediately.

Before, a miscategorized entry or a structural error could sit in SAP for months, quietly distorting downstream reports. Nobody caught it because nobody had a system that could surface it. Errors were invisible until something downstream stopped making sense, at which point the investigation was already time-consuming.

Our ETL pipeline and data model are built with rigorous validation logic at every stage. Now, errors typically surface within a day or a week of being introduced. The ERP team finds this less comfortable than the business does.

This is worth saying clearly: data quality didn't improve because we fixed anything in the source system. It improved because the new layer made problems impossible to ignore. When there's nowhere for an error to hide, it gets fixed faster. That's a governance benefit that never appeared in any requirements document, but it shows up consistently in how confidently the finance team now presents its numbers to leadership.

When this project started, the client maintained a team of three to four internal IT people dedicated to supporting and managing the engagement. Today that's down to one product owner, whose job is gathering business requirements and managing internal alignment.

Everything else is handled by us.

That reduction represents roughly a quarter-million euros per year in internal cost that no longer needs to exist. And it's not a soft saving. The headcount went away. The cost went away with it. There's no asterisk on this one.

It's also a meaningful signal about how the relationship has evolved. When a client can reduce their own IT involvement to a single coordinator and the system keeps running smoothly, that's not dependency. That's trust backed by a track record.

Five years in, the client would face a genuinely difficult situation if they ever wanted to switch providers.

Not because we've made it artificially complicated. Because the system is the institutional memory of how this business plans. We built the data model. We know how their data flows from SAP through the ETL layer into TM1. We understand how their organizational structure maps to their planning logic, and we've tracked every change to that structure over five years. The current internal stakeholder team? Most of the original people are gone. We're the continuity.

Replacing the platform with something off the shelf wouldn't be technically impossible. You could do it. But you're realistically looking at 18 months to two years of rebuild time, and that estimate assumes you can extract the institutional knowledge from the team that built the current system and translate it into requirements a new one can work from. That process is harder than it sounds, and the knowledge loss in translation is real.

This isn't vendor lock-in through obscurity. It's the natural result of building something highly specific to one organization's needs, over five years, with a team that has stayed consistent throughout. The client's leadership understands that. They've also seen what the alternative looks like.

Not every business is a natural fit for what we build. This one was, and the reason comes down to one structural feature: they practice bottom-up planning.

Rather than top management setting targets and pushing them downward, this company aggregates real input from hundreds of sales representatives and team leaders, builds that into a company-wide financial plan, and treats it as something the whole organization has a hand in. That's a fundamentally different planning model from the top-down approach, and it has very different software requirements.

When you have hundreds of people contributing to a single plan, the quality and usability of the tool they use is not a secondary concern. A clunky interface produces support tickets. An unintuitive workflow produces errors. A slow system produces workarounds, and workarounds produce Excel, and Excel brings you back to where you started.

Our stack handles this well. TM1 manages complex multi-dimensional models at scale without slowing down under concurrent load. The custom front-end keeps onboarding fast, which matters considerably in an industry where annual employee turnover can run 20 to 30 percent. New representatives need to be productive in the system quickly, ideally without a dedicated training session, and that only happens when the interface is designed with them in mind rather than with the system's architecture in mind.

The right candidate for a system like this is any organization with a large, distributed contributor base and a genuine need for a plan that reflects ground-level reality, not just what the top floor decided to hand down. That profile is more common than most companies admit. It shows up in HR firms, in insurance businesses with large field sales teams, in manufacturers with dozens of cost centers, in any organization where the plan is only as good as the input from the people closest to the work.

The difference between those companies and the ones still running annual planning in Excel is usually not awareness that a better approach exists. It's whether they've found an implementation partner capable of building it for their specific situation rather than selling them something that was built for someone else's.