Por Joannes Vermorel, marzo de 2020Cuando se habla de un sistema ERP (planificación de recursos empresariales) se hace referencia a una clase de software empresarial que respalda las operaciones rutinarias de una empresa y hace un seguimiento de sus recursos, principalmente flujo de caja, materias primas, trabajo en curso, productos finales, pedidos de clientes, pedidos de compra y nómina. Los sistemas ERP generalmente incluyen módulos pensados para funciones de negocio claves, como contabilidad, compras, distribución, finanzas, ventas, etc., y ofrecen una estrecha integración entre esos módulos para facilitar el flujo de la información (transaccional) entre funciones. Los sistemas ERP se construyen sobre bases de datos relacionales y su diseño es generalmente bastante amplio: incluye una gran cantidad de entidades (por ej., productos, clientes, facturas, etc.)., numerosas pantallas y un alto grado de configurabilidad.
Cómo surgieron y por qué
Durante los años 70, se volvió cada vez más evidente que los registros electrónicos tenían múltiples ventajas con respecto a los registros tradicionales en papel. Comparados con estos últimos, los registros electrónicos se estaban volviendo más económicos, rápidos y fiables. Hubo dos invenciones que precedieron a los sistemas ERP y que resultaron claves para impulsar la adopción de 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 ofrecieron un modo superior de gestionar los flujos de bienes, aumentando la productividad y reduciendo al mismo tiempo los errores administrativos. Sin embargo, aunque estos lectores mejoraron drásticamente la adquisición de datos en muchas situaciones, el almacenamiento, la organización y el procesamiento de registros electrónicos seguirían siendo problemas irresueltos durante otras dos décadas. A fines de los años 70, las bases de datos relacionales aparecieron como la respuesta de la industria de software a este problema y, cinco décadas después, estas bases de datos siguen siendo la práctica dominante cuando se trata de la gestión de datos de negocios.
Sin embargo, la implementación de los sistemas de bases de datos relacionales aislados, como generalmente se vendían a principios de los años 80, resultó ser muy costosa, ya que cada empresa estaba reinventando la manera de representar todos los elementos de su base de datos: productos, clientes, facturas, pagos, etc. Así fue como, durante los años 80, aparecieron toda una serie de empresas de software que vendían sistemas relacionales "preconfigurados". Estos productos se conocerían más tarde como sistemas ERP, un término acuñado en los años 90. Lamentablemente, el acrónimo ERP es, en realidad, una denominación inexacta, ya que, en lugar de "planificación", debería haberse utilizado "gestión" recursos empresariales. De hecho, la planificación es, en el mejor de los casos, una cuestión secundaria para los ERP. Como se detalla a continuación, las analíticas predictivas son básicamente antagónicas al diseño esencial de los ERP.
Históricamente, los ERP se popularizaron porque optimizaban series de operaciones que antes requerían importantes esfuerzos de parte del personal administrativo. Por ejemplo, el envío de un pedido de compra a un proveedor requería rellenar un formulario con el nombre y la dirección del proveedor. Las líneas de pedido debían incluir solo referencias de producto válidas. Luego, cuando se recibían las mercancías, las cantidades recibidas debían coincidir con las que se encontraban en el pedido de compra original y, una vez que se había determinado que la entrega era
adecuada, debía generarse un pedido de pago con una plantilla que incluyera el monto correcto, la fecha que coincidiera con los términos de pago del proveedor y el número correcto de cuenta bancaria del proveedor. Todos esos pasos pueden encontrarse en el sistema ERP, y las verificaciones de coherencia pueden realizarse fácilmente en forma automatizada.
El mercado de los sistemas ERP creció rápidamente a fines de los años 90, un crecimiento que se vio impulsado en gran medida por el progreso constante en el hardware informático (procesadores, memoria, almacenamiento), que se había vuelto accesible para empresas de todas las dimensiones.
En los años 90, los sistemas ERP se convirtieron en el software central para la mayoría de las grandes empresas en las que el negocio giraba en torno al flujo de mercancías. Las empresas orientadas principalmente a los servicios, en cambio, tendieron a adoptar un software CRM (gestión de relaciones con clientes) como sistema principal. Los sistemas ERP y los sistemas CRM tienen muchos atributos en común, incluido el hecho de que su diseño se apoya en bases de datos relacionales. Los sistemas ERP generalmente adoptan un abordaje centrado en las transacciones en la mayoría de sus funciones, mientras que los sistemas CRM adoptan un abordaje centrado en el cliente.
El diseño de los sistemas ERP
Los sistemas ERP son diversos, ya que el mercado se compone de muchos proveedores que han ido introduciendo diferentes versiones de sus sistemas ERP a lo largo de las últimas décadas; no obstante, la el diseño de la mayoría de las implementaciones sigue siendo bastante similar. Los sistemas ERP surgieron como capas de software "preconfiguradas" implementadas sobre bases de datos relacionales. El proceso de diseño del sistema ERP implica, por lo tanto, la catalogación de los siguientes elementos:
- Entidades, es decir, todos los conceptos y objetos que el sistema ERP debe representar, como productos, pagos, stocks, proveedores, etc. Cada entidad puede implicar una o varias tablas en la base de datos relacional subyacente. La mayoría de los ERP definen cientos de entidades y hasta miles en el caso de los ERP más complejos.
- Interfaces de usuario que les permiten a los usuarios finales ver y editar los datos de las entidades. Estas interfaces están dominadas por el diseño CRUD (Create/Read/Update/Delete o Crear/Leer/Actualizar/Eliminar), que representa las operaciones más básicas que los usuarios finales esperan para la gestión de las entidades.
- Lógica de negocios, que proporciona comportamientos automatizados que eliminan la necesidad de muchas tareas administrativas que pueden automatizarse sobre la base de reglas bien definidas, como la conversión de pedidos de clientes en facturas.
Debido a que las empresas son muy diferentes y complejas, existe una necesidad interminable de entidades nuevas o perfeccionadas, interfaces de usuario y lógicas de negocios necesarias para adaptarse a las prácticas de negocios cambiantes. Esto representa un enorme esfuerzo continuo de parte de los proveedores de sistemas ERP. Y este desafío resulta aún más complejo cuando se suman las ambigüedades que surgen cuando se intenta servir a sectores muy diversos. Un mismo término, como
pago, refleja realidades y procesos muy diferentes entre un sector y otro. En el ámbito del software, la complejidad tiende a tener costos no lineales: admitir el doble de funciones en un producto cuesta mucho más que el doble del costo original.
Como consecuencia, los proveedores de sistemas ERP han adoptado una serie de estrategias para hacer que las inversiones en sus softwares resulten más competitivas.
Tecnología
Para afrontar la complejidad, la primera estrategia utilizada por los proveedores de ERP consiste en desarrollar tecnologías con la intención explícita de disminuir costo asociado con la gestión de la complejidad.
En particular, muchos proveedores de ERP desarrollaron lenguajes DSL (programación específica de dominio) que tienen el objetivo de complementar el lenguaje de consulta utilizado —generalmente alguna forma del SQL actual— por la base de datos relacional subyacente. A través de un lenguaje DSL bien diseñado es posible ampliar el sistema ERP (es decir, nuevas entidades, interfaces y lógica) para cubrir las especificidades de una determinada empresa con menos recursos de los que serían necesarios con un lenguaje de programación genérico.
A partir del 2000, los proveedores de sistemas ERP
de código abierto —que surgieron aprovechando las bases de datos relacionales de código abierto que aparecieron a fines de los años 90— adoptaron en general una estrategia de complemento alternativo (en lugar de lenguajes DSL) en la que el ERP está diseñado para ser ampliado mediante la introducción de código personalizado, ajustado para cada empresa y escrito en el mismo lenguaje de programación genérico que el ERP mismo. Esta estrategia resulta más
liviana de ejecutar para el proveedor de ERP (no es necesario diseñar ningún lenguaje DSL) y se alinea con la naturaleza de código abierto del ERP.
Oferta
A medida que el costo de implementar y respaldar funciones aumenta con la cantidad de funciones global, la mayoría de los proveedores de sistemas ERP adoptan una estrategia de precios basada en módulos: las funciones se agrupan en
módulos que se concentran en diferentes áreas funcionales de la empresa: gestión del inventario, finanzas, nómina, etc. El sistema ERP se vende por módulos, lo que les permite a las empresas elegir los módulos que más necesitan y retrasar la compra de los demás, dejándolos para inversiones futuras.
La estrategia de precios basada en módulos también le da al proveedor de ERP una estrategia de venta ascendente en la que base de clientes existente se vuelve el objetivo principal de ventas futuras. Llegado el momento, las áreas de negocios no contempladas originalmente en el conjunto de módulos original del ERP podrán contar con nuevos módulos dedicados que podrán a su vez, venderse a empresas cliente.
Esta estrategia de fijación de precios basada en módulos es un mecanismo eficaz para gestionar la complejidad, porque proporciona un feedback directo al proveedor del sistema ERP sobre las áreas funcionales por las que los clientes están más dispuestos a pagar. Y, por lo tanto, le ayuda al proveedor a priorizar correctamente sus esfuerzos de desarrollo.
Entorno
Cada función adicional que se agrega al ERP tiende a generar un retorno menor para el proveedor de ERP que ha priorizado correctamente sus esfuerzos de desarrollo de software (1). De hecho, si esa función no se había agregado antes, probablemente sea porque no era de interés para muchas empresas. También es verdad que las organizaciones mismas —los proveedores de ERP incluidos— tienden a estar sujetas a deseconomías de escala: es bien sabido que agregar ingenieros de software al equipo de desarrollo de un producto de software no genera ganancias lineales en la producción de mejoras aportadas al producto.
Por lo tanto, la mayoría de los proveedores de ERP adoptan una estrategia de entorno para delegar a empresas terceras (generalmente conocidas como
integradores) esos esfuerzos de desarrollo de
última milla necesarios para poner en funcionamiento al sistema ERP para una determinada empresa. Esos integradores les cobran a las empresas cliente por la implementación y la puesta en marcha de todas las funcionalidades no incluidas en el ERP "básico". Históricamente, hasta el año 2000, cuando las empresas comenzaron a adoptar los sistemas ERP por primera vez, el trabajo de los integradores generalmente consistía en tareas relacionadas con la introducción de funciones adicionales para el ERP. Hoy en día, en cambio, la mayoría de los proyectos de sistemas ERP son
actualizaciones, ya que el ERP
heredado ya está implementado. Por lo tanto, el principal valor agregado del integrador es el de asegurar una transición sin problemas del antiguo ERP al nuevo. En la práctica, este trabajo implica la migración de datos y procesos entre sistemas.
A diferencia de los proveedores de ERP que tienen una estrategia de negocios principalmente orientada al sistema ERP en sí mismo, tratado como activo de PI (propiedad intelectual), los integradores generalmente adoptan alguna forma de cobro por días-hombre. Facturan su trabajo de acuerdo con la cantidad de días trabajados y la PI del trabajo entregado generalmente se cede, por contrato, a la empresa cliente.
El desarrollo de un ecosistema diverso de integradores, tanto geográficamente como en términos de sectores, es un modo eficaz de mitigar la complejidad inherente al desarrollo de sistema ERP. Casi todos los grandes proveedores de sistemas ERP han desarrollado grandes redes de integradores.
Los límites de los sistemas ERP
Los sistemas ERP heredan la mayoría de las limitaciones de los sistemas de base de datos relacionales subyacentes (2). Y luego se agregan más limitaciones provenientes de las estrategias de mitigación de la complejidad que acabamos de describir en la sección anterior. Estas limitaciones son particularmente interesantes porque se trata de limitaciones
de diseño y, por lo tanto, es poco probable que sean abordadas por versiones de ERP más nuevas o, mejor dicho, es probable que la resolución de esas limitaciones implique desnaturalizar el sistema ERP hasta tal punto que ya no tendría mucho sentido seguir llamándolos sistemas ERP.
Adversos a lecturas o escrituras rudimentarias
Las bases de datos relacionales utilizadas por los sistemas ERP aportan propiedades ACID (atomicidad, consistencia, aislamiento y durabilidad) con un diseño orientado principalmente a una carga de trabajo de pequeñas operaciones de lectura y escritura que deberían realizarse con baja latencia —generalmente, una fracción de segundo— y con volúmenes relativamente equilibrados. Un análisis detallado de las bases de datos relacionales excede el alcance de este artículo, pero esta observación con respecto la
carga de trabajo planeada para los ERP explica, por sí sola, muchas de las poco comprendidas limitaciones de los sistemas ERP.
Debido a su diseño basado en bases de datos relacionales, los sistemas ERP resultan inadecuados para analíticas, estadísticas y generación de informes cuando la cantidad de datos es muy grande. El acceso a cantidades de datos importantes en cualquier sistema ERP —mientras las operaciones de negocio están en curso— es
siempre problemático, porque cuando el sistema se ve exigido por demasiadas lecturas o escrituras, se hace lento. En la práctica, esto significa que también operaciones rutinarias, como el procesamiento de códigos de barras, se hacen más lentas. Y, en el peor de los casos, toda la empresa se detiene. Por lo tanto, cada operación en el sistema ERP, sea de lectura o de escritura, debe ser pequeña, idealmente
trivial. Gracias a la mejora del hardware informático y la disminución de sus costos, en los últimos 40 años la cantidad de datos que hoy puede considerarse no trivial ha aumentado drásticamente. El problema es que las empresas aprovecharon este progreso para aumentar enormemente la cantidad de datos que vuelcan a sus sistemas ERP. Como consecuencia, los sistemas ERP actuales no parecen mucho más rápidos que lo que eran hace dos décadas.
Por ejemplo, los sistemas ERP resultan muy útiles para mostrar el nivel de stock de una
SKU o para actualizar su valor cuando se recoge o se carga una unidad; no son, sin embargo, adecuados para mostrar la cronología diaria consolidada de las variaciones de stock de una SKU a lo largo de los últimos tres años. Todo el segmento de inteligencia de negocios (BI) de los productos de software surgió en los años 90 como respuesta de la industria a las limitaciones de los sistemas ERP (y también de los sistemas CRM). A diferencia de los sistemas ERP, las herramientas de BI se diseñan en torno a
hipercubos in-memory, generalmente llamados OLAP (procesamiento analítico en línea). Al resignar las propiedades ACID, los sistemas OLAP se vuelven muchísimo 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 curioso notar que la mayoría de los proveedores de ERP no parecen ser del todo conscientes de esta limitación de diseño de 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 cuestión. Por ejemplo, la mayoría de los proveedores de ERP se aventuraron a desarrollar funciones de pronóstico de la demanda que, por diseño, se oponen a su base de datos relacionales, incluso más que las funciones de
generación de informes simples. El pronóstico requiere acceso a todo el historial de datos transaccionales de una empresa: ventas, devoluciones, niveles de stock, descuentos, etc. Mientras que los cálculos generalmente están pensado para ser realizados durante la noche para mitigar el problema de sobreexigencia del sistema mencionado anteriormente, las bases de datos relacionales generan sobrecargas accidentales importantes cuando intentan realizar este tipo de cálculo. Como resultado, en la actualidad, la mayoría de los sistemas ERP incluyen funciones de pronóstico
heredadas (3) que dejaron de usarse hace años o, en algunos casos, décadas.
Adversos a paradigmas nuevos o distintos
La estrategia de catalogación de entidades utilizada por los proveedores de sistemas ERP no escala de forma lineal en términos de gestión de la complejidad. Mejores herramientas, como se comentaba anteriormente, solo aportan un alivio lineal —con respecto a la cantidad de entidades—, mientras que los costos de complejidad aumentan en forma superlineal. Como consecuencia, paradigmas nuevos o distintos resultan ser generalmente costosos, tanto en términos de costos como de retrasos en la integración, y a menudo llegan al punto en que es mejor evitar el sistema ERP por completo y optar por una alternativa. Estas situaciones son diversas, por lo que a continuación incluiremos una lista solo de algunas de ellas. Sin embargo, en general todas se reducen a paradigmas que son difíciles de integrar porque llegaron
tarde al proceso de desarrollo del ERP (4).
Lograr un
tiempo de parada operativa cero es difícil, porque, como señalábamos antes, cualquier lectura o escritura importante puede generar una desaceleración general del sistema ERP. Es por eso que todas esas operaciones generalmente se realizan en lotes nocturnos, cuando son pocas o ninguna las operaciones en curso. Sin embargo, este diseño se opone a los requerimientos del e-commerce, que apareció relativamente tarde en la historia de los ERP. Como consecuencia, la mayoría de los proveedores de sistemas ERP separaron claramente su módulo de e-commerce, a menudo utilizando un sistema de base de datos separado, rompiendo con la regla de diseño implícita de que todos los módulos de ERP deben residir en la misma o las mismas bases de datos. Es por esa razón que los módulos de e-commerce respaldados por el ERP tienden a ser tan difíciles y costosos de implementar como las aplicaciones terceras.
Algo similar sucede con los sectores de la
refabricación, en los que las mercancías siguen flujos cíclicos (reparaciones), mientras que los ERP están fuertemente orientados a los flujos
hacia delante —de los productores a los consumidores—, como sucede generalmente en los sectores de los productos FMCG y la distribución. Si bien la mayoría de las entidades relevantes necesarias para los fines de la refabricación (es decir, productos, stocks, pedidos) ya existen en los sistemas ERP, sus diseños generalmente son completamente antagónicos a los requerimientos de la refabricación. A menudo resulta más fácil volver a implementar de cero esas entidades que intentar reciclar las de un sistema ERP convencional en esos sectores.
Entregar
latencias bajas garantizadas, digamos por debajo de la percepción humana (es decir, de menos de 50 ms), es difícil, porque ni el sistema ERP ni su base de datos relacionales han sido diseñados teniendo en cuenta esos requerimientos. Y sin embargo, la operación de sistemas altamente automatizados, como almacenes robóticos, requiere este tipo de latencias para evitar que la organización impulsada por el software se vuelva un cuello de botella del sistema. Es por esta razón que, 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.
Resulta interesante que haya sistemas ERP especializados —no siempre denominados ERP— que han adoptaron caminos de desarrollo alternativos para afrontar precisamente esas situaciones. Estos sistemas ERP generalmente se dirigen a sectores de nicho para los que los sistemas ERP convencionales no resultan adecuados. Sin embargo, esos caminos de desarrollo alternativos generalmente se oponen a los requisitos convencionales.
Riesgos de las transiciones en sistemas ERP
Si bien puede parecer una paradoja, a menudo resulta más difícil
actualizar un ERP que
implementarlo por primera vez. Las actualizaciones son famosas por acabar siendo procesos de varios años. Incluso la simple actualización de
versión del ERP —manteniendo el mismo proveedor— resulta ser una empresa difícil que puede llevar varios meses. A título ilustrativo, esta dificultad a menudo llega a los titulares cuando grandes empresas publican comunicados de prensa indicando que los esfuerzos de actualización de su sistema ERP han excedido el presupuesto de cientos de millones de dólares o euros. En esas situaciones, se culpa al proveedor del ERP, al integrador o a la empresa misma . Sin embargo, parece que la mayoría no logra reconocer que esos problemas con intrínsecos a los
sistemas ERP mismos, por su mismo diseño, como se explicaba anteriormente.
Los costos de la complejidad no escalan en forma lineal sino superlineal. Cuando una empresa adopta un sistema ERP por primera vez, tiene el privilegio de adoptar gradualmente cada módulo, un módulo a la vez o similar. Por lo tanto, la cantidad de entidades/interfaces/lógicas involucradas en cada iteración es relativamente pequeña y es posible entregar extensiones a medida y en forma gradual para hacer que el ERP responda a las necesidades de la empresa.
Sin embargo, cuando la empresa debe pasar a otro ERP, se enfrenta al problema de tener que pasar
todos los módulos al mismo tiempo. De hecho, los sistemas ERP son, por diseño y debido a las fuerzas económicas (5),
monolitos de software construidos sobre pequeños conjuntos de bases de datos. Por lo tanto, cuando se debe implementar el nuevo ERP, no es posible replicar el camino de adopción
progresivo utilizado para el ERP original. La empresa debe, entonces, hacer una transición de todo o nada. Como consecuencia, los costos de implementación iniciales tienden a ser significativos, mientras que el resultado de la implementación suele ser un sistema que funciona a medias y que lleva años reparar.
Técnicamente, estas actualizaciones son siempre difíciles de implementar debido a que en la importación de las entidades/interfaces/lógicas del sistema antiguo al nuevo no hay una equivalencia de uno a uno. La semántica de estas entidades evoluciona con el tiempo. Por ejemplo, el proveedor del sistema ERP puede haber comenzado con una tabla llamada "Pedidos" que estaba pensada para los pedidos de clientes. Sin embargo, con el tiempo, el proveedor puede haber tenido que dar respuesta a nuevos requisitos de gestión de devoluciones de clientes, algo que no estaba planificado originalmente. La versión siguiente del ERP recicla la tabla "Pedidos" para las devoluciones de clientes, pero esas líneas ahora tienen cantidades de pedido
negativas. Este cambio aparentemente inocuo acaba complicando muchísimo la migración de la versión antigua del ERP a la nueva.
Sin embargo, la actualización a un nuevo ERP, o hacia la última versión del mismo ERP, no es la
única opción para las empresas. Existen, de hechos, muchas alternativas disponibles para disminuir 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, por el simple hecho de que así se aseguran la supervivencia de su modelo económico.
Más allá del monolito
Los ERP nacieron como un
monolito de software, es decir, como productos de software en los que los componentes internos están estrechamente vinculados, algo que asegura una implementación
plug-and-play de todos los módulos. Además, hasta la década de 2010, el diseño de sistemas distribuidos —es decir, software que opera sobre una flota de máquinas en lugar de operar sobre unas pocas máquinas centrales— era significativamente más difícil y costoso (6). Por lo tanto, muchos proveedores de ERP (la mayoría de ellos con décadas de trayectoria) no tuvieron otra alternativa que realizar sus productos como monolitos.
Sin embargo, cuando la computación en la nube se convirtió en estándar, las herramientas y las bibliotecas —a menudo de código abierto— se volvieron más populares y más accesibles. Como resultado, los costos y los costos adicionales asociados con el diseño de aplicaciones distribuidas ha ido disminuyendo en forma constante en los últimos diez años. La industria del software ha comenzado a rever el modo en que puede entregarse el valor agregado que históricamente solo entregaban los sistemas ERP (o softwares similares a los ERP).
El abordaje moderno de los softwares empresariales consiste en dividir el monolito en una serie de aplicaciones más pequeñas que, idealmente, hacen una sola cosa y la hacen bien (7). Las aplicaciones se combinan a través de API (interfaces de programación de aplicación) que están especialmente pensadas para facilitar integraciones a medida en entornos aplicativos diversos. La mayoría de las API están diseñadas para aprovechar las populares herramientas de API de código abierto que disminuyen significativamente los costos relacionados con esas integraciones a medida.
Esas aplicaciones a veces tienen costos iniciales de integración mayores que los módulos de ERP integrados. Sin embargo, aportan grandes beneficios a largo plazo, ya que disminuyen enormemente el riesgo de evoluciones posteriores del entorno aplicativo. La empresa obtiene la posibilidad 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 menores riesgos. Por último, las aplicaciones SaaS (software como servicio) generalmente optan por una entrega continua de pequeños cambios graduales. Si bien este patrón genera una carga de trabajo continua —aunque limitada— para los equipos de TI, el proceso de cambio de SaaS es más orgánico, menos costoso y con menos riesgos si se lo compara con las 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 sistemas ERP desde los años 80. Sin embargo, a partir de la década de 2010, han ido apareciendo alternativas interesantes. La más destacada probablemente sea el
Event Sourcing (ES) o abastecimiento de eventos, combinado con la
Command Query Responsibility Segregation (CQRS) o segregación de responsabilidad de consulta de comandos. Este abordaje ofrece una escalabilidad y una latencia superiores, al tiempo que permite diseños más expresivos, es decir, capaces de captar con mayor detalle las intenciones de negocios en varias situaciones.
La idea del
event sourcing consiste en tratar cada cambio en el sistema como un evento inmutable. El perspectiva de la inmutabilidad se inspira en las prácticas de contabilidad: cuando una línea resulta incorrecta en un libro contable, el contador no borra la línea para solucionar el problema, sino que agrega otra línea correctiva en el libro. El mantenimiento de todo el historial de eventos —suponiendo que el almacenamiento de datos es lo suficientemente económico como para hacer que esta estrategia sea viable— aporta numerosos beneficios: mejor trazabilidad, auditabilidad, seguridad, etc. Además, la perspectiva inmutable hace que los sistemas impulsados por eventos sean más fáciles de escalar. Los datos pueden copiarse en forma extensiva y replicarse sin tener que ocuparse de los 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 es altamente desequilibrado. En muchas situaciones, el volumen de lecturas (de datos) supera por mucho el volumen de escrituras. Sin embargo, las bases de datos relacionales están orientadas hacia volúmenes (relativamente) simétricos de lecturas y escrituras. La CQRS segrega en forma explícita las responsabilidades de lecturas y escrituras, generalmente en dos subsistemas distintos. Este diseño también aporta beneficios, principalmente en términos de latencia, escalabilidad y eficiencia de hardware.
Sin embargo, si bien tanto el ES como la CQRS ya son populares en grandes empresas de tecnología orientadas al consumidor y en el trading (financiero) cuantitativo, solo recientemente han comenzado a ganar terreno en el sector del software empresarial convencional. Las herramientas ES+CQRS siguen siendo aún incipientes con respecto a sus pares en el ambiente de las bases de datos relacionales. No obstante, este abordaje ofrece maneras no solo de reducir significativamente los costos de hardware, sino también de comprimir las latencias que a menudo siguen siendo un problema importante para la mayoría de las implementaciones de sistemas ERP.
La postura de Lokad
Debido a que los ERP no son siquiera adecuados para finalidades analíticas — y de ahí la necesidad de herramientas de BI (inteligencia de negocios)—, no debería sorprender que su historial sea desalentador cuando se trata de analíticas
predictivas. Como evidencia anecdótica, ninguna de las revoluciones de machine learning/ciencia de datos sucedió en los sistemas ERP y, al enfrentarse a esas clases de requisitos, los equipos sistemáticamente recurrían a las hojas de cálculo o a scripts
ad hoc.
Lokad mismo surgió como una aplicación especializada pensada para complementar —no reemplazar— a los sistemas ERP como capa analítica dedicada a la optimización predictiva de las cadenas de suministro. La mayoría de nuestras funciones centrales, como el
pronóstico probabilístico, pensadas para respaldar decisiones rutinarias, como stocks, compras, producción, surtido, fijación de precios, que no sería posible implementar en sistemas ERP.
Notas
(1) Esta visión es más bien simplista. En la práctica, en las últimas décadas, la ingeniería de software ha dado un enorme salto hacia adelante junto con los recursos de computación básicos. Como resultado, las funcionalidades que hubiera sido excesivamente costoso desarrollar en los años 80 pueden haberse vuelto mucho más económicas una décadas después. Los proveedores de ERP vuelven a priorizar sus esfuerzos de desarrollo teniendo en cuenta este fenómeno.
(2) Históricamente, los primeros sistemas ERP de los años 70 o, mejor dicho, las piezas de software de estilo ERP (ya que el sistema ERP surgiría más tarde) recurrían a bases de datos rudimentarias de archivos planos. Las bases de datos relacionales surgieron como alternativa superior a esas bases de datos de archivos planos en prácticamente cada esquina. Es por eso que los primeros proveedores de sistemas ERP actualizaron su diseño utilizando las bases de datos relacionales. Sin embargo, en lo que tiene que ver con procesos de datos en lote de bases de datos completas, las bases de datos de archivos planos siguieron siendo superiores en la práctica —a igualdad de inversión en hardware de computación— hasta que la forma en columnas de las bases de datos relacionales se popularizó en la década de 2010.
(3) Debido a que muchos proveedores de sistemas ERP intentaron realizar y entregar
funciones de pronóstico, los proveedores de base de datos, a su vez, intentaron realizar y entregar
funcionalidades de pronóstico en sus sistemas. Por lo que sabemos, esas funcionalidades
de pronóstico nativas de las bases de datos son tan omnipresentes como inutilizadas (o muy compensadas manualmente con hojas de cálculo de Excel), preservadas solo para permitir la compatibilidad retroactiva por parte de los proveedores.
(4) El procesamiento en tiempo real es un término relativamente subjetivo. Técnicamente, la velocidad de la luz misma impone duros límites a las latencias que pueden obtenerse con sistemas distribuidos. La objetivo de contar con un sistema ERP es poder coordinar proveedores, plantas, almacenes, etc., que están geográficamente dispersos.
(5) El atractivo comercial de una estrategia de precios por módulos es que agregar un nuevo módulo sea (casi) una experiencia
plug-and-play para la empresa cliente. Sin embargo, el precio que se paga, en cuanto al diseño, por esta facilidad de adopción es una combinación pesada entre los módulos, es decir, un diseño monolítico. Tocar cualquier módulo afecta a muchos de los demás.
(6) Los sistemas informáticos distribuidos existen desde hace décadas. Sin embargo, hasta que la
computación en la nube se volvió moneda corriente alrededor de la década de 2010, casi todas las piezas de software empresarial se realizaban en torno a una arquitectura cliente-servidor, que centraliza todos los procesos y los datos en un puñado de máquinas, generalmente un front-end, un back-end y una base de datos. En cambio, la computación en la nube implica una
flota de máquinas, tanto para finalidades de fiabilidad como de rendimiento.
(7) Esta fue originalmente la filosofía de diseño Unix. Después de 2010, las aplicaciones empresariales especializadas generalmente no son tan estrechas ni concentradas como las herramientas Unix. Sin embargo, estas aplicaciones ya son el doble de complejas (o más) que los sistemas ERP. Además, este abordaje no debería confundirse con los microservicios, que es un modo de diseñar internamente las aplicaciones mismas.
