Nuo to, kas nutiko, iki darbo, kuris padeda

Slack, Teams, kasos, darbuotojų grafikų programos, rodiklių lentelės, failai, užduočių sistemos, darbuotojų pastebėjimai ir turimi žinynai gali būti naudingi šaltiniai. Jie suteikia daug informacijos apie tai, kas nutiko.

Toliau kyla sunkesni klausimai: kurie pastebėjimai susiję, kokia priežastis juos geriausiai paaiškina, koks atsakas tinka, ką daryti pirmiau, kiek komanda pajėgi prisiimti, kuo patvirtinti atlikimą, ar situacija pagerėjo ir ką prisiminti kitą kartą.

Įprastas pokalbių asistentas iš tų pačių duomenų gali paruošti kelis įtikinamus planus. SANDR šį lankstumą naudoja pokalbiui, klausimams ir paaiškinimams. O USOOSR atskirai išlaiko pastovius įrašus, aiškius ryšius, pakartojamas taisykles ir teisę nuspręsti.

Rodiklių lentelės — pagrindas spręsti, o ne galutinis tikslas

1. Atsiranda poreikis. Jį sukuria klientas, pacientas, svečias, maršrutas, objektas ar darbo užsakymas.
2. Duodamas pažadas. Organizacija įsipareigoja dėl laiko, kokybės, rezultato ar aptarnavimo standarto.
3. Paskirstoma, ką turime. Skiriami žmonės, laikas, įranga, erdvė ir dėmesys.
4. Komanda pasiruošusi arba ne. Informacija, įgūdžiai, paruošimas ir atsakomybė arba yra, arba jų trūksta.
5. Vyksta darbas. Paslaugą atlieka skirtingi žmonės, perimdami vieni kitų darbus ir priimdami sprendimus.
6. Perdavimai pavyksta arba stringa. Informacija ir atsakomybė keliauja tarp žmonių, pamainų, komandų ar vietų.
7. Kokybė išlieka arba svyruoja. Standartai stabilūs arba priklauso nuo asmeninių pastangų.
8. Atsiranda išimčių. Paklausos šuoliai, neatvykimai, gedimai ir klaidos išbando veiklą.
9. Atsigauti pavyksta arba ne. Organizacija suvaldo išimtį, improvizuoja, kreipiasi pagalbos arba praranda kontrolę.
10. Pamoka lieka arba dingsta. Kitą kartą komanda pasinaudoja patirtimi arba daro tą patį iš naujo.

Nesakome, kad visos sritys veikia vienodai. Mintis paprastesnė: daugeliui paslaugų verslų praverčia tas pats kelias nuo faktų iki pasikartojančios problemos, sprendimo, darbų, jų patvirtinimo, rezultato ir pamokos.

Todėl metodas aktualus gyvam aptarnavimui, rezervacijoms, išvykstamajam darbui, objektų valdymui ir kelių vietų grupėms.

4.1 Įvykiai skirtingi. Po jais slypinti problema dažnai ta pati.

Paslaugų versluose daug pažįstamų situacijų: svečių daugiau nei komanda pajėgia aptarnauti, neaiškūs lūkesčiai, nepasiruošta pamainai, neaiškios atsakomybės, neperduoti darbai, nevienodi standartai, mokymo ar priežiūros spragos, įrangos bėdos ir pamirštos pamokos.

SANDR grupuoja pasikartojančias problemas, užuot kiekvieną įvykį laikiusi visiškai nauju.

4.2 Rekomendacija turi parodyti savo priežastį.

Patarimas stipresnis, kai sistema išsaugo jį paaiškinančius faktus ir ryšius.

4.3 Pokalbio asistentas neturi spręsti, kas ką gali matyti ar keisti.

Pokalbio asistentas padeda parinkti žodžius, paaiškinti ir rasti informaciją. Tačiau prieigą, tapatybę, patvirtinimus, atlikimo įrodymus ir leidžiamus pakeitimus valdo aiškios programos taisyklės.

4.4 Atsakymas turi atitikti darbų eilę ir komandos galimybes.

Net tinkamas veiksmas gali nepadėti, jei imsitės jo per anksti. Plane turi būti matyti, ką komanda pajėgs atlikti ir ką būtina padaryti pirmiau.

4.5 Mokymasis turi likti susietas su rezultatais.

Užduoties užbaigimas rodo atliktą darbą. Rezultatas – pokytį. Keli tvirti rezultatai gali pagrįsti tobulinimą ateityje. Nė vienas žingsnis savaime netampa tiesa.

Grandinė:

Tai, kas kartojasi, dar nepaaiškina priežasties. Pasiūlymas dar nėra darbas, o atliktas darbas dar neparodo jo naudos. Vienas rezultatas savaime dar nėra pamoka ateičiai.

Aiškūs skirtumai padeda SANDR suprasti ir ja pasitikėti.

Keturi klausimai:

1. Kokių faktų turime?
2. Kas juose kartojasi?
3. Kokia problema geriausiai tai paaiškina?
4. Koks sprendimas tinka faktams ir šiai situacijai?

Dabartinė kavinių versija eina tuo pačiu keliu: sutvarko faktus, atpažįsta pasikartojimus, palygina tikėtinas problemas, parenka sprendimus ir priemones, įvertina praktines ribas ir sudaro planą.

Svarbu, kad kelias būtų pakartojamas. SANDR neturi kiekvieną kartą iš naujo išgalvoti viso metodo.

6.1 Kai faktai nesutampa

Verslo faktai dažnai nepilni arba prieštaringi. Vadovas gali teigti, kad standartas yra, o darbuotojų pastebėjimai rodyti, kad jis taikomas nevienodai. Viena pamaina gali būti stabili, kita – nuolat strigti tame pačiame perdavime.

Kai faktai prieštarauja, SANDR turi sumažinti tikrumą, paaiškinti neatitikimą ar paprašyti informacijos. Nežinomybė negali dingti vien todėl, kad atsakymas skamba užtikrintai.

SANDR gali parodyti pasiūlymą pagrindžiančius faktus ir ryšius. Tai neįrodo priežasties moksliniu tikrumu. Ryšių stiprumą reikia tikrinti pagal tikrus rezultatus.

Ši dalis paaiškinimą paverčia pakartojamu darbu.

7.1 Nepradėti nuo nulio

Žinomas sprendimas leidžia pasiūlyti vietai pritaikytus žingsnius ir priemones. Veiksmų gide matyti, kada jis tinka, ką padaryti pirmiau, kuo patvirtinti atlikimą, kiek reikės pastangų ir kaip tai susiję su kitais darbais.

7.2 Darbų eilė ir komandos galimybės — atsakymo dalis

Komanda negali laikytis neaiškios perdavimo tvarkos, išmokti standarto, kurį vadovai taiko skirtingai, ar patikrinti pokyčio be atsakingo žmogaus. Todėl SANDR dėlioja darbų eilę ir renkasi mažesnį, įgyvendinamą etapą, o ne milžinišką planą, kurio niekas nepajėgs atlikti. Planas turi tilpti į komandos galimybes.

SANDR išsaugo planus, užduotis, atsakomybes, datas, komentarus, ankstesnius būtinus darbus, failus, aptarimus, patvirtinimus ir rezultatus. Darbas lieka susietas su problema, dėl kurios atsirado, ir pasirinktu sprendimu.

8.1 „Atlikta“ nėra tas pats, kas „patikrinta“

Dauguma darbo programų leidžia pažymėti užduotį atlikta. SANDR atskiria žymą „atlikta“ nuo patikrintos reikiamos būklės.

Kai patvirtinimas svarbus, jo galima reikalauti, jį pateikti, peržiūrėti, priimti, atmesti, pateikti iš naujo arba įgaliotam žmogui sąmoningai jo atsisakyti.

Tai nereiškia, kad patvirtinimo reikia kiekvienai užduočiai. Jis prieinamas tada, kai darbą tikrai būtina patikrinti.

Šis skirtumas saugo mokymąsi. Mokydamasi iš klaidingai užbaigtos užduoties sistema galėtų rekomenduoti sprendimą, kuris iš tiesų net nebuvo išbandytas.

8.2 Užbaigimas nėra rezultatas

Patvirtinimas klausia, ar sutartas darbas įvyko. Rezultatas – kas pasikeitė po jo.

Nauja perdavimo tvarka gali būti visiškai įdiegta ir vis tiek nesumažinti klaidų. Tai naudinga pamoka. SANDR atskiria atliktą darbą nuo pagerėjusio verslo.

Mokymasis kelia svarbų klausimą: kas gali veikti būsimus patarimus ir kiek pagrindimo pakanka? SANDR šį kelią parodo aiškiai:

Galima pamoka lieka susieta su faktais, atlikimo patvirtinimu, rezultatu ir prieštaraujančiais duomenimis. Viena pamoka pati produkto nekeičia: būsimoms rekomendacijoms reikia tvirtesnio pagrindimo ir žmogaus peržiūros.

9.1 Kai vėlesni faktai prieštarauja

Tarkime, SANDR atpažino perdavimo problemą, darbai atlikti, vadovas pasakė, kad padėjo. Tai naudinga, bet dar ne visas rezultatas. Jei vėlesni aptarimai rodo tą pačią problemą, teigiamas atsakymas neturi tapti patikima pamoka.

Pamoką turi pagrįsti peržiūrėti faktai, o ne viltis. Išlaikę ryšį tarp faktų, darbų ir rezultatų galime lyginti panašias situacijas ir siūlyti pakeitimus. Nereikia apsimesti, kad programa pati savaime tampa išmintingesnė.

Kiekvienai sričiai reikia savo žodyno, pareigybių, rodiklių ribų, pavyzdžių, šablonų, darbų patvirtinimų, išteklių, žinių ir patikrų.

Srities pritaikymas gali keisti kalbą ir pavyzdžius. Tačiau jis negali perimti bendrų paskyrų, teisių, patvirtinimų ar sprendimo, kokias pamokas naudoti ateityje.

Dabartinis produktas parodo, kad šis atskyrimas gali veikti programoje. Jis neįrodo, kad kiekviena būsima sritis tiks nepakeitus branduolio. Platesnį teiginį dar reikia patikrinti.

12.1 Sprendimo istorija

USOOSR išsaugo susijusius faktus, pasikartojimus, pasirinktą sprendimą, priemones, darbų eilę, patvirtinimo reikalavimus, prieštaravimus, tikrumo įvertinimą ir įvykius. Todėl SANDR gali paaiškinti, kodėl ką nors rekomendavo.

12.2 Aiškūs etapai

Svarbūs įrašai pereina apibrėžtus etapus. Vien pakeisti jų pavadinimą neužtenka. Programos taisyklės neleidžia praleisti būtinų ar saugumui svarbių žingsnių.

12.3 Pakeitimų įrašas

Svarbūs pakeitimai gali fiksuoti kas, kur ir kodėl juos atliko bei iš kurio sprendimo jie kilo. Taip dabartinis įrašas atskiriamas nuo jo keitimo istorijos.

12.4 Juodraštis ir patvirtintas turinys

USOOSR atskiria pasiūlymą nuo patvirtintos informacijos. SANDR gali paruošti ir paaiškinti pakeitimą, bet pasiūlymas ar galima pamoka netampa patikima tiesa vien dėl to, kad programa ją parašė.

Šie valdikliai nėra saugumo sertifikatas. Tai praktinės apsaugos, kurias galima tikrinti ir stiprinti produktui augant.

USOOSR išlaiko pastovų būdą suprasti problemas, naudoti žinomus sprendimus, dėlioti įgyvendinamus darbus ir tikrinti jų naudą. SANDR leidžia tuo naudotis paprastame pokalbyje, pagal aiškias prieigos teises.

14.1 Ar SANDR supranta problemą?

Ar atpažįsta tai, kas kartojasi, randa tikėtinas priežastis, parodo prieštaraujančius faktus ir neapsimeta žinanti daugiau, nei žino?

14.2 Ar pasirenka naudingą atsaką?

Ar žingsniai ir priemonės tinka? Ar aišku, ką atlikti pirmiau? Ar komanda pajėgs įgyvendinti planą?

14.3 Ar darbai tinkamai užbaigiami?

Ar atsakomybės, grafikas, patvirtinimai ir peržiūra padeda nueiti iki pabaigos? Ar SANDR skiria „pažymėta atlikta“ nuo „patikrinta“?

14.4 Ar situacija pagerėjo?

Ar pasirinktas darbas išmatuojamai pagerina pradinę situaciją? Kurie pokyčiai lieka, kurie atsitraukia?

14.5 Ar verslas išmoksta teisingą pamoką?

Ar galimos pamokos lieka susietos su pradiniais faktais? Ar siūlomos korekcijos tinka panašioms situacijoms? Ar žmogaus peržiūra sustabdo silpnų faktų įtaką būsimoms rekomendacijoms?

14.6 Ar tai nuosekliai veikia skirtingose vietose?

Ar panašios problemos atpažįstamos vienodai, o vietinės aplinkybės vis tiek lemia tinkamą atsaką? Ar bendras tinklo vaizdas sumažina pakartotinį tos pačios problemos atradimą?

Nepasitvirtinusi idėja irgi naudinga. Produktą turi tobulinti faktai, o ne spaudimas pritaikyti visas rinkas pradinei minčiai.

Ką dabartinis produktas gali pagrįsti:

• USOOSR kelią, jungiantį faktus, problemą, atsaką, atlikimo patvirtinimą, rezultatus ir mokymąsi;
• pakartojamą kavinių problemų peržiūros ir planavimo metodą;
• veikiančius sprendimų istorijos, patvirtinimų, galimų pamokų, leidimų, teisių ir sričių gidų įrašus;
• talpinamą SANDR programą, kuri skaito ir keičia tik leistiną produkto informaciją;
• vieną bendrą pagrindą su sričiai pritaikyta kalba ir pavyzdžiais.

Ko šiandien neturime vadinti įrodyta:

• kad metodas veikia visuose sektoriuose;
• kad USOOSR moksliškai tiksliai įrodo priežastį;
• kad veikiantis produktas tobulina save be žmogaus peržiūros;
• garantuoto mokymosi pranašumo tarp klientų;
• garantuotų verslo rezultatų;
• saugumo sertifikavimo vien dėl produkto sandaros;
• savarankiško vadovo, pakeičiančio žmogaus sprendimo teisę.

Taisyklė paprasta: pasitikėjimas turi augti tik stiprėjant pagrindžiantiems faktams.

Svetingumo versle galime išsamiai tikrinti, ar supratome problemą, tinkamai sudėjome darbus, juos atlikome ir gavome rezultatą. Kelių vietų grupės padeda patikrinti pasikartojimą, nuoseklumą ir kiekvienos vietos aplinkybes. Toliau reikėtų bandyti panašius susitarimo sunkumus turinčius, bet pakankamai skirtingus paslaugų verslus. Tik taip sąžiningai patikrinsime metodo ribas.

Kiekvienai naujai sričiai aiškiai klausiame:

1. Ar ta pati susieta grandinė išlieka prasminga?
2. Kurie problemų dėsningumai perkeliami, o kurie iš tiesų būdingi tik šiai sričiai?
3. Kurie atsakai perkeliami?
4. Kokie nauji patvirtinimo ar teisiniai reikalavimai atsiranda?
5. Ar darbų eilės ir komandos galimybių vertinimas vis dar naudingas?
6. Ar rezultatus galima lyginti neprarandant konteksto?
7. Ką, jei apskritai reikia, keisti bendrame pagrinde?

Ilgesnė galimybė — bendras USOOSR pagrindas, padedantis išsaugoti praktinę verslo patirtį skirtingose paslaugų srityse. Tam neužteks vien pakeisti kelis žodžius.

17.1 Autorystė ir statusas

Leidėjas – SANDR, autorius – įkūrėjas ir vadovas Matas Paulinas. Aprašas remiasi svetingumo metodu ir kūrimo darbu, suformavusiu dabartinę SANDR bei USOOSR. Klausimus ir peržiūros prašymus siųskite gm@sandr-ai.com.

Tai viešas produkto ir tyrimų aprašas apie USOOSR po SANDR. Jis pristato dabartinį metodą ir tikrinamus klausimus. Tai nėra recenzuotas mokslinis tyrimas, nuomonė dėl patentų, saugumo sertifikatas, investavimo rekomendacija, teisinis atstovavimas ar įrodymas, kad metodas veikia visur.

17.2 Viešas produkto pagrindas

1. SANDR programa — dabartinis viešas programos, pokalbio, vietos aplinkybių, darbų, jų patvirtinimų ir valdymo erdvių aprašas.
2. Praktinis žinynas — viešas paaiškinimas apie sritis, temų grupes, veiksmų gidus, L1/L2/L3 etapus, priemones, darbų patvirtinimus, rizikas ir susijusius darbus.
3. SANDR pagalbos centras – dabartinė pagalba dėl pasiruošimo, kasdienio naudojimo, vaidmenų, balso, failų, kreditų, valdiklių ir nesklandumų.
4. Saugumas ir duomenys – viešos saugumo, duomenų aptarimo, incidentų pranešimo ir bandomųjų projektų skaidrumo ribos.
5. Investuotojams – atskiras įmonės, rinkos, finansavimo ir patikros pagrindimas. Šios temos sąmoningai nekartojamos metodo apraše.

USOOSR prasidėjo nuo svetingumo verslo problemų analizės ir išaugo į platesnę veikiančią tvarką: darbų eilę, patvirtinimus, sprendimų istoriją, teises, pritaikymą sritims ir pamokų naudojimo ribas. Veikianti SANDR programa rodo, kad tai ne vien mintis lentoje — joje jau yra problemų peržiūra, planai, išsaugomi darbai ir pokalbiai.

Tačiau didžiausius ilgalaikius pažadus dar reikia patikrinti. USOOSR dar neįrodė vienodos naudos skirtingose srityse, automatinio ilgalaikio mokymosi ar garantuotai teisingų priežasčių. Tam reikia daugiau tyrimų ir didesnio masto bandymų.

Šiandien galime pasakyti siauriau:

SANDR — programa ir pokalbio erdvė. USOOSR — tvarka, kuria ji remiasi. Žmogus turi galėti papasakoti, kas nutiko, peržiūrėti SANDR supratimą, patvirtinti atsaką ir toliau valdyti verslą. SANDR rūpinasi kalba, patikslinimu, paaiškinimu ir navigacija. USOOSR išlaiko struktūrą, seką, įrašus, patvirtinimus, teises ir mokymosi ribas. Tiesos vertinimas ir sprendimo teisė lieka žmonėms.

Dauguma verslo programų prisimena veiksmus. USOOSR siekia padėti verslui prisiminti kas nutiko, ką laikėme gilumine problema, ką keitėme, ar pakeitimą iš tiesų atlikome, ar jis padėjo ir ką turi žinoti kitas vadovas.

SANDR – paprastas pokalbis. USOOSR – sutvarkyta verslo atmintis po juo.