Christian HOHMANN

Depuis 1998 - 2024 26 ans déjà !

  • Augmenter la taille
  • Taille par défaut
  • Diminuer la taille
Accueil Logical Thinking Process - Thinking Processes Conflict Resolution Diagram, une étude de cas

Conflict Resolution Diagram, une étude de cas

Envoyer

Christian HOHMANNAu cours d’une mission de diagnostic concernant la performance de la chaine de valeur amont (marketing-commerce-développement-industrialisation) chez un équipementier automobile, un conflit a fait surface.

Ce conflit oppose les responsable marketing et commerciaux aux ingénieurs développement. Les premiers réclament de l’innovation pour séduire les clients (les constructeurs automobile, OEM) alors que les seconds rétorquent que la consigne leur impose de ne développer que sur la base de solutions éprouvées.


Le diagramme CRD

Le Conflict Resolution Diagram de ce conflit est le suivant.


Le conflit est basé sur l’hypothèse que D et D’ sont des exigences mutuellement exclusives.

Pourquoi ?

"Des solutions mal maitrisées par le passé ont conduit un client à se méfier de nos innovations"

Suite à cette déconvenue, le dirigeant a imposé le recours aux seules solutions éprouvées. C’est une contrainte de paradigme, une politique décidée dans des circonstances particulières, qui va avoir des répercussions durables.

Test de validité

Le CRD (ou Evaporating Cloud) doit passer avec succès le test de validité aux sept conditions suivantes :

  1. Pour que l'objectif A se réalise, il faut que B soit réalisé
  2. Pour que l'objectif A se réalise, il faut que C soit réalisé
  3. Pour que l'objectif B se réalise, il faut que D soit réalisé
  4. Pour que l'objectif C se réalise, il faut que D' soit réalisé
  5. Les conditions D et D' sont en opposition et il est impossible de les réaliser / obtenir simultanément
  6. La réalisation de D met C en danger
  7. La réalisation de D' met B en danger

Notre diagramme est validé.


Verbalisation des hypothèses

  • Hypothèse 1 (relation de B vers A) fondée sur la logique de nécessité ; pour décrocher un contrat, il est nécessaire de sécuriser le client avec des solutions éprouvées.
  • Hypothèse 2 (relation de D vers B) : Pour sécuriser le client avec des solutions éprouvées, il ne faut développer que sur la base de solutions éprouvées.
  • Hypothèse 3 (relation de C vers A) : pour décrocher un contrat, il est nécessaire de séduire le client avec des solutions innovantes.
  • Hypothèse 4 (relation de D’ vers C) : pour séduire le client avec des solutions innovantes il faut développer des solutions innovantes.
  • Hypothèse 5 (relation de D’ vers D) : il ne faut développer que sur la base de solutions éprouvées ET il faut développer des solutions innovantes

Vérification des hypothèses

Test de vraisemblance

Chaque participant est prié de donner pour chacune des hypothèses, son évaluation de vraisemblance. Cette évaluation n’a rien de scientifique, chacun répond en fonction de son analyse, des éléments et informations dont il dispose. L’hypothèse 5 qui sous-tend le conflit n’est pas mise au débat.

Rôle du consultant : Je ne connais pas l’historique, je ne peux pas et ne dois pas arbitrer les réponses. Je ne suis que l’animateur du groupe de travail qui fait partie du diagnostic.

Le but de ce test est de :

  • Vérifier la dispersion des opinions ou leur cohérence
  • Vérifier si l’on peut « tuer » un mythe en apportant ou en partageant une information détenue par un participant, ou par le bon sens
  • Rendre les membres les plus butés plus perméables aux autres opinions

Note : ce test ne fait pas partie du mode opératoire « académique » de la Théorie des Contraintes, c’est un choix personnel.


Discussion des hypothèses

Le test de robustesse des hypothèses est la clé du CRD : si l’une des hypothèses liant deux entités est fausse ou peut être invalidée dans le futur, le conflit s’évapore.

Hypothèse 1 (relation de B vers A) fondée sur la logique de nécessité ; pour décrocher un contrat, il est nécessaire de sécuriser le client avec des solutions éprouvées.

Pour :

  • Unanimité des participants, c’est une condition indispensable (ils ont en tête le client le plus exigeant, qui est également le plus important de leur portefeuille)

Contre (questions du consultant) :

  • Est-ce une loi d’airain, non-négociable ? Est-ce binaire ? ne peut-on admettre une certaine dose d’innovation, en périphérie ?
  • Qu’appelle-t-on « éprouvée », un proof of concept est-il suffisant au moment de la soumission d’offre ?
  • Peut-on prouver la validité de la solution innovante auprès d’un autre client d’abord ?
  • Peut-on prouver la vraisemblance de la validité de la solution par des résultats de tests poussés ?

Les débats entre participants montrent que l’acceptation de l’hypothèse comme vraie a fermé la recherche de solutions alternatives. Personne n’a d’information suffisamment fiable et suffisante pour rejeter mes questions/ suggestions. Il faut récupérer la voix du client (le seul qui pourra apporter la réponse) sur ces différents points.

Hypothèse 2 (relation de D vers B) : Pour sécuriser le client avec des solutions éprouvées, il ne faut développer que sur la base de solutions éprouvées.

Pour :

  • Quasi-unanimité des participants pour qui c’est une évidence, voire une tautologie.

Contre :

  • Quelques responsables marketings et commerce qui pensent que des alternatives sont possibles, sans pouvoir les formuler (intuition)
  • Question du consultant : les solutions ou parties de solution peuvent être éprouvées par d’autres équipementiers ou sous-traitant et leur intégration dans vos solutions pourraient-elles contourner l’obstacle ? Si oui, c’est une décision make-or-buy qui penche pour le buy…

Les débats sont globalement les mêmes que précédemment. Les responsables marketings et commerce apprécient l’idée de ne pas tout développer systématiquement en interne, essentiellement parce que cela concrétise leur intuition de solutions alternatives. Les ingénieurs développement sont plutôt sceptiques et opposés. Je suppose que cela met à mal leur honneur de développeurs que d’admettre qu’éventuellement des concurrents sont capables de maitriser des solutions et pas eux…

Hypothèse 3 (relation de C vers A) : pour décrocher un contrat, il est nécessaire de séduire le client avec des solutions innovantes.

Cette exigence est suggérée et non explicitement citée dans les cahiers de charge. Les commerciaux rapportent de leurs échanges avec les clients que l’innovation est un élément de séduction.

Pour :

  • Les déclarations des commerciaux (mais pas de preuve formelle, d’expression formelle d’exigences en ce sens)
  • Le témoignage de quelques ingénieurs citant les échanges avec leurs homologues chez les clients

Contre :

  • Les affaires passées, conclues sur des solutions déjà connues, anciennes. Ces réutilisations n’ont pas été des freins à l’obtention du contrat (notons que cela tend à renforcer l’hypothèse 1)
  • (question consultant) le client désire-t-il réellement des solutions innovantes ou être « rassuré » sur votre capacité à innover ?
  • (question consultant) la demande d’innovation n’est-elle pas en réalité du « brain sucking » ?

Hypothèse 4 (relation de D’ vers C) : pour séduire le client avec des solutions innovantes il faut développer des solutions innovantes.

La discussion de cette hypothèse est pratiquement une copie de celle de l’hypothèse 2

Pour :

  • Quasi-unanimité des participants pour qui c’est une évidence, voire une tautologie.

Contre :

  • Quelques responsables développement qui pensent que des solutions innovantes peuvent être créées à partir de réemploi de solutions existantes
  • Question du consultant (idem que pour hypothèse 2) : les solutions ou parties de solution peuvent être éprouvées par d’autres équipementiers ou sous-traitant ? Si oui, c’est une décision make-or-buy.

Finalement, la discussion autour de l’hypothèse 5 (relation de D’ vers D) : il NE faut développer QUE sur la base de solutions éprouvées ET il faut développer des solutions innovantes pose la question de la possibilité de faire coexister les deux et ne pas les considérer comme mutuellement exclusive.


Portefeuille projets différencié

Le groupe est mis sur la voie par le rappel des basiques de la gestion de portefeuille produits et de leurs cycles de vie. L’hypothèse 5 peut être invalidée par la gestion d’un portefeuille équilibré, consistant à éliminer « NE » et « QUE » dans sa formulation ci-dessus.

Une matrice a été esquissée durant la discussion.


Un portefeuille équilibré, à terme, devrait comporter :

  • des projets innovants naissants dans le quadrant Nord-Ouest (Supérieur-Gauche),
  • des produits innovants en passe de devenir des standards (ils sont stabilisés, reconnus)
  • des produits de fonds de portefeuille qui sont, selon la stratégie de l’entreprise seront plutôt des solutions robustes standards ou des solutions innovantes mais fiables qui s’inscrivent comme des standards sans équivalents (quadrant N-E)

Un portefeuille équilibré pourrait ressembler à cela :

La taille des bulles représente une troisième dimension pertinente. Pour en savoir plus sur les >graphes à bulles<.



Conclusion

Au terme des débats, j’ai procédé à un nouveau test de vraisemblance afin de vérifier si les positions individuelles avaient évoluées.

 

La comparaison des deux tests montre que la branche supportant les hypothèses 1 et 2 semble plus résistante que celle qui supporte les hypothèses en faveur de l’innovation.

L'approche portefeuille équilibré est retenue car elle permet de répondre à diverses exigences et contraintes sans totalement désobéir à la consigne de ne développer que des solutions sur bases éprouvées. Le dirigeant sera informé des débats et suggestions de cette session de travail et invité à se prononcer sur l'assouplissement de sa consigne.

Rappel

Au stade du CRD, les injections proposées pour évaporer le conflit ne sont que des idées, pas des solutions. Il convient de ne pas s'autocensurer par crainte des difficultés ou un doute sur la faisabilité de telle ou telle solution. Ces aspects sont traités ultérieurement à l'aide des Future Reality Tree (FRT) et des Prerequisite Trees (PRT)



View Christian HOHMANN's profile on LinkedIn




Mise à jour le Lundi, 20 Novembre 2017 11:09  

Syndication