En tant que CIO, une grande partie de ce que vous faites consiste à concevoir des choses, et c’est à ce moment-là que vous ne supervisez pas d’autres personnes qui conçoivent des choses. Ou lorsque vous ne vous assurez pas que tout ce que tout le monde conçoit s’emboîte comme il se doit.
Il existe des règles universelles qui régissent une bonne conception, peu importe ce qui est conçu. Le plus célèbre est probablement le dicton du grand architecte Louis Sullivan selon lequel la forme suit la fonction. Moins connu, mais tout aussi important (au moins pour notre contexte) est celui introduit par W. Edwards Deming : Pour optimiser l’ensemble il faut sous-optimiser les parties.
Cela compte, peu importe ce qui est conçu, qu’il s’agisse d’un gadget, d’un logiciel, d’une organisation ou d’un processus. Et c’est la clé pour comprendre pourquoi tant de DSI se trompent en matière d’optimisation.
De file d’attente en file d’attente : le goulot d’étranglement caché des processus
Si les DSI pouvaient gagner leur vie grâce à une seule astuce, l’optimisation des processus le serait probablement. Il est essentiel que l’informatique remplisse bien son rôle, et une grande partie de ce que fait l’informatique dans la vie consiste également à aider les chefs d’entreprise à optimiser leurs processus.
Les optimiseurs de processus à l’intérieur et à l’extérieur de l’informatique ont une multitude de cadres et de méthodologies à leur disposition. Lean est parmi les plus populaires, alors utilisons cela pour illustrer ce point.
La contribution la plus importante mais la moins reconnue de la pensée Lean au monde de l’optimisation des processus est peut-être que les processus ne sont pas des ensembles de tâches qui passent d’une case à l’autre.
Au lieu de cela, ce sont des tâches qui circulent de file d’attente en file d’attente en file d’attente. La différence peut sembler subtile, mais c’est l’une des raisons pour lesquelles l’optimisation d’un tout donne des résultats différents de l’optimisation des parties d’un tout. Cela peut ressembler à un hoo-ha académique ou à un koan informatique, mais comprendre cette différence est essentiel pour maîtriser l’optimisation des processus.
Écoutez-moi.
Imaginez que vous gérez un projet qui a besoin d’un nouveau serveur pour continuer, en supposant que pour le moment, l’informatique n’est pas entièrement cloud et possède toujours des serveurs et un centre de données. Vous suivez la procédure et soumettez une demande à la file d’attente des demandes informatiques.
En simplifiant un peu, la vue boîte à boîte de ce qui suit ressemblerait à la figure ci-dessous :
C’est un flux simple. Les équipes en charge de chaque étape ont depuis longtemps optimisé les procédures de prise en charge de leurs responsabilités. L’effort total et la durée du cycle de processus sont les mêmes – pour cet exemple hypothétique, comptez environ huit heures ou un jour sur le calendrier du projet.
Mais la vision boîte à boîte du processus est erronée. Le processus réel ressemble plus à la figure suivante :
Chaque étape du processus est gérée comme une file d’attente premier entré, premier sorti (FIFO). Les équipes travaillent sur les demandes uniquement lorsque la demande a traversé la file d’attente et est ressortie pour être traitée. L’effort total est le même que celui estimé dans la vue boîte à boîte. Mais le temps de cycle inclut à la fois le temps de travail et le temps en file d’attente – pour ce processus modélisé, cinq jours plus ou moins.
L’analyse proprement dite est plus compliquée que cela. Habituellement, une étape finit par être un goulot d’étranglement ; le travail s’empile dans sa file d’attente tandis que les autres files d’attente s’épuisent, contrebalancées par toutes les files d’attente recevant des demandes de plusieurs sources. Mais cela ne change pas le principe, seulement la complexité de la simulation.
C’est réel, pas seulement théorique. Il n’y a pas si longtemps, un client, dont la taille des files d’attente était un peu plus longue que ce qui est décrit ci-dessus, a connu des retards de projet de plusieurs mois alors que ses équipes attendaient l’installation des serveurs approuvés dont il dépendait, même si un serveur typique n’en avait pas besoin de plus. effort pour acquérir, configurer et installer que ce qui est décrit ci-dessus.
La cause-racine? Les gestionnaires responsables de l’approvisionnement, de l’administration du réseau, de l’installation des logiciels, de l’assurance qualité et du déploiement avaient tous organisé le travail de leurs services pour optimiser l’utilisation et le rendement du personnel.
Ils – les parties – s’étaient optimisés au détriment de l’ensemble de chaque projet.
Éliminer les externalités
La solution, que les passionnés de DevOps reconnaîtront et adopteront immédiatement, consistait à inclure des analystes de l’infrastructure informatique dans l’équipe principale du projet et, plus important encore, à inclure des tâches d’infrastructure telles que la configuration des serveurs dans le plan de travail de chaque projet, l’attribution de dates de début et d’échéance. dates basées sur le moment où leurs produits de travail seraient nécessaires.
Avec ce changement, les builds de serveur sont devenus une partie du calendrier du projet au lieu d’être des externalités sur lesquelles le chef de projet n’avait aucun contrôle.
En échange, le CIO devait accepter que si les projets devaient livrer leurs résultats dans les délais et dans les limites de leurs budgets, le reste de l’organisation informatique devrait permettre un certain relâchement dans leur gestion du travail. Les objectifs d’utilisation du personnel n’approcheraient pas et ne devraient même pas approcher les 100 %. (Conseil de pro : consacrez du temps à la recherche d’Eliyahu Goldratt Chaîne critique méthodologie de gestion de projet pour une compréhension plus approfondie de ce point.)
L’effondrement du MBO
Le problème d’optimisation/sous-optimisation s’applique à bien plus que la conception de processus. Prenons, par exemple, la rémunération de la direction.
À l’époque, la gestion par objectifs (MBO) était une théorie populaire sur la façon de tirer le meilleur parti de l’organisation en tirant le meilleur parti de chaque responsable de l’organisation. Son défaut fatal était également de ne pas reconnaître les conséquences inévitables mais imprévues de l’optimisation des parties au détriment de l’ensemble.
La façon dont cela a fonctionné – ne pas travailler est une meilleure façon de le dire – était que, comme son nom l’indique, les dirigeants de l’entreprise assignaient à chaque gestionnaire un ou plusieurs objectifs. Les managers, compte tenu de la clarté accrue de ce qu’ils étaient censés accomplir, se sont mis à l’accomplir avec une ferveur monomaniaque, sans être gênés par les distractions de ce dont tout autre manager de l’organisation avait besoin pour atteindre ses propres objectifs.
Les organisations modernes qui souffrent de ce que leurs habitants appellent la « pensée en silo » avec leur incapacité à collaborer sont des vestiges de l’ère MBO.
Aider impuissant le service d’assistance
Comme quelqu’un l’a dit un jour – ou vraiment comme presque tous les managers l’ont dit chaque fois que le sujet est abordé – il n’y a pas d’organigrammes parfaits. Le principe d’optimisation/sous-optimisation de Deming est un contributeur clé aux imperfections de l’organigramme.
Prenez le service d’assistance classique et sa position au sein de la conception organisationnelle de l’informatique. Il a des objectifs de niveau de service pour le délai entre le premier contact de l’utilisateur final et la réponse initiale du service d’assistance ; également une cible pour le temps nécessaire pour résoudre le problème de l’utilisateur final. Quelque part là-dedans, il y a aussi un objectif de minimiser le coût par incident.
Imaginez que la gestion de chaque incident signalé inclut le temps passé à le consigner, et soit le temps passé à essayer de le résoudre, soit le temps passé à s’en débarrasser en le transférant à une autre équipe informatique.
Le moyen le plus simple pour le service d’assistance d’atteindre son niveau de service de réponse initial est d’en faire le moins possible lors de la réponse initiale, en transmettant chaque incident aussi rapidement que possible. Ainsi, les analystes du service d’assistance sont libres de répondre au prochain appel et évitent de s’enliser dans la résolution de problèmes qu’ils ne sont pas équipés pour gérer. Mieux encore, en dirigeant les problèmes vers les départements les plus compétents, les incidents seront résolus plus rapidement que si les analystes du service d’assistance essayaient de les résoudre eux-mêmes.
Malheureusement, cette approche garantit également que les analystes du service d’assistance n’apprendront jamais à gérer des problèmes similaires à l’avenir. Et même si cela réduit également les coûts du service d’assistance, cela se fait au détriment des talents les plus chers de leur ensemble actuel de priorités, qui, du point de vue de la valeur globale, sont probablement plus importantes.
L’optimisation du service d’assistance se termine par un exercice de transfert sans contrainte des coûts et des responsabilités. Le coût total de la gestion des incidents augmente proportionnellement à la diminution des propres coûts du service d’assistance.
Pour optimiser l’ensemble, il faut sous-optimiser les parties. Ces conseils peuvent ne pas sembler concrets et pragmatiques, mais ne vous laissez pas décourager par leurs connotations ésotériques. Si vous voulez obtenir les meilleurs résultats, assurez-vous que toutes les personnes impliquées dans l’obtention de ces résultats savent ce qu’ils sont censés être.
Aussi que personne ne sera pénalisé en collaborant à leur réalisation.
Source link