任职计划解耦改造

---

一、项目背景

1.1 模型说明

任职计划（Position Plan）

• 由上游业务系统根据注册单生成
• 表达“某员工在某时间区间内的岗位任职安排”
• 是一条时间区间型数据
• 包含岗位、组织、任职类型、reasonCode 等信息
• 仅描述“计划发生什么”

任职（Position Instance）

• 由主数据基于任职计划进行计算生成
• 表达“某一时刻真实生效的任职状态”
• 是当前有效态数据
• 是组织结构推导与下游消费的基础

当前链路为：

业务系统
→ 生成任职计划
→ 推送至主数据
→ 主数据定时任务进行编排与生效
→ 生成任职结果

---

1.2 当前系统现状

当前系统存在：

• 上游 7 个业务系统
• 80+ reasonCode
• 每日约 10 起数据订正
• 多业务语义冲突无人统一解释

表现为：

• 业务系统承担了部分主数据职责
• 语义边界模糊
• 规则分散
• 数据订正成本高

---

1.3 本次解耦的目标

目标是：

让主数据成为任职语义与时间线编排的唯一中心。

对业务系统的价值：

• 不再承担主数据职责
• 不需要维护复杂任职规则
• 不需要理解时间线编排逻辑
• 可以专注自身业务流程
• 有机会梳理并优化自身历史代码

对主数据系统的价值：

• 统一任职语义
• 重构编排策略
• 优化时间线引擎
• 优化结构推导逻辑
• 降低长期维护成本

---

二、整体拆分模型

整体拆分为：

1️⃣ 生成侧（语义拆解）
2️⃣ 编排侧

编排侧进一步拆分为：

• 时间线引擎
• 结构推导引擎

---

三、生成侧难点

3.1 业务理解成本高

由于核心人事与主数据职责已分离：

需要逐一分析 7 个业务系统：

• 入职
• 离职
• 异动
• 晋升
• 派遣等场景

从注册单开始：

• 追溯完整业务链路
• 分析字段来源
• 明确字段语义
• 理清最终如何生成任职计划

现实复杂度：

往往需要一天时间才能完全理解一个业务的生成逻辑。

---

3.2 深入注册单的原因（简述）

• 明确语义边界
• 判断职责归属
• 设计准入规则
• 为后续一致性校验打基础

这是生成侧复杂度的主要来源。

---

四、编排侧难度

编排侧分为两部分。

---

4.1 时间线引擎

负责：

• 时间区间开闭合计算
• 任职冲突裁决
• 历史插入模拟
• 撤销反向推演
• 冲突矩阵配置化

历史插入

• 从插入点开始
• 重算后续任职计划
• 重新判断合法性
• 可能触发衍生更新

撤销

• 评估影响范围
• 判断未来任职合法性
• 触发提醒或人工干预

本质是：

时间轴连续一致性维护问题。

---

4.2 结构推导引擎

在任职生效后：

• 多岗位模型处理
• 主岗识别
• 多汇报线比例计算
• 主岗汇报链重建
• 组织关系生成

本质是：

基于时间结果构建动态组织图结构。

---

五、组织级难度

实际推进难度高于技术实现难度。

现实情况：

• 一个系统的生成改造需要约半个月
• 包含开发、联调、测试
• 主数据需要协调配合

如果多个系统改造不同步：

• 测试成本增加
• 风险放大
• 逻辑不一致

该项目属于：

主数据驱动的跨系统技术改造工程。

---

六、复杂度整体判断

该项目包含：

• 跨系统语义治理
• 时间轴编排引擎设计
• 动态图结构重建
• 多团队协同改造

属于企业级主数据治理项目。