SAP S/4HANA Steering Committee: Roles, Decision Rights, and Governance Best Practices

See how an SAP S/4HANA Steering Committee governs key decisions and risks.

An SAP S/4HANA transformation can slow down even when the architecture is sound, the implementation partner is experienced, and the delivery plan is realistic. The difficulty often starts when a decision crosses organizational boundaries: two business units want different process variants, a local team requests an exception to the global template, a critical data issue threatens cutover, or a scope change affects both budget and timing.

These are not configuration questions that an individual workstream can resolve safely. They require a governance body with enough authority to weigh competing priorities, accept material risks, allocate resources, and make decisions that affect the transformation as a whole. That is the role of the SAP S/4HANA Steering Committee.

The need for this executive layer often extends beyond the first deployment. SAPinsider's 2026 ERP Migration and Transformation benchmark found that 55% of respondents had completed an SAP S/4HANA or SAP S/4HANA Cloud deployment, while only 34% considered their overall transition complete. Multiple ERP instances, parallel systems, and pilot deployments can make the first go-live only one stage in a longer transformation journey.

This article explains how the Steering Committee should operate throughout that journey: what it should decide, who should participate, when an issue requires executive escalation, and how the committee should approach scope, risk, Clean Core, data, adoption, and go-live. Broader questions around multi-year operating models, RACI design, quality gates, handoffs, and program-wide escalation architecture are covered separately in our guide to governing a multi-year SAP program.

What Does an SAP S/4HANA Steering Committee Do?

The Steering Committee exists to make decisions that cannot safely remain within a project workstream or delegated governance body. If it becomes another project-management meeting or a forum for reviewing every open task, executive attention shifts away from the trade-offs that actually require executive authority.

Routine delivery management, therefore, remains with the program management office (PMO) and project managers. At the same time, executives still need a reliable view of program status because that evidence supports their decisions. SAP's implementation guidance describes executive sponsors from the customer and partner/SAP teams as forming the Steering Committee, with responsibility for critical decisions, budget, project resources, organization-wide decisions, and final escalation. Project managers, meanwhile, track implementation tasks and deliverables and provide status updates to the committee.

In practice, this division means the Steering Committee should focus on material changes to approved scope, budget, or major milestones; unresolved cross-functional process conflicts; significant resource constraints; architecture or solution exceptions with program-level consequences; risks above delegated tolerance; major deviations from agreed standardization principles; and go-live decisions. Routine configuration, sprint planning, staffing coordination, defect triage, and workstream-level risk mitigation should remain with the delivery organization.

The boundary is defined by authority rather than by the type of issue. A project team should resolve a problem while its impact remains within delegated limits; executive governance becomes necessary when the consequences exceed those limits or require a decision that lower-level governance cannot make.

Where Does the Steering Committee Fit in SAP Program Governance?

A Steering Committee can only work effectively when its boundaries with other governance bodies are explicit. A large SAP program may include the Steering Committee, PMO, Business Process Owners, architecture leadership, a Solution Standardization Board (SSB), data owners, change leads, and multiple functional and technical workstreams. Governance breaks down when several groups believe they own the same decision — or when each assumes another group will make it.

The Steering Committee should own material business decisions, major changes, resource conflicts, risk acceptance, and final program-level escalation. The PMO manages delivery, dependencies, schedule, reporting, and escalation preparation. Business Process Owners remain accountable for end-to-end process outcomes, while an SSB or an architecture authority evaluates deviations in processes, solutions, integrations, and extensibility within their delegated scope. Data owners govern definitions and quality, while change and adoption teams manage communication, training, and organizational readiness.

Customization shows why these boundaries matter. The Steering Committee should not review every request for a nonstandard process or extension. An SSB, architecture body, or Business Process Owner should first determine whether the request can be resolved within established standards. Executive involvement becomes appropriate when the decision materially changes scope, budget, schedule, risk, or the approved operating model, or when the responsible governance body cannot resolve the conflict.

Global template programs create a similar tension between enterprise standards and legitimate local requirements. The question is not whether all local variation should be rejected, but which deviations can be handled within delegated governance and which materially change the shared model.

Core template vs. local fit — what should you choose?

Our guide to SAP global template and rollout strategy examines how to draw that boundary across countries, processes, and rollout waves in more detail.

Explore

Who Should Sit on the SAP S/4HANA Steering Committee?

There is no universal committee size or composition that fits every SAP program. A more useful test is whether the standing members collectively have enough organizational authority to make binding decisions when business priorities, budget, architecture, or risk are in conflict.

Core decision members

The Executive Sponsor connects the transformation to business objectives and provides authority when decisions affect enterprise priorities. Depending on the program, this may be the CFO, COO, CIO, or another executive with enough organizational reach to resolve cross-functional trade-offs.

Senior business leadership or Business Process Owners represent the functions most affected by the transformation. Their involvement becomes especially important when a decision changes an end-to-end process, operating model, or business requirement rather than simply altering system design.

The CIO, CTO, or delegated architecture authority represents enterprise architecture and technology risk when a decision has significant implications for integration, extensibility, security, or long-term maintainability.

The implementation partner or SAP executive sponsor is also part of the Steering Committee in SAP's reference project structure. The charter should clearly define this role's decision rights while preserving customer accountability for the business scope, operating model, budget, and risk acceptance.

Recurring participants

The Transformation Lead or PMO Director provides the committee with an executive view of the schedule, scope, dependencies, risks, and decisions requiring attention. This role typically structures the information and facilitates decision-making rather than replacing executive accountability.

The implementation partner's program or project lead contributes evidence of delivery, realistic alternatives, dependencies, and experience from comparable transformations. This helps the committee understand the consequences of each option, but it does not replace the customer's authority over business decisions.

Invited experts

Enterprise architects, security specialists, data leads, functional experts, legal or compliance specialists, change leads, and regional leaders do not necessarily need permanent seats. They can join when a particular escalation requires their expertise, keeping the standing committee focused while still giving executives access to the evidence required for a decision.

A larger attendee list does not automatically create stronger governance. The objective is to concentrate decision authority in the right group while bringing specialist expertise into the discussion when the issue requires it.

How Should You Define the Steering Committee Charter and Decision Rights?

The Steering Committee should not discover the limits of its authority during the first major escalation. By then, uncertainty over who can decide may already have become a delivery problem, especially when the issue affects several functions or requires an urgent response.

A practical charter should define the committee's purpose and scope, standing membership, recurring attendees, quorum, decision rights, delegated authorities, and escalation thresholds. It should also explain how urgent decisions are handled between scheduled meetings, what information belongs in a pre-read, how decisions are recorded, and who may accept residual risk. Where corporate governance reserves certain decisions for another authority, the charter should describe how an issue moves beyond the program governance structure.

Just as importantly, the charter needs to state what the Steering Committee does not own. Responsibilities that remain with the PMO, Business Process Owners, SSB, architecture team, data governance, and delivery workstreams should be explicit. The decision method also needs to be clear, whether the program uses consensus, a committee chair, customer executive authority, or another agreed mechanism.

Define escalation thresholds before the project needs them

Executive governance becomes inefficient when every scope change, defect, or risk is sent upward. Thresholds should therefore reflect the program's actual scale, risk profile, and delegated authorities rather than a generic governance template.

A change to the approved budget, scope, or a committed milestone is an obvious candidate for escalation. An issue affecting several functions, regions, or legal entities may also require executive involvement, as can material compliance, security, operational, architectural, or standardization exposure. Resource shortages and go-live issues should escalate when the program cannot resolve them within its existing authority.

There is no universal dollar amount, number of delayed days, or defect count that should trigger escalation across every SAP transformation. What matters is that the program defines its own tolerances before an issue occurs, communicates them to the delivery organization, and applies them consistently.

How Should a Decision Reach the Steering Committee?

A well-designed escalation path filters issues instead of automatically sending them upward. The process starts with the workstream that identifies the problem and documents its impact. The relevant Business Process Owner, architecture authority, SSB, data owner, or PMO then determines whether the issue can be resolved within existing standards and delegated authority.

If it cannot, the team should prepare realistic options rather than escalate an unresolved problem without a decision framework. The PMO validates the implications for scope, cost, timeline, dependencies, and risk, while the relevant specialists explain the operational or architectural consequences. The Steering Committee can then choose an option, reject the escalation, request additional evidence, or explicitly accept residual risk.

The governance cycle does not end when the committee approves an option. The decision must return to delivery with an accountable owner, implementation conditions, and a deadline, and the program must track whether those actions occur. This closed loop keeps each governance level focused on the work it is best positioned to perform: specialists analyze the issue, delegated governance tries to resolve it, and executives decide when executive authority is genuinely required.

How Does Executive Governance Change Across SAP Activate?

Executive governance changes as the program moves from the business case to implementation and eventually into production. In SAP Activate, the formal implementation project begins in Prepare. During Discover, equivalent decisions typically sit with executive sponsors or pre-project governance unless the Steering Committee has already been established.

From Prepare onward, where a Steering Committee is part of the governance model, it provides the executive governance layer for material decisions and escalations. For broader context, see our guide to SAP Activate.

The exact transition from stabilization into Run governance depends on the SAP Activate roadmap and implementation scenario. What remains consistent is the division of responsibility: executive governance makes decisions at the appropriate level, but it does not replace detailed phase management, delivery controls, or quality gates.

How Should the Steering Committee Govern Scope, Budget, Resources, and Risk?

Scope, budget, resources, and risk rarely move independently. A request that initially looks like a functional enhancement may require additional development and testing, expand migration effort, consume scarce specialists, and ultimately affect the rollout date. The committee, therefore, needs to assess the combined business impact rather than approve one consequence while ignoring the others.

A material scope change should arrive with that impact already analyzed. The decision paper should explain what is changing, why the change is required, which alternatives were considered, how cost and schedule would be affected, which risks would be created or reduced, and what would happen if the request were rejected. That turns scope governance into an explicit business trade-off rather than a feature-approval exercise.

The same principle applies to resources. A staffing gap within a single workstream is usually a delivery management problem. It becomes an executive decision when the solution requires reprioritizing other initiatives, adding material budget, changing the rollout sequence, or committing scarce business resources across organizational boundaries.

Risk follows the same boundary. Workstreams should own routine risks and mitigation actions, while the Steering Committee focuses on exposures that exceed delegated tolerance, threaten major transformation objectives, or require an executive decision to reduce, transfer, accept, or avoid the risk.

How Should the Steering Committee Govern Customization and Clean Core?

Customization becomes an executive concern when individual exceptions begin to accumulate into long-term complexity. The Steering Committee does not need to approve every extension, but it should ensure that the transformation has a mechanism for distinguishing justified differentiation from the gradual recreation of legacy processes.

Recent migration data illustrates why this matters. In SAPinsider's 2026 detailed ERP migration findings, 38% of respondents reported modernizing or eliminating custom processes to streamline the transition and enable more agile future updates, while 32% reported implementing standardized end-to-end processes for core ERP tasks. The research also identifies adapting and remediating custom code as the biggest challenge among organizations deploying SAP S/4HANA.

The Steering Committee's role is therefore not to govern every aspect of Clean Core directly. Instead, it should ensure that the appropriate process and architecture bodies apply agreed standards consistently and that only deviations with consequences beyond delegated authority reach executive governance.

In practice, a business requirement should first be evaluated against standard SAP functionality. If a deviation remains necessary, the team should document the business case, alternatives, and downstream consequences before the appropriate Business Process Owner, architecture body, or SSB reviews it. Only unresolved or materially significant deviations should reach the Steering Committee.

This changes the discussion from "Can SAP be customized to do this?" to the more useful governance question: "Does the business value justify the lifecycle, architecture, cost, and upgrade consequences?" That distinction keeps technical feasibility from becoming the only criterion for a business decision.

Measure the exceptions that matter to executive governance

There is no single universal "Clean Core percentage" that can adequately describe transformation health. Depending on the program, executives may need visibility into material process deviations, extensions requiring architectural remediation, non-approved integration patterns, exceptions to development standards, or remediation that could affect future upgrades.

Technical teams should interpret the detailed measures and determine their architectural significance. The Steering Committee needs the next level of information: which exceptions create material business, lifecycle, schedule, cost, or upgrade exposure, whether that exposure exceeds delegated tolerance, and what executive action is required.

A LeverX example: governing pressure to customize

In one published LeverX Clean Core case study, a global chemicals company faced growing requests after go-live to recreate familiar legacy processes. LeverX used process-alignment workshops, standard vs. custom heatmaps, TCO, upgrade-risk analysis, and change champions to assess those requests. Within six months, the client eliminated more than 70% of customization requests while maintaining its Clean Core approach.

The public case does not identify a Steering Committee as the decision body, so the relevant lesson is the decision mechanism rather than a specific governance structure. Stakeholders can make better customization choices when business value, long-term costs, and architectural consequences are evaluated together, rather than reducing the question to a technical recommendation to approve or reject an extension.

How Should the Steering Committee Govern Data and Business Adoption?

Poor data readiness and low process adoption can threaten the same milestones as technical defects, but executive governance should not take over the operational work required to solve them. Its role is to establish accountability, understand whether agreed readiness criteria are being met, and decide what happens when a material gap cannot be resolved by the responsible teams.

Treat data as a readiness decision

Current migration research shows why data and integration belong in readiness governance. In the same SAPinsider 2026 benchmark, 82% of respondents identified integration between core ERP and line-of-business applications as a requirement for their transition, 78% cited minimal disruption to operations, and 75% identified cleansed and harmonized operational data across systems.

Critical data objects should therefore have named business owners, while detailed cleansing, harmonization, migration, reconciliation, and validation remain with the responsible business and delivery teams. The Steering Committee becomes involved when an unresolved data problem threatens a major gate or go-live and can no longer be addressed within delegated authority.

At that point, executives need evidence against the agreed criteria, such as reconciliation results, migration errors, data-quality thresholds, unresolved ownership gaps, or other program-specific indicators. The decision is then whether the issue can be remediated within the existing plan, whether the schedule should change, or whether the remaining exposure can be accepted explicitly.

For a deeper treatment of ownership, harmonization, and the distinction between migration and long-term governance, see our guide to master data harmonization in SAP transformation. If the issue is the migration scope itself, historical data, reconciliation, or legacy system retirement, our SAP S/4HANA data migration strategy addresses these questions in more detail.

Adoption ownership also stays below the committee

Business Process Owners, functional leaders, and change-management teams remain responsible for implementing the approved process model and preparing users. Executive governance becomes necessary when evidence shows that adoption has moved from an operational concern to a material readiness risk.

That evidence may include training completion for critical roles, readiness assessments, unresolved organizational impacts, open process deviations, user acceptance testing results, and the preparedness of local leadership. The committee's task is not to manage training or communications itself; it is to decide whether the business can proceed safely when agreed readiness conditions are not fully met.

How Should the Steering Committee Make the Go-Live Decision?

Go-live is one of the clearest examples of a decision that can exceed project-level authority. By this point, hundreds of detailed tasks may still remain, but executives should not have to reconstruct readiness by reviewing them individually.

Instead, the Steering Committee should receive a consolidated view of cutover and technical readiness, critical defects and integrations, data migration and reconciliation, security and compliance, business and user readiness, support preparedness, open dependencies, and material residual risks. The exact evidence will vary by program, but the objective is consistent: decision-makers need to understand whether the unresolved exposure remains acceptable.

For SAP S/4HANA on-premises, SAP documents an iterative migration process that supports validation before production. The documentation describes creating the migration project in a development system, moving it through test systems while incorporating corrections from earlier migrations, and then transporting the refined project to production. SAP also supports migration simulation before the actual transfer.

The governance objective is not necessarily to reach zero open issues. Large programs may enter production with known items that have been assessed and controlled. What matters is that every material remaining issue has a known impact, an accountable owner, a mitigation or workaround, a target resolution date, and an explicit decision on whether the remaining risk is acceptable.

Residual risk must be accepted explicitly

When an agreed readiness criterion is not fully met, the decision paper should explain what remains unresolved, its potential business or technical impact and likelihood, the mitigation or workaround, the remediation owner and deadline, and the authority responsible for accepting the remaining risk.

The go-live choice then becomes explicit rather than implicit. The organization can meet the agreed threshold, postpone the release, adjust the deployment plan, or proceed with a documented acceptance of residual risk and clear responsibility for the remaining actions.

How Often Should an SAP Steering Committee Meet?

There is no universal meeting cadence for every SAP program because decision pressure changes over the course of a transformation. A stable delivery period may require only a regular governance rhythm, while Explore, cutover preparation, a major rollout wave, or a period of elevated risk may justify more frequent executive attention.

The charter should also define how urgent decisions are handled between scheduled meetings. The useful test is not whether the committee meets weekly or every two weeks, but whether an issue reaches the right authority early enough for a decision to be made before it becomes a delivery blocker.

What should happen during the meeting?

A Steering Committee meeting should be organized around decisions rather than presentations. A practical agenda can start with decisions required at the current meeting, then move to material exceptions, risks requiring executive action, changes above delegated authority, and upcoming decisions with fixed deadlines.

Routine project information belongs in a pre-read whenever possible, with meeting time reserved for the issues that require discussion. This keeps executives focused on trade-offs, consequences, and action rather than status reporting that could have been reviewed in advance.

Use a decision paper instead of a long presentation

Each material escalation should reach the committee in a consistent form. The decision paper should state exactly what must be approved or rejected and by when, explain why the issue exceeds delegated authority, and present realistic alternatives rather than a single preferred answer without context.

It should then show what those alternatives mean for business operations, scope, cost, schedule, architecture, compliance, and risk before presenting project leadership's recommendation and rationale. Any residual risk associated with the recommendation should be explicit, along with the person accountable for implementing the decision.

This discipline helps translate a complex project issue into a decision executives can actually make. It also creates a consistent evidence base when similar questions arise later in the program.

Keep a decision log

Every material decision should be recorded with its date, outcome, rationale, decision authority, conditions, affected scope, implementation owner, and required follow-up. The log should also remain accessible to the teams whose work is affected so that approved decisions translate into execution.

Its value becomes particularly visible during long programs. A decision log prevents the same issue from being reopened simply because leadership changes, a new rollout wave begins, or members of the implementation team change.

Which Tools Can Support Steering Committee Decisions?

Technology can improve governance transparency, but it should not turn executive meetings into dashboard-review sessions. The useful output for the committee is not another layer of operational detail but reliable evidence that helps executives see where intervention may be required.

SAP Cloud ALM can provide program leadership with visibility into implementation progress, tasks, deliverables, testing, and issues. SAP Signavio can support process-transformation governance by helping teams maintain visibility into process initiatives, priorities, and areas that may require intervention.

The committee does not need to operate these tools or interpret every operational metric. It needs the decision-oriented layer of information they support: what is off track, why it matters, whether the issue remains within delegated tolerance, and what executive action is required.

What Should the Steering Committee Scorecard Track?

A Steering Committee scorecard should make emerging decision needs visible without reproducing the PMO's operational reporting. Detailed measures remain with delivery teams; executives need the indicators that show when a condition is approaching or exceeding an agreed tolerance.

The exact indicators and thresholds should be designed around the program rather than copied from a generic scorecard. Their purpose is to show executives where a decision may soon be required, while ownership, escalation paths, and authority remain defined in the broader governance model.

What Are the Most Common Steering Committee Failure Modes?

A program can have a formally established Steering Committee and still have weak governance. The strongest warning signs are therefore not isolated project issues but recurring patterns showing that decisions are being made at the wrong level, arriving too late, or failing to translate into execution.

Decisions repeatedly arrive too late

If an issue reaches the Steering Committee only after it has delayed a milestone or changed a commitment, the problem is likely not the individual escalation but the governance path that preceded it. The program should examine whether teams recognize escalation triggers early enough and whether issues move through intermediate governance layers quickly enough.

The practical response is not necessarily to escalate more issues. It is to make thresholds clearer and ensure that unresolved decisions are identified while executives still have meaningful options.

Delegated authority is applied inconsistently

Governance also slows down when similar issues are handled differently depending on the workstream, region, or individual involved. This usually means that thresholds exist on paper but are not interpreted consistently across the program.

Clarifying examples, tolerances, and decision boundaries can often solve the problem more effectively than adding another governance body. Teams need to understand both what they are authorized to decide and when they are expected to escalate.

Governance becomes fragmented across partners, regions, or rollout waves

Multi-partner and multi-wave programs can develop parallel approval paths unless they operate within a common decision model. Regional teams and delivery partners may need delegated authority to keep execution moving, but decisions with enterprise-wide consequences still require a shared framework and a clear route into central governance.

The objective is not to centralize every decision. It is to prevent the same type of material issue from being resolved under incompatible assumptions in different parts of the program.

Decisions are made, but not translated into execution

A timely executive decision has little value if the resulting conditions, owners, deadlines, and downstream changes never reach the delivery teams. Governance, therefore, needs a closed loop in which the committee makes the decision, the delivery organization implements it, and the program verifies that the required action occurred.

A strong Steering Committee does not attempt to control every aspect of implementation. Its value comes from keeping material decision authority timely, consistent, program-wide, and connected to execution.

Steering Committee Responsibility Matrix

The matrix below illustrates how operational ownership can be separated from executive governance. It is a practical example rather than a universal SAP RACI, and the exact allocation should reflect the organization's governance model and delegated authorities.

Which SAP Environments Does This Governance Model Apply To?

The governance principles described here apply broadly across SAP Cloud ERP, SAP Cloud ERP Private, and SAP S/4HANA on-premises. The exact decision model will still vary with deployment, transformation approach, program scale, existing customization, organizational complexity, and regulatory requirements.

Those deployment differences do not need to be resolved inside the Steering Committee itself. Organizations assessing the public cloud path can review our guide to cloud-first ERP strategy for more details on Fit-to-Standard, extensibility, and continuous cloud delivery.

Across these environments, the governance principle remains the same: decision authority should reflect the materiality and consequences of a decision rather than the technical platform alone.

How LeverX Supports SAP Transformation Governance

LeverX supports SAP programs from transformation planning and SAP S/4HANA readiness through implementation, migration, process harmonization, integration, change, and post-go-live optimization. Our SAP S/4HANA consulting services include business-process, data, architecture, migration, and implementation activities that provide the evidence needed for effective transformation governance.

The governance design should reflect the transformation itself. A global template rollout may require strong controls around local deviations and cross-wave decisions. An SAP ECC conversion may place greater emphasis on migration risk, custom code, business continuity, and cutover, while a Clean Core transformation may require formal controls to prevent legacy requirements from gradually re-entering the target environment.

If you already have a draft governance model, Steering Committee charter, escalation path, or responsibility matrix, LeverX can help identify unclear decision rights, duplicated authority, and ownership gaps before they become delivery risks.

FAQ