Read Me

Don’t trust me.
Trust the five rules that make this possible.
When they make sense to you, we succeed.

FOCUS
If everything is important, nothing gets proven.
Find the one thing the prototype needs to test.
Agree up front as feasible within 30 days.
One critical business scenario, fully validated.

COMMUNICATE
Ambiguity is how S/4 projects die.
The Scope Agreement must be clear.
Use plain-language documentation without jargon.
Be specific what is out of scope.

SIMPLIFY
Complexity eventually kills your business.
Stick to Clean Core S/4.
Find where standard functionality breaks.
See if you can adapt to standard.

COMMIT
The 30 day deadline is on purpose.
We stick to what is agreed.
Day 30 arrives regardless of completion.
No extensions. No excuses.

EDUCATE
If we don’t learn now, you will pay for it later.
We redefine what success looks like.
Your leverage is born from what went wrong.
Failure comes from hiding the early warnings.

If these five rules feel uncomfortable, that’s the sign you’re ready.

You’ve been burned before.

Big-budget programme.
Big-name integrator.
Big promises.
Big theatre.
Small truth.

So when you land on a website claiming that one consultant can deliver a working S/4HANA prototype in 30 days, complete with governance artefacts and board-ready recommendations, your first reaction is obvious:

“This is impossible. Too good to be true. Next.”

Hold that thought.

Because you’re right.

• Most system integrators have a specific business model.

• They’re designed to scale teams, not to work small, fast, or focused.

And they unleash billable armies.

And that changes everything.

Some Simple Maths.

Let’s start with brutal honesty:

Your S/4HANA implementation went over budget and delivered half of what was promised.
Not because the people were unskilled.

It failed because of structural incentives no one discusses during the sales pitch.

The System Integrator Dilemma.

When they quote your S/4 implementation, they’re not pricing expertise.
They’re pricing resource utilisation.

Been there. Done that. Guilty as charged.
And I hated every second of it.

The maths you don’t see:

• 8 consultants × 12 months = £2M in fees

• 1 consultant × 30 days = £50k

Which deal do their partners approve?

The dysfunction you’ve experienced isn’t random.
It’s economic gravity:

• Scope creep extends engagements (more billable hours, higher revenue)

• Large teams require coordination overhead (more project management fees)

• Custom code creates ongoing maintenance (multi-year support contracts)

• Complexity justifies premium rates (the more confused you are, the more you pay)

• Change orders are profit centres (remember those change orders you dealt with?)

None of this is conspiracy.
It’s not even malice.
It’s just business model alignment.
They optimise for revenue per engagement.

You optimise for truth per pound spent.

Those aren’t compatible goals.

Why This Matters for Prototyping.

The 30-day prototype works precisely because it can’t scale to standard System Integrator economics.

Every constraint that makes it valuable to you makes it worthless to them:

• Fixed scope = can’t expand billable hours

• Locked timeline = can’t extend engagement

• Solo delivery = can’t bill for coordination

• Standard functionality only = can’t sell ongoing customisation support

• Governance transparency = can’t hide scope drift

This isn’t better consulting.

It’s different economics.

And different economics require different rules.

The Rule of One.

Most people assume big projects need big teams.

For implementations, that’s true.
For validation, it’s backwards.

Here’s what a 30-day prototype actually requires…

One Brain, One Rhythm.

Not:

• 8 consultants coordinating across finance, logistics, architecture, governance, and documentation

• 60 handoff meetings to align people who’ve never worked together before

• 3 weeks lost to “check with the finance lead” bottlenecks

• 40% of time spent on coordination overhead instead of actual work

But:

• One person who understands end-to-end flows without translation layers

• One workflow where configuration and documentation happen simultaneously

• Zero handoff delays because there are no handoffs

• Zero coordination tax because there’s nothing to coordinate

Large teams don’t fail because the individuals are bad.
They fail because coordination overhead destroys velocity.

If it takes 8 people to configure, test, and document a scenario.
6 of them are compensating for the fact that the other 2 don’t talk to each other.

Pattern Recognition, Not Discovery.

Most SAP implementations waste months on “discovery” because consultants are learning your business from scratch.

After 30 years, I don’t need discovery workshops.

When you describe your scenario, I recognise it instantly:

• “That’s triangular invoicing and VAT determination across three jurisdictions”

• “That’s fixed-price project with milestone billing”

• “That’s Kanban between production and warehouse”

I’m not figuring out what you need.
I’m confirming which variant of a known pattern applies.

Pattern recognition compresses time:

• Large teams debate for weeks what I validate in days

• Junior consultants research what I’ve configured hundreds of times

• Generalists coordinate across domains, I navigate without translation

This isn’t arrogance.
It’s pattern matching.

A cardiologist doesn’t need six months to diagnose arrhythmia.
They’ve seen it a thousand times.

Same principle.

Governance as Native Workflow, Not Overhead.

Here’s where it gets interesting.

The Scar Log, Decision Register, and Board Pack.
These aren’t extra deliverables I create after configuration.

They’re how I work.

Documentation happens during configuration, not after:

• Problem encountered → logged in Scar Log immediately (not sanitised at project end)

• Scope pressure applied → recorded in Decision Register in real-time (not memory-holed)

• Business objective tested → focus point in the Board Pack, compiled as I configure (not reverse-engineered)

No separate “governance person” needed.
No post-sprint documentation catch-up.
No sanitisation layer between reality and reporting.

Governance is the process, not overhead on top of the process.

What I Do In My Spare Time…
And Why That Matters To You.

When normal people unwind, they watch Netflix.
Or play video games, like Minecraft or Roblox.

Me?
I rent SAP systems.

I’ve been doing this since the naughties.
Long before S/4HANA existed.

I want to know how SAP ERP is stitched together.
What makes me different to many, is that I actually take action.

Normally a SAP consultant does finance or logistics.
I do finance and logistics, and more…
Like teaching myself how to build Fiori apps.

Why?

Not because anyone paid me.
Because my brain refused to leave it alone.

Some people collect stamps.
I collect integration patterns.

I’m curious.
Stupidly curious.

And curiosity is useless unless you let it collide with reality.
I trained myself to embrace mistakes as signals.
Because every break point tells me something new.

That’s why I push until SAP cracks.

I want to see where it breaks, why it breaks, and what the standard system does under pressure.

That curiosity needs a playground, so I built one.

And it is called In-House Secure.
My fictional company in my rented SAP ERP system.

Why does this matter to you?
Because when your scenario breaks during the PoC, I’ve probably already broken it in In-House Secure.
And I know how to fix it. Or prove it can’t be fixed.

And no … I don’t claim to have all the answers.
That would be absurd in a system as wide and weird as S/4HANA.
But I do know how to find the answers fast.

Break it.
Trace it.
Document it.
Learn from it.
Move on.

That’s the point.
Not perfection … discovery under pressure, with receipts.

Still Sceptical?

Good.
You should be.

Scepticism is a survival skill in SAP.

Go down the rabbit hole and explore my ecosystem.
Discover that everything I do is connected.