Patrick Steyaert
Transcription (Traduit)
On commence ? D'accord.
Alors, qui a fait l'exposé en classe juste avant celui-ci ?
Super. Donc, je vais un peu m'appuyer sur cela.
C'est assez drôle qu'ils aient été programmés l'un après l'autre, car je vais continuer un peu sur certains des thèmes que Klaas a introduits. Mais il y aura aussi quelques différences. Donc, tandis que Klaas regarde un peu plus vers le haut, ce qui est... La chose naturelle que nous avons tendance à faire, je vais regarder un peu plus sur les côtés.
Donc, juste pour tester si vous avez prêté attention à l'exposé de Klaus, un petit quiz.
Alors, supposons qu'au niveau organisationnel, vraiment pas au niveau de l'équipe, mais au niveau organisationnel, vous ayez pu
augmenter considérablement votre taux de livraison, réduire considérablement votre délai de mise sur le marché, et tout en améliorant votre qualité.
Initiative agile. Est-ce que cela serait considéré comme un succès ?
Non.
Eh bien, pour la plupart des organisations, ce serait un succès. Mais pourtant, les gens font non de la tête. Pourquoi pas ?
Oui. Donc, nous avons peut-être accéléré la livraison de la mauvaise chose, n'est-ce pas ?
Oui.
Oui, enfin, pas entièrement. Mais laissez-moi expliquer. Laissez-moi expliquer. Donc, ce seraient des aspects d'une initiative de développement agile, n'est-ce pas ? Même si nous le faisons à grande échelle, nous parlerions d'améliorer notre développement agile. Et comme Klaus l'a déjà introduit, nous ne parlons pas des personnes, des entreprises aujourd'hui, les organisations aujourd'hui ne se contentent pas de regarder le développement agile. Elles regardent une entreprise agile. Donc, le travail commence beaucoup plus tôt. Il commence avec l'utilisateur, avec votre entreprise, avec votre client.
Donc, nous cherchons l'agilité métier, nous ne cherchons pas une optimisation locale dans votre petit ou grand silo informatique, de développement ou d'ingénierie. Nous regardons le flux de valeur de bout en bout.
Maintenant, afin de comprendre un peu ce concept d'agilité métier, parce que Ce terme a été un peu utilisé ces dernières années. Alors, que veux-je dire par cela ? Et afin de pouvoir expliquer cela, je dois faire... Un pas en arrière. Alors, comment délivrons-nous l'agilité aujourd'hui ? Quelle est notre principale façon de délivrer l'agilité aujourd'hui ?
C'est par les méthodes agiles, n'est-ce pas ? Par les méthodes lean et agiles. C'est la principale façon dont nous introduisons l'agilité dans les organisations. En commençant quelque part il y a environ 20 ans avec des méthodes comme XP et Scrum. Et même avant, il y avait certaines méthodes. En commençant par XP et Scrum, puis
une sorte d'explosion cambrienne, avec une nouvelle vague de méthodes qui tendent chacune, étrangement, à se concentrer sur un aspect particulier de l'agilité.
Ainsi, GAMMAN se concentre davantage sur l'équilibre et le flux,
Les méthodes, les méthodes autogérées en termes d'holacratie, de sociocratie, des méthodes qui se concentrent vraiment sur la partie organisationnelle, sur les personnes et les interactions. Et puis des méthodes comme Lean Startup qui se concentrent vraiment sur la partie apprentissage, l'apprentissage itératif, la gestion de l'incertitude.
Étrangement, cette deuxième génération de méthodes agiles semble se concentrer chacune sur un aspect particulier de l'agilité. Donc, il semble y avoir une spécialisation en cours.
Alors, qu'est-ce que cela nous apporte ? En termes d'agilité métier, qu'est-ce que cela nous apporte ? Eh bien, cela nous apporte pas mal de bonnes choses. Si nous regardons la perspective de flux, passant de la concentration sur l'occupation des mains à mieux répondre à la demande du client.
C'est comme la perspective CAMMAN. En termes d'apprentissage, donc la perspective Lean Startup, ne pas se concentrer sur les outputs, mais sur les outcomes. Et puis en termes de perspective organisationnelle, pas vraiment la division du travail et le commandement et contrôle, mais se concentrer sur les équipes autogérées. Donc, cela nous apporte... les ingrédients de base de ce que vous appelleriez l'agilité métier.
Mais ce que nous ne voyons pas, ou... Ce que nous voyons en quelque sorte, ce sont ces îlots d'agilité, n'est-ce pas ? Donc, nous avons les ingrédients, nous avons les ingrédients, mais ils semblent vivre tous sur leurs petits îlots.
Et pas seulement comme différentes communautés qui vivent chacune dans leur petit silo, mais aussi dans les organisations, nous voyons cela. Donc, cette partie de l'organisation fait du Kanban et du Scrum dans un contexte SAFe, et puis peut-être que l'incubateur ou la partie plateforme numérique fait du Lean Startup, Et l'entreprise fait de l'holacratie ou une forme de sociocratie ou d'autogestion.
Et puis vous allez dans un atelier et vous avez différentes parties de l'organisation présentes et vous devez pouvoir parler à toutes. Maintenant, cela est assez éloigné de l'agilité métier, n'est-ce pas ? Nous avons ces petits îlots d'agilité à travers l'organisation. Et ce qui nous manque... Ce que nous ne voyons pas, c'est l'océan bleu entourant ceux-ci.
Îlots d'agilité, qui sont encore remplis des reliques du passé, n'est-ce pas ? Les reliques de la gestion du 20ème siècle.
Des reliques comme la division du travail, le commandement et contrôle. La pensée dominante est encore un type de pensée très déterministe et réductionniste. Et nous voyons les reliques de cela.
Nous ne relions pas ces îlots. Surtout en amont, où nous avons des choses comme les portes de phase, le portefeuille, le portefeuille n'est pas un flux, c'est un stock. C'est une vue statique.
Donc, nous voyons encore ces reliques qui entravent quelque peu notre réflexion sur le fait de devenir vraiment agile en tant qu'organisation entière.
Alors, quels sont certains des symptômes que vous pourriez reconnaître ?
Donc, un symptôme est, surtout dans cette division entre l'entreprise et puis le côté livraison des choses, où nous devenons beaucoup plus agiles du côté livraison, donc notre cadence de livraison s'accélère. Maintenant, si notre cadence du côté de la demande, où nous devons prendre pas mal de décisions, et que le processus de prise de décision a encore cette cadence de, comme, trimestrielle, ou même annuelle, le cycle budgétaire annuel, Vous créez un assez grand écart entre les deux. Vous créez un assez grand décalage entre le côté demande et le côté livraison. Oui, nous sommes capables de livrer. Nous avons une cadence de livraison trimestrielle ou hebdomadaire, bi-hebdomadaire ou même quotidienne. Mais notre processus de prise de décision est encore un processus de prise de décision annuel, autour du budget annuel.
Donc, un effet que vous pourriez voir en conséquence de ce processus de prise de décision très lent du côté de la demande, est que votre demande est comme
fluctuante assez fortement.
Nous voyons cette fluctuation saisonnière. Tout le travail est libéré dans l'organisation au début de l'année. Et à la fin de l'année, nous devons dépenser nos budgets.
Donc, nous voyons cette grande fluctuation de la demande.
Du côté livraison, nous disons, comme, les gars, nous n'avons pas de travail. Et puis soudainement,
on a comme des tonnes de travail. Donc on alterne entre des périodes où on est surchargés et des périodes où il faut regarder autour de nous et se demander, quel travail peut-on faire ? On manque de travail.
Et surtout parce qu'il y a cette mentalité de La demande fluctue et nous devons adapter notre capacité à cette demande fluctuante. Nous devons monter en puissance parce que notre demande augmente et nous devons réduire la voilure parce que notre demande diminue. Alors, comment faisons-nous face à cela ? Avec cela, comme ce besoin de monter en capacité et de réduire la capacité.
On ouvre une boîte de développeurs. De nouveaux développeurs.
De nouvelles personnes.
Et puis quand on n'a plus besoin de ces personnes, que fait-on ?
On libère la connaissance, n'est-ce pas ? Parce qu'elle sort par la porte. Donc beaucoup de gaspillage.
Et puis, peut-être le plus important, nous finissons par une création de valeur sous-optimale.
Nous avons tendance à sous-livrer sur les demandes à haut risque et à haute valeur. Nous avons donc tendance à
ne pas très bien pouvoir faire face ou livrer très bien des initiatives à haute valeur, mais où la valeur pourrait être incertaine. Et j'expliquerai un peu pourquoi dans un instant.
Mais juste pour faire référence aux classes, reparlons-en. Vous vous souvenez de la grande partie en amont où nous devons prendre beaucoup de décisions ? Eh bien, les éléments à haute valeur et à haut risque ont tendance à y rester bloqués. Ils mettent beaucoup de temps à démarrer.
Et donc ils y restent bloqués. Nous sommes donc très lents, les délais pour ceux-ci sont très longs. Et non seulement cela, une fois qu'ils sont démarrés, nous avons du mal. à les livrer en raison, par exemple, de la montée en puissance.
Donc on voit des organisations ou je vois des organisations qui sous-livrent largement sur les demandes à haute valeur et à haut risque et qui sur-livrent sur les demandes à faible valeur et à faible risque parce que en périodes de disette, que faisons-nous ? On commence à travailler sur ce type de demande. Et d'un autre côté, on voit aussi des organisations qui se concentrent uniquement sur les éléments à haute valeur et à haut risque, et il n'y a aucune livraison sur les demandes à faible valeur et à faible risque. Donc au final, notre livraison de valeur est assez sous-optimale.
Donc, je pense...
L'amont est en quelque sorte la partie la plus importante du processus. Oui, nous devons examiner le côté livraison et améliorer notre capacité à livrer. Oui, nous devons faire cela.
Et nous devons le faire à grande échelle.
En coordonnant plusieurs équipes et ainsi de suite. Mais la plupart des gains aujourd'hui dans la plupart des organisations ne sont pas là. Ils sont en amont. En s'assurant que vous faites les bons choix en amont, que vous façonnez la demande, et que vous vous concentrez sur les bonnes choses au bon moment. Donc la plupart des gains peuvent être réalisés en amont.
Nous devons donc regarder l'ensemble. Nous devons examiner le flux de bout en bout, et non pas simplement optimiser une partie, mais optimiser le flux de bout en bout du début à la fin. C'est ici que je ne suis pas d'accord avec mon précédent intervenant. Mais la plupart des gains aujourd'hui dans la plupart des organisations ne sont pas là. Ils se trouvent en amont. En veillant à faire les bons choix en amont, à façonner la demande.
Et à se concentrer sur les bonnes choses au bon moment. Donc la plupart des gains peuvent être réalisés en amont.
Nous devons donc considérer l'ensemble. Nous devons examiner le flux de bout en bout, et non pas seulement optimiser une partie, mais optimiser le flux de bout en bout, du début à la fin. C'est ici que je ne suis pas d'accord avec mon précédent intervenant. Je ne pense pas que l'amont soit simple. Je pense en fait que cela nécessite beaucoup d'attention. Cela nécessite beaucoup d'attention. Alors, quels sont les défis en amont ? Quels sont les défis dans la gestion de la demande ? Voilà ce que les gens considèrent généralement comme le défi en amont. C'est vraiment le défi de faire une sélection, n'est-ce pas ?
Au sommet de l'amont, nous le voyons comme un entonnoir. Et au sommet de l'entonnoir, nous avons toutes ces opportunités, toute cette demande qui arrive. Et ensuite, nous devons faire une sorte de sélection parce que le bas de l'entonnoir est comme ce petit pipeline, et nous avons toujours plus de demande que nous ne pouvons en satisfaire, donc ce petit pipeline est le goulot d'étranglement en termes de livraison. Donc la sélection est conçue comme le grand défi à cet endroit. Je pense que c'est... Une mauvaise représentation.
Si c'était notre défi, ce serait si simple. Je pense que le défi est bien plus profond que cela. Alors, laissez-moi expliquer.
Donc une partie du défi est de surmonter les frictions.
La diapositive précédente montrait cet entonnoir et la sélection dans l'entonnoir. Et cela nous donne l'image que la sélection est comme Nous mettons toutes les alternatives les unes à côté des autres, nous les notons d'une manière ou d'une autre, et nous les évaluons les unes par rapport aux autres. N'est-ce pas ? D'accord ? Et c'est ça, la sélection. Mais la réalité est que ces initiatives, ces opportunités, la demande, n'arrivent pas Toutes ensemble. Elles arrivent, une semaine vous avez une opportunité, la deuxième semaine vous n'en avez aucune, la troisième semaine vous en avez trois, Elles arrivent de manière très inégale. N'est-ce pas ? Alors, comment faites-vous une sélection lorsque la demande arrive de manière très inégale ? Comment faites-vous une sélection dans ce cas ?
Que faisons-nous pour y parvenir ? Nous regroupons nos opportunités. Nous faisons un cycle de budgétisation annuel pour les regrouper afin de pouvoir faire une sélection. Mais savez-vous ce qui se passe si nous les regroupons ?
Nous obtenons un grand décalage entre le côté demande et le côté livraison. Nous obtenons cette énorme fluctuation de la demande. Ce qui n'est pas ce que nous voulons. Donc le vrai défi pour moi est qu'en aval, du côté de la livraison, ici, dans ce petit pipeline, nous savons maintenant qu'il est préférable de l'organiser autour d'un flux très stable et régulier. C'est ce que nous avons découvert jusqu'à présent, je pense. Il est donc préférable d'avoir un flux entrant stable de travail et que l'équipe puisse s'organiser autour d'un flux entrant très stable de travail. Mais savez-vous quoi ? En haut, Du côté de la demande, du côté des opportunités, c'est très inégal. Cela arrive quand cela arrive. Et le défi pour l'amont est... est de surmonter cet écart, de combler l'écart entre une demande entrante très fluctuante et un flux stable vers votre livraison.
Et ce défi est encore aggravé ou rendu plus difficile parce qu'entre les deux, nous devons prendre ces décisions. Et ces décisions nécessitent généralement des personnes plus haut placées dans la hiérarchie. Donc des personnes qui ne sont pas toujours disponibles ou des personnes dans l'entreprise, des personnes qui ne sont pas nécessairement disponibles instantanément. Donc encore une fois, cela rend la fluctuation de la demande encore pire.
Donc c'est une partie du défi, et je pense une partie principale du défi. Comment surmonter cet écart, cette friction ?
Une autre partie est évidemment la gestion de l'incertitude.
Maintenant, je pense que nous avons désormais une certaine conception de la manière de gérer cela.
Gérer l'incertitude dans le sens où toute la demande n'est pas égale. Certaines demandes peuvent avoir une valeur moindre, mais avec cette valeur moindre vient une plus grande certitude.
N'est-ce pas ? Faible valeur mais très certaine, ou faible risque. C'est une certaine demande. D'autres demandes ont une valeur beaucoup plus élevée, un potentiel plus élevé. valeur, mais par conséquent aussi une plus grande incertitude.
Donc ce sont différents types de valeur et ils nécessitent différentes façons de les traiter.
Mais je pense que cela est désormais assez bien établi. Faible valeur, faible incertitude, surtout faible incertitude.
Nous pouvons immédiatement nous engager à les exécuter. Donc c'est un processus en une étape. Si vous parlez de haute incertitude ou de faible certitude, vous devez avoir un processus en plusieurs étapes, n'est-ce pas ? Donc plutôt que de s'engager immédiatement, nous disons que nous allons faire une première étape, nous prenons une option sur la valeur, puis nous exerçons cette option en termes
d'engagement, n'est-ce pas ? Donc c'est toute la réflexion autour, par exemple, de la pensée MVP. Nous développons d'abord un produit minimum viable. C'est notre option. En fonction des résultats, nous évoluons. Donc c'est un processus en deux étapes. Encore une fois, en amont, nous devons gérer cette incertitude et voir quelle voie nous allons prendre. Et enfin, oh, enfin,
Je pense qu'un problème plus important de mentalité est le problème de la prise de commande que nous devons surmonter. Nous organisons pas mal d'ateliers en amont. Et à la fin de l'atelier, il peut encore rester des personnes qui disent, oui, mais en fin de compte, si le client demande, nous devons livrer. D'accord ? Nous avons donc réussi d'une manière ou d'une autre à établir une mentalité de prise de commande dans les organisations. Et le fait que vous puissiez réellement façonner la demande, le fait que toute la demande ne soit pas irrévocable, est un obstacle assez important à surmonter. Que si la demande du client est faible, vous pouvez en fait influencer le client pour créer plus de demande. Et d'autre part, si la demande est élevée, vous pouvez en fait influencer le client en termes de réduction de la demande ou de modification de la demande d'une manière mieux adaptée à la livraison. C'est donc une pièce à deux faces. Ce n'est pas seulement améliorer la capacité à livrer, Mais le client a également un intérêt à façonner la demande afin que nous utilisions mieux notre capacité de livraison.
C'est donc une pièce à deux faces.
Et je pense que cette mentalité est... reste encore un défi assez important à établir.
D'accord, donc c'est en quelque sorte la théorie. Regardons un exemple concret.
Donc, point de départ. Donc, ceci est un système KEMAN.
Pour une équipe de maintenance informatique.
Et donc, comme vous pouvez le voir très typiquement, ici nous sommes dans une situation où nous avons une visualisation, un tableau pour l'amont ainsi que pour l'aval. Mais la partie CAMMAM est vraiment seulement ici. Donc, nous n'avons un vrai système Kanban que du côté de la livraison. Ici, nous avons une visualisation, mais pas encore un vrai système Kanban. Donc, qu'est-ce que je veux dire par là ? Ici, nous contrôlons le travail en cours, nous gérons le flux. Nous contrôlons le travail en cours, donc nous avons des contraintes de WIP en place. Nous gérons les délais d'exécution, et ainsi de suite. Ici, cette partie, et en fait cette partie, Nous visualisons simplement ce qui s'y trouve.
Cette partie est fortement influencée par les utilisateurs. C'est le test d'acceptation utilisateur. Donc, c'est pourquoi ce n'est pas contraint, parce que nous ne pouvons pas contraindre les utilisateurs. Cette partie, de même.
Donc, agilité émergente.
Donc, dans ce cas, contrairement à ce que Klaus a montré, nous avons en fait pas mal d'améliorations.
Donc, nous pouvons parler de succès dans le sens où nous voyons nos délais d'exécution réduits de moitié grâce au système Kanban.
Les délais d'exécution ont été réduits de moitié, notre débit a légèrement augmenté. Si vous regardez, ceci est un diagramme de flux cumulatif, donc si vous regardez la ligne de livraison, qui est cette ligne ici, vous voyez qu'elle s'incurve un peu vers le haut, ce qui signifie que notre taux de livraison augmente légèrement. Et en fait, il y a aussi des indications que la qualité s'améliorait également. Succès ?
Oui ? Donc, succès. C'est aussi ce que l'équipe a trouvé. C'est ce qu'ils ont rapporté à leurs clients, qui sont les partenaires commerciaux.
C'est aussi ce qu'ils ont constaté. Jusqu'au moment où vous parlez avec certains des utilisateurs métiers, Et ils disent comme, oui, Patrick, c'est bien.
Nous sommes convaincus que l'équipe fait de son mieux pour s'améliorer et nous voyons les résultats de cela.
Mais vous savez quoi ? Pour nous, L'horloge ne commence pas à tourner quand l'équipe commence à travailler dessus. L'horloge commence à tourner quand nous émettons la demande.
En même temps, le manager de l'équipe vient vous voir et dit comme, oui, Patrick, nous sommes maintenant meilleurs pour livrer, mais je ne suis pas convaincu que nous livrons les bonnes choses.
Donc, en termes d'ascension de notre montagne vers l'agilité métier, oui, nous avons fait ce premier pas, et je pense un pas important, mais ce n'est qu'un pas.
Que voyez-vous ? Donc, oui, nous avons amélioré cette partie du flux. Mais que voyez-vous dans le flux final ? Que voyez-vous en amont ?
Eh bien, il y a au moins une chose remarquable sur le tableau ici.
N'est-ce pas ? Il y a une chose remarquable sur le tableau ici en amont, c'est que nous avons une bulle dans notre pipeline.
Nous avons une bulle dans notre pipeline. Donc, nous avons ce que j'appelle un flux en haltère. Un flux en haltère est comme l'haltère. Et le poids est... Aux extrémités opposées et rien au milieu. Donc, nous avons un flux en haltère. Dans le sens où nous avons pas mal d'éléments en cours, en attente, désolé, en attente dans notre inventaire ou notre backlog, juste devant le point où nous nous engageons. Donc, ceci est l'amont. Voici notre point d'engagement où nous nous engageons sur le travail. Et voici la livraison. Donc, juste devant le point d'engagement, Nous avons un gros lot de travail en attente.
Ensuite, dans le processus amont proprement dit, nous n'avons aucun travail et puis nous voyons pas mal de travail bloqué tôt dans le processus. Maintenant, si vous regardez de plus près, vous verrez qu'une grande partie de ceci est de faible valeur, faible
Et puis une grande partie de ceci est de haute valeur, haut risque. Donc, ce qui se passe ici, c'est que nous avons un processus de prise de décision à certains points en amont. Et ce qui se passe, c'est que les éléments de faible valeur, faible risque rencontrent peu de friction dans cet amont.
Il y a peu de discussion sur les éléments de faible valeur, faible risque. Oui, c'est de faible valeur, faible risque, nous approuvons. Faible priorité, mais nous l'avons analysé, nous l'avons estimé, nous l'approuvons, c'est fait.
Où voyons-nous la discussion ? Où voyons-nous beaucoup de friction ? Évidemment dans les éléments de haute valeur, haut risque. Et ils restent bloqués très tôt dans l'amont.
Donc, que se passe-t-il quand ils restent bloqués dans l'amont ? Et ils restent bloqués très tôt en amont.
Que se passe-t-il lorsqu'ils restent bloqués en amont ? Ces éléments de haute valeur et haut risque. Et les gens en discutent. Il y a des opinions différentes entre les parties prenantes. Que pensez-vous qu'il se passera à un certain moment ?
La direction supérieure appelle et dit, vous devez le faire maintenant.
Donc l'équipe s'occupe, car nous devons garder les mains occupées. L'équipe s'occupe. Donc ils commencent ce travail de faible valeur et faible risque, et puis à un certain moment, Il y a une intervention de la direction supérieure disant que cette initiative devient urgente, vous devez vraiment la faire maintenant. Ainsi, les demandes de haute valeur qui étaient bloquées tôt en amont sont accélérées. Même si le travail n'est pas préparé ou bien analysé, nous devons commencer à le faire.
Et nous devons nous engager en plus du travail déjà engagé par l'équipe.
Donc oui, l'équipe fera de son mieux pour respecter ses contraintes de travail en cours. Mais vous verrez qu'ils commenceront à travailler à leur maximum de travail en cours.
Donc, en fin de compte, nous avons un flux en aval très irrégulier, en raison de cette dynamique en amont, nous avons un flux en aval très irrégulier où il y a des moments où l'équipe doit inventer du travail et des moments où l'équipe est surchargée par beaucoup de travail.
Ainsi, le résultat final est des délais de livraison clients très longs. Donc, comment cela explique-t-il les longs délais de livraison clients ? Donc, nos délais de livraison du système deviennent plus courts et plus stables, mais les délais de livraison clients de bout en bout, le délai entre le début d'une demande et sa livraison effective sont assez longs. Et la raison en est bien sûr les éléments de faible valeur qui restent bloqués avant le point d'engagement.
Ils y restent et y vieillissent. Certains y meurent.
Donc leurs délais de livraison deviennent longs.
Et les délais de livraison des éléments de haute valeur et haut risque sont également longs parce qu'ils restent bloqués tôt dans le processus.
Donc, globalement, des délais de livraison clients très longs. Client satisfait ? Pas vraiment. Pas vraiment.
Donc, le défi spécifique en amont que nous avions dans ce cas est
toute la demande doit être analysée et traitée en priorité. Et afin de déterminer la priorité, nous devons les analyser. Et plus nous les analysons pour déterminer la priorité,
plus le délai en amont devient long.
La prise de décision provoque le retard, en particulier pour les éléments de haute valeur. Et en fin de compte, nous avons un grand arriéré de demandes de faible valeur vieillissantes. Et ensuite, la demande de haute valeur doit être accélérée et précipitée parce qu'elle est restée bloquée.
Donc, nous devons faire quelque chose à ce sujet. Nous devons faire quelque chose à ce sujet.
Donc, pour faire face à la pénurie, c'est-à-dire les périodes où l'équipe n'a pas de travail, il existe une technique établie issue de la logistique.
Donc, ils ont établi cette technique afin de s'assurer dans l'entrepôt que vous ne manquez jamais de pièces en établissant des points de commande.
Donc, un point de commande est, supposons que ce sont les éléments de travail que vous avez ou l'inventaire que vous avez.
Cet inventaire diminuera parce que vous livrez.
Cet inventaire diminuera parce que vous livrez.
S'il descend en dessous d'un certain point, en dessous du point de commande, que faites-vous ? Vous commandez afin d'avoir à nouveau suffisamment d'éléments de travail prêts à être livrés.
Et où établissez-vous ce point de commande ? Eh bien, vous l'établissez si le délai pour la commande est aussi long, vous voulez vous assurer que vous établissez, vous commandez juste à temps pour qu'il ne descende pas en dessous d'un certain stock de sécurité. D'accord ? Donc, en termes simples, cela signifie que supposons que vous êtes une équipe en aval qui livre cinq éléments de travail par semaine, d'accord, et qu'il faut deux semaines en amont pour préparer un élément de travail, où placez-vous votre point de commande ? Oui, quelque part un peu au-dessus de 10. De sorte qu'à tout moment, Vous pouvez survivre pendant deux semaines. L'équipe en aval peut toujours survivre pendant deux semaines. Elle a toujours un arriéré suffisant pour deux semaines qu'elle peut continuer à travailler pendant deux semaines. D'accord ? C'est votre point de commande.
Donc, c'est une partie de la solution, les points de commande.
Éviter la pénurie. L'autre partie consiste à gérer l'incertitude. Donc, dans le processus qui a été établi, toutes les demandes doivent être analysées par l'équipe.
Et il n'y avait pas de différenciation entre les demandes qui présentaient plus d'incertitude et celles qui en présentaient moins.
Nous avons donc établi une nouvelle façon de travailler où nous différencions les demandes qui présentent une grande incertitude de celles qui présentent peu d'incertitude. Pour les demandes présentant peu d'incertitude, nous capturons les demandes et nous les analysons immédiatement.
Nous les analysons immédiatement. Il n'y a donc pas d'étape intermédiaire. Pour les demandes à haute incertitude, ou faible certitude, nous capturons la demande. Nous nous assurons d'abord avec une équipe,
avec un groupe de parties prenantes et ensuite les bonnes personnes de la livraison. Nous nous assurons d'avoir une compréhension correcte de ce qui est nécessaire sans entrer dans les détails. Donc, c'est une étape de synthèse avant que nous ne fassions réellement l'analyse. Donc, nous avons un processus en deux étapes.
Nous gérons donc l'incertitude en amont. Et enfin, nous mettons en place un système de triage. C'est un concept assez central pour l'amont. Je sais que beaucoup de gens utilisent le mot triage comme synonyme de sélection. Mais ce n'est pas un synonyme de sélection. C'est vraiment quelque chose de différent.
Donc, le triage comme dans un hôpital de campagne ou comme dans un service d'urgence de l'hôpital, n'est-ce pas ? Aussi dans un hôpital de campagne ou dans un service d'urgence, la demande est bien plus élevée que la capacité de livraison. Et alors, comment faisons-nous face à cela ? Ainsi, nous colorons nos demandes. Les demandes sont colorées en termes de noir, Noir signifie que nous ne pensons pas que ceci soit une demande valide. Donc, cela doit être escaladé. La prise de décision doit être escaladée. Ce n'est pas une demande valide. Dans un hôpital de campagne, le noir a une signification différente, mais c'est plus comme si cela ne survivra pas au processus.
Donc, dans notre cas, nous ne pensons pas que cela survivra à notre processus, donc nous devons escalader la décision. Rouge, c'est si nous agissons maintenant, nous pouvons sauver le patient, mais nous devons agir maintenant. Donc rouge signifie tout le monde sur le pont. Nous devons accélérer les demandes. La maison est en feu.
Donc, la partie intéressante se situe entre les demandes jaunes et vertes. Donc jaune signifie que ceci est potentiellement un élément de haute valeur, mais aussi un élément à haut risque. Donc, c'est un élément qui pourrait potentiellement rester bloqué en amont. Nous devons donc influencer le timing ici, car nous savons que si nous n'influençons pas le timing, si nous ne sommes pas proactifs sur cet élément, il restera bloqué en amont jusqu'à ce qu'il soit accéléré.
Nous prenons donc réellement soin de notre client. Le client peut émettre une demande puis l'oublier ou ne pas agir dessus jusqu'au moment où elle devient urgente pour le client et ensuite elle est accélérée. Donc, ce que nous faisons, c'est que nous allons être proactifs envers notre client et dire que nous devons travailler sur ceci. C'est comme préparer une présentation pour une conférence. Si vous attendez jusqu'au dernier moment, vous n'avez pas assez de temps pour incuber vos idées. Vous n'avez pas assez de temps pour laisser mûrir les idées. Que faites-vous alors ? Vous allez être proactif. Vous commencez. À temps, mais vous vous engagez tard. Donc, vous allez être préventif sur ces éléments.
Les éléments verts. Donc, ce sont les éléments qui précédemment sont restés bloqués avant le point d'engagement. Donc, ce sont les éléments qui sont restés bloqués dans notre backlog. Nous avons fait l'analyse, nous avons fait le scoring, nous les avons évalués, et ensuite ils restent là.
Que faisons-nous avec les éléments verts ?
Nous ne les regardons même pas. Nous les classons simplement comme verts. Donc, c'est le patient qui arrive aux urgences et dit, oh, je suis en train de mourir. J'ai une coupure à mon... doigt et je dois voir le spécialiste tout de suite. Donc ce patient reçoit un bracelet vert, d'accord ? Et ils ne vont même pas commencer un quelconque type de diagnostic. Ils vont simplement dire, allez vous asseoir dans la salle d'attente,
Et vous pourriez y rester trois, quatre, cinq, six heures.
Est-ce drôle pour le patient ? Non.
Mais c'est pour s'assurer que tout le monde est servi de manière optimale.
Donc les éléments verts resteront très tôt dans le backlog, aussi en amont que possible. Nous les trions simplement et c'est tout. Quand commençons-nous à les traiter ? Quand nous avons le temps, quand nous avons de la capacité. Donc nous les tirons quand nous avons de la capacité.
Donc en combinaison, vous devez prendre tous ces éléments ensemble. Cela nous donne un système Kanban en amont.
Donc un système Kanban en amont où vous avez des points de commande. Afin de s'assurer que l'équipe se voit toujours présenter le bon mélange de travail. Dans ce cas, nous avons un point de commande pour les éléments à haut risque, à haute valeur, et un point de commande... Oups. Ouh, ouh, ouh.
Désolé. Et un point de commande pour les éléments de faible valeur, à faible risque, car nous voulons allouer de la capacité à l'équipe en termes de s'assurer qu'ils travaillent toujours sur au moins un élément de haute valeur, à haut risque, mais aussi qu'ils aient toujours disponibles certains éléments de faible valeur, à faible risque à tirer, de sorte que nous ayons un bon équilibre dans la valeur que nous créons.
Donc nous avons des points de commande en amont. Nous avons un triage tôt, et le triage n'est pas seulement une sélection, mais vraiment un routage à travers l'amont.
Les éléments jaunes sont routés à travers un processus plus long où nous avons un engagement en deux étapes. De sorte que nous ne nous engageons pas immédiatement, mais que nous puissions avoir un engagement basé sur un processus très léger d'abord, avant de faire l'engagement complet.
Et nous sommes préventifs à leur sujet, donc ils sont un peu poussés dans l'amont.
Et ensuite, nous avons les éléments verts qui sautent complètement ce processus en deux étapes et vont directement en analyse. Et ceux-là, nous les tirons simplement au fur et à mesure que nous en avons besoin. Nous les tirons quand...
n'atteignant pas notre point de commande.
Donc le point de commande donne de la concentration à l'équipe.
J'ai eu plusieurs équipes qui, en fait, lorsque le point de commande n'est pas rempli, mettent une grande étiquette
sur le backlog avec un squelette disant famine.
Comme un signal clair à l'amont pour dire que nous avons besoin de travail. Nous avons besoin de travail. Nous avons besoin du bon type de travail.
Donc c'est un signal clair pour collaborer afin de s'assurer que nous avons le bon type de travail au bon moment.
Donc maintenant, nous façonnons la demande. Maintenant, nous façonnons la demande. Nous ne prenons pas simplement des commandes. Si nécessaire, les personnes en aval qui sont du côté droit du tableau viennent aider en amont s'il y a un danger de famine. Donc, nous avons vraiment un point de concentration pour façonner la demande et non pas simplement prendre la demande telle quelle.
Donc, dans notre ascension vers l'agilité métier, y sommes-nous déjà ?
Clairement, nous avons fait un pas en avant, passant de la prise de commande au façonnage de la demande. Nous n'y sommes peut-être pas encore entièrement.
Malgré les points de commande malgré le DDH, les utilisateurs métiers peuvent encore avoir cette mentalité de poussée.
Donc, bien que dans l'équipe nous ayons établi des limites de travail en cours, des contraintes, qui créent une mentalité de tirage dans l'équipe, nous avons encore un client qui a une mentalité de poussée. Dans le sens de pousser des demandes de ce côté du tableau et de ne pas tirer le travail de l'autre côté du tableau. Donc, une plainte de l'équipe est que le client est là pour demander de nouveaux travaux, mais si nous avons besoin d'aide, pour finir le travail, ils ne sont pas disponibles pour nous aider.
Donc, nous avons encore une mentalité de poussée du côté du client.
Alors, comment faisons-nous face à cela ? Un mécanisme très simple, un responsable client Kanban. Donc, le responsable client Kanban, c'est que les différents
groupes métiers reçoivent une sorte d'argent, ils reçoivent des jetons Kanban, et ils ont besoin de jetons Kanban pour démarrer une demande. Tout le monde peut émettre une demande, ce n'est pas un problème, mais si vous voulez qu'une demande soit traitée, vous avez besoin d'un jeton Kanban en tant que client.
Quand récupèrent-ils leur jeton Kanban ?
quand la demande est terminée.
D'accord, quand la demande est terminée. Maintenant, cela implique clairement le client, ou engage le client dans le processus de bout en bout, car si le client veut démarrer une nouvelle demande, une demande précédente doit être terminée.
Cela ne signifie pas que le client ne peut avoir qu'une seule demande, il peut en avoir plusieurs en fonction du nombre de jetons CAMMAN que le client possède. Donc maintenant, nous promouvons la collaboration non seulement au sein de l'équipe, mais nous facilitons également la collaboration entre l'équipe et le client.
Alors, y sommes-nous déjà ?
Donc, nous passons de la prise de commande à la définition de la demande pour collaborer avec le client.
Y sommes-nous déjà ?
Eh bien, peut-être pas entièrement.
Et je vais passer très rapidement sur ceci, car quelqu'un en arrière-plan dit quelque chose. Donc, je vais passer rapidement sur ceci. Évidemment, nous devons encore faire face à l'incertitude à un niveau plus profond, l'incertitude en termes de viabilité, de faisabilité, d'attractivité de ce que nous construisons. Donc ici, nous parlons non seulement d'une boucle de rétroaction au sein de l'équipe ou d'une boucle de rétroaction au sein de l'organisation, mais nous parlons de la boucle de rétroaction revenant de vrais clients, de vrais utilisateurs vers l'équipe et comment faire face à cela. Donc, il s'agit de tout le processus d'apprentissage autour de l'incertitude. Encore une fois, et je ne vais pas entrer dans les détails, nous pouvons parler des systèmes CAMMAN qui soutiennent ce processus. Ceci est tout le domaine du CAMMAN de découverte.
Donc, le Discovery Camp, il s'agit vraiment de soutenir le processus d'apprentissage, de gérer les expériences, de gérer les observations, de gérer la boucle de décision stratégique, en fin de compte, de gérer l'incertitude.
Fonctionner à plein régime.
Donc maintenant, nous parlons d'agilité métier en termes de vraiment fonctionner à plein régime. Ne pas avoir ces cylindres séparés où dans une partie de l'organisation nous nous concentrons sur le flux, dans une autre partie de l'organisation nous nous concentrons sur l'apprentissage, et dans la troisième partie de l'organisation nous nous concentrons sur l'organisation. Maintenant, nous parlons vraiment de l'interaction entre ceux-ci. Donc avec le CAMMAN en amont, vous ne pouvez pas très bien le lire dans la partie bleue là, le CAMMAN en amont se concentre sur le passage de la satisfaction de la demande à la définition de la demande.
Le Customer CamMan sur la droite, en termes non seulement de collaboration au sein de l'équipe, mais de collaboration avec vos clients.
Et puis le Discovery CamMan en termes de concentration sur l'apprentissage.
Donc, des systèmes CamMan qui couvrent vraiment les trois aspects de l'agilité métier.
Il y a un e-book gratuit que vous pouvez télécharger depuis le site de LKU, qui couvre en quelque sorte le matériel que j'ai abordé dans cette présentation. Il se concentre sur le CAMMAN en amont. Il se concentre vraiment sur le CAMMAN en amont, moins sur le Discovery CAMMAN.
Avec ceci, je tiens à vous remercier.