AMIS — Anomalies, manques, inadéquations, suggestions

16-01-2024 14:53:30

Les AMIS forment un prisme de pensée en matière de boucles de rétroaction entre l'organisation et les acteurs de sa value-stream chaîne de valeur en aval, en particulier le client et/ou l'utilisateur. Les AMIS sont une pièce de l'orientation clients. Tenant donc cette place, les AMIS permettent de répondre à un des 2 objectifs des Transformations Digitales : le ravissement des clients. Il ne peut donc pas s'agir d'un sujet mineur.

L'habillage technique du sujet, sa nature digitale, permet également de répondre à une contrainte ubiquitaire forte : la pression AAA — Anywhere, Anything, Anytime:

On connaît le rapport d'incident / bogue

Il s'agit de dépasser la seule notion de bogue pour inclure dans la réflexion tout ce qui peut nous amener à améliorer le produit / service : les choses qui s'y trouvent et qui sont inutiles, celles qui ne s'y trouvent pas et qui seraient utiles, les choses qui s'y trouvent mais qui ne donnent pas les résultats attendus par les utilisateurs (ou par d'autres parties prenantes), …

Voici un exemple concret de AMI sur un site Web :

En établissant des boucles de rétroaction directes entre l'utilisateur final et ceux qui ont conçu le produit / service et en dépassant l'horizon du seul bug report on jette les bases d'un flux potentiellement ininterrompu d'améliorations. D'un côté, les clients / utilisateurs; de l'autre l'organisation. Sans être exhaustif, voici quatre boucles possibles :

1. De l'organisation vers les clients / utilisateurs / prospects (ce n'est pas une boucle AMIS)
2. Des clients / utilisateurs / prospects vers le service après-vente (boucle AMIS)
3. Des clients / utilisateurs / prospects vers l'équipe responsable du développement du produit / service (boucle AMIS, correspondant au formulaire illustré ci-dessus)
4. Du service après-vente vers l'équipe responsable du développement du produit / service (ce n'est pas une boucle AMIS)

On se connecte à la chaîne de valeur en aval

Selon Michael E. Porter, une chaîne de valeur a trois objectifs principaux :

1. améliorer les produits / services,
2. en réduire les coûts,
3. et … créer de la valeur.

Notre question d'AMIS ne se donne pas nécessairement comme objectif immédiat de réduire les coûts de développement des produits / services. Si c'était le cas, il s'agirait d'un bénéfice indirect.

Il nous reste les deux autres prémisses : améliorer les produits / services et créer de la valeur pour ceux qui vont les "consommer". Cela donne un espace de possibilités comme l'innovation, une plus grande différenciation des produits / services, une qualité accrue, l'amélioration du service au client, la réduction des délais de livraison grâce à une bonne organisation logistique, etc.

Lorsque l'entreprise vend directement au consommateur / utilisateur final, sa chaîne de valeur en aval est limitée au strict minimum. Par contre, lorsqu'elle élabore des stratégies de distribution à plusieurs étages, elle doit s'intéresser à l'ensemble des protagonistes, par exmple, le distributeur, le revendeur, le prescripteur, … et le consommateur / utilisateur final du produit / service.

Les AMIS ne sont pas limités à la fin de la chaîne; on peut concevoir de multiples courses pour chaque étape entre l'organisation et l'extrémité concernée (distribueur, revendeur, …) que j'appelle endpoint. Le endpoint sera un facteur déterminant de la destination où l'information transmise va atterrir, variable d'organisation à organisation. Par exemple, on peut imaginer que les AMIS établis entre un distributeur et l'organisation aboutissent au service logistique.

Les AMIS font partie de la chaîne vertébrale digitale

Pour que les AMIS puissent être établis, gérés, modifiés il est nécessaire de les inclure dans l'enchevêtrement de services de l'organisation, une fonction réservée à la colonne digitale.

Les fonctions principales attendues de l'ESB (Enterprise Service Bus) sont essentiellement des questions de routage intelligent, de format, de stockage, d'archivage et de traitement automatique.

L'organisation peut vouloir mettre en place des AMIS à titre expérimental en contournant la colonne vertébrale digitale. C'est une stratégie que je soutiens en période de POC (Proof of Concept). Une fois passé le cap du POC, il faut se diriger vers une prise en charge sérieuse par l'équipe qui développe et maintient la colonne. Sans cette prise en charge précoce dans la mise en place d'AMIS, on risque en effet de développer une série d'élastiques dépourvus de la moindre élasticité. Ajouter un problème à ceux qu'on se propose de résoudre n'est pas vraiment une bonne idée.

Les AMIS sont un delta qui alimente plusieurs piliers des Transformations Digitales

Stricto sensu, on active plusieurs piliers des Transformation Digitales : les produits / services, les canaux de communication (ici boucles de feedback), les méthodes de travail et processus, et l'accélération des cycles.

Produits / Services

Si on connaît depuis belle lurette le rapport de bogue automatisé (bug report : voulez-vous envoyer le rapport d'incident au support ?), ce qui est d'ailleurs une partie constituante du produit / service, on ne connait que beaucoup plus rarement son élargissement à d'autres préoccupations que les bugs.

La mise en place de cette boucle de rétroaction implique de facto une modification du produit / service lui-même, laquelle modification doit pouvoir être industrialisée pour être incluse dans tous les produits / services d'une gamme, voire plus généralisée encore. Voilà un sujet qui doit être abordé par une Transformation Digitale.

Méthodes de travail

Modifier les produits / services sans adapter les processus et les méthodes de travail s'apparenterait au gâchis Overproduction. Ainsi, le bug report arrive quelque part où il est censé être traité.

Élargissant la boucle, on peut donc espérer que toute autre information soit dûment traitée également : les manques, les inédéquations, les suggestions.

Si le rapport de bogue intéresse le plus souvent la seule équipe technique, il n'en est pas de même lorsqu'on adresse un manque, une inadéquation ou une suggestion. D'autres processus doivent être activés.

Revenant au bug report, et au sujet des méthodes de travail / processus, il devient légitime de se poser la question de la bonne gestion des incidents. Doit-on inclure cette gestion dans chaque équipe ou doit-elle être centralisée ? Il n'y a pas de silver bullet … quelle que soit la réponse à cette question, elle impliquera une réflexion sur les méthodes de travail et les processus de l'organisation variable en fonction du contexte, changeante avec le temps.

Accélération des cycles

La boucle de rétroaction liée aux AMIS doit être la plus directe et la plus automatique possible sans causer de friction. Une accélération qui générerait des frustrations s'ajoute aux problèmes à traiter. Une boucle directe ne fait que rendre possible une prise en compte rapide. Si l'automatisation ne vient pas en soutien des méthodes de travail et processus, la boucle aura peu d'intérêt. La boucle génèrera même des désappointements sévères si la vitesse de réaction n'est pas accrue, une situation vécue dans de très nombreuses circonstances et que j'ai connue avec acuité dans une organisation syndicale. La mesure du temps de réaction est nécessaire. Des alertes doivent pouvoir être générées si le traitement ne semble pas efficace (des messages qui s'accumulent dans une boîte mail par exemple). Il devrait être possible d'activer ou désactiver les boucles en fonction des impératifs rencontrés. On voit donc à quel point ces boucles entraînent des modifications / adaptations dans la conception des produits / services et requièrent des méthodes de travail adaptées. Établir des boucles de rétroaction en biffant les autres aspects induits est une erreur.

S'agissant par exemple des suggestions, il semble acquis que soit impliqué le PO (Product Owner), proxy du Business. On établira donc une boucle directe avec l'équipe concernée si tant est que cela paraît idoine dans le contexte de l'organisation et de sa maturité digitale. Cela paraît simple et logique mais c'est bien plus complexe que cela en a l'air. Que dire de ces suggestions qui impliquent un travail coordonné entre plusieurs équipes, voire un pont entre chaînes de valeur différentes ?

Canaux de communication

Tout support technique correspond à l'établissement d'un canal de communication à l'instar du service après-vente . Des boucles directes et automatisées n'échappent pas au principe.

On pense généralement à ces boucles comme à de simples moyens techniques de mise en contact. C'est une vue étriquée du sujet : il y a échange avec les clients / utilisateurs, il y a communication ! On ne peut donc débrayer les divers aspects liés au marketing et aux relations publiques. C'est un travail qui implique l'ensemble de la chaîne de valeur.

Définitions rapides

Anomalie

ce qui s'écarte des spécifications. Autres vocables : bogue, défectuosité, vice. Une anomalie constatée en contexte est le signe de procédures de test perfectibles.

Manque

fait de manquer, de faire défaut ; insuffisance ou absence de ce qui serait nécessaire. Un manque n'est jamais une anomalie (au sens où il ne met pas en défaut une spécification). Le manque se constate en contexte.

Inadéquation

caractère de ce qui n'est pas adéquat sans être en défaut avec la spécification. Le sujet couvert par l'inadéquation a été mal étudié, ou incomplètement couvert. L'inadéquation se constate en contexte.

Suggestion

action de suggérer; art de faire naître une idée; action de proposer. Une suggestion n'est jamais une anomalie. Elle peut adresser un manque ou une inadéquation. Synonyme : proposition. La suggestion s'obtient en contexte, est issue d'une utilisation effective.

Exception

état anormal d'un système dans des circonstances où des événements particuliers de produisent. Une exception est toujours une anomalie en contexte.

Contexte

ensemble de circonstances liées, situation où un phénomène apparaît, où un événement se produit.

Enseignements

Toute mise à disposition d'un produit / service, en tout ou partie, et quel que soit le public visé, large ou restreint, doit pouvoir ramener une moisson d'enseignements qui permettront de préciser un ensemble d'hypothèses ou de les confirmer / infirmer, d'établir des constats. Une mise en production peut s'envisager pour une panoplie de raisons mais s'il y en a une sur laquelle la profession s'accorde, c'est celle qui consiste à pouvoir récolter des enseignements utiles pour les prochaines versions qui devront être développées.

Je ne suis pas de ceux qui exigent des mises en production à la fin de chaque itération : je suis de la secte des agnostiques. Pour moi, chaque mise en production doit avoir du sens et le seul sens qui prévale est celui où la balance bénéfices / risques / coûts penche du côté des bénéfices.

Parmi les bénéfices, je place les enseignements en excellente position. Dans ma carrière j'ai souvent demandé à mettre en production des versions boguées ou incomplètes pourvu que les impacts soient nuls ou négligeables ET que cela m'apprenne quelque chose. Parfois même, ces versions étaient inactivées en production. Ce que je cherchais à faire est simplement d'évaluer la capacité de l'équipe et du tooling à promouvoir une version en production et à passer toutes les étapes intermédiaires. Voilà un enseignement singulier particulièrement éclairant : vous passez à la loupe le processus de déploiement, les interactions entre les membres de l'équipe, les interactions entre équipes, le tooling, la gouvernance, … Ainsi, m'occupant d'une équipe Business Intelligence dans le secteur de l'énergie j'ai pu constater que ce n'est qu'après de multiples tentatives de mises en production que l'équipe a finalement trouvé la bonne façon de faire. J'ajoute que je n'ai pris qu'une part très limitée à l'établissement de la solution, me contentant de poser quelques questions orientantes. J'ai été critiqué pour l'approche poursuivie avant qu'on finisse par reconnaître que l'équipe était devenue finalement une véritable machine à délivrer parfaitement autonome. Ce drill de la mise en production y a beaucoup contribué et les nombreux enseignements collectés lors des tentatives infructueuses (mais ne présentant aucun risque) ont été mis à profit et partagés par l'ensemble de l'équipe.