La naissance d’un outil vient souvent pour combler une problématique rencontrée durant les développements. Chaque outil vient répondre de façon différente à différentes problématiques. Nous nous sommes alors posé la question inverse :

Quelles sont les problématiques rencontrées de façon marquée durant les développements industriels et comment notre environnement y répond-il?

Comment améliorer notre niveau de qualité?

améliorer la qualité

Problématiques classiques
Comment y répondre
  • Les données sont éclatées, éparses et compartimentées (silos) ce qui annule leur valeur du point de vue de la collaboration,
  • Il existe des données compartimentées dans différents outils spécialisés et leur cohérence n’est pas assurée,
  • Trop de données à forte valeur ajoutée se retrouvent dans des documents Word / Excel, sur les réseaux, non indexées et non liées,
  • Notre connaissance en temps réel de la viabilité de notre système est biaisée par le manque d’informations à jour de la part de nos fournisseurs.
  • Une solution très intégrée (Héberger tous les « articles » d’ingénierie et du support à l’ingénierie dans un même répertoire - articles liés),
  • Interfaçage simple avec Word/Excel et d’autres outils spécialisés (laisser aux spécialistes leurs spécialités mais s’assurer de l’interfaçage pour la cohérence d’ensemble)

Comment améliorer notre productivité?

améliorer la productivité

Problématiques classiques
Comment y répondre
  • Les données sont éclatées, éparses et compartimentées (silos) ce qui annule leur valeur du point de vue de la collaboration,
  • Il existe des données compartimentées dans différents outils spécialisés et leur cohérence n’est pas assurée,
  • Trop de données à forte valeur ajoutée se retrouvent dans des documents Word / Excel, sur les réseaux, non indexées et non liées,
  • Notre connaissance en temps réel de la viabilité de notre système est biaisée par le manque d’informations à jour de la part de nos fournisseurs.
  • Automatiser la production de documentation et se concentrer sur la gestion du design,
  • Mise à disposition de templates prêts à l’emploi et ayant un contenu mis à jour en temps réel comme un dashboard,
  • Une gestion de la traçabilité infaillible et couvrant la totalité des « articles » d’ingénierie et de support à l’ingénierie pour s’assurer que le changement se propage, sous contrôle, et que l’ensemble reste cohérent,
  • Génération de vue spécialisées « à la volée » - Spécialisées car répondant à une problématique bien spécifiques d’une activité, d’un instant du développement, d’une équipe, etc. « à la volée » car apparaissant aussi vite que disparaissant et nécessitant donc d’être générées et adaptées très facilement.

Comment gérer nos changements de configuration?

gérer la configuration

Problématiques classiques
Comment y répondre
  • Il est souvent difficile de suivre les changements dans le système pour les valider, ce qui a changé à date, entre deux versions ou encore entre deux projets ayant effectué une "branche",
  • La gestion du changement est difficile. Nous aimerions un process associé mais sa mise en place est lourde et nécessite des ressources supplémentaires (humaines, temps, etc...),
  • Comment s'assurer de l'impact d'un changement sur le reste du développement. Il nous manque une vision claire des impacts via la traçabilité.
  • Des objets du design gérés à la façon « PLM », à la manière d’articles, avec des attributs, un historique qui se fait de façon automatique sur l’ensemble des évolutions, une version, un cycle de vie, et la possibilité de verrouiller une configuration sur un article, un groupe ou le développement dans son ensemble,
  • Des « change requests » dans lesquels « tombent » automatiquement les « articles » ayant évolués pour mieux accepter ou refuser leur statut,
  • Chaque objet doit avoir un cycle de vie propre si nécessaire et aisément configurable. Le moteur de cycle de vie doit offrir la possibilité de configurer l’ensemble des actions et notifications nécessaires au changement de statut.

Comment gérer notre montée en maturité?

Problématiques classiques
Comment y répondre
  • Dassault, PTC et IBM nous ont assuré que l’outil en notre possession pourrait évoluer facilement suivant nos souhaits. Mais quand vient le moment de le faire évoluer, la note est plus que salée pour assurer le développement de fonctions qui ne nous satisfassent qu’à moitié. Et plus nous faisons évoluer le produit et moins celui-ci est maintenable et nécessite de personnes pour le maintenir
  • Les évolutions de logiciels « mainstream » sont loin d’être satisfaisantes, la roadmap est fermée, il n’est donc pas possible de l’influencer, et l’échelle de temps des changements est bien loin de la dynamique requise par notre industrie
  • La solution en notre possession possède un langage propre, fermé ou assez fermé. L’interfaçage est acceptable et standardisé mais les possibilités sont assez limitées.
  • En outre, le besoin d’évolutivité vient parfois d'un ou plusieurs « articles » d’ingénierie ou de support à l’ingénierie (modèles, projet/action/CR réunion, architecture/fonction/produit) manquant à l’appel. Il faut alors faire appel à une solution extérieure gérant ces « articles » pour combler le vide. Ce qui nécessite de grossir le processus d’interfaçage des données. Cela revient à accroitre la lourdeur et diminuer la productivité.
  • Une disponibilité des données à l'export/import avec des standards de données ouvert (XML, etc.),
  • Un environnement ouvert,
  • Un langage aisément accessible pour réaliser des extensions,
  • Une maintenance faible,
  • Une roadmap claire, partagée et discutée avec les clients
  • L’ajout et la configuration poussée d’articles.

Sur la base de ce cahier des charges, nous avons sélectionné deux outils, Cognition Cockpit et HiP-HOPS.

Découvrez en particulier comment Cockpit répond à notre cahier des charges

 

Essayez Cockpit maintenant! Back to top