Requisitos de las asignaciones
Cuando reúna los requisitos, un paso importante consistirá en asignar cada requisito a las capacidades de las aplicaciones de Dynamics 365. Se trata de una tarea diferente a la que haría con un software personalizado o un proyecto solo de Microsoft Power Platform, en los que no existe una lógica de proceso de negocio diseñada previamente, como si es el caso en las aplicaciones de Dynamics 365. Por ejemplo, Microsoft Dynamics 365 Sales ya tiene implementado el seguimiento de oportunidades de ventas, por lo que no necesita crear esta lógica. Su trabajo de asignación consistirá en revisar cada requisito y sopesar cómo lo implementará. Por lo general, con la asignación se aplicará una de las categorías siguientes al requisito:
Listo para usar: la aplicación de Dynamics 365 tiene este requisito integrado y solo es preciso habilitarlo o realizar una configuración mínima. El seguimiento de oportunidades de Sales es un buen ejemplo de esta categoría.
Configuración: la aplicación de Dynamics 365 no admite la configuración de forma predeterminada, pero con solo agregar unas cuantas columnas a las tablas o unas cuantas tablas personalizadas y quizá un poco de automatización, podrá implementar el requisito. Por ejemplo, supongamos que el requisito sea realizar un seguimiento del importe de la comisión en cada oportunidad. Puede implementar este requisito con alguna configuración sin código o de código bajo y tal vez algo de automatización para automatizar los cálculos.
Personalizar: la aplicación Dynamics 365 no admite la personalización, pero puede lograrlo si incluye algunos recursos de desarrollo de código para compilar una lógica o un componente personalizados. Por ejemplo, un desarrollador de código de su equipo puede crear un control de Microsoft Power Apps Component Framework para implementar un configurador de productos personalizado en el formulario de oportunidad.
Solución de partner: muchas soluciones de partners funcionan con aplicaciones de Dynamics 365. Por ejemplo, un configurador de productos puede provenir de una solución de un partner en vez de una compilación personalizada.
Estos ejemplos son categorías que puede usar, pero los equipos no se limitan a estas categorías.
Cuando se combinan con el nivel de esfuerzo y la prioridad, puede usarlas para realizar un análisis de lagunas e idoneidad. Este tipo de análisis es un proceso de evaluación del grado de idoneidad de una solución al problema que se está solucionando. En las categorías anteriores, las capacidades listas para usar se considerarían "idóneas". Este aspecto es importante en una aplicación empresarial como Dynamics 365, ya que significa que se adapta a lo que hace la aplicación. Si el porcentaje de "adaptación" es bajo, es posible que esa aplicación no sea un buen punto de partida para compilar la solución.
Por lo general, los requisitos que terminan en categorías que requieren mucha configuración o personalización deben examinarse para decidir si se dispone de opciones que permitan adaptarlos mejor a las capacidades listas para usar, con solo realizar un poco de configuración para dar respuesta a los requisitos únicos. No es raro que, en un principio, los requisitos se asignen a personalizado porque el cliente piensa que deben ejecutarse igual que en el sistema anterior, sin darse cuenta de que Dynamics 365 difiere ligeramente en su soporte listo para usar. Puede ser beneficioso trabajar junto con el cliente para negociar este tipo de requisitos y conseguir que se usen capacidades listas para usar.
Otra de las ventajas del ejercicio de asignación consiste en que se evalúa la viabilidad de un requisito. Normalmente, los requisitos no son viables por los motivos siguientes:
Muy pocas personas utilizarán la característica.
Técnicamente, la característica no es posible.
Las normativas o leyes prohíben la característica o el proceso.
Estudiar cómo se implementará un requisito tiene también la ventaja de que le permite detectar dónde puede necesitar una solución de prueba de concepto para identificar cómo se implementará. Normalmente, en las pruebas de concepto se compila o se crea un ejemplo de cómo se podría solucionar un problema. No tiene la funcionalidad de una característica lista para la producción, pero sí lo suficiente para evaluar si el concepto funciona. Este concepto también se puede aplicar a la evaluación de soluciones de partners para saber si pueden resolver el problema. Microsoft AppSource es un buen lugar para encontrar estas soluciones de partners.
Independientemente de si realiza la asignación de manera informal o formal siguiendo la metodología de su proyecto, precisar los requisitos y comprender mejor el nivel de esfuerzo necesario para implementarlos puede ser muy valioso.