Soutenance mémoire
Télécharger le fichier pdf d’un mémoire de fin d’études
Cycle du projet de transformation de l’Entreprise
Pour gagner différents enjeux détaillés ci-après, il convient de mener un (ou plusieurs) projet de transformation. Afin de représenter l’Entreprise, telle qu’elle est « As-is » et telle qu’elle voudrait être « To-be ». Afin de comprendre, voire de simplifier, son fonctionnement complexe, il est recommandé d’élaborer des modèles. Ces modèles sont des représentations partielles de la réalité, mais doivent être bien adaptés au contexte.
Avant de commencer un projet de transformation, il est recommandé [Mamoghli, 2013], d’imaginer des états intermédiaires du système, représentés également par des modèles, afin d’explorer le champ des possibles. On peut alors désirer le système idéal « As-wished », puis le réaliser grâce à des développements sur-mesure, ou choisir un progiciel qui répond au mieux aux besoins exprimés, voire faire des concessions, si ce n’était pas le cas. A l’inverse, il arrive qu’un progiciel dispose de fonctionnalités qui n’ont pas été demandées, mais qui se révèlerait utiles « Might-be ». La Figure 3 représente ces 4 états du système par autant de modèles.
La transformation peut, comme l’amélioration, être considérée comme un processus continu.
Ainsi, le système futur réalisé devient le système existant et l’on peut commencer une nouvelle itération de transformation. C’est une forme de cercle vertueux et il faut profiter de chaque itération pour affiner les modèles, qui deviennent plus précis et qui représentent mieux la réalité.
Architecture d’Entreprise
Définition de l’Architecture d’Entreprise
L’Architecture d’Entreprise est une discipline (ensemble de règles de conduite imposées) qui permet de concevoir l’Entreprise dans ses principaux aspects, du métier à la technique.
L’Architecture d’Entreprise est un des moyens pour mener à bien son projet de transformation (en complément de la conduite du changement et du pilotage).
L’Entreprise doit s’appuyer sur l’Architecture d’Entreprise (composée essentiellement d’une méthode, d’un cadre de représentation et de modèles) pour maitriser sa complexité, puis gouverner sa transformation. Il faut également utiliser des langages ou des notations – si possible standardisés – et des outils, pour élaborer les modèles.
Enjeux de l’Architecture d’Entreprise
L’Architecture d’Entreprise permet de faire face à différents enjeux, aussi variés qu’ambitieux, notamment :
– aligner son Système d’Information sur sa stratégie,
– maitriser la complexité et réduire la complication,
– changer les processus métier pour respecter la règlementation qui évolue,
– augmenter l’efficience et diminuer les coûts,
– lancer un programme de transformation numérique,
– réussir une fusion-acquisition de sociétés pour agrandir leur périmètre,
– réduire au contraire le périmètre des activités, voire les effectifs,
– maitriser les évolutions technologiques,
o profiter des nouvelles technologies
o gérer l’obsolescence des anciennes technologies,
– communiquer efficacement le projet de transformation entre les différents partis.
L’architecture de l’Entreprise doit avant tout être alignée sur sa stratégie. Mais, la mise en place de l’Architecture d’Entreprise peut, voire doit, faire partie de la stratégie de l’Entreprise (« Enterprise Architecture as Strategy » [J. W. Ross et al., 2006]) et constitue elle-même un enjeu majeur.
Différents types d’alignements
L’Architecture d’Entreprise peut être décomposée en amont en Architecture Métier (son offre de produits et de services, son organisation, ses processus, ses règles, ses décisions, etc.) et en aval en Architecture Technique (un ensemble cohérent de logiciel et de matériel, pour ne citer que les deux composantes qui concernent son Système d’Information ; de la logistique de façon plus générale).
L’Architecture Technique met à disposition de l’Entreprise les ressources nécessaires lui permettant d’exercer les activités définies par l’Architecture Métier. Idéalement, l’Architecture Technique doit donc être parfaitement alignée sur l’Architecture Métier, elle-même préalablement alignée sur la Stratégie de l’Entreprise, mécanisme connu sous le nom d’Alignement Stratégique [Henderson et Venkatraman, 1992].
Architecture d’Entreprise et Urbanisation
L’Architecture d’Entreprise est une discipline qui a commencé à partir des années 1990 aux Etats-Unis d’Amérique, puis s’est développée à travers le monde, les pays anglo-saxons d’abord, puis les autres.
A la même période, en France, la discipline similaire était l’Urbanisation, une métaphore de l’aménagement des villes appliquée aux Systèmes d’Information. Bien que le terme Architecture d’Entreprise ait tendance désormais à supplanter le terme Urbanisation, des différences existent entre ces deux disciplines, mais elles restent très proches [Longépé, 2009].
Ces deux disciples partagent notamment le même objectif d’accroitre l’agilité du Système d’Information [CIGREF, 2003]. Le Club Urba-SI (SI comme Systèmes d’Information) créé en 2000, qui regroupe des urbanistes et des architectes de grandes entreprises françaises, a été renommé en Club Urba-EA (EA comme Enterprise Architecture) en 2006, afin de suivre cette tendance globale.
Besoin d’une méthode
Une méthode doit répondre à la question « Comment faire ? » en indiquant notamment des actions ordonnées à exécuter et des règles à respecter pour atteindre un but. Elle doit y répondre de manière suffisamment précise, par étapes successives, afin que la façon de faire soit identique à chaque utilisation et garantisse le même résultat.
Une méthode peut s’appuyer sur une ou plusieurs théories. Elle constitue alors la mise en pratique de cette théorie. Une méthode doit être documentée, voire si possible outillée si la façon de faire est complexe. Elle peut être décomposée en processus, en procédures et en procédés ou modes opératoires. Une méthode permet également d’apprendre une science ou une technique, de transmettre la connaissance, voire de s’imposer une discipline, comme celle de l’Architecture d’Entreprise.
Dans notre cadre d’étude, une méthode doit notamment appliquer des principes et des règles d’architecture sur son cadre de représentation et des principes et des règles de modélisation, mais aussi de transformation, sur ses différents modèles.
Une méthode d’Architecture d’Entreprise doit permettre de prendre et de justifier des décisions. Nous présenterons plus loin les différents types de décisions. Les décisions d’architecture, celles qui sont prises en appliquant la méthode, sont généralement de type tactique. Procéder avec méthode reste le meilleur moyen de prendre les bonnes décisions.
Besoin d’un cadre de représentation
L’Architecture d’Entreprise s’appuie sur un cadre de représentation (framework) qui est constitué d’un socle de référence (idéalement, un métamodèle, c.-à-d. un modèle générique pour les modèles spécifiques de l’Entreprise), sur lequel une méthode plus ou moins aboutie peut être élaborée. Un cadre de représentation permet d’organiser la perception de l’Entreprise.
Selon les bonnes pratiques, un cadre idéal devrait respecter certains principes comme :
– la focalisation sur l’Entreprise,
– la prise en compte de toute sa réalité (approche holistique),
– l’unicité de tout élément à l’intérieur du cadre (et son corollaire, le bannissement de la redondance).
Besoin de modèles
Modélisation d’Entreprise
Modéliser l’Entreprise dans sa globalité, afin d’expliciter sa structure et son fonctionnement complexe, c’est un des buts de l’Architecture d’Entreprise. Un modèle peut servir également à analyser son comportement, voire estimer les performances de l’Entreprise via la simulation.
Enfin, un modèle peut servir d’aide à la décision, lors de son exploitation. Les modèles permettent aussi de proposer des points de vue différents, mais cohérents, de l’Entreprise, adaptés à chacun, qu’il soit spécialiste métier, informaticien ou autre. Ils fournissent une représentation consensuelle et partagée de l’Entreprise.
Les modèles ont rarement une représentation graphique uniquement : ils sont généralement représentés par des diagrammes (notation graphique) et du texte. Certains langages, comme BPMN, séparent bien le modèle (les objets à représenter) de sa représentation graphique (les symboles qui représentent ces objets et leur disposition sur un écran ou sur un page). Ainsi, modifier la disposition des symboles de la représentation graphique ne modifie le modèle.
Afin de représenter et comprendre l’Entreprise sous tous ses aspects, les besoins de représentation par des modèles sont multiples. On voudrait représenter depuis longtemps sa mission, ses objectifs, sa stratégie, ses activités sous forme de processus métier, son vocabulaire, ses règles métier voire ses contraintes, l’organisation de ses ressources, humaines notamment, son offre de produits et de services et leurs cycles de vie, la structure de ses données, les flux physiques et les flux d’information (liste non limitative). La représentation des prises de décision est un besoin plus récent, qui est exprimé depuis une dizaine d’années seulement, et qui sera développée dans la suite de ce mémoire.
Utilité, utilisabilité et utilisation d’un modèle
Tout le monde s’accorde à dire qu’un modèle est utile : ce postulat de départ ne sera pas démontré. Il faut toutefois que l’objectif du modèle fasse partie des questions préliminaires à la modélisation, afin de justifier son utilité.
Il faut également qu’un modèle soit si nécessaire utilisable. Par exemple, un modèle représentant un processus métier, avec un fort niveau de détail, peut devenir exécutable. C’est le meilleur moyen pour s’assurer que le modèle représente bien la réalité (ou bien éventuellement que la réalité soit alignée sur le modèle).
Enfin, à chaque utilisation d’un modèle dans le monde réel, une instance est créée (l’instance est l’action de créer un « objet » à partir d’un modèle). Idéalement, on devrait pouvoir compter le nombre d’instances d’un modèle, c.-à-d. mesurer son utilisation réelle, pour piloter efficacement les opérations. Par exemple, il sera intéressant de compter combien d’instances il y a eu du modèle de processus métier « Traitement d’une commande », car ce comptage indiquera le nombre de commandes traitées.
Principes de modélisation
Toute démarche d’Architecture s’appuie sur la modélisation de l’Entreprise et ses principes :
– la cohérence des modèles,
– la mise en relation des éléments les uns avec les autres,
– l’aide à la transformation d’un modèle vers un autre,
– l’existence d’un métamodèle de référence.
Pyramide de modélisation
(Bon) Modèle
Un bon modèle doit représenter au mieux une partie du monde réel. Une seule classe d’objets dans un modèle peut représenter des millions d’objets (alias des instances) dans le monde réel.
De manière plus précise, [Brackett, 1990] nous indique les avantages d’un bon modèle :
(1) réduit le niveau de complexité et doit être compris du premier coup,
(2) est plus économique à construire et à modifier qu’un système réel,
(3) facilite la description des aspects complexes d’un système réel.
Certains auteurs préfèrent parler de modèles pertinents (relevant). Nous avons toutefois vu des modèles qui semblaient pertinents (vus du modélisateur), mais qui étaient loin d’être compris par tous. D’autres auteurs encore parlent de truthful models. Les traductions en français de « truthful » sont multiples, mais la plupart de ces traductions correspondent bien aux qualités d’un « bon » modèle : véridique, honnête, vrai & fidèle. Il y a quand même de bons modèles qui simplifient délibérément la réalité, afin de faciliter sa compréhension.
Voici une liste de 7 critères pour tenter de qualifier un bon modèle [Mader et al., 2007] :
– Il a un objet de modélisation clairement spécifié,
– Il a un objectif clairement spécifié,
– Il est simple,
– Il est véridique,
– Il est traçable,
– Il est extensible et réutilisable,
– Il est conçu pour l’interopérabilité et le partage.
Tandis que les 4 premiers critères génériques concernent tous les domaines métier, les 3 derniers critères répondent précisément à des besoins dans le domaine de l’Architecture d’Entreprise, qui nous intéresse ici :
Traçabilité : chaque élément du modèle doit correspondre à un aspect précis de l’objet de modélisation et cette relation bidirectionnelle doit être clairement documentée. Si la traçabilité est assurée, cela permet d’envisager notamment la transformation d’un modèle vers un autre. Extensibilité et réutilisabilité : il y a rarement une seule version d’un modèle. Celui-ci doit pouvoir évoluer. C’est même indispensable quand un modèle sert de base à l’automatisation d’une activité et qu’un changement s’avère nécessaire. Quant à la réutilisabilité, il s’agit de capitaliser les modèles existants, rangés dans le cadre de représentation de l’Entreprise.
Interopérabilité et partage : il est recommandé qu’un modèle réalisé respecte un formalisme standard, afin de faciliter sa compréhension et son partage. L’étymologie de « standard » nous apprend que ce mot vient de « étendard », qui sert de point de ralliement, et cette métaphore semble adaptée pour un bon modèle. Le choix d’un formalisme standard permet généralement d’échanger les modèles entre des outils différents, grâce à des fonctionnalités d’export puis d’import : c’est un cas concret d’interopérabilité.
Métamodèle
Pour respecter rigoureusement ce formalisme standard, ce modèle (le plus souvent représenté par un diagramme) doit être conforme à un métamodèle (rappel : modèle générique pour les modèles spécifiques). Ainsi un diagramme de collaboration pour représenter un processus métier doit être conforme au métamodèle BPMN (Business Process Model and Notation) et un diagramme des exigences pour représenter une prise de décision doit être conforme au métamodèle DMN (Decision Model and Notation), comme représenté sur la Figure 4.
|
Table des matières
1 Introduction Générale
2 Contexte
2.1 Transformation de l’Entreprise
2.1.1 Trajectoire de transformation de l’Entreprise
2.1.2 Cycle du projet de transformation de l’Entreprise
2.2 Architecture d’Entreprise
2.2.1 Définition de l’Architecture d’Entreprise
2.2.2 Enjeux de l’Architecture d’Entreprise
2.2.3 Différents types d’alignements
2.2.4 Architecture d’Entreprise et Urbanisation
2.2.5 Besoin d’une méthode
2.2.6 Besoin d’un cadre de représentation
2.2.7 Besoin de modèles
2.2.7.1 Modélisation d’Entreprise
2.2.7.2 Utilité, utilisabilité et utilisation d’un modèle
2.2.7.3 Principes de modélisation
2.2.7.4 Pyramide de modélisation
2.2.7.4.1 (Bon) Modèle
2.2.7.4.2 Métamodèle
2.2.7.4.3 Métamétamodèle
3 Problématique
3.1 Modélisation des processus métier
3.1.1 Approche processus généralisée
3.1.2 Représentation d’un processus métier
3.2 Modélisation des prises de décisions
3.2.1 Prises de décisions à différents niveaux
3.2.2 Principaux Types de Décisions
3.2.3 Impacts des décisions stratégiques-tactiques et opérationnelles
3.2.4 Prises de décisions humaines versus automatisées
4 Etat de l’Art
4.1 Méthodes et cadres de représentation pour l’Architecture d’Entreprise
4.1.1 Périmètre de l’état de l’art
4.1.2 Zachman Framework
4.1.3 CIMOSA
4.1.4 GERAM
4.1.5 Standards ISO pour l’architecture et la modélisation
4.1.5.1 ISO 14258-15704-19439-19440
4.1.5.2 ISO 42010
4.1.6 UEML
4.1.7 TOGAF®
4.1.8 CIGREF
4.1.9 CHAMPS2
4.1.10 Praxeme
4.1.10.1 Présentation de la méthode publique
4.1.10.2 Topologie du Système Entreprise
4.1.10.2.1 Les 7 Aspects de Représentation de l’Entreprise
4.1.10.2.2 Les 4 Aspects de l’Architecture Métier
4.1.10.2.3 Les 3 Aspects de l’Architecture Technique
4.2 Modélisation d’Entreprise
4.2.1 Différents Besoins de Modélisation d’Entreprise
4.2.2 Modélisation des processus métier
4.2.2.1 Représentation des macro-processus
4.2.2.2 Diagramme d’activité UML
4.2.2.3 BPMN (Business Process Model and Notation)
4.2.2.3.1 Diagramme de collaboration
4.2.2.3.2 Limitation pour la représentation des prises de décisions
4.2.2.3.3 Exemple de Modélisation BPMN sans DMN
4.2.2.4 Autres notations pour représenter les processus métier
4.2.2.4.1 EPC (Event-driven Process Chain)
4.2.2.4.2 ArchiMate
4.2.3 Modélisation des décisions
4.2.3.1 Décisions et Règles métier dans les Cadres de Représentation
4.2.3.2 Décisions et Règles métier dans la modélisation d’entreprise
4.2.3.3 GRAI
4.2.3.3.1 GRAI, une méthode globale
4.2.3.3.2 Partie décisionnelle de la méthode GRAI
4.2.3.3.3 Grille GRAI
4.2.3.3.4 Réseau GRAI
4.2.3.4 TDM (The Decision Model)
4.2.3.5 DMN (Decision Model and Notation)
4.2.3.6 Autres langages et notations pour représenter les règles métier
5 Proposition de Solution
5.1 Séparation des préoccupations
5.2 Evolution de l’Architecture des Applications Métier
5.3 Bouquet de standards de l’OMG
5.3.1 Cartographie des principaux standards
5.3.2 Langage versus Notation
5.3.3 BMM
5.3.4 SBVR
5.3.5 BPMN
5.3.6 CMMN
5.3.7 DMN
5.3.8 BPMN + CMMN + DMN
5.4 Modélisation des décisions avec DMN
5.4.1 DRD (Decision Requirements Diagram)
5.4.1.1 Quatre éléments graphiques principaux
5.4.1.2 Trois types de liens différents
5.4.1.3 Exemple de diagramme DRD
5.4.1.4 Extrait du métamodèle DMN
5.4.2 Modélisation des Règles Métier
5.4.2.1 Différentes Façons d’Exprimer la Logique de Décision
5.4.2.2 Représentation des Tables de Décision
5.4.2.3 Deux Propriétés Cruciales des Tables de Décision
5.4.2.3.1 Complétude et Cohérence
5.4.2.3.2 Complétude d’une Table de Décision
5.4.2.3.3 Cohérence d’une Table de Décision
5.4.2.4 Politiques de Succès des Tables de Décision
5.4.3 Autres éléments de DMN
5.4.3.1 Modèle interchangeable DMN 1.1 XML
5.4.4 Complémentarité de DMN avec BPMN
5.4.4.1 Relation forte, mais implicite
5.4.4.2 Tâche Business Rules avec branchement
5.4.4.3 Tâche Business Rules sans branchement
5.4.5 Contrôle Qualité d’un modèle DMN
5.4.6 Positionnement de DMN dans la méthode Praxeme
5.4.6.1 Rappel des aspects métier de la méthode Praxeme
5.4.6.2 Positionnement des Diagrammes DRD
5.4.6.3 Traitement et positionnement des Règles métier
6 Validation de la Solution
6.1 PoC (Proof of Concept)
6.2 Etude de cas
6.2.1 DRD (Decisions Requirements Diagram)
6.2.1.1 Relation implicite avec le diagramme BPMN
6.2.1.2 Représentation en notation DMN retenue
6.2.1.3 Alternatives de représentation possibles
6.2.2 Tables de décision
6.3 Méthode pour comparer les solutions
6.3.1 MDA (Model Driven Architecture)
6.3.2 Trois modèles CIM, PIM & PSM
6.3.3 Projection de DMN sur les modèles MDA
6.4 Démonstrateur pour l’automatisation des décisions
6.4.1 Composants du démonstrateur
6.4.1.1 Deux outils principaux
6.4.1.2 Modeleur DMN sur mesure
6.4.1.3 Modeleur DMN standard
6.4.1.4 Moteur de règles
6.4.1.5 Autres outils
6.4.2 Paradigmes de programmation
6.4.2.1 Changement de paradigme de programmation
6.4.2.2 Programmation impérative
6.4.2.3 Programmation déclarative
6.4.3 Première solution spécifique : du CIM au PSM (sans PIM)
6.4.3.1 Principe de la solution spécifique
6.4.3.2 Déclaration simplifiée des données
6.4.3.3 Déclaration des règles métier
6.4.3.4 Application des règles métier
6.4.4 Deuxième solution générique : du CIM au PIM (sans PSM)
6.4.4.1 Principe de la solution générique
6.4.4.2 Application des règles métier
6.4.5 Troisième solution intégrée : le CIM uniquement
6.4.6 Comparaison des trois solutions
7 Conclusion et Perspectives
7.1 Conclusion
7.1.1 Approche complète, de bout en bout
7.1.2 Modélisation des prises de décisions adaptée
7.1.3 Automatisation des prises de décisions possible
7.1.4 De l’intérêt de s’appuyer sur un langage standard
7.1.5 Méthode, langage et outils
7.2 Perspectives
7.2.1 Solution indépendante des moteurs de règles
7.2.2 Evolutions attendues de DMN
7.2.3 Solveur de contraintes
7.2.4 Formalisation des règles de l’Architecture d’Entreprise
8 Bibliographie et autres Références
Télécharger le rapport complet
