<\/a><\/noindex><\/p>\nHe fancied himself clever and decided to find a niche within the company he worked for. This niche needed to be something special, unoccupied by anyone else. He wanted the company to willingly pay someone in this niche, without deception or manipulation involved. It should be objective: it was necessary to pay a lot of money to the person in this position. A oddball, to say the least.<\/p>\n
The search didn\u2019t take long. In the company where this guy worked, there was a completely available niche that could be conditionally called \"organizing business processes.\" Every company has a ton of problems. There's always something that doesn\u2019t work, and there\u2019s no one to come in and fix the business process. So, he decided to try himself as a specialist who could help the owner solve his business process problems.<\/p>\n
At that time, he had been working at the company for six months and was earning an average market salary. He had nothing to lose \u2014 especially since he could easily find the same job within a week. Overall, this guy reasoned that nothing terrible would happen if things didn\u2019t work out and he got fired.<\/p>\n
He gathered his courage and approached the owner. He suggested improving the most problematic process in the business at the time, which was inventory management. Now, everyone working in this company feels ashamed to recall those issues, as the quarterly inventories revealed discrepancies between the accounting system and actual stock levels of tens of percent, both in value and quantity, and in the number of items. It was a disaster. The company only had accurate stock levels in the accounting system four times a year\u2014on the day after the inventory. This is the process our guy set out to fix.<\/p>\n
The guy made an agreement with the owner to reduce the discrepancies in the inventory results by half. Moreover, the owner had little to lose, as various employees had already attempted to fix things before our hero, and the task was generally considered nearly impossible. This greatly fueled interest because if it worked, the guy would automatically become known as someone who can bring order and solve insurmountable problems.<\/p>\n
So, his task was clear: to reduce the inventory discrepancies by half within a year. At the start of the project, he had no idea how to achieve this, but he understood that inventory management is a straightforward matter, so he figured he could still accomplish something useful. Especially since reducing discrepancies from tens of percent to a single digit didn't seem that difficult. Everyone who has worked in consulting or a similar field knows that most process problems can be resolved with relatively simple actions.<\/p>\n
From January to May, he prepared, automated some processes, rewrote the business operations for inventory management, changed the workflows for warehouse workers and accountants, and completely revamped the system without showing or telling anyone. In May, he distributed new instructions to everyone, and after the first inventory count of the year, a new life began \u2013 work according to his rules. To monitor the results, the company started conducting inventory counts more frequently \u2013 every two months. The initial results were positive, and by the end of the year, discrepancies in the audit results had fallen to fractions of one percent.<\/p>\n
The success was tremendous, but its sustainability was doubted. The young man himself questioned whether the results would hold if he stepped back and stopped overseeing the process. Nevertheless, the results were there, and he received everything he had agreed upon with the owner. Later, after a few years, the sustainability of the results was confirmed \u2013 for several years, discrepancies remained within 1%.<\/p>\n
He then decided to repeat the experiment and suggested to the owner to improve another problematic process \u2013 procurement. There were shortages that prevented shipping the volumes that our clients wanted. They agreed that within a year the shortages would be halved, and the guy would complete another 10-15 projects related to 1C \u2013 automating different business processes and other related tasks.<\/p>\n
In the second year, everything was successfully completed again; shortages decreased by more than 2 times, and all IT projects were successfully finished.<\/p>\n
Since his salary already fully met all of his requests for the next two years, he decided to settle down a bit, calm down, and enjoy a cozy warm place that he had created for himself.<\/p>\n
What did this entail? Formally, he was the IT director. But understanding who he really was is difficult. After all, what does an IT director do? Usually, they administer the IT infrastructure, manage system administrators, implement ERP systems, and participate in meetings of the board of directors.<\/p>\n
One of this guy's key responsibilities was participating in change processes, mainly generating and initiating these processes, searching for and proposing solutions, applying new management methods, assessing proposed changes, analyzing the effectiveness of other functions and departments, and finally, directly engaging in the strategic development of the company, right down to independently developing the company-wide strategic plan.<\/p>\n
He was given a free hand. He could attend any meeting he had previously not had access to. He would sit there with a notebook, writing something down or just listening. He spoke rarely. Then he started playing on his phone\u2014he claimed that this helped his associative memory work better.<\/p>\n
He rarely contributed anything useful at meetings. He would leave, think, and then a letter would arrive\u2014either with criticism, or opinions, or suggestions, or descriptions of solutions he had already implemented.<\/p>\n
But more often than not, he gathered meetings himself. He would identify a problem, come up with solution options, determine the stakeholders, and pull everyone into the negotiation room. And there he would\u2014do his best. Persuade, motivate, argue, prove, and negotiate. <\/p>\n
Unofficially, he was considered the third person in the company, after the owner and the director. Naturally, he drove all the company 'faces,' starting from number 4, absolutely crazy. Especially with his torn jeans and bright t-shirts, not to mention the time of the owner.<\/p>\n
The owner dedicated one hour to him each day. Every day. They talked, discussed problems, solutions, new businesses, development directions, metrics and effectiveness, personal development, books, and just life.<\/p>\n
But this guy was peculiar. It seemed like he should just sit back and enjoy life, but no. He decided to reflect.<\/p>\n
He became curious: why was it that he succeeded while others did not? The owner also urged him on, saying that he wanted others to be able to establish order too, because there were many managers, who generally focused on operational management and strategic planning, but practically no one addressed systematic changes in their processes. It might be written in their job descriptions that they should speed up their processes and enhance their efficiency, but in reality, no one was doing this. Why was that? This young man also became curious about why, and he went to speak with all these managers.<\/p>\n
He went to the quality deputy director and suggested implementing control charts to improve product quality beyond that of the Japanese. But it turned out that his colleague didn\u2019t know what control charts were, what statistical process control meant, and had only heard vaguely about the Deming cycle in quality management. Alright\u2026<\/p>\n
He then went to another deputy director and suggested implementing controlling. But here too he found no support. A bit later, he learned about boundary management and proposed to all the deputy directors to implement the systemic part of this methodology to improve processes. But no matter how much he talked, nobody really wanted to engage with the subject. Perhaps they found it uninteresting or too complex. But in fact, no one really grasped it.<\/p>\n
In general, he shared everything he knew and applied in the company. But no one understood him. They still do not comprehend why, for example, everything was managed in warehouse accounting, and how controlling and boundary management fit into it.<\/p>\n
Finally, he reached out to his programmers - there were three in the team. He talked about boundary management, controlling, quality management, agile, and scrum... Surprisingly, they all understood him, and could even discuss technical and methodological nuances with him. They understood why the warehouse and supply chain projects succeeded. And then it struck him: it would actually be programmers who would save the world.<\/p>\n
He realized that programmers were the only ones who could properly understand business processes with the necessary detail.<\/p>\n
Why them? In fact, he never found a definitive answer. He only formulated some thesis hints.<\/p>\n
First of all, programmers understand the business domains, and they know them better than anyone else in the company.<\/p>\n
Moreover, programmers truly grasp what a process algorithm is. This is important because business processes are algorithms, and elements within them can be out of sync. For instance, in the procurement process the guy was working on, the first step is to create an annual procurement plan, and the second is daily procurement. These steps are linked by a direct connection, which means it's assumed that people should work according to this algorithm \u2013 to create the annual procurement plan and immediately fulfill requests. The annual procurement plan is made once a year, while requests come in 50 times a day. The algorithm ends there, and one has to work according to it. He reasoned that for programmers, knowledge of algorithms is a competitive advantage because anyone else unfamiliar with them simply does not understand how a business process should function and how it can be depicted.<\/p>\n
Another plus for programmers, according to that 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 to bring any business process in order, one needs to have a lot of free time \u2013 to think, observe, learn, and experiment.<\/p>\n
Most managers, according to the guy, do not have this free time and take pride in it. Although in reality, this means a person cannot become effective because they lack time for enhancing efficiency \u2013 a vicious circle. In our culture, it's fashionable to be busy, which keeps everything stagnant. But for us, programmers, this is an advantage. We can find free time and reflect on everything.<\/p>\n
Programmers, he stated, can quickly change the information system. This isn't applicable in all enterprises, but wherever he worked, adjustments could be made at will, especially when they didn\u2019t affect anyone else's work. For example, he could launch a system that would secretly measure users' actions and then use this information to analyze the efficiency of the accounting department and track the cost of accounting.<\/p>\n
And the last thing I remember from his words is that programmers have access to a vast amount of information since they are granted administrative access to the system. Therefore, they can use this information in their analysis. No one else at a typical factory possesses such a resource.<\/p>\n
Then he left. During the required two-week notice period, we made him share his experience because we wanted to continue the work he was doing. Also, his position was becoming vacant.<\/p>\n
Over the course of several days, we seated him on a chair, turned on the camera, and recorded his monologues. We asked him to talk about all the completed projects, methods, approaches, successes and failures, reasons and consequences, profiles of leaders, etc. We didn't impose many restrictions since we didn't know what was going on in his head. <\/p>\n
His monologues, of course, mostly contained all sorts of nonsense and humor \u2014 he was in high spirits as he was moving from a remote area to St. Petersburg. But where would he go to work in St. Petersburg? At Gazprom, of course.<\/p>\n
But we managed to extract some useful information from his monologues. I'll share what I remember.<\/p>\n
So, the recommendations from that guy. For those who want to try to bring order to business processes.<\/p>\n
To do such work, first of all, you need to have a certain level of \u2018fearlessness\u2019. You must not be afraid of losing your job, not be afraid to take risks, not be afraid of conflicts with colleagues. He found this easy because he began his path after working at the company for only six months, and he hadn't had time to build connections with anyone, nor did he intend to. He understood that people come and go, and what mattered to him were his own results and their evaluation by the business owner. Whether colleagues liked him or not mattered little to him at the time.<\/p>\n
The second point is that to effectively engage in this work, unfortunately, you will have to learn. But it\u2019s not about an MBA, courses, or institutions; it\u2019s about self-education. For instance, in his first project related to the warehouse, he acted intuitively, knowing nothing except what 'quality management' was.<\/p>\n
When he started reading literature on methods to improve efficiency, he discovered the technologies he had been applying. The guy applied them intuitively, only to find out it wasn't his invention; everything had been written long ago. However, he spent time\u2014much more than if he had read the necessary book right away. Here, it\u2019s crucial to understand that when studying a specific methodology, none of them, even the most advanced, can fully solve all business process problems.<\/p>\n
The second trick is that the more methodologies you know, the better. For example, in ancient Japan, there lived Miyamoto Musashi \u2013 one of the most famous swordsmen, author of the two-sword style. He studied at some school under some master, then traveled across Japan, battling various opponents. If a fighter was stronger, the journey would pause, and Musashi would become a pupil. As a result, over several years, he acquired skills from various masters' practices and formed his own school, adding his unique touch. Ultimately, he achieved a unique mastery. It's the same here.<\/p>\n
Of course, you can act like business consultants. They are generally great guys. But, as a rule, they come to implement a certain methodology, and they often apply the wrong one for the business\u2019s needs. We too have had such unfortunate situations: no one knows how to solve the problem, and no one wants to think about how to resolve it. We start searching either on the internet or call a consultant, asking what can help us. The consultant thinks and suggests that we should implement the theory of constraints. We pay him for the recommendation and spend on implementation, but the result is zero.<\/p>\n
Why does this happen? Because the consultant said to implement a certain system, and everyone agreed with him. Wonderful, but one methodology doesn\u2019t cover all problems even for a single business process, especially if the initial conditions\u2014ours and those required for the methodology implementation\u2014do not match.<\/p>\n
In the practice that the guy recommends, you should take the best and implement it. Don't adopt methods entirely, but rather extract their key features, tricks, and practices. And most importantly, you need to understand the essence.<\/p>\n
Let's take, 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 consider 'light reading.' To him, it was profound, because one of the fundamental principles of Scrum is quality management, which is clearly written about in the book.<\/p>\n
It talks about Toyota Production, about how Jeff Sutherland demonstrated Scrum in Japan, how it took root there, and how close it was to their philosophy. Sutherland also spoke about the importance of the Scrum Master's role and the Deming cycle. The Scrum Master's role is to continuously accelerate the process. Everything else in Scrum\u2014phase delivery, customer satisfaction, a clear list of work for the sprint period\u2014is also important, but it all needs to move faster and faster. The work speed should continually increase in the units by which it is measured.<\/p>\n
Perhaps it lies in the translation, because our book was translated as 'Scrum \u2013 a revolutionary project management method,' but if you translate the English title literally, it would come out as: 'Scrum \u2013 twice as much in half the time,' meaning even in the title there is a reference to speed as a key feature of Scrum.<\/p>\n
When this guy implemented Scrum, the speed doubled in the first month without any significant changes. He found points for improvement, modified Scrum to work much faster. The only issue, as is written online, was the question they faced: 'We've doubled our speed; now we need to understand what to do with that speed.' However, that is a completely different area...<\/p>\n
He also personally recommended several methodologies. He called them fundamental and foundational.<\/p>\n
The first is boundary management.<\/p>\n
It is taught at Skolkovo; according to the guy, there are no other books or materials available. He was fortunate enough to attend a lecture by a Harvard professor who advocates for boundary management and also read several articles in Harvard Business Review about the works of Erik Trista. <\/p>\n
Boundary management is about being able to see boundaries and work with them. Boundaries are everywhere \u2014 between departments, between different types of work, between functions, between operational and analytical tasks. Understanding boundary management doesn\u2019t reveal higher truths, but allows one to see reality in a different light \u2014 through the lens of boundaries. Accordingly, it enables managing them \u2014 establishing them where necessary and removing them where they hinder progress.<\/p>\n
But more often, the guy spoke about controlling. He had an obsession with this topic.<\/p>\n
Controlling, in brief, is management based on numbers. Here, he emphasized that every part of the definition is important \u2014 'management,' 'based on,' and 'numbers.'<\/p>\n
According to him, we are struggling with all three components of controlling. Especially considering that they are closely interconnected with each other and other parts of the business system.<\/p>\n
The first issue is with the numbers. There are too few of them, and the quality is poor.<\/p>\n
We took a significant part of the numbers from the 1C information system. The quality of the numbers in 1C, he asserted, is unacceptable. At the very least, this is due to the possibility of retroactively modifying the data.<\/p>\n
It\u2019s clear that the developers of 1C are not to blame for this \u2014 they merely respond to market demands and the mentality of domestic accounting. However, for controlling purposes, the principles of how 1C handles data should be modified for specific enterprises.<\/p>\n
After that, the numbers from 1C, according to him, undergo semi-manual processing using Excel, for example. Such processing does not improve the quality of the data or its timeliness.<\/p>\n
In the end, someone checks the final report to ensure that numbers with errors are not mistakenly presented to the management. As a result, the numbers reach the recipient looking polished and verified, but very late \u2014 usually after the period (month, week, etc.) has concluded.<\/p>\n
And here, he said, it is very simple. If the numbers for January reach you in February, you can no longer manage January\u2019s activities. Because January has already ended.<\/p>\n
If the figures are based on accounting, and the company is an ordinary one, submitting VAT quarterly, then the manager receives relatively adequate figures once a quarter.<\/p>\n
Next, it\u2019s clear. If you get figures once a month, you have the opportunity to manage by the numbers (i.e., conduct controlling) 12 times a year. If you practice quarterly reporting, you manage 4 times a year. Plus, there's the annual report as a bonus. Another chance to steer the ship.<\/p>\n
Most of the time, management is typically done blindly.<\/p>\n
When (and if) the figures do appear, a second problem arises \u2014 how to manage based on these figures? I couldn\u2019t agree with him on this point of reasoning.<\/p>\n
The guy claimed that if the manager hadn't had figures before, their appearance would cause a wow effect. He would look at the numbers, twist them every which way, call people in, demand explanations and investigations. After playing around with the figures, conducting reviews, and sternly promising everyone, \"I won't let go of you now,\" the manager would quickly calm down and drop it. He would stop using the tool. Meanwhile, problems would remain.<\/p>\n
This happens, he said, due to the manager's insufficient competencies. Primarily in controlling. The manager simply doesn't know what to do with these figures. Knowing what to do \u2014 yes, but knowing how to act \u2014 no. Taking action \u2014 that's about what was mentioned earlier (getting angry, playing around). Doing \u2014 that's the daily business process. with<\/b>He insisted that it was very simple: the number must become part of the business process. It should be clear in the business process: who, what, and when should act in response to a deviation of the number from the norm (any scenarios \u2014 above the limit, below the limit, going outside the corridor, trend presence, failure to meet quantiles, etc.)<\/p>\n
And he outlined the key dilemma: the figure exists, it must become part of the business system to improve management efficiency, but... this doesn't happen. Why?<\/p>\n
Because a Russian manager will not give up a piece of his power to a competitor.<\/p>\n
The competitors of a Russian manager \u2014 a quality and functioning business process, well-thought-out mutually beneficial motivation, and proper automation \u2014 unfortunately, will leave the manager without a job.<\/p>\n
The competitors of the Russian manager \u2014 a quality and functioning business process, well-thought-out mutually beneficial motivation, and proper automation \u2014 unfortunately, will leave the manager unemployed.<\/p>\n
It's nonsense, wouldn't you agree? Especially about the leaders. Well, I shared it, you decide for yourselves.<\/p>\n
A bit less, but still too much, in my opinion, he was talking about Scrum.<\/p>\n
He insisted, read and try Scrum in practice. If you\u2019ve read it but haven\u2019t tried it, consider that you don't know it. It\u2019s better to read a book, like Sutherland's, rather than articles and various guides (what nonsense?) on the internet.<\/p>\n
Scrum, he said, is only understood through practice, with mandatory measurements of the volume of completed work. Personally, try out the two most important roles \u2014 the product owner and the scrum master.<\/p>\n
Especially important, according to the guy, is to experience the role of the scrum master in practice, when you can increase the volume of tasks completed per sprint without increasing resources and costs.<\/p>\n
He also highly regarded TOC (Theory of Constraints).<\/p>\n
These, according to the guy, are fundamental principles for improving efficiency that can be applied in almost any area, in any business process and business system as a whole.<\/p>\n
When he found out we weren't familiar with TOC, he stopped explaining. He just added that he wouldn't deprive us of the pleasure of reading Eliyahu Goldratt's books. He made a similar recommendation to Scrum \u2014 read it and try it. He said, no matter what position you are in or what work you do, there is room for improving efficiency through TOC methods.<\/p>\n
Then it seemed his toolkit of methods was exhausted, and he said: mix principles to create practical solutions for specific situations.<\/p>\n
This, he says, is the main recommendation, the key to success. Understand the principles, the essence, and create unique practical solutions \u2014 business processes and business systems.<\/p>\n
Then he struggled to recall a quote, and eventually had to look it up online. It turned out to be a quote from the article \"Standing on the Shoulders of Giants\" by Eliyahu Goldratt:<\/p>\n
There is a difference between applied solutions and the fundamental concepts on which these solutions are based. Concepts are general, while applied solutions are adaptations of concepts to specific environments. As we have seen, such adaptations are not simple and necessitate the development of certain solution elements. We must remember that an applied solution is based on initial premises (sometimes hidden) about the specific environment. One should not expect this applied solution to work in an environment where the initial premises are not valid.<\/p>\n
He said that the work of a programmer and a \"business process improver\" is very similar. And he left.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0418\u0441\u0442\u043e\u0440\u0438\u044f \u0440\u0435\u0430\u043b\u044c\u043d\u0430\u044f, \u044f \u0432\u0441\u0435 \u0432\u0438\u0434\u0435\u043b \u0441\u0432\u043e\u0438\u043c\u0438 \u0433\u043b\u0430\u0437\u0430\u043c\u0438. \u041d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u043e\u0434\u0438\u043d \u043f\u0430\u0440\u0435\u043d\u044c, \u043a\u0430\u043a \u0438 \u043c\u043d\u043e\u0433\u0438\u0435 \u0438\u0437 \u0432\u0430\u0441, \u0440\u0430\u0431\u043e\u0442\u0430\u043b \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u043e\u043c. \u041d\u0430 \u0432\u0441\u044f\u043a\u0438\u0439 \u0441\u043b\u0443\u0447\u0430\u0439 \u043d\u0430\u043f\u0438\u0448\u0443 \u0442\u0430\u043a: \u00ab\u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u043e\u043c\u00bb. \u041f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u043e\u043d \u0431\u044b\u043b 1\u0421\u043d\u0438\u043a\u043e\u043c, \u043d\u0430 \u0444\u0438\u043a\u0441\u0435, \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438. \u0414\u043e \u044d\u0442\u043e\u0433\u043e \u043e\u043d \u043f\u0440\u043e\u0431\u043e\u0432\u0430\u043b \u0440\u0430\u0437\u043d\u044b\u0435 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u2013 4 \u0433\u043e\u0434\u0430 \u0432\u043e \u0444\u0440\u0430\u043d\u0447\u0435 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u043e\u043c, \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u043c \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0443\u043c\u0435\u043b \u0437\u0430\u043a\u0440\u044b\u0432\u0430\u0442\u044c \u043f\u043e 200 \u0447\u0430\u0441\u043e\u0432, \u043e\u0434\u043d\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e \u043f\u043e\u043b\u0443\u0447\u0430\u044f \u043f\u0440\u043e\u0446\u0435\u043d\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-54335","post","type-post","status-publish","format-standard","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t