Hoe we monsters namen bij SIBUR op nieuwe rails

En wat is daaruit gekomen

Hallo!

In de productie is het belangrijk om de kwaliteit van zowel de binnenkomende producten van leveranciers als de producten die we afleveren, in de gaten te houden. Hiervoor worden er vaak steekproeven genomen — speciaal opgeleide medewerkers nemen monsters en verzamelen ze volgens de beschikbare instructies, die vervolgens naar het laboratorium worden gestuurd voor kwaliteitscontrole.

Mijn naam is Katya, ik ben producteigenaar van een van de teams bij SIBUR, en vandaag zal ik vertellen hoe we het leven (al met al in werktijd) van de medewerkers die monsters nemen en andere deelnemers aan dit fascinerende proces hebben verbeterd. In de cat zullen we het hebben over hypothesen en hun verificatie, over de benadering van gebruikers van jouw digitale product en een beetje over hoe wij alles geregeld hebben.

Hypothesen

Hiermee moeten we beginnen met het feit dat ons team vrij jong is, we werken sinds september 2018, en een van onze eerste uitdagingen in het kader van de digitalisering van processen is machinecontrole. De facto is dit de controle van alles in de fase tussen de ontvangst van de grondstoffen en de uitgifte van het eindproduct uit onze productiefaciliteiten. We besloten de olifant in stukken te eten en begonnen met het nemen van monsters. Want voordat we laboratoriumonderzoeken op deze monsters op digitale rails kunnen zetten, moet iemand deze monsters eerst verzamelen en brengen. Gewoonlijk met de handen en benen.

De eerste hypothesen hadden betrekking op het afstappen van papier en handmatig werk. Vroeger liep het proces als volgt: iemand moest op papier schrijven wat hij van plan was te verzamelen in de monsternamecontainer, zichzelf identificeren (lees: zijn naam, achternaam en de tijd van monstername op papier schrijven), dit papier op de buis plakken. Vervolgens moest hij naar de laaddek, een monster uit verschillende wagons nemen en teruggaan naar de bedieningsruimte. In de bedieningsruimte moest de persoon deze gegevens nogmaals invoeren in het acten van monstername, samen met het monster dat naar het laboratorium werd gestuurd. En daarna moest hij nog een logboek bijhouden speciaal voor zichzelf, zodat hij in geval van iets kon nagaan wie en wanneer een specifiek monster had genomen. De chemicus die het monster in het laboratorium registreerde, droeg de aantekeningen van de papiertjes vervolgens over naar speciale laboratoriumsoftware (LIMS).

De problemen zijn duidelijk. Ten eerste duurt het lang, plus we zien duplicatie van dezelfde operatie. Ten tweede is de nauwkeurigheid laag — de tijd voor monstername werd deels op de gevoel afgeschat, omdat het iets anders is om een schatting op papier te zetten, dan wanneer je bij de wagon aankomt en begint met het verzamelen van monsters; dat zal al wat andere tijd zijn. Voor data-analyse en procesmonitoring is dit belangrijker dan het lijkt.

Zoals u kunt zien, is er een enorm potentieel voor procesoptimalisatie.

We hadden weinig tijd en moesten alles snel doen, binnen de bedrijfsstructuur. Iets in de cloud doen tijdens productie is niet ideaal, omdat je met veel gegevens werkt, waarvan een deel commercieel wezenlijk of persoonlijke gegevens bevat. Voor het maken van een prototype hadden we alleen het wagonnummer en de productnaam nodig — deze gegevens werden goedgekeurd door de beveiligingsafdeling, en we zijn begonnen.

In mijn team zijn er nu 2 externe ontwikkelaars, 4 interne, een ontwerper, een scrum-master en een junior productmanager. Dit zijn trouwens de vacatures die we momenteel hebben. In het algemeen zijn er vacatures..

In een week hebben we met Django een admin panel voor het team en een eenvoudige mobiele applicatie voor de gebruikers gebouwd. Daarna hebben we nog een week aanpassingen gedaan en ingesteld, en vervolgens hebben we deze aan de gebruikers overgedragen, hen opgeleid en zijn we begonnen met testen.

Prototype

Hier is alles eenvoudig. Er is een webgedeelte dat het mogelijk maakt om een taak voor monstername te creëren, en er is een mobiele applicatie voor medewerkers waarin alles duidelijk is, bijvoorbeeld: ga naar die weegbrug en verzamel monsters uit die wagon. We hebben aanvankelijk QR-codes op de monstername-instrumenten geplakt, zodat we het wiel niet opnieuw hoefden uit te vinden, want voor meer serieuze aanpassingen aan het monstername-instrument zouden we goedkeuring moeten krijgen, en dit was onschuldig — plak een papiernetje en ga aan het werk. De werknemer hoefde alleen maar de taak in de applicatie te selecteren en de code te scannen, waarna de gegevens in het systeem werden opgeslagen over dat hij (de specifieke medewerker) op een bepaald moment monsters uit de wagon met een bepaald nummer heeft genomen. Figuratief, "Ivan nam een monster uit wagon nr. 5 om 13.44 uur." Bij terugkomst in de controlekamer hoefde hij alleen maar het al opgestelde verslag met dezelfde gegevens af te drukken en zijn handtekening te zetten.

De oude versie van het admin panel

Taak aanmaken in het nieuwe admin panel

Voor de meisjes in het laboratorium is het op dit moment ook makkelijker geworden - nu kunnen ze de teksten op papier overslaan en gewoon de code scannen om meteen te begrijpen wat er in de monsterhouder zit.

En hier stuitten we op een soortgelijk probleem aan de laboratoriumzijde. Ook hier hadden de dames te maken met hun eigen complexe software, LIMS (Laboratory Information Management System), waarin ze alles handmatig moesten invoeren vanuit de ontvangen monsternameverslagen. En op dit moment loste ons prototype hun problemen helemaal niet op.

Daarom besloten we tot integratie. De ideale situatie lijkt ons wanneer alle software die we hebben ontwikkeld voor de integratie van deze twee processen, van monstername tot laboratoriumanalyse, helpt om helemaal van papier af te komen. De webapplicatie zal de papieren logboeken vervangen, het monsternameformulier wordt automatisch ingevuld met een digitale handtekening. Dankzij het prototype beseften we dat het concept toepasbaar is, en we zijn begonnen met de ontwikkeling van het MVP.

Prototype van de vorige versie van de mobiele applicatie

MVP van de nieuwe mobiele applicatie

Vingers en handschoenen

Hier moet ook rekening worden gehouden met het feit dat werken in de productie niet +20 graden en een lichte bries is, maar soms -40 en een overtuigende kou, waardoor je helemaal geen zin hebt om je handschoenen uit te doen om op het touchscreen van een explosieveilige smartphone te tikken. Geen enkele. Zelfs niet onder de dreiging van het invullen van papieren formulieren en tijdverlies. Maar je hebt tenminste wel je vingers bij je.

Daarom hebben we het werkproces van de jongens een beetje aangepast - ten eerste hebben we een aantal acties op de hardware-knoppen van de smartphone ingebouwd, die perfect te gebruiken zijn met handschoenen, en ten tweede hebben we de handschoenen zelf verbeterd: onze collega’s die zorgen voor de veiligheidsmiddelen voor het personeel hebben handschoenen gevonden die aan alle benodigde standaarden voldoen, en ze zijn ook geschikt voor gebruik met touchscreens.

Hier is een stukje in de video over hen.

We kregen ook feedback over de labels op de monsterhouders. Het probleem is dat monsterhouders in verschillende soorten komen - plastic, glas, gebogen vormen, kortom, in allerlei varianten. Het is lastig om een QR-code op gebogen houders te plakken; het papier buigt en kan niet zo goed worden gescand als je zou willen. Bovendien worden ze onder tape ook slechter gescand, en als je er veel tape omheen doet, wordt het helemaal niet gescand.

We hebben alles vervangen door NFC-tags. Dit is veel handiger, maar we hebben het nog niet helemaal gebruiksvriendelijk gemaakt — we willen overstappen op flexibele NFC-tags, maar zitten voorlopig vast in de overeenstemming over explosieveiligheid, daarom zijn onze tags groot, maar wel explosieveilig. Maar we gaan hier met onze collega's van de industriële veiligheid aan werken, dus er komt nog meer aan.

Meer over tags

LIMS als systeem voorziet wel in het afdrukken van barcodes voor dergelijke behoeften, maar het heeft één groot nadeel — ze zijn wegwerp. Je plakt het op een monsterafname, je bent klaar met je werk en je moet het eraf halen, weggooien en dan een nieuwe plakken. Ten eerste, het is niet echt milieuvriendelijk (er gaat veel meer papier verloren dan het op het eerste gezicht lijkt). Ten tweede, het kost tijd. Onze tags zijn herbruikbaar, met herlezing. Wanneer een monsterafname naar het laboratorium wordt gestuurd, hoeft deze alleen maar gescand te worden. Vervolgens wordt de monsterafname zorgvuldig schoongemaakt en teruggestuurd voor het nemen van de volgende monsters. Een medewerker in de productie scant het opnieuw en registreert nieuwe gegevens op de tag.

Deze aanpak heeft ook bewezen succesvol te zijn, en we hebben deze grondig getest en geprobeerd alle moeilijke punten te verhelpen. Uiteindelijk zijn we nu in de fase van het ontwikkelen van een MVP in de industriële omgeving met volledige integratie in de bedrijfsystemen en accounts. Het helpt dat veel destijds naar microservices is overgezet, daarom zijn er geen problemen geweest met het werken met accounts. In tegenstelling tot hetzelfde LIMS — daarvoor deed niemand iets. Hier hadden we bepaalde hobbels bij het normaal integreren met onze ontwikkelomgeving, maar we hebben deze overwonnen en in de zomer gaan we alles in gebruik nemen.

Controles en training

Maar hier is een geval dat voortkwam uit een vrij alledaags probleem — er was een keer de veronderstelling dat soms monsters een afwijkend resultaat vertonen omdat de monsters simpelweg slecht worden genomen. De hypothesen over wat er aan de hand was, waren als volgt.

1. Monsters worden gewoon verkeerd afgenomen door het niet naleven van de technologische processen door de medewerkers op de locatie.
2. Er komen veel nieuwelingen in de productie, en niet alles kan hen uitgebreid worden uitgelegd, vandaar de niet helemaal correcte monsterafname.

De eerste optie hebben we direct bekritiseerd, maar we zijn ook gaan controleren voor de zekerheid.

Hier vermeld ik één belangrijke zaak. We leren bedrijven actief om hun denkwijze te herstructureren in de richting van een cultuur van digitale productontwikkeling. Voorheen was het denkkader zo dat er een leverancier is, die alleen een duidelijk technisch ontwerp met oplossingen moest opstellen en dit opleveren, en dan moest hij alles doen. Dat wil zeggen, mensen baseerden zich de facto direct op potentiële kant-en-klare oplossingen die in het technische ontwerp als gegeven moesten worden opgenomen, in plaats van uit te gaan van de bestaande problemen die ze willen oplossen.

En we verschuiven nu de focus van zo'n 'ideeën generator' naar het formuleren van duidelijke problemen.

Daarom, na het horen van de beschrijvingen van deze problemen, zijn we manieren gaan bedenken om deze hypothesen te testen.

De kwaliteit van het werk van de monsters leidende medewerkers controleren is het eenvoudigst met videobewaking. Het is duidelijk dat het om een nieuwe hypothese te toetsen niet zo eenvoudig is om het hele platform met explosieveilige camera's uit te rusten; al snel kwam het voorlopige berekeningen op enkele miljoenen roebel, en we hebben dat opgegeven. We besloten om naar onze mensen in de industrie 4.0 te gaan, die nu de enige explosieveilige wifi-camera in Rusland testen. Volgens de beschrijving zou het moeten lijken op iets ter grootte van een waterkoker, maar in werkelijkheid is dit apparaat niet groter dan een markeerstift voor whiteboards.

We namen dit ding mee en kwamen naar het platform, waarbij we de medewerkers zo gedetailleerd mogelijk uitlegden wat we hier doen, hoe lang en specifiek waarvoor. Het was belangrijk om direct duidelijk te maken dat dit echt bedoeld is voor het testen van het experiment en tijdelijk is.

Enkele weken werkten mensen in de normale modus, er werden geen overtredingen vastgesteld, en we besloten onze tweede hypothese te testen.

Voor snelle en gedetailleerde training hebben we gekozen voor video-instructies, in de veronderstelling dat een goede video-tutorial, die je in een paar minuten kunt bekijken, veel duidelijker alles zou laten zien dan een gebruikershandleiding van 15 pagina's. Zeker omdat ze al zo'n handleiding hadden.

Gezegd - gedaan. Ik ging naar Tobolsk, keek hoe ze monsters nemen, en het bleek dat de mechaniek van het monster nemen al 20 jaar hetzelfde is. Ja, het is een vrij routinematig proces dat je kunt automatiseren door het vaak te herhalen, maar dat betekent niet dat het niet geautomatiseerd en vereenvoudigd kan worden. Aanvankelijk werd het idee van een video-instructie door het personeel verworpen, omdat ze zeiden: waarom deze video's maken als we hier al 20 jaar hetzelfde doen.

We hebben onze PR afgesproken, de meest geschikte jongen voor de video-opnames ingeschakeld, hem een geweldige glimmende moersleutel gegeven en het proces van monstername in ideale omstandigheden vastgelegd. Het resultaat was een voorbeeldige versie. Ik heb de video toen ook ingesproken voor extra duidelijkheid.

We hebben medewerkers uit acht ploegendiensten samengebracht, een filmvertoning georganiseerd en hen gevraagd wat ze ervan vonden. Het bleek dat het als het bekijken van de eerste 'Avengers' voor de derde keer was: cool, prachtig, maar niets nieuws. Ze zeiden: 'We doen dit al die tijd zo.'

Daarna vroegen we de jongens rechtstreeks wat ze niet leuk vonden aan dit proces en wat ongemakken opleverde. En toen brak de dam - na zo'n improvisatiesessie met de productiemedewerkers hebben we het management een vrij omvangrijke backlog gepresenteerd, gericht op het veranderen van de operationele processen. Want we moesten eerst een aantal aanpassingen aan de processen zelf aanbrengen en pas daarna een digitaal product maken dat onder de nieuwe voorwaarden goed ontvangen zal worden.

Serieus, als iemand een grote onhandige monstername zonder handvat heeft, moet hij deze met twee handen dragen, en jij zegt: 'Hier, Ivan, neem de mobiel, scan het daar' - dat is niet echt inspirerend.

De mensen voor wie je het product maakt, moeten begrijpen dat je ze hoort en niet gewoon voorbereid bent om een hippe gadget uit te rollen die ze op dit moment helemaal niet nodig hebben.

Over processen en effecten

Als je een digitaal product ontwikkelt en je proces is niet goed, moet je het product nog niet implementeren; je moet eerst dit proces verbeteren. Onze focus ligt nu op het optimaliseren van dergelijke processen. Binnen de design-sessies blijven we een backlog verzamelen, niet alleen voor het digitale product, maar ook voor wereldwijde operationele verbeteringen, die soms zelfs eerder kunnen worden doorgevoerd dan het product zelf. Dit alleen al heeft een geweldig effect.

Het is ook belangrijk dat een deel van het team direct op de locatie is. We hebben jongens uit verschillende afdelingen die ervoor hebben gekozen om een carrière in de digitale wereld op te bouwen en ons te helpen bij de implementatie van producten en het bestuderen van processen. Dergelijke operationele veranderingen worden precies door hen aangeven.

En voor de medewerkers is het ook gemakkelijker; ze begrijpen dat we hier niet gewoon zijn om te zitten, maar dat we echt bespreken hoe ze onnodige papieren kunnen afschaffen, of hoe ze de 16 benodigde documenten voor een proces kunnen reduceren tot 1 (en die uiteindelijk misschien ook kunnen afschaffen), hoe ze een elektronische handtekening kunnen maken en het werk met overheidsinstellingen kunnen optimaliseren, en meer.

En als we het hebben over het proces zelf, hebben we nog iets gevonden.

Het nemen van monsters duurt gemiddeld 3 uur. En in dit proces zijn er mensen die als coördinator fungeren; gedurende die drie uur hebben ze constant telefoonverkeer en rapporteren ze de statussen - waar ze een auto heen moeten sturen, hoe de opdrachten over de laboratoria te verdelen, en dergelijke. Dit is aan de kant van het laboratorium.

Aan de productiezijde zit er ook zo'n persoon met een telefoon die constant aanneemt. We hebben besloten dat het goed zou zijn om een visueel dashboard voor hen te maken, dat hen helpt om de processtatussen te zien, van de aanvragen voor monstername tot de uitgifte van resultaten in het laboratorium, met de benodigde meldingen en andere zaken. Daarna denken we eraan om dit te koppelen aan de transportbestellingen en de activiteiten van de laboratoria zelf te optimaliseren - het werk onder de medewerkers te verdelen.

Uiteindelijk kunnen we door de digitale en operationele veranderingen gezamenlijk ongeveer 2 uur aan arbeidskracht en een uur stilstand van de voertuigen besparen voor één monstername, vergeleken met hoe we het voorheen deden. En dit is slechts voor één monstername; er kunnen er per dag meerdere zijn.

Van de effecten gebeurt momenteel ongeveer een kwart van het monsternameproces. Het resultaat is dat we ongeveer 11 medewerkers vrijmaken voor nuttiger werk. En het verminderen van wagon-uren (en samenstel-uren) opent mogelijkheden voor monetisatie.

Natuurlijk begrijpt niet iedereen volledig wat het digitale team hier doet en waarom ze zich bezighouden met operationele verbeteringen. Mensen hebben nog steeds deze niet helemaal correcte perceptie, waarin je denkt dat de ontwikkelaars kwamen, binnen een dag een app voor je maakten en al je problemen oplosten. En de operationele medewerkers zijn, begrijpelijk, blij met deze aanpak, hoewel met een zekere scepsis.

Maar het is belangrijk om te onthouden dat er geen magische dozen zijn. Het is allemaal werk, onderzoek, hypotheses en verificaties.

Bron: habr.com