And what came of it
Hi!
In production, it is important to monitor the quality of products, both those coming from suppliers and those that we issue at the output. To do this, we often conduct sampling - specially trained employees take samplers and, according to the available instructions, collect samples, which are then transferred to the laboratory, where they are checked for quality.
My name is Katya, I am a product owner of one of the teams at SIBUR, and today I will tell you how we improved the life (at least during working hours) of sampling specialists and other participants in this exciting process. Under the cut - about hypotheses and their testing, about the attitude towards users of your digital product, and a little about how everything works for us.
Hypotheses
Here it is worth starting with the fact that our team is quite young, we have been working since September 2018, and one of our first challenges as part of the digitalization of processes is production control. De facto, this is a check of everything at the stage between the receipt of raw materials to us and until the end product leaves our production facilities. We decided to eat the elephant piecemeal and started with sampling. After all, in order to put laboratory tests of samples on a digital footing, these samples must first be collected and brought by someone. Usually hands and feet.
The first hypotheses concerned the departure from paper and manual labor. Previously, the process looked like this - a person had to write on a piece of paper what exactly he was preparing to collect in the sampler, identify himself (read - write his name and time of sampling on a piece of paper), stick this piece of paper on the test tube. Then go to the overpass, take a sample from several cars and return to the control room. In the control room, a person had to fill in the same data in the act of sampling, along with which the sample was sent to the laboratory, in the second round. And then write a journal just for yourself, so that if something happens, you can check on it who and when took a particular sample. And the chemist, who registered the sample in the laboratory, then transferred the notes from the pieces of paper to special laboratory software (LIMS).
The problems are obvious. Firstly, it is long, plus we are seeing duplication of the same operation. Secondly, low accuracy - the sampling time was written partly by eye, because it’s one thing that you wrote the approximate sampling time on paper, another thing is that by the time you get to the car and start collecting samples, it will be a slightly different time. For data analytics and process tracking, this is more important than it sounds.
As you can see, the field for process optimization is truly unplowed.
We had little time, and we needed to do everything quickly, and within the corporate circuit. Doing things in the cloud in production is a bit of a chore because you work with a lot of data, some of which is trade secret or contains personal data. To create a prototype, we only needed the number of the car and the name of the product - these data were approved by the security officers, and we started.
My team now has 2 external developers, 4 internal developers, a designer, a scrum master, and a junior product developer. Here, by the way, what we have now .
In a week, we built an admin panel for the team and a simple mobile application for users on Django. Then they finished and adjusted it for another week, and then gave it to users, trained them and started testing.
Prototype
Everything is simple here. There is a web part that allows you to create a task for sampling, and there is a mobile application for employees, where everything is clear, they say, go to that overpass and collect samples from that car. We first stuck QR codes on the samplers so as not to reinvent the wheel, because we would have to coordinate a more serious tuning of the sampler, but here everything is harmless, I stuck a piece of paper and went to work. The employee only had to select a task in the application and scan the tag, after which the system recorded data that he (a specific employee) took samples from a car with such and such a number at such and such an exact time. Figuratively speaking, "Ivan took a sample from car No. 5 at 13.44." Upon returning to the control room, he only had to print out a ready-made act with the same data and simply put his signature on it.
Old version of the admin
Creating a task in the new admin panel
It has also become easier for girls in the laboratory at this stage - now you can not make out the inscriptions on a piece of paper, but simply scan the code and immediately understand what exactly is in the sampler.
And then we stumbled upon a similar problem already on the side of the laboratory. The girls here also have their own complex software, LIMS (Laboratory Information Management System), in which they had to interrupt everything from the received sampling certificates with pens. And at this stage, our prototype did not solve their pains in any way.
Therefore, we decided to make an integration. The ideal situation is when all the filling that we have done to integrate these opposite ends, from sampling to laboratory analysis, will help to get rid of paper altogether. The web application will replace paper journals, the selection act will be filled in automatically, using an electronic signature. Thanks to the prototype, we realized that the concept can be applied, and we started developing the MVP.
Prototype of the previous version of the mobile application
MVP of a new mobile application
Fingers and gloves
Here we must also take into account the fact that work in production is not +20 and a light breeze fluttering the brim of a straw hat, but at times -40 and an outright wind, where you don’t want to take off your gloves to tap on the touch screen of an explosion-proof smartphone. No way. Even under the threat of filling out paper acts and wasting time. But you have your fingers.
Therefore, we slightly changed the work process for the guys - firstly, we sewed a number of actions on the hardware side buttons of the smartphone, which are perfectly pressed in gloves, and secondly, we upgraded the gloves themselves: our colleagues who are engaged in providing personnel with personal protective equipment found us gloves that meet all the necessary standards, while also with the ability to work with touch screens.
Here is a little video about them.
Another feedback came about the marks themselves on the samplers. The thing is that samplers are different - plastic, glass, curved, in general, in assortment. It is inconvenient to stick a QR code on curved ones, the paper bends and may not be scanned as well as you would like. Plus, it also scans worse under tape, and if you wrap the tape with all your heart, it doesn’t scan at all.
We have replaced all this with NFC tags. This is much more convenient, but we have not yet made it very convenient - we want to switch to flexible NFC tags, but so far we have come up against an agreement on explosion protection, so our tags are large, but explosion-proof. But we will work it out with colleagues from industrial security, so there is still more to come.
More about tags
LIMS as a system itself provides for printing barcodes for such needs, but they have one significant disadvantage - they are disposable. That is, I stuck it on the sampler, finished with the work, and I have to tear it off, throw it away, and then stick a new one. Firstly, it’s not that all this is environmentally friendly (there is much more paper than it seems at first glance). Second, it's long. Our tags are reusable, overwritten. When a sampler is sent to the laboratory, it is enough to scan it. Then the sampler is carefully cleaned and returned back to take the next samples. The production employee scans it again and writes new data to the tag.
This approach also proved to be quite successful, and we thoroughly tested it and tried to work out all the difficult places. As a result, now we are at the stage of developing an MVP in an industrial circuit with full integration into corporate systems and accounts. It helps that at one time a lot was transferred to microservices, so there were no problems in terms of working with accounts. Unlike the same LIMS, no one did anything for it. Here we had certain rough edges in order to integrate it normally with our development environment, but we mastered them and in the summer we will launch everything into battle.
Checks and training
But what case was born out of a rather ordinary problem - once there was an assumption that sometimes checking samples shows results that are different from the norm, because samples are simply taken badly. The hypotheses for what happened were as follows.
- Samples are simply taken incorrectly due to non-compliance by field staff with the process.
- Many newcomers come to production, they may not be able to explain everything in detail, hence the not quite correct sampling.
We criticized the first option at the start, but just in case, we also began to check it.
Here I will note one important thing. We are actively teaching the company to shift the way of thinking towards a culture of digital product development. Previously, the thinking model was such that there is a vendor, he only needs to write a clear TOR with solutions once, give it away, and let him do everything. That is, it turned out that people de facto started immediately from potential ready-made solutions that had to be entered into the TOR as a given, instead of proceeding from the existing problems that they wanted to solve.
And now we are shifting the focus from such a “generator of ideas” to the formulation of clear problems.
So when we heard about these problems, we started thinking of ways to test these hypotheses.
The easiest way to check the quality of the samplers is by using video surveillance. It is clear that in order to test another hypothesis, it is not so easy to take and equip the entire overpass with explosion-proof chambers, the knee calculation immediately gave us many millions of rubles, and we refused it. It was decided to go to our guys from industry 4.0, who are now piloting the use of the only explosion-proof wifi camera in the Russian Federation. It's supposed to look like something about the size of an electric kettle, but it's actually no bigger than a whiteboard marker.
We took this baby and came to the overpass, telling the employees in as much detail as possible what we are giving here, for how long and for what exactly. It was important to immediately make it clear that this was actually to test the experiment and temporary.
For a couple of weeks, people worked as usual, no violations were identified, and we decided to test the second hypothesis.
For quick and detailed training, we chose the format of video instructions, suspecting that an adequate video tutorial, which will take you several minutes to watch, will show everything and everything much more clearly than a 15-sheet job description. Moreover, they already had such instructions.
No sooner said than done. I went to Tobolsk, looked at how they take samples, and it turned out that the sampling mechanics there have been the same for the last 20 years. Yes, this is a rather routine process that can be brought to automaticity with frequent repetition, but this does not mean that it cannot be automated and simplified. But initially the idea with a video instruction was rejected by the staff, they say, why shoot these videos if we have been doing the same thing here for 20 years.
Agreed with our PR, outfitted the right guy for the video shoot, gave him a great shiny wrench, and recorded the sampling process under ideal conditions. There was such an exemplary version. I then also voiced the video for clarity.
We rounded up employees from eight shifts, gave them a cinematic screening, and asked them how it was. It turned out that it was like watching the first Avengers for the third time: cool, beautiful, but nothing new. Like, we've been doing this all the time.
Then we asked the guys directly what they don’t like about this process and what causes inconvenience. And here the dam has already burst - after such an impromptu design session with production workers, we brought a fairly large-scale backlog to the management, aimed at changing the operational processes. Because it was necessary first to make a number of changes to the processes themselves, and then to make a digital product that would be correctly perceived in the new conditions.
Well, seriously, if a person has a large, uncomfortable sampler without a handle, you have to carry it with both hands, and you say: “You, Vanya, have a mobile phone, you can scan it there” - this is somehow not very inspiring.
The people you're making a product for need to understand that you're listening to them, and not just getting ready to roll out some fancy thing that they don't need right now.
About processes and effects
If you are making a digital product and you have a crooked process, you don’t need to implement the product yet, you need to fix this process in the first place. The concern of our direction now is to tune such processes; within the framework of design sessions, we continue to collect the backlog not only for the digital product, but also for global operational improvements, which sometimes even turn out to be implemented before the product itself. And this in itself gives a great effect.
It is also important that part of the team is located directly at the enterprise. We have guys from different departments who have decided to build a career in digital and help us with the implementation of products and learning processes. It is they who suggest such operational changes.
Yes, and it’s easier for employees, they understand that we are not just going to sit here, but we will actually discuss how they can cancel unnecessary pieces of paper, or make 16 paper out of 1 necessary papers for the process (and then cancel it too), how to make an EDS and optimize work with government agencies, and so on.
And if we talk about the process itself, we found something else.
Sampling takes an average of 3 hours. And in this process, there are people who act as a coordinator, and during these three hours their phone rings and they constantly report statuses - where to send the car, how to distribute orders among laboratories, and the like. And this is on the side of the laboratory.
And on the side of production sits the same person with the same red-hot phone. And we decided that it would be nice to make them a visual dashboard that will help them see the status of the process, from requests for sampling to the issuance of results in the laboratory, with the necessary notifications and so on. Then we are thinking of connecting this with ordering transport and optimizing the activities of the laboratories themselves - distributing work among employees.
As a result, for one sampling, together from digital and operational changes, we will be able to save about 2 hours of human labor and an hour of downtime of the train, compared to how we worked before us. And this is only for one selection, there may be several per day.
Of the effects - now about a quarter of sampling is carried out this way. It turned out that we are freeing up about 11 units of personnel for more useful work. And the reduction of car-hours (and train-hours) opens up opportunities for monetization.
Of course, not everyone fully understands what the digital team forgot here and why it is engaged in operational improvements, people still have this not entirely correct perception when you think that the developers came, made an application for you in a day and solved all the problems. But the operational staff, of course, is happy with this approach, albeit with a little skepticism.
But it is important to remember that there are no magic boxes. It's all work, research, hypotheses and tests.
Source: habr.com