En wat kwam er van?
Hey there!
In de productie is het belangrijk om de kwaliteit van producten te bewaken, zowel die van leveranciers als die die we bij de uitgang afgeven. Om dit te doen, voeren we vaak bemonstering uit - speciaal opgeleide medewerkers nemen monsternemers en verzamelen volgens bestaande instructies monsters, die vervolgens naar het laboratorium worden overgebracht, waar ze op kwaliteit worden gecontroleerd.
Mijn naam is Katya, ik ben de producteigenaar van een van de teams bij SIBUR, en vandaag zal ik je vertellen hoe we de levens (tenminste tijdens werkuren) van de bemonsteringsspecialisten en andere deelnemers aan dit spannende proces hebben verbeterd. Onder de snede - over hypothesen en het testen ervan, over de houding ten opzichte van gebruikers van uw digitale product en een beetje over hoe alles bij ons werkt.
Hypotheses
Hier is het de moeite waard om te beginnen met het feit dat ons team vrij jong is, we werken sinds september 2018, en een van onze eerste uitdagingen bij de digitalisering van processen is productiecontrole. Feitelijk is dit een controle van alles in de fase tussen de ontvangst van de grondstoffen en het eindproduct dat onze productiefaciliteiten verlaat. We besloten de olifant stukje voor stukje op te eten en begonnen met sampling. Om het laboratoriumonderzoek van monsters op een digitaal spoor te zetten, moet iemand deze monsters immers eerst verzamelen en brengen. Meestal met handen en voeten.
De eerste hypothesen betroffen het afstappen van papier en handarbeid. Voorheen zag het proces er als volgt uit: een persoon moest op een stuk papier schrijven wat hij precies aan het voorbereiden was om in de monsternemer te verzamelen, zichzelf identificeren (lezen - zijn volledige naam en tijdstip van bemonstering op een stuk papier schrijven), Plak dit stukje papier op de reageerbuis. Ga dan naar het viaduct, neem een monster uit verschillende auto's en keer terug naar de controlekamer. In de controlekamer moest de persoon voor de tweede keer dezelfde gegevens in het monsternamerapport invoeren, waarna het monster naar het laboratorium werd gestuurd. En schrijf dan speciaal voor jezelf een dagboek, zodat je, als er iets gebeurt, kunt nagaan wie een specifiek monster heeft genomen en wanneer. En de scheikundige die het monster in het laboratorium registreerde, bracht de aantekeningen van de stukjes papier vervolgens over naar speciale laboratoriumsoftware (LIMS).
De problemen zijn duidelijk. Ten eerste duurt het lang en bovendien zien we dat dezelfde operatie dubbel wordt uitgevoerd. Ten tweede, lage nauwkeurigheid - de bemonsteringstijd werd gedeeltelijk met het oog geschreven, omdat het één ding is dat je de geschatte bemonsteringstijd op papier hebt geschreven, een ander ding is dat tegen de tijd dat je bij het rijtuig aankwam en begon met het verzamelen van monsters, het een beetje een andere keer. Voor data-analyse en procestracking is dit belangrijker dan het lijkt.
Zoals u kunt zien, is het veld voor procesoptimalisatie werkelijk nog niet geploegd.
We hadden weinig tijd en moesten alles snel en binnen het bedrijfscircuit doen. Iets in de cloud doen in de productie is geen goed idee, omdat je met veel data werkt, waarvan een deel bedrijfsgeheim is of persoonlijke gegevens bevat. Om een prototype te maken hadden we alleen het autonummer en de naam van het product nodig. Beveiligingsfunctionarissen keurden deze gegevens goed en we gingen aan de slag.
Mijn team heeft nu twee externe ontwikkelaars, vier interne, een ontwerper, een Scrum Master en een junior productmanager. Dit is trouwens wat we nu hebben .
Binnen een week hebben we een beheerderspaneel voor het team gebouwd en een eenvoudige mobiele applicatie voor gebruikers die Django gebruiken. Vervolgens hebben we het voor nog een week voltooid en geconfigureerd, en vervolgens aan de gebruikers gegeven, hen getraind en begonnen met testen.
prototype
Alles is hier eenvoudig. Er is een webonderdeel waarmee je een taak voor monstername kunt aanmaken, en er is een mobiele applicatie voor medewerkers, waar alles duidelijk is, zeggen ze, ga naar dat viaduct en haal monsters uit die auto. We hebben eerst QR-codes op de samplers geplakt om het wiel niet opnieuw uit te vinden, omdat we een serieuzere afstemming van de sampler zouden moeten coördineren, maar hier is alles onschadelijk, ik plakte een stuk papier en ging aan de slag. De medewerker hoefde alleen maar een taak in de applicatie te selecteren en de tag te scannen, waarna gegevens in het systeem werden vastgelegd dat hij (een specifieke medewerker) op een bepaald tijdstip monsters nam van een auto met dat en dat nummer. Figuurlijk gesproken: “Ivan heeft om 5 uur een monster genomen van auto nr. 13.44.” Toen hij terugkeerde naar de controlekamer hoefde hij alleen maar een kant-en-klaar document met dezelfde gegevens af te drukken en er eenvoudigweg zijn handtekening op te zetten.
Oude versie van het beheerderspaneel
Een taak aanmaken in het nieuwe beheerdersdashboard
In dit stadium werd het ook gemakkelijker voor de meisjes in het laboratorium - nu hoeven ze het schrift op een stuk papier niet te lezen, maar hoeven ze alleen maar de code te scannen en begrijpen ze meteen wat er precies in de sampler staat.
En toen kwamen we een soortgelijk probleem tegen aan de laboratoriumkant. De meiden hier hebben ook hun eigen complexe software, LIMS (Laboratory Information Management System), waarin ze met pennen alles uit de ontvangen monsternamerapporten moesten invoeren. En in dit stadium loste ons prototype hun pijn op geen enkele manier op.
Daarom hebben we besloten om aan integratie te doen. De ideale situatie zou zijn dat al het werk dat we hebben gedaan om deze tegenpolen te integreren, van monstername tot laboratoriumanalyse, ons zal helpen om helemaal van het papier af te komen. De webapplicatie gaat de papieren journaals vervangen, het selectierapport wordt automatisch ingevuld met een elektronische handtekening. Dankzij het prototype realiseerden we ons dat het concept kon worden toegepast en begonnen we met de ontwikkeling van de MVP.
Prototype van de vorige versie van de mobiele applicatie
MVP van een nieuwe mobiele applicatie
Vingers en handschoenen
Hierbij moeten we ook rekening houden met het feit dat het werken in de productie niet +20 is en een licht briesje dat de rand van een strohoed laat waaien, maar af en toe -40 en ronduit winderig, waarbij je je handschoenen niet uit wilt doen. om op het touchscreen van een explosieveilige smartphone te tikken. Echt niet. Zelfs onder de dreiging papieren formulieren in te vullen en tijd te verspillen. Maar je vingers zijn bij je.
Daarom hebben we het werkproces voor de jongens enigszins veranderd - ten eerste hebben we een aantal acties op de hardwareknoppen aan de zijkant van de smartphone genaaid, die perfect met handschoenen kunnen worden ingedrukt, en ten tweede hebben we de handschoenen zelf geüpgraded: onze collega's, die zich bezighouden met het voorzien van personeel van persoonlijke beschermingsmiddelen, hebben handschoenen voor ons gevonden die aan alle noodzakelijke normen voldoen, en ook met de mogelijkheid om met touchscreens te werken.
Hier is een kleine video over hen.
Ook kregen we feedback over de merktekens op de samplers zelf. Het punt is dat samplers in verschillende soorten verkrijgbaar zijn: plastic, glas, gebogen, in het algemeen in een assortiment. Het is lastig om een QR-code op gebogen exemplaren te plakken; het papier buigt en wordt mogelijk niet zo goed gescand als je zou willen. Bovendien scant het ook slechter onder tape, en als je de tape naar hartenlust omwikkelt, wordt er helemaal niet gescand.
We hebben dit allemaal vervangen door NFC-tags. Dit is veel handiger, maar we hebben het nog niet helemaal handig gemaakt. We willen overstappen op flexibele NFC-tags, maar tot nu toe zitten we vast aan de goedkeuring voor explosiebeveiliging, dus onze tags zijn groot, maar explosieveilig. Maar we gaan hier samen met onze collega’s van de industriële veiligheid aan werken, dus er komt nog veel aan.
Meer over tags
LIMS als systeem zelf voorziet in het afdrukken van streepjescodes voor dergelijke behoeften, maar ze hebben één belangrijk nadeel: ze zijn wegwerpbaar. Dat wil zeggen, ik lijmde het op de merklap, maakte de klus af, en ik moest het afscheuren, weggooien en er dan een nieuwe op plakken. Ten eerste is het allemaal niet zo milieuvriendelijk (er wordt veel meer papier gebruikt dan op het eerste gezicht lijkt). Ten tweede duurt het lang. Onze tags zijn herbruikbaar en herschrijfbaar. Wanneer een monsternemer naar het laboratorium wordt gestuurd, hoeft u deze alleen maar te scannen. Vervolgens wordt de monsternemer zorgvuldig gereinigd en teruggebracht om de volgende monsters te nemen. De productiemedewerker scant het opnieuw en schrijft nieuwe gegevens op de tag.
Deze aanpak bleek ook behoorlijk succesvol en we hebben hem grondig getest en geprobeerd alle moeilijke punten uit te werken. Als gevolg hiervan bevinden we ons nu in de fase van het ontwikkelen van een MVP in een industrieel circuit met volledige integratie in bedrijfssystemen en accounts. Het helpt hier dat er ooit veel dingen naar microservices zijn overgebracht, dus er waren geen problemen met het werken met accounts. In tegenstelling tot dezelfde LIMS deed niemand er iets voor. Hier hadden we bepaalde ruwe kantjes om het goed te integreren met onze ontwikkelomgeving, maar we hebben ze onder de knie en zullen in de zomer alles in de strijd gooien.
Testen en trainen
Maar dit geval kwam voort uit een nogal gewoon probleem: op een dag werd aangenomen dat het testen van monsters soms resultaten oplevert die afwijken van de norm, omdat de monsters simpelweg slecht worden genomen. De hypothesen over wat er gebeurde waren als volgt.
- Monsters worden eenvoudigweg verkeerd genomen omdat het personeel ter plaatse het proces niet volgt.
- Veel nieuwelingen komen naar de productie en niet alles kan hen in detail worden uitgelegd, vandaar dat de bemonstering niet helemaal correct is.
We hadden in het begin kritiek op de eerste optie, maar voor de zekerheid zijn we deze ook gaan controleren.
Hier zal ik één belangrijk ding opmerken. We leren het bedrijf actief om zijn manier van denken opnieuw op te bouwen in de richting van een cultuur van het ontwikkelen van digitale producten. Voorheen was het denkmodel zo dat er een leverancier is, hij hoeft maar één keer een duidelijke technische specificatie met oplossingen te schrijven, deze aan hem te geven en hem alles te laten doen. Dat wil zeggen, het bleek dat men de facto direct uitging van mogelijke kant-en-klare oplossingen die als gegeven in de technische specificaties moesten worden opgenomen, in plaats van uit te gaan van bestaande problemen die men wilde oplossen.
En we verleggen nu de focus van deze ‘ideeëngenerator’ naar het formuleren van duidelijke problemen.
Dus nadat we deze problemen hadden horen beschrijven, begonnen we manieren te bedenken om deze hypothesen te testen.
De eenvoudigste manier om de kwaliteit van het werk van monsternemers te controleren is door middel van videobewaking. Het is duidelijk dat het, om de volgende hypothese te testen, niet zo eenvoudig is om het hele viaduct te nemen en uit te rusten met explosieveilige kamers; de knieberekening leverde ons onmiddellijk vele miljoenen roebel op, en we hebben er afstand van gedaan. Er werd besloten om naar onze jongens van Industrie 4.0 te gaan, die nu een pilot uitvoeren met het gebruik van de enige explosieveilige wifi-camera in de Russische Federatie. Er wordt beschreven dat hij ongeveer zo groot is als een waterkoker, maar in werkelijkheid is hij niet groter dan een whiteboardmarker.
We namen dit kindje mee en kwamen naar het viaduct, waar we de medewerkers zo gedetailleerd mogelijk vertelden wat we hier gaven, voor hoe lang en waarvoor precies. Het was belangrijk om meteen duidelijk te maken dat dit eigenlijk voor het testen van het experiment was en van tijdelijke aard was.
Een paar weken lang werkten mensen normaal, er werden geen overtredingen gedetecteerd en we besloten de tweede hypothese te testen.
Voor een snelle en gedetailleerde training hebben we gekozen voor het formaat van video-instructies, in de veronderstelling dat een adequate video-tutorial, die je een paar minuten kost om te bekijken, alles en iedereen veel duidelijker zal laten zien dan een functiebeschrijving van 15 pagina's. Bovendien hadden ze al dergelijke instructies.
Zo gezegd zo gedaan. Ik ging naar Tobolsk, keek hoe ze monsters namen, en het bleek dat de monsternemingsmechanismen daar de afgelopen 20 jaar hetzelfde zijn geweest. Ja, dit is een tamelijk routinematig proces dat met frequente herhaling tot automatisme kan worden gebracht, maar dit betekent niet dat het niet kan worden geautomatiseerd of vereenvoudigd. Maar aanvankelijk werd het idee van video-instructies door het personeel verworpen en zeiden: waarom zouden we deze video's maken als we hier al twintig jaar hetzelfde doen.
We stemden in met onze PR, rustten de juiste man uit om de video op te nemen, gaven hem een geweldige glimmende sleutel en legden het bemonsteringsproces in ideale omstandigheden vast. Deze voorbeeldversie is uitgebracht. Ik heb toen ook de video ingesproken voor de duidelijkheid.
We verzamelden medewerkers uit acht ploegen, gaven ze een filmische vertoning en vroegen hoe het was. Het bleek alsof je voor de derde keer naar de eerste ‘Avengers’ keek: cool, mooi, maar niets nieuws. Wij doen dit bijvoorbeeld de hele tijd.
Vervolgens vroegen we de jongens rechtstreeks wat ze niet leuk vonden aan dit proces en wat hen ongemak bezorgde. En hier brak de dam: na zo'n geïmproviseerde ontwerpsessie met productiemedewerkers brachten we het management een vrij grootschalige achterstand binnen, gericht op het veranderen van operationele processen. Omdat het nodig was om eerst een aantal wijzigingen in de processen zelf aan te brengen en vervolgens een digitaal product te creëren dat onder de nieuwe omstandigheden correct zou worden waargenomen.
Nou, serieus, als iemand een grote, ongemakkelijke sampler zonder handvat heeft, moet je hem met beide handen dragen en zeg je: "Je hebt een mobiele telefoon bij je, Vanya, scan daar" - dit is op de een of andere manier niet erg inspirerend.
De mensen voor wie je een product maakt, moeten begrijpen dat je naar hen luistert, en dat je je niet alleen maar klaarmaakt om iets moois uit te rollen dat ze op dit moment niet nodig hebben.
Over processen en effecten
Als u een digitaal product maakt en uw proces klopt niet, dan hoeft u het product nog niet te implementeren, u moet dit proces eerst repareren. De zorg van onze afdeling is nu om dergelijke processen af te stemmen; in het kader van ontwerpsessies blijven we een achterstand verzamelen, niet alleen voor het digitale product, maar ook voor wereldwijde operationele verbeteringen, die we soms zelfs vóór het product zelf kunnen implementeren. En dit op zichzelf geeft een uitstekend effect.
Ook is het belangrijk dat een deel van het team direct bij de onderneming gevestigd is. We hebben jongens van verschillende afdelingen die besloten hebben een carrière in de digitale wereld op te bouwen en ons helpen met het introduceren van producten en leerprocessen. Zij zijn het die dergelijke operationele veranderingen teweegbrengen.
En het is gemakkelijker voor de medewerkers, ze begrijpen dat we hier niet alleen zijn om hier te zitten, maar dat we daadwerkelijk zullen bespreken hoe ze onnodige stukjes papier kunnen schrappen, of 16 vel papier kunnen maken van de 1 benodigde papieren voor het proces ( en dat vervolgens ook annuleren), hoe u een elektronische handtekening kunt maken en de samenwerking met overheidsinstanties kunt optimaliseren, enzovoort.
En als we het over het proces zelf hebben, hebben we dit ook gevonden.
Het nemen van monsters duurt gemiddeld 3 uur. En in dit proces zijn er mensen die als coördinator optreden, en gedurende deze drie uur gaat hun telefoon roodgloeiend en rapporteren ze voortdurend statussen - waar ze de auto heen moeten sturen, hoe ze de bestellingen over de laboratoria moeten verdelen, en dergelijke. En dit is aan de laboratoriumkant.
En aan de productiekant zit dezelfde persoon met dezelfde hotphone. En we besloten dat het leuk zou zijn om voor hen een visueel dashboard te maken waarmee ze de status van het proces kunnen zien, van aanvragen voor monsterneming tot het uitbrengen van resultaten in het laboratorium, met de nodige meldingen enzovoort. Vervolgens denken we erover om dit te koppelen aan het bestellen van transport en het optimaliseren van de activiteiten van de laboratoria zelf: het verdelen van werk onder de medewerkers.
Het resultaat is dat we voor één steekproef, gecombineerd met digitale en operationele veranderingen, ongeveer 2 uur aan menselijke arbeid en een uur treinuitval kunnen besparen, vergeleken met hoe we voorheen werkten. En dit is slechts voor één selectie; er kunnen er meerdere per dag zijn.
Wat de effecten betreft, wordt nu ongeveer een kwart van de bemonsteringen op deze manier uitgevoerd. Het blijkt dat we ongeveer 11 personeelsleden vrijmaken om nuttiger werk te doen. En de vermindering van het aantal auto-uren (en treinuren) opent mogelijkheden voor het genereren van inkomsten.
Natuurlijk begrijpt niet iedereen volledig wat het digitale team is vergeten en waarom het bezig is met operationele verbeteringen; mensen blijven zitten met deze niet geheel correcte perceptie, als je denkt dat de ontwikkelaars zijn gekomen, in één dag een applicatie voor je hebben gemaakt en alles hebben opgelost jouw problemen. Maar het bedienend personeel is uiteraard blij met deze aanpak, zij het met enige scepsis.
Maar het is belangrijk om te onthouden dat er geen magische dozen zijn. Het is allemaal werk, onderzoek, hypothesen en testen.
Bron: www.habr.com