Una vez seleccionada la plataforma ERP que cree que puede encajar mejor para su empresa, sería bueno que el cliente elabore un documento lo mejor explicado posible, documento de requerimientos. En el que detalla que espera que haga el ERP o software de gestión, básicamente redacta “una carta a los reyes magos”. Incluyendo cada departamento de la empresa (Compras, Ventas, Comercial, Producción, Calidad, RRHH, etc.).
Dependiendo del partner este documento de requerimientos se hace más en detalle o más genérico. A partir de aquí el partner de implementación realiza un análisis de estos requerimientos para empezar la gestión del proyecto. A continuación explicaremos en que consideramos que se debe basar un buen análisis de requerimientos por parte del partner des de nuestra experiencia en Microsoft Dynamics 365.
¿Qué consideramos un mal análisis de requerimientos?
Los análisis con exceso de detalle son análisis trampa. En este caso básicamente el partner detalla con extrema exactitud que va a hacer el software, detallando las tablas y campos de la base de datos. Las relaciones entre tablas y detallando las pantallas.
Son análisis que tardan mucho en redactarse, a veces hasta un año. Tienen muchísimas páginas, llegando a superar las 1.000 en muchas ocasiones. En cuanto a imagen queda muy bien y queda muy profesional. Pero a nuestro juicio son análisis trampa. Se hacen así porque en tiempo de implantación o entregas si hemos obviado algo, algún campo o algún desarrollo nos vendrán con la frase típica. “Esto no está en el análisis que hicimos, para hacerlo tendrás que pagar un extra”. Ojo con los análisis trampa de requerimientos.
¿Qué consideramos un buen análisis de requerimientos?
Los análisis deben ser genéricos sin llegar a exceso de detalle por parte de ambos, especificando lo que deseamos que haga el software, incluyendo los documentos impresos que tengan papel en el circuito e incluso nos podemos ayudar de algún pantallazo para aclarar que procesos queremos que haga el software.
Cuando está validado por las dos partes se procede a programar y a entregar (explicaremos en próximos blogs). El cliente revisa el desarrollo y propone sus mejoras. Por parte del implementador se programan y se realiza de nuevo la entrega. Por segunda vez el cliente vuelve a comprobar e indicarnos nuevas mejoras o cambios. (a veces no es necesario esta segunda revisión). 2 revisiones deberían ser suficientes para dar por cerrado el desarrollo. Trabajando de esta manera no nos encontraremos con sorpresas ni con la frase de “esto no estaba en el análisis”, dado que el análisis lo hemos redactado a nivel genérico. Así, estaremos más cerca de conseguir el éxito en la implantación de nuestro ERP, como en el caso de TMA, una empresa de gestión de residuos que confío en Dynamics 365bc.