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, è stato uno degli ingegneri fondatori di Siteline, dove ha costruito sistemi core tra cui l’architettura dei permessi, le integrazioni con il sistema ERP e i framework di automazione, contribuendo anche all’assunzione di personale, alle operazioni di revenue e alla cultura aziendale. In precedenza, ha ricoperto ruoli di ingegnere in Rubrik e ha svolto stage presso aziende come Uber e VMware, sviluppando competenze in infrastrutture cloud, sistemi di dati e automazione. Parallelamente 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 a sostegno della prossima generazione di ingegneri.

Doss è una società di software moderna che si concentra sul reinventare i tradizionali sistemi ERP attraverso la sua piattaforma di operazioni adattive (ARP), una piattaforma operativa flessibile e nativa per l’intelligenza artificiale 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, la procedura di acquisto, la finanza e l’adempimento 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 implementazioni lunghe 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 sconvolto 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 dalla base?

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 impegnati nell’implementazione di un ERP”. Quando ho approfondito il tema dell’ERP, sono rimasto sbalordito dal modello di implementazione esistente.

Quello che continuavo a vedere era lo stesso fallimento fondamentale: l’implementazione richiede mesi o anni, costa centinaia di migliaia di dollari e viene bloccata interamente da consulenti umani con fatturazione oraria. Una volta che l’ERP viene consegnato, smette di cambiare. L’azienda continua a evolversi; il sistema no. Questo è un problema architettonico, non di configurazione. Non puoi risolverlo con 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. Poi, 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 abbiamo raggiunto la stessa conclusione: l’unico modo per risolverlo era costruire da zero.

DOSS si posiziona come una piattaforma operativa nativa per l’intelligenza artificiale progettata per sostituire i tradizionali sistemi ERP come SAP o Oracle (ORCL ). Quali sono le differenze architettoniche fondamentali che rendono possibile un ERP nativo per l’intelligenza artificiale oggi che non lo erano un decennio fa?

Oracle e SAP sono stati costruiti in un’era in cui, per ottenere una massima distribuzione, dovevano semplificare il piano di configurazione di un ERP per renderlo un editor basato su GUI che i consulenti relativamente non tecnici potessero consegnare su larga scala. Per preservare le best practice, hanno bloccato ampie parti del sistema 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.

Il mondo nativo per l’intelligenza artificiale 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 il ZSL, un linguaggio di dominio specifico dichiarativo (DSL) che descrive l’intera implementazione del cliente di DOSS in codice. Pensate a ciò che “Terraform” ha fatto per lo sforzo “Infrastructure as Code”, ma applicato alla logica delle applicazioni aziendali. 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 il 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 dei carichi di lavoro ERP intermittenti. 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 resistenza di livello aziendale fin dall’inizio, il sistema è predisposto per una distribuzione agente interamente agente. Ciò che un tempo richiedeva team di consulenti mesi o anni per fare può ora essere parallelizzato su larga scala utilizzando un’infrastruttura agente nel nostro sistema chiuso proprietario.

Molte aziende si affidano ancora a fogli di calcolo e strumenti frammentati per la procedura di acquisto, la gestione dell’inventario e la gestione degli ordini. Quali sono i più grandi punti ciechi operativi che sorgono quando i dati core dell’azienda 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 i fatti. Quando qualcuno si rende conto che l’inventario è fuori o che un fornitore è in ritardo, è già un problema per l’azienda.

Verve Coffee Roasters è un buon esempio di dove questo si rompe nella pratica. Gestiscono operazioni in tutto il mondo, nei negozi di generi alimentari, nel commercio all’ingrosso, nel commercio diretto e nei caffè, 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 hanno colpito stock critici durante il lancio di un importante rivenditore che ha danneggiato una relazione di vendita chiave. I dati esistevano da qualche parte; non erano solo connessi in modo da poter agire in tempo.

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

Al suo nucleo, immagina di gestire un’azienda senza accesso a un sistema di controllo delle versioni (Git), uno strumento di osservabilità (DataDog) o un database centralizzato per interrogare le informazioni.

Le implementazioni di ERP hanno storicamente richiesto grandi team di consulenti e mesi – o addirittura anni – di distribuzione. Come l’intelligenza artificiale 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 passate. 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 per consulenza e spesa per 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 si accontentano di software che non si adatta realmente a come operano, ritardano il progetto o lo abbandonano a metà strada.

L’intelligenza artificiale 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 man mano che si va”. Quando l’azienda 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 1,86 trilioni di dollari per i servizi IT con l’implementazione agente e la manutenzione utilizzando il nostro ZSL come linguaggio per il software delle applicazioni aziendali. Il successo a Doss significa rendere commodity tutte le applicazioni aziendali su larga scala.

Aprite DOSS con aziende che operano in ambienti del mondo reale come la produzione, la logistica e i beni di consumo. Quali sono alcune delle sfide inattese che sorgono quando l’intelligenza artificiale incontra dati operativi disordinati?

La sfida raramente è l’intelligenza artificiale. È 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 ottimo 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 oggetti di dati diversi 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 località di mostra, 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 singola 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 di 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 la massima flessibilità. Solo allora l’intelligenza artificiale può essere utile per comprendere il modello di dati sottostante su cui sta lavorando e costruire il modello che funziona per ogni cliente.

C’è molto dibattito su copiloti di intelligenza artificiale e agenti autonomi nel software aziendale. Dove pensi che l’intelligenza artificiale aggiungerà il maggior valore ai flussi di lavoro operativi oggi, e dove il controllo umano rimane essenziale?

A scala, l’intelligenza artificiale ha la capacità di interrompere tutto il lavoro operativo.

Sul prossimo orizzonte, 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é i nuclei 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 questo. È nel lavoro che è ripetitivo, basato su regole e attualmente eseguito da persone che hanno altre priorità più strategiche: l’elaborazione degli ordini di acquisto, la riconciliazione dell’inventario e la gestione delle decisioni di adempimento. Questi compiti hanno input e output ben definiti e l’intelligenza artificiale può gestirli in modo affidabile su larga scala.

Per ora, il controllo umano è 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 interamente la presa di decisione umana; è quello di agenti che gestiscono il lavoro ben definito e ad alto volume in modo che le persone possano concentrarsi sulle decisioni che richiedono effettivamente il loro giudizio.

Molte aziende stanno cercando di sovrapporre l’intelligenza artificiale ai sistemi software esistenti. Perché sovrapporre l’intelligenza artificiale ai sistemi legacy spesso non funziona rispetto a costruire l’intelligenza artificiale direttamente nella fondazione della piattaforma?

I sistemi legacy non sono stati costruiti per essere ragionati dall’intelligenza artificiale. 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’intelligenza artificiale, si chiede di lavorare intorno a vincoli per cui non era stato progettato.

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 un maggiore bloat del contesto della finestra e fa esplodere le prestazioni.

Tuttavia, il problema più profondo è il modello di implementazione. In un ERP tradizionale, la configurazione del sistema è memorizzata nel sistema stesso. Non è 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 il ZSL proprio per questo, in modo che la configurazione sia una base di codice adeguata: leggibile, testabile e distribuibile in un sistema chiuso. Stiamo costruendo un ciclo di vita di sviluppo del software (SDLC) interamente agente. Questo è il prerequisito per l’intelligenza artificiale per poter effettivamente operare sul sistema invece di semplicemente stare sopra.

Si parla molto dell’evoluzione delle interfacce dei software aziendali con l’introduzione dell’intelligenza artificiale. Come pensi che l’interfaccia dei software aziendali tradizionali si evolverà?

La questione dell’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.

Quello che stiamo costruendo è un’interfaccia componibile, che tratta l’interfaccia come un costruttore di siti web. L’interfaccia stessa è anche supportata dal ZSL chiuso. Ogni persona, il CFO, il gestore 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’intelligenza artificiale gestisce sempre più l’esecuzione del flusso di lavoro sottostante, l’interfaccia diventa meno incentrata sull’inserimento dei dati e più sulla visibilità e sulla presa di decisioni. Hai bisogno di vedere cosa sta accadendo, capire il perché e prendere decisioni. Il software dovrebbe gestire il resto.

Le startup come DOSS stanno entrando in un mercato dominato da aziende consolidate da decenni. Quali sono i vantaggi che le startup native per l’intelligenza artificiale hanno quando competono con piattaforme aziendali stabilite?

I leader di mercato 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à di intelligenza artificiale 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.

Nello specifico dei sistemi ERP, sono anche gravati da decisioni aziendali che li hanno portati su un percorso in cui il ricavo è 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 ricavo di origine è insostenibile per i grandi leader di mercato.

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

Guardando avanti, come immagini che l’intelligenza artificiale 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 potessero costruirsi da soli. Tre anni dopo, siamo entrati nella Fase 2 di Doss: l’implementazione agente autonoma. 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’azienda. 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 mentre l’azienda cambia, è una categoria diversa di capacità operativa. La visibilità in tempo reale non è solo una segnalazione più veloce; è la capacità di intercettare una perturbazione della catena di approvvigionamento prima che diventi un fallimento di adempimento. Le operazioni automatizzate non sono solo questione di efficienza; è la capacità di gestire un’azienda più complessa con lo stesso team. Questa è la versione del software operativo che stiamo costruendo.

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