Mở đầu — vì sao bài này quan trọng
Nếu bạn đến từ Finance hoặc Kế toán, có một sự thật bạn cần nghe ngay từ đầu: bạn đã làm "automation" hàng ngày suốt nhiều năm mà có thể không tự gọi nó bằng cái tên đó. Mỗi khi bạn viết một công thức VLOOKUP để khớp dữ liệu giữa hai sheet, dựng một macro để tự động format báo cáo cuối tháng, hay tạo một template Excel với các ô tự tính ra số tổng hợp — bạn đang tự động hóa một quy trình thủ công. Bạn đã có tư duy automation rồi.
Vấn đề là: trong thế giới BA, automation không dừng lại ở một file Excel chạy trên máy của bạn. Nó phải trở thành một system requirement — một yêu cầu rõ ràng để đội kỹ thuật xây dựng tính năng vào hệ thống dùng cho cả phòng ban, cả công ty, có thể là hàng nghìn người dùng. Khoảng cách giữa "tôi có một file Excel tự tính" và "đây là yêu cầu để dev xây một module trên ERP" chính là khoảng cách mà bài học này giúp bạn vượt qua.
Đây là một trong những chủ đề "ăn tiền" nhất khi bạn chuyển từ Finance sang BA, bởi vì rất nhiều dự án chuyển đổi số tại doanh nghiệp Việt Nam bắt đầu chính xác từ câu hỏi: "Làm sao bỏ được những file Excel khổng lồ mà phòng kế toán đang chạy?". Người hiểu được logic bên trong những file Excel đó — tức là bạn — lại thường là người giải thích cho dev tốt nhất. Bài này sẽ dạy bạn cách biến hiểu biết Excel thành ngôn ngữ mà đội phát triển hệ thống có thể đọc và xây dựng.
Khái niệm cốt lõi
Excel là một "hệ thống thu nhỏ" — và đó là tài sản của bạn
Một file Excel nghiệp vụ phức tạp thực ra chứa đủ các thành phần của một hệ thống phần mềm: nó có input (dữ liệu nhập tay hoặc dán vào), có logic xử lý (công thức, IF lồng nhau, macro), có dữ liệu tham chiếu (bảng tỷ giá, bảng thuế suất, danh mục tài khoản), và có output (báo cáo, số tổng hợp, file gửi đi). Khi bạn nhìn file Excel của mình bằng lăng kính này, bạn đã bắt đầu suy nghĩ như một BA chuyên về automation.
Nhiệm vụ của bạn là "giải phẫu" file Excel thành bốn lớp:
- Data inputs: dữ liệu nào đi vào? Từ đâu (nhập tay, import từ ngân hàng, kéo từ phần mềm kế toán)? Định dạng gì?
- Business logic / rules: các quy tắc tính toán, điều kiện. Ví dụ "nếu hóa đơn trên 20 triệu thì phải thanh toán qua ngân hàng để được khấu trừ VAT".
- Lookup / reference data: các bảng tra cứu cố định ít thay đổi.
- Outputs: kết quả cần ra, ai nhận, dùng để làm gì.
Từ thao tác thủ công sang "to-be process"
Trong automation, BA phân biệt rõ hai trạng thái: as-is (quy trình hiện tại đang chạy bằng Excel/thủ công) và to-be (quy trình tương lai khi đã có hệ thống). Sai lầm lớn nhất của người mới là bê nguyên cái Excel hiện tại lên hệ thống — tức là "số hóa cái lộn xộn". Một BA giỏi sẽ hỏi: "Trong quy trình Excel này, bước nào là giá trị thật, bước nào chỉ tồn tại vì Excel không làm được điều tốt hơn?".
Ví dụ, trong Excel bạn phải copy dữ liệu từ sheet A sang sheet B mỗi sáng. Đó không phải là "yêu cầu" — đó là một workaround vì Excel không tự liên thông. Khi lên hệ thống, bước copy đó nên biến mất hoàn toàn, thay bằng dữ liệu liên thông tự động. Bạn phải tách "ý định nghiệp vụ" ra khỏi "thao tác thủ công bắt buộc".
Functional requirement vs business rule
Khi viết yêu cầu cho hệ thống, hãy tách hai thứ:
- Functional requirement: hệ thống phải làm gì. Ví dụ: "Hệ thống phải tự động tính số tiền chiết khấu cho mỗi dòng đơn hàng khi người dùng lưu đơn."
- Business rule: logic cụ thể đằng sau. Ví dụ: "Chiết khấu = 5% nếu giá trị đơn ≥ 50 triệu, 3% nếu từ 20–50 triệu, 0% nếu dưới 20 triệu." (Đây chính là cái IF lồng nhau trong Excel của bạn.)
Các tiêu chí để quyết định automation
Không phải mọi thứ trong Excel đều đáng tự động hóa lên hệ thống. BA cần đánh giá theo: tần suất (chạy hàng ngày hay một năm một lần?), khối lượng (10 dòng hay 100.000 dòng?), tỷ lệ lỗi khi làm thủ công, rủi ro tuân thủ (sai sót gây phạt thuế?), và độ ổn định của logic (quy tắc có thay đổi liên tục không?). Một quy trình tần suất cao + khối lượng lớn + logic ổn định là ứng viên vàng cho automation.
Tình huống thực tế
Ví dụ 1 — File "Đối chiếu công nợ" tại một công ty phân phối FMCG
Chị Lan, kế toán công nợ tại một nhà phân phối hàng tiêu dùng ở TP.HCM, mỗi cuối tháng phải đối chiếu công nợ của hơn 800 nhà bán lẻ. Quy trình as-is: chị export sao kê ngân hàng ra Excel, export danh sách hóa đơn từ phần mềm kế toán ra Excel khác, rồi dùng VLOOKUP và lọc tay để khớp khoản nào đã thu, khoản nào còn nợ. Mỗi tháng tốn khoảng 3 ngày làm việc, và tháng nào cũng có vài chục dòng lệch do trùng tên, sai mã, hoặc khách trả gộp nhiều hóa đơn một lần.
Khi chuyển sang BA và được giao dự án thay thế file này, chị Lan giải phẫu nó ra: input là sao kê ngân hàng + danh sách hóa đơn; logic là quy tắc khớp (khớp theo số tiền + nội dung chuyển khoản, ưu tiên hóa đơn cũ nhất khi khách trả gộp); output là báo cáo tuổi nợ. Chị viết thành functional requirement: "Hệ thống tự động nhập file sao kê (định dạng .csv của ngân hàng X), đối chiếu với hóa đơn chưa thanh toán theo business rule BR-01, và đánh dấu trạng thái thanh toán; các dòng không khớp được tự động chuyển vào hàng đợi xử lý thủ công."
Bài học rút ra: chị không chỉ "số hóa file Excel" mà còn thiết kế cơ chế xử lý ngoại lệ (các dòng không khớp). Chính những dòng "lệch" mà trước đây chị xử lý bằng kinh nghiệm mới là phần khó nhất — và là phần dev cần được mô tả rõ nhất. Một BA non kinh nghiệm thường quên mất "luồng ngoại lệ" và chỉ tả "luồng đẹp".
Ví dụ 2 — Macro tính lương tại một doanh nghiệp sản xuất
Anh Hùng làm kế toán tiền lương tại một nhà máy may ở Bình Dương với 1.200 công nhân. Anh có một file Excel "thần thánh" với macro VBA tự tính lương theo sản phẩm, phụ cấp, tăng ca, trừ BHXH. File này chạy đúng nhưng chỉ mình anh hiểu, và mỗi lần chính sách lương đổi anh phải sửa code VBA trong đêm.
Khi công ty triển khai phần mềm HR, anh Hùng — giờ là BA — phải chuyển logic file này thành yêu cầu hệ thống. Anh phát hiện file có 14 quy tắc tính khác nhau lẫn lộn trong các công thức. Anh lập một bảng business rule rõ ràng: mỗi quy tắc một dòng, có mã, điều kiện áp dụng, công thức, ngày hiệu lực. Ví dụ: "BR-07: Phụ cấp chuyên cần = 300.000đ nếu công nhân đi làm đủ 26 công/tháng, không nghỉ không phép." Anh cũng tách phần "tham số có thể thay đổi" (mức phụ cấp, ngưỡng công) ra để hệ thống cho phép HR tự chỉnh mà không cần dev.
Bài học rút ra: giá trị lớn nhất anh Hùng mang lại không phải là biết Excel, mà là biết bóc tách logic ngầm trong công thức thành các quy tắc tường minh, có phiên bản, ai cũng đọc được. Anh cũng thiết kế tính tham số hóa (parameterization) — điều mà người chỉ biết code cứng sẽ bỏ qua.
Ví dụ 3 — Báo cáo quản trị tại một chuỗi F&B
Một chuỗi cà phê 40 chi nhánh ở Hà Nội có một file Excel tổng hợp doanh thu được gửi qua email mỗi sáng từ 40 quản lý cửa hàng, rồi một bạn ở văn phòng gộp tay vào file tổng. Quy trình mất 2 tiếng mỗi sáng, thường xong lúc 11h trong khi giám đốc cần số lúc 9h.
BA của dự án (vốn từng làm kế toán) không vội đề xuất "xây dashboard". Cô ấy hỏi câu quan trọng: "Vì sao dữ liệu phải gửi tay?" — hóa ra vì hệ thống POS các chi nhánh chưa kết nối tập trung. Cô nhận ra yêu cầu thật không phải là "tự động gộp Excel" mà là "đồng bộ dữ liệu POS về trung tâm theo thời gian thực". Khi giải quyết được gốc, file Excel tổng hợp tự nhiên biến mất.
Bài học rút ra: đôi khi automation đúng nghĩa là xóa bỏ cả quy trình, không phải tự động hóa nó. BA giỏi truy nguyên nhân gốc rễ thay vì tô son cho một quy trình vốn không nên tồn tại.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng để biến một file Excel thành system requirement:
Bước 1 — Map quy trình as-is. Ngồi cạnh người đang dùng file (hoặc chính bạn) và ghi lại từng thao tác: mở file gì, copy từ đâu, bấm nút nào, gửi cho ai. Đừng phán xét, chỉ ghi. Vẽ thành sơ đồ tuần tự đơn giản.
Bước 2 — Giải phẫu file thành 4 lớp. Tách rõ inputs / business logic / reference data / outputs như đã nói ở phần khái niệm. Với mỗi công thức phức tạp, viết lại bằng tiếng Việt thường: "ô này nghĩa là gì với nghiệp vụ?".
Bước 3 — Tách workaround khỏi yêu cầu thật. Đánh dấu những bước chỉ tồn tại vì giới hạn của Excel (copy-paste, gửi email, gộp file thủ công). Những bước này thường biến mất ở to-be.
Bước 4 — Lập catalog business rule. Mỗi quy tắc một dòng: mã rule, mô tả, điều kiện, công thức/kết quả, ngày hiệu lực, nguồn (ai là người duyệt quy tắc này). Đây là tài sản quý nhất bạn bàn giao cho dev.
Bước 5 — Viết functional requirement và data mapping. Mô tả hệ thống phải làm gì (không phải làm thế nào). Kèm bảng mapping: trường dữ liệu nguồn → trường trong hệ thống, kiểu dữ liệu, bắt buộc hay không, giá trị mặc định.
Bước 6 — Thiết kế luồng ngoại lệ. Liệt kê các trường hợp "không đẹp": dữ liệu thiếu, không khớp, trùng, vượt ngưỡng. Với mỗi cái, hệ thống nên làm gì (chặn, cảnh báo, đẩy vào hàng đợi thủ công)?
Bước 7 — Định nghĩa output và tiêu chí nghiệm thu. Output trông thế nào, ai nhận, khi nào. Viết acceptance criteria để tester biết khi nào tính năng được coi là "đúng".
Lỗi thường gặp & mẹo
Lỗi 1 — "Số hóa cái lộn xộn". Bê nguyên quy trình Excel rối rắm lên hệ thống. Mẹo: luôn hỏi "bước này tạo giá trị gì, hay chỉ là vá víu cho Excel?".
Lỗi 2 — Mô tả "cách làm" thay vì "yêu cầu". Viết "hệ thống phải có nút VLOOKUP" thay vì "hệ thống phải tự đối chiếu khoản thu với hóa đơn". Mẹo: tả ý định nghiệp vụ, để dev tự chọn cách kỹ thuật.
Lỗi 3 — Bỏ quên luồng ngoại lệ. Chỉ tả trường hợp dữ liệu đẹp. Trong thực tế, 80% công sức xử lý nằm ở 20% dữ liệu lỗi. Mẹo: với mỗi bước, tự hỏi "nếu dữ liệu sai/thiếu/trùng thì sao?".
Lỗi 4 — Để logic dính cứng, không tham số hóa. Ghi "chiết khấu 5%" cứng vào yêu cầu. Khi business đổi sang 6%, phải sửa code. Mẹo: tách những con số/ngưỡng có khả năng thay đổi thành tham số cấu hình được.
Lỗi 5 — Không xác định nguồn dữ liệu chuẩn. Khi nhiều file Excel có cùng một số nhưng khác nhau, không ai biết tin file nào. Mẹo: xác định "single source of truth" cho từng dữ liệu trước khi automation.
Mẹo vàng: tận dụng chính những file Excel cũ làm "bộ test data". Khi dev xây xong, cho hệ thống chạy lại đúng dữ liệu một tháng cũ và so kết quả với file Excel. Nếu khớp, bạn có bằng chứng automation đúng — đây là kỹ thuật cực mạnh mà người từ Finance dễ nghĩ ra nhờ thói quen đối chiếu số.
Bài tập thực hành
- Chọn một file Excel nghiệp vụ bạn từng dùng (đối chiếu công nợ, tính lương, báo cáo bán hàng...). Giải phẫu nó thành 4 lớp: inputs, business logic, reference data, outputs. Viết ra giấy hoặc một sheet riêng.
- Lập catalog business rule cho file đó: ít nhất 5 quy tắc, mỗi quy tắc gồm mã, mô tả, điều kiện, kết quả, ngày hiệu lực. Đặc biệt cố tìm những quy tắc đang "ẩn" trong công thức IF lồng nhau.
- Phân biệt workaround và yêu cầu thật: liệt kê các thao tác trong file chỉ tồn tại vì giới hạn của Excel. Với mỗi cái, viết một câu mô tả nó sẽ biến đổi thế nào trong quy trình to-be.
- Viết 3 functional requirement theo mẫu "Hệ thống phải [làm gì] khi [điều kiện] để [mục tiêu nghiệp vụ]". Tránh nhắc tên công thức Excel hay thao tác kỹ thuật.
- Thiết kế 3 luồng ngoại lệ: chọn 3 tình huống dữ liệu lỗi có thể xảy ra trong file, và mô tả hệ thống nên xử lý ra sao (chặn / cảnh báo / đẩy hàng đợi thủ công).
Tóm tắt
Process automation từ Excel sang system requirements là sân nhà của người từ Finance, vì bạn đã hiểu sâu logic nghiệp vụ ẩn trong những file Excel mà người khác chỉ thấy là "bảng tính". Chìa khóa là: (1) nhìn Excel như một hệ thống thu nhỏ gồm input, logic, dữ liệu tham chiếu và output; (2) phân biệt quy trình as-is và to-be, mạnh dạn loại bỏ các workaround chỉ tồn tại vì giới hạn của Excel; (3) tách functional requirement khỏi business rule, lập catalog quy tắc tường minh và có thể tham số hóa; (4) luôn thiết kế luồng ngoại lệ vì đó là phần khó và quan trọng nhất; và (5) dùng chính file Excel cũ làm bộ kiểm thử đối chiếu. Khi làm chủ kỹ năng này, bạn không chỉ chuyển nghề — bạn trở thành cây cầu mà mọi dự án chuyển đổi số đều cần: người biến tri thức nghiệp vụ trong đầu kế toán thành ngôn ngữ mà hệ thống có thể xây dựng.