- La implementación comienza con un prototipo, en el que ya se han implementado cadenas de procesos de negocio, que puede ser aceptado por el cliente como target. Al mismo tiempo, puede haber diferencias que deban eliminarse durante el proyecto.
- Para trabajar en el proyecto, se crea un solo equipo compuesto por consultores, representantes de clientes del negocio y del servicio de TI. Los representantes de los clientes reciben formación durante el proyecto y, junto con los consultores, prueban los prototipos del sistema, formulan los requisitos del sistema y aceptan su implementación. El servicio de TI toma parte activa, implementa algunos de los requisitos y al final del proyecto toma el sistema como soporte.
- Durante el proyecto, se configuran varios prototipos más, que con cada iteración se acercan más a los requisitos del cliente. Durante el transcurso del proyecto, los requisitos se especifican y cambian varias veces.
De hecho, en un gran proyecto de implementación de ERP, se aplican principios ágiles: las personas y la interacción son más importantes que los procesos, un producto funcional es más importante que la documentación, la cooperación con un cliente es más importante que un contrato y la preparación para los cambios es más importante que seguir un plan inicial.
Sin embargo, en las condiciones de un contrato firmado con un precio fijo, trabajando con un gran sistema unificado, estos principios deben aterrizar. Sin condiciones y restricciones adicionales, lo más probable es que el proyecto no se complete, y ciertamente irá más allá del presupuesto.
En primer lugar, no se trata de un desarrollo de un sistema que pueda iniciarse por partes, como suele ocurrir en los proyectos ágiles, cuando cada iteración debe finalizar con el desarrollo de un bloque funcional completo listo para usar. Un sistema ERP solo se puede ejecutar en su totalidad y no en partes.
En segundo lugar, si no limita los requisitos, entonces su aclaración y cambio serán interminables, el proyecto se extenderá y requerirá fondos adicionales.
Entonces, el primer problema es que el sistema ERP consta de partes que están estrechamente interconectadas, impregnadas de procesos de un extremo a otro. Por lo tanto, necesitamos un sistema holístico en todo su alcance en cada iteración. La tarea se ve facilitada por el hecho de que el sistema no se crea desde cero, es un producto terminado. A menudo existe una solución industrial o un sistema preconfigurado con procesos estándar que puede utilizar como su primer prototipo de trabajo.
Se necesita tiempo para preparar el próximo prototipo. El sistema es grande, complejo, hay muchos participantes en el proyecto, por lo que se necesitan al menos dos meses para preparar un prototipo, probarlo y formular comentarios sobre él. En nuestro caso, las iteraciones no son de dos semanas, como en un típico ágil, sino de 2-5 meses.
En cada iteración hacemos un sistema completo, pero hay diferencias entre ellos. En la primera iteración, este es un sistema típico con procesos estándar o específicos de la industria. Los procesos estándar pueden estar bastante lejos de lo que el cliente espera ver al final. Los procesos en el nivel superior son los mismos, pero los detalles serán muy diferentes. Cuando digo "cliente" me refiero a personas que utilizarán el sistema - independientemente de la relación que lo conecte con el contratista - contractual, o se trata de un proyecto interno de la empresa, donde el contratista puede ser el departamento de TI.
Después de recopilar los requisitos en función de los resultados de probar el primer prototipo, configuramos el segundo prototipo, en el que se implementan todos los requisitos que se pueden implementar con la configuración, se cargan los datos de prueba del cliente, se resuelven todas las preguntas que surgieron durante la prueba del primer prototipo. El cliente revisa los procesos de negocio en el sistema, verifica hasta qué punto la implementación actual se adapta, qué tan eficiente es el sistema y cumple sus requisitos.
En la segunda iteración, los futuros usuarios del sistema no lo ven por primera vez, se sienten más cómodos y presentan nuevos requisitos que ya son más significativos y detallados. Idealmente, todos los problemas clave deben resolverse durante este período, porque los cambios se vuelven más costosos cuanto menos tiempo queda antes del lanzamiento.
En la tercera iteración, ya podemos permitirnos comenzar a desarrollar extensiones o, como lo llamamos en la jerga, "personalizaciones" del sistema. Estos pueden ser informes, procedimientos, formularios que están ausentes en el sistema estándar, pero son muy necesarios, porque no siempre es posible ajustar los procesos de negocio al estándar del sistema. La decisión de desarrollar extensiones se toma después de considerar todas las demás posibilidades, ya que su desarrollo y soporte es un placer bastante caro, y esto es dinero adicional.
Hemos estado preparando el tercer prototipo durante varios meses para que se convierta en un sistema completo cerca del objetivo. Por lo general, el sistema está completamente configurado, se carga una cantidad significativa de datos allí y se instalan todas las extensiones críticas. Se está probando muy a fondo con un gran número de usuarios. Esta prueba suele durar alrededor de un mes.
Después de probar el tercer prototipo, quedan comentarios y preguntas sobre las que se elabora un plan para su desarrollo. Y todos los comentarios críticos deben eliminarse en el lanzamiento.
El ritmo del proyecto en este momento se vuelve muy intenso, el tiempo se comprime, como durante una pelea. Es necesario preparar instrucciones, capacitar usuarios, convertir datos, realizar cambios organizacionales. Surgen problemas previamente no resueltos, alguien recuerda que se olvidó de anunciar alguna circunstancia importante ... Antes del lanzamiento, se realiza una prueba más de aceptación - y adelante, el inicio de un nuevo sistema.
Esto, por supuesto, es una descripción muy superficial del enfoque iterativo para la implementación de un sistema ERP. La metodología describe en detalle todos los procesos, incluida la documentación, la formación del equipo del proyecto y los usuarios, la conversión de datos, la realización de cambios organizativos, etc., que de hecho no difieren de otros enfoques de gestión de proyectos.
Naturalmente, surge la pregunta, ¿cómo organizar el proceso de tal manera que no pase a la cuarta, y luego a la quinta o sexta iteración? ¿Cómo puede evitar el riesgo de cambios incontrolados y aclaración de requisitos, que se desarrolla naturalmente a medida que profundiza en los detalles y, a veces, debido a cambios comerciales?
Por supuesto, existe ese riesgo y es muy significativo. A la entrada del proyecto, los requisitos están fijados en el contrato, pero por regla general se formulan de manera general, y el diablo está en los detalles.
Con el "enfoque en cascada" al inicio del proyecto, se fijan los requisitos, se firma el encargo técnico, que se convierte en base formal para luego negarse a cambiar los requisitos o pedir dinero adicional por el cambio. En un enfoque iterativo, este truco no es aplicable.
Entendemos que los requisitos están sujetos a cambios y cambiarán sin falta. Estamos invirtiendo en tiempo y dinero. La pregunta es el alcance de estos cambios. Podemos cometer un gran error y obtener una ola de nuevos comentarios al final, especialmente si el cliente al principio se refiere a la participación en el proyecto "descuidada", selecciona a las personas equivocadas para participar, no formula claramente los requisitos, espera que "todo saldrá bien" confía en consultores, entonces al final tenemos serios problemas.
Por lo tanto, el componente más importante para reducir el riesgo de requisitos de expansión al final del proyecto es la participación del cliente. La misma implementación del principio de desarrollo ágil, según el cual el equipo trabaja en conjunto, el cliente y el desarrollador, en estrecho contacto desde el inicio del proyecto. Esto tiene varias consecuencias importantes. En primer lugar, la identificación temprana de las necesidades reales y el incumplimiento de estas necesidades del sistema. En segundo lugar, al estar involucrado en el proceso de preparación del sistema, el cliente se convierte en su propietario no en el momento de su transferencia en su forma final, sino gradualmente, durante todo el proyecto. Se convierte en el resultado de su trabajo, y al final del proyecto se vuelve imposible hacer afirmaciones como "su sistema no está funcionando", porque este es su sistema.
Es una buena práctica cuando las personas más calificadas y capaces de tomar decisiones están asignadas al proyecto el 100% del tiempo. En nuestra práctica, estos eran los propietarios de los procesos comerciales, sus delegados o empleados que gozan de la plena confianza de los gerentes de servicios. Sí, es difícil, sí, no hay gente extra, sí, es difícil dar lo mejor. Pero esta es la única forma de hacer un proyecto rápidamente y conseguir un sistema de calidad. Los participantes del proyecto obtienen un gran avance en la comprensión de cómo funciona una empresa, adquieren nuevos conocimientos, aprenden a trabajar de una manera nueva y, como regla, esto les crea nuevas oportunidades profesionales. Puede considerar el proyecto de implementación de ERP como un evento de desarrollo de personal extremadamente poderoso, como la creación de una nueva reserva de personal para gerentes.
La segunda cosa a tener en cuenta son las estrictas limitaciones de tiempo del proyecto. El cronograma del proyecto debe ser agresivo y la fecha de lanzamiento no debe cambiar. Si el proyecto se estira, aumenta la probabilidad de que cambien los requisitos comerciales. Si la fecha del proyecto cambia, aparecen nuevos requisitos y la situación se repite: nuevamente el sistema no está listo, pospongamos el lanzamiento. La perfección de los sistemas no se logrará incluso con plazos de proyecto muy largos, y todos los requisitos nunca se identificarán completamente antes del lanzamiento. Solo la explotación real muestra todos los cuellos de botella y lo que es realmente importante. Por lo tanto, después del lanzamiento, hay un período de estabilización de al menos tres meses, durante el cual el equipo del proyecto ayuda y educa a los usuarios, corrige errores, recibe nuevos requisitos y realiza las mejoras necesarias.
Para resistir la tentación de retrasar los plazos y ampliar las demandas, todos deben tener un fuerte incentivo para cumplir esos plazos. El contratista, por supuesto, tiene obligaciones contractuales y un presupuesto. La motivación del cliente suele formarse desde arriba, desde la dirección o los accionistas de la empresa. Por ejemplo, un CEO que toma una decisión de preparación para el lanzamiento puede verse limitado por una obligación hacia los accionistas. El director del proyecto y el equipo del proyecto pueden ser motivados por una bonificación al final del proyecto, sujeto al cumplimiento de los plazos. Los jefes de departamento se enfrentarán a la necesidad de poner en marcha por encargo de la empresa.
Rara vez ocurre cuando existe un deseo sincero de lanzar el sistema lo antes posible debido a las gratas expectativas de las nuevas oportunidades que brinda. El nuevo sistema es, ante todo, el estrés y la necesidad de pasar de la interfaz familiar a la inicialmente inconveniente, a un mayor control, a la necesidad de introducir más información. Los usuarios finales casi nunca dan la bienvenida a un nuevo sistema. Les toma tiempo llegar a un acuerdo y encontrar ventajas en ello. Y si la motivación interna para lanzar a tiempo no está inicialmente incorporada en el proyecto, el lanzamiento se pospondrá, porque los sistemas nunca estarán 100% listos para lanzarse.
Dadas las fechas de lanzamiento ajustadas, resulta imposible expandir y refinar los requisitos sin cesar. El equipo del proyecto, que incluye representantes del cliente, deja de nominarlos y empieza a pensar en prioridades, en las posibilidades de posponer algo, ante un plazo inevitablemente inminente. La tarea del director del proyecto es desde el principio del proyecto formar este sentimiento de un lanzamiento temprano, falta de tiempo. El ambiente demasiado tranquilo en la primera mitad del proyecto significa que la segunda mitad será extremadamente estresante debido a la carrera que es inevitable. Para ello, se deben establecer metas intermedias, y el cronograma del proyecto se conforma de tal manera que las primeras fases del proyecto se comprimen en el tiempo, por lo que se forma una reserva para las últimas fases antes del lanzamiento. Existen diferentes estrategias en las carreras de larga distancia,pero aquí la estrategia debería ser la misma: debes correr rápido desde el principio, es posible que no tengas la fuerza suficiente para acelerar al final.
Resumen de todo lo anterior:
- El enfoque iterativo ofrece resultados mucho mejores en términos de la cercanía del sistema a los requisitos del cliente declarados e implícitos.
- La participación total del cliente en el proyecto es absolutamente esencial para implementar este enfoque.
- Para evitar la proliferación y el perfeccionamiento interminable de requisitos, los plazos del proyecto deben limitarse estrictamente y los participantes del proyecto deben estar motivados para cumplirlos.
Por supuesto, estos son solo los principios básicos, todavía hay muchas sutilezas que dependen de las condiciones específicas, las características de la empresa y la personalidad de los participantes. En cada caso, todo se decide individualmente.