Og hvad kom der ud af det
Hej!
I produktionen er det vigtigt at overvåge kvaliteten af produkterne, både dem der kommer fra leverandørerne og dem vi leverer som færdige produkter. For at sikre dette udfører vi ofte stikprøvetagning — særligt uddannede medarbejdere tager stikprøver og indsamler prøver i henhold til de givne instruktioner, som derefter sendes til laboratoriet for kvalitetskontrol.
Mit navn er Katya, jeg er produktleder for et af teamene i SIBUR, og i dag vil jeg fortælle, hvordan vi har forbedret hverdagen (i det mindste i arbejdstiden) for de medarbejdere, der foretager stikprøvetagning, samt andre deltagere i denne spændende proces. Under 'læs mere' finder du information om hypoteser og deres validering, om forholdet til brugerne af dit digitale produkt og lidt om, hvordan vi har organiseret det hele.
Hypoteser
Det er værd at nævne, at vores team er relativt ungt; vi har arbejdet siden september 2018, og en af vores første udfordringer inden for digitalisering af processerne har været produktionskontrol. De facto er det en kontrol af alt, der sker mellem modtagelsen af råmaterialer og udgangen af vores færdige produkter. Vi besluttede at tage 'slangen' i bidder og begyndte med stikprøvetagning. For at kunne digitalisere laboratoriumsundersøgelserne skal disse prøver først samles og leveres. Normalt gøres dette manuelt.
De første hypoteser handlede om at eliminere papirarbejde og manuel håndtering. Tidligere så processen således ud — en person skulle på et stykke papir skrive, hvad han/hun skulle indsamle i stikprøvetagningsbeholderen, selvidentificere sig (læs: skrive sine initialer og tidspunktet for stikprøvetagningen), klæbe dette papir på prøverøret. Derefter skulle de gå op til platformsområdet, tage en prøve fra flere vogne og vende tilbage til kontrolrummet. I kontrolrummet skulle personen igen indtaste de samme data i stikprøveprotokollen, sammen med hvilken prøven sendes til laboratoriet. Og så skulle man også føre en journal for sig selv, så man i tilfælde af problemer kunne tjekke, hvem og hvornår der havde taget den specifikke prøve. Kemiingeniøren, der registrerede prøven i laboratoriet, overførte derefter oplysningerne fra papiret til et særligt laboratorie-software (LIMS).
Problemerne er åbenlyse. For det første tager det lang tid, og vi observerer samtidig duplikering af den samme operation. For det andet er nøjagtigheden lav — den tid, vi skrev ned, var delvist et gæt, fordi det er en ting at skrive det omtrentlige tid på papir, og noget helt andet er, når du når til vognen og begynder at samle prøver, vil det allerede være lidt anderledes tid. For dataanalyse og overvågning af processen er det vigtigere, end det ser ud til.
Som I kan se, er der virkelig stort potentiale for at optimere processen.
Vi havde ikke meget tid, og vi skulle gøre alt hurtigt inden for virksomhedens rammer. At gøre noget i skyen under produktionen er en risikabel idé, fordi du arbejder med mange data, hvoraf nogle repræsenterer erhvervshemmeligheder eller indeholder persondata. Vi havde kun brug for vognnummeret og produktnavnet for at lave en prototype — disse data blev godkendt af sikkerhedsfolkene, og vi gik i gang.
I mit team er der nu 2 eksterne udviklere, 4 interne, en designer, en scrum master og en junior produktansvarlig. Her er i øvrigt, hvilke .
I løbet af ugen samlede vi en administrationsgrænseflade til teamet på Django og en simpel mobilapp til brugerne. Derefter brugte vi yderligere en uge på at forfine og justere den, og derefter gav vi den til brugerne, trænede dem og begyndte at teste.
Prototype
Her er det enkelt. Der er en webdel, som gør det muligt at oprette en opgave for prøvetagning, og der er en mobilapp for medarbejderne, hvor alt er klart, altså, gå til den rampe og saml prøver fra den vogn. Til prøvetagningsenhederne klistrede vi først QR-koder, for ikke at finde på en ny løsning, fordi mere avanceret tuning af prøvetagningsenheden skulle godkendes — her er alt harmløst, klistrede et stykke papir og gik til arbejdet. Medarbejderen havde kun til opgave at vælge opgaven i appen og scanne koden, hvorefter systemet registrerede oplysninger om, at han (den specifikke medarbejder) præcist på det tidspunkt tog prøver fra en vogn med det nummer. Billedligt talt, "Ivan tog en prøve fra vogn nr. 5 kl. 13.44". Efter at være vendt tilbage til kontrolrummet skulle han blot udskrive den færdige rapport med de samme oplysninger og derefter sætte sin underskrift.
Den gamle version af administrationsgrænsefladen
Oprettelse af opgave i den nye administrationsgrænseflade
Det er blevet lettere for pigerne i laboratoriet på dette stadium - nu kan de undgå at skulle tyde beskeder på papir, men blot scanne koden og straks forstå, hvad der er i prøvebeholderen.
Og her stødte vi på et lignende problem allerede fra laboratoriets side. Pigerne har deres eget komplekse software, LIMS (Laboratory Information Management System), hvor de måtte indtaste alt fra de modtagne prøvetagningsrapporter manuelt. På dette tidspunkt løste vores prototype slet ikke deres problemer.
Derfor besluttede vi at lave en integration. Den ideelle situation ville være, at alt, hvad vi har lavet til integrationen mellem prøvetagning og laboratorieanalyse, vil hjælpe med at eliminere papir fuldstændigt. Webapplikationen vil erstatte papirdagbøgerne, og prøvetagningsrapporten vil automatisk blive udfyldt ved hjælp af en elektronisk signatur. Takket være prototypen indså vi, at konceptet kunne anvendes, og vi gik i gang med at udvikle MVP.
Prototype af den tidligere version af mobilappen
MVP af den nye mobilapp
Fingre og handsker
Her skal man også tage højde for, at arbejdet i produktionen ikke er +20 grader med en let brise, der blæser på en stråhat, men til tider -40 grader og en åbenlys vind, hvor det slet ikke er rart at tage handskerne af for at trykke på den berøringsfølsomme skærm på en eksplosionssikker smartphone. Slet ikke. Selv ikke under trussel om at udfylde papirrapporter og spilde tid. Men så har man fingrene ved sig.
Derfor ændrede vi lidt på arbejdsprocessen for dem - for det første, vi har programmeret en række handlinger til de fysiske sideknapper på smartphones, der kan trykkes på, selv når man har handsker på, og for det andet, vi har forbedret handskerne selv: vores kolleger, der arbejder med at sikre personale med personligt beskyttelsesudstyr, fandt nogle handsker, der opfylder alle nødvendige standarder og samtidig gør det muligt at arbejde med berøringsskærme.
Her er lidt om dem i videoen.
Vi har også fået feedback om selve mærkerne på prøvebeholderne. Problemet er, at prøvebeholdere kommer i forskellige former - plastik, glas, krumformede, kort sagt, et udvalg. Det er vanskeligt at påsætte QR-koden på de krumme, papiret bøjer sig, og den scannes ikke så godt, som man kunne ønske. Desuden scannes det også dårligere under tape, og hvis man pakker tape omkring, så kan det slet ikke scannes.
Vi har erstattet alt dette med NFC-tags. Det er meget mere praktisk, men vi har endnu ikke gjort det helt brugervenligt — vi ønsker at overgå til fleksible NFC-tags, men vi er lige nu stødt på godkendelse i forhold til eksplosionssikkerhed, så vores tags er store, men eksplosionssikre. Men vi vil arbejde på dette med vores kolleger fra produktsikkerhed, så der er stadig meget, der ligger foran os.
Yderligere om tags
LIMS som systemet selv forudsætter print af stregkoder til sådanne behov, men de har en væsentlig ulempe — de er engangsprodukter. Det vil sige, at når du er færdig med arbejdet, skal den tages af, smides væk, og derefter skal du klæbe en ny på. For det første er det ikke ligefrem miljøvenligt (der går meget mere papir til end man lige tror). For det andet tager det tid. Vores tags er genanvendelige, med mulighed for omprogrammering. Når et prøvesampler sendes til laboratoriet, er det tilstrækkeligt at scanne det. Herefter bliver prøvesamleren nænsomt rengjort og sendt tilbage til næste prøvetagning. Medarbejderen på produktionen scanner det igen og skriver nye oplysninger på taggen.
Denne tilgang har også vist sig at være ganske succesfuld, og vi har grundigt testet den og har forsøgt at tage hånd om alle vanskelige punkter. I sidste ende er vi nu på udviklingsstadiet af MVP i et produktionsmiljø med fuld integration i virksomhedens systemer og konti. Her hjælper det, at vi i sin tid oversatte meget til mikroservices, så der ikke har været problemer med at arbejde med konti. I modsætning til LIMS — for den har ingen lavet noget. Her havde vi enkelte udfordringer med at integrere den ordentligt med vores udviklingsmiljø, men vi har overvundet dem, og vi vil lancere alt i sommer.
Kontroller og træning
Her er en sag, der er opstået ud fra et ret almindeligt problem — en gang opstod der en formodning om, at nogle gange viser prøvetagningen abnorme resultater, fordi prøverne simpelthen tages dårligt. Hypoteserne om det, der skete, bestod i følgende.
- Prøverne tages simpelthen forkert på grund af medarbejdernes manglende overholdelse af den teknologiske proces.
- Der kommer mange nybegyndere til produktionen, og de får måske ikke alt forklaret grundigt, hvilket kan føre til ikke helt korrekte prøvetagninger.
Den første mulighed kritiserede vi straks, men alligevel begyndte vi også at tjekke den.
Her vil jeg påpege en vigtig ting. Vi underviser aktivt virksomheden i at ændre tankegangen mod en kultur for udvikling af digitale produkter. Tidligere var tankemåden sådan, at der eksisterede en leverandør, som blot skulle skrive et klart kravspecifikation én gang, aflevere det, og så skulle de gøre alt. Det betød, at folk de facto umiddelbart baserede sig på potentielle færdige løsninger, som skulle formuleres i kravspecifikationen som en given ting, i stedet for at tage udgangspunkt i de eksisterende problemer, som ønskedes løst.
Og vi flytter nu fokus fra en sådan "idé-generator" til formuleringen af klart definerede problemer.
Derfor, efter at have hørt beskrivelsen af disse problemer, begyndte vi at tænke på måder at teste disse hypoteser på.
At teste kvaliteten af rekrutteringsspecialisternes arbejde er nemmest med hjælp fra videobehandling. Det er klart, at det ikke er helt enkelt at udstyre hele rampen med eksplosionssikre kameraer for at teste en ny hypotese; en hurtig beregning afslørede, at det ville koste mange millioner rubler, og vi droppede det. Det blev besluttet at gå til vores folk fra industri 4.0, som nu piloterer brugen af det eneste eksplosionssikre wifi-kamera i Rusland. Beskrivelsen siger, at det skal minde om noget på størrelse med en elkedel, men i virkeligheden er denne dims ikke større end en marker til whiteboards.
Vi tog denne lille sag og kom til rampen, hvor vi detaljeret forklarede medarbejderne, hvad vi gav dem, hvor længe det ville vare, og til hvilket formål. Det var vigtigt straks at gøre klart, at dette faktisk var til test af eksperimentet og var midlertidigt.
I et par uger arbejdede folk i normal drift, og der blev ikke fundet nogen overtrædelser, så vi besluttede at teste den anden hypotese.
Til hurtig og detaljeret læring valgte vi formatet video-instruktioner, da vi mistænkte, at en passende videotutorial, som du kan se på i løbet af et par minutter, bedre viser alt og alle, end en stillingsbeskrivelse på 15 sider. Især fordi de allerede havde en sådan instruktion.
Det sagt, det gjort. Jeg tog til Tobolsk, så hvordan de tager prøver, og det viste sig, at mekanikken for prøvetagning har været den samme i de sidste 20 år. Ja, det er en temmelig rutinepræget proces, som kan gøres automatisk ved hyppig gentagelse, men det betyder ikke, at den ikke kan automatiseres og forenkles. Men i første omgang blev idéen med video instruktion af personalet afvist, som om: hvorfor skulle vi optage disse videoer, når vi har lavet det samme i 20 år.
Vi aftalte med vores PR, og mobiliserede den helt rigtige fyr til at filme videoen, gav ham en flot, blank søgnøgle og optog prøvetagningsprocessen under ideelle forhold. Det blev en modelversion. Jeg angav også lyden til videoen for klarhedens skyld.
Vi samlede medarbejdere fra otte skift, arrangerede en cinematografisk fremvisning og spurgte, hvad de syntes. Det viste sig, at det var som at se de første 'Avengers' for tredje gang: fedt, smukt, men intet nyt. De sagde, at de har gjort det sådan hele tiden.
Derefter spurgte vi direktørerne direkte, hvad de ikke kunne lide ved denne proces, og hvad der var besværligt. Her brast dæmningen - efter denne improviserede designsession med produktionsmedarbejderne præsenterede vi ledelsen en ret stor backlog, målrettet mod at ændre netop de operationelle processer. Fordi det var nødvendigt først at foretage en række ændringer i selve processerne, og derefter lave det digitale produkt, som vil blive opfattet korrekt under de nye forhold.
Jamen seriøst, hvis en person har en stor, besværlig prøvetager uden et håndtag, skal den bæres med to hænder, og du siger: 'Her, Ivan, tag mobilen, så scanner du der' - det er ikke særlig inspirerende.
Folkene, som I laver produktet til, skal forstå, at I hører dem, og ikke bare forbereder jer på at lancere noget smart, som de lige nu ikke har brug for.
Om processer og effekter
Hvis du laver et digitalt produkt, og du har en skæv proces – så er det ikke tid til at implementere produktet, du skal først få styr på denne proces. Vores fokus lige nu er at optimere sådanne processer, og i vores design-sessioner fortsætter vi med at samle backlog, ikke kun for det digitale produkt, men også for globale operationelle forbedringer, som nogle gange også kan implementeres hurtigere end selve produktet. Og dette giver i sig selv en fantastisk effekt.
Det er også vigtigt, at en del af teamet er direkte på virksomheden. Vi har folk fra forskellige afdelinger, der har besluttet at bygge en karriere inden for digitalisering og hjælpe os med implementeringen af produkter og studiet af processer. Disse operationelle ændringer kommer netop fra dem.
Og det er lettere for medarbejderne, de forstår, at vi ikke bare er samlet for at sidde her, men faktisk diskuterer, hvordan de kan afskaffe unødige papirer, eller fra 16 nødvendige dokumenter for en proces lave ét dokument (og så afskaffe det også), hvordan de kan lave en digital underskrift og optimere arbejdet med myndighederne, og meget mere.
Og hvis vi taler om selve processen, har vi også fundet dette.
Prøveudtagningen tager i gennemsnit omkring 3 timer. Og i denne proces er der folk, der fungerer som koordinatorer, og i hele disse tre timer har de deres telefon konstant i brug og rapporterer status – hvor skal bilen sendes, hvordan skal ordrer fordeles til laboratorierne, og lignende. Og det er på laboratoriets side.
Og på produktionssiden sidder der en person med en lige så travl telefon. Og vi besluttede, at det ville være godt at lave et visuelt dashboard, der hjælper med at se status for processen, fra anmodninger om prøveudtagning til udlevering af resultaterne i laboratoriet, med de nødvendige underretninger og andet. Senere overvejer vi at forbinde dette med transportordrerne og optimere laboratoriernes aktiviteter – fordele arbejdet mellem medarbejderne.
I sidste ende kan vi med de digitale og operationelle ændringer spare omkring 2 timers arbejdskraft og 1 times nedetid for personale ved hver prøveudtagning i forhold til, hvordan vi arbejdede før. Og dette er kun for én prøveudtagning, der kan være flere om dagen.
Af effekterne — lige nu udføres cirka en fjerdedel af prøvetagningerne på denne måde. Det betyder, at vi frigiver cirka 11 enheder af personale til mere nyttigt arbejde. Og reduktionen af vogn-time (og sammensætnings-time) åbner muligheder for monetisering.
Selvfølgelig er der ikke alle, der helt forstår, hvad det digitale team laver her, og hvorfor de beskæftiger sig med operationelle forbedringer. Folk har stadig denne ikke helt korrekte opfattelse, når man tænker, at udviklerne kom, lavede en app til dig på en dag og løste alle problemerne. Og det operationelle personale er, helt forståeligt, glade for sådan en tilgang, omend med en smule skepsis.
Men det er vigtigt at huske, at der ikke findes magiske bokse. Det hele er arbejde, forskning, hypoteser og afprøvninger.
Kilde: habr.com
