Les modèles d’entreprise et leur utilisation : quelques réflexions

22/09/2017
Publication e-STA e-STA 2007-4
OAI : oai:www.see.asso.fr:545:2007-4:19880
DOI :

Résumé

Les modèles d’entreprise et leur utilisation : quelques réflexions

Métriques

20
8
118.01 Ko
 application/pdf
bitcache://3037acea0a59f0d6bf9ab98001fa98867041b9aa

Licence

Creative Commons Aucune (Tous droits réservés)
<resource  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://datacite.org/schema/kernel-4"
                xsi:schemaLocation="http://datacite.org/schema/kernel-4 http://schema.datacite.org/meta/kernel-4/metadata.xsd">
        <identifier identifierType="DOI">10.23723/545:2007-4/19880</identifier><creators><creator><creatorName>Johnny Huysentruyt</creatorName></creator></creators><titles>
            <title>Les modèles d’entreprise et leur utilisation : quelques réflexions</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2017</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Fri 22 Sep 2017</date>
	    <date dateType="Updated">Fri 22 Sep 2017</date>
            <date dateType="Submitted">Wed 19 Sep 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">3037acea0a59f0d6bf9ab98001fa98867041b9aa</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>33791</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

Résumé - Depuis plus d’un quart de siècle, la modélisation des processus et d’organisations a fait l’objet d’efforts considérables. Différents modèles ont été développés et de nombre d’outils ont pour ambition de supporter les efforts de modélisation des organisations. Après un bref aperçu des modèles de référence, l’auteur examine un échantillon de projets de modélisation et tente de dégager un certain nombre de tendances pour conclure par une série de suggestions de recherche dans le domaine. I. POSITION DU PROBLEME A. La question Depuis plus d’un quart de siècle, des efforts de recherche considérables ont été consacrés à la modélisation d’entreprise et plus particulièrement à la définition de modèles de référence et à la mise au point d’outils de modélisation. Dans un monde dominé par la dimension économique où les critères de coûts et bénéfices et d’allocation de ressources limitées sont d’une importance majeure, il est naturel de se poser la question de l’impact de ces efforts de recherche, au vu notamment des objectifs poursuivis. La présente contribution n’a ni pour but de présenter dans toute son ampleur les projets de recherche en cours, ni de faire un état de la pratique de ces modèles et des outils qui les accompagnent. Il s’agit plutôt, sur base de quelques cas pratiques, de poser le problème, de donner réponse à un certain nombre de questions et par la suite, de présenter quelques suggestions en matière de recherche. La question qui se pose est donc de savoir si les modèles développés sont utilisés en pratique, de savoir quels sont les facteurs propices à leur utilisation durable et d’indiquer de quelle façon l’alignement entre les travaux de recherche et la pratique pourrait être renforcé. B. Les limites de cette contribution La contribution réfère à un certain nombre de cas récents, parfois en cours, dans différents domaines : • Secteur financier : développement d’un architecture d’entreprise couplée à une architecture informatique en vue d’un redécoupage et d’une réallocation des processus en Europe. • Secteur financier : après fusion de deux organisations, révision et unification des processus propres aux fonctions chargées des contacts avec la clientèle (front-office). • Secteur public : mise en place au sein d’un ministère d’une entité chargée de la gouvernance de l’architecture d’entreprise. • Secteur de la distribution d’électricité et de gaz : mise au point d’un modèle d’entreprise cible, servant de base à la conception de nouveaux processus suite à la libéralisation du marché et à la rénovation, sur plusieurs années, des systèmes informatiques. • Secteur de l’automobile : définition d’une stratégie informatique visant à établir des synergies entre les entités européennes, jusqu’alors, fort indépendantes. La taille des organisations concernées varie de quelques centaines à quelques dizaines de milliers de personnes. Vu l’actualité des cas, les entreprises en questions sont réticentes à déjà en divulguer les détails. Les sources d’information sont dans la plupart des consultants qui ont participé de façon directe aux travaux ou qui y participent encore. L’analyse présente une vue partielle sur certaines organisations et court donc le risque d’une certaine subjectivité.. Dans une autre phase de sa vie professionnelle, l’auteur a participé a un projet de recherche visant à la mise au point, dans un contexte international, d’un modèle de référence, ce qui lui a permis d’observer et de partager les idées, les rêves et parfois les déceptions, de dizaines de collègues chercheurs. La confrontation de ces deux types de sources permet d’espérer que les suggestions formulées présenteront quelque utilité pour les chercheurs intéressés. II. LA RECHERCHE ET LE DEVELOPPMENT EN MODELISATION A. La recherche et de le développement Dans le domaine qui nous intéresse, l’on trouve un multiplicité d’appellations qui identifient des objets sinon similaires, du moins fort proches quant à leur nature et quant à leur finalité : modèle d’entreprise, modèle de processus, modèle de domaine (valable pour un domaine d’activité donné comme par exemple la banque ou les télécommunications), modèle de référence, metamodèle, architecture ou encore architecture de référence. Ces différentes définitions reflètent les ambitions de leurs auteurs : développer un formalisme ou une référence pouvant être utilisée dans de multiples situations ou mettre en évidence en vue d’un partage, l’essentiel des activités communes à plusieurs organisations similaires. JOHNNY HUYSENTRUYT CAPGEMINI CONSULTING BELGIQUE Email : johnny.huysentruyt@skynet.be Les modèles d’entreprise et leur utilisation : quelques réflexions La modélisation d’entreprise est riche de contributions [2]. On peut citer : Des modèles génériques tels que : CIM-OSA [1], ETOM [4], FEA [5], GRAI [3] , GERAM [6], PERA [10], et d’autres tels que TOGAF et Zachmann, , auxquels on peut ajouter des formalismes de modélisation tels que UBL , UML, diagramme de Petri, sans parler de techniques de modélisation pratiquées en organisation administrative, en informatique et en recherche opérationnelle. Ces techniques sont mentionnées car elles accompagnent souvent l’utilisation de modèles dits de référence. Voir aussi [9] pour une introduction synthétique à CIMOSA ? GRAI/GIM et PERA.. • Des modèles plus ou moins explicites, associés à des suites de solutions informatiques (progiciels) telles que SAP, Oracle, …. • Des outils de modélisation qui selon le cas, sont fortement alignés sur un des modèles mentionnés ou par contre, fort ouverts en termes de techniques de modélisation, ce qui requiert alors la configuration de l’outil en fonction du modèle adopté. • En parallèle, il y a les travaux au niveau de la standardisation. En effet, certains modèles prétendent à une certaine universalité et lorsqu’il n’existe pas d’acteur dominant à même d’imposer ses normes, les objectifs de diffusion et d’adoption large d’un modèle passent par les travaux de standardisation. B. Objet et objectifs de la modélisation Les modèles visent à la représentation des processus et activités, des entrées-sorties, des interdépendances entre processus, des règles de pilotage, les indicateurs de performance ainsi que des ressources mises en œuvre. Le but n’est pas ici de passer en revue les caractéristiques des différentes modèles. A titre d’illustration cependant, voici quelques de concepts-clé du modèle Geram1 : (1) un objet d’entreprise (un processus, une ressource, une ensemble de données) peut être caractérisé par son cycle de vie, qui détermine les étapes depuis l’identification de l’objet jusqu’à sa mise hors service, en passant par toute une série d’étapes intermédiaires : Figure 1 : La notion de cycle de vie d’une entité 1 Geram n’est pas un modèle de référence à proprement parler mais plutôt un cadre de référence conceptuel permettant de situer et de comparer différents modèles de référence. (2) le modèle de référence est structuré en deux ‘dimensions’ fondamentales. D’abord la notion qui permet de regrouper certaines catégories de modélisation de façon à présenter à son utilisateur, la quantité d’information idéale pour un contexte donné. Ainsi l’on peut produire dans un contexte, une vue focalisée sur les activités tandis que pour un autre contexte, c’est la vue sur les ressources qui est la plus appropriée. D’autre part, au travers de la notion d’instanciation, le modèle considère que l’on peut passer d’un modèle générique à un modèle particulier, spécifique à une situation donnée, par exemple la configuration d’une organisation donnée à un instant donné. Entre le modèle générique et le modèle particulier, il y a le modèle partiel, dans le sens de modèle partiellement générique (ou concret). Figure 2: Les notions de vue multiples et d'instanciation (3) aux caractéristiques mentionnées plus haut s’ajoute une notion de traduction (mapping) ou d’exécution d’activités et ce, au moyen de trois types de ressources (a) les acteurs humains (2) les équipements tels que machines et robots (3) les ordinateurs compris au sens des technologies de l’information. Cette traduction est évidemment conditionnée par les décision prises quant au niveau d’automatisation. Les informations propres à ces différents types de ressources permettant d’exécuter les processus, sont regroupées sous la forme d’architectures spécifiques. Figure 3: La traduction (mapping) des activités vers les différentes architectures de mise en oeuvre Il y a évidemment des variations d’un modèle de référence à l’autre. Parmi ces modèles, la méthodologie GRAI avec sa grille, mise au point par le laboratoire GRAI/LAPS de l’Université de Bordeaux, se distingue des autres modèles par l’accent fort important porté sur les aspects décisionnels de l’entreprise, en complément de la modélisation des activités. En général, la littérature dans le domaine met en avant différents objectifs génériques pour la modélisation : • La conception, l’analyse et la mise en œuvre, sur base d’un modèle explicite, d’une organisation, • Une meilleure compréhension de ce qu’est une organisation en vue de faciliter la communication, la coopération et la synergie entre les différents acteurs, • L’identification de structures de bases pour des organisations similaires, le partages des meilleures pratiques et dès lors, la possibilité d’accélérer le processus de conception. En termes d’utilisation pratique, les différents modèles permettent de représenter l’état actuel (As-Is en anglais), des situations futures possibles (As-Could) et la situation cible (To-Be). L’objet de la modélisation peut être l’organisation dans son intégralité dans un contexte de conception stratégique ; celle-ci sera suivie de la gouvernance du modèle en vue d’intégrer les contributions de différents projets de modélisation et de réorganisation de processus. Soit l’on considèrera un sous-ensemble de l’organisation lors d’un projet de transformation, par exemple, dans le cas de la réorganisation du « front-office » d’une banque. Dans d’autres cas encore, on modélisera l’essentiel des activités en vue d’établir une base de référence pour la stratégie informatique. Les considérations précédentes permettent de mettre en évidence le contraste entre les motivations de chercheurs et des praticiens. Les premiers visent à mettre en évidence le langage commun permettant de représenter des états de l’entreprise et si possible, les structures communes. Pour les gens de la pratique, l’objectif essentiel de la modélisation est le contrôle. Autrement dit, le but est d’augmenter le caractère prévisible des systèmes et de réduire ainsi le risque associé aux situations non prévues ou non pilotables. Le commerce électronique (eCommerce ou eBusiness), l’administration en ligne (eGovernment) et les tendances croissantes d’interaction électronique entre les organisations, leurs clients et leurs partenaires, auront sans aucun doute une influence considérable sur la modélisation. L’interoperabilité des organisations2 requiert non seulement la communication entre les infrastructures informatiques, la coopération entre les applications et la compatibilité des modèles d’entreprises. Ce dernier aspect est d’importance car, lorsque par voie électronique l’on adresse un objet donné, il faut s’assurer qu’il s’agit de la même chose, même si le nom qui lui est donné dans un contexte (organisation A) est différent de son appellation dans un autre contexte (organisation B). Une évolution est aussi probable quant à l’objet de la modélisation. Si par le passé l’effort se portait sur une organisation donnée 2 Sujet central du projet INTEROP, projet européen qui regroupe plusieurs dizaines de partenaires et dont la maîtrise d’oeuvre est assurée par le laboratoire LAPS de l’Université de Bordeaux [8]. ou une des ses parties, le besoin ira croissant de modéliser les processus de coopération entre organisations ou leurs protocoles d’interaction au niveau des interfaces. Un exemple frappant est ce qui se passe dans le secteur public où une organisation par exemple située au niveau national est amenée à collaborer avec celles du niveau régional et du niveau local, pour prendre en compte la répartition des compétences et afin d’offrir aux citoyens et aux entreprises un service cohérent, efficient et de qualité. Il est permis de croire que la modélisation inter-organisationnelle aura un effet d’accélération sur la modélisation intra-organisationnelle. C. Les outils Les outils de modélisation constituent tout un sujet en soi. Dès que l’on aborde un sujet tant soit peu compliqué, l’outil automatisé servira d’outil de mémorisation, de vérification et d’expression sélective ou complète du modèle. C’est évidemment la technologie informatique qui conditionne l’évolution de ces outils : elle permet d’embarquer de plus en plus d’intelligence càd des règles d’aide à la modélisation et à sa vérification. L’objectif primaire poursuivi par la mise en place d’un outil est d’assurer l’économie du processus de modélisation. Celui- ci est dans la plupart des cas, une activité de groupe et requiert donc une discipline visant: • au caractère univoque des définitions, • à l’application uniforme des règles de modélisation, • à la gestion des configurations et des versions de modèles, pendant le processus de conception et au-delà, • à la gestion de la cohérence. Un outil n’est pas uniquement adéquat de par sa puissance de modélisation. Il doit posséder aussi un certain nombre de caractéristiques propres à son utilisation opérationnelle et qui touchent: • à sa capacité d’analyse et de simulation, • à ses possibilités de publication et de production de rapports, • à ses interfaces avec d’autres outils en vue de l’import ou l’export d’informations, • à son ergonomie, • au support fourni en matière de formation et d’utilisation, • aux coûts de mise en place et de mise en œuvre, • à la continuité du support fourni, au niveau d’un pays, par son distributeur. Hormis les outils mis au point par les laboratoires et les instituts de recherche, le développement des outils de modélisation obéit à une rationalité de marché. Certains outils s’alignent sur un modèle ou un progiciel donné, d’autres prônent l’ouverture et la flexibilité. Cette flexibilité n’est pas toujours un avantage puisqu’il faut une bonne connaissance des finalités, des besoins de modélisation à court et à moyen terme, et de l’outil lui-même pour le configurer pour un contexte donné, pour une organisation donnée. Dans les petites et moyennes entreprises et même dans les grandes, ces connaissances ne sont pas toujours présentes et entraînent parfois à des révisions considérables du modèle. Certains outils imposent un démarche de modélisation hiérarchique : le modèle est développé de façon hiérarchique, ce qui est propice à la cohérence interne du modèle. Dans beaucoup de cas cependant, le processus de conception présente des aspects « chaotiques » càd non planifiés ou planifiables au départ, ce qui empêche une démarche d’analyse purement hiérarchique. La connaissance des différents domaines d’une entreprise ou d’un processus est en pratique fort variable ; la modélisation se fait alors par assemblage de sous-modèles, quitte, au moment de l’intégration, à revoir la structure du modèle global. Certains outils vérifient à tout instant la cohérence, avec ses avantages et ses inconvénients : la mise en évidence des erreurs de modélisation ce qui constitue une contrainte forte lorsqu’en conception, l’on veut travailler avec des objets et des structures incomplètement définis. III. LA PRATIQUE DE LA MODELISATION Examinons maintenant les cas cités et notamment la connaissance des modèles, les objectifs des projets où la modélisation intervient, l’aspect durable des efforts de modélisation et les éléments de contexte qui nous semblent conditionner le succès de la modélisation. A. La connaissance des modèles Dans l’ensemble les modèles de référence sont relativement mal connus; les modèles propres à un domaine le sont mieux, en tout cas par les acteurs du domaine. C’est le cas d’ETOM pour les télécommunications. La méconnaissance des modèles génériques a sans doute des causes diverses : • Le manque de maturité, dans ce domaine, des organisations, • La multiplicité des modèles de référence et des techniques de modélisation, • Le rôle secondaire des techniques de modélisation par rapport aux impacts ‘visibles’ du projet: la rentabilité des l’investissement, la transformation de l’organisation, • Le cloisonnement qui existe toujours entre le monde technique et le monde administratif et qui freine la diffusion des modèles de référence hors de leur domaine d’origine. B. Les objectifs de projets de modélisation Ici, une première remarque s’impose : dans la vie des organisations, la modélisation est un moyen et non un but en soi. Les objectifs des projets concernés sont multiples ; il n’est pas rare qu’au départ d’un projet les objectifs ne soient pas clairement définis avec un risque de divergence ou d’inadaptation des moyens. De manière générale, l’on peut classer les objectifs des projets de modélisation de la manière suivante : • Contribuer à la conception d’entreprise dans son ensemble: traduction de la vision à long terme, • Contribuer à la conception d’un ou plusieurs processus d’entreprise : critique de l’existant, définition de la situation cible, définir la configuration du ou des processus aux différentes étapes de l’évolution depuis la situation actuelle jusqu’à la situation cible. • Faciliter la mise en place de l’organisation administrative, • Faciliter la gestion du risque, • Supporter la gestion de la qualité, • Supporter la gouvernance de l’architecture d’entreprise : veiller à l’intégration par le biais d’un modèle unifié, de toutes les initiatives en matière d’organisation et d’amélioration des processus, • Définir la base à partir de laquelle on pourra développer l’architecture du système informatique. On peut y ajouter des fonctions supplémentaires : un modèle d’entreprise peut, par exemple, offrir un cadre de référence à la gestion des connaissances et notamment à celle des meilleures pratiques et ce, dans une perspective d’amélioration continue. Souvent aussi, surtout aux premières étapes de la modélisation, l’organisation se découvre et permet aux acteurs de prendre distance, de développer un point de vue commun et d’en faire une analyse, ce qui facilitera l’émergence de synergies. Il est à noter que dans la plupart des cas que nous avons mentionnés au début de ce document, la modélisation était secondaire par rapport à l’objectif du projet. C’est la valeur générée par le projet – retour sur investissement, flexibilité accrue, motivation des équipes -, qui prime. Les éléments de justification seront évidemment différents selon qu’il s’agit d’un projet d’organisation, d’informatisation ou de gouvernance architecturale, mais dans tous les cas, on considère le projet comme un investissement dont on espère un résultat positif. Les acteurs impliqués dans le processus de modélisation sont divers : ce sont des décisionnaires, des architectes d’entreprise, des organisateurs, de consultants internes et externes, avec une expérience fort variable de la modélisation . La modélisation avec les outils spécialisés est la plupart du temps le propre des spécialistes qui maîtrisent le formalisme et l’outil. Lors des interactions avec les autres acteurs, par exemple, pendant des séances de brainstorming ou de prises de décision au niveau d’un comité directeur, l’on utilise en fait des techniques de représentation très simples : il est essentiel pour les acteurs impliqués de s’en approprier le contenu. Les formalismes qui visent à une représentation complète de toutes les dimensions relevantes semblent souvent trop peu transparents et complexes et risquent d’aliéner ceux qui ne les maîtrisent pas. De même, pour les séances de brainstorming qui visent non seulement à la définition d’un problème, à sa solution mais aussi à l’appropriation par les membres du groupe, les outils de modélisation apparaissent trop lents et trop peu flexibles par rapport à la technique qui utilise de grandes feuilles de papier (papier Kraft) collées au mur et l’on utilise des auto- collants détachables pour représenter les idées ou les éléments d’un problème. Chacun y est libre de contribuer avec ses idées. Cette technique brille par sa simplicité, sa flexibilité (on peut reconfigurer un problème ou une solution en un laps de temps très court) ; elle permet aussi le partage car la représentation est le résultat de l’ensemble du groupe. Sur un certain nombre de projets, l’on marie les deux démarches : acquisition des connaissances au moyen de techniques très simples et édition « off-line » du modèle au moyen d’un formalisme plus rigoureux. Pour les processus de décision, c’est à nouveau la simplicité qui prime. Bien sûr, ceci est sans doute une situation temporaire. En gestion, l’adoption des techniques se caractérise souvent par génération de managers, suivant que ceux-ci, lors de leur formation, ont pratiqué oui ou non certaines techniques. Mais ce n’est pas la seule limite de formalismes. Lorsqu’on examine un projet d’organisation, l’on constate que ce type de projet requiert un éventail de techniques et d’aptitudes qui dépassent la modélisation telle qu’on la conçoit aujourd’hui : • des techniques d’extraction de connaissance (interview, séance de brainstorming, enquêtes, • des techniques de mise en évidence des parties intéressées et des circuits d’influence (stakeholder mapping), • des techniques de planification des transitions, • de techniques de gestion du changement, • des techniques de transformation de l’organisation C’est ici notamment que l’on constate certaines limites des modèles de référence qui conçoivent les acteurs humains comme des ressources ayant des capacités d’action, d’analyse, de décision et porteuses de connaissances. Le propre du travail d’organisation est que l’activité de conception d’une nouvelle organisation conduit à un changement de l’objet de la conception. Les acteurs peuvent en même temps concevoir un état futur et faire partie de l’objet de la transformation. D’où l’importance à donner à la gestion du changement dans un processus de réorganisation. La conception d’une organisation et son implémentation est un acte que l’on peut définir comme sociotechnique : il comporte à la fois des composantes techniques et sociologiques, au sens de la sociologie des entreprises. C. Continuité et discontinuité dans la modélisation Suivant les situations, l’utilisation d’un formalisme et/ou d’un outil perdure ou s’arrête après le projet. De toute évidence, c’est lorsque le formalisme, le modèle lui-même ou encore l’outil offrent un service ou une valeur ajoutée au jour le jour, que la probabilité de continuité est la plus grande. C’est le cas notamment pour : • La gouvernance architecturale : le modèle comme référentiel de décision • Les situations où le modèle est largement disséminé et utilisé en pratique, par exemple en gestion de la qualité ou gestion des connaissance : le modèle comme cadre de référence, • Les cas où le modèle sert à piloter un système automatisé comme le workflow où, en cas de changement de processus, le modèle doit être adapté : le modèle comme instrument de pilotage. Les situations de conception pure sont celles où la probabilité de discontinuité est plus grande, surtout si les équipes changent. D. Eléments contextuels Certains éléments de contexte favorisent la mise en place d’une modélisation systématique comme par exemple la règlementation Sarbanes-Oxley qui impose des niveaux de transparence et de conformité en matière de transactions financières ou à impact financier,. Dans le même ordre d’idées la loi Clinger-Cohen aux Etats-Unis a engendré toutes une séries d’actions, par les organismes d’état, dans le domaine de l’architecture informatique et par voie de conséquence dans celui de la modélisation de processus. On peut croire que cette évolution qui se situe encore surtout au niveau des grandes organisations aura des conséquences auprès de leurs partenaires et fournisseurs. Sauf facteurs contraignants externes, une organisation ne passe au stade d’un modélisation systématique qu’à partir où elle acquiert une maturité suffisante en matière de processus (process-minded) : elle doit se voir comme une ensemble de processus reliés entre eux et touchant les clients et les fournisseurs, plus qu’une simple hiérarchie d’unités en charge d’activités sont plus ou moins intégrées. E. L’utilisation des outils Les outils utilisés relèvent de différentes classes : • Des outils de dessin qui n’ont pas été conçus dans le but de la modélisation d’entreprise • Des outils de modélisation de processus avec ou sans base de données centrale • Des outils de type upper-case3 • Des outils de gestion de workflow. Tous ces outils n’ont évidemment pas la même puissance de modélisation et certains peuvent être considérés comme incomplets. Il se pose le problème de la multiplicité des outils utilisés dans des domaines qui se recouvrent : c’est le cas pour la modélisation de processus et la modélisation informatique. Il se pose aussi la question de leur intégration ou du moins, de leur compatibilité et la question de leur spécialisation respective : il faut donc déterminer le domaine propre à chaque outil ainsi que les interfaces entre outils. On en arrive à considérer les outils comme des progiciels avec une problématique similaire : soit l’on opte pour un outil contraignant qui tolère peu de flexibilité par rapport aux formalismes supportés, soit l’on choisit un outil très ouvert mais qui nécessite l’intervention de spécialistes internes ou externes qui en optimalisent la configuration et son utilisation. Chaque option comporte bien sûr ses avantages et ses inconvénients. F. Critères de succès Certains auteurs [7] ont traité de la qualité des modèles en citant notamment : • Le caractère correct de la modélisation • La cohérence • La facilité de compréhension • Le caractère utilisable du modèle. Ces critères sont relativement évidents mais pas toujours aisés à utiliser en vue d’un choix. Sur base de la pratique, l’on y peut ajouter : • L’existence d’une méthodologie qui propose une démarche adaptées aux situations décrites. En conception, l’on est fréquemment confronté à la nécessaire maîtrise de la complexité. Un modèle de référence appliqué systématiquement peut générer en pratique, un modèle fort compliqué et inadéquat car trop détaillé et donc compliqué. D’où le besoin d’une méthodologie qui préconise une démarche de modélisation. • La présence d’un outil permettant d’appliquer correctement le formalisme choisi. • La maturité de l’organisation en matière de processus : faire évoluer cette maturité est souvent le travail de plusieurs années. • La présence au sein de l’organisation d’un promoteur de la modélisation ou d’un décisionnaire qui en voit l’intérêt stratégique. 3 CASE : Computer Aided Software Engineering : développement de logiciel assisté par ordinateur. Upper –case fait référence au fait que ces outils sont utilisée pour la modélisation dans le premières phases du cycle de vie d’un logiciel (conception à haut niveau, fonctionnelle, …) IV. CONCLUSION Quelles conclusions tirer de ces considérations développées, il est vrai, sur une échantillon fort limité ? Une précaution s’impose ici : elle a trait au contraste entre le chercheur et l’organisateur/consultant (interne ou externe) : • Le chercheur est en questionnement continu; à chaque réponse trouvée, il pose de nouvelles questions et espère développer ainsi un ensemble de connaissances ou une théorie apte à expliquer de manière générale un ensemble de phénomènes et sur base d’une série de conditions, de prévoir une situation par déduction. • Le consultant-organisateur a toujours un mandat limité dans le temps et dans l’espace, ainsi que des ressources limitées. La notion d’impact d’un projet, en termes de coûts et de bénéfices, est d’une importance fondamentale. L’organisateur utilise à cette fin des connaissances générales ou théoriques, ainsi que des connaissances particulières, dérivées d’expériences précédentes. Trouver une solution acceptable et spécifique, dans un temps limité, contraste avec la travail du chercheur qui vise la cohérence et l’applicabilité générale dans des contextes multiples. Cette différence de perspective est à prendre en compte lorsqu’il s’agit d’évaluer « l’utilité» des techniques de modélisation et des outils. A. Conclusions quant à la pratique De ces cas pratiques mais aussi d’autres observations faites dans le milieu professionnel, on peut faire un certain nombre de constatations : • La modélisation des processus et des organisations se développe incontestablement et prend une importance croissante, non seulement en termes de « re-engineering » localisé mais aussi au niveau stratégique. Elle se développe sous l’effet de facteurs externes (voir le besoin de conformité ou de transparence) mais aussi parce que les organisations y voient un levier pour un meilleur contrôle et pour une meilleure gestion des performances. • Les modèles et architectures de référence sont relativement peu connus et utilisés par les organisateurs et architectes d’entreprise ou informatiques. La préférence va vers les modèles propres à un domaine. Il peut y avoir des différences par pays et sans doute par domaine d’activité. T.J. Williams et Hong Li font mention d’une utilisation relativement intense de PERA [11]. • Les modèles génériques apparaissent comme (trop) compliqués pour toute une série d’acteurs impliqués dans les processus de modélisation. Il convient donc combiner les techniques de représentation en fonction des besoins de ces acteurs. • Il n’existe pas encore de standard largement diffusé en matière de modélisation d’entreprise. L’interaction formalisée entre organisations comme dans le cas du commerce électronique ou l’administration en ligne peut en favoriser l’émergence. • Modélisation n’est pas conception : la modélisation supporte la conception mais n’en n’est qu’une partie. Les formalismes et méthodologies de modélisation sont à utiliser de concert avec un éventail de modèles et techniques de conception d’organisation et de gestion du changement. • L’utilisation d’un modèle perdure et il est tenu à jour lorsqu’on en a besoin dans pour un processus de gouvernance, soit parce que le modèle a une valeur opérationnelle comme dans le cas du workflow management. • L’introduction d’un formalisme de modélisation et d’un outil en vue d’une utilisation durable exige des efforts considérables et soutenus sur plusieurs années. Elle a rarement un effet considérable à court terme. B. Quelques suggestions de recherche Suite à ces constatations, on peut en déduire une série de besoins et de défis qui peuvent tenter certains chercheurs: • D’abord, développer le sujet de cette contribution de manière plus académique et de manière plus exhaustive et explorer notamment, les aspects sociotechniques de la modélisation. • Compléter les dimensions de la modélisation et prendre en compte l’aspect humain et social des organisations: la plupart des modèles actuels sont limités à ce niveau. • Supporter la gestion de la transformation (passage de l’état actuel à l’état futur) : la plupart modèles ont une capacité de modélisation d’états mais n’offrent guère de support pour la modélisation les transitions possibles (scénarios d’évolution). • Développer la traduction, assistée par ordinateur, de modèles d’un formalisme de représentation en un autre en vue de faciliter la migration d’un modèle à l’autre (récupération d’investissement) et en vue de faciliter l’interopérabilité. En parallèle, viser à standardiser ou du moins créer les fondements d’un langage de représentation neutre par rapport aux outils en vue de faciliter les échanges entre ces outils. • Développer des vues multiples qui représentent les intérêts de parties concernées, avec une forme adaptée, tenant compte de niveaux d’expérience différents des utilisateurs des modèles. • Pour les outils, faciliter les représentations adaptées au type d’utilisateur basées sur une bases de connaissance qui est construite avec un langage de représentation interne qui en assure la cohérence. • Développer des outils qui, sur base de l’analyse automatique de l’état actuel d’une organisation décrit au moyen de divers documents, schémas, modèles antérieurs, formulent des suggestions de structuration de l’organisation et contribuent ainsi au processus de conception. V. REFERENCES Nous mentionnions ici quelques références qui permettent au lecteur intéressé de prendre connaissance en détail avec certains modèles. [1] CIMOSA. CIMOSA - open System Architecture For CIM, 2nd edition. (Springer-Verlag), ISBN 3-540- 56256-7, ISBN 0387-56256-7, Berlin. Voir aussi:http://www.cimosa.de/ [2] G. Doumeingts and D. Chen. State-of-the-art on models, architectures and methodologies, Chapter 4 in "Architecture for Enterprise integration". Edited by P. Bernus, L. Nemes and T. Williams, Chapman & Hall, 1996, ISBN 0-412-73140-1, pp. 32-59. [3] G. Doumeingts, B. Vallespir, D. Chen. Decision modelling GRAI grid. Chapter in: Handbook on architectures of Information Systems, Editors: Peter Bernus, Kai Mertins, Gunter Schmidt, Springer, 1998, pp. 313-337. [4] ETOM. Enhanced Telecom Operations Map® (eTOM) The Business Process Framework For The Information and Communications Services Industry - GB921 v6.0 r6.0.Voir http://www.tmforum.org. [5] FEA: Federal Enterprise Architecture. http://www.whitehouse.gov/omb/egov/a-1-fea.html [6] GERAM: Generalised Enterprise Reference Architecture and Methodology Version 1.6.3. IFIP– IFAC Task Force on Architectures for Enterprise Integration. March 1999. [7] Hommes B. and V. van Reijswoud. 2000. “Assessing the Quality of Business Process Modeling Techniques”. In Proceedings of the 33rd Hawaii International Conference on System Sciences, Vol. 1, 1-10. [8] Interop. http://www.interop-noe.org; [9] Nazzal Dima. Reference architecture of Enterprise Integration. CIMOSA GRAI/GIM PERA. Voir : http://www2.isye.gatech.edu/people/faculty/Leon_McG innis/8851/EIRA [10] PERA : Purdue Enterprise Reference Architecture. http://www.pera.net Pera Integration Web site [11] Theodore J. Williams and Hong Li. PERA and GERAM--Enterprise reference architectures in enterprise integration. http://www.pera.net L’auteur tient à remercier ses collègues de Capgemini (Belgique & Pays-Bas) : Tom Jacobs, Ivan Keuller, Martin Op ‘t Land, Hans Toebak, Freddy Withagels, Johan Witters pour les échanges fructueux sur ce vaste sujet. Il est clair qu’il garde l’entière responsabilité des vues exprimées ici.