Entretiens
Arnav Mishra, Co-Fondateur et CTO de Doss – Série d’entretiens
Arnav Mishra, Co-Fondateur et CTO de Doss, est un ingénieur full-stack et un leader technique avec une expérience qui s’étend des startups en démarrage aux systèmes d’infrastructure à grande échelle. Avant de co-fonder Doss, il était l’un des premiers ingénieurs de Siteline, où il a construit des systèmes de base, notamment l’architecture des autorisations, les intégrations ERP et les cadres d’automatisation, tout en contribuant au recrutement, aux opérations de revenu et à la culture d’entreprise. Plus tôt dans sa carrière, il a occupé des postes d’ingénieur chez Rubrik et a effectué des stages dans des entreprises comme Uber et VMware, développant une expertise dans les infrastructures cloud, les systèmes de données et l’automatisation. Parallèlement à son travail technique, il a été activement impliqué dans le mentorat et le développement des talents à travers des organisations comme Techquitable Futures et Contrary, reflétant un engagement plus large pour soutenir la prochaine génération d’ingénieurs.
Doss est une entreprise de logiciels d’entreprise modernes qui se concentre sur la réinvention des systèmes ERP traditionnels grâce à sa plate-forme de ressources adaptatives (ARP), une plate-forme d’exploitation flexible et native AI conçue pour unifier et automatiser les flux de travail commerciaux. Conçue comme une alternative composable aux solutions ERP legacy, Doss permet aux entreprises de gérer l’inventaire, les achats, les finances et les livraisons dans un seul système qui s’adapte aux opérations du monde réel plutôt que de forcer des processus rigides. Sa plate-forme combine une couche de données centralisée, des flux de travail sans code et des analyses en temps réel, permettant aux entreprises de déployer rapidement, d’intégrer avec des outils existants et d’évoluer en continu leurs opérations sans mise en œuvre longue ou coûteuse de consultants.
La motivation de construire DOSS remonte à Wiley qui a vu les logiciels legacy perturber l’entreprise de fabrication de son père, et vous deux avez vu des problèmes similaires de première main alors que vous travailliez avec des usines et des chaînes d’approvisionnement en matériel. Comment ces expériences ont-elles façonné votre décision de co-fonder DOSS et de repenser les systèmes ERP desde zéro ?
Avant DOSS, j’étais l’un des premiers ingénieurs d’une startup FinTech. La raison numéro un pour laquelle nos acheteurs – les DAF, les comptables, etc. – ne passaient pas à notre solution était parce qu’ils étaient « trop occupés à mettre en œuvre un ERP ». Lorsque j’ai creusé plus profondément dans le paysage archaïque de l’ERP, j’ai été choqué par le modèle d’implémentation existant.
Ce que je voyais constamment, c’était la même faille fondamentale : la mise en œuvre prend des mois ou des années, coûte des centaines de milliers à des millions de dollars, et est bloquée entièrement par des consultants humains avec une facturation horaire. Ensuite, une fois que l’ERP est livré, il cesse de changer. L’entreprise continue d’évoluer ; le système ne change pas. C’est un problème architectural, et non un problème de configuration. Vous ne pouvez pas patcher votre chemin hors de celui-ci.
En tant que concepteur de logiciels, la comparaison la plus proche que je pouvais penser était la suivante : imaginez un monde dans lequel l’outil le plus important que vous utilisez – disons GitHub – était construit spécifiquement pour votre entreprise au cours de plusieurs années par une agence de conseil tiers. Ensuite, une fois que le produit est terminé, les consultants partent sans maintenance, sans amélioration des fonctionnalités et sans support. Les ingénieurs se révolteraient.
Aucune entreprise de technologie moderne ne peut fonctionner dans ce modèle. Wiley et moi sommes arrivés à la même conclusion : la seule façon de résoudre ce problème était de construire desde zéro.
DOSS se positionne comme une plate-forme d’exploitation native AI conçue pour remplacer les systèmes ERP traditionnels comme SAP ou Oracle. Quelles sont les différences architecturales fondamentales qui rendent un ERP natif AI possible aujourd’hui et qui n’étaient pas réalisables il y a dix ans ?
Oracle et SAP ont été construits à une époque où, pour atteindre une distribution maximale, ils devaient simplifier le plan de configuration d’un ERP pour qu’il soit un éditeur GUI que des consultants relativement non techniques puissent livrer à grande échelle. Pour préserver les meilleures pratiques, ils ont verrouillé de grandes parties des systèmes de base et n’ont autorisé la composition qu’à la périphérie. Cependant, dans la réalité, lorsque vous regardez le spectre de toutes les entreprises du monde, leurs applications commerciales ont besoin d’une flexibilité maximale.
Ce que le monde natif AI permet, c’est la transformation de l’ingénierie logicielle d’un artisanat à une machine industrialisée. Vous n’avez plus besoin d’artisans logiciels pour créer des systèmes de code à la main ; à la place, nous entrons dans un monde où le débit logiciel est un facteur de calcul et de jetons.
Doss a été conçu avec cela à l’esprit.
Nous avons construit le ZSL, un langage de programmation déclaratif spécifique au domaine (DSL) qui décrit la mise en œuvre complète d’un client DOSS en code. Pensez à ce que « Terraform » a fait pour l’effort Infrastructure as Code, mais appliqué à la logique d’application commerciale. En définissant les ERP dans un langage de programmation de faible dimension, nous sommes en mesure de déployer des agents à grande échelle pour livrer des solutions ERP.
Une fois que le ZSL a été écrit, la partie la plus importante de l’architecture était d’intégrer les meilleures pratiques dans la plate-forme elle-même pour empêcher les agents de construire des mises en œuvre de mauvaise qualité. Notre équipe a livré un système distribué évolutif avec un planificateur noyau pour prendre en charge la charge de travail d’ERP par à-coups. De plus, nous avons construit un système de base de données HTAP qui combine les parties les plus importantes d’une base de données transactionnelle comme Postgres et les capacités analytiques d’un entrepôt de données.
En construisant la plate-forme pour avoir une force d’entreprise dès le départ, le système est configuré pour une distribution entièrement agente. Ce qui prenait des mois ou des années à des équipes de consultants peut maintenant être parallélisé à grande échelle en utilisant une infrastructure agente dans notre système de boucle fermée propriétaire.
De nombreuses entreprises s’appuient toujours sur des tableurs et des outils fragmentés pour les achats, l’inventaire et la gestion des commandes. Quels sont les plus grands angles morts opérationnels qui surgissent lorsque les données commerciales de base ne sont pas unifiées dans une seule source de vérité ?
Le problème le plus critique est que les décisions sont prises sur la base d’informations obsolètes ou incomplètes. Si vos données d’inventaire vivent dans un endroit, vos commandes d’achat dans un autre et vos commandes de vente dans un troisième, vous êtes toujours en train de réconcilier, manuellement, lentement et après coup. Dès que quelqu’un réalise que l’inventaire est hors norme ou qu’un fournisseur est en retard, c’est déjà un problème dans l’entreprise.
Verve Coffee Roasters est un bon exemple de où cela se brise dans la pratique. Ils exécutent des opérations à travers les canaux de détail, de gros, de vente directe et de cafés aux États-Unis et au Japon, mais géraient tout cela à travers des systèmes non connectés sans visibilité en temps réel de l’inventaire. Ils manquaient de leur propre café dans les emplacements à fort trafic et ont atteint des ruptures de stock critiques pendant le lancement d’un détaillant majeur qui a blessé une relation de détail clé. Les données existaient quelque part ; elles n’étaient simplement pas connectées de manière à permettre à quiconque d’agir dessus à temps.
Le problème plus subtil est que la fragmentation cache la véritable forme de vos opérations. Vous ne pouvez pas voir la relation entre un retard en amont et un problème de livraison en aval si ces deux choses vivent dans des outils séparés. Vous finissez par gérer les symptômes, en expédiant des commandes, en construisant des stocks de sécurité et en exécutant des vérifications manuelles au lieu de comprendre ce qui se passe réellement. Un système unifié ne sauve pas seulement du temps sur la réconciliation. Il change ce que vous pouvez même voir et interroger.
Au cœur, imaginez exécuter une entreprise sans accès à un système de contrôle de version (Git), un outil d’observabilité (DataDog) ou une base de données centralisée pour interroger les informations.
Les mises en œuvre d’ERP ont historiquement nécessité de grandes équipes de consultants et des mois – ou même des années – de déploiement. Comment l’IA change-t-elle l’économie et la complexité de la mise en œuvre de logiciels opérationnels à l’intérieur d’entreprises réelles ?
Le modèle d’implémentation traditionnel est le résultat émergent de pratiques logicielles vieilles de plusieurs générations. Nous ne vivons plus dans ce monde.
Il y a une incitation perverse dans les mises en œuvre d’ERP aujourd’hui – plus la mise en œuvre prend de temps et moins elle est efficace, plus les concepteurs reçoivent d’argent. La majorité des concepteurs ne profiteraient pas de cela ; cependant, ils ne sont jamais incités à bouger avec rapidité et qualité.
De plus, le ratio des dépenses de conseil aux dépenses de logiciel dans un engagement ERP traditionnel tourne autour de 9:1, vous dépensez donc neuf dollars pour des consultants pour chaque dollar que vous dépensez pour le logiciel lui-même. Pour une grande entreprise, c’est extrêmement douloureux. Pour les entreprises du marché moyen, c’est prohibitif. Ils optent donc pour un logiciel qui ne correspond pas réellement à la façon dont ils opèrent, retardent le projet ou l’abandonnent en cours de route.
L’IA change complètement l’unité économique de cela. Au lieu d’un engagement de conseil, une mise en œuvre DOSS est une base de code. À mesure que nos délais de mise en œuvre continuent de diminuer, nous sommes en mesure d’aligner les incitations sur un modèle « payez sur livraison » au lieu de « payez au fur et à mesure ». Lorsque l’entreprise change, le système change avec elle. Le besoin de salles de consultants et de diapositives longues n’est plus pertinent.
Le succès à Doss signifie remplacer les 1,86 billion de dollars de dépenses mondiales de services IT par une mise en œuvre et une maintenance agente en utilisant notre ZSL comme langage pour les logiciels d’applications commerciales. Le succès à Doss signifie commodifier toutes les applications commerciales à grande échelle.
Vous avez déployé DOSS avec des entreprises opérant dans des environnements réels comme la fabrication, la logistique et les biens de consommation. Quels sont les défis inattendus qui surgissent lorsque l’IA rencontre des données opérationnelles désordonnées ?
Le défi est rarement l’IA. C’est les données sur lesquelles vous lui demandez de raisonner.
Chaque entreprise avec laquelle nous travaillons a accumulé des années de contournements opérationnels. Les données existent techniquement, elles ne vivent simplement pas dans un endroit où leurs employés, et encore moins les systèmes agents, puissent agir dessus de manière fiable.
Un excellent exemple est un fabricant de meubles allemand qui crée des pièces sur mesure. Lorsque nous sommes arrivés, ils avaient 10 ans de données historiques réparties sur 8 formats de fichiers personnalisés avec 11 objets de données différents et une synchronisation 3PL en cours d’exécution sur une copie manuelle à partir de dossiers FTP. La logique commerciale était spécifique avec des dimensions personnalisées, des configurations, des méthodes de paiement et des emplacements de salle d’exposition, et le système entier devait fonctionner en allemand. Il n’y a pas de schéma prêt à l’emploi pour cela. Ils devaient payer des milliers d’euros chaque fois qu’ils voulaient changer des options de configuration simples, comme les options de statut pour une commande d’achat.
Le défi n’est pas la complexité technique de l’un ou l’autre pièce. C’est que chaque entreprise a une version différente de ce problème, et vous ne pouvez pas pleinement l’anticiper jusqu’à ce que vous soyez à l’intérieur de leurs données. Le travail consiste à prendre une empreinte précise de la façon dont l’entreprise fonctionne réellement, et non à mapper leurs données dans un modèle générique et espérer qu’il corresponde.
Pour construire une solution qui fonctionne pour le monde réel, vous avez besoin d’une plate-forme avec une flexibilité maximale. Seulement alors l’IA peut être utile pour comprendre le modèle de données sous-jacent sur lequel elle travaille, et construire le modèle qui fonctionne pour chaque client.
Il y a beaucoup de discussions sur les copilotes IA et les agents autonomes dans les logiciels commerciaux. Où voyez-vous l’IA ajoutant la plus grande valeur dans les flux de travail opérationnels aujourd’hui, et où la surveillance humaine reste-t-elle essentielle ?
À grande échelle, l’IA a la capacité de perturber toutes les opérations.
Sur l’horizon à court terme, les modèles et les agents propriétaires de Doss devraient être en mesure de transformer les noyaux des consultants techniques dans la mise en œuvre d’applications commerciales ainsi que les consultants de gestion dans la fourniture de recommandations stratégiques. Doss aura le plus grand référentiel de données structurées et co-localisées représentant à la fois le schéma et les informations opérationnelles pour les entreprises. Nos agents peuvent utiliser ces données pour fournir des recommandations évolutives.
La valeur la plus claire aujourd’hui est plus spécifique que cela. C’est dans les travaux qui sont répétitifs, basés sur des règles et actuellement effectués par des personnes qui ont d’autres priorités stratégiques : le traitement des commandes d’achat, la réconciliation de l’inventaire et la prise de décision de livraison. Ces tâches ont des entrées et des sorties bien définies, et l’IA peut les gérer de manière fiable à grande échelle.
Pour l’instant, la surveillance humaine est essentielle partout où le coût d’une mauvaise décision est élevé, et le système n’a pas encore suffisamment de contexte pour être confiant. Aujourd’hui, le bon modèle n’est pas les agents autonomes remplaçant la prise de décision humaine dans son ensemble ; c’est les agents qui gèrent le travail à haute volume et bien défini afin que les gens puissent se concentrer sur les décisions qui nécessitent réellement leur jugement.
De nombreuses entreprises tentent de superposer l’IA sur leurs piles logicielles existantes. Pourquoi, selon vous, le rétrofit des systèmes legacy avec l’IA échoue souvent par rapport à la construction de l’IA directement dans les fondements de la plate-forme ?
Les systèmes legacy n’ont pas été conçus pour être raisonnés par l’IA. Les modèles de données, les API, la façon dont les informations sont structurées, tout cela a été conçu pour que les humains interagissent avec des interfaces. Lorsque vous essayez de superposer l’IA sur cela, vous lui demandez de travailler autour de contraintes pour lesquelles elle n’était pas conçue.
Même si vous essayez de lancer un serveur MCP au-dessus, en réalité, un serveur MCP nécessite des modèles de conception très spécifiques. La plupart des serveurs MCP aujourd’hui introduisent en fait une plus grande fenêtre de contexte et font exploser les performances.
Cependant, le problème plus profond est le modèle d’implémentation. Dans un ERP traditionnel, la configuration du système est stockée dans le système lui-même. Ce n’est pas du code que vous pouvez lire, tester ou versionner. Il n’y a pas de moyen pour un agent de comprendre ce que le système fait, et encore moins de le modifier en toute sécurité. Nous avons construit le ZSL spécifiquement afin que la configuration soit une base de code appropriée : lisible, testable et déployable dans un système de boucle fermée. Nous construisons un cycle de vie de développement logiciel (SDLC) entièrement agente. C’est la condition préalable pour que l’IA puisse réellement opérer sur le système plutôt que de simplement s’asseoir dessus.
À mesure que l’IA devient capable de générer des flux de travail et d’interagir directement avec les systèmes opérationnels, comment pensez-vous que l’interface des logiciels d’entreprise traditionnels évoluera ?
La question d’interface est vraiment à propos de qui a besoin d’utiliser le système. Actuellement, les interfaces ERP sont construites autour d’un petit ensemble d’utilisateurs puissants, les personnes qui ont été formées sur le système pendant la mise en œuvre. Toute autre personne ne peut pas l’utiliser ou obtient une version dégradée.
Ce que nous construisons, c’est une interface composable, qui traite l’interface comme un constructeur de site Web. L’interface elle-même est également prise en charge par la boucle fermée ZSL. Chaque personne – le DAF, le responsable du entrepôt, l’analyste de la chaîne d’approvisionnement – obtient un tableau de bord et des vues de données composées autour de la façon dont ils travaillent réellement, et non autour de la façon dont le logiciel a été configuré. À mesure que l’IA gère davantage l’exécution du flux de travail sous-jacent, l’interface devient moins axée sur la saisie de données et plus sur la visibilité et la prise de décision. Vous devez voir ce qui se passe, comprendre pourquoi, et prendre des décisions de jugement. Le logiciel devrait gérer le reste.
Les startups comme DOSS entrent sur un marché dominé par des entreprises ayant des décennies d’existence. Quels sont les avantages que les startups natives IA ont lorsqu’elles concourent contre les plateformes d’entreprise établies ?
Les entreprises établies ont le problème inverse de celui des startups. Ils ont des bases installées énormes à protéger. Chaque décision architecturale qu’ils prennent doit être compatible avec les versions précédentes. Ils peuvent ajouter des fonctionnalités IA à des produits existants, mais ils ne peuvent pas reconstruire les systèmes sous-jacents sans tout casser qui s’exécute dessus. Ce n’est pas un échec d’ambition ; c’est structurel.
Dans l’ERP en particulier, ils sont également chargés de décisions commerciales qui les ont menés sur un chemin où les revenus sont générés par la fonction spécifique que DOSS cherche à éliminer – les consultants en services professionnels. Étant donné que les utilisateurs dépensent neuf dollars pour des consultants pour chaque dollar qu’ils dépensent pour le logiciel lui-même, la capacité de transformer 90 % de leurs revenus est intenable pour les grandes entreprises établies.
Un système natif IA peut être conçu dès le départ pour que l’IA fasse partie de l’architecture de base, et non une couche au-dessus. Le modèle d’implémentation, le modèle de données et la façon dont la configuration fonctionne sont tous conçus avec l’IA comme participant de premier plan. C’est un avantage cumulatif où chaque déploiement améliore le système, et les agents d’implémentation deviennent plus capables avec chaque nouveau client. Cette boucle d’amélioration n’existe pas dans un système où l’implémentation est toujours un engagement de conseil humain.
En regardant vers l’avenir, comment voyez-vous l’IA transformer le « système d’exploitation » d’une entreprise au cours des cinq à dix prochaines années, en particulier dans des domaines tels que la visibilité de la chaîne d’approvisionnement, la prise de décision en temps réel et les opérations automatisées ?
Nous avons fondé DOSS sur la conviction que les systèmes d’entreprise pourraient se construire eux-mêmes. Trois ans plus tard, nous sommes entrés dans la phase 2 de Doss : la mise en œuvre auto-pilote agente. La plate-forme peut déjà générer, valider et faire évoluer le système d’un client plutôt que de compter sur la configuration manuelle d’un consultant, et elle s’améliore avec chaque déploiement.
La direction dans laquelle cela va est un système qui est toujours à l’unisson avec l’entreprise. Aujourd’hui, l’écart entre la façon dont une entreprise opère et ce que le logiciel sait sur elle est de mois ou d’années. Le système a été configuré à un moment donné et n’a pas changé depuis. Ce qui devient possible lorsque cet écart se ferme, lorsque le système s’adapte en temps réel à mesure que l’entreprise change, est une catégorie différente de capacité opérationnelle. La visibilité en temps réel n’est pas seulement un rapport plus rapide ; c’est la capacité d’attraper une perturbation de la chaîne d’approvisionnement avant qu’elle ne devienne une défaillance de livraison. Les opérations automatisées ne sont pas seulement une question d’efficacité ; c’est la capacité de faire fonctionner une entreprise plus complexe avec la même équipe. C’est la version de logiciels opérationnels que nous construisons.
Je vous remercie pour vos réponses détaillées, les lecteurs qui souhaitent en savoir plus devraient visiter Doss.
