Arnav Mishra, Co-Founder og CTO af Doss – Intervieuserie

Arnav Mishra, Co-Founder og CTO af Doss, er en full-stack ingeniør og teknisk leder med en baggrund, der spænder over tidlige startups og større skala infrastruktursystemer. Før han co-foundede Doss, var han founding engineer hos Siteline, hvor han byggede kernesystemer, herunder tilladelsesarkitektur, ERP-integrationer og automatiseringsrammer, samt bidrog til rekruttering, omsætningsoperationer 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 i cloud-infrastruktur, datasystemer og automatisering. Ud over sit tekniske arbejde har han været aktivt involveret i mentorering og udvikling af talent 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, der er 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 et enkelt system, der tilpasser sig til virkelige operationer i stedet for at tvinge faste processer. Dets platform kombinerer en centraliseret datalag, kodefrie workflows og realtidsanalyser, hvilket giver virksomheder mulighed for at deployere 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å, hvordan legacy-software forstyrrede hans fars produktionsvirksomhed, og hvordan I begge senere så lignende problemer førstehånds, mens I arbejdede med fabrikker og hardwareforsyningskæder. Hvordan formede disse oplevelser din beslutning om at co-funde DOSS og omdefinere ERP-systemer fra bunden?

Før DOSS var jeg founding engineer i en FinTech-startup. Årsagen til, at vores købere – CFO’er, revisorer osv. – ikke ville gå med vores løsning, var, fordi de var “for travlt optaget af at implementere et ERP”. Da jeg dykkede dybere ind i den arkaiske verden af ERP, blev jeg chokeret over den eksisterende implementeringsmodel.

Det, jeg stadig så, var det samme fundamentale problem: Implementering tager måneder eller år, koster hundredtusinder til millioner af dollars og er bundet helt til menneskelige konsulenter med timebaseret fakturering. Derefter, når ERP’en er færdig, stopper den med at ændre sig. Forretningsvirksomheden udvikler sig stadig; systemet gør ikke. Det er et arkitekturproblem, ikke et konfigurationsproblem. Du kan ikke lave en løsning ved at lappe på 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. Derefter, når produktet er færdigt, forlader konsulenterne med ingen vedligehold, ingen funktionforbedringer og ingen support. Ingeniører ville reagere meget stærkt.

Ingen moderne teknologivirksomhed kan fungere i den model. Wiley og jeg nåede begge til 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. Hvad er de fundamentale arkitekturafvigelser, der gør en AI-nativ ERP mulig i dag, som ikke var mulig for ti år siden?

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

Det, AI-verdenen muliggør, er transformationen af softwareudvikling fra en håndværk til en industrialiseret maskine. Vi har ikke længere brug for software-håndværkere til at håndbygge kodesystemer; i stedet bevæger vi os ind i en verden, hvor software-gennemstrømning er en faktor af beregning og token.

Doss er bygget med netop 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-bestræbelserne, men i stedet anvendt på forretningsapplikationslogik. Ved at definere ERP’er i et relativt lavdimensionalt programmeringssprog kan vi deployere agenter i stor målestok for at levere ERP-løsninger.

Da ZSL var skrevet, var det vigtigste del 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-arbejdsbelastninger. Derudover byggede vi en HTAP-databasesystem, der kombinerer de vigtigste dele af en transaktionsdatabase som Postgres og de analytiske funktioner af en Data Warehouse.

Ved at bygge platformen til at have enterprise-klasse-styrke fra begyndelsen er systemet sat op til fuldstændig 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 ordrebehandling. Hvad er de største operationelle blinde pletter, der opstår, når kerneforretningsdata ikke er samlet i en enkelt sandheds kilde?

Det mest kritiske problem er, at beslutninger tages på stælle eller ufuldstændige oplysninger. Hvis dine lagerdata bor et sted, dine købsordrer et andet sted og dine salgsordrer et tredje, 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 bagi, 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 fødevarer, engros, DTC og cafeer 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 eget kaffe på højtrafikerede steder og ramte kritiske lagermængder under en stor detailhandlerlancering, der skadede en nøgle detailforbindelse. Dataene fandtes et sted; de var bare ikke tilkoblede på en måde, der lod nogen handle på det i tide.

Det mere subtile problem er, at fragmentering skjuler den virkelige form af dine operationer. Du kan ikke se forholdet mellem en forsinkelse opstrøms og et opfyldningsproblem nedstrøms, hvis disse to ting bor i separate værktøjer. Du ender med at styre symptomer, ekspedere ordrer, bygge sikkerhedsstok og køre 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 dens kerne, forestil dig at køre en enterprise-virksomhed uden adgang til en versionsstyringssystem (Git), et overvågningsværktøj (DataDog) eller en centraliseret database til at forespørgse informationer 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 operationelt software inden for virkelige virksomheder?

Den traditionelle implementeringsmodel er det fremkomne 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 tager, og jo mindre effektiv den er, jo mere penge modtager implementorerne. De fleste byggere ville ikke udnytte dette; dog er de aldrig inciteret til at bevæge sig med fart og kvalitet.

Desuden kører forholdet mellem konsulentudgifter og softwareudgifter i en traditionel ERP-engagement 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-markedsvirksomheder er det forbudt. Så de enten sætter sig tilfreds med software, der ikke faktisk passer til, hvordan de opererer, forsinker projektet eller opgiver det på halvvejen.

AI ændrer enhedsekonomien i dette helt og holdent. I stedet for en konsulentengagement er en DOSS-implementering en kodebase. Da vores implementeringstider fortsætter med at skrumpe, er vi i stand til at 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 slide-decks 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 til en vare i stor målestok.

De har deployet DOSS med virksomheder, der opererer i virkelige miljøer som fremstilling, logistik og forbrugsvarer. Hvad er nogle af de uventede udfordringer, der opstår, når AI møder beskidt operationel data?

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

Hver virksomhed, vi arbejder med, har akkumuleret år af operationelle workaround. Dataene findes teknisk set; de bor bare ikke et sted, hvor deres ansatte, lad os sige agentic systemer, kan pålideligt handle på det.

Et godt eksempel er en tysk møbelproducent, 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ørte på manuel kopiering fra FTP-mapper. Forretningslogikken var specifik med brugerdefinerede 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 en enkelt del. Det er, at hver virksomhed har en anden version af dette problem, og du ikke fuldstændigt kan forudse det, før du er inde i deres data. Arbejdet er at tage en præcis aftryk af, hvordan virksomheden faktisk opererer, ikke kortlægge deres data til en generisk skabelon og håbe, det passer.

For at bygge en løsning, der fungerer for den virkelige verden, har du brug for en platform med maksimal fleksibilitet. Først da 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 business-software. Hvor ser du AI tilføje mest værdi i operationelle workflows i dag, og hvor forbliver menneskelig oversigt stadig essentiel?

I stor målestok har AI evnen til at afbryde alle operationelle arbejder.

Over den nære horisont burde Doss’ proprietære modeller og agenter være i stand til at transformere kerneområderne for tekniske konsulenter i implementering af business-applikationer samt managementkonsulenter i levering af strategiske anbefalinger. Doss vil have den største repository af struktureret og samlokaliseret 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øres af mennesker, der har andre, mere strategiske prioriteringer: behandling af købsordrer, afstemning af lager og routing af opfyldningsbeslutninger. 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 endnu ikke har nok kontekst til at være sikker. I dag er den rette model ikke autonome agenter, der erstatter menneskelig beslutningstagning helhjertet; 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 software-stacks. Hvorfor falder retrofitting af legacy-systemer med AI ofte kort i forhold til at bygge AI direkte ind i grundlaget for platformen?

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

Selv hvis du forsøger at kaste en MCP-server oven på, i virkeligheden har en MCP-server brug for meget specifikke designmønstre. De fleste MCP-servere i dag introducerer faktisk større kontekstvindue-ødem og sprenger performance.

Men 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 deployerbar i et lukket loop-system. Vi bygger en fuldstændig 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 software-græ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 er 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 nedgraderet version af det.

Det, vi bygger, er en komponerbar brugergrænseflade, der behandler grænsefladen som en website-bygger. Grænsefladen selv er også backet af den lukkede ZSL. Hver enkelt – CFO’en, lagerchefen, supply chain-analysten – får en dashboard og data-visninger komponeret omkring, hvordan de faktisk arbejder, 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ømmekraftskrævende beslutninger. Softwaren skal håndtere resten.

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

De etablerede virksomheder har det modsatte problem i forhold til startups. De har enorme installeringsbaser at beskytte. Hver arkitekturbeslutning, de tager, skal 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 fra den specifikke funktion, DOSS ser på at eliminere – professionelle services-konsulenter. Givet, at brugere bruger ni dollars på konsulenter for hver dollar, de bruger på softwaren selv, er evnen til at transformere 90% af deres kildeindtægt utænkelig for store etablerede virksomheder.

Et AI-nativt 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 på, er alle designet med AI som en førsteklasses deltager. Det er en kompenserende fordel, hvor hver deployment gør systemet bedre, og implementeringsagenterne bliver mere kapable med hver ny kunde. Den slags forbedringsløkke findes ikke i et system, hvor implementering stadig er et menneskeligt konsulentengagement.

Set fremad, hvordan forestiller du dig, at AI vil transformere “driftssystemet” for en virksomhed over de næste fem til ti år, især på områder som supply chain-synlighed, realtidsbeslutning og automatiserede operationer?

Vi grundlagde DOSS på overbevisningen om, 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 det bliver bedre med hver ny deployment.

Retningen, dette er på vej mod, er et system, der altid er i takt med forretningsvirksomheden. I dag er afstanden mellem, hvordan en virksomhed opererer, og hvad systemet ved om det, måneder eller år. Systemet blev konfigureret på et tidspunkt og har ikke ændret sig siden. Det, 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 evne. Realtids-synlighed er ikke bare hurtigere rapportering; det er evnen til at fange en forsyningsafbrydelse, før det bliver et opfyldningsfejl. Automatiserede operationer er ikke bare om effektivitet; det er evnen til at køre en mere kompleks virksomhed med det samme hold. Det er den version af operationssoftware, vi bygger mod.

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