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 startup-selskaper og større skala infrastruktursystemer. Før han co-grunnla Doss, var han en av de første ingeniørene i Siteline, der han bygde kjerne-systemer inkludert tillatelses-arkitektur, ERP-integrasjoner og automatiserings-rammeverk, samtidig som han bidro til rekruttering, omsetningsdrift og selskapskultur. Tidligere i sin karriere holdt han ingeniørstillinger i Rubrik og praktiserte i selskaper som Uber og VMware, og utviklet ekspertise i sky-infrastruktur, datasystemer og automatisering. Samtidig med sitt tekniske arbeid, har han vært aktivt engasjert i mentorering 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 bedriftsprogramvare-selskap som fokuserer på å gjenskape tradisjonelle ERP-systemer gjennom sin Adaptive Resource Platform (ARP), en fleksibel, AI-nativ operasjonsplattform designet for å forene og automatisere forretnings-workflows. Bygget som en komposabel alternativ til legacy ERP-løsninger, gjør Doss det mulig for selskaper å håndtere lager, innkjøp, finans og levering innen ett enkelt system som tilpasser seg virkelige operasjoner i stedet for å tvinge faste prosesser. Plattformen kombinerer en sentralisert data-lag, kode-frie workflows og sanntids-analyser, som gjør det mulig for bedrifter å deployere raskt, integrere med eksisterende verktøy og kontinuerlig utvikle sine operasjoner uten lengre implementeringer eller dyre konsulenter.

Motivasjonen for å bygge DOSS går tilbake til Wiley som så hvordan legacy-programvare forstyrte hans fars produksjonsselskap, og både dere så lignende problemer førstehånds mens de arbeidet med fabrikker og hårdvaruleverandører. Hvordan har disse erfaringene formet 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 – CFOer, regnskapsførere osv – ikke gikk med vår løsning, var fordi de var “for opptatt med å implementere et ERP”. Da jeg dykket dyptere inn i den arkaiske verden av ERP, ble jeg slått av den eksisterende implementeringsmodellen.

Hva jeg fortsatte å se, var det samme grunnleggende feilet: implementering tar måneder eller år, koster hundredtusener til millioner av dollar, og er bottlenecket helt på menneskelige konsulenter med time-basert fakturering. Deretter, når ERP-en er ferdig, stopper den med å endre seg. Bedriften fortsetter å utvikle seg; systemet gjør det ikke. Dette er et arkitektur-problem, ikke et konfigurasjons-problem. Du kan ikke patche deg ut av det.

Som en programvare-bygger, 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. Ingeniører ville reagere.

Ingen moderne teknologiselskap kan operere i den modellen. Wiley og jeg kom til samme konklusjon: den eneste måten å fikse det på, var å bygge fra scratch.

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

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

Hva den AI-native verden muliggjør, er transformasjonen av programvare-utvikling fra en håndverksmessig prosess til en industrialisert maskin. Lenger trenger vi ikke programvare-håndverkere til å hånd-bygge kode-systemer; i stedet beveger vi oss inn i en verden hvor programvare-gjennomstrømming er en faktor av beregning og token.

Doss er bygget 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”-bestrebelser, men i stedet anvendt på forretnings-applikasjons-logikk. Ved å definere ERP-er i et relativt lav-dimensjonal programmeringsspråk, er vi i stand til å deployere agenter i skala for å levere ERP-løsninger.

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

Ved å bygge plattformen for å ha enterprise-grad av styrke tidlig, er systemet satt opp for fullstendig agentic distribusjon. Hva som tidligere tok lag av konsulenter måneder og år å gjøre, kan nå parallelliseres i 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, lager og ordre-håndtering. Hva er de største operasjonelle blind-sonene som oppstår når kjerne-forretnings-data ikke er forent i en enkelt kilde til sannhet?

Det største problemet er at beslutninger tas på basis av stale eller ufullstendig informasjon. Hvis ditt lager-data bor i ett sted, dine kjøpsordrer i et annet, og dine salgsordrer i et tredje, er du alltid i ferd med å rekonsilere, manuelt, sakte og etter faktum. Ved den tid 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 kjører operasjoner over grocery, wholesale, DTC og cafes i USA og Japan, men håndterte all dette over forskjellige systemer uten sanntids lager-synlighet. De løp tom for sin egen kaffe på høy-traffic lokasjoner og traff kritiske lager-utsalg under en stor detaljhandels-lansering som skadet en nøkkel detaljhandels-forhold.

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 leverings-problem nedstrøms hvis disse to ting bor i separate verktøy. Du ender med å håndtere symptomer, ekspedere ordrer, bygge sikkerhets-lager og kjøre manuelle sjekker i stedet for å forstå hva som virkelig skjer. Et forent system endrer ikke bare tid på rekonsiliasjon. Det endrer hva du kan se og spørre om.

I sin kjerne, forestill deg å kjøre et bedrifts-selskap uten tilgang til et versjonskontroll-system (Git), et overvåkning-verktøy (DataDog) eller en sentralisert database for å spørring informasjon ut av.

ERP-implementeringer har historisk sett krevet store konsulent-lag og måneder – eller sogar år – av deployering. Hvordan endrer AI økonomien og kompleksiteten ved å implementere operasjonelt programvare innen virkelige bedrifter?

Den tradisjonelle implementeringsmodellen er det emergente resultatet av generasjons-gamle programvare-praksiser. Vi bor ikke lenger i den verden.

Det er en pervertert incentiv i ERP-implementeringer i dag – jo lenger en implementering 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 å bevege seg med fart og kvalitet.

Videre er forholdet mellom konsulent-utgifter og programvare-utgifter i en tradisjonell ERP-engasjement 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-market bedrifter er det forbudt. Så de enten setter seg for programvare som ikke faktisk passer hvordan de opererer, forsinker prosjektet eller forkaster det delvis gjennom.

AI endrer enhets-økonomien helt. I stedet for en konsulent-engasjement, er en DOSS-implementering en kodebase. Etterhvert som våre implementerings-tider fortsetter å krympe, er vi i stand til å aligne incentiv 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-tjeneste-utgift på 1,86 billioner dollar med agentic implementering og vedlikehold ved hjelp av vår ZSL som språket for bedrifts-applikasjons-programvare. Suksess hos Doss er å kommodisere alle bedrifts-applikasjoner i 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 uordenlige operasjonelle data?

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

Hvert selskap vi arbeider med, har akkumulert år med operasjonelle workarounds. Dataene eksisterer teknisk sett, de bor bare ikke noen sted hvor deres ansatte, la oss si agentic-systemer, kan pålitelig handle på dem.

Et godt eksempel er en tysk møbel-produsent som lager tilpassede deler. Da vi kom inn, hadde de 10 år med historiske data spredt over 8 tilpassede fil-formater med 11 forskjellige data-objekter og en 3PL-synkronisering som kjørte på manuell kopier-og-lim fra FTP-mapper. Forretnings-logikken var spesifik med tilpassede dimensjoner, konfigurasjoner, betalings-metoder og utstillings-lokasjoner, og hele systemet trengte å fungere på tysk. Det er ingen av-the-shelf-skema for det. De måtte betale tusenvis av euro hver gang de ønsket å endre enkle konfigurasjons-alternativer, som status-alternativer for en kjøpsordre.

Utfordringen er ikke den tekniske kompleksiteten til noen enkelt del. Det er at hvert selskap 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 data-modellen det arbeider fra, og bygge modellen som fungerer for hver kunde.

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

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

Over den nære horisont, burde Doss’ proprietære modeller og agenter være i stand til å transformere kjerne-konsulenter i implementering av bedrifts-applikasjoner 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 tydeligste verdien i dag er mer spesifik enn det. Det er i arbeid som er repetitivt, regel-basert og for tiden gjort av mennesker som har andre, mer strategiske prioriteringer: prosessering av kjøpsordrer, rekonsiliasjon av lager og routing av leverings-beslutninger. Disse oppgavene har godt definerte inndata og utdata, og AI kan håndtere dem pålitelig i 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, godt-definert arbeid så mennesker kan fokusere på beslutningene som faktisk krever deres dømmekraft.

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

Legacy-systemer ble ikke bygget for å bli resonnert om av AI. Data-modellene, API-ene, måten informasjon er strukturert, alt var designet for mennesker å interagere med gjennom grensesnitt. Når du prøver å legge AI på toppen, ber du den om å arbeide rundt begrensninger det ikke var ment å arbeide rundt.

Selv om du prøver å kaste en MCP-server på toppen, i virkeligheten, trenger en MCP-server ekstremt spesifikke design-mønster. De fleste MCP-servere i dag introduserer faktisk større kontekst-vindus-bloat og sprenger ytelse.

Likevel er det dypere problemet implementerings-modellen. 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 korrekt kodebase: lesbar, testbar og deploybar i et lukket system. Vi bygger en fullstendig agentic programvare-utviklings-livssyklus (SDLC). Dette er forutsetningen for at AI kan faktisk operere på systemet i stedet for bare å sitte på toppen.

Hvordan tror du AI vil endre grensesnittet til tradisjonell bedrifts-programvare i fremtiden, særlig i områder som supply chain-synlighet, sanntids-beslutning og automatiserte operasjoner?

Grensesnitt-spørsmålet er virkelig om hvem som trenger å bruke systemet. Nå er ERP-grensesnitt bygget rundt en liten gruppe power-brukere, menneskene som ble trent på systemet under implementering. Alle andre enten kan ikke bruke det eller får en degradert versjon av det.

Hva vi bygger, er et komposabelt UI, som behandler grensesnittet som en nettside-bygger. Grensesnittet selv er også bakket av det lukkede ZSL. Hver, CFO-en, lager-mesteren, supply chain-analysten, får en dashboard og data-views komponert rundt hvordan de faktisk arbeider, ikke rundt hvordan programvaren var konfigurert. Etterhvert som AI håndterer mer av den underliggende workflow-eksekvering, blir grensesnittet mindre om data-innputt og mer om synlighet og beslutning. Du trenger å se hva som skjer, forstå hvorfor og gjøre dømmekraft-beslutninger. Programvaren burde håndtere resten.

Startups som DOSS går inn i en marked dominert av tiår-gamle etablerte selskaper. Hva fordeler har AI-native startups når de konkurrerer mot etablerte bedrifts-plattformer?

De etablerte selskapene har det motsatte problemet fra startups. De har enorme installerte baser å beskytte. Hver arkitektur-beslutning de tar, må være bakover-kompatibel. De kan legge AI-funksjoner til eksisterende produkter, men de kan ikke bygge om de underliggende systemene uten å bryte alt som kjører på dem. Dette er ikke en feil av ambisjon; det er strukturelt.

I ERP-spesifikt, er de også belastet med forretnings-beslutninger som drev dem ned en vei hvor inntekt er drevet fra den spesifikke funksjonen DOSS ser på å eliminere – profesjonelle tjenester-konsulenter. Gitt at brukerne bruker ni dollar på konsulenter for hver dollar de bruker på programvaren selv, er evnen til å transformere 90% av deres kilde-inntekt umulig for store etablerte selskaper.

Et AI-nativt system kan være designet fra starten av så at AI er en del av kjerne-arkitekturen, ikke et lag på toppen. Implementerings-modellen, data-modellen og måten konfigurasjon fungerer, er alle designet med AI som en førsteklasses deltaker. Dette er en komponerende fordel hvor hver deployering gjør systemet bedre, og implementerings-agenter blir mer kapable med hver ny kunde. Denne type forbedrings-løkken eksisterer ikke i et system hvor implementering fortsatt er en menneskelig konsulent-engasjement.

Ser fremover, hvordan forestiller du deg at AI vil transformere “operasjonssystemet” til en bedrift over de neste fem til ti år, særlig i områder som supply chain-synlighet, sanntids-beslutning og automatiserte operasjoner?

Vi grunnla DOSS på overbevisningen om at bedrifts-systemer ville være i stand til å bygge seg selv. Tre år inn, har vi gått inn i Fase 2 av Doss: den agentic selv-kjørende implementering. Plattformen kan allerede generere, validere og utvikle en kundes system i stedet for å avhenge av manuell konsulent-konfigurasjon, og den blir bedre med hver ny deployering.

Retningen dette er på vei mot, er et system som alltid er i samspill 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 som bedriften endrer seg, er en annen kategori av operasjonell evne. Sanntids-synlighet er ikke bare raskere rapportering; det er evnen til å fange en forsynings-forstyrrelse før den blir en leverings-feil. Automatiserte operasjoner er ikke bare om effisiens; det er evnen til å kjøre en mer kompleks bedrift med samme team. Dette er versjonen av operasjonelt programvare vi bygger mot.

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