Krajobraz Steve Trucking

🌐 Dostępne także w 28 językach

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

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku

Moduł 6 z 6 w rozdziale Zrozumieć dane przedsiębiorstwa, rozdziale 4 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Strategia orgów to decyzja o krajobrazie · Dalej: następny rozdział, Jakość danych i ład danych

Pytanie, na które odpowiada ten moduł: co prawdziwy krajobraz mówi nam, zanim cokolwiek zaprojektujemy?

Ten rozdział odsuwał kamerę: Salesforce jako jeden system z wielu, rodzaje danych, systemy wokół Salesforce, rysowanie krajobrazu i strategia orgów. Teraz złóżmy to razem na przykładzie Steve Trucking. Ale jeszcze niczego nie będziemy naprawiać. Na tym polega dyscyplina: narysuj to, co istnieje, przejdź po każdej strzałce i zobacz, co mówi ci krajobraz.

Zacznij od tego, co wiemy

Steve Trucking ma jeden org Salesforce, w USA. Service Cloud obsługuje zgłoszenia od odbiorców i partnerów detalicznych; Field Service obsługuje wizyty, ekipy i aplikację mobilną; Experience Cloud daje partnerom detalicznym portal, dziś używany tylko do reklamacji i raportów; Sales Cloud śledzi umowy z partnerami i oferty na nowe CD. Salesforce trafia więc na środek.

Po lewej ludzie: 45 dyspozytorów pracujących w centrach dystrybucyjnych partnerów detalicznych, około 700 członków ekip na 330 ciężarówkach, 60 agentów obsługi klienta, 40 osób z operacji, finansów i sprzedaży oraz około 300 użytkowników u partnerów detalicznych. To już coś nam mówi: to nie jest działowy CRM. To platforma operacyjna dla większości biznesu. Ale to wciąż jeden prostokąt. Zobaczmy teraz, co go otacza.

Click to enlarge

Steve Trucking dziś, przed porządnym wdrożeniem. Każdy manifest ląduje w RouteDesk; koordynatorzy ręcznie przepisują trasy do Salesforce, a ukończone przystanki z powrotem; FleetLinkowi brakuje połączenia.

Zaznacz, co jest nie tak

To jest stan obecny, sprzed porządnego wdrożenia, i piszę to na rysunku. Potem otwieram paletę. Na krajobrazie gotowego systemu nie używam czerwieni; na stanie obecnym tak. Czerwony oznacza zły albo niewłaściwy proces, linia przerywana oznacza coś robionego ręcznie, a czerwone kropki oznaczają brakujące połączenie. Pominięcie strzałki też coś mówi. Nic z tego nie jest dekoracją: każda czerwona linia to wymaganie czekające na zapisanie.

Trzech partnerów, trzy integracje

Trzech partnerów detalicznych wysyła manifesty na trzy różne sposoby, więc narysuj każdego osobno.

Keystone co popołudnie wrzuca manifest CSV na serwer SFTP, z dostawami na pojutrze, i każdej nocy chce z powrotem pliku statusów. Dwie strzałki: manifest do środka plikiem, otwierany przez Keystone, i status na zewnątrz plikiem, otwierany przez RouteDesk. Asynchronicznie, z szerokim oknem czasowym.

Redrock wysyła manifesty przez REST API i oczekuje aktualizacji statusu przez webhook na bieżąco. Dwie strzałki, dwa mechanizmy: Redrock wywołuje API z manifestami, a RouteDesk wywołuje webhook ze statusem. Prawie w czasie rzeczywistym.

Brightwave wysyła pliki EDI przez sieć zewnętrznego dostawcy i oczekuje z powrotem komunikatów statusu EDI. Inny format, inny mechanizm.

Te same pojęcia biznesowe (manifest, dostawa, status), trzy zupełnie różne integracje. Nie upraszczaj rysunku, bo wolałoby się, żeby były spójne. Nie są. Taki jest stan obecny.

Potem przejdź po nich. Keystone: jak uwierzytelnia się połączenie SFTP, gdzie ląduje plik, co go odbiera, skąd wiemy, że cały plik został przetworzony, co się dzieje ze złym wierszem i jak Keystone dowiaduje się o zmianie przed dzisiejszym nocnym plikiem? Redrock: jak uwierzytelnia się API, co się dzieje, gdy któraś strona nie działa, co uznaje się za udany webhook, co, jeśli ten sam status przyjdzie dwa razy? Brightwave: kto prowadzi sieć EDI, gdzie odbywa się tłumaczenie, jakie potwierdzenia wracają? Niczego nie przeprojektowujemy. Odkrywamy pytania. To jest zadanie krajobrazu.

RouteDesk wciąż tam jest

RouteDesk to stare, desktopowe narzędzie do dyspozycji i planowania tras, którego koordynatorzy używają w każdym CD, żeby zamieniać manifesty na trasy. Przechowuje osiem lat historii dostaw i jest zaplanowane do wycofania. I tak je narysuj. Częsty błąd to pominięcie systemu, „którego się pozbywamy”. Kiedy? Powiedzmy, że odpowiedź brzmi: za osiemnaście miesięcy. W takim razie przez co najmniej osiemnaście miesięcy jest częścią architektury, a jego osiem lat historii, około pięciu milionów dostaw, nie znika razem z aplikacją. I spójrz, co odsłania krajobraz: RouteDesk i Salesforce nie są połączone. Ekipy obsługują swoje przystanki w aplikacji Field Service w Salesforce, ale trasy powstają w RouteDesk, więc koordynatorzy co wieczór przepisują je do Salesforce, a potem przepisują ukończone przystanki z powrotem do RouteDesk, żeby mógł wysłać status partnerom. Około 3300 przystanków dziennie, dwa razy, ręcznie. Na rysunku to linia przerywana i czerwona. Mówi ci to też, że webhook Redrock „na bieżąco” wcale nie jest na bieżąco. Czego RouteDesk jest dziś właścicielem? Co od niego zależy? Jaka historia musi go przetrwać i gdzie: w Salesforce, w hurtowni, w archiwum? Jeszcze nie odpowiadamy. Krajobraz właśnie odsłonił pytania.

FleetLink to wyspa

FleetLink, platforma telematyczna, dostaje GPS z każdej ciężarówki: około 200 000 odczytów dziennie, z każdej ciężarówki, w każdej minucie jej pracy. I nie jest z niczym połączona. Dyspozytorzy patrzą na nią na osobnym ekranie. Narysuj więc FleetLink bez strzałek. Żadnej magicznej linii integracji tylko dlatego, że uważamy, że powinna tam być.

Potem policz zera: 200 000 dziennie to ponad 70 milionów rocznie. To nie jest „mamy dane GPS”. To źródło strumieniowe z mnóstwem zer, leżące poza doświadczeniem Salesforce. Czy Salesforce potrzebuje 70 milionów odczytów rocznie? Raczej nie wszystkich. To pytanie projektowe na później.

Finanse mają własną prawdę

Finansowy ERP fakturuje każdego partnera detalicznego za każdą dostawę, instalację i wywóz oraz wypłaca premie ekipom. A liczby dostaw docierają do niego przez comiesięczny arkusz kalkulacyjny. Narysuj arkusz. Nie zastępuj go schludną strzałką API, bo jesteśmy architektami i wiemy lepiej; to część obecnej architektury. A gdy już jest narysowany, przychodzą pytania: kto go przygotowuje, z którego systemu, kto go sprawdza, co, jeśli dostawa zmieni się po wysłaniu, i czyja liczba wygrywa? Do odpowiedzi przypięte są pieniądze.

Snowflake dostaje cotygodniowy eksport

Snowflake przechowuje analitykę operacyjną i finansową, zasilaną cotygodniowym eksportem. Snowflake sam tego nie zrobi; robi to coś pośrodku: zaplanowane zadanie eksportu, działające poza Salesforce, które pobiera dane przez Bulk API i ładuje je do Snowflake. To, gdzie mieszka analityka, wynika z tego, gdzie mieszkają dane, a Snowflake już jest domem analityki. Ale coś mówi nam też czas. „Co się wydarzyło w zeszłym miesiącu?” Cotygodniowe zasilanie wystarczy. „Gdzie jest ta dostawa w tej chwili?” Od Snowflake bym nie zaczynał. To samo przedsiębiorstwo, inne obciążenie, inna świeżość, inna odpowiedź.

Tożsamość nie dociera do wszystkich tak samo

Firmowy dostawca tożsamości idzie nad Salesforce. Pracownicy biurowi używają single sign-on. Ale koordynatorzy i ekipy logują się danymi uwierzytelniającymi Salesforce. Jedna linia zaufania z IdP do Salesforce ukryłaby więc połowę historii. Prawdziwe pytanie brzmi: którzy użytkownicy logują się którą ścieżką, a to należy do krajobrazu.

W doświadczeniu odbiorcy jest luka

Dostawca SMS i e-mail wysyła odbiorcom z RouteDesk ogólną wiadomość „Twoja dostawa jest jutro”. Nie ma linku do śledzenia. Tymczasem zgłoszeń jest około 180 000 rocznie, a około 60% z nich to „gdzie moja dostawa?”: mniej więcej 108 000 zgłoszeń rocznie z tym samym pytaniem. Teraz postaw to obok FleetLink. Firma wie, gdzie są jej ciężarówki. Jej odbiorcy ciągle dzwonią, żeby o to zapytać. A system, który wie, nie jest połączony z tym, który odpowiada. Nie muszę jeszcze projektować rozwiązania. Krajobraz już opowiada historię.

Wpisz zera do inwentarza

Teraz policz, co się przemieszcza. Jak w module 4, zera nie trafiają na strzałki; trafiają do inwentarza za obrazem, gdzie wyznaczą mechanizmy, kiedy będziemy projektować. Około miliona dostaw rocznie, około 3300 dziennie, ze wzrostem o 30% rocznie; około 1,6 pozycji na dostawę; około ośmiu aktualizacji statusu na dostawę, czyli dziś osiem milionów aktualizacji statusu rocznie; cztery do pięciu milionów zdjęć rocznie, obecnie na prywatnych telefonach ekip; około 200 000 odczytów GPS dziennie; około 180 000 zgłoszeń rocznie. Strzałka z etykietą „status dostawy” to nie okazjonalny komunikat. Prostokąty mówią ci, co istnieje. Strzałki mówią ci, co się przemieszcza. Zera mówią ci, czy twoje założenia przetrwają zderzenie z rzeczywistością.

Click to enlarge

Inwentarz za krajobrazem Steve Trucking: wolumen obok mechanizmu, który wyznaczy.

Nie ma jeszcze architektury docelowej, a już widzę, gdzie mieszkają ważne dane, jakiego są rodzaju, jak szybko się przemieszczają i jak wymieniają je systemy.

Poza egzaminem: co zmienia AI. Załóżmy, że Steve Trucking buduje agenta, który ma odpowiadać na pytanie odbiorcy „gdzie moja dostawa?”. Który system powinien pytać? Salesforce zna wizytę, FleetLink wie, gdzie jest ciężarówka, manifest partnera zdefiniował dostawę. Obecny krajobraz to mapa agenta, a zanim agent będzie mógł bezpiecznie odpowiadać, architekt musi wiedzieć, który system jest nadrzędny dla każdego faktu i jak bardzo jest aktualny. Skieruj agenta do złego źródła, a nieaktualne dane staną się pewną siebie odpowiedzią.

Odczytaj ból, jeszcze go nie lecz

Cofnij się o krok. Trzech partnerów, trzy style integracji. Stare narzędzie dyspozytorskie z ośmioma latami historii i koordynatorzy przepisujący 3300 przystanków dziennie do Salesforce i z powrotem. Platforma telematyczna z 200 000 odczytów dziennie, odłączona. Finanse liczące dostawy z comiesięcznego arkusza. Analityka tydzień w tyle. Single sign-on dla części użytkowników, dla innych nie. Brak linku do śledzenia i 108 000 zgłoszeń rocznie z pytaniem, gdzie jest dostawa. A wszystko rośnie o 30% rocznie.

To dużo architektury z jednego obrazu. Kusi, żeby zacząć to naprawiać. Nie rób tego. Jeszcze nie. Chcę, żeby zostawienie brzydkiego diagramu stanu obecnego nie sprawiało ci kłopotu, bo czasem stan obecny jest brzydki. Nie chodzi o to, żeby komuś zaimponować czystym rysunkiem; chodzi o wspólne zrozumienie rzeczywistości. Przeprojektuj w trakcie dokumentowania, a stracisz punkt odniesienia. Później chcę móc powiedzieć: to istniało, to jest problem, który rozwiązaliśmy, to zmieniliśmy, i oto dlaczego. Rozdział 6 zaczyna podejmować decyzje o własności i tożsamości, a Punkt kontrolny 1 składa część 1 w całość. Kurs Integration Architect szczegółowo projektuje przepływy z partnerami.

Co tu decyduje architekt

Na tym etapie architekt nie decyduje o architekturze docelowej. Decyzja dotyczy tego, czy stan obecny jest zrozumiany na tyle dobrze, żeby ją zaprojektować:

• Jakie systemy, grupy użytkowników, magazyny danych i partnerzy zewnętrzni naprawdę dziś istnieją.
• Jakie dane przekraczają każdą ważną granicę, w którym kierunku, jak często i jakim mechanizmem.
• Gdzie dziś mieszkają dane operacyjne, analityczne, strumieniowe, historyczne i nieustrukturyzowane.
• Które przepływy niosą największy wolumen i zasługują na wczesną uwagę.
• Które luki, ręczne kroki, odłączone systemy, niejasne autorytety i niespójne wzorce stają się jawnymi pytaniami projektowymi.

Ten rozdział zaczął się od jednej myśli: narysuj krajobraz, zanim zaprojektujesz org. Gdybym zaczął od modelu danych Steve Trucking, mógłbym spędzić godziny nad obiektami i relacjami, podczas gdy FleetLink stałby z boku z 200 000 odczytów dziennie, RouteDesk trzymałby osiem lat historii, trzech partnerów mówiłoby trzema językami, finanse używałyby arkusza, a sto tysięcy zgłoszeń rocznie pytałoby, gdzie jest dostawa. To nie są pytania o model obiektów. To pytania o dane przedsiębiorstwa. Narysuj brzydkie integracje, arkusz, system, który rzekomo wycofujesz. Zapisz zera. Przejdź po każdej strzałce. Wtedy możesz zacząć to zmieniać.

Do zgłębienia

• Opis Steve Trucking (po angielsku), sekcje 2–4, oraz jego diagram krajobrazu.