Arnav Mishra, Mitgründer und CTO von Doss – Interview-Serie

Arnav Mishra, Mitgründer und CTO von Doss, ist ein Full-Stack-Entwickler und technischer Leiter mit einer Erfahrung, die von Start-ups im Frühstadium bis hin zu groß angelegten Infrastruktursystemen reicht. Bevor er Doss mitgründete, war er Gründungsingenieur bei Siteline, wo er Kernsysteme wie Berechtigungsarchitektur, ERP-Integrationen und Automatisierungsframeworks aufbaute und auch zur Rekrutierung, Revenue-Operationen und Firmenkultur beitrug. In seiner früheren Karriere war er bei Rubrik und absolvierte Praktika bei Unternehmen wie Uber und VMware, wo er Expertise in Cloud-Infrastruktur, Daten-Systemen und Automatisierung erwarb. Neben seiner technischen Arbeit war er auch aktiv in Mentorship und Talent-Entwicklung bei Organisationen wie Techquitable Futures und Contrary engagiert, was seine breitere Verpflichtung zur Unterstützung der nächsten Generation von Ingenieuren widerspiegelt.

Doss ist ein modernes Unternehmen für Unternehmenssoftware, das sich auf die Neuerfindung traditioneller ERP-Systeme durch seine Adaptive Resource Platform (ARP) konzentriert, eine flexible, AI-nativen Operationsplattform, die darauf ausgelegt ist, Geschäftsprozesse zu vereinen und zu automatisieren. Als komponierbare Alternative zu herkömmlichen ERP-Lösungen ermöglicht Doss es Unternehmen, Inventar, Beschaffung, Finanzen und Erfüllung innerhalb eines einzigen Systems zu verwalten, das sich an reale Betriebsabläufe anpasst, anstatt starre Prozesse aufzuzwingen. Die Plattform kombiniert eine zentrale Daten-Ebene, No-Code-Workflows und Echtzeit-Analytics, was es Unternehmen ermöglicht, schnell zu deployen, sich mit bestehenden Tools zu integrieren und ihre Betriebsabläufe kontinuierlich zu entwickeln, ohne langwierige Implementierungen oder teure Berater.

Die Motivation, DOSS aufzubauen, geht auf die Erfahrungen von Wiley zurück, der beobachtete, wie Legacy-Software das Unternehmen seines Vaters behinderte, und später ähnliche Probleme selbst bei der Arbeit mit Fabriken und Hardware-Lieferketten erlebte. Wie haben diese Erfahrungen Ihre Entscheidung beeinflusst, DOSS zu gründen und ERP-Systeme von Grund auf neu zu denken?

Bevor DOSS, war ich Gründungsingenieur bei einem FinTech-Start-up. Der Grund Nummer eins, warum unsere Käufer – CFOs, Buchhalter usw. – nicht unsere Lösung wählten, war, dass sie “zu beschäftigt waren, ein ERP zu implementieren”. Als ich tiefer in die archaische Welt von ERP eintauchte, war ich von dem bestehenden Implementierungsmodell schockiert.

Was ich immer wieder sah, war das gleiche grundlegende Versagen: Die Implementierung dauert Monate oder Jahre, kostet Hunderttausende bis Millionen von Dollar und wird vollständig von menschlichen Beratern mit stündlichen Abrechnungen gebremst. Sobald das ERP ausgeliefert wird, hört es auf, sich zu ändern. Das Unternehmen entwickelt sich weiter; das System nicht. Das ist ein architektonisches Problem, kein Konfigurationsproblem. Man kann es nicht durch Patches beheben.

Als Software-Entwickler konnte ich mir am nächsten vergleichbaren Szenario vorstellen: Stellen Sie sich eine Welt vor, in der das wichtigste Werkzeug, das Sie als Entwickler verwenden – sagen wir GitHub – speziell für Ihr Unternehmen über Jahre von einer externen Beratungsagentur aufgebaut wurde. Dann, sobald das Produkt fertig ist, verlassen die Berater mit keiner Wartung, keiner Funktionsverbesserung und keiner Unterstützung. Ingenieure würden revoltieren.

Kein modernes Technologie-Unternehmen kann in diesem Modell operieren. Wiley und ich kamen beide zu dem gleichen Schluss: Der einzige Weg, es zu beheben, war, von Grund auf neu aufzubauen.

DOSS positioniert sich als AI-nativen Operationsplattform, die traditionelle ERP-Systeme wie SAP oder Oracle (ORCL ) ersetzen soll. Welche grundlegenden architektonischen Unterschiede machen ein AI-nativen ERP heute möglich, was vor einem Jahrzehnt nicht möglich war?

Oracle und SAP wurden in einer Ära aufgebaut, in der sie, um maximale Verteilung zu erreichen, die Konfigurations-Ebene eines ERP zu einem GUI-basierten Editor vereinfachen mussten, den relative nicht-technische Berater liefern konnten. Um Best-Practices zu bewahren, sperrten sie große Teile der Kernsysteme und erlaubten nur Komponierbarkeit an den Rändern. In Wirklichkeit jedoch benötigen die Geschäftsanwendungen aller Unternehmen maximale Flexibilität.

Die AI-nativen Welt ermöglicht die Transformation der Software-Entwicklung von einem Handwerk zu einer industrialisierten Maschine. Man benötigt keine Software-Künstler mehr, um Code-Systeme von Hand zu erstellen; stattdessen bewegen wir uns in eine Welt, in der Software-Durchsatz ein Faktor von Rechenleistung und Token ist.

Doss wurde genau mit diesem Ziel im Sinn aufgebaut.

Wir bauten die ZSL, eine deklarative Domain-Specific Language (DSL), die die gesamte DOSS-Implementierung eines Kunden in Code beschreibt. Denken Sie daran, was “Terraform” für die Infrastructure-as-Code-Bemühungen getan hat, aber stattdessen auf Geschäftsanwendungslogik angewendet. Durch die Beschreibung von ERPs in einer relativ niedrigdimensionalen Programmiersprache können wir Agenten im großen Maßstab bereitstellen, um ERP-Lösungen zu liefern.

Sobald die ZSL geschrieben war, war der wichtigste Teil der Architektur, Best-Practices in die Plattform selbst zu integrieren, um zu verhindern, dass Agenten qualitativ schlechte Implementierungen aufbauen. Unser Team hat ein skalierbares verteiltes System mit einem Kernel-Level-Scheduler entwickelt, um die Last von bursty ERP-Workloads zu bewältigen. Darüber hinaus bauten wir ein HTAP-Database-System, das die wichtigsten Teile einer transaktionalen Datenbank wie Postgres und die analytischen Fähigkeiten eines Data-Warehouse kombiniert.

Indem wir die Plattform von Anfang an mit Enterprise-gradiger Stärke aufgebaut haben, ist das System für eine vollständig agentische Verteilung konfiguriert. Was früher Teams von Beratern Monate oder Jahre gekostet hat, kann jetzt parallelisiert werden, indem agentische Infrastruktur in unserem proprietären Closed-Loop-System verwendet wird.

Viele Unternehmen verlassen sich immer noch auf Tabellenkalkulationen und fragmentierte Tools für Beschaffung, Inventar und Auftragsmanagement. Welche größten operativen Blindspots entstehen, wenn Kern-Geschäftsdaten nicht in einer einzigen Wahrheitsquelle vereinigt werden?

Das größte Problem ist, dass Entscheidungen auf der Grundlage veralteter oder unvollständiger Informationen getroffen werden. Wenn Ihre Inventardaten an einem Ort leben, Ihre Bestellungen an einem anderen und Ihre Verkaufsaufträge an einem dritten, müssen Sie immer manuell abgleichen, langsam und nachträglich. Sobald jemand bemerkt, dass das Inventar falsch ist oder ein Lieferant im Rückstand ist, ist es bereits ein Problem im Geschäft.

Verve Coffee Roasters ist ein gutes Beispiel dafür, wo dies in der Praxis zusammenbricht. Sie betreiben Operationen in den Bereichen Einzelhandel, Großhandel, DTC und Cafes in den USA und Japan, aber verwalteten all dies in getrennten Systemen ohne Echtzeit-Inventar-Sichtbarkeit. Sie liefen aus ihrem eigenen Kaffee in hoch frequentierten Standorten aus und hatten bei einem großen Einzelhändler-Start kritische Lagerbestände, was eine wichtige Einzelhandelsbeziehung schädigte. Die Daten existierten irgendwo; sie waren nur nicht so verbunden, dass jemand darauf reagieren konnte.

Das subtilere Problem ist, dass Fragmentierung die wahre Form Ihrer Betriebsabläufe versteckt. Sie können die Beziehung zwischen einer Verzögerung stromaufwärts und einem Erfüllungsproblem stromabwärts nicht sehen, wenn diese beiden Dinge in getrennten Tools leben. Sie enden damit, Symptome zu managen, Bestellungen zu beschleunigen, Sicherheitsbestände aufzubauen und manuelle Kontrollen durchzuführen, anstatt zu verstehen, was tatsächlich passiert. Ein vereinigtes System spart nicht nur Zeit bei der Abgleichung; es ändert, was Sie überhaupt sehen und fragen können.

Im Kern ist es, als ob Sie ein Unternehmen ohne Zugriff auf ein Versionssystem (Git), ein Observability-Tool (DataDog) oder eine zentrale Datenbank, um Informationen abzufragen, führen würden.

ERP-Implementierungen haben historisch gesehen große Beraterteams und Monate – oder sogar Jahre – der Bereitstellung erfordert. Wie verändert AI die Ökonomie und Komplexität der Implementierung von operativer Software in realen Unternehmen?

Das traditionelle Implementierungsmodell ist das emergente Ergebnis von Generationen alten Software-Praktiken. Wir leben nicht mehr in dieser Welt.

Es gibt eine perverse Anreizstruktur in ERP-Implementierungen heute – je länger eine Implementierung dauert und je weniger effektiv sie ist, desto mehr Geld erhalten die Implementierer. Die meisten Erbauer würden nicht von dieser Anreizstruktur profitieren; jedoch werden sie nie dazu angeregt, mit Tempo und Qualität zu arbeiten.

Darüber hinaus beträgt das Verhältnis von Beratungsausgaben zu Software-Ausgaben in einer traditionellen ERP-Verpflichtung etwa 9:1, sodass Sie neun Dollar für Berater für jeden Dollar ausgeben, den Sie für die Software selbst ausgeben. Für ein großes Unternehmen ist das extrem schmerzhaft. Für mittelständische Unternehmen ist es prohibitiv. Sie entscheiden sich daher entweder für eine Software, die nicht wirklich ihren Betrieb abbildet, verzögern das Projekt oder brechen es teilweise ab.

AI verändert die Einheitskosten hierbei vollständig. Anstatt einer Beratungsverpflichtung ist eine DOSS-Implementierung ein Codebase. Wenn unsere Implementierungszeiten weiter schrumpfen, können wir Anreize mit einem “Pay-on-Delivery”-Modell anstelle von “Pay-as-you-go” ausrichten. Wenn das Geschäft sich ändert, ändert sich das System mit. Die Notwendigkeit von Beraterräumen und langen Präsentationen ist nicht mehr relevant.

Erfolg bei Doss bedeutet, den 1,86-Billionen-Dollar-Global-IT-Dienstleistungsmarkt durch agentische Implementierung und Wartung mit unserer ZSL als Sprache für Geschäftsanwendungs-Software zu ersetzen. Erfolg bei Doss bedeutet, alle Geschäftsanwendungen im großen Maßstab zu kommodifizieren.

Sie haben DOSS mit Unternehmen in realen Umgebungen wie Fertigung, Logistik und Konsumgütern eingesetzt. Welche unerwarteten Herausforderungen entstehen, wenn AI auf unordentliche operationale Daten trifft?

Die Herausforderung liegt selten bei der AI. Es ist die Daten, über die sie nachdenken soll.

Jedes Unternehmen, mit dem wir zusammenarbeiten, hat über Jahre hinweg operationale Workarounds angesammelt. Die Daten existieren technisch; sie leben nur nicht an einem Ort, an dem ihre Mitarbeiter, geschweige denn agentische Systeme, darauf zuverlässig reagieren können.

Ein gutes Beispiel ist ein deutscher Möbelhersteller, der maßgefertigte Stücke herstellt. Als wir hereinkamen, hatten sie 10 Jahre historische Daten, die über 8 benutzerdefinierte Dateiformate mit 11 verschiedenen Datenobjekten und einer 3PL-Synchronisierung, die über manuelles Kopieren aus FTP-Ordner läuft, verteilt waren. Die Geschäftslogik war spezifisch mit benutzerdefinierten Dimensionen, Konfigurationen, Zahlungsmethoden und Showroom-Standorten, und das gesamte System musste auf Deutsch funktionieren. Es gibt kein vorgefertigtes Schema dafür. Sie mussten jedes Mal, wenn sie einfache Konfigurations-Optionen ändern wollten, wie z.B. den Status einer Bestellung, Tausende von Euros zahlen.

Die Herausforderung ist nicht die technische Komplexität eines einzelnen Teils. Es ist, dass jedes Unternehmen eine andere Version dieses Problems hat, und Sie können es nicht vollständig vorhersehen, bis Sie in ihren Daten sind. Die Aufgabe ist, einen genauen Abdruck davon zu erstellen, wie das Unternehmen tatsächlich operiert, und nicht, ihre Daten in ein generisches Template zu übertragen und zu hoffen, dass es passt.

Um eine Lösung zu bauen, die für die reale Welt funktioniert, benötigen Sie eine Plattform mit maximaler Flexibilität. Nur dann kann AI nützlich sein, um das zugrunde liegende Datenmodell zu verstehen, auf dem es arbeitet, und das Modell zu bauen, das für jeden Kunden funktioniert.

Es gibt viel Diskussion über AI-Copiloten und autonome Agenten in Geschäftsanwendungen. Wo sehen Sie AI am meisten Wert in operativen Workflows heute, und wo bleibt menschliche Aufsicht noch unerlässlich?

In großem Maßstab hat AI die Fähigkeit, alle operativen Arbeiten zu stören.

Im Nahbereich sollten die proprietären Modelle und Agenten von Doss in der Lage sein, die Kerne von technischen Beratern bei der Implementierung von Geschäftsanwendungen sowie die von Management-Beratern bei der Lieferung strategischer Empfehlungen zu transformieren. Doss wird das größte Repository strukturierter und kollozierter Daten haben, die sowohl Schema als auch operationale Informationen für Unternehmen darstellen. Unsere Agenten können diese Daten verwenden, um skalierbare Empfehlungen zu liefern.

Der klarste Wert heute ist spezifischer als das. Es liegt in Arbeiten, die repetitiv, regelbasiert und derzeit von Menschen durchgeführt werden, die andere, strategischere Prioritäten haben: Verarbeitung von Bestellungen, Abgleich von Inventar und Routen von Erfüllungsentscheidungen. Diese Aufgaben haben gut definierte Eingaben und Ausgaben, und AI kann sie zuverlässig im großen Maßstab bewältigen.

Für jetzt ist menschliche Aufsicht dort unerlässlich, wo der Kosten eines falschen Entscheids hoch ist und das System noch nicht genug Kontext hat, um sich sicher zu sein. Heute ist das richtige Modell nicht autonome Agenten, die menschliche Entscheidungsfindung vollständig ersetzen; es sind Agenten, die die hochvolumigen, gut definierten Arbeiten übernehmen, damit Menschen sich auf die Entscheidungen konzentrieren können, die tatsächlich ihre Urteilsfähigkeit erfordern.

Viele Unternehmen versuchen, AI auf bestehende Software-Stacks aufzuschichten. Warum funktioniert das Retrofitting von Legacy-Systemen mit AI oft nicht so gut wie das Aufbauen von AI direkt in die Grundlage der Plattform?

Legacy-Systeme wurden nicht dafür gebaut, von AI durchdacht zu werden. Die Datenmodelle, die APIs, die Art und Weise, wie Informationen strukturiert sind, all dies wurde für menschliche Interaktionen durch Schnittstellen entworfen. Wenn Sie AI darauf aufschichten, bitten Sie es, um Einschränkungen herumzuarbeiten, für die es nicht gedacht war.

Sogar wenn Sie versuchen, einen MCP-Server darauf zu setzen, führt dies in der Realität zu einem größeren Kontextfenster-Overhead und verschlechtert die Leistung. Die tiefere Problematik ist das Implementierungsmodell. In einem traditionellen ERP ist die Konfiguration des Systems im System selbst gespeichert. Es ist kein Code, den man lesen, testen oder versionieren kann. Es gibt keine Möglichkeit für einen Agenten, zu verstehen, was das System tut, geschweige denn es sicher zu ändern. Wir bauten die ZSL speziell, damit die Konfiguration ein ordentlicher Codebase ist: lesbar, testbar und deploybar in einem Closed-Loop-System. Wir bauen einen vollständig agentischen Software-Entwicklungslebenszyklus (SDLC) auf. Das ist die Voraussetzung dafür, dass AI tatsächlich auf dem System arbeiten kann, anstatt nur darauf zu sitzen.

Wie sehen Sie die Zukunft der traditionellen Unternehmenssoftware-Schnittstellen, wenn AI in der Lage ist, Workflows zu generieren und direkt mit operativen Systemen zu interagieren?

Die Schnittstellen-Frage ist wirklich darüber, wer das System verwenden muss. Derzeit sind ERP-Schnittstellen um eine kleine Gruppe von Power-Usern herum aufgebaut, die Menschen, die während der Implementierung auf das System trainiert wurden. Jeder andere kann es entweder nicht verwenden oder erhält eine abgegradete Version davon.

Was wir aufbauen, ist eine komponierbare Benutzeroberfläche, die die Schnittstelle wie einen Website-Builder behandelt. Die Schnittstelle selbst wird auch durch die geschlossene ZSL unterstützt. Jeder – der CFO, der Lagerverwalter, der Supply-Chain-Analyst – erhält ein Dashboard und Datenansichten, die um ihre tatsächliche Arbeitsweise komponiert sind, nicht um die Konfiguration der Software. Wenn AI mehr von der zugrunde liegenden Workflow-Ausführung übernimmt, wird die Schnittstelle weniger zur Dateneingabe und mehr zur Sichtbarkeit und Entscheidungsfindung. Sie müssen sehen, was passiert, verstehen, warum, und Urteilsentscheidungen treffen. Die Software sollte den Rest übernehmen.

Start-ups wie DOSS treten in einen Markt ein, der von Jahrzehnte alten etablierten Unternehmen dominiert wird. Welche Vorteile haben AI-nativen Start-ups, wenn sie gegen etablierte Unternehmensplattformen konkurrieren?

Die etablierten Unternehmen haben das gegenteilige Problem von Start-ups. Sie haben enorme installierte Basis, die sie schützen müssen. Jede architektonische Entscheidung, die sie treffen, muss rückwärts kompatibel sein. Sie können AI-Funktionen zu bestehenden Produkten hinzufügen, aber sie können die zugrunde liegenden Systeme nicht ohne alles zu brechen, was darauf läuft, neu aufbauen. Das ist kein Mangel an Ehrgeiz; es ist strukturell.

In ERP speziell sind sie auch mit Geschäftsentscheidungen beladen, die sie auf einen Pfad geführt haben, auf dem ihr Umsatz durch spezifische Funktionen getrieben wird, die DOSS genau zu eliminieren sucht – professionelle Dienstleistungsberater. Angesichts dessen, dass Benutzer neun Dollar für Berater für jeden Dollar ausgeben, den sie für die Software selbst ausgeben, ist die Fähigkeit, 90 % ihres Quellumsatzes zu transformieren, für große etablierte Unternehmen unerreichbar.

Ein AI-natives System kann von Anfang an so konzipiert werden, dass AI Teil der Kernarchitektur ist, nicht eine Schicht darauf. Das Implementierungsmodell, das Datenmodell und die Art und Weise, wie Konfiguration funktioniert, sind alle so konzipiert, dass AI ein erster Klassenteilnehmer ist. Das ist ein Vorteil, der sich verdoppelt, wo jede Bereitstellung das System besser macht und die Implementierungsagenten mit jedem neuen Kunden fähiger werden. Diese Art von Verbesserungsschleife existiert nicht in einem System, in dem die Implementierung immer noch eine menschliche Beratungsverpflichtung ist.

Wenn Sie in die Zukunft blicken, wie sehen Sie AI die “Betriebssysteme” eines Unternehmens in den nächsten fünf bis zehn Jahren transformieren, insbesondere in Bereichen wie Lieferketten-Transparenz, Echtzeit-Entscheidungsfindung und automatisierte Betriebsabläufe?

Wir gründeten DOSS auf der Überzeugung, dass Unternehmenssysteme sich selbst aufbauen können. Drei Jahre später sind wir in Phase 2 von Doss eingetreten: der agentischen Selbstfahrfunktion. Die Plattform kann bereits eine Kunden-System-Generierung, -Validierung und -Evolution durchführen, anstatt auf manuelle Berater-Konfiguration zu setzen, und sie wird mit jeder Bereitstellung besser.

Die Richtung, in die dies führt, ist ein System, das immer im Einklang mit dem Unternehmen steht. Heute ist die Lücke zwischen dem, wie ein Unternehmen operiert, und dem, was die Software darüber weiß, Monate oder Jahre. Das System wurde zu einem bestimmten Zeitpunkt konfiguriert und hat sich seitdem nicht geändert. Was möglich wird, wenn diese Lücke geschlossen wird, wenn das System in Echtzeit mit dem Unternehmen ändert, ist eine andere Kategorie operativer Fähigkeiten. Echtzeit-Transparenz ist nicht nur schnelleres Berichten; es ist die Fähigkeit, eine Lieferketten-Unterbrechung zu erkennen, bevor sie zu einem Erfüllungsfehler wird. Automatisierte Betriebsabläufe sind nicht nur effizienter; es ist die Fähigkeit, ein komplexeres Unternehmen mit dem gleichen Team zu führen. Das ist die Version der Betriebssystem-Software, auf die wir hinarbeiten.

Vielen Dank für Ihre detaillierten Antworten. Leser, die mehr erfahren möchten, sollten Doss besuchen.