En uno los proyectos de gestión de la implantación de ERPs en los que estoy envuelto ahora estoy viviendo un pequeño infierno.Requerimientos que se tomaron hace escasamente tres semanas han sido cambiados por el cliente radicalmente, y más de una vez, desde el momento en que revisó el documento donde el implantador había documentado su análisis.
Lógicamente éste se ha rebotado y ya ha empezado a hablar de ampliaciones en el proyecto, algo que ha erizado el pelo de mi cliente. Nosotros en medio e intentando reconducir la situación... (sí ya se, otro proyecto que es igual)Y es que el proceso de toma de requerimientos, su transformación en un diseño/modelo para la configuración posterior del ERP en general está muy mal resuelto por monolítico y poco ágil.
Es muy complicado, por no decir imposible, clavar en un documento los requerimientos del cliente - siempre hay matices o situaciones y que se les acaban ocurriendo cuando acaban viendo el sistema en funcionamiento. Históricamente se han utilizado prototipos que aunque mejoran la situación no acaban de resolverla.Para romper este enfoque en cascada echo mucho de menos el poder aplicar en las implantaciones de ERPs una metodología como scrum, donde los requerimientos se van cerrando por el (y al) cliente a medida que el producto se va desarrollando y perfeccionando por el equipo.
Pero a ver quien convence a un cliente de que el proyecto de implantación de su ERP no tiene una planificación con un alcance cerrado y conocido de antemano, aunque esa planificación siempre se incumpla.Este es un tema, scrum aplicado a la implantación de sistemas de información, que me gustaría desarrollar en algún post.
Aqui te mostramos un video de lo complicado que se puede tornar la toma de requerimientos:
No hay comentarios:
Publicar un comentario