Arnav Mishra, medstifter og CTO af Doss – Intervieuserie

Arnav Mishra, medstifter og CTO af Doss, er en full-stack ingeniør og teknisk leder med en baggrund, der spænder over tidlige startups og store skala infrastruktursystemer. Før han co-foundede Doss, var han en af de grundlæggende ingeniører hos Siteline, hvor han byggede core systemer, herunder tilladelsesarkitektur, ERP-integrationer og automatiseringsrammer, samt bidrog til rekruttering, revenue operations og firmaets kultur. Tidligere i sin karriere havde han ingeniørstillinger hos Rubrik og praktikerede hos virksomheder som Uber og VMware, hvor han udviklede ekspertise inden for cloud-infrastruktur, datasystemer og automatisering. Samtidig med sit tekniske arbejde har han været aktivt involveret i mentorering og talentudvikling gennem organisationer som Techquitable Futures og Contrary, hvilket afspejler en bredere forpligtelse til at støtte den næste generation af ingeniører.

Doss er et moderne enterprise softwarefirma, der fokuserer på at genopfinde traditionelle ERP-systemer gennem sin Adaptive Resource Platform (ARP), en fleksibel, AI-nativ operationsplatform designet til at samle og automatisere forretningsworkflows. Bygget som en komponerbar alternativ til legacy ERP-løsninger, giver Doss virksomheder mulighed for at styre lager, indkøb, finans og opfyldelse inden for ét system, der tilpasser sig til virkelige operationer i stedet for at tvinge faste processer. Platformen kombinerer en centraliseret datalag, no-code-workflows og realtidsanalyser, hvilket giver virksomheder mulighed for at udvikle hurtigt, integrere med eksisterende værktøjer og kontinuerligt udvikle deres operationer uden lange implementeringer eller dyre konsulenter.

Motivationen for at bygge DOSS går tilbage til Wiley, der så legacy software forstyrre sin fars fabrik, og hvordan I begge senere så lignende problemer på nærmere hold, mens I arbejdede med fabrikker og hardwareforsyningskæder. Hvordan formede disse oplevelser jeres beslutning om at co-funde DOSS og omdefinere ERP-systemer fra bunden?

Før DOSS var jeg grundlæggende ingeniør hos en FinTech-startup. Årsagen til, at vores købere – CFO’er, regnskabsmedarbejdere osv. – ikke ville gå med vores løsning, var, fordi de var “for travlt optaget af at implementere et ERP”. Da jeg dykkede dybere ned i det arkaiske land af ERP, blev jeg chokeret over den eksisterende implementeringsmodel.

Det, jeg hele tiden så, var det samme grundlæggende problem: implementering tager måneder eller år, koster hundredtusinder til millioner af dollars og er bottlenecket helt på menneskelige konsulenter med timebaseret fakturering. Så, når ERP’en er afskibet, holder den op med at ændre sig. Forretningsvirksomheden udvikler sig videre; systemet gør ikke. Det er et arkitekturproblem, ikke et konfigurationsproblem. Du kan ikke lave en omgang ud af det.

Som softwarebygger kan den tætteste sammenligning, jeg kunne tænke på, var følgende: forestil dig en verden, hvor det vigtigste værktøj, du bruger – som udvikler, lad os sige GitHub – var bygget specifikt til kun dit firma over en periode på år af en tredjeparts konsulentbureau. Så, når produktet er færdigt, forlader konsulenterne med ingen vedligeholdelse, ingen funktionforbedringer og ingen support. Ingen moderne teknologivirksomhed kan fungere i den model.

Wiley og jeg nåede begge til den samme konklusion: den eneste måde at løse det på var at bygge fra bunden.

DOSS positionerer sig selv som en AI-nativ operationsplatform designet til at erstatte traditionelle ERP-systemer som SAP eller Oracle (ORCL ). Hvad er de grundlæggende arkitektoniske forskelle, der gør en AI-nativ ERP mulig i dag, som ikke var mulig for et årti siden?

Oracle og SAP blev bygget i en æra, hvor de for at opnå maksimeret distribution behøvede at simplificere konfigurationsplanet af en ERP til at være en GUI-baseret editor, som relativt upræcise konsulenter kunne levere i stor målestok. For at bevare bedste praksis låste de store dele af de centrale systemer og tillod kun komposition ved kanten. Men i virkeligheden, når du ser på spektret af alle virksomheder i verden, har de brug for maksimal fleksibilitet.

Det, AI-verdenen muliggør, er transformationen af softwareudvikling fra en håndværk til en industrialiseret maskine. Længere behøver vi ikke softwarehåndværkere til at håndbygge kodesystemer; i stedet bevæger vi os ind i en verden, hvor softwaregennemstrømning er en faktor af beregning og tokens.

Doss er arkitekturdesignet med dette i mente.

Vi byggede ZSL, et deklarativt domænespecifikt sprog (DSL), der beskriver en kundes hele DOSS-implementering i kode. Tænk på, hvad “Terraform” gjorde for Infrastructure as Code-bevægelsen, men i stedet anvendt på forretningsapplikationslogik. Ved at definere ERP’er i et relativt lavdimensionalt programmeringssprog kan vi udvikle agenter i stor målestok til at levere ERP-løsninger.

Når ZSL var skrevet, var det vigtigste aspekt af arkitekturen at bage bedste praksis ind i platformen selv for at forhindre agenter i at bygge lavkvalitetsimplementeringer. Vores team har leveret et skalerbart distribueret system med en kernel-niveau scheduler til at tage på arbejdsbyrden af bursty ERP-arbejdsbyrde. Derudover byggede vi en HTAP-databasesystem, der kombinerer de vigtigste dele af en transaktionsdatabase som Postgres og de analytiske muligheder af en Data Warehouse.

Ved at bygge platformen til at have enterprise-grads styrke tidligt er systemet sat op til fuldt agentic distribution. Det, der tidligere tog hold af konsulenter måneder og år at gøre, kan nu paralleliseres i stor målestok ved hjælp af agentic infrastruktur i vores proprietære lukkede loop-system.

Mange virksomheder afhænger stadig af regneark og fragmenterede værktøjer til indkøb, lagerstyring og ordrestyring. Hvad er de største operationelle blinde pletter, der opstår, når kerneforretningsdata ikke er samlet i en enkelt sandheds kilde?

Det største problem er, at beslutninger tages på basis af forældede eller ufuldstændige oplysninger. Hvis dine lagerdata bor i ét sted, dine købsordrer i et andet, og dine salgsordrer i et tredje, så er du altid i gang med at afstemme, manuelt, langsomt og efterfølgende. Inden nogen opdager, at lageret er forkert eller en leverandør er efter, er det allerede et problem i forretningsvirksomheden.

Verve Coffee Roasters er et godt eksempel på, hvor dette bryder sammen i praksis. De driver operationer på tværs af detail, engros, DTC og caféer i USA og Japan, men styrede alt dette på tværs af ikke-tilkoblede systemer uden realtids lageroversigt. De løb tør for deres egen kaffe på højt trafikerede steder og ramte kritiske lagermængder under en stor detaillancering, der skadede en nøgle detailforbindelse. Dataen fandtes et sted; den var bare ikke tilkoblet på en måde, der tillod nogen at handle på den i tide.

Det mere subtile problem er, at fragmentering gemmer den virkelige form af dine operationer. Du kan ikke se forholdet mellem en forsinkelse opstrøms og et opfyldelsesproblem nedstrøms, hvis disse to ting bor i separate værktøjer. Du ender med at styre symptomer, ekspederer ordrer, bygger sikkerhedsstok og kører manuelle kontroller i stedet for at forstå, hvad der virkelig sker. Et samlet system ændrer ikke kun tiden på afstemning. Det ændrer, hvad du overhovedet kan se og stille spørgsmål om.

I sin kerne handler det om at køre en virksomhed uden adgang til en versionsstyringssystem (Git), en overvågningsværktøj (DataDog) eller en centraliseret database til at hente oplysninger ud af.

ERP-implementeringer har historisk set krævet store konsulenthold og måneder – eller endda år – af deployment. Hvordan ændrer AI økonomien og kompleksiteten af at implementere operationssoftware inden for virkelige virksomheder?

Den traditionelle implementeringsmodel er den fremvoksende resultat af generationer gamle softwarepraksis. Vi lever ikke længere i den verden.

Der er en pervers incitament i ERP-implementeringer i dag – jo længere en implementering varer og jo mindre effektiv den er, jo mere penge modtager implementorerne. De fleste byggere ville ikke tage fordel af dette; dog er de aldrig inciteret til at flytte med fart og kvalitet.

Derudover kører forholdet mellem konsulentudgifter og softwareudgifter i en traditionel ERP-forbindelse omtrent 9:1, så du bruger ni dollars på konsulenter for hver dollar, du bruger på softwaren selv. For en stor virksomhed er det ekstremt smertefuldt. For mid-markedsforretninger er det forbudt. Så de enten finder sig i software, der ikke faktisk passer til, hvordan de opererer, forsinker projektet eller opgiver det på halvvejen.

AI ændrer enheden økonomi helt. I stedet for en konsulentforbindelse er en DOSS-implementering en kodebase. Da vores implementeringstider fortsætter med at skrumpe, kan vi tilpasse incitamenter med en “betaling ved levering”-model i stedet for “betaling undervejs”. Når forretningsvirksomheden ændrer sig, ændrer systemet sig med det. Behovet for rum af konsulenter og lange slid er ikke længere relevant.

Success hos Doss betyder at erstatte den globale IT-tjenesteudgift på 1,86 billioner dollars med agentic implementering og vedligeholdelse ved hjælp af vores ZSL som sprog for business-applikationssoftware. Success hos Doss er at gøre alle business-applikationer tilgængelige i stor målestok.

I har udrullet DOSS hos virksomheder, der opererer i virkelige miljøer som fabrikation, logistik og forbrugsvarer. Hvad er nogle af de uventede udfordringer, der opstår, når AI møder beskidt operationsdata?

Udfordringen er sjældent AI. Det er data, du beder det om at forstå.

Hver virksomhed, vi arbejder med, har akkumuleret år af operationelle workaround. Dataen findes teknisk set; den bor bare ikke et sted, hvor deres medarbejdere, eller endda agentic systemer, kan handle på den pålideligt.

Et godt eksempel er en tysk møbelfabrikant, der laver tilpassede stykker. Da vi kom ind, havde de 10 års historisk data spredt over 8 brugerdefinerede filformater med 11 forskellige dataobjekter og en 3PL-synkronisering, der kører på manuel kopiering fra FTP-mapper. Forretningslogikken var specifik med tilpassede dimensioner, konfigurationer, betalingsmetoder og udstillingslokationer, og hele systemet skulle fungere på tysk. Der er ingen standard skema til det. De måtte betale tusinder af euros hver gang, de ville ændre simple konfigurationsindstillinger, som statusindstillinger for en købsordre.

Udfordringen er ikke den tekniske kompleksitet af noget enkelt stykke. Det er, at hver virksomhed har en anden version af dette problem, og du kan ikke fuldt ud forudse det, før du er inde i deres data. Arbejdet er at tage en præcis aftryk af, hvordan forretningsvirksomheden faktisk opererer, og ikke at kortlægge deres data ind i en generisk skabelon og håbe, det passer.

For at bygge en løsning, der fungerer i den virkelige verden, har du brug for en platform med maksimal fleksibilitet. Først derefter kan AI være nyttig til at forstå den underliggende datamodel, det arbejder fra, og bygge modellen, der fungerer for hver kunde.

Der er meget diskussion om AI-kopiloter og autonome agenter i businesssoftware. Hvor ser du AI tilføjer mest værdi i operationelle workflows i dag, og hvor forbliver menneskelig oversigt stadig essentiel?

På lang sigt har AI evnen til at forstyrre alle operationelle arbejde.

Inden for den nærmeste horisont burde Doss’ proprietære modeller og agenter være i stand til at transformere kernerne af tekniske konsulenter i implementering af business-applikationer samt managementkonsulenter i levering af strategiske anbefalinger. Doss vil have den største repository af struktureret og samlokalet data, der repræsenterer både skema og operationel information for virksomheder. Vore agenter kan bruge denne data til at levere skalerbare anbefalinger.

Den mest tydelige værdi i dag er mere specifik end det. Det er i arbejde, der er repetitivt, regelbaseret og i øjeblikket udført af mennesker, der har andre, mere strategiske prioriteringer: behandling af købsordrer, afstemning af lager og routing af opfyldelsesbeslutninger. Disse opgaver har veldefinerede input og output, og AI kan håndtere dem pålideligt i stor målestok.

For nu er menneskelig oversigt essentiel, hvoromkostningerne ved en forkert beslutning er høje, og systemet ikke endnu har nok kontekst til at være sikker. I dag er den rette model ikke autonome agenter, der erstatter menneskelig beslutning som helhed; det er agenter, der håndterer det højvolumen, veldefinerede arbejde, så mennesker kan fokusere på beslutningerne, der faktisk kræver deres dømmekraft.

Mange virksomheder forsøger at lagre AI oven på eksisterende softwarestakke. Hvorfor falder retrofitting af legacy-systemer med AI ofte kort i forhold til at bygge AI direkte ind i fundamentet af platformen?

Legacy-systemer blev ikke bygget til at blive forstået af AI. Datamodellerne, API’erne, måden information er struktureret på, alt dette blev designet til, at mennesker kan interagere med gennem grænseflader. Når du prøver at lagre AI oven på det, beder du det om at arbejde rundt om begrænsninger, det ikke var designet til at arbejde rundt om.

Selv hvis du forsøger at kaste en MCP-server oven på, introducerer en MCP-server i virkeligheden ofte større kontekstvinduesbloat og sprenger performance.

Det dybere problem er implementeringsmodellen. I en traditionel ERP er konfigurationen af systemet gemt i systemet selv. Det er ikke kode, du kan læse, teste eller versionere. Der er ingen måde for en agent at forstå, hvad systemet gør, endsige ændre det sikkert. Vi byggede ZSL specifikt, så konfigurationen er en ordentlig kodebase: læselig, testbar og deploybar i en lukket loop-system. Vi bygger en fuldt agentic softwareudviklingslivscyklus (SDLC). Det er forudsætningen for, at AI kan operere på systemet i stedet for bare at sidde oven på det.

Hvordan tror du, at traditionelle enterprise softwaregrænseflader vil udvikle sig, når AI bliver i stand til at generere workflows og interagere direkte med operationelle systemer?

Grænseflade-spørgsmålet handler virkelig om, hvem der har brug for at bruge systemet. I øjeblikket er ERP-grænseflader bygget omkring en lille gruppe af power-brugere, de mennesker, der blev trænet på systemet under implementeringen. Alle andre kan enten ikke bruge det eller får en degraderet version af det.

Det, vi bygger, er en komponerbar brugergrænseflade, der behandler grænsefladen som en webbygning. Grænsefladen selv er også backet af den lukkede ZSL. Hver, CFO’en, lagerchefen, forsyningskædeanalytiker, får en dashboard og dataudsigt komponeret omkring, hvordan de faktisk arbejder, og ikke omkring, hvordan softwaren blev konfigureret. Da AI håndterer mere og mere af den underliggende workflow-eksekvering, bliver grænsefladen mindre om dataindtastning og mere om synlighed og beslutningstagning. Du har brug for at se, hvad der sker, forstå hvorfor og træffe dømmekraftskrav. Softwaren skal håndtere resten.

Startups som DOSS kommer ind på en marked, der er domineret af årtier gamle etablerede virksomheder. Hvad er fordelene, som AI-native startups har, når de konkurrerer mod etablerede enterprise-platforme?

De etablerede virksomheder har det modsatte problem af startups. De har en enorm installeret base at beskytte. Hver arkitekturbeslutning de tager, må være bagudkompatibel. De kan tilføje AI-funktioner til eksisterende produkter, men de kan ikke genopbygge de underliggende systemer uden at bryde alt, der kører på dem. Det er ikke en fejl i ambition; det er strukturelt.

I ERP specifikt er de også belastet med forretningsbeslutninger, der drev dem ned ad en vej, hvor omsætning drives af den specifikke funktion, DOSS søger at eliminere – professionelle serviceskonsulenter. Givet, at brugere bruger ni dollars på konsulenter for hver dollar, de bruger på softwaren selv, er evnen til at transformere 90% af deres kildeomsætning uholdbar for store etablerede virksomheder.

En AI-nativ system kan være designet fra starten, så AI er en del af den grundlæggende arkitektur, ikke et lag oven på. Implementeringsmodellen, datamodellen og måden konfiguration virker er alle designet med AI som en førsteklasses deltager. Det er en fordelsfordel, hvor hver deployment gør systemet bedre, og implementeringsagenten bliver mere kapabel med hver ny kunde. Den slags forbedringsløkke findes ikke i et system, hvor implementering stadig er en menneskelig konsulentforbindelse.

Set fremad, hvordan forestiller du dig, at AI vil forvandle “operations-systemet” for en virksomhed over de næste fem til ti år, især inden for områder som forsyningskæde-synlighed, realtidsbeslutning og automatiseret drift?

Vi grundlagde DOSS på den overbevisning, at enterprise-systemer ville være i stand til at bygge sig selv. Tre år inde er vi gået ind i Fase 2 af Doss: den agentic selvstyrende implementering. Platformen kan allerede generere, validere og udvikle en kundes system i stedet for at afhænge af manuel konsulentkonfiguration, og den bliver bedre med hver enkelt deployment.

Retningen, dette bevæger sig i, er et system, der altid er i takt med forretningsvirksomheden. I dag er afstanden mellem, hvordan en virksomhed opererer, og hvad softwaren ved om det, måneder eller år. Systemet blev konfigureret på et tidspunkt og har ikke ændret sig siden. Hvad der bliver muligt, når denne afstand lukkes, når systemet tilpasser sig i realtid, som forretningsvirksomheden ændrer sig, er en anden kategori af operationel kapacitet. Realtids-synlighed er ikke bare hurtigere rapportering; det er evnen til at fange en forsyningskæde-forstyrrelse, før det bliver et opfyldelsesfejl. Automatiseret drift handler ikke kun om effektivitet; det handler om evnen til at køre en mere kompleks forretningsvirksomhed med det samme hold. Det er den version af operationssoftware, vi bygger imod.

Tak for dine detaljerede svar, læsere, der ønsker at lære mere, skal besøge Doss.