L'histoire est réelle, je l'ai vue de mes propres yeux.
Il y a quelques années, un gars, comme beaucoup d'entre vous, travaillait comme programmeur. Juste pour être sûr, je vais écrire ainsi : « programmeur ». Parce qu'il était un spécialiste 1C, dans une entreprise de production.
Avant cela, il avait essayé différentes spécialités – 4 ans en tant que programmeur dans une franchise, chef de projet, réussissant à clôturer jusqu'à 200 heures, tout en prenant un pourcentage du projet, en dirigeant et en faisant un peu de vente. Il a essayé de développer des produits par lui-même, a été chef du département IT dans une grande entreprise de 6 000 personnes, essayant différentes façons d'appliquer son métier de programmeur 1C.
Mais toutes ces positions étaient un peu des impasses, surtout en ce qui concerne les revenus. À cette époque, nous gagnions tous à peu près le même argent, travaillions dans les mêmes conditions.
Ce gars a commencé à s'interroger sur comment gagner plus d'argent, sans se lancer dans les ventes et sans créer sa propre entreprise.
Il s'est pris pour un génie et a décidé de trouver une niche dans l'entreprise où il travaillait. Cette niche devait être spéciale, inoccupée par personne. Et il souhaitait que l'entreprise soit prête à payer une personne dans cette niche, pour ne pas avoir à tromper quelqu'un ou à manipuler quoi que ce soit. Pour que ce soit objectif : une personne à cette position devait être bien rémunérée. Un original, en somme.
Les recherches n'ont pas été longues. Dans la société où ce gars travaillait, il y avait une niche totalement libre, que l'on peut qualifier d'« organisation des processus d'affaires ». Dans chaque entreprise, il y a plein de problèmes. Il y a toujours quelque chose qui ne fonctionne pas, et il n'y a personne pour venir corriger le processus d'affaires. Eh bien, il a décidé d'essayer de se positionner comme un spécialiste capable d'aider le propriétaire à résoudre ses problèmes liés aux processus d'affaires.
À ce moment-là, il travaillait dans l'entreprise depuis six mois et percevait un salaire moyen sur le marché. Il n'avait rien à perdre – d'autant plus qu'il aurait pu trouver un emploi similaire en une semaine. En gros, ce gars a pensé que rien de grave ne se passerait si jamais cela ne fonctionnait pas et qu'il était renvoyé.
Il a pris son courage à deux mains et est venu voir le propriétaire. Il lui a proposé d'améliorer le processus le plus problématique de l'entreprise. À l'époque, il s'agissait de la gestion des stocks. Aujourd'hui, même ceux qui travaillent dans cette entreprise ont honte de se souvenir de ces problèmes, mais les inventaires réalisés trimestriellement montraient des écarts de plusieurs dizaines de pourcents entre le système comptable et les stocks réels, tant en valeur qu'en quantité, et en nombre de postes. C'était un véritable cauchemar. L'entreprise avait en réalité des stocks corrects dans le système comptable seulement quatre fois par an - le lendemain de l'inventaire. C'est ce processus que notre jeune homme s'est chargé de remettre en ordre.
Le jeune homme a convenu avec le propriétaire qu'il devait réduire de moitié les écarts sur les résultats d'inventaire. De plus, le propriétaire n'avait pas grand-chose à perdre, car avant notre héros, d'autres employés avaient déjà tenté de corriger la situation, et la tâche était considérée comme presque insoluble. Tout cela a fortement attisé l'intérêt, car si tout réussissait, le gars deviendrait automatiquement quelqu'un capable de mettre de l'ordre et de résoudre des problèmes apparemment insolubles.
Ainsi, il avait pour mission de réduire les écarts sur les résultats d'inventaire de moitié en un an. Au début du projet, il ne savait pas comment y parvenir, mais il comprenait que la gestion des stocks était quelque chose de simple, donc il pourrait quand même accomplir quelque chose d'utile. D'autant plus que réduire les écarts de plusieurs dizaines de pourcents à une dizaine de pourcents, ce n'était pas si difficile que ça. Tous ceux qui travaillent dans le conseil ou un domaine similaire savent que la plupart des problèmes de processus peuvent être résolus par des actions assez simples.
De janvier à mai, il s'est préparé, a automatisé certaines tâches, a réécrit le processus commercial de gestion des stocks, a changé les flux de travail des magasiniers et des comptables, et a complètement redéfini le système, sans rien montrer ni expliquer à personne. En mai, il a distribué de nouvelles instructions à tous, et après le premier inventaire de l'année, une nouvelle vie a commencé – le travail selon ses règles. Pour observer les résultats, l'entreprise a ensuite commencé à réaliser des inventaires plus fréquemment – une fois tous les deux mois. Déjà les premiers résultats étaient positifs, et d'ici la fin de l'année, les écarts dans les résultats d'audit étaient tombés à des fractions de un pour cent.
Le succès a été colossal, mais sa durabilité était mise en doute. Le jeune homme lui-même doutait que les résultats seraient maintenus s'il s'éloignait et cessait de surveiller le processus. Cependant, le résultat était là, et il a obtenu tout ce qu'il avait convenu avec le propriétaire. Puis, après quelques années, la durabilité des résultats a été confirmée – pendant plusieurs années, les écarts sont restés dans la limite de 1 %.
Alors, il a décidé de répéter l'expérience et a proposé au propriétaire d'améliorer un autre processus problématique – l'approvisionnement. Il y avait des pénuries qui empêchaient d'expédier les volumes que nos clients désiraient. Ils ont convenu que, sur un an, les pénuries seraient réduites de moitié, et le gars réaliserait encore 10-15 projets liés à 1C — pour automatiser différents processus commerciaux et autres.
Au cours de la deuxième année, tout a de nouveau été réussi, les pénuries ont été réduites de plus de deux fois, tous les projets IT ont été menés à bien.
Puisque le salaire satisfaisait déjà toutes les demandes du jeune homme pour deux ans à venir, il a décidé de se calmer un peu, de se poser et de profiter d'un endroit confortable et chaleureux qu'il avait lui-même créé.
Qu'est-ce que cela représentait réellement ? Formelement, il était directeur IT. Mais pour déterminer qui il était réellement, c'est difficile. Que fait en général un directeur IT ? En règle générale, il administre l'infrastructure IT, dirige les administrateurs systèmes, implante un système ERP, participe à des réunions au conseil d'administration.
Pour ce gars, l'une de ses responsabilités clés était de participer aux processus de changement, principalement en générant et initiant ces processus, en recherchant et proposant des solutions, en appliquant de nouvelles méthodes de gestion, en expertisant les changements proposés, en analysant l'efficacité d'autres fonctions et départements, et enfin — en participant directement au développement stratégique de l'entreprise, allant jusqu'à développer de manière autonome le plan stratégique de l'ensemble de la société.
On lui a donné carte blanche. Il pouvait assister à n'importe quelle réunion, auxquelles il n'avait pas accès auparavant. Il s'y installait avec un bloc-notes, notait quelque chose ou simplement écoutait. Il parlait rarement. Ensuite, il a commencé à jouer sur son téléphone — affirmant que cela améliorait sa mémoire associative.
Lors des réunions, il ne produisait que rarement quelque chose d'utile. Il partait, réfléchissait, puis recevait un e-mail — soit avec des critiques, soit avec des opinions, soit avec des propositions, soit avec des descriptions de solutions qu'il avait déjà mises en œuvre.
Mais il organisait plus souvent lui-même des réunions. Il identifiait un problème, proposait des solutions, déterminait les personnes concernées et entraînait tout le monde dans la salle de négociation. Là, il persuadait, motivait, prouvait, argumentait, obtenait ce qu'il voulait.
Officieusement, il était considéré comme la troisième personne de l'entreprise, après le propriétaire et le directeur. Bien sûr, il agaçait énormément toutes les « personnes de l’entreprise », à partir du numéro 4. Surtout avec ses jeans déchirés et ses t-shirts colorés, sans oublier le temps du propriétaire.
Le propriétaire lui consacrait 1 heure par jour. Chaque jour. Ils discutaient, abordaient des problèmes, des solutions, de nouvelles activités, des orientations de développement, des indicateurs et des performances, son développement personnel, des livres, et tout simplement — la vie.
Mais ce gars était étrange. Il semblait que tout allait bien, que la vie était réussie. Mais non. Il a décidé de réfléchir.
Il s'est demandé pourquoi il avait réussi alors que d'autres ne l'avaient pas fait. Le propriétaire l'a aussi encouragé, lui disant qu'il souhaitait que les autres réussissent également à instaurer de l'ordre, car il y a beaucoup de managers, qui, en règle générale, s'occupent de la gestion opérationnelle et de la planification stratégique, mais pratiquement personne ne s'occupe des changements systémiques de ses processus. Peut-être que leur description de poste stipule qu'ils doivent accélérer leur processus, améliorer son efficacité, mais en fait, personne ne s'en occupe. Pourquoi ? Ce jeune homme s'est également demandé pourquoi, et il est donc allé discuter avec tous ces managers.
Il a rencontré le directeur adjoint de la qualité et a proposé d'implémenter des cartes de contrôle de Shewhart, afin que la production soit meilleure que celle des Japonais. Mais il s'est avéré que son collègue ne savait pas ce qu'étaient les cartes de contrôle de Shewhart, ni ce qu'était la gestion statistique des processus, et il n'avait entendu parler du cycle de Deming dans la gestion de la qualité qu'en passant. Bon...
Il est allé voir un autre directeur adjoint et a proposé d'implémenter le contrôle de gestion. Mais là encore, il n'a pas trouvé de soutien. Un peu plus tard, il a entendu parler de la gestion des frontières (boundary management) et a proposé à tous les directeurs adjoints d'implémenter la partie systémique de cette méthodologie pour améliorer les processus. Mais peu importait combien il parlait, personne ne semblait vraiment vouloir s'y intéresser. Peut-être que cela ne les intéressait pas ou que c'était trop compliqué. Mais en fait, personne ne s'est jamais vraiment penché sur la question.
En gros, il a expliqué tout ce qu'il savait et avait appliqué dans l'entreprise. Mais personne ne l'a compris. Ils ne comprennent toujours pas, par exemple, pourquoi tout a réussi à être corrigé dans la comptabilité des stocks, et quel rapport il y a avec le contrôle de gestion et la gestion des frontières.
En dernier lieu, il a atteint ses programmeurs - l'équipe comptait 3 personnes. Il leur a parlé de la gestion des frontières, du contrôle de gestion, de la gestion de la qualité, d'agile et de scrum… Et à sa grande surprise, ils ont tous compris et pouvaient même discuter avec lui, y compris des nuances techniques et méthodologiques. Ils ont compris pourquoi les projets liés à l'entrepôt et à l'approvisionnement avaient réussi. Et là, le jeune homme a réalisé : en fait, ce sont les programmeurs qui sauveront le monde.
Les programmeurs, a-t-il compris, sont les seuls qui pourront vraiment, avec le niveau de détail requis, comprendre les processus métier.
Pourquoi eux en particulier ? En réalité, il n'a pas trouvé de réponse définitive. Il a seulement formulé quelques indices sous forme de thèses.
Tout d'abord, les programmeurs connaissent les domaines d'activité de l'entreprise, et ils les comprennent mieux que quiconque dans l'entreprise.
De plus, les programmeurs comprennent vraiment ce que signifie un algorithme de processus. C'est important parce que les processus d'affaires sont des algorithmes, et les éléments qui les composent peuvent être tout simplement non coordonnés. Par exemple, dans le processus d'approvisionnement sur lequel le jeune homme a travaillé, la première étape consiste à établir un plan d'achats annuel, et la seconde à effectuer des achats quotidiens. Ces étapes sont liées par un lien direct, c'est-à-dire qu'il est supposé qu'avec cet algorithme, les personnes doivent travailler — établir un plan d'achats annuel et exécuter immédiatement une demande. Le plan d'achats annuel est établi une fois par an, alors que les demandes arrivent 50 fois par jour. Cet algorithme prend fin ici, et il faut travailler selon cela. En réalité, a-t-il réfléchi, pour les programmeurs, connaître les algorithmes constitue un avantage concurrentiel, car toute autre personne non familiarisée avec eux ne comprend tout simplement pas comment un processus commercial doit fonctionner et comment cela peut être représenté.
Un autre avantage des programmeurs, selon ce jeune homme, est qu'ils ont suffisamment de temps libre. Nous comprenons tous comment un programmeur peut passer trois fois plus de temps sur une tâche que ce qui est réellement nécessaire, et peu de personnes le remarqueront. C'est encore un avantage concurrentiel, car pour mettre un processus commercial en ordre, il faut avoir beaucoup de temps libre – pour réfléchir, observer, étudier et essayer.
La plupart des managers, selon ce jeune homme, n'ont pas ce temps libre et en sont fiers. Pourtant, cela signifie en fait qu'une personne ne peut pas devenir efficace car elle n'a pas de temps pour améliorer son efficacité — un cercle vicieux. Dans notre culture, il est à la mode d'être occupé, donc tout reste en place. Et pour nous, les programmeurs, c'est un avantage. Nous pouvons trouver du temps libre et réfléchir à tout cela.
Les programmeurs, disait-il, peuvent rapidement modifier le système d'information. Ce n'est pas applicable à toutes les entreprises, mais partout où il a travaillé, il était possible d'apporter des modifications à sa guise. Surtout si elles n'affectent le travail de personne. Par exemple, il pouvait mettre en place un système qui mesurerait secrètement les actions des utilisateurs, puis utiliser ces informations pour analyser l'efficacité du travail du service comptable et suivre les coûts de la comptabilité.
Et la dernière chose que je me souviens de ses mots – les programmeurs ont accès à une grande quantité d'informations, car ils ont un accès administratif au système. Ils peuvent donc utiliser ces informations dans leur analyse. Personne d'autre dans une usine ordinaire n'a une telle ressource.
Puis il est parti. Pendant le préavis de deux semaines, nous l'avons contraint à partager son expérience, car nous voulions continuer le travail qu'il faisait. De plus, son poste allait se libérer.
Pendant plusieurs jours, nous l'avons fait s'asseoir sur une chaise, nous avons allumé une caméra et avons enregistré ses monologues. Nous lui avons demandé de parler de tous les projets réalisés, des méthodes, des approches, des succès et des échecs, des causes et des conséquences, des portraits de dirigeants, etc. Nous ne l'avons pas particulièrement limité, car nous ne savions pas ce qui se passait dans sa tête.
Dans ses monologues, il y avait bien sûr principalement des absurdités et des blagues — il était de bonne humeur, car il partait de la province pour Saint-Pétersbourg. Et où aller travailler à Saint-Pétersbourg ? Chez Gazprom, bien sûr.
Mais nous avons réussi à extraire quelques informations utiles de ses monologues. Je vais raconter ce dont je me souviens.
Ainsi, les recommandations de ce gars. À ceux qui voudraient essayer d'organiser les processus d'affaires.
Pour faire ce genre de travail, il faut d'abord avoir un certain niveau de "fougue". 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 des collègues. Il réussissait facilement, parce qu'il avait commencé son parcours après avoir travaillé dans l'entreprise seulement six mois, et il n'avait eu le temps d'entrer en contact avec personne, et n'avait pas l'intention de le faire. Il comprenait que les gens viennent et partent, et que pour lui, ce qui comptait, c'était ses propres résultats et leur évaluation par le propriétaire de l'entreprise. Que ses collègues aient une opinion favorable ou défavorable à son égard — cela lui importait peu à l'époque.
Le deuxième point est que, pour être efficace dans ce travail, il faudra malheureusement apprendre. Mais ce n’est pas en MBA, ni dans des cours, ni dans des instituts, mais par soi-même. Par exemple, dans son premier projet concernant un entrepôt, il a agi par instinct, ne savait rien, seulement ce que c'était que la « gestion de la qualité ».
Lorsqu'il a commencé à lire des livres sur les méthodes d'amélioration de l'efficacité, il a découvert les technologies qu'il avait appliquées. Ce jeune homme les avait appliquées intuitivement, et il s'est rendu compte que ce n'était pas une invention de sa part, mais que tout cela avait déjà été écrit depuis longtemps. Mais il a perdu du temps et beaucoup plus que s'il avait immédiatement lu le bon livre. Il est seulement important de comprendre que lorsque l'on étudie une méthode spécifique, aucune d'entre elles, même la plus avancée, ne résoudra complètement tous les problèmes d'un processus commercial.
Le deuxième point est que plus vous connaissez de méthodes, mieux c'est. Par exemple, dans l'ancienne Japon, vivait Miyamoto Musashi – l'un des escrimeurs les plus célèbres, auteur du style des deux sabres. Il a étudié dans une école chez un maître, puis a voyagé à travers le Japon, combattant divers adversaires. Si un adversaire était plus fort, il cessait de voyager pendant un certain temps et devenait l'élève de ce maître. En quelques années, il a ainsi acquis des compétences de différentes pratiques de maîtres et a formé sa propre école en y ajoutant quelque chose de personnel. Au final, il a développé une maîtrise unique. C'est la même chose ici.
Bien sûr, on peut agir comme des consultants en affaires. En général, ce sont d'excellents gars. Mais, en règle générale, ils viennent pour mettre en œuvre une certaine méthode, mais pas nécessairement la méthode dont l'entreprise a besoin. Nous avons aussi eu des situations tristes comme ça : personne ne sait comment résoudre le problème et personne ne veut réfléchir à la solution. Nous commençons à chercher sur Internet ou à appeler un consultant et lui demandons ce qui pourrait nous aider. Le consultant réfléchit et dit qu'il faut mettre en œuvre la théorie des contraintes. Nous le payons pour son conseil, nous dépensons pour la mise en œuvre, mais le résultat est nul.
Pourquoi cela arrive-t-il ? Parce que le consultant a dit de mettre en œuvre tel système, et tout le monde est d'accord avec lui. C'est bien, mais une méthode ne résout pas tous les problèmes d'un processus commercial, surtout si les prémisses de départ ne correspondent pas — les nôtres et celles requises pour l'implémentation de la méthode.
Dans la pratique recommandée par le gars, il faut prendre le meilleur et l'implémenter. Ne pas adopter les méthodes dans leur intégralité, mais en extraire les caractéristiques clés, les astuces, les pratiques. Et le plus important, il faut comprendre l'essence.
Prenons, a-t-il dit, par exemple, le scrum ou l'agilité. Dans ses monologues, le gars a répété plusieurs fois que tout le monde ne comprend pas entièrement l'essence du scrum. Il a également lu le livre de Jeff Sutherland, qui semble à certains comme une lecture légère. Pour lui, c'était une lecture profonde, car l'un des principes fondamentaux du scrum est la gestion de la qualité, ce qui est directement mentionné dans le livre.
Il est question de la Production Toyota, de la façon dont Jeff Sutherland a présenté le scrum au Japon, de la façon dont il a été adopté là-bas et sa proximité avec leur philosophie. Sutherland a également parlé de l'importance du rôle de scrum master, du cycle de Deming. Le rôle de scrum master consiste à accélérer constamment le processus. Tout le reste présent dans le scrum — les livraisons par étapes, la satisfaction du client, une liste claire des tâches pour la durée du sprint — est également important, mais tout cela doit progresser de plus en plus rapidement. La vitesse de travail doit constamment augmenter dans les unités dans lesquelles elle est mesurée.
Peut-être que cela vient de la traduction, car chez nous le livre a été traduit par "Scrum - une méthode révolutionnaire de gestion de projet", alors que si on traduit littéralement le titre anglais, cela donnerait : "Scrum - deux fois plus en deux fois moins de temps", ce qui signifie qu'il y a déjà une référence à la vitesse, comme fonction clé du scrum, même dans le titre.
Lorsque ce gars a implémenté le scrum, en un mois, la vitesse a doublé sans changements particuliers. Il a identifié des points d'amélioration, a modifié le scrum pour l'adapter, afin qu'il fonctionne beaucoup plus vite. La seule chose, comme l'écrivent les internautes, est qu'ils se sont retrouvés confrontés à la question : "Nous avons doublé notre vitesse, il reste à comprendre que faisons-nous avec une telle vitesse ?". Cependant, c'est un tout autre domaine...
Il a également recommandé plusieurs méthodes. Il les a qualifiées de fondamentales et essentielles.
La première — gestion des limites.
Il enseigne cela à « Skolkovo ». D'après le jeune homme, il n'y a pas d'autres livres ou matériels. Il a eu la chance d'assister à une conférence d'un professeur de Harvard qui prône la gestion des frontières, ainsi que de lire quelques articles dans le Harvard Business Review sur les travaux d'Éric Trista.
La gestion des frontières parle de la capacité à voir et à travailler avec les frontières. Il y a des frontières 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 permet de voir la réalité sous un autre jour — à travers le prisme des frontières. Par conséquent, il est possible de les gérer — de les établir là où c'est nécessaire et de les supprimer là où elles sont un obstacle.
Mais plus souvent, le jeune homme parlait de contrôle. Il avait une sorte de fixation sur ce sujet.
Le contrôle, en résumé, est la gestion basée sur des chiffres. Ici, disait-il, chaque partie de cette définition est importante — « gestion », « basée sur », et « chiffres ».
Nous, disait-il, avons des problèmes avec les trois composantes du contrôle. Surtout si l'on considère qu'elles sont étroitement liées les unes aux autres et à d'autres parties du système commercial.
La première chose qui ne va pas, ce sont les chiffres. Ils sont rares et de mauvaise qualité.
Une partie importante des chiffres que nous avions à l'époque était tirée du système d'information 1C. Or, la qualité des chiffres dans 1C, selon lui, laisse à désirer. Au minimum, à cause de la possibilité de modifier les données rétroactivement.
Il est évident que la responsabilité n'incombe pas aux développeurs de 1C — ils prennent simplement en compte les exigences du marché et la mentalité de la comptabilité locale. Mais pour les besoins du contrôle, les principes de traitement des données par 1C devraient être modifiés au sein d'une entreprise spécifique.
Ensuite, les chiffres de 1C, selon ses paroles, subissent un traitement semi-manuel, en utilisant par exemple Excel. Ce traitement n'améliore ni la qualité des données, ni leur rapidité.
En fin de compte, le rapport final est encore vérifié par quelqu'un pour ne pas transmettre accidentellement au responsable des chiffres erronés. Au final, les chiffres parviennent au destinataire beaux, vérifiés, mais très tard. En général, après la fin de la période (mois, semaine, etc.).
Et là, disait-il, c'est très simple. Si les chiffres de janvier vous arrivent en février, vous ne pouvez plus gérer l'activité de janvier. Parce que janvier est déjà terminé.
Et si les chiffres sont basés sur la comptabilité, et que l'entreprise est tout à fait ordinaire, avec une déclaration de TVA trimestrielle, alors son dirigeant reçoit des chiffres relativement raisonnables une fois par trimestre.
Ensuite, c'est clair. Si vous recevez des chiffres une fois par mois, vous avez la possibilité de gérer par les chiffres (c'est-à-dire de faire du contrôle) 12 fois par an. Si vous pratiquez un reporting trimestriel, vous gérez 4 fois par an. En plus, un bonus - le reporting annuel. Une autre occasion de diriger.
Le reste du temps, la gestion se fait généralement dans le flou.
Quand (et si) les chiffres apparaissent enfin, un second problème entre en jeu : comment gérer sur la base des chiffres ? Sur ce point de ses réflexions, je n'ai pas pu être d'accord.
Le gars affirmait que si le dirigeant n'avait jamais eu de chiffres auparavant, leur apparition provoquerait un effet wahou. Il allait examiner et manipuler les chiffres dans tous les sens, convoquer des gens, exiger des explications et des enquêtes. Après avoir joué avec les chiffres et organisé des analyses, promettant sternement à tous les employés qu'« maintenant, je ne vous lâcherai plus », le dirigeant se calmerait très vite et abandonnerait cette affaire. Il ne se servirait plus de l'outil. Les problèmes resteraient là.
Cela se produit, disait-il, à cause des compétences insuffisantes du dirigeant. En contrôlant, avant tout. Le dirigeant ne sait tout simplement pas quoi faire avec ces chiffres. Ce qu'il doit faire, il le sait, mais ce qu'il doit faire, il ne le sait pas. Faire, c'est ce qui a été écrit ci-dessus (se fâcher, jouer). Agir, c'est un processus d'affaires quotidien. avecIl affirmait que c'est très simple : le chiffre doit devenir une partie du processus d'affaires. Dans le processus d'affaires, il doit être clairement entendu : qui, quoi, et quand doit intervenir en cas de déviation du chiffre par rapport à la norme (toutes les variantes - au-dessus de la limite, en dessous de la limite, sortie des corridors, présence d'une tendance, non réalisation du quantile, etc.)
Et là, il a désigné le dilemme clé : le chiffre est là, il doit devenir une partie du système d'affaires pour améliorer l'efficacité de la gestion, mais... cela ne se produit pas. Pourquoi ?
Parce que le dirigeant russe ne cédera pas un morceau de son pouvoir à un concurrent.
Les concurrents du dirigeant russe - un processus d'affaires de qualité et fonctionnel, une motivation mutuellement bénéfique bien pensée et une bonne automatisation - hélas, laisseront le dirigeant sans emploi.
Les concurrents du dirigeant russe — un processus commercial efficace et fonctionnel, une motivation mutuellement bénéfique bien pensée et une automatisation appropriée — hélas, laisseront le dirigeant sans emploi.
C'est n'importe quoi, ne trouvez-vous pas ? Surtout en ce qui concerne les dirigeants. Enfin, je l'ai raconté, à vous de décider.
Un peu moins, mais quand même trop, à mon avis, il parlait de Scrum.
Il a insisté pour dire qu'il faut lire et essayer Scrum en pratique. Si vous avez lu, mais n'avez pas essayé, considérez que vous ne savez pas. Il vaut mieux lire un livre, comme celui de Sutherland, plutôt que des articles et divers guides (qu'est-ce que c'est que ça ?) sur Internet.
Scrum, disait-il, ne s'apprend qu'à travers la pratique, et avec des mesures obligatoires des volumes de travail réalisés. Essayez personnellement les deux rôles les plus importants : celui de propriétaire de produit et de Scrum Master.
Il est particulièrement important, selon ce gars, de ressentir en pratique le rôle de Scrum Master, lorsque vous pourrez augmenter le volume de tâches complétées par sprint, sans augmenter les ressources et le coût du sprint.
Et puis, dans son top, il y avait la TOC (Théorie des Contraintes).
Ce sont, selon ses dires, des principes de base et fondamentaux pour améliorer l'efficacité, qui peuvent être appliqués pratiquement dans n'importe quel domaine, dans n'importe quel processus commercial et système d'affaires en général.
Quand il a réalisé que nous n'étions pas familiers avec la TOC, il a cessé d'expliquer. Il a juste ajouté qu'il ne nous priverait pas du plaisir de lire les livres d'Eliyahu Goldratt. Il a donné une recommandation similaire à celle de Scrum : lisez et essayez. Peu importe le poste que vous occupez, quel travail vous faites, il y a toujours une place pour améliorer l'efficacité avec les méthodes de la TOC.
Puis, visiblement, il a manqué de méthodes et il a dit : mélangez les principes pour créer des solutions applicables dans des situations spécifiques.
C'est, dit-il, la principale recommandation, la clé du succès. Comprenez les principes, l'essence, et créez des solutions uniques et applicables — processus d'affaires et systèmes d'affaires.
Puis il s'est efforcé de se souvenir d'une citation, finalement il a dû chercher sur Internet. Il s'est avéré que la citation provenait de l'article « Se tenant sur les épaules de géants » d'Eliyahu Goldratt :
«Il y a 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, tandis que les solutions appliquées représentent une adaptation des concepts à un environnement spécifique. Comme nous l'avons déjà vu, une telle adaptation n'est pas simple et nécessite le développement de certains éléments de la solution. Nous devons garder à l'esprit qu'une solution appliquée repose sur des prémisses (parfois cachées) concernant l'environnement spécifique. Il ne faut pas s'attendre à ce que cette solution appliquée fonctionne dans un environnement pour lequel les prémisses de base ne sont pas valables ».
Il a dit que le travail d'un programmeur et celui d'un «améliorateur de processus d'affaires» sont très similaires. Et il est parti.
Source : habr.com
