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 desde startups en etapas iniciales hasta sistemas de infraestructura a gran escala. Antes de co-fundar Doss, fue ingeniero fundador en Siteline, donde construyó sistemas básicos, incluyendo la arquitectura de permisos, integraciones de ERP y marcos de automatización, mientras también contribuía a la contratación, operaciones de ingresos y 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 talento 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 en AI 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 costosos consultores. Es una infraestructura empresarial diseñada para la velocidad, la escalabilidad y la adaptabilidad.

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

Antes de DOSS, fui el ingeniero fundador de una startup de FinTech. La razón número uno por la que los compradores – CFOs, contadores, etc. – no iban con nuestra solución era porque estaban “demasiado ocupados implementando un ERP”. Cuando me sumergí más en el arcaico mundo del 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 de él.

Como constructor de software, la comparación más cercana que pude pensar fue 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 características 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 manera de solucionarlo era construir desde cero.

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

Oracle y SAP se construyeron en una era 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 secciones del sistema central y solo permitieron la composabilidad en los bordes. Sin embargo, en la realidad, cuando se mira el espectro de todos los negocios del mundo, sus aplicaciones comerciales necesitan flexibilidad máxima.

Lo que el mundo nativo en AI 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 ha sido arquitectado con exactly esto en mente.

Construímos el ZSL, un lenguaje de dominio específico declarativo (DSL) que describe la implementación completa de DOSS de un cliente en código. Piensa 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 ERPs en un lenguaje de programación de baja dimensionalidad, podemos desplegar 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 hornear las mejores prácticas en la plataforma en sí para evitar que los agentes construyeran implementaciones de baja calidad. Nuestro equipo ha entregado un sistema distribuido escalable con un programador de nivel de kernel para asumir la carga de flujos 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 enteramente agente. Lo que solía tomar meses o años para que los equipos de consultores lo hicieran ahora se puede paralelizar a gran escala utilizando la infraestructura agente en nuestro sistema de bucle cerrado propietario.

Muchas empresas aún 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 grande es que las decisiones se toman con información estancada o incompleta. Si tus datos de inventario viven en un lugar, tus pedidos de compra en otro y tus pedidos de venta en un tercero, siempre estás reconciliando, manualmente, lentamente y después de los hechos. Hasta que alguien se da cuenta de que el inventario está mal o un proveedor está atrasado, ya es un problema en el negocio.

Verve Coffee Roasters es un buen ejemplo de dónde se rompe esto en la práctica. Operan en operaciones en tiendas, 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 quedaban sin 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 comercial clave. Los datos existían en algún lugar; simplemente no estaban conectados de una manera que permitiera a nadie actuar sobre ellos a tiempo.

El problema más sutil es que la fragmentación oculta la verdadera forma de tus 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, construyendo stock de seguridad y ejecutando controles manuales en lugar de comprender qué está sucediendo realmente. Un sistema unificado no solo ahorra tiempo en la reconciliación. Cambia lo que puedes ver y preguntar.

En su núcleo, imagina ejecutar un negocio 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 han requerido históricamente grandes equipos de consultores y meses, o incluso años, de despliegue. ¿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 tome la implementación y menos efectiva sea, más dinero reciben los implementadores. La gran mayoría de los constructores no aprovecharían esto; sin embargo, nunca están incentivados a moverse con ritmo y calidad.

Además, la relación entre el gasto en consultoría y el gasto en 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 las empresas del mercado medio, es prohibitivo. Así que o bien se conforman con un software que no se adapta realmente a cómo operan, o retrasan el proyecto o lo abandonan en parte.

La IA cambia completamente la unidad económica de esto. 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 de “pago por entrega” en lugar de “pago según vaya”. Cuando el negocio cambia, el sistema cambia con él. La necesidad de habitaciones llenas de consultores y diapositivas largas ya no es relevante.

El éxito en Doss significa reemplazar el gasto global de $1.86 billones en servicios de TI 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.

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 mucho menos los sistemas agente, puedan actuar sobre ellos de manera confiable.

Un gran ejemplo es un fabricante de muebles alemán que crea piezas personalizadas. Cuando entramos, 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 FTP. La lógica empresarial 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 para 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 el negocio en realidad, no mapear sus datos en una plantilla genérica y esperar que encaje.

Para construir una solución que funcione para el mundo real, necesitas una plataforma con flexibilidad máxima. Solo entonces puede la IA 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 agregue el mayor 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 la información del esquema como la 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 actualmente realizado por personas que tienen otras prioridades más estratégicas: procesar pedidos de compra, reconciliar el inventario y enrutar decisiones de cumplimiento. Estas tareas tienen entradas y salidas bien definidas, y la IA puede manejarlas de manera confiable 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 reemplazando 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 intentan capas de IA sobre sistemas de software existentes. ¿Por qué, en su opinión, a menudo falla la retroalimentación de sistemas heredados con IA en comparación con la construcción de 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 interfaces. Cuando intentas capas de IA sobre eso, estás pidiéndole que trabaje alrededor de restricciones para las que no estaba diseñado.

Incluso si intentas lanzar un servidor MCP sobre él, 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 en realidad introducen un mayor bloat de la ventana de contexto y explotan el rendimiento.

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 menos aún 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 sobre él.

¿Cómo ve la evolución de la interfaz tradicional del software empresarial a medida que la IA se vuelve capaz de generar flujos de trabajo e interactuar directamente con sistemas operativos?

La pregunta de la interfaz es realmente sobre quién necesita usar el sistema. Ahora, 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 de él.

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. Todos, el CFO, el gerente de almacén, el analista de la cadena de suministro, obtienen 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 sobre la entrada de datos y más sobre la visibilidad y la toma de decisiones. Necesitas ver qué está sucediendo, comprender por qué y tomar decisiones. 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 en AI al competir contra plataformas empresariales establecidas?

Los incumbentes tienen el problema opuesto al de las startups. Tienen bases instaladas enormes que proteger. Cada decisión arquitectónica que toman debe ser compatible con versiones anteriores. Pueden agregar características 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 fracaso de ambición; es estructural.

En ERP específicamente, también están cargados con decisiones comerciales que los llevaron por un camino en el que los ingresos se impulsan desde la función específica que DOSS está buscando 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 por fuentes es inaceptable para los grandes incumbentes.

Un sistema nativo en AI puede diseñarse desde el principio para que la IA sea parte de la arquitectura central, no una capa sobre ella. 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 un participante de primera clase. Esa es una ventaja de compounding donde cada despliegue 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 aún es un compromiso de consultoría humana.

Mirando hacia adelante, ¿cómo ve la transformación de la “plataforma operativa” de un negocio 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 entrado en la Fase 2 de Doss: la implementación autodirigida 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 despliegue.

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 un negocio y lo que el software sabe sobre él 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 el negocio cambia, 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 en la cadena de suministro antes de que se convierta en un fracaso de cumplimiento. Las operaciones automatizadas no son solo sobre la eficiencia; es la capacidad de ejecutar un negocio más complejo con el mismo equipo. Esa es la versión del software de operaciones que estamos construyendo hacia.

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