Cosa Le 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 CRM D365, con concetti FS come accordi, ordini di lavoro, attività, ecc., integrati. Come tutto D365, la maggior parte delle entità "core" come attività, account, utenti, team, ecc., può essere associata in modo flessibile tra loro e i flussi di lavoro possono essere 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ù facile rispetto alla codifica manuale dell'ETL.
Le tabelle dei metadati che descrivono possibili stati, sottostati e associazioni con entità sono molto sistematiche, riportando persino il RUOLO di ciascun lato di un'associazione. Se lo desideri, potresti automatizzare completamente un ETL di database grafico solo dall'assunzione accurata delle tabelle dei metadati (il che eliminerebbe il problema segnalato 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 Le 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ì, ti trovi di fronte a ogni entità che ha OGNI POSSIBILE campo che potrebbe essere utilizzato. Le entità principali come "account", "contatto", "attività", ecc. hanno oltre 100 campi ciascuna. L'ordine delle colonne sembra casuale: i campi configurati dall'utente sono mescolati tra quelli integrati. Fortunatamente, i metadati disponibili tramite API sono disponibili, consentendo 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 far parte di qualsiasi soluzione CRM->FS:
1. Mancanza di un concetto di "stato" o "pipeline" unificato dell'account: in D365. I "lead" che vengono chiusi creano "opportunità", che in FS si trasformano in "accordi" a cui possono essere associate una o più "ordini di lavoro". Non c'è un luogo unificato, a parte i collegamenti di ritorno al passaggio precedente, per capire a quale data un particolare accordo per un account (nessuno dei quali può essere creato fino a quando il lead non è chiuso) era un lead, quando il lead è stato chiuso e ha creato un'opportunità, che poi si è trasformata in un accordo, ecc. Se vuoi creare un rapporto di pipeline (anche nell'interfaccia grafica 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, ad esempio). Quando viene utilizzato per comprendere i tassi di chiusura, il costo di acquisizione del cliente/account, il valore a vita di un cliente, ecc., è super impegnativo.
2. Le entità specifiche di FS "accordo" e "ordine di lavoro" sono state, credo, implementate inizialmente da un altro fornitore di soluzioni e poi acquistate e aggiunte. (Sono chiamate "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à sono gestiti in modo molto diverso: in tutti gli altri integrati 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 configurabili dall'utente che denotano lo stesso significato sono in tabelle di entità aggiuntive con GUID per chiavi invece di interi.
È un'altra cosa da aggirare.
Questi due, e il requisito assoluto comune a tutti gli ambienti di configurazione o implementazione senza codice o a basso codice 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 questo, il fatto che tu possa interrogare DIRETTAMENTE tutte le associazioni legali tra entità e stati nelle tabelle dei metadati rende questo un problema trattabile. Recensione raccolta e ospitata su G2.com.
