Kai sprendimai lieka susirašinėjime, o ne sistemoje

Klientas klausia, kodėl jo užsakymas buvo išsiųstas devyniomis dienomis vėliau. Atsakymas yra - tik jis užfiksuotas trijų savaičių senumo pokalbyje tarp dviejų kolegų, iš kurių vienas dabar atostogauja, o rasti jį pavyksta tik atspėjus, kokiais žodžiais tada buvo rašyta.

Ir čia slypi problema. Sprendimas buvo priimtas, ir jis buvo teisingas. Tik niekur neužfiksuotas taip, kad po pusmečio jį rastumėte.

Mygom.tech (opens in new tab) komandoje daug laiko praleidžiame braižydami, kaip darbas iš tikrųjų juda per įmonę. Dažnai matome tą patį: oficiali tvarka surašyta ERP arba CRM sistemoje, o tikrieji sprendimai - išimtys, patvirtinimai, nestandartiniai atvejai - lieka susirašinėjime, kuriuo niekas neplanavo remtis.

Taigi: kodėl darbas nukeliauja į susirašinėjimą, ko jis negali išlaikyti, kiek tai kainuoja, kaip tai pasitikrinti, kaip įrašą perkelti į sistemą ir kur čia padeda dirbtinis intelektas.

Kodėl išimtys nukeliauja į pokalbius

ERP ar CRM sistema turi formą: privalomi laukai, iš anksto nustatytos reikšmės, baigtinis būsenų sąrašas. Užsakymas gali būti „naujas", „gaminamas" arba „išsiųstas" - ir nieko tarp jų. Būtent tai sistemą ir daro naudingą. Ir būtent dėl to išimties nėra kur įrašyti: forma turi laukus tam, ką kas nors numatė iš anksto, o išimtis yra tai, ko niekas nenumatė.

O jei ERP išvis neturite, ir viskas vyksta skaičiuoklėje, o būsenas žino tik kolegos, niekas nesikeičia. Išimties vis tiek nėra kur įrašyti, tik pas jus tai pasimato greičiau.

Klientas nori dalinio pristatymo. Tiekėjas vėluoja dviem dienomis, procesą reikia perdėlioti. Nuolatinis pirkėjas prašo nuolaidos, šiek tiek viršijančios standartą. Forma nė vienam atvejui laukelio neturi. Todėl kas nors parašo situaciją kanale, kitas atsako, priimamas sprendimas ir darbas juda toliau.

Pokalbiai priima viską. Dėl to jie laimi tada, kai reikia veikti tuoj pat - ir pralaimi tada, kai reikia atsakyti, kas ir kodėl buvo nuspręsta.

Beveik visur matome šiuos keturis modelius:

• Patvirtinimas reakcija. Pakeltas nykštys po žinute yra vienintelis įrašas, kad kažkas pritarė sprendimui, kuris kainuoja pinigus.
• Išimtis be pėdsako. „Šį kartą labai skubu, praleidžiam papildomą tikrinimą." Sprendimas - logiškas. Bet sistemoje niekur neparašyta, kad tikrinimas buvo praleistas ir kodėl.
• Būsena, kuri niekur nekeliauja. Komanda žino, kad užsakymas sustabdytas. Sistema vis tiek rodo, kad jis gaminamas.
• Nėra galutinės versijos. Susirašinėjime persimesta trimis pataisymais. Niekas negali pasakyti, kurią iš jų klientas galiausiai gavo.

Visais keturiais atvejais žmonės tiesiog stumia darbą pirmyn greičiausiu turimu įrankiu. Bet greičiausias įrankis ir vieta, kur informacija turėtų būti užfiksuota, nėra tas pats.

Archyvas, iš kurio nieko nesuskaičiuosi

Testas paprastas: ar galite suskaičiuoti praėjusio mėnesio išimtis nieko neskaitydami?

Jei norint atsakyti „kiek užsakymų praėjusį mėnesį reikėjo taisyti rankiniu būdu ir kokios buvo trys dažniausios priežastys" tenka vartyti žinutes, tai neturite nieko, ką galėtumėte suskaičiuoti. Turite archyvą. Archyvas padeda atsakyti į vieną konkretų klausimą, bet nepasako, kas kartojasi - iš rišlaus teksto skaičių neišvesi.

Priežastis paprasta. Susirašinėjimas puikiai tinka diskusijai, kontekstui ir greičiui, bet jis neišlaiko būsenos. Nėra statuso, pagal kurį filtruotumėte. Nėra atsakingo lauko. Nėra termino, kuris pasibaigtų ir pats apie save primintų. Todėl negalite atsidaryti sąrašo ir pamatyti, kas šiandien neišspręsta, kas kieno rankose ir kas jau vėluoja.

Dėl tos pačios priežasties geresnė paieška nėra sprendimas. Paieška padeda tik tada, kai jau žinote, ko ieškoti. Struktūruotas įrašas leidžia paklausti: kuris tiekėjas dažniausiai lemia išimtis, kuriuo mėnesiu jų daugiausia, kas jas dažniausiai tvirtina.

Kiek kainuoja sprendimai, likę susirašinėjime

Atsakymas, kurio niekas negali patikrinti. Kas nors paklausia, dėl ko buvo sutarta. Dabar žmogus turi eiti ir išsiaiškinti. Klausimas tik, ar jis suras tikrą atsakymą.

Microsoft 2025 m. darbo aplinkos tyrimas (opens in new tab) rodo, kad vidutinis darbuotojas per dieną gauna 153 žinutes ir 117 el. laiškų. Pokalbis, vykęs prieš tris savaites, yra vienas iš kelių tūkstančių. Randate žinutę, kuri atrodo ta pati, bet vėliau pasirodo, kad sprendimas dar buvo keistas kitame pokalbyje. Arba nustojate ieškoti ir norite paklausti kolegos, kuris tada dalyvavo, bet jis kaip tik atostogauja.

Abiem atvejais rezultatas tas pats: klientui atsakote nebūdami tikri. Dažnai spėjimas pasiteisina. Kartais ne, ir po savaitės tam pačiam klientui tenka skambinti iš naujo.

Štai tikroji kaina. Ne sugaištas laikas. Atsakymas, kurį davėte dar nebūdami tikri.

Sąžiningai apie šaltinį: tai Microsoft produkto duomenys, surinkti iš prie stalo dirbančių darbuotojų už ES ribų. Ir sprendimą, kurį tyrimas rekomenduoja, Microsoft pats ir pardavinėja. Skaičių vertinkite kaip apytikslį.

Jei jūsų komanda dirba ceche ar objekte, žinučių bus mažiau. Bet įrašas - dar prastesnis. Sprendimas, priimtas telefonu ar prie staklių, netampa net žinute, tad ieškoti nėra ko.

Skaičiai su spragomis. Štai kur prasideda tikri pinigai. Ir štai ko niekas nepastebi.

Jei išimtis išsprendžiama susirašinėjime, ji niekada nepatenka į duomenis. Rankinių pakeitimų dažnis, vėlavimų priežastys, nuolaidų dažnis - visi šie rodikliai rodo mažiau, nei yra iš tikrųjų, nes sistema suskaičiavo tik tuos atvejus, kurie tilpo į formą.

Tarkim, ataskaita rodo keturis pavėluotus siuntinius per praėjusį mėnesį. Dar trys irgi buvo pradelsti, bet kažkas laiku pastebėjo, susirašė su klientu, sutarė naują datą ir tą datą įvykdė. Sistema matė tik naują datą, tad tie trys niekada neužsiskaitė kaip vėlavimas.

Pirminės pažadėtos datos nesilaikė septyni užsakymai. Ataskaita rodo keturis.

Keturi atrodo pakenčiamai. Todėl visą ketvirtį tobulinate komplektavimą sandėlyje, o tikroji priežastis - tiekėjas, kuris patvirtina per vėlai - niekur nepasirodo.

Įrašas, kuris išnyksta. Susirašinėjimas turi galiojimo laiką. Duomenų bazės įrašas - ne.

Jei patvirtinimas atsidūrė asmeniniame WhatsApp ar Messenger, jis išeina iš įmonės kartu su žmogumi. Jis lieka jo telefone. Ir jūs neturite jokio pagrindo jo reikalauti.

Net ir tvarkingiausiu atveju įrašai turi galiojimo terminą. Slack leidžia administratoriui nustatyti, kad žinutės būtų automatiškai trinamos (opens in new tab), o nemokamose darbo erdvėse (opens in new tab) komanda mato tik paskutinių 90 dienų istoriją. Tad jei ginčas su tiekėju kyla po penkių mėnesių, patvirtinimo, kuriuo norite pasiremti, jau gali nebūti.

Yra ir ketvirta kaina, apie kurią jau rašėme atskirai, tad tik trumpai: kai sprendimo taisyklė egzistuoja tik vieno žmogaus galvoje ir jo išsiųstose žinutėse, jo atostogos tampa rizika. Apie tai - Kai verslo procesai priklauso nuo vieno žmogaus (opens in new tab).

Patikrinkite paskutines tris išimtis

Prieš ką nors keisdami išsiaiškinkite, ar ši problema jums jau kainuoja. Prisiminkite tris paskutinius atvejus, kurie nuėjo ne pagal tvarką - rankinis pakeitimas, pavėluota siunta, kaina už įprastų ribų, skubus užsakymas. Kiekvienam iš jų atsakykite į keturis klausimus. Naudokitės tik savo sistemomis: kolegų neklauskite, susirašinėjimo neatsidarykite.

1. Kas nusprendė? Ne kas įvedė į sistemą, o kas turėjo teisę spręsti ir ja pasinaudojo.
2. Kada? Laiko žyma, kurią galėtumėte parodyti klientui ar auditoriui.
3. Kodėl? Priežastis, užrašyta taip, kad ją būtų galima suskaičiuoti visuose trijuose atvejuose.
4. Kas pasikeitė toliau? Ar kaina, data ar maršrutas iš tikrųjų atsinaujino ten, kur reikėjo?

Atsakykite sąžiningai. Jei visais trimis atvejais visi keturi klausimai turi atsakymą, jūsų procesai tvarkingesni, nei paprastai matome, ir šis straipsnis ne jums.

Jei bent kartą pagalvojote „reikėtų kažko paklausti", rezultatą jau turite. Įrašas yra susirašinėjime, o tų išimčių nėra nė vienoje ataskaitoje, kuria remiatės.

Kaip perkelti įrašą į sistemą

Tvarkų griežtinimas nepadės. Galite paskelbti, kad kiekviena išimtis turi būti užfiksuota sistemoje, bet jei formoje jai vietos nėra, žmogus turės rinktis: arba atvejo netvarkyti, arba sutvarkyti jį pokalbyje. Rinksis pokalbį - ir bus teisus, nes klientas atsakymo laukia šiandien.

Todėl reikia ne naujos tvarkos, o vietos. Sistema laiko įrašą, pokalbis lieka pokalbiu.

Praktiškai tai keli visai paprasti sprendimai:

• Vienas laukas atsakingam asmeniui, vienas būsenai. Abu privalomi, reikšmės pasirenkamos iš sąrašo.
• Išimties priežastis - pasirenkama reikšmė, ne laisvas tekstas. Penkios-aštuonios parinktys ir „kita". Būtent tai pavienius pasakojimus paverčia skaičiais.
• Laiko žymą sukuria sistema, ne žmogus.
• Nuoroda į patį pokalbį. Kontekstas naudingas, tad pokalbį palikite - jis tik nebėra vienintelė vieta, kur tas sprendimas išlikęs.

Viena taisyklė: viskas, kas keičia tolesnę eigą, privalo būti sistemoje. Viskas, kas tik paaiškina, gali likti pokalbyje.

Ne kiekvienai išimčiai to reikia. Jei toks atvejis pasitaiko vos kelis kartus per metus, nėra susijęs su pinigais, nepatenka į jokią ataskaitą ir niekam toliau procese nesvarbu, ar jis įvyko - palikite pokalbyje ir energiją skirkite kitur. Tai pasakyti mums svarbiau nei parduoti projektą.

Forma turi būti trumpa. Įprastas noras - sukurti detalią išimčių formą su laukeliu viskam. Bet jos niekas nepildo iki galo, tad po poros savaičių visi vėl grįžta į pokalbius. Pradėkite nuo trijų laukų, kuriuos pildo žmogus - atsakingas, būsena, priežastis - ir dviejų, kuriuos sistema užpildo pati: laiko žymos ir nuorodos. Ketvirtą pridėsite tada, kai šie trys taps įpročiu.

Kartą per ketvirtį peržvelkite priežasčių sąrašą. Jei dažniausiai renkamasi „kita", sąraše trūksta vienos parinkties. Jei viena priežastis sudaro trečdalį visų atvejų, tai jau ne išimtis - jos vieta pagrindiniame procese.

AI gali užrašyti sprendimą, bet ne jį priimti

Būtent čia AI operacijose tikrai naudingas, nes problema atitinka tai, ką modeliai iš tikrųjų moka.

Susirašinėjimas yra laisvas tekstas, kurį žmonės rašo kaip patogu. Perskaitęs jį žmogus iškart supranta, kas nutiko. Sistema iš to paties teksto negali ištraukti nieko. Tai ne apsileidimas, kurį pataisytų griežtesni nurodymai - tai kalbos savybė. Ir būtent kalbą paversti duomenimis modeliai moka geriausiai.

Modelis gali perskaityti užbaigtą susirašinėjimą ir pasiūlyti įrašą: išimties tipą, susijusį užsakymą, kas sprendė, dėl ko susitarta, kas keičiasi toliau. Žmogui lieka patvirtinti arba pataisyti vienu paspaudimu.

Tai svarbiau, nei skamba. Žmonės vengia papildomų laukų ne iš principo - jie tiesiog nenori iš naujo rinkti to, ką ką tik paaiškino trimis žinutėmis. Jei įrašas susirašo pats iš pokalbio, nelieka priežasties viską tvarkyti žinutėmis.

Tokį sprendimą jau esame sukūrę. MYGOM Invoices (opens in new tab) taip apdoroja sąskaitas, kurios ateina PDF failais, nuotraukomis, skaičiuoklėmis ir laiškų tekstu iš šimtų tiekėjų, be jokio bendro formato.

Bet spręsti AI čia neturi. Patvirtinimo limitai, nuolaidų ribos ir maršrutų taisyklės yra vienareikšmiai dalykai, tokie ir turi likti. Klausimui „ar galima praleisti 40 000 € užsakymą?" reikia taisyklės, patikros ir įrašo žurnale, o ne tikimybinio atsakymo. Modelį naudokite ten, kur kalba netvarkinga. Paprastą logiką - ten, kur sprendžiama dėl pinigų ir atsakomybės.

Kaip atrodo, kai tai veikia

Kai įrašas yra, diena atrodo kitaip. Klientas klausia, kodėl siunta iškeliavo devyniomis dienomis vėliau. Atsidarote užsakymą ir matote išimtį: priežastį, kas ją patvirtino ir kada. Atsakyti užtrunka pusę minutės, ir nieko nebereikia ieškoti ar prisiminti.

Tas pats įrašas padeda dar dviejose vietose. Išimčių statistika pagaliau atitinka realybę, tad ataskaitos, pagal kurias planuojate, yra apie jūsų verslą. O kolega, kuris susidurs su panašiu atveju, pamatys, kaip buvo išspręstas praėjęs, ir jam nereikės nieko klausti.

Nežinote, ar jūsų sprendimai lieka sistemoje, ar pokalbiuose?

Ankstesnis testas padės pamatyti, ar problema yra. Ką su ja daryti - klausimas sunkesnis. Ne kiekvieną situaciją verta tvarkyti, o iš šalies tai dažnai matosi geriau.

Tam ir sukūrėme nemokamą trijų minučių diagnostiką (opens in new tab). Ji padeda atskirti, ar jums reikia AI, ar užtenka sklandesnio proceso, ar tiesiog reikia sujungti sistemas, už kurias jau mokate.

Jei norite tiesiog pasikalbėti - susisiekite (opens in new tab). O jei norite pamatyti, kaip tokius dalykus sprendžiame, skaitykite apie AI diegimą ir automatizavimą (opens in new tab).