The Assembly-Line Implementation Trap: Why Tech Consulting Stopped Understanding the Business

A script that keeps repeating

Two senior partners sign your contract. They show up at the kickoff meeting, have a coffee, talk strategy, global best practices and transforming your company. The following week you never see them again.

The project is left to three recent graduates — or juniors with a couple of years of experience — who have enough trouble figuring out how to log their own hours in the consultancy's system. Their job is not to think about your business; it is to close development tickets before Friday to hit the end-of-month billing milestone.

Six months later they deliver the platform. They run a presentation where everything seems to work, show a couple of screens with test data, get the acceptance form signed and move on to the next account.

The problem shows up the next morning.

The sales team keeps using its spreadsheets on the side because the new screen asks for twenty data points nobody cares about. Operations receives duplicated tasks. Management can't pull a decent report without asking an analyst to cross-reference three Excel files over the weekend. And leadership discovers it is paying thousands of dollars a year in licenses for software the team dodges every chance it gets.

That is not an accident of your project, and you didn't have bad luck with the vendor. It is how the traditional consulting industry is built.

The economic model nobody tells you about

To understand why consulting stopped understanding the business, you have to look at how the big system integrators make money.

Their profitability does not depend on your company working better or increasing your margin. It depends on an internal metric called the utilization rate: selling as many development hours as possible at the lowest possible staffing cost.

In that scheme, sitting down to review the client's processes is terrible business for the consultancy.

If a company arrives with a confusing sales process, ten approval levels that make no sense and discount rules that change depending on who you ask, the traditional consultancy has no incentive to question any of it. Questioning it takes time, hard conversations with managers who don't want to change how they work, and genuinely experienced people at the table.

It is much easier and more profitable to take that mess as-is and put it into code. The more complex, tangled and full of custom exceptions the build is, the more hours get billed. If halfway through they discover the rule was poorly designed, even better: a change order is issued and a hundred more hours are billed to patch the screen.

They end up programming the chaos. The technology doesn't fix the process: it just makes it more expensive, slower and harder to change in the future.

What happens when you configure without understanding

We have spent more than 6 years watching software projects from the inside, and one constant never changes: the software is almost never the cause of failure.

Modern tools like those in the Salesforce ecosystem can solve virtually any sales, operations or customer service flow. They have the flexibility to adapt to almost any industry. What fails, almost always, is the lack of judgment before touching the tool.

Consider a common scenario in B2B companies. A sales team wants to speed up quoting because customers wait a week to receive a formal price.

The software factory sends an analyst to gather requirements. The analyst asks: "Which fields do you want on the screen, and who should approve a discount?". The company answers with what it has been doing for ten years: discounts over 5% need the regional manager's approval, and over 10% the sales director has to sign. The consultancy goes and programs that exact sequence with validations and automated emails.

The result? Quotes now take ten days instead of seven. The system instantly notifies two executives who were already buried in meetings and have now become digital bottlenecks. Salespeople, to avoid losing the sale, learn to split orders into two smaller invoices or agree on terms outside the system.

A business architecture consultancy asks a different question before configuring anything: "Why does a 5% discount need a director's signature? What is the real margin on that product, and how many of these requests were rejected last year?".

When you look at the numbers, you almost always discover that 95% of those requests were being approved on autopilot without anyone looking at the data. The solution was not building a complex approval flow in the CRM; it was giving the salesperson direct discount authority under clear rules and eliminating the need for human approval in most cases.

Configuring screens or creating fields is the easy part; any professional with basic technical training can do it. The hard part is sitting down with leadership to discuss commercial policy, showing where the company loses time and simplifying the rules before putting them into a system.

The "silent" cost inside the company

When a technology project is dispatched like an assembly line, the cost is not just what was paid to the consultancy. The real cost starts being paid every single day after the consultancy leaves.

A silent friction appears on several fronts:

• In the sales force: Salespeople perceive the CRM as a bureaucratic burden created so management can control them, not as a tool that helps them sell more. They spend hours filling in required fields at the end of the week just to comply, loading junk or incomplete information.
• In the internal IT team: The company's technology department inherits a "spaghetti" of custom code, poorly documented automations and patches that break every time an update is needed. The team goes from innovating to firefighting.
• In leadership: The C-suite keeps receiving contradictory reports. Marketing shows lead generation metrics, sales shows a pipeline that never closes, and finance looks at completely different numbers in the ERP. The promise of the "unified customer view" turns into weekly arguments about which spreadsheet has the right number.

When a project's priority is closing development tickets to meet an artificial timeline, the technology becomes an expensive decorative layer on top of the mess the company already had.

Why we built Zarasa differently

Against that market inertia, in 2020 we decided to structure Zarasa on a different premise.

After years of experience advising corporate organizations on their technology projects, Mathias Möller and Dagoberto Suarez knew the market did not need another consultancy selling thousands of hours of mass development with rotating teams. It needed an experienced team, able to get involved in the client's reality without intermediaries.

This stance is not a marketing slogan; it is a concrete decision about how we work:

Deciding not to operate as a mass factory is a decision about the quality of the deliverable. The moment a consultancy prioritizes account volume, it loses the ability to get involved in the operational details that actually determine whether a project works or not.

From our base in Uruguay, working with clients across sectors throughout the region, we confirm every day that the true value of a technology partner is not in the amount of code it writes, but in the sobriety of the design: simple, structured, easy-to-maintain solutions the company can adopt and sustain over time without being held hostage by anyone.

The tool as a consequence, not a starting point

Being specialized as partners in the Salesforce ecosystem (from Sales Cloud and Service Cloud to Data Cloud, MuleSoft, Tableau and Agentforce) gives us the technical capacity to solve complex architectures. But the tool always comes second.

The real work starts long before opening the platform. It starts by understanding the operating mechanics of the business:

1. How do sales actually come in and close? Not what the process manual written five years ago says, but what your best-performing salesperson does today to unblock a negotiation.
2. Where are the real bottlenecks? Identifying which decisions stall because of internal politics, missing data or duplicated tasks across areas.
3. What information lives in people's memory and not in the organization? Detecting the critical points where the operation freezes if a key person gets sick or goes on vacation.
4. Which metrics does leadership need to decide without guessing? Eliminating the excess of vanity indicators and focusing on the data that moves margin, retention and execution speed.

When you work with this level of clarity, implementing technology stops being a traumatic event and becomes an exercise in bringing order. The software stops feeling like an imposed obligation and starts working as the natural infrastructure that supports the operation.

Maintaining operational clarity

Evolving project after project demands the discipline of giving up easy volume to focus on solid results.

The companies that endure are not the ones that buy the most licenses or fill the organization with disconnected trendy tools. They are the ones that achieve the greatest clarity about their own operation. And that clarity is not achieved by adding technical complexity; it is achieved by removing friction from processes and making sure every software decision answers to a measurable business objective.

In the end, technology exists so the business works better, faster and with higher margins — not to keep a consultancy busy.

Frequently asked questions

Why do most enterprise software projects end up over time and over budget?

Because they start with the tool before solving the process. If you begin configuring software without having simplified the business rules, permissions and workflows, decisions get improvised along the way. Deviations are almost never code problems; they are the result of building on top of operational ambiguities that nobody took the time to sort out first.

How do I know if my company fell into an "assembly-line implementation"?

The typical symptom is having first-class software while your team keeps coordinating the important things over WhatsApp, Excel spreadsheets or loose emails. If leadership has to ask a manager to build a manual report to understand how the month is going because the system's screens don't produce reliable data, the tool was installed as an administrative formality and not as the operating brain of the company.

How is an architecture consultancy different from a software factory?

The software factory bills programming hours and measures success in development tickets closed, even if the solution ends up complicating the user's life. An architecture consultancy works from senior experience to diagnose the business logic, design the right data structure and use as little custom development as possible, avoiding filling the company with technical patches that are expensive to maintain later.

Can a poorly implemented Salesforce project be fixed without redoing everything?

Yes. In the vast majority of cases there is no need to throw away the licenses or the investment. What is needed is simplification work: going into the system, removing all the required fields, flows and automations that nobody uses and only add friction, and reorganizing the data architecture (Data Cloud) so leadership has the real information it needs to decide without going in circles.