Cách Viết SRS Domain Logistics: Cẩm Nang “Sống Sót” Cho BA Mới

Bài viết được chia sẻ từ chuyên gia Business Analyst trong lĩnh vực Logistics

Viết SRS (System Requirement Specification) trong ngành Logistics không chỉ là liệt kê tính năng, mà là giải một bài toán vận hành cực kỳ hóc búa. Nếu bạn là BA mới và đang “ngộp” giữa hàng tá thuật ngữ như TMS, OMS hay Proof of Delivery, bài viết này dành cho bạn.

Khi SRS Logistics trở thành “ác mộng” của BA mới

Ai từng làm Business Analyst chắc đều biết: viết SRS (System Requirement Specification) không khác gì làm một… luận văn tốt nghiệp. Dài, chi tiết, và dễ bị “soi lỗi” từng dấu chấm dấu phẩy. Đặc biệt trong domain logistics, mọi thứ còn phức tạp hơn: shipment, tracking, warehouse, route optimization, proof of delivery… đủ thể loại thuật ngữ khiến BA mới đọc xong muốn bỏ nghề.

Mình nhớ lần đầu được giao viết SRS cho một dự án Order Management System + Transportation Management System (OMS + TMS). Cầm requirement từ khách hàng Mỹ, vừa lòe loẹt Excel vừa vài cái use case sơ sài, PM bảo:
“Em draft SRS đi, tuần sau khách review.”

Nếu mới vào nghề thì lúc đó mình sẽ nghĩ: Ơ, SRS là cái gì nhỉ? . Nhưng vào nghề cũng được vài năm thì hơi lo lắng, vì SRS cho domain này không hề dễ nhé.

Sau một tuần ăn hành, mình rút ra được cả đống bài học xương máu. Dưới đây mình sẽ chia sẻ thẳng thắn cho các bạn BA mới, để lần đầu viết SRS logistics không “toang” như mình.

Tại sao Domain Logistics lại “khó nhằn”?

Trước khi nói về SRS, phải hiểu tại sao logistics làm mọi thứ khó hơn.

• Tính real-time: Khác với hệ thống CRM hay HRM, logistics liên quan đến tracking từng phút. Shipment delay 30 phút có thể gây mất hợp đồng.
• Nhiều actor: Hệ thống phải phục vụ cùng lúc shipper, driver, warehouse, dispatcher, customer service, customer… Mỗi người 1 role, 1 flow.
• Quy trình chồng chéo: Từ khi tạo đơn → warehouse pick → route planning → driver pick up → delivering → proof of delivery. Nếu viết thiếu một bước là hỏng.
• Yêu cầu compliance: Vận tải xuyên quốc gia còn phải tuân theo quy định hải quan, thuế, chứng từ.

Nói cách khác: Logistics là domain “đầy bẫy”. Nếu BA không nắm rõ, viết SRS rất dễ sai hoặc hổng.

Cấu trúc chuẩn của một SRS Logistics

Một SRS chuẩn cho hệ thống logistics thường có 7 phần chính (tùy công ty, nhưng core thì giống nhau):

1. Introduction (Giới thiệu)

• Project overview
• Business objectives (giảm tỷ lệ trễ, tăng tracking real-time, optimize cost)
• Scope (OMS, TMS, mobile app cho driver, dashboard cho dispatcher)

2. Business Process Overview (AS-IS & TO-BE)

• Mô tả quy trình hiện tại và vấn đề.
• Quy trình đề xuất cải tiến.
• BPMN diagram.

3. Functional Requirements

• Use case detail.
• Flow per actor (shipper, driver, dispatcher).
• Các rule (SLA, cảnh báo delay, route auto-assign).

4. Non-functional Requirements

• Performance (update tracking ≤ 5s).
• Security (user role, data encryption).
• Scalability (support 10k shipment/day).

5. Data Requirements

• Entities: Shipment, Order, Driver, Vehicle, Warehouse.
• Field: tracking_number, ETA, POD (Proof of Delivery).
• ERD diagram.

6. Reporting & Dashboard

• KPI: SLA on-time %, average delivery time, delay reason breakdown.
• UI mockup.

7. Constraints & Assumptions

• Ví dụ: Mobile app cho driver chỉ chạy trên Android.
• GPS accuracy có thể ± 50m.

5 lỗi sai “kinh điển” khiến BA dễ ăn hành

Viết quá “chung chung”

Ví dụ:

• Sai: “System must allow driver to update status.”
• Đúng: “Driver must be able to update shipment status (Picked up, In-transit, Delivered, Failed Delivery) via mobile app, with timestamp auto-captured.”

Khách logistics cực kỳ dị ứng với kiểu requirement mơ hồ. Bạn phải viết cụ thể từng trạng thái, từng điều kiện.

Bỏ sót actor

BA mới thường chỉ nghĩ đến driver và customer, mà quên dispatcher và warehouse staff. Trong logistics, dispatcher chính là “linh hồn”. Bỏ sót vai trò này → flow sai hoàn toàn.

Thiếu use case exception

Ví dụ: Shipment bị “failed delivery” thì sao? Có cho re-delivery không? Có hoàn kho không? Nếu không ghi rõ, dev sẽ không code, QA không test, cuối cùng production bug.

Không link requirement với KPI

Khách logistics thường hỏi: “Nếu tôi đầu tư 1 triệu USD vào hệ thống này, KPI cải thiện thế nào?”
Nếu SRS không map requirement → business KPI (giảm delay %, giảm cost routing…), thì khách dễ reject.

Ngôn ngữ không nhất quán

Lúc thì viết “delivery”, lúc thì “shipment”, lúc thì “parcel”. Đọc 50 trang SRS mà thuật ngữ loạn xạ, khách Mỹ sẽ highlight đỏ hết.

Bí kíp viết SRS “vượt rào” mọi vòng review

Để bản SRS Logistics của bạn được khách hàng (đặc biệt là với khách hàng Mỹ) gật đầu, hãy áp dụng bộ quy tắc sau:

Bắt đầu từ business flow

Đừng nhảy vào viết use case ngay. Hãy vẽ AS-IS vs TO-BE:

• Shipment creation → Warehouse → Dispatcher assign → Driver pick up → Deliver → POD.

 Flow rõ thì requirement mới chuẩn.

Viết requirement theo chuẩn SMART

• Specific: rõ ràng, không mơ hồ.
• Measurable: có thể đo (ETA update ≤ 5s).
• Achievable: đừng viết viển vông.
• Relevant: liên quan KPI logistics.
• Time-bound: có điều kiện thời gian.

Ví dụ:
“System must auto-alert dispatcher if a shipment has no status update for > 2 hours.”

Đưa ví dụ thực tế

Khi mô tả use case, hãy thêm ví dụ:

“Shipment #123456 created at 9:00 AM. If driver does not update Picked up by 11:00 AM, system sends alert.

=> Cái này giúp dev & QA hiểu, khách Mỹ cũng gật gù.

Gắn mockup/flowchart

Khách logistics thích visual. Đừng để 50 trang chữ. Thêm flow diagram, Figma mockup dashboard. Ví dụ: tracking screen giống Uber → họ dễ hình dung.

Review chéo

• Gửi draft cho dev: để check khả năng implement.
• Gửi cho QA: để họ design test case.
• Gửi cho PM: để align timeline.

 Nếu bạn tự viết rồi gửi thẳng khách, nguy cơ “ăn hành” cực cao.

Case study: Khi SRS cứu team thoát bug production

Mình kể một kỷ niệm: dự án logistics ở Singapore, build tính năng auto-route assignment cho driver. Ban đầu dev code theo kiểu random assign. Sau khi đi live, hàng loạt shipment bị giao cho driver ở xa → delay.

Khách nổi giận, dọa cancel contract.
Nhờ có SRS (mình ghi rõ rule: “System must assign driver based on warehouse location + driver’s current route proximity”), team mới chứng minh dev làm sai spec. Kết quả: fix trong 1 tuần, khách dịu xuống.

Bài học: SRS là “bùa hộ mệnh” của BA. Không có SRS, bạn không có gì để bảo vệ mình trước khách hàng.

Tips thực tế cho BA mới

1. Đọc trước tài liệu logistics: học các term như SLA, POD, Last-mile, Reverse logistics.
2. Xem hệ thống có sẵn: FedEx, UPS, Uber Freight → lấy cảm hứng UI/flow.
3. Đặt nhiều câu hỏi “đời”: Nếu shipment trễ thì ai gọi cho khách? Nếu driver mất mạng 4G thì sao?
4. Dùng template SRS: IEEE 830 là chuẩn, nhưng hãy custom cho logistics.
5. Làm glossary: define hết thuật ngữ để không bị lẫn.

Thay vì chỉ mô tả các tính năng tĩnh, hãy đặt mình vào vị trí của người điều phối (Dispatcher) để lường trước các rủi ro dữ liệu. Hãy học cách xử lý vấn đề khi đơn hàng không cập nhật trạng thái để từ đó đưa ra các yêu cầu về cảnh báo (Alert) hoặc báo cáo sai lệch dữ liệu ngay trong bản SRS của mình.

Lời kết cho BA mới vào nghề

Viết SRS trong domain logistics giống như đi chợ mà phải liệt kê từng rau, từng củ, từng gram thịt. Nếu liệt kê thiếu, về nhà nấu ăn không thành món. Với BA mới, SRS là một thử thách đau đầu, nhưng khi làm được, bạn sẽ level up cực nhanh.

Hãy nhớ: logistics đòi hỏi sự chi tiết, chính xác, và thực tế. Nếu bạn học được cách viết SRS chuẩn trong logistics, thì đi sang bất kỳ domain nào cũng “nhẹ nhàng như gió”.