Flow based organization: les premières briques d’une organisation agile

Capture d'écran 2014-09-20 12.11.17

Cela fait quelques mois que j’aide une organisation dans sa transformation agile et au fur et à mesure de notre avancement certaines techniques, certains jeux émergent comme étant des outils très intéressants.

L’organisation n’est pas dans l’informatique, il ne s’agit pas d’un service informatique, donc l’approche méthodologique n’est pas dans le coeur de la mission.

Pour connaître rapidement le contexte et les interactions de chacun des managers, j’aime utiliser mon jeu « Take the Win Win Wave (TWWW) ». Celui-ci permet d’avoir une température du fonctionnement de l’organisation:

– si le workflow est clair et rapidement dessiné: la structure est mature

– si le workflow ressemble…. disons voir…. à plutôt l’aspect… de…. d’un nuage… on a un soucis

Dans mon expérience, j’ai eu plus de « soucis » que de workflow clair. Sauf peut-être dans les équipes supports sous ITIL.

Phase de découverte

TWWW permet de découvrir quels sont les comportements du système (l’organisation) ainsi que l’interaction des personnes avec ce dernier. Comme décrit précédemment, ce comportement varie en fonction du métier, de la nature et de la culture.

Dans mon exemple, j’avais comme attente de voir émerger un ou plusieurs flux. Ce n’était pas le cas. Un nuage immense est en création et je me disais comment arriver à trouver de la consistance ou plutôt comment aider les participants à trouver leur chemin dans ces méandres. En clair, TWWW n’était pas du tout adapté à cette phase exploratoire.

L’adaptation d’un jeu

En voyant ces informations, je me suis dit qu’il fallait apporter un clef de décryptage simple pour entamer un tri, une réorganisation. Lors de différents ateliers de cadrage ou de service design, j’avais pu utiliser le « Prune Tree » et je me disais que ce serait une idée intéressante. Donc:

Capture d'écran 2014-09-20 12.07.33

 

Nous avons commencé à dessiner 3 lignes sur le nuage:

  • la ligne supérieure: « les fruits » qui sont les résultats ou les « outcomes ». Cela peut être un bénéfice, des euros, une valeur…
  • la ligne médiane: « les roots » ou les racines. Celles-ci sont les actions, les processus ou les articulations permettant aux fruits de se développer, de croître.
  • la ligne inférieure: la « BAU » ou « Business-as-usual ». Cela concerne tous le reste donc ni « fruits » ni « roots ». La BAU ne peut être éliminée, mais peut être contrôlée comme un « expedite » pour adepte de Lean Kanban.

Résultat: ce simple système de tri a donné aux participants un outil simple permettant de s’organiser de manière optimale. Cela fait un mois que l’on peut entendre plusieurs fois par heure les mots « fruits », « roots » et « BAU ». Pour information, dans de précédentes missions, j’ai constaté que certaines organisations mesuraient la « BAU ». Pas dans le même esprit qu’indiqué précédemment, mais les KPIs étaient sur la BAU et pas sur les « fruits ».

Qu’est-ce cela signifie?

  • KPI sur la « BAU »: je mesure le taux d’occupation des personnels, la consommation du budget et le respect des consignes, voir de l’interaction entre les silos fonctionnels (les directions, les services). Valeur de ce KPI pour l’entreprise: zéro.
  • KPI sur les « roots »: je mesure le processus, j’optimise le processus et je ne tiens pas compte des résultats. Un effet pervers est de mettre une structure, un projet en échec même si les processus ont été parfaitement respectés. En clair, mon arbre a plein de racines et de branches mais ne porte pas ou peu de fruits. Valeur de ce KPI pour l’entreprise: zéro.
  • KPI sur « fruits »: vous aurez compris. Je livre est la seule valeur à mesurer.

L’adaptation de « Fishbone »

« Fishbone » ou « Ishikawa » est un outil pour la « Root-cause » analyse. Dans mon contexte, je voulais essayer une approche graphique. Celle-ci a fait son effet.

Capture d'écran 2014-09-20 12.10.27

« Fisbone », dans mon cas, représente le flux designé par « TWWW », les arrêtes, elles, correspondent aux flux en parallèle. Si les flux restent en parallèle, nous avons une alteration du processus ou un « BAU ». L’objectif est de trier les flux de sorte à ce qu’ils parviennent à un flux principal tels des ruisseaux alimentant une rivière.

Capture d'écran 2014-09-20 12.12.14

Cela nous donne une extrapolation de « TWWW » suivant. « A » étant le point d’entrée, « B » le point de sortie.

Une fois le flux « clarifié », nous pouvons alors réfléchir aux personnes responsables de ces flux.

Les Rôles et Responsabilités

En tant normal, dans des organisations de taille importante, j’utilise le principe RACI:

  • R pour Responsable: c’est la personne qui performe le processus
  • A pour Accountable: c’est la personne qui est redevable de la réussite ou non du processus
  • C pour Consulté: c’est la personne qui doit être consultée pour réduire le risque, pour aider le bon déroulement du processus
  • I pour Informé: c’est la ou les personnes qui doivent être mise au courant.

Comme l’équipe était petite (20 personnes), nous nous sommes concentré sur R, A et I. Ce qui nous donne le graphe suivant:

Capture d'écran 2014-09-20 12.24.37

 

et l’agilité dans ce concept?

  • l’optimisation du flux est portée et construite par les personnes en charge de la production de ce dernier de manière « bottom-up »
  • les Rôles et Responsabilités ne sont pas liés à la fonction et permettent de s’assurer une bonne gouvernance du flux
  • la direction quant à elle, se concentre sur la protection de l’organisation et la fourniture des moyens nécessaires pour l’optimisation des résultats
  • le processus est empirique, ce qui permet de revoir et d’optimiser ce dernier et, in extenso, l’organisation
  • ici, l’organisation supporte la livraison de la valeur, la livraison des « fruits »

En conclusion

Toutes mes excuses pour les adeptes du Lean Six Sigma qui aurait procédés à un « Fishbone » suivi d’un « 5S » à grand renfort de DMAIC. Je l’avoue l’idée m’a effleurée mais nous aurions fait un grand écart en matière d’agilité.

Le dossier est bien sûr pas clos. Je reviendrai ultérieurement sur les nouvelles mesures qui ont émergées de cette approche.

 

Ah! j’oubliais… il a fallu 4 heures à des non-agilistes pour obtenir un résultat mis en place le jour même. Cool, non?

 

 

2 commentaires Ajoutez le vôtre

  1. idetido dit :

    A reblogué ceci sur agile coach under constructionet a ajouté:
    Une véritable leçon pour moi cet article. J’ai adoré l’analyse simple (donc brillante) des KPI.
    Merci Pierre.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s