news & insights
back to all news
SAP Concur is the solution that enables companies to manage their business travel and expense processes: expense reports, business travel, and travel requests.
A successful SAP Concur project is not limited to putting a solution into production. It should help simplify travel and expense management processes, ensure reliable data, harmonise practices, and encourage adoption of the solution by both employees and Finance teams.
In this article, Sofia Abrunhosa, Project Manager at Arago, shares her experience of the SAP Concur projects she has supported, with practical insights into each of these seven key factors.
Sofia Abrunhosa works on SAP Concur projects involving functional requirements, governance, and international deployments.
The first step is to clearly define what the company wants to improve: reducing manual processing, harmonising expense policies, speeding up approvals, strengthening controls, or deploying a common model across several countries.
This scoping phase should make it possible to:
The project should not be designed as a simple technical reproduction of existing practices. It is an opportunity to simplify and harmonise processes before translating them into SAP Concur, including by challenging certain rules that have become too complex or difficult to apply.
The feedback from the Pernod Ricard project highlights the value of reviewing, simplifying, and harmonising existing processes. The first phase of the project covered two countries, France and the United Kingdom, as well as six organisations. See the Pernod Ricard customer case on harmonising Travel & Expense management.
A SAP Concur project generally involves several stakeholders: Finance, Procurement, IT, HR, Security, Travel Managers, travel agencies, and payment card providers. Governance helps clarify who makes decisions, who approves, who contributes, and who steps in when difficulties arise.
The project manager's role is not limited to monitoring a schedule. They must establish a decision-making framework, ensure that decisions and trade-offs are clearly understood, and maintain the commitment of the different teams.
For Sofia Abrunhosa, Project Manager at Arago, this role relies more on leadership and the ability to bring people together than on hierarchical authority. The project manager must coordinate stakeholders with different priorities while maintaining a shared vision of the objectives.
The Pernod Ricard project experience also highlights the importance of expertise capable of working with Finance, Procurement, and HR teams while also mastering the technical aspects of the solution (Pernod Ricard testimonial published by SAP Concur).
Point to watch Overly complex governance slows decision-making. Conversely, insufficient governance can lead to unapproved decisions, unclear responsibilities, and an accumulation of conflicting requests. |
In an international group, the core model defines the common foundation of the project: rules, processes, and configuration choices shared across the different entities, to facilitate the harmonisation of practices, maintenance, and future deployments.
The core model does not mean that all entities must operate in exactly the same way. The tax, legal, social, or operational requirements specific to each country must be identified, documented, and assessed. The challenge is to distinguish a genuine local requirement from a simple operational habit.
L'Oréal established a core model with its implementation partner designed to be deployed across 60 countries and 30 factories, with an organisation capable of deploying approximately 25 sites per year, according to the testimonial published by SAP Concur on L'Oréal's international project. These figures relate specifically to this project and should not be considered a universal benchmark for all SAP Concur deployments.
Point to watch A local exception should be based on a verifiable constraint. Without clear governance, the accumulation of exceptions can gradually make the model difficult to maintain. |
When deploying across several countries, it is recommended to define the common rules that cannot be modified, the elements that can be adapted locally, the authorities responsible for approving exceptions, and how these decisions will be documented.
The Pernod Ricard customer case illustrates this approach: a global baseline model was created with common processes for the different countries and entities, while taking localisation and language requirements into account.
One of the main pitfalls Sofia identifies with customers is the temptation to reproduce their existing processes identically in the new solution. This logic leads to stretching the capabilities of the standard model, to the detriment of simplicity and sustainability. She cites the case of a customer who rejected Concur's standard functionalities in favor of an advanced configuration to suit his habits, resulting in delays, additional costs and technical complexity. For her, staying as close as possible to the tool's standard is essential to guarantee stability, support and access to future innovations.
Sofia applies a waterfall methodology, but does not hesitate to introduce agile elements into large-scale projects. Daily meetings, incremental deliveries and continuous readjustments energize follow-up and reinforce team involvement. This flexibility is invaluable, particularly in times of crisis, as demonstrated by the simultaneous launch of Concur in 24 countries for SWIFT in the midst of the COVID-19 pandemic - a challenge successfully met.
One of the most common risks is trying to reproduce existing processes exactly in the new tool, which can lead to an excessive number of specific configurations and increase project complexity.
For each specific request, the project team should ask four questions: does the request address a legal or regulatory requirement, or is it simply a preference? Is there already a standard feature that meets the need? Can the business process be simplified? What will be the impact of this choice on maintenance and future upgrades?
Prioritising standard features does not mean giving up all adaptations: it means reserving specific configurations for genuinely justified requirements and documenting their consequences.
Sofia Abrunhosa notably cites the example of a client that opted for extensive configuration in order to preserve its existing practices, resulting in delays, additional costs, and increased technical complexity.
Good to know The right question is not only “Can SAP Concur reproduce this process?”, but rather “Does this process really need to be maintained in this form?”. |
Each specific requirement should therefore be assessed based on its business value, complexity, and long-term impact.
SAP Concur does not operate in isolation: the project may require integrations with the HRIS, ERP, accounting systems, payment tools, travel agencies, or other applications used by the company.
For each interface, teams should in particular verify the source of record for each data element, the frequency of exchanges, transformation rules, the handling of new hires, departures and organisational changes, error management, as well as data protection and traceability.
When SAP SuccessFactors is the source of employee data, Arago ConnectHR enables data synchronisation between SAP SuccessFactors and SAP Concur, including employee hires, departures, and updates to employee information, without relying on Excel reconciliation files.
Testing should cover common scenarios, as well as exceptions that could lead to errors after go-live: manager changes, approval delegation, cost centre changes, users assigned to multiple organisational structures, missing receipts, rejected accounting flows, or employees joining or leaving during a reporting period.
The Pernod Ricard project notably illustrates the importance of integrations: the setup presented by Arago includes integration with Oracle JDE and Workday, in addition to the global model deployed with SAP Concur (Pernod Ricard customer case).
Pilot users provide a perspective that complements that of the project teams: they can identify points of confusion, unnecessary steps, or scenarios that were not anticipated. Their feedback should be collected early enough to allow adjustments before go-live.
A structured methodology is still necessary to organise project scoping, design, configuration, testing, and go-live. These milestones can be complemented by shorter validation cycles to avoid discovering issues too late: regular workshops, interim demonstrations, progressive validation, and documented decision tracking.
Sofia Abrunhosa recommends a waterfall approach enhanced with agile practices. The overall framework helps secure responsibilities and milestones, while short cycles facilitate collaboration and adjustments. The experience published by Arago notably mentions daily meetings, incremental deliveries, and continuous adjustments on large-scale projects.
This flexibility was notably used when SAP Concur was deployed simultaneously across 24 countries for SWIFT during the COVID-19 pandemic, an example drawn from Sofia Abrunhosa's experience shared by Arago.
The objective is not to oppose the two methodologies, but to maintain a clear organisation while giving teams the ability to test, validate, and adjust the solution throughout the project.
SAP Concur also emphasises that thorough preparation upstream is an important foundation for promoting solution adoption (SAP Concur resource on preparing an implementation project).
Key decisions should be recorded in a shared document specifying the topic addressed, the options considered, the decision made, the person responsible for approval, and the functional or technical implications. This documentation helps prevent misunderstandings and facilitates decision-making when the project evolves.
Change management should begin before go-live: impact analysis, communication, training, user support, and adoption monitoring. The adoption plan may include internal ambassadors, training tailored to different roles, short guides covering common tasks, and enhanced support during the launch period.
Employees, managers, Finance teams, and administrators do not use SAP Concur in the same way, so support materials should be tailored to their responsibilities and actual needs.
The SAP Concur guide covering the seven stages of change management recommends assessing impacts, aligning stakeholders, training users, communicating, and measuring user satisfaction before, during, and after go-live.
Post-go-live support should be defined before launch: functional questions, login issues, incorrect employee data, integration errors, enhancement requests, or incidents affecting multiple users. An enhanced support period can also be planned for the first few weeks of use to address recurring issues quickly.
Support therefore does not stop at deployment. Arago supports clients throughout the different stages of Travel & Expense transformation, from process analysis through to support and continuous improvement. → Discover Arago's Travel & Expense support
Key takeaway Go-live does not mark the end of the project. It marks the beginning of a phase of monitoring, support, and continuous improvement. |
KPIs should be defined during the scoping phase and tailored to the company's objectives.
| Objective | Example KPIs |
| Adoption | Percentage of active users, frequency of use |
| Quality | Number of rejected or corrected submissions |
| Speed | Average processing or approval time |
| Automation | Percentage of controls or processes automated |
| Support | Volume and nature of requests received |
| Reliability | Number of integration errors or rejections |
| Satisfaction | Feedback from users and managers |
| Compliance | Number of deviations identified against internal policies |
These KPIs are not only used to assess the initial success of the project: they also help identify difficulties encountered by users and prioritise improvement actions. An indicator should always be interpreted in context: for example, a temporary increase in support requests may be normal during the launch phase.
As a specialist in support function transformation projects, Arago supports companies in scoping, deploying, and optimising their SAP Concur solutions.
Since 2015, Arago has supported organisations in implementing SAP Concur and transforming their Travel & Expense processes. This support is based on a dedicated team combining Travel & Expense functional expertise with in-depth technical knowledge of the solution, covering every stage of the project: process analysis, governance, core model design, configuration, integrations, testing, change management, and continuous improvement.
This combination of functional and technical expertise enables Arago to support both single-country deployments and international projects involving multiple entities and systems.
Are you preparing an SAP Concur project or looking to secure an ongoing deployment?
Discover how Arago supports organisations in transforming their Travel & Expense processes
Find out more in the full version of his video interview:
An SAP Concur core model is a common framework bringing together the processes, business rules, and configuration principles intended for use across multiple entities or countries. It enables an organisation to harmonise how the Group operates while structuring the local adaptations that are genuinely required. The Pernod Ricard customer case provides an example of a global model combining common processes with adaptations related to localisation and languages.
Not systematically. The project provides an opportunity to simplify processes before configuration. A specific customization should address a justified need and be assessed based on its impact on maintenance and future developments.
The composition depends on the scope, but it generally includes Finance, IT, Procurement, Travel, and Security teams, as well as those responsible for employee data. Local representatives and pilot users should also be involved when the project covers multiple entities.