Pour comprendre une approche multi-modèle, il est nécessaire de commencer par comprendre son contexte. Selon les outils et les objectifs des projets de modélisation des processus, cette approche peut être tout à fait adaptée ou au contraire pas du tout

Commençons peut être par définir ce qu’est « un modèle » ou encore « un référentiel » ou pour d’autres un « méta-modèle ».

Dans le cadre d’une démarche de modélisation, nous modélisons ou représentons des entités, des individus ou des machines de manière à pouvoir nous les représenter de manière synthétique et souvent graphique. Ces « instances » portent des caractéristiques enrichis à partir de données réelles. Nous modélisons donc la réalité pour la représenter sous une forme schématisée et simplifiée.

Il faut bien comprendre cependant que le modèle doit permettre de représenter la réalité, ainsi, un individu est unique tout comme les entités ou une machine, mais un individu ne peut être confondu à une machine, il est donc évident que le modèle différencie les types d’instances qu’il contient et peut même les catégoriser.

Ce que nous appellerons un modèle est donc  une représentation logique de la réalité.

Une approche multi-modèle consiste donc à « diviser » cette réalité selon des critères objectifs dans le but d’enrichir le référentiel le plus efficacement possible. Ces critères peuvent être définis selon des contraintes géographiques, opérationnelles ou organisationnelles en prenant en compte la politique et la culture de l’entreprise.

Objectifs d’une telle approche

La mise en place d’une démarche multi-modèle doit répondre à un besoin et à des objectifs précis. Ce type d’approche est toujours plus complexe qu’une démarche « mono-modèle ». Elle doit être réfléchie et murie. De manière générale, il est conseillé de démarrer les projets avec un modèle unique avant de basculer vers une démarche multi-modèle. Lorsque le projet aura atteint une maturité suffisante et qu’au moins un des besoins décrits dans la suite de cet article s’est manifesté, il faut commencer sérieusement à réfléchir à une démarche multi-modèle.

                Optimisation du temps et des ressources

Les contraintes les plus souvent rencontrés dans tout projet sont bien entendu les contraintes de temps et de ressources. Si dans votre projet de modélisation ces contraintes sont importantes, adopter une approche multi-modèle peut permettre paralléliser les tâches de modélisations.

Cependant, dans la mesure où cela est techniquement possible, il faut préférer un travail collaboratif directement dans un modèle unique au travers d’un référentiel accessible par l’ensemble de l’équipe en même temps. Les tâches de modélisation peuvent ainsi être répartit de manière plus souple et plus flexible.

Dès lors que la mise en place d’un référentiel central est impossible et que la parallélisassions des tâches est nécessaire à la réussite du projet, il est important de réfléchir aux critères de division du périmètre de modélisation. Dans ce contexte, ces critères seront le plus souvent fonctionnels afin d’obtenir des sous-périmètres le plus cloisonnés possibles. Nous traiterons l’impact de ces différents critères sur la gestion des différents modèles tout au long de l’article.

                Multilinguisme

Il existe aujourd’hui différentes façons de gérer le multilinguisme pour une même information. Les différents éditeurs de logiciel de modélisation ont souvent chacun choisis une philosophie qu’ils ont défendue ardemment pendant des années avant que le bon sens et le pragmatisme ramènent tout le monde à la raison.

Effectivement, si nous revenons à notre définition, un modèle représente des instances uniques, autrement dit le serveur MX00987 n’existe qu’une seule fois dans notre modèle même s’il est représenté dans différents contextes. Or, si nous voulons gérer le multilinguisme, cela signifie que le serveur se dénommera « serveur » en français, « server » en anglais, allemand et néerlandais ou encore « distribuidor» en espagnol, il n’en reste pas moins unique. Il parait donc logique que l’instance unique porte elle-même les variantes linguistiques la caractérisant.

Ceci dit, il ne faut pas oublier qu’un modèle a de manière consensuelle le but d’unifier la communication au sein de l’entreprise où comment parler une seule langue dans différents dialectes. Il est alors opportun de se demander si une langue, souvent l’anglais, ne fait pas référence par rapport aux autres ?

La gestion multi-modèle ne se justifie dans ce contexte que par la volumétrie des modèles ou par le volume des informations qu’il contient. En effet, le multilinguisme répondant à un objectif de communication, disposer d’un modèle pour chaque langue utilisée dans l’entreprise, parfaitement synchronisés entre eux, ne peut que suivre le même objectif. Ces derniers doivent être suffisamment conséquents pour justifier une communication ciblée dans chaque langue.

                Approche locale ou organisationnelle

La gestion multi-modèle peut également se justifier par la dimension locale des informations contenues dans le modèle. En effet, les critères de différentiations peuvent très souvent se baser sur des données géographiques ou organisationnelles telle qu’une division particulièrement importante ou encore une filiale locale.

Ainsi la division ou la filiale maintiendra et enrichira un modèle qui lui sera dédié tout en se fondant dans une gestion multi-modèle permettant une cohérence d’ensemble dans l’entreprise.

La gestion multi-modèle se prête naturellement à ces situations qui mobilisent et responsabilisent tout une division de l’entreprise en les impliquant directement dans le périmètre qui les concernent et donc qui les intéressent le plus.  Cette démarche doit cependant s’effectuer avec rigueur.

Il est temps maintenant de définir de quelle manière nous pouvons organiser nos différents modèles entre eux.

Les relations entre les différents modèles

                Une approche « hiérarchique »

Une approche dite « hiérarchique » consiste, comme son nom l’indique, à définir des relations hiérarchiques entre les modèles. Le plus souvent l’approche hiérarchique propose de définir un modèle maitre qui fait référence.

Les autres modèles se résument à une duplication de tout ou partie du modèle maitre. Les modifications des modèles fils ne sont jamais remontées dans le modèle maitre. Au contraire, toutes les modifications réalisées dans le modèle maitre impactent automatiquement l’ensemble des modèles fils.

Cette démarche à l’avantage d’être plus simple à mettre en place que sa concurrente l’approche « à plat ». Néanmoins, il est difficile dans cette approche de trouver des réponses suffisantes aux besoins identifiés plus tôt.

                Une approche « à plat »

Une approche à plat, contrairement à une approche hiérarchique, mets l’ensemble des modèles sur un pied d’égalité. Ainsi, tous changement dans l’un des modèles impactent directement l’ensemble des modèles du réseau.

Cet impact peut se faire de deux manières, soit de manière synchrone, soit de manière asynchrone. En fonction des outils et des éditeurs, l’une ou l’autre est possible. Synchroniser « en temps réel » nécessite des ressources importantes, mais en même temps, laisser les différents modèles diverger trop longtemps peut avoir des conséquences dramatiques.

Là encore tout dépend du projet, choisir la manière synchrone nécessitera de définir rapidement et de manière transparente les règles d’arbitrages des conflits. La manière asynchrone laissera plus de place à la réflexion lorsqu’apparaîtrons les conflits.

Dans les deux cas, si l’on choisit une approche « à plat », il faut clairement spécifier les règles de gouvernance métier avant de basculer sur ce genre d’approche. Typiquement, en cas de conflits de nom ou de description, qui fait foi ? La version du département vente ou la version du département marketing ? D’où l’importance de mettre en place des processus de conciliation et d’arbitrage. Dans tous les cas, il ne faut jamais hésiter, dans la mesure du possible, à faire appel aux possibilités de personnalisations et d’automatisation des éditeurs. Celui qui proposera des API ouverte et flexible sera le plus adapté pour cette démarche.

Quel que soit la démarche et l’approche choisie, vos modèles font partie d’un seul réseau qu’il vous faudra gérer. Et comme tout réseau, celui-ci se base sur des constantes, des repères, autour desquels vous organiserez votre gestion du quotidien.

Les repères permettant une gestion multi-modèle

                La structure

Le premier élément que nous allons expliciter est un pré-requis indispensable pour pouvoir mettre en place une démarche multi-modèle. Il s’agit bien entendu de la structure, du squelette de vos modèles, en d’autres termes du « méta-modèle ».

Il est évident que pour pouvoir communiquer entre eux les différents modèles doivent avoir des points communs. La structure des différents modèles doit donc être commune, du moins en partie. Dans ce dernier cas, la gestion des différents modèles se limitera, dans la pratique, à la gestion de la « sous partie » du modèle dont la structure est commune aux autres modèles.

Les « Objets Types » (et « Associations types » qui définissent les relations entre eux) sont donc vos premiers repères dans une démarche de gestion multi-modèle. Contraignez vous au maximum dans la mesure du possible à conserver des modèles avec une structure générale identique. Cette remarque est valable quelque soit le type d’approche choisie.

                Le contenu

Une gestion multi-modèle doit nécessairement délimitée un contenu spécifique et distinct pour chacun des modèles. Il est important ici que le contenu soit différent du périmètre de modélisation du modèle : deux modèles peuvent très bien modéliser les mêmes processus d’un même département dans deux langues différentes. Le multilinguisme est un exemple typique de contenu différent dans un même périmètre de modélisation.

Il est également important de distinguer le contenu ou les informations qui enrichissent le modèle des diagrammes qui la composent. Ainsi les diagrammes sont la partie immergée de l’iceberg. En effet, le résultat le plus visible de votre travail est la modélisation mais une gestion multi-modèle peut se justifier par des contenus différents avec une modélisation strictement identique dans tous les modèles. Ce cas est rare, je le conçois, mais il permet de bien comprendre que la gestion du contenu est aussi importante que la modélisation graphique.

La gestion de ce contenu est bien entendu spécifique à chaque projet, mais de la même manière que votre structure réponde à des règles qui permettent de conserver une cohérence entre les modèles, votre contenu doit répondre à des règles de gestion communes à l’ensemble des modèles. Ces « règles de cohérences et de consistances » doivent être définies en amont et mise à jour de manière itérative au fur et à mesure de l’avancement du projet.

Une analogie de ces règles peut être faite pour la gestion des diagrammes des différents modèles avec néanmoins quelques variantes.

                La modélisation

Tout comme pour la gestion du contenu, la gestion de la modélisation doit répondre à une gestion rigoureuse dès lors qu’elle est répartie entre plusieurs modèles.

En effet, la première étape est de définir le périmètre de modélisation graphique de chaque modèle, trois choix s’offre alors à nous :

·         Tous les diagrammes seront strictement identiques sur tous les modèles.

·         Chaque modèle contient ses propres diagrammes qui lui sont spécifique.

·         Une approche hybride, certains diagrammes sont identiques sur tous les modèles, d’autres sont spécifiques.

Le premier cas représente l’approche type « Maitre-Esclave ». Il faut donc définir quel modèle contient les diagrammes de références et tous les autres modèles seront impactés par les modifications effectuées sur le modèle maître.

Dans le second cas, il est nécessaire de définir les règles de cohérences et de consistances graphiques afin que l’ensemble garde une cohérence. L’analogie avec la gestion du contenu peut être faite.

Enfin le troisième cas doit combiner les deux approches précédentes, elle est donc, de fait, plus compliquée à mettre en place.

La gestion du projet autour des contraintes d’une gestion multi-modèle

Nous avons bien compris désormais les différentes typologies de projets et les différentes contraintes rencontrées lors de la mise en place d’une approche multi-modèle. Essayons désormais de résumer les différents outils à notre disposition pour réussir.

                Les contraintes sur le projet

Afin de faire face aux contraintes inhérentes aux projets, des actions doivent être mises en place autour de deux éléments essentiels : la méthodologie et la gouvernance.

                                La méthodologie

Il est nécessaire de définir la méthodologie de modélisation, autour ou non d’un framework, mais impérativement il faudra définir :

·         Les règles de correspondances graphiques et leurs significations. Cet élément est particulièrement important pour bien comprendre les diagrammes qui seront modélisés et pouvoir les communiquer ensuite au sein de l’entreprise. Ces règles doivent être intuitives au possible.

·         Les règles de modélisations et de nommages. Il est important de définir des règles de nommage pour les éléments modélisés en fonction de leur contexte (verbe à l’infinitif pour une action, participe passé pour un évènement par exemple). Il est également important de définir dans quel mesure les instances, qui rappelons le sont unique au sein du modèle, seront représentés sur les diagrammes (pas plus d’une instance à la fois, toujours représenté avec la même couleur, par exemples). Ces règles permettront de garder un ensemble graphique logique et cohérent au sein des différents modèles.

                                Les workflows de gouvernance

Comme pour tout projet, il est nécessaire d’établir un certains nombres de règles de gestions. Afin de pouvoir en assurer le respect et ainsi s’assurer de la bonne marche du projet. Un certain nombre de processus de gouvernance doivent donc être mis en place.

Ces règles de gestion être élaborées en fonction des périmètres de chacun des modèles :

·         Que dois-je faire si je dois modifier une donnée centralisée qui impact l’ensemble des modèles ?

·         Comment puis-je démarrer une nouvelle initiative qui implique la création d’un nouveau modèle ?

·         Qui dois-je contacter pour effectuer une modification ou faire parvenir une remarque ?

·         Comment réaliser les objectifs qui ont été assignés à mon équipe ?

·         Etc…

On remarque que les règles de gouvernance répondent à l’ensemble des questions d’organisation interne des équipes de modélisations au-delà de la gestion elle-même du réseau de modèles.

Enfin, il faut dans la mesure du possible, toujours chercher à automatiser ces processus qui deviennent ainsi ce qu’on appelle des « workflows ». Automatiser un processus en workflow obligera l’équipe centrale à réfléchir de manière très opérationnelle à la gouvernance et permettra à la fois de commencer le projet sur des bases solides et d’optimiser le temps passé à gérer le côté opérationnel du projet.

                Les contraintes sur le modèle

                                La structure

Nous l’avons déjà évoqué, mais ce point est particulièrement important : la structure de l’ensemble des modèles doit impérativement être aligné en permanence, faute de quoi la gestion des modèles sera de plus en plus difficiles avant de devenir impossible.

                                Les données (la cohérence)

De la même manière que les modèles doivent être cohérents au niveau de la structure. Les données et informations contenues dans les différents modèles doivent garder une cohérence. Cette cohérence doit se retrouver dans tous les objets manipulés et fait donc partie intégralement de la méthodologie à mettre en place dans un système multi-modèle.

Il s’agit bien entendu de la façon de décrire les différents objets mais également des règles de « dessin » des diagrammes ou encore des règles permettant de définir les différents regroupement et filtres permettant de retrouver une information.

La cohérence des données implique également d’éviter des erreurs qui pourraient avoir de grave conséquences lors de l’analyse des informations modélisées : éviter les doublons, éviter de confondre des objets méthodologiques, tels que les organisations et les rôles ou encore éviter qu’une relation jamais modélisée ne soit jamais renseignée.

Ainsi, ces règles, dites de cohérences et de consistances, vont nous permettre de garder une homogénéité dans l’ensemble des informations réparties dans les différents modèles et ainsi faire rayonner une image cohérente, ambitieuse et positive de votre projet.