Checkpoint 1, disegna e difendi il progetto dei dati di Steve Trucking

Disponibile anche in 28 lingue

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Un’esercitazione originale, basata su uno scenario. Mai modellata su domande reali d’esame. È scritta nello stile di “Cosa progetterei io”: il punto è rendere visibile il tuo giudizio, non scegliere una lettera. Questa sfida chiude la Parte 1 del corso Data Architect; la mia soluzione commentata arriva nel Checkpoint 1, quindi prova prima tu.

Scenario

Steve Trucking è un’azienda di consegne dell’ultimo miglio. Grandi catene, i Partner retail, vendono elettrodomestici, TV e mobili; le squadre di due persone di Steve Trucking li consegnano ai clienti dei Partner retail (i Destinatari), ne installano alcuni e ritirano quelli vecchi. Leggi il brief di Steve Trucking, sezioni 1–8. Lascia stare la sezione 9 (le modifiche dell’ultima ora); quelle arrivano alla fine del corso.

Requisiti

Tutto ciò che è nella sezione 5 del brief (R1–R15) e nella sezione 6 (S1–S5). Quelli su cui questo checkpoint si appoggia di più:

R1. Ricevere i manifesti di carico di ogni Partner retail nel suo formato (file SFTP, API, EDI) e trasformarli in percorsi, tappe e voci senza ridigitarli.
R3. I responsabili dei CD di ogni Partner retail vedono nel portale le proprie consegne, eccezioni, foto e reclami, e mai quelli di un altro partner.
R4. I manifesti vengono modificati il giorno stesso; le modifiche dopo l’assegnazione ai percorsi vanno gestite.
S2. Un Partner retail non deve mai vedere consegne, prezzi, volumi o Destinatari di un altro partner.
S3. Il link di tracciamento del Destinatario mostra solo quella consegna, senza un account, e scade.
S4. Indirizzi, numeri di telefono e note di consegna dei Destinatari sono dati personali; le squadre li vedono solo per le proprie tappe, solo quel giorno.

Vincoli

Circa 3.300 consegne per giorno lavorativo, un milione all’anno, in crescita del 30% l’anno; circa 1,6 voci e otto cambi di stato per consegna; da quattro a cinque milioni di foto all’anno; circa 200.000 letture GPS al giorno.
Una sola org Salesforce negli Stati Uniti, che usa già Service Cloud, Field Service e un portale per i partner; MuleSoft in licenza; Data 360 in licenza ma non implementato.
Tre Partner retail, tre stili di integrazione; nove centri di distribuzione.

Il tuo compito

Disegna e difendi il progetto della Parte 1. Usa ciò che hai imparato nei capitoli 1–6:

Il panorama (capitolo 4): disegna il panorama dei sistemi dello stato attuale di Steve Trucking con il layout di Steve, con ogni freccia etichettata con ciò che si muove e come.
Il modello (capitolo 2): modella il dominio delle consegne a livello concettuale, poi logico. Partner retail, centri di distribuzione, manifesti di carico, consegne, voci, percorsi, camion, squadre, checklist di installazione, foto, firme, eccezioni e Destinatari. (Sfida D1.)
Il progetto fisico (capitolo 3): quali di questi sono oggetti standard (Field Service ha ordini di lavoro, appuntamenti di servizio, risorse di servizio e territori di servizio) e quali sono personalizzati? Di quali licenze hanno bisogno gli utenti dei partner e i Destinatari? Dove risiede ogni tipo di dato: nella org, fuori dal core, nel data warehouse?
La chiave (questo capitolo): quale chiave abbina la riga d’ordine di un Partner retail alla tua consegna, e cosa succede quando il manifesto viene modificato dopo l’assegnazione ai percorsi? (Sfida D3.)
Il Destinatario (questo capitolo): un Contatto, un account personale, o nessuno dei due? Argomentalo a partire dalla relazione, dal volume, dall’isolamento tra partner e dal ciclo di vita dei dati.
Unificare o no (questo capitolo): i Destinatari compaiono nei manifesti di diversi partner, a volte più di una volta all’anno. Li unificheresti, o deliberatamente no? Qual è il rischio, dato S2? (Sfida DC1, senza le modifiche dell’ultima ora.)
Autorità: per cinque campi chiave (il riferimento d’ordine del partner, lo stato della consegna, il numero di telefono del Destinatario, la fascia di consegna, la ragione sociale del partner), di’ chi lo crea, chi ne è responsabile, quale sistema è autorevole e chi può modificarlo.

Scrivi ogni decisione con entrambe le opzioni, poi la tua scelta: “secondo il mio giudizio professionale…”

Discussione

La mia soluzione commentata è Checkpoint 1: Steve Trucking, cosa progetterei io. Confronta il tuo ragionamento, non solo i tuoi riquadri. Dove hai scelto diversamente, sai dire cosa guadagneresti e a cosa rinunceresti?

Revisione del progetto

Per ora tieni da parte il tuo progetto. La Parte 2 lo mette alla prova con volume, query, integrazione, migrazione, transazioni e sicurezza, e la scheda di revisione del capitolo 18 lo verifica al terzo anno.

Obiettivi d’esame esercitati

DM-1, DM-2 (progettazione del modello dati; il modello rispetta la condivisione)
MDM-1, MDM-2, MDM-3, MDM-4 (gestione dei dati master, autorità, corrispondenza, tracciabilità)
SDM-1 (licenze), SDM-3 (una vista unica, e quando non costruirne una)