Reflexiones sobre la implementación de software empresarial y metodologías de gestión de proyectos.

Cualquier proyecto que gestione una implementación de ERP, independientemente de la metodología utilizada o de cómo se etiqueten las fases, se estructura de la misma manera típica.

1. Iniciación del proyecto
2. Planificación
3. Diseño
4. Desarrollo
5. Pruebas
6. Formación y gestión del cambio
7. Preparación para la puesta en marcha
8. Puesta en marcha
9. Soporte posterior a la puesta en marcha
10. Cierre del proyecto

Y así ha sido desde al menos los últimos 30 años. Cuando las empresas empezaron a usar Agile para sus proyectos (y sé que estoy tomando un atajo), no cambió realmente la forma de hacer las cosas; a menudo solo significó que el diseño detallado, el desarrollo y las pruebas se convirtieron en ciclos iterativos.

1. Iniciación y planificación
2. Descubrimiento y diseño
3. Desarrollo y pruebas iterativas
4. Capacitación de usuarios y gestión de cambios
5. Preparación para la puesta en marcha
6. Puesta en marcha y estabilización
7. Mejora continua

Además, cuando se añadió el concepto de "mejora continua", no muchas organizaciones tenían idea de cómo esto podría integrarse en sus organizaciones, especialmente cuando el equipo del proyecto de implementación se disuelve.

La estructura utilizada para organizar un proyecto ERP de la forma descrita en la introducción proviene de la correcta comprensión de que una plataforma de aplicación de software soporta (o debería soportar) a una organización: las metas y objetivos estratégicos de la organización, la estructura organizativa, su presencia geográfica, sus departamentos, los procesos de negocio, los KPI y todos los requisitos de los empleados con respecto al trabajo eficiente y eficaz. Esto significa que el proyecto comienza con el análisis del negocio, cómo funciona hoy, cómo está organizado y cuáles son los requisitos y objetivos (estratégicos). Este análisis se centra en los requisitos de negocio, los requisitos de proceso, las metas y los objetivos de negocio. En menor grado, el análisis se centra en los requisitos de tecnología de la información: son los objetivos y requisitos de negocio los que (deberían) impulsar los requisitos de tecnología de la información. Las excepciones son para los requisitos de migración e integración de aplicaciones; aquí, la demanda proviene de la propia tecnología.

En resumen, la metodología empleada en proyectos ERP consiste en analizar los requisitos y diseñar la organización propuesta, los procesos y aplicaciones (modificados y nuevos), construir la plataforma de aplicaciones basada en el diseño, y capacitar y probar los nuevos procesos y herramientas. El último paso es la puesta en marcha y el soporte a la organización, así como la resolución de todos los problemas que esta encuentre en los primeros días, semanas o meses tras la puesta en marcha.

La pregunta es cuán exitosas y efectivas son realmente las metodologías de implementación basadas en los principios mencionados. Muchos proyectos de ERP actuales fracasan o, al menos, se consideran poco exitosos. Un proyecto exitoso hoy en día es aquel que, al menos, cubre la funcionalidad al mismo nivel que el sistema anterior (reemplazado), y se considera un éxito que la tecnología se actualice a los estándares actuales.

Y es extraño que el proyecto se considere un éxito cuando la única ventaja es la nueva tecnología y la organización, en términos de cultura, procesos y apoyo a las metas y objetivos, ha ganado muy poco o nada. La pregunta es: ¿por qué seguimos aferrados a la metodología?

Los desafíos de las implementaciones de ERP actuales se pueden resumir mejor de la siguiente manera:

1. La organización está decepcionada con los resultados
2. El proyecto tarda más de lo esperado
3. El proyecto está costando más de lo presupuestado
4. Existe frustración entre el socio de implementación y el cliente

Cuando tratamos de relacionar esas frustraciones con la forma en que se organiza el proyecto de implementación o la metodología utilizada, podemos decir que las siguientes áreas son las principales razones de los llamados fracasos en la implementación de ERP:

1. Gestión y gobernanza de proyectos: desviación del alcance, problemas de asignación y disponibilidad de recursos y, por supuesto, la incapacidad del director del proyecto para organizar el proyecto debido a la falta de apoyo o porque la metodología no está implementada en la organización y la organización/el liderazgo no entiende la metodología.
2. Gestión de cambios y capacitación de usuarios: Los empleados se resisten a los cambios por desconocimiento, miedo a perder su trabajo o por falta de capacitación y comunicación adecuadas. A menudo se subestima la cantidad y la profundidad de la capacitación requerida para que los usuarios comprendan eficazmente el propósito del proyecto. Por supuesto, más adelante en el proyecto, la capacitación en el uso del nuevo sistema y los procesos es insuficiente e ineficiente.
3. Impacto Cultural y Organizacional: La falta de un objetivo o visión común en los departamentos y las partes interesadas es un problema común en muchos proyectos. Además, el proyecto no está alineado con los objetivos estratégicos de la empresa y su Dirección Ejecutiva no reconoce la importancia del proyecto en esta área (y, por lo tanto, existe una drástica falta de apoyo), lo que constituye un factor importante de fracaso y frustración. Además, en la Gestión del Cambio, el cambio cultural necesario para adaptarse a nuevos procesos y herramientas se subestima o incluso se ignora, lo que genera decepción y frustración. Otros dos puntos importantes a considerar son la comunicación y la flexibilidad. La Dirección solo comprende la presión del proyecto (el cambio) en la organización demasiado tarde, lo que genera un estado de pánico que reduce la flexibilidad, la creatividad y la apertura a la adaptación al proyecto. También observamos que, cuanto más difícil se vuelve, más se reduce y se olvida la comunicación con la organización.
4. Reingeniería de procesos: Como se destacó anteriormente en este artículo, comprender y documentar exhaustivamente los procesos actuales antes de diseñar nuevos procesos o migrar al nuevo sistema ERP es mucho más complejo y requiere más tiempo de lo esperado o de lo que las organizaciones están dispuestas a aceptar (invertir). Alinear los procesos de negocio deseados con los procesos estándar del sistema ERP sin una personalización exhaustiva puede ser un desafío y frustrar o desmotivar al equipo del proyecto.

¿Son estas las únicas razones de frustración y problemas en el proyecto? Cabe destacar que, a menudo, la migración de datos se menciona como un desafío para el proyecto. Sin embargo, aunque en algunos proyectos causa retrasos y costos adicionales, la migración de datos casi nunca causa decepción o insatisfacción con lo que el proyecto aportó a la organización (el valor obtenido). Además, las dificultades con el desarrollo de personalizaciones e integraciones pueden, o casi causarán, tiempo y costos adicionales. Sin embargo, estas nunca son la razón por la que, tras la puesta en marcha, los usuarios tengan la sensación de que no se ha entregado todo lo deseado o requerido. Incluso diría que es lo contrario: lo único que realmente se mide y controla es la entrega del software. La funcionalidad de la aplicación, la migración, las personalizaciones, las integraciones, los informes, etc., son básicamente los aspectos fáciles de gestionar.

Y cuando las evaluaciones de proyectos muestran que las pruebas o el soporte posterior a la implementación son desafíos, yo diría que esto se relaciona más con una mala gestión del proyecto y/o la motivación de la organización para asignar la (cantidad de) personas correctas y reconocer la importancia y el impacto del proyecto como se mencionó anteriormente.

Creo que las razones destacadas anteriormente son las razones del fracaso del proyecto y nos obligan a repensar la metodología que utilizamos y a pensar en los recursos y las habilidades que necesitamos para gestionar y ejecutar un proyecto ERP con éxito.

Es importante mencionar que una metodología de implementación de proyectos ágil o alternativa tiene más probabilidades de tener éxito que el enfoque en cascada, por razones de flexibilidad y adaptabilidad, participación del usuario, mitigación de riesgos y comunicación mejorada.

También es importante mencionar que creo que, tras un proyecto inicial difícil para implementar un sistema ERP, los proyectos de mejora continua tendrán muchas más posibilidades de éxito y las organizaciones obtendrán mucho más valor de ellos, por supuesto, solo si estas organizaciones siguen permitiéndolos y hacen del "apetito por el cambio" un valor fundamental. Cabe mencionar, en este sentido, que los sistemas en la nube tienen la ventaja de ser la mejor herramienta para la mejora continua.

Me gustaría ver este documento como un documento de debate y el comienzo de una discusión en p2-i y entre socios y clientes, para ayudarnos a mejorar nuestra propia organización y nuestros servicios para:

1. Establecer la metodología adecuada
2. Tenemos nuestra función de PM organizada
3. Contratar a las personas que necesitamos para ejecutar según la metodología
4. Capacitar y capacitar continuamente a nuestra gente para que tengan éxito en nuestra metodología
5. Capacitar y organizar al grupo de ventas para poder vender nuestros proyectos.
6. Entregar proyectos con éxito

¡Me encanta escuchar sus comentarios y opiniones!

Escrito por Amit Kumar

9 de diciembre de 2024