Hệ thống E-learning tích hợp CRM/ERP

Vấn đề

Doanh nghiệp đào tạo vận hành bằng Excel và tin nhắn: tư vấn viên ghi khách tiềm năng vào một file, kế toán theo dõi học phí ở file khác, giáo vụ xếp lớp ở file thứ ba. Khách muốn “một phần mềm quản lý tất cả” nhưng chưa mô tả được quy trình hiện tại chạy ra sao.

Hệ quảBa chỗ đau khách kể đầu tiên

• Công nợ lệch giữa các phòng.
• Không biết học viên nào sắp hết khoá để tư vấn tiếp.
• Giờ dạy của giáo viên phải đối chiếu tay cuối tháng.

Bối cảnh và vai trò

• Phạm vi: CRM (từ khách tiềm năng đến ghi danh), học viên và lớp học, học phí và công nợ, giáo viên và giờ dạy, báo cáo cho ban giám đốc.
• Bên liên quan: đội kỹ thuật, khách hàng nội bộ, khách hàng outsource, phòng nhân sự, kế toán, kinh doanh.
• Vai trò của tôi: khảo sát, phân tích As-Is và To-Be, viết BRD, PRD, SRS, wireframe, business rules, mô hình dữ liệu, hỗ trợ kiểm thử và UAT.

Ví dụ dưới đây dùng một trung tâm mô phỏng tên “BrightPath”.

Bước 1: Khảo sát As-Is theo từng phòng ban

Tôi phỏng vấn riêng từng phòng, vẽ lại quy trình họ đang chạy thật và tìm chỗ đứt gãy giữa các phòng.

As-IsDữ liệu đứt ở hai chỗ giữa các phòng

1. 1Tư vấn viênkhách từ Facebook, Zalo; ghi Excel
2. 2Ghi danhform giấy
   giảm giá nói miệng, không ai ghi lại
3. 3Kế toánfile học phí
   bảo lưu không báo kế toán
4. 4Giáo vụfile xếp lớp

Bản đồ bên liên quanMỗi phòng cần gì, đang vướng ở đâu

	Họ cần	Đang vướng	Đưa vào thiết kế
Kinh doanh	Theo dõi khách, biết ai sắp hết khoá	Trùng khách, mất khách khi tư vấn viên nghỉ	Pipeline CRM, quyền chuyển khách
Kế toán	Thu đúng, thu đủ, đối chiếu nhanh	Giảm giá nói miệng, không ai ghi lại	Chính sách giá, duyệt giảm giá
Giáo vụ	Xếp lớp, đổi lớp, bảo lưu	Bảo lưu không báo kế toán	Trạng thái ghi danh gắn với công nợ
Giáo viên	Biết lịch, được tính đúng giờ	Tự ghi giờ, tranh cãi cuối tháng	Điểm danh gắn với giờ dạy
Ban giám đốc	Doanh thu, công nợ, tỷ lệ học tiếp	Chờ lâu mới có báo cáo	Báo cáo từ dữ liệu vận hành

Bước 2: Thiết kế To-Be theo vòng đời học viên

Tôi không thiết kế theo phòng ban mà theo vòng đời học viên. Mỗi module là một giai đoạn của vòng đời đó.

To-BeMột vòng đời, một nguồn dữ liệu

1. 1CRMtư vấn, chốt
2. 2Ghi danhhợp đồng
3. 3Học phí và công nợ
4. 4Lớp họcđiểm danh sinh ra giờ dạy

Lớp học → CRM · còn từ 4 buổi trở xuống thì tự về danh sách tư vấn tiếp (BR-06)

Business rulesTrích từ BRD, mỗi quy tắc có phòng chủ quản

	Chủ quản
BR-01 · Giảm giá trên 10% phải được quản lý duyệt trên hệ thống trước khi ghi danh	Kế toán
BR-02 · Học phí tối đa 3 đợt; đợt 1 từ 30% và thu trước buổi học đầu	Kế toán
BR-03 · Bảo lưu tối đa 6 tháng; công nợ đóng băng; tự báo kế toán và tư vấn	Giáo vụ
BR-04 · Hoàn phí chỉ trước buổi 3, tỷ lệ giảm dần, tính trên số tiền sau giảm giá	Ban giám đốc
BR-05 · Giờ dạy tính từ điểm danh, không nhập tay; chênh lệch phải được duyệt	Nhân sự
BR-06 · Học viên còn từ 4 buổi trở xuống tự chuyển sang danh sách tư vấn tiếp	Kinh doanh

Một thao tác, hai dữ liệu

1. 1Giáo viên điểm danh lớpHọc viên có mặtGiờ dạy của giáo viên
2. 2Không cần module chấm công riêng

Bước 3: Mô hình dữ liệu và luồng học phí, công nợ

Tôi thiết kế mô hình dữ liệu cùng đội Dev. Trọng tâm là một nguồn sự thật duy nhất cho công nợ.

Mô hình dữ liệuQuan hệ chính giữa các thực thể

Học phí và công nợ (To-Be)Công nợ luôn bằng tổng hoá đơn trừ tổng thanh toán

1. 1Ghi danhsinh hoá đơn theo đợt
2. ?Thu đủ 30% đợt 1?chưa đủ thì chặn xếp lớp
3. 3Mở xếp lớp
4. 4Nhắc đợt 2 và 3trước 7 ngày
5. 5Quá hạncảnh báo tư vấn và kế toán, gắn cờ học viên

Chuyển dữ liệu cũKhông nhập cột "Còn nợ" từ Excel

1. 1Hoá đơn và thanh toán cũ
2. 2Tính lại công nợ
3. 3Báo cáo chênh lệch
4. 4Kế toán xử lý một lần

Bước 4: Tài liệu bàn giao cho Dev

Một phần đội Dev là outsource nên tài liệu phải tự đứng được.

Bộ tài liệuĐủ để người mới đọc và làm tiếp

• Mục tiêu, phạm vi, bên liên quan, As-Is và To-Be, business rules, tiêu chí thành côngBRD
• Yêu cầu chức năng có mã theo module; phân quyền, log, hiệu năng báo cáoPRD, SRS
• Ma trận vai trò và chức năngPhân quyền
• User story, acceptance criteria, wireframe, sơ đồ kỹ thuậtSprint

US-FEE-04

Ghi nhận thanh toán một phần

Là kế toán, tôi muốn ghi nhận khoản thanh toán ít hơn số tiền hoá đơn để học viên có thể đóng dần mà công nợ vẫn chính xác.

• Cho trước hoá đơn đợt 2 là 3.000.000đ, khi kế toán ghi nhận 1.000.000đ, thì hoá đơn chuyển sang “Thanh toán một phần”, công nợ giảm đúng 1.000.000đ và lịch sử ghi rõ ngày, người thu.
• Cho trước tổng thanh toán bằng hoặc vượt giá trị hoá đơn, khi ghi nhận, thì hoá đơn chuyển “Đã thanh toán” và không cho ghi nhận thêm.
• Cho trước người dùng có vai trò Tư vấn, khi mở màn hình ghi nhận thanh toán, thì chỉ xem được, không có nút ghi nhận.

Module

Học phí và công nợ

Quy tắc

BR-02

Truy vết

1. 1Yêu cầu có mã
2. 2User story
3. 3Test caseTester bám theo mã
4. 4Kết quả UAT

Bước 5: Kiểm thử và UAT theo phòng ban

UAT được tổ chức theo từng phòng. Mỗi phòng chạy đúng kịch bản của mình.

UAT checklistTrích phần của Kế toán

• Ghi danh có giảm giá 15% chưa duyệt thì hệ thống chặn thuBR-01
• Thu đợt 1 mới 25% thì chặn xếp lớpBR-02
• Bảo lưu thì công nợ đóng băng, kế toán nhận thông báoBR-03
• Hoàn phí tính trên số tiền sau giảm giáBR-04
• Báo cáo công nợ tổng khớp với số kế toán tự tính trên mẫu học viên

Trong UAT thường phát sinh trường hợp chưa được thiết kế, ví dụ học viên chuyển cơ sở thì công nợ thuộc cơ sở nào:

Khi UAT lộ ra trường hợp mới

1. 1Trường hợp chưa thiết kếhọc viên chuyển cơ sở
2. 2Ghi thành yêu cầu thay đổi
3. 3Họp nhanh các phòngchốt quy tắc
4. 4Đưa vào sprint kế tiếpkhông sửa vội trong UAT

Kết quả

• Một hệ thống tích hợp CRM và ERP: khách hàng, học phí, công nợ và việc giảng dạy của giáo viên.
• Bộ tài liệu BRD, PRD, SRS, sơ đồ kỹ thuật và mô hình dữ liệu làm nguồn tham chiếu cho đội Dev.
• Các phòng ban dùng chung một nguồn dữ liệu cho công nợ và giờ dạy.

Điều tôi học được

• Khi khách nói “muốn phần mềm quản lý tất cả”, việc của BA là tìm ra vài chỗ đứt gãy thật sự.
• Thiết kế theo vòng đời của đối tượng chính giúp giảm số module và giảm tranh chấp giữa các phòng.
• Với Dev outsource, tài liệu có mã truy vết là bảo hiểm cho dự án.