Hello @Gauthier, 

Quand nous avons implémenté LeanIX en 2019, nous sommes partis sur une logique mutualisée, en mettant 2 types d’infos dans les user groups;:

• notre orga
• notre découpage en entités juridiques

ça s’est avéré contre productif car l’orga était trop détaillée et trop mouvante, et pas grand monde ne maîtrisait les entités juridiques.
Du coup, en 2022, nous avons revu notre copie et sommes partis sur une simplification. Pour l’orga, nous l’avons supprimée des user groups car , à travers les business capabilities, nous pouvons déduire les fonctions business.

Nous avons ensuite transformé nos user groups pour y mettre une logique géographique (région → pays).

Il est probable que l’on revoit notre copie encore une fois car le besoin n’est pas uniforme. Par exemple, la supply chain souhaiterait pouvoir bénéficier d’une vue par entrepôt et l’industriel par usine. Pour ce qui est des Sales et Marketing, ils souhaiteraient sans aucun doute qu’on puisse utiliser la notion de business unit. 

Bref, nous avons encore du pain sur la planche.

De manière générale, mon conseil , c’est tout d’abord d’évaluer la capacité de votre organisation à renseigner l’information. 

Pour ce qui est du choix “du modèle d’implémentation”, j’imagine qu’un fact sheet type commun avec plusieurs sub-types est la cible préconisée par leanIX. Ce serait intéressant si on pouvait avoir les arguments de l’éditeur qui justifient ce choix. J’avoue que je ne maîtrise pas encore totalement les pros & cons des sub-types par rapport à des fact sheet types custom.

Cdt,

Didier

Salut @Gauthier !

De notre côté, nous utilisons les 2 méthodes : subtypes & différentes factsheets.

Je m'explique :

Nous avons commencé en respectant rigoureusement le méta-model et les préconisations de LeanIX, à savoir une factsheet appelée "Organization" avec des "Sub-types" par "dimensions", dans notre cas "Department" et "Geographie".

Cela nous a permis d'obtenir des rapports matriciels (Matrix) et de visualiser par exemple "Quel département utilise quelle application dans quel pays", en filtrant si besoin sur une business capability spécifique comme par exemple "Security" (cf. un exemple de matrice sans apps ci-dessous)

Cependant, les besoins de nos utilisateurs ont commencé à s'affiner et on nous a demandé de fournir des analyses du type "Qui utilise quelle application dans quel pays et pour quel client ?". À ce moment, nous avons essayé de modéliser cela dans LeanIX grâce aux "constrains relations" (Cf. doc here) , mais la capacité de reporting intégré à l'outil ne nous permettait pas de visualiser des données à cette granularité.

Nous avons donc été obligés d'ajouter une nouvelle "Factsheet" qu'on a appelée "External Organization", et qui liste tous nos clients. Ainsi, en renseignant les "constrains relations" dans l'outil, on a la capacité de modéliser des Tableau de Bord en utilisant des outils externes (dans notre cas PowerBI) pour répondre à nos besoins d'analyse.

Pour résumer, je suis d'accord avec @Didier.Nowak sur le fait que la qualité et la capacité de renseigner les données dans l'outil sont des prérequis, mais je considérerai également le besoin en reporting/analyse afin de définir le meilleur setup possible dans l'outil.

Bien à vous,

François C.

Hi @Gauthier,

Les subtypes par défaut du Meta Modèle V4 ont été élaborés à partir d’une analyse approfondie des usages et des retours clients, incluant de nombreuses discussions avec des entreprises de divers secteurs. Ils sont conçus pour répondre aux besoins fréquents de modélisation des groupes d’utilisateurs, tout en prenant en compte les spécificités de chaque secteur et les meilleures pratiques générales.

Il est également important de garder à l’esprit qu’en utilisant les subtypes par défaut de LeanIX, vous bénéficiez pleinement des fonctionnalités de reporting Out-Of-The-Box. Cela vous permet de générer des rapports et diagrammes pertinents sans recourir à des outils externes. Cela peut également garantir la compatibilité avec les futures fonctionnalités de l’outil.

Enfin, il n’est pas nécessaire d’adopter tous les subtypes dès le début ; vous pouvez sélectionner ceux qui sont les plus adaptés à votre organisation selon votre niveau de maturité et de complexité actuel. Cette flexibilité vous permet de démarrer simplement et de faire évoluer votre implémentation au rythme de vos besoins, assurant ainsi un déploiement qui se développe en parallèle avec votre organisation.

Hello,

merci à tous pour vos retours !

Nous avons finalement opté pour garder une seule factsheet “User Group” (meta model V3) mais avec différents subtype : Organisation, Group of product, Job/User Role.

Sur les factsheet applications, nous avons en revanche ajouté une relation “Organisation” (en plus de la relation User Group), pointant elle aussi sur la factsheet “User Group”.

Et sur la factsheet User Group, nous avons opté pour un champ conditionnel qui n’affiche les application liées à la nouvelle relation que pour les subtypes “Organisation” et “Group of products”

Ca semble correspondre à notre besoin, sans devoir modifier en profondeur le meta-model ou ajouter un nouveau concept.

Gauthier

Bonjour ​@Gauthier, 

Pour notre part, nous sommes aussi encore sur le MM3 (en route vers le MM4). Nous avions commencé par dimensionner nos types de clients et nos job functions/user roles.

Nous avons élargi la relation pour connecter le User Group à plus que les Applications. Le MM4 propose juste de lier Application->Org  mais notre besoin est plus large et se retrouve similaire au vôtre.

On considère revamper le Organization pour en décliner 3 concepts:

• User Role (liens process et apps, inclut le client externe)
• Business Unit (L1-L2-L3 seulement, lien pour décliner le “ownership” de certains fact sheets)
• Legal Entity