Preparativos de la revisión del plano técnico de soluciones

Completado

Normalmente, la revisión del plano técnico de soluciones tarda aproximadamente de dos a ocho horas en realizarse. El tiempo puede variar según el nivel de detalle disponible para su revisión y la amplitud de la solución general. El arquitecto de soluciones trabajará con la dirección del equipo de implementación para planificar el taller en función de los detalles de la solución que se está revisando.

Antes del taller de revisión del plano técnico de soluciones, los participantes del taller deben asegurarse de estar lo más familiarizados posible con su estructura y los tipos de temas y requisitos previos que se tratarán. El arquitecto de soluciones proporcionará un orden del día con temas y requisitos previos antes del taller.

Nota

La revisión del plano técnico de soluciones es esencialmente una discusión; no pretende ser un cuestionario que pueda completarse y revisarse sin conexión. Si bien los requisitos previos se definen y proporcionan de antemano, no es posible encapsular la amplitud de las indicaciones en las que se podría desarrollar la conversación.

El arquitecto de soluciones se preparará de antemano para el taller revisando los artefactos del proyecto existente con antelación. Entre los artefactos útiles del proyecto se encuentran los siguientes:

  • Catálogos de procesos: listas o jerarquías de procesos, subprocesos e historias de usuarios que están en el ámbito de la implementación.
  • Diagramas de flujo de proceso: diagramas que pueden agregar contexto al catálogo de procesos y describir el funcionamiento del negocio. En la etapa de revisión del plano técnico de soluciones, los procesos de extremo a extremo de alto nivel son los más útiles.
  • Diagramas de aplicación: diagramas de bloques que muestran los distintos componentes de la solución. Estos diagramas también pueden proporcionar un contexto relacionado con cómo se asignan las capacidades a los componentes de la aplicación o cómo interactuarán estos entre sí.
  • Requisitos de brecha: áreas de funcionalidad conocidas que no se consideran compatibles con el sistema estándar.
  • Diagramas de flujo de datos: en una solución que incluye múltiples aplicaciones de Dynamics 365, servicios y componentes heredados o externos, que es útil poder identificar dónde se originan los datos y cómo se mueven y utilizan en la solución..
  • Estrategia de migración de datos: documentos o registros que muestren las entidades que se van a migrar, los orígenes de dónde vendrán, los volúmenes, el tiempo y los métodos de migración. En la etapa de diseño de la solución, es clave asegurarse de tener ámbito (tablas y orígenes).
  • Registro de interfaz: listas de interfaces con requisitos no funcionales y patrones de diseño que documenten el ámbito y el enfoque para implementar esas interfaces.
  • Diseño de agregación de datos analíticos: diagramas o registros de orígenes de datos que se migrarán para análisis agregados.
  • Estrategia de entorno: diagramas de bloques o de flujo que describen los tipos de entornos que se aprovisionarán y cómo y cuándo se usarán, y cómo el código y la configuración fluirán a través de ellos.
  • Perfiles de uso del sistema: programaciones de procesos operativos y volúmenes transaccionales máximos por tipo de carga de trabajo.
  • Estructura de la entidad jurídica: diagramas o registros que muestren las personas jurídicas que se modelarán en la solución y sus relaciones entre sí.
  • Ubicaciones de implementación: diagramas o registros que muestran las ubicaciones físicas donde se implementará la solución junto con los requisitos de idioma y localización.
  • Carta del proyecto: documento que proporciona los antecedentes del proyecto, los objetivos y los resultados clave esperados, las partes interesadas, los presupuestos, las escalas de tiempo y los hitos.
  • Plan/programación del proyecto: documento o diagramas de Gantt que representan la programación general y la dependencia de las fases clave del proyecto y sus actividades asociadas.
  • Matriz de asignación de responsabilidades: tabla de tareas y relación de los roles del proyecto con esas tareas. Estas relaciones generalmente se asignan a través de una clasificación ERCI (encargado, responsable, consultado, informado)
  • Plan/estrategia de prueba: documento que describe los tipos de pruebas que se realizarán a lo largo de la implementación y cómo se definirán, implementarán y medirán las pruebas.

Esta lista de entregables del proyecto no es exhaustiva, pero es un buen punto de partida para la revisión del plano técnico de soluciones. Los formatos, la composición y los nombres de cada entregable pueden variar de un proyecto a otro. El formato no es el componente más importante; lo que es esencial es la información que está disponible y acordada con todo el equipo.

Cuando está llevando a cabo una revisión del plano técnico de soluciones al principio del proyecto, muchos de estos documentos no estarán completamente formados, lo cual es aceptable en la mayoría de los casos. Es más importante que se haya determinado el ámbito y que exista un plan conceptual para determinar cómo la solución apoyará ese ámbito. Si el plan no tiene éxito, estos elementos deben estar representados en algún nivel en la declaración de trabajo proporcionada por el partner consultor que está ayudando con la implementación. Si el ámbito y el enfoque de la solución conceptual están establecidos, la revisión del plano técnico de soluciones puede centrarse en el enfoque conceptual y los talleres de seguimiento más profundos pueden centrarse en los detalles en el momento en que estén disponibles.

Es aceptable si su proyecto utiliza diferentes formas de administrar o seguir la información de los proyectos que no sean las enumeradas anteriormente. Por lo general, el formato no es crítico si la información está fácilmente disponible para los miembros del proyecto. Si la información antes mostrada no está documentada en su proyecto, o si está documentada de manera que no es fácilmente accesible, debe priorizar la producción de los artefactos correspondientes.

Se recomienda usar diagramas y representaciones visuales para proporcionar resúmenes generales, cuando sea posible, en la implementación. Estos diagramas, cuadros y gráficos proporcionan un medio de comunicación listo para todo el equipo y los ejecutivos acerca de los planes y diseños.

Nota

La revisión del plano técnico de soluciones no pretende ser una revisión exhaustiva de los requisitos detallados o los documentos de diseño. El equipo de implementación trabajará con niveles más bajos de detalle para derivar y presentar la arquitectura general. El supuesto es que el equipo de implementación mostrará los puntos clave que más preocupan y los arquitectos investigarán las posibles áreas problemáticas. El arquitecto de soluciones sugerirá talleres en profundidad para investigar áreas que requieran una evaluación adicional.