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 in start-ups en grote infrastructuursystemen. Voordat hij Doss mede-oprichtte, was hij een van de oprichters van Siteline, waar hij core-systemen ontwikkelde, waaronder een toestemmingarchitectuur, ERP-integraties en automatiseringsframeworks, en droeg hij ook bij aan werving, omzetoperaties en bedrijfscultuur. Eerder in zijn carrière werkte hij als 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 was hij actief betrokken 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 moderne ondernemingssoftwarebedrijf dat zich richt op het herscheppen van traditionele ERP-systemen via zijn Adaptive Resource Platform (ARP), een flexibele, AI-native operationsplatform dat is ontworpen om bedrijfsprocessen te verenigen en te automatiseren. 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 bedrijfsprocessen in plaats van rigide 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.

De motivatie om DOSS te bouwen gaat terug naar Wiley die legacy-software zag die zijn vaders productiebedrijf verstoorden, en jullie beiden zagen later vergelijkbare problemen tijdens het werken met fabrieken en hardware-toeleveringsketens. Hoe hebben die ervaringen jullie beslissing beïnvloed om DOSS te co-founden en ERP-systemen van scratch te herbouwen?

Voordat DOSS, was ik de oprichter van een FinTech-startup. De #1 reden waarom onze kopers – CFO’s, accountants, enz. – niet voor onze oplossing gingen, was omdat ze “te druk waren met de implementatie van een ERP”. Toen ik dieper in de archaïsche wereld van ERP doordrong, 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 geblokkeerd door menselijke consultants met uurloonfacturering. Vervolgens, zodra het ERP-systeem geïmplementeerd is, stopt het met veranderen. Het bedrijf blijft evolueren; het systeem niet. Dat is een architecturaal probleem, geen configuratieprobleem. Je kunt het niet oplossen door patches toe te passen.

Als softwarebouwer kon ik de volgende vergelijking maken: stel je een wereld voor waarin het belangrijkste instrument dat je gebruikt – als ontwikkelaar, laten we zeggen GitHub – specifiek voor jouw bedrijf is gebouwd over een periode van jaren door een derde partij consultant. Vervolgens, zodra het product af is, vertrekken de consultants zonder onderhoud, functionaliteitsverbeteringen of ondersteuning. Ontwikkelaars zouden in opstand komen.

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

DOSS positioneert zich als een AI-native operationsplatform ontworpen om traditionele ERP-systemen zoals SAP of Oracle (ORCL ) te vervangen. Wat zijn de fundamentele architecturale verschillen die een AI-native ERP mogelijk maken vandaag die niet haalbaar waren een decennium geleden?

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

Wat de AI-native 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 binnen waarin software-doorvoer een factor is van compute en tokens.

Doss is specifiek met dit in gedachten ontworpen.

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

Zodra de ZSL 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 met een kernel-niveau scheduler gebouwd om de belasting van bursty ERP-werklasten aan te pakken. Bovendien hebben we een HTAP-databasesysteem gebouwd dat de belangrijkste onderdelen van een transactiedatabase zoals Postgres en de analytische capaciteiten van een Data Warehouse combineert.

Door het platform te bouwen met ondernemingsklasse sterkte vanaf het begin, is het systeem ingericht voor volledig agente distributie. Wat eerder maanden of jaren duurde om te doen, kan nu parallel worden uitgevoerd met 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 blind spots die ontstaan wanneer core bedrijfsgegevens niet worden verenigd in één bron van waarheid?

Het grootste probleem is dat beslissingen worden genomen op basis van verouderde of onvolledige informatie. Als uw voorraadgegevens op één plek leven, uw inkooporders op een andere en uw verkooporders op een derde, bent u altijd aan het reconciliëren, handmatig, langzaam en achteraf. Door de tijd dat iemand 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. Zij opereren in de detailhandel, groothandel, directe verkoop en cafes in de VS en Japan, maar beheerden alles via onverbonden systemen zonder real-time voorraadzichtbaarheid. Zij raakten hun eigen koffie kwijt op drukke locaties en hadden kritieke voorraadtekorten tijdens een grote retailerlancering 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 uw operaties verbergt. U kunt de relatie tussen een vertraging upstream en een leveringsprobleem downstream niet zien als die twee dingen in verschillende tools leven. U eindigt met het beheersen van symptomen, het versnellen van orders, het opbouwen van veiligheidsvoorraden en het uitvoeren van handmatige controles in plaats van te begrijpen wat er echt gebeurt. Een geünificeerd systeem bespaart niet alleen tijd op reconciliatie. Het verandert wat u überhaupt kunt zien en vragen stellen.

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

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

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

Er is een pervers stimulans in ERP-implementaties vandaag – hoe langer de implementatie duurt en hoe minder effectief het is, hoe meer geld de implementeerders ontvangen. De meeste bouwers zouden hier niet van profiteren; echter, ze worden nooit gestimuleerd om met tempo en kwaliteit te bewegen.

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

AI verandert de unit economics van dit geheel. In plaats van een consultantengagement is een DOSS-implementatie een codebase. Naarmate onze implementatiekosten blijven dalen, kunnen we de incentives uitlijnen met een “betaal bij levering”-model in plaats van “betaal zoals u 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 wereldwijde IT-dienstenuitgaven van $1,86 biljoen met agente implementatie en onderhoud met behulp van onze ZSL als taal voor bedrijfssoftware. Succes bij Doss is het commodificeren van alle bedrijfsapplicaties op grote schaal.

U 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 kruist met rommelige operationele gegevens?

De uitdaging ligt zelden bij de AI. Het is de gegevens waarover u het wilt laten redeneren.

Elk bedrijf waarmee we werken, heeft jarenlang operationele workarounds opgebouwd. De gegevens bestaan technisch gezien, maar ze wonen nergens waar hun werknemers, laat staan agente systemen, erop kunnen handelen.

Een goed voorbeeld is een Duitse meubelfabrikant die maatwerkstukken maakt. Toen we binnenkwamen, hadden ze 10 jaar historische gegevens verspreid over 8 aangepaste bestandsformaten met 11 verschillende gegevensobjecten en een 3PL-synchronisatie die handmatig werd gekopieerd 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 standaard schema voor dat. Ze moesten duizenden euro’s betalen elke keer dat ze eenvoudige configuratie-opties wilden wijzigen, 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 u kunt het niet volledig anticiperen totdat u in hun gegevens zit. De taak is om een nauwkeurige afdruk te maken van hoe het bedrijf werkelijk werkt, in plaats van hun gegevens in een generieke sjabloon te passen en te hopen dat het past.

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

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

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

Op de korte termijn zouden de propriëtaire modellen en agenten van Doss in staat moeten zijn om de kernen van technische consultants in de implementatie van bedrijfsapplicaties en die van managementconsultants in het leveren van strategische aanbevelingen te transformeren. Doss zal de grootste repository van gestructureerde en co-gelegen 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 specifieker dan dat. Het is in werk dat repetitief, regelgebaseerd is en momenteel door mensen wordt gedaan die andere, strategischere prioriteiten hebben: het verwerken van inkooporders, het reconciliëren van voorraad en het routeren van leveringsbeslissingen. Deze taken hebben goed gedefinieerde invoer en uitvoer, en AI kan ze betrouwbaar op grote schaal afhandelen.

Voor nu 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 besluitvorming in zijn geheel vervangen; het is agenten die het hoogvolume, goed gedefinieerde werk afhandelen zodat mensen zich kunnen concentreren op de beslissingen die werkelijk hun oordeel vereisen.

Veel ondernemingen proberen AI op bestaande software-stacks te leggen. Waarom faalt het retrofitten van legacy-systemen met AI vaak in vergelijking met het bouwen van AI rechtstreeks in de basis van het platform?

Legacy-systemen zijn niet gebouwd om door AI te worden geredeneerd. De datamodellen, API’s, de manier waarop informatie is gestructureerd, alles was ontworpen voor menselijke interactie via interfaces. Wanneer u AI hierop legt, vraagt u het om te werken rondom beperkingen waarvoor het niet is ontworpen.

Zelfs als u een MCP-server probeert toe te voegen, introduceert een MCP-server in werkelijkheid vaak grotere contextwindowbloat en blaast het de prestaties op.

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

Hoe ziet u de evolutie van traditionele ondernemingssoftware-interfaces met AI die workflows genereert en rechtstreeks met operationele systemen interacteert?

De interfacevraag gaat eigenlijk over wie het systeem moet gebruiken. 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.

Wat we bouwen, is een composable UI, die de interface behandelt als een websitebouwer. De interface zelf wordt ook ondersteund door de gesloten ZSL. Iedereen, de CFO, de magazijnmanager, de supply chain-analist, krijgt een dashboard en gegevensweergaven samengesteld rond hoe ze werkelijk werken, niet rond hoe de software was geconfigureerd. Naarmate AI meer van de onderliggende workflow-uitvoering afhandelt, wordt de interface minder over gegevensinvoer en meer over zichtbaarheid en besluitvorming. U moet zien wat er gebeurt, begrijpen waarom, en oordeelsvellingen maken. De software moet de rest afhandelen.

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

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

In ERP specifiek zijn ze ook beladen met bedrijfsbeslissingen die hen op een pad hebben gezet waarop de omzet wordt gedreven door specifieke functionaliteit die DOSS juist probeert te elimineren – professionele dienstenconsultants. Gezien de gebruikers negen dollar uitgeven aan consultants voor elke dollar die ze uitgeven aan de software zelf, is de mogelijkheid om 90% van hun bronomzet te transformeren onhoudbaar voor grote gevestigde partijen.

Een AI-native systeem kan vanaf het begin worden ontworpen zodat AI een onderdeel is van de core-architectuur, 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 worden capabeler met elke nieuwe klant. Die verbeteringslus bestaat niet in een systeem waar implementatie nog steeds een menselijke consultantengagement is.

Kijkend naar de toekomst, hoe ziet u AI de “besturingssysteem” 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 hebben DOSS opgericht met de overtuiging dat ondernemingssoftware zichzelf kan bouwen. Drie jaar later zijn we Phase 2 van Doss binnengegaan: de agente self-driving implementatie. Het platform kan al een klantsysteem genereren, valideren en evolueren in plaats van te vertrouwen op handmatige consultantconfiguratie, en het wordt beter met elke implementatie.

De richting waarin dit gaat, is een systeem dat altijd in sync is met het bedrijf. Vandaag is de kloof tussen hoe een bedrijf werkt 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 wanneer die kloof wordt gesloten, wanneer het systeem in real-time verandert naarmate het bedrijf verandert, 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 leveringsfout wordt. Geautomatiseerde operaties gaan niet alleen over efficiëntie; het is de mogelijkheid om een complexer bedrijf te runnen met hetzelfde team. Dat is de versie van operationssoftware die we naar toe bouwen.

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