企业在使用钉钉、飞书等SaaS平台两年后，审批数据难以沉淀为可二次开发的业务系统，核心原因在于SaaS平台与自建业务系统在设计理念、数据架构和控制层级上的根本差异。这本质上是“轻量协同工具”与“深度业务系统”之间的结构性矛盾。

一、 问题根源：两种系统的本质差异

二、 具体问题场景分析

以一个典型的“出差报销”场景为例，对比两种模式下的数据状态：

-- 场景：员工出差后报销
-- SaaS平台（钉钉/飞书）数据模拟：两张独立的审批单
CREATE TABLE saas_leave_application ( -- 出差申请单
    id INT PRIMARY KEY,
    applicant VARCHAR(255),
    destination VARCHAR(255),
    start_date DATE,
    end_date DATE,
    status VARCHAR(50) -- “已通过”
    -- 缺少与报销单的强关联字段
);

CREATE TABLE saas_expense_report ( -- 费用报销单
    id INT PRIMARY KEY,
    applicant VARCHAR(255),
    total_amount DECIMAL(10,2),
    invoice_attachments TEXT,
    status VARCHAR(50) -- “已支付”
    -- 手动填写或选择出差单号，关联脆弱，无法自动校验
);

注释：SaaS平台的数据表结构是虚拟示意，实际不开放。这里展示其数据孤立的特性。

-- 自建业务系统（如RuoyiOffice）数据模拟：业务关联的数据模型
CREATE TABLE business_trip_application ( -- 出差申请业务单据
    id INT PRIMARY KEY,
    applicant_id INT FOREIGN KEY REFERENCES employee(id),
    project_id INT FOREIGN KEY REFERENCES project(id), -- 关联项目
    destination VARCHAR(255),
    start_date DATE,
    end_date DATE,
    estimated_budget DECIMAL(10,2),
    status VARCHAR(50), -- 状态驱动：申请中、已批准、进行中、已完成、已报销
    CONSTRAINT fk_employee FOREIGN KEY (applicant_id) REFERENCES employee(id)
);

CREATE TABLE expense_reimbursement ( -- 费用报销业务单据
    id INT PRIMARY KEY,
    trip_application_id INT FOREIGN KEY REFERENCES business_trip_application(id), -- 强关联出差单
    reimburser_id INT FOREIGN KEY REFERENCES employee(id),
    actual_amount DECIMAL(10,2),
    financial_entry_id INT, -- 关联财务凭证
    status VARCHAR(50), -- 状态驱动：填报中、审批中、已付款、已归档
    FOREIGN KEY (trip_application_id) REFERENCES business_trip_application(id),
    CHECK (actual_amount <= (SELECT estimated_budget FROM business_trip_application WHERE id = trip_application_id)) -- 自动校验预算
);

注释：自建系统通过外键、状态机和业务规则，使数据形成可追溯、可计算的业务网络。

对比说明：

1. 数据关联性弱：SaaS中，出差与报销是两张独立表单，依赖人工记忆或填写编号关联。自建系统中，它们是主从业务实体，通过外键强制关联，报销自动继承出差信息。
2. 业务规则缺失：SaaS中，预算是否超支依赖审批人肉眼判断。自建系统可通过数据库约束（CHECK）或业务逻辑层自动校验。
3. 状态管理简单：SaaS审批状态通常只有“通过/拒绝”。自建系统的状态是业务生命周期的核心（如“已批准”、“已报销”），可触发后续动作（如自动生成财务凭证）。
4. 数据价值低：SaaS的审批数据导出后多为扁平表格，难以直接进行多维业务分析（如“各部门季度出差报销趋势”）。自建系统的结构化数据易于生成跨模块报表。

三、 为何这阻碍了“可二开的业务系统”？

1. 缺乏核心数据模型：二次开发一个CRM或项目管理模块，需要以“客户”或“项目”为核心构建数据关系网。SaaS平台沉淀的是一堆离散的审批记录，无法直接作为这类系统的数据基础。
2. 无法实现复杂业务逻辑：二次开发常需定制复杂规则，如“特定客户类型的合同审批通过后，自动创建项目并分配资源”。这需要流程引擎与多个业务模型深度交互，SaaS轻量审批引擎无法支持。
3. 扩展受制于平台：即使通过开放平台API获取数据，二次开发的功能、界面、交互也严格受限于平台规范。当企业需要高度定制化的界面或偏离平台主路径的业务流程时，将无从下手。
4. 数据治理困难：数据分散在多个SaaS应用（审批、CRM插件、项目插件）中，标准不一，清洗和整合成本极高，难以形成统一、干净的“数据资产”用于分析或驱动AI。

四、 解决方案与选型建议

正如参考资料所述，更成熟的架构是分层设计，而非替换：

结论：钉钉、飞书等SaaS平台在解决企业“连接”问题上表现出色，但其设计初衷并非成为全功能的业务系统中台。当企业业务复杂度增长，需要将数据转化为可驱动业务、可深度分析的资产时，自建或基于开源框架（如RuoyiOffice）构建的业务平台就成为必然选择。两者关系是互补的“入口”与“主干”关系，通过开放平台集成，既能保留员工习惯的协同体验，又能确保核心业务数据的自主、可控与可演进性。

参考来源

• RuoyiOffice vs 钉钉/飞书/企业微信：办公系统 SaaS平台 vs 自建怎么选
• 六大办公协作平台深度横评：泛微、致远、蓝凌、钉钉、企业微信、飞书如何选型？
• 中小企业如何选择办公协作平台？泛微、致远、蓝凌、钉钉、企业微信、飞书六大平台优缺点全解析
• 企业级AI办公落地实践：基于钉钉/飞书的标准产品解决方案
• 钉钉、企业微信和飞书向“钱”看
• 钉钉、企业微信与飞书：三大企业协作平台的功能对比与选型指南