Staffing a SAP Commerce Project: The Roles You Need and When You Need Them

The most common staffing mistake on a SAP Commerce project is not too few people; it is an unowned artifact. Every team has developers. Fewer teams can name the person who decides what goes into SolrIndexedType, who signs off an ImpEx header change before it runs against production data, who owns manifest.json, who grants a Backoffice permission, and who says no to a breaking /occ/v2 field change. Those artifacts do not care about job titles, and they fail loudly when nobody owns them. This guide maps the roles to the artifacts: oversight, the day-to-day delivery engine, the business representative who can decide, and the SMEs, with the caveat that team shape changes by phase, so you staff for the phase you are in.

Oversight: The Decisions Only the Sponsor Can Make#

Three oversight decisions on a SAP Commerce programme are platform decisions wearing a budget hat, and no architect can make them:

• Licensed module scope. An extension is available to your build only if your contract covers the module it belongs to. Whether you can use the B2B organization model (b2bcommerce, b2bapprovalprocess), the order management and sourcing machinery (warehousing), or the marketplace extensions is a commercial answer, not a design answer. The sponsor owns it, and the architecture waits on it.
• The CCv2 subscription shape. Environment count, region, and who holds Cloud Portal rights are decided once and paid for monthly. Cloud Portal access is governed separately from Backoffice user groups, so "can edit products" and "can deploy to production" are two different grants with two different owners.
• Platform currency. Staying on supported update releases is a business commitment with a security expiry attached. Somebody with budget authority has to schedule upgrade work against feature work, every year, in public.

Under the sponsor sit the ordinary two: a delivery lead accountable for the release plan and a steering forum that takes escalations on a known cadence. Both are real roles. Neither substitutes for the three decisions above.

The Delivery Engine, Named by Artifact#

The useful staffing exercise is a table of artifacts with a name in the second column. If a row is empty, that is your gap, and it is a gap you can fix before it costs a sprint.

Around that table sit two conventional roles that still need naming: a development lead who owns branches, merges, and code review, and a QA lead who owns the test pyramid and the pipeline gates. On SAP Commerce their work is platform-shaped, not generic: JUnit tests that run against the platform, ImpEx fixtures as test data, and gates wired into the CCv2 build.

The Business Representative Who Can Decide#

One business role deserves singling out, because projects stall without it and staff it as an afterthought: a representative who can decide, not relay. On SAP Commerce the decisions are concrete and each carries an engineering bill:

• Which product attributes are searchable and facetable, which changes the index and the reindex duration.
• Which pricing dimensions the business needs, because PriceRow resolves along product, currency, unit, and user group, and a fifth dimension is a customization.
• Which consents are collected, because ConsentTemplate items bind per base store and the storefront and OCC flows must enforce that.
• In B2B, which approval thresholds and budgets apply, which lands as B2BOrderThresholdPermission values and B2BBudget records per B2BCostCenter.

A committee that meets weekly turns each of those into a week of latency. Staff a decision-maker with the authority to answer in a sprint.

Subject-Matter Experts, Mapped to Configuration Surfaces#

SMEs are not full-time team members. They are the authoritative source for one domain, brought in when that domain is analyzed, and each one signs off a surface somebody will otherwise guess at:

• Merchandiser: indexed properties and boosts, synonyms, redirects, and category structure, all configured in Backoffice.
• Pricing and promotions: the price dimensions above, plus the promotion rules and their evaluation cost.
• Fulfilment and inventory: Warehouse records, the StockLevel feed and its freshness, and the priorities a sourcing strategy encodes.
• Finance: payment and tax configuration, and in B2B the cost centre and budget model.
• Data protection: the consent template set, and the retention rules that expire personal data on a schedule.
• Customer service: assisted service agent access, and which order actions an agent may take on a customer's behalf.
• Brand and content: the CMS content model, page templates, and the SmartEdit workflow the authors will live in.

Missing SMEs do not produce silence. They produce a developer's assumption, discovered in UAT.

One Person, Many Hats, No Vacancies#

On a small build one person can be architect and development lead, or data steward and release engineer. That is normal and often better, because fewer handoffs means fewer lost decisions. What cannot happen is an empty row in the table above. Multi-hatting is a way to reduce headcount, not a way to skip ownership.

Roster by Phase#

• Discovery and prepare: architect, data modeller, integration owner, business representative. The output is the type model, the integration inventory, and the first manifest.json, not code.
• Realize: peak development and QA. The search owner and the data steward are busiest here, because indexing and data loading are where the estimates were wrong.
• Deploy: the release engineer leads. Performance testing and the cutover runbook need named owners with the authority to stop a go-live.
• Run: development ramps down; the Backoffice configuration owner, the data steward, and the release engineer stay. Hypercare needs a rota, not goodwill.

Staffing Checklist#

• Every artifact row above has a named owner, and the owners know they own it
• Licensed module scope confirmed before the architecture depends on a module
• Cloud Portal rights and Backoffice permissions granted as two separate, least-privilege decisions
• A business representative who can decide within a sprint, with the four decision classes above written into the role
• Every domain mapped to a named SME and a configuration surface they sign off
• Multi-hatting used to reduce headcount, never to leave a row empty
• Roster planned per phase, with the Run-phase owners named before go-live, not after

Staffing is validated by walking the artifact table and asking who owns each row. Projects rarely stall for want of developers. They stall waiting for the person who is allowed to decide.