Kiekvieną rytą atsidarę nešiojamąjį kompiuterį rasite dar vieną pranešimą. Jūsų CRM dabar turi „DI asistentą“. Jūsų projektų valdymo įrankis turi „DI rašytoją“. Net jūsų buhalterinė programinė įranga turi „DI įžvalgų“ skydelį. Atrodo, kad atsakymą į klausimą ar turėčiau naudoti DI savo versle už jus jau nusprendė programinės įrangos tiekėjai. Jie tiesiog užklijavo blizgantį „DI pagrįstą“ lipduką ant įrankių, už kuriuos jau mokate, o tai paprastai lydi tylus kainos pakėlimas arba naujas „Pro“ lygis.
Tačiau štai negailestinga tiesa, kurią pastebėjau padėdamas šimtams įmonių įveikti šį perėjimą: dauguma šių funkcijų yra spąstai. Jos nepadeda jums transformuotis; jos padeda programinės įrangos tiekėjui išvengti moralinio nusidėvėjimo. Jei jūsų DI strategija susideda tik iš naujo „Magiško“ mygtuko paspaudimo jūsų senojoje SaaS programinėje įrangoje, jūs nekuriate DI orientuoto verslo. Jūs tiesiog mokate „Sąsajos mokestį“ už technologiją, kurią patys galėtumėte naudoti kur kas efektyviau ir pigiau.
„Funkcijų pertekliaus klystžvakė“: kodėl „priklijuotas“ DI žlunga
💡 Norite Penny analizuoti jūsų verslą? Ji nustato, kuriuos vaidmenis AI gali pakeisti, ir sudaro etapinį planą. Pradėkite nemokamą bandomąją versiją →
Norėdami suprasti, kodėl turėtumėte vertinti tai skeptiškai, turime pažvelgti į „Funkcijų pertekliaus klystžvakę“ (angl. Feature-Bloat Fallacy). Senosios programinės įrangos įmonės šiuo metu išgyvena tylią paniką. Visas jų verslo modelis sukurtas remiantis „vietų“ skaičiumi – žmonių, prisijungiančių prie valdymo skydelio tam tikroms užduotims atlikti, kiekiu. DI, pagal savo prigimtį, mažina poreikį žmonėms jungtis prie šių skydelių.
Tai sukuria esminį interesų konfliktą. Senoji CRM įmonė nenori taip visiškai automatizuoti jūsų pardavimų proceso, kad jums prireiktų tik vienos licencijos vietoj dešimties. Jie nori suteikti jums tiek DI, kiek užtektų, kad ir toliau mokėtumėte už tas dešimt licencijų. To rezultatas yra tai, ką aš vadinu „Supakuotu DI“ – plonas funkcionalumo sluoksnis, sukurtas ant bendro modelio (pavyzdžiui, GPT-4), kuris yra apribotas veikti tik to konkretaus įrankio ekosistemoje.
Kai žmonės manęs klausia: „Ar turėčiau naudoti DI savo versle per įrankius, kuriuos jau turiu?“, mano atsakymas dažniausiai yra atsargus „ne“. Jei DI negali susikalbėti su kitomis jūsų sistemomis, jei jis negali inicijuoti veiksmų už savo lango ribų ir jei jam reikia žmogaus, kuris sėdėtų ir rankiniu būdu įvedinėtų užklausas, tai nėra efektyvumo padidėjimas. Tai tik dėmesio nukreipimas.
Sąsajos mokestis: jūs mokate už trinties privilegiją
Viena pagrindinių koncepcijų, kuria dalinuosi su aiaccelerating.com prenumeratoriais, yra Sąsajos mokestis.
Istoriškai už SaaS mokėjome todėl, kad vartotojo sąsaja (UI) padėjo žmonėms lengvai naršyti sudėtingose duomenų bazėse. Mokėjome už mygtukus, meniu ir vaizdinį išdėstymą. Tačiau DI pasaulyje vartotojo sąsaja dažnai tampa kliūtimi. DI nereikia mygtukų. Jam reikia API prieigos prie grynųjų duomenų.
Kai senas įrankis ima iš jūsų papildomus £30 už vartotoją už „DI funkcijas“, jie dažnai tiesiog apmokestina jus už gražesnį būdą pasiekti modelį, kurio tiesioginis naudojimas kainuoja menką dalį pensų. Jūs mokate priemoką už apribotą patirtį. Pavyzdžiui, „DI rašytojas“ projektų valdymo įrankyje gali padėti parengti užduoties juodraštį, tačiau jis automatiškai neatnaujins jūsų IT pagalbos bilietų ir nesinchronizuos jų su klientų atsiliepimų ciklu, nebent tiekėjas būtų sukūręs tą konkrečią integraciją.
Priešingai, DI paremtas požiūris naudoja orkestratorių duomenims tarp įrankių perkelti. Jūs nustojate mokėti už „sąsają“ ir pradedate mokėti už „rezultatą“.
Šablonų atpažinimas: 90/10 SaaS transformacijos taisyklė
Pastebėjau pasikartojantį šabloną įvairiose pramonės šakose – nuo mažmeninės prekybos iki profesionalių paslaugų. Aš tai vadinu 90/10 taisykle.
Beveik kiekvienoje verslo funkcijoje DI dabar gali atlikti 90 % rutininio, duomenų imlaus vykdymo. Likusiems 10 % reikia žmogaus nuovokos, empatijos ar strateginės priežiūros. Senieji SaaS įrankiai sukurti senajam pasauliui, kuriame žmonės atlikdavo 90 % darbo. Jų „DI lipdukai“ skirti padėti tiems 10 % – projektų rengimui, apibendrinimui, „darbo pradžiai“.
Tikroji transformacija įvyksta tada, kai apverčiate scenarijų. Jūs nenaudojate DI tam, kad padėtumėte žmogui atlikti darbą; jūs naudojate DI, kad jis atliktų darbą, o žmogus prižiūrėtų rezultatą. Tam paprastai reikia atsisakyti „viskas viename“ senųjų platformų ir pereiti prie išskaidyto specializuotų, DI paremtų įrankių rinkinio, kurie bendrauja per API.
Argumentas už išskaidymą: kodėl „begalvės“ operacijos yra pranašesnės
Jei rimtai svarstote, kaip turėtumėte naudoti DI savo versle, turite pasidomėti „begalvėmis“ (angl. Headless) operacijomis. Tai koncepcija, pasiskolinta iš saityno kūrimo, kur galinė dalis (duomenys ir logika) yra atskirta nuo priekinės dalies (UI).
Naudodamiesi senojo SaaS įrankio DI, esate užrakinti jų „galvoje“. Jei jų DI nėra labai geras atliekant konkrečią užduotį, jūs įstringate. Jei operacijas išskaidote, įgyjate „Agilumo pranašumą“. Galite naudoti geriausią modelį transkripcijai, geriausią modelį duomenų analizei ir geriausią modelį klientų aptarnavimui – visi jie maitina centrinį tiesos šaltinį.
Tai susiję ne tik su našumu, bet ir su galutiniu rezultatu. Žvelgdami į SaaS ir programinės įrangos sutaupymus, didžiausius laimėjimus pasiekiame ne ieškodami pigesnės to paties įrankio versijos. Jie pasiekiami visiškai pašalinant įrankio poreikį ir pakeičiant jį paprasta, DI varoma darbo eiga.
Kaip atlikti esamo įrankių rinkinio auditą
Prieš paspausdami „atnaujinti“ tam naujam DI lygiui, užduokite sau šiuos tris klausimus:
- Ar tai „generavimas“, ar „valdymas“? Jei DI tik rašo tekstą, kurį žmogus turi nukopijuoti ir įklijuoti, tai yra žaislas. Jei jis gali inicijuoti daugiapakopį procesą tarp skirtingų skyrių be žmogaus įsikišimo, tai yra įrankis.
- Ar duomenys yra įstrigę? Ar DI turi prieigą prie viso jūsų verslo konteksto, ar tik prie to, kas yra konkrečioje programinėje įrangoje? Izoliuotas DI yra silpnas DI.
- Kokia yra „žmogaus viduryje“ kaina? Ar ši funkcija vis tiek reikalauja, kad žmogus prisijungtų, spustelėtų mygtuką ir lauktų atsakymo? Jei taip, jūs nesumažinote sąnaudų; jūs tiesiog šiek tiek pagreitinote užduotį.
Penny prieš „Magišką mygtuką“
Šiame etape jums gali kilti klausimas, kuo tai skiriasi nuo tokio bendro įrankio kaip ChatGPT naudojimo. Parengiau išsamią analizę Penny prieš ChatGPT, kurioje tai nagrinėjama, tačiau trumpa versija yra tokia: bendras LLM yra galingas variklis, bet jis neturi jūsų verslo žemėlapio. Senojo SaaS DI turi vieno jūsų namo kambario žemėlapį, bet jis nemato likusio pastato.
Mano vaidmuo yra būti architektu. Aš ne tik duodu jums geresnį „Magišką mygtuką“. Aš padedu jums permąstyti, kodėl jums to mygtuko išvis reikėjo.
Verdiktas: nepirkite „pakuotės“, kurkite logiką
Kitą kartą, kai pardavėjas pasakys, kad jų programinė įranga dabar yra „DI pagrįsta“, nesusižavėkite. Būkite smalsūs. Paklauskite apie API ribojimus, paklauskite apie duomenų perkeliamumą ir, svarbiausia, paklauskite, kodėl vis dar reikia pilnos kainos vartotojo licencijos, jei DI atlieka pagrindinį darbą.
Verslai, kurie laimės ateinantį dešimtmetį, nebus tie, kurie ant savo senų įrankių turės daugiausia „DI lipdukų“. Tai bus tie, kurie turės drąsos atsisakyti išpūstų sąsajų ir sukurti paprastesnes, greitesnes, „begalves“ operacijas, kurios DI laiko esme, o ne priedu.
Jei esate pasiruošę nustoti mokėti Sąsajos mokestį ir pradėti kurti tikrą DI strategiją, peržiūrėkime jūsų operacijas. Tikslas nėra turėti „DI pagrįstą“ programinę įrangą; tikslas yra turėti DI varomą verslą.
Kokia yra viena „DI funkcija“, kurią neseniai išbandėte ir kuri atrodė labiau kaip reklaminis triukas, o ne esminis pokytis? Pasikalbėkime, kodėl.