The root cause of an SAP project’s crisis is neither “requirements complexity” nor “insufficient resources.”

It lies in the failure of project design itself: “consultants who cannot design business processes proceeded without ever producing the deliverables they should have produced, and ran the project without securing personnel who could make decisions.”

And as a structure that conceals this failure,

the human-wave tactic of “adding more people will solve it” takes hold,

and the consulting firm’s business model accelerates that very direction.

[Symptoms of a functional consultant acting as a “recorder”]

– The deliverable of the Fit & Gap analysis is a “Gap list,” with no “standardization proposal”

– Everything a user says they “want to do” is recorded as an add-on requirement

– No proposal such as “business would be more efficient this way under SAP” ever emerges

– The design document never rises above the level of “meeting minutes of what was heard from users”

– When a problem occurs, the only thing they can say is “let’s bring in more staff”

[What a consultant who is truly a “designer” does]

– Can draw the As-Is and To-Be of the business themselves (not merely have others draw it)

– Can propose, down to “which side should change,” the gap between SAP standard processes and the customer’s business

– Can point out during deliverable review, “this design will cause a problem here”

– Can make the priority call of “what should be cut to make the deadline” when the project is behind schedule

□ In meetings, phrases like “we’ll pull the requirements together,” “we’ll check,” and “we’ll coordinate” keep repeating, but nothing gets decided

□ The consultants cannot draw the To-Be business flow (the business process as it should be) themselves (they only have users draw it and record it)

□ The results of the Fit & Gap analysis end with “there are N Gaps,” with no proposal from the consultants on “what to do about it”

□ Design documents exist, but they are not at a quality level that allows development and testing to proceed from reading them

□ When a scope change or additional requirement arises, “who approves it” has not been decided

□ On the client side, there is effectively no “business owner (final decision-maker)”

□ In response to a report that “there is a problem,” the consultants’ only answer is “let’s add more people”

□ The phrase “the users are slow to confirm requirements” often comes up as the reason for project delays

▶ If three or more apply, a consultant-quality problem is inherent in the project. If five or more apply, judge it as a signal that a crisis is already in progress.

No business design

↓

Gaps are judged against the standard of “a Fit means being able to do business exactly as it is now”

↓

Most SAP standard functions are judged “not a Fit (a Gap)”

↓

An attempt is made to address every Gap with an add-on or a Config

↓

Development effort explodes. Test volume explodes too.

↓

The diagnosis “we need additional staff” is handed down

↓

People increase, cost increases, the schedule extends, and quality drops

↓

Crisis is confirmed

── This chain cannot be stopped by anything other than redoing the business design

□ The To-Be business flow (the process diagram of how things should be) has been drawn by the hand of the consultants (not simply adopted as drawn by users)

□ The To-Be business flow has been designed after being compared against and examined alongside SAP’s standard process (Best Practice)

□ The reason “why customization is needed instead of the SAP standard” is documented in writing for every functional requirement

□ The results of the Fit & Gap analysis include “proposals to change the business side (a plan to conform to the Fit)”

□ Business-department heads have explicitly agreed to the change in business design (current → future)

□ The To-Be business flow is consistently linked with the design documents, test plans, and training plans

□ “Whose job changes and how” as a result of the business transformation is documented at the individual level

▶ If four or more are “No,” business design is not functioning in any real sense. It’s time to consider redoing the Fit & Gap analysis.

[A typical timeline when design document quality is low]

Month 3: The business design phase is complete. The design document review is only a “quick skim.”

The line “we’ll iron out the details later” comes up frequently.

Month 7: Mid-implementation phase. Developers frequently ask, “I don’t understand how to implement this design document.”

Consultants supplement it verbally on a case-by-case basis.

The content of the verbal explanations is never reflected back into the design document.

Month 12: Integration testing begins. Module A and Module B don’t work when connected.

Discussion begins: “What happened to the verbal agreement we made about that point?”

There are no meeting minutes, no evidence.

Month 14: Three months before go-live. Massive rework occurs. Additional staff are brought in, but

time is consumed simply chasing down “which design is actually correct.”

Month 18: Six months behind the original plan. The cause is “the design document was ambiguous,” but

no one says so. It gets summarized instead as “the requirements were complex.”

□ The results of the Fit & Gap analysis include “business-process-level detail,” such that the rationale for the design is clear just from reading it

□ An integration design document (cross-module linkage and data hand-off specifications) exists as a standalone document

□ For each module’s design document, there is a process where a consultant outside that area reviews it and points out contradictions or gaps

□ The data-migration design document records “source → destination field mapping” for every single item, with exception handling also defined

□ The cutover plan records, for every task, its “task name, owner, required time, start condition, completion condition, and escalation contact”

□ The test plan clearly states “test completion conditions (number of cases, pass rate, number of critical bugs),” and stakeholders have agreed to them

□ Deliverable review criteria (what level allows moving to the next phase) are defined, and the PMO manages them

▶ If four or more are “No,” only formal, box-checking deliverables exist. This is an almost certain predictor of massive rework during the testing process.

Role ①: Executive Sponsor (senior management)

Role: Gives final sign-off on the overall direction of the project, major changes, and the go-live decision

Required conditions: Receives a weekly project status report and has the authority and follow-through to render a decision within two business days

Role ②: Business Owner (department-head level)

Role: Decides business requirements, business-process changes, and UAT pass/fail judgments

Required conditions: Holds final decision-making authority over “how their department’s business will change after SAP go-live,” and commits at least two days a week of involvement in the project

Role ③: Project Lead (client-side PM)

Role: Handles day-to-day decision-making, scope management, and vendor management

Required conditions: Someone who has both an understanding of the purpose of the SAP implementation and business knowledge, and who can drive execution in practice rather than “leaving everything to the consultants”

① “Who is the architect (the person responsible for design) on this project?”

→ Have them provide a specific name along with a track record on similar past projects

② “How many years of experience does the consultant who will conduct the Fit & Gap analysis have in a business similar to ours?”

→ Confirm not whether they “can configure SAP module XX,” but whether they are someone who “can design with an understanding of, say, procurement operations in the food manufacturing industry”

③ “If additional requirements or scope changes occur, which role will conduct the impact analysis, and how will it be reported?”

→ Confirm the clarity of the change-management process and the reporting line

④ “What is the handover setup if a member changes partway through the project?”

→ A project where “knowledge depends on the person” is dangerous. Confirm the policy on documentation

⑤ “If progress falls behind, what kind of recovery measures will your company take?”

→ Be wary if the only answer that comes out is “we’ll add more people.”

Check whether they have a policy for addressing the root cause

□ On the client side, “the person with final authority to approve scope changes” is documented in writing, and that person is actually committed to the project

□ On the vendor side, “the person with final responsibility for design (the architect)” has been named, and actually participates in design review sessions

□ There is a rule setting the “maximum number of days” from when a decision is needed to when the final judgment is rendered

□ A process functions for quantitatively analyzing the impact (effort, cost, duration) of scope changes and additional requirements

□ The Go/No-Go criteria (what must be satisfied to go live, what would trigger a postponement) are agreed upon in a document

□ There are no more than two issues in the issue log that have sat “under coordination” or “under confirmation,” unmoved, for two weeks or more

□ There is a relationship and mechanism by which, when the client senses a problem with the quality of the consultants’ deliverables, it can formally raise that with the vendor

▶ If four or more are “No,” a decision-making vacuum is obstructing the project’s progress. Resetting the authority matrix and redefining escalation rules is urgent.

Failure ①: The Fit & Gap analysis had become “a record of the current business”

→ The only analysis performed was “there are Gaps in reproducing the current business in SAP”

→ There was no cost comparison whatsoever for “what if the business were changed to align with SAP’s standard processes”

→ The consultants were not people capable of proposing business transformation — they were people who wrote down what they heard

Failure ②: No integration design document existed

→ PP, MM, and FI were each designed by separate teams, on the assumption they would be “integrated later”

→ As a result of each module’s design proceeding without an integration design document,

a fundamental contradiction arose in the linkage design between PP (production orders) and FI (inventory valuation)

→ No one noticed until this was discovered during testing (there was no mechanism in place to catch it)

Failure ③: “Add-ons increased” is a result, not a cause

→ The real cause was the chain of decisions: “there was no business design” → “every Gap was addressed with an add-on or Config”

→ There was no “empowered business owner” on the client side to make the call to align the business with SAP

[The lesson from this case]

The increase in add-ons is not the “cause” of the crisis — it is a “symptom.”

Looking at the symptom and saying “cut the add-ons” is already too late.

Unless you start from the diagnosis that “there was no consultant capable of business design,”

the same thing will happen again.

Failure ①: The data-migration design document was nothing more than “paperwork”

→ A migration design document had been produced, but the granularity of “what to migrate and how” was far too coarse

→ It stated that “the product master will be migrated,” but

“which fields, under what conditions, mapped to which SAP codes” was left undefined

→ The consultants treated “producing the migration design document” as the deliverable,

rather than treating “the migration actually succeeding” as the deliverable

Failure ②: Data quality improvement was positioned as “a technical task”

→ The data-quality problem across 1.5 million SKUs was not a technical problem,

but a business problem of “who owns the data” and “which data is correct”

→ The consultants were unable to propose this business design (master data governance)

→ As a result, “fix-it work” kept recurring every time a data-migration problem surfaced

Failure ③: Migration testing was scheduled far too late

→ A “migration rehearsal with production-equivalent data” was scheduled for six months before go-live

→ It should have been conducted regularly starting from early in the project

→ The consultants simply followed a formal phase design in which “migration testing belongs in the Final Preparation phase,” with no risk-management perspective

The real failure in Case C (food manufacturer):

– There was no consultant able to research and design, early in the project, the regulatory requirements specific to the food industry (HACCP, the Food Safety Basic Act, expiration-date management)

– A consultant with little QM module experience took charge of the design, saying “I can do it”

– The problem was discovered at the UAT stage, after three months of silence born of “it’s too late to say anything now”

The real failure in Case D (logistics 3PL):

– Design proceeded using SAP TM+EWM’s “standard implementation approach” without understanding the business characteristics of the 3PL industry (the complexity of rules that differ by shipper)

– The project entered the implementation phase without ever answering the single most critical business-design question: “how do you standardize the individual logic of 47 different shippers?”

[The shared structure]

“A consultant who doesn’t know the industry proceeds with the design while pretending to know it”

→ The problem invariably explodes during the testing process

→ By that point, the cost to fix it is 10 to 30 times what it would have been at the design stage

The essence of the countermeasure is to make “the consultant’s industry experience” the top priority in the selection criteria.

Failure ①: Industry-specific regulatory requirements were not investigated in Phase 0 (the preparation phase)

→ CSV requirements are not a technical SAP issue but a precondition for using an ERP system in the pharmaceutical industry

→ This failure could have been prevented by confirming “pharmaceutical industry experience” when vetting the consultants’ backgrounds

→ “Being able to implement SAP” and “being able to implement SAP in pharmaceutical manufacturing” are entirely different capabilities

Failure ②: QM validation design became an afterthought

→ QM must be designed through a reverse-engineered process of “validation plan → design → implementation → testing → documentation,” not by “configuring the system and then checking that it works”

→ Because the consultants did not know this requirement, QM design proceeded on a system-requirements basis, and the validation perspective was dropped

Failure ③: UAT did not double as OQ/PQ (operational qualification / performance qualification) for validation purposes

→ In the pharmaceutical industry, UAT needs to be designed so it can be used as validation evidence

→ That requires the UAT scenarios, test procedures, and result records to follow a prescribed format, but the project’s UAT design did not include that perspective

[Lesson]

“A consultant who doesn’t know an industry’s regulations must not lead a project in that industry.”

This is not a technical problem. It is a hiring and staffing-management problem.

Failure ①: The designers did not understand the plant’s “actual movements on the floor”

→ At an auto-parts plant, the “production takt time,” measured in seconds and minutes, is the basic unit of the business

→ SAP transactions are designed on the assumption they operate on a “minutes-to-hours” timescale, and could not meet the floor’s need to “check right now”

→ If the consultants had come to the plant, this design mismatch would have been apparent in a single day

Failure ②: The MES-integration interface design ended with nothing more than “confirming technical specifications”

→ The business-flow-level design of “at what timing which data is sent from SAP to MES, and by what judgment criteria MES results are pulled into SAP” remained ambiguous, while only the technical connection specifications were decided

→ The connection “worked,” but it was not designed to “operate correctly as a business process”

Failure ③: Floor users did not participate in UAT

→ UAT was carried out by the head office’s IT and production-control departments; plant shift leaders and operators did not participate

→ A “system that works from a manager’s viewpoint” went live, but it never became “a system the floor workers could use”

[Lesson]

In a manufacturing SAP project, a designer “who never goes to the plant” can only ever produce a “desk-bound design,” no matter how skilled they are.

Visiting the floor repeatedly, and seeing the actual work with your own eyes, is the minimum requirement for business design in manufacturing.

Failure ①: An attempt was made to change only the system’s “management structure” while leaving the business’s “management structure” unchanged

→ WBS design is not the technical task of “using SAP PS’s functions,” but a management decision about “along what axis the company manages its projects”

→ The consultants proposed, “this is the standard design under SAP PS,” but could not make the essential proposal of “how your company’s business structure should change”

Failure ②: The most critical business-design challenge — “unifying the management structure” — was postponed

→ At the company, the project-management structure varied by department and by construction site

→ When introducing SAP PS, it was necessary to first “decide on a WBS structure unified across the whole company,” but instead the decision was made to “just put the current structure into SAP for now”

→ This was a fundamental failure of business design, and responsibility lies with the consultants for not strongly pressing management on “the need for unification”

Failure ③: The linkage between CO’s internal cost design and PS became an afterthought

→ The linkage design between PS (project cost) and CO (management accounting) was the most difficult part and should have been designed first, but it was postponed to the very end under the assumption “we can connect it later”

→ The single biggest purpose of the implementation — “making project cost visible through SAP PS” — went live without ever being designed to completion

[Lesson]

An SAP PS implementation in the construction industry means “WBS design equals management design.”

What’s needed is not a consultant who knows SAP PS’s functions, but a consultant who can transform the construction industry’s cost-management structure.

These are entirely different capabilities, and few people possess both.

At the procurement stage, be sure to confirm a track record of “reforming cost management in the construction industry.”

Line up every failed case, and there is almost no technical problem to be found.

What exists is the problem of “someone who didn’t know designed it.”

– Someone who didn’t know the pharmaceutical industry designed a pharmaceutical-industry project

– Someone who didn’t know the plant floor designed a system for the manufacturing floor

– Someone who didn’t know construction-industry cost management designed a project cost system

And “not knowing” does not get exposed at the design stage.

The problem only surfaces during testing, or after go-live.

By that point, the cost to fix it is 10 to 30 times what it would have been at the design stage.

In selecting a consultant, “do they know SAP” is merely a necessary condition.

The sufficient condition is “do they have a track record of transforming operations in your industry.”

Be sure to confirm this question before signing the contract. That alone will prevent half of all crises.

Principle ①: Conduct at least two rehearsals before the production cutover

1st (dry run): Conducted to find problems. Record time overruns and procedural mistakes.

2nd (timed run): Conducted with the corrected procedure. Confirm it completes within the time limit.

Principle ②: Write the procedure manual at a level where “no thinking is required”

Record everything — task name, owner, start condition, completion condition, required time, and contact point in case of trouble — so that on cutover day, people can act simply by reading the manual.

Principle ③: Agree on Go/No-Go criteria in advance

Define numerically the “conditions to proceed with go-live” and “conditions to postpone,” and have management pre-approve them.

Establish a rule that decisions are not made based on emotion or pressure on the day itself.

Principle ④: Always prepare a rollback plan

Can you revert to the old system if a critical problem occurs after go-live?

If not, explain that risk to management in advance and obtain their approval

One of the biggest mistakes in an SAP project is the perception that “it’s finished at Go-Live.”

Go-Live is not the end — it is the beginning of business transformation.

Who will drive the improvement of business performance after go-live,

and designing that structure from the project-planning stage onward,

is the single most important organizational design decision for the long-term ROI of SAP.

Maintain a CCoE (Center of Excellence) or a business-transformation team that continues improvement activities after go-live, even once the project itself has ended.

Designing, before go-live, whether “everything can be run by ourselves once the consultants are gone”

is the real condition for success.

□ A support structure for the hypercare period (1–3 months after go-live) — help desk, resident SIer, key users — has been designed before go-live

□ The KPI indicators to track after go-live, and their target values, have been agreed at the management level

□ A person or organization has been named to drive post-go-live improvement activities, with a plan to continue that activity even after the project ends

□ A roadmap toward advanced post-go-live utilization, such as SAP Fiori and SAP Analytics Cloud, has been planned

□ Timing has been set for an “SAP utilization review” at the 6-month and 12-month marks after go-live

□ There is a plan for transferring the people and knowledge needed to operate and keep improving SAP in-house after the consultants withdraw

▶ If four or more are “No,” you are heading toward the SAP implementation failure pattern of “it went live, but nothing changed.” Start designing the post-go-live structure now.

□ The business design (To-Be business flow) has been finalized with the client’s business owner’s approval

□ An evaluation of the consultants’ deliverable quality has been carried out, and items that fail to meet the quality bar have been identified and improved

□ Scope has been classified into “mandatory for go-live,” “to be implemented later,” and “discontinued,” and management has approved it

□ An integration design document exists, and the cross-module linkage specifications are fully documented

□ The success rate of the data-migration rehearsal has reached 90% or higher in the most recent rehearsal

□ The client-side decision-makers (executive sponsor, business owner) are actually engaged with the project

□ The Go/No-Go criteria are agreed upon in a document, and management is aware of the content

□ The post-go-live structure (hypercare, KPI tracking, business-improvement promotion) has been designed

▶ If six or more are “Yes,” the turnaround is on track. If four or fewer are “Yes,” a fundamental problem still remains. Do not rush to go live.

Why did this project not go well?

It was not “because the requirements were complex.”

It was not “because there weren’t enough resources.”

It was not “because the schedule was unreasonable.”

“The people who could design the business did not design the business.”

“What needed to be built was never built at a level that actually worked.”

“The people who should have decided kept running away from deciding.”

One of these three is always at the root of a crisis.

To turn a project around means to face these three questions honestly,

and to change the structure.

It is not about adding more people, remaking the plan, or holding more meetings.

It is about creating “a place where the truth can be spoken,”

seating “people who can decide,”

and entrusting the work to “people who can actually build it.”

From there, a project is reborn.