ภาพรวมระบบของ Steve Trucking

🌐 มีให้อ่านอีก 28 ภาษา

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)

ภาพสร้างด้วย AI

แปลโดย AI ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

โมดูลที่ 6 จาก 6 ในบท ทำความเข้าใจข้อมูลองค์กร บทที่ 4 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: กลยุทธ์ org คือการตัดสินใจระดับภาพรวมระบบ · ถัดไป: บทถัดไป คุณภาพและธรรมาภิบาลข้อมูล

คำถามที่โมดูลนี้ตอบ: ภาพรวมระบบจริงบอกอะไรเราก่อนที่เราจะออกแบบอะไรเลย?

บทนี้ถอยกล้องออกมาเรื่อยๆ: Salesforce ในฐานะหนึ่งในหลายระบบ ประเภทของข้อมูล ระบบรอบ Salesforce วิธีวาดภาพรวมระบบ และกลยุทธ์ org ตอนนี้มาประกอบทั้งหมดบน Steve Trucking แต่เราจะยังไม่แก้อะไร นั่นคือวินัย: วาดสิ่งที่มีอยู่ เดินตามทุกลูกศร และดูว่าภาพรวมระบบบอกอะไรเรา

เริ่มจากสิ่งที่เรารู้

Steve Trucking ใช้ org ของ Salesforce ตัวเดียว ในสหรัฐฯ Service Cloud จัดการเคสจากผู้รับและพันธมิตรค้าปลีก Field Service ดูแลนัดหมาย ทีมจัดส่ง และแอปมือถือ Experience Cloud ให้พอร์ทัลแก่พันธมิตรค้าปลีก ซึ่งวันนี้ใช้แค่สำหรับการเคลมและรายงาน Sales Cloud ติดตามสัญญาพันธมิตรและการเสนอราคาสำหรับ DC ใหม่ ดังนั้น Salesforce อยู่ตรงกลาง

ทางซ้ายคือคน: ผู้ประสานงานการจัดส่ง 45 คนที่ทำงานใน DC ของพันธมิตรค้าปลีก สมาชิกทีมจัดส่งราว 700 คนบนรถบรรทุก 330 คัน เจ้าหน้าที่ดูแลลูกค้า 60 คน พนักงานฝ่ายปฏิบัติการ การเงิน และการขาย 40 คน และผู้ใช้ของพันธมิตรค้าปลีกราว 300 คน นั่นบอกเราบางอย่างแล้ว: นี่ไม่ใช่ CRM ของแผนกเดียว มันคือแพลตฟอร์มเชิงปฏิบัติการสำหรับธุรกิจส่วนใหญ่ แต่มันยังเป็นกล่องเดียว ทีนี้มาดูว่าอะไรอยู่รอบมัน

Click to enlarge

Steve Trucking ในวันนี้ ก่อนการ implement อย่างเหมาะสม ใบรายการสินค้าทุกใบลงที่ RouteDesk ผู้ประสานงานคีย์เส้นทางซ้ำเข้า Salesforce และคีย์จุดแวะที่เสร็จแล้วกลับ ด้วยมือ FleetLink ขาดการเชื่อมต่อ

ทำเครื่องหมายสิ่งที่ผิด

นี่คือสถานะปัจจุบัน ก่อนการ implement อย่างเหมาะสม และผมเขียนบอกไว้บนภาพ แล้วผมก็เปิดจานสี บนภาพรวมระบบของระบบที่เสร็จแล้ว ผมไม่ใช้สีแดง บนสถานะปัจจุบันผมใช้ สีแดง ทำเครื่องหมายกระบวนการที่ไม่ดีหรือไม่เหมาะสม เส้นประ ทำเครื่องหมายสิ่งที่ทำด้วยมือ และจุดสีแดง ทำเครื่องหมายการเชื่อมต่อที่ขาดหายไป การไม่วาดลูกศรก็บอกอะไรบางอย่างเช่นกัน ไม่มีสิ่งใดเป็นของตกแต่ง: เส้นสีแดงทุกเส้นคือความต้องการที่รอการเขียนขึ้นมา

พันธมิตรสามราย การผสานรวมสามแบบ

พันธมิตรค้าปลีกสามรายส่งใบรายการสินค้าสามวิธีที่ต่างกัน ดังนั้นวาดแต่ละรายแยกกัน

Keystone วางใบรายการสินค้าแบบ CSV บนเซิร์ฟเวอร์ SFTP ทุกบ่าย สำหรับการจัดส่งสองวันถัดไป และต้องการไฟล์สถานะกลับทุกคืน ลูกศรสองเส้น: ใบรายการสินค้าเข้าทางไฟล์ เปิดโดย Keystone และสถานะออกทางไฟล์ เปิดโดย RouteDesk แบบ asynchronous มีช่วงเวลากว้าง

Redrock ส่งใบรายการสินค้าผ่าน REST API และคาดหวังการอัปเดตสถานะทาง webhook ทันทีที่เกิดขึ้น ลูกศรสองเส้น สองกลไก: Redrock เรียกเข้ามาพร้อมใบรายการสินค้าผ่าน API และ RouteDesk เรียกออกไปพร้อมสถานะผ่าน webhook แบบเกือบเรียลไทม์

Brightwave ส่งไฟล์ EDI ผ่านเครือข่ายของบุคคลที่สาม และคาดหวังข้อความสถานะ EDI กลับมา อีกรูปแบบหนึ่ง อีกกลไกหนึ่ง

แนวคิดทางธุรกิจเดียวกัน (ใบรายการสินค้า การจัดส่ง สถานะ) การผสานรวมสามแบบที่ต่างกันโดยสิ้นเชิง อย่าทำให้ภาพง่ายขึ้นเพราะคุณอยากให้มันสอดคล้องกัน มันไม่สอดคล้อง นั่นคือสถานะปัจจุบัน

แล้วเดินตามมัน Keystone: การเชื่อมต่อ SFTP ยืนยันตัวตนอย่างไร ไฟล์ไปลงที่ไหน อะไรหยิบมันไป เรารู้ได้อย่างไรว่าประมวลผลทั้งไฟล์แล้ว แถวที่เสียจะเป็นอย่างไร และ Keystone จะรู้เรื่องการเปลี่ยนแปลงก่อนไฟล์คืนนี้ได้อย่างไร? Redrock: API ยืนยันตัวตนอย่างไร จะเกิดอะไรขึ้นเมื่อฝั่งใดฝั่งหนึ่งล่ม อะไรนับเป็น webhook ที่สำเร็จ ถ้าสถานะเดียวกันมาถึงสองครั้งล่ะ? Brightwave: ใครดูแลเครือข่าย EDI การแปลงอยู่ที่ไหน การตอบรับอะไรส่งกลับมา? เราไม่ได้ออกแบบอะไรใหม่ เรากำลังค้นพบคำถาม นั่นคืองานของภาพรวมระบบ

RouteDesk ยังอยู่

RouteDesk คือเครื่องมือจัดส่งและวางเส้นทางแบบเดสก์ท็อปรุ่นเก่าที่ผู้ประสานงานใช้ในแต่ละ DC เพื่อเปลี่ยนใบรายการสินค้าเป็นเส้นทาง มันเก็บประวัติการจัดส่งแปดปี และมีกำหนดจะเลิกใช้ วาดมันอยู่ดี ความผิดพลาดที่พบบ่อยคือการไม่วาดระบบที่ “เรากำลังจะทิ้ง” เมื่อไร? สมมติว่าคำตอบคือสิบแปดเดือน งั้นมันก็เป็นส่วนหนึ่งของสถาปัตยกรรมอย่างน้อยสิบแปดเดือน และประวัติแปดปีของมัน ราวห้าล้านการจัดส่ง ไม่ได้หายไปเมื่อแอปพลิเคชันหายไป และดูสิ่งที่ภาพรวมระบบเปิดเผย: RouteDesk กับ Salesforce ไม่ได้เชื่อมต่อกัน ทีมจัดส่งทำงานตามจุดแวะในแอป Field Service ของ Salesforce แต่เส้นทางถูกสร้างใน RouteDesk ผู้ประสานงานจึงคีย์มันซ้ำเข้า Salesforce ทุกเย็น แล้วคีย์จุดแวะที่เสร็จแล้วกลับเข้า RouteDesk เพื่อให้มันส่งสถานะไปยังพันธมิตรได้ ราว 3,300 จุดแวะต่อวัน สองรอบ ด้วยมือ นั่นคือเส้นประสีแดงบนภาพ มันยังบอกคุณด้วยว่า webhook แบบ “ทันทีที่เกิดขึ้น” ของ Redrock ไม่ได้ทันทีที่เกิดขึ้นจริงๆ วันนี้ RouteDesk เป็นเจ้าของอะไร? อะไรพึ่งพามัน? ประวัติใดต้องอยู่รอดหลังมัน และอยู่ที่ไหน: Salesforce คลังข้อมูล หรือที่เก็บถาวร? เรายังไม่ตอบ ภาพรวมระบบแค่เปิดเผยคำถาม

FleetLink เป็นเกาะ

FleetLink แพลตฟอร์มเทเลเมติกส์ ได้รับ GPS จากรถบรรทุกทุกคัน: ราว 200,000 ค่าต่อวัน ทุกคัน ทุกนาทีที่วิ่ง และมันไม่ได้เชื่อมกับอะไรเลย ผู้ประสานงานดูมันบนหน้าจอแยก ดังนั้นวาด FleetLink โดยไม่มีลูกศร ไม่มีเส้นผสานรวมวิเศษเพราะเราคิดว่าควรมี

แล้วนับเลขศูนย์: 200,000 ต่อวันคือมากกว่า 70 ล้านต่อปี นั่นไม่ใช่ “เรามีข้อมูล GPS” มันคือแหล่งสตรีมมิงที่มีเลขศูนย์เยอะ อยู่นอกประสบการณ์ Salesforce Salesforce ต้องการ 70 ล้านค่าต่อปีไหม? น่าจะไม่ทั้งหมด นั่นคือคำถามการออกแบบไว้ทีหลัง

ฝ่ายการเงินมีความจริงของตัวเอง

ERP ฝ่ายการเงินออกใบแจ้งหนี้ให้พันธมิตรค้าปลีกแต่ละรายตามการจัดส่ง การติดตั้ง และการขนของเก่าออก และจ่ายค่าตอบแทนจูงใจให้ทีมจัดส่ง และจำนวนการจัดส่งไปถึงมันผ่านสเปรดชีตรายเดือน วาดสเปรดชีตนั้น อย่าแทนมันด้วยลูกศร API เรียบร้อยเพราะเราเป็นสถาปนิกและรู้ดีกว่า มันเป็นส่วนหนึ่งของสถาปัตยกรรมปัจจุบัน และเมื่อวาดแล้ว คำถามก็มา: ใครทำมัน จากระบบไหน ใครตรวจ ถ้าการจัดส่งเปลี่ยนหลังส่งไปแล้วล่ะ และตัวเลขของใครชนะ? เงินผูกอยู่กับคำตอบ

Snowflake ได้รับการส่งออกรายสัปดาห์

Snowflake เก็บข้อมูลเชิงวิเคราะห์ด้านปฏิบัติการและการเงิน ป้อนด้วยการส่งออกรายสัปดาห์ Snowflake ทำเองไม่ได้ มีบางอย่างตรงกลางที่ทำ: งานส่งออกตามกำหนดเวลาที่รันอยู่นอก Salesforce ซึ่งดึงข้อมูลผ่าน Bulk API แล้วโหลดเข้า Snowflake การวิเคราะห์อยู่ที่ไหนขึ้นกับว่าข้อมูลอยู่ที่ไหน และ Snowflake คือบ้านเชิงวิเคราะห์อยู่แล้ว แต่จังหวะเวลาก็บอกบางอย่างเช่นกัน “เดือนที่แล้วเกิดอะไรขึ้น?” ฟีดรายสัปดาห์ก็พอ “การจัดส่งนี้อยู่ที่ไหนตอนนี้?” Snowflake ไม่ใช่ที่ที่ผมจะเริ่ม องค์กรเดียวกัน ภาระงานต่างกัน ความใหม่ต่างกัน คำตอบต่างกัน

ตัวตนไม่ได้ไปถึงทุกคนด้วยวิธีเดียวกัน

ผู้ให้บริการตัวตนขององค์กรอยู่เหนือ Salesforce พนักงานสำนักงานใช้ single sign-on แต่ผู้ประสานงานและทีมจัดส่งล็อกอินด้วยข้อมูลรับรองของ Salesforce ดังนั้นเส้นความไว้วางใจเส้นเดียวจาก IdP ไป Salesforce จะซ่อนเรื่องไปครึ่งหนึ่ง คำถามจริงคือผู้ใช้กลุ่มไหนล็อกอินผ่านเส้นทางไหน และนั่นควรอยู่บนภาพรวมระบบ

ประสบการณ์ของผู้รับมีช่องโหว่

ผู้ให้บริการ SMS และอีเมลส่งข้อความทั่วไป “การจัดส่งของคุณคือพรุ่งนี้” ให้ผู้รับจาก RouteDesk ไม่มีลิงก์ติดตาม ในขณะเดียวกันมีเคสราว 180,000 เคสต่อปี และราว 60% เป็น “การจัดส่งของฉันอยู่ไหน?”: ประมาณ 108,000 เคสต่อปีที่ถามคำถามเดียวกัน ทีนี้วางสิ่งนั้นข้าง FleetLink บริษัทรู้ว่ารถบรรทุกของตนอยู่ที่ไหน ผู้รับของบริษัทก็โทรมาถามเรื่อยๆ และระบบที่รู้ไม่ได้เชื่อมกับระบบที่ตอบ ผมยังไม่ต้องออกแบบโซลูชัน ภาพรวมระบบกำลังเล่าเรื่องอยู่แล้ว

ใส่เลขศูนย์ลงในบัญชีรายการ

ทีนี้นับสิ่งที่เคลื่อนย้าย เหมือนในโมดูลที่ 4 เลขศูนย์ไม่ได้อยู่บนลูกศร มันอยู่ในบัญชีรายการเบื้องหลังภาพ ที่ซึ่งมันจะเป็นตัวกำหนดกลไกเมื่อเราออกแบบ การจัดส่งราวหนึ่งล้านครั้งต่อปี ราว 3,300 ครั้งต่อวัน เติบโต 30% ต่อปี ราว 1.6 รายการต่อการจัดส่ง การอัปเดตสถานะราวแปดครั้งต่อการจัดส่ง จึงเป็นการอัปเดตสถานะแปดล้านครั้งต่อปีในวันนี้ รูปถ่ายสี่ถึงห้าล้านรูปต่อปี ซึ่งตอนนี้อยู่บนโทรศัพท์ส่วนตัวของทีมจัดส่ง ค่า GPS ราว 200,000 ค่าต่อวัน เคสราว 180,000 เคสต่อปี ลูกศรที่ติดป้าย “สถานะการจัดส่ง” ไม่ใช่ข้อความที่มาเป็นครั้งคราว กล่องบอกคุณว่ามีอะไรอยู่ ลูกศรบอกคุณว่าอะไรเคลื่อนย้าย เลขศูนย์บอกคุณว่าสมมติฐานของคุณรอดพ้นความเป็นจริงหรือไม่

Click to enlarge

บัญชีรายการเบื้องหลังภาพรวมระบบของ Steve Trucking: ปริมาณเคียงข้างกลไกที่มันจะเป็นตัวกำหนด

ยังไม่มีสถาปัตยกรรมเป้าหมาย และผมเห็นได้แล้วว่าข้อมูลสำคัญอยู่ที่ไหน เป็นประเภทไหน เคลื่อนที่เร็วแค่ไหน และระบบแลกเปลี่ยนมันอย่างไร

นอกเหนือจากการสอบ: AI เปลี่ยนอะไร สมมติว่า Steve Trucking สร้างเอเจนต์เพื่อตอบ “การจัดส่งของฉันอยู่ไหน?” ของผู้รับ มันควรถามระบบไหน? Salesforce รู้นัดหมาย FleetLink รู้ว่ารถอยู่ไหน ใบรายการสินค้าของพันธมิตรกำหนดการจัดส่ง ภาพรวมระบบปัจจุบันคือแผนที่ของเอเจนต์ และก่อนที่เอเจนต์จะตอบได้อย่างปลอดภัย สถาปนิกต้องรู้ว่าระบบใดมีอำนาจชี้ขาดสำหรับข้อเท็จจริงแต่ละข้อ และข้อมูลใหม่แค่ไหน ชี้เอเจนต์ไปที่แหล่งผิด แล้วข้อมูลเก่าจะกลายเป็นคำตอบที่มั่นใจ

อ่านความเจ็บปวด อย่าเพิ่งแก้

ถอยออกมา พันธมิตรสามราย การผสานรวมสามรูปแบบ เครื่องมือจัดส่งรุ่นเก่าที่เก็บประวัติแปดปี และผู้ประสานงานที่คีย์ 3,300 จุดแวะต่อวันซ้ำเข้า Salesforce แล้วกลับออกมา แพลตฟอร์มเทเลเมติกส์ที่มี 200,000 ค่าต่อวัน ไม่ได้เชื่อมต่อ ฝ่ายการเงินนับการจัดส่งจากสเปรดชีตรายเดือน การวิเคราะห์ช้าไปหนึ่งสัปดาห์ single sign-on สำหรับผู้ใช้บางกลุ่ม ไม่ใช่ทุกกลุ่ม ไม่มีลิงก์ติดตาม และ 108,000 เคสต่อปีที่ถามว่าการจัดส่งอยู่ไหน ทั้งหมดเติบโต 30% ต่อปี

นั่นคือสถาปัตยกรรมจำนวนมากจากภาพเดียว สิ่งยั่วยุคือการเริ่มแก้ อย่าทำ ยังไม่ใช่ตอนนี้ ผมอยากให้คุณสบายใจที่จะปล่อยไดอะแกรมสถานะปัจจุบันให้ดูน่าเกลียด เพราะบางครั้งสถานะปัจจุบันก็น่าเกลียด ประเด็นไม่ใช่การทำให้ใครประทับใจด้วยภาพที่สะอาด มันคือความเข้าใจร่วมกันเกี่ยวกับความจริง ออกแบบใหม่ระหว่างที่บันทึก แล้วคุณจะเสียเส้นฐาน ทีหลังผมอยากพูดได้ว่า: นี่คือสิ่งที่มีอยู่ นี่คือปัญหาที่เราแก้ นี่คือสิ่งที่เราเปลี่ยน และทำไม บทที่ 6 เริ่มตัดสินใจเรื่องความเป็นเจ้าของและตัวตน และจุดตรวจสอบที่ 1 ประกอบส่วนที่ 1 เข้าด้วยกัน หลักสูตร Integration Architect ออกแบบโฟลว์ของพันธมิตรอย่างลงลึก

สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้

ในขั้นนี้สถาปนิกยังไม่ได้ตัดสินสถาปัตยกรรมเป้าหมาย การตัดสินใจคือสถานะปัจจุบันเข้าใจดีพอที่จะออกแบบหรือยัง:

• ระบบ กลุ่มผู้ใช้ ที่เก็บข้อมูล และพันธมิตรภายนอกใดบ้างที่มีอยู่จริงวันนี้
• ข้อมูลใดข้ามขอบเขตสำคัญแต่ละแห่ง ไปทางไหน บ่อยแค่ไหน และด้วยกลไกใด
• ข้อมูลเชิงปฏิบัติการ เชิงวิเคราะห์ สตรีมมิง ประวัติ และไม่มีโครงสร้างอยู่ที่ไหนตอนนี้
• โฟลว์ใดมีปริมาณมากที่สุดและควรได้รับความสนใจก่อน
• ช่องโหว่ ขั้นตอนที่ทำด้วยมือ ระบบที่ไม่เชื่อมต่อ อำนาจชี้ขาดที่ไม่ชัด และรูปแบบที่ไม่สอดคล้องใดที่กลายเป็นคำถามการออกแบบที่ชัดเจน

บทนี้เริ่มด้วยความคิดเดียว: วาดภาพรวมระบบก่อนออกแบบ org ถ้าผมเริ่มจากโมเดลข้อมูลของ Steve Trucking ผมอาจใช้เวลาหลายชั่วโมงกับออบเจกต์และความสัมพันธ์ ขณะที่ FleetLink อยู่ข้างนอกพร้อม 200,000 ค่าต่อวัน RouteDesk เก็บประวัติแปดปี พันธมิตรสามรายพูดสามภาษา ฝ่ายการเงินใช้สเปรดชีต และหนึ่งแสนเคสต่อปีถามว่าการจัดส่งอยู่ไหน นั่นไม่ใช่คำถามเรื่องโมเดลออบเจกต์ มันคือคำถามเรื่องข้อมูลองค์กร วาดการผสานรวมที่น่าเกลียด สเปรดชีต ระบบที่คุณบอกว่ากำลังจะเลิกใช้ จดเลขศูนย์ เดินตามทุกลูกศร แล้วคุณก็พร้อมจะเปลี่ยนมัน

ศึกษาเพิ่มเติม

• บรีฟ ของ Steve Trucking ส่วนที่ 2–4 และไดอะแกรมภาพรวมระบบ