¿Qué es lo que más te gusta de Dynamics 365 Field Service?
Dynamics 365 Field Server (FS) permite una implementación muy flexible de contratos de servicio, teniendo todas las características de la solución D365 CRM, con conceptos de FS como acuerdos, órdenes de trabajo, tareas, etc., integrados. Al igual que todo D365, la mayoría de las entidades "básicas" como tareas, cuentas, usuarios, equipos, etc., pueden asociarse de manera flexible entre sí, y se pueden construir flujos de trabajo en torno a eso.
Además, como líder de análisis de datos, tener las posibles asociaciones integradas y configuradas por el usuario entre entidades hace que automatizar y convertir los datos en una estructura relacional más tradicional sea mucho más fácil que tener que codificar manualmente el ETL.
Las tablas de metadatos que describen posibles estados, subestados y asociaciones con entidades son muy sistemáticas, incluso informando el ROL de cada lado de una asociación. Si se quisiera, se podría automatizar completamente un ETL de base de datos de grafos solo a partir de una cuidadosa recopilación de las tablas de metadatos (lo que eliminaría el problema reportado en la sección de "disgusto" de que muchas entidades tienen más de 100 campos (en su mayoría no utilizados en la mayoría de las implementaciones) que son nulos si no se utilizan). Reseña recopilada por y alojada en G2.com.
¿Qué es lo que no te gusta de Dynamics 365 Field Service?
Lo que hace que D365 FS (y D365 en general) sea difícil es que el modelo de datos subyacente es extremadamente difícil de gestionar fuera de las herramientas ofrecidas por Microsoft. Requiere bastante esfuerzo configurar la duplicación de datos en una base de datos accesible a través de SQL tradicional (incluso SQL Server). Una vez que los datos están allí, te enfrentas a que cada entidad tiene TODOS los campos POSIBLES que podrían usarse. Entidades principales como "cuenta", "contacto", "tarea", etc. tienen más de 100 campos cada una. El orden de las columnas parece aleatorio: los campos configurados por el usuario están mezclados entre los predefinidos. Afortunadamente, la metadata disponible a través de la API permite la construcción de herramientas de conversión automatizadas para que los datos extraídos contengan solo los campos en uso, ordenados de una manera más manejable.
El comentario anterior es aplicable a TODAS las soluciones D365, no solo a FS. FS tiene dos conceptos clave que faltan, que parecen ser parte de cualquier solución CRM->FS:
1. Falta de un concepto de "estado" o "pipeline" de cuenta unificado: en D365. Los "leads" que se cierran crean "oportunidades", que en FS se convierten en "acuerdos" a los que se pueden asociar una o más "órdenes de trabajo". No hay un lugar unificado, aparte de los enlaces de retroceso al paso anterior, para entender en qué fecha un acuerdo particular para una cuenta (cualquiera de los cuales puede no ser creado hasta después de que el lead se cierre) fue un lead, cuándo el lead se cerró y creó una oportunidad, que luego se convirtió en un acuerdo, etc. Si deseas construir un informe de pipeline (incluso en la GUI incorporada, pero también en SQL) tienes que crear manualmente uniones que sigan los enlaces. También es posible que el front end cree entidades más adelante en el proceso sin el paso anterior (un acuerdo puede existir sin una oportunidad que lo creó, por ejemplo). Cuando se utiliza para entender tasas de cierre, costo de adquisición de cliente/cuenta, valor de vida de un cliente, etc., es muy desafiante.
2. Las entidades específicas de FS "acuerdo" y "orden de trabajo" fueron, creo, implementadas inicialmente por otro proveedor de soluciones y luego compradas e incorporadas. (Se nombran "msdyn_account" y "msdyn_workorder - esa convención de prefijo también se aplica a nuevas entidades/campos añadidos por los implementadores). Por lo tanto, el "estado/subestado" de estas dos entidades se maneja de manera muy diferente: en todos los demás incorporados de D365, hay dos campos de metadata que denotan el "estado" de la entidad: actual/activo, inactivo, etc. y "subestado": "nuevo", "abierto", "en progreso", "cerrado", etc. En acuerdos y órdenes de trabajo, esos campos existen, pero los campos configurables por el usuario que denotan el mismo significado están en tablas de entidades adicionales con GUIDs para claves en lugar de enteros.
Es otra cosa con la que trabajar.
Estos dos, y el requisito absoluto común a todos los entornos de configuración o implementación sin/bajo código de trabajar dentro del paradigma de la herramienta en lugar de imponer tu proceso sobre ella, son probablemente las cosas más difíciles de superar.
Dicho esto, el hecho de que puedas consultar DIRECTAMENTE todas las asociaciones legales entre entidades y estados en las tablas de metadata hace que este sea un problema tratable. Reseña recopilada por y alojada en G2.com.
