Arnav Mishra, Co-Founder und CTO von Doss – Interviewreihe

Arnav Mishra, Co-Founder und CTO von Doss, ist ein Full-Stack-Entwickler und technischer Leiter mit einer Erfahrung, die von frühen Startups bis hin zu großen Infrastruktursystemen reicht. Vor der Gründung von Doss war er Gründungsingenieur bei Siteline, wo er Kernsysteme wie die Berechtigungsarchitektur, ERP-Integrationen und Automatisierungsframeworks aufbaute und auch zur Rekrutierung, Umsatzoperationen und Unternehmenskultur beitrug. Früher in seiner Karriere war er bei Rubrik und absolvierte Praktika bei Unternehmen wie Uber und VMware, wobei er Expertise in Cloud-Infrastruktur, Daten-systemen und Automatisierung erwarb. Neben seiner technischen Arbeit war er auch aktiv in Mentorings- und Talententwicklungsprogrammen von Organisationen wie Techquitable Futures und Contrary engagiert, was ein umfassenderes Engagement für die Unterstützung der nächsten Generation von Ingenieuren widerspiegelt.

Doss ist ein modernes Unternehmen für Unternehmenssoftware, das traditionelle ERP-Systeme durch seine Adaptive Resource Platform (ARP) neu erfinden will, eine flexible, künstliche Intelligenz-native Betriebsplattform, die darauf ausgelegt ist, Geschäftswerkzeuge zu vereinen und zu automatisieren. Als komponierbare Alternative zu herkömmlichen ERP-Lösungen ermöglicht Doss Unternehmen, Bestand, 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 Datenebene, Code-freie Workflows und Echtzeit-Analysen, sodass Unternehmen schnell bereitstellen, in bestehende Tools integrieren und ihre Betriebsabläufe ohne langwierige Implementierungen oder teure Berater kontinuierlich weiterentwickeln können.

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

Bevor ich zu DOSS kam, war ich Gründungsingenieur bei einem FinTech-Startup. Der Hauptgrund, warum unsere Käufer – CFOs, Buchhalter usw. – unsere Lösung nicht wählten, war, dass sie “zu beschäftigt mit der Implementierung eines ERPs” waren. Als ich tiefer in das archaische Land der ERP eintauchte, war ich schockiert über das bestehende Implementierungsmodell.

Was ich ständig 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 blockiert. 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. Sie können es nicht durch Patches beheben.

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

Kein modernes Technologieunternehmen 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 zu bauen.

DOSS positioniert sich als künstliche Intelligenz-native Betriebsplattform, die traditionelle ERP-Systeme wie SAP oder Oracle ersetzen soll. Welche grundlegenden architektonischen Unterschiede machen eine künstliche Intelligenz-native ERP heute möglich, die vor einem Jahrzehnt nicht machbar waren?

Oracle und SAP wurden in einer Ära entwickelt, in der sie, um eine maximale Verteilung zu erreichen, die Konfigurationsebene eines ERPs zu einer GUI-basierten Editor-Oberfläche vereinfachen mussten, die relative nicht-technische Berater im großen Maßstab bereitstellen konnten. Um Best Practices zu bewahren, sperrten sie große Teile der Kernsysteme und erlaubten nur an den Rändern Komposition. In Wirklichkeit jedoch benötigen die Geschäftsanwendungen der meisten Unternehmen maximale Flexibilität.

Was die künstliche Intelligenz ermöglicht, ist die Umwandlung der Software-Entwicklung von einem Handwerk zu einer industrialisierten Maschine. Wir benötigen keine Software-Künstler mehr, um Code-Systeme von Hand zu erstellen; stattdessen bewegen wir uns in eine Welt, in der die Software-Ausgabe ein Faktor von Rechenleistung und Token ist.

Doss wurde genau mit diesem Ziel im Blickwinkel entwickelt.

Wir bauten die ZSL, eine deklarative domänen-spezifische Sprache (DSL), die die gesamte DOSS-Implementierung eines Kunden in Code beschreibt. Denken Sie daran, was “Terraform” für den Infrastructure-as-Code-Einsatz geleistet hat, aber stattdessen auf die Geschäftsanwendungslogik angewendet. Durch die Definition von ERPs in einer relativ niedrig-dimensionalen 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 Implementierungen von schlechter Qualität erstellen. Unser Team hat ein skalierbares verteiltes System mit einem Kernel-Scheduler erstellt, um die Last von bursty ERP-Workloads zu bewältigen. Darüber hinaus bauten wir ein HTAP-Datenbank-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-Stärke aufbauten, ist das System für eine vollständig agentische Verteilung ausgelegt. Was früher Teams von Beratern Monate oder Jahre gekostet hat, kann jetzt parallelisiert und im großen Maßstab mithilfe agentischer Infrastruktur in unserem proprietären Closed-Loop-System durchgeführt werden.

Viele Unternehmen verlassen sich immer noch auf Tabellenkalkulationen und fragmentierte Werkzeuge für Beschaffung, Bestandsverwaltung und Auftragsmanagement. Welche größten operativen Blindstellen entstehen, wenn Kerngeschäftsdaten nicht in einer einzigen Wahrheitsquelle vereint sind?

Das größte Problem ist, dass Entscheidungen auf der Grundlage veralteter oder unvollständiger Informationen getroffen werden. Wenn Ihre Bestandsdaten an einem Ort, Ihre Bestellungen an einem anderen und Ihre Verkaufsaufträge an einem dritten Ort gespeichert sind, müssen Sie ständig manuell abgleichen, langsam und nachträglich. Sobald jemand bemerkt, dass der Bestand 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 fehlschlägt. Sie betreiben Operationen in den Bereichen Lebensmittel, Großhandel, Direktvertrieb und Cafes in den USA und Japan, aber verwalteten all dies über nicht verbundene Systeme ohne Echtzeit-Bestandsüberwachung. Sie gingen aus ihrem eigenen Kaffee bei hoch frequentierten Standorten aus und erlebten kritische Lagerengpässe während eines großen Einzelhandelsstarts, der 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 Werkzeugen leben. Sie enden damit, Symptome zu verwalten, Aufträge zu beschleunigen, Sicherheitsbestände aufzubauen und manuelle Kontrollen durchzuführen, anstatt zu verstehen, was tatsächlich passiert. Ein vereintes System spart nicht nur Zeit für die Abgleichung; es verändert, was Sie überhaupt sehen und fragen können.

Im Kern stellen Sie sich vor, ein Unternehmen ohne Zugriff auf ein Versionskontrollsystem (Git), ein Überwachungstool (DataDog) oder eine zentrale Datenbank, um Informationen abzufragen.

ERP-Implementierungen erforderten historisch große Beraterteams und Monate – oder sogar Jahre – der Bereitstellung. Wie verändert künstliche Intelligenz die Ökonomie und Komplexität der Implementierung von Betriebssoftware in realen Unternehmen?

Das traditionelle Implementierungsmodell ist das emergente Ergebnis von jahrzehntealten 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 Möglichkeit profitieren; jedoch werden sie nie dazu angeregt, mit Geschwindigkeit und Qualität voranzuschreiten.

Darüber hinaus beträgt das Verhältnis von Beratungsausgaben zu Software-Ausgaben in einer traditionellen ERP-Verpflichtung ungefähr 9:1, sodass Sie für jeden Dollar, den Sie für die Software selbst ausgeben, neun Dollar für Berater ausgeben. Für ein großes Unternehmen ist das extrem schmerzhaft. Für mittelständische Unternehmen ist es prohibitiv. Sie entscheiden sich entweder für eine Software, die nicht wirklich der Art und Weise entspricht, wie sie operieren, verzögern das Projekt oder geben es auf halbem Weg auf.

Künstliche Intelligenz verändert die Einheitskosten hierbei vollständig. Anstatt einer Beratungsverpflichtung ist eine DOSS-Implementierung ein Codebasis. Da unsere Implementierungszeiten weiterhin sinken, können wir Anreize mit einem “Pay-on-Delivery”-Modell anstelle von “Pay-as-you-go” ausrichten. Wenn sich das Unternehmen ändert, ändert sich das System mit. Die Notwendigkeit für Räume voller Berater und lange Präsentationen ist nicht mehr relevant.

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

Sie haben DOSS bei Unternehmen mit realen Umgebungen wie Fertigung, Logistik und Konsumgütern bereitgestellt. Welche unerwarteten Herausforderungen entstehen, wenn künstliche Intelligenz auf unordentliche Betriebsdaten trifft?

Die Herausforderung liegt selten bei der künstlichen Intelligenz. Es liegt in den Daten, über die sie nachdenken soll.

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

Ein gutes Beispiel ist ein deutscher Möbelhersteller, der maßgefertigte Stücke erstellt. Als wir kamen, hatten sie 10 Jahre historischer Daten über 8 benutzerdefinierte Dateiformate mit 11 verschiedenen Datenobjekten und einer 3PL-Synchronisierung, die über manuelles Kopieren und Einfügen aus FTP-Ordner lief. Die Geschäftslogik war spezifisch mit benutzerdefinierten Dimensionen, Konfigurationen, Zahlungsmethoden und Showroom-Standorten, und das gesamte System musste auf Deutsch funktionieren. Es gibt kein Standard-Schema dafür. Sie mussten jedes Mal Tausende von Euros zahlen, wenn sie einfache Konfigurationsparameter wie den Status von Bestellungen ändern wollten.

Die Herausforderung liegt nicht in der technischen Komplexität eines einzelnen Teils. Es liegt darin, 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, eine genaue Kopie 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 in der realen Welt funktioniert, benötigen Sie eine Plattform mit maximaler Flexibilität. Erst dann kann künstliche Intelligenz nützlich sein, um das zugrunde liegende Datenmodell zu verstehen, auf dem sie basiert, und das Modell zu erstellen, das für jeden Kunden funktioniert.

Es gibt viel Diskussion über künstliche Intelligenz-Co-Piloten und autonome Agenten in Geschäftsanwendungssoftware. Wo sehen Sie die künstliche Intelligenz mit dem größten Mehrwert in operativen Workflows heute, und wo bleibt menschliche Aufsicht unerlässlich?

Im großen Maßstab hat künstliche Intelligenz die Fähigkeit, alle operativen Arbeiten zu durchbrechen.

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 kohärenter Daten haben, die sowohl Schema- als auch Betriebsinformationen für Unternehmen darstellen. Unsere Agenten können diese Daten nutzen, um skalierbare Empfehlungen zu liefern.

Der klarste Mehrwert 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 Beständen und Routen von Erfüllungsentscheidungen. Diese Aufgaben haben gut definierte Eingaben und Ausgaben, und künstliche Intelligenz kann sie zuverlässig im großen Maßstab durchführen.

Für den Moment ist menschliche Aufsicht dort unerlässlich, wo der Kosten einer falschen Entscheidung hoch ist und das System noch nicht genug Kontext hat, um sich sicher zu sein. Heute ist das richtige Modell nicht autonome Agenten, die menschliches Entscheiden vollständig ersetzen; es sind Agenten, die die hochvolumigen, gut definierten Arbeiten durchführen, damit Menschen sich auf Entscheidungen konzentrieren können, die tatsächlich ihr Urteil erfordern.

Viele Unternehmen versuchen, künstliche Intelligenz auf ihre bestehenden Software-Stacks aufzuschichten. Warum funktioniert das Aufschichten von Legacy-Systemen mit künstlicher Intelligenz oft nicht im Vergleich zum direkten Einbau in die Grundlage der Plattform?

Legacy-Systeme wurden nicht dafür gebaut, von künstlicher Intelligenz durchdacht zu werden. Die Datenmodelle, die APIs, die Art und Weise, wie Informationen strukturiert sind, all dies wurde für menschliche Interaktionen durch Schnittstellen konzipiert. Wenn Sie künstliche Intelligenz darauf aufschichten, fordern Sie sie auf, innerhalb von Einschränkungen zu arbeiten, für die sie nicht konzipiert war.

Selbst wenn Sie versuchen, einen MCP-Server darüber zu legen, benötigt ein MCP-Server in der Realität extrem spezifische Designmuster. Die meisten MCP-Server heute führen tatsächlich zu einem größeren Kontextfenster-Überlauf und verursachen Leistungsprobleme.

Das tiefer liegende Problem ist jedoch das Implementierungsmodell. In einem traditionellen ERP wird die Konfiguration des Systems im System selbst gespeichert. Es ist kein Code, den Sie lesen, testen oder versionieren können. 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 eine ordnungsgemäße Codebasis ist: lesbar, testbar und in einem geschlossenen System bereitstellbar. Wir bauen einen vollständig agentischen Software-Entwicklungslebenszyklus (SDLC) auf. Das ist die Voraussetzung dafür, dass künstliche Intelligenz tatsächlich auf dem System operieren kann, anstatt nur darauf zu sitzen.

Wie Sie denken, dass die traditionellen Schnittstellen von Unternehmenssoftware sich entwickeln, wenn künstliche Intelligenz in der Lage ist, Workflows zu generieren und direkt mit operativen Systemen zu interagieren?

Die Frage der Schnittstelle ist wirklich darüber, wer das System verwenden muss. Derzeit sind ERP-Schnittstellen um eine kleine Gruppe von Power-Usern herum gebaut, die Personen, 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 bauen, ist eine komponierbare Benutzeroberfläche, die die Schnittstelle wie einen Website-Builder behandelt. Die Schnittstelle selbst wird auch durch den geschlossenen ZSL-Loop 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 künstliche Intelligenz mehr und mehr 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 Urteile fällen. Die Software sollte den Rest übernehmen.

Startups wie DOSS treten in einen Markt ein, der von jahrzehntealten etablierten Unternehmen dominiert wird. Welche Vorteile haben künstliche Intelligenz-Startups, wenn sie gegen etablierte Unternehmensplattformen konkurrieren?

Die etablierten Unternehmen haben das Gegenteil von dem, was Startups haben. Sie haben enorme installierte Basis, die sie schützen müssen. Jede architektonische Entscheidung, die sie treffen, muss abwärtskompatibel sein. Sie können künstliche Intelligenz-Features zu bestehenden Produkten hinzufügen, aber sie können die zugrunde liegenden Systeme nicht neu aufbauen, ohne alles zu zerstören, was darauf läuft. Das ist kein Mangel an Ehrgeiz; es ist strukturell.

Im speziellen Fall von ERP sind sie auch mit Geschäftsentscheidungen belastet, die sie auf einen Weg geführt haben, den DOSS zu eliminieren sucht – professionelle Dienstleistungsberater. Angesichts der Tatsache, 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 nicht tragbar.

Ein künstliche Intelligenz-natives System kann von Anfang an so konzipiert werden, dass künstliche Intelligenz Teil der Kernarchitektur ist, nicht eine Schicht darüber. Das Implementierungsmodell, das Datenmodell und die Art und Weise, wie Konfiguration funktioniert, sind alle für künstliche Intelligenz als erste Klasse-Teilnehmer konzipiert. Das ist ein kumulativer Vorteil, bei dem jede Bereitstellung das System besser macht und die Implementierungsagenten mit jedem neuen Kunden leistungsfähiger werden. Diese Art von Verbesserungsschleife existiert nicht in einem System, in dem die Implementierung immer noch eine menschliche Beratungsverpflichtung ist.

Auf lange Sicht, wie Sie die künstliche Intelligenz die “Betriebssysteme” eines Unternehmens in den nächsten fünf bis zehn Jahren transformieren, insbesondere in Bereichen wie Lieferketten-Transparenz, Echtzeit-Entscheidungsfindung und automatisierte Betriebe?

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: die agentische Selbstfahrfähigkeit der Implementierung. Die Plattform kann bereits generieren, validieren und die Systeme eines Kunden weiterentwickeln, anstatt sich auf manuelle Beraterkonfiguration zu verlassen, 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 liegt die Lücke zwischen der Art und Weise, wie ein Unternehmen operiert, und dem, was die Software darüber weiß, bei Monaten oder Jahren. 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 von Betriebsfähigkeit. Echtzeit-Transparenz ist nicht nur schnelleres Berichten; es ist die Fähigkeit, eine Lieferkettenunterbrechung zu erkennen, bevor sie zu einem Erfüllungsfehler wird. Automatisierte Betriebe sind nicht nur effizienter; es ist die Fähigkeit, ein komplexeres Unternehmen mit dem gleichen Team zu führen. Das ist die Version von Betriebssoftware, auf die wir hinarbeiten.

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