Contexte

La raison de cet article est que nous avons créé un guide ou boite à outils DSM (Design Structure Matrix) sous Cockpit. Ce guide a été créé dans le cadre d’une prestation client. Ce client avait émis le besoin de pouvoir réaliser des « clusters » (ou groupements) de travaux intelligents.

Plus particulièrement, comment organiser les lots de travaux au mieux sur la partie architecture fonctionnelle du système. Le système en question comportait une centaine de fonctions. Dans ces conditions, le travail d’optimisation des lots de travaux est encore possible mais le résultat n’est sans doute pas réellement optimal et le travail nécessaire pour y parvenir, pas marginal.

Nous sommes rapidement tombés d’accord pour implémenter le DSM sous Cognition Cockpit. Toutes les données sous Cockpit sont déjà liées et ces liens sont autant de dépendances qu’il faut quantifier pour juger de la valeur du lien. Cockpit semble être un outil très bien positionné pour ces analyses systémiques.

Illustration

L’implémentation

Nous avons organisé l’outil pour couvrir 5 phases pour identifier et créer ces groupes optimaux:

1. Sélection des éléments à grouper

Sélectionner le type d’artefacts à grouper de façon optimale

2. Calibration de l’algorithme

Calibrer l’algorithme sur base de différents paramètres (nombre de « clusters », type de liens à considérer, pondération des liens, etc.)

3. Performances de l’algorithme

L’algorithme effectue de multiples itérations et à chaque itération il tente d’améliorer son résultat pour tendre vers un optimum. L’algorithme tente d’éviter les optimums locaux. Il est possible de visualiser les performances obtenues par la configuration actuelle de l’algorithme

4. Visualisation graphique des résultats

Voici un exemple de visualisation sous forme de matrice comme nous l’avons implémentée sous Cockpit.Chaque ligne correspond dans ce cas à une fonction.Chaque carré grisé correspond à une dépendance existant entre l’élément en ligne et l’élément en colonne.Chaque carré coloré, embarquant une série de carrés grisés, est en fait un groupement déterminé par l’algorithme.En survolant les groupements, on obtient des informations telles que la valeur du groupement.Cette vue est très puissante pour cerner rapidement le résultat de l’algorithme et le comparant avec les groupements effectués.

5. Générer les groupes optimaux

Une fois les groupements étudiés et la performance de l’algorithme jugée satisfaisante, le guide DSM Cockpit permet de créer les groupes directement sous Cockpit afin de pouvoir travailler sur la base de ce résultat. Il est très aisé de supprimer les groupes de travail nouvellement créés.

Conclusion

Les résultats de cette implémentation sont très encourageants. Nous avons eu l’opportunité dans le cas de cette étude de pouvoir comparer les résultats des groupements effectués par des humains avec ceux de notre algorithme. Des groupements de travaux avaient en effet été réalisés sur ce même jeu de données à priori. Les résultats sont considérés comme très encourageants car très proches de la logique appliquée par les humains.

De plus, nous croyons pouvoir revendiquer que cette application DSM est une première mondiale en ce sens que la méthodologie est appliquée directement dans l’environnement de travail et d’évolution des données.

Habituellement ce genre d’analyse s’effectue sur un lot de données extrait d’un environnement de travail. Les données sont analysées puis un travail de création des groupements est effectué pour recréer les groupes dans l’environnement. Dans le cas de notre « Proof of Concept », la démarche est totalement intégrée à l’environnement et de fait s’effectue de façon naturelle sur des données toujours à jour. L’analyse est de plus aisément reproductible et l’application des résultats de l’analyse est effectuée, encore une fois de façon tout à fait naturelle sous l’environnement de travail.

Potentielles futures applications

L’application principale de ce guide s’est faite sur un jeu de données d’architecture fonctionnelle d’un client. Nous avons également entamé une investigation sur un planning projet très complexe afin de déterminer les dépendances entre tâches de travail. Les résultats visent à améliorer la répartition de l’effort de gestion et la distribution des lots de travaux pour s’assurer que les travaux qui dépendent le plus des uns des autres soient rapprochés (N.B. que le terme rapproché n’est pas précisé et peut être compris comme physiquement ou non – la solution n’est pas donnée).

Le guide est prêt à être utilisé dans ce contexte et nous pensons que les bénéfices sont d’autant plus conséquents que le planning est complexe.

Posted by Matthieu Aubron

System Thinker for complex industrial projects Consultant en ingénierie système et plus globalement en organisationnel pour l'industrie.

5 Comments

  1. Tres interessant !

    La representation matricielle est extremement interessante pour visualiser l »ensemble des interfaces entre les différents systemes, et permet de donner un indicateur de « qualité » de l’architecture.

    Est-ce que vous avez des chiffres concrets , avec des exemples de systèmes industriels reels – un avion, une auto, … , sur le nombre ou le pourcentage d’interfaces ??

    1. Aubron Matthieu juin 10, 2016 at 12:34

      Bonjour Nicolas,

      Merci pour votre commentaire.

      J’aurais bien des chiffres à vous partager, mais je ne suis pas sur que cela vous aide. Tout dépend du niveau de granularité. Si par exemple je donne une architecture avion, quel est le niveau de granularité ou d’abstraction représentatif des mes systèmes les uns avec les autres? Pour un même porteur avion par exemple, je pourrais vous donner deux architectures représentatives du même porteur mais avec x100 interfaces suivant ce que je souhaite représenter le premier niveau de granularité fonctionnel (qui est très subjectif) ou bien un très bas niveau fonctionnel. Ce n’est pas de la mauvaise volonté, c’est simplement que le niveau de subjectivité est tel …

      Par contre un pourcentage peut être représentatif de quelque chose peut-être puisque c’est un rapport (encore que la façon de modéliser soit elle aussi très subjective – le regroupement de plusieurs flux d’information sur un seul signal va fausser le ratio par exemple)…à quel pourcentage pensez-vous? Le pourcentage d’interfaces par rapport a quoi s’il vous plait?

      Désolé de me pas pouvoir répondre facilement.

      Bien a vous,

      1. Effectivement, je suis d’accord avec vous, un tel rapport est assez subjectif, et les comparaisons ont une certaine limite.

        Pour ma part, je pensais à calculer une sorte « d’indicateur d’interfacage » – par exemple, dans la presentation matricielle ‘n x n’ en calculant le nombre de case avec interface, par rapport au nombre total d’interfaces possible (n x (n-1)) .

        Si la matrice est petite (n entre 5 et 10), on peut s’attendre a un taux d’interfaces élevé.

        Si on ‘éclate’ l’architecture avec un étage de décomposition supplémentaire (n entre 25 et 100), le taux d’interface pourrait être plus faible …

        J’avais lu un article sur l’architecture d’une imprimante, décomposée en une centaine de sous-elements, la presentation matricielle mettait un evidence un taux d’interface de l’ordre de 3% .

        Pour clarifier le sens de ma question : pour un cas réel d’un avion/une auto/une usine, décomposé en 25 à 100 sous-éléments de maniere optimisée, quel est ce taux d’interface ? ( est-ce moins de 5 %, plutot 20 %, autres ?).

        Quand on regarde la matrice présentée dans votre article, le taux d’interface semble plutot ‘faible’.

        1. Aubron Matthieu juin 21, 2016 at 11:52

          Bonjour Nicolas,

          J’ai effectué le calcul demandé (en calculant le nombre de cases avec interface, par rapport au nombre total d’interfaces possible (n x (n-1)). Très intéressant puisqu’il nous ramène peu ou prou au pourcentage de l’imprimante:

          – Il y a 570 cases « grisées » (avec au moins une interface)
          – contre 165 fonctions, donc 165×165 (nxn) = 27225 cases

          Nous avons donc un pourcentage comme vous le définissez de 570 / 27225 = 2%

          Je découvre grâce a vous quelque chose de très intéressant: Un indicateur qui semble donc pertinent! A creuser donc…Pourrait-on le rapprocher d’un indicateur de complexité?

          N’hésitez pas si vous avez d’autres axes de réflexions que nous pourrions développer dans ce blog.

          Matthieu

          1. Bonjour Matthieu,

            C’est un résultat interessant : sur deux exemples différents, on trouve un « taux d’interface » +/- similaire.

            L’idéal serait d’avoir des données pour d’autres produits industriels. Je serai trés curieux de connaitre ce « taux d’interface » pour une voiture ou un avion .. ou on interface des systemes tres différents, entre les fluides, le contrôle-commande, l’électricité, la mécanique, …

Comments are closed.