Procesų automatizavimas: nuo ko pradėti

Procesų automatizavimas dažnai nuvilia dėl paprastos priežasties - procesas po juo lieka toks pat chaotiškas.

Paleidžiate naują darbo eigą. Bet vis tiek matote tuos pačius vėlavimus, tas pačias klaidas, tas pačias „tai kieno čia atsakomybė?" situacijas - tik dabar jos juda šiek tiek greičiau ir per patogesnę sistemą. Problema neišnyko, ji tik persikėlė.

Mygom.tech pirmiausia išanalizuojame, kaip viskas veikia, pašaliname perteklinius žingsnius, sujungiame sistemas, ir tik po to automatizuojame. Ne todėl, kad taip atrodo tvarkingiau, o todėl, kad tai, ką sukuriame, patiems ir tenka palaikyti. Automatizuoti netvarką reiškia prižiūrėti netvarką.

Todėl svarbu žinoti, kaip atskirti sugedusį procesą nuo tiesiog lėto, ką reikia sutvarkyti prieš keičiant sistemas, kada automatizavimas atsipirks ir kada čia iš tikrųjų reikia DI.

Skirtumas tarp lėto ir sugedusio proceso

Lėtas procesas tiesiog lėtas, bet bent jau nuspėjamas. Sugedęs - kaskart vis kitoks.

Lėta eiga turi aiškius žingsnius, bet strigdama užlaiko darbą. Patvirtinimai guli dieną ar dvi, eksportas trunka dešimt minučių. Kelias aiškus, greitis - ne visuomet. Tai greičio problema, o greičio problemos dažniausiai sprendžiamos nesunkiai.

Sugedęs procesas atrodo vis kitaip. Vienas žmogus daro vienaip, kitas - savaip. Niekas nesutaria, kokia tikroji žingsnių eilė. Rezultatas keičiasi pagal tai, kas darbą atliko. Sprendimai gyvena Slack'e, lapeliuose ir žmonių galvose.

Paprastas testas: ar trys darbuotojai apibūdins tą patį procesą vienodai? Jei ne, tai ne greičio problema. Tai kontrolės problema, ir automatizavimas jos nepašalins, o įrašys į sistemą.

Paprašius trijų žmonių nupiešti tą pačią darbo eigą, gausite tris skirtingas pradžias, du žmones, įsitikinusius, kad jie atsakingi už tą patį žingsnį, ir vieną etapą, kurio be buhalterio įsikišimo paaiškinti neišeina. Čia ne vėlavimas, o painiava.

Požymiai lengvai atpažįstami:

• Ta pati informacija suvedama į kelias sistemas
• Perdavus darbą, tenka iš naujo tikrinti ar taisyti
• Nėra aiškaus atsakomybės paskirstymo
• Išimčių pasitaiko dažniau nei įprastų atvejų
• Tas pats duomenų laukas kaskart užpildomas kitaip

Kaip pažymi Asana (opens in new tab): „aprašykite procesą taip, kaip jis vyksta, o ne kaip norėtumėte, kad vyktų." Skamba savaime suprantamai tol, kol nesusėdate su komanda ir neišgirstate idealios vizijos, kuria niekas realiai nesivadovauja.

Ką aprašome dar prieš imdamiesi automatizavimo

Pirmas žingsnis - suprasti, kaip procesas veikia iš tikrųjų.

Žymime šešis dalykus: kas procesą paleidžia, kokia informacija privaloma, kas atsakingas už kiekvieną žingsnį, kokios sistemos dalyvauja, koks rezultatas ir kokios išimtys galimos. To pakanka, kad diskusija būtų apie faktus, o ne apie tai, kam kaip atrodo.

Nereikia tobulų schemų. Pakanka paprasto proceso aprašymo, kuris aiškiai rodo seką, sprendimo taškus, numatomą laiką ir grįžimo kilpas. KYP.ai (opens in new tab) pastebi: ranka nubraižytas planas teisingas tik tol, kol niekas proceso nepakeičia. Todėl svarbu, kad proceso aprašymas būtų pakankamai paprastas ir reguliariai atnaujinamas.

Ten, kur skundžiamasi, dažnai nėra tikroji problema

Žmonės dažniausiai skundžiasi toje vietoje, kur skausmas tampa matomas, o ne ten, kur jis atsiranda.

Kai pradėjome dirbti su vienu dviračių gamintoju (opens in new tab), defektai išlįsdavo per vėlai - jau gamybos pabaigoje, kai ištaisyti klaidą ar sustabdyti partiją jau kainuoja. Būtent ten ir buvo nukreiptas visas dėmesys.

Bet kokybės patikros vyko popierinėse formose, „Excel" lentelėse ir neformaliuose susirašinėjimuose. Kokybės informacija likdavo ten, kur buvo užrašyta. Tad defekto kilmę tekdavo spėlioti.

Sprendimas buvo ne taisyti greičiau, o pastebėti anksčiau. Patikra vyksta kiekviename etape: darbuotojas nuskenuoja darbo vietos brūkšninį kodą ir gauna būtent tam etapui skirtą patikros sąrašą. Defektas fiksuojamas nuotrauka, ne aprašymu. Taip kiekvienas įrašas pririštas prie konkretaus etapo - ir iškart matyti, kur defektas atsirado.

Rezultatas: 65 % mažiau kokybės nukrypimų, 80 % mažiau rankinio dokumentavimo, o kokybės komanda perėjo nuo reagavimo prie defektų prevencijos.

Plieno konstrukcijų gamintojui (opens in new tab) problema buvo kitoje vietoje. Daugiausia skundų buvo apie tą patį: medžiagų surinkimas ir išsiuntimas trunka per ilgai.

Bet painiava atsirasdavo anksčiau. Medžiagų duomenis rankiniu būdu pildė ir pirkimai, ir sandėlis, ir gamyba - kiekvienas savoje Excel lentelėje. Komandos gaišo valandas jas atnaujindamos ir vis tiek dirbo su pasenusiais duomenimis. Trys skyriai, trys šiek tiek skirtingos to paties dalyko versijos.

Sprendimas buvo ne greičiau surinkti medžiagas, o žinoti, kas kur yra. Medžiagų užklausa suvedama vieną kartą, projekto pradžioje - tipas, ilgis, kiekis, svoris - o kiekvienas judėjimas fiksuojamas tą akimirką, kai įvyksta. Nuo sandėlio iki objekto visi mato tą patį.

Rezultatas: medžiagų surinkimas ir išsiuntimas pagreitėjo 35 %, o kiekvienas gamybos vadovas kasdien sutaupė apie tris valandas.

Abiem atvejais automatizavus būtent tą vietą, dėl kurios skundžiamasi, nebūtų pasikeitę nieko. Būtent todėl tiek daug automatizavimo projektų nepasiteisina: automatizuojama tai, kas matoma, o ne tai, nuo ko viskas prasideda.

Abiem atvejais kalti buvo tie patys duomenys - užrašyti ne ten, kur reikia, arba ne vienodai. Tai ne smulkmena. Didžiausi nuostoliai susideda ne iš vienos didelės avarijos, o iš tūkstančių smulkių pataisymų, kurių niekas nefiksuoja: perrašyta eilutė, sutvarkytas įrašas, skambutis pasitikslinti, kuri versija teisinga.

Pirma supaprastinti, tada stabilizuoti

Kai turime aiškų proceso aprašymą, imame dirbti dviem kryptimis.

Supaprastiname. Šaliname dvigubus patvirtinimus, sujungiame pasikartojantį duomenų įvedimą, kiekvienam etapui skiriame vieną atsakingą žmogų, o kiekvienam svarbiam laukui - vieną patikimą šaltinį: kliento ID, užsakymo būsena, sąskaitos suma. Šį žingsnį dažnai praleidžiama, nes nauji įrankiai atrodo įdomiau. Bet didžioji nauda slepiasi būtent čia.

Stabilizuojame. Naudojame vieningas formas ir įpareigojame užpildyti esminius laukus. Apibrėžiame statusus taip, kad visiems jie reikštų tą patį. Užfiksuojame duomenų struktūros taisykles. Ten, kur sistemos kartais neatsako, įtraukiame pakartotinių bandymų logiką. O klaidų pranešimus rašome taip, kad žmogus iškart suprastų, kas nutiko ir kas bus toliau.

Tada viską dokumentuojame: sprendimų lentelės, laukų susiejimai, webhook'ų susitarimai, duomenų taisyklės, atkūrimo keliai. Ne dėl formalumo, o tam, kad po pusantrų metų pakeisti sistemą būtų paprasta.

Geras išorinis pavyzdys būtų Pipefy (opens in new tab) aprašyta situacija: apskaitos komandoje apmokėjimo patvirtinimai vyko el. paštu, duomenys įvedami ranka į kelias senas sistemas - procesas užtrukdavo iki trijų savaičių, pasitaikydavo dvigubų išmokų. Kai procesas buvo pertvarkytas ir perkeltas į vieną platformą, apdorojimas sutrumpėjo iki septynių dienų - 66,6 % greičiau.

Svarbu žinoti - Pipefy čia pasakoja apie savo klientą ir sprendimas buvo jų sistema. Bet verta kopijuoti ne sprendimą, o eiliškumą - jie procesą pertvarkė prieš automatizuodami, o ne po to.

Tada automatizuokite - nuobodžiai ir patikimai

Kai darbo eiga tampa nuspėjama, laikas automatizacijai.

Pradėkite nuo stabiliausio kelio: vienas paleidimo impulsas, vienas atsakingas žmogus, vienas sėkmės kriterijus ir viena atkūrimo opcija. Taip rizika lieka maža, o kai kas nors sulūžta, priežastį rasti paprasta.

Pats sprendimas neturėtų atrodyti stebuklingai. Patikimas automatizavimas iš išorės dažnai gana paprastas: įvykių valdomos integracijos, eilinių užduočių kartojimas, tinkamų laukų tikrinimas, raktai, neleidžiantys to paties veiksmo įvykdyti dukart, ir žurnalai, rodantys kas, ką, kada padarė ir kodėl. Penktadienio vakarą žmonės tikisi ne magijos, o stabilumo.

Paprastiems procesams dažniausiai užtenka paprastos struktūros: forma, kurioje užpildomi duomenys, webhook'as, perduodantis įvykį toliau, vidurinė dalis, kuri nukreipia veiksmą, ir tikrinimas prieš sukuriant įrašą. Neprekiaujame stebuklais. Svarbiausia - patikimumas, kai procesai liečia klientus, pajamas ar reikalavimus.

Pavyzdys su metalo apdirbimo užsakymų sistema (opens in new tab): anksčiau užsakymai ateidavo el. paštu su failais, reikėjo rankiniu būdu skaičiuoti kainas, konvertuoti formatą ir rizikuoti, kad kliento duomenys netiks įrangai. DI čia nepridėjome. Sukūrėme savitarnos platformą su momentiniu kainos apskaičiavimu, 3D peržiūra ir automatiniu failų konvertavimu į tą formatą, kurį skaito jų įranga. Užsakymo procesas paspartėjo 2 kartus, individualių užsakymų padaugėjo 5 kartus, administracinio darbo sumažėjo per pusę.

Šioje sistemoje nėra modelio - tik tvarkingas procesas.

Kada DI tikrai reikalingas

Taisyklė paprasta – DI gali tą padaryti nereiškia, kad būtinai verta jį naudoti.

DI tinka ten, kur sprendimas tikrai neaiškus, bet dėsningumų vis tiek yra. Jokios naudos, kai pats procesas chaotiškas, tada tiesiog gausite užtikrintai skambantį atsakymą, sudėtą ant nepatikimų duomenų.

Geras pavyzdys - sąskaitų valdymas. Jos atkeliauja PDF failais, nuotraukomis, Excel lentelėmis ir el. laiškų tekstu - ir iš šimtų tiekėjų, be vieningo formato. Mokėjimo paskirtys retai sutampa su sąskaitos eilutėmis. Tai realus neaiškumas, o ne chaosas. Todėl sąskaitų automatizavimo platformoje (opens in new tab) DI panaudojome duomenų atpažinimui ir suderinimui. Sutapimų tikslumas - iki 95 %, 40 % mažiau apdorojimo laiko, kiekvienas žmogus tvarko 10 kartų daugiau sąskaitų.

Svarbu žinoti, ko DI nedaro. Jis nenustato patvirtinimo limitų, nesugalvoja siuntimo schemų. Tokie žingsniai vyksta pagal aiškias taisykles, tokie ir turi likti - jiems reikia ne spėjimo, o stipresnio tikrinimo ir tvarkingesnės integracijos.

Kodėl DI projektai dažnai nepavyksta, aprašėme straipsnyje Kodėl DI projektai žlunga ir kaip to išvengti (opens in new tab).

Dalis, kurią visi praleidžia - priežiūra

Automatizuota sistema vėl griūva į netvarką tada, kai procesas aplink ją pasikeičia, o taisyklių niekas neatnaujina.

Todėl dokumentaciją prižiūrime nuolat: atnaujiname procesų aprašymus, kai keičiasi atsakomybės, formos ar išimtys. Kartą per mėnesį pasižiūrime, kiek atvejų iškrenta iš standartinio kelio. Jei ta pati išimtis vis kartojasi, sutvarkome taisyklę arba perdavimą anksčiau procese, o ne lipdome naujus įrankius ant viršaus.

Geros sistemos lieka tvarkingos todėl, kad kažkas jas prižiūri. Neįdomu, bet čia ir yra visas darbas.

Nežinote, ar jūsų procesas lėtas, ar sugedęs?

Jei skaitydami mąstote nežinau, ar mūsų procesas lėtas, ar sugedęs - tai normalu. Būtent tam ir yra mūsų nemokama 3 minučių diagnostika (opens in new tab).

Ji padeda atskirti, ar sprendimas yra DI, proceso sutvarkymas, ar tiesiog jau turimų sistemų sujungimas. Kartais paaiškėja, kad DI jums išvis nereikia. Toks atsakymas irgi nemokamas.

Jei mieliau aptartumėte gyvai, susisiekite (opens in new tab) - arba pasižiūrėkite, kaip prie to prieiname: DI integracija ir automatizavimas (opens in new tab).