Arnav Mishra, medgrunnlegger og CTO av Doss – Intervju-serie

Arnav Mishra, medgrunnlegger og CTO av Doss, er en full-stack utvikler og teknisk leder med bakgrunn fra tidlige startups og store skala-infrastruktursystemer. Før han co-grunnla Doss, var han en av de første ingeniørene i Siteline, hvor han bygde kjerne-systemer inkludert tillatelser, ERP-integrasjoner og automatiseringsrammeverk, samt bidro til rekruttering, omsetningsdrift og selskapskultur. Tidligere i sin karriere hadde han ingeniørstillinger i Rubrik og internerte i selskaper som Uber og VMware, og utviklet ekspertise innen sky-infrastruktur, datasystemer og automatisering. Samtidig med sitt tekniske arbeid, har han vært aktivt engasjert i mentorprogrammer og talentutvikling gjennom organisasjoner som Techquitable Futures og Contrary, og reflekterer en bredere forpliktelse til å støtte den neste generasjonen av ingeniører.

Doss er et moderne bedriftsprogramvareselskap som fokuserer på å gjenskape tradisjonelle ERP-systemer gjennom sin Adaptive Resource Platform (ARP), en fleksibel, AI-nativ operasjonsplattform designet for å samordne og automatisere forretningsprosesser. Bygget som en komponerbar alternativ til legacy ERP-løsninger, muliggjør Doss at selskaper kan håndtere lager, innkjøp, finansiell styring og oppfyllelse innen ett enkelt system som tilpasser seg virkelige operasjoner i stedet for å tvinge faste prosesser. Plattformen kombinerer en sentralisert datalag, kodefrie arbeidsflyter og sanntidsanalyser, og lar bedrifter raskt utvikle, integrere med eksisterende verktøy og kontinuerlig utvikle sine operasjoner uten lange implementeringer eller dyre konsulenter.

Motivasjonen for å bygge DOSS går tilbake til Wiley som så hvordan legacy-programvare forstyrte hans fars produksjonsbedrift, og både de så lignende problemer førstehånds mens de arbeidet med fabrikker og hardvareforsyningskjeder. Hvordan påvirkte disse erfaringene din beslutning om å co-grunnlegge DOSS og tenke om ERP-systemer fra bunnen av?

Før DOSS, var jeg en av de første ingeniørene i et FinTech-startup. Årsaken til at våre kjøpere – CFO-er, regnskapsførere osv – ikke ville gå med vår løsning, var fordi de var “for opptatt med å implementere et ERP”. Da jeg dykket dyptere inn i det gamle landet av ERP, ble jeg slått av den eksisterende implementeringsmodellen.

Hva jeg fortsatte å se, var det samme fundamentale feilet: implementering tar måneder eller år, koster hundredtusener til millioner av dollar, og er bottlenecket helt på menneskelige konsulenter med timebasert fakturering. Deretter, når ERP-en er levert, holder den opp med å endre seg. Bedriften fortsetter å utvikle seg; systemet gjør det ikke. Dette er et arkitektonisk problem, ikke et konfigurasjonsproblem. Du kan ikke luke deg ut av det.

Som programvarebygger, var den nærmeste sammenligningen jeg kunne tenke på, følgende: forestill deg en verden hvor det viktigste verktøyet du bruker – som en utvikler, la oss si GitHub – var bygget spesifikt for bare ditt selskap over en periode på år av en tredjeparts konsulentbyrå. Deretter, når produktet er ferdig, forlater konsulentene med ingen vedlikehold, ingen funksjonsforbedringer og ingen støtte. Ingen moderne teknologiselskap kan operere i denne modellen.

Wiley og jeg kom til samme konklusjon: den eneste måten å fikse det på, var å bygge fra bunnen av.

DOSS stiller seg som en AI-nativ operasjonsplattform designet for å erstatte tradisjonelle ERP-systemer som SAP eller Oracle (ORCL ). Hva er de grunnleggende arkitektoniske forskjellene som gjør en AI-nativ ERP mulig i dag, som ikke var mulig for et tiår siden?

Oracle og SAP ble bygget i en æra hvor de, for å oppnå maksimalt distribusjon, måtte forenkle konfigurasjonsplanet til en ERP til å være en GUI-basert editor som relativt ikke-tekniske konsulenter kunne levere i stor skala. For å bevare beste praksis, låste de ned store deler av kjerne-systemene og tillot bare komposisjon på kantene. Imidlertid, i virkeligheten, når du ser på spekteret av alle bedrifter i verden, trenger deres forretningsapplikasjoner maksimal fleksibilitet.

Hva den AI-native verden muliggjør, er transformasjonen av programvareutvikling fra en håndverksmessig prosess til en industrialisert maskin. Lenger trenger vi ikke programvarehåndverkere til å håndbygge kode-systemer; i stedet er vi i ferd med å gå over til en verden hvor programvare-gjennomstrømming er en faktor av beregning og token.

Doss er arkitektonisk designet med nettopp dette i mente.

Vi bygde ZSL, et deklarativt domene-spesifikt språk (DSL) som beskriver en kundes hele DOSS-implementering i kode. Tenk på hva “Terraform” gjorde for “Infrastructure as Code”-bestrebelsen, men i stedet anvendt på forretningsapplikasjonslogikk. Ved å definere ERP-er i et relativt lav-dimensjonalitets programmeringsspråk, er vi i stand til å deployere agenter i stor skala for å levere ERP-løsninger.

En gang ZSL var skrevet, var den viktigste delen av arkitekturen å bake inn beste praksis i plattformen selv for å forhindre agenter fra å bygge lavkvalitetsimplementeringer. Vårt team har levert et skalerbart distribuert system med en kernel-nivå scheduler for å ta på seg belastningen av bursty ERP-arbeidsbelastninger. Videre har vi bygget en HTAP-database som kombinerer de viktigste delene av en transaksjonsdatabase som Postgres og de analytiske evnene til en Data Warehouse.

Ved å bygge plattformen for å ha Enterprise-grads styrke tidlig, er systemet satt opp for fullstendig agentic distribusjon. Hva som tidligere tok konsulentlag måneder og år å gjøre, kan nå parallelliseres i stor skala ved hjelp av agentic infrastruktur i vårt proprietære lukkede system.

Mange selskaper avhenger fortsatt av regneark og fragmenterte verktøy for innkjøp, lagerstyring og ordrebehandling. Hva er de største operasjonelle blindsonene som oppstår når kjerneforretningsdata ikke er samlet inn i en enkelt kilde til sannhet?

Det største problemet er at beslutninger tas på basis av utdatert eller ufullstendig informasjon. Hvis dine lagerdata bor i ett sted, dine kjøpeordrer i et annet, og dine salgsordrer i et tredje, er du alltid i ferd med å forlike, manuelt, sakte og etter faktum. Når noen innser at lageret er feil eller en leverandør er forsinket, er det allerede et problem i bedriften.

Verve Coffee Roasters er et godt eksempel på hvor dette bryter sammen i praksis. De driver operasjoner over hele landet, inkludert detaljhandel, grossist, DTC og kafeer i USA og Japan, men håndterte all dette over separate systemer uten sanntids lageroversikt. De gikk tom for sin egen kaffe på høyt trafikkerte steder og rammet kritiske lagermengder under en stor detaljhandelslansering som skadet en nøkkel detaljhandelsforhold. Dataene eksisterte et sted; de var bare ikke koblet sammen på en måte som lot noen handle på dem i tide.

Det mer subtile problemet er at fragmentering skjuler den virkelige formen på dine operasjoner. Du kan ikke se forholdet mellom en forsinkelse oppstrøms og et oppfyllelsesproblem nedstrøms hvis disse to ting bor i separate verktøy. Du ender med å håndtere symptomer, ekspederer ordrer, bygger sikkerhetslager og kjører manuelle sjekker i stedet for å forstå hva som faktisk skjer. Et samlet system endrer ikke bare tid på forlikning; det endrer hva du overhodet kan se og stille spørsmål om.

I kjernen, tenk på å drive et bedriftsbedrift uten tilgang til et versjonskontrollsystem (Git), et observasjonssystem (DataDog) eller en sentralisert database for å spørre informasjon ut av.

ERP-implementeringer har historisk sett kravd store konsulentlag og måneder – eller til og med år – med deployering. Hvordan endrer AI økonomien og kompleksiteten ved å implementere operasjonell programvare innen virkelige bedrifter?

Den tradisjonelle implementeringsmodellen er det emergente resultatet av generasjons-gamle programvarepraksiser. Vi lever ikke lenger i den verden.

Det er en pervers incentiv i ERP-implementeringer i dag – jo lenger implementeringen tar og jo mindre effektiv den er, jo mer penger mottar implementererne. De fleste byggere ville ikke dra nytte av dette; likevel er de aldri incentivert til å flytte med fart og kvalitet.

Videre er forholdet mellom konsulentutgifter og programvareutgifter i en tradisjonell ERP-engasjement på omtrent 9:1, så du bruker ni dollar på konsulenter for hver dollar du bruker på programvaren selv. For et stort bedrift er dette ekstremt smertefullt. For mid-markedsbedrifter er det forbudt. Så de enten setter seg for en programvare som ikke faktisk passer hvordan de opererer, forsinker prosjektet eller forkaster det delvis gjennom.

AI endrer enhetens økonomi helt. I stedet for en konsulentengasjement, er en DOSS-implementering en kodebase. Etterhvert som våre implementeringstider fortsetter å krympe, er vi i stand til å alignere incentiver med en “betale ved levering”-modell i stedet for “betale mens du går”. Når bedriften endrer seg, endrer systemet seg med det. Behovet for rom fulle av konsulenter og lange slide-dek er ikke lenger relevant.

Suksess hos Doss betyr å erstatte den globale IT-tjenesten på 1,86 billioner dollar med agentic implementering og vedlikehold ved hjelp av vår ZSL som språket for bedriftsprogramvare. Suksess hos Doss er å kommodisere alle bedriftsapplikasjoner i stor skala.

De har deployert DOSS med selskaper som opererer i virkelige miljøer som produksjon, logistikk og forbruksgoder. Hva er noen av de uventede utfordringene som oppstår når AI møter urent operasjonell data?

Utfordringen er sjelden AI-en. Det er dataene du ber om å granske.

Hvert selskap vi arbeider med, har akkumulert år med operasjonelle arbeidsomgåelser. Dataene eksisterer teknisk sett, men bor ikke et sted hvor deres ansatte, la oss si agenter, kan pålitelig handle på dem.

Et godt eksempel er en tysk møbelprodusent som lager tilpassede deler. Når vi kom inn, hadde de 10 års historiske data spredt over 8 tilpassede filformater med 11 forskjellige dataobjekter og en 3PL-synkronisering som kjørte på manuell kopiering fra FTP-mapper. Forretningslogikken var spesifik med tilpassede dimensjoner, konfigurasjoner, betalingsmetoder og utstillingssteder, og hele systemet måtte fungere på tysk. Det er ingen standard-skjema for det.

Utfordringen er ikke den tekniske kompleksiteten til noen enkelt del. Det er at hver bedrift har en annen versjon av dette problemet, og du kan ikke fullstendig forutse det før du er inne i deres data. Jobben er å ta en nøyaktig avtrykk av hvordan bedriften faktisk opererer, ikke å kartlegge deres data inn i en generisk mal og håpe det passer.

For å bygge en løsning som fungerer for den virkelige verden, trenger du en plattform med maksimal fleksibilitet. Først da kan AI være nyttig i å forstå den underliggende datamodellen det arbeider fra, og bygge modellen som fungerer for hver kunde.

Det er mye diskusjon om AI-kopiloter og autonome agenter i bedriftsprogramvare. Hvor ser du at AI legger til mest verdi i operasjonelle arbeidsflyter i dag, og hvor forblir menneskelig tilsyn fortsatt essensielt?

På stor skala har AI evnen til å forstyrre all operasjonell arbeid.

Over den nærmeste horisonten, skal Doss’ proprietære modeller og agenter kunne transformere kjernen av tekniske konsulenter i implementering av bedriftsapplikasjoner, samt management-konsulenter i levering av strategiske anbefalinger. Doss vil ha den største repository av strukturert og samlokalisert data som representerer både skjema og operasjonell informasjon for bedrifter. Våre agenter kan bruke denne dataen til å levere skalerbare anbefalinger.

Den mest verdifulle verdien i dag er mer spesifik enn det. Det er i arbeid som er repetitivt, regelbasert og for tiden gjort av mennesker som har andre, mer strategiske prioriteringer: prosessering av kjøpeordrer, lagerrekonkiling og routing av oppfyllelsesbeslutninger. Disse oppgavene har veldefinerte inndata og utdata, og AI kan håndtere dem pålitelig i stor skala.

For nå er menneskelig tilsyn essensielt hvor kostnaden av en feil beslutning er høy, og systemet ikke ennå har nok kontekst til å være sikker. I dag er den riktige modellen ikke autonome agenter som erstatter menneskelig beslutning helt; det er agenter som håndterer høy-volum, veldefinert arbeid så mennesker kan fokusere på beslutningene som faktisk krever deres dømmekraft.

Mange bedrifter prøver å lagre AI på toppen av eksisterende programvare-stacker. Hvorfor faller retrofitting av legacy-systemer med AI ofte kort i forhold til å bygge AI direkte inn i grunnlaget av plattformen?

Legacy-systemer ble ikke bygget for å bli gransket av AI. Datamodellene, API-ene, måten informasjon er strukturert, alt dette var designet for mennesker å interagere med gjennom grensesnitt. Når du prøver å lagre AI på toppen, ber du det om å arbeide rundt begrensninger det ikke var meningen å arbeide rundt.

Selv om du prøver å kaste en MCP-server på toppen, i virkeligheten, trenger en MCP-server ekstremt spesifikke designmønster. De fleste MCP-servere i dag introduserer faktisk større kontekstvindus-bloat og blåser opp ytelse.

Det dypere problemet er implementeringsmodellen. I en tradisjonell ERP, er konfigurasjonen av systemet lagret i systemet selv. Det er ikke kode du kan lese, teste eller versjonere. Det er ingen måte for en agent å forstå hva systemet gjør, la oss si endre det trygt. Vi bygde ZSL spesifikt så at konfigurasjonen er en ordentlig kodebase: lesbar, testbar og deploybar i et lukket system.

Hvordan ser du at AI transformerer “operasjonssystemet” til en bedrift over de neste fem til ti årene, særlig i områder som forsyningskjede-synlighet, sanntidsbeslutning og automatiserte operasjoner?

Vi grunnla Doss på overbevisningen om at bedriftssystemer ville kunne bygge seg selv. Tre år senere, har vi gått inn i Fase 2 av Doss: den agent-baserte selvkjørende implementeringen. Plattformen kan allerede generere, validere og utvikle en kundes system i stedet for å avhenge av manuell konsulentkonfigurasjon, og den blir bedre med hver deployering.

Retningen dette er på vei mot, er et system som alltid er i fase med bedriften. I dag er gapet mellom hvordan en bedrift opererer og hva programvaren vet om det, måneder eller år. Systemet ble konfigurert på et tidspunkt og har ikke endret seg siden. Hva som blir mulig når dette gapet lukkes, når systemet tilpasser seg i sanntid mens bedriften endrer seg, er en annen kategori av operasjonell evne. Sanntids-synlighet er ikke bare raskere rapportering; det er evnen til å fange en forsyningsforstyrrelse før den blir en oppfyllelsesfeil. Automatiserte operasjoner er ikke bare om effisiens; det er evnen til å kjøre en mer kompleks bedrift med samme lag.

Takk for dine detaljerte svar, lesere som ønsker å lære mer, bør besøke Doss.