David Anderson
Transcription (Traduit)
D'accord, bonjour.
Je pense que nous devrions commencer dans l'intérêt de faire avancer le programme.
D'accord, merci d'être venus. Je viens d'apprendre que la participation cette année est en hausse de plus de 100 % par rapport aux années précédentes, donc un excellent résultat pour les organisateurs. Et j'aimerais les remercier à nouveau pour leur persévérance à organiser cela chaque année. C'est formidable que nous ayons une opportunité et une plateforme pour partager nos idées avec le public ici à Paris.
Ceux d'entre vous qui étaient ici l'année dernière se souviendront qu'à la fin de mon intervention, j'ai parlé d'une idée appelée Enterprise Services Planning. En tant que futur de Kanban et cette année, je reviens pour parler de ce que cela signifie vraiment. Donc, Enterprise Services Planning, étendre les avantages de Kanban.
Alors, à quoi pensons-nous ici ? Eh bien, la clé de cela est Vous travaillez dans une organisation de services professionnels.
Depuis environ 100 ans maintenant, les comptables ont des méthodes pour gérer les entreprises, et à cette époque, toutes les entreprises étaient physiques.
Donc, lorsque des types de travail sont apparus qui n'étaient pas physiques, ils avaient besoin d'un moyen d'exprimer ce que c'était et de le comptabiliser. Et ils ont adopté ce terme de biens immatériels.
Toutes les entreprises qui traitent des biens immatériels sont classées comme des services professionnels. Donc, si vous faites quoi que ce soit qui implique de penser pour gagner votre vie, vous êtes dans une entreprise de services professionnels.
Et les entreprises de services professionnels sont des écosystèmes de nombreux services interdépendants.
Ces interdépendances sont de nature complexe. Et cela rend la gestion des entreprises de ce type très différente de la gestion d'une entreprise physique, qu'il s'agisse d'une entreprise de fabrication, d'un lieu d'événement, d'un hôtel, d'un café, d'un restaurant ou d'une chaîne de distribution.
Chaîne de vente au détail et ainsi de suite, toutes ces entreprises sont des entreprises physiques. Les entreprises de services professionnels ont des biens immatériels. Cela signifie que vous ne pouvez pas les prendre, vous ne pouvez pas les stocker dans un entrepôt, vous ne pouvez pas vous promener et les compter. Vous ne pouvez pas faire des choses simples et évidentes que les managers d'entreprises physiques peuvent faire. Donc, le défi de diriger ces services professionnels et ces entreprises, n'est pas seulement que le travail est de nature immatérielle. Vous ne pouvez pas le voir, vous ne pouvez pas le stocker, il n'occupe pas d'espace physique. Et à cause de cela, cela limite notre capacité à utiliser un langage plus courant ou le bon sens pour gérer l'entreprise. Mais en plus de cela, l'environnement, l'environnement externe, est en constante évolution. Cela peut être des changements politiques, économiques, des changements de marché, des changements dans les goûts des clients, des changements concurrentiels. Le marché change constamment en dehors de l'entreprise et cela a un effet d'entraînement sur l'ensemble de l'écosystème de services. Les conséquences de cela sont que les priorités changent, les capacités dont vous avez besoin dans votre entreprise changent et évoluent constamment, et vos niveaux de service doivent augmenter en réponse à la concurrence et aux attentes changeantes des clients.
Ainsi, les managers posent des questions comme, que devrions-nous commencer ensuite ? Avons-nous la capacité de tout faire ce que nous devons faire ? Quand sera-t-il livré ? Et arrivera-t-il quand nous en aurons besoin ? Comment allons-nous gérer les dépendances à travers ce réseau de services interdépendants ? Et cela va-t-il affecter notre capacité à livrer ? Et si nous retardons le démarrage de quelque chose maintenant, aurons-nous la capacité disponible pour le faire plus tard ? Et arrivera-t-il encore à temps ou au moins quand nous en aurons besoin ? Et combien d'activités devrions-nous avoir en parallèle ? Plus nous avons de choses en parallèle, probablement plus nous avons besoin de personnes, plus l'organisation est grande, plus le capital d'exploitation est important, plus c'est coûteux et risqué de gérer notre entreprise. Sauf que nous faisons beaucoup de choses en parallèle afin de couvrir les risques.
Ainsi, toutes les entreprises de services professionnels sont-elles intrinsèquement intensives en capital, malgré le fait qu'elles ne traitent que des biens immatériels ?
Donc, imaginez que nous avons un réseau de services et j'ai grandement simplifié le problème ici avec seulement trois et je représente chacun de ceux-ci comme un système Kanban parce que cette entreprise est clairement très sophistiquée et assiste au Lean Kanban France depuis plusieurs années. Ils ont donc ces services indépendants et très efficaces en place, mais ils ont toujours des interdépendances entre eux. Et si vous êtes quelqu'un en première ligne recevant la demande des clients externes, vous voulez pouvoir regarder en aval ici et dire, d'accord, où les dépendances vont-elles se produire et quel effet cela aura-t-il ? Et donc, quand devrions-nous commencer un travail ici ? Quand le planifions-nous ?
D'autre part, si vous êtes l'un des autres managers quelque part ailleurs dans ce réseau, vous aimeriez pouvoir regarder en amont et anticiper ce qui arrive afin de pouvoir avoir les bonnes personnes avec les bonnes compétences disponibles au bon moment pour faire le travail en temps opportun.
Ainsi, aux tout débuts de Kanban, les managers qui travaillaient pour moi appelaient cela regarder à gauche ou regarder à droite.
Si vous anticipez une demande arrivant, vous regardez à gauche. Vous regardez à gauche sur le tableau, en amont. D'autre part, si vous essayez d'anticiper les dépendances qui se produiront à l'avenir, vous regardez en aval, vous regardez à droite sur le tableau. Si nous pouvons combiner ces deux idées, nous pouvons grandement améliorer la gestion d'un réseau de services professionnels.
Ainsi, l'Enterprise Services Planning est ce concept selon lequel nous gérons un réseau de services. Et donc, c'est une solution de gestion à l'échelle des services de l'entreprise et elle exploite Kanban parce que nous utilisons Kanban pour améliorer chaque service au sein de cette entreprise. Mais si vous améliorez les services indépendamment, vous n'améliorerez pas nécessairement la performance globale du réseau. Parce que nous savons que des dépendances se produisent. Nous savons que les choses sont retardées lorsqu'elles dépendent d'autres éléments. Il y a beaucoup de files d'attente entre les différents nœuds de ce réseau. Ainsi, l'objectif de l'Enterprise Services Planning est de choisir les bonnes choses au bon moment, de les faire de la bonne manière, avec une exposition au risque appropriée. Parce que vous ne gérez pas votre entreprise si vous ne gérez pas les risques. Combien de choses devriez-vous faire en parallèle ? C'est juste une question de gestion des risques. Si votre entreprise présente très peu de risques, la réponse serait probablement aucune, juste une chose à la fois. La raison pour laquelle vous faites des choses en parallèle est qu'il y a des risques dans l'environnement.
Ainsi, le nom Enterprise Services Planning a été inspiré par le monde des biens physiques tangibles. Dans la fabrication, Toyota a adopté l'utilisation des systèmes Kanban en 1947. Et ils se sont en fait inspirés de deux idées existantes. L'idée d'utiliser des cartes de signalisation dans la société japonaise pour limiter les quantités de ressources rares. Et le réapprovisionnement juste-à-temps des rayons des épiceries américaines. Combinez ces deux idées et vous obtenez des systèmes Kanban dans les usines Toyota en 1947. En 1964, un Américain nommé Joseph Orlicky a proposé une idée appelée Manufacturing Resource Planning, ou MRP. Il lui a fallu 11 ans pour écrire un livre à ce sujet. En 1975, de manière assez opportune, la même année que l'invention du microprocesseur. Et donc, un grand marché logiciel s'est développé pour les solutions MRP.
Eh bien, en 2004, nous avons essayé un système Kanban dans un environnement de services professionnels, dans un environnement de biens immatériels.
Maintenance logicielle. au département informatique de Microsoft. Nous voici 11 ans plus tard et maintenant je propose l'Enterprise Services Planning essentiellement comme l'équivalent du MRP mais pour les services professionnels dans des environnements de biens immatériels.
Donc, ESP, si vous voulez le pitch rapide pour votre patron, c'est le MRP pour les services professionnels. C'est la gestion de la capacité et la planification du travail immatériel. Maintenant, si vous connaissez quelque chose au MRP, vous savez qu'il y a beaucoup de mathématiques, beaucoup d'algorithmes impliqués pour déterminer comment planifier, séquencer, sélectionner le travail, comment prendre des engagements sur le travail, et dans les environnements de fabrication, cela inclut également des choses comme quels éléments regrouper, quelle doit être la taille d'un lot, et ainsi de suite. Ainsi, l'Enterprise Services Planning, le mot planification implique de programmer quelque chose, de séquencer quelque chose, de sélectionner les bonnes choses à faire, de prendre des engagements envers les clients, d'anticiper et de gérer les dépendances, de gérer toutes sortes de risques. Et de comprendre ce qui est essentiel en fonction à la fois de votre stratégie commerciale et de ce que votre client pense qui rendra ce produit immatériel et la manière dont vous le réalisez adapté à l'usage. Et ceux d'entre vous qui étaient ici l'année dernière savent que mon intervention portait sur l'adéquation à l'usage.
Je vais maintenant entrer un peu dans les détails de la manière dont nous faisons ces choses, comment nous déterminons quoi choisir, quand le choisir, si nous couvrons les risques de manière appropriée ou non. Et la clé de cela est l'évaluation des risques. Nous l'utilisons pour la planification, la séquencement, la sélection, la couverture des risques, l'allocation des capacités, la modulation de la demande, trop de choses que je n'ai pas pu faire tenir proprement dans le titre ici.
La première chose est de réaliser que nous utilisons une approche qualitative pour l'évaluation des risques. Dans la plupart de la littérature sur la gestion de projet ou le développement logiciel agile, nous nous situons à l'une ou l'autre extrémité de ce spectre. Soit tout est complètement hétérogène, tout est unique, et donc nous devons tout analyser indépendamment, nous devons faire des estimations, nous devons établir des plans déterministes très détaillés, nous devons diviser les choses à travers différents niveaux de hiérarchie et les exigences afin d'atteindre le niveau atomique et établir un plan détaillé à ce niveau atomique.
La planification traditionnelle, coûteuse, chronophage, elle est pleine de fausse précision et de chiffres inventés. Et bien qu'elle donne aux managers un sentiment de contrôle, cela ressemble à du risque. a été bien géré, il est probablement encore très risqué parce qu'il y a beaucoup de conneries intégrées dans ce style de planification. L'autre extrémité de l'échelle consiste à traiter tout comme s'il était homogène. Hé, ce n'est qu'une user story et nous avons une vélocité. Combien de user stories avons-nous multiplié par la vélocité ? Voilà votre réponse.
Les managers seniors savent intrinsèquement que c'est une stratégie très risquée. C'était bon marché et rapide, mais ils comprennent l'idée que leur entreprise n'est pas homogène. Et donc ils ont peur des plans simples, bon marché et rapides. Et cela crée une incongruité entre les personnes de niveau inférieur qui veulent simplement multiplier les user stories par la vélocité.
Et les managers seniors qui pensent que c'est plein de conneries.
Nous avons donc besoin de quelque chose qui mette les managers seniors plus à l'aise sans emprunter la voie du traitement de tout de manière hétérogène. La grande planification initiale, les longs délais, etc. Ce que nous avons, c'est un système qui utilise des taxonomies qualitatives, généralement deux à six catégories dans chaque dimension. Et qui sont basées sur des faits. Évaluer un fait dans quelque chose qui est arrivé, une demande qui est arrivée, est généralement bon marché, rapide, tend à être précis, et en raison de toutes ces choses, cela tend également à former un consensus. Si vous demandez à quatre ou cinq personnes leur avis sur la catégorie à laquelle appartient quelque chose dans une taxonomie, elles vous donneront généralement le même avis. Si vous leur demandiez une estimation, vous obtiendriez plus d'estimations que le nombre de personnes dans la pièce.
Et cela nous permet de gérer les risques. Ainsi, l'une des façons dont nous procédons est d'évaluer qualitativement le coût du retard, et il y a quelques personnes dans la salle et à cette conférence qui vont vous parler du coût quantitatif du retard, ce qui est parfaitement bien dans les circonstances où vous pouvez le faire et où vous pouvez accéder à des faits réels pour le rendre possible. Mais une grande partie... du reste du temps, nous avons découvert que les responsables marketing peuvent vous donner des informations qualitatives sur la fonction d'utilité d'un travail. Si vous leur demandiez une estimation, vous obtiendriez plus d'estimations que le nombre de personnes dans la pièce.
Et cela nous permet de gérer le risque.
Donc, l'une des façons dont nous faisons cela est d'évaluer qualitativement le coût du retard, et il y a quelques personnes dans la salle et à cette conférence qui vont vous parler du coût quantitatif du retard, ce qui est parfaitement acceptable dans les circonstances où vous pouvez le faire et où vous pouvez accéder à des faits réels pour le rendre possible. Mais la plupart du temps, nous avons découvert que les responsables marketing peuvent vous donner des informations qualitatives sur la fonction d'utilité d'un travail. Et bien que cette information qualitative soit factuelle, elle manque de précision, mais elle reste exacte. Alors, imaginez que nous allons lancer une campagne de vacances de Pâques pour une chaîne d'hôtels. Nous allons lancer des pages web et des emails. Pour quand en avons-nous besoin ? Le temps sur l'axe des abscisses. Imaginez que c'est le moment où nous en avons besoin, mi-janvier. Et si c'est vrai, si nous lançons la campagne d'emails et les pages web, combien de chambres d'hôtel supplémentaires cela nous aidera-t-il à vendre pendant la période jusqu'à Pâques ? Et la fonction pour cela ressemblera à quelque chose comme ceci. Quand arrive Pâques, surprise, surprise, les gens commencent... À arrêter de réserver pour Pâques.
Au début de la campagne, les gens prennent le temps de réfléchir à ce qu'ils vont faire. Et puis progressivement, ils commencent à faire des réservations, donc nous enregistrons effectivement les réservations de chambres d'hôtel.
Que se passe-t-il si cette campagne n'était pas prête à la mi-janvier ? Et si cette campagne arrivait un mois plus tard ?
Comme ici. Eh bien, le nombre de chambres d'hôtel que nous vendons réellement pourrait ressembler davantage à ceci.
Maintenant, la différence a été causée par ce retard et la différence entre les deux courbes. De nos chambres supplémentaires estimées vendues aux chambres réelles, c'est le coût du retard.
Il y a d'autres personnes qui pourraient être à cette conférence et qui vont parler du coût du retard en tant que taux. Moi, j'en parle ici comme d'une quantité absolue. Maintenant, si nous prenons cette zone rouge et que nous la représentons graphiquement, nous obtenons une forme qui ressemble à ceci sur la même période. C'est cette forme en S. Il y a des gens sur le circuit des conférences qui continuent de vous dire que le coût du retard est un taux, comme s'il était constant. Eh bien, ce n'est pas une constante. S'il était constant, ce serait une ligne droite. Il y a des moments où l'approximer par une régression linéaire est acceptable, et d'autres moments où ce n'est pas le cas.
La forme de cette courbe en S nous en dit long sur le moment où nous pouvons planifier quelque chose et notre sensibilité à l'incertitude du calendrier.
Donc, si nous examinons trois variantes, cette fonction à charge arrière comme celle que je viens de vous montrer, une fonction à charge avant où vous lancez une nouvelle version de votre produit, quel qu'il soit, et tout le monde le veut au début lorsqu'il est lancé. Cela arrive avec les produits saisonniers. Don Reinertsen, s'il est dans la salle, aime parler de SRAM, le fabricant de composants pour vélos. Un autre cas d'étude que nous avons est Blizzard Sport, qui fabrique des skis de descente. Et ils lancent de nouveaux produits chaque année. SRAM et Blizzard sont à peu près à la même période de l'année, curieusement. Et si vous êtes un cycliste professionnel de course, un néo-pro ou un amateur de haut niveau, ou un skieur professionnel de course ou quelqu'un qui est peut-être un moniteur de ski, vous prenez livraison de votre nouvel équipement dès le début de la saison. Et puis une année entière s'écoule et vous prenez livraison du nouvel équipement à nouveau. Donc le pic dans ces entreprises est au début, alors que si vous organisez une conférence, le pic est à la fin. Et puis il y a d'autres types d'entreprises où l'adoption suit une courbe en cloche. Typique.
Développement de nouveaux produits, cycle de vie du produit, courbe en cloche. Et il y a d'autres variantes. Ce n'est pas un ensemble complet. Eh bien, il s'avère que celles en haut ici sont plus sensibles au calendrier que celles en bas. Cela vous indique quelque chose sur la façon dont vous pourriez séquencer les choses.
Eh bien, si vous avez des taxonomies comme celles-ci, vous pouvez en construire une carte complète. Et avec les entreprises avec lesquelles nous faisons cela, nous trouvons généralement qu'entre quatre et neuf de ces taxonomies sont suffisantes. Dimensions de risque chacune avec... Avec des catégories sur elles. Et ceci est en fait une carte pour un projet ERP qui a été réalisé en 2007. Et la façon dont ceci est dessiné, la sensibilité au calendrier de la taxonomie est dessinée vers l'extérieur de l'image. Donc quelque chose qui se situe vers l'extérieur impliquerait que nous devons le commencer tôt. Nous devons le séquencer en premier. Nous devons le planifier tôt. D'autre part, si c'est dessiné vers le milieu, l'implication est que cela peut être retardé jusqu'à plus tard. Nous pouvons nous engager dessus plus tard, nous pouvons le planifier plus tard, nous pouvons le séquencer en dernier.
Eh bien, la vie serait simple si vous faisiez cela pour votre portefeuille ou votre backlog de produit et que vous obteniez de jolies petites images comme celle-ci.
Le bleu irait évidemment en premier, et l'orange en second, et le vert en troisième, et la vie ne serait-elle pas merveilleuse ? Comme ce serait simple de séquencer les choses. Un peu comme calculer la valeur commerciale divisée par le coût, appeler cela le retour sur investissement, et classer tout par ordre de priorité dans une feuille de calcul. Croyez-moi, c'est un non-sens complet. Et la vraie vie ne ressemble pas à cela.
Voici un peu de vraie vie. Ceci provient d'une entreprise appelée Bazaar Voice. Certains d'entre vous utilisent-ils leur service ? Une main levée, deux mains levées. Donc ceci ne cartographie que quatre projets dans le portefeuille de Bazaar Voice à l'époque où nous l'avons fait, mais le profil de risque, les six dimensions, ont été développés pour Bazaar Voice. Quatre d'entre elles proviennent de notre ensemble standard et deux sont personnalisées. Celle-ci concerne l'implication légale avec le niveau le plus élevé étant un recours collectif. Et celle-ci est le nombre d'utilisateurs finaux affectés par le projet, où le niveau le plus élevé est tous les utilisateurs de Bazaar Voice, et le niveau le plus bas est un seul client ou un marché de niche.
Ces quatre projets sont représentés. Les noms sont syndication, accessibilité, quelque chose appelé temps de déploiement fois deux, et puis celui-ci est astucieusement déguisé en demande de la direction. Parce que ce projet particulier était le projet préféré du PDG. Le PDG est arrivé un lundi matin avec un, les gars, j'ai eu une super idée ce week-end, une épiphanie. Et nous devons le faire tout de suite.
Donc le profilage des risques, la... La demande des cadres supérieurs, c'est ce bleu pâle ici.
En regardant cela, devrions-nous le faire du tout ? Et si nous devrions le faire, devons-nous le commencer maintenant ou devrions-nous le reporter à plus tard ? C'est une chose non triviale. Il y a essentiellement un récit dans cette demande et toutes les autres, et nous devons en parler. Nous devons avoir une discussion encadrée.
Et la conséquence de ceci est en fait, oui, nous devrions le faire, et c'est le violet ici que nous devrions sacrifier. Pour des raisons que j'expliquerai très brièvement et très rapidement, peut-être trop rapidement pour que vous compreniez pleinement dans cette présentation. La catégorie, cette catégorie ici, s'appelle la catégorie de risque de marché du changement. Et elle divise les fonctionnalités d'un produit ou les projets d'un portefeuille en fonction de s'ils sont des incontournables pour un marché donné, s'ils sont différenciants, s'ils copient ou rattrapent, en gâchant effectivement le marché d'un autre concurrent, ou s'ils sont destinés à réduire nos coûts.
Et à partir de cette information, les incontournables ont peu de chances de changer et il y a un faible risque de retravail. Par conséquent, nous pouvons nous engager tôt envers eux, mais le mot clé est pouvons, pas devons.
Alors qu'à l'autre extrémité de l'échelle, il y a un risque élevé de retravail, et nous devrions reporter l'engagement jusqu'à plus tard, jusqu'à ce que nous ayons recueilli plus d'informations, et que nous soyons absolument sûrs de ce que nous voulons, comment nous voulons le mettre en œuvre.
Le risque de retravail augmente à mesure que nous allons dans ce sens et la planification va dans ce sens. Donc nous planifierions généralement les incontournables en premier et les différenciateurs en dernier. Mais nous ne sommes pas obligés de planifier les incontournables en premier. Ce projet violet particulier était un incontournable. Tout le reste est à faible risque et peut être planifié plus tard. Le fait que nous puissions planifier cela maintenant ne signifie pas que nous le devrions. Donc, nous pouvons le reporter. Nous faisons celui en bleu, celui en violet attendra plus tard. Cette conversation pourrait prendre 15 ou 20 minutes et tout le monde repart avec une compréhension consensuelle. C'est une approche bien plus puissante pour la planification et la séquence des travaux que tout ce que j'ai jamais vu dans ma carrière, franchement.
Maintenant, nous avons découvert cela en le faisant avec des gens, car il fut un temps où j'y croyais.
Vous découvrez que la vraie vie n'est pas aussi simple que cela en le faisant réellement et en voyant des images comme celle-ci, puis en écoutant le récit de la manière dont ils la résolvent.
Donc, c'est essentiellement ce à quoi cela revient. Parfois, nous voulons visualiser le risque inhérent plutôt que le risque de planning. Et cela implique d'inverser certains de ceux-ci. Donc, voici l'image pour le même projet, mais montrant son risque inhérent, qui est en fait plus faible.
Et donc, un projet à relativement faible risque, bien qu'il s'agisse d'une dépense en capital majeure.
Lorsque nous le faisons de cette manière, nous pouvons utiliser le risque pour façonner la demande. Combien d'entre vous dans cette salle travaillent dans le logiciel ? Si vous avez levé la main, faites-vous du tri des bugs dans votre entreprise ?
Un bon nombre d'entre vous. Donc, vous comprenez déjà le concept de façonnage de la demande. Le triage est toute la question de savoir si nous devons corriger le bug ou si nous ne devrions tout simplement pas nous en soucier. Les cas où on ne s'en soucie pas se trouveraient dans cette zone rouge sur cette image. Donc, chacune de ces dimensions représenterait une raison différente de corriger le bug. Par exemple, combien d'utilisateurs sont affectés par celui-ci.
Donc, bien que ce soit un dessin abstrait, nous avons essentiellement tracé le seuil, et dans le tri des bugs, cela s'appelle la barre de bugs. La barre de bugs est cette ligne ici, et si le bug se trouve à l'intérieur, vous ne le corrigez pas. Merveilleux. Seuil de façonnage de la demande. Voici une situation pas si réelle. Eh bien, le numéro un ici, cela semble évident. Nous faisons définitivement celui-ci.
Et celui-ci, eh bien, nous ne le ferons définitivement pas. Le problème survient avec ceux-ci.
Le faites-vous ou ne le faites-vous pas ? Nous allons devoir en parler. Et en en parlant, nous apprendrons quelque chose. Nous apprendrons laquelle de ces dimensions nous importe le plus et dans quelles circonstances, et comment les choses se compensent entre elles. Oh, et puis il y a cette autre chose très capricieuse : avons-nous toujours notre vélocité moyenne ?
Non, ce n'est pas le cas.
Il y a donc des moments où nous avons une capacité supplémentaire cette semaine parce que nous allions un peu plus vite, et cela signifie que certains de ceux-ci sont faits. Mais si c'était une autre semaine où nous n'avons vraiment aucune capacité supplémentaire et que nous empruntons déjà à la semaine prochaine, alors non, ils ne sont pas faits. Parfois, c'est juste une question de timing. La vraie vie est pleine de beaucoup de chance et de timing. Tout ne se fait pas. Et quand vous écrivez des livres sur ce sujet ou que vous êtes sur scène en essayant d'enseigner aux gens comment le faire, Il n'y a pas de bonne ou de mauvaise façon de le faire à chaque fois. Il n'y a pas de prescription qui fonctionne à chaque fois. Il y a un ensemble de conseils pour vous aider, puis il y a le récit. Parlez-en. Mais en parler de manière structurée comme ceci vous aide à parvenir à une réponse beaucoup plus rapidement avec un niveau de consensus beaucoup plus élevé.
Donc, la prochaine chose est la prévision. Quand sera-t-il terminé ? Ou plus précisément, si nous savons quand nous en avons besoin, quand devons-nous le commencer ?
Eh bien, ce que nous avons appris du Kanban, c'est que les tickets passant par un système Kanban suivent une distribution de Weibull. Et si vous voulez plus d'informations sur ce sujet, il y a la présentation de Demetar demain. Il y a aussi la présentation de Daniel Vacanti, mais elles sont consécutives.
Donc, choisissez l'une ou l'autre.
Voici une courbe typique de Weibull. Ceci provient d'un de mes clients de l'année dernière. Nous avons simplement échantillonné cela au hasard dans un département que je visitais un jour. Nous l'avons extrait de leur système de suivi JIRA. Et voilà, c'est une distribution de Weibull avec une forme d'environ 1,4.
Voici les plages de distribution typiques que nous voyons pour les distributions de Weibull à travers les systèmes Kanban. Et la chose importante à réaliser à propos de celles-ci est que le risque se trouve toujours dans la queue. En voici une autre. Le mode dans ces données est un quart de la valeur de la queue.
85 % de ces éléments sont complétés en 60 jours. La queue s'étend jusqu'à 150. L'étendue de la variation est de 22 à 150. Alors, quand devons-nous commencer quelque chose ?
Avant d'aborder cette question, ESP repose sur deux principales approches de prévision. La première s'appelle la prévision par classe de référence, et c'est une partie de ce que je viens de vous montrer. Pour construire cet histogramme, vous devez sélectionner une période de temps pour prendre les données, et c'est votre classe de référence. La prévision par classe de référence est la technique pour laquelle Daniel Kahneman a remporté le prix Nobel. C'est une approche assez solidement testée. Et puis il y a la simulation de Monte Carlo. Et nous avons tendance à utiliser ces deux méthodes en combinaison. Nous utilisons les courbes de distribution de prévision par classe de référence comme partie de l'approche de simulation de Monte Carlo.
Donc, planifier quelque chose. Imaginez qu'à partir du coût du retard et de la fonction d'utilité, nous savons quand nous en avons besoin. Nous voulons que notre campagne marketing pour les vacances de Pâques soit lancée le 10 janvier parce que c'est le deuxième mardi de janvier et que nous lançons toujours les campagnes marketing le mardi.
Quand en avons-nous besoin ?
Eh bien, si nous avons une courbe qui ressemble à ceci, et que l'échelle sur ces axes est la même, nous pouvons revenir en arrière à partir de cela. Et nous pouvons dire, eh bien, avec six chances sur sept de livraison à temps, nous devons commencer le 11 novembre. Imaginez que votre système de suivi de logiciel agile puisse réellement vous donner ce conseil.
Eh bien, à partir du milieu de ce mois, il y aura un produit sur le marché qui peut vous donner ce conseil.
Nous pouvons commencer à étudier la sensibilité.
Alors, que se passe-t-il si nous voulions seulement nous donner 50 % de chances de livraison à temps ? Cela nous donne le 25 novembre.
Et si nous voulions prendre des risques ? cela et l'échelle sur ces axes est la même, nous pouvons en déduire cela. Et nous pouvons dire, eh bien, avec six chances sur sept de livraison à temps, nous devons commencer le 11 novembre. Imaginez que votre système de suivi de logiciel agile puisse réellement vous donner ce conseil. Eh bien, à partir du milieu de ce mois, il y aura un produit sur le marché qui pourra vous donner ce conseil.
Nous pouvons commencer à étudier la sensibilité. Et si nous voulions seulement nous donner 50 % de chances de livraison à temps ? Cela nous donne le 25 novembre.
Et si nous voulons prendre des risques ? Quand est la dernière date à laquelle nous pourrions éventuellement commencer ? Il y a un débat sur les algorithmes ici. Et en fait, l'algorithme que j'ai intégré dans la diapositive n'est plus mon préféré. Mais en utilisant cet algorithme, qui dit, donnons-nous 0 % de chances de livraison à temps. Maintenant, je préfère que vous choisissiez un nombre comme, donnons-nous 15 % de chances d'échec total. Cela vous donne 85 % de chances d'atteindre au moins quelque chose.
Mais ces deux algorithmes dans cet exemple donnent des réponses relativement similaires mais légèrement différentes. Celui-ci donne le 19 décembre, et il suppose que Noël et le Nouvel An n'existent pas, donc vous devez en tenir compte. parce que ces données de classe de référence n'incluaient probablement pas Noël au milieu.
Et si vous utilisez l'autre algorithme, celui qui dit donnons-nous 15 % de chances d'échec total, vous obtenez quelque chose comme le 27 décembre. Eh bien, avec cette information, oh, une chose de plus. Et si nous voulons être absolument sûrs que la chose sera livrée à temps ? Eh bien, la réponse à cela est que nous devons commencer le 11 août avec ces données d'exemple. Eh bien, cela nous donne une définition de la fenêtre d'opportunité. Cet élément particulier devient éligible pour la sélection le 11 août. Jusqu'à cette date, il pourrait être dans notre backlog, mais nous ne voulons pas le voir lors des réunions de planification. C'est juste du bruit. Le moment optimal pour commencer, en supposant que nous estimons que 85 % est à peu près aussi risqué que nous nous sentons à l'aise, ce serait le 11 novembre, et la dernière date de début disponible est le 19 décembre. Si nous dépassons le 19 décembre, nous ne devrions même pas nous embêter. C'est aussi connu sous le nom de date d'expiration de l'option.
Et donc après le 19 décembre, nous voulons que notre système ferme ce ticket car l'option a expiré et nous ne voulons plus le voir lors de la planification.
Ce type de filtrage simplifie vraiment les gros backlogs. Montrez-moi simplement les candidats qui sont éligibles pour la sélection aujourd'hui. Maintenant, montrez-les-moi en fonction d'un profil de risque particulier pour façonner la demande. Soudain, nous avons filtré la chose. Des centaines de choses pourraient être réduites à 20 ou 30. Maintenant, choisissons-en une. Cette conversation pourrait ne nous prendre que 20 ou 30 minutes. Nous arrivons à une prise de décision de très bonne qualité vraiment, vraiment rapidement en utilisant cela. Des gens que je connais qui ont 800, 900 choses dans leur backlog peuvent passer deux jours avec 17 parties prenantes dans une réunion pour essayer de décider ce qu'ils devraient faire ensuite.
Mise à l'échelle dans toute l'organisation. Nous en avons déjà parlé. C'est un réseau et nous allons kanbaniser chacun d'eux et nous avons cela comme approche définie. Nous l'enseignons dans la classe de formation de deux jours sur la conception de systèmes Kanban de base. C'est connu sous le nom de statique, l'approche de la pensée systémique pour introduire Kanban. Et lorsque les gens viennent à la formation Kanban, ils apprennent à faire cela afin de pouvoir aller kanbaniser des parties de leur organisation.
Et cette procédure ici qu'ils apprennent en classe tend à être itérative car au fur et à mesure que vous le faites, vous apprenez de meilleures façons de le faire. Généralement, la conception initiale du système Kanban n'est pas aussi bonne qu'elle pourrait l'être. Vous vous améliorez.
Nous avons donc quelques principes simples de mise à l'échelle pour passer de Kanban à la planification des services d'entreprise. Vous vous étendez de manière orientée service, un service à la fois. Maintenant, nous aimons l'orientation service pour les mêmes raisons que les ingénieurs logiciels l'aiment. Quel est l'avantage de l'orientation service ? Sur le plan architectural, d'un point de vue de la mise à l'échelle, c'est plat.
Cela ne nécessite pas d'être une solution sans échelle parce qu'il n'y a qu'un seul niveau d'échelle.
Cela rend toute l'idée de la planification des services d'entreprise utilisant Kanban intrinsèquement évolutive parce qu'elle est plate. Le défi consiste à apprendre à voir votre organisation comme un ensemble de services. Lorsque vous avez été habitué à la penser comme un portefeuille géré en matrice ou comme un ensemble de silos fonctionnels. Une mentalité différente. Imaginez que vous entriez au bureau avec une nouvelle paire de lunettes et que cette paire de lunettes vous permette de voir les services. Chaque fois que vous voyez quelqu'un demander quelque chose à quelqu'un d'autre, vous venez probablement de voir une demande de service. Découvrez quel workflow est impliqué dans la livraison de cette demande au demandeur, puis kanbanisez-le. Donc, anticiper et gérer les dépendances, les gens s'en inquiètent énormément.
Vous savez quoi ? Si vous avez une courbe de distribution pour ce système Kanban ici, et qu'il y a tout un ensemble de dépendances vers ces autres, cette courbe de distribution de délai contient déjà le risque qu'une dépendance survienne. Et si vous utilisez cette courbe de distribution de délai particulière pour toute votre planification, vous avez déjà pris en compte les possibilités de dépendances. Vous n'avez pas besoin de planifier ces choses de manière déterministe. Y aura-t-il une dépendance ou non ? Avons-nous vraiment besoin de le savoir ? Quand devons-nous le commencer au plus tard ? Eh bien, si vous êtes prêt à accepter 6 chances sur 7 de livraison à temps et donc 1 chance sur 7 d'encourir un certain coût de retard, commençons le 11 novembre.
D'un autre côté, oh non, je ne veux prendre aucun risque.
Eh bien, nous devons commencer le 11 août. Oh, eh bien, je ne peux pas commencer le 11 août. C'est trop tôt. D'accord, alors laissez-moi comprendre. Vous ne voulez prendre aucun risque, et pour ne prendre aucun risque, nous devons commencer le 11 août, mais vous ne voulez pas commencer le 11 août. Oui, c'est exact. À ce stade, nous devons maintenant savoir s'il y a une dépendance ou non. Sinon, nous n'avions pas besoin de le savoir.
de savoir, car nous devons savoir s'il y a un risque de se retrouver dans la queue de la courbe de distribution. Donc, vous avez vu ces diapositives.
Nous modélisons les dépendances sur les tableaux Kanban en utilisant des tampons, la pondération entre un système et un autre. Et généralement, ce sont des files d'attente non bornées. Cela signifie qu'il y a un long risque dans la queue. Eh bien, nous pourrions commencer à recueillir des preuves sur le temps que nous passons à attendre. Nous pourrions développer un SLA avec l'autre groupe. Ils deviennent fiables et prévisibles, et nous transformons notre file d'attente non bornée en une file bornée. Et le résultat de cela sera que vous réduirez massivement la queue. Dans la courbe de distribution pour le premier système qui appelle le second. Et avons-nous une dépendance ou non ?
Nous pouvons obtenir la plupart de ces informations à partir d'une évaluation des risques, une évaluation des risques qualitative basée sur une taxonomie. La véritable clé est de savoir s'il existe un moyen peu coûteux et rapide de poser une question qui vous dira avec un haut niveau de certitude, c'est une mauvaise façon de le formuler, une haute probabilité, un haut niveau de confiance, qu'une dépendance est susceptible d'exister.
Si vous pensez que ce n'est pas le cas, vous pouvez filtrer votre courbe de distribution de délai pour dire, montrez-moi les éléments qui n'ont pas cette dépendance impliquée.
Vous obtenez alors une courbe de distribution différente et vous l'utilisez pour planifier les éléments différemment. Et tout cela est algorithmique. En d'autres termes, vous pouvez le programmer dans un logiciel. Le logiciel peut commencer à vous dire tout cela. Alors, comment faire en sorte que ce réseau commence à se comporter intelligemment au niveau du réseau, et pas seulement au niveau des nœuds individuels du réseau, les systèmes Kanban individuels ?
Eh bien, nous faisons cela avec des boucles de rétroaction. Nous faisons cela avec des boucles de rétroaction. Et ces boucles de rétroaction dans Kanban sont connues sous le nom de cadences Kanban. Et quatre d'entre elles figuraient dans le livre Kanban écrit il y a six ans. Et les trois autres, celle du milieu existait, je ne l'ai tout simplement pas écrite dans le livre parce que je ne pensais pas que c'était important. Et les deux autres, la revue des risques et la revue stratégique, sont des éléments qui ont émergé au cours des dernières années.
Donc, parmi ces sept réunions, le réapprovisionnement, la réunion Kanban, la planification de la livraison, il s'agit de faire avancer les choses. Se concentrer sur la prestation de services. Ensuite, nous avons la revue de la prestation de services, la revue des opérations, la revue des risques. Et cela concerne : faisons-nous les choses correctement et pourrions-nous faire mieux ? Et puis ici, la revue stratégique couplée au réapprovisionnement et à l'engagement, le processus de sélection. Cela concerne : faisons-nous la bonne chose ? Choisissons-nous les bonnes choses au bon moment ?
En utilisant ces boucles de rétroaction, notre réseau de services s'auto-équilibre. Dans la littérature Toyota, ils parlent des systèmes Kanban comme étant auto-équilibrants. Cela ne se produit que si vous avez des êtres humains comme boucle de rétroaction, et c'est la même chose pour nous. Parce que vous effectuez des ajustements, des ajustements aux limites de travail en cours (WIP), des ajustements à l'allocation de capacité, des ajustements à la politique de façonnage de la demande, à l'évaluation des risques.
Vous modifiez la politique sur le moment de planifier les choses et le niveau de risque que vous êtes prêt à prendre, et ainsi de suite.
Nous pouvons visualiser les dépendances, nous avons déjà vu cette diapositive.
Cela consiste à visualiser une dépendance d'intégration en divisant les colonnes d'un tableau Kanban en plusieurs lignes.
Et ce qui se passe effectivement, c'est que notre point d'intégration ici devient un élément à date de livraison fixe, une date de livraison fixe intermédiaire. Ainsi, la classe de service pour ceux-ci, l'orange ou le violet ici, aura une date de livraison fixe pour le moment où nous voulons entrer dans les tests d'intégration.
Cela montre une dépendance hiérarchique. Il s'agit d'un grand projet qui s'est déroulé dans mon portefeuille en 2007. Dan Vacanti. était le responsable de ce projet et une grande partie de ce qu'il présente est basée sur ce qu'il a appris pendant cette période de gestion. C'était un projet de 11 millions de dollars. Les tickets verts sont les parents des tickets jaunes. Il y a une dépendance parent-enfant, donc nous avons cinq équipes construisant ces tickets verts, et pour ce faire, elles doivent construire les plus petits éléments qui sont des user stories.
Ce tableau date de 2009, client à San Francisco, et ils utilisaient des points de couleur pour signifier différents types de dépendances.
Nous pouvons également signaler de nombreuses dépendances dans la conception des tickets. Donc, vous pourriez utiliser la couleur du ticket, c'est peu probable. Nous pouvons en fait montrer des dépendances de services spécifiques comme la conception graphique, la rédaction, l'administration de base de données, l'approbation du client. Sont-elles requises et ont-elles été complétées ? Nous pouvons utiliser des décorateurs comme vous l'avez vu sur l'image juste avant. Nous pouvons parfois utiliser des lettres pour signifier certains types de dépendances. Nous pouvons avoir une barre de progression pour le délai d'exécution. Cela pourrait être notre SLA, notre date cible. Chacun de ceux-ci représente un jour. Et lorsqu'un élément est bloqué, nous pouvons utiliser une couleur différente pour enregistrer le nombre de jours où il a été bloqué. De même, sur les tickets de blocage, nous pouvons enregistrer combien de temps le blocage a existé.
Nous pouvons montrer des choses comme les dates de test d'intégration système intermédiaire, comme je l'ai dit, des dates sur le ticket. Et nous pouvons utiliser ces informations pour changer la manière dont nous sélectionnons la discipline de file d'attente que nous utilisons pour les tickets, modifiant ainsi dynamiquement sa classe de service. De temps en temps. Quelque chose entre dans le système avec une classe de service, il y a des périodes où il a temporairement une classe de service différente en conséquence des risques que nous gérons et particulièrement en conséquence de la dépendance.
Donc, pour conclure, une définition de la planification des services d'entreprise. La chose simple est que vous apprenez à voir les services et nous enseignons cela dans nos cours de formation. C'est le facilitateur fondamental. Et ensuite, vous pouvez kanbaniser chaque service et nous avons ce cours de formation depuis cinq ou six ans. Et ensuite, vous mettez en œuvre le système de boucles de rétroaction et maintenant nous avons un nouveau cours de formation appelé Kanban Management Professional qui enseigne aux gens comment mettre en œuvre les cadences Kanban. Une grande partie de ce concept a été modélisée sur le Toyota Kata.
Nous apprenons donc à voir les services, et il y en a beaucoup.
Les RH peuvent fournir des services, le marketing fournit des services, l'IT est souvent appelé services ou Certains sont évidents, d'autres ne le sont pas.
Si un cadre supérieur signe quelque chose, il fournit un service. C'est un service de signature. Parfois, les services sont des personnes individuelles. Vous pouvez avoir un Kanban personnel qui représente un service. Parfois, ce sont juste deux ou trois personnes qui travaillent en collaboration. Vous pouvez avoir un Kanban d'équipe qui représente un service. Parfois, c'est toute une chaîne de personnes qui effectuent un travail spécialisé, se passant le travail entre elles. C'est un flux de travail. Donc, vous obtenez un flux de travail, une prestation de service, des systèmes Kanban de flux de travail, et ils représentent des services. Parfois, vous ne créeriez pas de tableau pour cela, mais vous reconnaissez tout de même que la personne est un service et vous la représentez par un avatar sur votre tableau existant. Mais l'essentiel est de reconnaître qu'ils fournissent un service professionnel et de se demander, d'accord, qui était le client ? Qui était le demandeur ? Qu'ont-ils demandé ? Et quelles sont leurs attentes ? Quel est le niveau de service attendu ? À quelle vitesse ? À quel niveau de qualité ?
Avec quel niveau de gestion des risques
rendra cette prestation de service adaptée à son usage. qu'il arrive parfois que vous ne créiez pas de tableau pour cela, mais que vous reconnaissiez tout de même que la personne fournit un service et que vous la représentiez par un avatar sur votre tableau existant. Mais l'essentiel est de reconnaître qu'ils fournissent un service professionnel. Et de se demander, d'accord, qui était le client ? Qui était le demandeur ? Qu'ont-ils demandé ? Et quelles sont leurs attentes ? Quel est le niveau de service attendu ? À quelle vitesse ? À quel niveau de qualité ?
Avec quel niveau de gestion des risques
permettra à cette prestation de service d'être adaptée à son usage.
Nous pouvons interdire les services avec la méthode statique, nous l'enseignons en classe, puis nous avons toute une classe pour enseigner six de ces sept éléments. La revue de stratégie est réservée à nos cours de planification des services d'entreprise. La raison est assez simple. En général, les participants aux cours Kanban n'ont pas le niveau de rémunération pour influencer la stratégie de l'entreprise, il est donc inutile de leur enseigner quelque chose qu'ils ne peuvent pas faire. Alors que lorsque nous organisons des cours de planification des services d'entreprise avec des clients privés, nous obtenons souvent la présence du directeur général ou de membres du comité exécutif. Pas tous les jours pendant les cinq jours de la semaine entière, mais pour les deux jours qui concernent réellement la gestion de portefeuille et la stratégie, nous avons souvent les cadres supérieurs dans la salle, et il est donc logique de leur enseigner comment nous aimerions qu'ils fassent la revue de stratégie, ce qui est généralement différent de la manière dont ils la font aujourd'hui.
Et cette image met vraiment en évidence quatre fonctions de gestion. J'en ai parlé au passage. Il y a la prestation de service, les trois cases du bas. Il y a la stimulation de l'amélioration, qui concerne principalement ces deux-là. Il y a la stratégie et il y a le risque.
Ce sont quatre choses que les cadres supérieurs reconnaîtront fortement et avec lesquelles ils résonneront. Oui, bien sûr, nous devons être capables de gérer la prestation de service. Nous devons être capables de l'améliorer. Nous devons être capables de gérer notre stratégie et de gérer nos risques.
Notre matériel de planification des services d'entreprise est conçu pour plaire à un public de cadres supérieurs. Il doit ressembler à quelque chose dont ils ont besoin, quelque chose dont leur entreprise a besoin, quelque chose qui va les aider. La littérature Kanban ne l'a généralement pas fait. Elle ne sonnait pas comme cela et, franchement, toute la littérature sur le développement agile de logiciels et la gestion de projet agile ne résonne pas avec les cadres supérieurs. Elle ne leur est pas destinée. Et c'est un problème significatif car nous avons dû nous appuyer sur un analyste de Gartner entrant dans le comité exécutif et demandant : quelle est votre stratégie agile ? Si vous ne faites pas d'agile, vous devriez le faire.
Les personnes qui rient dans l'auditoire ont effectivement vécu la visite d'un analyste de Gartner, n'est-ce pas ?
D'accord, donc bien sûr, les cadres supérieurs reconnaîtront celles-ci comme des fonctions de gestion de niveau supérieur. En d'autres termes, il y a quelque chose pour eux. Peut-être quelque chose de plus frais que ce qu'ils ont appris à l'école de commerce.
Voici un rappel de l'année dernière sur l'adéquation à l'usage (Fitness for Purpose). Imaginez que nous sommes dans le secteur de la livraison de pizzas. Nous fabriquons des pizzas. Nous les livrons à votre bureau ou à votre domicile. Qu'est-ce qui rend cette entreprise adaptée à son usage ? Maintenant, j'utilise ici une entreprise physique de manière analogique. Mais nous avons conçu les pizzas. Quelqu'un a créé le menu, un chef exécutif. Nous fabriquons des pizzas. Et puis ce gars-là monte sur un scooter et les livre à vos locaux. Pour avoir une entreprise de livraison de pizzas adaptée à son usage et réussie, nous devons être bons dans ces trois domaines. Et que signifie être bon ? Eh bien, nous devons offrir les bonnes saveurs de pizza que les clients veulent acheter. En d'autres termes, ce sont eux qui décident ce que signifie être bon. Nous fabriquons la pizza et elle doit être chaude et savoureuse. Et c'est le client qui décide à quel point elle doit être chaude et savoureuse, à quel point elle doit être croustillante, toutes ces exigences non fonctionnelles. Le client décide de ce qui représente un niveau suffisant. Et combien de temps cela prend-il ? pour nous livrer la pizza et avec quel niveau de précision ? En termes de votre pizza sera là dans 20 minutes ? A-t-elle vraiment été livrée en 20 minutes ?
Alors, à quel point les gens sont-ils satisfaits de la sélection que nous offrons, de la manière dont nous cuisinons les pizzas et de la manière dont nous les livrons ? Et si nous sommes adaptés à notre usage, si nous répondons aux seuils des clients pour ces trois choses, nous réussirons sur le marché.
Et nous enseignons tout cela dans la formation en planification des services d'entreprise.
En avançant ici, j'ai beaucoup parlé de planification. Il y a vraiment six activités. Planifier et séquencer le travail, prévoir les dates. Cela parle de dates de livraison, mais il s'agit principalement de prévoir les dates de début.
Résultats attendus, gestion des risques, que se passe-t-il si nous ne sommes pas à l'heure, combien du coût du retard allons-nous encourir, allouer la capacité, gérer les dépendances, comprendre et gérer les risques, et le dernier point ici, sur lequel je n'ai pas le temps de m'étendre aujourd'hui, garantir une liquidité suffisante pour que nous puissions réagir aux événements en cours. Maintenant, si nous pouvons faire ces choses de manière compétente, nous avons une entreprise très robuste, résiliente et anti-fragile qui saura faire face à un environnement externe en constante et rapide évolution. environnement. environnement.
En résumé, la Planification des Services d'Entreprise est pour nous une formation de cinq jours. Voici le programme. La boîte noire ici représente principalement Kanban. Les boîtes en couleur représentent tout le reste. Stratégie, gestion des risques, planification, ordonnancement, gestion de la demande, résilience et survie. Nous avons tendance à ne pas utiliser le mot anti-fragile avec les cadres supérieurs, cela leur fait un peu peur. Mais aimeriez-vous que votre entreprise soit plus résiliente et plus apte à survivre ? Oh oui, nous en voudrions bien un peu. Particulièrement avec les entreprises privées où ils se soucient beaucoup plus de l'avenir à long terme de l'entreprise.
Vous avez déjà vu ces diapositives. Anticiper la demande, être capable de regarder à gauche, de regarder en aval et de déterminer où se trouvent les dépendances. Et de regarder en amont pour anticiper la demande et voir si nous aurons la capacité disponible, si nous aurons les bonnes personnes avec les bonnes compétences disponibles au bon moment.
Combinez ces deux éléments et tout à coup, la prestation de service s'améliore considérablement. Que nous sommes beaucoup plus adaptés à notre usage qu'auparavant. Donc, la planification des services d'entreprise en quatre points. Il s'agit de faire la bonne chose au bon moment, de la bonne manière avec une exposition au risque appropriée.
Au total, si vous ajoutez la formation Kanban, il nous faut 10 jours pour former les organisations à cela. Et nous délivrons généralement cette formation sur une période de plusieurs mois.
L'année prochaine, nous prévoyons que la plupart de ces fonctionnalités seront intégrées dans des logiciels. Ainsi, la formation portera sur la théorie, et la mise en pratique consistera simplement à apprendre à utiliser le logiciel. Le logiciel ne peut jamais que vous donner des conseils. Il ne peut que suggérer, je pense que vous devriez faire les choses dans cet ordre, ou que vous devriez commencer quelque chose à ce moment-là, que vous devriez le planifier par rapport à cette autre chose, ou que vous devriez faire ces nombreuses choses en parallèle.
En fin de compte, vous devez prendre la décision car le logiciel reste un système de domaine ordonné très déterministe et vous opérez dans un monde de domaine complexe. Nous voyons des profils de risque où il est évident que vous devriez faire 1, 2, 3, mais en raison du fait que le ministre du gouvernement qui est le sponsor du projet est vraiment mécontent du chef de projet en ce moment. Et le numéro trois est vraiment facile à faire, peu risqué, et nous pouvons le faire rapidement. Donc le numéro trois est promu au numéro un. Il n'y a aucun moyen pour que le logiciel puisse jamais savoir cela. Le logiciel ne fera jamais que des recommandations. Mais la réalité de la planification des services d'entreprise les paquets logiciels commencent dans deux semaines avec le lancement du produit à Munich lors du Lean Kanban Central Europe. Et sur ce, merci beaucoup.