Chuyển tới nội dung chính

Tách Biệt Nhiệm Vụ (Segregation of Duties) & Dòng Vết Kiểm Toán

Sứ Mệnh Của Bài Học

Trong các bài trước, chúng ta đã hiểu hệ thống ERP là gì và làm quen với việc tạo các chứng từ cơ bản. Tuy nhiên, sự khác biệt lớn nhất giữa một "phần mềm ghi chép" và một Hệ thống ERP thực thụ nằm ở khả năng Kiểm Soát Nội Bộ (Internal Controls).

Bài học này sẽ đi sâu đến "tận cùng ngọn ngành" của nguyên lý Tách biệt nhiệm vụ (Segregation of Duties - SoD), kiến trúc phân quyền đa tầng và dòng vết kiểm toán (Audit Trail) – những tấm khiên thép bảo vệ tài sản, chống gian lận và sai sót trong doanh nghiệp của bạn.

1. Tại Sao Không Để "Một Người Làm Mọi Việc"?​

Khi một doanh nghiệp chỉ có 2-3 người (ví dụ: vợ làm kế toán kiêm thủ quỹ, chồng vừa bán hàng vừa giao hàng), sự tin tưởng là tuyệt đối và quy trình rất nhanh gọn. Tuy nhiên, khi doanh nghiệp mở rộng lên 20, 50 hay 500 nhân sự, rủi ro tiềm ẩn bắt đầu phình to:

  • Rủi ro nhầm lẫn (Human Error): Một nhân viên kinh doanh mệt mỏi có thể gõ nhầm giá bán của sản phẩm từ 1.000.000đ thành 100.000đ. Nếu phần mềm cho phép họ tự chốt đơn, tự xuất kho, doanh nghiệp sẽ mất tiền oan.
  • Rủi ro gian lận (Fraud): Nếu một nhân viên mua hàng vừa có quyền chọn nhà cung cấp, vừa có quyền tạo Phiếu nhập kho, và vừa có quyền Duyệt chi tiền... Họ hoàn toàn có thể tạo ra một nhà cung cấp "ma", lập phiếu nhập hàng "khống", và chuyển tiền của công ty vào tài khoản cá nhân.

Để giải quyết vấn đề này, các hệ thống ERP áp dụng một nguyên tắc bất di bất dịch của ngành Kiểm toán và Quản trị rủi ro: Segregation of Duties (SoD) – Tách biệt nhiệm vụ.

2. Bản Chất Của Tách Biệt Nhiệm Vụ (SoD) Là Gì?​

SoD là nguyên tắc thiết kế luồng công việc sao cho không có một cá nhân nào có quyền thực hiện toàn bộ một quy trình nghiệp vụ từ đầu đến cuối. Một quy trình quan trọng phải luôn đi qua ít nhất 2 người (Nguyên tắc 4 mắt - Four-eyes principle).

Trong một doanh nghiệp chuẩn mực, ba nhóm quyền hạn sau đây bắt buộc phải tách rời:

  1. Quyền Phê Duyệt / Quyết Định (Authorization): Ký duyệt mua hàng, duyệt giá bán.
  2. Quyền Quản Lý Tài Sản Vật Lý (Custody): Cầm chìa khóa kho hàng, cầm két sắt, giữ tài khoản ngân hàng.
  3. Quyền Ghi Sổ / Xử Lý Dữ Liệu (Record Keeping): Định khoản kế toán, ghi nhận công nợ.

Ví Dụ Thực Tế Về SoD Trong ERP​

Hãy xem một quy trình Mua hàng - Nhập kho - Thanh toán (Procure to Pay) nếu áp dụng đúng chuẩn SoD sẽ diễn ra như thế nào:

  • Bước 1 - Đề xuất: Nhân viên mua hàng tạo Purchase Order (Đơn mua hàng). Họ đang đề xuất mua.
  • Bước 2 - Phê duyệt: Kế toán trưởng hoặc Giám đốc kiểm tra đơn giá, hạn mức ngân sách và ấn nút Submit (Duyệt) Đơn mua hàng.
  • Bước 3 - Nhận tài sản: Thủ kho kiểm đếm thực tế khi xe giao hàng đến, lập Purchase Receipt (Phiếu nhập kho). Thủ kho chỉ ghi nhận số lượng thực nhận, họ không quan tâm đến giá tiền hay công nợ.
  • Bước 4 - Ghi sổ công nợ: Kế toán công nợ đối chiếu Hóa đơn tài chính của nhà cung cấp với Phiếu nhập kho (so khớp 3 chiều - 3-way matching), sau đó lập Purchase Invoice (Hóa đơn mua hàng) để ghi nhận nợ phải trả.
  • Bước 5 - Chi tiền: Kế toán trưởng duyệt đề nghị thanh toán. Thủ quỹ (hoặc người cầm token ngân hàng) thực hiện chuyển khoản và ghi nhận Payment Entry (Phiếu thanh toán).

Mỗi bước trên được thực hiện bởi một Vai trò (Role) khác nhau trên ERP, không ai được lấn sân của ai. Nếu muốn gian lận, Nhân viên mua hàng, Thủ kho và Thủ quỹ bắt buộc phải thông đồng với nhau – điều này khó hơn rất nhiều so với việc một người tự ý làm bậy.

3. Kiến Trúc Phân Quyền Đa Tầng Trong ERPNext​

Để biến nguyên lý SoD thành các dòng code cứng rắn, ERPNext cung cấp một kiến trúc phân quyền rất sâu sắc, chia làm 3 lớp bảo vệ độc lập:

Lớp Bảo Vệ 1: Trình Quản Lý Quyền Theo Vai Trò (Role Permission Manager)​

Thay vì cấp quyền cho từng cá nhân (User), ERP sẽ định nghĩa các Vai Trò (Role). Ví dụ: Sales User, Sales Manager, Stock User, Accounts Manager. Một cá nhân có thể được gán nhiều Role.

Trên từng loại chứng từ (DocType), mỗi Role sẽ được cấp các hành động cụ thể:

  • Read (Đọc): Chỉ nhìn thấy tài liệu, không được thao tác.
  • Write (Ghi/Sửa): Được phép tạo mới hoặc sửa nội dung tài liệu ở trạng thái Draft (Nháp).
  • Submit (Duyệt/Khóa sổ): Bấm nút chốt chứng từ. Hành động này sẽ khóa toàn bộ dữ liệu, phát sinh bút toán sổ cái hoặc sổ kho. Đây là quyền nguy hiểm nhất.
  • Cancel (Hủy): Hủy chứng từ đã Submit (tạo bút toán đảo triệt tiêu).
  • Amend (Sửa đổi): Tạo một bản sao mới từ chứng từ đã Hủy để sửa lỗi.

💡 Mẹo thiết lập: Đừng bao giờ cấp quyền Submit Phiếu nhập kho cho Nhân viên mua hàng. Quyền đó chỉ thuộc về Stock User (Thủ kho).

Lớp Bảo Vệ 2: Giới Hạn Dòng Dữ Liệu (User Permissions / Row-Level Security)​

Quyền Role giải quyết bài toán "Bạn được làm thao tác gì?". Còn User Permissions giải quyết bài toán "Bạn được làm trên dữ liệu của ai?".

Giả sử doanh nghiệp có 2 chi nhánh: Hà Nội và TP.HCM. Cả 2 thủ kho đều có Role Stock User (có quyền Submit Phiếu xuất kho). Làm sao để thủ kho Hà Nội không vô tình xuất nhầm hàng ở kho TP.HCM?

Đó là lúc ta thiết lập User Permission. Ta gán một giới hạn cho tài khoản thủ kho Hà Nội: Chỉ được thao tác với dữ liệu có trường Company = Chi nhánh Hà Nội, hoặc trường Warehouse = Kho Hà Nội. Lập tức, toàn bộ các đơn hàng, phiếu nhập, tồn kho của chi nhánh TP.HCM sẽ biến mất hoàn toàn khỏi màn hình của thủ kho Hà Nội.

Lớp Bảo Vệ 3: Quy Trình Phê Duyệt Nhiều Bước (Workflows)​

Có những nghiệp vụ phức tạp đòi hỏi sự tham gia của nhiều cấp quản lý trên cùng một chứng từ, dựa trên các điều kiện động. Quyền Submit cơ bản sẽ không đủ đáp ứng. Lúc này ta dùng Workflows.

Ví dụ với Quy trình duyệt Báo Giá (Quotation):

  • Nếu Báo giá < 50 triệu: Sales User soạn -> Sales Manager duyệt.
  • Nếu Báo giá >= 50 triệu: Sales User soạn -> Sales Manager duyệt bước 1 -> CEO duyệt bước 2.

Hệ thống Workflow cho phép ta định nghĩa:

  1. Trạng thái (States): Nháp, Chờ Quản lý duyệt, Chờ Giám đốc duyệt, Đã duyệt.
  2. Sự chuyển đổi (Transitions): Ai (Role nào) có quyền bấm nút chuyển từ trạng thái này sang trạng thái khác. Nút đó sẽ ẩn đi đối với những người không có thẩm quyền.

4. Dòng Vết Kiểm Toán (Audit Trail) – "Con Mắt Không Bao Giờ Ngủ"​

Dù có hệ thống phân quyền chặt chẽ, sai sót và ý đồ xấu vẫn có thể len lỏi. Vậy khi xảy ra sự cố hao hụt tiền hoặc hàng hóa, làm sao để điều tra trách nhiệm?

Hệ thống ERP giải quyết vấn đề này bằng một cơ chế cốt lõi được gọi là Audit Trail (Dòng vết kiểm toán). Mỗi một tương tác dù nhỏ nhất của người dùng đều bị hệ thống ghi lại một cách thầm lặng và không thể tẩy xóa.

Cơ Chế Lưu Vết Sửa Đổi (Versioning & Track Changes)​

Mỗi khi một chứng từ được lưu (ngay cả khi ở trạng thái Nháp), ERPNext sẽ tạo ra một ảnh chụp (snapshot) của phiên bản đó.

  • Khi bạn thay đổi số lượng bán từ 10 thành 100 rồi bấm Save, kéo xuống cuối trang chứng từ, bạn sẽ thấy một dòng log: "Nguyễn Văn A đã đổi số lượng từ 10 thành 100 vào lúc 14:30 ngày 15/05/2026".
  • Bạn không thể xóa được dòng log này, kể cả khi bạn là System Manager (Quản trị viên hệ thống).

Gắn Thẻ Bất Biến (Immutable Timestamps)​

Mọi bản ghi trong cơ sở dữ liệu đều có sẵn 4 cột vô hình nhưng luôn hoạt động:

  1. owner: Ai tạo ra tài liệu này?
  2. creation: Tạo lúc mấy giờ, ngày nào?
  3. modified_by: Ai là người sửa đổi cuối cùng?
  4. modified: Sửa lúc mấy giờ, ngày nào?

Những dữ liệu này được bảo vệ ở tầng Database, người dùng giao diện không có bất cứ ô nhập liệu nào để có thể làm giả ngày tháng tạo chứng từ.

Theo Dõi Truy Cập (View Logs)​

Thậm chí, ERPNext còn có thể cấu hình để lưu lại việc ai đã nhìn thấy chứng từ này. Nếu một nhân viên tải xuống danh sách khách hàng VIP hoặc xem lén thông tin lương của giám đốc (nếu họ vô tình có quyền truy cập), hệ thống đều ghi nhận hành vi Read đó trong bảng View Log.

5. Tổng Kết Bằng Một Lời Khuyên Quản Trị​

Một trong những sai lầm kinh điển nhất của các Giám đốc (CEO) khi mới dùng ERP là: "Cấp cho tôi tài khoản Admin (System Manager), tôi là Giám đốc nên tôi cần quyền cao nhất để xem mọi thứ!".

Đây là một thảm họa về quản trị rủi ro.

Tài khoản System Manager có khả năng thay đổi cấu hình gốc, hủy chứng từ hàng loạt và can thiệp sâu vào luồng dữ liệu. Nếu CEO dùng tài khoản này lướt ERP bằng điện thoại và lỡ tay chạm nhầm nút Cancel một hóa đơn quan trọng, hậu quả kế toán là rất lớn.

Thực hành chuẩn (Best Practice):

  • CEO / Ban Giám đốc: Nên được cấp các Role mang tính chất C-Level hoặc Read Only trên toàn hệ thống. Họ có thể xem mọi báo cáo, đọc mọi chứng từ, và tham gia vào quy trình Workflow để ấn nút Duyệt, nhưng tuyệt đối không nên có quyền Ghi/Sửa/Submit độc lập trong các thao tác nghiệp vụ hàng ngày.
  • Tài khoản Administrator: Chỉ dành riêng cho chuyên gia IT/ERP Administrator và phải được bảo vệ bằng mật khẩu cực mạnh + Xác thực hai yếu tố (2FA), chỉ dùng khi bảo trì hệ thống.

Sức mạnh thực sự của ERP không nằm ở tính năng, mà nằm ở sự kỷ luật. Khi bạn thiết lập đúng SoD, bạn đã xây dựng được một hàng rào phòng thủ tài chính vững chắc cho doanh nghiệp của mình.

👉 Trong bài tiếp theo, chúng ta sẽ khám phá nền tảng dữ liệu gốc rễ của mọi hệ thống ERP: Quản Trị Dữ Liệu Chủ (Master Data Governance).