集成 CRM/ERP 的 E-learning 系统

问题

这家培训机构靠 Excel 和聊天消息运营：课程顾问把潜在客户记在一个文件里，财务在另一个文件里跟踪学费，教务在第三个文件里排班。客户想要“一套什么都能管的软件”，却说不清现有流程到底是怎么运转的。

后果客户最先提到的三个痛点

• 各部门的应收款对不上。
• 不知道哪些学员课程即将结束、需要继续跟进。
• 教师课时要到月底手工核对。

背景与角色

• 范围：CRM（从潜在客户到报名）、学员与班级、学费与应收款、教师与课时、面向管理层的报表。
• 干系人：技术团队、内部客户、外包客户、人事部、财务部、销售部。
• 我的角色：调研，As-Is 与 To-Be 分析，编写 BRD、PRD、SRS，线框图、业务规则、数据模型，支持测试与 UAT。

下面的示例使用一家名为“BrightPath”的模拟培训中心。

第 1 步：按部门调研 As-Is

我分别访谈每个部门，还原他们实际在跑的流程，找出部门之间的断点。

As-Is数据在部门之间断了两处

1. 1课程顾问客户来自 Facebook、Zalo；记录在 Excel
2. 2报名纸质表单
   口头承诺折扣，没人记录
3. 3财务学费文件
   休学保留不通知财务
4. 4教务排班文件

干系人地图每个部门需要什么、卡在哪里

	需要什么	当前问题	对设计的影响
销售	跟踪潜在客户，知道谁的课程即将结束	客户重复录入；课程顾问离职时客户流失	CRM pipeline、客户转交权限
财务	收得对、收得齐、对账快	口头承诺折扣，没人记录	价格政策、折扣审批
教务	排班、转班、休学保留	办理休学保留时不通知财务	报名状态与应收款挂钩
教师	知道课表，课时计算准确	自己登记课时，月底起争议	考勤与课时挂钩
管理层	营收、应收款、续读率	报表要等很久	报表直接来自运营数据

第 2 步：按学员生命周期设计 To-Be

我没有按部门来设计，而是按学员生命周期来设计。每个模块对应生命周期中的一个阶段。

To-Be一个生命周期，一个数据来源

1. 1CRM咨询、成交
2. 2报名合同
3. 3学费与应收款
4. 4班级考勤生成课时

班级 → CRM · 剩余课次不超过 4 次时，自动回到待继续跟进的名单（BR-06）

业务规则BRD 节选，每条规则都有归口部门

	归口部门
BR-01 · 折扣超过 10% 时，必须在报名前由主管在系统中审批	财务
BR-02 · 学费最多分 3 期；第 1 期不低于 30%，且须在第一次课之前收取	财务
BR-03 · 休学保留最长 6 个月；应收款冻结；自动通知财务和课程顾问	教务
BR-04 · 退费仅适用于第 3 次课之前，比例递减，按折后金额计算	管理层
BR-05 · 课时根据考勤计算，不手工录入；如有差异须经审批	人事
BR-06 · 剩余课次不超过 4 次的学员，自动进入待继续跟进的名单	销售

一次操作，两份数据

1. 1教师进行班级考勤学员到课教师课时
2. 2无需单独的工时模块

第 3 步：数据模型与学费、应收款流程

我与开发团队共同设计数据模型。重点是让应收款只有唯一的可信数据来源。

数据模型实体之间的主要关系

学费与应收款（To-Be）应收款始终等于账单总额减去付款总额

1. 1报名按期生成账单
2. ?第 1 期收足 30%？未收足则禁止排班
3. 3开放排班
4. 4提醒第 2 期和第 3 期提前 7 天
5. 5逾期提醒课程顾问和财务，对学员做标记

旧数据迁移不导入 Excel 中的“欠费”列

1. 1旧账单和付款
2. 2重新计算应收款
3. 3差异报告
4. 4财务一次性处理

第 4 步：交付开发的文档

开发团队有一部分是外包，所以文档必须自成一体。

整套文档新人读完就能接着做

• 目标、范围、干系人、As-Is 与 To-Be、业务规则、成功标准BRD
• 按模块编号的功能需求；权限、日志、报表性能PRD, SRS
• 角色与功能矩阵权限
• 用户故事、验收标准、线框图、技术设计图Sprint

US-FEE-04

登记部分付款

作为财务人员，我希望登记少于账单金额的付款，以便学员可以分次缴费，同时应收款保持准确。

• 假设 第 2 期账单为 3,000,000 越南盾，当 财务登记 1,000,000 越南盾时，则 账单变为“部分付款”，应收款恰好减少 1,000,000 越南盾，历史记录注明日期和收款人。
• 假设 付款总额等于或超过账单金额，当 登记付款时，则 账单变为“已付款”，且不允许继续登记。
• 假设 用户角色为课程顾问，当 打开付款登记界面时，则 只能查看，没有登记按钮。

模块

学费与应收款

规则

BR-02

追溯

1. 1带编号的需求
2. 2用户故事
3. 3测试用例测试人员按编号编写
4. 4UAT 结果

第 5 步：按部门测试与 UAT

UAT 按部门组织。每个部门执行自己的场景。

UAT 清单财务部分节选

• 报名时有 15% 折扣但未审批，系统禁止收款BR-01
• 第 1 期只收了 25%，禁止排班BR-02
• 学员办理休学保留后，应收款冻结，财务收到通知BR-03
• 退费按折后金额计算BR-04
• 应收款汇总报表与财务在学员样本上自行计算的数字一致

UAT 中常会出现设计时没有覆盖的场景，例如学员转校区后应收款归属哪个校区：

当 UAT 暴露出新场景

1. 1尚未设计的场景学员转校区
2. 2记录为变更请求
3. 3与各部门开短会确定规则
4. 4放入下一个 Sprint不在 UAT 期间仓促修改

结果

• 一套集成 CRM 与 ERP 的系统：管理客户、学费、应收款和教师授课。
• 由 BRD、PRD、SRS、技术设计图和数据模型组成的整套文档，作为开发团队的参考依据。
• 各部门在应收款和课时上共用同一数据来源。

我学到的

• 当客户说“想要一套什么都能管的软件”时，BA 的工作是找出那几个真正的断点。
• 按核心对象的生命周期来设计，可以减少模块数量，也减少部门之间的争执。
• 面对外包开发，带追溯编号的文档就是项目的保险。