Quelques commentaires sur d’autres blogs janvier 10, 2008
Posted by vincent poncet in Architecture.1 comment so far
Voici quelques commentaires que j’ai pu écrire sur d’autre blog sur ce sujet qui me tient à coeur.
ITRedux.com, le blog d’Ismael Ghalimi d’Intalio, à propos de la solution thinkgamy
Forthcoming, le blog de Sig de Thingamy, à propos de la modélisation des concepts de la comptabilité
Une organisation pour un SI intégré septembre 11, 2006
Posted by vincent poncet in Architecture, Organisation.1 comment so far
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.
Petite histoire de l’organisation d’entreprise et de son informatisation juillet 24, 2006
Posted by vincent poncet in Organisation.6 comments
Afin d’apporter quelques lumières aux problèmes actuels de la DSI (maitrise des coûts, délais, alignement avec le métier), cet article les mettra en perspective avec l’histoire de l’organisation des entreprises.
Fondation de l’entreprise : pas de responsabilité interne
Historiquement, les premières entreprises sont gérées par leur fondateur. Ce dernier partage à la fois la fonction d’entrepreneur et d’apporteur de fonds. Il embauche des employés pour l’aider dans la réalisation des ses activités vis à vis des différents partenaires de l’entreprise : ses fournisseurs et ses clients. Au début, les employés se voient affectés à différentes tâches mais sans avoir de responsabilités vis à vis des contrats liant l’entreprise à ses partenaires. Il n’y a pour ainsi dire pas d’organisation d’entreprise.
Ce modèle ne peut fonctionner efficacement qu’avec une très petite taille d’entreprise, car dans ce modèle, toutes les décisions ne peuvent être prises que par l’entrepreneur. Le système de prise de décision devient un facteur limitant pour la croissance de l’entreprise, surtout dans un marché en concurrence.
Sur les différents marchés où agissent les clients, les fournisseurs et les investisseurs, notre entreprise se trouve en concurrence avec d’autres pour la conservation de ses contrats et l’obtention de nouveaux. Cette concurrence sera le moteur essentiel dans la recherche de nouvelles manières de s’organiser pour augmenter son efficience.
Responsabilités internes : apparition de l’organisation
Pour pouvoir croitre dans un contexte concurrentiel, l’entrepreneur va déléguer des responsabilités contractuelles de l’entreprise à certains de ses employés. L’organisation d’entreprise va commencer à apparaitre autour de branches qui auront pour responsabilité de gérer chacun des différents types de contrats.
Ces branches seront propriétaires – internes à l’entreprise – de ces contrats. De nouvelles branches apparaissent :
• Direction des Achats : elle aura la responsabilité des contrats avec les fournisseurs. Ses rôles seront de chercher les fournisseurs, de définir les cahiers des charges, de négocier les prix, gérer les contentions, etc…
• Direction Commerciale : elle aura la responsabilité des contrats avec les clients. Ses rôles seront de chercher des clients, de s’assurer la bonne exécution de leurs commandes
• Direction Financière : elle aura la responsabilité de fournir les rapports demandés par les investisseurs
• La production sera elle aussi regroupée dans une branche spécifique à cette activité. La différence avec les autres branches, c’est qu’elle n’est pas directement attachée à un contrat de l’entreprise. Elle l’est, toutefois, indirectement via ses relations internes avec les autres branches.
Chaque branche deviendra responsable de son activité. Le manager sera ainsi en quelque sorte propriétaire de son activité. Il aura donc une certaine liberté quand aux décisions qu’il pourra prendre pour répondre au mieux aux objectifs qui lui ont été fixés.
Arrivée des outils de productivité informatisée
Le manager étant propriétaire de son activité, il mettra en œuvre les moyens nécessaires pour augmenter la productivité de sa branche. Les technologies de traitement de l’information permettent d’augmenter la vitesse, la fiabilité, la productivité et donc les coûts du traitement.
Ainsi, certains managers jugeront opportun de s’équiper de ces machines de traitement de l’information. L’informatisation des différentes branches métiers se fera au rythme de chaque manager et de la nature des fonctions et des tâches qui sont sous sa responsabilité. Les tâches les plus répétitives et ayant lieu de manière plus fréquente seront celles qui auront les premières intérêts à être informatisées.
Compte tenu donc de l’ouverture du manager aux outils informatiques et de la nature de ses fonctions dont il a la responsabilité, chaque branche métier s’informatisera à des vitesses différentes et surtout de manière indépendantes. En effet, chacun étant propriétaire de sa branche métier, chaque système informatique aura tendance à être indépendant des autres.
Peu à peu, toutes les branches de l’entreprise vont s’informatiser, et souvent en s’équipant des mêmes systèmes et résolvant les mêmes problématiques récurrentes chacune de leur côté.
Rationalisation de l’informatique : la Direction Informatique
Prenant conscience qu’il existe désormais une multitude de systèmes et de compétences redondants, la direction générale souhaitera réduire ces coûts inutiles. Elle donc jugera utile de mutualiser toutes les ressources informatiques disséminées dans les différentes branches métiers au sein d’une branche unique, la Direction Informatique.
Le rôle de la DI est de gérer les systèmes informatiques pour le compte des branches métiers. Elle assure l’exploitation, la supervision, la maintenance corrective et évolutive des systèmes qui lui ont été confiés.
Des gains de productivité vont être réalisés grâce à la rationalisation de la gestion des compétences informatiques et à la capitalisation des méthodes de gestion de projets informatiques. Néanmoins, force est de constater que l’infrastructure informatique reste éclatée dans un grand nombre d’applications connectées entre elles de manière souvent désordonnée. La DI dépense la plus grande part de son temps et de ses budgets dans cet effort visant à intégrer les applications entre elles afin de réaliser des processus métiers qui sont nécessairement transverses, contrairement aux applications.
Si la DI a su capitaliser sur les méthodes et les compétences, c’est parce qu’elle est propriétaire de ses ressources humaines et de ses méthodes de gestion de projet, de conception et d’exploitation. De même, si la DI n’a pas pu rationaliser les applications dont elle a la gestion en faisant émerger des référentiels uniques d’objets métiers et des processus de bout en bout dans le SI, c’est parce que les applications restent propriétés des branches métiers.
Les freins à l’alignement du SI avec le métier trouvent leurs sources dans la propriété des applications
Tout comme les branches métiers ont pu améliorer leur efficience parce qu’elles étaient propriétaires de leurs ressources, la DI n’a pu le faire que ce sur quoi elle était pleinement propriétaire. La Direction Informatique se retrouve donc dans la même configuration que l’entreprise à ses débuts. Elle n’a pas d’organisation bâtie sur des responsabilités définies en accord avec les engagements qu’elle a vis-à-vis de ses clients que sont les branches métiers. Elle ne peut donc d’ailleurs prétendre à s’appeller Direction du Système d’Information, puisqu’elle n’en est pas propriétaire. Pour améliorer la réactivité, l’alignement et les coûts de la DI, il faut qu’elle devienne propriétaire des applications. Dans le prochain article, on verra comment évolura le SI dans ce contexte et ce qu’il deviendra des applications.
Quelques enseignements à tirer des ERPs (2/2): une organisation pour construire le SI avril 17, 2006
Posted by vincent poncet in Organisation.add a comment
Les concepteurs des ERPs ont réussi à réunir de manière homogène et cohérente de nombreuses fonctions métiers disparates. C’est une révolution dans l’histoire de l’information de gestion, parce qu’auparavant les applicatifs n’étaient conçus qu’en fonction d’une typologie de besoin métier. L’ambition pouvait sembler démesurée, mais force est de constater qu’au moins une partie du chemin a été accompli. L'ERP a apporté une homogénéisation du SI, mais il a aussi apporté son propre lot de rigidités. On peut tirer parti de cet enseignement pour esquisser une organisation de la DSI capable d'avoir un système homogène et évolutif aux besoins de changements de l'entreprise.
Ayant bien identifié que le problème essentiel était la dissémination des informations, leur solution a été de bâtir les différents modules applicatifs autour d’un modèle de données unique. De même, étant parti des besoins globaux de l'entreprise, les processus métiers ont été conçus de manière transverse dès le départ. Dans un ERP, les objets métiers sont présents de manière unique et les processus métier sont identifiables à l'intérieur de la solution. De son côté, le développement par applications nous a laissé un paysage applicatif avec des duplications de données, des différences de représentation et même des différences de valeur de ces données. De même, ce mode de développement ne permet pas d'avoir une visibilité sur l'implémentation des processus métiers. Les processus métiers sont enfouis et éclatés dans pléthore d'applications à travers tout le SI. L'informatique héritée de l'âge du développement applicatif permet certes d'exécuter des opérations, mais elle ne permet pas d'en suivre l'exécution. Enfin, elle ne permet surtout pas de se reconfigurer rapidement pour répondre aux besoins changeant de l'entreprise.
La difficulté d’assurer la cohérence aussi bien des objets métiers que des processus métiers réside dans le fait que ces deux entités sont interdépendantes. D’un côté, les objets métiers sont utilisés par plusieurs processus, de l’autre, les processus manipulent plusieurs objets métiers. L’objet « Client » est utilisé par de nombreux processus, comme par exemple, « Prise de Commande » ou « Retour SAV ». De son côté, le processus « Prise de Commande » manipule aussi bien l'objet « Client » que l'objet « Produit ».
Le développement par applications conduit à une incohérence et non-homogénéité des objets et des processus à travers le système d'information. En effet, se limitant à une vue centrée sur une typologie de besoins spécifiques, l'application ne traduit qu'une vue incomplète des objets et des processus de l'entreprise.
« Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. »
Loi de Melvin Conway, 1968
Pour arriver à faire cohabiter des définitions globales des objets métiers et des processus métier de l’entreprise sans en dupliquer des instances, les éditeurs d’ERP ont dû construire et raffiner les objets métiers en même temps qu’ils ont construits et raffinés les processus métiers. Pour arriver à ce résultat, il est fortement probable que leur organisation interne distingue des responsables du développement des objets métiers d’une part et des responsables de processus métiers, d’autre part. Nous n'avons pas trouvé de documents tangibles sur l'organisation interne des éditeurs d'ERP, mais il y a des éléments qui corroborent cette thèse. En juillet 2003, SAP a annoncé qu'ils redéfinissaient l'organisation du développement de leur produit.
Following the creation in February 2003 of SAP’s Technology Platform organization (formerly Technology Development) led by Shai Agassi, member of the SAP Executive Board, SAP also announced today the newly created Application Platform & Architecture (AP&A) group, led by Peter Zencke, member of the SAP Executive Board. This group will drive the SAP Enterprise Services Architecture, enabling the BSGs to rapidly develop, configure and assemble industry and solution-specific capabilities. The AP&A group will develop reusable core business objects (such as cost/profit centers); business process patterns and user interface patterns as well as engines that are used in multiple industries (such as pricing engines); and product suite elements. The AP&A group will also facilitate and streamline all global research and innovation activities at SAP, focus on further improving time-to-market and enhance overall product quality.
Les DSIs doivent apprendre de l’organisation des éditeurs d’ERP, car si elles arrivaient à intégrer leur modèle en leur sein, elles pourraient avoir ce qu’elles recherchent, c’est à dire un SI cohérent, aligné sur le business et l’accompagnant dans ses évolutions.
Tant que les DSIs continueront à être organisées par responsabilité d’applications, elles souffriront de ce manque de cohérence, de ces coûts d’intégration et de ce manque d’agilité qui les caractérisent tant. Ces problèmes ont une source organisationnelle. Il est inutile de courir après la dernière technologie quand son organisation ne peut pas permettre de mettre en œuvre l’agilité. Les seuls éléments qui ont du sens vis-à-vis de l’entreprise ne sont pas les applications, mais les objets métiers et les processus de l’entreprise.
La DSI doit donc abandonner son organisation par application. Elle doit désormais s’organiser par responsabilités de processus et d’objets métiers. Le chemin sera long et difficile, il y aura de nombreuses réticences à ce changement. Mais ce changement est inévitable pour tendre vers une DSI partenaire du métier qui ne soit plus un partenaire limitateur mais un partenaire facilitateur.
Quelques enseignements à tirer des ERPs (1/2): efficacité, coûts et rigidité février 5, 2006
Posted by vincent poncet in Organisation.2 comments
Avec le recul que nous avons aujourd’hui, nous pouvons dire que les ERPs ont bouleversés les Systèmes d’Information des entreprises de manière durable. Ils ont aussi impacté la manière qu’il convenait de voir le SI, càd avant tout, un outil au service du métier.
La vision des ingénieurs qui ont fondé SAP était de faire une application couvrant tous les besoins en matière d’automatisation des activités, et ce, en temps réel. En effet, à l’époque, en 1972, bon nombre des traitements étaient réalisés en lot à échéance régulière, généralement à la journée. La mise en place d’un ERP a permis aux différentes activités de l’entreprise de travailler enfin au fil de l’eau. Les personnes d’un service n’avaient plus à attendre que les opérations de leurs collègues des autres services soient traitées par le système pour pouvoir réaliser leur travail. Les ERPs ont ainsi apportés de grands gains d’efficacité dans l’organisation des entreprises.
Des gains d’efficacité indéniables, mais avec des coûts d’implémentations à la dérive
On se doit de reconnaitre que la stratégie menée par SAP est un grand succès. De nombreuses entreprises sont sorties de la faible efficacité de leur informatique en implémentant cet applicatif portant les best practices de processus. La transformation de ces entreprises est allée jusqu’à la transformation de la manière qu’elles avaient de faire leurs business. Elles ont changé leurs pratiques pour s’adapter à celles imposées par SAP. L’implémentation des ERPs a été une phase de rationalisation des pratiques métiers des entreprises. Pour autant, cette rationalisation n’a pas été sans douleur, elle a même été une rupture. Elle a aussi engendré des coûts considérables qui n’avaient pas été estimé à une telle ampleur. En effet, la transformation de l’organisation de ces entreprises a nécessité des coûts allant bien au-delà des simples coûts de licences des ERPs. Il a fallu transformer l’organisation et donc former les employés aux nouvelles pratiques, redéfinir les responsabilités pour se conformer au modèle implicitement implémenté dans SAP. À cela, il faut ajouter les coûts d’ordre politique pour l’obtention des nouveaux postes à responsabilité générés par la réorganisation.
Ce bouleversement a dû être accompagné d’une information sans faille afin de convaincre tous les acteurs de l’entreprise du bien fondé de la transformation et de limiter les effets d’incompréhension et de mécontentement qui accompagnent une transformation. Ces processus de conduite du changement ont accru d’autant la facture de la mise en place des ERPs.
Côté SI, il a fallu récupérer les informations présentes dans les systèmes devant être remplacés par l’ERP, les trier, les traiter, les transformer pour qu’elles soient conformes au modèle imposé par l’ERP. Le SI existant étant rempli de duplication et d’incohérences dues à la duplicité de présence des informations dans le SI, d’énormes coûts de normalisation des données ont été à ajouter à la facture. Aussi, l’ERP remplaçant une pléthore de systèmes par un seul système, l’infrastructure technique supportant l’ERP a donc du être remplacée, ajoutant un facteur de coût supplémentaire en terme de hardware. Enfin, le SI étant transformé, on a donc eu aussi des coûts de formation, de politique et de conduite du changement dans le DSI même.
Comme l’expérience des « early adopters » sert à ceux qui les ont suivent, les suiveurs ont pu mieux estimer les coûts d’une telle transformation pour mieux juger de son retour sur investissement. Toutes les entreprises n’ont adopté l’ERP, elles ont malgré tout été nombreuses à le faire. Disposant de nombreux retours d’expériences, nous sommes aujourd’hui plus à même de juger du positif et du négatif de la vague ERP.
Et quel résultat concernant la rigidité du SI ?
L’implémentation d’un ERP a permis une rationalisation des méthodes de travail mais il est tout de même étonnant qu’il ait fallu une évolution du système d’information pour que le business se transforme. Une hypothèse sur ce point est d’émettre que l’infrastructure informationnelle existante bloquait l’évolution du métier. Les ERPs ont permis de débloquer cette situation. Néanmoins, cette hypothèse nous apporte un nouvel argument critique à l’encontre des ERPs : Bien que les ERPs aient apporté des gains indéniables en termes d’efficacité, n’ont-ils pas remplacé une rigidité par une autre rigidité ?
Il s’agit d’une critique majeure à l’encontre des ERPs. Les entreprises qui en disposent ont scellé leur destin organisationnel avec celui implémenté dans les ERPs. La critique de la rigidité du SI n’a pas été balayée avec l’avènement de l’ERP. Elle a simplement changé de forme. Et la réalité n’a pas tardé à s’imposer. La vague des progiciels spécifiques à un domaine métier (CRM, SCM , B2B, …) a montré que les DSIs avaient deux solutions pour faire évoluer leur SI. Attendre que leur éditeur d’ERP implémente de nouvelles fonctionnalités et soit perdre des parts de marché face à leur concurrent, soit diminuer leur rentabilité relative à leurs concurrents, ce qui reviendrait à perdre la confiance de leurs investisseurs. Ou bien suivre les « pure players » spécifiques (Siebel, I2, …) et supporter les coûts d’intégration entre ces briques logiciels et donc retourner à la situation initiale avec une multiplicité de la présence des données et un éclatement des processus métiers.
Nous revoilà donc au point de départ et le SI traverse de nouveau une crise existentielle face à sa mission : être une fonction support du métier lui permettant de s’épanouir et non de limiter son évolution.
Intégration d’applications ou intégration ontologique ? janvier 9, 2006
Posted by vincent poncet in Architecture.1 comment so far
L’intégration du SI passe par l’intégration des briques le composant étant présent à un moment donné. Aujourd’hui, la brique élémentaire du SI est l’application. C’est donc tout logiquement que l’intégration du SI est considérée comme l’intégration des applications qui le composent. Néanmoins, il ne suffit pas de connecter les applications entre elles selon les besoins en information de telle ou telle application pour dire que l’on fait de l’intégration de SI. Il ne faut pas prendre l’application comme un élément stable et autonome qu’il faudrait connecter à d’autres éléments stables et autonomes. Il faut plutôt intégrer ce pourquoi les applications ont été conçues. Il faut donc revenir à leur processus de conception afin de définir l’objet de l’intégration de SI.
Le processus de conception de l'application comme source du problème d'intégration
Une application est conçue pour répondre à des besoins métiers au périmètre bien circonscrit. En effet, chaque application est généralement considérée comme propriété de la branche métier commanditaire. C'est, en effet, elle qui a ouvert une ligne budgétaire afin de payer la DSI pour la conception de l’application correspondant à son besoin. Cette relation de propriété entre la branche métier et l’application conduit nécessairement à la limitation du périmètre de l’application aux besoins de la branche commanditaire. Pour la branche métier commanditaire et utilisatrice de l’application, cette application lui sert à automatiser un certain nombre de tâches relatives aux sous-processus dont elle a la charge dans l’entreprise et d’en suivre l’exécution. Ainsi, cette application servira à manipuler un certain nombre d’objets en vue de leur appliquer les traitements appropriés. Par exemple, la branche « Commercial » souhaite une application de gestion des ventes. Pour cela, devront être définis l’objet métier « Vente » ainsi que les différents traitements qui feront évoluer son cycle de vie. Ces différents traitements seront définis en accord avec les sous-processus méties relatifs au processus métier « Vente » dont elle a la charge.
Les applications sont définies par rapport à des besoins au périmètre restreint. On comprend donc que la définition des objets et des traitements relatifs à ces objets présents dans l’application ne recouvrent qu’une vision parcellaire et non globale de l’entreprise. Une application manipulant des sous-processus et des objets métiers, elle porte en elle une représentation du monde du point de vue de son commandiataire. Une application porte donc l’ontologie relative à la branche métier commanditaire et non l’ontologie globale de l’entreprise. Or, un même objet métier peut se retrouver dans différents processus métiers. Par exemple, l’objet « Vente » est autant présent pour la branche métier « Commercial » que pour celle de « Gestion des stocks ». Sa définition au sens de l’entreprise sera donc portée par au moins deux applications. De même, les sous-processus réalisés dans différentes applications participent aux mêmes processus globaux. Les définitions des objets métiers et des processus globaux sont donc disséminées dans tout le système d’information. Toute la difficulté de l'intégration du SI consiste donc à recréer une homogénéité globale alors que les parties à intégrer n’ont pas été conçues dans cette optique.
Le but de l’intégration du Système d’Information : l’intégration ontologique
La problématique d’intégration du système d’information prend donc sa source dans cette dissémination des définitions des objets métiers et des processus globaux de l’entreprise dans toutes les applications du système d’information. L’intégration de SI ne vise qu’à rassembler tous les sous-processus et les objets métiers parcellaires portées par toutes les applications du SI afin de reformer les processus métiers de bout en bout de l’entreprise et les objets métiers du point de vue global de l’entreprise. En un mot, l’intégration du système d’information vise à faire émerger l’ontologie de l’entreprise à partir des ontologies locales de ses différentes branches métiers capturées dans les applications du système d’information.
L’organisation centrée sur les applications comme source de la problématique d’intégration janvier 4, 2006
Posted by vincent poncet in Organisation.2 comments
La logique actuelle dans la majorité des DSIs est qu’à chaque besoin ou typologie de besoin corresponde une application. Ces applications nécessitants des informations déjà présentes dans le système d’information, les personnes en charge de la réalisation de ces applications devront développer des connections entre ces nouvelles applications et celles déjà présentes dans le SI.
L’intégration d'application : sa complexité technique et organisationnelle
Toute application peut potentiellement être consommatrice des données générées par toutes les autres applications du SI. La multiplicité des liens point à point que l’on retrouve dans tous les SI ont amené les analystes à décrire le système d’information comme un plat de spaghettis. Cette multiplicité des interdépendances entre applications donne lieu à d’énormes coûts tout au long des différentes phases du cycle de vie d’une application.
Lors de l’étude, vu que bien peu d’entreprise disposent d’une cartographie exhaustive de leur SI, les personnes en charge de la réalisation d’une application devront aller enquêter auprès de leurs collègues pour savoir où se trouve l’information convoitée et quelle application – en espérant qu’il n’y en ait qu’une – en est génératrice. Dans la plupart des cas, cette enquête arrivera à la conclusion que chaque information prise individuellement se trouve dans telle ou telle application en fonction de telle ou telle condition. Ainsi, par exemple, pour avoir la totalité des clients de l’entreprise, on devra aller les chercher dans différentes applications en fonction, par exemple, de la ligne de produits qu’ils ont achetés. De plus, cette étude montrera que la représentation d’une même donnée ne sera pas identique d’une application à l’autre et donc que des règles de transformation spécifiques devront être réalisées durant le développement. De même, toutes les informations relatives à un client sont disséminées parmi toutes les applications du SI.
Lors de la conception, une fois les applications sources identifiées, la problématique à résoudre sera celle de la stratégie de connectivité. A cette étape, les concepteurs devront définir, avec les responsables de l’application tierce, comment se connecter, à quel niveau (par les données, par les APIs, par revamping d’écrans), par quelle technologie, selon quelle régularité (par batch, au fil de l’eau). Ce travail devra être fait pour toutes les applications auxquelles se connecter, et il y a de grandes chances pour que chaque connexion doive être réalisée selon une stratégie de connectivité spécifique.
Lors de l’exploitation de l’application, se posera le problème de la supervision de toutes ces chaînes de connectivité. En effet, la rupture de l’un des liens reliant une application à une autre peut rendre non fonctionnelles ces deux applications. L'impact pourra être encore plus important si l’on considère que chaque application fait partie d'un systèmes d'applications interdépendantes.
Lors de l’évolution de cette application, il devra être pris en compte l’impact des modifications demandées sur la multitude des liens relative à cette application.
Enfin, cette multiplicité des connections n’a pas qu’un impact technologique, car pour chacune de ces connections, il devra y avoir un accord entre les responsables des applications concernées. Chaque application ayant été conçue par rapport à un besoin métier circonscrit, la gestion de cette application en a pris la même direction. Il n’est effectivement pas rare de voir qu’en termes de sphère d’influence de pouvoir au sein de l’entreprise, un responsable d’application est très proche du responsable métier correspondant aux besoins de l’application. Ainsi le responsable d’une application n’a pas d’intérêt à voir « ses » données utilisées par d’autres applications ; de même, il n’a pas d’intérêt à voir « ses » ressources humaines travailler sur la connectivité nécessaire pour les besoins d’une autre application.
Nous voyons donc que tout au long du cycle de vie d’une application, de part ses implications organisationnelles, technologiques et politiques, la connectivité inter-applicative alourdit considérablement le processus de réalisation de cette application et alourdit surtout son évolution. Ces interdépendances non-alignées avec l’organisation de la DSI augmentent la rigidité du SI et freinent son adaptabilité au changement permanent du business face à une économie, elle aussi, en évolution perpétuelle.
L’urbanisation durable du SI passe par un alignement des concepts premiers du SI avec l’organisation de la DSI
En définissant implicitement ou explicitement les applications comme élément de base du SI, l’organisation actuelle des DSI ne mettent pas en avant les besoins de leur clients, mais une implémentation possible de ces besoins. En effet, les besoins des branches métiers s’exprimant en terme de processus métiers et d’objets métiers, alors que la DSI ne parle qu'en terme d'applications et de flux inter-applicatifs. Il est donc aisé de comprendre la difficulté de communication quand une branche métier exprime une demande informatique en terme de processus et que la DSI répond en terme d’applications. Cette différence de paradigme entre les branches métiers et la DSI est la source du non-alignement entre le SI et le métier. Si la DSI veut pouvoir réussir l’alignement du SI au métier de l’entreprise, elle doit donc abandonner son organisation par responsabilité d’applications, voire abandonner le concept même d’application pour s’organiser selon les concepts premiers du métier que sont le processus et l'objets métier.
Bienvenu sur le blog de «Urbanisation Durable du Système d’Information» janvier 4, 2006
Posted by vincent poncet in Architecture, Organisation.3 comments
Ce blog vise à définir l’Urbanisation Durable du Système d’Information, comme relevant d’un ensemble de principes à la fois architecturaux et organisationnels dont l’objet d’aligner la DSI comme une partie intégrée au business de l’entreprise.
Urbanisation Durable du Système d\'Information 