Steve Truckings landskab

🌐 Findes også på 28 sprog

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

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 6 af 6 i kapitlet Forstå virksomhedens data, kapitel 4 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Org-strategi er en landskabsbeslutning · Næste: det næste kapitel, Datakvalitet og styring

Spørgsmålet, dette modul besvarer: Hvad fortæller et rigtigt landskab os, før vi designer noget som helst?

I dette kapitel har vi trukket kameraet tilbage: Salesforce som ét system blandt mange, typerne af data, systemerne omkring Salesforce, hvordan man tegner landskabet, og org-strategi. Nu samler vi det på Steve Trucking. Men vi skal ikke rette noget endnu. Det er disciplinen: tegn det, der findes, gå hver pil igennem, og se, hvad landskabet fortæller os.

Start med det, vi ved

Steve Trucking kører én Salesforce-org i USA. Service Cloud håndterer sager fra modtagere (Recipients) og detailpartnere (Retail Partners); Field Service styrer aftaler, teams og mobilappen; Experience Cloud giver detailpartnerne en portal, som i dag kun bruges til reklamationer og rapporter; Sales Cloud holder styr på partnerkontrakter og bud på nye distributionscentre (DC’er). Så Salesforce kommer i midten.

Til venstre menneskene: 45 dispatch-koordinatorer, der arbejder inde i detailpartnernes DC’er, omkring 700 teammedlemmer på 330 lastbiler, 60 kundeservicemedarbejdere, 40 medarbejdere i drift, økonomi og salg og omkring 300 brugere hos detailpartnerne. Det fortæller os allerede noget: Det her er ikke et CRM til én afdeling. Det er en driftsplatform for det meste af forretningen. Men det er stadig én boks. Lad os se, hvad der omgiver den.

Click to enlarge

Steve Trucking i dag, før en ordentlig implementering. Hvert manifest lander i RouteDesk; koordinatorerne indtaster ruterne igen i Salesforce og de afsluttede stop tilbage, i hånden; FleetLink mangler sin forbindelse.

Markér det, der er galt

Det her er en nuværende tilstand, før en ordentlig implementering, og det skriver jeg på tegningen. Så åbner jeg farvepaletten. På et landskab over et færdigt system bruger jeg ikke rødt; på en nuværende tilstand gør jeg. Rødt markerer en dårlig eller forkert proces, stiplet markerer noget, der gøres i hånden, og røde prikker markerer en forbindelse, der mangler. At udelade en pil siger også noget. Intet af det er pynt: Hver rød linje er et krav, der venter på at blive skrevet.

Tre partnere, tre integrationer

De tre detailpartnere sender manifester på tre forskellige måder, så tegn hver af dem for sig.

Keystone lægger et CSV-manifest på en SFTP-server hver eftermiddag, til levering to dage senere, og vil have en statusfil tilbage hver nat. To pile: manifest ind som fil, åbnet af Keystone, og status ud som fil, åbnet af RouteDesk. Asynkront, med et bredt tidsvindue.

Redrock sender manifester via et REST API og forventer statusopdateringer via webhook, efterhånden som tingene sker. To pile, to mekanismer: Redrock kalder ind med manifester via API’et, og RouteDesk kalder ud med status via webhooken. Næsten i realtid.

Brightwave sender EDI-filer via et tredjepartsnetværk og forventer EDI-statusbeskeder tilbage. Et andet format, en anden mekanisme.

Samme forretningsbegreber (manifest, levering, status), tre helt forskellige integrationer. Forenkl ikke tegningen, fordi du gerne ville have, at de var ens. Det er de ikke. Det er den nuværende tilstand.

Gå dem så igennem. Keystone: Hvordan autentificerer SFTP-forbindelsen, hvor lander filen, hvad henter den, hvordan ved vi, at hele filen blev behandlet, hvad sker der med en dårlig række, og hvordan hører Keystone om en ændring før aftenens fil? Redrock: Hvordan autentificerer API’et, hvad sker der, når en af siderne er nede, hvad tæller som en vellykket webhook, og hvad hvis den samme status kommer to gange? Brightwave: Hvem driver EDI-netværket, hvor sker oversættelsen, og hvilke kvitteringer kommer tilbage? Vi redesigner ikke noget. Vi finder spørgsmålene. Det er landskabets opgave.

RouteDesk er der stadig

RouteDesk er det gamle desktopværktøj til dispatch og ruteplanlægning, som koordinatorerne bruger i hvert DC til at gøre manifester til ruter. Det rummer otte års leveringshistorik, og det skal udfases. Tegn det alligevel. En almindelig fejl er at udelade systemet, »vi er ved at slippe af med«. Hvornår? Lad os sige, at svaret er atten måneder. Så er det en del af arkitekturen i mindst atten måneder, og dets otte års historik, omkring fem millioner leveringer, forsvinder ikke, når applikationen gør. Og se, hvad landskabet afslører: RouteDesk og Salesforce er ikke forbundet. Teamene arbejder med deres stop i Field Service-appen i Salesforce, men ruterne bygges i RouteDesk, så koordinatorerne indtaster dem igen i Salesforce hver aften og indtaster så de afsluttede stop tilbage i RouteDesk, så det kan sende status til partnerne. Omkring 3.300 stop om dagen, to gange, i hånden. Det er stiplet og rødt på tegningen. Det fortæller dig også, at Redrocks webhook »efterhånden som tingene sker« ikke rigtig er det. Hvad ejer RouteDesk i dag? Hvad afhænger af det? Hvilken historik skal overleve det, og hvor: Salesforce, datavarehuset, et arkiv? Vi svarer ikke endnu. Landskabet har bare afsløret spørgsmålene.

FleetLink er en ø

FleetLink, telematikplatformen, får GPS fra hver lastbil: omkring 200.000 målinger om dagen, hver lastbil, hvert minut den kører. Og den er ikke forbundet til noget. Koordinatorerne kigger på den på en separat skærm. Så tegn FleetLink uden pile. Ingen magisk integrationslinje, fordi vi synes, der burde være en.

Tæl så nullerne: 200.000 om dagen er over 70 millioner om året. Det er ikke »vi har GPS-data«. Det er en streamingkilde med mange nuller, der står uden for Salesforce-oplevelsen. Har Salesforce brug for 70 millioner målinger om året? Sandsynligvis ikke dem alle. Det er et designspørgsmål til senere.

Økonomi har sin egen sandhed

Økonomiafdelingens ERP fakturerer hver detailpartner pr. levering, montering og bortskaffelse og udbetaler incitamenter til teamene. Og leveringsantallet når frem til det via et månedligt regneark. Tegn regnearket. Erstat det ikke med en pæn API-pil, fordi vi er arkitekter og ved bedre; det er en del af den nuværende arkitektur. Og når det først er tegnet, kommer spørgsmålene: Hvem laver det, fra hvilket system, hvem tjekker det, hvad hvis en levering ændres, efter det er sendt, og hvis tal vinder? Der hænger penge på svarene.

Snowflake får en ugentlig eksport

Snowflake rummer analyser til drift og økonomi, fodret af en ugentlig eksport. Det kan Snowflake ikke selv; noget i midten gør det: et planlagt eksportjob, der kører uden for Salesforce, trækker via Bulk API og indlæser i Snowflake. Hvor analysen bor, følger af, hvor dataene bor, og Snowflake er allerede det analytiske hjem. Men timingen fortæller os også noget. »Hvad skete der sidste måned?« Et ugentligt feed er fint. »Hvor er denne levering lige nu?« Der ville jeg ikke starte med Snowflake. Samme virksomhed, anden arbejdsbelastning, anden friskhed, andet svar.

Identitet når ikke alle på samme måde

Virksomhedens identitetsudbyder kommer ovenover Salesforce. Kontorpersonalet bruger single sign-on. Men koordinatorer og teams logger ind med Salesforce-loginoplysninger. Så én tillidslinje fra IdP’en til Salesforce ville skjule halvdelen af historien. Det rigtige spørgsmål er, hvilke brugere der logger ind ad hvilken vej, og det hører hjemme på landskabet.

Modtagernes oplevelse har et hul

SMS- og e-mailudbyderen sender modtagerne en generisk besked fra RouteDesk om, at »din levering kommer i morgen«. Der er intet sporingslink. Samtidig er der omkring 180.000 sager om året, og omkring 60 % af dem er »hvor er min levering?«: cirka 108.000 sager om året, der stiller det samme spørgsmål. Læg det nu ved siden af FleetLink. Virksomheden ved, hvor dens lastbiler er. Dens modtagere bliver ved med at ringe og spørge. Og systemet, der ved det, er ikke forbundet til det, der svarer. Jeg behøver ikke designe løsningen endnu. Landskabet fortæller allerede historien.

Sæt nullerne i oversigten

Tæl nu, hvad der bevæger sig. Ligesom i modul 4 skal nullerne ikke stå på pilene; de skal i oversigten bag billedet, hvor de styrer mekanismerne, når vi designer. Omkring en million leveringer om året, omkring 3.300 om dagen, med en vækst på 30 % om året; omkring 1,6 leveringslinjer hver; omkring otte statusopdateringer hver, så otte millioner statusopdateringer om året i dag; fire til fem millioner fotos om året, i dag på teamenes egne telefoner; omkring 200.000 GPS-målinger om dagen; omkring 180.000 sager om året. En pil med teksten »leveringsstatus« er ikke en lejlighedsvis besked. Boksene fortæller dig, hvad der findes. Pilene fortæller dig, hvad der bevæger sig. Nullerne fortæller dig, om dine antagelser overlever virkeligheden.

Click to enlarge

Oversigten bag Steve Truckings landskab: volumen ved siden af den mekanisme, den vil styre.

Endnu ingen målarkitektur, og jeg kan allerede se, hvor de vigtige data bor, hvilken type de er, hvor hurtigt de bevæger sig, og hvordan systemerne udveksler dem.

Ud over eksamen: hvad AI ændrer. Forestil dig, at Steve Trucking bygger en agent, der skal svare på en modtagers »hvor er min levering?« Hvilket system skal den spørge? Salesforce kender aftalen, FleetLink ved, hvor lastbilen er, og partnerens manifest definerede leveringen. Det nuværende landskab er agentens kort, og før agenten kan svare sikkert, skal arkitekten vide, hvilket system der er autoritativt for hvert faktum, og hvor aktuelt det er. Peg en agent mod den forkerte kilde, og forældede data bliver til et selvsikkert svar.

Læs smerten, men ret den ikke endnu

Træd et skridt tilbage. Tre partnere, tre integrationsstile. Et gammelt dispatch-værktøj med otte års historik og koordinatorer, der indtaster 3.300 stop om dagen i Salesforce og tilbage igen. En telematikplatform med 200.000 målinger om dagen, uden forbindelse. Økonomi, der tæller leveringer fra et månedligt regneark. Analyser, der er en uge bagud. Single sign-on for nogle brugere, ikke for andre. Intet sporingslink og 108.000 sager om året, der spørger, hvor en levering er. Og alt sammen vokser med 30 % om året.

Det er meget arkitektur ud af ét billede. Fristelsen er at begynde at rette det. Lad være. Ikke endnu. Jeg vil have, at du er tryg ved at lade et diagram over den nuværende tilstand være grimt, for nogle gange er den nuværende tilstand grim. Pointen er ikke at imponere nogen med en pæn tegning; det er en fælles forståelse af virkeligheden. Redesigner du, mens du dokumenterer, mister du udgangspunktet. Senere vil jeg kunne sige: Det her var det, der fandtes, det her er problemet, vi løste, det her er det, vi ændrede, og hvorfor. Kapitel 6 begynder at træffe beslutninger om ejerskab og identitet, og kontrolpunkt 1 samler del 1. Kurset Integration Architect designer partnerflowene i dybden.

Hvad en arkitekt beslutter her

På dette trin beslutter arkitekten ikke målarkitekturen. Beslutningen er, om den nuværende tilstand er forstået godt nok til at designe en:

• Hvilke systemer, brugergrupper, datalagre og eksterne partnere der faktisk findes i dag.
• Hvilke data der krydser hver vigtig grænse, i hvilken retning, hvor ofte og med hvilken mekanisme.
• Hvor de operationelle, analytiske, streamende, historiske og ustrukturerede data bor nu.
• Hvilke flows der bærer mest volumen og fortjener tidlig opmærksomhed.
• Hvilke huller, manuelle trin, afkoblede systemer, uklare autoriteter og inkonsistente mønstre der bliver til eksplicitte designspørgsmål.

Dette kapitel startede med én idé: tegn landskabet, før du designer org’en. Hvis jeg var startet med Steve Truckings datamodel, kunne jeg have brugt timer på objekter og relationer, mens FleetLink stod udenfor med 200.000 målinger om dagen, RouteDesk rummede otte års historik, tre partnere talte tre sprog, økonomi brugte et regneark, og hundrede tusind sager om året spurgte, hvor en levering var. Det er ikke spørgsmål om objektmodellen. Det er spørgsmål om virksomhedens data. Tegn de grimme integrationer, regnearket, systemet, du angiveligt er ved at udfase. Skriv nullerne ned. Gå hver pil igennem. Så er du klar til at ændre det.

Læs mere

• Steve Truckings brief (på engelsk), afsnit 2–4, og dets landskabsdiagram.