Arnav Mishra, Co-Fondatore e CTO di Doss – Serie di Interviste

Arnav Mishra, Co-Fondatore e CTO di Doss, è un ingegnere full-stack e leader tecnico con un background che spazia dalle startup in fase di avvio a sistemi di infrastruttura su larga scala. Prima di co-fondare Doss, era un ingegnere fondatore di Siteline, dove ha costruito sistemi core tra cui l’architettura delle autorizzazioni, le integrazioni con ERP e i framework di automazione, contribuendo anche all’assunzione, alle operazioni di revenue e alla cultura aziendale. All’inizio della sua carriera, ha ricoperto incarichi di ingegnere in Rubrik e ha svolto stage presso aziende come Uber e VMware, sviluppando competenze in infrastrutture cloud, sistemi di dati e automazione. Oltre al suo lavoro tecnico, è stato attivamente coinvolto nel mentoraggio e nello sviluppo del talento attraverso organizzazioni come Techquitable Futures e Contrary, riflettendo un impegno più ampio per sostenere la prossima generazione di ingegneri.

Doss è una società di software aziendale moderna che si concentra sul reinventare i tradizionali sistemi ERP attraverso la sua Piattaforma di Risorse Adattive (ARP), una piattaforma operativa flessibile e nativa AI progettata per unificare e automatizzare i flussi di lavoro aziendali. Costruita come un’alternativa componibile alle soluzioni ERP legacy, Doss consente alle aziende di gestire l’inventario, gli acquisti, le finanze e la gestione degli ordini all’interno di un unico sistema che si adatta alle operazioni del mondo reale piuttosto che forzare processi rigidi. La sua piattaforma combina un livello di dati centralizzato, flussi di lavoro senza codice e analisi in tempo reale, consentendo alle aziende di distribuire rapidamente, integrarsi con strumenti esistenti e continuare a evolvere le loro operazioni senza lunghe implementazioni o costosi consulenti. Un’infrastruttura aziendale progettata per velocità, scalabilità e adattabilità.

La motivazione per costruire DOSS risale a quando Wiley ha visto come il software legacy ha interrotto l’attività di produzione di suo padre, e successivamente entrambi avete visto problemi simili lavorando con fabbriche e catene di approvvigionamento di hardware. Come hanno plasmato queste esperienze la vostra decisione di co-fondare DOSS e ripensare i sistemi ERP dall’inizio?

Prima di DOSS, ero l’ingegnere fondatore di una startup FinTech. Il motivo principale per cui i nostri acquirenti – CFO, contabili, ecc. – non adottavano la nostra soluzione era perché erano “troppo occupati a implementare un ERP”. Quando ho approfondito l’argomento, sono stato colpito dal modello di implementazione esistente.

Ciò che continuavo a vedere era lo stesso fallimento fondamentale: l’implementazione richiede mesi o anni, costa centinaia di migliaia di dollari o più, e si blocca interamente sui consulenti umani con fatturazione oraria. Una volta che l’ERP viene spedito, smette di cambiare. L’attività continua a evolversi; il sistema no. Questo è un problema architettonico, non di configurazione. Non puoi uscire da questo problema con le patch.

Come costruttore di software, la cosa più simile che potevo pensare era il seguente: immagina un mondo in cui lo strumento più importante che usi – come sviluppatore, ad esempio GitHub – fosse stato costruito specificamente per la tua azienda nel corso di anni da un’agenzia di consulenza di terze parti. Una volta che il prodotto è finito, i consulenti se ne vanno senza manutenzione, miglioramenti delle funzionalità o supporto. Gli ingegneri si ribellerebbero.

Nessuna società di tecnologia moderna può operare con quel modello. Wiley e io siamo giunti alla stessa conclusione: l’unico modo per risolvere il problema era costruire da zero.

DOSS si posiziona come una piattaforma operativa nativa AI progettata per sostituire i tradizionali sistemi ERP come SAP o Oracle. Quali sono le differenze architettoniche fondamentali che rendono possibile un ERP nativo AI oggi che non erano fattibili dieci anni fa?

Oracle e SAP sono stati costruiti in un’era in cui, per ottenere una distribuzione massimizzata, dovevano semplificare il piano di configurazione di un ERP per renderlo un editor basato su GUI che i consulenti relativamente non tecnici potevano consegnare su larga scala. Per preservare le best practice, hanno bloccato ampie parti dei sistemi core e hanno consentito la composabilità solo ai margini. Tuttavia, nella realtà, quando si guarda lo spettro di tutte le aziende del mondo, le loro applicazioni aziendali richiedono flessibilità massimale.

Ciò che il mondo nativo AI consente è la trasformazione dell’ingegneria del software da un’attività artigianale a una macchina industrializzata. Non abbiamo più bisogno di artigiani del software per creare manualmente sistemi di codice; invece, stiamo entrando in un mondo in cui la produttività del software è un fattore di calcolo e token.

Doss è stata progettata esattamente con questo in mente.

Abbiamo costruito lo ZSL, un linguaggio di programmazione dichiarativo specifico del dominio (DSL) che descrive l’intera implementazione di DOSS di un cliente nel codice. Pensate a ciò che “Terraform” ha fatto per lo sforzo “Infrastructure as Code”, ma applicato alla logica dell’applicazione aziendale. Definendo gli ERP in un linguaggio di programmazione a bassa dimensionalità, siamo in grado di distribuire agenti su larga scala per consegnare soluzioni ERP.

Una volta scritto lo ZSL, la parte più importante dell’architettura è stata quella di incorporare le best practice nella piattaforma stessa per impedire agli agenti di costruire implementazioni di bassa qualità. Il nostro team ha consegnato un sistema distribuito scalabile con un scheduler a livello di kernel per gestire il carico di lavoro di ERP intermittente. Inoltre, abbiamo costruito un sistema di database HTAP che combina le parti più importanti di un database transazionale come Postgres e le capacità analitiche di un Data Warehouse.

Costruendo la piattaforma per avere una forza aziendale già dall’inizio, il sistema è impostato per una distribuzione agente interamente. Ciò che un tempo richiedeva mesi o anni per essere fatto da squadre di consulenti può ora essere parallelizzato su larga scala utilizzando infrastrutture agente nel nostro sistema chiuso proprietario.

Molte aziende continuano a fare affidamento a fogli di calcolo e strumenti frammentati per l’approvvigionamento, la gestione dell’inventario e la gestione degli ordini. Quali sono i più grandi punti ciechi operativi che sorgono quando i dati aziendali core non sono unificati in un’unica fonte di verità?

Il problema più grande è che le decisioni vengono prese sulla base di informazioni obsolete o incomplete. Se i dati dell’inventario vivono in un posto, gli ordini di acquisto in un altro e gli ordini di vendita in un terzo, si è sempre in fase di riconciliazione, manualmente, lentamente e dopo il fatto. Quando qualcuno si rende conto che l’inventario è fuori o che un fornitore è in ritardo, il problema è già presente nell’attività.

Verve Coffee Roasters è un buon esempio di dove questo si rompe nella pratica. Gestiscono operazioni in tutto il mondo, tra cui negozi di generi alimentari, wholesale, DTC e caffè negli Stati Uniti e in Giappone, ma gestivano tutto ciò attraverso sistemi non connessi senza alcuna visibilità dell’inventario in tempo reale. Stavano finendo il loro stesso caffè in località ad alto traffico e subivano stockout critici durante un lancio importante di un rivenditore che danneggiava una relazione di vendita chiave. I dati esistevano da qualche parte; non erano solo connessi in modo che qualcuno potesse agire su di essi in tempo.

Il problema più sottile è che la frammentazione nasconde la vera forma delle vostre operazioni. Non puoi vedere la relazione tra un ritardo a monte e un problema di evasione a valle se quelle due cose vivono in strumenti separati. Finisci per gestire i sintomi, accelerare gli ordini, costruire scorte di sicurezza e eseguire controlli manuali invece di capire cosa sta realmente accadendo. Un sistema unificato non salva solo tempo sulla riconciliazione. Cambia ciò che puoi anche vedere e chiedere.

A livello fondamentale, immagina di gestire un’attività aziendale senza accesso a un sistema di controllo versione (Git), uno strumento di osservabilità (DataDog) o un database centralizzato per interrogare le informazioni.

L’implementazione di ERP ha storicamente richiesto grandi squadre di consulenti e mesi – o anche anni – di distribuzione. Come l’AI cambia l’economia e la complessità dell’implementazione del software operativo all’interno di aziende reali?

Il modello di implementazione tradizionale è il risultato emergente di pratiche di software di generazioni precedenti. Non viviamo più in quel mondo.

C’è un’incentivo perverso nelle implementazioni di ERP oggi – più a lungo dura l’implementazione e meno efficace è, più denaro ricevono gli implementatori. La stragrande maggioranza dei costruttori non approfitterebbe di ciò; tuttavia, non sono mai incentivati a muoversi con velocità e qualità.

Inoltre, il rapporto tra spesa di consulenza e spesa di software in un impegno ERP tradizionale è di circa 9:1, quindi si spendono nove dollari per consulenti per ogni dollaro speso per il software stesso. Per un’azienda di grandi dimensioni, è estremamente doloroso. Per le aziende del mercato di medio livello, è proibitivo. Quindi o accettano un software che non si adatta realmente a come operano, ritardano il progetto o lo abbandonano a metà strada.

L’AI cambia completamente l’economia di questo. Invece di un impegno di consulenza, un’implementazione di DOSS è un codice. Man mano che i tempi di implementazione continuano a ridursi, siamo in grado di allineare gli incentivi con un modello “pagamento alla consegna” invece di “pagamento durante il percorso”. Quando l’attività cambia, il sistema cambia con essa. La necessità di stanze piene di consulenti e lunghe presentazioni non è più rilevante.

Il successo a Doss significa sostituire la spesa globale di servizi IT di 1,86 trilioni di dollari con un’implementazione e manutenzione agente utilizzando lo ZSL come linguaggio per il software di applicazione aziendale. Il successo a Doss significa commodityizzare tutte le applicazioni aziendali su larga scala.

Aprite DOSS con aziende che operano in ambienti del mondo reale come la produzione, la logistica e le merci di consumo. Quali sono le sfide inaspettate che sorgono quando l’AI incontra dati operativi disordinati?

La sfida raramente è l’AI. È i dati a cui stai chiedendo di ragionare.

Ogni azienda con cui lavoriamo ha accumulato anni di soluzioni operative. I dati esistono tecnicamente, non vivono solo in un posto in cui i dipendenti, per non parlare dei sistemi agente, possano agire su di essi in modo affidabile.

Un buon esempio è un produttore di mobili tedesco che crea pezzi su misura. Quando siamo entrati, avevano 10 anni di dati storici sparsi su 8 formati di file personalizzati con 11 diversi oggetti di dati e una sincronizzazione 3PL in esecuzione su copia e incolla manuale da cartelle FTP. La logica aziendale era specifica con dimensioni personalizzate, configurazioni, metodi di pagamento e posizioni di showroom, e l’intero sistema doveva funzionare in tedesco. Non c’è uno schema predefinito per questo. Dovevano pagare migliaia di euro ogni volta che volevano cambiare opzioni di configurazione semplici, come le opzioni di stato per un ordine di acquisto.

La sfida non è la complessità tecnica di una qualsiasi parte. È che ogni azienda ha una versione diversa di questo problema, e non puoi prevederlo completamente fino a quando non sei dentro i loro dati. Il lavoro è quello di prendere un’impronta precisa di come l’azienda opera effettivamente, non mappare i loro dati in un modello generico e sperare che si adatti.

Per costruire una soluzione che funzioni per il mondo reale, hai bisogno di una piattaforma con flessibilità massima. Solo allora l’AI può essere utile per capire il modello di dati sottostante su cui sta lavorando e costruire il modello che funziona per ogni cliente.

C’è molto dibattito su copiloti AI e agenti autonomi nel software aziendale. Dove vedete l’AI aggiungere il maggior valore nei flussi di lavoro operativi oggi, e dove la supervisione umana rimane essenziale?

Su larga scala, l’AI ha la capacità di interrompere tutto il lavoro operativo.

Sull’orizzonte a breve termine, i modelli e gli agenti proprietari di Doss dovrebbero essere in grado di trasformare i nuclei dei consulenti tecnici nell’implementazione di applicazioni aziendali, nonché quelli dei consulenti di gestione nella fornitura di raccomandazioni strategiche. Doss avrà il repository più grande di dati strutturati e co-locati che rappresentano sia lo schema che le informazioni operative per le aziende. I nostri agenti possono utilizzare quei dati per fornire raccomandazioni scalabili.

Il valore più chiaro oggi è più specifico di così. È nel lavoro che è ripetitivo, basato su regole e attualmente eseguito da persone che hanno altre priorità più strategiche: elaborazione degli ordini di acquisto, riconciliazione dell’inventario e decisioni di evasione. Questi compiti hanno input e output ben definiti e l’AI può gestirli in modo affidabile su larga scala.

Per ora, la supervisione umana è essenziale ovunque il costo di una decisione errata sia alto e il sistema non abbia ancora abbastanza contesto per essere confidente. Oggi, il modello giusto non è quello di agenti autonomi che sostituiscono la presa di decisione umana nel suo complesso; è quello di agenti che gestiscono il lavoro ad alto volume e ben definito in modo che le persone possano concentrarsi sulle decisioni che richiedono effettivamente il loro giudizio.

Molte aziende stanno cercando di sovrapporre l’AI ai sistemi software esistenti. Perché il retrofitting dei sistemi legacy con l’AI spesso non raggiunge gli obiettivi rispetto a costruire l’AI direttamente nella fondazione della piattaforma?

I sistemi legacy non sono stati costruiti per essere ragionati dall’AI. I modelli di dati, le API, il modo in cui le informazioni sono strutturate, tutto ciò è stato progettato per l’interazione umana attraverso interfacce. Quando si tenta di sovrapporre l’AI su ciò, si chiede all’AI di lavorare intorno a vincoli che non era destinata a lavorare.

Anche se si tenta di aggiungere un server MCP sopra, nella realtà, un server MCP richiede modelli di progettazione estremamente specifici. La maggior parte dei server MCP oggi introduce effettivamente un maggiore bloat della finestra di contesto e fa esplodere le prestazioni.

Tuttavia, il problema più profondo è il modello di implementazione. In un ERP tradizionale, la configurazione del sistema è archiviata nel sistema stesso. Non è un codice che puoi leggere, testare o versionare. Non c’è modo per un agente di capire cosa sta facendo il sistema, per non parlare di cambiarlo in modo sicuro. Abbiamo costruito lo ZSL specificamente in modo che la configurazione sia una base di codice adeguata: leggibile, testabile e distribuibile in un sistema chiuso. Stiamo costruendo un ciclo di sviluppo del software (SDLC) completamente agente. Questo è il prerequisito per l’AI per operare effettivamente sul sistema invece di semplicemente sedersi sopra.

Man mano che l’AI diventa in grado di generare flussi di lavoro e interagire direttamente con sistemi operativi, come pensate che l’interfaccia tradizionale del software aziendale evolverà?

La domanda sull’interfaccia è realmente su chi ha bisogno di utilizzare il sistema. Attualmente, le interfacce ERP sono costruite intorno a un piccolo set di utenti potenti, le persone che sono state formate sul sistema durante l’implementazione. Chiunque altro non può utilizzarlo o ottiene una versione degradata.

Ciò che stiamo costruendo è un’interfaccia componibile, che tratta l’interfaccia come un costruttore di siti web. L’interfaccia stessa è anche supportata dal ciclo chiuso ZSL. Ogni persona, il CFO, il responsabile del magazzino, l’analista della catena di approvvigionamento, ottiene un cruscotto e viste dei dati composte intorno a come lavorano effettivamente, non intorno a come il software è stato configurato. Man mano che l’AI gestisce più dell’esecuzione del flusso di lavoro sottostante, l’interfaccia diventa meno importante per l’inserimento dei dati e più per la visibilità e la presa di decisioni. Hai bisogno di vedere cosa sta succedendo, capire il perché e prendere decisioni di giudizio. Il software dovrebbe gestire il resto.

Le startup come DOSS stanno entrando in un mercato dominato da incumbent decennali. Quali vantaggi hanno le startup native AI quando competono con piattaforme aziendali stabilite?

Gli incumbent hanno il problema opposto rispetto alle startup. Hanno enormi basi installate da proteggere. Ogni decisione architettonica che prendono deve essere compatibile con le versioni precedenti. Possono aggiungere funzionalità AI ai prodotti esistenti, ma non possono ricostruire i sistemi sottostanti senza rompere tutto ciò che funziona su di essi. Questo non è un fallimento di ambizione; è strutturale.

In particolare nell’ERP, sono anche gravati da decisioni aziendali che li hanno portati su un percorso in cui il ricavato è guidato dalla specifica funzione che DOSS sta cercando di eliminare – i consulenti di servizi professionali. Dato che gli utenti spendono nove dollari per consulenti per ogni dollaro che spendono per il software stesso, la capacità di trasformare il 90% del loro ricavato è insostenibile per gli incumbent di grandi dimensioni.

Un sistema nativo AI può essere progettato fin dall’inizio in modo che l’AI sia parte integrante dell’architettura, non uno strato sopra. Il modello di implementazione, il modello di dati e il modo in cui funziona la configurazione sono tutti progettati con l’AI come partecipante di primo livello. Questo è un vantaggio cumulativo in cui ogni distribuzione rende il sistema migliore e gli agenti di implementazione diventano più capaci con ogni nuovo cliente. Quel tipo di ciclo di miglioramento non esiste in un sistema in cui l’implementazione è ancora un impegno di consulenza umana.

Guardando avanti, come vi immaginate che l’AI trasformerà il “sistema operativo” di un’azienda nei prossimi cinque o dieci anni, in particolare in aree come la visibilità della catena di approvvigionamento, la presa di decisioni in tempo reale e le operazioni automatizzate?

Abbiamo fondato DOSS sulla convinzione che i sistemi aziendali sarebbero stati in grado di costruirsi da soli. Tre anni dopo, siamo entrati nella Fase 2 di Doss: l’implementazione autonoma agente. La piattaforma può già generare, convalidare ed evolvere il sistema di un cliente piuttosto che affidarsi alla configurazione manuale dei consulenti, e migliora con ogni distribuzione.

La direzione in cui questo sta andando è un sistema che è sempre in sincronia con l’attività. Oggi, il divario tra come un’azienda opera e cosa il software sa di essa è di mesi o anni. Il sistema è stato configurato in un momento specifico e non è cambiato da allora. Ciò che diventa possibile quando quel divario si chiude, quando il sistema si adatta in tempo reale man mano che l’attività cambia, è una categoria diversa di capacità operativa. La visibilità in tempo reale non è solo una segnalazione più veloce; è la capacità di intercettare una interruzione della catena di approvvigionamento prima che diventi un fallimento di evasione. Le operazioni automatizzate non sono solo una questione di efficienza; è la capacità di gestire un’attività più complessa con la stessa squadra. È la versione del software operativo che stiamo costruendo.

Grazie per le vostre risposte dettagliate, i lettori che desiderano saperne di più possono visitare Doss.