Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được giao một dự án số hóa quy trình duyệt vay tại một ngân hàng. Bạn chưa gặp ai, chưa phỏng vấn ai, chưa tổ chức workshop nào. Vậy bạn có hoàn toàn "tay trắng" không? Hoàn toàn không. Ngay lúc này, trong các ngăn tủ tài liệu, trên Confluence, trong các file Excel của nghiệp vụ, trong sổ tay quy trình đóng dấu của Khối Vận hành — đã có hàng nghìn trang thông tin chờ bạn khai thác.
Document Analysis (phân tích tài liệu) chính là kỹ thuật elicitation mà BA chuyên nghiệp dùng để "đào mỏ" kho tri thức sẵn có này trước khi làm phiền bất kỳ stakeholder nào. Đây là một trong những technique được BABOK liệt kê chính thức, và theo kinh nghiệm của tôi, đây là kỹ thuật bị đánh giá thấp nhất nhưng lại tiết kiệm thời gian nhất.
Tại sao quan trọng? Vì thời gian của stakeholder là tài nguyên đắt đỏ nhất trong một dự án. Một Giám đốc Vận hành chỉ cho bạn 30 phút phỏng vấn. Bạn muốn dùng 30 phút đó để hỏi "Quy trình duyệt vay gồm mấy bước?" — câu mà bạn có thể tự tìm trong SOP — hay để hỏi "Bước thẩm định hồ sơ thường tắc ở đâu và vì sao?" — câu mà chỉ con người mới trả lời được? Document analysis giúp bạn đi vào phòng họp với một bộ khung kiến thức đã có sẵn, để mỗi câu hỏi đặt ra đều có giá trị cao. Đây cũng là nền tảng để bài sau — Observation và Shadowing (Bài 38) — trở nên hiệu quả, vì bạn sẽ biết "lý thuyết trên giấy nói gì" trước khi đi quan sát "thực tế làm gì".
Khái niệm cốt lõi
Document analysis là việc nghiên cứu một cách có hệ thống các tài liệu hiện hữu để trích xuất thông tin liên quan đến nhu cầu nghiệp vụ, quy tắc nghiệp vụ (business rules), quy trình, và bối cảnh của giải pháp. Điểm mấu chốt nằm ở hai chữ "có hệ thống" — đọc lan man không phải là document analysis.
Hai loại trạng thái: "should-be" và "as-is"
Trước khi nói về nguồn tài liệu, bạn cần nắm một sự phân biệt nền tảng. Mỗi tài liệu cho bạn biết một trong hai bức tranh:
- Trạng thái "should-be" (lẽ ra phải vậy): Quy trình lý tưởng theo thiết kế. Đây là những gì policy, quy chế, SOP mô tả. Nó nói "đáng lẽ nhân viên phải làm thế này".
- Trạng thái "as-is" (thực tế đang vậy): Quy trình thực sự diễn ra. Đây là những gì log hệ thống, báo cáo lỗi, email phàn nàn, file Excel "lậu" do nhân viên tự tạo phản ánh.
Các nguồn tài liệu thường gặp
| Nguồn | Cho bạn biết gì | Trạng thái |
|---|---|---|
| Policies / Quy chế / Quy định | Ràng buộc, business rules, giới hạn pháp lý bắt buộc | should-be |
| Procedures / SOP (quy trình chuẩn) | Trình tự các bước nghiệp vụ lý tưởng | should-be |
| Manuals / Hướng dẫn sử dụng | Cách hệ thống hiện tại vận hành, các tính năng đang có | as-is (của hệ thống cũ) |
| Báo cáo / Report mẫu | Output nghiệp vụ cần, các chỉ số đang theo dõi | as-is |
| Org chart / Sơ đồ tổ chức | Vai trò, phân quyền, ai duyệt ai (gợi ý stakeholder) | should-be |
| Hợp đồng / SLA | Cam kết dịch vụ, ràng buộc với đối tác/khách hàng | should-be |
| Tài liệu hệ thống cũ (legacy) | Logic nghiệp vụ đã được code hóa, các edge case | as-is |
| Form / Mẫu biểu | Dữ liệu nào đang được thu thập, các trường bắt buộc | as-is |
| File Excel "tự chế" của nhân viên | Quy trình ngầm, workaround, nhu cầu chưa được đáp ứng | as-is (rất quý!) |
| Email / Ticket khiếu nại | Pain point thật, tần suất lỗi | as-is |
Phân biệt với các kỹ thuật khác
Đừng nhầm document analysis với interface analysis (Bài 39, phân tích điểm tích hợp giữa các hệ thống) hay với data/log analysis (Bài 17, phân tích dữ liệu vận hành để rút insight). Document analysis tập trung vào tài liệu do con người viết ra để mô tả nghiệp vụ — văn bản, quy trình, biểu mẫu — chứ không phải dữ liệu giao dịch thô hay đặc tả API. Khi bạn đọc một bản SOP, đó là document analysis. Khi bạn truy vấn một triệu dòng log để tìm pattern, đó là data analysis.
Tình huống thực tế
Ví dụ 1: Ngân hàng số hóa quy trình mở tài khoản (bối cảnh Việt Nam)
Một BA tên Linh nhận dự án xây dựng luồng eKYC (định danh điện tử) cho một ngân hàng thương mại tại TP.HCM. Trước khi phỏng vấn ai, Linh xin ba loại tài liệu: (1) Quy chế mở tài khoản theo Thông tư của NHNN, (2) SOP mở tài khoản tại quầy hiện hành, và (3) mẫu biểu giấy "Đề nghị mở tài khoản".
Đọc SOP, Linh thấy quy trình "should-be" gồm 7 bước, trong đó bước 4 là "đối chiếu CMND/CCCD bản gốc". Nhưng đọc mẫu biểu, cô phát hiện có tới 11 trường thông tin bắt buộc, trong đó 3 trường (nghề nghiệp, mục đích mở tài khoản, nguồn tiền) là do quy định phòng chống rửa tiền. Đây là những business rule mà nếu chỉ phỏng vấn nhân viên giao dịch, cô có thể bỏ sót vì với họ những trường này "hiển nhiên phải có".
Diễn giải: Nhờ document analysis, Linh bước vào buổi phỏng vấn với câu hỏi sắc bén: "Trong môi trường eKYC không gặp mặt trực tiếp, làm sao chúng ta thay thế bước 4 đối chiếu bản gốc?" — thay vì hỏi những câu cơ bản về quy trình.
Bài học: Tài liệu pháp lý (Thông tư, quy chế) là nguồn business rule không thể thương lượng. Đọc chúng trước giúp bạn không thiết kế ra một giải pháp vi phạm quy định — sai lầm cực kỳ tốn kém.
Ví dụ 2: Khoảng cách "should-be" vs "as-is" tại công ty logistics
Một công ty giao vận ở Hà Nội thuê BA để xây hệ thống quản lý đơn hàng mới. SOP chính thức nói: "Sau khi giao hàng thành công, tài xế cập nhật trạng thái 'Đã giao' trên app trong vòng 15 phút." Nghe rất gọn gàng.
Nhưng BA xin thêm hai nguồn as-is: file log cập nhật trạng thái (xuất từ hệ thống cũ) và một file Excel mà chị điều phối viên tự tạo. Log cho thấy 40% đơn được cập nhật trạng thái muộn hơn 2 tiếng. Còn file Excel của chị điều phối — tên là "theo dõi đơn treo.xlsx" — chứa danh sách các đơn mà tài xế gọi điện báo "đã giao nhưng quên bấm app", và chị phải gọi xác nhận từng đơn với khách.
Diễn giải: "Should-be" nói quy trình hoàn hảo, nhưng "as-is" (log + file Excel tự chế) phơi bày một pain point khổng lồ: app khó dùng khiến tài xế không cập nhật, tạo ra cả một lớp công việc thủ công ẩn.
Bài học: File Excel tự chế của nhân viên là "kim chỉ nam" tới các requirement quan trọng nhất. Yêu cầu thật sự ở đây không phải "thêm nút cập nhật" mà là "thiết kế lại UX cập nhật trạng thái để tài xế dùng được khi đang vội".
Ví dụ 3: Tài liệu lỗi thời tại doanh nghiệp sản xuất (bối cảnh Đông Nam Á)
Một nhà máy sản xuất linh kiện điện tử tại khu công nghiệp ở Bình Dương cung cấp cho BA một bộ SOP dày 200 trang về quy trình kiểm tra chất lượng. BA trẻ tin tưởng tuyệt đối, dành hai tuần phân tích và viết requirement dựa hoàn toàn trên đó. Đến khi demo, trưởng phòng QC ngạc nhiên: "Quy trình này chúng tôi bỏ từ năm 2021 sau khi chuyển sang chuẩn IPC mới rồi mà."
Diễn giải: Tài liệu có ngày ban hành từ 4 năm trước, không ai cập nhật. BA đã không kiểm tra "vòng đời" của tài liệu — version, ngày hiệu lực, người phê duyệt gần nhất.
Bài học: Tài liệu không phải lúc nào cũng đáng tin. Luôn kiểm tra ngày ban hành, phiên bản, và xác nhận (validate) lại với người dùng thực tế. Document analysis cho bạn giả thuyết, không phải sự thật tuyệt đối.
Hướng dẫn từng bước
Đây là quy trình 6 bước tôi khuyên bạn áp dụng mỗi khi làm document analysis.
Bước 1 — Lập danh mục tài liệu (document inventory). Trước khi đọc, hãy liệt kê tất cả tài liệu có thể liên quan và nguồn lấy chúng. Tạo một bảng đơn giản: tên tài liệu, loại (policy/SOP/manual...), người sở hữu, ngày ban hành, mức độ ưu tiên. Việc này giúp bạn không bỏ sót và không bị "ngộp" giữa biển giấy tờ.
Bước 2 — Phân loại should-be vs as-is. Với mỗi tài liệu trong danh mục, gắn nhãn nó mô tả trạng thái lý tưởng hay thực tế. Điều này định hướng cách bạn đọc: tài liệu should-be cho bạn business rule và quy trình chuẩn; tài liệu as-is cho bạn pain point.
Bước 3 — Kiểm tra độ tin cậy. Với mỗi tài liệu, hỏi: Nó được ban hành khi nào? Đây có phải phiên bản mới nhất không? Ai phê duyệt? Còn hiệu lực không? Đánh dấu rõ tài liệu nào "đáng ngờ" để xác nhận lại sau.
Bước 4 — Trích xuất có cấu trúc. Đọc và rút ra ba nhóm thông tin, ghi vào một nơi tập trung (ví dụ một trang Confluence):
- Business rules: "Khoản vay trên 500 triệu phải có hai cấp duyệt."
- Quy trình / bước: trình tự các hoạt động.
- Câu hỏi & khoảng trống: những chỗ tài liệu mâu thuẫn, thiếu, hoặc bạn chưa hiểu.
Bước 6 — Xác nhận với người thật. Document analysis không bao giờ đứng một mình. Mang phát hiện của bạn đi xác nhận với SME (Bài 23) qua phỏng vấn hoặc playback (Bài 18). Câu chốt kinh điển: "Theo SOP thì quy trình là thế này, anh/chị xác nhận giúp em thực tế có đúng vậy không, hay có khác biệt nào?"
Lỗi thường gặp & mẹo
Lỗi 1 — Tin tài liệu một cách mù quáng. Như ví dụ nhà máy Bình Dương, tài liệu lỗi thời có thể dẫn bạn đi sai cả dự án. Mẹo: luôn coi mỗi phát hiện từ tài liệu là một "giả thuyết cần kiểm chứng", không phải sự thật.
Lỗi 2 — Bỏ qua tài liệu "không chính thức". Người mới thường chỉ xin SOP và quy chế, mà quên file Excel tự chế, email, ticket. Đây mới là nơi pain point thật ẩn náu. Mẹo: hãy hỏi thẳng nhân viên vận hành: "Ngoài hệ thống chính thức, anh/chị có tự dùng file hay công cụ nào để làm việc không?"
Lỗi 3 — Đọc lan man, không có khung. Lao vào đọc 200 trang mà không có mục tiêu khiến bạn tốn thời gian và mất tập trung. Mẹo: trước khi đọc, viết ra 5–7 câu hỏi bạn muốn tài liệu trả lời. Đọc để tìm câu trả lời, không đọc để "biết hết".
Lỗi 4 — Không ghi nguồn (traceability). Khi viết requirement, bạn cần truy được nó đến từ tài liệu nào, trang nào. Sáu tháng sau khi có người chất vấn, bạn sẽ cảm ơn chính mình. Mẹo: mỗi requirement trích từ tài liệu nên ghi rõ "Nguồn: SOP-MoTaiKhoan v3.2, mục 4.1". Điều này cũng chuẩn bị cho Traceability Matrix ở Bài 55.
Lỗi 5 — Coi document analysis thay thế cho con người. Tài liệu cho bạn cái khung, nhưng "tri thức ngầm" (tacit knowledge) — lý do tại sao quy trình lại thế, các ngoại lệ không ghi ra giấy — chỉ con người mới có. Mẹo: dùng document analysis để chuẩn bị, rồi luôn theo sau bằng phỏng vấn hoặc quan sát.
Mẹo nâng cao: Với tài liệu pháp lý dày (Thông tư, Nghị định), hãy lập một bảng "business rules catalog" riêng — mỗi dòng một quy tắc, kèm điều khoản tham chiếu. Đây sẽ là tài sản dùng đi dùng lại trong cả dự án và là bằng chứng vững chắc khi cần bảo vệ thiết kế trước bộ phận Pháp chế hoặc Tuân thủ.
Bài tập thực hành
Bài tập 1 — Lập document inventory. Chọn một quy trình bạn quen thuộc (ví dụ: quy trình xin nghỉ phép ở công ty bạn, hoặc quy trình đặt hàng trên một sàn TMĐT bạn hay dùng). Liệt kê ít nhất 6 nguồn tài liệu bạn sẽ thu thập để phân tích, và với mỗi nguồn gắn nhãn "should-be" hay "as-is".
Bài tập 2 — Săn gap should-be vs as-is. Lấy bản mô tả công việc (job description) chính thức của một vị trí — đây là tài liệu "should-be". Phỏng vấn nhanh một người đang giữ vị trí đó (hoặc tự suy nghĩ nếu là việc của bạn) về một ngày làm việc thực tế — đây là "as-is". Liệt kê 3 khác biệt và giải thích mỗi khác biệt có thể dẫn tới requirement gì.
Bài tập 3 — Trích xuất business rule. Tìm phần "Điều kiện và điều khoản" của một dịch vụ bạn dùng (ví dụ: chính sách hoàn tiền của Shopee, điều kiện vay của một app tài chính). Đọc và rút ra ít nhất 5 business rule, viết mỗi rule dưới dạng câu mệnh lệnh rõ ràng (ví dụ: "Yêu cầu hoàn tiền phải gửi trong vòng 7 ngày kể từ ngày nhận hàng"). Ghi rõ nguồn tham chiếu cho từng rule.
Bài tập 4 — Danh sách câu hỏi mở. Dựa trên kết quả bài tập 3, viết ra 5 câu hỏi bạn sẽ mang vào buổi phỏng vấn với stakeholder — những câu mà tài liệu KHÔNG trả lời được nhưng quan trọng để hoàn thiện yêu cầu.
Tóm tắt
Document analysis là kỹ thuật elicitation giúp bạn khai thác kho tri thức sẵn có trước khi tiêu tốn thời gian quý báu của stakeholder. Hãy ghi nhớ những điểm cốt lõi:
- Tài liệu chia làm hai trạng thái: "should-be" (policy, SOP, quy chế — cho bạn business rule và quy trình chuẩn) và "as-is" (log, email, file Excel tự chế — cho bạn pain point thật). Khoảng cách giữa hai trạng thái này là mỏ vàng requirement.
- Đừng bỏ qua tài liệu không chính thức. File Excel tự chế và ticket khiếu nại thường tiết lộ nhu cầu chưa được đáp ứng rõ hơn bất kỳ SOP nào.
- Luôn kiểm tra độ tin cậy: phiên bản, ngày ban hành, người phê duyệt. Tài liệu lỗi thời có thể làm lệch cả dự án.
- Quy trình 6 bước: lập danh mục → phân loại should-be/as-is → kiểm tra độ tin cậy → trích xuất có cấu trúc → tổng hợp đối chiếu chéo → xác nhận với người thật.
- Document analysis cho giả thuyết, không cho sự thật. Nó là bước chuẩn bị tuyệt vời, nhưng phải luôn được theo sau bằng phỏng vấn, quan sát, hoặc playback để xác nhận.