L'histoire est réelle, j'ai tout vu de mes propres yeux.
Pendant plusieurs années, un gars, comme beaucoup d’entre vous, a travaillé comme programmeur. Juste au cas où, je l'écrirai ainsi : « programmeur ». Parce qu'il était 1Snik, sur une société de production fixe.
Avant cela, il a essayé différentes spécialités - 4 ans en France en tant que programmeur, chef de projet, il a pu réaliser 200 heures, tout en percevant un pourcentage du projet, pour la gestion et en faisant un peu de vente. J'ai essayé de développer des produits par moi-même, j'étais chef du département informatique dans une grande entreprise de 6 1 personnes, j'ai essayé différentes options pour utiliser mon métier cité - programmeur XNUMXC.
Mais toutes ces positions étaient quelque peu sans issue, notamment en termes de revenus. A cette époque, nous recevions tous à peu près le même argent et travaillions dans les mêmes conditions.
Ce type se demandait comment gagner plus d’argent sans vendre ni créer sa propre entreprise.
Il se considérait comme un homme intelligent et décida de trouver une place dans l'entreprise où il travaillait. Cette niche devait être quelque chose de spécial, que personne n’occupait. Et je voulais que l'entreprise elle-même veuille payer de l'argent à une personne dans ce créneau, afin qu'il n'y ait pas besoin de tromper qui que ce soit ou de tromper quoi que ce soit. Pour atteindre cet objectif : une personne occupant ce poste doit être payée beaucoup d’argent. Un excentrique, en un mot.
La recherche fut de courte durée. Dans l'entreprise où travaillait ce type, il existait un créneau totalement libre que l'on pourrait appeler « mettre de l'ordre dans les processus commerciaux ». Chaque entreprise a beaucoup de problèmes. Quelque chose ne fonctionne toujours pas et personne ne viendra réparer le processus commercial. Il a donc décidé de s'essayer en tant que spécialiste capable d'aider le propriétaire à résoudre ses problèmes dans les processus commerciaux.
À cette époque, il travaillait pour l’entreprise depuis six mois et recevait le salaire moyen du marché. Il n’y avait rien à perdre, d’autant plus qu’il pouvait facilement retrouver le même emploi en une semaine. En général, ce type a décidé que rien de grave ne se produirait si tout à coup rien ne se passait et il était licencié.
Il reprit courage et vint chez le propriétaire. Je lui ai suggéré d'améliorer le processus le plus problématique de l'entreprise. A cette époque, il s’agissait de comptabilité d’entrepôt. Aujourd'hui, tous ceux qui travaillent dans cette entreprise ont même honte de se souvenir de ces problèmes, mais les inventaires, effectués trimestriellement, ont montré des écarts de plusieurs dizaines de pour cent entre le système comptable et les soldes réels. Et en coût, en quantité et en nombre de postes. Ce fut un désastre. En réalité, l'entreprise ne disposait des soldes corrects dans le système comptable que quatre fois par an, soit le lendemain de l'inventaire. Notre gars a commencé à mettre de l'ordre dans ce processus.
Le gars a convenu avec le propriétaire qu'il devrait réduire de moitié les écarts par rapport aux résultats de l'inventaire. De plus, le propriétaire n'avait rien de spécial à perdre, car avant notre héros, divers ouvriers avaient déjà tenté de tout réparer et, en général, la tâche était considérée comme pratiquement insoluble. Tout cela a grandement alimenté l'intérêt, car si tout se passait bien, le mec deviendrait automatiquement une personne qui sait mettre les choses en ordre et résoudre des problèmes insolubles.
Il s'est donc retrouvé confronté à une tâche : réduire de 2 fois les écarts basés sur les résultats des stocks en un an. Au début du projet, il ne savait pas comment y parvenir, mais il a compris que la comptabilité d'entrepôt est une chose simple et qu'il serait donc toujours capable de faire quelque chose d'utile. De plus, réduire les écarts de quelques dizaines de pour cent à une dizaine de pour cent ne semble pas si difficile. Quiconque a travaillé dans le conseil ou dans des activités similaires comprend que la plupart des problèmes de processus peuvent être résolus en suivant des étapes assez simples.
De janvier à mai, il a préparé, automatisé un peu, réécrit le processus commercial de comptabilité des entrepôts, modifié les flux de travail des magasiniers, des comptables et, en général, refait l'ensemble du système, sans rien montrer ni dire à personne. En mai, il a distribué de nouvelles instructions à tout le monde et après le premier inventaire de l'année, une nouvelle vie a commencé - en travaillant selon ses règles. Pour observer les résultats, l'entreprise a commencé à l'avenir à procéder à des inventaires plus souvent - une fois tous les deux mois. Les premiers résultats étaient déjà positifs et, à la fin de l'année, les écarts par rapport aux résultats de l'audit étaient tombés à une fraction de XNUMX pour cent.
Le succès fut colossal, mais on ne pouvait croire à sa pérennité. Le gars lui-même doutait que le résultat serait préservé s'il se retirait et arrêtait d'observer le processus. Néanmoins, il y a eu un résultat et le gars a reçu tout ce qu'il avait convenu avec le propriétaire. Puis, après plusieurs années, la stabilité du résultat s'est confirmée - pendant plusieurs années, les écarts sont restés inférieurs à 1 %.
Il a ensuite décidé de répéter l'expérience et a suggéré au propriétaire d'améliorer un autre processus problématique : l'approvisionnement. Il y avait des pénuries qui ne nous permettaient pas d’expédier les volumes souhaités par nos clients. Nous avons convenu que d'ici un an, les déficits seraient réduits de moitié et que le gars réaliserait également 10 à 15 projets liés à 1C - pour automatiser divers processus commerciaux et autres hérésies.
Au cours de la deuxième année, tout s'est à nouveau déroulé avec succès, les déficits ont été réduits de plus de 2 fois et tous les projets informatiques ont été menés à bien.
Comme le salaire satisfaisait déjà pleinement tous les besoins de ce type deux ans à l'avance, il a décidé de s'installer un peu, de se calmer et de s'asseoir dans un endroit confortable et chaleureux qu'il s'était créé.
Comment c'était ? Formellement, il était le directeur informatique. Mais qui il était réellement est difficile à comprendre. Après tout, que fait un directeur informatique ? En règle générale, il administre l'infrastructure informatique, gère les administrateurs système, met en œuvre un système ERP et participe aux réunions du conseil d'administration.
Et ce mec avait l'une des responsabilités clés de participer aux processus de changement, et principalement - génération, lancement de ces processus, recherche et proposition de solutions, application de nouvelles techniques de gestion, examen des changements proposés, analyse de l'efficacité des autres fonctions et divisions et, enfin, la participation directe au développement stratégique de l'entreprise, jusqu'à l'élaboration indépendante d'un plan stratégique pour l'ensemble de l'entreprise.
On lui a donné carte blanche. Il pouvait assister à n'importe quelle réunion à laquelle il n'avait pas eu accès auparavant. Je me suis assis là avec un bloc-notes, j'écrivais quelque chose ou j'écoutais simplement. Il parlait rarement. Puis il a commencé à jouer au téléphone, affirmant que la mémoire associative fonctionne mieux ainsi.
Lors de la réunion, il donnait rarement quelque chose d'utile. Il est parti, a réfléchi, puis une lettre est arrivée - soit avec une critique, soit avec une opinion, soit avec des suggestions, soit avec une description des solutions qu'il avait déjà appliquées.
Mais le plus souvent, il convoquait lui-même les réunions. J'ai trouvé un problème, proposé des solutions, identifié les parties intéressées et invité tout le monde à la réunion. Et puis - du mieux qu'il pouvait. Il a convaincu, motivé, prouvé, argumenté, réalisé.
Officieusement, il était considéré comme la troisième personne de l'entreprise, après le propriétaire et directeur. Bien sûr, il a terriblement exaspéré tous les « personnes de l'entreprise », à commencer par le numéro 4. Surtout avec ses jeans déchirés et ses T-shirts clairs, et aussi avec son temps en tant que propriétaire.
Le propriétaire lui donnait 1 heure par jour. Tous les jours. Ils ont parlé, discuté de problèmes, de solutions, de nouvelles entreprises, de domaines de développement, d'indicateurs et d'efficacité, de développement personnel, de livres et tout simplement de la vie.
Mais ce type était étrange. C’est comme asseoir et être heureux, la vie est belle. Mais non. Il décida de réfléchir.
Il se demandait : pourquoi cela a-t-il fonctionné pour lui, mais pas pour d’autres ? Le propriétaire l'a également poussé : il a dit qu'il voulait que d'autres puissent également rétablir l'ordre, car il y a beaucoup de managers, ils sont généralement engagés dans la gestion opérationnelle et la planification stratégique, mais pratiquement personne n'est engagé dans des changements systémiques. dans leurs processus. Il est peut-être écrit dans leur description de poste qu'ils doivent accélérer leur processus et accroître son efficacité, mais en réalité, personne ne le fait. Pourquoi donc? Le gars s'est aussi demandé pourquoi, et il est allé parler à tous ces managers.
Il s'adresse au directeur adjoint chargé de la qualité et lui suggère d'introduire des cartes de contrôle Shewhart afin que les produits soient meilleurs que les produits japonais. Mais il s'est avéré que le collègue ne savait pas ce qu'étaient les cartes de contrôle Shewhart, ce qu'était le contrôle statistique des processus, et avait seulement entendu parler de l'utilisation du cycle de Deming dans la gestion de la qualité. D'ACCORD…
Il s'est adressé à un autre directeur adjoint et lui a proposé d'introduire le contrôle. Mais je n'ai pas non plus trouvé de soutien ici. Un peu plus tard, il s'initie à la gestion des frontières (bordering management) et propose à tous les directeurs adjoints de mettre en œuvre la partie systémique de cette méthodologie afin d'améliorer les processus. Mais peu importe combien notre homme parlait, personne ne voulait vraiment approfondir de quoi il s'agissait. Peut-être qu'ils n'étaient pas intéressés ou que c'était trop difficile. Mais en fait, personne ne l’a compris.
En général, il a parlé de tout ce qu'il savait et utilisait dans l'entreprise. Mais personne ne l'a compris. Ils ne comprennent toujours pas pourquoi, par exemple, tout a été corrigé dans la comptabilité des entrepôts, ni ce que le contrôle de gestion et la gestion des frontières ont à voir avec cela.
Enfin, il a contacté ses programmeurs - le personnel comprenait 3 personnes. Il a parlé de gestion des frontières, de contrôle, de gestion de la qualité, d'agile et de Scrum... Et étonnamment, ils ont tout compris, et ont même pu discuter d'une manière ou d'une autre avec lui, y compris les subtilités techniques et méthodologiques. Ils ont compris pourquoi les projets d’entrepôt et d’approvisionnement ont fonctionné. Et puis le gars s'est rendu compte : en fait, les programmeurs sauveraient le monde.
Les programmeurs, réalisa-t-il, sont les seuls à pouvoir comprendre les processus métier normalement, avec les détails nécessaires.
Pourquoi eux ? En fait, il n’a jamais trouvé de réponse claire. Je n'ai formulé que des indices de thèse.
Premièrement, les programmeurs connaissent les domaines de l’entreprise et ils les connaissent mieux que tous les autres membres de l’entreprise.
De plus, les programmeurs comprennent vraiment ce qu’est un algorithme de processus. Ceci est important car les processus métiers sont des algorithmes et leurs éléments peuvent tout simplement ne pas être cohérents. Par exemple, dans le processus d'approvisionnement sur lequel le gars travaillait, la première étape consistait à créer un plan d'achat annuel et la seconde était les achats quotidiens. Ces étapes sont reliées par une connexion directe, c'est-à-dire qu'il est supposé que les personnes doivent travailler selon cet algorithme - établir un plan d'approvisionnement annuel et exécuter immédiatement la demande. Le plan annuel de passation des marchés est établi une fois par an et les candidatures sont reçues 50 fois par jour. C'est là que se termine l'algorithme et vous devez y travailler. En fait, explique-t-il, pour les programmeurs, la connaissance des algorithmes constitue un avantage concurrentiel, car quiconque ne les connaît pas ne comprend tout simplement pas comment un processus métier doit fonctionner ni comment il peut être représenté.
Un autre avantage des programmeurs, selon le gars, est qu'ils disposent de suffisamment de temps libre. Nous comprenons tous comment un programmeur peut consacrer trois fois plus de temps à une tâche que ce dont elle a réellement besoin, et peu de gens le remarqueront. Ceci, encore une fois, constitue un avantage concurrentiel, car pour mettre de l'ordre dans certains processus commerciaux, vous devez disposer de beaucoup de temps libre - réfléchir, observer, étudier et essayer.
La plupart des managers, selon le gars, n'ont pas ce temps libre et en sont fiers. Bien qu'en fait, cela signifie qu'une personne ne peut pas devenir efficace parce qu'elle n'a pas le temps d'améliorer son efficacité - un cercle vicieux. Dans notre culture, il est de bon ton d'être occupé, donc tout reste pareil. Et pour nous, programmeurs, c'est un avantage. Nous pouvons trouver du temps libre et penser à tout.
Les programmeurs, dit-il, peuvent modifier rapidement un système d'information. Cela ne s'applique pas à toutes les entreprises, mais partout où il travaillait, il pouvait apporter toutes les modifications qu'il souhaitait. Surtout s'ils ne concernent pas le travail de quelqu'un d'autre. Par exemple, il pourrait lancer un système qui mesurerait secrètement les actions des utilisateurs, puis utiliser ces informations pour analyser l'efficacité du même service comptable et suivre le coût de la comptabilité.
Et la dernière chose dont je me souviens de ses paroles, c'est que les programmeurs ont accès à une grande quantité d'informations, parce que... avoir un accès administratif au système. Ils peuvent donc utiliser ces informations dans leur analyse. Personne d’autre dans une usine ordinaire ne dispose d’une telle ressource.
Et puis il est parti. Pendant les deux semaines de détention requises, nous l'avons forcé à partager son expérience parce que nous voulions continuer le travail qu'il faisait. Eh bien, son poste est devenu vacant.
Pendant plusieurs jours, ils l'ont assis sur une chaise, ont allumé la caméra et ont enregistré ses monologues. Ils nous ont demandé de nous parler de tous les projets réalisés, des méthodes, des approches, des réussites et des échecs, des causes et des effets, des portraits de managers, etc. Il n'y avait pas de restrictions particulières, car Ils ne savaient pas ce qui se passait dans sa tête.
Les monologues, bien sûr, n'étaient pour la plupart que des bêtises et des rires - il était de bonne humeur, parce que quittait l'arrière-pays pour Saint-Pétersbourg. Où faut-il aller travailler à Saint-Pétersbourg ? À Gazprom, bien sûr.
Mais nous avons réussi à extraire quelque chose d'utile de ses monologues. Je vais vous dire ce dont je me souviens.
Donc, les recommandations de ce type. Pour ceux qui veulent essayer de mettre de l'ordre dans les processus commerciaux.
Pour effectuer ce genre de travail, il faut d'abord avoir un certain niveau de « gelures ». Il ne faut pas avoir peur de perdre son emploi, ne pas avoir peur de prendre des risques, ne pas avoir peur des conflits avec ses collègues. Cela a été facile pour lui, car il a commencé son voyage alors qu'il travaillait dans l'entreprise depuis seulement six mois, qu'il n'avait pas le temps d'entrer en contact avec qui que ce soit et qu'il n'avait pas l'intention de le faire. Il a compris que les gens vont et viennent, mais ses propres résultats et leur évaluation par le propriétaire de l'entreprise sont importants pour lui. Que ses collègues le traitent bien ou mal ne l'inquiétait alors guère.
Le deuxième point est que pour faire ce travail efficacement, vous devrez malheureusement étudier. Mais n'étudiez pas pour un MBA, ni dans des cours, ni dans des instituts, mais par vous-même. Par exemple, dans son premier projet, un projet d’entrepôt, il a agi de manière intuitive, il ne savait rien, juste ce qu’était la « gestion de la qualité ».
Lorsqu'il a commencé à lire la littérature sur les méthodes existantes pour augmenter l'efficacité, il a découvert les technologies qu'il utilisait. Le gars les a appliqués intuitivement, mais il s'avère que ce n'était pas son invention, tout était déjà écrit il y a longtemps. Mais il a passé du temps, et bien plus que s'il avait immédiatement lu le bon livre. Ici, il est seulement important de comprendre que lorsque vous étudiez une technique spécifique, aucune d'entre elles, même la plus avancée, ne résoudra complètement tous les problèmes d'un processus métier.
La deuxième astuce est que plus vous connaissez de techniques, mieux c'est. Par exemple, dans l'ancien Japon vivait Miyamoto Musashi, l'un des épéistes les plus célèbres, l'auteur du style à deux épées. Il a étudié dans une école avec un maître, puis a voyagé à travers le Japon, s'est battu avec différents mecs. Si le gars était plus fort, le voyage s'arrêtait pendant un certain temps et Musashi devenait étudiant. En conséquence, pendant plusieurs années, il a acquis les compétences de diverses pratiques de différents maîtres et a formé sa propre école, en y ajoutant quelque chose qui lui était propre. En conséquence, il a acquis une compétence unique. C'est la même chose ici.
Vous pouvez bien entendu agir en tant que consultant en entreprise. En général, ce sont des gars formidables. Mais, en règle générale, ils viennent introduire une sorte de méthodologie et mettent en œuvre la mauvaise méthodologie dont l'entreprise a besoin. Nous avons également eu des situations très tristes : personne ne sait comment résoudre le problème et personne ne veut réfléchir à la manière de le résoudre. Nous commençons à chercher soit sur Internet, soit appelons un consultant et lui demandons ce qui peut nous aider. Le consultant réfléchit et dit qu'il faut introduire la théorie des contraintes. Nous le payons pour sa recommandation, nous dépensons de l'argent pour la mise en œuvre, mais les résultats sont nuls.
Pourquoi cela arrive-t-il? Parce que le consultant l'a dit, nous introduisons tel ou tel système, et tout le monde était d'accord avec lui. Génial, mais une méthodologie ne couvre pas tous les problèmes d'un seul processus métier, surtout si les conditions préalables initiales - les nôtres et celles nécessaires à la mise en œuvre de la méthodologie - ne coïncident pas.
Dans la pratique recommandée par le gars, vous devez prendre le meilleur et mettre en œuvre le meilleur. Ne prenez pas les méthodes dans leur intégralité, mais prenez leurs principales caractéristiques, caractéristiques et pratiques. Et le plus important est d’en comprendre l’essence.
Prenez, dit-il, par exemple Scrum ou Agile. Dans ses monologues, le gars a répété à plusieurs reprises que tout le monde ne comprend pas pleinement l'essence de Scrum. Il a également lu le livre de Jeff Sutherland, que certains trouvent « léger ». Cela lui a semblé une lecture approfondie, car l'un des principes fondamentaux de Scrum est la gestion de la qualité, cela est écrit directement dans le livre.
Il parle de Toyota Production, de la manière dont Jeff Sutherland a présenté Scrum au Japon, de la façon dont il s'est implanté là-bas et à quel point il était proche de leur philosophie. Et Sutherland a parlé de l'importance du rôle du Scrum Master, du cycle de Deming. Le rôle du Scrum Master est d’accélérer constamment le processus. Tout le reste dans Scrum - livraison progressive, satisfaction du client, liste claire des travaux pour la période de sprint - est également important, mais tout cela doit avancer de plus en plus vite. La vitesse de travail doit augmenter constamment dans les unités dans lesquelles elle est mesurée.
C'est peut-être une question de traduction, car notre livre a été traduit par « Scrum - une méthode révolutionnaire de gestion de projet », et si le titre anglais est traduit littéralement, il s'avérera : « Scrum - deux fois plus en deux fois moins de temps » , c'est-à-dire même dans Le nom fait référence à la vitesse comme fonction clé de Scrum.
Lorsque ce type a implémenté Scrum, la vitesse a doublé au cours du premier mois sans aucun changement significatif. Il a trouvé des points de changement et a modifié Scrum lui-même pour le faire fonctionner beaucoup plus rapidement. La seule chose qu'ils écrivent sur Internet, c'est qu'ils ont été confrontés à la question : « Nous avons doublé la vitesse, il ne reste plus qu'à comprendre ce que nous faisons à une telle vitesse ? Mais c'est un tout autre domaine...
Il a également personnellement recommandé plusieurs techniques. Il les a qualifiés de fondamentaux et fondamentaux.
Le premier est la gestion des frontières.
Ils l'enseignent à Skolkovo ; selon le gars, il n'y a pas d'autres livres ni matériels. Il a eu la chance d'assister à une conférence d'un professeur de Harvard qui prêche la gestion des frontières, et a également lu plusieurs articles dans la Harvard Business Review sur le travail d'Eric Trist.
La gestion des limites signifie que vous devez être capable de voir les limites et de travailler avec celles-ci. Il existe de nombreuses frontières, elles sont partout : entre les départements, entre les différents types de travail, entre les fonctions, entre le travail opérationnel et analytique. La connaissance de la gestion des frontières ne révèle pas de vérités supérieures, mais elle nous permet de voir la réalité sous un jour légèrement différent – à travers le prisme des frontières. Et, en conséquence, gérez-les - érigez-les là où cela est nécessaire et retirez-les là où ils gênent.
Mais le plus souvent, le gars parlait de contrôle. Il avait juste une sorte de bizarrerie sur ce sujet.
En bref, contrôler est une gestion basée sur les chiffres. Ici, dit-il, chaque partie de la définition est importante – à la fois « gestion », « basée sur » et « chiffres ».
Nous, dit-il, sommes mauvais dans les trois composantes du contrôle. D’autant plus qu’ils sont étroitement interconnectés les uns avec les autres et avec d’autres parties du système commercial.
La première chose qui est mauvaise, ce sont les chiffres. Il y en a peu et ils sont de mauvaise qualité.
Nous avons ensuite récupéré une partie importante des chiffres du système d'information 1C. Ainsi, la qualité des chiffres dans 1C, comme il l'a affirmé, n'est pas bonne. Au minimum, en raison de la possibilité de modifier les données de manière rétroactive.
Il est clair que ce n'est pas la faute des développeurs 1C - ils ne prennent en compte que les exigences du marché et la mentalité de la comptabilité nationale. Mais à des fins de contrôle, il est préférable de modifier les principes du travail 1C avec les données d'une entreprise spécifique.
De plus, les chiffres de 1C, selon lui, subissent un traitement semi-manuel, à l'aide d'Excel par exemple. Un tel traitement n’ajoute pas non plus de qualité aux données, ni d’efficacité.
En fin de compte, quelqu'un d'autre revérifie le rapport final afin de ne pas soumettre accidentellement des chiffres contenant des erreurs au responsable. En conséquence, les numéros parviennent au destinataire beaux, vérifiés, mais très tard. Habituellement - après la fin de la période (mois, semaine, etc.).
Et ici, dit-il, tout est très simple. Si les chiffres de janvier vous sont parvenus en février, alors vous ne pouvez plus gérer les activités de janvier. Parce que janvier est déjà terminé.
Et si les chiffres sont basés sur la comptabilité, et que l'entreprise est la plus ordinaire, avec soumission trimestrielle de la TVA, alors son dirigeant reçoit des chiffres relativement adéquats une fois par trimestre.
Le reste est clair. Vous recevez des numéros une fois par mois - vous avez la possibilité de gérer par numéros (c'est-à-dire de contrôler) 12 fois par an. Si vous pratiquez le reporting trimestriel, vous le gérez 4 fois par an. Plus un bonus - un rapport annuel. Dirigez-vous encore une fois.
Le reste du temps, le contrôle s’effectue généralement à l’aveugle.
Quand (et si) les chiffres apparaissent, alors le deuxième problème entre en jeu : comment gérer en fonction des chiffres ? Je ne peux pas être d'accord avec ce point de son raisonnement.
Le gars a fait valoir que si le manager n’avait pas les chiffres auparavant, leur apparition provoquerait un effet wow. Il regardera et déformera les chiffres d'un côté et de l'autre, appellera les gens sur le tapis, exigera des explications et des enquêtes. Après avoir joué avec les chiffres, effectué des analyses et promis de manière menaçante à tous les salariés que « maintenant je ne me débarrasserai pas de vous », le manager va très vite se calmer et abandonner sur cette affaire. Arrêtez d'utiliser l'outil. Mais les problèmes resteront en place.
Cela se produit, a-t-il expliqué, en raison de compétences managériales insuffisantes. Dans le contrôle, tout d’abord. Le manager ne sait tout simplement pas quoi faire de ces chiffres. Quoi сfaire - sait quoi faire - non. Faire, c'est ce qui est écrit ci-dessus (se disputer, jouer). Faire est un processus commercial quotidien.
Selon lui, tout est très simple : le numérique doit faire partie du processus commercial. Dans le processus commercial, il doit être clairement clair : qui doit faire quoi et quand si les chiffres s'écartent de la norme (toutes les options - au-dessus de la frontière, en dessous de la frontière, au-delà du couloir, présence d'une tendance, non-respect des quantile, etc.)
Il a ainsi souligné le dilemme clé : le nombre existe, il devrait faire partie du système d'entreprise afin d'augmenter l'efficacité de la gestion, mais... ce n'est pas le cas. Pourquoi?
Car le dirigeant russe ne cédera pas une part de son pouvoir à un concurrent.
Les concurrents du manager russe - un processus commercial de haute qualité et fonctionnel, une motivation bien pensée et mutuellement bénéfique et une automatisation appropriée - laisseront hélas le manager sans emploi.
C'est un peu absurde, tu n'es pas d'accord ? Surtout concernant les dirigeants. D'accord, je te l'ai dit, tu décides toi-même.
Un peu moins, mais quand même trop, à mon avis, il a parlé de Scrum.
Assurez-vous, ai-je dit, de lire et d'essayer Scrum en pratique. Si, dit-il, vous l’avez lu mais ne l’avez pas essayé, considérez-vous comme ignorant. Il vaut mieux lire un livre, par exemple de Sutherland, plutôt que des articles et toutes sortes de guides (c'est quoi ce bordel ?) sur Internet.
Scrum, a-t-il dit, ne peut être appris que par la pratique et avec des mesures obligatoires de la quantité de travail effectué. Essayez personnellement les deux rôles les plus importants : Product Owner et Scrum Master.
Il est particulièrement important, selon le gars, d'expérimenter en pratique le rôle d'un Scrum Master, lorsque vous pouvez augmenter le volume de tâches accomplies par sprint sans augmenter les ressources et le coût du sprint.
Eh bien, à son sommet, il y avait la TOS (théorie des limitations du système).
Selon le gars, ce sont les principes fondamentaux de base pour accroître l'efficacité qui peuvent être appliqués dans presque tous les domaines, dans n'importe quel processus commercial et système commercial dans son ensemble.
Lorsqu’il a découvert que nous ne connaissions pas TOS, il a arrêté de nous le dire. Il a seulement ajouté qu’il ne nous priverait pas du plaisir de lire les livres d’Eliyahu Goldratt. Il a donné une recommandation similaire à Scrum : lisez-la et essayez-la. Par exemple, quel que soit le poste que vous occupez, quel que soit le travail que vous effectuez, il est possible d'augmenter l'efficacité en utilisant les méthodes TOC.
Puis son sac de techniques s'est apparemment tari, et il a dit : mélangez les principes pour créer des solutions appliquées dans une situation spécifique.
C’est là, dit-il, la principale recommandation, la clé du succès. Comprendre les principes, l'essence et créer des solutions d'application uniques - processus métier et systèmes métier.
Ensuite, il a essayé de se souvenir d'une citation et, à la fin, il a dû se connecter. Il s’est avéré qu’il s’agissait d’une citation de l’article « Debout sur les épaules de géants » d’Eliyahu Goldratt :
« Il existe une différence entre les solutions appliquées (applications) et les concepts fondamentaux sur lesquels ces solutions sont basées. Les concepts sont généraux ; les solutions appliquées sont l’adaptation des concepts à un environnement spécifique. Comme nous l’avons déjà vu, une telle adaptation n’est pas simple et nécessite l’élaboration de certains éléments de solution. Il faut rappeler qu’une solution applicative repose sur des hypothèses initiales (parfois cachées) sur un environnement précis. Il ne faut pas s’attendre à ce que cette solution d’application fonctionne dans un environnement pour lequel les hypothèses ne sont pas correctes.
Il a déclaré que le travail d'un programmeur et d'un « améliorateur de processus métier » est très similaire. Et gauche.
Source: habr.com