Aller au contenu

Modèle de business case SAP : obtenir l'approbation sans délai

Les business cases SAP calent à cause de leur rédaction, pas de la technologie. La structure, les coûts à y faire figurer et la façon de montrer un ROI qu'un DAF croira.

Ordinateur portable affichant des icônes de business case à côté d'une calculatrice, de carnets et de lunettes de lecture
Sommaire
  1. Rédigez pour ceux qui l'approuvent
  2. Le résumé exécutif décide de tout
  3. Écrivez pour trois lecteurs
  4. Modèle de business case SAP
  5. Le dossier financier
  6. Les coûts qu'un directeur financier cherchera
  7. ROI, délai de récupération et bénéfices que le DAF croira
  8. Ce que RISE, GROW et l'IA changent dans le dossier
  9. Les erreurs qui tuent les business cases
  10. Questions fréquentes

Un business case SAP est approuvé quand les décideurs voient le problème, le coût, le retour et le risque sur une seule page, dans leurs propres termes. Utilisez la structure en sept sections ci-dessous, incluez tous les coûts sur au moins cinq ans, gardez des hypothèses de bénéfices prudentes et rédigez des passages séparés pour le DAF, la DSI et le métier. La plupart des dossiers qui calent échouent sur la présentation, pas sur l'idée.

J'ai vu des approbations traîner des semaines, parfois des mois, alors que l'idée était solide. Je me souviens d'une migration S/4HANA où le premier pitch a échoué. La proposition était bourrée de schémas d'architecture système et ne disait presque rien des gains opérationnels. Nous l'avons retravaillée pour que l'ouverture porte sur la réduction des retards d'expédition, la baisse des coûts de stock et la façon dont l'équipe allait livrer. Le DAF l'a approuvée en une seule réunion.

Un dernier point avant le modèle. Votre partenaire d'intégration ne doit pas rédiger votre business case. Son intérêt est de lancer le programme. Le vôtre est de le terminer. C'est ainsi que des programmes de 40 millions de dollars deviennent discrètement des programmes de 90 millions.

Le résumé exécutif décide de tout

Tenez-le sur une page. Les dirigeants ne liront peut-être rien d'autre.

Commencez par le problème, en chiffres. Énoncez la proposition en une ou deux phrases, sans détail technique. Donnez ensuite les principaux bénéfices chiffrés, un calendrier simple, l'investissement total et les risques clés avec leurs mesures d'atténuation.

Dans l'une des entreprises que j'ai accompagnées auparavant, le résumé s'ouvrait sur des termes comme « objets techniques » et « Embedded HANA ». Le DAF l'a posé après le premier paragraphe. Nous l'avons réécrit pour commencer par « 2,5 millions de dollars d'économies annuelles grâce à la réduction des stocks » et « traitement des commandes 40 % plus rapide ». Le même DAF a lu toute la page et approuvé le projet dans la semaine.

Quand le résumé est terminé, donnez-le à quelqu'un d'extérieur au projet. S'il peut vous l'expliquer en retour, il fonctionne.

Écrivez pour trois lecteurs

Une seule version pour tout le monde ne marche pas. J'ai vu de bonnes propositions mourir parce qu'elles étaient écrites pour le mauvais public.

Un business case, trois lecteursLe même plan, lu de trois façons. Rédigez un passage pour chaque lecteur, sinon l'un d'eux bloquera l'approbation.
DAF et conseil d'administrationDSIUtilisateurs métier
Ce qu'ils cherchentDAF et conseil d'administrationDes chiffres qu'ils peuvent répéter sans notesDSILe périmètre d'intégration cartographié par rapport aux systèmes actuelsUtilisateurs métierUne image tâche par tâche de leur semaine
À leur donnerDAF et conseil d'administrationLes économies annuelles et le délai de récupération, avec les risques énoncés sans détourDSILe modèle de support après le go-liveUtilisateurs métierL'avant et l'après, avec un temps de formation honnête
Ce qui les convaincDAF et conseil d'administrationLa franchise plutôt que l'optimismeDSILa preuve que vous savez où des projets similaires ont mal tournéUtilisateurs métierL'honnêteté sur chaque clic supplémentaire

Le DAF et le conseil d'administration veulent des chiffres qu'ils peuvent répéter sans notes : « 2 millions de dollars d'économies annuelles, récupération en 18 mois ». Ils veulent les risques énoncés sans détour. Avec ce public, la franchise l'emporte sur l'optimisme.

La DSI veut le périmètre d'intégration cartographié par rapport aux systèmes actuels, le modèle de support après le go-live et la preuve que vous savez où des projets similaires ont mal tourné.

Les utilisateurs métier veulent une image tâche par tâche de leur semaine avant et après, et un chiffre honnête pour le temps de formation. Un petit clic supplémentaire, répété des milliers de fois par semaine, devient un vrai problème.

Un jour, une directrice financière a rejeté un business case en pleine réunion, parce qu'il ne répondait à aucune de ses questions. Nous l'avons reconstruit en trois sections, une par public, chacune ancrée sur des KPI mesurables. Le plan technique n'a jamais changé. Seule la façon de le raconter a changé.

Voici les sept sections que j'utilise, dans cet ordre. Je me souviens d'une entreprise industrielle dont le DAF a trouvé le détail des coûts enterré en page 23, pendant que le DSI ne trouvait pas du tout les risques techniques. L'approbation a glissé de six mois. Avec une version structurée, l'approbation a pris deux semaines, alors que le contenu avait à peine changé.

SectionCe qu'elle doit contenir
Résumé exécutifProblème chiffré, proposition, bénéfices, investissement total, calendrier, principaux risques
Situation actuellePoints de douleur, leur coût aujourd'hui et le coût de l'inaction
Approche proposéePérimètre, modules, modèle de déploiement (RISE, GROW ou sur site), principales intégrations
Dossier financierCoûts et bénéfices sur cinq ans, ROI, délai de récupération, VAN pour les grands programmes
Plan de mise en œuvrePhases, jalons, équipe, dépendances
RisquesRisques précis avec responsables et mesures d'atténuation
GouvernanceSponsor, comité de pilotage, contrôle des changements, règles d'approbation des extensions

Gardez les schémas d'architecture et le détail du paramétrage en annexe.

Les coûts qu'un directeur financier cherchera

Les coûts incomplets tuent plus de business cases que des bénéfices faibles. Incluez tout ceci :

  1. Logiciel : licence plus support annuel pour le sur site, ou abonnement pour RISE et GROW.
  2. Honoraires du partenaire d'intégration.
  3. Infrastructure, si vous l'exploitez vous-même ; avec RISE, SAP l'exploite dans le cadre de l'abonnement.
  4. Temps du personnel interne. C'est la ligne le plus souvent absente.
  5. Formation et conduite du changement.
  6. Migration et nettoyage des données.
  7. Support récurrent. Pour SAP Enterprise Support sur site, il représente depuis longtemps environ 22 % de la valeur de la licence par an. Pour RISE et GROW, montrez l'abonnement pour chaque année de la durée.
  8. Hypercare après le go-live.

Le point 7 est la première chose que beaucoup de directeurs financiers vérifient. Si les années deux à cinq manquent, la crédibilité chute aussitôt. Mon guide des coûts d'une mise en œuvre SAP donne les fourchettes habituelles pour chaque ligne, et mon guide de revue de contrat pour les DAF traite du côté partenaire.

ROI, délai de récupération et bénéfices que le DAF croira

Le ROI est le bénéfice net divisé par l'investissement total. 3,5 millions de dollars de bénéfices sur cinq ans pour 2 millions de coûts donnent un bénéfice net de 1,5 million de dollars, soit 75 %.

Le délai de récupération est l'investissement divisé par le bénéfice net annuel en trésorerie. Un projet de 1,2 million de dollars qui rapporte 400 000 $ par an est amorti en trois ans.

La VAN (valeur actuelle nette) ramène les flux de trésorerie futurs à leur valeur d'aujourd'hui. Si le conseil la demande, faites venir votre équipe finance dans la salle.

Chiffrez les bénéfices en montrant le calcul :

  • Stocks : 10 millions de dollars de stock, réduits de 15 %, avec un coût de possession de 20 %, font économiser 300 000 $ par an.
  • Temps de traitement : une tâche de 45 minutes exécutée 200 fois par jour, ramenée à 15 minutes, à 30 $ de l'heure, fait économiser environ 750 000 $ par an sur 250 jours ouvrés.

Montrez une montée en charge. Les bénéfices de la première année après le go-live sont généralement inférieurs à ceux du régime établi. Gardez les bénéfices que vous ne pouvez pas chiffrer sur une liste à part, pour qu'ils ne diluent pas ceux que vous pouvez chiffrer.

Soyez prudent. J'ai vu des entreprises obtenir l'approbation de projets SAP difficiles en étant d'une honnêteté brutale sur les coûts et prudentes sur les bénéfices. Un client industriel a d'abord présenté un ROI de 30 % pour son projet S/4HANA. Mis au défi, il a révisé le dossier à un chiffre plus réaliste de 18 %. Le DAF a apprécié la franchise et l'a approuvé.

Le plan technique n'a jamais changé. Seule la façon de le raconter a changé.

L'abonnement remplace la licence et le support. RISE et GROW sont des abonnements : la première année coûte donc moins qu'un achat de licence sur site. Le total sur cinq ans dépend des utilisateurs, du périmètre et de la durée. Montrez les années un, trois et cinq côte à côte.

La comptabilité change, pas seulement la trésorerie. Selon les IFRS, un contrat cloud donne souvent accès à un logiciel plutôt qu'à un actif logiciel que vous contrôlez. Dans ce cas, la décision d'agenda de 2021 du Comité d'interprétation des IFRS implique que les coûts de paramétrage et de personnalisation sont généralement passés en charges à mesure que les services sont reçus, et non immobilisés. Cela peut faire passer une grande part du coût du programme du bilan au compte de résultat. Convenez avec vos commissaires aux comptes du traitement de votre contrat RISE ou GROW avant que le dossier financier n'aille au conseil.

Le clean core change le coût à long terme. Les extensions construites sur des interfaces publiées coûtent plus cher à concevoir mais survivent aux mises à niveau. Les modifications sont moins chères aujourd'hui et coûteuses à chaque mise à niveau ensuite. Un modèle sur cinq ans doit montrer cette différence, surtout en Private Edition, où le core peut encore être modifié.

L'IA n'a sa place dans le dossier qu'avec des hypothèses au niveau du workflow. Joule et d'autres fonctions d'IA peuvent faire gagner du temps sur des tâches précises. Rattachez chaque bénéfice d'IA à un workflow nommé, à un nombre d'utilisateurs et à un taux d'adoption que vous pouvez défendre. Les DAF voient chaque semaine des pitchs du type « l'IA va transformer l'entreprise » et les décotent fortement.

Oublier le coût de l'inaction. Si le système actuel cause 500 000 $ de retraitements par an, cela a sa place dans le dossier. Parfois, c'est plus que l'investissement SAP.

Ignorer les perturbations. Le temps de formation, l'indisponibilité pendant la bascule et un premier mois lent après le go-live réduisent tous le retour.

Des risques vagues. « Problèmes de données » n'est pas un risque. « Écart de données de base provoquant des rejets de factures dans les 30 premiers jours » en est un.

Une date de go-live unique, sans détail. Les retards commencent généralement dans les passages de relais : des exigences au paramétrage, des tests à la validation, de la formation à la préparation. Montrez-les.

Ignorer la taille de l'entreprise. Sur un projet où j'ai travaillé, un petit distributeur avait copié le processus de gouvernance d'un grand groupe. Les comités de pilotage hebdomadaires se sont transformés en heures de productivité perdues, jusqu'à ce que le processus soit allégé. En dessous de 200 salariés, 8 à 10 pages suffisent. Les grandes entreprises attendent une modélisation financière complète et une section de gouvernance détaillée.

J'ai travaillé avec une équipe industrielle qui a mis six mois à obtenir l'approbation. Elle a révisé le dossier quatre fois, parce que chaque version répondait à un approbateur différent et ignorait les autres. Écrire pour les trois lecteurs dès le départ aurait fait gagner l'essentiel de ce temps. Une fois le dossier approuvé, le document suivant est la charte de projet.

Que doit contenir un business case SAP ?

Sept sections : un résumé exécutif, la situation actuelle et le coût de l'inaction, l'approche proposée et le modèle de déploiement, un dossier financier sur cinq ans avec ROI et délai de récupération, un plan de mise en œuvre, des risques précis avec leurs responsables, et un modèle de gouvernance. Gardez le détail technique en annexe.

Pourquoi les business cases SAP sont-ils rejetés ?

Généralement parce que les bénéfices sont vagues ou les coûts incomplets, surtout le support récurrent ou les dernières années d'abonnement. Autres causes fréquentes : des risques passés sous silence, ou un document écrit pour un seul public alors qu'il faut convaincre la finance, la DSI et les opérations.

Comment calculer le ROI d'une mise en œuvre SAP ?

Divisez le bénéfice net sur la période, généralement cinq ans, par l'investissement total. Incluez tous les coûts : logiciel ou abonnement, honoraires du partenaire, temps interne, formation, migration des données, support récurrent et hypercare. Utilisez des bénéfices prudents, avec une montée en charge après le go-live. Un ROI réaliste de 18 % se conclut plus vite qu'un 35 % optimiste.

Comment RISE with SAP change-t-il le business case ?

L'abonnement remplace la licence et le support annuel : le dossier doit donc présenter les coûts pour chaque année de la durée. SAP exploite l'infrastructure, ce qui supprime la dépense matérielle. Selon les IFRS, les coûts de paramétrage d'un service cloud sont généralement passés en charges plutôt qu'immobilisés ; convenez donc du traitement comptable avec vos commissaires aux comptes dès le départ.

Quelle longueur doit avoir un business case SAP ?

Un résumé exécutif d'une page, puis environ 15 à 25 pages pour un programme de taille intermédiaire et jusqu'à 40 pour une grande entreprise. Mettez tout ce qui est plus long en annexes. Si le sponsor a besoin d'une heure pour s'y préparer, le document est trop long.

Qu'est-ce que le coût de l'inaction dans un business case SAP ?

Ce que l'entreprise continue de perdre en restant sur le système actuel : contournements manuels, effort de rapprochement, retards de reporting, support de systèmes vieillissants et décisions prises sur des données peu fiables. Si vous êtes sur ECC, incluez le coût de la maintenance étendue après 2027.

Noel D'Costa

Écrit par

Noel D'Costa

25 ans de programmes ERP SAP et Oracle dans l'aérien, le secteur public, la finance, la distribution et l'industrie. Une formation en finance. J'aide les équipes dirigeantes à cadrer leurs transformations avec honnêteté, à redresser les programmes en difficulté et à bâtir des systèmes qui tiennent leur première année en production.

Prochaine étape

Vous menez un programme ERP en ce moment ?

Si cet article fait écho à un programme que vous menez en ce moment, un échange de 30 minutes va généralement plus loin qu'une semaine supplémentaire d'analyse interne.