Planificación de Recursos Empresariales (ERP)

ERP (Planificación de Recursos Empresariales) se refiere a una clase de software empresarial que apoya las operaciones rutinarias de la compañía y lleva el seguimiento de sus recursos, destacándose el efectivo, las materias primas, el trabajo en curso, los productos terminados, los pedidos de los clientes, las órdenes de compra y la nómina. Los ERPs generalmente incluyen muchos módulos destinados a las funciones empresariales centrales, es decir, contabilidad, compras, distribución, finanzas, ventas, … y ofrecen una integración estrecha entre dichos módulos para facilitar el flujo de la información (transaccional) entre funciones. Los ERPs se construyen sobre bases de datos relacionales y, por lo general, presentan un diseño muy extenso: un gran número de entidades (por ejemplo, productos, clientes, facturas, etc.), numerosas pantallas y un alto grado de configurabilidad.

Origen y motivación

Durante los años 70, se fue haciendo evidente que los registros electrónicos presentaban múltiples ventajas en comparación con el rastro tradicional en papel. Los registros electrónicos se volvían más baratos, más rápidos y más fiables que los registros en papel. Dos invenciones que precedieron a los ERPs fueron clave para potenciar los registros electrónicos: los lectores de códigos de barras (años 50) y las bases de datos relacionales (años 70). Los lectores de códigos de barras ofrecían una forma superior de administrar los flujos de mercancías, aumentando la productividad al reducir los errores administrativos. Sin embargo, aunque los lectores de códigos de barras habían mejorado dramáticamente la captura de datos en muchas situaciones, almacenar, organizar y procesar registros electrónicos siguió siendo, durante dos décadas, un problema sin resolver del todo. Las bases de datos relacionales fueron la respuesta de la industria del software a este problema a finales de los años 70 y, cinco décadas después, las bases de datos relacionales siguen siendo la práctica dominante cuando se trata de la gestión de datos empresariales.

Sin embargo, los sistemas de bases de datos relacionales “en bruto”, tal como se vendían típicamente a principios de los años 80, resultaron ser muy costosos de implementar, ya que cada compañía estaba reinventando la manera de representar todo en su base de datos: productos, clientes, facturas, pagos, etc. Así, durante los años 80, surgió una serie de empresas de software que vendían sistemas relacionales “preconfigurados”. Más tarde, a estos productos se les conocería colectivamente como ERPs, un término acuñado en los años 90. Desafortunadamente, el acrónimo ERP es un nombre inapropiado; debería haber sido Gestión de Recursos Empresariales en lugar de Planificación. De hecho, la planificación es, en el mejor de los casos, una preocupación secundaria para los ERPs. Como se detalla a continuación, la analítica predictiva es, esencialmente, contraria al diseño central de los ERPs.

Históricamente, los ERPs ganaron tracción porque racionalizaron una serie de operaciones que anteriormente requerían un esfuerzo administrativo extenso. Por ejemplo, emitir una orden de compra a un proveedor requería rellenar un formulario con el nombre y la dirección del proveedor. Las líneas de la orden solo debían incluir referencias de productos válidas. Luego, al recibir la mercancía, las cantidades recibidas debían coincidir con las indicadas en la orden de compra original, y una vez que la entrega se consideraba conforme, se debía generar una orden de pago basada en una plantilla con el monto adecuado, la fecha que coincidiera con los términos de pago del proveedor e identificando correctamente el número de cuenta bancaria del proveedor. Todo esto se puede encontrar en el ERP y los controles de coherencia se pueden realizar fácilmente de manera automatizada.

El mercado de ERPs experimentó un crecimiento rápido a finales de los años 90, impulsado principalmente por el constante progreso en el hardware informático (procesador, memoria, almacenamiento), que se había vuelto accesible para empresas de todos los tamaños.

En los años 90, los ERPs se convirtieron en el núcleo del software en la mayoría de las grandes empresas, cuando el negocio giraba principalmente en torno al flujo de mercancías. En contraste, las empresas orientadas mayormente a los servicios usualmente adoptaron un software CRM (Customer Relationship Management) como su núcleo. Los ERPs y los CRMs comparten muchos atributos, incluyendo su diseño basado en bases de datos relacionales. Por lo general, los ERPs adoptan una perspectiva centrada en las transacciones para la mayoría de sus características, mientras que los CRMs adoptan una perspectiva centrada en el cliente.

El diseño de los ERPs

Los ERPs son diversos, ya que el mercado incluye a muchos proveedores que han continuado lanzando múltiples versiones de sus productos ERP a lo largo de varias décadas y, sin embargo, en el fondo, la mayoría de las implementaciones aún siguen líneas de diseño muy similares. Los ERPs surgieron como capas de software “preconfiguradas” implementadas sobre bases de datos relacionales. Así, el proceso de diseño de un ERP implica catalogar:

• entidades, es decir, todos los conceptos u objetos que el ERP necesita representar, tales como productos, pagos, inventarios, proveedores… Cada entidad puede involucrar una o varias tablas en la base de datos relacional subyacente. La mayoría de los ERPs definen cientos de entidades, y hasta miles en los ERPs más complejos.
• interfaces de usuario que permiten a los usuarios finales ver y editar los datos de las entidades. Estas interfaces se caracterizan por el diseño CRUD (Crear / Leer / Actualizar / Eliminar), que representa las operaciones más básicas que los usuarios finales esperan al tratar con las entidades.
• lógica de negocio que proporciona comportamientos automatizados que eliminan la necesidad de muchas tareas administrativas, las cuales pueden ser automatizadas basándose en reglas bien definidas, como convertir pedidos de clientes en facturas de clientes.

Dado que las empresas son increíblemente diversas y complejas, existe un flujo incesante de necesidades de nuevas o refinadas entidades, interfaces de usuario y lógicas de negocio que se requieren para cubrir las prácticas empresariales en evolución. Esto representa un esfuerzo masivo y continuo por parte de los proveedores de ERP. Además, este desafío se ve agravado por todas las ambigüedades que surgen al intentar atender verticales muy diversos. El mismo término, como “pago”, refleja realidades y procesos muy distintos de un sector a otro. En el software, la complejidad tiende a tener costos no lineales, es decir, soportar el doble de características en un producto cuesta mucho más que el doble del costo original.

Como resultado, los proveedores de ERP han adoptado una serie de estrategias para hacer que sus inversiones en software sean más competitivas.

Tecnología

Para hacer frente a la complejidad, la primera estrategia empleada por los proveedores de ERP consiste en desarrollar tecnologías con la intención explícita de reducir el costo asociado a manejar la complejidad.

En particular, muchos proveedores de ERP desarrollaron lenguajes DSL (Programación Específica de Dominio) que están destinados a complementar el lenguaje de consulta subyacente - actualmente, típicamente, una forma de SQL - de la base de datos relacional. A través de un DSL bien diseñado, extender el ERP (es decir, nuevas entidades, interfaces o lógica) para cubrir las especificidades de una compañía determinada se puede hacer con menos recursos en comparación con emprender el mismo esfuerzo utilizando un lenguaje de programación de propósito general.

Desde los años 2000, los proveedores de ERP de código abierto - que surgieron aprovechando las bases de datos relacionales de código abierto que estuvieron disponibles a finales de los años 90 - generalmente adoptaron una estrategia alternativa de complementos (en lugar de DSLs), donde el ERP está diseñado para ser extendido mediante la introducción de código personalizado, hecho a la medida para cada empresa cliente, y que se escribe en el mismo lenguaje de programación de propósito general que el propio ERP. Esta estrategia es más ligera de ejecutar para el proveedor de ERP (sin necesidad de diseñar un DSL), y está alineada con la naturaleza de código abierto del ERP.

Oferta

A medida que el costo de implementar y soportar las funcionalidades crece con el número total de características, la mayoría de los proveedores de ERP adoptan una estrategia de precios basada en módulos: las funcionalidades se agrupan en “módulos”, que se enfocan en áreas funcionales distintas dentro de la empresa: control de inventario, finanzas, nómina, etc. El ERP se vende por módulo, permitiendo a las empresas clientes seleccionar los módulos más urgentes y posponer los demás para inversiones futuras.

La estrategia de precios basada en módulos también proporciona al proveedor de ERP una estrategia natural de venta adicional, en la que la base de clientes existente se convierte en el objetivo principal para las ventas futuras. Las áreas de negocio que no habían sido cubiertas inicialmente por el conjunto original de módulos del ERP reciben nuevos módulos dedicados que, a su vez, pueden ser vendidos a las empresas clientes.

Esta estrategia de precios basada en módulos es un mecanismo efectivo para hacer frente a la complejidad, ya que proporciona retroalimentación directa al proveedor de ERP sobre las áreas funcionales donde la disposición a pagar es mayor. Como tal, ayuda al proveedor a priorizar correctamente sus esfuerzos en ingeniería de software.

Ecosistema

Cada funcionalidad extra añadida al ERP tiende a rendir retornos decrecientes para el proveedor de ERP que ha priorizado correctamente sus esfuerzos en ingeniería de software¹. De hecho, si esta funcionalidad no se había añadido antes, probablemente fue porque no afectaba a suficientes empresas en primer lugar. Además, las propias organizaciones -incluidos los proveedores de ERP- suelen estar sujetas a deseconomías de escala: añadir más ingenieros de software a un producto de software es notoriamente conocido por no producir ganancias lineales en el rendimiento de las mejoras aplicadas al producto.

Así, la mayoría de los proveedores de ERP adoptan una estrategia de ecosistema para delegar esos esfuerzos de desarrollo de última milla necesarios para que el ERP sea operativo en una empresa determinada a compañías de terceros, conocidas típicamente como integradores. Esos integradores cobran a las empresas clientes por la implementación y el despliegue de todas las capacidades que no ofrece el ERP “en crudo”. Históricamente, hasta los años 2000, cuando las empresas adoptaron los ERPs por primera vez, el trabajo de los integradores se centraba usualmente en la introducción de capacidades adicionales para el ERP. Hoy en día, sin embargo, la mayoría de los proyectos de ERP son actualizaciones, ya que ya existe un ERP legado. Así, el valor agregado principal del integrador es asegurar una transición sin problemas del antiguo ERP al nuevo. En la práctica, este trabajo implica migrar datos y procesos entre sistemas.

A diferencia de los proveedores de ERP que tienen una estrategia de negocio orientada principalmente al propio ERP, tratado como un activo de propiedad intelectual (IP), los integradores suelen adoptar algún tipo de tarifa por jornada. Facturan su trabajo en función de la cantidad de días trabajados y, generalmente por contrato, la propiedad intelectual del trabajo entregado recae en la misma empresa cliente.

Desarrollar un ecosistema diverso de integradores, tanto en términos geográficos como verticales, es una forma efectiva de mitigar la complejidad inherente asociada con el desarrollo de ERPs. Casi todos los grandes proveedores de ERP han desarrollado redes considerables de integradores.

Los límites de los ERPs

Los ERPs heredan la mayoría de las limitaciones de sus sistemas de bases de datos relacionales subyacentes². Luego, surgen limitaciones adicionales a partir de las estrategias de mitigación de la complejidad que acabamos de describir en la sección anterior. Estas limitaciones son particularmente interesantes porque son limitaciones de diseño y, por lo tanto, es poco probable que sean abordadas por versiones más nuevas de los ERP; de hecho, resolver esas limitaciones probablemente implicaría desnaturalizar los ERPs hasta el punto en que ya no tendría mucho sentido referirse a esos productos de software como ERPs.

Adversos a lecturas o escrituras intensivas

Las bases de datos relacionales utilizadas por los ERPs brindan las propiedades ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) con un diseño orientado extensamente a una carga de trabajo que involucra, predominantemente, operaciones pequeñas de lectura y escritura, las cuales deben realizarse con bajas latencias - típicamente una fracción de segundo - y con un volumen de lecturas y escrituras aproximadamente balanceado. Un análisis detallado de las bases de datos relacionales escapa al alcance del presente artículo, pero esta observación sobre la carga de trabajo prevista para los ERPs explica, por sí sola, muchas de las limitaciones poco entendidas de los ERPs.

Debido a su diseño basado en bases de datos relacionales, los ERPs son en gran medida inadecuados para análisis, estadísticas e informes cuando la cantidad de datos es no trivial. Acceder a una cantidad no trivial de datos en cualquier ERP -mientras las operaciones comerciales están en curso- siempre es un problema, porque cuando el sistema se queda sin recursos debido a demasiadas lecturas o escrituras de datos, el sistema se ralentiza. En la práctica, esto significa que las operaciones mundanas, como el procesamiento de códigos de barras, también se ralentizan. En el peor de los casos, toda la compañía se paraliza. Por ello, cada operación en el ERP, ya sea de lectura o escritura, debe permanecer pequeña, idealmente “trivial”. La cantidad de datos que puede considerarse no trivial ha aumentado dramáticamente en las últimas cuatro décadas, junto con hardware informático mejor y más económico. Sin embargo, las empresas aprovecharon este progreso para ampliar enormemente la cantidad de datos volcados en sus ERPs. Como resultado, los sistemas ERP actuales generalmente no son perceptiblemente más rápidos que hace dos décadas.

Por ejemplo, los ERPs son adecuados para mostrar el nivel de inventario de un SKU, o para actualizar su valor cuando se recoge o carga una unidad, pero por lo general no son aptos para mostrar la línea de tiempo diaria consolidada de las variaciones de inventario de un SKU durante los últimos tres años. Todo el segmento de Business Intelligence (BI) de productos de software surgió en los años 90 como respuesta a nivel industrial a las limitaciones analíticas de los ERPs (y de los CRMs, en realidad, de igual manera). A diferencia de los ERPs, las herramientas de BI están diseñadas en torno a hipercubos en memoria, comúnmente referidos como OLAP (Online Analytical Processing). Al renunciar a las propiedades ACID, los sistemas OLAP se vuelven dramáticamente más eficientes en términos de hardware que las bases de datos relacionales para entregar estadísticas agregadas, como ventas por día, por tienda, por categoría, etc.

Es intrigante notar que la mayoría de los proveedores de ERP no parecían estar plenamente conscientes de esta limitación de diseño en sus propios productos, incluso aquellos que surgieron después de los años 90, cuando el segmento de BI era la prueba viviente de esta situación. Por ejemplo, la mayoría de los proveedores de ERP incursionaron en características de forecast de demanda que son, por diseño, completamente contrarias a su base de datos relacional subyacente -incluso más que las simples características de informes. El forecast requiere acceso a la historia completa de los datos transaccionales de la empresa: ventas, devoluciones, niveles de inventario, descuentos, etc. Aunque el cálculo usualmente se realiza en lote durante la noche, mitigando así el problema de la escasez de recursos mencionado anteriormente, las bases de datos relacionales conllevan enormes sobrecostos accidentales al intentar llevar a cabo este tipo de cálculo. Como resultado, en la actualidad, la mayoría de los ERPs cuentan con capacidades de forecast “legado”³ que cayeron en desuso hace años, y a veces décadas.

Adverso a paradigmas nuevos o distintivos

La estrategia de catalogación de entidades utilizada por los proveedores de ERP no escala de forma lineal en términos de gestión de la complejidad. Las mejores herramientas, como se discutió anteriormente, solo ofrecen un alivio lineal —con respecto al número de entidades— mientras que los costos de complejidad crecen de forma superlineal. Como resultado, los paradigmas nuevos o distintivos suelen resultar costosos tanto en términos de costos como de retrasos para integrarlos, llegando frecuentemente al punto en el que resulta una mejor alternativa saltarse por completo el ERP. Estas situaciones son diversas, listaremos algunas de ellas a continuación, pero todas se reducen de manera similar a paradigmas que son difíciles de integrar porque llegaron tarde en el proceso de desarrollo del ERP.⁴

Lograr tiempo de inactividad operacional cero es difícil porque, como se indicó anteriormente, cualquier lectura o escritura de gran magnitud pone en riesgo al ERP de sufrir una desaceleración del sistema. Por ello, todas esas operaciones se realizan típicamente en lotes nocturnos, cuando hay pocas o ninguna operación en curso. Sin embargo, este diseño está en desacuerdo con los requerimientos de ecommerce que surgieron relativamente tarde en la historia de los ERPs. Como resultado, la mayoría de los proveedores de ERP separaron extensamente su módulo de ecommerce, aprovechando frecuentemente un sistema de base de datos separado, rompiendo la regla de diseño implícita de que todos los módulos del ERP residen en la misma(s) base(s) de datos. En consecuencia, los módulos de ecommerce respaldados por ERP tienden a ser tan difíciles y costosos de desplegar como las aplicaciones de terceros.

Tratar con verticales de remanufactura donde las mercancías siguen flujos cíclicos complejos (es decir, reparaciones), mientras que los ERPs convencionales están fuertemente orientados hacia flujos hacia adelante —de productores a consumidores— como se encuentra comúnmente en FMCG y distribución. Aunque la mayoría de las entidades relevantes necesarias para los propósitos de la remanufactura (es decir, productos, inventarios, pedidos) ya existen en los ERPs, sus diseños suelen estar completamente en desacuerdo con los requerimientos de la remanufactura. Frecuentemente, resulta más fácil reimplementar completamente dichas entidades en lugar de intentar reciclar las de un ERP convencional en esos verticales.

Proporcionar latencias garantizadas bajas, digamos por debajo de la percepción humana (es decir, por debajo de 50ms), es difícil porque ni el ERP ni su base de datos relacional han sido diseñados con tales requerimientos en mente. Sin embargo, pilotar sistemas altamente automatizados como almacenes robóticos requiere este tipo de latencias para evitar que la orquestación impulsada por el software se convierta en el cuello de botella del sistema. Así, en la práctica, la mayoría de las áreas asociadas con el procesamiento “en tiempo real” (4) cuentan con sistemas dedicados fuera del ERP.

Curiosamente, existen ERPs especializados —aunque no siempre se autodenominan ERPs— que tomaron caminos de desarrollo alternativos para hacer frente precisamente a esas situaciones. Estos ERPs suelen estar dirigidos a verticales de nicho que no son atendidos adecuadamente por los ERPs convencionales. Sin embargo, estos caminos de desarrollo alternativos suelen estar en desacuerdo con los requerimientos del mercado convencional.

Riesgos en las transiciones de ERP

Si bien puede parecer una paradoja, generalmente es mucho más difícil actualizar un ERP que simplemente desplegarlo por primera vez. Las actualizaciones son notoriamente procesos de varios años. Incluso las simples actualizaciones de versión del ERP —manteniendo al mismo proveedor— suelen resultar en labores difíciles que duran muchos meses. De forma anecdótica, esta dificultad suele aparecer en las noticias, ya que grandes empresas publican comunicados de prensa indicando que sus esfuerzos de actualización del ERP han excedido el presupuesto en cientos de millones de dólares o euros. En tales situaciones, se culpa al proveedor del ERP, al integrador y/o a la propia empresa. Sin embargo, parece que la mayoría no reconoce que tales problemas son inherentes a los propios ERPs, tal como fueron diseñados a través de las fuerzas del mercado mencionadas anteriormente.

Los costos de complejidad no escalan de forma lineal, sino superlinealmente. Cuando una empresa adopta un ERP por primera vez, tiene el lujo de adoptar gradualmente cada módulo, uno a la vez, por así decirlo. De este modo, el número de entidades / interfaces / lógicas involucradas en cada iteración es relativamente pequeño, y se pueden entregar extensiones hechas a la medida de forma gradual para hacer que el ERP sea adecuado a las necesidades de la empresa.

Sin embargo, cuando la empresa tiene que hacer la transición a otro ERP, se enfrenta entonces al problema de migrar todos los módulos al mismo tiempo. De hecho, los ERPs son, por diseño y por fuerzas económicas⁵, monolitos de software construidos sobre un pequeño conjunto de bases de datos. Así, cuando se debe desplegar el nuevo ERP, el camino de adopción incremental utilizado para el ERP original no puede ser replicado. Por lo tanto, la empresa tiene que hacer la transición de todo o nada. Como resultado, los costos de implementación inicial tienden a ser muy elevados, mientras que el estado posterior al despliegue suele ser de situaciones a medio solucionar que pueden tardar hasta varios años en arreglarse.

Técnicamente, estas actualizaciones siempre son difíciles de implementar porque la importación de las entidades / interfaces / lógicas entre el sistema antiguo y el nuevo no es un proceso uno a uno. La semántica de las entidades evoluciona con el tiempo. Por ejemplo, el proveedor del ERP podría haber empezado con una tabla llamada “Orders” que estaba destinada a los pedidos de los clientes. Sin embargo, más adelante, el proveedor debe abordar los nuevos requerimientos, no planificados originalmente, de gestionar las devoluciones de clientes. La siguiente versión del ERP recicla la tabla “Orders” para las devoluciones de clientes, sin embargo, esas líneas ahora tienen cantidades de pedido negativas. Este cambio aparentemente inocuo termina complicando enormemente la migración desde la versión antigua del ERP hasta la nueva.

Sin embargo, actualizar hacia un nuevo ERP, o hacia una versión más reciente del mismo ERP, no es la única opción para las empresas. De hecho, existen múltiples alternativas para reducir el riesgo de la transición. Naturalmente, todo el ecosistema de proveedores de ERP e integradores tiene un vivo interés financiero en promover lo contrario, como cuestión de supervivencia de su modelo económico.

Más allá del monolito

Los ERPs surgieron como un monolito de software, es decir, productos de software en los que todos los componentes internos están fuertemente acoplados, lo que era necesario para asegurar un despliegue plug-and-play de todos los módulos. Además, hasta la década de 2010, construir sistemas distribuidos —es decir, software que opera sobre una flota de máquinas en lugar de hacerlo sobre unas pocas máquinas centrales— era significativamente más difícil y costoso⁶. Así, en gran medida, los proveedores de ERP (la mayoría con décadas de antigüedad) no tuvieron más alternativa que construir sus productos como un monolito.

No obstante, a medida que la computación en la nube se volvió convencional, las herramientas y bibliotecas —con frecuencia de código abierto— se popularizaron y resultaron más accesibles. Como resultado, los costos y gastos generales asociados con el diseño de aplicaciones distribuidas han ido disminuyendo de manera constante durante la última década. La industria del software ha comenzado a replantear extensamente cómo se puede entregar el valor añadido que históricamente solo fue ofrecido por los ERPs (o software similar a ERP).

El enfoque moderno del software empresarial consiste en romper el monolito mediante una serie de aplicaciones más pequeñas que, idealmente, hacen una sola cosa y lo hacen bien⁷. Unir las aplicaciones se hace mediante APIs (Interfaces de Programación de Aplicaciones) que están precisamente destinadas a facilitar integraciones hechas a la medida en diversos entornos aplicativos. La mayoría de las APIs están diseñadas para aprovechar herramientas populares de API de código abierto que reducen significativamente los costos de desarrollo asociados con esas integraciones hechas a la medida.

Esas aplicaciones a veces tienen costos de integración iniciales más elevados que los módulos integrados en el ERP. Sin embargo, presentan beneficios a largo plazo considerables, ya que reducen en gran medida el riesgo en la evolución futura del entorno aplicativo. La empresa adquiere la opción de actualizar o reemplazar una aplicación a la vez, lo que resulta no solo mucho más fácil de ejecutar, sino también más económico y con menos riesgos. Finalmente, las aplicaciones SaaS (Software as a Service) suelen optar por una entrega continua de pequeños cambios incrementales. Aunque este patrón genera una carga de trabajo continua —pero limitada— para los equipos de TI, el proceso de cambio en SaaS es más orgánico, más económico y menos arriesgado en comparación con actualizaciones anuales o bienales.

Más allá de las bases de datos relacionales

Las bases de datos relacionales han sido la columna vertebral de facto de los ERPs desde los años 80. Sin embargo, desde la década de 2010, han surgido alternativas convincentes. La más notable es probablemente Event Sourcing (ES) combinado con Command Query Responsibility Segregation (CQRS). Este enfoque ofrece una escalabilidad y latencia superiores, al mismo tiempo que permite diseños más expresivos, es decir, capaces de capturar de forma más precisa las intenciones de negocio en diversas situaciones.

La esencia del event sourcing consiste en tratar cada cambio en el sistema como un evento inmutable. El enfoque de inmutabilidad está inspirado en las prácticas contables: cuando una línea resulta incorrecta en un libro mayor, el contador no borra la línea para solucionar el problema, sino que añade otra línea correctiva en el libro mayor. Conservar todo el historial de eventos —asumiendo que el almacenamiento de datos es lo suficientemente barato como para hacer viable esta estrategia— ofrece numerosos beneficios: mejor trazabilidad, auditabilidad, seguridad… Además, el enfoque inmutable facilita la escalabilidad de los sistemas basados en eventos. Los datos pueden ser copiados y replicados extensamente sin tener que lidiar con cambios en los mismos.

El diseño CQRS reconoce que, en la mayoría de los sistemas, los volúmenes respectivos de lecturas y escrituras están altamente desequilibrados. En muchas situaciones, el volumen de lecturas (de datos) supera al de escrituras por varios órdenes de magnitud. Sin embargo, las bases de datos relacionales están orientadas a volúmenes (algo) simétricos de lecturas y escrituras. CQRS segrega explícitamente las responsabilidades de las lecturas y las escrituras, típicamente en dos subsistemas distintos. Este diseño también ofrece beneficios, principalmente en términos de latencia, escalabilidad y eficiencia en el uso de hardware.

Sin embargo, aunque tanto ES como CQRS ya son populares en grandes empresas tecnológicas orientadas al consumidor y en el trading cuantitativo (finanzas), solo recientemente han comenzado a ganar tracción en el software empresarial convencional. Como resultado, las herramientas ES+CQRS aún están en pañales en comparación con sus contrapartes en el ámbito de las bases de datos relacionales. No obstante, este enfoque ofrece formas no solo de reducir drásticamente los costos de hardware, sino también de comprimir las latencias que con frecuencia siguen siendo un problema agudo en la mayoría de las implementaciones de ERP.

La perspectiva de Lokad

Dado que los ERPs ni siquiera son adecuados para propósitos analíticos —de ahí la necesidad de herramientas BI (Business Intelligence)— no debería sorprender que su historial sea desastroso cada vez que se involucran análisis predictivos. A modo de evidencia anecdótica, ninguna de las revoluciones de machine learning / ciencia de datos ocurrió en los ERPs, y cuando se enfrentan a ese tipo de requerimientos, los equipos invariablemente recurren a hojas de cálculo o scripts ad hoc.

El propio Lokad surgió como una aplicación especializada destinada a complementar —no a reemplazar— los ERPs como una capa analítica dedicada a la optimización predictiva de supply chains. La mayoría de nuestras funciones centrales, como las capacidades de forecast probabilístico, destinadas a apoyar decisiones mundanas tales como inventarios / compras / producción / surtido / precios, son francamente imprácticas de implementar dentro de los sistemas ERP.

Notas