jump to navigation

Une organisation pour un SI intégré septembre 11, 2006

Posted by vincent poncet in Architecture, Organisation.
trackback

Tout projet applicatif comporte une phase d’intégration avec les applications existantes pour récupérer leurs données ou bien pour prolonger un processus métier déjà implémenté dans un système. Cette phase est souvent la plus difficile à réaliser car elle est au centre des intérêts nécessairement divergents des différents responsables applicatifs et métiers. Pour cela, il est aisé de dire que l’intégration de système d’information est la source de coût la plus importante dans le budget d’une DSI. L’objet de cet article est d’expliquer les causes profondes de la complexité de l’intégration de système d’information. Arrivant à la conclusion que la source du problème est de nature organisationnelle, il sera proposé une organisation de la DSI qui permette un SI structurellement intégré.

Nature de l’application

Pour appréhender la problématique d’intégration d’application, il faut revenir à la nature de l’application.

Les applications sont conçues pour aider le business à réaliser ses objectifs. Lorsque les utilisateurs métiers définissent leurs besoins, ils le font naturellement par rapport à la manière dont ils conceptualisent leur environnement de travail. Ils connaissent les acteurs avec lesquels ils interagissent ainsi que les objets qu’ils manipulent. De même, ils connaissent les procédures qu’ils accomplissent pour manipuler ces objets et interagir avec ces acteurs. Les utilisateurs métiers attendent donc d’une application qu’elle automatise une partie de la gestion de leurs activités afin de gagner en productivité. Pour cela, les objets et les procédures définis par les utilisateurs métiers seront implémentés dans le modèle objet et dans le modèle de données de l’application.

Une application est un système de traitement de l’information réalisant des processus métiers en manipulant des objets métiers, pour une classe spécifique d’utilisateurs métiers. En cela, elle incorpore une ontologie qui est un sous-ensemble de l’ontologie de l’entreprise.

Ces objets et ces processus sont implémentés de manière spécifique dans une application en fonction de la vision qu’en ont ses commanditaires. Ces objets et ces processus sont, par ailleurs, aussi implémentés dans d’autres applications composant le système d’information de l’entreprise. Par exemple, les utilisateurs métier chargés des ventes manipuleront les objets « Client », « Produit » et « Commande ». De leur côté, les utilisateurs métier chargés de la production utiliseront aussi les objets « Produit » et « Commande ». Avec le processus actuel de conception d’application, chaque équipe de projet de conception de ces deux applications vont implémenter de manières différentes les objets « Produit » et « Commande ». Pourtant, du point de vue de l’entreprise prise dans sa globalité, l’acte de production suit l’acte de vente. Ces deux branches métier manipulent donc les mêmes objets dans le but de réaliser successivement leurs activités.

Du point de vue du SI global, une application est donc une implémentation de sous-objets métiers et de sous-processus métier. Avec le temps, il y aura différentes représentations dans le système d’information des processus et des objets métier. L’intégration d’applications consiste donc à reconstruire les objets globaux à l’entreprise à partir des sous-objets et reconstruire les processus globaux à partir des sous-processus enfouis dans les applications.

Les problèmes organisationnels de l’intégration d’applications

La tâche de l’intégration d’applications est de connecter toutes les ontologies restreintes embarquées dans les applications qui peuplent le SI pour construire l’ontologie globale du point de vue de l’entreprise. Cette tâche est très difficile car elle demande l’intervention d’une multitude d’acteurs qui ont chacun des objectifs individuels qui ne vont pas dans le sens d’une meilleure intégration entre les applications. En effet, l’intérêt d’un responsable d’application est avant tout de répondre aux besoins des commanditaires de son application, car ils sont ses véritables patrons.

Dans la plupart des entreprises, la branche métier commanditaire est, de fait, propriétaire de l’application qu’elle a commandé à la DSI. La DSI n’agit, en fait, que comme un prestataire de réalisation et de gestion de services informatiques. Pour chaque demande de besoins informatiques, la DSI va constituer une équipe projet dont le but sera de réaliser une application. Cette application sera directement financée par la branche métier commanditaire. Ensuite, lors du passage à la phase de production, la DSI va transmettre l’application à des équipes de production informatique dédiées, et de la même manière, le coût de la production informatique de cette application sera directement payé par la branche métier commanditaire. Souvent même, la branche métier commanditaire paye directement l’achat des ressources hardware nécessaires au bon fonctionnement de son application. Les coûts de chaque application étant imputés sur des budgets de branches métiers, il parait donc évident que la DSI n’est pas propriétaire de ses applications, mais elle n’en est que le gérant pour le compte des branches métiers.

Ainsi, il n’est pas possible pour la DSI de prendre l’initiative de mutualiser ses ressources pour gagner en efficacité. Comme nous l’avons vu dans le chapitre précédent, la problématique de l’intégration n’est due qu’au fait que chaque application reconstruit une vision des objets et des processus métiers spécifiques aux besoins des commanditaires. Comment la DSI peut-elle construire l’informatisation des objets et processus globaux de l’entreprise au fur et à mesure des demandes informatiques, si elle n’agit que comme prestataire gérant des applications, c’est à dire des implémentations spécifiques de ces objets et processus métiers ?

Un SI intégré

Nous voyons que la source du problème d’intégration, facteur du coût essentiel du budget d’une DSI, vient du fait de la conception d’un SI comme un composé d’applications. Cette approche conduit nécessairement à l’éclatement des objets métiers et des processus métiers.

Pour avoir un système d’information intégré, il faut arrêter de construire des applications qui sont spécifiques à une petite classe d’utilisateurs. À la place, il faut construire un et un seul système d’information d’entreprise qui soit aligné avec les concepts premiers de l’entreprise considérée dans son entier.

Toute action humaine peut être considérée comme la transformation de choses pour former de nouvelles choses. Une entreprise est une organisation humaine, donc de la même manière, elle prend en entrée des « choses » ou des « services », elle les combine, les transforme afin de réaliser de nouvelles « choses » ou de nouveaux « services ». Ainsi, les concepts premiers de l’entreprise sont ces « choses » ou ces « services » et la manière dont elle les utilise pour réaliser d’autres « choses » ou d’autres « services ». Ces « choses » ou « services » sont appelés les « objets métier », et la manière dont l’entreprise les utilise est appelée « processus métiers ». Vue comme une boite noire, l’entreprise interagit avec les acteurs du monde extérieur selon un protocole défini dans les contrats qui la lie avec ces derniers. Vue comme une boite blanche, les concepts d’ « objet métier » et de « processus métier » sont donc les concepts premiers de l’organisation interne de l’entreprise.

Pour ne plus avoir à subir tous les problèmes d’intégration des ontologies auxquels nous avons à faire fasse, il faut donc construire nos systèmes d’information du point de vue de l’entreprise considérée dans son entier, c’est à dire en concevant les processus et les objets métiers de manière globale depuis la phase de conception et tout au long de l’évolution des besoins des utilisateurs métiers. Les processus internes à l’entreprise interagissent avec les acteurs extérieurs via l’échange de messages de nature contractuelle (commande, bon de livraison, paiement, etc…). Une plateforme d’échanges servira d’adaptateur entre les formats techniques et fonctionnels de ces messages et la représentation normalisée qu’ils ont dans le SI. Elle sera mutualisée pour tous les échanges avec l’extérieur avec un module par standard d’échange (EDI, Swift, ebXML, propriétaire, etc…).

Il existe un précédent notable d’architecture similaire à celle proposée ici. Les ERPs doivent leur succès comme système d’information intégré au fait qu’ils ont été conçus de manière intégré. Ils sont, en effet, composés d’un référentiel unique d’objets métier et les processus y sont implémentés de manière globale. Bien sûr, les ERPs ont aussi des défauts, notamment leur coût d’implémentation à la spécificité de chaque entreprise, ainsi que la rigidité que cela induit dans le SI. Mais cet exemple nous prouve qu’il est possible de concevoir un SI de manière intégrée. La démarche proposée ici vise donc à construire un système intégré à l’image des ERPs, mais dans l’entreprise utilisatrice et donc directement à partir des besoins spécifiques de l’entreprise.

Un SI intégré est donc l’implémentation d’objets et de processus métier globaux à l’entreprise. Les utilisateurs métier interagissent avec des processus continuellement adaptés à l’évolution de leurs besoins. Les processus manipulent des objets implémentés comme des référentiels uniques. Il faut bien distinguer les processus et les objets, car un même objet est souvent manipulé par plusieurs processus, comme par exemple, les objets « Commande » et « Produits » dans le schéma ci-dessous.

Une organisation pour un SI intégré

Pour atteindre cet objectif d’intégration du SI, les DSIs doivent rompre avec le modèle actuel d’organisation par équipe applicative.

Pour cela, il faut refonder les relations qui unissent les directions métier et la DSI. Les DSIs doivent être libres de l’implémentation informatique des processus et des objets métier de l’entreprise. Dans l’histoire de l’organisation d’entreprise, les gérants des directions métier ont pu devenir relativement libres de gérer les obligations contractuelles dont ils avaient la charge en devenant propriétaire de ces contrats. La direction commerciale est ainsi responsable et donc propriétaire des contrats qu’elle négocie avec les clients, la direction des achats est responsable des contrats avec les fournisseurs, la direction financière est responsable des engagements vis-à-vis des actionnaires, et ainsi de suite. De même, la DSI doit passer d’un statut de gérant des applications métier à un statut de propriétaire d’infrastructure informatique qui rend des services visant à soutenir les processus métier de l’entreprise.

Cette infrastructure informatique cible est composée de l’implémentation informatique de processus métiers et d’objets métiers dont la DSI devient complètement propriétaire. Elle fournit donc un service opérationnel d’informatisation des processus métier gérés par les pilotes de processus côté métier.

Comme chacun des objets et les processus sont liés par des relations contractuelles différentes ayant chacune des exigences de niveau de service, il est nécessaire que chacun de ces processus et de ces objets soient sous la responsabilité d’une personne unique appartenant à la DSI.

Nous aurons donc un manager IT par processus métier IT, ainsi qu’un manager IT par objet métier. Le manager de processus métier IT est l’interface entre le métier et la DSI. Il est responsable de l’implémentation IT d’un processus métier. Son interface côté métier est le pilote de processus. Comme nous l’avons défini précédemment, un processus est une manipulation d’objets métier. Le manager de processus métier IT sera donc en relation avec les managers IT d’objets métier entrant dans le fonctionnement du processus dont il a la charge. De son côté, le manager d’objet métier répondant à tous besoins des processus utilisant son objet est à même de définir son objet de tel manière qu’il satisfasse à chacun des processus IT de l’entreprise. En cela, il peut construire un objet métier englobant toutes les vues parcellaires qu’en ont les différents managers de processus métier côté métier. Les processus étant en interaction avec des acteurs externes, les responsables des modules d’intégration avec l’extérieur de l’entreprise seront en relation avec les managers de processus métier IT qui utiliseront les formats dont ils auront la responsabilité.

De cette manière, nous passons d’une organisation centrée sur les applications à une organisation centrée sur les processus de l’entreprise.

Conclusion

Comme nous l’avons vu, le cœur du problème d’intégration trouve sa source dans la nature même des applications qui ne sont que des implémentations spécifiques des processus et des objets métier. Chacune des applications composant le SI étant définie de manière autonome, c’est pourquoi l’intégration des ontologies embarquées dans ces applications sont si difficiles. De plus, aux difficultés techniques et conceptuelles, s’ajoute la difficulté organisationnelle. En effet, chaque application est sous la responsabilité d’un manager de la DSI qui lui-même n’est qu’un gérant d’une application qui appartient dans les faits au commanditaire métier. Il n’a pas d’intérêts à répondre aux besoins des autres commanditaires d’applications demandeuses de « ses » données. Une DSI qui n’est que gérante et non propriétaire de son infrastructure ne peut pas organiser le SI de manière intégré. C’est pourquoi nous avons proposé dans cet article de transformer la DSI d’une organisation gérante d’applications, à une organisation propriétaire de l’implémentation informatique des objets et des processus métier. De cette manière, en changeant la nature des relations entre la DSI et les branches métier, la DSI pourra concevoir et maintenir un SI intégré duquel la problématique d’intégration aura, de fait, disparu.

 

Un prochain article proposera un modèle de transformation pour passer de l’organisation actuelle des DSIs à celle proposée ici.

About these ads

Commentaires»

1. Johnf457 - juin 26, 2014

Nice post. I study one thing more difficult on completely different blogs everyday. cabgdfbcfdfk


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

Suivre

Recevez les nouvelles publications par mail.

%d blogueurs aiment cette page :