企业案件台账系统的数据模型设计：从 Excel 到可查询看板

背景

很多企业最早管理案件信息时，都会从 Excel 开始：一张表记录案件名称、案号、主体、阶段、金额、负责人和下一步动作。这个方式上手快，但当数据量、参与角色和汇报频率增加后，表格会逐渐暴露几个问题：

• 字段口径不统一，同一类信息可能有多种写法；
• 关键节点依赖人工提醒，缺少稳定的状态流转；
• 材料、费用、进展记录和主表脱节；
• 总部、子公司、外部协作方的可见范围不同；
• 管理层需要看趋势和分布时，仍要人工汇总。

如果把这类场景抽象成一个企业案件台账系统，核心不是"把 Excel 搬到网页上"，而是把案件、主体、节点、材料、费用、协作和看板拆成可维护的数据对象。

一、核心实体

一个最小可用的案件台账系统，至少需要以下实体。

实体	说明
case_record	案件主表，保存案件名称、编号、类型、阶段、金额、责任主体等核心字段
party	当事方或相关主体，可关联企业主体、子公司、个人或外部机构
milestone	关键节点，例如立案、开庭、举证、执行、结案等
progress_log	进展记录，用于保存每次跟进动作和下一步计划
document	材料归档，记录文件类型、上传人、关联案件和权限范围
expense	费用记录，关联案件维度的律师费、诉讼费、差旅费等支出
collaborator	协作方，包括内部法务、业务部门、外部律师或其他服务方
risk_event	风险事件，用于保存外部数据源或人工登记的风险线索

这里最容易踩坑的是把所有字段都塞进案件主表。短期看开发简单，长期会导致表结构膨胀、查询困难、权限难拆。更稳妥的方式是：案件主表只放稳定的主数据，节点、进展、材料、费用等高频变化对象单独建表。

二、案件主表字段设计

案件主表建议控制在"用于识别、筛选、统计"的字段范围内。

case_record
- id
- case_name
- case_no
- case_type
- dispute_type
- status
- stage
- amount
- currency
- owner_org_id
- responsible_user_id
- external_owner_id
- opened_at
- closed_at
- next_action
- next_action_due_at
- created_at
- updated_at

几个设计建议：

1. status 和 stage 分开。status 表示在办、暂停、结案、归档等管理状态；stage 表示业务阶段。
2. owner_org_id 不要只存文本。集团、多子公司、多区域场景下，组织维度必须结构化。
3. next_action_due_at 单独保存，方便做待办提醒和逾期查询。
4. 金额字段要保存币种，避免后续做汇总时口径混乱。

三、状态机不要过度复杂

很多系统上线失败，不是因为功能少，而是状态设计太复杂。案件台账可以先用一个轻量状态机：

draft -> active -> pending_close -> closed -> archived

再通过 stage 表示更细的业务阶段，例如：

pre_filing / filing / trial / second_instance / enforcement / settlement / closed

这样做的好处是，管理状态服务于系统操作，业务阶段服务于统计分析，两者不会互相污染。

四、权限模型建议采用 RBAC + 数据范围

企业案件管理通常不适合只做简单的"管理员 / 普通用户"权限。更合理的是角色权限加数据范围。

角色	典型权限
总部法务管理员	查看全集团案件、配置字段、查看统计看板
子公司法务	查看本组织及授权案件，更新进展和材料
业务部门用户	查看与本部门相关的案件摘要和待办
外部协作方	只查看被授权案件的指定字段、材料和节点
财务用户	查看费用相关字段和付款状态

数据范围可以按组织、案件、字段、材料四层控制。尤其是外部协作方，不建议默认开放完整案件信息，而应按案件授权、按材料授权、按字段授权。

五、节点和提醒设计

节点表不宜只保存一个日期字段。实际业务中，一个节点通常包含名称、类型、计划时间、实际完成时间、负责人、提醒规则和完成状态。

milestone
- id
- case_id
- milestone_type
- title
- planned_at
- completed_at
- owner_user_id
- reminder_rule
- status

看板查询常用的几个指标包括：

• 未来 7 天待处理节点；
• 已逾期未完成节点；
• 按负责人分布的待办数量；
• 按案件阶段统计的节点完成率。

这些指标如果一开始就按结构化节点保存，后期做消息提醒、日历同步和管理看板会容易很多。

六、费用与案件关联

费用表建议独立于案件主表，按明细保存。

expense
- id
- case_id
- expense_type
- amount
- currency
- vendor_id
- invoice_status
- payment_status
- occurred_at
- approved_at

这样可以支持：

• 单案成本统计；
• 按供应商统计费用；
• 按组织或地区统计支出；
• 费用预算和实际支出的差异分析；
• 结案复盘时查看投入产出。

如果费用只写在备注里，后续几乎无法做可靠统计。

七、看板指标

企业案件台账系统的看板不需要一开始就很复杂，可以先做 6 类指标：

指标	查询目的
在办案件数量	了解当前工作负载
阶段分布	看案件集中在哪些阶段
金额分布	识别高金额案件
逾期节点	发现流程风险
费用支出	统计单案和整体成本
结案结果	支持复盘和管理汇报

技术实现上，早期可以通过关系型数据库聚合查询完成；当数据量增大或报表复杂后，再考虑宽表、ETL 或 BI 工具。

八、从 Excel 迁移的顺序

建议不要一次性迁移所有历史数据。更稳的顺序是：

1. 先统一字段字典，包括案件类型、阶段、组织、责任人和费用类型；
2. 只迁移在办案件和重点案件；
3. 对历史案件只保留必要摘要；
4. 上线后要求新节点、新材料、新费用都在系统内产生；
5. 运行一个月后再补充报表和自动提醒。

这样可以避免一开始陷入历史数据清洗，先让系统承担当前业务流转。

小结

企业案件台账系统的关键，不是页面做得多复杂，而是数据对象拆得是否清楚、状态流转是否稳定、权限边界是否可控、看板指标是否能直接从结构化数据中生成。

对于已经有一定案件量、协作角色较多、需要统一看板的企业，可以参考上述模型逐步建设。律杏法务云这类企业法务管理系统，本质上也是围绕案件主数据、节点、材料、费用、协作和看板这些对象进行产品化封装。自研或采购时，都可以先用这套模型检查需求是否完整。

本文只讨论企业管理系统的数据模型和流程设计，不构成具体法律意见。具体字段、流程和权限配置，应结合企业组织结构、数据合规要求和实际业务场景确定。