How we made a prototype stop repair application
Hello! My name is Andrey Grachev, and I am a product manager at SIBUR.
In SIBUR, “stop repairs” regularly take place. This is something like preventive maintenance, scheduled maintenance and repair, during which the entire plant or part of it is completely stopped. Such repairs are necessary to ensure the smooth operation of the enterprise in the future. But, it is clear that at this time the plant does not make money, so it is important to do everything as quickly as possible. For this you need to optimally plan and carry out work. So the idea came up to create your own mobile application for stop repairs, which would make the process of managing work more organized, minimize the loss of time. We’ll tell you how we did it, what happened in the end and what we are striving for now.
To begin, I will tell you what a stop repair is. This is a set of measures for the repair of a large number of plant equipment, which must be carried out at a certain period of time - for example, once a year, quarter or at other intervals. At this time, production stops, the contractor calls in at the plant, everything that is needed is repaired. It can last a week, several weeks, at Sibur-Khimprom, for example, the plant stopped for almost a month.
Such a large-scale repair of almost all equipment at the plant can be presented as a large project. He has preparatory operations when the plant gradually reduces power and stops. There is an active phase, when there is a replacement and maintenance of units, and the phase of the resumption of production. 10-11 months before the start of the repair work, all responsible persons begin to plan this procedure, order orders are created for the work that needs to be carried out. Thus, by the beginning of work, a large pool of tasks is accumulated that must be completed within the time allotted for repair. These tasks are often interrelated: without completing one, you cannot start another. For example, we cannot repair something in the pump, because we must first turn it off, remove equipment that interferes with the dismantling of this unit, and only then work with the pump. From these interconnections the term of the entire stop repair is built.
Stop repairs have a “critical path”. As a rule, from year to year at each enterprise there are constant operations, without which the plant cannot be started. It turns out that the critical path is the longest time that can be spent on stop repairs. Everything else is planned so that it either corresponds to the time of the stop repair, or at least does not lengthen it. This means that these works must take place in parallel.
All this until now has been done like this: people in SAP create orders within a year that are marked as requiring stop repair. When the time comes, all orders from SAP are uploaded to the so-called “defective list”, on the basis of which mechanics develop a schedule for stop repairs. These are hundreds of lines in Excel, from which you then need to understand the list of necessary work, how much time and people will need it, build logic in time: what will be repaired for what. At all SIBUR enterprises this is done almost the same way - by hand in Excel. Only one company, Sibur-Khimprom, learned how to do this in the Primavera planning service. For us, it is extremely inconvenient in terms of interface and user scripts.
Of course, we looked away from other services, such as MS Project. But their functionality was either insufficient for us, or a lot of time and, accordingly, money would have to be spent on training. Therefore, we decided to develop our own product.
When we started, the picture in SIBUR was like this: everyone is trying to plan a serious project in Excel tables. All this is printed out, signatures of interested persons approving the schedule are put. Further, during a stop repair, people gather in planning meetings and are grouped into headquarters, where the Excel file is displayed on the screen, and the percentages of completing tasks are set in it.
Numerous and regular meetings of this kind are needed to bring together and update information. The representative of the contractor tells what has been done, what are the problems, and the representative of the customer notes everything in a paper document. Then another person collects information from each responsible person, consolidates it and prepares a centralized report. It’s all complicated and long, people stay at work until night.
We thought that the management of any projects is based on basic things: planning processes and transparency of what happens at any given moment in time. To ensure transparency, it is necessary during the repair to give the system up-to-date data on what is happening. We studied production processes in detail, understood how stop repair works, and proposed a structure where you can schedule. At first, we decided not to break the existing process and not get into people's scripts. Who used to plan in Excel - let them plan. Whoever learned at Primavera, let him work there.
Initially, our product was a visualization system for the graphs that they make. We developed an application for iOS, Android and a web browser version. The schedule is loaded into the service along with the responsible, executors and supervisors - three main roles during the stop repair. This is an important point, so I will dwell on it in more detail and show how everything works with an example.
There is a task to repair the pump.
The task has an executor - this is the foreman of the contracting organization, which repairs a particular object.
Responsible - he is responsible for ensuring that everything is prepared for repair, he must hand over the object for repair and then accept it, confirming that the contractor has completed the work in full and can proceed with other tasks. As a rule, this is done by the installation mechanic.
Supervisors are the top management of the enterprise, people who want to constantly see the compliance of the work with the schedule.
Responsible persons and performers have access both to the application and to the web version. The contractor sees the tasks that are assigned to him for today, as well as for the entire stop repair. The performer has a sequence of these tasks. When starting work, he must press the corresponding button, add to the program the number of people who are working on this task. It is important for management to know whether the number of people working on this task matches the number that they have planned. The contractor presses the button and the work has begun. The application monitors the duration of the process. In the event that the deadline is passed, and the contractor did not press the shutdown button, notifications of delay are sent to the responsible person. So the person in charge goes and looks at what happened.
If everything is fine and at the set time, the contractor completes the work, he clicks the “Submit Report” button and writes that he completed the work 100%. Then the responsible person also receives a notification that everything is done, you need to go and see the result. This is how the role model works.
People may not keep in mind everything that happens on the site entrusted to them, they see a schedule for every day and receive notifications about the process.
We also provided the opportunity to work with tasks that last more than one day. This works the same way as with small tasks, only at the end of each day you need to make reports in the program: for example, today the work is 50% completed. The responsible person receives a notification and must verify that this information is true. If not, he rejects the report and forces the contractor to put another number.
As for the web version, its functionality is slightly different; it is intended more for controllers - enterprise management. We realized that people are accustomed to perceiving information about progress on all works in Gantt charts. They see the plan facts, relationships, statistics on the mobilization of human resources, how many people we wanted to see at the plant during the repair, and how many works after the fact. And, accordingly, for all production installations, the controller can see the progress of work, quickly see the lag from the schedule.
During a stop repair, hidden additional work always appears that cannot be ignored. For example, when disassembling equipment, there is a breakdown in the part that is not visible in the assembled state of the unit. These tasks are also included in the schedule, the decision is made that we also perform hidden work during the stop repair. Everything is entered into the program. If this additional work affects the duration of the entire stop repair, the program will automatically postpone all other tasks for the time it takes to complete this hidden work. The same is true in the opposite case - if some tasks are completed faster than planned, the schedule is optimized.
For such cases, the team and I designed a serious messaging system and push notifications to warn people who are starting to work that they can do this sooner or later. And here an interesting moment was revealed. We pretty much went too far with these notifications.
The fact is that we brought there a “fourth-level schedule” - a large, detailed plan for all stop repairs. For our purposes, it turned out to be too detailed. It turned out that users received notifications about every little thing, which may be insignificant for the process as a whole. After all, when a person works without an application, he does not look at the work schedule every day. He just knows: in order to repair a conditional pump, you need to perform many operations (disassemble it, clean it, replace the units, assemble, check and so on). And the person who checks how the contractor works does not need to control the passage of each of these stages. It is enough to look at the result of the work as a whole and on the compliance with the stated deadlines.
That is, if we proceed to notifications, then the controller should learn about two events: the start of repair and the completion of repair. Therefore, we adjusted the application on the go. To begin with, they asked to change the schedules and enlarge them. Then they abandoned some minor events and everything began to work more smoothly, the user began to be less distracted by notifications.
When we finalized the application, we got a service that allows us to constantly have up-to-date information on the enterprise: what is being repaired, at what stage of the process and when is the deadline. This allows you to plan work and prepare a schedule. Essentially, this stop repair project management system is an advanced task manager.
Initially, we declared the main metric to reduce the time of stop repair. It’s clear how to evaluate this in terms of money: you know how much an hour or a day of production downtime costs. Therefore, we set ourselves the goal of accelerating the holding of repair work. Now we see that analytics is also important - an assessment of what happens during a stop repair, to the smallest detail. If we log the user's actions, how and when he accepted the work, what comments he wrote, what went wrong, how the coordination goes, we see the formation of hidden defects, understand who works, then you can analyze and understand a lot about production processes. Just for their assessment, we have a “Production Efficiency Function”. After each repair, a certain amount of data is collected: how much money was spent, how much was planned, how quickly we got out of the repair.
Of course, we envisage further development of the project. So far this is only the first step in collecting statistics on stop repairs. We want to collect enough data so that we can work with it and draw more conclusions. For example, we need to repair the pump. This is done by X people and it takes Y time. Accordingly, all subsequent planning of any repair can already be based on this model. We will be able to plan work based on the fact that there is already an analyst confirmed by the data, which means that we do not overestimate or underestimate expectations in terms of time.
Our application can be used not only for production. This may be the management of capital construction, any other areas where a similar approach to work planning is applied.
A group of people both inside SIBUR and contractors worked on the project. The development of the server side and the front-end was entirely on the contractor, we within the team were engaged in the design of the application logic and the interface. The consultants included the manager of the repair, the mechanic who worked directly on the schedules, the chief engineer who monitors the process, and the director of the enterprise.
Everything about everything (research, piloting, interfaces and development) took six months.
In the near future - several key updates. While there are problems with the calculation of physical volumes within the framework of a task, for example, for replaced fittings. Not only relative, but also absolute indicators are important for our colleagues at the enterprise: we need to understand how much percent of the work has been completed, how many reinforcing bars of the conditional 1000 have already been replaced. Now this is not taken into account in the application’s work schedule. We will think how to implement this. So far, we can only talk about the progress of the work performed and the percentage of their completion, to fix situations of lagging or ahead of schedule.
It is possible (and we already have such an understanding), we will transfer the entire process of planning a stop repair to our project. Perhaps, at the same time, the entire development will move the house.
We will be glad to see new colleagues in the team: product owners, product designers, developers. The list of current vacancies at the link to hh.ru.
In SIBUR, “stop repairs” regularly take place. This is something like preventive maintenance, scheduled maintenance and repair, during which the entire plant or part of it is completely stopped. Such repairs are necessary to ensure the smooth operation of the enterprise in the future. But, it is clear that at this time the plant does not make money, so it is important to do everything as quickly as possible. For this you need to optimally plan and carry out work. So the idea came up to create your own mobile application for stop repairs, which would make the process of managing work more organized, minimize the loss of time. We’ll tell you how we did it, what happened in the end and what we are striving for now.
Why is all this necessary?
To begin, I will tell you what a stop repair is. This is a set of measures for the repair of a large number of plant equipment, which must be carried out at a certain period of time - for example, once a year, quarter or at other intervals. At this time, production stops, the contractor calls in at the plant, everything that is needed is repaired. It can last a week, several weeks, at Sibur-Khimprom, for example, the plant stopped for almost a month.
Such a large-scale repair of almost all equipment at the plant can be presented as a large project. He has preparatory operations when the plant gradually reduces power and stops. There is an active phase, when there is a replacement and maintenance of units, and the phase of the resumption of production. 10-11 months before the start of the repair work, all responsible persons begin to plan this procedure, order orders are created for the work that needs to be carried out. Thus, by the beginning of work, a large pool of tasks is accumulated that must be completed within the time allotted for repair. These tasks are often interrelated: without completing one, you cannot start another. For example, we cannot repair something in the pump, because we must first turn it off, remove equipment that interferes with the dismantling of this unit, and only then work with the pump. From these interconnections the term of the entire stop repair is built.
Stop repairs have a “critical path”. As a rule, from year to year at each enterprise there are constant operations, without which the plant cannot be started. It turns out that the critical path is the longest time that can be spent on stop repairs. Everything else is planned so that it either corresponds to the time of the stop repair, or at least does not lengthen it. This means that these works must take place in parallel.
How did everything happen before?
All this until now has been done like this: people in SAP create orders within a year that are marked as requiring stop repair. When the time comes, all orders from SAP are uploaded to the so-called “defective list”, on the basis of which mechanics develop a schedule for stop repairs. These are hundreds of lines in Excel, from which you then need to understand the list of necessary work, how much time and people will need it, build logic in time: what will be repaired for what. At all SIBUR enterprises this is done almost the same way - by hand in Excel. Only one company, Sibur-Khimprom, learned how to do this in the Primavera planning service. For us, it is extremely inconvenient in terms of interface and user scripts.
Of course, we looked away from other services, such as MS Project. But their functionality was either insufficient for us, or a lot of time and, accordingly, money would have to be spent on training. Therefore, we decided to develop our own product.
When we started, the picture in SIBUR was like this: everyone is trying to plan a serious project in Excel tables. All this is printed out, signatures of interested persons approving the schedule are put. Further, during a stop repair, people gather in planning meetings and are grouped into headquarters, where the Excel file is displayed on the screen, and the percentages of completing tasks are set in it.
Numerous and regular meetings of this kind are needed to bring together and update information. The representative of the contractor tells what has been done, what are the problems, and the representative of the customer notes everything in a paper document. Then another person collects information from each responsible person, consolidates it and prepares a centralized report. It’s all complicated and long, people stay at work until night.
First prototype
We thought that the management of any projects is based on basic things: planning processes and transparency of what happens at any given moment in time. To ensure transparency, it is necessary during the repair to give the system up-to-date data on what is happening. We studied production processes in detail, understood how stop repair works, and proposed a structure where you can schedule. At first, we decided not to break the existing process and not get into people's scripts. Who used to plan in Excel - let them plan. Whoever learned at Primavera, let him work there.
Initially, our product was a visualization system for the graphs that they make. We developed an application for iOS, Android and a web browser version. The schedule is loaded into the service along with the responsible, executors and supervisors - three main roles during the stop repair. This is an important point, so I will dwell on it in more detail and show how everything works with an example.
There is a task to repair the pump.
The task has an executor - this is the foreman of the contracting organization, which repairs a particular object.
Responsible - he is responsible for ensuring that everything is prepared for repair, he must hand over the object for repair and then accept it, confirming that the contractor has completed the work in full and can proceed with other tasks. As a rule, this is done by the installation mechanic.
Supervisors are the top management of the enterprise, people who want to constantly see the compliance of the work with the schedule.
Custom roles
Responsible persons and performers have access both to the application and to the web version. The contractor sees the tasks that are assigned to him for today, as well as for the entire stop repair. The performer has a sequence of these tasks. When starting work, he must press the corresponding button, add to the program the number of people who are working on this task. It is important for management to know whether the number of people working on this task matches the number that they have planned. The contractor presses the button and the work has begun. The application monitors the duration of the process. In the event that the deadline is passed, and the contractor did not press the shutdown button, notifications of delay are sent to the responsible person. So the person in charge goes and looks at what happened.
If everything is fine and at the set time, the contractor completes the work, he clicks the “Submit Report” button and writes that he completed the work 100%. Then the responsible person also receives a notification that everything is done, you need to go and see the result. This is how the role model works.
People may not keep in mind everything that happens on the site entrusted to them, they see a schedule for every day and receive notifications about the process.
We also provided the opportunity to work with tasks that last more than one day. This works the same way as with small tasks, only at the end of each day you need to make reports in the program: for example, today the work is 50% completed. The responsible person receives a notification and must verify that this information is true. If not, he rejects the report and forces the contractor to put another number.
As for the web version, its functionality is slightly different; it is intended more for controllers - enterprise management. We realized that people are accustomed to perceiving information about progress on all works in Gantt charts. They see the plan facts, relationships, statistics on the mobilization of human resources, how many people we wanted to see at the plant during the repair, and how many works after the fact. And, accordingly, for all production installations, the controller can see the progress of work, quickly see the lag from the schedule.
Unscheduled work
During a stop repair, hidden additional work always appears that cannot be ignored. For example, when disassembling equipment, there is a breakdown in the part that is not visible in the assembled state of the unit. These tasks are also included in the schedule, the decision is made that we also perform hidden work during the stop repair. Everything is entered into the program. If this additional work affects the duration of the entire stop repair, the program will automatically postpone all other tasks for the time it takes to complete this hidden work. The same is true in the opposite case - if some tasks are completed faster than planned, the schedule is optimized.
For such cases, the team and I designed a serious messaging system and push notifications to warn people who are starting to work that they can do this sooner or later. And here an interesting moment was revealed. We pretty much went too far with these notifications.
Where did we go wrong?
The fact is that we brought there a “fourth-level schedule” - a large, detailed plan for all stop repairs. For our purposes, it turned out to be too detailed. It turned out that users received notifications about every little thing, which may be insignificant for the process as a whole. After all, when a person works without an application, he does not look at the work schedule every day. He just knows: in order to repair a conditional pump, you need to perform many operations (disassemble it, clean it, replace the units, assemble, check and so on). And the person who checks how the contractor works does not need to control the passage of each of these stages. It is enough to look at the result of the work as a whole and on the compliance with the stated deadlines.
That is, if we proceed to notifications, then the controller should learn about two events: the start of repair and the completion of repair. Therefore, we adjusted the application on the go. To begin with, they asked to change the schedules and enlarge them. Then they abandoned some minor events and everything began to work more smoothly, the user began to be less distracted by notifications.
What is the result?
When we finalized the application, we got a service that allows us to constantly have up-to-date information on the enterprise: what is being repaired, at what stage of the process and when is the deadline. This allows you to plan work and prepare a schedule. Essentially, this stop repair project management system is an advanced task manager.
Initially, we declared the main metric to reduce the time of stop repair. It’s clear how to evaluate this in terms of money: you know how much an hour or a day of production downtime costs. Therefore, we set ourselves the goal of accelerating the holding of repair work. Now we see that analytics is also important - an assessment of what happens during a stop repair, to the smallest detail. If we log the user's actions, how and when he accepted the work, what comments he wrote, what went wrong, how the coordination goes, we see the formation of hidden defects, understand who works, then you can analyze and understand a lot about production processes. Just for their assessment, we have a “Production Efficiency Function”. After each repair, a certain amount of data is collected: how much money was spent, how much was planned, how quickly we got out of the repair.
Of course, we envisage further development of the project. So far this is only the first step in collecting statistics on stop repairs. We want to collect enough data so that we can work with it and draw more conclusions. For example, we need to repair the pump. This is done by X people and it takes Y time. Accordingly, all subsequent planning of any repair can already be based on this model. We will be able to plan work based on the fact that there is already an analyst confirmed by the data, which means that we do not overestimate or underestimate expectations in terms of time.
Our application can be used not only for production. This may be the management of capital construction, any other areas where a similar approach to work planning is applied.
Who worked on the project?
A group of people both inside SIBUR and contractors worked on the project. The development of the server side and the front-end was entirely on the contractor, we within the team were engaged in the design of the application logic and the interface. The consultants included the manager of the repair, the mechanic who worked directly on the schedules, the chief engineer who monitors the process, and the director of the enterprise.
Everything about everything (research, piloting, interfaces and development) took six months.
What is the future of the product?
In the near future - several key updates. While there are problems with the calculation of physical volumes within the framework of a task, for example, for replaced fittings. Not only relative, but also absolute indicators are important for our colleagues at the enterprise: we need to understand how much percent of the work has been completed, how many reinforcing bars of the conditional 1000 have already been replaced. Now this is not taken into account in the application’s work schedule. We will think how to implement this. So far, we can only talk about the progress of the work performed and the percentage of their completion, to fix situations of lagging or ahead of schedule.
It is possible (and we already have such an understanding), we will transfer the entire process of planning a stop repair to our project. Perhaps, at the same time, the entire development will move the house.
We will be glad to see new colleagues in the team: product owners, product designers, developers. The list of current vacancies at the link to hh.ru.
All Articles