Įžanga: Adrenalino ir kofeino atgarsis
Andrzej Kinastowski (AK): Konnichiwa! Sveiki atvykę į AI automatizacijos Dojo, kur nagrinėjame verslo konferencijų pasaulį ir klausiame – ar visa tai negalėjo būti tiesiog el. laiškas? Na, mes nusprendėme surengti tokią, kuri negalėjo. Šiandien mėgaujamės mūsų trečiosios „Samurai and Friends“ konferencijos atgarsiu. Išgirsite dviejų „Office Samurai“ įkūrėjų balsus, kurie šiuo metu veikia pavojingame adrenalino ir kofeino derinyje. Esame čia tam, kad išnarstytume, kas nutinka, kai sukuriate išmaniosios automatizacijos konferenciją, kuri gerbia kiekvieno protą. Aš esu jūsų vedėjas Andrzej Kinastowski, vienas iš „Office Samurai“ įkūrėjų – įmonės, kuri nusprendė surengti konferenciją ir iš tikrųjų padaryti ją naudingą. Įsivaizduokite tai. Tad nesvarbu, ar buvote ten ir norite dar kartą išgyventi šlovės akimirkas, ar praleidote ir dabar skęstate FOMO – esate tinkamoje vietoje. Dabar pasiimkite savo mėgstamą kataną arba tą dovaninį rašiklį, kurį tikrai pasiėmėte iš registracijos stalo, ir kibkime į darbą. Praėjusią savaitę turėjome trečiąją savo kasmetinę „Samurai and Friends“ konferenciją. Dominikai, kaip jautiesi – kaip pavargęs esi? Ar jau atsigavai?
Dominik Jaskulski (DJ): Andrzej, visų pirma turėčiau paklausti tavęs – kokia konferencija? Oficialiai jokios konferencijos nebuvo. Nėra jokio tinklalapio, kuriame galėtum nueiti ir nusipirkti bilietus. Tai tik kvietimais pagrįstas renginys, į kurį kviečiame savo draugus – daugiausia vadovaujančias, direktorių ar aukščiausio lygmens pareigas einančius žmones – pasikalbėti apie dirbtinį intelektą, automatizaciją ir procesų tobulinimą. Ir jaučiuosi šiek tiek išsekęs, bet patenkintas.
(AK): Galiausiai turėjome apie 160 žmonių ar panašiai. Turėjome tikrai smagų vakarėlį po renginio, kuris, mano manymu, yra gana svarbus, žinoma. Ir klausimas, kurį sau dažnai užduodu iškart po konferencijos, yra – kodėl mes tai darome?
(DJ): Rengiame šį renginį todėl, kad rinkoje kyla daug triukšmo apie tai, kas potencialiai įmanoma su dirbtiniu intelektu. Gali matyti tuos „LinkedIn“ įrašus su 500 DI panaudojimo atvejų, kurie iš esmės nieko nereiškia, tiesa? Jei giliau pasižiūrėtum, tikriausiai jie patys sukurti DI, o ne paremti realiais pavyzdžiais. Taigi norėjome pamatyti, kas vyksta rinkoje, kas įmanoma, kokius projektus vykdo skirtingos įmonės ir taip pat kokių nesėkmių jos patiria projektų metu. Manau, tai buvo įdomi dalis – ir tai labai retai sutinkama konferencijose, tiesa? Kad pranešėjai taip pat parodytų, kas nepavyko, arba kaip, jų manymu, reikia pakeisti projekto kryptį. Tad, manau, didžiausia šios konferencijos vertė buvo ta, kad ji buvo apie tikrus dalykus, tikrus projektus.
(AK): Manau, tai yra vienas iš dalykų, ir mes tai matome apklausose, kurias pildo dalyviai – visų pirma, žinoma, buvo laikomasi taisyklės „be nesąmonių“. O žmonės, kurie kalba, yra tie, kurie iš tikrųjų daro darbus ir nori pasidalyti savo istorijomis.
(DJ): Tiesiog norėjau pridurti, kad nebuvo jokių kalbų apie DI programų planus, DI veiklos žemėlapius ar kitokį konsultacinį „šlamštą“, tiesa? Visa tai buvo apie realius projektus, kurie iš tikrųjų įvyko, ir kokias pamokas žmonės iš jų išmoko.
Technologijos ir partneriai
(AK): Konferencijoje turėjome gana daug įvairių technologijų, nors jau matome, kad, pavyzdžiui, RPA pasaulyje kai kurie tiekėjai šiek tiek atsiliko, kai kalbama apie dirbtinį intelektą. Tačiau mums labai pasisekė turėti įmones, kurios su mumis bendradarbiavo ir mus rėmė. Turėjome „UiPath“ ir „KYP.ai“. „Aspire“ padėjo mums su konferencija ir skleisti žinią apie ją. Ir, žinoma, turėjome „Shock“, kurie kasmet paruošia puikią scenografiją ir pasirūpina visomis techninėmis detalėmis. Tai, ką jie padarė šiais metais – kai visos salės spalvos buvo sinchronizuotos su pagrindine pristatymo spalva – manau, buvo vienas iš tų mažų dalykų, kurių niekur kitur nepamatysi.
(DJ): Ir manau, kad taip pat turime paminėti, jog konferencija buvo tokia karšta, kad net kilo gaisras, tiesa?
(AK): O taip. Iš tiesų kilo gaisras. Tai nebuvo tyčia, bet labai greitai pavyko jį suvaldyti, tačiau taip – jis tikrai buvo.
Pirmos dienos akcentai
(AK): Taigi tu buvai pirmos dienos vedėjas, viską laikėi kontroliuojamai ir pagal grafiką. Pradėjome nuo mano pagrindinio pranešimo apie žaidimų industriją. Kokių minčių apie tai turi?
(DJ): Taip, mane tikrai nustebino ir sudomino, ką norėjai perkelti iš žaidimų industrijos į DI automatizacijos sritį. Esu tikras, kad padarysime atskirą tinklalaidės epizodą šia tema, todėl turbūt neverta dabar gilintis.
Pristatymas 1: Agentinė automatizacija (Krzysztof Karaszewski iš AgenciAI.biz)
(AK): Tuomet turėjome Krzysztofą Karaszewskį iš „AgenciAI.biz“. Jo tema buvo „Naujoji riba: kas įmanoma su agentine automatizacija“, ir mes Krzysztofą pažįstame jau seniai. Ką manai?
(DJ): Na, sakyčiau, ji labai skyrėsi nuo kitų prezentacijų, kurios buvo sutelktos į projektus. Krzysztofas parodė, kas šiuo metu įmanoma su dirbtiniu intelektu, ir kaip greitai tobulėja modeliai. Iš jo pristatymo pasiėmiau dvi pamokas:
- Dabar LLM nėra toks svarbus, tiesa? Nes po mėnesio atsiras naujas LLM, kuris galbūt išspręs problemas, su kuriomis anksčiau susidūrei. Tad nesvarbu, ar naudoji „ChatGPT“, „Claude“, „Gemini“ ar bet kurį kitą. Manau, daug svarbiau yra tai, kad tavo organizacija turėtų prieigą prie šių bazinių modelių.
- Antroji pamoka susijusi su užklausų formulavimu, tiesa? Reikia klausti DI, kaip DI galėtų mums padėti tinkamai suformuluoti klausimą kitam DI.
(AK): Tai dalykas, kuris daugeliui žmonių buvo labai įdomus, nes jei tuo užsiimi, tau tai jau savaime aišku, bet jei to nesi daręs anksčiau, tai tarsi „aha“ akimirka – gali paprašyti LLM sukurti užklausą kitam LLM, ir jis tai daro tikrai labai gerai. Vis dėlto vis tiek turi žinoti, ko iš jo nori gauti.
(DJ): Turiu omenyje, tai taip pat priklauso nuo to, ko nori iš LLM, tiesa? Jei klausi LLM, koks yra aukščiausias kalnas pasaulyje, tikriausiai nereikia jokių specialių užklausų kūrimo technikų. Bet jei nori, kad LLM atliktų kažką sudėtingesnio, tikro, tada turėtum labiau susitelkti į savo klausimo kokybę. Manau, jis tai pavadino meta-užklausomis.
(AK): Meta-užklausos. Taip, teisingai. Kitas dalykas, kuris man buvo gana įdomus – tai jo eksperimentai, kaip naudoti LLM procesų analizei. Apie tai mūsų įmonėje nemažai kalbėjome. Tai mums labai padėtų. Šiuo metu tai tarsi sėkmės ir nesėkmės derinys – kai kas veikia, o kai kas ne taip gerai, kaip norėtume.
(DJ): Be abejo, ką dabar matau – mūsų analitikai labai aktyviai naudoja DI susitikimų užrašams, santraukoms ir tolimesniems veiksmams, tiesa? Tad tai vis dar padeda. Tačiau jei DI galėtų nupiešti visą proceso žemėlapį beveik be klaidų, arba bent jau atlikti 80 % darbo – tai būtų tobula, tiesa? Bet, manau, iššūkis tas, kad tokie sprendimai gerai veikia, kai turi „laimingą kelią“, bet kai atsiranda daug išimčių, kai reikia grįžti prie ankstesnės proceso dalies ar pridėti kažką daugiau – tuomet DI daug sunkiau su tavimi suspėti.
(AK): Taip, turiu omenyje, jei tai sunku žmonėms, tai dar sunkiau DI. O dauguma procesų, su kuriais susiduriame, jau seniai nebėra paprasti ir tiesūs „laimingo kelio“ procesai. Be to, Krzysztofas turi daug įdomių įrašų „LinkedIn“. Tad raginame visus pasižiūrėti, ką jis rašo – jis visada stengiasi peržengti ribas, ką DI gali nuveikti.
(DJ): Yra dar vienas dalykas, kurį prisimenu iš Krzysztofo pristatymo. Jis lygino UI agentus, tiesa? Tai agentai, kurie, užuot veikę kaip klasikiniai RPA robotai su selektoriais, kur tu nurodai robotui, ką daryti žingsnis po žingsnio programoje, dabar su LLM koncepcija gali veikti kitaip – gali tiesiog duoti užklausą LLM: „ei, užsakyk man skrydį į Dubajų kitą savaitę“ arba „ei, noriu naujos riedlentės, parink geriausią riedlentę mano vidutinio lygio įgūdžiams ir nupirk ją man“. Yra keletas pavyzdžių rinkoje, kur LLM gali, pavyzdžiui, užsakyti tau picą. Tačiau kai kalbame apie tikrus verslo procesus ir tu paprašai LLM: „ei, noriu įdarbinti Andrzej savo įmonėje, susisiek su juo ir įdarbink“, LLM gali kilti sunkumų suprasti, ką konkrečiai reikia padaryti, kad tave įdarbintų. Krzysztofas taip pat rodė palyginimą, kaip, jo manymu, „Claude“ ir jų agentinė UI sistema veikia skirtingose programose, ir man tai buvo labai įdomu – LLM mokosi programos pagal elementų padėtis, tiesa? Taigi jis identifikuoja mygtukus ir tada žino, kad reikia nueiti 200 pikselių žemyn, 100 pikselių į kairę ir paspausti kitą mygtuką, tiesa? Bet kas, jei pasikeis raiška, jei pasikeis sąsaja? Todėl jis taip pat lygino tai, man atrodo, su „UiPath“ UI Vision ar UI Agent, kažkuo panašiu, kur agentas vis dar gauna pagrindinę užklausą, ką reikia padaryti, bet veikia su selektoriais, tiesa? O ne pagal mygtukų pozicijas – kas yra įdomu ir, kiek pamenu, daug greitesnis metodas.
(AK): Taip, bet praeis dar tikrai labai daug laiko, kol leisime agentams patiems spaudinėti dalykus mūsų sistemose, tiesa? Tai technologija, kuri dar turi nueiti ilgą kelią, kad galėtume būti tikri – jei apdoroji dešimtis tūkstančių atvejų, leisti agentui kiekvieną kartą pačiam priimti sprendimą nebūtų efektyvu, tiesa? Be to, šiuo metu tai būtų gana rizikinga.
(DJ): Ir, manau, mažoms įmonėms ar privatiems asmenims, kurie gali prisiimti riziką, tai nebūtų problema, tiesa? Bet didelėms korporacijoms, kuriose nori, kad DI laikytųsi nustatyto proceso, tai gali būti iššūkis. Ir ši tema iš tikrųjų kartojosi skirtinguose pranešimuose – klausimas, kaip užtikrinti, kad DI, ypač generatyvusis DI, nedarytų kvailų dalykų.
Pristatymas 2: El. pašto automatizacija su DI („Kingfisher“)
(AK): Tuomet turėjome Dariuszą Procyką ir Mirosławą Rodzeń iš „Kingfisher“. Tiems, kurie nežino, „Kingfisher“ logotipą Lenkijoje atpažinsite pagal „Castorama“ parduotuves, o Jungtinėje Karalystėje – pagal „VNQI“. Tai labai didelė tarptautinė įmonė, ir turėti tiek daug parduotuvių savaime yra iššūkis. Jų pranešimo pavadinimas buvo „Brangus el. laiške, mums reikia pasikalbėti – el. pašto automatizacija su DI“. Tai projektas, kurį iš tikrųjų vykdome kartu su jais, todėl turime vidinį supratimą, kas ten vyksta. Jie gauna apie 30 000 el. laiškų per mėnesį į savo bendras finansų pašto dėžutes. Ir kažkas juk turi tuos laiškus apdoroti, tiesa?
(DJ): Ir juk kalbama ne apie vieną pašto dėžutę, tiesa? Nes, jei gerai prisimenu, jų yra daugiau nei 40. Tad yra skirtingos komandos, skirtingos kalbos. Todėl negali tiesiog sukurti paprastos formos ir visiems pasakyti: „oi, dabar turite užpildyti formą, o mes tai tvarkysime kaip paslaugos užklausą“, pavyzdžiui.
(AK): Ir visa ši istorija buvo apie tai, kaip kartu sukūrėme sistemą, paremtą daugybe skirtingų komponentų, tačiau pagrindinis DI komponentas buvo komunikacijų analizė. Komunikacijų analizės užduotis buvo paimti el. laišką, susisteminti duomenis ir išgauti informaciją, kurios reikia robotams tiems procesams atlikti. Buvo nemažai įdomių pavyzdžių, kai net žmonėms tokius laiškus būna sunku apdoroti. Jie ne visada turi visą reikalingą informaciją, kartais parašyti labai keistu būdu, o kartais tai tiesiog atsakymas į senesnį el. laišką – penkiais laiškais anksčiau nei dabartinė užklausa. Iš tikrųjų prisimenu du pavyzdžius:
- Vienas pavyzdys buvo el. laiškas su tekstu: „Ei, prašau padaryk man tą patį, ką darei praėjusią savaitę.“ Ir tu iš tiesų turi pažinoti šį žmogų bei surasti jo ar jos ankstesnę užklausą, kad suprastum, ko jie nori.
- Kitas pavyzdys buvo su nuotrauka, tiesa? Kažkas tiesiog atsiuntė nuotrauką su informacija apie elektros suvartojimą parduotuvėje. Tiesiog nuotrauką – ir tai buvo visas laiško turinys, tiesa? O užduotis buvo finansinėje sistemoje užregistruoti, kiek elektros buvo sunaudota tam tikrą mėnesį.
(AK): Taigi tai puikūs pavyzdžiai, kaip teorija susitinka su praktika, ir matome, kad šios technologijos labai pažengė į priekį – komunikacijų analizė yra puikus įrankis, ir mums pavyko sėkmingai jį pritaikyti. Tačiau tam tikruose projektuose šios technologijos šiuo metu tiesiog nebepakanka. Ir iš esmės tokia buvo visa istorija – dabar svarstome naudoti LLM modelius šiems el. laiškams apdoroti, nes dėl jų sudėtingumo komunikacijų analizės įrankio jau nebeužtenka. Bet, žinoma, naudojant LLM kyla ir savų iššūkių – pavyzdžiui, tu negauni patikimumo įvertinimo (confidence score), kuris tokio tipo procesuose yra itin svarbus.
(DJ): Tiems, kurie nežino, kas yra komunikacijų analizė, nes kai kurie mūsų klausytojai galbūt pirmą kartą girdi šį terminą – tai metodas, kai mokymo modelis apmokomas pagal gana didelį kiekį el. laiškų, kad išmoktų, ką su jais daryti: kaip juos suskirstyti į skirtingas kategorijas, kaip iš jų išgauti reikiamą informaciją. O su LLM tai visiškai kitoks požiūris – tu tiesiog pateiki užklausą, kad modelis pats suprastų, apie ką yra laiškas, ir belieka tikėtis geriausio rezultato.
(AK): Taip, tikrai įdomi technologija. Esu tikras, kad turėsime atskirą epizodą šia tema. Šiuo metu nėra tobulų sprendimų, kai kalbame apie el. laiškų ar užklausų apdorojimą. Pamatysime, kur mus nuves technologija. Bet, manau, šis pranešimas buvo labai vertingas iš to požiūrio, kurį tu paminėjai anksčiau – puiku kalbėti apie tai, kas pavyko, tačiau galbūt dar svarbiau kalbėti apie tai, kas nepavyko, kad kitiems nereikėtų kartoti tų pačių klaidų, kurias darėme mes.
Pristatymas 3: Skaitmeninės sąveikos analizė („SPS Hungary“)
(AK): Tuomet turėjome Gáborą Körmendi iš „SPS Hungary“. Jo pranešimo tema buvo „Skaitmeninės sąveikos analizė: „SPS Hungary“ atvejis“. Jie pasakojo, kaip savo organizacijoje naudoja „KYP.ai“, tiesa? Dominikai, tu gana daug dirbi su „KYP.ai“.
(DJ): „SPS“ – tiems, kurie nežino šios organizacijos – yra BPO įmonė, taigi iš esmės jie teikia išorines paslaugas. Anksčiau tai buvo „Swiss Post Services“, priklausanti „XC“ grupei, o dabar tai atskira organizacija. Ir, žinoma, jie turi daug pasikartojančių užduočių. Jie vykdo procesus daugeliui klientų, daugiausia iš Vokietijos. Jie turi registruoti darbo laiką, tiesa? Tarkime, Andrzej, tu praleidi 2 valandas dirbdamas prie tam tikro proceso, pavyzdžiui, „BMW“. Tuomet reikia išsiųsti sąskaitą šiai įmonei už tas dvi tavo darbo valandas. Anksčiau žmonės tai darydavo rankiniu būdu – pasirinkdavo, kad dabar dirba su įmone A ir atlieka tokį procesą, o dabar su įmone B ir kitą procesą. Ir su „KYP.ai“ mes iš tikrųjų sužinojome, kad žmonės apie 4 % savo laiko praleidžia vien tam, kad pasirinktų, kokį procesą jie atlieka. Tai jiems kainavo tūkstančius valandų per metus vien šiai veiklai. Tačiau naudojant „KYP.ai“ pavyko tai sumažinti, nes ši sistema veikia fone ir pati nustato, ką žmonės daro, galėdama atlikti matavimus tikslumu iki sekundžių.
(AK): Taigi ne tik kad tai nebeatima žmonių laiko, bet ir gaunami rezultatai yra daug arčiau tiesos nei atliekant rankinius matavimus.
(DJ): Be to, jie gavo informaciją apie savo darbuotojų veiklą. Taigi galėjo matyti, kiek jų žmonės dirba, ar kai kurie iš jų yra nepakankamai ar per daug apkrauti, ir kaip geriau paskirstyti darbą komandos viduje. Tačiau mane šiek tiek nustebino, kad jie dar nenaudoja jokių procesų analizės („process discovery“) funkcijų iš „KYP.ai“ – tų funkcijų, kurios gali parodyti, ką galima automatizuoti ar patobulinti procesuose, analizuoti veiklas ir sudaryti procesų žemėlapius pagal tai, ką žmonės daro. Bet, kiek suprantu, tai yra kitas jų kelionės žingsnis, kurį jie planuoja žengti.
(AK): Ir kas man vis dar kelia nuostabą dėl „KYP.ai“, tai tai, kad kai pirmą kartą pamačiau šį įrankį – aš juk kilęs iš nuolatinio tobulinimo srities – pirmoji mintis buvo: o Dieve, jei vykdyčiau „lean management“ projektus, turėčiau tiesiog nuostabius duomenis. Tačiau vėliau paaiškėjo, kad skirtingos įmonės jį naudoja visiškai skirtingais tikslais, tiesa? Ir tai vis tiek turi prasmę. Tad galiausiai tai įrankis, kurį skirtingos įmonės diegia dėl visiškai skirtingų priežasčių.
(DJ): „SPS“ atveju tai buvo operacijų valdymas. Jie norėjo geriau kontroliuoti savo veiklą. Tačiau turime įmonių, kurios naudoja „KYP.ai“ tik tam, kad identifikuotų procesus, kuriuos galima automatizuoti ar patobulinti, tiesa? Arba tiesiog nori sužinoti, kokio tipo procesus jos turi.
Pristatymas 4: Pradėk nuo „lean“ ir niekada nesustok („Euroclear“)
(AK): Kitas pranešėjas buvo Michałas Baraniakas iš „Euroclear“. Jo tema buvo Pradėk nuo… „Lean“. Ir niekada nesustok. Nuolatinės „Euroclear Bank“ transformacijos istorija . Tai buvo visiškai mano sritis, tiesa? Aš juk kilęs iš „Lean Management“ ir savo karjerą kūriau nuolatinio tobulinimo („Continuous Improvement“) srityje. Beje, Michałas buvo mano komandos narys „Lufthansa“. „Euroclear“ yra bankas bankams – jie tvarko sandorius tarp bankų ir daugybę kitų itin svarbių dalykų, kurie, jei kas nors „Euroclear“ neveiktų, iš esmės galėtų sustabdyti pasaulį, tiesa? Kokių minčių turi apie tai, ką jie daro „Euroclear“?
(DJ): Turiu omenyje, tai labai skyrėsi nuo tipiškos „lean“ transformacijos. Dažnai matome, kaip įmonėse atsiranda „lean“ transformacijos juodieji diržai, kurie įveda „Kaizen“ – tuos mažus patobulinimus, kuriuos kiekvienas gali siūlyti, įdiegia komandoms lentas ar kasdienius susirinkimus. Sakykime, tai labiau pagrindiniai dalykai, kurie kuria „lean“ kultūros pamatus. O „Euroclear“ atvejis gana kitoks, nes jie visa tai darė jau daugelį metų ir suprato, kad negali iš tiesų susitelkti tik į komandos lygmenį, vykdydami „lean“ transformaciją. Todėl jie pradėjo vykdyti „end-to-end“ projektus, kuriuose analizavo, ką daro skirtingos komandos, bet visame procese nuo pradžios iki pabaigos. Ir man, tiesą sakant, buvo labai netikėta pamatyti Michalo pateiktą pavyzdį – jie turėjo procesą, kuris, jei gerai pamenu, turėjo apie 95 žingsnius. Be to, jame dalyvavo kelios komandos, ir užduotys tarp jų buvo perduodamos net 50 kartų proceso metu.
Kai jie tai išanalizavo, parodė rezultatus komandoms ir bandė perkurti, kaip procesas turėtų atrodyti iš tikrųjų, man atrodo, žingsnių skaičių pavyko sumažinti iki 40. O vietų, kuriose procesai buvo perduodami tarp komandų – iki maždaug 15. Taigi jie reikšmingai supaprastino procesą. Taip pat kelis kartus sumažino įvykdymo laiką – nuo kelių dienų iki vienos dienos.
Ir jei pagalvotume apie automatizaciją – jei tada būtų atėjusi RPA ar net DI komanda ir pasiūliusi automatizuoti tą pirmąją proceso versiją su LLM ar DI, galbūt būtų pavykę patobulinti kelias vietas ir gauti kelis greitus laimėjimus, bet iš tikrųjų tai būtų buvęs didžiulis laiko švaistymas.
(AK): Taip, teisingai, ir tai iš tiesų yra tarsi šventasis „Continuous Improvement“ Gralis – tobulinti procesus nuo pradžios iki pabaigos. Visi apie tai kalba, visi to nori, bet labai mažai įmonių iš tikrųjų tai daro. O čia jie tai daro, bet, kaip tu sakai, tai logiškas žingsnių rinkinys. Jie pradėjo nuo pagrindų – turi informacines lentas, susirinkimus, visus tuos dalykus jie jau įgyvendino. Bet tuo nesustojo – žengė toliau, imdamiesi vis sudėtingesnių dalykų. Ir tai iš tiesų veikia, tiesa? Tai daugelio metų darbas. Ir dar vienas labai svarbus dalykas – negali sustoti. Negali po kelerių metų pakeisti krypties. Nes dažnai nutinka būtent taip: ateina naujas generalinis direktorius, įkuria nuolatinio tobulinimo programą, ji veikia trejus ar ketverius metus, duoda puikių rezultatų, o tada direktorius išeina kitur. Ir naujasis sako: „Ne, ne, ne, dabar darysime kažką kita.“
(DJ): Tiesa. Dar vienas dalykas, kuris, manau, buvo gana išskirtinis jų atveju, yra tai, kad jie į pirmą vietą iškėlė klientą. Visa ši transformacija buvo orientuota į klientą, ir jie iš tikrųjų kvietė klientus dalyvauti šiuose projektuose – kad šie galėtų pateikti atsiliepimų, išsakyti vadinamąjį „kliento balsą“.
(AK): Visiškai teisingai. Visi sako, kad tai daro, visi žino, jog taip reikėtų daryti, bet beveik niekas to iš tikrųjų nedaro.
Pristatymas 5: RABuy automatizacijos iniciatyva („Rockwell Automation“)
(AK): Kitas pranešimas buvo Sawos Konfisz ir Jakubo Markowskio iš „Rockwell Automation“. „Rockwell Automation“ – kaip rodo pavadinimas – yra automatizacija užsiimanti įmonė. Tačiau jie daro būtent tą automatizaciją, apie kurią dauguma galvoja išgirdę žodį „robotai“ – tikrą, fizinę, pramoninę automatizaciją. Jų pranešimo tema buvo „RABuy: automatizacijos iniciatyva, pašalinanti SAP iš pirkimų proceso“. Man ši idėja labai patiko, nes jie sugalvojo tai, apie ką aš pats tikriausiai nebūčiau pagalvojęs. Iš esmės, kai jiems reikia pateikti pirkimo užklausą savo sistemoje – o jie perka daug – jie paima tiekėjo pateiktą komercinį pasiūlymą, įkelia jį į sistemą, o DI perskaito pasiūlymą ir paverčia jį pirkimo užsakymu. Ir kai tai pamatai, atrodo visiškai logiška. Atrodo akivaizdu.
(DJ): Ir jei pagalvotum, tai neskamba įspūdingai. Bet kai jie pradėjo kalbėti apie skaičius, aš iš tikrųjų išsitraukiau telefoną, atsidariau skaičiuotuvą ir greitai paskaičiavau, kad jie iš esmės padidino visos įmonės produktyvumą maždaug 50 etatų, jei teisingai prisimenu. Nesu tikras, ar jiems pavyko tai tiesiogiai perkelti į pelno ir nuostolio ataskaitą, bet net jei tai būtų tik „minkštieji“ sutaupymai 50 etatų mastu visoje kelių tūkstančių žmonių organizacijoje, tai reiškia, kad darbuotojai gali susitelkti į svarbesnius dalykus, o ne vien tik suvedinėti užsakymus į sistemą.
(AK): Tai juk nėra veikla, kurią žmonės mėgsta daryti. Rankinis duomenų suvedimas tikrai nėra mėgstamiausias darbas. O jie sukūrė patogų įrankį su lengvai naudojama sąsaja, kuris tai daro už tave. Bet, žinoma, turint omenyje, kad LLM vis dar „haliucinuoja“ ir daro klaidų, paskutinis žingsnis yra tas, kad žmogus peržiūri, ką sistema suprato iš pasiūlymo, prireikus pakoreguoja, ir tada leidžia jai užbaigti procesą.
(DJ): Yra ir kita perspektyva, kaip į tai galima pažvelgti, nes jie iš tikrųjų pasinaudojo mažo kodo („low-code“) programų kūrimo metodu. Jie susikūrė savo pačių „low-code“ programą, kuri atrodė daug geriau nei jų senoji SAP sistema. Be to, jie galėjo atsisakyti SAP licencijų – kas, žinoma, nėra labai maloni žinia SAP, bet „Rockwell“ iš to tikrai gavo nemažai sutaupymų.
Antros dienos išsamios analizės
(AK): Tuo ir baigėsi pirmoji diena. Į vakarėlio po renginio detales nesileisime, bet jis buvo fenomenalus. O antroji diena – kadangi pirmos dienos pranešimai trunka po 30 minučių, yra šiek tiek laiko klausimams, tačiau daugiau dėmesio skiriame idėjų pristatymui, įkvėpimui, realių pavyzdžių rodymui. Antroji diena skirta išsamesnėms analizėms – turime mažiau pranešimų, bet jie trunka po valandą, ir gilinamės į įgyvendinimo bei dažnai technines detales, kas ir kaip vyksta. Šią dieną vedė mūsų pristatymų vadovė Dagmara Sysula.
Pristatymas 1: P2P aptarnavimo centro DI agentas („McCormick“)
(AK): Pirmasis antros dienos pranešimas buvo Radosławo Ociepos iš „McCormick“. Jis kalbėjo apie P2P aptarnavimo centro DI agentą. Tai mums gana artima tema, nes pastaraisiais mėnesiais ir patys dirbome prie kažko panašaus. Kaip tau pasirodė?
(DJ): Manau, kad tokie aptarnavimo centro agentai – nesvarbu, ar kalbame apie finansus, personalo skyrių, pirkimus ar IT pagalbos centrą – yra ta sritis, kur įvyks didžioji dalis DI automatizacijų. Turiu ir kitą įtarimą – pavyzdžiui, kalbant apie „Salesforce“ atleidimus, tiesa? Jie paskelbė, kad iš 9 000 darbuotojų klientų aptarnavimo padalinyje sumažino apie 4 000. Ir, mano manymu, daugiausia tai buvo būtent pirmojo lygio aptarnavimo centro agentai.
(AK): Ir manau, kad kai girdime apie tuos masinius atleidimus, kuriuos daro įmonės, dauguma jų, mano manymu, yra tiesiog pasiteisinimas. Jos sako, kad tai dėl DI, bet iš tikrųjų DI diegimo lygis dar nėra toks aukštas. Tai tik pretekstas padaryti tai, ką vis tiek planavo padaryti. Bet šiuo atveju, apie kurį tu kalbi, manau, kad tai gali būti tiesa. Generatyvusis DI šiuose procesuose iš tiesų yra labai veiksmingas. L1 – visiškai taip. Tad jei kažkas ieško geros srities, nuo kurios pradėti dirbti su DI, aptarnavimo centro tipo darbas gali būti puiki vieta. Jie šį sprendimą sukūrė naudodami „UiPath“ agentus – tai gana naujas dalykas, tiesa? Juk viešai prieinamas vos kelis mėnesius. Bet jie parodė, kad, pasitelkę šią technologiją, gali įgyvendinti sprendimus ir padaryti tai labai greitai. Nes jei viską reikėtų kurti nuo nulio, tai pareikalautų milžiniškų pastangų ir didelio kompetencijų kiekio – nežinau, ar jie tokių turėjo organizacijos viduje, o galbūt būtų tekę samdyti mašininio mokymosi, „DevOps“ inžinierius ir panašius specialistus.
(DJ): Kadangi jie jau turi „UiPath“ platformą ir naudoja robotus, tai leidžia jiems viską įgyvendinti daug, daug paprasčiau. Ir aš labai laukiu tęsinio – jie sakė, kad pradėjo nuo P2P aptarnavimo centro, nes P2P aptarnavimo centre gaunama daugybė pasikartojančių klausimų, pavyzdžiui: „ei, koks mano sąskaitos statusas?“
(AK): Ir visiškai logiška pradėti būtent ten, tačiau jie jau turi planų panaudoti tą pačią technologiją ir kituose aptarnavimo centruose, kad padarytų tą patį. Kadangi turėjome visą valandą, galėjome gana giliai panagrinėti, kaip jie tai įgyvendino. Matėme tiksliai, kaip jie kūrė tuos agentus.
(DJ): Manau, tai buvo gana tipiška sąranka, tiesa? Jie turėjo, berods, tris ar keturias programas, kuriose reikia tikrinti informaciją – buvo SAP, „Ariba“ ir dar kelios kitos. Ir priklausomai nuo konkretaus atvejo reikia eiti į vieną ar kitą iš jų. Taigi tai ne toks agentas, kuris dirba tik vienoje programoje – reikia tiksliai koordinuoti, ką agentai daro. Be to, agentai juk neatlieka viso darbo, tiesa? Buvo ir integracijų, buvo ir RPA robotai – klasika. Agentai buvo naudojami tam, kad suprastų, apie ką yra klausimas. O kai tai jau aišku, tada nebereikia, kad agentas viską atliktų – tam galima naudoti įprastinę automatizaciją.
(AK): Tikrai taip. Ir, manau, jie naudojo dar vieną agentą tam, kad šis parengtų gražų atsakymą, remdamasis duomenimis, kuriuos jam pateikė robotas. Bet tai logiška ir aiškiai parodo, kad DI nereikia naudoti viskam. Yra dalių, kur DI tinka, ir yra dalių, kur labiau tinka kitos technologijos. Žinai, kas mane nustebino šiame pristatyme?
(DJ): Jie paminėjo, kad nėra žmogaus įsikišimo grandinėje. Ir jų verslo direktorius paprašė, kad jie netikrintų siunčiamų el. laiškų. Man tai buvo tikrai netikėta – kad jie iš tiesų taip padarė. Mes juk paprastai rekomenduojame turėti bent kokį nors galutinį patikrinimą žmogaus, arba ankstyvą patikrą, ar agentas eina teisinga kryptimi.
(AK): Ir žmonės apie tai klausė, tai buvo aptarta. Iš esmės procesai, kuriuos šiuo metu atlieka agentas, yra labai mažos rizikos, tiesa? Sutinku, kad bent jau pradžioje, pirmosiomis savaitėmis, aš tikriausiai patarčiau įtraukti žmogų į procesą. Bet mums patinka drąsūs žmonės, kurie daro drąsius dalykus.
Pristatymas 2: „UiPath“ antro veiksmo agentinė automatizacija („UiPath“)
(AK): Tuomet turėjome Piotrą Zająką iš „UiPath“. „UiPath Act 2: Agentinė automatizacija“. Tai buvo labai daug informacijos.
(DJ): Manau, tai buvo labiausiai informacijos kupinas pristatymas. Piotras kalba labai greitai, ir jis labai greitai rodė, kaip „UiPath“ transformuoja savo organizaciją ir produktus – nuo tradicinės RPA prie DI pagrįstos automatizacijos („AI first automation“). Spėju, tai visų pirma buvo įdomu „UiPath“ klientams, galbūt ne tiek tiems, kurie naudoja „Blue Prism“ ar „Automation Anywhere“. Bet kai svarstėme, ar galėtume pakviesti kitus tiekėjus į konferenciją ir paprašyti jų pakalbėti apie DI galimybes, pagalvojome – nesame tikri, ar jie turėtų ką iš tiesų papasakoti. Atsakymas galėtų būti: „kokias dar DI galimybes?“
(AK): „UiPath“ labai stipriai dirba su DI sritimi – tiek, kad jie patys tai vadina „antruoju veiksmu“, kai jų platforma virsta kažkuo visiškai kitu. Tai nereiškia, kad jie nustos kurti robotus ar panašiai – tai vis dar svarbi viso ekosistemos dalis. Tačiau jie visiškai teisingai sako, kad to jau nebeužtenka, ir visos šios DI galimybės turi būti integruotos, nes būtent to dabar tikisi klientai.
(DJ): Ir trumpai tariant, man atrodo, kad „UiPath“ bando įdiegti DI į kiekvieną savo produktų tipą, tiesa? Jie įdėjo jį į robotus – pavyzdžiui, savarankiškai taisančius selektorius („self-healing selectors“). Įdėjo į testų automatizaciją – DI pritaikymus testavimo atvejams. Į procesų analizę. Iš esmės – į dokumentų duomenų ištraukimą. Visiškai visur, kur tik galima įsivaizduoti, kad DI galėtų būti panaudotas. Bet esmė ta, kad jie jau turi visą sisteminį pagrindą – jie to nestato nuo nulio.
(AK): Ir dar svarbu tai, kad šios DI funkcijos yra tarsi pasirenkamos – jei tau, pavyzdžiui, nepatinka savarankiškai taisančių selektorių idėja, dėl kurios, tiesą sakant, pats turiu abejonių, ir esu tikras, kad mano programuotojai jų taip pat turi, – tiesiog jų nenaudoji, tiesa? Bet turi galimybę jas naudoti tada, kai tai tinka ir kai tai iš tikrųjų turi prasmę.
Pristatymas 3: „KYP.ai“ ir netikėti atradimai („Office Samurai“)
(AK): Tuomet turėjome Zuzanną Pamulą ir Michałą Kozubskį, abu iš „Office Samurai“, kurie kalbėjo tema „KYP.ai ir netikėti atradimai“. Nors su jais dirbu kasdien, vis tiek labai laukiau šio pranešimo, nes jie pabandė surinkti kuo daugiau netikėtų dalykų, kuriuos jie patys arba mūsų klientai atrado naudodami „KYP.ai“ projektų metu. Kaip jau kalbėjome anksčiau, „KYP.ai“ galima naudoti labai įvairiems tikslams.
(DJ): Bet man didžiausia šio pristatymo pamoka buvo ta, kad galbūt turėtume pagalvoti apie tai, kaip „KYP.ai“ kurti daugiau pritaikytų informacinių lentų, kuriose būtų galima sužinoti, kiek kainuoja jūsų susitikimai organizacijoje. Jie pateikė ir labai įdomių pavyzdžių, kai analizuojamas vadovo darbas, tiesa? O juk vadovas šiais laikais paprastai naudoja „Outlook“, galbūt „Teams“, šiek tiek „Excel“. Ir užuot kartais darę konkretų darbą, jie daugiausia susitinka ir kalbasi su žmonėmis. Kartais tai pateisinama, kartais galbūt galėtų būti mažiau. Bet iš tikrųjų nežinai, kokio tai masto reiškinys – o su „KYP.ai“ gali tiksliai paskaičiuoti, kiek tau kasdien kainuoja susitikimai.
(AK): Ir tai yra dalykas, kuris vadovams sudaro didžiąją darbo dalį. Bet net ir operatyviniai darbuotojai praleidžia daug laiko susitikimuose, tiesa? Ir nors tam tikras susitikimų kiekis yra būtinas, kad viskas veiktų, daugelis organizacijų jų turi tiesiog per daug, o tie susitikimai tik trukdo darbuotojams atlikti savo tiesioginį darbą.
(DJ): Kai pagalvoju apie tai, niekada nesu girdėjęs nė vienoje organizacijoje, kad trūktų susitikimų. Dažniausiai girdžiu – „turime pakankamai“, kas būtų ideali situacija, arba „turime per daug“, kas pasitaiko, manau, maždaug 80% atvejų.
(AK): Bandau įtikinti Zuzanną arba Michałą padaryti atskirą tinklalaidės epizodą šia tema. Tad sekite naujienas – grįšime su dar daugiau pavyzdžių.
Pristatymas 4: DI automatizacijos vadovas („Dominik Jaskulski“)
(AK): Ir galiausiai – vyšnia ant torto – Dominikas Jaskulskis su pranešimu „DI automatizacijos vadovas“. Man asmeniškai viso tavo pranešimo metu galvoje sukosi mintis: turėjome kažką tokio sukurti anksčiau. Tu sujungiai mintis, sistemas ir idėjas apie tai, kaip DI turėtų būti diegiamas organizacijose.
(DJ): Atvirai kalbant, šį pristatymą parengiau visai atsitiktinai, nes iš pradžių planavau kalbėti apie DI panaudojimo atvejus – nuo ko reikėtų pradėti jų ieškoti, kurie iš jų turi prasmę, kurie ne, kad žmonės iš konferencijos išeitų su konkrečiomis idėjomis, nuo ko pradėti. Tačiau kai pradėjau dėlioti skaidres, pajutau, kad istorijoje kažko trūksta. Tuomet kilo mintis, kad iš esmės yra kelios pagrindinės fazės, kurias reikia pereiti, norint tinkamai įdiegti DI organizacijoje.
Šis modelis taip pat buvo sukurtas remiantis grįžtamuoju ryšiu ir pamokomis iš dviejų ataskaitų – viena iš „McKinsey“, kita iš MIT. Abiejose buvo kalbama apie tam tikrą spragą: daugelis organizacijų turi vadinamąsias horizontaliąsias diegimo iniciatyvas. „Horizontaliosios“ reiškia, kad, pavyzdžiui, visiems darbuotojams suteikiama prieiga prie „ChatGPT“ ar „Microsoft Copilot“. Kai kurie tuo naudojasi, kiti – ne. Ir tada labai sunku įvertinti bei išmatuoti naudą. „KYP.ai“ gali padėti šioje vietoje, padėdama išmatuoti naudą, tačiau vis tiek sudėtinga ją tiesiogiai perkelti į pelno ir nuostolio ataskaitas.
Man atrodo, „McKinsey“ nustatė, kad tik 1 % organizacijų mano, jog jų DI strategija yra brandi. Be tų horizontalių projektų, egzistuoja ir vertikalūs projektai – pavyzdžiui, tas P2P aptarnavimo centro agentas iš „McCormick“. Tai vertikalaus projekto pavyzdys. Arba „Rockwell Automation“, tiesa? Jie vykdė projektą konkrečioje srityje – nuo pradžios iki pabaigos – kuris išsprendė realią organizacijos problemą. Tačiau tik apie 5 % tokių projektų iš tikrųjų pasiseka – dauguma jų įstringa POC arba pilotinėje fazėje.
Išvada buvo tokia, kad būtent tokie projektai suteikia realią naudą, kurią galima paversti finansiniais rezultatais. Tačiau pradėti nuo jų nėra lengva. Todėl mano pasiūlymas buvo diegti DI etapais: pradėti horizontaliai – su pokalbių robotais, „Copilotais“, tada pereiti prie DI asistentų, t. y. DI, kuris prijungtas prie jūsų žinių bazių, gali atsakyti į klausimus apie turimą informaciją, ją apibendrinti ir pan.
Kitas etapas būtų paprasti DI agentai – tokie agentai, kurie gali kažką atlikti už jus, bet tik vienoje sistemoje. Manau, tiek „McCormick“, tiek „Rockwell“ pavyzdžiai yra būtent tokie – agentas turėjo vieną aiškią užduotį, nereikėjo koordinuoti sudėtingos agentinės sistemos.
Ir galiausiai paskutinis lygmuo – kai reikia orkestruoti agentus, o kartais net kai vienas agentas turi koordinuoti kitus. Tačiau prieš pasiekiant šį lygį, mano nuomone, būtina atlikti „namų darbus“ ir turėti sutvarkytus pagrindinius dalykus.
(AK): Į šį paskutinį lygį nėra pasiekusios daug įmonių – aišku, kad masiniu mastu ten dar niekas neveikia. Ir tai tiesa: ką bedarytum, jei nori tai daryti atsakingai, o ne tik „PowerPoint“ skaidrėse, turi pereiti tam tikrus žingsnius, kol ten pateksi.
Tas MIT pranešimas yra gana žiaurus – kai jį skaičiau, turėjau jausmą, kad taip ir yra: tik apie 5 % tokių projektų iš tiesų pasiseka ir atneša naudą. Aš maniau, kad tas skaičius bus didesnis nei 5%.
Faktas, kad 40 % organizacijų jau įdiegė „Copilot“ ar DI pokalbių robotus savo darbuotojams, o 90 % įmonių darbuotojai jau dabar jais naudojasi, reiškia, kad jūsų duomenys yra siunčiami į kažkieno debesį be jūsų sutikimo ir be jokios priežiūros. Manau, tai labai svarbus pastebėjimas, nes jei dirbate IT saugumo srityje, turite suprasti, kad jeigu nesuteiksite darbuotojams saugaus būdo naudoti DI, jie vis tiek jį naudos – tik nesaugiai. Ir jūs jų nesustabdysite.
(DJ): Kitas dalykas – mokymai, tiesa? Matėme daug organizacijų, kurios, pavyzdžiui, perka bendrinius mokymus arba prašo savo darbuotojų tiesiog pažiūrėti kelis „YouTube“ vaizdo įrašus ar pasiklausyti mokymo apie tai, kas yra LLM. Tačiau vėliau jie vis tiek nesugeba pritaikyti to savo darbe.
Rodžiau vienos įmonės (negaliu jos įvardyti) pavyzdį – ten komanda analizavo labai sudėtingas, tūkstančių eilučių SQL užklausas. Aš įdėjau visą tą užklausą, man rodos, į „Copilot“, sukūriau paprastą užklausą, ir per septynias minutes gavome rezultatą, kurį anksčiau trys žmonės darydavo visą dieną.
Pagal MIT tyrimą, jei pradedi diegti DI savo įmonėje savarankiškai, turi tik 50% sėkmės tikimybę, palyginti su tuo, kai tai darai su išoriniu, patyrusiu partneriu.
(AK): Tavo pranešimo tema – tikrai persekiosiu tave, kad paverstume ją tinklalaidės epizodu. Apibendrinant, tos dvi dienos mums, be abejo, buvo varginančios, bet buvo nepaprastai gera išgirsti visas tas įmonių istorijas ir susitikti tiek daug žmonių, kuriems šios temos iš tiesų įdomios.
(DJ): Ir žinai, iš tikrųjų jaučiuosi labai įkvėptas ir kupinas energijos. Ir būtent tai paprastai ir yra pagrindinė priežastis, kodėl dalyvauju konferencijose, tiesa? Viena dalis – išmokti kažką naujo. Bet kita, ta įkvepianti dalis – tas jaudulys, kai supranti: ei, mes juk turime tą pačią problemą, o jie jau parodė, kaip ją išspręsti. Tad padarykime tą patį ir savo įmonėje.
Išvada
(AK): Ir štai baigėme mūsų „Samurai and Friends“ apžvalgą. Scena tuščia, vėliavos nuleistos, o paskutiniai dovaniniai sausainiai – iškovoti ir suvalgyti. Dōmo arigatō, kad klausėtės mūsų pergalės rato. Didžiulis, nuoširdus ačiū tikriesiems renginio herojams – pranešėjams ir įmonėms, kurios pasidalijo savo istorijomis. Šis epizodas, kaip ir pati konferencija, nebūtų buvę įmanomi be mūsų prodiuserės Annos Cubal – strategijos meistrės užkulisiuose. Įrašinėjame legendinėje „Wodzu Beats“ studijoje, kur jau braižome idėjas kitam renginiui.
Jei ši apžvalga privertė jus norėti tapti veiksmo dalimi kitą kartą, būtinai sekite mus socialiniuose tinkluose – ten rasite visus pranešimus. Iki kito karto – tegul jūsų procesai būna automatizuoti, o konferencijos – be nesąmonių. Mata ne.
