Aunque pueda parecer curioso, incluso inquietante, una gran parte de los proyectos de implantación de ERP’s entre los que podemos incluir la familia Dynamics en general y Microsoft Dynamics AX en particular no se ejecutan como proyectos de software. Quizás por la cercanía del proyecto al negocio o quizás por la orientación -más a negocio que a software- de las personas implicadas en la mayor parte del tiempo consumido, una buena parte de las veces se olvida, o se obvia, que estamos tratando de implementar un software y por tanto es conveniente tratar el proyecto como un proyecto de software y aplicar conceptos propios de la ingeniería de software para gestionar el software y la gestión de proyectos para gestionar el proyecto.

Ya he hablado en artículos anteriores de diferentes metodologías de implantación como puede ser Microsoft Sure Step o las metodologías ágiles a las que cada vez se acerca más gente, incluida Microsoft. No son las únicas, cada empresa utiliza las que conoce y considera mas apropiadas para cada proyecto como PMBOK o PRINCE2 o técnicas más específicas del software y la tecnología como CMMI o ITIL, e incluso algunas empresas “diseñan” las suyas propias. El problema es que es demasiado habitual que no se utilice ninguna o que la elegida no abarque todo el ciclo de vida de una aplicación.

Alguno podrá pensar: “¿Estás criticando la utilidad de metodologías utilizadas por la mayoría de multinacionales del mundo durante años?“. No. Claro que no. Ni siquiera conozco la mayoría de ellas como para, siquiera, tener una opinión. Lo que sí esta claro, por su propia definición, es que son propuestas orientadas a la gestión del proyecto como tal (alcance, recursos, tiempo, coste, materiales,…) pero no tienen en cuenta de manera específica los problemas propios del software, que a menudo quedan olvidados al no formar parte de los procedimientos formales. En resumen, se gestionan más las limitaciones y los riesgos (lo que no se puede hacer) que lo que SÍ debe hacerse. Dicho de otra forma, se están utilizando estas metodologías (totalmente válidas) para gestionar conceptos que NO SON el software.

Para mejorar esto hemos de recurrir a la tan olvidada ingeniería del software y a un concepto que cualquier empresa dedicada exclusivamente a producir software tiene más que asumido en su operativa diaria y en su rentabilidad: El ciclo de vida de la aplicación (o Application Lifecycle Management, o simplemente ALM).

Wikipedia da una buena definición de Ingeniería del Software (traducido). Quizás no es la mejor fuente pero es la más accesible:

[…] Ingeniería de Software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al diseño, desarrollo, operación y mantenimiento de software […]

Ahora cabría plantearse si el método que estamos utilizando en nuestro entorno (soy optimista y pienso que ya se está utilizando alguno) cumple estas sencillas directivas (sistemático, disciplinado y cuantificable) a todas las áreas del ciclo de vida (desde el desarrollo al mantenimiento, sin olvidar la gestión del cambio). Si es así, enhorabuena; si no lo es, te interesa el resto del artículo y los que vendrán a continuación…