Mở đầu — vì sao bài này quan trọng
Nếu bạn đang làm Finance hoặc Kế toán và đã đọc tới bài này, bạn đã hiểu BA là gì, đã biết kỹ năng nào của mình chuyển đổi được, và đã làm quen với việc biến một bài phân tích tài chính thành business requirements. Bây giờ là lúc chạm tới hai sản phẩm "đầu ra" cụ thể nhất mà một BA phải tạo ra hằng ngày: PRD (Product Requirements Document) và Process Flow (sơ đồ luồng quy trình).
Đây là hai tài liệu mà nhà tuyển dụng sẽ hỏi đầu tiên khi phỏng vấn, và là hai thứ mà đội phát triển (dev, QA, designer) dựa vào để biết phải xây cái gì. Nói thẳng: bạn có thể giỏi phân tích đến mấy, nhưng nếu không viết được PRD rõ ràng và vẽ được process flow đúng chuẩn, bạn chưa thực sự "làm được việc BA".
Tin tốt cho người Finance: bạn có lợi thế rất lớn. Mỗi ngày bạn đã sống trong quy trình — quy trình duyệt chi, quy trình closing cuối kỳ, quy trình đối chiếu công nợ. Bạn đã quen viết thuyết minh báo cáo tài chính (financial statement notes) — một dạng tài liệu giải thích con số cho người khác hiểu. PRD và process flow chỉ là phiên bản "ngôn ngữ phần mềm" của những kỹ năng bạn đã có. Bài này dạy bạn cách dịch chúng sang.
Lưu ý phạm vi: bài này tập trung vào cách viết PRD và cách vẽ process flow ở mức nền tảng, thực hành được ngay. Các kỹ thuật chuyên sâu hơn như BPMN 2.0, use case của Cockburn, Gherkin acceptance criteria, hay business rule catalog sẽ có những bài riêng sau. Ở đây ta xây nền móng.
Khái niệm cốt lõi
PRD là gì — và không phải là gì
PRD (Product Requirements Document) là tài liệu mô tả một sản phẩm hoặc tính năng cần xây dựng cái gì, để giải quyết vấn đề gì, cho ai, và thành công trông như thế nào. Nó trả lời câu hỏi "WHAT" và "WHY", chứ không phải "HOW". HOW (chọn công nghệ gì, code ra sao) là việc của đội kỹ thuật.
Hãy so sánh với thế giới Finance để bạn dễ hình dung. Khi bạn lập một bộ thuyết minh báo cáo tài chính, bạn không chỉ đưa con số mà còn giải thích: con số này đến từ đâu, theo chuẩn mực nào, giả định gì. PRD cũng vậy — nó là "thuyết minh" cho một tính năng phần mềm, giúp mọi người hiểu cùng một thứ.
Một PRD tốt thường có các phần sau:
- Bối cảnh & vấn đề (Problem statement): Vì sao ta cần làm cái này? Nỗi đau của người dùng/doanh nghiệp là gì? Tương đương việc bạn nêu lý do tại sao một khoản mục cần được điều chỉnh.
- Mục tiêu & chỉ số thành công (Goals & metrics): Làm xong thì đo bằng gì? Ví dụ "giảm 50% thời gian duyệt chi". Người Finance cực mạnh ở phần này vì bạn quen tư duy bằng con số và KPI.
- Phạm vi (Scope) & ngoài phạm vi (Out of scope): Lần này làm gì, KHÔNG làm gì. Giống như khi bạn khóa sổ một kỳ — phải nói rõ giao dịch nào thuộc kỳ này.
- User stories / yêu cầu chức năng: Mô tả từng việc người dùng cần làm, thường theo cấu trúc "Là [vai trò], tôi muốn [hành động] để [đạt mục đích]".
- Yêu cầu phi chức năng (Non-functional): Tốc độ, bảo mật, khả năng chịu tải, tuân thủ (compliance).
- Giả định & ràng buộc (Assumptions & constraints): Giống các giả định kế toán (going concern, accrual basis) — phải ghi ra để mọi người cùng đồng ý.
- Câu hỏi mở (Open questions): Những điều chưa chốt, cần stakeholder trả lời.
Process Flow là gì
Process Flow (sơ đồ luồng quy trình) là cách vẽ lại một quy trình bằng hình — ai làm gì, theo thứ tự nào, rẽ nhánh ở đâu khi có điều kiện. Nó biến một đoạn văn dài dòng thành một bức tranh mà ai nhìn cũng hiểu trong 30 giây.
Người Finance vốn đã tư duy theo luồng: chứng từ → ghi nhận → duyệt → hạch toán → báo cáo. Bạn chỉ cần học cách thể hiện luồng đó bằng các ký hiệu chuẩn:
- Hình bầu dục (oval): điểm bắt đầu / kết thúc (Start / End).
- Hình chữ nhật (rectangle): một bước hành động / xử lý (ví dụ "Nhập hóa đơn").
- Hình thoi (diamond): điểm quyết định, có điều kiện rẽ nhánh (ví dụ "Số tiền > 50 triệu?"). Từ đây luôn có ít nhất hai nhánh: Có / Không.
- Mũi tên: hướng đi của luồng.
- Hình bình hành (parallelogram): dữ liệu vào/ra (input/output), ví dụ "Hóa đơn điện tử".
Hai loại process flow bạn sẽ luôn vẽ: As-Is và To-Be
- As-Is (hiện trạng): quy trình đang chạy thực tế hôm nay, kể cả những bước thủ công, lằng nhằng, dễ sai.
- To-Be (tương lai): quy trình sau khi có phần mềm/cải tiến — gọn hơn, tự động hơn.
Tình huống thực tế
Ví dụ 1 — PRD cho tính năng tự động đối chiếu công nợ tại một công ty phân phối ở TP.HCM
Chị Lan, kế toán công nợ 6 năm tại một công ty phân phối hàng tiêu dùng (giả định, doanh thu ~800 tỷ/năm), chuyển sang BA. Dự án đầu tiên của chị: xây tính năng tự động đối chiếu công nợ giữa hệ thống bán hàng và sổ kế toán.
Trước đây, mỗi cuối tháng đội của chị mất 3 ngày để đối chiếu thủ công 1.200 dòng công nợ trên Excel, tỷ lệ sai sót khoảng 5%. Khi viết PRD, chị tận dụng triệt để background của mình:
- Problem statement: "Đối chiếu công nợ thủ công tốn 3 ngày/tháng, sai sót ~5%, gây chậm closing và rủi ro xuất hóa đơn sai."
- Goal & metric: "Giảm thời gian đối chiếu từ 3 ngày xuống dưới 4 giờ; sai sót dưới 0,5%."
- User story: "Là kế toán công nợ, tôi muốn hệ thống tự khớp các giao dịch theo mã khách hàng + số tiền + ngày để tôi chỉ phải xử lý các trường hợp lệch."
- Out of scope: "Lần này KHÔNG xử lý công nợ ngoại tệ và KHÔNG tích hợp với ngân hàng."
Ví dụ 2 — Process Flow As-Is vs To-Be cho quy trình duyệt chi ở một startup fintech
Anh Minh, cựu kế toán tổng hợp, làm BA tại một startup fintech ở Hà Nội. Nhiệm vụ: số hóa quy trình duyệt đề nghị thanh toán (payment request) vốn đang chạy qua email và chữ ký giấy.
Anh vẽ As-Is với swimlane gồm 4 làn: Người đề nghị → Kế toán → Kế toán trưởng → CFO. Sơ đồ phơi bày sự thật đau lòng: có 2 điểm hình thoi ("Số tiền > 100 triệu?" và "Đúng ngân sách?") nhưng việc kiểm tra hoàn toàn thủ công, và chứng từ phải in ra ký tay ở 3 chỗ. Trung bình một đề nghị mất 2,5 ngày mới được duyệt.
Sau đó anh vẽ To-Be: người đề nghị nhập trên hệ thống → hệ thống tự kiểm tra ngân sách (hình thoi tự động) → định tuyến duyệt theo hạn mức → ký số. Thời gian dự kiến: dưới 4 giờ.
Bài học: Khi anh Minh đem hai sơ đồ này trình bày cho ban giám đốc, không ai cần đọc một dòng văn xuôi nào. Sức mạnh của process flow nằm ở chỗ nó làm cho sự lãng phí trở nên hiển nhiên. Anh Minh chia sẻ: nhờ tư duy kiểm soát nội bộ (internal control) từ thời kế toán, anh phát hiện được điểm thiếu chốt kiểm soát mà BA khác bỏ sót — ví dụ "ai duyệt khi CFO đi vắng?".
Ví dụ 3 — Cái bẫy "PRD viết như quy trình kế toán" ở một ngân hàng
Một bạn từ phòng kế toán ngân hàng chuyển sang BA, viết PRD đầu tiên dài 18 trang, mô tả cực kỳ chi tiết từng bước thao tác — y như một quy trình nội bộ (SOP) của ngân hàng. Kết quả: đội dev đọc xong... bối rối. Vì bạn ấy đã viết lẫn cả phần HOW (giao diện phải có nút màu xanh, đặt ở góc trên bên phải), khiến tài liệu vừa thừa vừa thiếu — thừa chi tiết giao diện, thiếu mục tiêu và acceptance criteria.
Bài học: PRD không phải SOP. SOP mô tả cách con người thực hiện một quy trình đã cố định; PRD mô tả vấn đề và kết quả mong muốn để đội kỹ thuật tự thiết kế cách làm. Người Finance phải ý thức "buông" thói quen viết quy trình quá chi li, và tập trung vào WHAT/WHY.
Hướng dẫn từng bước
Phần A — Viết một PRD từ con số 0
- Thu thập bối cảnh & xác định vấn đề. Hỏi: ai đau? đau ở đâu? đo bằng gì? Viết problem statement một câu duy nhất, có số liệu.
- Chốt mục tiêu và metric. Mỗi mục tiêu phải đo được. Dùng kỹ năng KPI của bạn: thời gian, tỷ lệ lỗi, chi phí, số giao dịch/giờ.
- Vẽ ranh giới Scope / Out of scope. Liệt kê rõ những gì KHÔNG làm lần này. Đây là kỹ năng "khóa kỳ" của kế toán áp dụng vào phạm vi dự án.
- Viết user stories. Mỗi story theo mẫu "Là [vai trò], tôi muốn [hành động] để [mục đích]". Sắp xếp theo nhóm chức năng.
- Thêm yêu cầu phi chức năng. Đặc biệt với hệ thống tài chính: bảo mật, phân quyền, lưu vết (audit trail), tuân thủ. Đây là vùng bạn mạnh hơn người khác.
- Ghi giả định, ràng buộc, câu hỏi mở. Đừng giấu điều chưa biết — ghi vào "Open questions" để stakeholder trả lời.
- Rà soát với stakeholder rồi cập nhật. PRD là tài liệu sống.
Phần B — Vẽ một Process Flow chuẩn
- Xác định điểm bắt đầu và kết thúc của quy trình. Một quy trình chỉ nên có một Start rõ ràng.
- Liệt kê các bước theo thứ tự dưới dạng câu bắt đầu bằng động từ: "Nhập hóa đơn", "Kiểm tra ngân sách", "Duyệt".
- Xác định các điểm quyết định (hình thoi). Mỗi hình thoi phải là một câu hỏi Có/Không rõ ràng, và mọi nhánh phải dẫn đi đâu đó (không để nhánh "cụt").
- Gán vai trò bằng swimlane. Mỗi bước thuộc về một làn/một người chịu trách nhiệm.
- Vẽ As-Is trước, To-Be sau. Đừng nhảy thẳng vào giải pháp — phải hiểu hiện trạng đã.
- Kiểm tra tính khép kín: mọi nhánh đều có lối đi, không có bước nào lơ lửng, mọi luồng đều dẫn về một điểm kết thúc.
- Dùng công cụ: Lucidchart, draw.io (miễn phí), Miro, hoặc Figma. Người mới nên bắt đầu với draw.io vì miễn phí và đủ dùng.
Lỗi thường gặp & mẹo
- Viết PRD như SOP/quy trình kế toán. Như ví dụ 3 — sa đà vào HOW. Mẹo: tự hỏi "câu này mô tả vấn đề hay đang chỉ đạo cách làm?". Nếu là cách làm, hãy bỏ ra.
- Metric chung chung. "Tăng hiệu quả" là vô nghĩa. Tận dụng phản xạ định lượng của Finance: luôn gắn một con số mục tiêu.
- Quên Out of scope. Không khoanh vùng phạm vi dẫn tới "scope creep" — dự án phình ra vô tận. Khoanh vùng giống như khóa sổ đúng kỳ.
- Process flow có nhánh cụt. Một hình thoi mà nhánh "Không" không dẫn đi đâu = sơ đồ sai. Luôn kiểm tra từng nhánh.
- Quá nhiều chi tiết trong một sơ đồ. Nếu một flow có hơn ~15-20 bước, hãy tách thành sub-process. Người đọc không nên phải cuộn 3 màn hình.
- Bỏ qua trường hợp ngoại lệ (exception path). Người Finance giỏi việc này nhờ tư duy kiểm soát rủi ro: luôn hỏi "nếu duyệt thất bại thì sao? nếu người duyệt vắng mặt thì sao?".
- Mẹo vàng: Sau khi vẽ xong process flow, dùng chính nó làm xương sống để viết user stories trong PRD. Mỗi bước hành động thường tương ứng một story. Hai tài liệu sẽ ăn khớp nhau.
Bài tập thực hành
Chọn một quy trình tài chính bạn từng làm (ví dụ: quy trình tạm ứng và hoàn ứng, hoặc quy trình lập đề nghị thanh toán). Sau đó:
- Vẽ sơ đồ As-Is bằng draw.io, có ít nhất 2 hình thoi (điểm quyết định) và 3 swimlane theo vai trò. Đảm bảo không có nhánh cụt.
- Vẽ sơ đồ To-Be giả định quy trình này được số hóa bằng phần mềm. Đánh dấu rõ những bước được tự động hóa.
- Viết một PRD ngắn (1-2 trang) cho phần mềm To-Be đó, gồm đầy đủ 7 phần: problem statement, goals & metrics (ít nhất 2 metric có con số), scope, out of scope, 3-5 user stories, yêu cầu phi chức năng, và open questions.
- Tự kiểm tra: Đưa cho một người không làm Finance đọc PRD và nhìn process flow. Họ có hiểu trong 5 phút không? Nếu không, sửa lại cho rõ.
Tóm tắt
- PRD trả lời WHAT và WHY của một tính năng — không phải HOW. Cấu trúc gồm: problem, goals & metrics, scope/out-of-scope, user stories, yêu cầu phi chức năng, giả định, câu hỏi mở. PRD là tài liệu sống.
- Process Flow biến quy trình thành hình ảnh với ký hiệu chuẩn (oval, chữ nhật, hình thoi, mũi tên) và swimlane theo vai trò. Luôn vẽ As-Is trước, To-Be sau — khoảng cách giữa chúng chính là giá trị dự án.
- Người Finance có lợi thế cực lớn: tư duy quy trình, phản xạ định lượng metric, ý thức kiểm soát nội bộ và ngoại lệ, kỹ năng khoanh vùng phạm vi như khóa sổ.
- Cạm bẫy lớn nhất là viết PRD như SOP và sa vào chi tiết HOW. Hãy giữ kỷ luật ở WHAT/WHY.
- Hai tài liệu này nên ăn khớp nhau: mỗi bước trong process flow thường tương ứng một user story trong PRD.