About one guy

The story is real, I saw everything with my own eyes.

For several years one guy, like many of you, worked as a programmer. Just in case, I will write this: "programmer." Because he was 1Sniki, at fix, a production company.

Prior to that, he tried various specialties - 4 years in French as a programmer, project manager, knew how to close for 200 hours, at the same time receiving a percentage of the project, for management and doing some sales. I tried to independently develop products, was the head of the IT department in a large company, numbering 6 thousand people, tried on different ways to use my quotes profession - 1C programmer.

But all these positions were somewhat dead-end, first of all in terms of income. All of us then received about the same money, worked in the same conditions.

This guy was wondering how you can make more money without selling and not creating your own business.

He imagined himself a clever man, and decided to find a niche in the company where he worked. This niche was supposed to be something special, not occupied by anyone. And I wanted the company to want to pay money to a person in this niche so that it would not be necessary to deceive anyone or wind up something. To make it objective: a person in this position has to pay a lot of money. Kook, in one word.

Searches were short. In the company where this guy worked, there was a completely free niche, which can be called the “putting order in business processes”. Every company has a lot of problems. Something is always not working, and there is no person who will come and correct the business process. So, he decided to try himself in the role of a specialist who can help the owner to solve his problems in business processes.

At that time he worked in the company for six months, and received an average salary in the market. There was nothing to lose, especially since he could very well have found the same job in one week. In general, this guy reasoned that nothing terrible will happen if suddenly a fig fails and he is fired.

He plucked up courage and came to the owner. He offered to improve the most problematic process that was in the business. At that time it was inventory accounting. Now everyone who works in this company is even ashamed to remember those problems, but the inventories that were conducted quarterly showed discrepancies between the accounting system and actual balances of tens of percent. And in cost, and in quantity, and in the number of positions. It was a misfortune. The company actually had the right balances in the accounting system only four times a year - the day after the inventory. This process is our guy and began to put in order.

The guy agreed with the owner that he should reduce the deviations by the results of the inventory by half. Moreover, the owner had nothing to lose, because before our hero, various workers had already tried to fix everything, and on the whole the task was considered practically unsolvable. All this strongly fueled interest, because if everything works out, then the dude would automatically become a person who knows how to restore order and solve unsolvable problems.

So, he was faced with a task: to reduce deviations in the inventory results by a factor of 2 during the year. At the time of the start of the project, he did not know how to achieve this, but he understood that inventory accounting is a simple thing, so you can still do something useful. Moreover, to reduce deviations from tens of percent to one ten percent is, it seems, not so difficult. All those who worked in the field of consulting or similar activities, understand that most of the problems of the process are eliminated by rather simple actions.

From January to May, he was preparing, automated something a little, rewrote the warehouse accounting business process, changed the workflows of storekeepers, accountants and in general redid the entire system, without showing anything to anyone or telling. In May, he distributed new instructions to everyone, and after the first inventory in the year, a new life began - working according to his rules. In order to observe the result, in the future, the company began to conduct inventories more often - once in two months. The first results were already positive, and by the end of the year, the deviations from the results of the audit fell to fractions of one percent.

The success was colossal, but I could not believe in its stability. The guy himself doubted that the result would continue, if you step aside and stop watching the process. Nevertheless, the result was, and the guy got everything he agreed with the owner. Then, after a few years, the stability of the result was confirmed - several years of deviation kept within 1%.

Then he decided to repeat the experiment and suggested to the owner to improve another problematic process - supply. There were deficiencies that did not allow to ship such volumes that our customers wanted. We agreed that in a year the deficiencies will be halved, and the dude will still carry out 10-15 projects related to 1C, for the automation of various business processes and other heresy.

In the second year, again, everything was successfully completed, the deficits decreased by more than 2 times, all IT projects were completed successfully.

Since the salary already fully satisfied all the requests of that guy, about two years ahead, he decided to settle down a bit, calm down and sit in a cozy warm place, which he himself had created.

What did it represent? Formally, he was the IT director. But who he really was was difficult to understand. What does an IT director do? As a rule, he administers the IT infrastructure, manages sys.adminami, implements the ERP system, participates in meetings on the board of directors.

And one of the key responsibilities of this dude was to participate in the change processes, and basically - generating, initiating these processes, finding and proposing solutions, applying new management techniques, examining proposed changes, analyzing the effectiveness of other functions and departments, and finally - directly participation in the strategic development of the enterprise, up to the independent development of a strategic plan for the entire company.

He was given a blank check. He could come to any meeting where he did not have access before. I sat there with a notebook, wrote something down, or just listened. He spoke rarely. Then he began to play on the phone - argued that the associative memory works better.

At the meeting, something rarely gave out something useful. He left, he thought, then a letter arrived - either with criticism, or with opinion, or with suggestions, or with a description of the solutions that he had already applied.

But more often he gathered meetings himself. He found a problem, invented solutions, identified stakeholders and dragged everyone into the negotiations. And there too - as I could. Persuaded, motivated, argued, argued, sought.

Unofficially, he was considered the third person in the company, after the owner and director. Of course, he terribly infuriated all the "faces of the company", starting with number 4. Especially with his torn jeans and bright T-shirts, and also with the time of the owner.

The owner gave him 1 hour a day. Everyday. They talked, discussed problems, solutions, new businesses, development directions, indicators and efficiency, personal development, books, and just life.

But this guy was strange. Like - sit and rejoice, life is good. But no. He decided to reflect.

He wondered: why did he succeed, while others did not? The owner also pushed him: he said that he wanted others to manage to restore order, because there are many managers, they, as a rule, are engaged in operational management and strategic planning, but almost no one is engaged in systemic changes of their processes. In their job description, it may be written that they should speed up their process, increase its efficiency, but in fact no one does it. Why is that? That guy also wondered why, and he went to talk with all these managers.

He came to the deputy director for quality, and suggested introducing Shewhart control charts in order to have a better Japanese product. But it turned out that a colleague does not know what Shewhart control charts are, what statistical process control is, and only heard with the edge of the ear about the use of the Deming cycle in quality management. Okay…

He went to another deputy director, and offered to introduce controlling. But here I did not find support. A little later, he found out about boundry management (boundary management) and suggested that all deputy directors introduce a system part of this methodology in order to improve the processes. But how much our guy did not talk, no one really wanted to delve into what it was about. Maybe they were not interested or too difficult. But, in fact, no one figured it out.

In general, he told about everything that he knew and applied in the company. But no one understood him. It is still not clear to them why, for example, everything was corrected in warehouse accounting, and here controlling and border management.

At the last, he reached his programmers - the staff consisted of 3 people. He told about border management, about controlling, about quality management, about agile and scrum ... And surprisingly they understood everything, and could even discuss it with him somehow, including technical and methodological subtleties. They understood why the projects on the warehouse and on the supply turned out. And then it dawned on the guy: in fact, the world will be saved by programmers.

Programmers, he realized - the only ones who can properly, with the necessary detail to understand the business processes.

Why exactly they? In fact, he never found a clear answer. Formulated only theses hints.

First, programmers know the subject areas of business, and, moreover, they know them better than all the other people in the company.

In addition, programmers really understand what a process algorithm is. This is important because business processes are algorithms, and the elements in them may be trivially inconsistent. For example, in the procurement process that the guy worked on, the first step is to draw up an annual procurement plan, and the second is daily procurement. These steps are connected by a direct link, that is, it is assumed that according to this algorithm, people should work - to draw up an annual procurement plan and immediately execute the application. The annual procurement plan is prepared once a year, and the application is received 50 times a day. At this the algorithm ends, and it is necessary to work on it. In fact, he reasoned, for programmers, knowledge of algorithms is a competitive advantage, because any other person who is not familiar with them simply does not understand how the business process should work and how it can be represented.

Another advantage of programmers, according to that guy, is that they have plenty of free time. We all understand how a programmer can spend on a task three times longer than it actually requires, and few people will notice. This, again, is a competitive advantage, because in order to bring some business process in order, you need to have a lot of free time - to think, observe, study and try.

Most of the managers, according to the guy, do not have this free time and are proud of it. Although in fact this means that a person cannot become effective, because he does not have time to increase efficiency - a vicious circle. In our culture it is fashionable to be busy, so everything remains in place. And for us, programmers, this advantage. We can find free time and think about everything.

Programmers, he said, can quickly change the information system. This is not applicable to all enterprises, but wherever he worked, it was possible to make any modifications that he liked. Especially if they do not relate to anybody’s work. For example, he could launch a system that would secretly measure user actions, and then use this information to analyze the performance of the same accounting and track the cost of accounting.

And the last thing I remember from his words is that programmers have access to a lot of information, because have administrative access to the system. Therefore, they can use this information in their analysis. No one else in a normal factory possesses such a resource.

And then he left. During the two-week job we were forced to share his experience, because we wanted to continue the work in which he was engaged. Well, his position became vacant.

For several days they sat down on a chair, turned on the camera and recorded his monologues. They were asked to tell about all the completed projects, methods, approaches, successes and failures, causes and effects, portraits of managers, etc. Especially not limited, because did not know what was going on in his head.

In the monologues, of course, there was basically all sorts of nonsense and rzhak - he was in excellent spirits, because departed from the backwater to Peter. And where to go to work in St. Petersburg? In Gazprom, of course.

But we managed to get something useful out of his monologues. I'll tell you what I remember.

So the recommendations of that guy. Those who want to try to restore order in business processes.

To do this work, first, you need to have a certain level of "frostbite". We must not be afraid of losing a job, do not be afraid to take risks, and not be afraid of conflicts with colleagues. He did it easily, because he began his journey when he worked in the company for only six months, and did not have time to get in touch with anyone, nor was he going to do it. He understood that people come and go, and his own results and their assessment by the business owner are important for him. His colleagues treat him badly or well - he was little worried then.

The second point - to effectively do this work, unfortunately, will have to learn. But to study not on MBA, not on courses, not in institutes, but independently. For example, in his first project, at the warehouse, he acted intuitively, knew nothing, just what “quality management” is.

When he began to read the literature, what methods of improving efficiency exist, he discovered the technologies that he used. The guy intuitively applied them, but it turns out that this is not his invention, everything has already been written for a long time. But he spent the time, and much more than if he read the right book right away. Here it is only important to understand that when you study a specific method, not one of them, even the most advanced, will completely solve all the problems of the business process.

The second trick is that the more techniques you know, the better. For example, in ancient Japan, Miyamoto Musashi lived - one of the most famous fencers, the author of the style of two swords. He studied at some school with a master, then traveled around Japan, fought with different dudes. If the man was stronger, the journey stopped for a while, and Musashi went to the disciples. As a result, over several years he acquired the skills of various practices of various masters and formed his own school, adding something of his own. As a result, he got a unique skill. Here is the same.

You can, of course, act as business consultants. Generally, they are great guys. But, as a rule, they come to introduce some kind of methodology, and they introduce the wrong kind of business. We also had such sad situations: no one knows how to solve a problem and no one wants to think how to solve it. We start looking either on the Internet or calling a consultant, and ask him what can help us. The consultant thinks and says that it is necessary to introduce a theory of restrictions. We pay him for the recommendation, we spend on implementation, but the result is zero.

Why is this so? Because the consultant said, we are introducing such and such a system, and everyone agreed with him. Fine, but one technique does not close all the problems of even a single business process, especially if the initial prerequisites do not match - ours and those that are required for the implementation of the methodology.

In the practice that the guy recommends, we must take the best and introduce the best. Do not take methods entirely, but take their key features, chips, practices. And the most important thing is to understand the essence.

Take, he said, for example, scrum (or scale). In the monologues, the guy repeated many times that not everyone fully understands the essence of Scram. He also read a book by Jeff Sutherland, which to some seems like “light reading.” It seemed to him a deep reading, because one of the fundamental foundations of scram is quality management, which is written directly in the book.

It says about Toyota Production, about how Jeff Sutherland showed scrum in Japan, how he got accustomed there and was close to their philosophy. And Sutherland talked about the importance of the role of scrum master, about the Deming cycle. The role of the scrum master is the constant acceleration of the process. Everything else that is in the scram - gradual delivery, customer satisfaction, a clear list of works for the sprint period - is also important, but all this should move faster and faster. The speed of work should increase all the time in the units in which it is measured.

Perhaps it’s a matter of translation, because the book was translated as “Scrum is a revolutionary project management method”, and if you literally translate the English name, you’ll get: “Scrum is twice as long in half the time”, that is, even названии идет отсылка к скорости, как ключевой функции скрама.

Когда этот парень внедрял скрам, за первый месяц скорость увеличилась вдвое без каких-то особых изменений. Он нашел точки для изменений, модифицировал сам скрам под себя, чтобы он работал намного быстрее. Единственное, как в интернете пишут, — перед ними встал вопрос: «Мы увеличили скорость вдвое, осталось понять, что же мы делаем с такой скоростью?». Впрочем, это уже совсем другая область…

Еще он лично рекомендовал несколько методик. Назвал их фундаментальными и основополагающими.

Первая — boundary management (управление границами).

Преподают его в «Сколково», других книг и материалов, по утверждениям парня, нет. Ему как-то посчастливилось присутствовать на лекции профессора из Гарварда, который проповедует boundary management, а также прочитать несколько статей в Harvard Business Review про работы Эрика Триста.

Boundary management говорит о том, что надо уметь видеть границы и работать с границами. Границ полно, они повсюду — между отделами, между разными видами работ, между функциями, между оперативной и аналитической работой. Знание boundary management не открывает каких-то высших истин, но позволяет видеть реальность в несколько ином свете — через призму границ. И, соответственно, управлять ими — возводить там, где это необходимо, и убирать там, где они мешают.

Но больше и чаще всего парень говорил про контроллинг. Прям бзик какой-то у него был на эту тему.

Контроллинг, если кратко — это управление на основе цифр. Здесь, говорил он, важна каждая часть определения — и «управление», и «на основе», и «цифр».

У нас, говорил он, плохо со всеми тремя составляющими контроллинга. Особенно если учесть, что они тесно взаимосвязаны как друг с другом, так и с другими частями бизнес-системы.

Первое, что плохо — цифры. Их мало и они низкого качества.

Значительную часть цифр мы тогда брали из информационной системы 1С. Так вот, качество цифр в 1С, как он утверждал, никуда не годится. Как минимум, из-за возможности изменять данные задним числом.

Понятно, что вины разработчиков 1С в этом нет — они лишь учитывают требования рынка и менталитета отечественного учета. Но для целей контроллинга принципы работы 1С с данными лучше изменить, на конкретном предприятии.

Дальше цифры из 1С, по его словам, проходят полуручную обработку, с использованием Excel, например. Качества данным, равно как и оперативности, такая обработка тоже не добавляет.

В конце концов, итоговый отчет еще кто-то перепроверяет, чтобы случайно не подать руководителю цифры с ошибками. В итоге, цифры попадают к адресату красивыми, проверенными, но очень поздно. Обычно — после окончания периода (месяца, недели, и т.д.).

И тут, говорил он, все очень просто. Если цифры о январе вам попали в феврале, то деятельностью января вы уже управлять не можете. Потому что январь уже закончился.

А если цифры основаны на бух.учете, и компания — самая обычная, с поквартальной сдачей НДС, то относительно адекватные цифры ее руководитель получает раз в квартал.

Дальше понятно. Получаете цифры раз в месяц — у вас есть возможность управлять по цифрам (т.е. осуществлять контроллинг) 12 раз в год. Практикуете квартальную отчетность — управляете 4 раза в год. Плюс бонус — годовая отчетность. Еще разок порулить.

Остальное время управление, как правило, выполняется вслепую.

Когда (и если) цифры все-таки появляются, то вступает в действие вторая проблема — как управлять на основе цифр? Вот с этим пунктом его рассуждений я так и не смог согласиться.

Парень утверждал, что если цифр у руководителя раньше не было, то их появление вызовет вау-эффект. Он будет смотреть и крутить цифры и так и эдак, вызывать людей на ковер, требовать объяснений и расследований. Поигравшись с цифрами, проведя разборы, грозно пообещав всем сотрудникам, что «уж теперь-то я с вас не слезу», руководитель очень быстро успокоится и бросит это дело. Инструментом пользоваться перестанет. А проблемы останутся на месте.

Так происходит, говорил он, из-за недостаточных компетенций руководителя. В контроллинге, в первую очередь. Руководитель просто не знает, что делать с этими цифрами. Что с делать — знает, что делать — нет. Сделать — это то, о чем написано выше (поругаться, поиграться). Делать — это ежедневный бизнес-процесс.

Он утверждал, что все очень просто: цифра должна стать частью бизнес-процесса. В бизнес-процессе должно быть четко понятно: кто, что, и когда должен делать при отклонении цифры от нормы (любые варианты — выше границы, ниже границы, выход за коридор, наличие тренда, невыполнение квантиля и т.д.)

И вот он обозначил ключевую дилемму: цифра есть, она должна стать частью бизнес-системы, чтобы повысить эффективность управления, но… этого не происходит. Why?

Потому что российский руководитель не отдаст конкуренту кусок своей власти.

Конкуренты российского руководителя — качественный и работающий бизнес-процесс, продуманная взаимовыгодная мотивация и правильная автоматизация — увы, оставят руководителя без работы.

Чушь какая-то, согласитесь? Особенно, про руководителей. Ладно, я рассказал, вы сами решайте.

Чуть меньше, но все равно слишком много, на мой взгляд, он говорил про скрам.

Обязательно, говорил, прочитайте и попробуйте на практике скрам. Если, говорит, читали, но не пробовали — считайте, что не знаете. Читать лучше книгу, например Сазерленда, а не статьи и всякие там гайды (что за хрень?) в интернете.

Скрам, говорил он, познается только практикой, и с обязательными измерениями объемов выполненной работы. Лично попробуйте две важнейшие роли — владельца продукта и скрам-мастера.

Особенно важно, по словам парня, прочувствовать на практике роль скрам-мастера, когда вы сможете увеличить объем закрываемых за спринт задач, не увеличивая ресурсы и стоимость спринта.

Ну и еще в его топе был ТОС (теория ограничений систем).

Это, по словам парня, базовые, фундаментальные принципы повышения эффективности, которые можно применить практически в любой области, в любом бизнес-процессе и бизнес-системе в целом.

Когда он узнал, что мы не знакомы с ТОС, то перестал рассказывать. Лишь добавил, что не будет лишать нас удовольствия от прочтения книг Элияху Голдратта. Рекомендацию дал аналогичную скраму — прочитайте и попробуйте. Типа, на какой бы должности вы не находились, какую бы работу не выполняли, там найдется место для повышения эффективности методами ТОС.

Потом у него багаж методик, видимо, иссяк, и он сказал: миксуйте принципы, для создания прикладных решений в конкретной ситуации.

Это, говорит, главная рекомендация, ключ к успеху. Поймите принципы, суть, и создавайте уникальные прикладные решения — бизнес-процессы и бизнес-системы.

Потом он силился вспомнить какую-то цитату, в итоге пришлось лезть в интернет. Оказалось, цитата из статьи «Стоя на плечах гигантов» Элияху Голдратта:

“There is a difference between the applied solutions (applications) and the fundamental concepts on which these solutions are based. Concepts are common, applied solutions are the adaptation of concepts to a specific environment. As we have already seen, such an adaptation is not simple and makes it necessary to develop certain elements of the solution. We have to remember - the application decision is based on the initial premises (sometimes hidden) about a specific environment. We should not expect that this application will work in an environment for which the initial premises are not correct. ”

He said that the work of the programmer and the “business process improver” is very similar. And left.