• 

  Các loại diagram “thần thánh” khi viết BRD (P3 – SM)

  Bài trước chúng ta đã bàn về BPM và SCD. Và bây giờ là diagram cuối cùng trong chuỗi bài.

  Scope model – SM

  Nếu SCD và BPM là 2 loại sơ đồ ở “tầng cao”. Cho bạn 1 cái nhìn overview thì Scope model – hay Sơ đồ phạm vi sẽ giúp bạn bước 1 chân vào phân tích làm sao để đạt được các mục tiêu đó.

  BRD (Business Reaquirement Document) là loại tài liệu chứa những yêu cầu về kinh doanh – thế giới của vấn đề và nhu cầu

  FRS (Functional Requirement Specification) là vùng đất của giải pháp. Danh sách chi tiết những tính năng cần làm để đáp ứng nhu cầu đó

  Và để liên kết BRD và FRS, làm sao cho những giải pháp đưa ra phục vụ đúng với các nhu cầu kinh doanh. Đó chính là lúc cần tới Scope model.

  Nếu hỏi: “Làm sao để bán được nhiều hàng trên website?” Thì đó là 1 nhu cầu đúng không? Nhưng nó quá mơ hồ, có hàng trăm nghìn việc phải làm, nên làm và có thể làm. Tương tự những thứ không nên làm cũng nhiều vô kể.
  Scope model hay có thể gọi là Work Breakdown Structure – là cách giúp chia nhỏ những vấn đề khó nuốt thành những mảnh nhỏ hơn. Giúp chúng ta khoanh vùng, chọn ra những việc phải làm một cách nhanh chóng và hợp lý.

  Ví dụ: Scope model cho Website bán hàng

  Chọn ra 1 nhu cầu chủ đạo nhất, sau đó tiếp tục tách nhỏ theo từng lớp với công thức như trên. Bạn sẽ có được 1 Scope model sơ bộ như sau:

  

  Nhìn vào sơ đồ này sẽ cho thấy phạm vi những việc cần làm 1 cách bao quát nhất. Tất nhiên là không thể đầy đủ. Vì đầy đủ không phải là mục tiêu.

  Hãy sử dụng các mindset sau để breakdown:

  • Ở mỗi level của Scope, ưu tiên những nhu cầu / nhóm tính năng Must have. Đừng vội đặt những thứ Nice to have vào.
  • 3-levels: Ở mỗi cấp, hãy brainstorm tối đa 3 nhánh nhỏ hơn. Nếu bạn cảm thấy có quá nhiều thứ muốn bỏ vào và 3 nhánh không đủ. Vậy thì có thể cách tiếp cận của bạn chưa hợp lý. Hãy nhìn rộng ra nữa, làm sao cho chỉ cần tối đa 3 nhánh có thể cover hết những thứ Must have. Đừng đi quá sâu vào chi tiết, dừng lại ở nhóm tính năng cấp 3 là đủ.
  • Việc brainstorm các nhánh con sẽ dựa vào:
    • Sự am hiểu về domain
    • Requirement lấy được từ user
    • Sự hỗ trợ và đề xuất từ dev.
    • Sự sắc bén và kinh nghiệm của BA

  Hãy sử dụng sơ đồ này để chốt lại tài liệu BRD và khởi đầu cho việc viết Function list trong tài liệu FRS. Nó sẽ là 1 chỉ dẫn rất cần thiết để tham khảo trong quá trình làm solution sau này.

  Tháng 10 24, 2026

• 

  Các loại diagram “thần thánh” khi viết BRD (P2 – BPM)

  Business Process Model – BPM

  Phần trước chúng ta đã nói về SCD – một cái nhìn toàn cảnh. Hôm nay sẽ bàn về 1 loại tài liệu khác chứa đựng nhiều thông tin hơn. Đó là BPM – lược đồ quy trình nghiệp vụ

  Nếu SCD là 1 cái địa đồ thô sơ thì BPM sẽ ở tầm Google Map. BPM bắt đầu chỉ rõ các con đường kết nối với nhau như thế nào, ở ngã ba nên rẽ trái hay phải , chỗ nào bị sạt núi…

  BPM giúp gì?

  BPM giả lập trình tự và logic mà các đối tượng trao đổi dữ liệu để đạt được 1 kết quả cụ thể cuối cùng.

  Bạn sẽ dùng tới công cụ này khi phải đối mặt với:

  • 1 quy trình cụ thể: có 1 kết quả cuối cùng cụ thể cần đạt được
  • Có nhiều đối tượng liên quan đến quy trình
  • Có nhiều hành động được thực hiện để đạt kết quả cuối cùng
  • Có nhiều logic và tình huống có thể xảy ra.

  Không phải quy trình nào cũng đè ra vẽ BPM làm chi, chừng nào bạn cảm thấy sẽ rất khó hiểu nếu mô tả bằng chữ thì hãy cân nhắc.

  Cách vẽ BPM

  Để tránh sa đà vào chi tiết, bài viết này chỉ giới thiệu sơ lược và đưa ra ví dụ khái quát. Mình đã viết 1 bài hướng dẫn từng cụ thể, chi tiết từng bước để ra được 1 BPMN xài được.

  Ví dụ

  Quy trình bán hàng as-is (khi chưa có website) được client mô tả như sau:

  Khách bên anh sẽ inbox fanpage facebook của shop để hỏi sản phẩm. Bạn trực inbox bên anh sẽ chăm sóc. Thường là khách hỏi size còn không, check giá. Bạn trực sẽ check hàng trong kho còn tồn không. Nếu còn thì báo khách thanh toán chuyển khoản trước 100%, hoặc nếu khách chọn COD thì chuyển trước 20%. Xong xuôi thì bạn trực đó tạo đơn hàng vô hệ thống quản lý kho sẵn có của shop anh. Nhân viên bên phía kho sẽ thấy đơn hàng và bắt đầu xuất kho, in bill, đóng gói, giao cho bên vận chuyển. Bên vận chuyển tiến hành giao hàng cho khách. Khách hàng nhận hàng nếu chọn COD thì phải thanh toán thêm 80%. Nếu khách không nhận hàng, bên vận chuyển sẽ giao ngược về, nhân viên kho nhận hàng sẽ tiến hành nhập kho.

  Một đoạn text dài, nhiều thông tin đan chéo nhau đúng không.

  Vì ghi theo văn nói, nên sẽ không theo 1 trình tự nhất định, nhiều khi nói cái này thì nhảy sang cái kia. Rồi lâu lâu lại lòi ra 1 “nhân vật” bất ngờ nào đó không báo trước. Đừng có viết vào document. Dev đọc được lại chửi cho.

  Bỏ ra tầm 30-45p để “chuyển hóa” nó thành 1 bức ảnh như thế này sẽ nâng tầm giá trị của 1 BA.

  

  Giờ thì đã thấy rõ quy trình này gồm những ai cùng tham gia, thực hiện những hành động gì, theo trình tự nào.

  Nhìn vào sơ đồ này, dễ dàng thấy ngay được:

  • Các đối tượng tham gia vào quy trình
  • Điểm bắt đầu và kết thúc của từng nhóm đối tượng trong quy trình
  • Chọn ra 1 action bất kỳ trong bức tranh này cũng thấy có thể suy ngược ra được cần điều kiện gì để action này xảy ra (input), và sau khi nó xảy ra thì trả ra thông tin gì (output)

  So sánh 1 chút để thấy được sự ưu việt của sơ đồ quy trình

  • Lược bỏ tất cả từ ngữ dư thừa
  • Các hành động đều có PIC, input, output rõ ràng
  • Sắp xếp và phân loại rất rõ, đưa sơ đồ này cho 1 role bất kỳ trong quy trình, họ có thể thấy được ngay tất cả các action họ phải làm, trình tự và kết quả cần đạt được

  Lưu ý:

  • Đừng tham lam dồn tất cả thông tin vào 1 sơ đồ BPM. Hãy gói gọn trong 1 hoặc 1/2 trang giấy
  • Nếu 1 role nào đó có quá nhiều action cần thực hiện trong 1 quy trình, hãy cố gắng gom nhóm các action đó lại thành 1 quy trình riêng biệt (Sub-Process). Bạn có thể làm rõ các Sub-process đó trong 1 sơ đồ khác. Keep it simple stupid!
  • Lưu ý 1 chút về tính thẩm mỹ và các cách sắp xếp, không có đúng hoặc sai trong cái này. Nhưng mục đích của BPM là làm mọi thứ rõ ràng chứ không phải rối hơn. Đừng ẩu!
  • Mindset thần thánh 3-levels
    • Mỗi role, hãy cô đọng lại thành 3 hoặc 4 task / Subprocess chính họ cần làm.
    • Chọn ra 3 hoặc 4 logic cốt lõi.
    • Hạn chế thể hiện alternative và exception flow. Chỉ 1 flow vui vẻ đã có thể ngốn hết thời gian rồi. Hãy tách riêng chúng ra.

  Đón xem phần 3 trong chuỗi 3 bài tại đây.

  Tháng 10 24, 2026

• 

  Các loại diagram “thần thánh” khi viết BRD (P1 – SCD)

  Đôi khi 1 ngàn câu nói không bằng 1 tấm hình. Não người có vẻ ưu ái hơn đối với việc xử lý hình ảnh so với xử lý ngôn ngữ. 20 trang giấy của 1 chuyên đề phức tạp có thể được gói gọn vào 1 vài hình ảnh minh họa.

  Làm BA, bạn sẽ phải đối mặt với rất nhiều stakeholder với nhiều background khác nhau. Người thì làm kỹ thuật, người thì chỉ chuyên bán hàng, người thì làm sổ sách kế toán. Bạn cần tạo ra 1 thứ ngôn ngữ phổ thông nhất với tất cả người đọc của mình. Và các sơ đồ, mô hình, bảng biểu là 1 thứ hình ảnh biết nói. Thống nhất các ý tưởng trên 1 trang giấy. Dễ dàng trong quá trình confirm, mô tả bức tranh tổng thể.

  Ok, giờ thì bắt đầu. Hãy chọn 1 ví dụ xuyên suốt cho bài viết này để các bạn dễ hình dung: Project xây dựng 1 website bán hàng.

  1. System context diagram – SCD

  Lược đồ ngữ cảnh hệ thống – hay SCD, là sơ đồ có mức độ tổng quát cao nhất trong các sơ đồ được trình bày dưới đây.

  SCD giúp gì?

  Thường thì chiêu này sẽ dùng ở đầu mỗi tài liệu lớn, hoặc ở đầu 1 phân mục phức tạp. Vai trò của nó giống như 1 cái mục lục, giúp người đọc hình dung họ sắp đọc cái gì, và chúng nó liên kết với nhau như thế nào trong một bức tranh lớn.

  Hãy tưởng tượng bạn đi du lịch ở 1 khu rừng xa lạ và bị lạc đường. SCD sẽ giống 1 cái địa đồ. Nhìn vào bạn sẽ biết được:

  • Các hướng đông, tây, nam, bắc và các cột mốc địa lý quan trọng (dòng suối, ngọn núi…);
  • Bạn đang đứng ở đâu giữa khu rừng này 1 cách tương đối;
  • Bạn nên đi theo hướng nào để mò ra khỏi khu rừng.

  Lược đồ ngữ cảnh cũng vậy, nó là 1 cái bản đồ tổng quát cho bất kỳ ai đang lặn ngụp trong hệ thống. Nhìn vào đây bạn sẽ thấy được luồng thông tin (ở mức tổng thể) chảy ra và vào hệ thống như thế nào. Bạn sẽ không thấy được tính năng hay mô tả tính năng gì quy trình gì trong này hết.

  Cách vẽ SCD

  

  Phạm vi

  1 SCD cho toàn hệ thống, hay chỉ cho 1 hệ thống con.

  Chọn phạm vi phù hợp với tài liệu bạn đang viết. Ví dụ:

  • Tài liệu BRD tổng quan cho toàn dự án Xây dựng website X. Khi đó phạm vi system là System của website X.
  • Hoặc bạn viết tài liệu riêng cho phần CMS (trang quản lý nội dung) thôi thì phạm vi systemt lúc này là CMS System

  Và bạn sẽ có input cho bước tiếp theo.

  Đối tượng dữ liệu

  • Trung tâm
    • Đã xác định được phạm vi thì ngay lập tức bạn xác định được cục nằm ở trung tâm sơ đồ. Đó chính là ngữ cảnh hệ thống.
    • Chỉ có 1 cục đó thôi. Ở ví dụ này gọi chung là system luôn, gộp hết Website + CMS lại.
  • Đối tượng dữ liệu:
    • Hình dung xem đối tượng nào cung cấp dữ liệu đi vào system
    • Và system cung cấp dữ liệu ra cho đối tượng nào.

  Dòng chảy dữ liệu

  Từ đối tượng đã xác định, tiếp tục hình dung:

  • Họ sẽ đổ dữ liệu vào hệ thống qua hành động nào: Vẽ mũi tên từ Đối tượng → Hệ thống. Ghi tên hành động đó (Động từ + Danh từ).
  • System cung cấp dữ liệu gì cho họ: Vẽ mũi tên Hệ thống → Đối tượng. Ghi tên dữ liệu đó (Danh từ)

  Rồi, tô màu và sắp xếp lại cho các khối. Cap màn hình lại và dán vào tài liệu thôi.

Đọc tiếp phần sau cho loại diagram thứ 2 ở đây nhé