Arnav Mishra, Co-Fondator și CTO al Doss – Seria de Interviuri

Arnav Mishra, Co-Fondator și CTO al Doss, este un inginer full-stack și lider tehnic cu o experiență care acoperă startup-uri de dimensiuni mici și sisteme de infrastructură de mare scară. Înainte de a co-fonda Doss, el a fost inginer fondator la Siteline, unde a construit sisteme de bază, incluzând arhitectura permisiunilor, integrări ERP și cadre de automatizare, contribuind, de asemenea, la recrutare, operațiuni de venituri și cultură de companie. La începutul carierei sale, el a ocupat funcții de inginer la Rubrik și a făcut stagii la companii precum Uber și VMware, dezvoltând expertiză în infrastructură de cloud, sisteme de date și automatizare. Alături de munca sa tehnică, el a fost implicat activ în mentorat și dezvoltarea de talente prin organizații precum Techquitable Futures și Contrary, reflectând un angajament mai larg de a sprijini următoarea generație de ingineri.

Doss este o companie de software enterprise modernă, axată pe reinventarea sistemelor ERP tradiționale prin intermediul Platformei Adaptive de Resurse (ARP), o platformă operațională flexibilă și nativă AI, proiectată pentru a unifica și automatiza fluxurile de lucru ale afacerilor. Construită ca o alternativă componibilă la soluțiile ERP legacy, Doss permite companiilor să gestioneze stocurile, achizițiile, finanțele și îndeplinirea comenzilor într-un singur sistem care se adaptează operațiunilor din lumea reală, mai degrabă decât să impună procese rigide. Platforma sa combină un strat de date centralizat, fluxuri de lucru fără cod și analize în timp real, permițând firmelor să implementeze rapid, să se integreze cu instrumentele existente și să-și evolueze continuu operațiunile fără implementări lungi sau consultanți costisitori.

Motivația pentru construirea DOSS se datorează experienței lui Wiley, care a văzut cum software-ul legacy a perturbat afacerea de fabricație a tatălui său, iar mai târziu, ambele au văzut probleme similare în timp ce lucrau cu fabrici și lanțuri de aprovizionare cu hardware. Cum v-au influențat aceste experiențe decizia de a co-fonda DOSS și de a reimagina sistemele ERP de la zero?

Înainte de DOSS, eram inginer fondator la un startup FinTech. Motivul nr. 1 pentru care cumpărătorii noștri – CFO, contabili etc. – nu au ales soluția noastră a fost pentru că erau „prea ocupați implementând un ERP”. Când am cercetat mai profund în domeniul arhaic al ERP, am fost șocat de modelul de implementare existent.

Ce am văzut constant a fost aceeași eșec fundamental: implementarea durează luni sau ani, costă sute de mii sau milioane de dolari și este blocată în întregime de consultanți umani cu facturare pe oră. Apoi, odată ce ERP-ul este livrat, el încetează să se mai schimbe. Afacerea continuă să evolueze; sistemul nu. Acesta este un problemă arhitecturală, nu una de configurare. Nu poți rezolva asta prin patch-uri.

Ca constructor de software, cea mai apropiată comparație pe care am putut-o face a fost următoarea: imaginați-vă o lume în care cel mai important instrument pe care îl folosiți – ca dezvoltator, să zicem GitHub – a fost construit special pentru compania dvs. pe parcursul a ani de zile de către o agenție de consultanță terță. Apoi, odată ce produsul este terminat, consultanții pleacă fără întreținere, fără îmbunătățiri de funcționalități și fără suport. Inginerii s-ar revolta.

Nicio companie de tehnologie modernă nu poate operaționa în acest model. Wiley și cu mine am ajuns la aceeași concluzie: singura modalitate de a remedia această situație era să construim de la zero.

DOSS se poziționează ca o platformă operațională nativă AI, proiectată pentru a înlocui sistemele ERP tradiționale, precum SAP sau Oracle. Care sunt diferențele arhitecturale fundamentale care fac posibilă o platformă ERP nativă AI astăzi, dar care nu erau fezabile cu un deceniu în urmă?

Oracle și SAP au fost construite într-o eră în care, pentru a atinge o distribuție maximizată, au trebuit să simplifice planul de configurare al unui ERP pentru a fi un editor GUI pe care consultanții relativ neatribuiți să îl poată livra la scară. Pentru a păstra cele mai bune practici, au blocat porțiuni mari ale sistemelor de bază și au permis doar o compozabilitate la margini. Cu toate acestea, în realitate, atunci când priviți spectrul tuturor afacerilor din lume, aplicațiile lor comerciale necesită o flexibilitate maximă.

Ce permite lumea nativă AI este transformarea ingineriei software de la un meșteșug la o mașină industrializată. Nu mai avem nevoie de artizani software care să creeze sisteme de cod; în schimb, ne îndreptăm spre o lume în care productivitatea software-ului este un factor al computației și token-urilor.

Doss a fost proiectat exact cu acest lucru în minte.

Am construit ZSL, un limbaj declarativ de specificare a domeniului (DSL) care descrie întreaga implementare a unui client Doss în cod. Gândiți-vă la ceea ce a făcut „Terraform” pentru efortul „Infrastructure as Code”, dar aplicat la logică de aplicații comerciale. Prin definirea ERP-urilor într-un limbaj de programare relativ de joasă dimensiune, suntem capabili să deployăm agenți la scară pentru a livra soluții ERP.

Odată ce ZSL a fost scris, partea cea mai importantă a arhitecturii a fost integrarea celor mai bune practici în platformă însăși pentru a preveni agenții să construiască implementări de calitate scăzută. Echipa noastră a livrat un sistem distribuit scalabil cu un programator de nucleu pentru a prelua încărcarea muncii ERP cu sarcină variabilă. Mai mult, am construit un sistem de bază de date HTAP care combină cele mai importante părți ale unei baze de date tranzacționale, cum ar fi Postgres, și capacitățile analitice ale unui depozit de date.

Prin construirea platformei pentru a avea o putere de clasă enterprise de la început, sistemul este pregătit pentru o distribuție agentică în întregime. Ceea ce obișnuia să dureze luni sau ani și echipe de consultanți poate fi paralelizat la scară, utilizând infrastructura agentică din sistemul nostru de buclă închisă.

Multe companii încă se bazează pe foi de calcul și instrumente fragmentate pentru achiziții, gestionarea stocurilor și managementul comenzilor. Care sunt cele mai mari puncte oarbe operaționale care apar atunci când datele comerciale de bază nu sunt unificate într-o singură sursă de adevăr?

Cel mai mare problemă este că deciziile sunt luate pe baza informațiilor învechite sau incomplete. Dacă datele dvs. despre stoc trăiesc într-un loc, comenzile de achiziție în altul și comenzile de vânzare într-un al treilea, sunteți întotdeauna în proces de reconciliere, manual, lent și după fapt. Până când cineva realizează că stocul este în afara graficului sau că un furnizor este în urmă, este deja o problemă în afacere.

Verve Coffee Roasters este un exemplu bun de unde se strică acest lucru în practică. Ei operează operațiuni în magazine, en-gros, DTC și cafenele în SUA și Japonia, dar gestionau totul prin sisteme desconectate, fără vizibilitate în timp real a stocurilor. Ei au rămas fără cafea proprie în locații cu trafic ridicat și au atins stocuri critice în timpul lansării unui retailer major, ceea ce a afectat o relație comercială importantă. Datele existau undeva; ele nu erau doar conectate într-un mod care să permită cuiva să acționeze în timp util.

Problema mai subtilă este că fragmentarea ascunde adevărata formă a operațiunilor dvs. Nu puteți vedea relația dintre o întârziere upstream și o problemă de îndeplinire downstream dacă aceste două lucruri trăiesc în instrumente separate. Ajungeți să gestionați simptome, să expediați comenzi, să construiți stocuri de siguranță și să rulați verificări manuale, în loc de a înțelege ce se întâmplă cu adevărat. Un sistem unificat nu doar economisește timp pe reconciliere. El schimbă ceea ce puteți vedea și întrebați.

La nivelul său fundamental, imaginați-vă conducerea unei afaceri enterprise fără acces la un sistem de control al versiunilor (Git), un instrument de observabilitate (DataDog) sau o bază de date centralizată pentru a interoga informații.

Implementările ERP au necesitat istoric echipe de consultanți mari și luni – sau chiar ani – de implementare. Cum schimbă AI economia și complexitatea implementării software-ului operațional în afaceri reale?

Modelul tradițional de implementare este rezultatul emergent al practicilor de software de generații vechi. Nu mai trăim în acea lume.

Există un stimulent pervers în implementările ERP de astăzi – cu cât implementarea durează mai mult și cu cât este mai ineficientă, cu atât implementatorii primesc mai mulți bani. Majoritatea constructorilor nu ar profita de asta; totuși, ei nu sunt niciodată stimulați să se miște cu viteză și calitate.

Raportul cheltuielilor de consultanță la cheltuielile de software într-o angajare ERP tradițională rulează aproximativ 9:1, așa că cheltuiți nouă dolari pe consultanți pentru fiecare dolar cheltuit pe software însuși. Pentru o întreprindere mare, acest lucru este extrem de dureros. Pentru afacerile de piață mijlocie, este prohibitiv. Așa că fie se mulțumesc cu software care nu se potrivește cu modul în care operează, fie amână proiectul, fie îl abandonează pe jumătate.

AI schimbă complet unitatea economică a acestui lucru. În loc de o angajare de consultanță, o implementare Doss este o bază de cod. Pe măsură ce timpul nostru de implementare continuă să scadă, suntem capabili să aliniem stimulentele cu un model „plătește la livrare” în loc de „plătește pe măsură ce mergi”. Când afacerea se schimbă, sistemul se schimbă odată cu ea. Nevoia de camere pline de consultanți și diapozitive lungi nu mai este relevantă.

Succesul la Doss înseamnă înlocuirea cheltuielilor globale de 1,86 trilioane de dolari pentru servicii IT cu implementare și întreținere agentică, utilizând ZSL-ul nostru ca limbaj pentru software-ul de aplicații comerciale. Succesul la Doss înseamnă comercializarea tuturor aplicațiilor comerciale la scară.

Ați implementat DOSS cu companii care operează în medii reale, cum ar fi producție, logistică și bunuri de consum. Care sunt unele dintre provocările neașteptate care apar atunci când AI întâlnesc date operaționale murdare?

Provocarea rareori este AI-ul. Este datele pe care le cereți să le raționalizeze.

Fiecare afacere cu care lucrăm a acumulat ani de ocoliri operaționale. Datele există tehnic, ele nu trăiesc nicăieri unde angajații, și mai ales sistemele agențice, să poată acționa în mod fiabil.

Un exemplu excelent este un producător german de mobilă care creează piese la comandă. Când am venit, aveau 10 ani de date istorice răspândite în 8 formate de fișiere personalizate cu 11 obiecte de date diferite și o sincronizare 3PL care rulează pe copiere manuală din foldere FTP. Logica afacerii era specifică, cu dimensiuni personalizate, configurații, metode de plată și locații de showroom, și tot sistemul trebuia să funcționeze în limba germană. Nu există un schema standard pentru asta. Trebuiau să plătească mii de euro de fiecare dată când doreau să schimbe opțiuni de configurare simple, cum ar fi opțiunile de stare pentru o comandă de achiziție.

Provocarea nu este complexitatea tehnică a unei singure piese. Este că fiecare afacere are o versiune diferită a acestei probleme, și nu puteți anticipa pe deplin până nu sunteți în interiorul datelor lor. Treaba este să luați o amprentă precisă a modului în care funcționează realmente afacerea, nu să hărțiți datele într-un șablon generic și să sperați că se potrivește.

Pentru a construi o soluție care funcționează pentru lumea reală, aveți nevoie de o platformă cu flexibilitate maximă. Abia atunci AI poate fi util în înțelegerea modelului de date subiacent pe care lucrează și construirea modelului care funcționează pentru fiecare client.

Există multă discuție despre copiloți AI și agenți autonomi în software-ul de afaceri. Unde credeți că AI adaugă cea mai mare valoare în fluxurile de lucru operaționale astăzi, și unde supravegherea umană rămâne esențială?

La scară, AI are capacitatea de a perturba toată munca operațională.

În orizontul apropiat, modelele și agenții noștri Doss ar trebui să poată transforma nucleele consultanților tehnici în implementarea aplicațiilor comerciale, precum și sfaturile consultanților de management în livrarea de recomandări strategice. Doss va avea cel mai mare depozit de date structurate și co-localizate, reprezentând atât schema, cât și informațiile operaționale pentru afaceri. Agenții noștri pot utiliza aceste date pentru a livra recomandări scalabile.

Cea mai clară valoare de astăzi este mai specifică decât atât. Este în munca care este repetitivă, bazată pe reguli și realizată în prezent de oameni care au alte priorități strategice: procesarea comenzilor de achiziție, reconcilierea stocurilor și deciziile de îndeplinire a comenzilor. Aceste sarcini au intrări și ieșiri bine definite, și AI le poate gestiona în mod fiabil la scară.

Pentru moment, supravegherea umană este esențială oriunde costul unei decizii greșite este ridicat, și sistemul nu are încă suficient context pentru a fi încrezător. Astăzi, modelul corect nu este reprezentat de agenți autonomi care înlocuiesc în întregime luarea deciziilor umane; este reprezentat de agenți care gestionează munca de volum mare și bine definită, astfel încât oamenii să se poată concentra pe deciziile care necesită realmente judecata lor.

Multe întreprinderi încearcă să adauge AI peste software-ul existent. Din punctul dvs. de vedere, de ce adesea adăugarea de AI la sisteme legacy se dovedeşte a fi inferioară construirii sale direct în fundația platformei?

Sistemele legacy nu au fost construite pentru a fi raționalizate de AI. Modelele de date, API-urile, modul în care informațiile sunt structurate, toate acestea au fost proiectate pentru interacțiunea umană prin interfețe. Când încercați să adăugați AI deasupra, îi cereți să lucreze în jurul constrângerilor pentru care nu a fost proiectat.

Chiar dacă încercați să adăugați un server MCP deasupra, în realitate, un server MCP necesită modele de proiectare foarte specifice. Majoritatea serverelor MCP de astăzi introduc de fapt o umflătură mai mare a ferestrei de context și fac să explodeze performanța.

Problema mai profundă este modelul de implementare. Într-un ERP tradițional, configurarea sistemului este stocată în sistemul însuși. Nu este cod pe care îl puteți citi, testa sau versiuni. Nu există nicio modalitate pentru un agent să înțeleagă ce face sistemul, să nu mai vorbim de a-l schimba în siguranță. Am construit ZSL în mod special, astfel încât configurarea să fie o bază de cod propriu-zisă: citibilă, testabilă și implementabilă într-un sistem de buclă închisă. Construim un ciclu de viață complet agentic de dezvoltare software (SDLC). Acesta este prerequisitul pentru ca AI să poată operaționa realmente asupra sistemului, și nu doar să stea deasupra lui.

Pe măsură ce AI devine capabil să genereze fluxuri de lucru și să interacționeze direct cu sistemele operaționale, cum credeți că interfețele tradiționale de software enterprise se vor evolua?

Întrebarea despre interfață este, de fapt, despre cine are nevoie să utilizeze sistemul. Astăzi, interfețele ERP sunt construite în jurul unui număr mic de utilizatori puternici, oamenii care au fost instruiți despre sistem în timpul implementării. Toată lumea altă nu poate utiliza sau primește o versiune degradată a acestuia.

Ce construim noi este o interfață componibilă, care tratează interfața ca pe un constructor de site-uri web. Interfața însăși este, de asemenea, susținută de ZSL-ul nostru de buclă închisă. Fiecare, CFO, manager de depozit, analist de lanț de aprovizionare, primește un panou de control și vederi de date compuse în jurul modului în care lucrează realmente. Pe măsură ce AI gestionează mai mult fluxul de lucru subiacent, interfața devine mai puțin despre introducerea de date și mai mult despre vizibilitate și luare de decizii. Software-ul ar trebui să gestioneze restul.

Startup-urile precum DOSS intră pe o piață dominată de companii cu zeci de ani de existență. Care sunt avantajele pe care le au startup-urile native AI atunci când concurează cu platformele enterprise stabilite?

Companiile stabilite au problema opusă față de startup-uri. Ei au baze de clienți imense de protejat. Fiecare decizie arhitecturală pe care o iau trebuie să fie compatibilă cu versiunile anterioare. Ei pot adăuga funcții AI la produsele existente, dar nu pot reconstrui sistemele subiacente fără a strica tot ceea ce rulează pe ele. Acest lucru nu este o eșec a ambiției; este structural.

În ERP, în special, ei sunt, de asemenea, încărcați cu decizii de afaceri care i-au condus pe o cale în care veniturile sunt generate de funcția specifică pe care DOSS o urmărește să o elimine – consultanții de servicii profesionale. Având în vedere că utilizatorii cheltuie nouă dolari pe consultanți pentru fiecare dolar cheltuit pe software însuși, capacitatea de a transforma 90% din veniturile lor este de neconceput pentru marii jucători.

Un sistem nativ AI poate fi proiectat de la început astfel încât AI-ul să fie parte a arhitecturii de bază, nu un strat deasupra. Modelul de implementare, modelul de date și modul în care configurarea funcționează sunt toate proiectate cu AI ca participant de rangul I. Acesta este un avantaj care se acumulează, unde fiecare implementare face sistemul mai bun, și agenții de implementare devin mai capabili cu fiecare client nou. Acest tip de buclă de îmbunătățire nu există într-un sistem în care implementarea este încă o angajare de consultanță umană.

Privind înainte, cum vă imaginați că AI va transforma „sistemul de operare” al unei afaceri în următorii cinci până la zece ani, în special în domenii precum vizibilitatea lanțului de aprovizionare, luarea deciziilor în timp real și operațiunile automate?

Am fondat DOSS pe convingerea că sistemele enterprise vor putea să se construiască singure. La trei ani distanță, am intrat în faza a 2-a a Doss: implementarea agentică autocondusă. Platforma noastră poate deja genera, valida și evolua sistemul unui client, mai degrabă decât să se bazeze pe configurarea manuală a consultanților, și devine mai bună cu fiecare client nou.

Direcția în care se îndreaptă acest lucru este un sistem care este întotdeauna în pas cu afacerea. Astăzi, decalajul dintre modul în care funcționează o afacere și ceea ce știe software-ul despre aceasta este de luni sau ani. Sistemul a fost configurat la un moment dat și nu s-a schimbat de atunci. Ce devine posibil atunci când acest decalaj se închide, atunci când sistemul se adaptează în timp real pe măsură ce afacerea se schimbă, este o altă categorie de capacitate operațională. Vizibilitatea în timp real nu este doar despre raportare mai rapidă; este capacitatea de a prinde o întrerupere a lanțului de aprovizionare înainte de a deveni o problemă de îndeplinire a comenzilor. Operațiunile automate nu sunt doar despre eficiență; este capacitatea de a conduce o afacere mai complexă cu aceeași echipă. Acesta este tipul de software operațional pe care îl construim.

Mulțumim pentru răspunsurile dvs. detaliate. Citiitorii care doresc să afle mai multe ar trebui să viziteze Doss.