Google Cloud définit l’IA générative ou l’intelligence artificielle générative comme « l’utilisation de l’IA pour créer de nouveaux contenus, comme du texte, des images, de la musique, de l’audio et des vidéos ». Le lean dans les activités de service est l’une de nos principales expertises et nos clients s’intéressent bien sûr à l’IA générative. Donc nous aussi. On pourrait par exemple imaginer que nos clients banque, assurance ou société de gestion d’actifs exploitent l’IA générative pour construire plus vite et avec moins d’effort les reportings qu’ils ont l’obligation de produire. Il y en a des quantités ! Un domaine d’application par excellence : les reportings sur les milliers de fonds d’investissement existants. Ils sont produits sur des bases très régulières, allant de la semaine à l’année, et ont une structure très standardisée.
Inès manage une équipe de support informatique qui a en charge la résolution des incidents et la réponse à un ensemble de demandes d’aide arrivant au fil de l’eau. Inès cherche à s’approprier les pratiques managériales du lean :
Elle a donc défini un premier challenge pour ses équipes : accélérer sur le traitement des incidents, avec comme premier pallier de respecter les engagements de service (SLA) auxquels son service a souscrit.
Exemple de SLA : cinq jours pour retrouver un fonctionnement informatique normal pour des incidents de criticité moyenne.
L’équipe construit sa 1ère mesure : le taux de retard dans la remise en service est de 27 %. Il y a donc matière à s’améliorer !
Gemba
L’équipe commence par mieux comprendre d’où viennent ces retards. Ils extraient un ensemble d’incidents, les analysent un par un et les organisent en « pareto », c’est-à-dire en piles d’incidents ayant la même caractéristique.
Ils sont surpris de découvrir que certaines familles comportent un nombre significatif d’incidents de même nature, alors qu’ils les croyaient plutôt uniques.
Kaizen
Arnaud, l’un des membres de l’équipe, propose de prendre en charge les incidents liés à la facturation entre l’entreprise et ses clients. Inès se réjouit de voir le kaizen commencer.
Elle continue dans sa posture de « manager as a coach » et cherche maintenant à ce qu’Arnaud comprenne bien l’importance du sujet qu’il travaille avant d’engager l’amélioration. Arnaud arrive à la liste suivante :
Les problèmes de facturation créent des tensions entre l’entreprise et la comptabilité de ses clients,
La législation oblige à un règlement des factures sous 45 jours, délai difficile à tenir s’il y a un incident,
Le département Finance se plaint d’avoir des incertitudes sur la facturation et le chiffre d’affaires.
Une fois l’impact posé, Arnaud entre maintenant dans la recherche de causes.
Dans son gemba, il lui apparait très vite que le standard de traitement des tickets n’est pas respecté. A titre d’exemple, sur l’un des incidents, l’équipe attend une validation externe du « métier » sur une solution très technique, sur laquelle le métier n’a pourtant pas de compétence particulière. Le temps s’allonge et le SLA n’est pas respecté.
D’autre part, les incidents ouverts disparaissent du radar des équipes « métier ». Chacun reçoit nominativement les incidents sur lesquels sa contribution est attendue. Il n’en existe aucune liste récapitulative et, avec un peu d’inattention, les incidents disparaissent. Beaucoup ne savent pas qu’ils ont un incident à regarder et une action à conduire.
Arnaud propose à Inès de retravailler les standards avec les « métiers » puis d’y former leurs interlocuteurs. A titre de pense-bête, il propose aussi de donner à leurs interlocuteurs « métiers » l’accès à leur management visuel du flux des tickets et de faire un point hebdomadaire pour voir s’il y a des problèmes particuliers.
Une fois ces actions conduites, le taux d’incidents hors SLA descend de 27 % à 15 %. Arnaud en est bien fier.
A la question d’Inès de savoir ce qui l’a le plus marqué dans son PDCA, il explique avoir été très étonné par les impacts concrets des incidents informatiques. Lui voyait une panne comme une panne de machine, et non comme un vrai risque commercial et financier.
L’histoire ne s’arrête pas là
Inès est guidée dans son parcours de manager lean par un coach lean expérimenté. Arnaud et elle profitent d’une de ses visites pour lui présenter le PDCA. A l’issue d’un échange à trois autour des questions du coach, la recommandation qu’il laisse est de réfléchir à deux points :
Question 1 pour Arnaud : Construire et partager un standard a manifestement permis de passer une marche mais il reste encore 15 % des incidents résolus hors SLA. Pourquoi ? Il faut retourner sur le terrain et creuser au-delà des problèmes les plus évidents.
Question 2 pour Inès : Comment faire vivre un standard et son usage sur le long terme ? Au moment où les bonnes volontés se mobilisent pour le construire, chacun progresse dans sa compréhension du processus. Mais ensuite, on oublie, les gens changent et les bonnes pratiques risquent de disparaitre.
Et vous, lecteur, qu’auriez-vous laissé comme question à Arnaud et Inès ?
Déjà la 8ème édition du Accelerate – State of DevOps Report, ce bilan annuel est l’une des plus larges études disponibles sur les pratiques DevOps et leur lien avec la performance des organisations.
Rappelons-le, suite à la revente de DORA (DevOps Research Assessment) par Jez Humble, Nicole Forsgren et Gene Kim …. à Google en décembre 2020, cette étude est maintenant entièrement rédigée par des salariés de Google (on notera que les noms de Jez et de Nicole figurent toujours dans les remerciements !). Jez Humble, Nicole Forsgren et Gene Kim sont également les auteurs de nombreux ouvrages de référence sur le DevOps dont Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations. Ne soyez donc pas surpris de retrouver des liens entre State of DevOps, DORA et Accelerate !
L’Obeya est une démarche éprouvée qui facilite le travail en équipe et l’alignement des activités autour de sept panneaux pour livrer des produits informatiques ou manufacturiers. L’une des principales raisons de son succès réside dans l’accélération de la résolution régulière de bons problèmes en décloisonnant les équipes et aussi dans le support du management.
L’objet de cet article d’Edmond Nguyen et Reynald Debaut-Henocque, revu par Stéphane Wojewoda, à lire dans InfoQ est de décrire le rôle essentiel du premier panneau de l’Obeya, dont l’utilisation est trop souvent négligée : la vision. Il explique exemples à l’appui, trois éléments de la vision :
En Lean Management nous aimons bien utiliser l’image du camion pour représenter les produits ou service délivrés par l’équipe chaque jour, que ce soit un dossier, une demande de service, une User Story… Le but est de remplir le camion pour le faire partir quotidiennement. Il matérialise la commande des clients, le rythme, la cadence, le takt time de la production.
L’équipe support N2 Commerce de la direction informatique (Digital and Data Factory) de Leroy Merlin qui a lancé une démarche Lean est passée d’un camion partant chaque jour quasi vide à un train routier australien (pour faire la comparaison) dix mois après la fin du coaching ! Entendons-nous bien «quasi vide» ne veut pas dire que l’équipe se tournait les pouces ; bien au contraire, elle essayait de s’en sortir dans ce contexte difficile ; elle n’avait pas les bons outils pour le faire.
Mais qu’a-t-elle de spécial, cette équipe ? Est-elle vraiment différente des autres équipes support pour réaliser de telles performances (détails dans l’article) ? Quelques éléments de réponse.
Dans l’IT, mais également dans d’autres activités, une multitude de documents est nommée standard : des modèles (template) de document, des procédures diverses et variées, des règles de développement, des processus d’entreprise (gestion des incidents, gestion des demandes)… Pour nombre d’entreprises, un standard est un ensemble de règles édictées par un groupe de personnes autorisées par la direction. Souvent, ces règles sont issues de «bonnes pratiques» vues dans quelques équipes et que les directions cherchent à répliquer partout. Ces standards – qui n’ont rien en commun avec celui du Lean – sont vus par les directions comme la Bible, les Tables de la Loi que chaque collaborateur doit connaître et appliquer le petit doigt sur la couture du pantalon.
Tout écart à ces standards doit être sanctionné et les coupables sont a minima rappelés à l’ordre, quand ce n’est pas un message diffusé à tous annonçant que c’est une erreur humaine (sic !) au sein de l’équipe X, ce qui ne fait qu’accentuer la stigmatisation et la recherche d’un coupable.
Le Kanban est un des éléments-clés du Just-In-time (JIT) du Toyota Production System (TPS) comme nous le rappelle l’article La magie du Kanban chez Toyota à Nagoya.
Pensé par Taiichi Ohno dès les années 1950 (lire Taiichi Ohno’s Workplace Management), le Kanban vise à atteindre l’idéal du one-piece flow (nommé également flux continu) tiré et rythmé (takt) par la demande du client.
Le développement des personnes est au cœur de la démarche lean. Développer en temps et en heure des produits incroyables que les clients adorent nécessite des collaborateurs impliqués et engagés dans l’amélioration continue de leur performance, comme les sportifs de haut niveau peuvent le faire. Tous les outils fournis par le Toyota Production System ont un seul et unique objectif, aider les collaborateurs à identifier les gestes qu’ils ne maîtrisent pas totalement pour leur donner la possibilité de faire de la résolution de problèmes et ainsi améliorer eux-mêmes leurs méthodes de travail et progresser vers l’excellence. Lire la suite « De la résolution de problèmes au Kaizen »→
La crise pétrolière de 1973 marque un moment charnière : celui à partir duquel les habitants des pays du sud ont décidé d’arrêter de fournir de la matière première peu chère pour soutenir la croissance de la classe moyenne des pays occidentaux. Depuis lors, la sécurité de nos emplois est mise en danger par plusieurs facteurs, concentrons-nous sur trois d’entre eux.
Le premier est la mondialisation. Des gens de tous les pays souhaitent vivre comme la classe moyenne occidentale. Comment leur en vouloir ? A eux la possibilité de mener une vie décente, de payer des études à leurs enfants, et la perspective d’une promotion sociale.
Le deuxième est l’ennui. Depuis les années 90, les grandes entreprises ont consacré une quantité phénoménale d’énergie (et d’argent ! parlez-en à Oracle ou Salesforce) à rationaliser des processus et à les figer dans leurs systèmes d’information. Les collaborateurs sont maintenant soumis à des systèmes IT qui dysfonctionnent pour la majorité d’entre eux avec des processus pulvérisés dans un grand nombre de fonctions, et les employés, ayant perdu tout contact avec les clients, ne trouvent plus aucun sens à leur travail.
Le troisième est plus récent : il s’agit de l’automatisation et des algorithmes. Les ingénieurs rêvent de créer des systèmes desquels ils ont exclus les personnes, afin de supprimer la variabilité qu’ils reprochent aux humains, et avoir des systèmes purement technologiques et donc « parfaits » (hum hum). L’avènement de la robotisation et des algorithmes est l’eden secret de la culture de l’ingénierie.
Qu’est-ce qui nous attend ? Qui va sauver nos emplois ? Si vous vous posez sérieusement la question, rassurez-vous, l’ombre bienveillante de Taïchi Ohno veille sur vous. Car c’est le Lean qui peut nous aider à surmonter ces menaces, à conserver nos emplois et même à nous sentir plus impliqués dans nos jobs. Découvrez pourquoi….
Si Kiichiro Toyoda est l’inventeur du principe de juste à temps et Sakichi Toyoda l’inventeur du Jidoka (autonomation, qualité intégrée au processus de production), Ohno est l’inventeur du Kanban (la fiche de commande de production qu’un processus donne au processus en aval) et de la notion de supermarché appliquée à la production. Ces deux principes (Kanban et Supermarché) ont permis à Ohno de déployer en trente ans les deux premiers (Juste à Temps et Autonomation) sur l’ensemble des usines de Toyota (et chez ses fournisseurs). Il raconte non sans humour qu’avant de s’appeler le Toyota Production System, comme l’entreprise n’était pas certaine que ce système fonctionnait, ils l’ont appelé le Ohno Production System. Lire la suite « Workplace Management – Les mots de Taiichi Ohno (2/2) »→
Better, faster, together 