And what came of it
Hello!
In production, it's essential to monitor product quality, both incoming from suppliers and that which we produce. For this, we often conduct sampling — specially trained staff take samplers and follow set instructions to collect samples, which are then sent to the laboratory for quality testing.
My name is Katya, I'm the product owner for one of the teams at SIBUR, and today I will talk about how we improved the lives (at least during working hours) of specialists who collect samples and other participants in this fascinating process. Below, I’ll discuss hypotheses and their testing, our approach to users of your digital product, and a bit about how everything is organized here.
Hypotheses
It’s worth starting by noting that our team is quite young; we have been working since September 2018 and one of our first challenges in digitalizing processes is production control. De facto, this is the verification of everything during the stage between the receipt of raw materials and the release of the final product from our facilities. We decided to tackle this issue step by step, starting with sampling. After all, to digitalize laboratory research on samples, someone has to first collect and bring those samples. Usually, this is done manually.
The initial hypotheses focused on moving away from paper and manual labor. Previously, the process looked like this: a person had to write on paper what they were preparing to collect in the sampler, self-identify (in other words, write their full name and the time of sample collection on paper), and stick this paper onto the test tube. Then, they would go to the platform, take a sample from several wagons, and return to the control room. In the control room, they had to re-enter the same data into the sampling report, which would accompany the sample to the laboratory. They also had to maintain a personal log to refer to in case they needed to check who collected a specific sample and when. Moreover, the chemist registering the sample in the laboratory had to transfer the notes from the papers into a special laboratory software (LIMS).
The problems are obvious. First, it takes too long, plus we observe duplication of the same operation. Second, the accuracy is low — the sampling time was partly estimated by eye, because it's one thing to write down an approximate sampling time on paper, and another to get to the wagon and start collecting samples; that will already be slightly different timing. For data analytics and process tracking, this is more important than it seems.
As you can see, there’s truly untapped potential for optimizing this process.
We had very little time, and we needed to act quickly, all within the corporate framework. Doing anything in the cloud during production isn't a great idea, as you’re dealing with a lot of data, some of which is commercial secrets or contains personal data. To create the prototype, we only needed the wagon number and the product name — these data were approved by the security team, and we got started.
My team currently consists of 2 external developers, 4 internal ones, a designer, a Scrum master, and a junior product manager. Here are the open positions we have at the moment. .
In a week, we built an admin panel with Django for the team and a simple mobile app for users. Then we spent another week refining and adjusting it, after which we handed it over to users, trained them, and started testing.
Prototype
It’s quite simple. There’s a web part that allows you to create a task for sample collection, and there’s a mobile app for employees, which shows everything clearly: go to that ramp and collect samples from that wagon. We initially placed QR codes on the sample collectors to avoid reinventing the wheel, because any serious tuning of the sampling device would have to be coordinated, but this was harmless; just stick a paper label and go to work. The employee only had to select the task in the app and scan the label, after which the system recorded that he (the specific employee) took samples from the wagon with that number at that exact time. Figuratively speaking, 'Ivan took a sample from wagon No. 5 at 13:44.' Upon returning to the control room, he simply had to print out the report with the same data and put his signature on it.
The old version of the admin panel
Creating a task in the new admin panel
For the girls in the lab, it has become easier at this stage — now they no longer need to decipher handwritten notes; they can simply scan the code and instantly understand what is in the sample collector.
And here we encountered a similar problem on the laboratory side. The girls have their own complex software, LIMS (Laboratory Information Management System), into which they had to manually enter everything from the received sampling reports. At this stage, our prototype did not solve their pain points at all.
Therefore, we decided to implement integration. An ideal scenario would be when all the components we developed for integrating these touchpoints, from sample collection to laboratory analysis, help eliminate paper completely. A web application will replace paper logs, and the sampling act will be filled out automatically using an electronic signature. Thanks to the prototype, we realized that the concept can be applied, and we moved on to developing the MVP.
Prototype of the previous version of the mobile application
MVP of the new mobile application
Fingers and gloves
Here we must also take into account the fact that working in production means it’s not +20 and a light breeze gently ruffling the fields of a straw hat, but sometimes -40 and a strong wind, making it undesirable to take off gloves just to tap on the touchscreen of an explosion-proof smartphone. Not at all. Even under the threat of filling out paper acts and wasting time. But at least you have your fingers.
Therefore, we slightly changed the workflow for the team — first, we programmed a series of actions on the hardware side buttons of the smartphone, which can be easily pressed while wearing gloves, and second, we improved the gloves themselves: our colleagues who provide personnel with personal protective equipment found us gloves that meet all necessary standards and also allow for use with touchscreens.
Here's a little bit about them in the video.
We also received feedback about the labels on the sample collectors. The thing is, sample collectors come in various types — plastic, glass, curved shapes, in general, a variety. It is inconvenient to stick a QR code on curved ones; the paper bends and may not scan as well as you’d like. Plus, it scans worse under tape, and if you wrap it tightly in tape, it may not scan at all.
We replaced all of this with NFC tags. This is much more convenient, but we haven't made it entirely user-friendly yet — we want to switch to flexible NFC tags, but we're currently stuck on safety compliance issues, which is why our tags are large, but explosion-proof. However, we will work on this with our colleagues from industrial safety, so there's still progress to be made.
More about the tags
LIMS as a system already includes barcode printing for such needs, but it has one significant disadvantage — they are single-use. That is, you stick it on a sample collector, finish your work, and then you have to tear it off, throw it away, and stick a new one on. Firstly, it’s not as environmentally friendly as it seems (it uses much more paper than one might think). Secondly, it takes time. Our tags are reusable, with rewritable features. When a sample collector is sent to the lab, it's enough to scan it. Then the sample collector is carefully cleaned and returned for the next samples. The production staff scans it again and records the new data on the tag.
This approach has also proven quite successful, and we have thoroughly tested it and tried to iron out all the complex issues. As a result, we are now at the MVP development stage in the industrial environment, with full integration into corporate systems and accounts. This is aided by the fact that much was migrated to microservices at one point, so there have been no problems regarding account management. Unlike LIMS — no one did anything for it. We had some rough edges in integrating it into our development environment, but we managed to resolve them, and we will be launching everything in summer.
Checks and Training
Here is a case that arose from a rather mundane problem — it was once suggested that sometimes sample testing shows results that differ from normal because the samples are simply collected poorly. The hypotheses about what was happening were as follows.
- Samples are simply collected incorrectly due to staff not adhering to the technological process.
- Many newcomers arrive in production, and they may not be fully briefed, hence the incorrect sampling.
We criticized the first option immediately, but we decided to check it just in case.
Here, I want to highlight an important point. We actively teach the company to restructure its way of thinking towards a digital product development culture. Previously, the mindset was that there is a vendor, and it is only necessary to write a clear technical specification with solutions once, hand it over, and let them do everything. This meant that people de facto relied immediately on potential ready-made solutions, which needed to be incorporated into the technical specification as givens, instead of starting from the existing problems they wanted to solve.
We are now shifting the focus from such an "idea generator" to formulating clear problems.
Therefore, upon hearing this description of the problems, we started brainstorming ways to test these hypotheses.
The easiest way to check the quality of work of the sample selectors is through video surveillance. It is clear that to verify another hypothesis, equipping the entire ramp with explosion-proof cameras is not so simple; the estimated costs immediately ran into millions of rubles, and we abandoned that. It was decided to reach out to our colleagues in Industry 4.0, who are currently piloting the use of the only explosion-proof Wi-Fi camera in Russia. Descriptions suggest it should resemble something the size of an electric kettle, but in fact, this device is no larger than a marker for boards.
We took this little device to the ramp and explained in as much detail as possible to the staff what we were offering, for how long, and for what purpose. It was important to make it clear right away that this is indeed for experimental verification and is temporary.
For a couple of weeks, people worked in their usual mode, no violations were detected, and we decided to test the second hypothesis.
For fast and detailed training, we chose the format of video instructions, suspecting that an adequate video tutorial, which takes a few minutes to watch, would be much clearer in demonstrating everything than a 15-page job manual. Moreover, they already had such an instruction.
It was said — it was done. I went to Tobolsk, observed how they take samples, and it turned out that the sample collection mechanics have been the same for the last 20 years. Yes, it is quite a routine process that can be automated with frequent repetition, but that does not mean it cannot be simplified and automated. However, the initial idea of creating a video instruction for the staff was rejected, with the argument that there’s no need to shoot these videos since we’ve been doing the same thing for 20 years.
We coordinated with our PR team, sent the most suitable guy for the video shoot, handed him a shiny wrench, and recorded the sampling process under ideal conditions. It resulted in an exemplary version. I even provided the voiceover for clarity.
We gathered employees from eight shifts, organized a cinematic screening, and asked how it was. It turned out to be like watching the first 'Avengers' for the third time: cool, beautiful, but nothing new. They said, 'We’ve been doing this all along.'
Then we directly asked the guys what they disliked about the process and what caused them inconveniences. And here, the dam broke — after such an improvised design session with production workers, we presented management with quite a substantial backlog aimed at changing the operational processes. Because it was necessary to first make a number of adjustments to the processes themselves, and only then create a digital product that would be correctly perceived under the new conditions.
Seriously, if a person has a large cumbersome sampler without a handle, they have to carry it with both hands, and you say, 'Here, Ivan, take the phone, you’ll scan it there' — that isn’t very inspiring.
The people for whom you are creating a product need to understand that you are listening to them, and not just preparing to roll out some trendy thing that they do not need at the moment.
On processes and effects
If you are creating a digital product and your process is flawed, you shouldn't implement the product just yet; you need to fix that process first. Our focus right now is to fine-tune such processes. During design sessions, we continue to gather a backlog not only for the digital product but also for global operational improvements, which we sometimes manage to implement even before the product itself. This alone yields great results.
It's also important that part of the team is directly at the enterprise. We have people from various departments who have decided to build a career in digital technologies and help us with product implementation and process understanding. Such operational changes are suggested by them.
For the employees, it's easier too; they realize that we're not just gathered here to sit around but actually to discuss how to eliminate unnecessary paperwork, or to consolidate 16 essential documents into 1 (and then also eliminate that), how to create digital signatures, optimize interactions with government bodies, and more.
And if we talk about the process itself, we've found even more.
Sampling takes about 3 hours on average. In this process, there are people acting as coordinators, and for those three hours, their phones are constantly ringing as they relay statuses—where to send the vehicle, how to distribute orders among laboratories, and similar tasks. This happens on the laboratory side.
On the production side, there is a similar person with a similarly busy phone. We've decided that it would be great to create a visual dashboard for them that helps monitor the status of the process, from sampling requests to issuing results in the laboratory, with necessary notifications and more. Later, we plan to connect this with transport orders and optimize the laboratories' operations—distributing tasks among employees.
As a result, through digital and operational changes, we can save about 2 hours of labor and 1 hour of downtime for each sampling, compared to how things were before we arrived. And this is just for one sampling; there can be several in a day.
In terms of effects, about a quarter of sample collections are now conducted this way. It turns out that we free up around 11 staff units for more valuable work. And the reduction in wagon-hours (as well as in composition-hours) opens up opportunities for monetization.
Of course, not everyone fully understands what the digital team is doing here and why they are engaged in operational improvements. People still harbor a somewhat inaccurate perception, thinking that developers came in, created an application in a day, and solved all the problems. Operational staff, understandably, welcomes such an approach, albeit with a bit of skepticism.
But it’s important to remember that there are no magic boxes. It's all about work, research, hypotheses, and validations.
Source: habr.com
