Quy trình nghiệp vụ

Luồng xuôi (Happy Path)

Đây là luồng lý tưởng khi mọi thứ diễn ra đúng kế hoạch, không phát sinh ngoại lệ:

Sales tìm khách  →  Tạo hợp đồng  →  CO-GO phê duyệt  →  Phân bổ POD
      │                                                         │
      │                                                         ▼
      │                                              POD vận hành dự án
      │                                                         │
      │                                                         ▼
      └─────────────── Khách hàng hài lòng ◄──────── Nghiệm thu & thanh toán

Giai đoạn	Người chịu trách nhiệm	Đầu ra
Tìm kiếm khách hàng	Sales	Lead đủ điều kiện
Tạo hợp đồng	Sales	Hợp đồng nháp trong hệ thống
Phê duyệt hợp đồng	CO-GO	Hợp đồng được duyệt hoặc từ chối
Phân bổ POD	CO-GO	POD được gán, Pod Leader nhận bàn giao
Vận hành dự án	Pod Leader + thành viên POD	Deliverables hoàn thành
Nghiệm thu & thanh toán	Pod Leader + Sales	Khách ký nghiệm thu, thanh toán

Luồng phê duyệt hợp đồng

Ai duyệt?

Mọi hợp đồng đều phải qua CO-GO phê duyệt. Không có ngoại lệ.

Điều kiện để hợp đồng được duyệt

Điều kiện	Mô tả
Thông tin đầy đủ	Tên khách, giá trị, thời hạn, scope dịch vụ
Biên lợi nhuận gộp ≥ mức tối thiểu	Đảm bảo hợp đồng không lỗ từ đầu
Scope rõ ràng	Deliverables được liệt kê cụ thể, tránh mập mờ
Điều khoản thanh toán	Lịch thanh toán, phương thức, điều kiện

Hợp đồng nháp (Draft)
    │
    ▼
Sales nộp duyệt → Trạng thái: PENDING_APPROVAL
    │
    ▼
CO-GO xem xét ──→ Đủ điều kiện? ──→ APPROVED → Khởi tạo dự án
    │
    └──→ Thiếu thông tin? ──→ REJECTED (kèm lý do) → Sales bổ sung

Hợp đồng bị từ chối

Khi CO-GO từ chối, hệ thống bắt buộc nhập lý do. Sales nhận thông báo và có thể chỉnh sửa rồi nộp lại. Lịch sử từ chối được lưu trong audit trail.

Luồng bàn giao dự án

Sau khi hợp đồng được duyệt, hệ thống tự động khởi tạo cấu trúc dự án:

Contract (Hợp đồng)
  └── Project (Dự án)
        ├── Deliverable 1 (Sản phẩm bàn giao)
        │     ├── Task 1.1
        │     ├── Task 1.2
        │     └── Task 1.3
        ├── Deliverable 2
        │     ├── Task 2.1
        │     └── Task 2.2
        └── Deliverable 3
              └── Task 3.1

Cấp	Ai quản lý	Mô tả
Contract	CO-GO + Sales	Thỏa thuận pháp lý với khách hàng
Project	Pod Leader	Đơn vị quản lý vận hành
Deliverable	Pod Leader	Sản phẩm cụ thể bàn giao cho khách
Task	Thành viên POD	Công việc cụ thể để hoàn thành deliverable

Lợi ích của cấu trúc phân tầng

Cấu trúc này cho phép theo dõi tiến độ từ tổng quan (hợp đồng hoàn thành bao nhiêu %) đến chi tiết (task nào đang chậm). Quản lý không cần hỏi — hệ thống tự tổng hợp.

Luồng công việc phát sinh (Non-Billable Request)

Khi khách hàng yêu cầu công việc ngoài scope hợp đồng:

Yêu cầu phát sinh từ khách
        │
        ▼
Pod Leader đánh giá ──→ Trong scope? ──→ Tạo task bình thường
        │
        └──→ Ngoài scope? ──→ Tạo Non-Billable Request
                                      │
                                      ▼
                              CO-GO phê duyệt?
                              ├── Đồng ý → Tạo task (gắn tag non-billable)
                              └── Từ chối → Thông báo Pod Leader → Phản hồi khách

Vì sao cần kiểm soát phát sinh?

Scope creep là nguyên nhân chính khiến COGS tăng lên 71.2%. Mỗi giờ làm việc phát sinh không thu tiền đều ăn vào lợi nhuận POD. Hệ thống ghi nhận và tổng hợp chi phí phát sinh để ban lãnh đạo có cơ sở đàm phán lại hợp đồng hoặc điều chỉnh scope.

Chốt kiểm soát (Gates)

Mỗi giai đoạn chuyển tiếp trong hệ thống đều có gate — điểm kiểm soát bắt buộc:

Gate	Người giữ gate	Điều kiện vượt qua
Hợp đồng → Dự án	CO-GO	Hợp đồng được phê duyệt
Dự án → Vận hành	Pod Leader	Kế hoạch sprint được tạo, nhân sự được gán
Task → Hoàn thành	Pod Leader	Sản phẩm đạt Definition of Done
Deliverable → Nghiệm thu	Pod Leader + Khách hàng	Khách xác nhận chất lượng
Phát sinh → Thực hiện	CO-GO	Yêu cầu non-billable được duyệt
Tài khoản → Kích hoạt	CO-GO	Đăng ký mới được phê duyệt

Không thể bỏ qua gate

Hệ thống không cho phép chuyển trạng thái nếu chưa vượt qua gate tương ứng. Đây là cơ chế cốt lõi để đảm bảo quy trình được tuân thủ nghiêm ngặt.

Luồng hỗ trợ nội bộ (Support Tickets)

Khi thành viên POD cần hỗ trợ từ bộ phận chức năng (IT, kế toán, hành chính):

Thành viên POD tạo ticket
        │
        ▼
Phân loại tự động (IT / Kế toán / Hành chính)
        │
        ▼
Người phụ trách nhận ticket → Xử lý → Phản hồi
        │
        ▼
Người tạo xác nhận hoàn thành → Đóng ticket

Ticket có SLA (thời gian cam kết xử lý) tùy mức độ ưu tiên:

Mức ưu tiên	Thời gian phản hồi	Thời gian xử lý
Khẩn cấp	1 giờ	4 giờ
Cao	4 giờ	1 ngày làm việc
Trung bình	8 giờ	3 ngày làm việc
Thấp	24 giờ	5 ngày làm việc

Luồng đăng ký tài khoản

Nhân viên mới hoặc cộng tác viên cần tài khoản để truy cập hệ thống:

Người dùng đăng ký (Sign-up)
        │
        ▼
Trạng thái: PENDING (chờ duyệt)
        │
        ▼
CO-GO xem xét thông tin
  ├── APPROVED → Tài khoản được kích hoạt, gán vai trò + POD
  └── REJECTED → Thông báo lý do từ chối

Quản lý tài khoản tập trung

CO-GO kiểm soát hoàn toàn ai được vào hệ thống và với quyền gì. Khi nhân viên nghỉ việc, tài khoản bị vô hiệu hóa ngay lập tức — không cần xóa, dữ liệu lịch sử vẫn được bảo toàn.