Arnav Mishra, Co-Fundador y CTO de Doss – Serie de Entrevistas

Arnav Mishra, Co-Fundador y CTO de Doss, es un ingeniero full-stack y líder técnico con una experiencia que abarca startups en etapas tempranas y sistemas de infraestructura a gran escala. Antes de co-fundar Doss, fue ingeniero fundador en Siteline, donde construyó sistemas básicos, incluida la arquitectura de permisos, las integraciones de ERP y los marcos de automatización, mientras también contribuía a la contratación, las operaciones de ingresos y la cultura de la empresa. Al comienzo de su carrera, ocupó puestos de ingeniería en Rubrik y realizó prácticas en empresas como Uber y VMware, desarrollando experiencia en infraestructura en la nube, sistemas de datos y automatización. Junto con su trabajo técnico, ha estado activamente involucrado en la mentoría y el desarrollo de talentos a través de organizaciones como Techquitable Futures y Contrary, reflejando un compromiso más amplio con el apoyo a la próxima generación de ingenieros.

Doss es una empresa de software empresarial moderna que se centra en reinventar los sistemas ERP tradicionales a través de su Plataforma de Recursos Adaptativa (ARP), una plataforma de operaciones flexible y nativa de IA diseñada para unificar y automatizar los flujos de trabajo empresariales. Construida como una alternativa componible a las soluciones ERP heredadas, Doss permite a las empresas gestionar el inventario, la compra, las finanzas y el cumplimiento dentro de un solo sistema que se adapta a las operaciones del mundo real en lugar de forzar procesos rígidos. Su plataforma combina una capa de datos centralizada, flujos de trabajo sin código y análisis en tiempo real, lo que permite a las empresas implementar rápidamente, integrarse con herramientas existentes y evolucionar continuamente sus operaciones sin implementaciones largas o consultores costosos. n infraestructura empresarial diseñada para la velocidad, la escalabilidad y la adaptabilidad.

La motivación para construir DOSS se remonta a Wiley, que vio cómo el software heredado interrumpió el negocio de fabricación de su padre, y ambos vieron problemas similares de primera mano mientras trabajaban con fábricas y cadenas de suministro de hardware. ¿Cómo influyeron esas experiencias en su decisión de co-fundar DOSS y replantear los sistemas ERP desde cero?

Antes de DOSS, era el ingeniero fundador de una startup de FinTech. La razón número uno por la que los compradores -CFO, contadores, etc.- no aceptaban nuestra solución era porque estaban “demasiado ocupados implementando un ERP”. Al profundizar en el arcaico mundo de los ERP, me sorprendió el modelo de implementación existente.

Lo que seguí viendo fue el mismo fracaso fundamental: la implementación lleva meses o años, cuesta cientos de miles a millones de dólares y se bloquea por completo en consultores humanos con facturación por horas. Luego, una vez que el ERP se entrega, deja de cambiar. El negocio sigue evolucionando; el sistema no. Ese es un problema arquitectónico, no de configuración. No puedes parchear tu salida.

Como constructor de software, la comparación más cercana que podía pensar era la siguiente: imagina un mundo en el que la herramienta más importante que usas -como desarrollador, digamos GitHub- se construyó específicamente para tu empresa a lo largo de años por una agencia de consultoría de terceros. Luego, una vez que el producto esté terminado, los consultores se van sin mantenimiento, mejoras de funciones ni soporte. Los ingenieros se rebelarían.

Ninguna empresa de tecnología moderna puede operar en ese modelo. Wiley y yo llegamos a la misma conclusión: la única forma de solucionarlo era construir desde cero.

DOSS se posiciona como una plataforma de operaciones nativa de IA diseñada para reemplazar los sistemas ERP tradicionales como SAP o Oracle. ¿Cuáles son las diferencias arquitectónicas fundamentales que hacen posible un ERP nativo de IA hoy en día que no eran factibles hace una década?

Oracle y SAP se construyeron en una época en la que, para lograr una distribución maximizada, necesitaban simplificar el plano de configuración de un ERP para que fuera un editor basado en GUI que los consultores relativamente no técnicos pudieran entregar a gran escala. Para preservar las mejores prácticas, bloquearon grandes partes de los sistemas básicos y solo permitieron la composabilidad en los bordes. Sin embargo, en la realidad, cuando se mira el espectro de todas las empresas del mundo, sus aplicaciones comerciales necesitan flexibilidad máxima.

Lo que el mundo nativo de IA permite es la transformación de la ingeniería de software de un oficio a una máquina industrializada. Ya no necesitamos artesanos de software para crear sistemas de código a mano; en cambio, estamos entrando en un mundo en el que el rendimiento de software es un factor de cómputo y tokens.

Doss se ha diseñado teniendo precisamente esto en mente.

Construímos el ZSL, un lenguaje de descripción de dominio específico (DSL) que describe la implementación completa de DOSS de un cliente en código. Piense en lo que “Terraform” hizo por el esfuerzo de Infraestructura como Código, pero aplicado a la lógica de la aplicación empresarial. Al definir los ERP en un lenguaje de programación de baja dimensionalidad, podemos implementar agentes a gran escala para entregar soluciones de ERP.

Una vez que se escribió el ZSL, la parte más importante de la arquitectura fue integrar las mejores prácticas en la plataforma en sí para evitar que los agentes construyan implementaciones de baja calidad. Nuestro equipo ha entregado un sistema distribuido escalable con un programador de nivel de núcleo para asumir la carga de las cargas de trabajo de ERP de alta intensidad. Además, construimos un sistema de base de datos HTAP que combina las partes más importantes de una base de datos transaccional como Postgres y las capacidades analíticas de un almacén de datos.

Al construir la plataforma para tener fuerza empresarial desde el principio, el sistema está configurado para una distribución agente completa. Lo que solía llevar meses o años a equipos de consultores ahora se puede paralelizar a gran escala utilizando infraestructura agente en nuestro sistema de bucle cerrado propietario.

Muchas empresas todavía confían en hojas de cálculo y herramientas fragmentadas para la compra, el inventario y la gestión de pedidos. ¿Cuáles son los puntos ciegos operativos más grandes que surgen cuando los datos comerciales básicos no se unifican en una sola fuente de verdad?

El problema más grave es que las decisiones se toman con información obsoleta o incompleta. Si sus datos de inventario viven en un lugar, sus pedidos de compra en otro y sus pedidos de venta en un tercero, siempre están reconciliando, manualmente, lentamente y después del hecho. Para cuando alguien se da cuenta de que el inventario está mal o un proveedor está retrasado, ya es un problema en el negocio.

Verve Coffee Roasters es un buen ejemplo de dónde se produce este fallo en la práctica. Ejecutan operaciones en comestibles, mayoristas, DTC y cafeterías en los EE. UU. y Japón, pero gestionaban todo a través de sistemas desconectados sin visibilidad de inventario en tiempo real. Se les acababa su propio café en ubicaciones de alto tráfico y llegaban a stockouts críticos durante un lanzamiento importante de un minorista que dañó una relación minorista clave. Los datos existían en algún lugar; simplemente no estaban conectados de una manera que les permitiera actuar en tiempo.

El problema más sutil es que la fragmentación oculta la forma real de sus operaciones. No puedes ver la relación entre un retraso en la parte superior y un problema de cumplimiento en la parte inferior si esas dos cosas viven en herramientas separadas. Terminas gestionando síntomas, expidiendo pedidos, creando stock de seguridad y ejecutando controles manuales en lugar de comprender lo que realmente está sucediendo. Un sistema unificado no solo ahorra tiempo en la reconciliación. Cambia lo que puedes ver y preguntar.

En su núcleo, imagine ejecutar una empresa empresarial sin acceso a un sistema de control de versiones (Git), una herramienta de observabilidad (DataDog) o una base de datos centralizada para consultar información.

Las implementaciones de ERP históricamente han requerido grandes equipos de consultores y meses, o incluso años, de implementación. ¿Cómo cambia la IA la economía y la complejidad de implementar software operativo dentro de empresas reales?

El modelo de implementación tradicional es el resultado emergente de prácticas de software de generaciones anteriores. Ya no vivimos en ese mundo.

Hay un incentivo perverso en las implementaciones de ERP hoy en día: cuanto más tiempo dura la implementación y menos efectiva es, más dinero reciben los implementadores. La gran mayoría de los constructores no se aprovecharían de esto; sin embargo, nunca se les incentiva a moverse con ritmo y calidad.

Además, la proporción de gastos de consultoría con respecto a los gastos de software en un compromiso de ERP tradicional es aproximadamente 9:1, por lo que estás gastando nueve dólares en consultores por cada dólar que gastas en el software en sí. Para una gran empresa, eso es extremadamente doloroso. Para empresas del mercado medio, es prohibitivo. Así que o aceptan un software que no se adapta realmente a cómo operan, o retrasan el proyecto o lo abandonan a mitad de camino.

La IA cambia la economía unitaria de esto por completo. En lugar de un compromiso de consultoría, una implementación de DOSS es una base de código. A medida que nuestros tiempos de implementación siguen disminuyendo, podemos alinear los incentivos con un modelo “paga por entrega” en lugar de “paga según vas”. Cuando el negocio cambia, el sistema cambia con él. La necesidad de salas de consultores y presentaciones de diapositivas largas ya no es relevante.

El éxito en Doss significa reemplazar el gasto en servicios de TI global de $1.86 billones con implementación y mantenimiento agente utilizando nuestro ZSL como el lenguaje para el software de aplicación empresarial. El éxito en Doss es commoditizar todas las aplicaciones empresariales a gran escala.

Usted ha desplegado DOSS con empresas que operan en entornos del mundo real como la fabricación, la logística y los bienes de consumo. ¿Cuáles son algunos de los desafíos inesperados que surgen cuando la IA se encuentra con datos operativos desordenados?

El desafío rara vez es la IA. Es los datos sobre los que se le pide que razone.

Cada negocio con el que trabajamos ha acumulado años de soluciones operativas. Los datos técnicamente existen, simplemente no viven en un lugar donde los empleados, y ni siquiera los sistemas agente, puedan actuar de manera confiable.

Un gran ejemplo es un fabricante de muebles alemán que crea piezas hechas a medida. Cuando llegamos, tenían 10 años de datos históricos dispersos en 8 formatos de archivo personalizados con 11 objetos de datos diferentes y una sincronización de 3PL que se ejecutaba en copia y pegado manual desde carpetas de FTP. La lógica comercial era específica con dimensiones personalizadas, configuraciones, métodos de pago y ubicaciones de salas de exhibición, y todo el sistema necesitaba funcionar en alemán. No hay esquema listo para usar para eso. Tenían que pagar miles de euros cada vez que querían cambiar opciones de configuración simples, como las opciones de estado de un pedido de compra.

El desafío no es la complejidad técnica de ninguna pieza en particular. Es que cada negocio tiene una versión diferente de este problema, y no puedes anticiparlo completamente hasta que estés dentro de sus datos. El trabajo es tomar una impresión precisa de cómo opera realmente el negocio, no mapear sus datos en una plantilla genérica y esperar que se ajuste.

Para construir una solución que funcione en el mundo real, necesitas una plataforma con flexibilidad máxima. Solo entonces la IA puede ser útil para comprender el modelo de datos subyacente con el que está trabajando y construir el modelo que funciona para cada cliente.

Hay mucha discusión sobre copilotos de IA y agentes autónomos en software empresarial. ¿Dónde ve que la IA agrega más valor en los flujos de trabajo operativos hoy en día, y dónde sigue siendo esencial la supervisión humana?

A gran escala, la IA tiene la capacidad de disruptar todo el trabajo operativo.

En el horizonte a corto plazo, los modelos y agentes propietarios de Doss deberían poder transformar los núcleos de los consultores técnicos en la implementación de aplicaciones empresariales, así como los de los consultores de gestión en la entrega de recomendaciones estratégicas. Doss tendrá el repositorio más grande de datos estructurados y co-localizados que representan tanto el esquema como la información operativa para las empresas. Nuestros agentes pueden usar esos datos para entregar recomendaciones escalables.

El valor más claro hoy en día es más específico que eso. Está en el trabajo que es repetitivo, basado en reglas y realizado actualmente por personas que tienen otras prioridades más estratégicas: procesar pedidos de compra, reconciliar el inventario y tomar decisiones de cumplimiento. Estas tareas tienen entradas y salidas bien definidas, y la IA puede manejarlas de manera fiable a gran escala.

Por ahora, la supervisión humana es esencial en cualquier lugar donde el costo de una mala decisión sea alto, y el sistema aún no tenga suficiente contexto para estar seguro. Hoy en día, el modelo correcto no es agentes autónomos que reemplazan la toma de decisiones humana en su totalidad; es agentes que manejan el trabajo de alto volumen y bien definido para que las personas puedan centrarse en las decisiones que realmente requieren su juicio.

Muchas empresas están tratando de superponer la IA sobre sus pilas de software existentes. En su opinión, ¿por qué a menudo falla la retroalimentación de los sistemas heredados con la IA en comparación con la construcción de la IA directamente en la base de la plataforma?

Los sistemas heredados no se construyeron para que la IA los razone. Los modelos de datos, las API, la forma en que se estructura la información, todo se diseñó para que los humanos interactúen con él a través de interfaces. Cuando intentas superponer la IA sobre eso, le estás pidiendo que trabaje alrededor de restricciones con las que no estaba diseñado para trabajar.

Incluso si intentas agregar un servidor MCP encima, en realidad, un servidor MCP necesita patrones de diseño muy específicos. La mayoría de los servidores MCP de hoy en día introducen un mayor desbordamiento de la ventana de contexto y explotan el rendimiento.

Sin embargo, el problema más profundo es el modelo de implementación. En un ERP tradicional, la configuración del sistema se almacena en el sistema en sí. No es código que puedas leer, probar o versionar. No hay forma de que un agente comprenda qué está haciendo el sistema, y ni siquiera puede cambiarlo de manera segura. Construimos ZSL específicamente para que la configuración sea una base de código adecuada: legible, probada y desplegada en un sistema de bucle cerrado. Estamos construyendo un ciclo de vida de desarrollo de software (SDLC) completamente agente. Esa es la condición previa para que la IA realmente opere en el sistema en lugar de simplemente sentarse encima.

¿Cómo ve que evoluciona la interfaz de los sistemas de software empresariales tradicionales a medida que la IA se vuelve capaz de generar flujos de trabajo e interactuar directamente con los sistemas operativos?

La pregunta de la interfaz es realmente sobre quién necesita usar el sistema. Hoy en día, las interfaces de ERP se construyen alrededor de un pequeño conjunto de usuarios poderosos, las personas que fueron capacitadas en el sistema durante la implementación. Todos los demás no pueden usarlo o obtienen una versión degradada.

Lo que estamos construyendo es una interfaz componible, que trata la interfaz como un constructor de sitios web. La interfaz en sí también está respaldada por el ZSL de bucle cerrado. Cada persona, el director financiero, el gerente de almacén, el analista de la cadena de suministro, obtiene un panel y vistas de datos compuestas alrededor de cómo realmente trabajan, no alrededor de cómo se configuró el software. A medida que la IA maneja más de la ejecución del flujo de trabajo subyacente, la interfaz se convierte en menos en entrada de datos y más en visibilidad y toma de decisiones. Necesitas ver lo que está sucediendo, comprender por qué y tomar decisiones de juicio. El software debe manejar el resto.

Las startups como DOSS están ingresando a un mercado dominado por incumbentes con décadas de antigüedad. ¿Cuáles son las ventajas que tienen las startups nativas de IA al competir contra plataformas empresariales establecidas?

Los incumbentes tienen el problema opuesto al de las startups. Tienen enormes bases instaladas que proteger. Cada decisión arquitectónica que toman debe ser compatible con versiones anteriores. Pueden agregar funciones de IA a productos existentes, pero no pueden reconstruir los sistemas subyacentes sin romper todo lo que se ejecuta en ellos. Eso no es un fallo de ambición; es estructural.

En ERP específicamente, también están cargados con decisiones comerciales que los llevaron por un camino donde los ingresos se generan a partir de la función específica que DOSS busca eliminar: consultores de servicios profesionales. Dado que los usuarios gastan nueve dólares en consultores por cada dólar que gastan en el software en sí, la capacidad de transformar el 90% de sus ingresos de fuente es insostenible para los grandes incumbentes.

Un sistema nativo de IA se puede diseñar desde el principio para que la IA sea parte de la arquitectura básica, no una capa encima. El modelo de implementación, el modelo de datos y la forma en que funciona la configuración están diseñados con la IA como participante de primera clase. Esa es una ventaja compuesta donde cada implementación hace que el sistema sea mejor, y los agentes de implementación se vuelven más capaces con cada nuevo cliente. Ese tipo de bucle de mejora no existe en un sistema donde la implementación sigue siendo un compromiso de consultoría humana.

Mirando hacia adelante, ¿cómo vislumbra que la IA transforme el “sistema operativo” de una empresa en los próximos cinco a diez años, particularmente en áreas como la visibilidad de la cadena de suministro, la toma de decisiones en tiempo real y las operaciones automatizadas?

Fundamos DOSS con la convicción de que los sistemas empresariales podrían construirse a sí mismos. Tres años después, hemos ingresado en la Fase 2 de Doss: la implementación autoconducida agente. La plataforma ya puede generar, validar y evolucionar el sistema de un cliente en lugar de confiar en la configuración manual de un consultor, y mejora con cada implementación.

La dirección hacia la que se dirige esto es un sistema que siempre está en sintonía con el negocio. Hoy en día, la brecha entre cómo opera una empresa y lo que el software sabe sobre ella es de meses o años. El sistema se configuró en un momento en el tiempo y no ha cambiado desde entonces. Lo que se vuelve posible cuando esa brecha se cierra, cuando el sistema se adapta en tiempo real a medida que cambia el negocio, es una categoría diferente de capacidad operativa. La visibilidad en tiempo real no es solo informes más rápidos; es la capacidad de atrapar una interrupción de la cadena de suministro antes de que se convierta en un fallo de cumplimiento. Las operaciones automatizadas no son solo sobre eficiencia; es la capacidad de ejecutar un negocio más complejo con el mismo equipo. Esa es la versión de software de operaciones que estamos construyendo hacia.

Gracias por sus respuestas detalladas, los lectores que deseen obtener más información deben visitar Doss.