DI įgyvendinimas realybėje - kas iš tiesų veikia

Kiekvienas CTO anksčiau ar vėliau atsiduria ties tuo pačiu tašku - valdyba nori DI, plane jis jau „privalomas“, o konkurentai tuo metu kažką bando ir apie tai kalba. Ir tada lieka trys kryptys, bet nė viena nėra ideali - gali bandyti viską kurti viduje, gali samdyti didelę agentūrą, arba ieškoti partnerio kažkur per vidurį.

Šiame straipsnyje trumpai ir aiškiai palyginsime visus tris kelius - ką jie realiai duoda, kur dažniausiai stringa ir kuris variantas dažniausiai pasiteisina.

Kurti viduje užtrunka ilgiau, nei atrodo

Turi visišką kontrolę - tavo duomenys, tavo intelektinė nuosavybė, tavo planas. Iš pirmo žvilgsnio atrodo, kad rimtai į technologijas žiūrinčiai įmonei tai ir yra akivaizdžiausias pasirinkimas.

Tik realybė dažnai kitokia.

Šiuo metu rasti stiprių, patyrusių DI inžinierių yra sunku. Paklausa milžiniška, talentų rinka per siaura, o kol tu pasisamdai žmones, juos įvedi į kontekstą ir komanda pagaliau susiderina ties konkrečia problema - rinka būna nuėjusi keliais žingsniais į priekį. Pasaulio ekonomikos forumas (opens in new tab) DI ir mašininio mokymosi specialistus įvardija kaip vieną sparčiausiai augančių ir labiausiai ieškomų profesijų pasaulyje, tačiau pasiūla kol kas nė iš tolo nespėja paskui paklausą.

Net kai komanda jau surinkta, greitai paaiškėja, kad darbas sunkesnis, nei atrodė. DI automatizaciją įmontuoti į esamą infrastruktūrą - ypač kai greta sukasi ERP, CRM ir visokie savi įrankiai - beveik niekada nebūna taip paprasta, kaip nupiešta architektūros schemoje. Pradeda lįsti kraštiniai atvejai, plečiasi apimtis, o prototipas, kuris iš pradžių atrodė įspūdingai, po kelių mėnesių tampa galvos skausmu.

Kurti viduje logiška tada, kai DI yra tavo pagrindinis produktas, kai kuriama sistema ir yra tai, ką parduodi. Visiems kitiems tai neretai tampa lėčiausiu ir brangiausiu keliu į rezultatą, kurį buvo galima pasiekti kitu būdu. Kaip Grafana Labs (opens in new tab) teigia - esmė ne tai, kuris variantas gražiausiai atrodo teorijoje, o kuris greičiausiai nuveda į rezultatą neužtrenkiant durų ateičiai.

Open source kelias - daug galios, daug atsakomybės

Kai kurios komandos vengia DI kurti komandos viduje - tiesiog susirenka open source modelius ir įrankius pačios. Iš pirmo žvilgsnio tai atrodo pigiau, kol nepradedi skaičiuoti laiko, kurį suvalgys vertinimas, integracijos, priežiūra ir nuolatiniai atnaujinimai. Gerų open source DI įrankių tikrai netrūksta, o komandoms, kurios turi stiprią inžinerinę bazę ir laiko paeksperimentuoti, tai duoda realų lankstumą ir kontrolę.

Tik open source yra pamatas, o ne paruoštas sprendimas. Vis tiek kažkam reikia suprojektuoti architektūrą, sujungti viską su tavo sistemomis, prižiūrėti modelio „nuslydimą“ laikui bėgant ir užtikrinti, kad viskas veiktų kai keičiasi duomenys ir reikalavimai. Open source yra galingas įrankis. Bet galia be patirties dažniausiai virsta tiesiog sudėtingumu.

Daugumai verslo komandų tikroji open source kaina nėra licencijos - didžiausia kaina yra inžinerijos valandos, priežiūros našta ir mėnesiai, praeinantys iki tol, kol pavyksta išleisti kažką išties naudingo.

Didelės agentūros - žmonių daug, dėmesio mažai

Pardaviminė dalis skamba įspūdingai - šimtai inžinierių, gebėjimas pristatyti sprendimą bet kurioje rinkoje, „patikrinti“ metodai, enterprise lygio patikimumas.

O realybėje dažniausiai gauni projekto vadovą, kelis vidutinio lygio programuotojus ir architektą, kuris pasirodo projekto pradžioje ir per ketvirčio apžvalgą. Visa, kas vyksta tarp jų, tampa „kažkieno kito“ problema - kol vieną dieną tai tampa tavo problema.

Didelės agentūros yra sukonstruotos dideliems klientams. Jei nesi Fortune 500 - tu joms nebūsi prioritetas. Terminai slenka, komunikacija keliauja per kelis sluoksnius, o sprendimas galiausiai būna „padarytas pagal specifikaciją“, bet ne būtinai taip, kad realiai veiktų. Ir kai DI diegimas nepavyksta, pirmiausia kaltas būna ne technologinis sprendimas, o „jūs neteisingai suformulavot poreikį“ arba „pas jus duomenys ne tokie“.

Esame girdėję tai ne kartą - scenarijus kartojasi. Po pusmečio - graži prezentacija, kažkoks staging’as ir vis didėjantis jausmas, kad „kažkas čia ne taip“. Po metų - jau ieškoma, kas sutvarkys tai, kas buvo pastatyta.

Kita bėda - atitikimas. Didelės agentūros dirba mastu, todėl jos linkusios standartinį požiūrį taikyti nestandartinėms problemoms. O tavo procesai nėra „tipiniai“, tavo duomenys nėra tvarkingi, o svarbiausi būna būtent tie išskirtiniai atvejai. Universalūs sprendimai dažniausiai susitvarko su lengvais 80% - ir subyra ten, kur tau jų labiausiai reikia.

McKinsey tyrimai (opens in new tab) rodo, kad DI iniciatyvos dažniausiai žlunga ne dėl technologinių ribojimų, o dėl to, kad sprendimas prastai atitinka realų verslo kontekstą, kuriam jis buvo kuriamas.

Specialistų komanda - partneris, kuriam rūpi

Yra vienas partnerio tipas, apie kurį šitoje diskusijoje kalbama per mažai - nors būtent čia dauguma vidutinio dydžio įmonių randa geriausią rezultatą.

Specialistų komanda atsineša konkrečios srities patirtį, juda greitai, nes tuo pačiu metu neaptarnauja šimto kitų klientų, ir kuria sprendimą tavo problemai - o ne bando pritempti šabloną. Jie pakankamai maži, kad tavo projektas jiems iš tikrųjų būtų svarbus, ir pakankamai patyrę, kad žinotų, kur viskas dažniausiai lūžta, dar prieš tam nutinkant. Gauni agentūros patirtį ir pajėgumą, bet be sudėtingų procesų ir didelių kaštų, o kartu - vidinės komandos fokusą be ilgo ir skausmingo samdymo.

Specialistų komanda tinka ne visada. Jei tau reikia diegimo globaliai per kelias dešimtis rinkų, arba enterprise lygio SLA su 24/7 palaikymu, didesnis tiekėjas dažnai bus logiškesnis pasirinkimas. Bet daugumai vidutinio dydžio įmonių, kurios bando įdiegti realų DI į realius procesus - būtent čia dažniausiai ir atsiranda geriausi rezultatai.

Kaip tai atrodo praktikoje? Pas mus atėjo įmonė - 200+ darbuotojų, 6 tarpusavyje nesusiję įrankiai ir BI sistema, kuri techniškai veikė, bet realybėje - nelabai. Analitikai pusę savaitės praleisdavo valydami duomenis, o ne juos naudodami. Ketvirčio ataskaitos užtrukdavo šešias valandas. Vadovybė sprendimus priimdavo remdamasi skaičiais, kuriais iki galo niekas nepasitikėjo.

Sukūrėme Dirbtinio intelekto agentų verslo analitikos platformą (opens in new tab) kuri sujungė visą jų „stack’ą“ ir į sudėtingus verslo klausimus atsakydavo paprasta, žmonėms suprantama kalba. Be SQL. Be laukimo. Integracija užtruko tris savaites, o realūs rezultatai pasimatė per pirmą mėnesį - 3 kartus greitesnė prieiga prie įžvalgų, 30% mažesnės viršvalandžių sąnaudos, 25% mažiau „scope creep“.

Šita istorija mums brangi ne todėl, kad technologija buvo įspūdinga. O todėl, kad ji greitai išsprendė realią problemą realiems žmonėms.

Tai kuris variantas tinka tau?

Kurti viduje verta tada, kai DI automatizacija yra tavo pagrindinis produktas ir turi pakankamai laiko bei noro investuoti į komandą.

Rinktis open source logiška, jei turi stiprią inžinerinę bazę, laiko eksperimentams ir nori visiškos kontrolės savo technologijų „stack’e“.

Samdyti didelę agentūrą verta, jei tau svarbiausia enterprise atitiktis, tarptautinis mastas ir turi biudžetą bei kantrybės ilgam bendradarbiavimui.

Rinktis mažą, fokusuotą komandą - jei reikia sprendimo, kuris būtų padarytas gerai, greitai ir konkrečiai pagal tai, kaip realiai veikia tavo verslas.

Prieš apsisprendžiant verta įsivertinti tris dalykus - ar turi reikiamų žmonių, ar tavo procesai telpa į šabloną, ir kiek tau kainuotų nepataikyti su pasirinkimu.

Kaip Mygom gali padėti

Per ketverius metus ir 110+ projektų išsigryninome, kaip kurti DI sprendimus, kurie ne tik pasiekia produkciją, bet ir realiai prigyja komandoje. Jei svarstai, nuo ko pradėti ir kuris kelias tavo situacijoje būtų protingiausias - susisiek (opens in new tab). Padėsim susidėlioti kryptį, įsivertinti rizikas ir aiškiai suprasti, ką verta daryti dabar, o ko geriau ne.