Siempre he pensado que SureStep es una metodolog\u00eda que permite implementar Navision\/Nav\/Business Central de una forma \u201cm\u00e1s correcta\u201d sin embargo, no debe ser utilizada al pie de la letra debido a los costos que implica toda la documentaci\u00f3n y tareas a realizar.<\/p>\n\n\n\n
<\/p>\n\n\n\n
Digamos que es una gu\u00eda donde se debe escoger lo primordial que permita llevar el proyecto a buen termino de la manera mas indolora para ambas partes proveyendo gu\u00eda y delimitando alcance para que ambas partes obtengan lo que buscan de la forma m\u00e1s balanceada posible.<\/p>\n\n\n\n
Aun as\u00ed, 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.<\/p>\n\n\n\n
En SureStep existen ciertos documentos en dos de las fases, en An\u00e1lisis tenemos el FRD y en el Dise\u00f1o el FDD as\u00ed como el TDD.<\/p>\n\n\n\n
El FRD (Functional Requirements Document) es el documento que se debe entregar al cliente durante la fase de an\u00e1lisis para tener ah\u00ed todos los requerimientos funcionales que ser\u00e1n implementados en la soluci\u00f3n. Con este documento se procede a hacer el an\u00e1lisis de Fit Gap y ayuda a terminar la planificaci\u00f3n del proyecto.<\/p>\n\n\n\n
El FDD (Functional Design Document) provee una respuesta al FRD diciendo como se cubrir\u00e1 cada proceso requerido y pantallas de la soluci\u00f3n mostrando la l\u00f3gica del proceso. Se supone que el usuario deber\u00eda de aprobar el dise\u00f1o a alto nivel de lo que se usar\u00e1 o desarrollar\u00e1 con este documento.<\/p>\n\n\n\n
El TDD (Technical Design Document) ayuda a establecer la l\u00f3gica detallada y el dise\u00f1o de las caracter\u00edsticas o modificaciones a realizar para la implementaci\u00f3n por lo que adem\u00e1s de decir c\u00f3mo se cubrir\u00e1n los gaps, tambi\u00e9n dar\u00e1 la gu\u00eda para el tiempo estimado y costo de los desarrollos.<\/p>\n\n\n\n
Estos tres documentos podr\u00edan ser la columna vertebral de proyecto ya que delimitaran que se instalar\u00e1 y configurar\u00e1, como funcionar\u00e1, que se agregar\u00e1 y finalmente, los resultados esperados.<\/p>\n\n\n\n
Lo que en lo personal no me gusta de todo esto es la separaci\u00f3n de trabajos y alcances, primero se entrega un documento que trata de demostrar que entend\u00ed del proceso, posteriormente, ya que el usuario valid\u00f3 que entend\u00ed correctamente (o al menos lo mas cercano a lo que pide), procedo a escribir en otro documento como cubrir\u00e9 lo que pidi\u00f3 en el documento anterior y finalmente, hago documentos por cada gap separados de los documentos anteriores.<\/p>\n\n\n\n
Uno de los puntos mas importantes de un ERP es \u201cunir\u201d la informaci\u00f3n 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\u00f3n de manera que entienda que estamos proponiendo y de su visto bueno.<\/em><\/p>\n\n\n\n Es importante que para las sesiones de an\u00e1lisis se defina tiempo suficiente en el proyecto para ir realizando tareas espec\u00edficas que, adem\u00e1s permitir obtener la informaci\u00f3n del cliente, vaya permitiendo el avance en la documentaci\u00f3n a entregar con una base m\u00e1s \u201coperativa\u201d.<\/p>\n\n\n\n La propuesta es tomar de SureStep la tarea llamada Solution Overview que consiste en mostrar a los usuarios como funciona el sistema \u201cout-of-the-box\u201d 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<\/em>.<\/p>\n\n\n\n La idea es que se vaya iniciando la creaci\u00f3n de conciencia y aceptaci\u00f3n entre los usuarios hacia la nueva soluci\u00f3n.<\/p>\n\n\n\n Una vez realizadas las sesiones de overview, se procede con las reuniones de an\u00e1lisis de procesos agrup\u00e1ndolas acorde a la actividad de la empresa; en dichas sesiones, adem\u00e1s de realizar el \u201cinterrogatorio\u201d, se debe aprovechar para ir mostrando nuevamente c\u00f3mo funciona la soluci\u00f3n para demostrar y apoyar como funciona el ERP, por ejemplo, comprar gastos, producto y servicios implicar\u00eda abrir el sistema, realizar los tres ejemplos durante la sesi\u00f3n, si el usuario solicita alg\u00fan campo o cambio o proceso, tomar nota y posterior a la sesi\u00f3n, 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.<\/p>\n\n\n\n Con esto, al final de la etapa de an\u00e1lisis ya tenemos avanzada la fase de dise\u00f1o tanto a nivel documental como a nivel configuraci\u00f3n de la empresa y en algunos casos, ya incluso podemos hablar de configuraciones definidas de grupos de registro y dimensiones.<\/p>\n\n\n\n En esta fase de \u201can\u00e1lisis-demo\u201d 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.<\/p>\n\n\n\n Este tambi\u00e9n 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.<\/p>\n\n\n\n En la fase de dise\u00f1o de la metodolog\u00eda tambi\u00e9n 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\u00f3mo se utilizar\u00e1 el sistema para resolver sus requerimientos y como se operar\u00e1.<\/p>\n\n\n\n Pensando en \u201ccorregir\u201d un poco la cantidad de documentos y sobre todo la separaci\u00f3n en tiempo entre esos documentos (FRD, FDD y TDD), la idea es crear un solo documento que conjunte tanto los requerimientos de operaci\u00f3n 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\u00f1os t\u00e9cnicos creando en s\u00ed, un documento conocido como blueprint el cual estar\u00e1 incluso documentando procesos y flujos en el sistema ya instalado est\u00e1ndar con las configuraciones propuestas, los procesos reales definidos y los resultados obtenidos acelerando de esta manera la comprensi\u00f3n del cliente de la soluci\u00f3n propuesta y no solo una serie de retazos inconexos de documentaci\u00f3n, recordemos que el cliente no conoce el producto y le ser\u00e1 muy dif\u00edcil tratar de imaginar una serie de procesos que lee de tres documentos diferentes.<\/p>\n\n\n\n Claro que esto implica tiempo, pero se esta abarcando las fases de an\u00e1lisis y dise\u00f1o por lo que, si inicialmente se hab\u00eda definido un mes para an\u00e1lisis y documentaci\u00f3n y otro mes para dise\u00f1o y documentaci\u00f3n, es tan simple que para este documento se ocupar\u00e1 el mismo lapso dos meses con la ventaja de que tendremos una base vainilla <\/em>configurada y lista para operar lo est\u00e1ndar.<\/p>\n\n\n\n La metodolog\u00eda tiene cosas buenas, Microsoft la dise\u00f1\u00f3 pensando en que sus partner tendr\u00edan los recursos humanos necesarios para ejecutarla y que podr\u00eda vender proyectos de implementaci\u00f3n de ERP a un precio que permitiera consumir todas esas horas, es trabajo del partner adecuar lo necesario, pero tratando de mantener el esp\u00edritu de SureStep.<\/p>\n\n\n\n Sure Step est\u00e1 dise\u00f1ado 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.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Siempre he pensado que SureStep es una metodolog\u00eda que permite implementar Navision\/Nav\/Business Central de una forma \u201cm\u00e1s correcta\u201d sin embargo, no debe ser utilizada al pie de la letra debido a los costos que implica toda la documentaci\u00f3n y tareas a realizar. Digamos que es una gu\u00eda donde se debe escoger lo primordial que permita […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[12,15],"tags":[],"class_list":["post-791","post","type-post","status-publish","format-standard","hentry","category-implementacion","category-metodologia"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/fbedolla.com\/index.php\/wp-json\/wp\/v2\/posts\/791","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/fbedolla.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/fbedolla.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/fbedolla.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/fbedolla.com\/index.php\/wp-json\/wp\/v2\/comments?post=791"}],"version-history":[{"count":1,"href":"https:\/\/fbedolla.com\/index.php\/wp-json\/wp\/v2\/posts\/791\/revisions"}],"predecessor-version":[{"id":792,"href":"https:\/\/fbedolla.com\/index.php\/wp-json\/wp\/v2\/posts\/791\/revisions\/792"}],"wp:attachment":[{"href":"https:\/\/fbedolla.com\/index.php\/wp-json\/wp\/v2\/media?parent=791"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/fbedolla.com\/index.php\/wp-json\/wp\/v2\/categories?post=791"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/fbedolla.com\/index.php\/wp-json\/wp\/v2\/tags?post=791"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}