Arnav Mishra, mede-oprichter en CTO van Doss – Interviewreeks

Arnav Mishra, mede-oprichter en CTO van Doss, is een full-stack engineer en technisch leider met een achtergrond die bestaat uit startups in de vroege fase en grote infrastructurele systemen. Voordat hij Doss mede-oprichtte, was hij een van de oprichters van Siteline, waar hij kernsystemen bouwde, waaronder een architectuur voor machtigingen, ERP-integraties en automatiseringskaders, en ook bijdroeg aan werving, omzetoperaties en bedrijfscultuur. Eerder in zijn carrière was hij ingenieur bij Rubrik en stond hij stage bij bedrijven als Uber en VMware, waar hij expertise ontwikkelde op het gebied van cloud-infrastructuur, datasystemen en automatisering. Naast zijn technische werk is hij actief betrokken geweest bij mentorship en talentontwikkeling via organisaties als Techquitable Futures en Contrary, wat een bredere toewijding weerspiegelt om de volgende generatie engineers te ondersteunen.

Doss is een modern bedrijf voor ondernemingssoftware dat zich richt op het vernieuwen van traditionele ERP-systemen met zijn Adaptive Resource Platform (ARP), een flexibele, AI-gebaseerde operatieplatform dat is ontworpen om bedrijfsprocessen te verenigen en te automatiseren. Gebouwd als een composable alternatief voor legacy ERP-oplossingen, stelt Doss bedrijven in staat om voorraad, inkoop, financiën en levering te beheren binnen één systeem dat zich aanpast aan de werkelijke operaties in plaats van starre processen op te leggen. Het platform combineert een centrale datalaag, no-code workflows en real-time analytics, waardoor bedrijven snel kunnen implementeren, integreren met bestaande tools en hun operaties voortdurend kunnen ontwikkelen zonder langdurige implementaties of dure consultants. ondernemingsinfrastructuur ontworpen voor snelheid, schaalbaarheid en aanpasbaarheid.

De motivatie om DOSS te bouwen gaat terug naar Wiley die legacy-software zag verstoren in het productiebedrijf van zijn vader, en jullie beiden zagen later soortgelijke problemen met eigen ogen terwijl jullie met fabrieken en hardware-toeleveringsketens werkten. Hoe hebben die ervaringen jullie beslissing beïnvloed om DOSS mede op te richten en ERP-systemen vanaf het begin te heroverwegen?

Voordat DOSS, was ik de oprichter van een FinTech-startup. De nummer één reden waarom onze kopers – CFO’s, accountants, enz. – niet voor onze oplossing gingen, was omdat ze “te druk waren met het implementeren van een ERP”. Toen ik dieper keek in het archaïsche land van ERP, was ik verbijsterd door het bestaande implementatiemodel.

Wat ik bleef zien was hetzelfde fundamentele falen: implementatie duurt maanden of jaren, kost honderdduizenden tot miljoenen dollars, en wordt volledig geblokkeerd door menselijke consultants met uurloon. Vervolgens, als de ERP eenmaal is geïmplementeerd, houdt het op met veranderen. Het bedrijf blijft evolueren; het systeem niet. Dat is een architecturaal probleem, geen configuratieprobleem. Je kunt het niet patchen.

Als softwarebouwer kon ik het volgende vergelijken: stel je een wereld voor waarin het belangrijkste instrument dat je gebruikt – als ontwikkelaar, laten we zeggen GitHub – specifiek voor jouw bedrijf is gebouwd in de loop van jaren door een derde partij consultant. Vervolgens, als het product eenmaal klaar is, vertrekken de consultants zonder onderhoud, geen functieverbeteringen en geen ondersteuning. Ontwikkelaars zouden in opstand komen.

Geen modern technologiebedrijf kan op die manier opereren. Wiley en ik kwamen allebei tot dezelfde conclusie: de enige manier om het te repareren was om van scratch te bouwen.

DOSS positioneert zich als een AI-gebaseerd operatieplatform dat is ontworpen om traditionele ERP-systemen zoals SAP of Oracle te vervangen. Wat zijn de fundamentele architecturale verschillen die een AI-gebaseerde ERP mogelijk maken vandaag die niet haalbaar waren tien jaar geleden?

Oracle en SAP werden gebouwd in een tijdperk waarin ze, om maximale distributie te bereiken, de configuratievlak van een ERP moesten vereenvoudigen tot een GUI-gebaseerde editor die relatief niet-technische consultants op grote schaal konden leveren. Om best practices te behouden, sloten ze grote delen van de kernsystemen en stonden ze alleen compositie toe aan de randen. Echter, in werkelijkheid, als je naar het spectrum van alle bedrijven in de wereld kijkt, hebben hun bedrijfsapplicaties maximale flexibiliteit nodig.

Wat de AI-gebaseerde wereld mogelijk maakt is de transformatie van software-engineering van een ambacht naar een geïndustrialiseerde machine. We hebben geen software-ambachtslieden meer nodig om handmatig codesystemen te maken; in plaats daarvan gaan we een wereld in waarin software-doorvoer een factor is van compute en tokens.

Doss is specifiek met dit in gedachten gebouwd.

We bouwden de ZSL, een declaratieve domeinspecifieke taal (DSL) die de volledige implementatie van een DOSS-klant in code beschrijft. Denk aan wat “Terraform” deed voor de Infrastructure as Code-inspanning, maar toegepast op bedrijfsapplicatielogica. Door ERP’s te definiëren in een relatief lage-dimensionale programmeertaal, kunnen we agents op grote schaal inzetten om ERP-oplossingen te leveren.

Zodra de ZSL eenmaal was geschreven, was het belangrijkste onderdeel van de architectuur het integreren van best practices in het platform zelf om te voorkomen dat agents lage kwaliteit implementaties bouwen. Ons team heeft een schaalbare gedistribueerd systeem geleverd met een kernel-niveau scheduler om de last van bursty ERP-werklasten te verwerken. Bovendien bouwden we een HTAP-databasesysteem dat de belangrijkste onderdelen van een transactiedatabase zoals Postgres en de analytische mogelijkheden van een Data Warehouse combineert.

Door het platform te bouwen met ondernemingskracht vanaf het begin, is het systeem ingesteld voor volledige agente distributie. Wat eerder maanden of jaren duurde om te doen, kan nu worden geparalleliseerd op grote schaal met behulp van agente-infrastructuur in ons propriëtaire gesloten loopsysteem.

Veel bedrijven vertrouwen nog steeds op spreadsheets en gefragmenteerde tools voor inkoop, voorraadbeheer en orderbeheer. Wat zijn de grootste operationele blindspots die ontstaan wanneer kernbedrijfsgegevens niet worden geünificeerd in een enkele bron van waarheid?

Het meest voorkomende probleem is dat beslissingen worden genomen op basis van verouderde of onvolledige informatie. Als je voorraadgegevens op één plek leven, je inkooporders op een andere en je verkooporders op een derde, ben je altijd aan het reconciliëren, handmatig, langzaam en na de feiten. Als iemand eenmaal beseft dat de voorraad niet klopt of een leverancier achterloopt, is het al een probleem in het bedrijf.

Verve Coffee Roasters is een goed voorbeeld van waar dit in de praktijk fout gaat. Ze runnen operaties over grocery, wholesale, DTC en cafes in de VS en Japan, maar beheerden alles over gescheiden systemen zonder real-time voorraadzichtbaarheid. Ze raakten zonder hun eigen koffie op drukke locaties en raakten kritieke voorraden tijdens een grote retailer-lancering die een belangrijke retailrelatie schaadde. De gegevens bestonden ergens; ze waren alleen niet op een manier verbonden die iemand in staat stelde om erop te handelen.

Het subtielere probleem is dat fragmentatie de werkelijke vorm van je operaties verhult. Je kunt de relatie tussen een vertraging upstream en een fulfillmentprobleem downstream niet zien als die twee dingen in afzonderlijke tools leven. Je eindigt met het beheren van symptomen, expeditie van orders, opbouw van veiligheidsvoorraden en handmatige controles in plaats van te begrijpen wat er echt gebeurt. Een geünificeerd systeem bespaart niet alleen tijd op reconciliatie. Het verandert wat je zelfs kunt zien en vragen over stellen.

In essentie, stel je voor dat je een ondernemingsbedrijf runt zonder toegang tot een versiebeheersysteem (Git), een observatiehulpmiddel (DataDog) of een centrale database om informatie uit op te vragen.

ERP-implementaties hebben historisch gezien grote consultantsteams en maanden – of zelfs jaren – van implementatie vereist. Hoe verandert AI de economie en complexiteit van het implementeren van operationele software in echte bedrijven?

Het traditionele implementatiemodel is het emergente resultaat van generatiesoude softwarepraktijken. We leven niet langer in die wereld.

Er is een perverse incentive in ERP-implementaties vandaag – hoe langer een implementatie duurt en hoe minder effectief het is, hoe meer geld de implementers ontvangen. De overgrote meerderheid van bouwers zou hier niet van profiteren; echter, ze worden nooit aangemoedigd om met vaart en kwaliteit te bewegen.

Bovendien loopt het verhoudingscijfer van consultantuitgaven tot software-uitgaven in een traditionele ERP-betrokkenheid ongeveer 9:1, dus je geeft negen dollar uit aan consultants voor elke dollar die je uitgeeft aan de software zelf. Voor een groot ondernemingsbedrijf is dat extreem pijnlijk. Voor middenmarktbedrijven is het prohibitief. Dus ze settelen ofwel voor software die niet werkelijk past bij hoe ze opereren, vertragen het project of geven het op halverwege.

AI verandert de eenheidseconomie van dit helemaal. In plaats van een consultantengagement is een DOSS-implementatie een codebase. Naarmate onze implementatietijden blijven krimpen, zijn we in staat om incentives uit te lijnen met een “betaal bij levering”-model in plaats van “betaal zoals je gaat”. Wanneer het bedrijf verandert, verandert het systeem mee. De noodzaak voor kamers vol consultants en lange dia’s is niet langer relevant.

Succes bij Doss betekent het vervangen van de 1,86 biljoen dollar wereldwijde IT-dienstenuitgaven met agente-implementatie en onderhoud met behulp van onze ZSL als taal voor bedrijfsapplicatiesoftware. Succes bij Doss is het commodificeren van alle bedrijfsapplicaties op grote schaal.

Je hebt DOSS geïmplementeerd bij bedrijven die opereren in echte omgevingen zoals productie, logistiek en consumentengoederen. Wat zijn enkele van de onverwachte uitdagingen die ontstaan wanneer AI ontmoet rommelige operationele gegevens?

De uitdaging ligt zelden bij de AI. Het is de gegevens waar je het om vraagt te redeneren over.

Elk bedrijf waar we mee werken, heeft in de loop der jaren operationele workarounds opgebouwd. De gegevens bestaan technisch gezien, ze leven alleen niet op een plek waar hun werknemers, laat staan agente-systemen, er betrouwbaar op kunnen handelen.

Een goed voorbeeld is een Duitse meubelfabrikant die maatwerkstukken maakt. Toen we binnenkwamen, hadden ze 10 jaar aan historische gegevens verspreid over 8 aangepaste bestandsformaten met 11 verschillende gegevensobjecten en een 3PL-synchronisatie die draaide op handmatige kopieer- en plakacties van FTP-mappen. De bedrijfslogica was specifiek met aangepaste dimensies, configuraties, betalingsmethoden en showroomlocaties, en het hele systeem moest werken in het Duits. Er is geen standaardschema voor dat. Ze moesten duizenden euro’s betalen elke keer dat ze eenvoudige configuratie-opties wilden veranderen, zoals de statusopties voor een inkooporder.

De uitdaging is niet de technische complexiteit van een enkel onderdeel. Het is dat elk bedrijf een andere versie van dit probleem heeft, en je kunt het niet volledig anticiperen totdat je in hun gegevens zit.

Om een oplossing te bouwen die werkt voor de echte wereld, heb je een platform nodig met maximale flexibiliteit. Pas dan kan AI nuttig zijn in het begrijpen van het onderliggende datamodel waar het mee werkt en het bouwen van het model dat werkt voor elke klant.

Er is veel discussie over AI-co-piloten en autonome agenten in bedrijfssoftware. Waar denk je dat AI de meeste waarde toevoegt in operationele workflows vandaag, en waar blijft menselijke toezicht essentieel?

Op grote schaal heeft AI de mogelijkheid om alle operationele werk te verstoren.

Over de korte termijnhorizon zouden de propriëtaire modellen en agenten van Doss in staat moeten zijn om de kern van technische consultants in het implementeren van bedrijfsapplicaties en de rol van managementconsultants in het leveren van strategische aanbevelingen te transformeren. Doss zal de grootste repository van gestructureerde en gelokaliseerde gegevens hebben die zowel schema als operationele informatie voor bedrijven vertegenwoordigen. Onze agenten kunnen die gegevens gebruiken om schaalbare aanbevelingen te leveren.

De duidelijkste waarde vandaag is specifiek. Het is in werk dat repetitief, regelgebaseerd is en momenteel wordt gedaan door mensen die andere, strategischere prioriteiten hebben: het verwerken van inkooporders, het reconciliëren van voorraad en het routeren van fulfillment-beslissingen. Deze taken hebben goed gedefinieerde invoer en uitvoer, en AI kan ze betrouwbaar op grote schaal verwerken.

Voorlopig is menselijke toezicht essentieel waar de kosten van een verkeerde beslissing hoog zijn en het systeem nog niet genoeg context heeft om vertrouwen te hebben. Vandaag is het juiste model niet autonome agenten die menselijke beslissingen volledig vervangen; het is agenten die het hoogvolume, goed gedefinieerde werk verwerken zodat mensen zich kunnen concentreren op de beslissingen die echt hun oordeel vereisen.

Veel ondernemingen proberen AI op hun bestaande software-stacks te leggen. In jouw mening, waarom faalt het vaak om legacy-systemen met AI te retrofitten in vergelijking met het bouwen van AI rechtstreeks in de fundamenten van het platform?

Legacy-systemen zijn niet gebouwd om door AI te worden geredeneerd. De datamodellen, de API’s, de manier waarop informatie is gestructureerd, alles is ontworpen voor menselijke interactie via interfaces. Als je AI probeert te leggen op dat, vraag je het om te werken rondom beperkingen waar het niet voor is ontworpen.

Zelfs als je een MCP-server probeert te leggen, introduceert een MCP-server in werkelijkheid een grotere contextvensteropblazing en blaast het de prestaties op.

Het diepere probleem is het implementatiemodel. In een traditionele ERP is de configuratie van het systeem opgeslagen in het systeem zelf. Het is geen code die je kunt lezen, testen of versiebeheren. Er is geen manier voor een agent om te begrijpen wat het systeem doet, laat staan om het veilig te veranderen. We bouwden ZSL specifiek zodat de configuratie een echte codebase is: leesbaar, testbaar en implementeerbaar in een gesloten loopsysteem. We bouwen een volledig agente software-ontwikkelingsleven (SDLC). Dat is de vereiste voor AI om werkelijk op het systeem te werken in plaats van alleen er bovenop te zitten.

Hoe denk je dat de traditionele ondernemingssoftware-interfaces zullen evolueren naarmate AI in staat is om workflows te genereren en rechtstreeks met operationele systemen te interacteren?

De interfacevraag gaat eigenlijk over wie het systeem nodig heeft. Op dit moment zijn ERP-interfaces gebouwd rond een kleine set van power users, de mensen die zijn getraind op het systeem tijdens de implementatie. Iedereen anders kan het niet gebruiken of krijgt een verslechterde versie ervan.

Wat we bouwen is een composable UI, die de interface behandelt als een websitebouwer. De interface zelf wordt ook ondersteund door de gesloten ZSL. Elke CFO, elke magazijnbeheerder, elke supply chain-analist krijgt een dashboard en gegevensweergaven samengesteld rond hoe ze echt werken, niet rond hoe de software is geconfigureerd. Naarmate AI meer van de onderliggende workflow-uitvoering verwerkt, wordt de interface minder over gegevensinvoer en meer over zichtbaarheid en besluitvorming. Je moet zien wat er gebeurt, begrijpen waarom, en oordeel vellen. De software moet de rest afhandelen.

Startups zoals DOSS treden een markt binnen die wordt gedomineerd door decennialange gevestigde ondernemingen. Wat zijn de voordelen die AI-gebaseerde startups hebben bij het concurreren met gevestigde ondernemingsplatforms?

De gevestigde ondernemingen hebben het tegenovergestelde probleem van startups. Ze hebben een enorm geïnstalleerde basis die ze moeten beschermen. Elke architectonische beslissing die ze nemen, moet backward compatible zijn. Ze kunnen AI-functies toevoegen aan bestaande producten, maar ze kunnen de onderliggende systemen niet opnieuw opbouwen zonder alles te breken wat erop draait. Dat is geen falen van ambitie; het is structureel.

In ERP specifiek zijn ze ook beladen met zakelijke beslissingen die hen op een pad hebben gezet waaropvenue wordt gegenereerd door specifieke functies die DOSS probeert te elimineren – professionele dienstconsultants. Gezien het feit dat gebruikers negen dollar uitgeven aan consultants voor elke dollar die ze uitgeven aan de software zelf, is de mogelijkheid om 90% van hun bronvenue te transformeren onhoudbaar voor grote gevestigde ondernemingen.

Een AI-gebaseerd systeem kan vanaf het begin worden ontworpen zodat AI een onderdeel is van de kernarchitectuur, niet een laag erop. Het implementatiemodel, het datamodel en de manier waarop configuratie werkt, zijn allemaal ontworpen met AI als een eerste klas deelnemer. Dat is een cumulatief voordeel waarbij elke implementatie het systeem beter maakt, en de implementatieagenten meer capabel worden met elke nieuwe klant. Die verbeteringslus bestaat niet in een systeem waar implementatie nog steeds een menselijke consultantengagement is.

Kijkend naar de toekomst, hoe zie je AI de “operating system” van een bedrijf transformeren in de komende vijf tot tien jaar, met name op gebieden zoals supply chain-zichtbaarheid, real-time besluitvorming en geautomatiseerde operaties?

We richtten DOSS op met de overtuiging dat ondernemingsystemen in staat zouden zijn om zichzelf te bouwen. Drie jaar later zijn we het tweede fase van Doss ingegaan: de agente self-driving implementatie. Het platform kan al een klantensysteem genereren, valideren en evolueren in plaats van te vertrouwen op handmatige consultantconfiguratie, en het wordt beter met elke implementatie.

De richting waar dit heen gaat, is een systeem dat altijd in overeenstemming is met het bedrijf. Vandaag is de kloof tussen hoe een bedrijf opereert en wat de software weet over het bedrijf maanden of jaren. Het systeem werd geconfigureerd op een bepaald moment en is sindsdien niet veranderd. Wat mogelijk wordt als die kloof sluit, als het systeem in real-time verandert met het bedrijf, is een andere categorie van operationele capaciteit. Real-time zichtbaarheid is niet alleen snellere rapportage; het is de mogelijkheid om een supply chain-verstoring te vangen voordat het een fulfillment-fout wordt. Geautomatiseerde operaties zijn niet alleen over efficiëntie; het is de mogelijkheid om een complexer bedrijf te runnen met hetzelfde team. Dat is de versie van operations software die we naar toe bouwen.

Bedankt voor uw gedetailleerde antwoorden, lezers die meer willen leren, moeten bezoeken Doss.