Dans les services managés SAP, la stack de monitoring n’est pas simplement un coût de delivery. C’est la couche de gestion du risque qui détermine si le contrat sera rentable ou non. Chaque incident P1 qui aurait pu être détecté une heure plus tôt représente trois à six heures de travail d’ingénierie imprévu, souvent mobilisé en urgence. Chaque violation de SLA ouvre une discussion sur les pénalités contractuelles. Et chaque client qui quitte son prestataire après une succession d’incidents représente un coût d’onboarding perdu et la disparition d’un revenu récurrent associé à un contrat qui a parfois nécessité un an de travail commercial.
Les MSP qui considèrent le monitoring comme une ligne de coût à réduire au minimum font une erreur commerciale. La bonne approche consiste à considérer que la qualité du monitoring détermine directement le coût du delivery, et que ce coût détermine directement la marge.
Cet article détaille ce que la stack de monitoring doit couvrir selon les différents modèles de tarification des services managés SAP, les coûts régulièrement sous-estimés et la manière dont les capacités de monitoring peuvent renforcer le pouvoir de tarification d’un MSP.
Comment le modèle de tarification détermine les besoins de monitoring
Les trois principaux modèles de tarification utilisés dans les services managés SAP répartissent différemment le risque entre le MSP et son client. Cette répartition influence directement ce que la stack de monitoring doit couvrir.
Une tarification forfaitaire par SID transfère l’essentiel du risque opérationnel au MSP. Si le système fonctionne mal et nécessite davantage de temps d’ingénierie que prévu, c’est le MSP qui absorbe le coût. Dans ce modèle, la stack de monitoring doit réduire au maximum les interventions non planifiées en détectant les problèmes suffisamment tôt pour permettre une action proactive plutôt que réactive. Chaque heure de travail réactif qui aurait pu être évitée grâce à une alerte proactive représente de la marge perdue.
La tarification en régie, ou time and materials, transfère davantage le risque opérationnel vers le client. Le MSP facture le temps passé, y compris celui consacré à la gestion des incidents. D’un strict point de vue de la marge, les exigences de monitoring sont donc moins fortes puisque le client paie aussi les conséquences d’un monitoring insuffisant.
Mais les clients en T&M finissent généralement par calculer ce que leur coûtent les incidents réactifs. Ils changent alors de prestataire ou restructurent le contrat. Le T&M associé à un mauvais monitoring constitue rarement un modèle commercial durable.
La tarification basée sur les résultats, où le MSP est rémunéré selon le respect des SLA plutôt que selon les activités réalisées, transfère au contraire un maximum de risque vers le prestataire et exige une couverture de monitoring maximale.
Un MSP ne peut pas respecter un SLA qu’il ne sait pas mesurer. Et il ne peut pas défendre ses performances SLA s’il ne dispose pas des données permettant de les documenter. Un contrat basé sur les résultats sans stack de monitoring capable de mesurer les indicateurs pertinents au niveau des processus métier est un futur désaccord contractuel.
Ce que la stack de monitoring doit couvrir pour chaque système SAP managé
La couverture de base nécessaire sur tous les systèmes
Quel que soit le modèle de tarification, chaque système SAP de production managé nécessite une couverture continue sur les mêmes domaines essentiels.
L’utilisation de la mémoire HANA par rapport à l’allocation limit doit être suivie à intervalles courts, avec un historique suffisamment long pour alimenter les discussions de planification de capacité.
L’utilisation des work processes de dialogue doit être monitorée par instance de serveur d’applications, avec des seuils adaptés dans le temps aux profils de charge batch et dialogue propres à l’environnement de chaque client.
Les taux de succès des jobs de fond Tier 1 doivent être suivis avec un monitoring de leur durée par rapport à des baselines établies, et pas uniquement selon un statut succès ou échec.
Les taux d’erreur des interfaces doivent être suivis par type de message, avec une détection des anomalies de volume pour les interfaces où une chute à zéro peut être aussi préoccupante qu’une augmentation brutale des erreurs.
Enfin, l’utilisation du volume de logs HANA doit déclencher une alerte à partir de 70 %, pas uniquement à 85 %.
Ces éléments ne sont pas facultatifs. Un MSP qui exploite des environnements SAP sans couverture continue sur ces cinq domaines travaille avec des angles morts qui finiront par produire un incident que le monitoring aurait dû détecter.
Et lorsque cet incident entraîne une violation de SLA, la question de la qualité de la stack de monitoring devient une question contractuelle, et non plus uniquement opérationnelle.
La couche de reporting que les clients doivent pouvoir consulter
Le reporting SLA est le produit visible par le client issu de la stack de monitoring.
Un MSP qui fournit chaque mois des rapports limités au pourcentage d’uptime présente l’indicateur le plus simple à calculer, mais aussi l’un des moins directement liés aux préoccupations réelles du client.
Un reporting SLA orienté métier montre les taux d’exécution des jobs batch par rapport aux fenêtres convenues, les taux de succès des interfaces, le MTTR par niveau de sévérité ainsi que les tendances permettant de voir si l’état du système s’améliore ou se dégrade au fil du contrat.
Un portail client dans lequel le client peut consulter en temps réel les données de santé de son propre environnement, sans attendre le rapport mensuel, modifie également la relation entre le prestataire et son client. Elle devient davantage une relation de collaboration opérationnelle qu’une simple relation fournisseur-client.
Cela permet aussi d’éviter la discussion mensuelle du type « le système semblait lent la semaine dernière ». Le MSP et le client disposent des mêmes données et peuvent analyser le même événement à partir d’une base factuelle commune.
Cet alignement des données élimine une source importante de friction entre les clients et les MSP.
Ce que les MSP sous-estiment systématiquement dans le coût du monitoring
La licence de la plateforme de monitoring est le coût visible. Les dépenses qui réduisent réellement le ROI du monitoring sont souvent les coûts humains, rarement budgétés de manière explicite.
La maintenance de la qualité des alertes est probablement le coût le plus sous-estimé.
Une configuration de monitoring qui génère 40 alertes par jour, dont 35 faux positifs, ne fait pas gagner du temps aux ingénieurs. Elle génère de l’alert fatigue. Les vraies alertes finissent par être ignorées, ce qui provoque précisément les incidents que le monitoring était censé éviter.
Adapter les seuils d’alerte au comportement spécifique des systèmes de chaque client est une activité continue, et non une tâche réalisée une seule fois lors du déploiement. Quelqu’un doit régulièrement analyser la qualité des alertes et ajuster les seuils à mesure que le paysage SAP du client évolue.
Cet effort est rarement intégré correctement dans le modèle de staffing d’un contrat de services managés.
L’onboarding client est le deuxième coût régulièrement sous-estimé.
Connecter le système SAP d’un nouveau client à la stack de monitoring, établir les baselines, définir les seuils d’alerte adaptés au client et vérifier que toutes les métriques sont correctement collectées demande entre 20 et 40 heures par système dans le cadre d’un onboarding bien structuré.
Pour un MSP qui facture un prix forfaitaire par SID, ce coût d’onboarding est absorbé dès le premier mois du contrat.
Avec 20 heures de travail par SID et un taux ingénieur de 80 € de l’heure, cela représente 1 600 € de coût d’onboarding à récupérer avant même que le contrat devienne rentable.
Pour un contrat qui a nécessité six mois de cycle commercial et qui démarre sur un engagement initial de douze mois, ce coût doit impérativement être intégré à l’économie unitaire du contrat.
Le troisième coût est la maintenance des chemins d’escalade.
Les contacts d’astreinte changent à mesure que les personnes changent de poste, quittent l’entreprise ou rejoignent de nouvelles équipes. Un système de monitoring qui envoie ses alertes à des personnes qui ne sont plus responsables du sujet, ou à des numéros de téléphone réattribués, est un système qui échouera à 3 h du matin précisément le jour où il devra fonctionner.
Quelqu’un doit donc vérifier régulièrement les chemins d’escalade, idéalement chaque trimestre.
Cela représente environ une heure par client et par trimestre. Pour 20 clients, on atteint 80 heures de travail administratif par an qui apparaissent rarement dans le budget de delivery.
| Attention : les MSP qui choisissent une nouvelle plateforme de monitoring en raison d’un coût de licence inférieur sous-estiment parfois l’ensemble des coûts liés au changement. Les configurations d’alertes, les baselines propres à chaque client, les modèles de reporting et les intégrations ITSM dépendent tous de la plateforme. Changer de solution pour un portefeuille de 30 clients signifie reconstruire simultanément tous ces éléments pour chacun d’entre eux. L’économie sur les licences doit être comparée au coût total de migration, et pas uniquement à la différence de prix entre les plateformes. |
|---|
Les capacités de monitoring comme différenciateur tarifaire
Deux MSP peuvent proposer des services managés SAP à des tarifs similaires tout en disposant de capacités de monitoring très différentes.
La différence apparaît dans le delivery.
Le premier appelle le client pour lui expliquer qu’une anomalie a été détectée et corrigée avant d’avoir un impact.
Le second l’appelle pour lui annoncer qu’un incident P1 s’est produit pendant la nuit.
La question commerciale est de savoir si les clients sont prêts à payer davantage pour bénéficier d’un service réellement proactif.
La réponse est oui, mais pas pour une capacité abstraite. Ils paient pour des preuves concrètes.
Un MSP qui présente lors de ses quarterly business reviews des incidents détectés avant qu’ils n’affectent les utilisateurs, des alertes de capacité remontées avant l’apparition d’une contrainte ou des rapports de monitoring des changements capables de répondre aux exigences d’audit démontre la valeur de son monitoring proactif dans des termes que le client peut directement relier à son expérience opérationnelle.
Un MSP incapable de produire ces preuves parce que sa stack de monitoring ne collecte pas ces données se retrouve à rivaliser principalement sur le prix.
La concurrence par les prix dans les services managés SAP mène rapidement vers un niveau de marge que peu de MSP peuvent maintenir tout en garantissant une qualité de service élevée.
La stack de monitoring est précisément ce qui permet à un MSP de vendre ses capacités plutôt que simplement son prix.
Certaines capacités de monitoring renforcent particulièrement les discussions autour d’une offre premium : le monitoring de l’exécution des processus métier, qui mesure les SLA réellement importants pour le business et pas uniquement l’infrastructure ; la planification proactive de capacité accompagnée de recommandations documentées ; le monitoring de la dérive de configuration avec des rapports de changements prêts pour l’audit ; et les dashboards clients qui donnent aux entreprises une visibilité directe sur leur propre environnement.
Chacune de ces capacités permet au MSP de justifier la différence de tarif avec un prestataire dont le monitoring commence et s’arrête à l’uptime des serveurs.
Le coût caché d’un monitoring insuffisant
Le business case d’un investissement dans le monitoring devient particulièrement évident lorsque l’on calcule le coût de son absence.
Un incident P1 sur un système SAP de production qui se produit en dehors des heures ouvrées, mobilise trois ingénieurs, nécessite quatre heures de résolution et entraîne une discussion sur les pénalités SLA peut facilement coûter entre 3 000 € et 6 000 € au MSP rien qu’en coûts directs d’ingénierie.
Il faut ensuite ajouter le coût relationnel de la discussion avec le client et, si le contrat le prévoit, la pénalité liée au SLA.
Si le même incident avait pu être détecté deux heures plus tôt et résolu avant de nécessiter une escalade, son coût aurait pu se rapprocher de 400 € dans le cadre d’une réponse proactive déclenchée par le monitoring.
Le calcul du seuil de rentabilité d’un investissement dans une plateforme de monitoring est donc relativement simple.
Combien d’incidents P1 évités chaque année suffisent à couvrir le coût de la plateforme ?
Pour la plupart des MSP qui gèrent au moins dix systèmes SAP de production, ce nombre est inférieur au volume d’incidents qu’ils rencontrent actuellement sur une année.
L’investissement dans le monitoring n’est donc pas un simple centre de coûts. C’est un programme de réduction du coût des incidents qui contribue également à limiter le churn client, l’un des événements les plus coûteux dans un modèle de services managés.
La perte d’un client à la suite d’une succession d’incidents évitables entraîne des coûts qui apparaissent rarement dans l’analyse initiale : le coût commercial nécessaire pour remplacer le client, qui peut représenter entre six et douze mois de revenus du contrat ; la perte d’une référence lorsque le client explique son expérience à d’autres prospects ; et la perturbation interne provoquée par le départ d’un client important du portefeuille.
Un MSP qui perd chaque année un grand client SAP Managed Services à cause de la qualité de sa gestion des incidents supporte un coût caché largement supérieur à l’investissement dans une plateforme de monitoring qui aurait pu contribuer à éviter cette situation.
La stack de monitoring doit donc être intégrée au modèle tarifaire avant même la signature du premier contrat client, et non ajoutée lorsque la marge commence à se dégrader.
Le coût de la plateforme, l’effort d’onboarding par système, la maintenance de la qualité des alertes et le travail de reporting sont tous des coûts prévisibles.
Une tarification qui les intègre produit des contrats qui restent rentables.
Une tarification qui les ignore produit des contrats dont la marge se dégrade progressivement à mesure que les coûts non anticipés s’accumulent.
Les MSP qui se développent durablement dans les services managés SAP sont ceux qui considèrent leurs capacités de monitoring comme un produit, et non comme un simple coût d’infrastructure en arrière-plan.
Leur tarification reflète le coût réel d’un delivery proactif. Leur reporting montre aux clients ce que cet investissement produit. Et leur marge ne disparaît pas à chaque incident que le monitoring aurait dû détecter.
Redpeaks est conçu pour les déploiements MSP à grande échelle : tarification par SID, dashboards multi-clients, portails clients et intégrations ITSM permettant de router les alertes avec tout le contexte SAP nécessaire. L’onboarding d’un nouveau système client se fait en quelques heures plutôt qu’en plusieurs semaines.
