User Grourp - Organisation

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.

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

Bonjour,

Merci pour vos échanges sur ce sujet. Nous avons également commencé à nous pencher sur cette problématique et nous expérimentons le fait de n’avoir qu’un objet pour représenter nos entités organisationnelles (entités juridiques, directions ayant un budget IT et parfois des équipes produits “autonomes”), organisations partenaires et clientes (entités juridiques ayant la propriété intellectuelle d’assets dont nous assurons la gestion, directions métiers utilisatrices des solutions IT délivrées et éventuelles directions IT clientes) et des rôles génériques de parties prenantes que nous avons appelé “acteurs” servant dans la modélisation des chaines de valeurs.

L’utilisation de sous-types semble effectivement bien fonctionner et ne dégrade pas les capacités de reporting.

Nous sommes vigilants tout de même sur l’utilisation des rapports de type matrice car le filtrage sur un sous-type ne s’appliquant pas sur les parents d’une fiche, on peut avoir des arborescences un peu perturbantes si on mélange des sous-types différents dans une même hiérarchie...