Arnav Mishra, medgrundare och CTO på Doss – Intervjuserie

Arnav Mishra, medgrundare och CTO på Doss, är en fullstack-utvecklare och teknisk ledare med en bakgrund som spänner över tidiga startups och storskaliga infrastruktursystem. Innan han co-founderade Doss var han en av grundarna till Siteline, där han byggde kärnsystem, inklusive behörighetsarkitektur, ERP-integrationer och automationsramverk, samtidigt som han bidrog till rekrytering, intäktsoperationer och företagskultur. Tidigare i sin karriär arbetade han som ingenjör på Rubrik och praktikant på företag som Uber och VMware, där han utvecklade expertis inom molninfrastruktur, datasystem och automation. Utöver sitt tekniska arbete har han varit aktivt engagerad i mentorering och talangutveckling genom organisationer som Techquitable Futures och Contrary, vilket speglar ett bredare engagemang för att stödja nästa generation av ingenjörer.

Doss är ett modernt företag inom företagsprogramvara som fokuserar på att revolutionera traditionella ERP-system genom sin Adaptive Resource Platform (ARP), en flexibel, AI-nativ operativ plattform som är utformad för att förena och automatisera affärsprocesser. Byggt som en komponerbar alternativ till legacy-ERP-lösningar möjliggör Doss för företag att hantera lager, inköp, ekonomi och leverans inom ett enda system som anpassar sig till verklighetsbaserade operationer snarare än att tvinga på rigida processer. Dess plattform kombinerar en centraliserad datalager, kodfria arbetsflöden och realtidsanalys, vilket gör det möjligt för företag att distribuera snabbt, integrera med befintliga verktyg och kontinuerligt utveckla sina operationer utan långa implementationer eller dyra konsulter.

Den drivkraft som ledde till att DOSS byggdes kan spåras tillbaka till Wiley som såg hur äldre programvara störde hans fars tillverkningsföretag, och båda såg liknande problem förstahands när de arbetade med fabriker och hårdvarukedjor. Hur formade dessa upplevelser ert beslut att co-grunda DOSS och tänka om ERP-system från grunden?

Innan DOSS var jag med och grundade ett FinTech-startup. Den främsta anledningen till att våra köpare – CFO:er, redovisare osv – inte gick med på vår lösning var att de var “för upptagna med att implementera ett ERP”. När jag grävde djupare i den föråldrade världen av ERP blev jag chockad av den befintliga implementeringsmodellen.

Vad jag ständigt såg var samma grundläggande misslyckande: implementation tar månader eller år, kostar hundratusentals till miljoner dollar och är flaskhalsat helt på mänskliga konsulter med timbaserad fakturering. Sedan, när ERP:n levereras, slutar den att förändras. Företaget fortsätter att utvecklas; systemet gör det inte. Det är ett arkitekturproblem, inte ett konfigurationsproblem. Du kan inte laga det genom att patcha.

Som programvaruutvecklare kunde jag inte tänka på någon jämförelse: föreställ er en värld där det viktigaste verktyget du använder – som utvecklare, låt säga GitHub – byggdes specifikt för bara ditt företag under flera år av en tredjeparts konsultbyrå. Sedan, när produkten är färdig, lämnar konsulterna med ingen underhåll, inga funktionsförbättringar och inget stöd. Utvecklare skulle revoltera.

Ingen modern teknikföretag kan operera i den modellen. Wiley och jag kom båda till samma slutsats: den enda vägen att lösa det var att bygga från scratch.

DOSS positionerar sig som en AI-nativ operativ plattform utformad för att ersätta traditionella ERP-system som SAP eller Oracle (ORCL ). Vilka är de grundläggande arkitekturerna som gör en AI-nativ ERP möjlig idag som inte var möjlig för ett decennium sedan?

Oracle och SAP byggdes i en era då de, för att uppnå maximal distribution, behövde förenkla konfigurationsplanet för ett ERP till ett GUI-baserat redigeringsverktyg som relativt icke-tekniska konsulter kunde leverera i stor skala. För att bevara bästa praxis låste de fast stora delar av kärnsystemen och tillät endast komposition vid kanterna. I verkligheten, när man tittar på spektrumet av alla företag i världen, behöver deras affärsapplikationer maximal flexibilitet.

Vad den AI-nativa världen möjliggör är transformationen av programvaruteknik från en hantverk till en industrialiserad maskin. Längre behöver vi inte programvaruutvecklare som handgjort kodsystem; istället rör vi oss mot en värld där programvaruthroughput är en faktor av beräkning och token.

Doss har arkitekterats med exakt detta i åtanke.

Vi byggde ZSL, ett deklarativt domänspecifikt språk (DSL) som beskriver en kunds hela DOSS-implementering i kod. Tänk på vad “Terraform” gjorde för “Infrastructure as Code”-insatsen, men tillämpat på affärsapplikationslogik. Genom att definiera ERP i ett relativt lågdimensionellt programmeringsspråk kan vi distribuera agenter i stor skala för att leverera ERP-lösningar.

När ZSL var skriven var den viktigaste delen av arkitekturen att baka in bästa praxis i plattformen själv för att förhindra att agenter bygger lågkvalitativa implementationer. Vårt team har levererat ett skalbart distribuerat system med en kärnskedeplanerare för att ta itu med belastningen av bursty ERP-arbetsbelastningar. Dessutom byggde vi ett HTAP-databasesystem som kombinerar de viktigaste delarna av en transaktionsdatabas som Postgres och de analytiska förmågorna i ett Data Warehouse.

Genom att bygga plattformen för att ha företagsklassens styrka tidigt är systemet inställt för helt agentisk distribution. Vad som tidigare tog konsultteam månader eller år att göra kan nu parallelliseras i stor skala med hjälp av agenter i vår egen slutna loopsystem.

Många företag förlitar sig fortfarande på kalkylblad och fragmenterade verktyg för inköp, lagerhantering och orderhantering. Vilka är de största operativa blindfläckarna som uppstår när kärnaffärsdata inte är enhetliga i en enda sanningsskälla?

Det största problemet är att beslut fattas på basis av föråldrad eller ofullständig information. Om dina lagerdata finns på ett ställe, dina inköpsorder på ett annat och dina försäljningsorder på ett tredje, så är du alltid i färd med att försona, manuellt, långsamt och efteråt. När någon inser att lagret är ur balans eller en leverantör är försenad, är det redan ett problem i företaget.

Verve Coffee Roasters är ett bra exempel på var detta bryter ned i praktiken. De kör operationer över livsmedel, grossist, DTC och kaféer i USA och Japan, men hanterade allt detta över separata system med ingen realtids synlighet för lagret. De hade slut på sin egen kaffe på högtrafikerade platser och drabbades av kritiska lagerbrister under en stor detaljhandelslansering som skadade en viktig detaljhandelsrelation. Data fanns någonstans; den var bara inte ansluten på ett sätt som tillät någon att agera på den i tid.

Det subtila problemet är att fragmentering döljer den verkliga formen av era operationer. Du kan inte se sambandet mellan en försening uppströms och ett leveransproblem nedströms om dessa två saker lever i separata verktyg. Du hamnar i att hantera symtom, skynda på order, bygga säkerhetslager och köra manuella kontroller istället för att förstå vad som verkligen händer. Ett enhetligt system sparar inte bara tid på försoning. Det förändrar vad du kan se och ställa frågor om.

I sin kärna, föreställ er att driva ett företag utan tillgång till ett versionskontrollsystem (Git), ett observabilitetsverktyg (DataDog) eller en centraliserad databas för att fråga information ur.

ERP-implementeringar har historiskt sett krävt stora konsultteam och månader – eller till och med år – av distribution. Hur förändrar AI den ekonomiska och komplexa implementeringen av operativ programvara i riktiga företag?

Den traditionella implementeringsmodellen är det framväxande resultatet av generationer gamla programvarupraktiker. Vi lever inte längre i den världen.

Det finns en perverterad incitamentstruktur i ERP-implementeringar idag – ju längre en implementering tar och ju mindre effektiv den är, desto mer pengar får implementatörerna. De flesta byggare skulle inte dra nytta av detta; dock är de aldrig inciterade att flytta med fart och kvalitet.

Dessutom är förhållandet mellan konsultutgifter och programvarukostnader i en traditionell ERP-engagemang ungefär 9:1, så du spenderar nio dollar på konsulter för varje dollar du spenderar på programvaran själv. För ett stort företag är det extremt smärtsamt. För medelstora företag är det förhindrande. Så de antingen bosätter sig för programvara som inte faktiskt passar hur de opererar, försenar projektet eller överger det på halva vägen.

AI förändrar enhetskonomin helt. Istället för en konsultengagemang är en DOSS-implementering en kodbas. När vår implementeringstid fortsätter att minska kan vi anpassa incitamenten med en “betala-på-leverans”-modell istället för “betala-medan-du-går”. När företaget förändras förändras systemet med det. Behovet av konsultrum och långa sliddecks är inte längre relevant.

Lyckade på Doss innebär att ersätta den globala IT-tjänstekostnaden på 1,86 biljoner dollar med agentisk implementering och underhåll med vår ZSL som språk för affärsapplikationsprogramvara. Lyckade på Doss är att kommoditisera alla affärsapplikationer i stor skala.

Ni har distribuerat DOSS med företag som opererar i verkliga miljöer som tillverkning, logistik och konsumentvaror. Vilka är några av de oväntade utmaningarna som uppstår när AI möter smutsiga operativa data?

Utanför är det sällan AI. Det är data du ber om att resonera om.

Varje företag vi arbetar med har ackumulerat år av operativa workaround. Data existerar tekniskt, men den lever inte någonstans där deras anställda, än mindre agenter, kan agera på den på ett tillförlitligt sätt.

Ett bra exempel är en tysk möbelfabricerare som skapar beställningsbara bitar. När vi kom in hade de 10 års historisk data spridd över 8 anpassade filformat med 11 olika dataobjekt och en 3PL-synkronisering som kördes manuellt med kopiering från FTP-mappar. Affärslogiken var specifik med anpassade dimensioner, konfigurationer, betalningsmetoder och utställningsplatser, och hela systemet behövde fungera på tyska. Det fanns ingen färdig schema för det. De behövde betala tusentals euro varje gång de ville ändra enkla konfigurationsalternativ, som statusalternativ för en inköpsorder.

Utanför är det inte den tekniska komplexiteten i någon enskild del. Det är att varje företag har en annan version av det här problemet, och du kan inte fullständigt förutse det förrän du är inne i deras data. Uppgiften är att ta en korrekt avtryck av hur företaget faktiskt opererar, inte kartlägga deras data till en generisk mall och hoppas att det passar.

För att bygga en lösning som fungerar för den verkliga världen behöver du en plattform med maximal flexibilitet. Endast då kan AI vara användbart för att förstå den underliggande datamodellen det arbetar med och bygga modellen som fungerar för varje kund.

Finns det mycket diskussion om AI-kopiloter och autonoma agenter i företagsprogramvara. Var ser du att AI lägger till mest värde i operativa flöden idag, och var förblir mänsklig övervakning fortfarande avgörande?

På stor skala har AI förmågan att störa alla operativa arbeten.

På den närmaste horisonten bör Doss’ egna modeller och agenter kunna omvandla kärnan av tekniska konsulter vid implementering av affärsapplikationer samt managementkonsulter vid leverans av strategiska rekommendationer. Doss kommer att ha den största samlingen av strukturerad och samlokaliserad data som representerar både schema och operativ information för företag. Våra agenter kan använda den datan för att leverera skalbara rekommendationer.

Det tydligaste värdet idag är mer specifikt än så. Det är i arbete som är repetitivt, regelbaserat och för närvarande utförs av människor som har andra, mer strategiska prioriteringar: bearbetning av inköpsorder, försoning av lager och routning av leveransbeslut. Dessa uppgifter har väldefinierade in- och utdata, och AI kan hantera dem tillförlitligt i stor skala.

För nu är mänsklig övervakning avgörande varhelst kostnaden för ett felaktigt beslut är hög, och systemet inte ännu har tillräckligt med sammanhang för att vara säker. Idag är den rätta modellen inte autonoma agenter som ersätter mänskligt beslutsfattande i sin helhet; det är agenter som hanterar det högvolym-, väldefinierade arbetet så att människor kan fokusera på de besluten som faktiskt kräver deras omdöme.

Många företag försöker lägga till AI på befintliga programvarustackar. Varför fungerar det ofta inte att retrofitta äldre system med AI jämfört med att bygga AI direkt in i grunden för plattformen?

Äldre system byggdes inte för att kunna resonera om av AI. Datamodellerna, API:erna, sättet information struktureras, allt detta var utformat för att människor skulle kunna interagera med gränssnitt. När du försöker lägga till AI ovanpå det ber du det att arbeta runt begränsningar det inte var menat att arbeta runt.

Även om du försöker kasta en MCP-server ovanpå, i verkligheten behöver en MCP-server extremt specifika designmönster. De flesta MCP-servrar idag introducerar faktiskt större kontextfönsterbloat och blåser upp prestanda.

Det djupare problemet är implementeringsmodellen. I ett traditionellt ERP är konfigurationen av systemet lagrad i systemet själv. Det är inte kod du kan läsa, testa eller versionera. Det finns inget sätt för en agent att förstå vad systemet gör, än mindre ändra det säkert. Vi byggde ZSL specifikt så att konfigurationen är en riktig kodbas: läsbar, testbar och distribuerbar i en slutna loopsystem. Vi bygger en fullständigt agentisk programvaruutvecklingslivscykel (SDLC). Det är det förkörningskravet för AI att faktiskt kunna operera på systemet snarare än att bara sitta ovanpå det.

Hur ser du att gränssnittet för traditionell företagsprogramvara utvecklas när AI blir mer kapabel att generera arbetsflöden och interagera direkt med operativa system?

Gränssnittsfrågan handlar verkligen om vem som behöver använda systemet. För närvarande är ERP-gränssnitt byggda runt en liten uppsättning poweranvändare, de människor som tränades på systemet under implementeringen. Alla andra antingen kan inte använda det eller får en degraderad version av det.

Vad vi bygger är ett komponerbart gränssnitt, som behandlar gränssnittet som en webbplatsbyggare. Gränssnittet i sig är också backat av den slutna ZSL. Varje, CFO, lagerchef, supply chain-analytiker, får en instrumentpanel och datavyer sammansatta runt hur de faktiskt arbetar, inte runt hur programvaran konfigurerades. När AI hanterar mer av den underliggande arbetsflödesexekveringen blir gränssnittet mindre om datainmatning och mer om synlighet och beslutsfattande. Du behöver se vad som händer, förstå varför och fatta omdömesbaserade beslut. Programvaran bör hantera resten.

Startups som DOSS går in på en marknad som domineras av decennier gamla etablerade företag. Vilka fördelar har AI-nativa startups när de tävlar mot etablerade företagsplattformar?

De etablerade företagen har det motsatta problemet från startups. De har enorma installerade baser att skydda. Varje arkitekturbeslut de fattar måste vara bakåtkompatibelt. De kan lägga till AI-funktioner i befintliga produkter, men de kan inte bygga om de underliggande systemen utan att bryta allt som körs på dem. Det är inte en brist på ambition; det är strukturerat.

I ERP specifikt är de också belastade med affärsbeslut som drev dem ner en väg där intäkter genereras från den specifika funktionen DOSS syftar till att eliminera – professionella konsulttjänster. Med tanke på att användare spenderar nio dollar på konsulter för varje dollar de spenderar på programvaran själv är förmågan att omvandla 90% av deras källintäkter oacceptabelt för stora etablerade företag.

Ett AI-nativt system kan utformas från början så att AI är en del av den grundläggande arkitekturen, inte ett lager ovanpå. Implementeringsmodellen, datamodellen och sättet konfiguration fungerar är alla utformade med AI som en första klassens deltagare. Det är en ackumulerande fördel där varje distribution gör systemet bättre, och implementeringsagenterna blir mer kapabla med varje ny kund. Den typen av förbättringsloop finns inte i ett system där implementering fortfarande är ett mänskligt konsultengagemang.

Om du ser framåt, hur ser du att AI omvandlar “operativsystemet” för ett företag under de kommande fem till tio åren, särskilt inom områden som leverantörskedje synlighet, realtidsbeslutsfattande och automatiserade operationer?

Vi grundade DOSS på övertygelsen att företagssystem skulle kunna bygga sig själva. Tre år senare har vi gått in i fas 2 av Doss: den agenter som kör implementeringen. Plattformen kan redan generera, validera och utveckla en kunds system snarare än att förlita sig på manuell konsultkonfiguration, och den blir bättre med varje distribution.

Riktningen som detta är på väg är ett system som alltid är i fas med företaget. Idag är gapet mellan hur ett företag opererar och vad programvaran vet om det månader eller år. Systemet konfigurerades vid en viss tidpunkt och har inte förändrats sedan. Vad som blir möjligt när det gapet stängs, när systemet anpassar sig i realtid när företaget förändras, är en annan kategori av operativ förmåga. Realtids synlighet är inte bara snabbare rapportering; det är förmågan att fånga en leverantörsstörning innan den blir en leveransmisslyckande. Automatiserade operationer är inte bara om effektivitet; det är förmågan att köra ett mer komplext företag med samma team. Det är den versionen av operativ programvara vi bygger mot.

Tack för dina detaljerade svar, läsare som vill veta mer bör besöka Doss.