Siempre he pensado que SureStep es una metodología que permite implementar Navision/Nav/Business Central de una forma “más correcta” sin embargo, no debe ser utilizada al pie de la letra debido a los costos que implica toda la documentación y tareas a realizar.
Digamos que es una guía donde se debe escoger lo primordial que permita llevar el proyecto a buen termino de la manera mas indolora para ambas partes proveyendo guía y delimitando alcance para que ambas partes obtengan lo que buscan de la forma más balanceada posible.
Aun así, como todo, es susceptible de mejoras y debemos tomar en cuenta que muchos partners no tiene la estructura necesaria para poder ejecutar todas las tareas descritas y, de todas maneras, el costo de cada tarea encarece el proyecto lo cual no siempre es aceptado por el cliente final.
En SureStep existen ciertos documentos en dos de las fases, en Análisis tenemos el FRD y en el Diseño el FDD así como el TDD.
El FRD (Functional Requirements Document) es el documento que se debe entregar al cliente durante la fase de análisis para tener ahí todos los requerimientos funcionales que serán implementados en la solución. Con este documento se procede a hacer el análisis de Fit Gap y ayuda a terminar la planificación del proyecto.
El FDD (Functional Design Document) provee una respuesta al FRD diciendo como se cubrirá cada proceso requerido y pantallas de la solución mostrando la lógica del proceso. Se supone que el usuario debería de aprobar el diseño a alto nivel de lo que se usará o desarrollará con este documento.
El TDD (Technical Design Document) ayuda a establecer la lógica detallada y el diseño de las características o modificaciones a realizar para la implementación por lo que además de decir cómo se cubrirán los gaps, también dará la guía para el tiempo estimado y costo de los desarrollos.
Estos tres documentos podrían ser la columna vertebral de proyecto ya que delimitaran que se instalará y configurará, como funcionará, que se agregará y finalmente, los resultados esperados.
Lo que en lo personal no me gusta de todo esto es la separación de trabajos y alcances, primero se entrega un documento que trata de demostrar que entendí del proceso, posteriormente, ya que el usuario validó que entendí correctamente (o al menos lo mas cercano a lo que pide), procedo a escribir en otro documento como cubriré lo que pidió en el documento anterior y finalmente, hago documentos por cada gap separados de los documentos anteriores.
Uno de los puntos mas importantes de un ERP es “unir” la información en un solo lugar para poder tomar decisiones de negocio, entonces lo mas raro es que entregamos diferentes documentos en diferentes momentos del tiempo y esperamos que el cliente sepa como unir dicha información de manera que entienda que estamos proponiendo y de su visto bueno.
Es importante que para las sesiones de análisis se defina tiempo suficiente en el proyecto para ir realizando tareas específicas que, además permitir obtener la información del cliente, vaya permitiendo el avance en la documentación a entregar con una base más “operativa”.
La propuesta es tomar de SureStep la tarea llamada Solution Overview que consiste en mostrar a los usuarios como funciona el sistema “out-of-the-box” pero con algunos ajustes previos como utilizar un catalogo de cuentas proporcionado por el cliente (normalmente lo solicito en la junta de kick off), y configuraciones modelo sencillas en una empresa limpia en una base de demo vainilla.
La idea es que se vaya iniciando la creación de conciencia y aceptación entre los usuarios hacia la nueva solución.
Una vez realizadas las sesiones de overview, se procede con las reuniones de análisis de procesos agrupándolas acorde a la actividad de la empresa; en dichas sesiones, además de realizar el “interrogatorio”, se debe aprovechar para ir mostrando nuevamente cómo funciona la solución para demostrar y apoyar como funciona el ERP, por ejemplo, comprar gastos, producto y servicios implicaría abrir el sistema, realizar los tres ejemplos durante la sesión, si el usuario solicita algún campo o cambio o proceso, tomar nota y posterior a la sesión, documentar el escenario con las pantallas mostradas y agregar las notas, es decir, estamos haciendo FRD, FDD y la solicitud del TDD en un mismo documento.
Con esto, al final de la etapa de análisis ya tenemos avanzada la fase de diseño tanto a nivel documental como a nivel configuración de la empresa y en algunos casos, ya incluso podemos hablar de configuraciones definidas de grupos de registro y dimensiones.
En esta fase de “análisis-demo” podemos hacer ajustes al catalogo de cuentas para poder aprovechar las fortalezas del sistema como las dimensiones de manera que durante las sesiones el usuario comienza a familiarizarse con el concepto y a ver los resultados del uso de este.
Este también es el momento de conciliar los requerimientos con el alcance vendido y determinar si algo esta fuera del mismo y tratarlo como Gap con costo o cambios al alcance del proyecto.
En la fase de diseño de la metodología también existe un documento denominado Solution Design Document (SDD) el cual contiene las soluciones propuestas para cada proceso de manera que el cliente pueda entender cómo se utilizará el sistema para resolver sus requerimientos y como se operará.
Pensando en “corregir” un poco la cantidad de documentos y sobre todo la separación en tiempo entre esos documentos (FRD, FDD y TDD), la idea es crear un solo documento que conjunte tanto los requerimientos de operación en el sistema como la forma de cubrir dichos procesos y en el caso de que se requiera, las definiciones de donde va un desarrollo y anexar los diseños técnicos creando en sí, un documento conocido como blueprint el cual estará incluso documentando procesos y flujos en el sistema ya instalado estándar con las configuraciones propuestas, los procesos reales definidos y los resultados obtenidos acelerando de esta manera la comprensión del cliente de la solución propuesta y no solo una serie de retazos inconexos de documentación, recordemos que el cliente no conoce el producto y le será muy difícil tratar de imaginar una serie de procesos que lee de tres documentos diferentes.
Claro que esto implica tiempo, pero se esta abarcando las fases de análisis y diseño por lo que, si inicialmente se había definido un mes para análisis y documentación y otro mes para diseño y documentación, es tan simple que para este documento se ocupará el mismo lapso dos meses con la ventaja de que tendremos una base vainilla configurada y lista para operar lo estándar.
La metodología tiene cosas buenas, Microsoft la diseñó pensando en que sus partner tendrían los recursos humanos necesarios para ejecutarla y que podría vender proyectos de implementación de ERP a un precio que permitiera consumir todas esas horas, es trabajo del partner adecuar lo necesario, pero tratando de mantener el espíritu de SureStep.
Sure Step está diseñado para permitir que el proveedor de soluciones brinde un mejor servicio a sus clientes al ayudarlos a reducir el costo total de propiedad de Microsoft Dynamics.
Leave a Reply
You must be logged in to post a comment.