actualités & événements
retour à toutes les nouvelles
SAP Concur est la solution qui permet aux entreprises de gérer leurs processus liés aux déplacements et aux dépenses professionnelles : notes de frais, voyages d'affaires et demandes de déplacement.
Un projet SAP Concur réussi ne se limite pas à mettre une solution en production. Il doit permettre de simplifier les processus de gestion des voyages et des dépenses, de fiabiliser les données, d'harmoniser les pratiques et de favoriser l'adoption de la solution par les collaborateurs comme par les équipes Finance.
Dans cet article, Sofia Abrunhosa, Project Manager chez Arago, partage son retour d'expérience sur les projets SAP Concur qu'elle a accompagnés, à travers des repères concrets pour chacune de ces sept clés.
Sofia Abrunhosa intervient sur des projets SAP Concur associant enjeux fonctionnels, gouvernance et déploiements internationaux.
La première étape consiste à définir précisément ce que l'entreprise souhaite améliorer : réduire les traitements manuels, harmoniser les politiques de dépenses, accélérer les validations, renforcer les contrôles, ou déployer un modèle commun dans plusieurs pays.
Ce cadrage doit permettre de :
Le projet ne doit pas être conçu comme la simple reproduction technique des habitudes existantes. Il constitue une occasion de simplifier et d'harmoniser les processus avant leur traduction dans SAP Concur, y compris en remettant en question certaines règles devenues trop complexes ou difficiles à appliquer.
Le retour d'expérience consacré au projet Pernod Ricard souligne l'intérêt de remettre à plat les processus existants, de les simplifier et de les harmoniser. La première phase du projet a concerné deux pays, la France et le Royaume-Uni, ainsi que six organisations. Voir le cas client Pernod Ricard sur l'harmonisation de la gestion Travel & Expense.
Un projet SAP Concur mobilise généralement plusieurs parties prenantes : Finance, achats, IT, RH, sécurité, responsables Travel, agences de voyages et fournisseurs de cartes de paiement. La gouvernance permet de préciser qui décide, qui valide, qui contribue et qui intervient en cas de difficulté.
Le chef de projet ne se contente pas de suivre un planning. Il doit créer un cadre de décision, rendre les arbitrages compréhensibles et maintenir l'engagement des différentes équipes.
Pour Sofia Abrunhosa, Project Manager chez Arago, cette fonction repose davantage sur le leadership et la capacité à fédérer que sur une logique hiérarchique. Le chef de projet doit accompagner des interlocuteurs aux priorités différentes tout en conservant une vision commune des objectifs.
L'expérience du projet Pernod Ricard montre également l'importance d'une expertise capable de dialoguer avec les équipes Finance, achats et RH, tout en maîtrisant les dimensions techniques de la solution (témoignage Pernod Ricard publié par SAP Concur).
Point de vigilance Une gouvernance trop complexe ralentit les décisions. À l'inverse, une gouvernance insuffisante peut entraîner des choix non validés, des responsabilités floues et une accumulation de demandes contradictoires. |
Dans un groupe international, le core model définit le socle commun du projet : règles, processus et choix de configuration partagés entre les différentes entités, pour faciliter l'harmonisation des pratiques, la maintenance et les futurs déploiements.
Le core model ne signifie pas que toutes les entités doivent fonctionner de manière strictement identique. Les contraintes fiscales, légales, sociales ou opérationnelles propres à chaque pays doivent être identifiées, documentées et arbitrées : l'enjeu consiste à distinguer une obligation locale réelle d'une simple habitude de fonctionnement.
L'Oréal a ainsi établi avec son intégrateur un core model destiné à être déployé dans 60 pays et 30 usines, avec une organisation permettant de déployer environ 25 sites par an, selon le témoignage publié par SAP Concur sur le projet international de L'Oréal. Ces chiffres correspondent à ce projet précis et ne constituent pas une référence universelle pour tous les déploiements SAP Concur.
Point de vigilance Une exception locale doit répondre à une contrainte vérifiable. Sans gouvernance claire, l'accumulation d'exceptions peut progressivement rendre le modèle difficile à maintenir. |
Lors d'un déploiement dans plusieurs pays, il est recommandé de définir les règles communes non modifiables, les éléments pouvant faire l'objet d'une adaptation locale, les autorités chargées de valider les exceptions, et la manière dont ces décisions seront documentées.
Le cas client Pernod Ricard illustre cette approche : un modèle de base global a été créé avec des processus communs pour les différents pays et entités, tout en tenant compte des besoins de localisation et des langues.
L’un des principaux écueils que Sofia identifie chez les clients est la tentation de reproduire à l’identique leurs processus existants dans la nouvelle solution. Une logique qui pousse à étirer les capacités du modèle standard, au détriment de la simplicité et de la pérennité. Elle cite le cas d’un client ayant rejeté les fonctionnalités standards de Concur au profit d’une configuration poussée pour coller à ses habitudes, avec à la clé retards, surcoûts et complexité technique. Pour elle, rester au plus proche du standard de l’outil est essentiel pour garantir la stabilité, le support et l’accès aux innovations futures.
Sofia applique une méthodologie en cascade (waterfall) mais n’hésite pas à introduire des éléments agiles dans les projets d’envergure. Réunions quotidiennes, livraisons incrémentales et réajustements en continu viennent dynamiser le suivi et renforcer l’implication des équipes. Une flexibilité précieuse, notamment en contexte de crise, comme l’a démontré la mise en production simultanée de Concur dans 24 pays pour SWIFT en pleine pandémie de COVID-19 — un défi relevé avec brio.
L'un des risques les plus fréquents consiste à vouloir reproduire exactement les anciens processus dans le nouvel outil, au risque de multiplier les configurations spécifiques et d'augmenter la complexité du projet.
Pour chaque demande particulière, l'équipe projet doit se poser quatre questions : la demande répond-elle à une obligation ou à une préférence ? Une fonctionnalité standard couvre-t-elle déjà le besoin ? Le processus métier peut-il être simplifié ? Quel sera l'impact du choix sur la maintenance et les évolutions futures ?
Privilégier les fonctionnalités standards ne signifie pas renoncer à toute adaptation : il s'agit de réserver les spécificités aux besoins réellement justifiés et de documenter leurs conséquences.
Sofia Abrunhosa cite notamment le cas d'un client ayant privilégié une configuration poussée afin de conserver ses pratiques existantes, avec des retards, des surcoûts et une complexité technique à la clé.
Bon à savoir La bonne question n'est pas uniquement « SAP Concur peut-il reproduire ce processus ? », mais plutôt « ce processus doit-il réellement être conservé sous cette forme ? ». |
Chaque spécificité doit donc être évaluée en fonction de sa valeur métier, de sa complexité et de son impact à long terme.
SAP Concur ne fonctionne pas de manière isolée : le projet peut nécessiter des échanges avec le SIRH, l'ERP, les systèmes comptables, les outils de paiement, les agences de voyages ou d'autres applications utilisées par l'entreprise.
Pour chaque flux, les équipes doivent notamment vérifier la source de référence de chaque donnée, la fréquence des échanges, les règles de transformation, la gestion des entrées, sorties et changements d'affectation, le traitement des erreurs, ainsi que la protection et la traçabilité des données.
Lorsque SAP SuccessFactors constitue la source des données collaborateurs, Arago ConnectHR permet de synchroniser les données entre SAP SuccessFactors et SAP Concur, notamment les entrées, sorties et mises à jour des informations collaborateurs, sans recourir à des fichiers Excel de réconciliation.
La recette doit couvrir les scénarios courants, mais aussi les exceptions susceptibles de provoquer des erreurs après le lancement : changement de manager, délégation de validation, modification de centre de coûts, utilisateur rattaché à plusieurs structures, justificatif manquant, flux comptable rejeté, arrivée ou départ en cours de période.
Le projet Pernod Ricard illustre notamment l'importance des intégrations : le dispositif présenté par Arago comprend une intégration avec Oracle JDE et Workday, en complément du modèle global déployé avec SAP Concur (cas client Pernod Ricard).
Les utilisateurs pilotes apportent un regard complémentaire à celui des équipes projet : ils identifient des difficultés de compréhension, des étapes inutiles ou des scénarios non anticipés. Leurs retours doivent être recueillis suffisamment tôt pour permettre des ajustements avant la mise en production.
Une méthodologie structurée reste nécessaire pour organiser le cadrage, la conception, le paramétrage, les tests et la mise en production. Ces jalons peuvent être complétés par des cycles de validation plus courts, afin d'éviter que les difficultés soient découvertes trop tard : ateliers réguliers, démonstrations intermédiaires, validations progressives, suivi documenté des décisions.
Sofia Abrunhosa recommande une approche waterfall enrichie de pratiques agiles. Le cadre général permet de sécuriser les responsabilités et les jalons, tandis que les cycles courts facilitent la collaboration et les ajustements. Le retour d'expérience publié par Arago mentionne notamment des réunions quotidiennes, des livraisons incrémentales et des réajustements continus sur les projets d'envergure.
Cette flexibilité a notamment été utilisée lors de la mise en production simultanée de SAP Concur dans 24 pays pour SWIFT, pendant la pandémie de COVID-19, un exemple issu du retour d'expérience de Sofia Abrunhosa publié par Arago.
L'objectif n'est pas d'opposer deux méthodologies, mais de conserver une organisation claire tout en donnant aux équipes la possibilité de tester, de valider et d'ajuster la solution tout au long du projet.
SAP Concur rappelle également que la préparation en amont constitue une base importante pour favoriser l'adoption de la solution (ressource SAP Concur sur la préparation d'un projet d'implémentation).
Les principales décisions doivent être consignées dans un document partagé précisant le sujet traité, les options étudiées, la décision retenue, la personne responsable de la validation et les conséquences fonctionnelles ou techniques. Cette documentation limite les incompréhensions et facilite les arbitrages lorsque le projet évolue.
La conduite du changement doit commencer avant la mise en production : analyse des impacts, communication, formation, accompagnement des utilisateurs et suivi de l'adoption. Le plan d'adoption peut notamment prévoir des ambassadeurs internes, des formations adaptées aux différents rôles, des guides courts sur les tâches courantes et une assistance renforcée pendant le lancement.
Les collaborateurs, les managers, les équipes Finance et les administrateurs n'utilisent pas SAP Concur de la même manière : les supports doivent donc être adaptés à leurs responsabilités et à leurs besoins réels.
Le guide SAP Concur consacré aux sept étapes de la gestion du changement recommande d'évaluer les impacts, d'aligner les parties prenantes, de former les utilisateurs, de communiquer et de mesurer leur satisfaction avant, pendant et après la mise en production.
Le support après la mise en production doit être défini avant le lancement : question fonctionnelle, problème de connexion, donnée collaborateur incorrecte, erreur d'intégration, demande d'évolution, incident affectant plusieurs utilisateurs. Une période de support renforcé peut également être prévue pendant les premières semaines d'utilisation, pour traiter rapidement les difficultés récurrentes.
L'accompagnement ne s'arrête donc pas au déploiement. Arago intervient sur les différentes étapes de la transformation Travel & Expense, depuis l'analyse des processus jusqu'au support et à l'amélioration continue. → Découvrez l'accompagnement Travel & Expense d'Arago
À retenir La mise en production ne constitue pas la fin du projet. Elle marque le début d'une phase d'observation, de support et d'amélioration continue. |
Les indicateurs doivent être définis pendant la phase de cadrage et adaptés aux objectifs de l'entreprise.
| Objectif | Exemples d'indicateurs |
| Adoption | Part des utilisateurs actifs, fréquence d'utilisation |
| Qualité | Nombre de dossiers rejetés ou corrigés |
| Rapidité | Délai moyen de traitement ou de validation |
| Automatisation | Part des contrôles ou traitements automatisés |
| Support | Volume et nature des demandes reçues |
| Fiabilité | Nombre d'erreurs ou de rejets d'intégration |
| Satisfaction | Retours des utilisateurs et des gestionnaires |
| Conformité | Nombre d'écarts détectés par rapport aux règles internes |
Ces indicateurs ne servent pas uniquement à évaluer le succès initial du projet : ils permettent d'identifier les difficultés rencontrées par les utilisateurs et de prioriser les actions d'amélioration. Un indicateur doit toujours être interprété dans son contexte : une augmentation temporaire des demandes adressées au support peut, par exemple, être normale pendant la phase de lancement.
Spécialiste des projets de transformation des fonctions support, Arago accompagne les entreprises dans le cadrage, le déploiement et l'optimisation de leurs solutions SAP Concur.
Depuis 2015, Arago accompagne les organisations dans l'implémentation de SAP Concur et la transformation de leurs processus Travel & Expense. Cet accompagnement s'appuie sur une équipe dédiée, combinant expertise fonctionnelle Travel & Expense et maîtrise technique de la solution, pour couvrir chaque étape du projet : analyse des processus, gouvernance, conception du core model, paramétrage, intégrations, tests, conduite du changement et amélioration continue.
Cette double compétence, fonctionnelle et technique, permet à Arago d'accompagner aussi bien des déploiements dans un seul pays que des projets internationaux mobilisant plusieurs entités et systèmes.
Vous préparez un projet SAP Concur ou souhaitez sécuriser un déploiement en cours ?
Pour en savoir plus, découvrez la version intégrale de son interview vidéo en anglais :
Un core model SAP Concur est un socle commun regroupant les processus, les règles de gestion et les principes de configuration destinés à plusieurs entités ou pays. Il permet d'harmoniser le fonctionnement du groupe tout en encadrant les adaptations locales réellement nécessaires. Le cas client Pernod Ricard présente un exemple de modèle global intégrant des processus communs et des adaptations liées à la localisation et aux langues.
Pas systématiquement. Le projet représente une occasion de simplifier les processus avant le paramétrage. Une adaptation spécifique doit répondre à un besoin justifié et être évaluée en fonction de son impact sur la maintenance et les évolutions futures.
La composition dépend du périmètre, mais elle comprend généralement les équipes Finance, IT, achats, Travel et sécurité, ainsi que les responsables des données collaborateurs. Des référents locaux et des utilisateurs pilotes doivent également être associés lorsque le projet couvre plusieurs entités.