Die Landschaft von Steve Trucking

🌐 Auch in 28 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · Italiano · 한국어 · 简体中文 · 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)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen

Modul 6 von 6 im Kapitel Unternehmensdaten verstehen, Kapitel 4 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Die Org-Strategie ist eine Entscheidung über die Landschaft · Weiter: das nächste Kapitel, Datenqualität und Governance

Die Frage, die dieses Modul beantwortet: Was sagt uns eine echte Landschaft, bevor wir irgendetwas entwerfen?

Dieses Kapitel hat die Kamera zurückgezogen: Salesforce als ein System unter vielen, die Arten von Daten, die Systeme rund um Salesforce, wie man die Landschaft zeichnet, und die Org-Strategie. Setzen wir es jetzt bei Steve Trucking zusammen. Aber wir werden noch nichts reparieren. Das ist die Disziplin: zeichnen, was existiert, jeden Pfeil abgehen und sehen, was uns die Landschaft sagt.

Beginnen Sie mit dem, was wir wissen

Steve Trucking betreibt eine Salesforce-Org, in den USA. Service Cloud bearbeitet Kundenvorgänge von Empfängern und Handelspartnern; Field Service steuert Termine, Crews und die mobile App; Experience Cloud gibt den Handelspartnern ein Portal, das heute nur für Reklamationen und Berichte genutzt wird; Sales Cloud verfolgt Partnerverträge und Angebote für neue Verteilzentren. Salesforce kommt also in die Mitte.

Links die Menschen: 45 Disponent:innen, die in den Verteilzentren der Handelspartner arbeiten, etwa 700 Crewmitglieder auf 330 Lkw, 60 Mitarbeitende im Kundenservice, 40 Mitarbeitende aus Betrieb, Finanzen und Vertrieb und etwa 300 Benutzer bei den Handelspartnern. Das sagt uns schon etwas: Das ist kein Abteilungs-CRM. Es ist eine operative Plattform für den größten Teil des Geschäfts. Aber es ist immer noch ein Kasten. Schauen wir jetzt, was ihn umgibt.

Click to enlarge

Steve Trucking heute, vor einer richtigen Implementierung. Jede Ladeliste landet in RouteDesk; die Disposition tippt Touren von Hand in Salesforce ab und abgeschlossene Stopps zurück; FleetLink fehlt die Verbindung.

Markieren Sie, was falsch ist

Das ist ein Ist-Zustand vor einer richtigen Implementierung, und das schreibe ich auf die Zeichnung. Dann öffne ich die Farbpalette. In der Landschaft eines fertigen Systems verwende ich kein Rot; in einem Ist-Zustand schon. Rot markiert einen schlechten oder unsachgemäßen Prozess, gestrichelt markiert etwas, das von Hand erledigt wird, und rote Punkte markieren eine fehlende Verbindung. Einen Pfeil wegzulassen sagt auch etwas. Nichts davon ist Dekoration: Jede rote Linie ist eine Anforderung, die darauf wartet, geschrieben zu werden.

Drei Partner, drei Integrationen

Die drei Handelspartner schicken ihre Ladelisten auf drei verschiedene Arten, also zeichnen Sie jede einzeln.

Keystone legt jeden Nachmittag eine CSV-Ladeliste auf einem SFTP-Server ab, für die Lieferung zwei Tage später, und will jede Nacht eine Statusdatei zurück. Zwei Pfeile: Ladeliste per Datei hinein, geöffnet von Keystone, und Status per Datei hinaus, geöffnet von RouteDesk. Asynchron, mit einem weiten Zeitfenster.

Redrock schickt Ladelisten über eine REST-API und erwartet Statusaktualisierungen per Webhook, sobald sie passieren. Zwei Pfeile, zwei Mechanismen: Redrock ruft mit Ladelisten über die API herein, und RouteDesk ruft mit dem Status über den Webhook hinaus. Nahezu Echtzeit.

Brightwave schickt EDI-Dateien über ein Netzwerk eines Drittanbieters und erwartet EDI-Statusnachrichten zurück. Ein weiteres Format, ein weiterer Mechanismus.

Dieselben Geschäftskonzepte (Ladeliste, Lieferung, Status), drei völlig verschiedene Integrationen. Vereinfachen Sie die Zeichnung nicht, weil Sie sich wünschen, sie wären einheitlich. Sie sind es nicht. Das ist der Ist-Zustand.

Dann gehen Sie sie ab. Keystone: Wie authentifiziert sich die SFTP-Verbindung, wo landet die Datei, was holt sie ab, woher wissen wir, dass die ganze Datei verarbeitet wurde, was passiert mit einer fehlerhaften Zeile, und wie erfährt Keystone von einer Änderung vor der Datei heute Nacht? Redrock: Wie authentifiziert sich die API, was passiert, wenn eine Seite ausfällt, was gilt als erfolgreicher Webhook, was, wenn derselbe Status zweimal ankommt? Brightwave: Wer betreibt das EDI-Netzwerk, wo findet die Übersetzung statt, welche Bestätigungen kommen zurück? Wir gestalten nichts neu. Wir entdecken die Fragen. Das ist die Aufgabe der Landschaft.

RouteDesk ist immer noch da

RouteDesk ist das alte Desktop-Werkzeug für Disposition und Tourenplanung, mit dem die Disposition in jedem Verteilzentrum Ladelisten in Touren verwandelt. Es enthält acht Jahre Lieferhistorie, und seine Ablösung ist geplant. Zeichnen Sie es trotzdem. Ein häufiger Fehler ist, das System wegzulassen, „das wir loswerden“. Wann? Sagen wir, die Antwort lautet achtzehn Monate. Dann ist es mindestens achtzehn Monate lang Teil der Architektur, und seine acht Jahre Historie, etwa fünf Millionen Lieferungen, verschwinden nicht, wenn die Anwendung verschwindet. Und schauen Sie, was die Landschaft offenlegt: RouteDesk und Salesforce sind nicht verbunden. Die Crews arbeiten ihre Stopps in der Field-Service-App von Salesforce ab, aber die Touren werden in RouteDesk gebaut, also tippt die Disposition sie jeden Abend in Salesforce ab und tippt dann die abgeschlossenen Stopps zurück in RouteDesk, damit es den Partnern den Status schicken kann. Etwa 3.300 Stopps am Tag, zweimal, von Hand. Das ist gestrichelt und rot in der Zeichnung. Es sagt Ihnen auch, dass der Webhook „sobald sie passieren“ für Redrock nicht wirklich passiert, sobald sie passieren. Was gehört RouteDesk heute? Was hängt von ihm ab? Welche Historie muss es überleben, und wo: Salesforce, das Data Warehouse, ein Archiv? Wir antworten noch nicht. Die Landschaft hat nur die Fragen offengelegt.

FleetLink ist eine Insel

FleetLink, die Telematikplattform, bekommt GPS von jedem Lkw: etwa 200.000 Messwerte am Tag, jeder Lkw, jede Minute, in der er fährt. Und es ist mit nichts verbunden. Die Disposition schaut es sich auf einem separaten Bildschirm an. Zeichnen Sie FleetLink also ohne Pfeile. Keine magische Integrationslinie, weil wir finden, es sollte eine geben.

Dann zählen Sie die Nullen: 200.000 am Tag sind über 70 Millionen im Jahr. Das ist nicht „Wir haben GPS-Daten“. Es ist eine Streaming-Quelle mit vielen Nullen, die außerhalb des Salesforce-Erlebnisses liegt. Braucht Salesforce 70 Millionen Messwerte im Jahr? Wahrscheinlich nicht alle. Das ist eine Entwurfsfrage für später.

Die Finanzabteilung hat ihre eigene Wahrheit

Das Finanz-ERP fakturiert jedem Handelspartner jede Lieferung, Installation und Mitnahme und zahlt die Prämien der Crews. Und die Lieferzahlen erreichen es über eine monatliche Tabelle. Zeichnen Sie die Tabelle. Ersetzen Sie sie nicht durch einen ordentlichen API-Pfeil, weil wir in der Architektur es besser wissen; sie ist Teil der aktuellen Architektur. Und sobald sie gezeichnet ist, kommen die Fragen: Wer erstellt sie, aus welchem System, wer prüft sie, was, wenn sich eine Lieferung nach dem Versand ändert, und wessen Zahl gewinnt? An den Antworten hängt Geld.

Snowflake bekommt einen wöchentlichen Export

Snowflake hält die Analytik für Betrieb und Finanzen, gespeist von einem wöchentlichen Export. Snowflake kann das nicht selbst; etwas in der Mitte tut es: ein geplanter Exportjob, der außerhalb von Salesforce läuft, die Daten über die Bulk API holt und in Snowflake lädt. Wo die Analytik lebt, folgt daraus, wo die Daten leben, und Snowflake ist bereits das analytische Zuhause. Aber auch das Timing sagt uns etwas. „Was ist letzten Monat passiert?“ Ein wöchentlicher Feed reicht. „Wo ist diese Lieferung gerade?“ Bei Snowflake würde ich nicht anfangen. Dasselbe Unternehmen, andere Arbeitslast, andere Aktualität, andere Antwort.

Die Identität erreicht nicht alle auf dieselbe Weise

Der Identitätsanbieter des Unternehmens kommt über Salesforce. Die Büroteams nutzen Single Sign-on. Aber Disposition und Crews melden sich mit Salesforce-Zugangsdaten an. Eine einzige Vertrauenslinie vom IdP zu Salesforce würde also die halbe Geschichte verbergen. Die echte Frage ist, welche Benutzer sich über welchen Weg anmelden, und das gehört in die Landschaft.

Das Erlebnis des Empfängers hat eine Lücke

Der SMS- und E-Mail-Anbieter schickt den Empfängern aus RouteDesk eine allgemeine Nachricht „Ihre Lieferung kommt morgen“. Es gibt keinen Sendungsverfolgungslink. Gleichzeitig gibt es etwa 180.000 Kundenvorgänge im Jahr, und etwa 60 % davon lauten „Wo ist meine Lieferung?“: rund 108.000 Kundenvorgänge im Jahr mit derselben Frage. Legen Sie das jetzt neben FleetLink. Das Unternehmen weiß, wo seine Lkw sind. Seine Empfänger rufen immer wieder an, um es zu erfragen. Und das System, das es weiß, ist nicht mit dem verbunden, das antwortet. Ich muss die Lösung noch nicht entwerfen. Die Landschaft erzählt die Geschichte schon.

Tragen Sie die Nullen ins Inventar ein

Jetzt zählen Sie, was sich bewegt. Wie in Modul 4 kommen die Nullen nicht auf die Pfeile; sie kommen in das Inventar hinter dem Bild, wo sie die Mechanismen bestimmen, wenn wir entwerfen. Etwa eine Million Lieferungen pro Jahr, etwa 3.300 am Tag, mit 30 % Wachstum pro Jahr; etwa 1,6 Positionen pro Lieferung; etwa acht Statusaktualisierungen pro Lieferung, also heute acht Millionen Statusaktualisierungen pro Jahr; vier bis fünf Millionen Fotos im Jahr, derzeit auf den eigenen Handys der Crews; etwa 200.000 GPS-Messwerte am Tag; etwa 180.000 Kundenvorgänge im Jahr. Ein Pfeil mit der Beschriftung „Lieferstatus“ ist keine gelegentliche Nachricht. Die Kästen sagen Ihnen, was existiert. Die Pfeile sagen Ihnen, was sich bewegt. Die Nullen sagen Ihnen, ob Ihre Annahmen die Wirklichkeit überleben.

Click to enlarge

Das Inventar hinter der Landschaft von Steve Trucking: das Volumen neben dem Mechanismus, den es bestimmen wird.

Noch keine Zielarchitektur, und ich sehe schon, wo die wichtigen Daten liegen, welche Art sie haben, wie schnell sie sich bewegen und wie die Systeme sie austauschen.

Über die Prüfung hinaus: Was KI ändert. Angenommen, Steve Trucking baut einen Agenten, der das „Wo ist meine Lieferung?“ eines Empfängers beantwortet. Welches System soll er fragen? Salesforce kennt den Termin, FleetLink weiß, wo der Lkw ist, die Ladeliste des Partners hat die Lieferung definiert. Die aktuelle Landschaft ist die Karte des Agenten, und bevor der Agent sicher antworten kann, müssen wir in der Architektur wissen, welches System für jede Tatsache maßgeblich ist und wie aktuell es ist. Richten Sie einen Agenten auf die falsche Quelle, und veraltete Daten werden zu einer selbstbewussten Antwort.

Lesen Sie den Schmerz, reparieren Sie ihn noch nicht

Treten Sie zurück. Drei Partner, drei Integrationsstile. Ein altes Dispositionswerkzeug mit acht Jahren Historie, und die Disposition tippt 3.300 Stopps am Tag in Salesforce ab und wieder zurück. Eine Telematikplattform mit 200.000 Messwerten am Tag, unverbunden. Die Finanzabteilung zählt Lieferungen aus einer monatlichen Tabelle. Die Analytik hinkt eine Woche hinterher. Single Sign-on für manche Benutzer, nicht für andere. Kein Sendungsverfolgungslink, und 108.000 Kundenvorgänge im Jahr, die fragen, wo eine Lieferung ist. Alles wächst um 30 % pro Jahr.

Das ist viel Architektur aus einem einzigen Bild. Die Versuchung ist, mit dem Reparieren zu beginnen. Tun Sie es nicht. Noch nicht. Ich möchte, dass Sie es aushalten, ein Diagramm des Ist-Zustands hässlich zu lassen, denn manchmal ist der Ist-Zustand hässlich. Es geht nicht darum, irgendwen mit einer sauberen Zeichnung zu beeindrucken; es geht um ein gemeinsames Verständnis der Wirklichkeit. Gestalten Sie um, während Sie dokumentieren, und Sie verlieren die Ausgangslage. Später möchte ich sagen können: Das existierte, das ist das Problem, das wir gelöst haben, das haben wir geändert, und warum. Kapitel 6 beginnt, Entscheidungen über Eigentümerschaft und Identität zu treffen, und Checkpoint 1 setzt Teil 1 zusammen. Der Kurs Integration Architect entwirft die Partnerflüsse in der Tiefe.

Was Architekt:innen hier entscheiden

In diesem Stadium wird in der Architektur nicht über die Zielarchitektur entschieden. Die Entscheidung ist, ob der Ist-Zustand gut genug verstanden ist, um eine zu entwerfen:

• Welche Systeme, Benutzergruppen, Datenspeicher und externen Partner es heute tatsächlich gibt.
• Welche Daten jede wichtige Grenze überschreiten, in welche Richtung, wie oft und über welchen Mechanismus.
• Wo die operativen, analytischen, Streaming-, historischen und unstrukturierten Daten jetzt liegen.
• Welche Flüsse das meiste Volumen tragen und früh Aufmerksamkeit verdienen.
• Welche Lücken, manuellen Schritte, unverbundenen Systeme, unklaren Autoritäten und uneinheitlichen Muster zu ausdrücklichen Entwurfsfragen werden.

Dieses Kapitel begann mit einer Idee: Zeichnen Sie die Landschaft, bevor Sie die Org entwerfen. Hätte ich mit dem Datenmodell von Steve Trucking begonnen, hätte ich Stunden mit Objekten und Beziehungen verbringen können, während FleetLink mit 200.000 Messwerten am Tag draußen lag, RouteDesk acht Jahre Historie hielt, drei Partner drei Sprachen sprachen, die Finanzabteilung eine Tabelle nutzte und hunderttausend Kundenvorgänge im Jahr fragten, wo eine Lieferung ist. Das sind keine Fragen des Objektmodells. Es sind Fragen der Unternehmensdaten. Zeichnen Sie die hässlichen Integrationen, die Tabelle, das System, das Sie angeblich ablösen. Schreiben Sie die Nullen auf. Gehen Sie jeden Pfeil ab. Dann sind Sie bereit, es zu ändern.

Weiterlesen

• Der Steckbrief von Steve Trucking (auf Englisch), Abschnitte 2 bis 4, und sein Landschaftsdiagramm.