Editorial Note: Sa nakaraang dalawampung taon, ang mga kahalintadang pangkaligtasan ng SaaS ay malawak na itinayo sa UI. Ang mga dashboard, fields, workflow ng pagpapahintulot, at mga gawi ng user ay hindi lamang mga interface ng paggamit, kundi nagpapakilala rin ng paraan ng paggawa ng organisasyon at ang orden ng data. Kapag ang AI ay maaaring direktang basahin ang data, tawagan ang mga kasangkapan, at pagsabihin ang proseso, ang pagkakadikit na nabuo sa pamamagitan ng muskulo memorya ng tao ay nagsisimulang mabawasan, at ang UI ay hindi na kailangang maging pangunahing interface ng enterprise software.
Hindi ito nangangahulugan na nawawala ang halaga ng sistema ng pag-record, kundi ang pagtatanggol nito ay nagpapalitan: mula sa UI at mga gawi sa paggamit, patungo sa mga modelo ng data, sistema ng mga pahintulot, responsibilidad sa pagtutugma, negosyong lohika, pagsasaput ng pagsasagawa, at network ng maraming bahagi. Ang mga software na may tunay na hadlang sa hinaharap ay maaaring hindi na lamang mga database na nag-uukit ng mga gawaing tao, kundi mga aktibong sistema na nakakakuha ng konteksto, nagpapalabas ng mga gawain, nagkoordinasyon ng mga intelligent agent, at patuloy na gumagawa ng bagong data habang isinasagawa.
Kapag ang software ay umuunlad patungo sa headless, nagbabago rin ang pangunahing problema ng enterprise software: ang halaga ay hindi na lamang kung sino ang may-ari ng data, kundi sino ang makakakumbinsi ng mga aksyon na nakabatay sa data.
Ang sumusunod ay ang orihinal:
Noong nakaraang buwan, ipinahayag ng Salesforce na gagawin nilang bukas ang kanilang API at ilalabas ang isang headless (nawawalan ng interface) na produkto. Sa pangkalahatan, nangangahulugan ito na nagtataya ang Salesforce na sa panahon ng Agent, ang kanilang pangunahing halaga ay hindi na pangunahing nanggagaling sa UI, kundi sa data layer. Ito ay isang napakatalino pagbabago ng posisyon.
Gayon man, mahalagang tukuyin na mula sa teknikal na pananaw, ang paglalabas na ito ay tila hindi nagdala ng maraming makabuluhang pagbabago. Ang mga API na muling isinama ng Salesforce bilang “headless product” ay malawak nang umiiral na sa loob ng maraming taon. Sa madaling salita, ito ay mas isang karaniwang paglalabas ng Salesforce.
Ang pangunahang ideya ng bagong produkto ay ang Agent ay maaaring direktang makakuha ng data mula sa system ng rekord, nang hindi na kailangang mag-interactive sa pamamagitan ng UI na disenyo para sa mga tao. Ang tradisyonal na UI ay naglalayong tulungan ang mga user na tao na subaybayan ang proseso, pamahalaan ang mga gawain, at pagbutihin ang workflow; ngunit matapos ang pagpasok ng Agent, nagsisimulang bumaba ang kahalagahan ng antas na ito ng interface.
Ang totoong pag-uusap sa paglabas na ito ay hindi lamang kung ano ang ipinakilala ng Salesforce, kundi ang mas malalim na tanong na itinaya nito: Kung alisin ang UI at buksan lamang ang ilalim na database, ano na ang natitira sa isang sistema ng pag-record? Gaano karami ang pagkakaiba nito sa isang Postgres database, isang maayos na disenyo na data schema, at isang set ng API?
Mas malalim pa, ang mga klasikong salik na dating nagbigay ng matagalang pagtatanggol sa mga sistema ng rekord, ba'ti pa ba ito o mayroon nang mga bagong pamantayan sa kompetisyon?
Sa panahon ng SaaS, ang mga sistema ng pag-record ay may malaking kahalagahan dahil ang mga tao ay nagpapaliban nang matagal sa kanilang interface. Ang interface ay nagdudulot ng mga karaniwang gawain, organisasyon ng proseso, at pagkumpuni ng data, na nagbuo ng mataas na gastos sa paglipat. Ngunit sa panahon ng Agent, ang kahalagahang ito ay nagsisimulang mawala. Ang tunay na may kakayahang magtagpo ay nasa isang bahagi ay bumababa patungo sa mga modelo ng data, sistema ng pahintulot, lohika ng workflow, at kakayahang magkomplya; at sa isa pang bahagi ay umuunlad patungo sa epekto ng network, kakayahang maglikha ng eksklusibong data, at kakayahang magpapatupad sa mundo ng katotohanan.
Kapag ang software ay umuunlad patungo sa headless, saan magkakaroon ng paglipat ng competitive advantage?
Ang UI ay dating ang produkto mismo
Ang tinatawag na System of Record (SoR) ay ang awtoritatibong pinagmulan ng isang uri ng negosyo data. Ito ang lugar kung saan matatagpuan ang "opisyal na bersyon" ng mga datos tulad ng ugnayan sa customer, mga rekord ng empleyado, o mga transaksyon sa pondo, at ito rin ang pangunahing sistema kung saan binabasa at isinusulat muli ng iba pang mga kasangkapan ang data. Ang CRM ay ang system ng record para sa mga data kaugnay sa kita, ang HRIS ay ang system ng record para sa mga data kaugnay sa tao, at ang ERP ay ang system ng record para sa mga data kaugnay sa pondo at pagsasapalaran.
Ang lakas ng mga sistema na ito ay hindi lamang dahil sa pag-iimbak ng data, kundi dahil naging «totoong bersyon» na sila na kung saan umaasa ang buong organisasyon sa kanilang paggalaw.
Sa loob ng nakaraang dalawampung taon, ang binenta ng Salesforce sa mga kliyente ay isang paraan para sa mga tagapamahala ng pagbebenta na pamahalaan ang kanilang mga team. Ang mga dashboard, mga pananaw ng sales pipeline, mga tool para sa pagpapahalaga, at mga dinamikong stream ng impormasyon ang tunay na binebenta. Ang kanilang business model ay nakabatay sa pagbebenta ng mga seat sa mga user, na sa kanyang pagkakatao ay nagbibigay ng pag-access sa mga function na ito. Bagaman ang ilalim na database ay mahalaga, ito ay mas mukhang isang impalpable na imprastruktura sa user experience.
Ibig sabihin, ang tunay na nagpapalakas ng pagkakadikit ng mga user ay ang UI.
Ang UI ay nagtatag ng mga pamantayan sa data at nagbuo ng isang karaniwang wika: mga lead, mga pagkakataon, at mga account ng customer. Ito ang nagpapahintulot sa mga libo-libo ng sales representative na magpatuloy sa pagpapakilala ng mga data na kanilang hindi nais ipakilala. Noon, ang UI ay ang mekanismo na nagpapanatili sa konsistensya at pagkakaroon ng data. Ang Salesforce ay may mataas na pagkakabukod dahil maraming mga head of sales ang patuloy na dala ang Salesforce sa kanilang bagong kumpanya pagkatapos magpalit ng trabaho — hindi dahil sa kanyang interface, kundi dahil naging muscle memory na ito.
Ngunit ang mga agent ay nagsisimulang palitan ang modelo na ito. Hindi na kailangan nilang mag-interactive sa software sa pamamagitan ng UI, kundi direktang makakabasa at makasusulat sa ilalim na data. Ito ay nagdulot din ng isang bagong hanay ng mga tool at alternatibong solusyon na umaalis sa tradisyonal na interface. Hindi lang Salesforce ang halimbawa: noong recent, tinatalakay namin kung paano umuunlad ang isang buong ecosystem na mas angkop para sa AI na pagtawag sa paligid ng SAP.
Samantala, ang mga Agent na makapagpapatakbo ng computer ay gagawing hindi na mahalaga ang mga tradisyonal na faktor sa antas ng tao tulad ng mga pagkakaintindi, pagsasanay, at konteksto na hindi dokumentado, habang dumadaloy ang oras. Sa ibang salita, ang mga kondisyon na kailangan upang maging isang patuloy na sistema ng rekord ay nagbabago.
Kahit na nakaraang pamantayan sa pagmamarka
Bago talakayin kung ano ang magiging pagbabago sa panahon ng Agent, kailangan muna nating bumalik nang mas tiyak sa isang tanong: Ano nga ba ang nagiging dahilan sa pagkakadikit ng mga sistema ng rekord sa nakaraan?
Ang mga nakaraang salik ay pangunahing may kaugnayan sa kung paano ginagamit ng mga tao ang software at sa kanilang sariling mga pagpapahalaga. Ang pagkakaroon ng mahirap palitan ang software ay malaking bahagi na nakasalalay sa UI, mga gawi sa paggamit, mga proseso ng trabaho ng tao, at mga institusyonal na pagkakakilanlan na naka-embed sa mga proseso ng organisasyon.
Una, gaano kadalas ito binibisita?
Ginagamit ng GTM team at iba pang mga kagawaran araw-araw ang CRM. Ito ang mataas na paggamit ang nagiging dahilan kung bakit ito ay isang mahalagang imprastruktura. Ngunit ang tao na layer na nakabatay dito—tulad ng mga regular na pagpupulong ng team, mga operasyonal na gawi, at mga ritmo ng pamamahala na nabuo sa loob ng maraming taon—ay madalas ang pinakamahirap na i-migrate. Dahil sa katotohanang ito ay madalas ay hindi kinikilala bilang “bagay na kailangang i-migrate.”
Ikalawa, ito ay write-only ba, o read at write?
Ang totoong may kakayahang mag-attach na sistema ay karaniwang isang bidireksyonal na sistema sa pagbabasa at pagpapalit. Sa halimbawa ng CRM, hindi ito isang sistema na naglalayong lamang mag-arkibo, kundi ito ay patuloy na binabasa. Bawat tala ng tawag, bawat pag-update ng yugto, at bawat paglikha ng gawain ay ipinapasa ng isang user, at karaniwan ay may kinalaman din ang user sa paraan ng paggamit ng mga data pagkatapos.
Ang dalawang direksyon na paggalaw na ito ay nangangahulugan na ang anumang alternatibo ay dapat makapagpapatuloy sa mga real-time na operasyonal na data, hindi lamang mag-export ng isang historical na data. Halos walang ganap na ligtas na punto para sa paglipat sa proseso ng migration. Kaya, matapos ang isang kumpanya ay magsimula, karaniwang mananatili ito sa loob ng sistema ng orihinal na supplier.
Sa kabaligtaran, ang Applicant Tracking System (ATS) ay karaniwang mas malapit sa isang "write-only" system. Pagkatapos ng pagpili o pagtanggi sa isang kandidato, may limitadong dahilan ang mga kumpanya na bumalik at gamitin ang mga data na iyon.
Ilang mga hindi dokumentadong SOP ang mayroon?
Ang tunay na mahalagang konteksto ng negosyo ay karaniwang hindi nakasulat sa anumang wiki, kundi nakapag-umpisa sa mga alituntunin sa workflow na itinayo ng mga administrator at system integrator sa loob ng maraming taon.
Halimbawa ng isang sales system, ang mga hindi dokumentadong konteksto ay maaaring kasama ang: kailangan ng pagpapahintulot ng VP para sa mga corporate transaction na hihigit sa $100,000; kailangan ng privacy review para sa mga transaksyon sa rehiyon ng EMEA; at ang discount para sa strategic clients ay maaaring i-bypass ang financial approval lamang sa dulo ng quarter.
Ang mga kontekstong ito ay madalas ang nagdedesisyon kung kaya bang maipagpatuloy nang maaga ang isang bagay, o kung kaya bang matapos nang hindi lumabag sa mga mahahalagang proseso. Ang paglipat ng sistema ay nangangahulugan ng pagbabalik sa pagkakabuo ng bawat automated rule; kung hindi, maaaring mawala agad ng bahagi ng organisasyonal na memorya ng kumpanya.
Ikaapat, gaano kakomplikado ang mga panloob o panlabas na pagkakasalig?
Ang pangunahing tanong ay: Gaano karaming mga loob na sistema, proseso ng tim, o panlabas na interesado ang nakadepende sa sistemang ito?
Ang internal connectivity ay tumutukoy sa bilang ng mga downstream software o workflow na nakadepende dito. Ang external connectivity naman ay tumutukoy kung kailangan ng mga panlabas na partido tulad ng auditor, accountant, at regulatory agencies na makapag-access nang direkta sa mga data nito. Ang ERP ay isang klasikong halimbawa.
Anuman ang loob o labas, mas komplikado ang mga ugnayan na kailangang disasemble at i-rebuild habang nagmamigrasyon kung mas mataas ang konektibidad.
Ika-lima, gaano kahalaga ang data mula sa pananaw ng pagkakasundo?
Ang pangunahing tanong dito ay simpleng: May komplikansya ba ang sistema?
Ang mga kompliyans na kritikal na sistema tulad ng payroll, ERP, at mga datos ng人力资源 ay dapat magbigay ng isang legal na mapagkakatiwalaang pinagmulan ng katotohanan at may mahigpit na kontrol sa mga pagsasakop. Ang anumang paglipat ay maaaring kailanganin ang direkta ng pag-intervensyon ng mga auditor at mga ahensya ng regulasyon. Ito ang nagiging sanhi ng mas malakas na pagkakabond.
Ang mga sales data at mga customer support tool tulad ng Zendesk ay nasa kabilang dulo. Mahalaga ng mga negosyo ang kontinuidad at konteksto, ngunit kung may paglipat ng data o kung may makakakuha ng access, karaniwan ay hindi agad nagdudulot ng panganib sa regulasyon.
Hindi lahat ng sistema ng pag-record ay may parehong antas ng gastos sa pagpapalit. Ang pagkukumpara ng CRM at ATS sa parehong grupo ng dimensyon ay magpapakita ng malaking pagkakaiba.
Ang ATS ay isang tool sa workflow na naglilingkod sa limitadong proseso, na nakatuon sa pag-recruit. Pagkatapos makatanggap o mabalewala ang isang kandidato, ang kaugnay na rekord ay karamihan ay naging data na isinusulat lamang ng isang beses. Mas nararapat ang sakop nito sa integrasyon, at mas maliit at mas nakatuon ang pangkat ng mga gumagamit.
Ang ERP naman ay nasa kabilang dulo. Ang general ledger ay sarili nito ay ang audit trail, at ang mga accountant, auditor, at mga regulahong ahensya ay magiging direkta na mga interesadong partido sa proseso ng migration.
Ang pagpalit ng ATS ay nakakasakit, ngunit masih maipaglalaban. Ang pagpalit ng CRM ay parang open-heart surgery. Ang pagpalit ng ERP ay parang gumagawa ng open-heart surgery sa isang pasyente habang tumatakbo siya ng marathon.
Tradisyonal, ang mga sistema ng rekord ay hindi talaga nagamit ang mga pinagkukunan ng mga lihim na data, network effects, at iba pang mga pinagkukunan ng proteksyon; karaniwan, ang sariling workflow ay sapat na bumubuo ng hadlang. Sa ilang paraan, ang pagpagsasama ng mga kasangkapan at network ay mas karaniwan sa consumer-oriented na negosyo; ang mga SoR sa nakaraan ay hindi sumunod sa landas na ito.
Proprietary data. Kahit na maraming sistema ng pag-record ang nagkolekta ng malaking dami ng data ng customer, hindi ito talaga ginamit nang malalim batay sa mga data na iyon, at sa maraming kaso, hindi pinapahintulutan ng mga tuntunin ng kontrata ang ganitong paggamit. Kaya, bagaman mayroon ang CRM sa malawak na set ng data at teoretikal na maaaring i-summarize ang data ng iba’t ibang customer upang makabuo ng mga insight na pumapaloob sa lahat ng customer, hindi ito ginawa nang may tunay na kahulugan. Totoo, may ilang pagsubok na ginawa ng mga produkto tulad ng Einstein ng Salesforce.
Network effect. Ang pinakamainam na moog para sa isang sistema ng pag-record ay ang network effect: halimbawa, mas magiging mas value ang CRM dahil ang mga seller ng software ay makakahanap ng mga buyer dito. Ngunit tulad ng data, ang network effect ng mga sistema ng pag-record sa kasaysayan ay palaging mahina, o kaya ay halos walang kahulugan.
Kung nawala ang UI, ano ang natitira sa software pagkatapos dumating ang Agent?
Hindi kailangan ng agent ng browser. Kailangan nito ang API, konteksto, mga utos, at ang kakayahang magpatawag ng mga aksyon. May dalawang bagay na nagpapahintulot sa lahat ng ito na maging scalable: una, ang LLM ay may sapat na kakayahang mag-isip, kaya ngayon ay maaari ng agent na basahin ang konteksto, gumawa ng plano, piliin ang mga kasangkapan, magpatawag ng mga aksyon, at suriin ang mga resulta, at sa karamihan ng mga gawain ay hindi na kailangan ng tao; pangalawa, ang MCP ay nag-standardize ang paraan ng pag-access sa mga kasangkapan, nagbibigay ng isang pangkalahatang interface para sa pagtawag ng eksternal na kakayahan ng agent.
Isang Agent na may pagsasakop sa MCP ay maaaring kumpletuhin sa loob ng mga milyong segundo at sa malaking iskala ang mga aksyon na dati ay ginagawa ng mga tao sa platform, nang walang pangangailangan ng browser. Sa sapat na konteksto, ang isang Agent na may kakayahang mag-operate ng computer ay maaari ring direktang gamitin ang mga umiiral na interface ng software, hindi lamang ang API.
Sa simpleng pagtingin, mayroon ngayong tatlong daan ang buyer ng software:
Una, patuloy na gamitin ang umiiral na sistema at idagdag dito ang Agent.
Gamitin ang mga ito sa pamamagitan ng CLI at API ng umiiral na sistema, maaari mong gamitin ang native na Agent product ng vendor, tulad ng Agentforce ng Salesforce at Joule ng SAP, o maaari mong itayo ang iyong sariling Agent dito. Sa kasalukuyan, ipinapalagay nating ang API ay kompletong available, at isinasaalang-alang natin ang komplikasyon na dulot ng “headless” na pagpapatakbo.
Ikalawa, ganap na sariling sistema ng pag-record.
Maaaring magsimula ang mga negosyo sa pagbuo ng kanilang sariling modelo ng data, logika sa operasyon, sistema ng mga pribilehiyo, pagsusuri ng pagtatawid, at integrasyon ng sistema, kasama ang kanilang sariling hanay ng Agent. Ang path na ito ay malamang na magagamit ang mga third-party na tool para sa pagbuo ng Agent at mga database tool.
Ikatlo, bumili ng mga alternatibong AI-native.
Maaari rin ng mga negosyo bumili ng mga bagong henerasyon ng software na disenyo na para sa Agent era mula sa simula. Ang mga produkto na ito ay nagtataglay ng machine readability, at itinuturing ang agent orchestration bilang isang pangunahing kakayahan, hindi lamang isang pagdaragdag na AI function sa mga lumang sistema. Maaari ring headless ang mga produkto na ito.
Ano ang mga bagay sa dating sistemang pagmamarka na mananatili?
Ang mga factor na dinudulot ng pagkilos at pagkakapili ng tao, tulad ng kadalian ng pag-access, ang dalawang direksyon na katangian ng pagbasa at pagsulat, at iba pang mga indikador na kaugnay sa muskulo memorya ng tao, ay magiging mas maliit sa paglipas ng panahon. Ang mga Agent ay maaaring mapabawasan ang halaga ng “muskulo memorya” bilang parapeto, ngunit hindi nila tatanggalin ang parapeto ng operasyonal na lohika at konteksto ng negosyo. Sa isang paraan, ipinapalakas nila ang kahalagahan ng mga lohikang ito, dahil upang magsagawa nang ligtas ang mga Agent, kailangan nilang basahin ang malinaw na mga patakaran, pagsasamantala, at depinisyon ng proseso.
Ang mga hindi dokumentadong SOP ay mahalaga pa rin sa maikling panahon.
Ang mga patakaran na nakapaloob sa mga patakaran ng workflow sa loob ng organisasyon ay ang mga bagay na kailangan ng Agent upang mabuti mong maisagawa ang mga gawain. Samantala, ito rin ang pinakamahirap na ibalik. Sa kasalukuyan, hindi pa ito maaaring malinis na i-export, lalo na kung mayroon pa ring bahagi ng proseso na nangangailangan ng tao. Gayunpaman, ang pagkuha ng konteksto ay nagsisiging mas madali; habang ang Agent ay nagpapalit sa mas maraming trabaho ng tao, ang kahalagahan nito ay magiging mas maliit.
Ang konektibidad ay patuloy na mahirap i-deconstruct, at magpapalawak pa sa mas malalim na antas.
Ang kahulugan ng konektibidad ay nagbabago. Hindi na ito para lamang sa pagtutulungan sa mga tao, kundi para sa pagpapanatili ng koneksyon sa pagitan ng mga tungkulin at software na dati ay hiwalay.
Kailangan ng isang CRM Agent na i-ugnay ang mga data at konteksto mula sa iba’t ibang yugto tulad ng pagbebenta, mga taksil, at tagumpay ng kliyente. Kung ang iyong platform ay naging node din para sa mga transaksyon sa pagitan ng maraming panlabas na organisasyon, tulad ng mga bumibili, nagbebenta, at mga kasosyo na nagtatapos ng kanilang interaksyon dito, mas lalalim ang mga pagkakaintindihan.
Kapag nagdadagdag ang mga manufacturer ng Agent, maaaring mahirapan sila na magtrabaho nang maayos sa pagitan ng mga pangunahing object at lohika ng iba’t ibang paaalaman na software; ang mga negosyo na nagtatayo lamang ng isang sariling database at isang grupo ng Agent ay maaaring makaharap sa katulad na problema.
Ang mga kritikal na datos para sa pagkakasunod ay patuloy na mahalaga.
Ang mga datos na may kinalaman sa mga ahensya ng regulasyon, panganib ng regulasyon, o panganib sa batas ay nangangailangan pa rin ng isang iisang, kapanipaniwalaang pinagkukunan ng datos. Kung ang mga customer ay nagsisilbi na sa umiiral na produkto, mas mababa ang posibilidad na sila ay magpapalit ng sistema.
Halimbawa, sa mga datos ng sahod at akuntansi, maaaring kailangan talaga ng Agent na makapag-access sa mga data na ito, ngunit karaniwan ay hindi malamang na piliin ng mga negosyo na itayo at matagalan na pangalagaan ang ganitong uri ng sistema sa loob ng organisasyon.
Sa isang mundo na lubos na Agent-angkop, isa sa mga pinakamahirap na isyu ay: Ano ang mga awtorisadong gawain ng bawat Agent? Sino ang kanilang kinakatawan? Paano ito ia-audit? Kung ang isang sistema ng rekord ay maaaring maging layer ng identidad at pahintulot sa pagitan ng mga Agent, ito ay makakakuha ng isang structural na papel na talagang mahirap palitan. Ang mga hadlang dito ay hindi lamang kung ano ang data na ito ay may-ari, kundi ano ang trust architecture ang ito ay ipinapatupad.
Tingnan ang nakararating, para sa mga bagong startup na AI-native, isang bagong hanay ng mga salik ay magiging lalong mahalaga at magpapasya kung kaya nilang bumuo ng pagkakaroon ng pagtatanggol.
Una, gaano kahirap baguhin ang sistema ng rekord na ito?
Mas mahalaga ang data sa ilang antas.
Una, sa maikling panahon, ang susi ay ang kalakasan at kahirapan sa pagkuha at pagbuwa muli ng mga datos sa ilalim ng sistema ng rekord. Ang AI ay nagiging mas madali ang proseso, at isang hanay ng mga kasangkapan ay tumutulong sa mga gumagamit na kumpletuhin ang ganitong uri ng paglipat at pagbuwa muli.
Sa maikling panahon, ang mga umiiral na kumpanya ay maaari at malamang na gawing mas mahirap ang bagay na ito: maaari nilang gawing mahirap gamitin ang API, magtakda ng mga limitasyon, maging hindi kompletong, o gawing hindi ekonomiko sa ekonomiya, o kaya ay hindi magbigay ng API sa lahat. Ngunit habang patuloy na umuunlad ang mga kasangkapan para sa pagkuha, lalo na ang kakayahan ng mga Agent na makapag-operate ng computer, mas madaling mabuo muli ang data.
Samantala, binubuo rin ng bagong kumpanya ang isang mas mayamang set ng data mula sa mga email, tawag, voice agent, at panloob na dokumento. Tinurunkan ng AI ang 80% ng gastos sa pagbuo ng isang sistema ng rekord. Ang nagpapakita ng pagkakaiba sa pagitan ng isang kapaki-pakinabang na pagsisimula at isang tunay na alternatibo ay ang natitirang 20%: mga kakaibang kaso, mga proseso ng pagpapayag, mga pangangailangan sa pagkakaroon ng pagsunod, at mga workflow sa mga edge scenario.
Ikalawa, mayroon ba kayo ng tunay na makabuluhang propiyetaryong data?
Sa pangalawa, ang data mismo ay magiging mas may halaga.
Ang totoong may kakayahang magbigay ng proteksyon ay hindi ang data na iyong ikinokonsulta, kundi ang data na likha ng iyong produkto nang may pagkakaiba. Karaniwang sinasabi natin ang “data walled garden”: ang mga data na ito ay either proprietary, nakalulupad sa regulasyon, o nangangailangan ng patuloy na pag-update. Ang isang software supplier na nag-invest ng malaking yaman sa pagkuha ng awtoridad at kompletong data, ay may malinaw na kahihintay kumpara sa mga pangkalahatang supplier o mga kalaban na kulang sa ganitong uri ng data.
Mayroon pa pong isa pang mahalagang direksyon ang data: kung ito ay nakasalalay sa mga aksyon na ginawa sa loob ng produkto.
Hindi lamang nag-iimbak ng mga data na kinuha mula sa ibang lugar ang pinakamahusay na mga kumpanya. Sila ay patuloy na nagpapalikha ng mga bagong trace ng data dahil nasa loob sila ng proseso, tulad ng obserbadong pag-uugali, rate ng pagtugon, mga pattern ng oras, resulta ng proseso, industry benchmark, anomalous patterns, at mga trace ng pagpapatupad ng Agent.
Ang susi ay: ang data ay ang konteksto ngayon.
Ikatlo, alam mo ba ang action layer?
Sa lumang mundo, sapat na ang pag-iimbak ng mga rekord. Ngunit sa bagong mundo, gagawin ng Agent ang direkta aksyon, at ang pagtatanggol ay maaaring magdirekta sa mga produkto na makakabuo ng isang saradong loop: mula sa paggawa ng aksyon, hanggang sa pagkuha ng resulta, at pagkatapos ay paggamit ng feedback para mapabuti ang mga susunod na desisyon.
Para sa ERP, maaari itong maglalayong mag-apruba ng gastos, mag-trigger ng pagbabayad ng sahod, i-verify ang mga invoice, at magpadala ng mga abiso. Mas masaklaw ang mga produkto na may闭环 dahil nakapaloob na nila ang proseso ng pagpapatupad, hindi lamang nasa antas ng pagmamasid. Gumagawa sila ng natatanging data na patuloy na nagpapabuti habang ginagamit, at mas mahirap palitan dahil sa pagkawala nito ay babagsak ang workflow.
Siyempre, habang lumalala ang konteksto at mas maayos ang pagtrato sa mga edge case, dadami pa ang halaga dito.
Ikaapat, mayroon ba itong mga hakbang sa pagsasagawa sa tunay na mundo?
May ilang negosyo na may koneksyon sa mga operasyon sa totoong mundo na hindi lubos na automated. Ang pinakamalinaw na halimbawa ay ang mga kumpanya na may operasyonal na network, tulad ng DoorDash. Kahit na hindi ito tradisyonal na bahagi ng mga sistema ng rekord, napakalaking aral nito dito.
Mas malawak na sinasabi, ang anumang kumpanya na makakapagpahaba ng software loop patungo sa mga serbisyo, pagpapatupad, logistik, operasyon sa lugar, o mga transaksyon sa pagbabayad, ay may isang uri ng pagtatanggol na iba sa pure SaaS. Ang mga kumpanyang ito ay hindi lamang nag-iimbak ng mga rekord o nagrerekomenda ng mga aksyon; sila ay nagpapadala ng mga tao, naglilipat ng mga kalakal, o nagtatapos ng mga partikular na serbisyo.
Para sa mga entrepreneur, ibig sabihin nito na ang mga pagkakataon ay maaaring lumabas sa mga merkado kung saan ang software ay lalong nakakagawa ng mga desisyon, at ang mga agent ay lalong nakakapagkoordineta ng mga proseso, ngunit ang huling kilometer ay kailangan pa rin ng real-world execution. Halimbawa, ang mga vertical software na nakabase sa on-site service ay isang tipikal na direksyon.
Ika-lima, mayroon bang network effect?
Sa kasaysayan, ang karamihan sa mga network effect ng mga sistema ng rekord ay mahina, dahil ito ay pangunahin mga pampanloob na software. Ngunit sa panahon ng Agent, kung isinasama ng isang sistema ang mga workflow ng maraming partido, maaaring maging mas mahalaga ang network effect.
Kung isang sistema ang responsable sa pagpapalit ng paulit-ulit na interaksyon sa pagitan ng maraming partido, tulad ng buyer at seller, employer at employee, company at auditor, supplier at customer, at payer at service provider, bawat dagdag na partido ay maaaring gawing mas may halaga ang network para sa susunod na partido.
Isa sa mga paraan ay ang pagbabahagi ng workflow para sa pagkakasundo: ang produkto ay naging lugar kung saan ang parehong panig ng proseso ay nagtatrabaho, nagpapalitan ng konteksto, at nagdadala ng mga anomaliya.
Isang iba pang paraan ay ang batayan at kamalayan: ang sistema ay maaaring magpakita ng karaniwang industriya, mga anomaliya, at mga rekomendasyon para sa aksyon batay sa mga pattern na nakikita sa network, na nagpapalakas muli sa halaga ng data na nabanggit sa itaas.
Ang ikatlong paraan ay ang pagkakaroon ng tiwala at pagkakasunod: kapag ang mga kalaban sa transaksyon ay nagsisimulang magtiwala sa iisang set ng proseso para sa pagpapahintulot, pagpapasa, pagpapatutupad ng patakaran, o pagbabayad, ang produkto ay hindi na lamang isang database, kundi ang sariling kooperatibong imprastruktura ng merkado, kaya mas mahirap itong palitan.
Ikaanim, gaano katalino ang teknikal na kakayahan ng mga bumibili?
Sa isang mundo kung saan teoretikal na kayang magbuo ng anumang Agent ang sinuman, ang tunay na kakayahan ng iba’t ibang buyer ay patuloy na malaki ang pagkakaiba. Lalo na sa mga vertical industry at sa mga function-based buyer na dati ay walang malakas na internal engineering resources, maliit pa rin ang posibilidad na sila mismo ang magbuo, magpanatili, at magpatuloy na mapabuti ang database, workflow logic, Agent stack, at governance layer.
Ang gastos ay mahalaga rin dito. Ang DIY ay teoretikal na maaaring mabawasan ang mga bayarin sa lisensya ng software, ngunit karaniwang isasalin ang gastos sa pagpapatupad, pagpapanatili, at panloob na kumplikasyon.
Ibig sabihin nito, mayroon pa ring tunay na pagkakataon sa mga kategorya na may komplikadong operasyon ngunit kulang sa teknikal na suplay. Halimbawa ang paggawa, back-office ng pagtatayo, industriyal na proseso, field service workflow, at accounting.
Mayroon pa ring iba pang mga salik na magkakaparehong kahalagahan at magiging pangunahing pamantayan sa software.
Halimbawa, kailangan magbago ang ontolohiya. Maraming ideya tungkol sa “pagbuo ng sariling database” ang nagkakamali sa pagbabawal ng halaga na dinala ng object model. Ang umiiral na software ay binuo para sa dashboard, report, at mga human user, at ito ay nagsasalita ng mga object sa loob ng workflow, tulad ng opportunity, ticket, at kandidato.
Ngunit ang schema ng Agent Era ay kailangang matanggap ang pag-iisip, mga aksyon, pagsubaybay ng estado, pag-handle ng mga anomaliya, pag-delegado ng mga gawain, at koordinasyon sa pagitan ng mga sistema. Ang native object model ay maaaring hindi na ang mga pagkakataon, mga tiket, at mga kandidato, kundi ang mga gawain, intensyon, mga thread, estratehiya, o resulta.
Kailangan din i-update ang sistema ng mga pahintulot. Hindi na ito lamang pamamahala sa mga tao, kundi pati na ang mga Agent. Kasama rito: sino ang makakagawa ng anumang gawain, sa pamamagitan ng anong Agent, sa ilalim ng anong patakaran, kailangan ng anong pagpapahintulot, anong mga rekord ng audit ang dapat iwanan, at paano gagawin ang rollback at pagharap sa mga anomali.
Totoo naman na lahat ng ito ay nakadepende sa gastos, tulad ng kung magkano ang pagbuo at pagpapanatili ng Agent at database, at gaano karami ang gastos sa pag-access sa API. Ito ay babalik muli sa ilang pangunahing tanong: gaano kahirap ang pagbuwa ng data, gaano karami ang mga dependensya, at gaano kahalimuyak ang sistema.
Ano kaya ang konklusyon?
Samantalang lumalakad ang mga umiiral na software vendor patungo sa headless, sila ay nagtataya nang impluwensyal: ang data layer ay patuloy na magiging pinagmumulan ng halaga. Sa ilang kategorya, lalo na sa mga larangan tulad ng financial services na malalim na pinagdadaanan ng compliance, maaaring magpatuloy pa ang taya na ito sa ilang panahon, at maaaring mas mabagal ang proseso ng headless.
Ngunit para sa mga entrepreneur sa software, habang ang mga umiiral na kumpanya ay nagsisimula nang alisin ang mga interface, ang paraan ng pagtutulungan at pagbuo ng software na may matagalang pagtatanggol ay nagbabago.
Ang susunod na henerasyon ng sistemang pagsasalaysay ay nagsisimulang magkakaroon ng iba’t ibang anyo: hindi na ito mga data warehouse na ginagamit lamang para sa pagsasalaysay ng trabaho ng tao, kundi mas may katangian ng Agent—kakayahang makakuha ng konteksto, aktibong magmula ng trabaho, at mag-record ng mga trace ng data na nabuo sa proseso ng pagsasagawa.
Sa mas malalim na antas, ang pinakamalikhaing mga kumpanya ay magkakaroon ng real-world execution: magkakakoordinasyon sila ng mga field staff, mga logistics provider, mga serbisyo team, at mga pisikal na ari-arian, o magiging intermediate layer sa pagitan ng maraming bahagi.
Ang mga kumpanyang ito ay magkakaroon ng pagkakaisa ng iba’t ibang negosyong modelo mula sa lumang mundo. Samantala, ang pangunahing sangkap ng tradisyonal na sistema ng rekord, ang data, ay magiging paulit-ulit na nasa likod at magiging pundasyon na nagpapatakbo ng buong sistema.
I-click para malaman ang mga posisyon na ina-offer ng BlockBeats
Maligayang pagdating sa opisyal na komunidad ng BlockBeats:
Telegram subscription group: https://t.me/theblockbeats
Telegram group: https://t.me/BlockBeats_App
Twitter official account: https://twitter.com/BlockBeatsAsia