El juego de la plataforma ERP: Más barato, más rápido, mejor

| Artículo

Nota: Hacemos nuestro mejor esfuerzo por preservar el espíritu original y los matices de nuestros artículos. Sin embargo, nos disculpamos de antemano por cualquier falla de traducción que pueda notar. Agradecemos sus comentarios en reader_input@mckinsey.com

La actualización de un sistema de planificación de recursos empresariales es una de las decisiones más grandes y costosas que habrán de tomar los líderes de TI. A menudo puede costar hasta $500 millones de dólares, durar varios años y determinar elementos importantes del modelo operativo de la empresa para la próxima década.

Más perspectivas de McKinsey en Español

Mire nuestra colección de artículos en Español y suscríbase a nuestro newsletter mensual en Español.

Navegue por la colección

Antes de tomar esa decisión, los directores de informática (Chief Information Officers, o CIO) podrían beneficiarse de comprender cómo las empresas tecnológicas abordan los cambios en su entorno de sistemas. Estas empresas valoran la velocidad, la flexibilidad y la escala para crear valor para el negocio. Eso significa que toman decisiones tecnológicas que maximizan la libertad y la independencia de sus desarrolladores al reducir las dependencias y complejidades del sistema. Como expusimos en nuestro artículo "El juego de la plataforma" (“The platform play”), las empresas nativas digitales brindan esa independencia al organizar su tecnología en torno a productos modulares y plataformas que funcionan como un servicio.1 Este enfoque permite a los equipos tomar las mejores decisiones para el producto o la plataforma que administran.

Comparemos este enfoque con lo que sucede en muchas empresas tradicionales, que trabajan con sistemas que abarcan toda la empresa y en los que las complejas dependencias hacen que la toma de decisiones independiente sea prácticamente imposible.

Consideremos el caso de una gran empresa farmacéutica que utilizaba un único sistema ERP para gestionar la distribución y el almacenamiento, a pesar de que la distribución era una gran ventaja competitiva y necesitaba ser flexible y receptiva, mientras que la gestión de almacenes era un producto básico. El estrecho acoplamiento entre estos dos ámbitos empresariales en el sistema ERP significaba que los cambios necesarios en la distribución estaban limitados por las dependencias del sistema con la gestión de almacenes. Esta realidad contribuye mucho a la deuda técnica acumulada.

No tiene por qué ser así. Al centrar los esfuerzos de actualización de ERP en los módulos dentro del sistema en lugar de en todo el sistema, y al comprender lo que importa para impulsar el valor empresarial, los CIOs pueden reducir las dependencias, gastar menos, obtener más, reducir el riesgo y hacerlo más rápido.

Del pensamiento centrado en ERP a una organización de plataforma moderna

La primera lección que se debe aprender de los nativos digitales es que primero establecen la estrategia y luego diseñan la arquitectura de su plataforma. Con una estrategia clara (por ejemplo, aumentar el número de nuevos clientes y reducir la rotación de clientes), siguen una lógica implacable en la identificación de "productos", como los recorridos del cliente (comprar el producto, encontrar una tienda, obtener información sobre un producto), que pueden impulsar la estrategia.

A continuación, identifican las plataformas (como la autenticación de usuarios y la comparación de productos) necesarias para entregar esos productos. Para cada una de esas plataformas, las empresas establecen un equipo que está a cargo del resultado y el rendimiento de la plataforma y que, en última instancia, también decidirá si utiliza las funcionalidades que ya existen en el sistema ERP.

Este enfoque de producto y plataforma destaca dos principios claros: primero, tratar el sistema ERP como una suma de capacidades en lugar de una pila monolítica, y segundo, el producto impulsa la decisión sobre qué partes del sistema ERP usar, y no al revés.

Dar el paso hacia un modelo operativo de producto y plataforma es importante y requiere un cambio de mentalidad para la mayoría de las organizaciones de TI. Tradicionalmente, las empresas se han centrado en comprar soluciones ERP y gestionar al proveedor y el integrador de sistemas para realizar las personalizaciones. Si bien esto sigue siendo suficiente para las áreas en las que uno se basa principalmente en procesos estándar, no es suficiente para las áreas en las que las empresas requieren algo adaptado a sus necesidades. La mayoría de los proveedores de ERP lo entienden y han comenzado a impulsar una mayor modularidad y un núcleo esbelto. Mientras tanto, la TI heredada ha abordado generalmente la cuestión construyendo sobre el sistema ERP, lo que provocaba una complejidad significativa al gestionar cualquier cambio.

Este cambio implica que los departamentos de TI tendrán que ser más activos en la gestión de sus sistemas ERP. Esto significa desarrollar habilidades profundas de ingeniería, administrar activamente las complejidades y dependencias del sistema y trabajar en estrecha colaboración con el negocio para garantizar que los cambios generen valor para la empresa.

Determine qué partes del sistema ERP agregan valor

Con claridad en torno a la estrategia y un enfoque en un modelo operativo de producto y plataforma, el siguiente paso crucial es determinar qué elementos del sistema ERP respaldan directamente la estrategia del negocio. En un alto nivel, este análisis de valor divide las funciones y capacidades dentro del sistema ERP en dos categorías:

  • En un grupo están los elementos diferenciadores que aportan valor a la empresa. Para un minorista que quiere ofrecer una entrega más rápida, por ejemplo, eso significaría priorizar las capacidades logísticas y de cumplimiento. En muchos casos, esas capacidades se entregan a través de microservicios y son totalmente independientes del sistema ERP.
  • En el otro grupo están las funciones básicas que no son fundamentales para impulsar la ventaja competitiva. En muchos casos, estas funciones incluyen la gestión legal o de la propiedad. Las ventajas de ERP al proporcionar estabilidad, seguimiento y funcionalidad de gestión de capacidades son suficientes. Si se aplican los estándares del sector, la empresa a menudo se beneficia de las innovaciones del proveedor y crea valor sin desviarse del estándar. Cualquier personalización creada por TI debe aportar suficiente valor para compensar el trabajo necesario para mantenerla.

El resultado de este ejercicio de clasificación es un mapa de capacidades de ERP diferenciadoras y no diferenciadoras y cómo están organizadas (ver Gráfica 1). Aunque la mayoría de las clasificaciones se pueden hacer al más alto nivel, hay algunas áreas que deben dividirse aún más. Como se muestra en la gráfica, por ejemplo, la mayor parte de la gestión del surtido se considera una función básica, pero la previsión de la demanda es donde esta empresa quiere diferenciarse de su competencia.

1

Un mapa de capacidades bien diseñado también ayudará a determinar qué grupo de módulos debe actualizarse en función del valor para el negocio.

Esta visión proporciona un poderoso contrapeso a la norma predominante en la que los proveedores, en lugar de la empresa, definen los límites de la funcionalidad y las necesidades de modernización. Esta situación a menudo se refleja en el hecho de que, en muchas empresas establecidas, incluso las partes interesadas ajenas a TI hablan del proyecto de actualización del "proveedor X de ERP" en lugar del proyecto de modernización de "finanzas" o de la "cadena de suministro".

Enfóquese en reducir el costo y el riesgo de las actualizaciones de las partes de bajo valor del sistema

Para el primer grupo, el de los elementos diferenciadores de ERP, los CIOs deben impulsar actualizaciones inmediatas. Pero para el segundo grupo, el de los elementos no diferenciadores de ERP, deben secuenciar las actualizaciones cuidadosamente para administrar el costo y el riesgo. De esta manera, la actualización pasa de ser un único proyecto de varios años a una serie de proyectos de software más pequeños que duran un par de meses cada uno. Esta reducción del alcance disminuye el riesgo (proyecto pequeño = riesgo pequeño) y posterga el gasto que puede asignarse mejor a los programas de transformación que generan valor rápidamente.

Hemos descubierto que la TI puede capturar estas ventajas dando tres pasos para reducir la complejidad de la configuración monolítica de ERP (Gráfica 2).

2

1. Desacople las conexiones innecesarias

Reemplazar los sistemas centrales puede ser una tarea abrumadora debido a la variedad de conexiones con otras aplicaciones. Algunas de estas conexiones ayudan a realizar funciones estándar (por ejemplo, cuentas por pagar), siguen todas las directrices de arquitectura del proveedor y son fáciles de mantener. Estas conexiones hacen las tareas para las que fueron diseñadas y no deben tocarse. Sin embargo, a menudo hay muchas conexiones entre partes del sistema que son soluciones provisionales o ad hoc que existen por una amplia variedad de razones, como la decisión de un desarrollador de que era más fácil acceder directamente a una base de datos creando algo a medida en lugar de usar una interfaz modular. El gran volumen y la singularidad de estas conexiones hacen que cualquier esfuerzo de modernización sea complejo y lento.

Para reducir esta complejidad, el primer paso es crear una nueva capa entre el sistema central y las aplicaciones a las que se conecta. Esto a menudo se denomina una “fachada” (façade). Todas las conexiones nuevas irán a esta capa de fachada a través de una interfaz de programación de aplicaciones (application programming interface, o API) que accede a los datos del sistema ERP. De esta manera, las innumerables conexiones se desacoplan del sistema central. Esto brinda la gran ventaja de poder realizar cambios dentro del sistema, como implementar facetas de arquitectura modular, sin afectar a todas las aplicaciones de conexión. La fachada se puede desarrollar en menos de un año. No necesita ser perfecta; basta con que sea funcional.

Pero los desarrolladores no usarán ni siquiera una buena fachada a menos que exista una gobernanza eficaz para imponer su uso. Una forma de hacerlo es facilitarlo, por ejemplo, permitiendo que los equipos de producto accedan a las funciones principales sin tener que pasar por largos mecanismos de aprobación y esperar a que alguien del equipo central construya una interfaz individual. Además de estas “zanahorias”, también pueden ser necesarios “palos” como sanciones para quienes no sigan los nuevos protocolos.

2. Extraiga la personalización

La mayoría de los sistemas centrales se han personalizado hasta la saciedad, desde las complejas funciones para elaborar informes hasta los protocolos de acceso a medida. Cada personalización debe migrarse —y a menudo corregirse de alguna manera— al nuevo entorno, lo que puede ser riesgoso debido a su complejidad correspondiente. Para resolver este problema, las empresas necesitan desarrollar una plataforma digital (generalmente en la nube) a la que se pueda acceder a través de microservicios. El número y la función de las plataformas digitales pueden variar; algunas empresas, por ejemplo, crearán una plataforma para las funciones orientadas al cliente, otra para la cadena de suministro y otra para el propio sistema ERP. La plataforma se convierte en el lugar al que se pueden mover las funciones personalizadas y donde se desarrolla el nuevo código.

Es importante evaluar qué personalizaciones son las más importantes. Este proceso inevitablemente descubre muchas personalizaciones que ya no son necesarias y pueden eliminarse, lo que simplifica la actualización.

3. Reduzca el núcleo

Una vez que se han eliminado las personalizaciones del núcleo, es necesario comenzar a reducir el núcleo mismo a su funcionalidad más necesaria.

Este es esencialmente un proceso de desagregación que elimina las numerosas conexiones intrincadas que a menudo se incorporan a los grandes sistemas. De esta manera, los desarrolladores e ingenieros pueden reemplazar o mejorar una funcionalidad específica sin afectar a otras partes del sistema. Este proceso suele incluir también la limpieza de la base de código, lo que facilita su comprensión y, por lo tanto, su reparación o sustitución.

Como se señaló anteriormente, este proceso de desagregación no necesita tocar los ámbitos funcionales, como la contabilidad o el control, que realizan operaciones estándar dentro del sistema ERP. Solo aquellas funciones que a menudo forman parte de un núcleo estrechamente acoplado sin ninguna razón funcional, como la gestión de almacenes, la previsión de la demanda o el transporte, son candidatas a residir fuera del sistema ERP central.


Las actualizaciones de ERP son masivas, complejas y necesarias, especialmente a medida que aumentan las presiones empresariales y los proveedores de ERP y la nube lanzan nuevos software y servicios. Sin embargo, al adoptar un enfoque de producto y plataforma, las empresas pueden priorizar las actualizaciones que crean valor y reducir el riesgo de las actualizaciones que no lo hacen. De este modo, pueden gestionar mejor los costos y mejorar los resultados.

Explore a career with us