BEYOND ESSENTIALS
Core insight: A global SAP rollout is decided before the design phase starts – by seven choices on rollout strategy, local staffing, regional alignment, statutory validation, scope beyond the ERP, shared methodology, and partner trust.
Consequence: Skipping these decisions forces expensive rework once local realities surface mid-implementation, usually when a subsidiary pushes back or a statutory requirement appears during testing.
Mid-market angle: A mid-market company rarely has the budget or spare staff for a second attempt. Getting it right takes discipline more than money: seven decisions, made early and on purpose.
A mid-market company expanding across borders usually has one shot at a global SAP implementation. There's no budget for a second attempt, and no time zone gives you a redo. The companies that get it right settle seven things before the project starts, regardless of team size or budget. All seven come from our Mid-Market Playbook for Global SAP Transformations.
DOWNLOAD THE FULL MID-MARKET PLAYBOOK HERE →
Settle your rollout strategy first, then choose who delivers it. A centralized rollout designs the global template at headquarters first, then rolls it out to subsidiaries in waves. A roll-in approach starts in one smaller, lower-risk subsidiary and expands outward. A global approach builds the template with every major market at the table from day one. Each trades speed for durability differently, and centralized, roll-in, or global compares the three in detail. With the strategy settled, you can judge partners on how well they deliver that model.
For a mid-market company, this decision also sets your budget shape. A centralized rollout is resource-heavy upfront, with shorter rollouts once the template is proven. A roll-in has a shorter start and spreads the same resources over longer rollouts. The global approach is the most resource-intensive and tends to produce the most durable result.
Decide early which workstreams need local ownership and which a global team can lead centrally. Statutory reporting, tax configuration, and labor compliance almost always need someone who lives in that country's regulatory environment. Core data models and system architecture usually don't. Consultants who only show up for execution inherit decisions they had no hand in making, and it shows in how confidently they can defend those decisions to a skeptical subsidiary.
For a mid-market company running lean, this split matters more than it does for an enterprise with redundant regional teams: you cannot afford to staff local expertise everywhere, so you need to know precisely where it's non-negotiable.
Every global SAP project produces differing perspectives between regions – on how much customization is reasonable, on how decisions should get made, on what a subsidiary is being asked to give up. Acknowledging this from day one resolves it in weeks; ignoring it turns it into resistance mid-project, when it's far more expensive to address.
This is where joint communication between the delivery team and the customer's regional stakeholders earns its keep. As Michael Greene, Principal at Answerthink, put it: "Too many times, engaging local partners is done after the fact. The ability to join forces, to establish joint communications, to establish an effective, consistent, holistic message – that has to happen before you meet with the customer."
A mid-market company rarely has a change-management department to absorb friction like this quietly; it has to be handled at the project level, from the start.
Validate legal, tax, and compliance requirements in every target country before configuration begins. Requirements vary dramatically by jurisdiction, and a partner who lives those requirements daily saves months of rework compared to a team learning them from documentation mid-project. Build these checks into the fit-to-standard workshops for each country, while the global template is still open. Late statutory discoveries are the first of the four traps that derail global SAP rollouts: a design that's technically sound everywhere and legally viable nowhere it hasn't been checked.
For a mid-market company expanding into two or three new countries, this is usually a matter of a handful of site visits or local expert consultations before the design phase locks – cheap insurance against a very expensive redesign.
A global transformation routinely surfaces needs beyond the ERP itself. E-commerce gaps, analytics needs, and AI-powered tooling requirements tend to appear during an SAP evaluation, once a company takes a hard look at how its regional operations actually run. Ask Odin, an AI assistant for a Brazilian factory floor, is one example. An alliance model gives you access to a specialist for each of these without adding a new vendor relationship for every capability.
For a mid-market company, this is the difference between discovering a gap and paying to fix it twice, or catching it once during the same engagement that's already underway.
Multiple partners working from different playbooks create friction that shows up as quiet delay long before anything visibly fails. Ask for a governance framework that every partner follows: common templates, escalation procedures, and quality gates that don't depend on any one person remembering to loop the right stakeholder in. Within UNITED VARS, the Project Handbook sets that framework, aligned with SAP Activate. When members from different countries operate from the same playbook, alignment that would otherwise take weeks happens in days.
Technical capability is close to table stakes at this point – most credible SAP partners can configure the system correctly. Trust between the partners in the room is harder to evaluate, and it's the better predictor of how the project actually goes. Watch how they present together and how they handle disagreement in front of you. That tells you more about how the project will run than any credentials slide.
For a mid-market company choosing between a single large integrator and a coalition of local specialists, the diligence worth doing is checking whether these partners have delivered a joint project like this before, and whether they defer to each other's judgment without ego. How to evaluate an SAP implementation partner for a global rollout goes deeper on this.
All seven decisions get easier when local expertise is already in place. UNITED VARS members know the statutory requirements, business culture, and people in their markets, and they work under one shared methodology. How the alliance delivers for the mid-market explains the mechanics. For the full picture, start at the Mid-Market Playbook series overview.
Working through these seven decisions right now? Talk to us.
Mid-sized companies should go global without losing speed or local identity. UNITED VARS brings together hand-picked local market leaders with real people on the ground in 100+ countries to remove legal, cultural, and language barriers. As a strategic alliance, UNITED VARS provides clear accountability from start to finish. UNITED VARS is the world's only SAP Platinum Partner alliance, delivering end-to-end SAP services for the mid-market.
stronger than one.
Seven things: the rollout strategy, which workstreams need local ownership, how regional disagreement gets surfaced, when statutory requirements get validated, which needs beyond the ERP to plan for, which shared methodology all partners follow, and how to judge trust between partners. Settling these before design starts keeps the global template stable once local realities surface.
A centralized rollout builds the global template at headquarters and deploys it to subsidiaries in waves: a longer start, shorter rollouts. A roll-in approach starts in one smaller, lower-risk subsidiary and expands from there: a shorter start, longer rollouts. A global approach involves every major market from the design phase onward. It's the most resource-intensive and tends to produce the most durable result.
Statutory and legal requirements discovered late – during testing or after go-live, when the design is already built. Fixing a design that's non-compliant in one country almost always costs more than validating requirements upfront would have. Checking each country's requirements in fit-to-standard workshops before the global template locks is the cheapest insurance.
No dedicated department is required. The project team itself has to surface regional disagreement early and communicate consistently across markets. That means involving regional stakeholders before the design is set, explaining what each subsidiary keeps and what changes, and letting people who know the local business culture present the global template in each market.
Judge them on whether they've delivered a joint project like this before and how they handle disagreement in front of you. Technical capability matters too, but most credible SAP partners can configure the system correctly. Far fewer can do it together, across borders, without friction.