Business processes in the load
Many people know about the "cult of cargo" - an amazing phenomenon that took place during the Second World War. During the fighting, the remote islands in the Pacific Ocean suddenly became a strategic object, the Americans built a military base on them, and local natives were blessed with the products of civilization that delivered cargo planes. The natives decided that a cunning white man, who himself does not produce any material assets, receives them directly from the gods, performing mysterious rituals: marching sticks along the parade-ground, sitting near the box with the antenna and praying in an incomprehensible language, calling on the birds of heaven. When the war ended, the Americans left the islands and their naive inhabitants. When the explorers later returned to the island, they were surprised to find the natives with painted stripes marching along the parade-ground and shamans calling for “cargo” in wooden headphones in front of a radio station dummy.
The cult of cargo, as it turned out, thrives not only on distant islands, but also in the offices of our Russian leaders. For many years they have been fully confident that if you put on a suit, sit in a chair, spend money on an expensive import system, iron birds will fly in and business efficiency will automatically increase. Sometimes priests in wooden headphones with business cards from various consulting companies also appear on the horizon and provide all possible assistance in invoking iron birds.
But let's digress, perhaps, from lyrical allegories and talk about how and why in projects for the implementation of automated control systems different people make the same mistakes related to the disregard of elementary things. Namely, why project customers refuse to see their own business processes.
Let's start with the most egregious example of the client's short-sightedness, which eventually led to a severe clinch in the project. One government customer wanted a complex object management system. He formulated detailed requirements for data collection and management functions, for subsystems, formulated general tasks at the business level (“improving something”, “reducing this”), formulated documentation requirements, reliability, and many more full compliance with GOST 34X.
')
The contractor took these requirements and began to develop the system. The early prototype did not cause any special complaints with the customer, and the contractor continued to develop. Everything was simple and logical: the image of the control object was on the screen. The user monitored the state of the object, chose various elements of the system and could do certain actions with them. In strict accordance with the technical specifications.
The most interesting thing began when the customer began to think about the organization of work on the operation of the control object. There are people who began to ask questions about how they will have to work, and who should be doing what. Correct questions that the customer had no answers. And he, guided by the logic obvious to many managers, decided to “squeeze” everything that was necessary for organizing the work of the developer, who had not yet had time to turn in the system and run with the money.
He began with the regulations of the new service. The executor with a sigh removed people from the implementation and directed them to develop regulations. He did not want to quarrel with the customer. Then the customer decided that the organizational interaction between people is very complex and requires automation. And then he suddenly thought that it would be nice to make the developed system be able to support the interaction processes and adapt flexibly for them. But here the laws of physics prevailed, and the performer began to glance toward the forest, mourning in advance the eaten advance.
Because, as it turned out, the customer actually needed to automate business processes with all its “buns” - automatic documentation, flexible configuration of rules in graphical editors, user interfaces that are created in real time depending on business rules ... The contractor tried hide behind the TK, but who in our time is worried about stupid papers? As a result, the customer began a massive trolling, began to delay the acceptance of work, the contractor faced financial problems, employees began to scatter, and the project was on the verge of closing. Successful, by the way, the project development of ACS.
The second example is softer, but no less significant. A large commercial customer wanted a process control system. The contractor took a specialized platform and began development. In the course of the survey, it turned out that the client actually has no processes, but there is some kind of non-formalized activity, sometimes chaotic and convulsive-convulsive. And since the formalization and formulation of business processes was not part of the work, the developers of the system had to get out. They scratched their heads and decided to implement the easiest option from their point of view. The customer, who, we recall, had no formalized processes, also scratched his head and accepted the proposed form of the process.
The fun began when customer employees tried to use the system. It turned out that the process was developed inconvenient, somewhere too complicated, but somewhere not sufficiently detailed. The system implementing it also turned out to be completely different from what the customer expected. The painful lapping stage began when, during the endless bidding process, the system began to acquire the desired look, and the customer began to build and describe his processes. The terms of introduction have doubled, the costs on both sides have also grown to completely ugly sizes. The project was already finished from a pure principle, and after the transfer of the next stage, almost the entire exhausted executor’s team quit.
The third example will be a successful example. The customer wanted a business process automation system. The technical assignment contained requirements both for the process itself and for its automation system. Before starting the project, the customer conducted training for key users and participants of the implementation team, where he showed the principles of organizing the designed business process and its benefits. Of the entire mass of users, several enthusiasts stood out, who formed the basis of the implementation team on the part of the customer.
Two thirds of the project’s works were related to the development of any instructions, interaction rules, responsibility matrices and the like. When the system tests began, trained and trained users sat down at the computers. And although the system turned out to be rather scarce in terms of functionality, the process started immediately and without squeaking. As far as I know, he has been successfully working so far (for more than three years now) without the participation of any consultants of any kind.
Let's sum up. The first example shows us an error in assessing the initial needs of the customer. Experienced implementers should not only read the TK, but also look at the customer's business. If he does not have the described processes, if in his organization there are not yet formed departments in which future users will work, then this is the first alarm bell. Sooner or later, such a customer will want to organize the operation. And if he doesn’t buy consulting services on organization of processes from you (and this is almost always the case), then you still need to lay in the system architecture possibilities for flexible adjustment of processes during implementation and even during operation. For example, instead of a SCADA system, implement an ESB based system or their symbiosis. For the customer, this will be a more expensive solution both on the platform and on additional capacities, but you have to pay for flexibility, and the risk of being left with nothing requires taking action.
The second case shows us the problem of the isolation of management from the real situation. When ordering you a system, they sincerely believe their subordinates, who assure them that all processes have been described for a long time and do not need to invent anything. Then they admit their mistakes, but it won't be any easier for you. The recipe here is also simple as a penny. Go down from the director's office to the production. Sit next to the performers, talk to them as an equal with equals. They will tell you about all their troubles - and that there are no instructions, and that there is a mess in the administration, and that they do not report in the dining room meat. Listen to them, and include in the quotation the clause “updating business processes”. Maybe the manager will think, and he will pay you for this work. And it will be money invested in the right thing.
What is the cult of "cargo"? And despite the fact that we, like those natives, have not yet recovered from the wave of a variety of “best practices”, ”advanced techniques” and miraculous systems that surged upon us because of the disappeared iron curtain. Many believe that the systems themselves solve business problems. What buying, for example, ERP, the company will reduce production inventories, and introducing CRM will immediately eliminate the risk of disposal of customers by dashing managers.
Yes, the presence of a walkie-talkie is necessary to call the iron bird. But in order for it to really arrive, you still need to know a lot and think a lot about it. The roots of our problem are in our past. At the helm of enterprises are techies with tech-narian mindset. The vast majority of IT companies are also headed by techies. Techies believe in technology, programs, algorithms, systems capabilities. Techies with disregard refer to the “pieces of paper”: regulations and instructions. And they really do not believe techies in people. But people are the main resource and main means of production of IT companies. People are the main gears of any business process, regardless of their level of automation. You can not neglect people in the processes and underestimate their impact on the success of any project. Those projects where they understand this become the beautification of the career of each team member.
Perhaps, colleagues, I again said some platitudes. But I will say platitudes and obvious things until these natives from the business and their shaman friends in wooden earphones do not sink into history.
PS from 23.09. Colleagues sent a link to the article by Mikhail Pliss “Bummer ambitions, or why the position of CIO in Russia is a career dead end” , which perfectly complements this post. Even nothing to add. I read and respectfully keep quiet.
The cult of cargo, as it turned out, thrives not only on distant islands, but also in the offices of our Russian leaders. For many years they have been fully confident that if you put on a suit, sit in a chair, spend money on an expensive import system, iron birds will fly in and business efficiency will automatically increase. Sometimes priests in wooden headphones with business cards from various consulting companies also appear on the horizon and provide all possible assistance in invoking iron birds.
But let's digress, perhaps, from lyrical allegories and talk about how and why in projects for the implementation of automated control systems different people make the same mistakes related to the disregard of elementary things. Namely, why project customers refuse to see their own business processes.
Let's start with the most egregious example of the client's short-sightedness, which eventually led to a severe clinch in the project. One government customer wanted a complex object management system. He formulated detailed requirements for data collection and management functions, for subsystems, formulated general tasks at the business level (“improving something”, “reducing this”), formulated documentation requirements, reliability, and many more full compliance with GOST 34X.
')
The contractor took these requirements and began to develop the system. The early prototype did not cause any special complaints with the customer, and the contractor continued to develop. Everything was simple and logical: the image of the control object was on the screen. The user monitored the state of the object, chose various elements of the system and could do certain actions with them. In strict accordance with the technical specifications.
The most interesting thing began when the customer began to think about the organization of work on the operation of the control object. There are people who began to ask questions about how they will have to work, and who should be doing what. Correct questions that the customer had no answers. And he, guided by the logic obvious to many managers, decided to “squeeze” everything that was necessary for organizing the work of the developer, who had not yet had time to turn in the system and run with the money.
He began with the regulations of the new service. The executor with a sigh removed people from the implementation and directed them to develop regulations. He did not want to quarrel with the customer. Then the customer decided that the organizational interaction between people is very complex and requires automation. And then he suddenly thought that it would be nice to make the developed system be able to support the interaction processes and adapt flexibly for them. But here the laws of physics prevailed, and the performer began to glance toward the forest, mourning in advance the eaten advance.
Because, as it turned out, the customer actually needed to automate business processes with all its “buns” - automatic documentation, flexible configuration of rules in graphical editors, user interfaces that are created in real time depending on business rules ... The contractor tried hide behind the TK, but who in our time is worried about stupid papers? As a result, the customer began a massive trolling, began to delay the acceptance of work, the contractor faced financial problems, employees began to scatter, and the project was on the verge of closing. Successful, by the way, the project development of ACS.
The second example is softer, but no less significant. A large commercial customer wanted a process control system. The contractor took a specialized platform and began development. In the course of the survey, it turned out that the client actually has no processes, but there is some kind of non-formalized activity, sometimes chaotic and convulsive-convulsive. And since the formalization and formulation of business processes was not part of the work, the developers of the system had to get out. They scratched their heads and decided to implement the easiest option from their point of view. The customer, who, we recall, had no formalized processes, also scratched his head and accepted the proposed form of the process.
The fun began when customer employees tried to use the system. It turned out that the process was developed inconvenient, somewhere too complicated, but somewhere not sufficiently detailed. The system implementing it also turned out to be completely different from what the customer expected. The painful lapping stage began when, during the endless bidding process, the system began to acquire the desired look, and the customer began to build and describe his processes. The terms of introduction have doubled, the costs on both sides have also grown to completely ugly sizes. The project was already finished from a pure principle, and after the transfer of the next stage, almost the entire exhausted executor’s team quit.
The third example will be a successful example. The customer wanted a business process automation system. The technical assignment contained requirements both for the process itself and for its automation system. Before starting the project, the customer conducted training for key users and participants of the implementation team, where he showed the principles of organizing the designed business process and its benefits. Of the entire mass of users, several enthusiasts stood out, who formed the basis of the implementation team on the part of the customer.
Two thirds of the project’s works were related to the development of any instructions, interaction rules, responsibility matrices and the like. When the system tests began, trained and trained users sat down at the computers. And although the system turned out to be rather scarce in terms of functionality, the process started immediately and without squeaking. As far as I know, he has been successfully working so far (for more than three years now) without the participation of any consultants of any kind.
Let's sum up. The first example shows us an error in assessing the initial needs of the customer. Experienced implementers should not only read the TK, but also look at the customer's business. If he does not have the described processes, if in his organization there are not yet formed departments in which future users will work, then this is the first alarm bell. Sooner or later, such a customer will want to organize the operation. And if he doesn’t buy consulting services on organization of processes from you (and this is almost always the case), then you still need to lay in the system architecture possibilities for flexible adjustment of processes during implementation and even during operation. For example, instead of a SCADA system, implement an ESB based system or their symbiosis. For the customer, this will be a more expensive solution both on the platform and on additional capacities, but you have to pay for flexibility, and the risk of being left with nothing requires taking action.
The second case shows us the problem of the isolation of management from the real situation. When ordering you a system, they sincerely believe their subordinates, who assure them that all processes have been described for a long time and do not need to invent anything. Then they admit their mistakes, but it won't be any easier for you. The recipe here is also simple as a penny. Go down from the director's office to the production. Sit next to the performers, talk to them as an equal with equals. They will tell you about all their troubles - and that there are no instructions, and that there is a mess in the administration, and that they do not report in the dining room meat. Listen to them, and include in the quotation the clause “updating business processes”. Maybe the manager will think, and he will pay you for this work. And it will be money invested in the right thing.
What is the cult of "cargo"? And despite the fact that we, like those natives, have not yet recovered from the wave of a variety of “best practices”, ”advanced techniques” and miraculous systems that surged upon us because of the disappeared iron curtain. Many believe that the systems themselves solve business problems. What buying, for example, ERP, the company will reduce production inventories, and introducing CRM will immediately eliminate the risk of disposal of customers by dashing managers.
Yes, the presence of a walkie-talkie is necessary to call the iron bird. But in order for it to really arrive, you still need to know a lot and think a lot about it. The roots of our problem are in our past. At the helm of enterprises are techies with tech-narian mindset. The vast majority of IT companies are also headed by techies. Techies believe in technology, programs, algorithms, systems capabilities. Techies with disregard refer to the “pieces of paper”: regulations and instructions. And they really do not believe techies in people. But people are the main resource and main means of production of IT companies. People are the main gears of any business process, regardless of their level of automation. You can not neglect people in the processes and underestimate their impact on the success of any project. Those projects where they understand this become the beautification of the career of each team member.
Perhaps, colleagues, I again said some platitudes. But I will say platitudes and obvious things until these natives from the business and their shaman friends in wooden earphones do not sink into history.
PS from 23.09. Colleagues sent a link to the article by Mikhail Pliss “Bummer ambitions, or why the position of CIO in Russia is a career dead end” , which perfectly complements this post. Even nothing to add. I read and respectfully keep quiet.
Source: https://habr.com/ru/post/128912/
All Articles