Companies often focus too narrowly on selecting a systems integrator (SI) for SAP projects, overlooking the critical internal readiness and alignment required for a successful transformation. This shift in perspective ensures that organizations not only choose the right partner but also prepare themselves for the responsibilities of ownership in the implementation process.
A rigorous selection process that goes beyond basic qualifications is essential to identify SIs that will provide candid feedback and challenge client assumptions. This proactive approach to due diligence helps minimize risks and ensures alignment between the SI's capabilities and the client's operational realities, ultimately leading to a smoother implementation.
Effective governance and accountability are key to navigating the complexities of SAP transformations. Establishing a strong PMO and a detailed understanding of client responsibilities fosters better collaboration with the SI, ensuring a successful delivery, reducing ambiguity, and enhancing overall business adoption of the new systems.
Companies often struggle with SAP transformations not solely due to the choice of systems integrator but also because they fail to adequately prepare their internal readiness, governance, and roles essential for successful implementation.
Why companies pick the right implementation partner and still struggle
By Brad Nicolaisen, Senior Vice President, Strategic Growth & AI Innovation, TotalTek
I have spent most of my career around SAP programs from different seats at the table: inside SAP, inside smaller SAP partner organizations, as the founder of an SAP partner business, as a delivery leader, as an executive sponsor, and as the person responsible for managing systems integrators when the stakes were high and the room was not always friendly.
That range has been useful. It also came with tuition.
I have seen strong SIs rescue messy situations. I have seen weak ones make already difficult programs worse. I have also seen capable SIs struggle because the client was not ready to be the kind of client a major SAP transformation requires. And yes, I have made enough mistakes myself to know which ones I do not plan to repeat.
That is why I believe many companies frame SI selection too narrowly. They think the question is, “Which SI should we choose?”
That is important, but incomplete.
The better question is this: “What must be true inside our company for the SI we choose to be successful?”
That single question changes the entire process. It moves the conversation from procurement to readiness, from vendor comparison to program design, and from sales presentations to execution reality.
The Uncomfortable Truth: The SI Is Not Your Strategy
A good systems integrator brings methodology, SAP depth, industry experience, delivery scale, templates, accelerators, and people who have been through the implementation cycle before. Those things matter. I would never minimize them.
But an SI cannot make the client own the transformation.
They cannot create executive alignment after kickoff. They cannot force timely business decisions if the governance model is weak. They cannot fix unclear data ownership with a methodology slide. They cannot turn part-time business involvement into full-time accountability. They cannot compensate forever for a PMO that is treated like an administrative reporting function instead of the operating system for the program.
The SI can help. The SI can lead parts of the work. The SI can challenge and guide. But the SI is still one part of the transformation model, not the whole model.
This is where many S/4HANA programs begin to drift. Not at cutover. Not during testing. Not even during design. The drift often starts before the statement of work is signed, when assumptions are still soft, ownership is still vague, and everyone is motivated to believe the plan is more complete than it really is.
Procurement Asks Necessary Questions, Not Always the Hard Ones
Most SI evaluations cover the obvious ground: implementation experience, SAP certifications, industry references, proposed timeline, commercial model, methodology, team structure, and executive commitment. Those are necessary inputs. They are not enough.
The sales room is not the delivery room.
The partner who shows up for the pitch may not be on the daily grind of design decisions, data cleansing, testing cycles, integration triage, OCM friction, and business readiness. The methodology may be polished and still leave critical client responsibilities undefined. The scope may look comprehensive while relying on assumptions that later become delays, change orders, or finger-pointing.
Nobody puts the risky assumptions in 28-point font.
That is why due diligence has to go beyond “Can you do this?” A serious selection process should ask, “How will you behave when this gets difficult? Where do you expect us to lead? What do clients like us typically underestimate? What are you assuming that we have not validated yet?”
The best SIs will welcome those questions. The wrong ones will try to steer you back to the deck.
Capability Is Table Stakes, Fit Is the Decision
Most firms invited into a serious S/4HANA selection process are capable. They have SAP credentials, implementation references, experienced partners, and a recognizable methodology. Capability gets them in the room. Fit should determine whether they stay there.
Fit is not about whether the team is likeable, although working chemistry matters more than most people admit. Fit is about whether the SI’s operating style matches the client’s reality.
Will they challenge you when your decision process is too slow? Will they be honest about the client-side roles you are underestimating? Will they tell you where your timeline is optimistic? Will they put real delivery leaders in front of you, not just pursuit leaders? Will they explain where scope ends instead of letting ambiguity survive until the change order arrives?
I would rather have the SI that tells a leadership team the uncomfortable truth in the selection process than the SI that politely nods until the contract is signed.
The Due Diligence Questions That Reveal Delivery Behavior
The questions below are the kind I like to see before an SI is selected or before Phase 0 locks in the delivery model. They are not designed to embarrass the SI. They are designed to expose the real work.
- What do clients most often underestimate in S/4HANA programs similar to ours?
- Which client-side roles are truly required, and which ones are often staffed too lightly?
- Where does your scope end and our ownership begin? Be specific.
- Which proposed resources are named, committed delivery resources versus advisory or oversight resources?
- What are the top assumptions in your proposal that would materially affect cost, timeline, or quality if they prove wrong?
- Where do you most often see scope ambiguity turn into change orders?
- How will your PMO work with our PMO? Who owns the integrated plan, risk log, decision log, dependency tracking, and executive reporting?
- How is OCM embedded into design, testing, training, deployment, and adoption instead of being treated as a communications workstream?
- How do you report risk when the client is the source of the delay?
- Show us an example of a status report where the news was bad. What did you escalate, and how?
- What decisions must our executives be prepared to make in the first 60 to 90 days?
- What would make us a difficult client for you to deliver for?
That last question is one of my favorites. It cuts through the choreography. A good SI will answer it directly. A great SI will answer it with enough candor that the client learns something about itself before the project starts.
The Scorecard Should Force Tradeoffs, Not Hide Them
Many SI scorecards are built to look objective but end up confirming the preference the room already had. The categories are too broad, the weighting is too generic, and the scoring does not reflect the actual risks of the program.
If business adoption is one of the biggest risks, OCM cannot be a five percent afterthought. If the client has limited internal capacity, the scorecard should heavily evaluate client enablement, role clarity, and the SI’s expectations of client-side ownership. If the program depends on manufacturing process discipline, the scorecard should test functional depth and practical operating experience, not just firm-level credentials.
A useful scorecard should measure the decision you are really making. I typically want to see categories like these:
- S/4HANA delivery experience and quality of the proposed delivery team
- Industry and operating-model fit
- Transparency of scope, assumptions, exclusions, and dependencies
- Program governance model and PMO integration
- OCM strategy and business adoption approach
- Data migration, data governance, and data ownership model
- Testing, cutover, and business readiness approach
- Commercial clarity and change-control discipline
- Cultural fit, communication style, and willingness to challenge leadership
- Knowledge transfer and ability to leave the client stronger after go-live
The weighting is where the truth shows up. If everything is important, nothing is important. A disciplined scorecard should make leadership choose what matters most, then live with that choice.
The SOW Is Where Optimism Goes to Hide
A legal review of the statement of work is necessary. A delivery-risk review is different, and it is just as important.
The delivery-risk review looks for ambiguity that sounds harmless until the program is under pressure. Words like “support,” “assist,” “coordinate,” “participate,” and “as needed” deserve a second look. They are not bad words, but they are incomplete words.
Support how? Assist with what? Coordinate across whom? Participate as an owner or an observer? As needed by whose judgment?
These questions matter in PMO, OCM, data, integrations, testing, training, reporting, and business readiness because those areas often sit in the gray space between SI responsibility and client responsibility. Gray space is where delays are born.
One of the most useful things a company can do before signing is build an assumptions map. Take every material assumption from the SI proposal and SOW, then assign it an owner, a validation method, and a risk level. If an assumption cannot be validated, it should not be quietly accepted as a fact.
PMO Is Not the Meeting Police
I have a strong bias on this one because I have watched programs underuse the PMO and then wonder why decisions, risks, dependencies, and escalations became blurry.
A transformation PMO is not there to collect status reports and schedule meetings. A real PMO creates the operating cadence of the program. It manages the integrated plan. It forces decision discipline. It tracks assumptions, issues, risks, dependencies, actions, and scope movement. It makes executive steering useful instead of ceremonial.
Most importantly, the PMO protects the business from passive drift.
The SI will have its own project management structure. That does not eliminate the need for a strong client-side PMO. In fact, it increases the need for one. The SI’s PMO is designed to manage the SI’s delivery responsibilities. The client PMO must manage the business transformation, the internal decision model, the client-side work, and the relationship between what the SI is doing and what the business must own.
Those are related. They are not the same.
OCM Is Not a Communications Plan With Training Attached
OCM is another area where companies can fool themselves early.
The question is not whether the SI has an OCM workstream. Most do. The question is whether that workstream is connected to the real disruption the program will create.
A strong OCM evaluation should ask how role impacts will be identified, how process changes will be translated into business readiness, how leaders will be equipped to sponsor change, how resistance will be surfaced, how adoption will be measured, and how OCM will be linked to testing, training, deployment, and stabilization.
If OCM lives off to the side, it becomes newsletters and training logistics. If it is embedded in the program, it becomes a risk-management discipline for adoption.
Phase 0 Should Be a Stress Test
Phase 0 is often treated as discovery. That is fine as far as it goes, but it should be more than discovery. It should be a stress test of the future program.
Before the broader program is moving at full speed, Phase 0 should clarify how decisions will get made, how scope will be controlled, what business resources are required, how risks will be escalated, what the SI is truly accountable for, what the client must own, how OCM will be integrated, and what success looks like at the end of each phase.
The worst time to invent governance is after the program is already late.
The best companies enter Phase 0 with enough structure to challenge the SI constructively, not so much structure that they stop listening. That balance matters. You want to be open to the SI’s expertise without outsourcing your judgment.
The Prework I Use with Clients
The work I recommend before or during SI selection is practical. It is not theory, and it is not a 100-page binder that nobody will read. The goal is to create enough clarity to make better decisions and avoid preventable surprises.
Practical Tools That Make the Selection Process Sharper
- SI Due Diligence Question Bank: A tailored set of questions designed to expose delivery behavior, staffing assumptions, client responsibilities, and risk transparency.
- Weighted SI Scorecard: A decision model that forces leadership to weight what actually matters for the program, not just what looks clean in an RFP.
- SOW and Assumptions Gap Review: A delivery-risk review of vague language, exclusions, dependencies, and areas likely to become future conflict or change orders.
- Client Readiness Assessment: A practical review of governance, business ownership, data accountability, PMO maturity, OCM capacity, and decision rights.
- Governance And PMO Blueprint: The client-side operating model for cadence, escalation, executive steering, risk management, decision control, and integrated reporting.
- OCM Evaluation Lens: A way to judge whether change management is integrated into the transformation or simply bolted onto training and communications.
Do Not Let the SI Own the Mirror
This is the part some companies miss. The SI can absolutely help shape Phase 0, and a good SI should bring valuable structure. But the SI is also shaping work it may deliver. That is not wrong. It is simply a reality that needs to be managed.
The client benefits from an independent lens before the delivery model is locked in. Someone needs to ask the awkward questions early, when they are cheaper to answer. Someone needs to look at the scorecard, the assumptions, the governance model, and the OCM plan from the client’s side of the table.
That role should not be adversarial. The goal is not to beat up the SI. The goal is to help the client become a better buyer, a better owner, and ultimately a better partner to the SI it selects.
What Good Looks Like Before the Contract Is Signed
Before an organization commits to an SI or exits Phase 0, leadership should be able to point to a few tangible outputs:
- A scorecard with weighted criteria tied to the actual risks of the program
- A clear view of SI assumptions, exclusions, dependencies, and client responsibilities
- Named business owners with realistic capacity expectations
- A client-side governance model with decision rights, escalation paths, and executive cadence
- A PMO model that integrates SI delivery management with client-side transformation ownership
- OCM evaluation criteria tied to business impact, not just training and communications
- A Phase 0 exit definition that says what must be known, decided, staffed, and governed before full kickoff
This is not bureaucracy. This is risk reduction.
Companies that do this prework tend to be harder to sell to, but much easier to deliver for. They ask better questions. They negotiate cleaner scope. They catch unrealistic assumptions earlier. They know what they own. They make SIs better because they create a healthier operating environment for delivery.
The Bottom Line
Selecting the right SI matters. It matters a lot. But it is not enough.
The real objective is to choose the right implementation partner while building the client-side structure required to make that partner successful. That means harder questions, a sharper scorecard, a delivery-risk review of the SOW, a serious look at PMO and governance, and an honest assessment of whether the organization is ready to own the transformation.
I have seen both sides of the struggle. I have been the consultant, the founder, the executive, the delivery leader, the client-side manager, and the person looking back at a decision thinking, “We should have challenged that earlier.”
That is the lesson I would offer any company preparing for an SAP transformation: do not wait until the project is under pressure to find out whether the SI selection process asked the right questions.
The project does not really start at kickoff. It starts when leadership decides how serious it is willing to be before kickoff.