Cosa ti piace di più di Dynamics 365 Field Service?
Dynamics 365 Field Server (FS) consente una distribuzione molto flessibile dei contratti di servizio, avendo tutte le funzionalità della soluzione D365 CRM, con concetti FS come accordi, ordini di lavoro, compiti, ecc., integrati. Come tutto D365, la maggior parte delle entità "core" come compiti, account, utenti, team, ecc., possono essere associate tra loro in modo flessibile, e i flussi di lavoro costruiti attorno a ciò.
Inoltre, come responsabile dell'analisi dei dati, avere le associazioni possibili integrate e configurate dall'utente tra le entità rende l'automazione e la conversione dei dati in una struttura relazionale più tradizionale molto più semplice rispetto alla necessità di codificare manualmente l'ETL.
Le tabelle di metadati che descrivono gli stati possibili, i sottostati e le associazioni con le entità sono molto sistematiche, riportando persino il RUOLO di ciascun lato di un'associazione. Se lo desideri, potresti automatizzare completamente un ETL di database a grafo solo da un'attenta acquisizione delle tabelle di metadati (il che eliminerebbe il problema riportato nella sezione "dislike" che molte entità hanno oltre 100 campi (per lo più inutilizzati nella maggior parte delle implementazioni) che sono nulli se non utilizzati). Recensione raccolta e ospitata su G2.com.
Cosa non ti piace di Dynamics 365 Field Service?
La cosa che rende D365 FS (e D365 in generale) è che il modello di dati sottostante è estremamente difficile da gestire al di fuori degli strumenti offerti da Microsoft. Ci vuole un notevole sforzo per impostare la duplicazione dei dati in un database accessibile tramite SQL tradizionale (anche SQL Server). Una volta che i dati sono lì, ci si trova di fronte a ogni entità che ha OGNI POSSIBILE campo che potrebbe essere utilizzato. Le entità principali come "account", "contatto", "compito", ecc. hanno oltre 100 campi ciascuna. L'ordine delle colonne sembra casuale: i campi configurati dall'utente sono mescolati tra quelli predefiniti. Fortunatamente, i metadati disponibili tramite API sono disponibili, permettendo la costruzione di strumenti di conversione automatizzati per fare in modo che i dati estratti contengano solo i campi in uso, ordinati in un modo più gestibile.
Il commento sopra è applicabile a TUTTE le soluzioni D365, non solo a FS. FS ha due concetti chiave che mancano, che sembrano dovrebbero far parte di qualsiasi soluzione CRM->FS:
1. Mancanza di un concetto di "stato" o "pipeline" unificato dell'account: in D365. I "lead" che sono chiusi creano "opportunità", che in FS si trasformano in "accordi" ai quali possono essere associati uno o più "ordini di lavoro". Non c'è un luogo unificato, se non i collegamenti di ritorno al passaggio precedente, per capire a quale data un particolare accordo per un account (entrambi i quali potrebbero non essere creati fino a dopo che il lead è chiuso) era un lead, quando il lead è stato chiuso e ha creato un'opportunità, che poi si è trasformata in un accordo, ecc. Se vuoi costruire un report di pipeline (anche nell'interfaccia utente integrata, ma anche in SQL) devi creare manualmente join che seguono i collegamenti. È anche possibile che il front end crei entità più avanti nel processo senza il passaggio precedente (un accordo può esistere senza un'opportunità che lo ha creato, per esempio). Quando utilizzato per comprendere i tassi di chiusura, il costo di acquisizione del cliente/account, il valore a vita di un cliente, ecc., è estremamente impegnativo.
2. Le entità specifiche di FS "accordo" e "ordine di lavoro" sono state, credo, inizialmente implementate da un altro fornitore di soluzioni poi acquistate e aggiunte. (Sono denominate "msdyn_account" e "msdyn_workorder - quella convenzione di prefisso si applica anche a nuove entità/campi aggiunti dagli implementatori). Pertanto, lo "stato/sottostato" di queste due entità è gestito in modo molto diverso - in tutti gli altri built-in di D365, ci sono due campi di metadati che denotano lo "stato" dell'entità: corrente/attivo, inattivo, ecc. e "sottostato": "nuovo", "aperto", "wip", "chiuso", ecc. Negli accordi e negli ordini di lavoro, quei campi esistono, ma i campi effettivamente configurabili dall'utente che denotano lo stesso significato sono in tabelle di entità aggiuntive con GUID come chiavi invece di interi.
È un'altra cosa da aggirare.
Questi due, e il requisito assoluto comune a tutti gli ambienti di configurazione o implementazione no/low code di lavorare all'interno del paradigma dello strumento piuttosto che imporre il proprio processo su di esso, sono probabilmente le cose più difficili da superare.
Detto ciò, il fatto che si possa interrogare DIRETTAMENTE per tutte le associazioni legali tra entità e stati nelle tabelle dei metadati rende questo un problema trattabile. Recensione raccolta e ospitata su G2.com.
