Welcome to the Zoo. Why Every Company Has One.

Welcome to the Zoo. Why Every Company Has One.

It was a workshop as typical as they come. The management team of a mid-sized industrial company had asked us to lay out the company’s entire digital tool landscape—before discussing the next IT project. The trigger was a gut feeling: something wasn’t working smoothly, but no one could clearly say what.

We kept it simple. An empty wall, yellow sticky notes, all department heads in the room. Each person wrote down which applications their area actively used—including Excel islands, homegrown databases, and department-specific SaaS tools. Three hours later, 47 notes were on the wall.

No one had known that number beforehand. Not them. Not us. Not even the Head of IT.

That wall wasn’t the result of poor leadership or lack of discipline. It was the result of twenty years of pragmatic, individual decisions. And that is exactly what this article—and the series it opens—is about.

What We Typically Find

We now run this “wall workshop” quite frequently. The exact numbers vary depending on company size and industry, but the pattern is remarkably consistent.

At the center are usually three to five so-called core systems: an ERP, a CRM, often a PLM or MES, maybe a BI solution. These are known to the responsible stakeholders, appear in official IT architecture diagrams, have formal license agreements, and clear ownership.

Around them sits a second layer: one to two dozen specialized tools. Product configurators, document management systems, reporting tools, engineering data tools, time tracking, travel expense systems, warehouse management. Some appear on the architecture map. Many do not.

And then there is a third layer—rarely documented, yet often carrying the most critical operational processes. Excel macros that have supported payroll for years. Access databases where sales managers built their own forecasting logic. SaaS tools subscribed to via credit card because the main system didn’t meet a specific need. Custom workflow tools that started as workarounds and became indispensable.

Above all this floats an interface soup: point-to-point connections, semi-automated data transfers, manual exports. Ask who is responsible for maintenance and data quality, and the answer is often fragmented.

Why Does the Zoo Exist?

Here is the most important insight we’ve gained from many workshops: there is almost never a single person to blame. And that’s exactly what makes the topic uncomfortable.

Twenty years ago, best-of-breed was the smart strategy. If you wanted a strong ERP, CRM, and PLM, you bought the best solution in each category—and accepted that they would need to communicate via interfaces. That was better than a monolith that did everything poorly. This logic shaped an entire generation of architectures.

Then come acquisitions, reorganizations, and new leaders with their own preferences. Every strategic shift leaves traces in the tool landscape. What a previous sales leader started with System A, the next wants to continue with System B—without shutting down System A, because legacy data and processes still depend on it.

And then there’s what we call the “quick win trap.” A single department has a specific problem, buys a specialized tool, and becomes productive within weeks. A success at the department level. No one asks what it means at a strategic level. Ten years and twenty such quick wins later—you have the zoo.

→ Every individual decision was right at the time. The sum, however, is not.

What Does the Zoo Really Cost?

This is the part most executives underestimate—not out of naivety, but because the costs are distributed and hidden. Three effects stand out.

1. License costs—significantly higher than necessary

In most assessments, we find unused modules, full licenses assigned to occasional users, and duplication where two tools essentially do the same thing. A systematic license analysis almost always uncovers six-figure annual savings—sometimes seven figures in larger mid-sized companies. These savings are often the fastest way to even start an architecture discussion, because they deliver immediate ROI.

2. Employee efficiency—quietly eroded

Duplicate data entry, manual consolidation across tools, training overhead for an ever-growing toolset, waiting times caused by interfaces. These costs don’t appear as a single line item—but they add up to a meaningful portion of personnel costs. Companies that take the effort to quantify them are often surprised to find they exceed license costs.

3. Innovation drag

The real strategic damage doesn’t show up in financial statements. Every new idea—a new report, an adjusted process, an integration with a new partner—gets stuck on the question: where does this fit? What should take two weeks turns into a six-month architecture project. In a market where speed is a competitive factor, this is the most expensive consequence.

And perhaps the most costly symptom of all: broken data quality. We regularly encounter companies where the same customer has three different addresses across CRM, ERP, and service tools—and no one knows which is correct. Promoting customer centricity or data-driven decision-making in such an environment addresses the problem at the wrong level.

The Real Problem

For all of the above: the zoo itself is not the problem. The problem is that no one ever designed the architecture as a whole. It simply happened.

Most companies have an org chart, a strategy paper, a sales strategy, a product roadmap—but no comprehensive map of their tool landscape. As consultants, we see this so often that it has become a default diagnosis.

→  The zoo is not the problem. The problem is that no one knows what each animal does anymore.

And here’s where it gets uncomfortable—even for us as consultants. We are often complicit. We are called in to solve a specific problem in a specific area—and we do. We replace the ERP. We extend the CRM. We integrate a new platform. Rarely do we ask: wouldn’t the more important assignment be to question the overall architecture before adding another system?

This series is our attempt to do exactly that. Publicly. Before the next project.

What Comes Next

In Part 2, we allow ourselves a thought experiment: if we were to design a new tool architecture for a typical mid-sized company from scratch today—what would it look like? Which platforms? Which principles? What has fundamentally changed since the 2000s?

In Part 3, we tackle the inevitable question: what does the AI wave mean for this architecture? Should we build everything ourselves because it’s becoming cheaper? What makes sense today—and what new risks come with it?

In Part 4, we look at a cost-optimized symbiosis: the honest mix of standard platforms, low-code, and AI-driven custom solutions that we currently consider the most economical architecture—including licensing pitfalls and total cost of ownership over five to seven years.

And in Part 5, we return to reality: how do you move from the zoo to a greenfield architecture without a big bang and without disrupting day-to-day operations? This is where the practical core lies—and where we outline the approach we use to guide such transformations.

For now, the most important question is this:
When was the last time you mapped your company’s tool landscape on a wall? And what number would genuinely surprise you?