By Hiran de Silva


Mark Proctor’s stance on Excel training—popular, profitable, and persuasive—rests on a deceptively simple premise: “This is what people understand, so this is what I teach.” In a marketplace of noise and short attention spans, that sounds pragmatic. But when it comes to enterprise-grade spreadsheet use, it’s not just wrong. It’s damaging.

Let’s unpack why.


Literal Thinking vs Enterprise Thinking

Proctor’s training philosophy caters to literal thinking—step-by-step, formula-focused tasks that make perfect sense in a YouTube tutorial or a classroom worksheet. This is the kind of learning where students follow along, replicate what’s on the screen, and feel like they’ve mastered Excel. But have they? Or have they just learned to copy-paste someone else’s method?

Enterprise architecture—true enterprise Excel—is different. It’s not about knowing every formula. It’s about understanding principles: scalability, automation, client-server architecture, relational data models, and process reusability.

Ironically, these principles are simpler than the duct-tape workarounds taught in many modern courses. But they require lateral thinking—an ability to step back, see the bigger picture, and question how things should work, not just how they do work.


Teaching the Wrong Painkiller

The mainstream Excel curriculum teaches users to cope with pain, not eliminate it. When you’re trained in methods that don’t scale, your solution to complexity becomes… more complexity: helper columns, manual workarounds, bloated files, scheduled batch processes, and rework cycles.

All of it adds friction.

Proctor’s defense, of course, is that his students understand those techniques. But that’s precisely the problem. Just because something is comprehensible doesn’t mean it’s right. Teaching techniques that people understand because they’ve been taught nothing else is a circular argument.

If users were shown the actual principles of hub-and-spoke Excel architecture—relational design, shared backend models, remote updating, and VBA/ADO automation—they’d realize: “This is what I’ve needed all along.


Let’s Test It

I’m not interested in debating philosophies. Let’s test them.

Take Proctor’s reconciliation method—manual, rigid, and local. Compare it with mine—dynamic, remote-enabled, and scalable. Put both in front of a management team. Ask: which better meets the business need?

There’s no contest. Managers aren’t looking for eye-catching formulas or clever index matches. They want:

  • A system that scales across hundreds of spreadsheets.
  • Minimal manual work.
  • Reliable, real-time consolidation.
  • Auditability.
  • Speed.

That’s what I’ve delivered repeatedly—in finance departments, across global operations, with ordinary Excel users using nothing more than Microsoft Office Professional and a bit of architectural thinking.


Power Query: A Misunderstood Workaround

Let’s take consolidation, often praised as a Power Query sweet spot. Sure, you can use Power Query to batch-process templates and pull in data. But it becomes just that: a batch process. A rigid assembly line with stages, lags, and limits.

You have to collect everything, load it, and refresh it.

Contrast that with the hub-and-spoke model I teach. Each spoke—each template—connects to a centralized database. Data flows back to the hub in real-time. Consolidation isn’t a post-event job; it’s always current. No batch processing required.

The obstacle? Power Query’s data model can’t take remote writebacks. It lives in a single workbook. It can’t dynamically update from 400 remote budget files. Mine can. In fact, mine does—and has, in live client environments for over 20 years.


Hub-and-Spoke: Not a Hack, But a Mature Paradigm

What I’m teaching isn’t a clever hack. It’s the natural evolution of business process engineering. It mirrors the shift that gave birth to the ERP industry: separate your data from your interface; store it centrally; interact with it intelligently.

That’s it.

This isn’t advanced. This is foundational. And it was made possible in Excel as early as Office Professional 4.2. Every version since has supported it. But Excel influencers—many of whom have never built or run enterprise systems—don’t teach it. Instead, they teach what gets likes: animations, formulas, shortcuts.

The result? A whole generation of Excel users stuck painting inside boxes—literally.


Time for a Global Impact

When I introduced this model to Tom Bauer, Lawrence Anderson, John Hood, John Unsworth, and Roger Waters Duke, their reaction was the same: “Oh my god, this changes everything.”

That impact needs to go global.

Because what I’ve shown is not a theory. It’s a proven method to get Excel out of the swamp of amateur misuse and into the realm of professional process engineering. It’s what Microsoft built Excel and Access to do. It’s what enterprise Excel should be.

So yes, I expect pushback. But I’m prepared for it.

Literal thinkers will tell you: “This is too complex for the average user.”

But the truth is simpler: The method you’re teaching is outdated. The one I’m teaching is obvious—once you’ve seen it.

And once you’ve seen it, you can’t unsee it.


Enterprise Excel isn’t just about using the tool. It’s about changing the mindset. Let’s stop painting squares and start using the spray gun.

Hiran de Silva

View all posts

Add comment

Your email address will not be published. Required fields are marked *