Systémová krajina Steve Trucking

🌐 K dispozici také v 29 jazycích

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 · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Obrázek vytvořený pomocí AI

Přeloženo pomocí AI. Komunita překlad zatím nezkontrolovala. Číst anglicky

Modul 6 z 6 kapitoly Porozumění podnikovým datům, kapitoly 4 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Strategie orgů je rozhodnutí o krajině · Další: další kapitola, Kvalita dat a správa dat

Otázka, na kterou tento modul odpovídá: Co nám skutečná krajina řekne dřív, než cokoli navrhneme?

Tato kapitola kameru postupně oddalovala: Salesforce jako jeden systém z mnoha, druhy dat, systémy kolem Salesforce, jak nakreslit krajinu a strategie orgů. Teď to dáme dohromady na Steve Trucking. Zatím ale nebudeme nic opravovat. To je ta disciplína: nakreslete, co existuje, projděte každou šipku a podívejte se, co vám krajina říká.

Začněte tím, co víme

Steve Trucking provozuje jeden org Salesforce v USA. Service Cloud řeší případy od příjemců a maloobchodních partnerů; Field Service řídí schůzky, posádky a mobilní aplikaci; Experience Cloud dává maloobchodním partnerům portál, který se dnes používá jen pro reklamace a sestavy; Sales Cloud sleduje smlouvy s partnery a nabídky pro nová DC. Salesforce tedy jde doprostřed.

Vlevo lidé: 45 dispečerů, kteří pracují přímo v DC maloobchodních partnerů, asi 700 členů posádek na 330 kamionech, 60 agentů zákaznické péče, 40 lidí z provozu, financí a obchodu a asi 300 uživatelů u maloobchodních partnerů. To už nám něco říká: tohle není oddělové CRM. Je to provozní platforma pro většinu byznysu. Pořád je to ale jedna krabice. Teď se podívejme, co ji obklopuje.

Kliknutím zvětšíte

Steve Trucking dnes, před řádnou implementací. Každý manifest přistane v RouteDesk; dispečeři ručně přepisují trasy do Salesforce a dokončené zastávky zpět; FleetLinku chybí spojení.

Označte, co je špatně

Tohle je současný stav, před řádnou implementací, a říkám to přímo na kresbě. Pak otevřu paletu. V krajině hotového systému červenou nepoužívám; v současném stavu ano. Červená označuje špatný nebo nesprávný proces, přerušovaná čára něco, co se dělá ručně, a červené tečky chybějící spojení. I vynechaná šipka něco říká. Nic z toho není dekorace: každá červená čára je požadavek, který čeká, až ho někdo zapíše.

Tři partneři, tři integrace

Tři maloobchodní partneři posílají manifesty třemi různými způsoby, takže každého nakreslete zvlášť.

Keystone každé odpoledne odloží manifest CSV na server SFTP, pro doručení o dva dny později, a každou noc chce zpátky soubor se stavy. Dvě šipky: manifest dovnitř souborem, který otevírá Keystone, a stav ven souborem, který otevírá RouteDesk. Asynchronní, se širokým časovým oknem.

Redrock posílá manifesty přes REST API a očekává aktualizace stavu přes webhook ve chvíli, kdy se dějí. Dvě šipky, dva mechanismy: Redrock volá dovnitř s manifesty přes API a RouteDesk volá ven se stavem přes webhook. Téměř reálný čas.

Brightwave posílá soubory EDI přes síť třetí strany a očekává zpátky stavové zprávy EDI. Další formát, další mechanismus.

Stejné obchodní pojmy (manifest, doručení, stav), tři úplně odlišné integrace. Nezjednodušujte kresbu jen proto, že byste chtěli, aby byly konzistentní. Nejsou. To je současný stav.

Pak je projděte. Keystone: jak se ověřuje spojení SFTP, kam soubor přistane, co si ho vyzvedne, jak poznáme, že se zpracoval celý soubor, co se stane se špatným řádkem a jak se Keystone dozví o změně dřív než z dnešního nočního souboru? Redrock: jak se ověřuje API, co se stane, když jedna ze stran nejede, co se počítá jako úspěšný webhook, co když stejný stav dorazí dvakrát? Brightwave: kdo provozuje síť EDI, kde je překlad, jaká potvrzení se vracejí? Nic nepřenavrhujeme. Objevujeme otázky. To je úkol krajiny.

RouteDesk tu pořád je

RouteDesk je starý desktopový nástroj pro dispečink a plánování tras, kterým dispečeři v každém DC mění manifesty na trasy. Drží osm let historie doručení a má být vyřazen. Nakreslete ho přesto. Častou chybou je vynechat systém, „kterého se zbavujeme“. Kdy? Řekněme, že odpověď zní za osmnáct měsíců. Pak je součástí architektury nejméně osmnáct měsíců a jeho osm let historie, asi pět milionů doručení, nezmizí, když zmizí aplikace. A podívejte se, co krajina odhalí: RouteDesk a Salesforce nejsou propojené. Posádky pracují se svými zastávkami v aplikaci Field Service v Salesforce, ale trasy se stavějí v RouteDesk, takže je dispečeři každý večer přepisují do Salesforce a pak dokončené zastávky přepisují zpátky do RouteDesk, aby mohl posílat stav partnerům. Asi 3 300 zastávek denně, dvakrát, ručně. Na kresbě je to přerušované a červené. Také vám to říká, že Redrockův webhook „ve chvíli, kdy se dějí“ ve skutečnosti ve chvíli, kdy se dějí, není. Co dnes RouteDesk vlastní? Co na něm závisí? Jaká historie ho musí přežít a kde: v Salesforce, v datovém skladu, v archivu? Zatím neodpovídáme. Krajina jen odhalila otázky.

FleetLink je ostrov

FleetLink, telematická platforma, dostává GPS z každého kamionu: asi 200 000 údajů denně, každý kamion, každou minutu, kdy jede. A není připojená k ničemu. Dispečeři se na ni dívají na samostatné obrazovce. Nakreslete tedy FleetLink bez šipek. Žádnou kouzelnou integrační čáru jen proto, že si myslíme, že by tam měla být.

Pak spočítejte nuly: 200 000 denně je přes 70 milionů ročně. To není „máme data z GPS“. Je to streamovací zdroj se spoustou nul, který leží mimo zážitek v Salesforce. Potřebuje Salesforce 70 milionů údajů ročně? Nejspíš ne všechny. To je otázka návrhu na později.

Finance mají vlastní pravdu

Finanční ERP fakturuje každému maloobchodnímu partnerovi za každé doručení, instalaci a odvoz a vyplácí pobídky posádkám. A počty doručení se do něj dostávají přes měsíční tabulku. Nakreslete tu tabulku. Nenahrazujte ji úhlednou šipkou API jen proto, že jsme architekti a víme to líp; je součástí současné architektury. A jakmile je nakreslená, přicházejí otázky: kdo ji dělá, z jakého systému, kdo ji kontroluje, co když se doručení po odeslání změní a čí číslo vyhraje? Na odpovědích visí peníze.

Snowflake dostává týdenní export

Snowflake obsahuje provozní a finanční analytiku, plněnou týdenním exportem. Snowflake to sám nedokáže; dělá to něco uprostřed: plánovaná exportní úloha, která běží mimo Salesforce, bere data přes Bulk API a nahrává je do Snowflake. Kde žije analytika, se řídí tím, kde žijí data, a Snowflake už je analytickým domovem. Načasování nám ale také něco říká. „Co se stalo minulý měsíc?“ Týdenní zdroj stačí. „Kde je toto doručení právě teď?“ Snowflake není místo, kde bych začal. Stejný podnik, jiná zátěž, jiná čerstvost, jiná odpověď.

Identita nedosahuje ke všem stejně

Firemní poskytovatel identity jde nad Salesforce. Kancelářští zaměstnanci používají jednotné přihlášení. Dispečeři a posádky se ale přihlašují přihlašovacími údaji Salesforce. Jedna čára důvěry od IdP k Salesforce by tedy skryla půlku příběhu. Skutečná otázka zní, kteří uživatelé se přihlašují kterou cestou, a to do krajiny patří.

Zážitek příjemce má mezeru

Poskytovatel SMS a e-mailů posílá příjemcům z RouteDesk obecnou zprávu „vaše doručení je zítra“. Není v ní žádný odkaz na sledování. Mezitím je ročně asi 180 000 případů a asi 60 % z nich je „kde je moje doručení?“: zhruba 108 000 případů ročně se stejnou otázkou. Teď to dejte vedle FleetLink. Firma ví, kde jsou její kamiony. Její příjemci se pořád volají ptát. A systém, který to ví, není připojený k tomu, který odpovídá. Řešení zatím navrhovat nemusím. Krajina už ten příběh vypráví.

Dejte nuly do inventury

Teď spočítejte, co se přesouvá. Stejně jako v modulu 4 nuly nejdou na šipky; jdou do inventury za obrázkem, kde budou řídit mechanismy, až budeme navrhovat. Asi milion doručení ročně, asi 3 300 denně, s růstem 30 % ročně; asi 1,6 řádkové položky na každé; asi osm aktualizací stavu na každé, tedy dnes osm milionů aktualizací stavu ročně; čtyři až pět milionů fotek ročně, zatím na vlastních telefonech posádek; asi 200 000 údajů z GPS denně; asi 180 000 případů ročně. Šipka s popiskem „stav doručení“ není občasná zpráva. Krabice vám říkají, co existuje. Šipky vám říkají, co se přesouvá. Nuly vám říkají, jestli vaše předpoklady přežijí realitu.

Kliknutím zvětšíte

Inventura za krajinou Steve Trucking: objem vedle mechanismu, který bude řídit.

Zatím žádná cílová architektura, a už vidím, kde žijí důležitá data, o jaký druh jde, jak rychle se přesouvají a jak si je systémy vyměňují.

Nad rámec zkoušky: co mění AI. Předpokládejme, že Steve Trucking postaví agenta, který bude příjemcům odpovídat na „kde je moje doručení?“. Kterého systému se má ptát? Salesforce zná schůzku, FleetLink ví, kde je kamion, partnerův manifest doručení definoval. Současná krajina je mapou agenta, a než může agent bezpečně odpovídat, musí architekt vědět, který systém je pro každý fakt autoritativní a jak je aktuální. Nasměrujte agenta na špatný zdroj a ze zastaralých dat se stane sebevědomá odpověď.

Čtěte bolest, zatím ji neopravujte

Ustupte o krok. Tři partneři, tři styly integrace. Starý dispečerský nástroj s osmi lety historie a dispečeři, kteří denně přepisují 3 300 zastávek do Salesforce a zpátky. Telematická platforma s 200 000 údaji denně, odpojená. Finance, které počítají doručení z měsíční tabulky. Analytika týden pozadu. Jednotné přihlášení pro některé uživatele, pro jiné ne. Žádný odkaz na sledování a 108 000 případů ročně s otázkou, kde je doručení. A všechno roste o 30 % ročně.

To je spousta architektury z jednoho obrázku. Pokušení je začít to opravovat. Nedělejte to. Zatím ne. Chci, abyste se naučili nechat diagram současného stavu ošklivý, protože současný stav je někdy ošklivý. Nejde o to někoho ohromit čistou kresbou; jde o společné porozumění realitě. Přenavrhujte, zatímco dokumentujete, a přijdete o výchozí bod. Později chci umět říct: tohle existovalo, tohle je problém, který jsme vyřešili, tohle jsme změnili, a proč. Kapitola 6 začne dělat rozhodnutí o vlastnictví a identitě a Kontrolní bod 1 dá část 1 dohromady. Kurz Integration Architect navrhuje toky partnerů do hloubky.

Co tady rozhoduje architekt

V této fázi architekt nerozhoduje o cílové architektuře. Rozhoduje se o tom, zda je současnému stavu porozuměno dost dobře na to, aby se dala navrhnout:

• Které systémy, skupiny uživatelů, úložiště dat a externí partneři dnes skutečně existují.
• Jaká data překračují každou důležitou hranici, kterým směrem, jak často a jakým mechanismem.
• Kde teď žijí provozní, analytická, streamovací, historická a nestrukturovaná data.
• Které toky nesou největší objem a zaslouží si brzkou pozornost.
• Které mezery, ruční kroky, odpojené systémy, nejasné autority a nekonzistentní vzory se stanou výslovnými otázkami návrhu.

Tato kapitola začala jednou myšlenkou: nakreslete krajinu dřív, než navrhnete org. Kdybych začal datovým modelem Steve Trucking, mohl jsem strávit hodiny nad objekty a vztahy, zatímco FleetLink seděl venku s 200 000 údaji denně, RouteDesk držel osm let historie, tři partneři mluvili třemi jazyky, finance používaly tabulku a sto tisíc případů ročně se ptalo, kde je doručení. To nejsou otázky objektového modelu. Jsou to otázky podnikových dat. Nakreslete ošklivé integrace, tabulku, systém, který prý vyřazujete. Zapište si nuly. Projděte každou šipku. Pak jste připraveni to změnit.

K prozkoumání

• Zadání Steve Trucking, oddíly 2–4, a jeho diagram krajiny.