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’ll write it this way: “programmer.” Because he was 1Snik, on a fix, production company.
Before that, he tried different specialties - 4 years in France as a programmer, project manager, he was able to complete 200 hours, at the same time receiving a percentage of the project, for management and doing a little sales. I tried to develop products on my own, was the head of the IT department in a large company with 6 thousand people, tried on different options for using my quotable profession - 1C programmer.
But all these positions were somewhat dead-end, primarily in terms of income. At that time, we all received approximately the same money and worked under the same conditions.
This guy was wondering how he could make more money without selling or creating his own business.
He fancied himself a smart guy and decided to find a niche in the company where he worked. This niche had to be something special, not occupied by anyone. And I wanted the company itself to want to pay money to a person in this niche, so that there would be no need to deceive anyone or cheat anything. To make this objective: a person in this position needs to be paid a lot of money. An eccentric, in a word.
The search was short-lived. In the company where this guy worked, there was a completely free niche that could be called “putting things in 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 fix the business process. So, he decided to try himself as a specialist who can help the owner solve his problems in business processes.
At that time, he had been working for the company for six months and received the average salary in the market. There was nothing to lose, especially since he could easily find the same job within one week. In general, this guy decided that nothing bad would happen if suddenly nothing worked out and he was fired.
He plucked up courage and came to the owner. I suggested that he improve the most problematic process in the business. At that time it was warehouse accounting. Now everyone who works in this company is even ashamed to remember those problems, but inventories, which were carried out 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 disaster. The company actually had the correct balances in the accounting system only four times a year - the day after the inventory count. Our guy began to put this process in order.
The guy agreed with the owner that he should reduce the deviations from the inventory results by half. Moreover, the owner had nothing special to lose, because before our hero, various workers had already made attempts to fix everything, and in general the task was considered practically unsolvable. All this greatly fueled interest, because if everything worked out, then the dude would automatically become a person who knows how to put things in order and solve unsolvable problems.
So, he was faced with the task: to reduce deviations based on inventory results by 2 times within a year. At the start of the project, he had no idea how to achieve this, but he understood that warehouse accounting is a simple thing, so he would still be able to do something useful. Moreover, reducing deviations from tens of percent to one tens of percent does not seem to be so difficult. Anyone who has worked in consulting or similar activities understands that most process problems can be resolved with fairly simple steps.
From January to May, he prepared, automated something a little, rewrote the warehouse accounting business process, changed the work flows of storekeepers, accountants, and generally remade the entire system, without showing or telling anything to anyone. In May, he distributed new instructions to everyone, and after the first inventory of the year, a new life began - working according to his rules. In order to observe the results, in the future the company began to conduct inventories more often - once every two months. Already the first results were positive, and by the end of the year, deviations from the audit results had dropped to a fraction of one percent.
The success was colossal, but one could not believe in its sustainability. The guy himself doubted that the result would be preserved if he stepped aside and stopped observing the process. Nevertheless, there was a result, and the guy received everything he agreed on with the owner. Then, after several years, the stability of the result was confirmed - for several years the deviations remained within 1%.
Then he decided to repeat the experiment and suggested that the owner improve another problematic process - supply. There were shortages that did not allow us to ship the volumes that our customers wanted. We agreed that within a year the deficits would be halved, and the guy would also complete 10-15 projects related to 1C - to automate various business processes and other heresies.
In the second year, everything was successfully completed again, deficits decreased by more than 2 times, all IT projects were completed successfully.
Since the salary already fully satisfied all the needs of that guy for two years in advance, he decided to settle down a little, calm down and sit in a cozy, warm place that he had created for himself.
What was it like? Formally, he was the IT director. But who he really was is difficult to understand. After all, what does an IT director do? As a rule, he administers the IT infrastructure, manages system administrators, implements an ERP system, and participates in meetings of the board of directors.
And this dude had one of the key responsibilities to participate in change processes, and mainly - generation, initiation of these processes, search and proposal of solutions, application of new management techniques, examination of proposed changes, analysis of the effectiveness of other functions and divisions, and, finally, direct participation in the strategic development of the enterprise, up to the independent development of a strategic plan for the entire company.
He was given carte blanche. He could come to any meeting where he had not previously had access. I sat there with a notepad, writing something down, or just listening. He rarely spoke. Then he started playing on the phone, claiming that associative memory works better this way.
At the meeting he rarely gave out anything useful. He left, thought, then a letter arrived - either with criticism, or with an opinion, or with suggestions, or with a description of the solutions that he had already applied.
But more often he convened meetings himself. I found a problem, came up with solutions, identified interested parties and brought everyone into the meeting. And then - as best he could. He convinced, motivated, proved, argued, achieved.
Unofficially, he was considered the third person in the company, after the owner and director. Of course, he terribly infuriated all the “persons of the company”, starting with number 4. Especially with his torn jeans and bright T-shirts, and also with his time as an owner.
The owner gave him 1 hour a day. Every day. They talked, discussed problems, solutions, new businesses, areas of development, indicators and efficiency, personal development, books, and simply life.
But this guy was strange. It’s like, sit back and be happy, life is good. But no. He decided to reflect.
He wondered: why did it work out for him, but others didn’t? The owner also pushed him: he said that he wanted others to also be able to restore order, because there are many managers, they, as a rule, are engaged in operational management and strategic planning, but practically no one is engaged in systemic changes in their processes. It may be written in their job description that they should speed up their process and increase its efficiency, but in fact no one is doing this. Why is that? The guy also became interested in why, and he went to talk to all these managers.
He came to the deputy director for quality and suggested introducing Shewhart control charts so that the products would be better than Japanese ones. But it turned out that the colleague did not know what Shewhart control charts were, what statistical process control was, and had only heard about the use of the Deming cycle in quality management. OK…
He went to another deputy director and suggested introducing controlling. But I didn’t find support here either. A little later, he learned about boundary management (boundary management) and suggested that all deputy directors implement the systemic part of this methodology in order to improve processes. But no matter how much our guy talked, no one really wanted to delve into what it was about. Maybe they weren't interested or it was too difficult. But, in fact, no one figured it out.
In general, he talked about everything he knew and used in the company. But no one understood him. They still don’t understand why, for example, everything was corrected in warehouse accounting, and what does controlling and border management have to do with it.
Last of all, he reached his programmers - the staff included 3 people. He talked about boundary management, about controlling, about quality management, about agile and scrum... And surprisingly, they understood everything, and were even able to somehow discuss with him, including technical and methodological subtleties. They understood why the warehouse and supply projects worked out. And then it dawned on the guy: in fact, programmers will save the world.
Programmers, he realized, are the only ones who can understand business processes normally, with the necessary detail.
Why them? In fact, he never found a clear answer. I formulated only thesis hints.
Firstly, programmers know the subject areas of the business, and they know them better than all 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 simply not be consistent. For example, in the procurement process the guy was working on, the first step was creating an annual purchasing plan, and the second was daily purchasing. These steps are connected by a direct connection, that is, it is assumed that people should work according to this algorithm - draw up an annual procurement plan and immediately execute the request. The annual procurement plan is drawn up once a year, and applications are received 50 times a day. This is where the algorithm ends, and you need to work on it. In fact, he reasoned, for programmers, knowledge of algorithms is a competitive advantage, because anyone else who is not familiar with them simply does not understand how a business process should work and how it can be represented.
Another advantage of programmers, according to the guy, is that they have enough free time. We all understand how a programmer can spend three times longer on a task than it actually requires, and few will notice. This, again, is a competitive advantage, because in order to put some business process in order, you need to have a lot of free time - think, observe, study and try.
Most 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 improve efficiency - a vicious circle. In our culture, it's fashionable to be busy, so everything stays the same. And for us programmers, this is an advantage. We can find free time and think about everything.
Programmers, he said, can quickly change an information system. This is not applicable at all enterprises, but wherever he worked, he could make any modifications he wanted. Especially if they don't concern anyone else's work. For example, he could launch a system that would secretly measure user actions, and then use this information to analyze the efficiency of the same accounting department and track the cost of accounting.
And the last thing I remember from his words is that programmers have access to a large amount of information, because... have administrative access to the system. Therefore, they can use this information in their analysis. No one else at a regular plant has such a resource.
And then he left. During the required two-week detention, we forced him to share his experience because we wanted to continue the work he was doing. Well, his position became vacant.
Over the course of several days, they sat him on a chair, turned on the camera and recorded his monologues. They asked to tell us about all completed projects, methods, approaches, successes and failures, causes and effects, portraits of managers, etc. There were no special restrictions, because They didn’t know what was going on in his head.
The monologues, of course, were mostly all nonsense and laughs - he was in a great mood, because was leaving the outback for St. Petersburg. Where should you go to work in St. Petersburg? To Gazprom, of course.
But we managed to extract something useful from his monologues. I'll tell you what I remember.
So, that guy's recommendations. For those who want to try to put things in order in business processes.
To do this kind of work, firstly, you need to have a certain level of “frostbite”. You should not be afraid of losing your job, not be afraid to take risks, not be afraid of conflicts with colleagues. It was easy for him, because he began his journey when he had worked in the company for only six months, and did not have time to come into contact with anyone, and did not intend to do so. He understood that people come and go, but his own results and their assessment by the business owner are important to him. Whether his colleagues treated him well or poorly was of little concern to him then.
The second point is that in order to effectively do this work, unfortunately, you will have to study. But study not for an MBA, not in courses, not in institutes, but on your own. For example, in his first project, a warehouse project, he acted intuitively, he didn’t know anything, just what “quality management” was.
When he began to read the literature about what methods of increasing efficiency existed, he discovered the technologies that he used. The guy applied them intuitively, but it turns out that this was not his invention, everything was already written a long time ago. But he spent time, and much more than if he had immediately read the right book. Here it is only important to understand that when you study a specific technique, not one of them, even the most advanced, will completely solve all the problems of a business process.
The second trick is that the more techniques you know, the better. For example, in ancient Japan lived Miyamoto Musashi, one of the most famous swordsmen, the author of the two-sword style. He studied at some school with some master, then traveled around Japan, fought with different dudes. If the guy was stronger, then the journey stopped for some time, and Musashi became a student. As a result, over several years he acquired the skills of various practices of different masters and formed his own school, adding something of his own. As a result, he achieved a unique skill. It's the same here.
You can, of course, act as business consultants. In general, they are great guys. But, as a rule, they come to introduce some kind of methodology, and they implement the wrong methodology that the business needs. We also had such sad situations: no one knows how to solve the problem and no one wants to think how to solve it. We start searching either on the Internet or call a consultant and ask him what can help us. The consultant thinks and says that we need to introduce the theory of constraints. We pay him for his recommendation, we spend money on implementation, but the results are zero.
Why does this happen? Because the consultant said, we are introducing such and such a system, and everyone agreed with him. Great, but one methodology does not cover all the problems of even one business process, especially if the initial prerequisites - ours and those required to implement the methodology - do not coincide.
In the practice that the guy recommends, you need to take the best and implement the best. Don’t take the methods entirely, but take their key features, features, and practices. And the most important thing is to understand the essence.
Take, he said, for example, Scrum or Agile. In his monologues, the guy repeated many times that not everyone fully understands the essence of Scrum. He also read Jeff Sutherland's book, which some people find "light reading." It seemed like a deep read to him, because one of the fundamental principles of Scrum is quality management, this is written directly in the book.
It says about Toyota Production, about how Jeff Sutherland showed Scrum in Japan, how it took root there and how close it was to their philosophy. And Sutherland talked about the importance of the role of the Scrum Master, about the Deming cycle. The role of the Scrum Master is to constantly speed up the process. Everything else that is in Scrum - phased delivery, customer satisfaction, a clear list of work for the sprint period - is also important, but all this must move faster and faster. The speed of work must constantly increase in the units in which it is measured.
Perhaps this is a matter of translation, because our book was translated as “Scrum - a revolutionary method of project management”, and if the English title is translated literally, it will turn out: “Scrum - twice as much in half the time”, that is, even in The name refers to speed as a key function of Scrum.
When this guy implemented Scrum, the speed doubled in the first month without any significant changes. He found points for change and modified Scrum itself to make it work much faster. The only thing they write on the Internet is that they were faced with the question: “We have doubled the speed, all that remains is to understand what we are doing at such a speed?” However, this is a completely different area...
He also personally recommended several techniques. He called them fundamental and fundamental.
The first is boundary management.
They teach it at Skolkovo; according to the guy, there are no other books and materials. He was somehow lucky enough to attend a lecture by a professor from Harvard who preaches boundary management, and also read several articles in the Harvard Business Review about the work of Eric Trist.
Boundary management says that you need to be able to see boundaries and work with boundaries. There are plenty of boundaries, they are everywhere - between departments, between different types of work, between functions, between operational and analytical work. Knowledge of boundary management does not reveal any higher truths, but it allows us to see reality in a slightly different light - through the prism of boundaries. And, accordingly, manage them - erect them where necessary, and remove them where they are in the way.
But most often the guy talked about controlling. He just had some kind of quirk on this topic.
Controlling, in short, is management based on numbers. Here, he said, every part of the definition is important - both “management” and “based on” and “numbers”.
We, he said, are bad with all three components of controlling. Especially considering that they are closely interconnected both with each other and with other parts of the business system.
The first thing that's bad is the numbers. There are few of them and they are of low quality.
We then took a significant part of the numbers from the 1C information system. So, the quality of the numbers in 1C, as he claimed, is no good. At a minimum, because of the ability to change data retroactively.
It is clear that this is not the fault of the 1C developers - they only take into account the requirements of the market and the mentality of domestic accounting. But for controlling purposes, it is better to change the principles of 1C work with data at a specific enterprise.
Further, the numbers from 1C, according to him, undergo semi-manual processing, using Excel, for example. Such processing also does not add quality to the data, as well as efficiency.
In the end, someone else double-checks the final report so as not to accidentally submit figures with errors to the manager. As a result, the numbers reach the recipient beautiful, verified, but very late. Usually - after the end of the period (month, week, etc.).
And here, he said, everything is very simple. If the numbers about January came to you in February, then you can no longer manage the activities of January. Because January is already over.
And if the figures are based on accounting, and the company is the most ordinary one, with quarterly submission of VAT, then its manager receives relatively adequate figures once a quarter.
The rest is clear. You receive numbers once a month - you have the opportunity to manage by numbers (i.e., control) 12 times a year. If you practice quarterly reporting, you manage it 4 times a year. Plus a bonus - annual reporting. Steer one more time.
The rest of the time, control is usually performed blindly.
When (and if) the numbers do appear, then the second problem comes into play - how to manage based on the numbers? I could not agree with this point of his reasoning.
The guy argued that if the manager didn’t have the numbers before, then their appearance would cause a wow effect. He will look and twist the numbers this way and that, call people on the carpet, demand explanations and investigations. After playing with numbers, conducting analysis, and threateningly promising all employees that “now I won’t get rid of you,” the manager will very quickly calm down and give up on this matter. Stop using the tool. But the problems will remain in place.
This happens, he said, due to insufficient managerial competencies. In controlling, first of all. The manager simply does not know what to do with these numbers. What сto do - knows what to do - no. To do is what is written about above (to quarrel, to play). Doing is a daily business process.
He argued that everything is very simple: digital must become part of the business process. In the business process it should be clearly clear: who should do what and when if the numbers deviate from the norm (any options - above the border, below the border, going beyond the corridor, the presence of a trend, failure to meet the quantile, etc.)
And so he outlined the key dilemma: the number exists, it should become part of the business system in order to increase management efficiency, but... this is not happening. Why?
Because the Russian leader will not give up a piece of his power to a competitor.
The competitors of the Russian manager - a high-quality and working business process, well-thought-out mutually beneficial motivation and proper automation - alas, will leave the manager without a job.
Kind of nonsense, don't you agree? Especially about leaders. Okay, I told you, you decide for yourself.
A little less, but still too much, in my opinion, he talked about Scrum.
Be sure, I said, read and try Scrum in practice. If, he says, you’ve read it but haven’t tried it, consider yourself ignorant. It’s better to read a book, for example by Sutherland, rather than articles and all sorts of guides (what the hell?) on the Internet.
Scrum, he said, can only be learned through practice, and with mandatory measurements of the amount of work performed. Personally try the two most important roles - Product Owner and Scrum Master.
It is especially important, according to the guy, to experience in practice the role of a Scrum Master, when you can increase the volume of tasks completed per sprint without increasing the resources and cost of the sprint.
Well, in his top there was TOS (theory of system limitations).
These, according to the guy, are the basic, fundamental principles of increasing efficiency that can be applied in almost any area, in any business process and business system as a whole.
When he found out that we were not familiar with TOS, he stopped telling us. He only added that he would not deprive us of the pleasure of reading Eliyahu Goldratt’s books. He gave a similar recommendation to Scrum - read it and try it. Like, no matter what position you are in, no matter what work you do, there is a place for increasing efficiency using TOC methods.
Then his bag of techniques apparently dried up, and he said: mix the principles to create applied solutions in a specific situation.
This, he says, is the main recommendation, the key to success. Understand the principles, essence, and create unique application solutions - business processes and business systems.
Then he tried to remember some quote, and in the end he had to go online. It turned out to be a quote from the article “Standing on the Shoulders of Giants” by Eliyahu Goldratt:
“There is a difference between applied solutions (applications) and the fundamental concepts on which those solutions are based. Concepts are general; applied solutions are the adaptation of concepts to a specific environment. As we have already seen, such adaptation is not simple and requires the development of certain elements of the solution. We must remember that an application solution is based on initial assumptions (sometimes hidden) about a specific environment. This application solution should not be expected to work in an environment for which the assumptions are not correct.”
He said that the work of a programmer and a “business process improver” are very similar. And left.
Source: habr.com