How to Evaluate an SAP Implementation Partner in Saudi Arabia

Confirm the provider’s relevant SAP product experience, proposed consultants and delivery responsibilities. Request comparable project references, a documented implementation method, evidence of applicable Saudi localisation capability and clear plans for integration, testing, change management and support. Score written evidence consistently, and resolve mandatory requirements before using commercial terms to make the final selection.

Start with an agreed project brief. Include business outcomes, entities, processes, existing systems, critical interfaces and expected customer participation. Every shortlisted provider should respond to that same brief.

1. Does the partner fit the SAP product and project?

“SAP experience” is too broad to establish suitability. Ask which product, edition, deployment model and implementation scope the proposed team has delivered.

A new implementation, an existing-system conversion and a regional rollout involve different decisions and dependencies. Experience with one SAP product does not automatically establish expertise in another.

Request a written explanation of why the proposed solution fits your operating model. Ask which requirements use standard functionality, which need configuration and which require extensions or separate products.

For detailed migration and readiness considerations, use our SAP S/4HANA Saudi Arabia implementation guide. This evaluation should establish whether the partner can deliver the agreed project.

2. Can you verify credentials and comparable delivery experience?

Check claimed partner status through SAP’s official partner directory. SAP distinguishes different partner activities, including selling, building, consulting and implementation. Verify the relationship relevant to the work being proposed.

Then assess the named consultants. Request relevant certifications, recent project roles and availability. Organisational credentials and individual qualifications provide different evidence; neither replaces a reference discussion.

Ask a reference customer:

• Was the delivered scope comparable to ours?
• Did the proposed senior consultants remain involved?
• How were disputed requirements and additional charges handled?
• What problems appeared after launch, and who resolved them?

Obtain permission-based references where possible. A logo list cannot explain delivery quality or the responsibilities the provider actually performed.

3. Can the team demonstrate your important processes?

Give providers the same practical scenarios. A Saudi distributor might request purchasing, partial receipt, inventory transfer, customer credit checks and financial posting. A project-based company may prioritise commitments, cost allocation and approval controls.

Ask the consultants who would deliver the project to lead the demonstration. Follow a transaction through operational records, accounting entries and management reporting.

Include an exception, such as a rejected invoice or returned item. Ask what happens, who acts and how the system records the correction.

The result should be a documented fit assessment with gaps and assumptions. Distinguish demonstrated functionality from items promised for later development.

4. How will the partner apply its implementation methodology?

If the proposal references SAP Activate, ask how its activities translate into deliverables and approvals for your project.

SAP’s Activate learning guidance describes six phases: Discover, Prepare, Explore, Realize, Deploy and Run. Fit-to-standard workshops help assess standard processes and identify required changes.

Request examples of the requirements register, decision log, test plan and milestone acceptance criteria. Ask how requirements remain traceable through configuration and testing.

Also establish who approves extensions and how the team assesses their effect on upgrades and maintenance. A methodology label becomes useful when the statement of work defines evidence, ownership and decision points.

5. How will Saudi regulatory requirements be addressed?

Ask the provider to identify requirements relevant to your entities and processes, then demonstrate the proposed implementation. Your finance, tax, legal and security teams should validate applicability within their areas.

VAT and ZATCA e-invoicing

Request evidence covering relevant tax scenarios, invoice types, credit notes and accounting reconciliation.

ZATCA’s e-invoicing rollout guidance explains that the integration phase is introduced in waves for targeted taxpayer groups. Confirm your applicable notification and requirements directly.

Ask who owns the Fatoora connection, how the relevant clearance or reporting workflows are tested, and how rejected documents and interruptions are handled. Establish whether the design uses SAP functionality, a separate solution or an integration provider.

Personal data and security

Request a data-flow diagram covering hosting, backups, support access and third parties. Identify personal data in employee, supplier and customer records.

Review the applicable obligations with your legal and security teams using SDAIA’s Personal Data Protection Law guidance. Where cross-border transfers or sector-specific controls are relevant, confirm the required arrangements explicitly. Avoid treating a hosting location or general compliance claim as sufficient evidence.

6. Who owns each implementation responsibility?

The implementation partner, your organisation, SAP and other providers may hold different responsibilities. Put the agreed boundaries into the contract, including escalation when a problem crosses them.

Use this comparison as a starting point, then adapt it to your deployment and service agreements.

Activity	Implementation partner	Customer organisation	SAP or other provider, as contracted
Process design	Facilitate and document the proposed design.	Supply process owners and approve decisions.	Clarify product capabilities where required.
Configuration and extensions	Deliver agreed work and documentation.	Approve requirements and changes.	Provide contracted platform or product services.
Data migration	Define the mapping, loading and validation approach.	Own source data quality and approve reconciliation.	Supply agreed tools or extraction access.
Integrations	Deliver and test assigned interfaces	Coordinate system owners and approve outcomes.	Maintain assigned endpoints or services.
User acceptance	Support tests and resolve assigned defects.	Execute business tests and approve acceptance.	Address issues within the contracted scope.
Go-live and support	Deliver agreed cutover and support activities.	Approve readiness and operational ownership.	Meet contracted service responsibilities.

Resolve gaps before award. “The other vendor handles it” needs a named owner and an accepted scope.

7. How will integrations and technical changes be maintained?

Ask for an architecture showing the SAP landscape and connected banking, payroll, CRM, warehouse, e-commerce or industry systems. Confirm record ownership, interface direction and failure handling.

For each interface or extension, request development responsibility, documentation, monitoring, testing and maintenance ownership. Ask which SAP Business Technology Platform services or other components are required and whether their commercial arrangements are included.

Test the explanation against an upgrade: who checks compatibility, who corrects failures and what support covers the work?

The proposed SAP consultant in KSA should explain technical choices in terms of business dependencies and ongoing responsibilities.

8. What testing and change management will the partner deliver?

Request a test strategy covering configuration, complete business processes, interfaces, permissions and relevant performance needs. Migration tests should include reconciliation and exception handling.

Your team should own business acceptance with partner support. Agree on defect severity, retesting evidence and the conditions that prevent go-live.

Change management needs a separate plan: process-owner engagement, role-based training, communications and user support. Confirm training languages and whether users practise realistic tasks.

Ask how the partner will demonstrate readiness. Attendance records alone cannot show that a user can complete an essential transaction correctly.

9. What happens after go-live?

Separate initial stabilisation from ongoing application support, platform operations and product support. Confirm who handles each layer.

Request coverage hours, severity definitions, response commitments, escalation routes and exclusions. Distinguish acknowledgement from investigation, workaround and resolution targets.

Ask how the service handles regulatory changes, upgrades, integrations and extensions. Establish what documentation and knowledge transfer your internal team receives.

Finally, clarify exit arrangements: data access, configuration records, source-code rights where applicable and handover support. Operational continuity should not depend on undocumented knowledge held by one consultant.

Weighted SAP partner-selection scorecard

Have finance, IT, operations and procurement score the same evidence. Use 1 for a major gap, 3 for adequate documented capability and 5 for strong, directly relevant evidence. Record unanswered questions alongside every score.

Evaluation criterion	Weight	Evidence required
SAP product and project fit	20%	Comparable scope and justified solution approach
Named team and relevant experience	15%	Consultant roles, qualifications and reference checks
Saudi localisation and relevant controls	15%	Demonstrations, responsibilities and validation plan
Governance and scope management	15%	Deliverables, approvals, change control and escalation
Architecture and integration capability	10%	Interface design and maintenance ownership
Testing and data assurance	10%	Test strategy, reconciliation and acceptance criteria
Change management and support	10%	Training, transition and service commitments
Commercial clarity	5%	Itemised scope, assumptions, exclusions and exit terms
Total	100%

Calculate each contribution as score ÷ 5 × weight, then add them for a result out of 100. This is a proposed procurement framework, not an SAP accreditation.

Set mandatory requirements separately. An unresolved critical interface, unacceptable security arrangement or missing accountable delivery lead should prevent approval regardless of the weighted total.

Questions for the final SAP partner shortlist

Use the final interview to close evidence gaps. Ask each provider the same questions and request written responses that can become contractual commitments.

1. Which requirement presents the greatest delivery risk, and why?
2. Which named consultants are committed, and how are replacements approved?
3. What must our team provide before each milestone can proceed?
4. Which integrations, licences or third-party services remain outside scope?
5. What evidence is required for acceptance and payment milestones?
6. Who makes the go-live decision, and what conditions postpone it?
7. Who owns a production incident involving several suppliers?
8. What changes would trigger additional fees or revised delivery dates?

Compare the answers with the proposal and reference feedback. Resolve material contradictions before signing.

Discuss your Saudi SAP requirements with Aramis Solutions

Review Aramis Solutions’ SAP implementation and support services to discuss the product, project scope and support requirements relevant to your organisation.

If the programme involves connected platforms beyond SAP, our Saudi Arabia enterprise technology overview provides broader context.

Bring an agreed business brief, system landscape and critical scenarios to the discussion. Contact Aramis Solutions to clarify delivery responsibilities and the evidence needed for your evaluation.

Frequently asked questions