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ă atât startup-uri de dimensiuni mici, cât ș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ă, inclusiv arhitectura permisiunilor, integrări ERP și cadre de automatizare, contribuind, de asemenea, la recrutare, operațiuni de venituri și cultură de companie. Mai devreme în cariera sa, 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. În paralel cu munca sa tehnică, el a fost implicat activ în mentorat și dezvoltare 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 pentru întreprinderi moderne, 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 uni și automatiza fluxurile de lucru ale afacerilor. Construită ca o alternativă compozabilă 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ă la operațiunile 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 afacerilor să se 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 întoarce la Wiley, care a văzut cum software-ul legacy a perturbat afacerea de fabricație a tatălui său, și amândoi ați văzut ulterior probleme similare din propria experiență, lucrând 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, am fost 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 în profunzime terenul arhaic al ERP, am fost șocat de modelul de implementare existent.

Ce vedeam în mod constant a fost același eșec fundamental: implementarea durează luni sau ani, costă sute de mii până la 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 schimbe. Afacerea continuă să evolueze; sistemul nu. Acesta este un problemă arhitecturală, nu una de configurare. Nu poți să pătrunzi prin ea.

Ca și 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 utilizați – ca și dezvoltator, să zicem GitHub – a fost construit special pentru compania dvs. în decurs de ani de către o agenție de consultanță terță. Apoi, odată ce produsul este terminat, consultanții pleacă fără întreținere, îmbunătățiri de funcționalitate și suport. Inginerii s-ar revolta.

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

DOSS se poziționează ca o platformă operațională nativă AI, proiectată pentru a înlocui sistemele ERP tradiționale, cum ar fi SAP sau Oracle (ORCL ). 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 create într-o eră în care, pentru a obține 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 netehnici pot livra la scară. Pentru a păstra cele mai bune practici, au blocat mari porțiuni ale sistemelor de bază și au permis doar compozabilitate la margini. Cu toate acestea, în realitate, atunci când priviți spectrul tuturor afacerilor din lume, aplicațiile lor de afaceri necesită maximă flexibilitate.

Lumea nativă AI permite transformarea ingineriei software de la un meșteșug la o mașină industrializată. Nu mai avem nevoie de artizani software care să creeze manual coduri de sisteme; în schimb, ne îndreptăm către o lume în care productivitatea software-ului este un factor al calculului și token-urilor.

Doss a fost proiectat având exact acest lucru în minte.

Am construit ZSL, un limbaj declarativ de domeniu specific (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 logica aplicației de afaceri. Prin definirea ERP-urilor într-un limbaj de programare de dimensiune relativ scăzută, 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 la nivel de nucleu pentru a prelua încărcarea fluxurilor de lucru 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 nivel întreprindere de la început, sistemul este pregătit pentru o distribuție agentică în întregime. Ceea ce obișnuia să ia echipe de consultanți luni și ani pentru a face poate fi acum paralelizat la scară, utilizând infrastructura agentică în sistemul nostru de buclă închisă.

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

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

Verve Coffee Roasters este un exemplu bun de unde se întrerupe acest lucru în practică. Ei operează în domenii precum magazine, vânzări cu amănuntul, DTC și cafenele în SUA și Japonia, dar gestionează totul prin sisteme desconectate, fără vizibilitate reală a stocului. Ei au rămas fără cafea proprie în locații cu trafic ridicat și au lovit 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.

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 să înțelegeți 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.

La nivelul său fundamental, imaginați-vă conducerea unei afaceri 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 interiorul afacerilor 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 puțin eficientă, cu atât mai mulți bani primesc implementatorii. Majoritatea constructorilor nu ar profita de acest lucru; cu toate acestea, ei nu sunt niciodată stimulați să se miște cu viteză și calitate.

Mai mult, raportul dintre cheltuielile de consultanță și cheltuielile cu software-ul într-o angajare ERP tradițională rulează aproximativ 9:1, astfel încât cheltuiți nouă dolari pe consultanți pentru fiecare dolar cheltuit pe software-ul însuși. Pentru o întreprindere mare, acest lucru este extrem de dureros. Pentru afacerile de piață mijlocie, este prohibitiv. Prin urmare, ei 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 economia unitară 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 cu servicii IT de 1,86 trilioane de dolari cu implementare și întreținere agentică, utilizând ZSL-ul nostru ca limbaj pentru software-ul de aplicații de afaceri. Succesul la Doss înseamnă comercializarea tuturor aplicațiilor de afaceri la scară.

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

Provocarea nu este de obicei 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 undeva unde angajații, și mai puțin sistemele agenților, pot 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ă prin copiere manuală din foldere FTP. Logica afacerii era specifică, cu dimensiuni personalizate, configurații, metode de plată și locații de showroom, și întregul sistem trebuia să funcționeze în germană. Nu există un șablon de tip 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 cumpărare.

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. Trebuie să luați o amprentă exactă a modului în care funcționează afacerea și să nu puteți mapa datele într-un șablon generic și să sperați că se potrivește.

Pentru a construi o soluție care să funcționeze pentru lumea reală, aveți nevoie de o platformă cu flexibilitate maximă. Doar 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 în prezent și unde rămâne supravegherea umană esențială?

La scară, AI are capacitatea de a perturba toate lucrările operaționale.

Pe orizontul apropiat, modelele și agenții noștri proprietari ar trebui să poată transforma nucleul consultanților tehnici în implementarea aplicațiilor de afaceri, precum și pe cel al 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 mai strategice: procesarea comenzilor de cumpărare, reconcilierea stocurilor și luarea deciziilor de îndeplinire. 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 agenți autonomi care înlocuiesc în întregime luarea deciziilor umane; este agenții 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 legacy. Din punctul dvs. de vedere, de ce adăugarea AI-ului la sistemele legacy adesea nu reușește în comparație cu construirea directă a AI-ului î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, îl cereți să lucreze în jurul constrângerilor pentru care nu a fost proiectat.

Chiar și dacă încercați să adăugați un server MCP deasupra, în realitate, un server MCP necesită modele de proiectare extrem de 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 versiona. Nu există nicio modalitate pentru un agent să înțeleagă ce face sistemul, și mai puțin să îl schimbe în siguranță. Am construit ZSL în mod special, astfel încât configurarea să fie o bază de cod adecvată: citibilă, testabilă și implementabilă într-un sistem închis. Suntem în curs de construire a unui ciclu de viață complet agentic de dezvoltare software (SDLC). Acesta este preconditionarea pentru ca AI să poată opera realmente pe sistem, și nu doar să stea deasupra lui.

Cum credeți că interfețele tradiționale de software de întreprindere se vor schimba pe măsură ce AI devine capabil să genereze fluxuri de lucru și să interacționeze direct cu sistemele operaționale?

Întrebarea interfeței este cu adevărat despre cine are nevoie să utilizeze sistemul. În prezent, interfețele ERP sunt construite în jurul unui număr mic de utilizatori puternici, oamenii care au fost instruiți pe sistem în timpul implementării. Toată lumea altcineva fie nu poate utiliza sistemul, fie primește o versiune degradată a acestuia.

Ce construim este o interfață compozabilă, 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 închis. Fiecare, CFO, managerul depozitului, analistul lanțului de aprovizionare, primește un tablou de bord și vedere de date compuse în jurul modului în care lucrează realmente, și nu în jurul modului în care a fost configurat software-ul. 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. Trebuie să vedeți ce se întâmplă, să înțelegeți de ce și să luați decizii de judecată. 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 de întreprindere stabilite?

Incumbenții au problema opusă față de startup-uri. Ei au baze de clienți uriașe pe care trebuie să le protejeze. Fiecare decizie arhitecturală pe care o iau trebuie să fie compatibilă cu versiunile anterioare. Pot adăuga funcții AI la produsele existente, dar nu pot reconstrui sistemele subiacente fără a rupe tot ceea ce rulează pe ele. Acesta nu este un eșec de ambiție; 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 încearcă 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-ul însuși, capacitatea de a transforma 90% din veniturile lor de bază este de neconceput pentru incumbenții mari.

Un sistem nativ AI poate fi proiectat de la început astfel încât AI-ul să fie parte a arhitecturii de bază, și nu doar un strat peste. 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 compune, 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ă un angajament 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 de întreprindere vor putea să se construiască singure. La trei ani de la aceasta, am intrat în faza 2 a Doss-ului: implementarea agentică care se conduce singură. 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 implementare.

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. Ceea 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 categorie diferită de capabilitate operațională. Vizibilitatea în timp real nu este doar raportare mai rapidă; este capacitatea de a prinde o întrerupere a lanțului de aprovizionare înainte de a deveni o eșuare a îndeplinirii. 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 de operare pe care îl construim.

Mulțumim pentru răspunsurile dvs. detaliate; cititorii care doresc să afle mai multe trebuie să viziteze Doss.