FIT 4 SAP: one process, prototyped, before you sign.

What is FIT 4 SAP, in plain words?

FIT 4 SAP is a 30 day proof of concept that comes before you sign the Statement of Work for your S/4HANA transformation. One critical business scenario, the one that carries your transformation, is tested in clean core S/4HANA, with full access to the people and places where the work really happens.

You learn what works, what breaks and why, while it is still cheap to act on. The result is evidence, not optimism: a Scar Log, a Decision Register and a Board Pack. The name comes from FIT, the FAST Implementation Track, applied to SAP S/4HANA. More on https://fit4sap.com/

What happens in the 30 days?

Two things run side by side. Access-All-Areas discovery: walking the warehouse, the production line or the shipping dock, watching the work, talking to the people who do it, and reading interfaces and error logs. And the prototype: the agreed scenario configured in clean core S/4HANA and tested against the constraints that discovery turns up.

Discovery starts on Day 1 and runs through weeks one to three, building, testing and capturing evidence run throughout, and the Board Pack is prepared in week four. When something works, the reason is documented. When something breaks, so is the reason.

What do I get at the end?

Three deliverables, all owned by you.

• Scar Log: every gap discovered, with direct quotes from the people doing the work, where it was found, its impact on the S/4HANA design and a recommended resolution.
• Decision Register: every choice made during the thirty days, who decided, when and why, and the alternatives considered. No forgotten assumptions.
• Board Pack: ten slides that tell the truth. What was tested, what worked, what broke, why, the options, the recommendations, the risks and the decision required.

The prototype system is not the asset. The evidence is: it travels into your SOW negotiation, your steering committee and your board.

Why test before signing the Statement of Work?

Because the window for cheap discovery closes the moment the SOW is signed. Before you select a delivery partner, discovery costs little more than time. Once a partner is chosen but nothing is signed, it is still possible, at a higher price. After signature, discovery happens during delivery: every problem becomes a change order and every assumption a negotiation.

The lessons get learned either way. Governance gaps, hidden dependencies, bad data and the gap between workshops and reality turn up in every programme. The only variable is when, and therefore the price. Discovery during delivery is just discovery with a larger invoice.

We have already chosen a partner or signed the SOW. Is it too late?

It depends where you are. Before you select a delivery partner, the window is wide open: discovery costs little more than time. With a partner selected but the SOW not yet signed, discovery is still possible, more expensive than doing it first, less expensive than doing it during delivery. The window is narrowing.

Once the SOW is signed, discovery happens during delivery, and every problem becomes a change order. The window for cheap discovery is closed. Whether a proof of concept still makes sense in your situation is a judgement for the real Isard: https://www.linkedin.com/in/isardhaasakker/

How does FIT 4 SAP relate to SAP Activate?

It does not replace it. FIT, the ‘FAST Implementation Track’, is a set of five principles that sits on top of any delivery method: SAP Activate, PRINCE2, SAFe, ITIL, agile or waterfall. The principles are Focus, Communicate, Simplify, Commit and Educate.

The difference is timing. SAP Activate structures how a programme is delivered once it has started. FIT 4 SAP comes before that, before the SOW is signed, and tests one critical scenario in clean core so the programme starts from evidence. Following every Activate phase is no guarantee: the white paper describes a go-live where all phases were completed, no red flags were logged, and the warehouse still did not work on Day 1.

What is the difference between FIT, FAST and FIT 4 SAP?

FIT stands for ‘FAST Implementation Track’: the method, five principles on top of any delivery approach. FAST stands for ‘Focus And Simplify Transformation’: what the method aims for. So FAST sits inside the FIT name. FIT 4 SAP is FIT applied to SAP S/4HANA: discovery and a working prototype before the Statement of Work is signed.

The five principles, always as verbs: Focus, Communicate, Simplify, Commit, Educate. The objective is preventing avoidable problems, not speed.

Who is FIT 4 SAP for, and who is it not for?

It is for organisations that treat S/4HANA as a business transformation and have not yet signed the Statement of Work: executives who want evidence before committing millions, boards that demand it, and anyone who suspects the process maps describe a business that does not exist.

It is not for a straight lift-and-shift to meet a date on a spreadsheet. If the plan is to replicate what you have, minimise change and hit the deadline, there is nothing to test. FIT 4 SAP also needs an organisation that is comfortable hearing bad news early, can decide quickly, and accepts one scenario and thirty days with no scope changes.

Why is it a paid proof of concept when integrators offer free ones?

Because they do different jobs. Free proof of concepts show possibility. They are demonstrations designed to impress: standard scenarios running perfectly, building confidence before a sale. They help you imagine what S/4HANA might do. They do not tell you what it will meet.

FIT 4 SAP is an investigation. It tests what is real, looks for constraints rather than showcases, and wants to find problems. That only works when the person testing gains nothing from a particular answer. Free proof of concepts demonstrate possibility; paid discovery tests reality.

Why only one scenario?

Because focus creates clarity. One scenario, tested properly in thirty days, tells you more than ten scenarios skimmed. The constraint is the feature: it forces you to choose the scenario that matters most, and it stops scope creep before it starts.

The right scenario is the one that carries the real transformation. When it works in clean core, everything else becomes easier. When it does not, you know before you sign. Whatever is not needed to prove that scenario goes on the backlog. The questionnaire will assist you in finding the one scenario to select for FIT 4 SAP.

Why does Isard step back after Day 30?

Because independence is what makes the evidence credible. When the firm that scopes the work also delivers it, optimism becomes structural. FIT 4 SAP has no delivery incentive: no implementation to win, no reason to find problems that require ongoing involvement, and no reason to hide them either.

After Day 30, Isard remains available to clarify the evidence, answer questions about the findings and help interpret what the proof of concept uncovered. He does not join the implementation team, does not influence the choice of system integrator, and does not stay on as an adviser. That is the standard position, written into the scope agreement.

Why only one FIT 4 SAP proof of concept at a time?

It is intentional, not operational. The work depends on direct access, direct observation and honest judgement, and none of that can be delegated without weakening the findings. So it does not scale, and it is not meant to.

Whether a slot is available for your organisation is a question for the real Isard, on LinkedIn: https://www.linkedin.com/in/isardhaasakker/

Can I speak to previous FIT 4 SAP clients?

Not yet. FIT 4 SAP is a new offer, and there are no completed FIT 4 SAP engagements to point to. What stands behind it: 30 years of hands-on SAP delivery in ten countries, and principles that have guided Isard's work since his 2016 book.

The proof of concept is designed to be checkable rather than taken on trust. One scenario, thirty days, fixed deliverables, and a Scar Log built on direct quotes from your own people. You do not have to believe the consultant. You can check the evidence.

What are the steps before Day 1?

Three steps, each one short.

• The questionnaire: twenty questions, about twenty minutes. It surfaces your critical transformation scenario and tests whether thirty days can test what matters.
• The conversation: thirty minutes, no obligation. If the questionnaire indicates a fit, the scenario is discussed and both sides check whether testing makes sense. Not a pitch.
• The scope agreement: one scenario, thirty days with fixed boundaries, three deliverables, Access-All-Areas, and the commitments on both sides. Work begins once it is signed and payment has cleared.

Before any of it, the real transformation question needs a name. Not "implement S/4HANA"; that is the tool, not the change.

What does the FIT 4 SAP questionnaire ask?

Twenty questions in seven sections.

• Why you are here: what drives the need now, the outcome you want, your biggest fear about signing the SOW.
• Where it could hurt: the scenario that is your unique selling point, the one that disrupts business as usual most, the biggest gap between how you work today and how you want to work in S/4HANA, the one with the most custom code and workarounds, and which one you would choose.
• Truth readiness: comfort with bad news early, a fixed thirty days, access to an S/4HANA sandbox, decision speed and possible blockers.
• System integrator landscape, past experience, desired outcomes, and timing and budget.

It is a pre-assessment for executives. It signals whether a conversation is worth having; the real story emerges in the conversation.

Who should fill in the questionnaire?

The executive who owns the decision, but not alone. The section on where it could hurt works best with the people who deal with those scenarios every day: support and operations teams, planners, warehouse supervisors. They are closest to the reality behind the answers, and their input makes the answers far more accurate.

An executive answering alone tends to describe the promise to customers. The person doing the work describes how that promise is actually kept, and that is where the gaps live.

How do you choose the scenario to test?

The questionnaire looks at your business from four angles: the scenario that is your unique selling point, the one that disrupts business as usual most, the one with the biggest gap between today and the S/4HANA you want, and the one with the most custom code, workarounds and deviations from standard.

If several answers point to the same scenario, that convergence is the strongest signal for the proof of concept. The scenario must matter enough to carry the transformation and be testable in thirty days. If it cannot be tested in thirty days, it is the wrong scenario, or it needs cutting down to its core.

What is in the scope agreement?

A short document that makes the work real, in plain language. In the In-House Secure example, a fictional company, it runs to eight pages:

• the scenario, why it was chosen, and what is in and out of scope;
• the method: Access-All-Areas, with the roles and places needed, and what the prototype will show;
• the thirty-day timeline;
• the three deliverables;
• the commitments on both sides;
• the system to be used;
• the fee and payment terms;
• what happens after Day 30.

It becomes binding when both parties have signed and payment is received.

What does Access-All-Areas mean?

Unrestricted access to every place where the work really happens and to the people who do it: the warehouse floor, the production line, the shipping dock, the planner's spreadsheets, the interfaces and the error logs. Access-All-Areas is a condition of the work. Floor truth replaces documentation truth; without walking the floor, the hidden gaps stay hidden.

People tell an outsider things management never hears: the workarounds, the frustrations, the contradictions they live with. They do so because the outsider is not their boss, is leaving in thirty days, wants to find problems, and is already paid. Every conversation becomes evidence: direct quotes and documented gaps.

What if we do not have an S/4HANA system?

Then a temporary clean core S/4HANA sandbox can be provided, charged separately and agreed before Day 1. Most likely a dedicated S/4HANA Cloud Private Edition sandbox, available within 24 hours of contract signature and decommissioned after Day 60, so the prototype can still be referred to during SOW negotiations.

Discovery starts on Day 1 regardless. System provisioning never delays walking the floor. A sandbox controlled by your system integrator is possible too, but it creates a dependency at exactly the moment you want independence.

What do you need from us during the thirty days?

Five commitments.

• Access-All-Areas to all relevant locations and people.
• Decision-makers reachable within one working day. The prototype does not stop for committees. In the fictional In-House Secure example, that meant operational decisions within 24 hours and the managing director within 48.
• No scope changes during the thirty days.
• A single point of contact.
• Payment before Day 1.

And one attitude: comfort with discovering problems early. An organisation that prefers optimistic assessments will not enjoy the Scar Log.

What does the consultant commit to?

Five commitments in the scope agreement as well: a fixed thirty-day timeline with no extensions, the three deliverables (Scar Log, Decision Register, Board Pack), independence with no execution bias, stepping back after Day 30, and all artefacts owned by the client.

No scope changes cuts both ways. The client cannot add requirements halfway through, and the consultant cannot expand the scope to justify more work.

What will the prototype actually prove?

Whether standard S/4HANA can model the agreed critical scenario, and at what price in complexity: what can be done with configuration, what would need customisation, and where the standard flow breaks.

It proves the logic, not the integration. The prototype is not connected to your live systems or partners' interfaces. It answers whether the system can do it; the implementation later answers how it connects.

What kinds of problems does the proof of concept uncover?

The predictable lessons, but specific to your scenario.

• Governance gaps: who actually makes decisions versus who is supposed to, where bottlenecks happen, and which workarounds exist because governance is unclear.
• Hidden dependencies: customisations hiding in daily operations, workarounds that cannot be replicated in standard, places where the business runs on two conflicting definitions of the truth, and technical debt the scenario still depends on.
• Change reality: how people actually work versus how the process is documented, frustrations clean core might solve or make worse, and where resistance will come from.

All found by building the prototype and walking around, not by analysing documentation in a meeting room.

What does a Scar Log entry look like?

Every entry records the gap, where it was found, a direct quote from the source, the impact on the S/4HANA design, and a recommended resolution. An example from the fictional In-House Secure case:

• Gap: re-layering from 8-layer to 9-layer pallets is not captured in SAP.
• Source: the demand planner, on-site observation.
• Quote: "Rework does not get captured. We have no time for that."
• Impact: stock quantity changes invisible to the system, labour cost not allocated, partial pallets creating phantom inventory.
• Recommendation: record all warehouse activities, including the cost.

A complaint becomes a logged gap, the gap becomes a test, the test produces a result, and the result becomes attributed evidence in the Board Pack. Not consultant opinion.

What is in the Decision Register?

Every choice made during the thirty days: who decided, when and why, and the alternatives considered. No forgotten assumptions.

It also records what was tested and what wasn’t, so accountability is clear on both sides of that line.

It is the deliverable behind one of the five client commitments: decision-makers reachable within one working day. The proof of concept shows where decisions actually get stuck, and the Register is the record of it. When the SOW negotiations start, nobody has to reconstruct why the scenario was shaped the way it was.

What is in the Board Pack?

Ten slides: a one-sentence executive summary, the scenario tested, the reality in direct quotes, what worked, what broke, why it broke, the options, the recommendations, the risk register, and the decision required.

No consultant theatre. No frameworks with proprietary names, no forty minutes of context. Direct quotes from your people, evidence from walking around, what it means and what happens next. A board can read it in twenty minutes and understand every word.

What can we use the findings for?

For the decisions that come after Day 30: negotiating the terms of the SOW from knowledge rather than hope, deciding whether S/4HANA is viable for the scenario, presenting evidence to the board, challenging vendor assumptions, and shaping the transformation roadmap: what works in standard, what needs configuration, what needs customisation, and what needs a change in process.

Either outcome is useful. Evidence that the scenario works in clean core gives confidence and a stronger negotiating position. Evidence that it breaks tells you before you have committed. The expensive answer is no answer at all.

What problems does every S/4HANA transformation run into?

The same four truths, whatever the industry or size. Only the timing varies.

• Reality rewrites the plan: nobody is sure who approves architectural choices, so decisions drift and the plan waits.
• Hidden workarounds break clean core fast: custom code written in a hurry and habits that became business logic stay quiet until clean core arrives. Then they snap.
• Bad data hides until reality exposes it, usually at cutover.
• Reality exposes what workshops miss: users first touch the system in user acceptance testing, the daily workarounds have nowhere to live, and the spreadsheets come back.

Find them during delivery and they bleed budget. Find them before commitment and they become solvable.

Why do S/4HANA programmes go over budget?

A 2025 Horváth survey of 200 companies found around two-thirds of S/4HANA transformations went significantly over budget, ran 30 percent longer than planned on average, and 65 percent reported serious quality deficits. Respondents blamed scope growing mid-project, weak project management, underestimated testing and data migration, concepts reworked again and again, and decisions not being made. Horváth's authors trace much of it back to how the programme was set up.

My reading, not the study's: most of those are predictable problems discovered at the wrong time. FIT 4 SAP is designed to catch several of them before the Statement of Work is signed: too many priorities (one scenario), decisions not being made (the Decision Register), concepts going round in circles (a working prototype instead of paper), and testing and data migration surprises, at least for that one scenario. It does not run the programme. After day 30 I step back, and managing delivery well is someone else's job. What it does give you is evidence to judge which partner, and which team, can actually deliver the scenario that matters.

The pattern starts at the beginning. Support for ECC is ending, so the trigger is technical, and the whole programme becomes technical: how do we replace the system, rather than what transformation can we finally deliver. A Statement of Work is signed on assumptions, and six months in, reality shows up. There is no return on investment in a technical upgrade; it appears when S/4HANA is treated as a business transformation.

Is the warehouse go-live story in the white paper real?

The white paper tells it as something that happened: a manufacturing company completed every SAP Activate phase, logged no red flags and went live on schedule, and on Day 1 the warehouse process did not work. Within the first month of hypercare, the warehouse had to be re-implemented from scratch while orders kept shipping. The consultant had never walked the warehouse floor; the documentation described a warehouse that did not exist. No company is named, and none will be.

It is based on a true story that Isard witnessed first-hand.

Is In-House Secure a real company?

No. In-House Secure Ltd is a fictional but fact-based European security technology company, used as the reference business for FIT 4 SAP examples. In the story it was founded in 2008 in Farnborough by former airport security specialists, sells cameras, smart alarms, biometric locks and security analytics, and operates across Europe with a legal entity kept in the United Kingdom.

It exists to make S/4HANA decisions concrete without exposing any real client: real enough to be believable, simple enough to stay readable. Its people, including the COO and the demand planner in the FIT 4 SAP walkthrough, are invented too.

What does the In-House Secure example show?

The whole FIT 4 SAP journey through the eyes of a sceptical client, at a fictional company. A COO, burned by an ECC implementation that halted the production line at go-live, reads the white paper late at night with two system integrator proposals on his desk. He fills in the questionnaire with the demand planner who carries the warehouse in her head, joins the thirty-minute call, and receives an eight-page scope agreement.

The lesson is in what surfaces along the way. The process maps describe one simple flow. The real operation runs on spreadsheets, phone calls and one person's memory. Neither integrator had asked. That gap is exactly what a proof of concept before the SOW is for.

What is the One Warehouse, Two Truths scenario?

It is the scenario chosen in the fictional In-House Secure example. Goods flow between an on-site warehouse and a logistics service provider, requiring consolidation, two different pallet definitions, re-layering and cross-dock visibility. No spreadsheets, with one caveat: the stock at the logistics service provider in SAP is assumed to be reliable.

The two truths: the on-site warehouse stores pallets of eight layers, because of the racking, while transport and the provider need nine layers. The conversion happens outside SAP, in an interface and in the planner's head, so the system and the floor disagree every day. The prototype tests whether clean core S/4HANA can handle both definitions, the re-layering, the cross-dock returns and stock visibility across both locations.

It is based on a true story that Isard witnessed first-hand.

What was out of scope in the In-House Secure example?

In the fictional example, everything not needed to prove the scenario went to the backlog: planning functionality not covered by standard S/4HANA, redesign of the interface to the logistics service provider, historical data migration, a user training curriculum, reporting dashboards, quality inspection, finance integration, and any custom code requests in S/4HANA.

All of it is important. None of it is what the thirty days test. The proof of concept answers whether the system can do it; the implementation answers whether the partners will play along. Different questions, different phases.