Développement applicatif Gestion de projet

Modèles de maturité : un outil pour décrire le présent et prévoir le futur

Publié le 22/04/2022 Par Gabriel Da Silva Serapiao Leal

Présentation de A à Z des modèles de maturité : différents niveaux, étapes à prendre en compte, exigences à respecter, principes de construction, conseils d’utilisation… On vous dit tout !

Un modèle de maturité propose différents niveaux de maturité, décrivant les étapes par lesquelles les systèmes doivent évoluer. Ce type de modèle permet aux entreprises d’identifier leurs forces et leurs faiblesses en termes de caractéristiques clés : interopérabilité, sécurité, agilité, etc. L’objectif est de prévoir et/ou de diagnostiquer les problèmes potentiels et de hiérarchiser les actions nécessaires pour les résoudre. Présentation globale du concept de modèle de maturité dans cet article.

Plus concrètement, les modèles de maturité sont généralement conçus pour évaluer une ou plusieurs caractéristiques clés. Ils proposent des niveaux qui décrivent les diverses étapes par lesquelles les systèmes devraient évoluer pour tendre vers l’excellence dans la réalisation d’un objectif donné.

croissance de plantes

qu’est ce qu’un modèle de maturité ?

Selon de Bruin et Becker, les modèles de maturité peuvent servir à trois fins différentes, comme décrit ci-dessous :

  • Descriptive : compte tenu de l’objectif descriptif, des modèles de maturité sont utilisés pour évaluer l’état des systèmes concernés. Ils servent de base à l’analyse des capacités actuelles du système par rapport à un ensemble de critères prédéterminés. Un modèle descriptif peut être utilisé comme outil de diagnostic.
  • Prescriptive : en ce qui concerne l’objectif prescriptif, des modèles sont utilisés pour identifier les étapes permettant d’atteindre un niveau de maturité plus élevé. Sur la base des résultats des évaluations, les modèles fournissent alors des conseils et des bonnes pratiques pour l’amélioration du système.
  • Comparative : concernant la finalité comparative, un modèle de maturité sert à un benchmarking interne ou externe. Avec suffisamment de données historiques, les niveaux de maturité d’organisations similaires peuvent être comparés.

Concernant leur structure, les modèles incluent un nombre fixe de niveaux de maturité génériques, généralement autour de cinq. Chaque niveau de maturité est associé à plusieurs processus (également appelés pratiques) qui doivent être mis en œuvre.

Cependant, la plupart des modèles de maturité manquent de définition formelle de leurs critères et nécessitent un haut niveau d’expertise pour être appliqués dans un contexte industriel. Une manière de formaliser les frontières entre chaque niveau de maturité repose sur l’utilisation de mesures quantitatives (valeurs numériques caractérisant les interopérations entre systèmes).

La section suivante décrit la méthodologie de développement d’un modèle de maturité.

Une méthode de développement du modèle de maturité : domaine de l’informatique

Sur la base du Design Science Research (DSR), Becker définit une procédure de développement d’un un modèle de maturité axée sur la gestion informatique. Les auteurs ont également proposé huit exigences qui doivent être remplies pour réussir à construire un modèle de maturité.

Le tableau 1 présente les trois phases simplifiées du DSR. Le tableau 2 quant à lui liste les huit exigences proposées par Becker. Finalement, la figure 1 illustre les exigences liées à chaque phase du DSR.

Tableau 1. Phases de développement d’un modèle de maturité

PhaseDescription
ConceptualisationDéfinition du public concerné, de la couverture des zones d’interopérabilité, du type d’évaluation et des contextes applicatifs abordés. Une comparaison des modèles existants fait également partie de cette phase.
DéveloppementDéfinition des critères d’évaluation sur la base des exigences d’interopérabilité ; Définition des méthodes de notation, c’est-à-dire (a) les méthodes utilisées pour étayer la notation des critères ; (b) la méthode d’agrégation à utiliser lorsqu’il y a plus d’un évaluateur ; et (c) la méthode de détermination du niveau de maturité.
Application / ÉvaluationCela se fait en l’appliquant dans une étude de cas.
Tableau 1. Phases de développement d’un modèle de maturité

ExigenceDescription
R1 (Comparaison avec les modèles de maturité existants)La nécessité de développer un nouveau modèle de maturité doit être justifiée par une comparaison avec les modèles existants. Le nouveau modèle peut aussi n’être qu’une amélioration d’un modèle déjà existant.
R2 (Procédure itérative)Les modèles de maturité doivent être développés de manière itérative, c’est-à-dire étape par étape.
R3 (Évaluation)Tous les principes et prémisses pour l’élaboration d’un modèle de maturité, ainsi que l’utilité, la qualité et l’efficacité de l’artefact, doivent être évalués de manière itérative
R4 (Procédure multi-méthodologique)Le développement de modèles de maturité fait appel à diverses méthodes de recherche, dont l’utilisation doit être fondée et finement cadrée.
R5 (Identification de la pertinence du problème)La pertinence de la problématique-solution proposée par le modèle de maturité projetée pour les chercheurs et/ou praticiens doit être démontrée.
R6 (Définition du problème)Le domaine d’application prospectif du modèle de maturité, ainsi que les conditions de son application et les bénéfices attendus, doivent être déterminés avant la conception.
R7 (Présentation ciblée des résultats)La présentation du modèle de maturité doit être ciblée sur les conditions de son application et les besoins de ses utilisateurs.
R8 (Documentation scientifique)Le processus de conception du modèle de maturité doit être documenté en détail, en tenant compte de chaque étape du processus, des parties impliquées, des méthodes appliquées et des résultats.
Tableau 2. Exigences de développement d’un modèle de maturité2
Figure. 1. Processus de développement d’un modèle de maturité (©Gabriel Leal)
Figure. 1. Processus de développement d’un modèle de maturité (©Gabriel Leal)

Un exemple réel d’un modèle de maturité 

Afin d’illustrer la conceptualisation d’un modèle de maturité, on présente dans cette section le Maturity Model For Enterprise Interoperability (MMEI).

De nombreux autres modèles sont présents dans la littérature et dans l’industrie avec pour caractéristiques l’interopérabilité, la durabilité, la sécurité, la gestion, etc. Cependant, nous avons décidé de prendre le modèle de maturité pour l’interopérabilité des entreprises MMEI4 comme modèle de référence. Pourquoi ? Parce qu’il :

  1. Définit un cadre pour évaluer et mesurer la maturité potentielle de l’interopérabilité, tout en fournissant des informations sur l’état d’avancement d’une entreprise quant aux niveaux de maturité ciblés ;
  2. Adopte une approche systémique et fournit une vision holistique en tenant compte des différents obstacles et préoccupations de l’interopérabilité basés sur le cadre d’interopérabilité des entreprises (FEI) ;
  3. Est une norme internationale ISO 11354-1:2011 et aussi ISO-11354-2.

Pour les lecteurs curieux, vous trouverez d’autres modèles de maturité ci-dessous :

Conceptualisation du modèle

Ce processus concerne le périmètre du modèle. Selon la littérature sur le développement du modèle de maturité, il est nécessaire de définir :

  • Le type d’application (c’est-à-dire intra ou niveau inter-organisationnel) ;
  • L’objectif (c’est-à-dire quel domaine l’artefact va cibler : généraliste ou plus spécifique) ;
  • Le problème abordé et la solution proposée ;
  • Le public ;
  • Le type de modèle.

Ci-dessous, le tableau 3 présente la conceptualisation de MMEI :

PhaseDescription
ApplicationIntra et inter-organisation.
ObjectifGénéral : considère les multiples domaines liés à l’interopérabilité d’entreprise en réseau,
Problème à résoudreAbsence de modèle d’évaluation organisant et corrélant les différentes exigences d’interopérabilité des différents domaines d’interopérabilité qui peuvent être appliquées dans les contextes « a priori » et « a posteriori ».
AudienceLes parties prenantes (qui connaissent l’entreprise ou une partie de celle-ci), les décideurs (qui sont en position de responsabilité de prendre des décisions), les architectes et les ingénieurs des services aux entreprises.
Type Descriptif : pour permettre aux entreprises d’évaluer leur état actuel, en ce qui concerne l’interopérabilité ; Prescriptif : permettant aux entreprises d’identifier les opportunités d’amélioration en fonction de leur état actuel et souhaité, en ce qui concerne l’interopérabilité ; Comparatif : pour permettre aux entreprises de comparer et d’identifier les obstacles potentiels entre les partenaires existants et potentiels.
Tableau 3. Le cadre du modèle de maturité MMEI

Ce modèle décrit cinq niveaux de maturité (tableau 4). Chaque niveau est une instanciation des principaux éléments d’interopérabilité avec une évolution des éléments concernant le développement du niveau.

Niveau de maturitéDescription
Niveau 4 – AdaptatifCapacité de négocier et d’accommoder dynamiquement avec n’importe quel partenaire hétérogène.
Niveau 3 – OrganiséCapacité de méta-modélisation pour réaliser les mappages nécessaires à l’interopérabilité avec plusieurs partenaires hétérogènes.
Niveau 2 – AlignéCapacité d’apporter les modifications nécessaires pour s’aligner sur des formats ou des normes communs.
Niveau 1 – DéfiniCapacité de modélisation et de description correctes des systèmes pour préparer l’interopérabilité.
Niveau 0 – Non préparéCapacités d’interopérabilité ad hoc ou absence de volonté d’interopérabilité.
Tableau 4. Les niveaux de maturité du MMEI

Le cadre de développement du MMEI

Sur la base des dimensions FEI, il définit douze domaines d’interopérabilité. Ces zones représentent le croisement entre les barrières et les préoccupations en matière d’interopérabilité. Chacun des domaines d’interopérabilité contient les critères d’évaluation qui doivent être vérifiés lors de l’évaluation du niveau de maturité d’une entreprise.

Ces domaines sont nommés d’après leur obstacle et leur préoccupation associés. Par exemple : Business-Conceptuel et Service-Technologique. Le tableau 5 présente les différents domaines d’interopérabilité.

 ConceptuelTechnologiqueOrganisation
BusinessModèles d’affaires pour les partenariats multiples et l’entreprise collaborativeInfrastructure informatique ouverteStructure organisationnelle flexible
ProcessusMéta-modélisation pour plusieurs mappages de modèlesPlateformes et outils pour l’exécution collaborative des processusCollaboration inter-entreprises Gestion des processus
ServiceMéta-modélisation pour plusieurs mappages de modèlesDécouverte et composition automatisées des services, applications partagéesServices collaboratifs et gestion des applications
DonnéesMéta-modélisation pour plusieurs mappages de modèlesAccès à distance aux bases de données possible pour les applications, données partagéesGestion personnalisée des données pour différents partenaires
Tableau 5. Les domaines d’interopérabilité et leurs critères d’évaluation.

Le MMEI propose un critère pour chaque zone d’interopérabilité et pour chaque niveau de maturité, totalisant ainsi 48 critères d’interopérabilité. De plus, le MMEI propose 126 bonnes pratiques.

Chaque pratique est associée à un critère d’interopérabilité. Ces pratiques décrivent « ce qui » devrait être fait pour améliorer la situation actuelle en termes d’interopérabilité. Le tableau 6 présente un exemple de critère d’évaluation.

CritèreDispositifs de stockage de données connectables, échange électronique simple possible
Niveau de maturité Niveau 1
Zone de l’IEDonnées – Technologique (DT1)
ObjectifL’objectif de la zone d’interopérabilité DT1 est de vérifier si les périphériques de stockage de données d’entreprise sont connectables et si le simple échange électronique de données est possible. Note 1 : le stockage de données comprend une base de données, des fichiers de données, etc. Note 2 : un « dispositif de stockage de données » est connectable, ce qui signifie qu’il est configuré pour recevoir une demande d’information d’un appareil électronique (par exemple : un PC) ou d’un serveur de stockage distant. Note 3 : à ce niveau, l’échange d’informations est généralement limité à de simples formats de données homogènes (texte, Jpeg, etc.).
Bonnes pratiquesDT1.1. : identifier les données qui peuvent faire l’objet d’une future interopérabilité. DT1.2. : configurer les périphériques de stockage de données afin qu’ils soient connectables. DT1.3. : mettre en place des actifs techniques prenant en charge l’échange de données au sein de l’entreprise. DT1.4. : définir des protocoles pouvant être utilisés pour l’interopérabilité de l’échange de données.
Tableau 6. Exemple d’un critère d’évaluation (adapté de Guédria et al., 2015).

Pour évaluer ces critères, le modèle adopte un mécanisme de mesure qualitative. Cela signifie que l’évaluateur peut évaluer chaque critère à l’aide de quatre variables linguistiques :

  • Non atteint (NA) ;
  • Partiellement atteint (PA) ;
  • Largement atteint (LA) ;
  • Entièrement atteint (EA).

Lorsqu’il y a plus d’un évaluateur, la cote finale d’un critère est calculée en agrégeant les cotes fournies par tous les évaluateurs concernés. Un mécanisme de mesure quantitative, basé sur la théorie des ensembles flous et sur l’opérateur d’agrégation de la Moyenne Pondérée Ordonnée (OWA), est fourni pour traduire les valeurs linguistiques en valeurs numériques.
Objectif : calculer, agréger et calculer les notations finales des critères, et par conséquent, le niveau de maturité. La figure 2 illustre la méthode de notation.

Figure 2. La méthode de notation actuelle pour l’évaluation de la potentialité (©Gabriel Leal)
Figure 2. La méthode de notation actuelle pour l’évaluation de la potentialité
(©Gabriel Leal)

L’application du MMEI à un cas réel

Le cas d’utilisation démontré dans cette partie afin d’évaluer la contribution proposée est le suivant : il s’agit d’une multinationale, qu’on appellera « CarPartsCo », spécialisée dans la construction automobile, intégrant les systèmes de faisceaux de câblage, les intérieurs exclusifs et les composants électriques. CarPartsCo a l’intention de devenir plus agile et flexible pour améliorer sa réponse aux nouvelles opportunités commerciales.

Pour assurer ses fonctions et atteindre ses objectifs, l’entreprise doit interagir avec de nombreux partenaires, y compris son siège. Cependant, certains défis concernant l’interopérabilité entre CarPartsCo et ses partenaires commerciaux entravent leur collaboration efficace.

Ainsi, le modèle MMEI est appliqué pour identifier les obstacles à l’interopérabilité, existants et potentiels, qui peuvent avoir une incidence sur l’ensemble des systèmes. Deux phases ont été utilisées pour mener les évaluations afin d’obtenir des résultats précieux.

La première a été la phase de préparation au cours de laquelle des entretiens et des ateliers ont été menés avec les employés clés de CarPartsCo. L’idée était de recueillir des données pertinentes concernant leur mode de fonctionnement, leurs tâches collaboratives, et les problèmes et risques perçus. De plus, dans cette phase, une analyse des données collectées nous a permis de concevoir la situation telle qu’elle est (principaux processus, ressources, infrastructure IT, etc.).

La deuxième a été la phase d’évaluation au cours de laquelle deux évaluateurs ont évalué l’interopérabilité de l’entreprise. L’évaluation a été réalisée afin de mettre en évidence sa capacité à être interopérable avec son environnement et en soulignant les problèmes potentiels peuvant influencer l’interopérabilité.

Le tableau 7 suivant présente le résumé de l’évaluation de CarPartsCo en tenant compte de chaque domaine d’interopérabilité.

ZoneIDNoteZoneIDNoteZoneIDNoteZoneIDNote
BCBC1EAPCPC1EASCSC1EADCDC1EA
BC2LAPC2LASC2LADC2EA
BC3LAPC3NASC3NADC3NA
BC4LAPC4PASC4LADC4NA
BTBT1EAPTPT1EASTST1EADTDT1EA
BT2EAPT2LAST2LADT2LA
BT3LAPT3LAST3LADT3LA
BT4PAPT4LAST4PADT4NA
BOBO1EAPOPO1EASOSO1EADODO1EA
BO2EAPO2LASO2LADO2LA
BO3LAPO3LASO3LADO3NA
BO4LAPO4LASO4NADO4NA
Tableau 7. L’évaluation des critères d’évaluation.

BC = Business-Conceptuel, PO = Process-Organisationnel, DT = Data-Technologique, etc.

EA= Entièrement atteint, etc.

En considérant le mécanisme de mesure MMEI, CarPartsCo a obtenu une maturité égale au Niveau 2 – Aligné : capacité d’apporter les modifications nécessaires pour s’aligner sur des formats ou des normes communes.

Conclusion

Dans cet article, nous avons parlé des modèles de maturité. Ce sont des instruments précieux pour les responsables informatiques car ils permettent d’évaluer la situation actuelle d’une entreprise et d’identifier des mesures d’amélioration raisonnables.

De même, nous avons présenté comment cadrer et développer un modèle de maturité, ainsi que les différentes phases à prendre en compte et les exigences à respecter. Nous avons également décortiqué le standard ISO Maturity Model for Enterprise Interoperability, ce qui nous a permis d’appréhender la construction d’un tel modèle. Enfin, nous avons présenté une application de MMEI afin de démontrer l’utilisation d’un modèle de maturité.

Sources 

  1. (de Bruin et al. 2005) De Bruin, T., Freeze, R., Kaulkarni, U., Rosemann, M., 2005. Understanding the Main Phases of Developing a Maturity Assessment Model, in: Campbell, B., Underwood, J., Bunker, D. (Eds.), Australasian Conference on Information Systems (ACIS). Australasian Chapter of the Association for Information Systems, Sydney, New South Wales, Australia, pp. 8–19.
  2. (Becker et al. 2009) Becker, J., Knackstedt, R., & Pöppelbuß, J. (2009). Developing maturity models for IT management. Business & Information Systems Engineering, 1(3), 213-222. https://doi.org/10.1007/s12599-009-0044-5
  3. (Ford et al., 2007) Ford, T., Colombi, J., Graham, J., Jacques, D. The Interoperability Score. In: Proceedings of the 5th Annual Conference on Systems Engineering Research. Hoboken, N.J., (2007)
  4. (Guédria et al., 2015) Guedria, W., Naudet, Y., Chen, D. Maturity model for enterprise interoperability, In Enterprise Information Systems, vol. 9, issue 1, pp. 1-18. (2015) https://doi.org/10.1080/17517575.2013.805246
  5. ISO 11354-1, 2011. ISO 11354-1:2011 Advanced automation technologies and their applications — Requirements for establishing manufacturing enterprise process interoperability — Part 1:Framework for enterprise interoperability. ISO/TC 184/SC 5.
  6. ISO 11354-2, 2015. ISO 11354-2:2015 – Advanced automation technologies and their applications — Requirements for establishing manufacturing enterprise process interoperability — Part 2:Maturity model for assessing enterprise interoperability. ISO/TC 184/SC 5.
  7. (Yager, 1988) Yager, R.R., 1988. On ordered weighted averaging aggregation operators in multicriteria decisionmaking. IEEE Transactions on Systems, Man, and Cybernetics 18, 183–190. https://doi.org/10.1109/21.87068
  8. (da Silva 2020) Leal, G. S., Guédria, W., & Panetto, H. (2020). Enterprise interoperability assessment: a requirements engineering approach. International Journal of Computer Integrated Manufacturing, 33(3), 265-286. https://doi.org/10.1080/0951192X.2020.1736636
bannière Meritis

Vous avez aimé cet article ?
Partagez-le et laissez vos commentaires 😉

Pas encore de commentaires

Publier un commentaire

Auteur

Gabriel Da Silva Serapiao Leal

Au cours des six dernières années, Gabriel a été toujours appliqué à la résolution des problèmes liés aux systèmes d’informations quel que soit le domaine d’application. Titulaire d’un Doctorat en Informatique, il est attiré surtout par la inter-opérations entre systèmes complexes, la modélisation des systèmes et la transformation numérique.