Case Study Phân Tích Nghiệp Vụ Phần Mềm Chấm Công & Nghỉ Phép Chuẩn Thực Tế

Trong hệ thống quản trị nguồn nhân lực (Human Resource Management - HRM), phân hệ Chấm công & Đăng ký Nghỉ phép luôn được coi là bài toán nghiệp vụ kinh điển nhưng phức tạp. Đây là điểm chạm hằng ngày của toàn bộ nhân sự trong doanh nghiệp, đồng thời là nguồn dữ liệu đầu vào trực tiếp cho hệ thống Tính lương.

Tuy nhiên, đối với các IT Business Analyst mới vào nghề, việc chuyển hóa các quy định hành chính thực tế thành tài liệu đặc tả yêu cầu phần mềm chuẩn chỉnh thường gặp khá nhiều lỗ hổng. Ví dụ như luồng quy trình bị ngược, nhầm lẫn giữa chức năng và hành động của nút bấm, hay cấu trúc tài liệu đặc tả (SRS) sai quy chuẩn, khiến đội ngũ Lập trình và Tester gặp khó khăn khi triển khai.

Trong bài viết này sẽ bóc tách toàn diện case study đồ án tốt nghiệp khóa ITBA tại Cole.vn do nhóm học viên K9 thực hiện và bạn Nguyễn Tâm trình bày. Chúng ta sẽ cùng phân tích chi tiết từ sơ đồ phân rã chức năng, quy trình nghiệp vụ, thiết kế wireframe cho đến những bài học phản biện đắt giá từ chuyên gia nhằm giúp bạn nâng cao năng lực viết tài liệu và phân tích nghiệp vụ theo chuẩn quốc tế.

1. Tổng quan bài toán và Sơ đồ phân rã chức năng (Functional Decomposition)

1.1. Mục tiêu kinh doanh và phạm vi hệ thống

Hệ thống được xây dựng nhằm giải quyết bài toán số hóa toàn diện quy trình chấm công và xin nghỉ phép của một doanh nghiệp. Mục tiêu cụ thể bao gồm:

• Đối với Nhân viên: Chủ động theo dõi bảng công cá nhân, tạo đơn nghỉ phép trước hoặc bổ sung đơn giải trình khi có việc đột xuất.

• Đối với Cấp quản lý (Trưởng phòng): Theo dõi quân số theo thời gian thực, phê duyệt hoặc từ chối các đề xuất nghỉ phép/công tác của cấp dưới một cách minh bạch.

• Đối với Phòng Kế toán / Nhân sự (HR): Kiểm soát quỹ phép năm của từng nhân sự, quản trị bảng công tổng hợp và kết xuất dữ liệu chính xác để phục vụ kỳ tính lương cuối tháng.

Theo hướng dẫn từ IIBA (International Institute of Business Analysis) trong khung chuẩn BABOK v3, việc xác định đúng phạm vi (Scope) và tác nhân (Actors) ngay từ giai đoạn khởi tạo là điều kiện tiên quyết để tránh hiện tượng phình phạm vi (Scope Creep) trong quá trình phát triển phần mềm.

1.2. Phân định 3 nhóm đối tượng sử dụng (Actors)

Phần mềm phân quyền rõ ràng cho 3 nhóm đối tượng:

1. Nhân viên (Employee): Đối tượng tạo yêu cầu và theo dõi công cá nhân.

2. Trưởng phòng (Department Manager): Người có thẩm quyền phê duyệt các yêu cầu phát sinh từ phòng ban phụ trách.

3. Kế toán / Quản trị nhân sự (Accountant / HR): Quản lý cấu hình dữ liệu nền (số ngày phép được nghỉ trong năm, ngày phép tồn), kiểm tra tính hợp lệ của công và tổng hợp dữ liệu tính lương.

1.3. Ma trận phân quyền chức năng (Permissions Matrix)

Dưới đây là ma trận phân rã chức năng chi tiết được chuẩn hóa từ dự án:

2. Phân tích chi tiết Luồng quy trình nghiệp vụ (Business Process Flow)

Một trong những đóng góp quan trọng nhất của ITBA là mô hình hóa luồng công việc thực tế thành luồng phần mềm mạch lạc, hạn chế tối đa các điểm nghẽn logic.

2.1. Luồng chuẩn (Happy Path): Nhân viên chủ động đăng ký nghỉ phép

1. Bước 1: Nhân viên đăng nhập vào hệ thống, truy cập mục Đăng ký mới.

2. Bước 2: Hệ thống tự động trích xuất thông tin nhân sự sẵn có (Họ tên, Mã nhân viên, Phòng ban). Nhân viên chỉ cần chọn:

   • Người duyệt (Người quản lý trực tiếp).

   • Loại nghỉ phép (Nghỉ phép năm hưởng lương, Nghỉ ốm hưởng chế độ BHXH, Nghỉ việc riêng có lương, Nghỉ không lương).

   • Thời gian nghỉ (Từ ngày ... Đến ngày ...) và số ngày nghỉ dự kiến.

   • Lý do xin nghỉ.

3. Bước 3: Nhân viên nhấn xác nhận gửi đơn. Trạng thái đơn được chuyển sang Đang đợi (Pending).

4. Bước 4: Trưởng phòng đăng nhập, vào danh sách duyệt đơn. Kiểm tra tình hình nhân sự phòng ban và bấm Duyệt.

5. Bước 5: Trạng thái đơn chuyển sang Đã duyệt (Approved). Hệ thống tự động ghi nhận vào dữ liệu ngày công và chuyển đến bộ phận Kế toán để theo dõi, tự động trừ vào quỹ ngày phép năm của nhân viên đó.

2.2. Luồng ngoại lệ (Alternative & Exception Paths): Xử lý thực tế

Tình huống 1: Nghỉ đột xuất (Nghỉ trước, làm đơn sau)

Trong thực tế doanh nghiệp, có những sự cố bất khả kháng (ốm đau đột xuất, tai nạn) khiến nhân sự chỉ kịp thông báo nhanh qua tin nhắn hoặc điện thoại mà chưa tạo đơn trên phần mềm.

• Cách xử lý của hệ thống:

  • Khi nhân viên đi làm trở lại và vào kiểm tra bảng công, hệ thống sẽ phát hiện ngày vắng mặt và đánh dấu trạng thái "Thiếu công".

  • Hệ thống cung cấp lối tắt (Shortcut) cho phép nhân viên bấm trực tiếp vào ngày thiếu công để tạo đơn "Bổ sung ngày nghỉ phép".

  • Quy trình này bắt buộc nhân sự phải giải trình và bổ sung đơn ngay khi quay lại làm việc, tránh việc để dồn đến cuối tháng gây khó khăn cho khâu đối soát của Kế toán.

Tình huống 2: Trưởng phòng từ chối đơn (Rejected Flow)

Nếu Trưởng phòng kiểm tra thấy lý do không thỏa đáng hoặc thời điểm đó phòng ban có dự án gấp cần đủ nhân sự, Trưởng phòng sẽ chọn Không duyệt (Reject) kèm theo lý do từ chối.

• Hệ thống xử lý: Đơn chuyển sang trạng thái Không duyệt.

• Quy trình nghiệp vụ thực tế:

  1. Việc trao đổi và giải trình được thực hiện trực tiếp giữa nhân viên và quản lý bên ngoài hệ thống.

  2. Nếu sau khi trao đổi, Trưởng phòng đồng ý cho nghỉ theo phương án khác: Nhân viên bắt buộc phải tạo một đơn mới hoàn toàn. Hệ thống không cho phép sửa trực tiếp trên đơn đã bị bác bỏ nhằm đảm bảo tính toàn vẹn và lưu vết lịch sử (Audit Trail).

  3. Nếu việc giải trình không được chấp thuận: Ngày nghỉ đó sẽ được ghi nhận vào bảng công tổng hợp là Nghỉ không lương (Unpaid Leave).

2.3. Tích hợp dữ liệu giữa phân hệ Chấm công và phần mềm Tính lương

Một điểm phân tích nghiệp vụ sắc bén được chỉ ra trong buổi bảo vệ: Hệ thống này chỉ dừng lại ở phạm vi quản lý Công và Phép, không bao gồm module Tính lương.

Tuy nhiên, nó đóng vai trò là "nguồn dữ liệu sạch" (Input Source). Cuối tháng, sau khi Kế toán rà soát và chốt bảng công, hệ thống sẽ hỗ trợ kết xuất (Export) dữ liệu ngày công thực tế, ngày nghỉ có lương và ngày nghỉ không lương dưới định dạng chuẩn (như file Excel/CSV hoặc đồng bộ qua Webhook/API) để nạp thẳng vào phần mềm Kế toán độc lập.

3. Thiết kế Wireframe & Trải nghiệm người dùng (UI/UX Breakdown)

Dựa trên luồng nghiệp vụ trên, giao diện người dùng được nhóm học viên thiết kế mạch lạc theo từng vai trò cụ thể:

3.1. Giao diện Phân hệ Nhân viên

• Màn hình Bảng chấm công chi tiết:

  • Hiển thị dạng bảng trực quan theo từng ngày trong tháng: Ngày, Thứ, Giờ vào (Check-in), Giờ ra (Check-out), Tổng số giờ làm việc, Trạng thái (Đủ công, Đi muộn, Về sớm, Nghỉ phép).

  • Đối với các ngày thiếu dữ liệu chấm công, hệ thống hiển thị nút Bổ sung đơn.

    

• Form Tạo đơn đăng ký nghỉ phép mới:

  • Tự động hiển thị (Read-only) các trường: Mã nhân viên, Tên nhân viên, Chức vụ.

  • Các trường nhập liệu: Dropdown chọn Người duyệt, Dropdown chọn Loại nghỉ phép, Bộ chọn ngày (Date-picker) từ ngày đến ngày, Ô nhập số ngày nghỉ và Ô văn bản nhập Lý do nghỉ.

    

3.2. Giao diện Phân hệ Trưởng phòng

• Màn hình Quản lý danh sách đơn xin nghỉ phép:

  • Hệ thống chia thành 3 tab trạng thái: Đang đợi, Đã duyệt, Không duyệt.

  • Bảng danh sách hiển thị: Tên nhân sự gửi đơn, Phòng ban, Loại phép, Khoảng thời gian xin nghỉ, Lý do.

  • Tại tab Đang đợi, mỗi dòng đơn đều tích hợp nút thao tác nhanh: Duyệt (màu xanh) và Từ chối (màu đỏ) kèm khung popup nhập ghi chú khi từ chối.

    

3.3. Giao diện Phân hệ Kế toán

• Màn hình Quản trị quỹ ngày phép nhân sự:

  • Danh sách toàn bộ nhân sự trong công ty kèm các thông số: Tổng số ngày phép được nghỉ trong năm theo quy định (thường là 12 ngày), Số ngày phép đã sử dụng, Số ngày phép còn lại.

  • Cho phép Kế toán bấm Sửa để can thiệp điều chỉnh số ngày phép được hưởng khi có sự thay đổi về thâm niên làm việc hoặc chính sách công ty.

    

4. Những bài học "xương máu" khi viết tài liệu SRS từ phản biện của Mentor

Phần giá trị nhất trong buổi báo cáo chính là những nhận xét thẳng thắn, mang tính chuyên môn cao từ giảng viên hướng dẫn. Đây là những lỗi sai mà hầu hết các BA mới bước chân vào nghề đều dễ mắc phải.

4.1. Lỗi sai 1: Gom đặc tả SRS theo Đối tượng (Actor) thay vì theo Chức năng (Function)

• Thực trạng học viên làm: Nhóm gom toàn bộ tài liệu đặc tả thành từng khối lớn theo phân hệ người dùng (Module Nhân viên gom vào một mục, Module Trưởng phòng một mục, Module Kế toán một mục). Hậu quả là tài liệu dài 15-16 trang nhưng rất nông, mô tả lướt qua nhiều màn hình cùng lúc mà không đi sâu vào chi tiết kỹ thuật.

• Quy chuẩn thực tế của ngành: Tài liệu Đặc tả Yêu cầu Phần mềm (Software Requirements Specification - SRS) chuẩn quốc tế (theo khuyến nghị từ tiêu chuẩn IEEE 830 / ISO/IEC/IEEE 29148) bắt buộc phải được bóc tách theo từng chức năng độc lập (Feature-by-Feature).

  Mỗi một chức năng đơn lẻ (ví dụ: Chức năng Đăng nhập, Chức năng Tạo đơn nghỉ phép, Chức năng Duyệt đơn) đều phải có một mục đặc tả riêng biệt bao gồm 5 thành phần bắt buộc:

  1. Mục đích chức năng (Purpose): Tính năng này giải quyết bài toán gì, ai sử dụng?

  2. Luồng sự kiện (Event Flows): Luồng chính (Main Flow), Luồng phụ (Alternative Flow) và Luồng ngoại lệ (Exception Flow).

  3. Đặc tả giao diện (UI Specification): Hình ảnh Wireframe/Mockup tương ứng của duy nhất chức năng đó.

  4. Đặc tả trường thông tin (Field Descriptions): Bảng chi tiết mô tả từng trường (Tên trường, Kiểu dữ liệu String/Int/Date, Độ dài tối đa, Bắt buộc hay không, Giá trị mặc định).

  5. Quy tắc nghiệp vụ & Bắt lỗi (Business Rules & Validations): Ví dụ ngày kết thúc không được nhỏ hơn ngày bắt đầu; không được nộp đơn nếu số ngày phép vượt quá quỹ phép khả dụng.

Nếu bạn đang muốn rèn luyện kỹ năng viết tài liệu chuẩn chỉnh và thực hành các dự án thực tế có mentor phản biện 1:1, hãy tham khảo ngay khóa học IT Business Analyst tại Cole.vn để xây dựng nền tảng vững chắc.

4.2. Lỗi sai 2: Nhầm lẫn giữa Quy trình nghiệp vụ, Danh sách chức năng và Hành động nút bấm

Trong buổi bảo vệ, mentor đã chỉ ra sự lẫn lộn nghiêm trọng trong bảng mô tả của nhóm: nhóm đưa hành động "Bấm nút Đăng ký" vào bảng quy trình nghiệp vụ và coi nó như một bước xử lý.

Để không mắc phải lỗi này, ITBA cần phân định rạch ròi 3 tầng khái niệm:

• Bảng quy trình nghiệp vụ (Business Workflow): Phải được đánh số thứ tự logic (Bước 1, Bước 2, Bước 3) và khớp hoàn toàn với sơ đồ luồng (Flowchart/BPMN).

• Bảng danh sách chức năng (Function List): Cung cấp cái nhìn bao quát (Bird-eye view) cho toàn bộ dự án để Project Manager (PM) và Tech Lead ước lượng khối lượng công việc (Estimation).

• Hành động (User Action): Nút bấm "Đăng ký" hay "Lưu" chỉ là sự kiện kích hoạt (Event Trigger) trên giao diện của một chức năng, tuyệt đối không được gọi là một "chức năng" hay một "bước quy trình".

4.3. Lỗi sai 3: Tư duy thiết kế luồng quy trình bị ngược (Thiếu tính chủ động)

Trong sơ đồ ban đầu của nhóm, quy trình xin nghỉ phép bắt đầu bằng việc: Nhân viên đến công ty chấm công -> Phát hiện thiếu công -> Mới làm đơn xin nghỉ phép.

Mentor đã phân tích điểm bất hợp lý: Quy trình xin nghỉ phép phải xuất phát từ sự chủ động của nhân sự. Không ai đợi đến khi đi làm lại, chấm công bị thiếu rồi mới bắt đầu nghĩ đến việc làm đơn.

Bài học thiết kế: Một hệ thống thông minh phải luôn hỗ trợ 2 điểm kích hoạt (Triggers) song song:

1. Trigger chủ động (Proactive): Menu độc lập "Tạo đơn nghỉ phép" luôn sẵn sàng để nhân sự tạo yêu cầu trước khi kỳ nghỉ diễn ra.

2. Trigger bị động (Reactive): Nút lối tắt trên Bảng công để giải quyết các trường hợp nghỉ việc đột xuất mà chưa kịp lên đơn từ trước.

5. Các câu hỏi thường gặp (FAQ)

1. Tại sao không nên tích hợp tính năng Tính lương vào cùng một phần mềm Chấm công - Nghỉ phép?

Nguyên tắc thiết kế hệ thống hiện đại khuyến nghị phân tách trách nhiệm (Separation of Concerns). Phân hệ Chấm công & Phép thuộc về quản trị vận hành hàng ngày (Time & Attendance), cần giao diện đơn giản, tốc độ phản hồi nhanh cho toàn bộ nhân sự. Trong khi đó, module Tính lương (Payroll) liên quan đến dữ liệu tài chính bảo mật, chính sách thuế, bảo hiểm xã hội và cấu trúc thu nhập phức tạp, chỉ dành riêng cho Kế toán trưởng và Giám đốc Nhân sự. Tách biệt hai hệ thống giúp đảm bảo tính bảo mật và dễ dàng bảo trì, nâng cấp.

2. Sự khác biệt giữa Sơ đồ phân rã chức năng (FDD) và Use Case Diagram là gì?

Sơ đồ phân rã chức năng (Functional Decomposition Diagram - FDD) thể hiện việc chia nhỏ hệ thống từ mục tiêu cấp cao xuống các tính năng con theo cấu trúc hình cây (Top-down Tree), giúp các bên liên quan nắm bắt được phạm vi tổng thể. Trong khi đó, Use Case Diagram thể hiện hành vi tương tác giữa các tác nhân (Actors) cụ thể với từng trường hợp sử dụng trong hệ thống, bao gồm các mối quan hệ mở rộng (<<extend>>) hoặc bao hàm (<<include>>).

3. Trong tài liệu SRS, phần "Quy tắc nghiệp vụ" (Business Rules) viết thế nào cho đúng?

Quy tắc nghiệp vụ cần được viết dưới dạng các mệnh đề điều kiện rõ ràng, có thể kiểm chứng được. Ví dụ:

• BR01: Nhân viên chỉ được nộp đơn nghỉ phép năm khi số ngày xin nghỉ nhỏ hơn hoặc bằng số ngày phép còn lại hiển thị trên hệ thống.

• BR02: Thời gian kết thúc nghỉ phép phải lớn hơn hoặc bằng thời gian bắt đầu nghỉ phép.

• BR03: Đơn xin nghỉ phép từ 3 ngày làm việc trở lên phải được gửi trước ít nhất 48 giờ làm việc.

6. Lời kết

Đồ án tốt nghiệp phân tích phần mềm Chấm công & Đăng ký Nghỉ phép của nhóm học viên K9 là một minh chứng rõ nét cho quá trình trưởng thành của một IT Business Analyst. Những va vấp trong cách bố cục tài liệu SRS, sự nhầm lẫn giữa quy trình và nút bấm, hay tư duy luồng bị ngược là những trải nghiệm quý báu mà bất kỳ BA nào cũng phải trải qua để hoàn thiện kỹ năng.

Một tài liệu phân tích nghiệp vụ giá trị không đo bằng số lượng trang giấy, mà đo bằng tính chặt chẽ của logic, sự thấu hiểu hành vi người dùng thực tế và tính khả thi khi bàn giao cho đội ngũ kỹ thuật. Nắm vững các tiêu chuẩn quốc tế và luôn đặt câu hỏi phản biện đa chiều chính là chìa khóa giúp bạn trở thành một BA chuyên nghiệp được mọi tổ chức săn đón.