Planificación de recursos empresariales (ERP)

La Planificación de Recursos Empresariales (ERP, por sus siglas en inglés) se refiere a una clase de software empresarial que respalda las operaciones rutinarias de la empresa y realiza un seguimiento de sus recursos, especialmente efectivo, materias primas, trabajo en progreso, productos finales, pedidos de clientes, órdenes de compra y nómina. Los ERPs suelen incluir muchos módulos destinados a funciones comerciales básicas, como contabilidad, adquisiciones, distribución, finanzas, ventas, … y ofrecen una integración estrecha dentro de esos módulos para facilitar el flujo de información (transaccional) entre las funciones. Los ERPs se construyen sobre bases de datos relacionales y suelen tener 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 hizo evidente que los registros electrónicos presentaban múltiples ventajas en comparación con el seguimiento en papel tradicional. Los registros electrónicos se estaban volviendo más baratos, rápidos y confiables que los registros en papel. Dos inventos que precedieron a los ERPs fueron clave para potenciar los registros electrónicos: los lectores de códigos de barras (década de 1950) y las bases de datos relacionales (década de 1970). Los lectores de códigos de barras ofrecían una forma superior de gestionar los flujos de mercancías, aumentando la productividad y reduciendo los errores administrativos. Sin embargo, aunque los lectores de códigos de barras habían mejorado drásticamente la adquisición de datos en muchas situaciones, almacenar, organizar y procesar registros electrónicos seguía siendo algo así como un problema abierto durante dos décadas. Las bases de datos relacionales fueron la respuesta de la industria del software a este problema a fines de los años 70 y, cinco décadas después, las bases de datos relacionales siguen siendo la práctica dominante en la gestión de datos empresariales.

Sin embargo, los sistemas de bases de datos relacionales sin procesar, como se vendían típicamente a principios de los años 80, resultaron ser muy costosos de implementar, ya que cada empresa estaba reinventando cómo representar todo en su base de datos: productos, clientes, facturas, pagos, etc. Así, durante los años 80, surgieron una serie de empresas de software que vendían sistemas relacionales “preconfigurados”. Estos productos luego se denominarían colectivamente ERPs, un término acuñado en los años 90. Desafortunadamente, el acrónimo ERP es un nombre incorrecto; 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 está fundamentalmente en desacuerdo con el diseño principal de los ERPs.

Históricamente, los ERPs ganaron impulso porque agilizaron una serie de operaciones que anteriormente requerían esfuerzos administrativos extensos. Por ejemplo, emitir una orden de compra a un proveedor requería completar un formulario con el nombre y la dirección del proveedor. Las líneas de pedido solo debían incluir referencias de productos válidas. Luego, al recibir la mercancía, las cantidades recibidas debían coincidir con las encontradas en la orden de compra original, y una vez que la entrega se consideraba conforme, se debía generar una orden de pago contra una plantilla con la cantidad adecuada, la fecha que coincidiera con los plazos de pago del proveedor y que identificara correctamente el número de cuenta bancaria del proveedor. Todo esto se puede encontrar en el ERP y las comprobaciones de coherencia se pueden realizar fácilmente de manera automatizada.

El mercado de los ERPs experimentó un crecimiento rápido a fines de los años 90 que se debió principalmente al progreso constante en 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 de la mayoría de las grandes empresas cuando el negocio giraba principalmente en torno al flujo de mercancías. En contraste, las empresas orientadas principalmente hacia los servicios generalmente adoptaban un software de CRM (Gestión de Relaciones con el Cliente) como su núcleo. Los ERPs y los CRMs comparten muchas características, incluido su diseño compartido sobre bases de datos relacionales. Los ERPs suelen adoptar una perspectiva centrada en transacciones en la mayoría de sus funciones, 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 muchos proveedores que han seguido lanzando muchas versiones de sus productos ERP durante varias décadas y, sin embargo, en el núcleo, la mayoría de las implementaciones siguen líneas de diseño muy similares. Los ERPs surgieron como capas de software “preconfiguradas” implementadas sobre bases de datos relacionales. Por lo tanto, el proceso de diseño de ERP implica catalogar:

• entidades, es decir, todos los conceptos u objetos que el ERP necesita representar, como productos, pagos, existencias, 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 para los ERPs más complejos.
• interfaces de usuario que permiten a los usuarios finales ver y editar los datos de las entidades. Estas interfaces están dominadas 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 entidades.
• lógica empresarial que proporciona comportamientos automatizados que eliminan la necesidad de muchas tareas administrativas, que se pueden automatizar en función de reglas bien definidas, como convertir pedidos de clientes en facturas de clientes.

Dado que las empresas son increíblemente diversas y complejas, hay una corriente interminable de necesidad de entidades, interfaces de usuario y lógicas empresariales más nuevas o refinadas que se requieren para cubrir prácticas comerciales en constante evolución. Esto representa un esfuerzo continuo masivo por parte de los proveedores de ERP. Luego, este desafío se ve agravado por todas las ambigüedades que surgen al intentar atender verticalmente muy diversos. El mismo término, como “pago”, refleja realidades y procesos muy diferentes de una vertical a otra. En el software, la complejidad tiende a tener costos no lineales, es decir, admitir 2 veces más 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 aprovechada por los proveedores de ERP consiste en desarrollar tecnologías con la intención explícita de reducir el costo asociado con el manejo de la complejidad.

En particular, muchos proveedores de ERP han diseñado lenguajes de programación específicos del dominio (DSL, por sus siglas en inglés) que están destinados a complementar el lenguaje de consulta subyacente, que suele ser una variante de SQL en la actualidad, de la base de datos relacional subyacente. A través de un DSL bien diseñado, se puede realizar la ampliación del ERP (es decir, nuevas entidades, interfaces o lógica) para cubrir las especificidades de una determinada empresa con menos recursos en comparación con emprender el mismo esfuerzo con un lenguaje de programación de propósito general.

Desde la década de 2000, los proveedores de ERP de código abierto, que surgieron aprovechando las bases de datos relacionales de código abierto que estaban disponibles a fines de la década de 1990, generalmente adoptaron una estrategia alternativa de complemento (en lugar de DSL), donde el ERP está diseñado para ser ampliado a través de la introducción de código personalizado, adaptado para cada empresa cliente, que se escribe en el mismo lenguaje de programación de propósito general que el propio ERP. Esta estrategia es más liviana de ejecutar para el proveedor de ERP (no se requiere 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 mantener características aumenta 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 características se agrupan en “módulos”, que se centran en áreas funcionales distintas dentro de la empresa: gestión de inventario, finanzas, nómina, etc. El ERP se vende por módulos, lo que permite a las empresas clientes seleccionar los módulos más urgentes y posponer los demás para inversiones posteriores.

La estrategia de precios basada en módulos también brinda al proveedor de ERP una estrategia natural de venta adicional, donde la base de clientes existente se convierte en el objetivo principal para las ventas futuras. Las áreas comerciales que inicialmente no fueron cubiertas por el conjunto original de módulos del ERP obtienen nuevos módulos dedicados que, a su vez, se pueden vender a empresas clientes.

Esta estrategia de precios basada en módulos es un mecanismo efectivo para hacer frente a la complejidad porque brinda informació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 de ingeniería de software.

Ecosistema

Cada característica adicional agregada al ERP tiende a generar rendimientos decrecientes para el proveedor de ERP que ha priorizado correctamente sus esfuerzos de ingeniería de software¹. De hecho, si esta característica no se había agregado antes, probablemente sea porque no preocupaba lo suficiente a las empresas en primer lugar. Luego, las organizaciones mismas, incluidos los proveedores de ERP, también tienden a estar sujetas a deseconomías de escala: agregar ingenieros de software adicionales a un producto de software es conocido por no generar ganancias lineales en la mejora del producto.

Por lo tanto, 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 funcione para una determinada empresa a empresas de terceros, generalmente conocidas como integradores. Esos integradores cobran a las empresas clientes por la implementación y puesta en marcha de todas las capacidades que no ofrece el ERP “puro”. Históricamente, hasta la década de 2000, cuando las empresas adoptaban ERPs por primera vez, el trabajo de los integradores se centraba generalmente en la introducción de capacidades adicionales para el ERP. Sin embargo, en la actualidad, la mayoría de los proyectos de ERP son actualizaciones, ya que ya hay un ERP heredado en su lugar. Por lo tanto, el valor agregado principal del integrador es garantizar una transición fluida 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 comercial principalmente orientada al propio ERP, tratado como un activo de propiedad intelectual (IP), los integradores suelen adoptar algún tipo de tarifas por día de trabajo. Facturan su trabajo en función de la cantidad de días trabajados y la propiedad intelectual del trabajo entregado generalmente recae, por contrato, en la propia empresa cliente.

Desarrollar un ecosistema diverso de integradores, tanto en geografías como en sectores, es una forma efectiva de mitigar la complejidad inherente asociada al desarrollo de ERP. Casi todos los grandes proveedores de ERP han desarrollado redes considerablemente grandes 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 más limitaciones 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 ERP, o más bien, resolver esas limitaciones probablemente implicaría desnaturalizar los ERPs hasta el punto en que ya no tendría mucho sentido seguir refiriéndose a esos productos de software como ERPs.

Adversos a lecturas o escrituras gruesas

Las bases de datos relacionales utilizadas por los ERPs ofrecen las propiedades ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) con un diseño orientado en gran medida a una carga de trabajo que involucra predominantemente operaciones de lectura y escritura pequeñas, que deben realizarse con bajas latencias, típicamente una fracción de segundo, con lecturas y escrituras aproximadamente equilibradas en volumen. Un análisis detallado de las bases de datos relacionales va más allá del alcance del presente artículo, pero esta observación sobre la carga de trabajo prevista para los ERPs explica, por sí sola, muchas limitaciones de los ERPs que se comprenden mal.

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 no es 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 ve privado de 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 empresa se paraliza. Por lo tanto, cada operación en el ERP, ya sea de lectura o escritura, debe seguir siendo pequeña, idealmente “trivial”. La cantidad de datos que se puede considerar no trivial ha aumentado drásticamente en las últimas cuatro décadas, junto con hardware informático mejor y más barato. Sin embargo, las empresas aprovecharon este progreso para expandir enormemente la cantidad de datos vertidos en sus ERPs también. Como resultado, los sistemas ERP actuales no suelen ser notablemente más rápidos que hace dos décadas.

Por ejemplo, los ERPs son adecuados para mostrar el nivel de stock de un SKU, o para actualizar su valor cuando se recoge o carga una unidad, pero los ERPs generalmente no son adecuados para mostrar la línea de tiempo diaria consolidada de las variaciones de stock de un SKU en los últimos tres años. El segmento completo de productos de Inteligencia de Negocios (BI) surgió en los años 90 como respuesta a las limitaciones analíticas de los ERPs (y también de los CRMs). A diferencia de los ERPs, las herramientas de BI están diseñadas en torno a hipercubos en memoria, generalmente conocidos como OLAP (Procesamiento Analítico en Línea). Al renunciar a las propiedades ACID, los sistemas OLAP son mucho más eficientes en términos de hardware que las bases de datos relacionales para proporcionar estadísticas agregadas, como ventas por día, por tienda, por categoría, etc.

Es intrigante observar que la mayoría de los proveedores de ERP parecen no estar completamente 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 se aventuraron en funciones de pronóstico de la demanda que, por diseño, están completamente en contra de su base de datos relacional subyacente, incluso más que las funciones de informes simples. El pronóstico requiere acceso a toda la historia de los datos transaccionales de la empresa: ventas, devoluciones, niveles de stock, descuentos, etc. Si bien el cálculo generalmente se realiza en lotes durante la noche, lo que mitiga el problema de escasez de recursos mencionado anteriormente, las bases de datos relacionales implican grandes sobrecargas 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 pronóstico “heredadas”³ que cayeron en desuso hace años, y a veces décadas.

Adversos a nuevos o distintivos paradigmas

La estrategia de catalogación de entidades utilizada por los proveedores de ERP no escala linealmente en términos de gestión de complejidad. Las mejores herramientas, como se discutió anteriormente, solo brindan un alivio lineal, en términos del número de entidades, mientras que los costos de complejidad crecen de manera superlineal. Como resultado, los nuevos o distintivos paradigmas suelen resultar costosos tanto en términos de costos como de retrasos para integrarse, llegando con frecuencia al punto en el que es mejor omitir por completo el ERP. Estas situaciones son diversas, enumeraremos algunas de ellas a continuación, pero todas se reducen de manera similar a paradigmas que son difíciles de integrar porque surgieron tarde en el proceso de desarrollo del ERP⁴.

Lograr cero tiempo de inactividad operativo es difícil porque, como se mencionó anteriormente, cualquier lectura o escritura grande pone en riesgo el ERP de una desaceleración del sistema. Por lo tanto, todas esas operaciones se realizan típicamente como lotes nocturnos, cuando hay pocas o ninguna operación en curso. Sin embargo, este diseño está en desacuerdo con los requisitos de comercio electrónico que surgieron relativamente tarde en la historia de los ERPs. Como resultado, la mayoría de los proveedores de ERP separaron ampliamente su módulo de comercio electrónico, aprovechando con frecuencia un sistema de base de datos separado, rompiendo la regla de diseño implícita de que todos los módulos del ERP viven en la misma base de datos. Como resultado, los módulos de comercio electrónico respaldados por ERP tienden a ser tan difíciles y costosos de implementar como las aplicaciones de terceros.

Lidiar con verticales de remanufactura donde los bienes siguen flujos cíclicos complejos (es decir, reparaciones), mientras que los ERPs principales están fuertemente orientados hacia flujos hacia adelante, desde los productores hasta los consumidores, como se encuentra comúnmente en FMCG y distribución. Si bien la mayoría de las entidades relevantes necesarias para fines de remanufactura (es decir, productos, stocks, pedidos) ya existen en los ERPs, sus diseños suelen estar completamente en desacuerdo con los requisitos de remanufactura. A menudo es más fácil volver a implementar por completo esas entidades en lugar de intentar reciclar las de un ERP principal en esas verticales.

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

Curiosamente, existen ERPs especializados, aunque no siempre se refieren a sí mismos como ERPs, que tomaron caminos alternativos de desarrollo para hacer frente precisamente a esas situaciones. Estos ERPs suelen apuntar a verticales de nicho que no son atendidas adecuadamente por los ERPs principales. Sin embargo, estos caminos alternativos de desarrollo suelen estar en desacuerdo con los requisitos principales.

Riesgos en las transiciones de ERP

Aunque pueda parecer paradójico, suele ser mucho más difícil actualizar un ERP que simplemente implementarlo por primera vez. Las actualizaciones son conocidas por ser procesos de varios años. Incluso las simples actualizaciones de versión del ERP, manteniendo el mismo proveedor, suelen resultar difíciles y llevar varios meses. Anecdóticamente, esta dificultad regularmente aparece en las noticias cuando las grandes empresas publican comunicados de prensa indicando que sus esfuerzos de actualización de ERP se han excedido en cientos de millones de dólares o euros. En tales situaciones, se culpa al proveedor de ERP, al integrador y/o a la propia empresa. Sin embargo, parece que la mayoría no reconoce que tales problemas son intrínsecos a los ERPs mismos, tal como están diseñados a través de las fuerzas del mercado mencionadas anteriormente.

Los costos de complejidad no se escalan de manera lineal sino superlineal. Cuando una empresa adopta un ERP por primera vez, tiene el lujo de adoptar gradualmente cada módulo, un módulo a la vez o algo así. Por lo tanto, el número de entidades / interfaces / lógicas involucradas en cada iteración es relativamente pequeño, y las extensiones personalizadas se pueden entregar gradualmente 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 al problema de hacer la transición de 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. Por lo tanto, cuando se tiene que implementar el nuevo ERP, no se puede replicar el camino de adopción incremental utilizado para el ERP original. La empresa tiene que hacer la transición de manera completa o no hacerla. Como resultado, los costos de implementación inicial tienden a ser muy altos, mientras que la situación posterior a la implementación tiende a ser situaciones a medio arreglar que pueden llevar varios años solucionar.

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 asunto uno a uno. La semántica de las entidades evoluciona con el tiempo. Por ejemplo, el proveedor del ERP podría haber comenzado con una tabla llamada “Pedidos” que estaba destinada a los pedidos de los clientes. Sin embargo, más adelante, el proveedor tiene que abordar los nuevos requisitos, que no estaban planeados originalmente, de gestionar las devoluciones de los clientes. La siguiente versión del ERP recicla la tabla “Pedidos” para las devoluciones de los clientes, pero estas líneas ahora tienen cantidades de pedido negativas. Este cambio aparentemente inocuo termina complicando enormemente la migración de la versión antigua del ERP a la nueva.

Sin embargo, actualizar hacia un nuevo ERP o hacia una versión posterior del mismo ERP no es la única opción para las empresas. En realidad, existen múltiples alternativas para reducir el riesgo de la transición. Naturalmente, todo el ecosistema de proveedores e integradores de ERP tiene un vivo interés financiero en promover lo contrario, como una 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 donde todos los componentes internos están estrechamente acoplados, una necesidad para garantizar una implementación plug-and-play de todos los módulos. Además, hasta la década de 2010, construir sistemas distribuidos, es decir, software que opera en una flota de máquinas en lugar de operar en unas pocas máquinas centrales, era significativamente más difícil y costoso⁶. Por lo tanto, en gran medida, los proveedores de ERP (la mayoría de ellos con décadas de antigüedad) no tenían más alternativa que construir sus productos como un monolito.

Sin embargo, a medida que la computación en la nube se hizo popular, las herramientas y bibliotecas, frecuentemente de código abierto, se volvieron más populares y accesibles. Como resultado, los costos y gastos generales asociados con el diseño de aplicaciones distribuidas han ido disminuyendo constantemente en la última década. La industria del software ha comenzado a revisar extensamente cómo se puede entregar el valor agregado que históricamente solo se entregaba mediante ERPs (o software similar a ERP).

El enfoque moderno del software empresarial consiste en romper el monolito a través de una serie de aplicaciones más pequeñas que, idealmente, hacen una sola cosa y la hacen bien⁷. La unión de las aplicaciones se realiza a través de APIs (Interfaces de Programación de Aplicaciones) que están diseñadas precisamente para facilitar integraciones personalizadas en diversos paisajes 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 personalizadas.

Estas aplicaciones a veces tienen costos de integración iniciales más altos que los módulos integrados de ERP. Sin embargo, presentan beneficios a largo plazo considerablemente mayores, ya que reducen en gran medida los riesgos de futuras evoluciones del paisaje aplicativo. La empresa tiene la opción de actualizar o reemplazar una aplicación a la vez, lo que no solo resulta mucho más fácil de ejecutar, sino también más barato y con menos riesgos. Finalmente, las aplicaciones SaaS (Software como Servicio) suelen optar por una entrega continua de pequeños cambios incrementales. Si bien este patrón genera una carga de trabajo continua, pero limitada, para los equipos de TI, el proceso de cambio de SaaS es más orgánico, más barato y menos arriesgado en comparación con las actualizaciones anuales o bianuales.

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 la década de 1980. Sin embargo, desde la década de 2010 han surgido alternativas convincentes. La más notable es probablemente Event Sourcing (ES) junto con Command Query Responsibility Segregation (CQRS). Este enfoque ofrece una escalabilidad y latencia superiores, al tiempo que permite diseños más expresivos, es decir, capaces de capturar de manera más precisa las intenciones comerciales en diversas situaciones.

La esencia del event sourcing consiste en tratar cada cambio en el sistema como un evento inmutable. El ángulo 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, en su lugar agrega otra línea correctiva en el libro mayor. Mantener todo el historial de eventos, asumiendo que el almacenamiento de datos es lo suficientemente económico como para hacer que esta estrategia sea viable, ofrece numerosos beneficios: mejor trazabilidad, auditabilidad, seguridad, etc. Además, el enfoque inmutable facilita la escalabilidad de los sistemas basados en eventos. Los datos se pueden copiar y replicar ampliamente sin tener que lidiar con cambios en los datos.

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 ampliamente el volumen de escrituras en varios órdenes de magnitud. Sin embargo, las bases de datos relacionales están diseñadas para volúmenes de lecturas y escrituras (algo) simétricos. CQRS separa explícitamente las responsabilidades de lecturas y escrituras, generalmente en dos subsistemas distintos. Este diseño también ofrece beneficios, principalmente en términos de latencia, escalabilidad y eficiencia de hardware.

Sin embargo, si bien ES y CQRS ya son populares en grandes empresas tecnológicas orientadas al consumidor y en el trading cuantitativo (finanzas), recientemente han comenzado a ganar impulso en el software empresarial convencional. Como resultado, las herramientas de ES+CQRS aún están en sus primeras etapas en comparación con sus contrapartes en el ámbito de las bases de datos relacionales. Sin embargo, este enfoque ofrece formas de no solo 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 opinión de Lokad

Dado que los ERPs ni siquiera son adecuados para fines analíticos, de ahí la necesidad de herramientas de BI (Inteligencia de Negocios), no debería sorprender que su historial sea lamentable cuando se trata de análisis predictivos. A modo de evidencia anecdótica, ninguna de las revoluciones de aprendizaje automático / ciencia de datos ha ocurrido en los ERPs, y cuando se enfrentan a ese tipo de requisitos, los equipos invariablemente recurren a hojas de cálculo o scripts ad hoc.

Lokad mismo surgió como una aplicación especializada destinada a complementar, no reemplazar, los ERPs como una capa analítica dedicada a la optimización predictiva de las cadenas de suministro. La mayoría de nuestras características principales, como las capacidades de pronóstico probabilístico, destinadas a respaldar decisiones mundanas como stocks / compras / producción / surtido / precios, son prácticamente impracticables de implementar dentro de los sistemas ERP.

Notas