Identificar los componentes de la solución
Durante el proceso de detección, algunas ideas sobre la solución deberían comenzar a aclararse. En esta unidad se describe cómo identificar los componentes de solución que podrían componer la solución propuesta para el cliente. Dado que esta es todavía la fase de preventa del proyecto, su objetivo es mostrarle al cliente el aspecto que tendrá la solución propuesta una vez construida y, a continuación, explicarle el modo en que la solución cumplirá sus objetivos. También es un buen momento para comenzar a pensar en una hoja de ruta del producto y en cómo se implementarán los componentes para aportar valor rápido con las iteraciones.
Asignar necesidades a funcionalidad
Las reuniones con el cliente deberían haberle servido para identificar sus necesidades esenciales. Para identificar componentes, debe reflexionar sobre estas necesidades en un alto nivel y asignarlas a aplicaciones de Dynamics 365 existentes, una aplicación Microsoft Power Platform personalizada o, en algunos casos, un proceso de desarrollo personalizado. En el caso de los proyectos grandes, es posible que deba asignar las necesidades a varias aplicaciones o a las tres categorías mencionadas.
No todos los proyectos comienzan desde el principio; muchos cuentan con sistemas existentes y simplemente consisten en mejorar o integrar algo en lo que ya existe. Por ejemplo, un cliente que ya tiene el servicio Dynamics 365 Customer Service podría querer agregar algunas características omnicanal para abordar una necesidad específica.
Algunas necesidades pueden asignarse a más de una aplicación. Es posible que el ámbito de ventas se asigne a Dynamics 365 Sales, con las funciones de seguimiento de comisiones y pago como mejoras a su aplicación Dynamics 365 Finance.
Tenga cuidado al hacer esta asignación o al proponer al cliente que reemplace una aplicación o agregue otra aplicación que duplique algo que ya tiene. Es posible que esté ayudando al cliente por ese motivo, lo cual es aceptable. Sin embargo, si el cliente ya tiene una aplicación de planificación de recursos empresariales (ERP) que no es de Microsoft y usted le propone agregar Dynamics 365 Finance porque facilita la implementación de su solución, su propuesta no será bien recibida.
Para los componentes clave de la solución, le recomendamos que resalte dónde se utilizará la funcionalidad lista para usar y dónde se requieren aspectos personalizados. Por ejemplo, debe destacar que su idea es utilizar funciones de venta estándar para todo, con excepción de un configurador de productos. Luego, para el configurador de productos, debe destacar la solución propuesta; por ejemplo, incorporar una Power App personalizada en la aplicación o tal vez ofrecer una solución de configurador de terceros.
Utilizar imágenes para explicar ideas complejas
Puede crear un diagrama o una imagen de una sola página que describa la solución de un modo más fácil de entender. Incluya a las diferentes personas que van a interactuar con el sistema para que quede claro cómo utilizará la solución cada una de estas personas. Evite agregar demasiados detalles, porque esto podría dificultar la visualización del diagrama o la imagen y complicar en exceso sus ideas. Si logra que la ilustración sea concisa y pulcra, se convertirá en el punto de referencia para futuras discusiones y lo distinguirá de la competencia. Para aquellos puntos que necesitan más detalles, puede crear diagramas relacionados que se centren en áreas determinadas.
Modelado de datos
El modelado formal de datos se produce como parte del diseño de la solución y, por lo general, después de establecido un contrato. Sin embargo, durante la fase de preventa, la conceptualización de modelado de datos de alto nivel se realiza constantemente para identificar los grandes grupos de datos y a qué pueden pertenecer. Si se realiza una prueba de concepto, este esfuerzo a menudo se utiliza para crear un prototipo de lo que se presenta al cliente. Esta información de modelado de datos también se transfiere al proceso de diseño, para iniciar el proceso de pensamiento de modelado de datos. Considere la opción de tener un modelo de datos resumido y otro detallado para compartir. El modelo detallado lo utilizarán quienes diseñan y construyen el sistema. El modelo resumido se compartirá con las partes interesadas que necesitan comprender la solución, pero no los detalles específicos.
Modelado de procesos
Durante el proceso de detección, debería haber conocido los procesos clave del cliente. Al proponer una solución al cliente, es fundamental ser capaz de explicarle cómo la solución propuesta realiza los procesos empresariales clave.
En algunos casos, el proceso propuesto puede ser similar al proceso existente del cliente; sin embargo, lo más habitual es que sea diferente. A medida que identifica los componentes de la solución, es importante resaltar las diferencias principales. Debe especificar cómo los cambios del proceso propuesto lograrán los objetivos identificados; por ejemplo, resolver casos un 20 por ciento más rápido y mantener a los clientes más informados.
Experiencia de usuario
Los clientes siempre se centrarán en la experiencia del usuario. Durante el proceso de detección, debería haber obtenido detalles (por ejemplo, si los usuarios son móviles siempre, a veces o nunca) u otras necesidades únicas relativas a la experiencia de usuario. A medida que identifica los componentes de la solución propuesta, es importante asignarlos a estas necesidades. En función de las necesidades, estos componentes deben demostrarse con una prueba de concepto o un wireframe que ilustre la solución propuesta.
Un wireframe puede incluir los elementos siguientes:
Formularios principales
Paneles
Experiencia móvil
Visualizaciones (por ejemplo, Power BI)
La siguiente imagen muestra un ejemplo de un gráfico de contorno reticular y el formulario real que construiría a partir del gráfico de contorno reticular.
Integraciones
La mayoría de las soluciones no existen de forma aislada y dependen de integraciones internas o externas. Como parte de la identificación de los componentes de la solución, debe poder señalar cómo se gestionarán estas integraciones. Este proceso puede incluir la definición de las herramientas o los servicios que se utilizarán para realizar las integraciones. En una solución multisistema, debe definir claramente los límites donde termina un sistema y comienza otro. Estos límites se convierten en "contratos" entre los responsables de la creación y el mantenimiento. Preste especial atención a lo que sucede en estos límites e intente definir claramente a quién corresponde la responsabilidad de crear las interfaces y quién las utilizará. Esta aclaración es especialmente importante cuando intervienen proveedores externos o equipos de desarrollo interno.
Opciones de implementación
Microsoft proporciona un modelo basado en suscripción de Microsoft Dynamics 365. Con esta opción, puede obtener acceso a Dynamics 365 a través de la nube, sin tener que invertir más en licencias de hardware y software de su red de TI. No hay una implementación local de la aplicación y sus usuarios pueden obtener acceso a Dynamics 365 desde múltiples navegadores. Este acceso puede ser crítico para el personal remoto o externo que necesita acceso fácil.
Sin embargo, Dynamics 365 Finance y Dynamics 365 Supply Chain Management (previamente conocido como Dynamics 365 Finance and Operations) también pueden implementarse localmente, lo que significa que la organización puede implementar las aplicaciones localmente.
Para las siguientes aplicaciones de Dynamics 365, debe usar Lifecycle Services para la implementación:
Dynamics 365 Finance
Dynamics 365 Supply Chain Management
Dynamics 365 Commerce
En el caso de otras aplicaciones empresariales de Dynamics 365, como las enumeradas en la siguiente lista, las implementaciones principales se harán en línea utilizando un conjunto de entornos de desarrollo-prueba-producción estándar:
Dynamics 365 Sales
Dynamics 365 Customer Service
Dynamics 365 Customer Insights - Journeys
Dynamics 365 Field Service
También puede crear un entorno de prueba y ejecutarlo de forma práctica, lo que le permitirá poner en funcionamiento su sistema en cuestión de días, en lugar de semanas o meses. Ya no tiene que lidiar con el mantenimiento continuo del servidor ni las tarifas de licencia. Además, puede comprar sus licencias de usuario directamente en línea, sin necesidad de recurrir a un proveedor, y puede agregar más usuarios en línea a medida que los necesite y que su negocio crezca.
Las aplicaciones empresariales de Dynamics 365 ofrecen diversos tipos de entorno. El tipo de entorno indica el propósito y determina las características del entorno:
Prueba: los entornos de prueba satisfacen las necesidades de prueba a corto plazo y se borran automáticamente después de un corto periodo de tiempo.
Espacio aislado: estos entornos no son de producción y, cuando están asociados a una instancia de base de datos de Microsoft Dataverse, ofrecen características como restablecer.
Producción: estos entornos se utilizan en el trabajo permanente de una organización. Pueden ser creados y ser propiedad de un administrador o de cualquier persona con una licencia de Power Apps.
Predeterminado: un entorno de producción no personalizado. Cada inquilino tiene un entorno predeterminado que se crea automáticamente.
Desarrollador: los entornos de desarrollador los crean usuarios que disponen de la licencia del Plan de la comunidad. Solo pueden utilizarlos sus respectivos propietarios. En el caso de estos entornos, compartirlos con otros usuarios no es posible.
Microsoft Dynamics Lifecycle Services
Microsoft Dynamics Lifecycle Services le ayuda a administrar el ciclo de vida de las aplicaciones en las implementaciones de Microsoft Dynamics 365 Finance y Microsoft Dynamics 365 Supply Chain Management. Lifecycle Services es un portal de colaboración basado en Microsoft Azure con un entorno y un conjunto de servicios que se actualizan periódicamente. Este portal proporciona un espacio de trabajo colaborativo que los clientes y sus partners pueden usar para administrar los proyectos de Finance y Supply Chain Management. Lifecycle Services le ayuda desde la fase de preventa hasta la fase de implementación y, por último, el entorno de producción, tanto en la nube como local. Lifecycle Services, mediante listas de comprobación y herramientas, le ayuda a administrar el proyecto, por ejemplo, con metodologías predefinidas que ayudan en la implementación.
Lifecycle Services permite un grado mayor de previsibilidad, colaboración y procedimiento estructural en lo que respecta a la gestión de la administración de aplicaciones. El objetivo de Lifecycle Services es avanzar hacia implementaciones predecibles, repetibles y de alta calidad mediante la simplificación y estandarización del proceso de implementación.
Pasos siguientes
La identificación de los componentes clave de la solución le ayudará a determinar los siguientes pasos. Los siguientes pasos dependerán, por ejemplo, de si tiene soluciones listas para demostración que debe adaptar al cliente o si tiene que crear una prueba de concepto o un prototipo nuevos.
El objetivo de este proceso no es crear un diseño detallado de la solución completa. Recuerde que continúa en la fase de preventa; debe ser capaz de exponer el modo en que su propuesta dará respuesta a las necesidades del cliente y debe tener la solución identificada hasta el grado que sea necesario. Disponer de esta información le ayudará a determinar los precios que sea necesario establecer para finalmente firmar un contrato y poder así proceder a crear la solución.
Ejercicio: Identificar usos comunes entre los equipos de Woodgrove Bank
Revise el perfil de cliente de Woodgrove Bank, concretamente los equipos que trabajan de cara al cliente descritos. Identificar temas comunes en los equipos. Determine si hay equipos que se superponen en términos de funcionalidad necesaria. Evalúe si algún equipo concreto es tan diferente de los demás que esta diferencia justifica una solución separada.