Il panorama 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)

Immagine generata con l'IA

Tradotto con l'IA. Non ancora rivisto dalla comunità. Leggi in inglese

Modulo 6 di 6 del capitolo Capire i dati aziendali, capitolo 4 del corso Data Architect. Ogni modulo si regge da solo. Precedente: La strategia delle org è una decisione di panorama · Successivo: il prossimo capitolo, Qualità e governance dei dati

La domanda a cui risponde questo modulo: Cosa ci dice un panorama reale prima di progettare qualsiasi cosa?

Questo capitolo ha allargato l’inquadratura: Salesforce come un sistema tra tanti, i tipi di dati, i sistemi intorno a Salesforce, come disegnare il panorama, e la strategia delle org. Ora mettiamo tutto insieme su Steve Trucking. Ma non aggiusteremo ancora niente. È questa la disciplina: disegna ciò che esiste, percorri ogni freccia, e guarda cosa ti dice il panorama.

Parti da ciò che sappiamo

Steve Trucking ha una sola org Salesforce, negli Stati Uniti. Service Cloud gestisce i casi di Destinatari e Partner retail; Field Service gestisce appuntamenti, squadre e app mobile; Experience Cloud offre ai Partner retail un portale, usato oggi solo per reclami e report; Sales Cloud traccia i contratti con i partner e le offerte per nuovi CD. Quindi Salesforce va al centro.

A sinistra, le persone: 45 coordinatori del dispatch che lavorano dentro i CD dei Partner retail, circa 700 membri delle squadre su 330 camion, 60 operatori dell’assistenza clienti, 40 persone tra operazioni, finanza e vendite, e circa 300 utenti dei Partner retail. Questo ci dice già qualcosa: non è un CRM di reparto. È una piattaforma operativa per gran parte del business. Ma è ancora un solo riquadro. Ora vediamo cosa lo circonda.

Click to enlarge

Steve Trucking oggi, prima di un’implementazione fatta come si deve. Ogni manifesto arriva in RouteDesk; i coordinatori ridigitano a mano i percorsi in Salesforce e le tappe completate all’indietro; a FleetLink manca la connessione.

Segna ciò che non va

Questo è uno stato attuale, prima di un’implementazione fatta come si deve, e lo dico sul disegno. Poi apro la tavolozza. Nel panorama di un sistema finito non uso il rosso; in uno stato attuale sì. Il rosso indica un processo sbagliato o improprio, il tratteggio indica qualcosa fatto a mano, e i puntini rossi indicano una connessione che manca. Anche lasciare fuori una freccia dice qualcosa. Niente di tutto ciò è decorazione: ogni linea rossa è un requisito che aspetta di essere scritto.

Tre partner, tre integrazioni

I tre Partner retail inviano i manifesti di carico in tre modi diversi, quindi disegnali separatamente.

Keystone deposita ogni pomeriggio un manifesto CSV su un server SFTP, per la consegna due giorni dopo, e vuole indietro un file di stato ogni notte. Due frecce: manifesto in entrata tramite file, aperto da Keystone, e stato in uscita tramite file, aperto da RouteDesk. Asincrono, con un’ampia finestra temporale.

Redrock invia i manifesti tramite un’API REST e si aspetta gli aggiornamenti di stato tramite webhook man mano che avvengono. Due frecce, due meccanismi: Redrock chiama in entrata con i manifesti tramite l’API, e RouteDesk chiama in uscita con lo stato tramite il webhook. Quasi in tempo reale.

Brightwave invia file EDI attraverso una rete di terzi e si aspetta indietro messaggi di stato EDI. Un altro formato, un altro meccanismo.

Stessi concetti di business (manifesto, consegna, stato), tre integrazioni completamente diverse. Non semplificare il disegno perché vorresti che fossero coerenti. Non lo sono. È lo stato attuale.

Poi percorrile. Keystone: come si autentica il collegamento SFTP, dove arriva il file, cosa lo preleva, come sappiamo che l’intero file è stato elaborato, cosa succede a una riga sbagliata, e come viene a sapere Keystone di una modifica prima del file di stanotte? Redrock: come si autentica l’API, cosa succede quando una delle due parti è giù, cosa conta come webhook riuscito, e se lo stesso stato arriva due volte? Brightwave: chi gestisce la rete EDI, dove avviene la traduzione, quali conferme tornano indietro? Non stiamo riprogettando niente. Stiamo scoprendo le domande. È il lavoro del panorama.

RouteDesk è ancora lì

RouteDesk è il vecchio strumento desktop di dispatch e pianificazione dei percorsi che i coordinatori usano in ogni CD per trasformare i manifesti in percorsi. Contiene otto anni di storico delle consegne, e la sua dismissione è in programma. Disegnalo comunque. Un errore comune è lasciare fuori il sistema “di cui ci stiamo liberando”. Quando? Diciamo che la risposta sia diciotto mesi. Allora fa parte dell’architettura per almeno diciotto mesi, e i suoi otto anni di storico, circa cinque milioni di consegne, non spariscono quando sparisce l’applicazione. E guarda cosa fa emergere il panorama: RouteDesk e Salesforce non sono collegati. Le squadre lavorano le loro tappe nell’app Field Service di Salesforce, ma i percorsi si costruiscono in RouteDesk, quindi ogni sera i coordinatori li ridigitano in Salesforce, poi ridigitano le tappe completate in RouteDesk perché possa inviare lo stato ai partner. Circa 3.300 tappe al giorno, due volte, a mano. Nel disegno è tratteggiato e rosso. Ti dice anche che il webhook “man mano che avvengono” di Redrock non è davvero man mano che avvengono. Cosa possiede oggi RouteDesk? Cosa ne dipende? Quale storico deve sopravvivergli, e dove: Salesforce, il data warehouse, un archivio? Non rispondiamo ancora. Il panorama ha solo fatto emergere le domande.

FleetLink è un’isola

FleetLink, la piattaforma telematica, riceve il GPS da ogni camion: circa 200.000 letture al giorno, ogni camion, ogni minuto in cui è in movimento. E non è collegata a niente. I coordinatori la guardano su uno schermo separato. Quindi disegna FleetLink senza frecce. Nessuna linea di integrazione magica perché pensiamo che dovrebbe essercene una.

Poi conta gli zeri: 200.000 al giorno sono oltre 70 milioni all’anno. Non è “abbiamo dati GPS”. È una fonte di streaming con molti zeri, che sta fuori dall’esperienza Salesforce. Salesforce ha bisogno di 70 milioni di letture all’anno? Probabilmente non di tutte. È una domanda di progettazione per dopo.

La finanza ha la sua verità

L’ERP finanziario fattura a ogni Partner retail ogni consegna, installazione e ritiro dell’usato, e paga gli incentivi alle squadre. E i conteggi delle consegne gli arrivano tramite un foglio di calcolo mensile. Disegna il foglio di calcolo. Non sostituirlo con un’ordinata freccia API perché siamo architetti e ne sappiamo di più; fa parte dell’architettura attuale. E una volta disegnato, arrivano le domande: chi lo prepara, da quale sistema, chi lo controlla, cosa succede se una consegna cambia dopo l’invio, e quale numero vince? Alle risposte sono legati dei soldi.

Snowflake riceve un’esportazione settimanale

Snowflake contiene le analisi di operazioni e finanza, alimentate da un’esportazione settimanale. Snowflake non può farlo da solo; lo fa qualcosa nel mezzo: un job di esportazione pianificato, che gira fuori da Salesforce, estrae i dati tramite la Bulk API e li carica in Snowflake. Dove vivono le analisi segue dove vivono i dati, e Snowflake è già la sede delle analisi. Ma anche i tempi ci dicono qualcosa. “Cosa è successo il mese scorso?” Un flusso settimanale va bene. “Dov’è questa consegna in questo momento?” Snowflake non è il punto da cui partirei. Stessa azienda, carico di lavoro diverso, aggiornamento diverso, risposta diversa.

L’identità non raggiunge tutti allo stesso modo

Il provider di identità aziendale va sopra Salesforce. Il personale d’ufficio usa il single sign-on. Ma coordinatori e squadre accedono con credenziali Salesforce. Quindi una sola linea di fiducia dall’IdP a Salesforce nasconderebbe metà della storia. La vera domanda è quali utenti accedono attraverso quale percorso, e appartiene al panorama.

L’esperienza del Destinatario ha una lacuna

Il provider di SMS ed email invia ai Destinatari da RouteDesk un messaggio generico “la tua consegna è domani”. Non c’è un link di tracciamento. Intanto ci sono circa 180.000 casi all’anno, e circa il 60% sono “dov’è la mia consegna?”: circa 108.000 casi all’anno che fanno la stessa domanda. Ora metti questo accanto a FleetLink. L’azienda sa dove sono i suoi camion. I suoi Destinatari continuano a chiamare per chiederlo. E il sistema che sa non è collegato a quello che risponde. Non ho ancora bisogno di progettare la soluzione. Il panorama sta già raccontando la storia.

Metti gli zeri nell’inventario

Ora conta ciò che si muove. Come nel modulo 4, gli zeri non vanno sulle frecce; vanno nell’inventario dietro l’immagine, dove guideranno i meccanismi quando progetteremo. Circa un milione di consegne all’anno, circa 3.300 al giorno, in crescita del 30% l’anno; circa 1,6 articoli ciascuna; circa otto aggiornamenti di stato ciascuna, quindi otto milioni di aggiornamenti di stato all’anno oggi; da quattro a cinque milioni di foto all’anno, oggi sui telefoni personali delle squadre; circa 200.000 letture GPS al giorno; circa 180.000 casi all’anno. Una freccia con l’etichetta “stato della consegna” non è un messaggio occasionale. I riquadri ti dicono cosa esiste. Le frecce ti dicono cosa si muove. Gli zeri ti dicono se le tue ipotesi sopravvivono alla realtà.

Click to enlarge

L’inventario dietro il panorama di Steve Trucking: il volume accanto al meccanismo che guiderà.

Nessuna architettura futura ancora, e vedo già dove risiedono i dati importanti, di che tipo sono, quanto in fretta si muovono e come se li scambiano i sistemi.

Oltre l’esame: cosa cambia l’IA. Supponi che Steve Trucking costruisca un agente per rispondere al “dov’è la mia consegna?” di un Destinatario. A quale sistema dovrebbe chiedere? Salesforce conosce l’appuntamento, FleetLink sa dov’è il camion, il manifesto del partner ha definito la consegna. Il panorama attuale è la mappa dell’agente, e prima che l’agente possa rispondere in sicurezza, l’architetto deve sapere quale sistema è autorevole per ogni fatto e quanto è aggiornato. Punta un agente sulla fonte sbagliata e dati vecchi diventano una risposta sicura di sé.

Leggi il dolore, non aggiustarlo ancora

Fai un passo indietro. Tre partner, tre stili di integrazione. Un vecchio strumento di dispatch con otto anni di storico, e coordinatori che ridigitano 3.300 tappe al giorno in Salesforce e all’indietro. Una piattaforma telematica con 200.000 letture al giorno, scollegata. La finanza che conta le consegne da un foglio di calcolo mensile. Analisi indietro di una settimana. Single sign-on per alcuni utenti, non per altri. Nessun link di tracciamento, e 108.000 casi all’anno che chiedono dov’è una consegna. Tutto in crescita del 30% l’anno.

È molta architettura da una sola immagine. La tentazione è iniziare ad aggiustarla. Non farlo. Non ancora. Voglio che tu sia a tuo agio nel lasciare brutto un diagramma dello stato attuale, perché a volte lo stato attuale è brutto. Il punto non è impressionare qualcuno con un disegno pulito; è una comprensione condivisa della realtà. Riprogetta mentre documenti e perdi il punto di riferimento. Più avanti voglio poter dire: questo è ciò che esisteva, questo è il problema che abbiamo risolto, questo è ciò che abbiamo cambiato, e perché. Il capitolo 6 inizia a prendere decisioni su titolarità e identità, e il Checkpoint 1 mette insieme la Parte 1. Il corso Integration Architect progetta in profondità i flussi con i partner.

Cosa decide qui un architetto

In questa fase l’architetto non sta decidendo l’architettura futura. La decisione è se lo stato attuale è compreso abbastanza bene da progettarne una:

• Quali sistemi, popolazioni di utenti, archivi di dati e partner esterni esistono davvero oggi.
• Quali dati attraversano ogni confine importante, in quale direzione, con quale frequenza e con quale meccanismo.
• Dove risiedono ora i dati operativi, analitici, di streaming, storici e non strutturati.
• Quali flussi portano più volume e meritano attenzione per primi.
• Quali lacune, passaggi manuali, sistemi scollegati, autorità poco chiare e schemi incoerenti diventano domande di progettazione esplicite.

Questo capitolo è partito da un’idea: disegna il panorama prima di progettare la org. Se fossi partito dal modello dati di Steve Trucking, avrei potuto passare ore su oggetti e relazioni mentre FleetLink restava fuori con 200.000 letture al giorno, RouteDesk conteneva otto anni di storico, tre partner parlavano tre lingue, la finanza usava un foglio di calcolo, e centomila casi all’anno chiedevano dov’era una consegna. Non sono domande sul modello a oggetti. Sono domande sui dati aziendali. Disegna le integrazioni brutte, il foglio di calcolo, il sistema che dovresti dismettere. Scrivi gli zeri. Percorri ogni freccia. Allora sei pronto a cambiarlo.

Per approfondire

• Il brief di Steve Trucking, sezioni 2–4, e il suo diagramma del panorama.