Corporate Finance, DeFi, Blockchain, Web3 News
Corporate Finance, DeFi, Blockchain News

Calcul du ROI d'une SOA et d'un BPMS . La stratégie comme point de départ

L’époque où le service d'encadrement ICT pouvait réussir à imposer toutes les décisions relatives aux investissements ICT avec une responsabilité minimale est définitivement révolue. Actuellement, chaque investissement est analysé en détail par un comité de direction ou par une commission d'experts au niveau de la valeur ajoutée visée par l'investissement.


Le retour sur investissement du développement et de l'implémentation d'une application s'avère encore un calcul relativement simple. Dans ce calcul, les réponses aux questions suivantes sont, entre autres, apportées : quels objectifs d'efficacité en matière de coûts peuvent être atteints avec l'application ; dans quelle mesure cette application contribue-t-elle à la réalisation d'un nouveau service de l'organisation ; de quelle manière cette application contribue-t-elle à la qualité de nos services ? Il devient beaucoup plus compliqué d'effectuer un tel calcul lors de l'implémentation d'une Architecture orientée services (SOA) et d'un Business Process Management System (BPMS). La valeur ajoutée d'une plateforme technologique est considérablement moins tangible que la contribution d'une application spécifique. Une plateforme technologique ne fournira un ROI que dans le futur, lorsque davantage d'applications auront été développées sur cette plateforme. Il s'agit également de la raison pour laquelle, à l'heure actuelle, les organisations temporisent les investissements dans une SOA ou un BPMS. Du fait que, d'une part, les décideurs politiques ne comprennent pas, ou alors seulement partiellement, les objectifs de cet investissement dans cette nouvelle technologie et du fait que, d'autre part, les responsables du service d'encadrement (les CIO, les architectes d'entreprise, etc.) s'abstiennent de reproduire la valeur commerciale d'un tel investissement dans une analyse transparente et soutenue de manière quantitative, la décision est continuellement repoussée.

Qu'est-ce qu'une SOA et un BPMS
Avant de clarifier le ROI d'une SOA et d'un BPMS, il convient de préciser la définition d'une SOA et d'un BMPS. Une SOA est une approche basée sur des normes pour gérer les services mis à disposition depuis différents progiciels pour la réutilisation et la reconfiguration.
Un BPMS est une solution logicielle qui a été conçue pour permettre aux business users d'implémenter rapidement et efficacement des applications basées sur des processus, par le biais d'un environnement de modelage des processus convivial. Ces business users font, à cet effet, appel aux composants de logiciels d'entreprise et aux fonctions réutilisables qui ont été créées par le département IT.

SOA et BPMS sont souvent cités conjointement. Il existe cependant une distinction claire entre BPMS et SOA. Un BPMS ne peut apporter une valeur ajoutée que s'il a également accès à la couche d'intégration. Une SOA est alors le lien entre la couche d'intégration et la couche de gestion des processus. Une architecture BPMS utilise donc une architecture orientée sur le service afin d'avoir accès aux différentes applications sous-jacentes via une SOA. Vous découvrirez une reproduction schématique à l'illustration 1.

BPMS/SOA, un choix stratégique ?
Deux parties prenantes directes tirent essentiellement profit d'un investissement SOA/BPMS. Il s'agit, d'une part, du département ICT et, d'autre part, du core business d'une organisation. Un grand nombre de ces objectifs dans un investissement SOA/BPMS ne peuvent être exprimés ou convertis en un retour immédiat en euros. Par exemple : comment est-il possible de quantifier l'avantage commercial en euros si une application peut être mise plus rapidement sur le marché ? Ou si une organisation peut adapter ses applications plus rapidement à la demande du marché ? Ou du fait qu'il est possible de procurer au client, plus rapidement et plus précisément, des informations relatives à l'implémentation d'une technologie SOA/BPMS.
Une réponse à ces questions ne se retrouvera donc pas dans une analyse de l'architecture en soi mais dans une analyse de là où l'architecture soutient les processus opérationnels. Il est, par conséquent, nécessaire de faire un pas en arrière et de prendre comme point de départ la stratégie d'une organisation. Ce sont les processus opérationnels qui permettent à une organisation de réaliser sa stratégie. L’ICT a un impact important sur le fonctionnement des processus dans une organisation.

L’ICT influencera, dans une large mesure, les conditions auxquelles doit satisfaire un processus. Les conditions auxquelles doit satisfaire un processus sont :
- L'efficience, dans quelle mesure est-il possible de limiter les ressources à un minimum ;
- L'efficacité, l'utilité du processus ;
- Le temps écoulé, le temps entre le début et la fin du processus ;
- La qualité, éviter d'effectuer le travail à deux reprises ;
- La flexibilité, l'adaptabilité aux circonstances changeantes.

Il importe donc de définir une série équilibrée d'indicateurs au niveau du processus, qui indique dans quelle mesure ces conditions sont remplies. Il est, par conséquent, possible de déterminer dans quelle mesure ces conditions contribuent à la réalisation de la stratégie de l'organisation.

Pour une telle approche, il faut éviter d'analyser un processus de manière autonome. Le processus doit être analysé dans son interaction avec les autres processus au sein et à l'extérieur de l'organisation. Mais il est encore nécessaire d'aller plus loin. Il faut analyser l'ensemble des processus opérationnels stratégiques. Dans le cas contraire, le risque est encouru de tomber dans une solution îlot. Cette « approche îlot » constitue également une des raisons importantes pour lesquelles de nombreuses organisations sont actuellement confrontées à un enchevêtrement extrêmement complexe d'applications, de normes et de plateformes. Les décisions pour une application étaient alors prises au niveau de la fonction ou du département, plutôt qu'au niveau d'un 'processus'.

Une SOA constitue le lien entre la couche d'intégration et la couche de gestion des processus
La maturité de la technologie et des normes était autrefois insuffisante pour permettre une optimalisation au niveau du 'processus'. Il s'agit également de la raison pour laquelle l'environnement ICT, pour de nombreuses organisations, représente aujourd'hui un facteur qui bloque l'adaptation des processus opérationnels aux conditions changeantes du marché. Une décision d'implémenter ou non une SOA/un BPMS ne peut donc pas être prise au niveau d'un département. Il s'agit, en effet, d'une décision au niveau de l'ensemble de l'organisation, nécessitant un sponsoring de la direction. Pour une étude stratégique de cette nature, il ne suffit pas d'examiner la situation à court terme, il faut également effectuer une analyse à long terme. À long terme, l’ICT peut s'avérer un désactivateur au lieu d'un activateur pour exécuter de nouveaux processus ou leur apporter des modifications. Ces besoins doivent servir de point de départ pour réaliser des choix ICT ciblés et non l'esprit progressiste d'une architecture SOA/BPMS.

La plateforme par excellence pour un calcul ROI correct
Sans raison pertinente, une organisation n'apporte aucune modification à sa plateforme technologique. Dans le passé, un grand nombre de ces modifications ont cependant été effectuées pour des raisons purement liées à la technique de la plateforme, sans qu'une valeur ajoutée ne soit créée pour les affaires. Pensons, par exemple, à Y2K, à l'introduction de l'euro, aux extensions obligatoires et aux modifications de la plateforme parce qu'une sortie n'est plus soutenue par un fournisseur, etc. Un passage vers BPMS/SOA ne présente certainement pas uniquement une raison technique mais surtout une raison commerciale.

Sur base d'une enquête concernant la SOA (AMR research report 2005), les objectifs opérationnels suivants pour le département ICT sont énumérés par les sondés :
- une reconfiguration plus rapide et plus flexible des processus d'affaire (48 pour cent) ;
- la réduction des frais opérationnels d'ICT (28 pour cent) ;
- des niveaux de service sûrs et fiables (15 pour cent) ;
- une implémentation « on the fly » des extensions du produit (5 pour cent) ;
- un système prêt à l'emploi de différents fournisseurs de technologie (3 pour cent).

Les raisons techniques, telles que celles indiquées dans le rapport AMR, se calculent encore assez directement. La plateforme SOA/BPMS mènera, en raison de la réutilisation des composants de service, à une réduction de la complexité de l'intégration de la plateforme, à une baisse des frais d'entretien, etc. Dans de nombreux cas, nous pouvons ici retomber sur des données de référence, combinées à la situation spécifique au département ICT afin d'évaluer le ROI.

La motivation commerciale
Les CEO, les CFO et les chefs d'entreprise d'une activité ne seront convaincus d'un investissement dans un système SOA/BPMS que si celui-ci crée également une valeur substantielle pour l'activité. Leur intérêt et leur motivation pour exécuter une telle modification de la plateforme dépendra donc, en grande partie, de la mesure dans laquelle cette plateforme contribuera à l'optimalisation des processus opérationnels principaux.
Si l'impact ROI de la modification d'un processus ou de la reconfiguration d'un processus est déterminé, les étapes suivantes doivent être parcourues.

Une première étape consiste à faire un tour d'horizon des processus. Cette procédure ne peut pas se limiter à une description des activités d'un processus à l'aide d'un flowchart. Ce flowchart doit être complété par des éléments quantitatifs d'un processus. Des exemples d'éléments quantitatifs de cette nature sont : le nombre d’ETP attribués au processus ; les objectifs au niveau du service attendus de la part du processus ; le temps écoulé du processus ; le temps du processus ; le nombre de triggers du processus.

Il ne faut toutefois pas se limiter à un calcul statistique du processus. Par exemple, la durée moyenne d'exécution d'une tâche d'un processus constitue une base erronée pour déterminer le nombre d’ETP nécessaires afin d'exécuter cette étape du processus. Si une mesure est effectuée sur le terrain, un écart sera remarqué concernant l'exécution de cette tâche. Si l'opération se déroule bien, elle peut être achevée en deux heures. Si l'opération ne se déroule pas correctement, elle peut parfois durer dix heures. Les catalyseurs qui démarrent un processus peuvent varier très fortement. Cette variation augmentera encore s'il s'agit d'un processus customer facing. Un exemple simple est le nombre d'appels d'un centre de contact un lundi matin par rapport au jeudi midi, par opposition à un samedi après-midi.

L'analyse quantitative des processus nécessite donc plus qu'une simple addition des temps moyens des processus. Cette addition simple procure une image très déformée des besoins d'une organisation. Dans le monde réel, les paramètres d'entrée sont stochastiques de nature. Cela signifie que l'aspect des missions professionnelles, des temps d'exécution, etc., présente un déroulement changeant dans le temps, qui dévie fortement d'une répartition uniforme. Les modèles ROI qui comptent cette dynamique des processus sont basés sur une technique de simulation. La construction d'un modèle de simulation représente d'ailleurs une deuxième étape dans le calcul ROI d'un modèle SOA/BPMS.

Modèle de simulation
Ce modèle de simulation reproduit le fonctionnement du processus et est parfaitement à même de percevoir les insuffisances des méthodes statistiques. Contrairement à un calcul statique, un calcul dynamique, à l'aide d'un modèle de simulation, tiendra compte d'un certain nombre de données complémentaires qui augmenteront le réalisme des besoins du personnel, des effectifs en personnel, des temps écoulés. En outre, le modèle de simulation nous permettra de cartographier les risques de l'investissement. Un modèle de simulation de cette nature permet d'exécuter une analyse des risques exacte en faisant varier les paramètres de simulation, afin de déterminer les limites du modèle de processus redessiné. Le modèle de simulation offrira une réponse à toute une série de décisions stratégiques importantes pour l'évaluation d'un nouveau processus :
- où apparaissent les premiers goulets d'étranglement ;
- quelle équipe de collaborateurs dépassera un taux d'occupation de 85 % ;
- pour quels services, en combinaison avec un groupe de clients spécifique, l'objectif au niveau du service ne pourra pas être atteint ;
- l'économie présupposée en ETP pourra-t-elle être obtenue, étant donné cette distribution dans le volume du dossier et pour un niveau de service inchangé ?

De cette manière, le ROI de l'amélioration des processus peut être soutenu quantitativement au moyen d'une implémentation SOA/BPMS. À l'aide du modèle de simulation, ces résultats peuvent également être visualisés. La simulation permet d'analyser et de gérer des interactions qui sont inhérentes à des environnements complexes et dynamiques. Les modèles de simulation ne se concentrent cependant pas sur des éléments spécifiques définis mais ils tiennent compte de l'ensemble de l'organisation, aussi bien le personnel, les processus que les systèmes et ils offrent un aperçu global du service et de la prestation d'une entreprise. Ce point est d'une importance cruciale lors d'un calcul ROI pour un système SOA/BPMS.

Le processus doit être analysé en interaction avec d'autres processus à l'intérieur et à l'extérieur de l'organisation
Outre l'impact direct d'une implémentation SOA-BPMS sur le soutien des processus, il existe encore une série complémentaire d'avantages stratégiques qui se moulent moins facilement dans le 'carcan' d'un calcul ROI mais qui présentent une importance élevée sur le plan stratégique pour une organisation. Pensons, à cet effet, à la possibilité de réagir plus rapidement aux demandes futures du marché, à l'adaptation des règles commerciales dans une application par les business users, à l'échange plus rapide d'informations avec les autres parties prenantes. Si cette analyse ROI fournit des résultats positifs, les avantages stratégiques, tels que la correction simple des processus opérationnels, l'adaptation simple des règles commerciales par les business users, ne pourront que continuer à faire pencher la balance ROI en faveur d'une implémentation SOA-BPMS.

Calcul du ROI d'une SOA et d'un BPMS . La stratégie comme point de départ

Conclusions
Le calcul ROI d'une implémentation SOA/BPMS ne peut pas se limiter au gain d'efficience du département ICT. La contribution la plus importante de la plateforme SOA/BPMS sera située dans le soutien des processus pour l'ensemble de l'organisation. Cela signifie que tous les processus principaux sont influencés par une telle plateforme. Le ROI est, par conséquent, influencé en grande partie par la proposition de la valeur commerciale qui peut être réalisée à l'aide de la nouvelle plateforme. La modélisation des processus et la technique de simulation permettent d'analyser les processus de manière dynamique afin de réaliser une prévision fiable du ROI de l'implémentation SOA/BPMS.

Par Jan Bellaert, partenaire MÖBIUS
www.mobius.eu

Retrouvez un jeudi tous les quinze jours l'actualité du BPM sur :
www.bpm-channel.com

Jeudi 18 Mars 2010




OFFRES D'EMPLOI


OFFRES DE STAGES


NOMINATIONS


DERNIERES ACTUALITES


POPULAIRES