Skip to content
← Back to the blog
Blog · March 28, 2026 · 12 min read

What the big consultancies won't tell you: three real senior IT consulting cases

Big consultancies charge hundreds of thousands of euros to diagnose problems a hands-on technician can fix in an afternoon. Three real cases: a botched SAP migration with a forgotten backup, a security audit that ignored the obvious, and an industrial machinery integration that was “impossible”. Real senior IT consulting gets its hands dirty.

A few months ago a CFO asked me for a second opinion on the cybersecurity audit report he'd received from one of the Big Four. 120 pages, 47 findings, risk matrix, €450,000 remediation plan. Very professional, visually polished. I read it three times looking for what I was missing. Then I opened a terminal, ran an nmap against the company's public IP ranges, and in six minutes I found the critical problem the 120-page report didn't even mention. This afternoon I'm going to tell you why this happens over and over again.

In this article I'll explain, with three real cases, the difference between consulting that hands you a PowerPoint and consulting that walks into the server room with a laptop and walks out six hours later with the problem solved. All three are Spanish clients who had previously paid large international consultancies and eventually called me. Names anonymised, technical details exact.

The myth of the big consultancy

For years there was a belief in mid- and large-sized companies: for important projects, you always hire a Big Four or a sector multinational. The reasoning was simple: nobody can blame you for choosing badly if the vendor is on the Dow Jones. If things go well, it's because you hired the best. If things go wrong, it's the client's or the context's fault.

The reality I've seen up close for twenty years is different. Large consultancies are billing machines with pyramidal structure. At the top there are one or two partners who sign the contract and really understand the business. Below them there are managers who organise projects. And at the base — where the actual work happens — there are junior consultants with one or two years of experience, fresh out of university, whom the consultancy bills to the client at €800-1,500 a day and pays €100-200. The margin is brutal and the structural incentive is clear: maximise billable hours, not minimise the client's problems.

That doesn't mean the big consultancies don't know how to work. It means their model isn't aligned with your interest. When you hire a Big Four for an SAP migration, the consultancy has an economic incentive for the migration to last as long as possible. When you hire a Big Four for a security audit, they have an economic incentive for the report to be as long and complex as possible, because that justifies the hours. And when you hire a Big Four to "implement digital transformation", what you're really hiring is an army of people who will document what you already do, present you thirty PowerPoints in three months, and leave you exactly where you were but with a six-figure invoice.

In the next few minutes I'll tell you three concrete cases where a big consultancy failed spectacularly and where the real solution cost a fraction of the time and money. Not because I'm smarter, but because the way I work is radically different.

Case 1: the SAP migration that forgot the backup

Logistics company in Valencia, around 200 employees, €45 million annual turnover. They'd been running SAP Business One for fifteen years — well enough to keep operations moving, but with major limitations in reporting and analytics. The board decided to migrate to SAP S/4HANA and hired a multinational consultancy with Madrid offices.

Initial budget: €380,000. Timeline: 18 months. Team: one senior project manager, two functional consultants, one technical consultant, one data architect. On paper, a solid team. The day-to-day reality was that the project manager was split across four projects simultaneously, the functional consultants were juniors, and the people who actually understood SAP in depth only showed up at phase reviews every three months.

In month 14 of the project, during a "final migration testing" phase, one of the junior consultants ran a cleanup script against the QA environment thinking he was pointing to a sandbox. The script wiped part of the customer and supplier master data — about 11,000 active records. The mistake was discovered the next day when integration tests started failing in cascade.

The consultancy's immediate answer was predictable: "we need to restore from backup, but restoring that specific table requires a full database restore, which will take between 48 and 72 hours". During those hours the company had to operate with manual processes — unthinkable in logistics, where every hour of delay means contractual penalties with clients.

The IT director called me the same day. I was at the office two hours later. Three things the consultancy had ignored:

  • HANA snapshots: SAP HANA lets you configure schema-level automatic snapshots every 15 minutes. Nobody had enabled them because "it wasn't in the project scope". It took me thirty minutes to check the configuration.
  • Persistent transaction logs: even without snapshots, HANA keeps redo logs for several days by default. With SSH access to the server and a few queries on the M_UNDO_CLEANUP_FILES view, I identified the range of operations caused by the script.
  • Row-level auditing: the consultancy had installed S/4HANA without enabling table-level audit trails, but the change history of master data is kept by default for 30 days in specific *_HIST tables.

In four hours I rebuilt the 11,000 deleted records by combining the three mechanisms above. I identified the user who had run the script, documented the operation step by step, and before 8 pm the company was operational again without a full restore.

My intervention cost: €2,800. Estimated cost of the full backup restore per the consultancy's contingency plan: €40,000 to €80,000 just in operational losses over those 72 hours, plus the team's overtime.

The most interesting part isn't the technical rescue. It's that when I asked the Big Four consultants why they hadn't enabled HANA snapshots, the answer was: "that feature isn't mentioned in our internal training". In other words: junior staff at a multinational consultancy didn't know what I learned reading SAP's official documentation on a random weekend. And those people were billing the client €1,200 a day.

When you hire a big consultancy for a critical project, you're not hiring the expert in the partner's photos. You're hiring the junior fresh out of a master's degree, supervised by a manager juggling seven projects at once.

Case 2: the security audit that ignored the obvious

Spanish pharmaceutical company with operations in three European countries. Due to healthcare regulatory requirements, they had to run an annual cybersecurity audit. In 2023 the board decided to "raise the bar" and hired one of the Big Four for €85,000 for a full assessment.

The final report was a 120-page elegantly laid out document. It included 47 findings classified as critical, high, medium and low; a risk matrix with probability and impact axes; cross-references to the NIST Cybersecurity Framework; a remediation plan with phases at 6, 12 and 24 months; and a €450,000 estimated budget to implement the recommendations.

The CFO called a board meeting asking for a second opinion before approving that budget. On the recommendation of another client's IT director, they asked me to review the report in 48 hours.

I read it carefully. The 47 findings were all reasonable — password policies, patching cycles, network segmentation, privileged identity management, incident response plan. Things every company should have. But something didn't add up. The "critical" findings were too generic — things like "implement a SIEM for continuous monitoring" — and none of them mentioned specific problems with the company's actual infrastructure.

I closed the report and opened a terminal. Basic internet reconnaissance: an nmap on the company's public IP ranges, a review of the SSL certificates on every exposed endpoint, Shodan searches on the domain and associated IPs, and manual tests of the admin web portals I found.

In six minutes I found this: the admin panel of their main ERP was exposed to the internet on a non-standard port (8443), with a self-signed certificate, accessible from any IP in the world, and — worst of all — with two test users created during initial installation in 2019, with the vendor's default passwords that had never been changed. One of those users had full admin permissions on the ERP database, which contained patient information, prescriptions, hospital consumption data and billing — all subject to LOPD-GDD and GDPR.

The company had technically been one click away from a catastrophic security incident for four years. And the Big Four's 120-page report didn't mention this anywhere.

Why? When the CFO asked them, the consultancy's answer was: "the contracted scope covered documentary audit of policies and procedures, not external penetration testing". In other words: they paid €85,000 for a report that analysed the written policies, not for a review of whether those policies were actually being applied in reality.

I fixed it in one afternoon. Two hours to close the exposed endpoint, change all default passwords, configure the perimeter firewall and enable MFA. Two more hours to document the process and hand over a four-page report the CFO understood in ten minutes. Total cost: €1,400.

About the €450,000 budget proposed by the Big Four: I recommended postponing it indefinitely, identifying the findings that were genuinely relevant (about 12 of the 47) and tackling them with internal budget. They saved approximately €400,000 following that recommendation.

Case 3: the "impossible" industrial machinery integration

Spanish industrial laundry chain. A dozen sites, each with eight to fifteen Miele Professional industrial washing machines. The operations manager wanted something simple: automate the programming of wash cycles from their order management software, so that when a hospital sent a linen order with a specific code, the system would automatically schedule the available machines with the right parameters.

They'd asked three industrial integration consultancies for quotes. All three gave the same answer: can't be done directly. Miele Professional machines are proprietary, they don't expose public APIs for external control, and the only official path is to contract the Miele@home Professional platform at €80-120 per machine per year, with a three-year minimum contract and additional implementation costs. For the full fleet of 150 machines, that meant at least €60,000 just in licences, plus integration, plus the obligation to redo everything if they ever changed brands.

They contacted me on another industrial client's recommendation. The question was: is there a way to do this without going through Miele Cloud?

The first thing I did was go to a site and physically open a machine. Inside the electrical panel I found what I expected: an RS-485 connector labelled "Service Port" — the one Miele technicians use when doing maintenance. That port speaks a documented industrial protocol (a variant of Modbus over RS-485 with some Miele-specific extensions) and allows both reading status and sending programming commands.

Miele doesn't offer that documentation publicly. But the documentation exists: their own service technicians use it and it circulates in industrial technical forums. In two days of reverse engineering with a €15 RS-485 to Ethernet converter and a protocol analyser, I mapped the main commands: cycle start, program selection, emergency stop, status read, error read, service counters.

The final solution was a Python gateway that exposed the machines as a private REST API inside the client's internal network. Each site got a small embedded server — a Raspberry Pi 4 with a USB-RS485 converter — that connected to the local machines and exposed a uniform API to the central management software. The whole system cost:

  • €4,200 in hardware (converters, cabling, Raspberry Pi, DIN enclosures)
  • €18,000 in gateway development and ERP integration
  • €6,400 in installation and commissioning of the 12 sites

Total: €28,600. Versus the minimum €60,000 for the Miele Cloud platform in the first year alone, plus integration costs the consultancies had estimated at €40,000-60,000 additional. Approximate saving: €70,000 in the first year, with no recurring contracts.

Four years later, the system is still running without problems. The client has changed ERP software once, and the only modification I needed was updating the gateway API — two days' work. The client has also kept the ability to switch washing-machine brands in the future, because the gateway is vendor-agnostic: any machine with an RS-485 port and known protocol can be integrated with the same pattern.

Why the big consultancies couldn't do this

The three cases above share a common pattern, and understanding it is key to knowing when to hire a big consultancy and when not to.

Big consultancies operate with pyramidal teams where the real technical work is done by junior profiles. Those profiles are trained in documented procedures: official checklists, certified frameworks, standardised methodologies. They're good at doing exactly what's in the playbook. When the problem is a standard one — implementing a market tool, auditing against a known framework, migrating from one system to another — they work reasonably well.

The problem appears when the client has a non-standard problem. A specific technical incident requiring deep product documentation. A real security audit, not a documentary one. An integration with an industrial protocol that's not officially documented. None of those things are in a big consultancy's playbook. And junior consultants don't have the experience — or the incentive — to step outside it.

My work is precisely in the cases where the playbook isn't enough. Not because I'm smarter than Big Four consultants, but because I've been working in the field for twenty years, I've read the documentation the juniors don't have time to read, I've physically opened industrial machines, I've written low-level code, and I've seen enough to quickly identify what matters and what doesn't.

What real senior IT consulting is

After twenty years doing this, my definition of senior IT consulting boils down to four points:

  1. Having done the manual work. A senior consultant must have spent years writing code, configuring routers, debugging databases, opening electrical panels or dealing with furious clients at 3 am. That experience can't be replaced by a certification or a master's degree.
  2. Being able to work alone. A senior consultant doesn't need a team of juniors behind to deliver results. If they can't sit down with a laptop, access the problem and solve it in person, they're not senior.
  3. Having aligned incentives. A senior consultant is paid to solve problems, not for hours. If your business model is about maximising billable hours, you're structurally incentivised to leave problems open.
  4. Knowing how to say "I don't know". A senior consultant knows when a problem is outside their area and says so in the first conversation. They don't sell smoke to get in and then subcontract the important work.

Conclusion

Big consultancies have their place. They're useful when you need a vendor with long arms to execute very large projects over long timeframes, with thousands of affected users and high reputational risk. If you're migrating your entire infrastructure to Azure and you need people working full-time for two years, a Big Four may be a reasonable option — with the caveat that you'll pay a lot and the results will heavily depend on the specific partners and managers they assign you.

But for specific problems, critical incidents, real audits, non-standard industrial integrations, urgent technical rescues — all that space where a PowerPoint doesn't solve anything — what you need is an independent senior consultant with real field experience, someone who can sit down with your IT director one morning and have the problem diagnosed by lunchtime.

There's no mystery. What I do isn't magic. It's reading the documentation junior consultants haven't had time to read, opening the machines they don't dare open, and writing code when code is the right answer. Anyone could do what I do — with twenty years of experience on top and a different working philosophy.

If you're about to approve a six-figure budget with a big consultancy to solve a specific technical problem, stop and ask for a second opinion. I'm not saying call me — I'm saying find someone who can explain the problem to you on one page and the solution on two. If they can't, they're not telling you the truth. And if the audit they're proposing costs €85,000 but a six-minute nmap finds the critical issue the report ignored — let's talk before you sign.