.svg)
Le risque lié à la livraison des projets d'intégration pour les services professionnels
L'intégration est un livrable de conseil inhabituel en ce qu'elle touche des systèmes que l'entreprise n'a pas construits, dépend d'API que l'entreprise ne contrôle pas, et doit continuer à fonctionner longtemps après la clôture du projet. La plupart des autres travaux de services professionnels sont délimités : un document de stratégie, un site web, une campagne marketing. L'intégration est, par conception, illimitée. Une fois livrée, elle fonctionne ou échoue selon que les systèmes externes se comportent comme prévu et que quelqu'un surveille lorsqu'ils ne le font pas.
Cela crée des schémas de risque qui se manifestent de manière constante dans toutes les entreprises. Les estimations de périmètre sont erronées car la structure de données « simple » du client s'avère contenir des exceptions non documentées. Les délais sont dépassés car un connecteur entre deux systèmes doit être développé sur mesure lorsqu'un changement de fournisseur rend une approche existante inapplicable. Des problèmes de stabilité apparaissent en production car personne n'a testé les modes de défaillance. Et six mois après le transfert, une mise à jour d'API rompt l'intégration silencieusement, et le client le signale comme une défaillance de service plutôt que comme un changement côté fournisseur.
Où la livraison d'intégrations tourne généralement mal
Les risques de livraison les plus courants ne sont pas exotiques. Ils sont prévisibles et largement architecturaux. Le risque d'estimation provient de la sous-estimation de la complexité des données réelles du client, et non des systèmes connectés. Le risque de développement provient du code personnalisé qui dépend d'hypothèses que seul le développeur d'origine comprend pleinement. Le risque de transfert provient de la livraison d'intégrations fonctionnelles que l'équipe cliente ne peut pas maintenir ou modifier en toute sécurité. Le risque post-lancement provient de changements que l'entreprise n'a pas causés mais dont elle est tenue responsable de la correction.
Chacun de ces risques a la même cause profonde : trop d'inconnues maintenues ensemble par du code qui existe en dehors d'un système gouverné. La solution n'est pas une meilleure gestion de projet. C'est un modèle de livraison où les inconnues sont réduites par l'architecture elle-même.
Comment une iPaaS centralisée réduit le risque d'estimation et de développement
Lorsque les intégrations sont construites sur une plateforme avec des connecteurs pré-testés et des modèles de transformation réutilisables, les inconnues lors de l'estimation diminuent considérablement. L'équipe n'est pas en train d'estimer « combien de temps faudra-t-il pour construire une connexion entre Shopify et SAP » à partir de zéro. Elle estime plutôt : « Combien de temps faudra-t-il pour configurer le modèle standard Shopify-SAP pour les mappages de champs et les cas limites spécifiques de ce client ? » La couche de base est connue, testée et comprise par toute l'équipe.
Le risque de développement diminue également car la plateforme gère les catégories de travail les plus susceptibles d'introduire des défauts : authentification, logique de réessai, gestion des erreurs et traduction de format. L'effort de l'équipe se concentre sur la logique métier spécifique au client plutôt que sur la reconstruction de l'infrastructure. Les cas limites sont gérés dans une couche de transformation contenue, souvent via des outils comme le Code Transformer d'Alumio pour les cas que la configuration visuelle ne peut pas couvrir, sans polluer le modèle standard.
Comment une plateforme gouvernée réduit le risque de transfert et post-lancement
Le risque qui nuit le plus aux entreprises sur le plan commercial est celui post-lancement. Un lancement réussi suivi de mois de support non facturable grignote toutes les marges intégrées au projet. Les principaux facteurs sont la dépendance aux connaissances et la visibilité.
Les intégrations personnalisées créent une dépendance aux connaissances : l'intégration n'est entièrement comprise que par le développeur qui l'a construite. Si cette personne quitte l'entreprise, celle-ci assume le risque. Une plateforme d'intégration gouvernée distribue les connaissances au sein de l'équipe car la configuration est visuelle, documentée et inspectable depuis la même interface accessible à tous.
La visibilité provient de la surveillance centralisée. Lorsqu'une intégration échoue sur une construction personnalisée, l'entreprise l'apprend généralement du client. Lorsqu'elle échoue au sein d'une plateforme gouvernée, l'entreprise voit l'alerte avant le client. Cette seule différence, être informé avant le client, est souvent ce qui distingue les contrats de services gérés qui conservent leur marge de ceux qui perdent discrètement de l'argent.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
