Bản đồ hệ thống của Steve Trucking

🌐 Cũng có bằng 28 ngôn ngữ khác

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

Hình ảnh được tạo bằng AI

Được dịch bằng AI. Cộng đồng chưa xem xét. Đọc bằng tiếng Anh

Mô-đun 6 trong 6 của chương Hiểu dữ liệu doanh nghiệp, chương 4 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Chiến lược org là một quyết định bản đồ · Tiếp theo: chương sau, Chất lượng và quản trị dữ liệu

Câu hỏi mô-đun này trả lời: Một bản đồ hệ thống thực tế cho chúng ta biết gì trước khi thiết kế bất cứ thứ gì?

Chương này đã kéo máy quay lùi lại: Salesforce là một hệ thống giữa nhiều hệ thống, các loại dữ liệu, các hệ thống quanh Salesforce, cách vẽ bản đồ hệ thống, và chiến lược org. Giờ hãy ghép chúng lại trên Steve Trucking. Nhưng chúng ta chưa sửa gì cả. Đó là kỷ luật: vẽ những gì đang có, đi qua từng mũi tên, và xem bản đồ hệ thống cho chúng ta biết gì.

Bắt đầu từ những gì chúng ta biết

Steve Trucking chạy một org Salesforce, tại Mỹ. Service Cloud xử lý các trường hợp từ Người nhận và Đối tác bán lẻ; Field Service vận hành lịch hẹn, tổ giao hàng và ứng dụng di động; Experience Cloud cho các Đối tác bán lẻ một cổng thông tin, hiện chỉ dùng cho khiếu nại và báo cáo; Sales Cloud theo dõi hợp đồng đối tác và hồ sơ dự thầu cho các DC mới. Vậy Salesforce đặt ở giữa.

Bên trái là con người: 45 điều phối viên làm việc bên trong các DC của Đối tác bán lẻ, khoảng 700 thành viên tổ giao hàng trên 330 xe tải, 60 nhân viên chăm sóc khách hàng, 40 nhân viên vận hành, tài chính và kinh doanh, và khoảng 300 người dùng của Đối tác bán lẻ. Điều đó đã cho chúng ta biết một điều: đây không phải là một CRM của một phòng ban. Đó là một nền tảng vận hành cho phần lớn doanh nghiệp. Nhưng nó vẫn là một hộp. Giờ hãy xem cái gì bao quanh nó.

Click to enlarge

Steve Trucking hôm nay, trước một đợt triển khai bài bản. Mọi bảng kê hàng đều rơi vào RouteDesk; điều phối viên nhập lại tuyến vào Salesforce và nhập các điểm dừng đã hoàn tất ngược về, bằng tay; FleetLink thiếu kết nối.

Đánh dấu những gì sai

Đây là hiện trạng, trước một đợt triển khai bài bản, và tôi ghi rõ điều đó trên bản vẽ. Rồi tôi mở rộng bảng màu. Trên bản đồ hệ thống của một hệ thống đã hoàn thiện, tôi không dùng màu đỏ; trên hiện trạng thì tôi dùng. Màu đỏ đánh dấu một quy trình tồi hoặc không đúng cách, nét đứt đánh dấu việc làm bằng tay, và chấm đỏ đánh dấu một kết nối còn thiếu. Bỏ một mũi tên ra cũng nói lên điều gì đó. Không thứ nào trong đó là trang trí: mỗi đường đỏ là một yêu cầu đang chờ được viết ra.

Ba đối tác, ba tích hợp

Ba Đối tác bán lẻ gửi bảng kê hàng theo ba cách khác nhau, nên hãy vẽ từng cái riêng biệt.

Keystone thả một bảng kê hàng dạng CSV lên một máy chủ SFTP mỗi buổi chiều, cho việc giao hàng hai ngày sau, và muốn nhận lại một tệp trạng thái mỗi đêm. Hai mũi tên: bảng kê hàng vào bằng tệp, do Keystone mở kết nối, và trạng thái ra bằng tệp, do RouteDesk mở kết nối. Bất đồng bộ, với khung thời gian rộng.

Redrock gửi bảng kê hàng qua một REST API và chờ cập nhật trạng thái qua webhook ngay khi chúng xảy ra. Hai mũi tên, hai cơ chế: Redrock gọi vào với bảng kê hàng qua API, và RouteDesk gọi ra với trạng thái qua webhook. Gần thời gian thực.

Brightwave gửi tệp EDI qua một mạng của bên thứ ba và chờ nhận lại các thông điệp trạng thái EDI. Thêm một định dạng, thêm một cơ chế.

Cùng các khái niệm nghiệp vụ (bảng kê hàng, giao hàng, trạng thái), ba tích hợp hoàn toàn khác nhau. Đừng đơn giản hóa bản vẽ chỉ vì bạn muốn chúng nhất quán. Chúng không nhất quán. Đó là hiện trạng.

Rồi đi qua chúng. Keystone: kết nối SFTP xác thực thế nào, tệp đáp xuống đâu, cái gì nhận nó, làm sao biết cả tệp đã được xử lý, chuyện gì xảy ra với một dòng lỗi, và Keystone nghe về một thay đổi trước tệp tối nay bằng cách nào? Redrock: API xác thực thế nào, chuyện gì xảy ra khi một trong hai bên ngừng hoạt động, thế nào là một webhook thành công, nếu cùng một trạng thái đến hai lần thì sao? Brightwave: ai vận hành mạng EDI, việc chuyển đổi nằm ở đâu, những xác nhận nào quay về? Chúng ta không thiết kế lại gì cả. Chúng ta đang khám phá các câu hỏi. Đó là việc của bản đồ hệ thống.

RouteDesk vẫn còn đó

RouteDesk là công cụ điều phối và lập tuyến cũ trên máy tính để bàn mà các điều phối viên dùng ở mỗi DC để biến bảng kê hàng thành tuyến. Nó giữ tám năm lịch sử giao hàng, và đã được lên lịch ngừng sử dụng. Dù vậy cứ vẽ nó. Một sai lầm phổ biến là bỏ qua hệ thống “chúng tôi sắp loại bỏ”. Khi nào? Giả sử câu trả lời là mười tám tháng. Vậy thì nó là một phần của kiến trúc trong ít nhất mười tám tháng, và tám năm lịch sử của nó, khoảng năm triệu lần giao hàng, không biến mất khi ứng dụng biến mất. Và hãy nhìn những gì bản đồ hệ thống phơi bày: RouteDesk và Salesforce không được kết nối. Các tổ giao hàng làm việc với các điểm dừng của họ trong ứng dụng Field Service của Salesforce, nhưng tuyến được lập trong RouteDesk, nên điều phối viên nhập lại chúng vào Salesforce mỗi tối, rồi nhập lại các điểm dừng đã hoàn tất ngược về RouteDesk để nó có thể gửi trạng thái cho các đối tác. Khoảng 3.300 điểm dừng mỗi ngày, hai lần, bằng tay. Trên bản vẽ, đó là nét đứt và màu đỏ. Nó cũng cho bạn biết webhook “ngay khi chúng xảy ra” của Redrock thực ra không hẳn là ngay khi chúng xảy ra. Hôm nay RouteDesk sở hữu gì? Cái gì phụ thuộc vào nó? Lịch sử nào phải tồn tại sau nó, và ở đâu: Salesforce, kho dữ liệu, một kho lưu trữ? Chúng ta chưa trả lời. Bản đồ hệ thống chỉ vừa phơi bày các câu hỏi.

FleetLink là một hòn đảo

FleetLink, nền tảng định vị xe, nhận GPS từ mọi xe tải: khoảng 200.000 lần đọc mỗi ngày, mọi xe, mọi phút xe chạy. Và nó không nối với thứ gì cả. Các điều phối viên xem nó trên một màn hình riêng. Vì vậy hãy vẽ FleetLink không có mũi tên nào. Không có đường tích hợp thần kỳ nào chỉ vì chúng ta nghĩ lẽ ra phải có.

Rồi đếm các chữ số 0: 200.000 mỗi ngày là hơn 70 triệu mỗi năm. Đó không phải là “chúng tôi có dữ liệu GPS”. Đó là một nguồn dữ liệu luồng với rất nhiều chữ số 0, nằm ngoài trải nghiệm Salesforce. Salesforce có cần 70 triệu lần đọc mỗi năm không? Có lẽ không phải tất cả. Đó là một câu hỏi thiết kế cho sau này.

Tài chính có sự thật riêng

ERP tài chính lập hóa đơn cho từng Đối tác bán lẻ theo mỗi lần giao hàng, lắp đặt và chở đồ cũ đi, và trả tiền thưởng cho tổ giao hàng. Và số lần giao hàng đến với nó qua một bảng tính hằng tháng. Hãy vẽ bảng tính đó. Đừng thay nó bằng một mũi tên API gọn gàng chỉ vì chúng ta là kiến trúc sư và biết rõ hơn; nó là một phần của kiến trúc hiện tại. Và khi đã vẽ, các câu hỏi xuất hiện: ai tạo ra nó, từ hệ thống nào, ai kiểm tra nó, nếu một lần giao hàng thay đổi sau khi gửi thì sao, và con số của ai thắng? Tiền gắn liền với các câu trả lời.

Snowflake nhận một bản xuất hằng tuần

Snowflake giữ dữ liệu phân tích vận hành và tài chính, được cấp bằng một bản xuất hằng tuần. Snowflake không tự làm được việc đó; có một thứ ở giữa làm: một tác vụ xuất dữ liệu theo lịch, chạy bên ngoài Salesforce, kéo dữ liệu qua Bulk API và nạp vào Snowflake. Phân tích nằm ở đâu đi theo dữ liệu nằm ở đâu, và Snowflake đã là ngôi nhà phân tích. Nhưng thời điểm cũng cho chúng ta biết điều gì đó. “Tháng trước đã xảy ra chuyện gì?” Một nguồn cấp hằng tuần là ổn. “Lần giao hàng này ngay bây giờ đang ở đâu?” Snowflake không phải là nơi tôi bắt đầu. Cùng một doanh nghiệp, khối lượng công việc khác, độ mới khác, câu trả lời khác.

Danh tính không đến với mọi người theo cùng một cách

Nhà cung cấp danh tính của công ty đặt phía trên Salesforce. Nhân viên văn phòng dùng đăng nhập một lần. Nhưng điều phối viên và tổ giao hàng đăng nhập bằng thông tin đăng nhập Salesforce. Vì vậy một đường tin cậy duy nhất từ IdP đến Salesforce sẽ giấu đi một nửa câu chuyện. Câu hỏi thực sự là người dùng nào đăng nhập qua con đường nào, và điều đó thuộc về bản đồ hệ thống.

Trải nghiệm của Người nhận có một khoảng trống

Nhà cung cấp SMS và email gửi cho Người nhận một thông điệp chung chung “hàng của bạn sẽ giao vào ngày mai” từ RouteDesk. Không có đường dẫn theo dõi. Trong khi đó có khoảng 180.000 trường hợp mỗi năm, và khoảng 60% trong số đó là “hàng của tôi đâu rồi?”: khoảng 108.000 trường hợp mỗi năm hỏi cùng một câu. Giờ hãy đặt điều đó cạnh FleetLink. Công ty biết xe tải của mình ở đâu. Người nhận của họ cứ gọi đến để hỏi. Và hệ thống biết câu trả lời không nối với hệ thống đang trả lời. Tôi chưa cần thiết kế giải pháp. Bản đồ hệ thống đã đang kể câu chuyện.

Đưa các chữ số 0 vào bảng kiểm kê

Giờ hãy đếm những gì di chuyển. Như ở mô-đun 4, các chữ số 0 không đặt lên mũi tên; chúng đi vào bảng kiểm kê phía sau bức tranh, nơi chúng sẽ quyết định các cơ chế khi chúng ta thiết kế. Khoảng một triệu lần giao hàng mỗi năm, khoảng 3.300 mỗi ngày, tăng 30% mỗi năm; trung bình khoảng 1,6 mặt hàng mỗi lần; khoảng tám cập nhật trạng thái mỗi lần, tức tám triệu cập nhật trạng thái mỗi năm hiện nay; bốn đến năm triệu ảnh mỗi năm, hiện nằm trên điện thoại riêng của các tổ giao hàng; khoảng 200.000 lần đọc GPS mỗi ngày; khoảng 180.000 trường hợp mỗi năm. Một mũi tên ghi nhãn “trạng thái giao hàng” không phải là một thông điệp thỉnh thoảng mới có. Các chiếc hộp cho bạn biết cái gì tồn tại. Các mũi tên cho bạn biết cái gì di chuyển. Các chữ số 0 cho bạn biết giả định của bạn có sống sót trước thực tế hay không.

Click to enlarge

Bảng kiểm kê phía sau bản đồ hệ thống của Steve Trucking: khối lượng bên cạnh cơ chế mà nó sẽ quyết định.

Chưa có kiến trúc mục tiêu, và tôi đã thấy được dữ liệu quan trọng nằm ở đâu, nó thuộc loại gì, nó di chuyển nhanh đến đâu và các hệ thống trao đổi nó thế nào.

Ngoài kỳ thi: AI thay đổi điều gì. Giả sử Steve Trucking xây một tác tử để trả lời câu “hàng của tôi đâu rồi?” của Người nhận. Nó nên hỏi hệ thống nào? Salesforce biết lịch hẹn, FleetLink biết xe tải đang ở đâu, bảng kê hàng của đối tác định nghĩa lần giao hàng. Bản đồ hệ thống hiện tại là bản đồ của tác tử, và trước khi tác tử có thể trả lời an toàn, kiến trúc sư phải biết hệ thống nào có thẩm quyền cho từng sự thật và nó cập nhật đến đâu. Trỏ một tác tử vào sai nguồn và dữ liệu cũ sẽ trở thành một câu trả lời đầy tự tin.

Đọc nỗi đau, chưa sửa vội

Hãy lùi lại. Ba đối tác, ba kiểu tích hợp. Một công cụ điều phối cũ giữ tám năm lịch sử, và các điều phối viên nhập lại 3.300 điểm dừng mỗi ngày vào Salesforce rồi ngược về. Một nền tảng định vị xe với 200.000 lần đọc mỗi ngày, không được kết nối. Tài chính đếm số lần giao từ một bảng tính hằng tháng. Phân tích chậm một tuần. Đăng nhập một lần cho một số người dùng, không cho những người khác. Không có đường dẫn theo dõi, và 108.000 trường hợp mỗi năm hỏi lần giao hàng đang ở đâu. Tất cả đều tăng 30% mỗi năm.

Đó là rất nhiều kiến trúc từ một bức tranh. Cám dỗ là bắt đầu sửa nó. Đừng. Chưa phải lúc. Tôi muốn bạn thoải mái để một sơ đồ hiện trạng xấu xí, vì đôi khi hiện trạng xấu xí thật. Mục đích không phải là gây ấn tượng với ai đó bằng một bản vẽ gọn gàng; mà là một sự hiểu biết chung về thực tế. Thiết kế lại trong lúc ghi chép và bạn mất đường cơ sở. Sau này tôi muốn nói được: đây là những gì đã tồn tại, đây là vấn đề chúng ta đã giải quyết, đây là những gì chúng ta đã thay đổi, và vì sao. Chương 6 bắt đầu đưa ra các quyết định về quyền sở hữu và danh tính, và Điểm kiểm tra 1 ghép Phần 1 lại với nhau. Khóa Integration Architect thiết kế các luồng đối tác một cách chuyên sâu.

Kiến trúc sư quyết định gì ở đây

Ở giai đoạn này, kiến trúc sư chưa quyết định kiến trúc mục tiêu. Quyết định là hiện trạng đã được hiểu đủ rõ để thiết kế một kiến trúc mục tiêu chưa:

• Những hệ thống, nhóm người dùng, kho dữ liệu và đối tác bên ngoài nào thực sự tồn tại hôm nay.
• Dữ liệu nào vượt qua từng ranh giới quan trọng, theo hướng nào, thường xuyên đến đâu và bằng cơ chế nào.
• Dữ liệu vận hành, phân tích, luồng, lịch sử và phi cấu trúc hiện đang nằm ở đâu.
• Những luồng nào mang khối lượng lớn nhất và đáng được quan tâm sớm.
• Những khoảng trống, bước thủ công, hệ thống rời rạc, thẩm quyền không rõ ràng và khuôn mẫu không nhất quán nào trở thành câu hỏi thiết kế rõ ràng.

Chương này bắt đầu với một ý tưởng: vẽ bản đồ hệ thống trước khi thiết kế org. Nếu tôi bắt đầu với mô hình dữ liệu của Steve Trucking, tôi có thể đã dành hàng giờ cho đối tượng và quan hệ trong khi FleetLink nằm bên ngoài với 200.000 lần đọc mỗi ngày, RouteDesk giữ tám năm lịch sử, ba đối tác nói ba thứ tiếng, tài chính dùng một bảng tính, và một trăm nghìn trường hợp mỗi năm hỏi một lần giao hàng đang ở đâu. Đó không phải là những câu hỏi về mô hình đối tượng. Đó là những câu hỏi về dữ liệu doanh nghiệp. Hãy vẽ những tích hợp xấu xí, bảng tính, hệ thống mà bạn được cho là sắp loại bỏ. Viết ra các chữ số 0. Đi qua từng mũi tên. Rồi bạn mới sẵn sàng thay đổi nó.

Tìm hiểu thêm

• Bản mô tả Steve Trucking, mục 2–4, và sơ đồ bản đồ hệ thống của nó.