Skill: wuritu/hr-archsystem (version 1.0.0)

--- name: hr-archsystem description: > HR组织架构与职级体系设计系统。触发场景包括： （1）组织架构设计——设计或调整公司/部门架构、部门划分、汇报关系、决策流； （2）职级体系设计——建立职级序列、职级数量、晋升通道、双通道模型； （3）胜任力模型词典——为岗位序列构建胜任力维度表、行为分级标尺； （4）职级评价（任职资格评定）——用胜任力词典评定具体人的职级。 同时处理：AI时代下这些系统的重构与迭代。 --- # HR ArchSystem — 组织架构·职级体系·胜任力模型·职级评价 ## 设计理念 组织架构、职级体系、胜任力模型、职级评价是四个相互咬合的模块，组成一个完整的人力资源基础设施系统： ``` 组织架构设计 ↓ 产出：部门划分 + 职类序列 职级体系设计 ↓ 产出：职级序列表 + 晋升通道 胜任力词典 ↓ 产出：能力维度 × 分级标尺 职级评价 ↓ 产出：评价结果 + 职级建议 ``` 四个模块必须保持内部一致性。改变任何一个，其他三个都需要重新检视。 --- ## 核心方法论来源 | 方法论 | 适用模块 | 核心贡献 | |--------|---------|---------| | McKinsey 7S | 组织架构 | 组织内部七要素对齐诊断 | | Korn Ferry Hay Method | 职级评价 | Know-How / Problem Solving / Accountability 三因子计分 | | AIHR T-Shaped Model | 胜任力词典 | HR专业能力深度 + 业务理解广度 | | WTW AI-Enhanced Leveling | 职级体系 | AI辅助的动态职级框架 | --- ## 模块导航 ### 1. 组织架构设计 → `references/org-design.md` - McKinsey 7S 七要素诊断 - 部门划分原则（复杂度系数） - AI时代人机协同架构新增考量 - 职类序列定义（管理/专业/技术/技能四大序列） ### 2. 职级体系设计 → `references/job-level.md` - 职级序列表（典型 L1-L9 结构） - 双通道模型（管理序列 + 专业序列） - 宽带薪酬映射 - 晋升校准机制 - AI渗透率差异对职级的影响 ### 3. 胜任力词典 → `references/competency-dictionary.md` - 胜任力建模流程（BEI访谈 + 编码） - 能力维度定义模板 - 分级标尺（每项能力4-5级描述） - AI协同能力分级（Level 1-5） - 按职类序列的差异化能力要求 ### 4. 职级评价 → `references/job-evaluation.md` - 评价流程（准备 → 证据收集 → 评分 → 校准 → 输出） - Korn Ferry Hay 三因子评分卡 - 证据收集模板（行为证据 / 项目证据 / AI效能证据） - 校准会机制 - 评价结果输出格式 --- ## 通用流程顺序 对于完整的体系建设，按以下顺序使用各模块： ``` Step 1: org-design → 产出《架构说明书》 Step 2: job-level → 产出《职级序列表》 Step 3: competency → 产出《胜任力词典》 Step 4: evaluation → 产出《个人评价报告》 ``` --- ## 关键原则 1. **架构决定层级** — 先有架构和职类序列，才能设计职级 2. **能力锚定职级** — 职级本质是对能力深度的计量 3. **评价依赖词典** — 没有词典就不要做评价 4. **AI能力分层** — 每一级胜任力都内置AI协同能力等级，不做附录 5. **保持动态** — 这些系统都是活的，每半年至少review一次 --- ## 启动方式 当用户提供以下类型信息时，识别其需求并导航到对应模块： | 用户输入信号 | 触发模块 | |------------|---------| | "我们公司要重新设计组织架构" | org-design | | "怎么建立职级体系" / "双通道怎么设计" | job-level | | "需要一套胜任力模型" / "能力词典怎么做" | competency-dictionary | | "怎么评定某人的职级" / "任职资格怎么写" | job-evaluation | | "AI时代这些体系怎么调整" | 所有模块（带AI视角）| | "我要建整套HR体系" | 完整流程（所有模块）|

path: references/competency-dictionary.md
content: # 胜任力模型词典

## 输入与输出

**前置依赖：** job-level 产出的职级序列表
**输入：** 职类序列、关键岗位清单、高绩效员工样本（BEI访谈）
**输出：** 《胜任力词典》——能力维度表 × 分级标尺，供 job-evaluation 使用

---

## Step 1：胜任力建模整体流程

```
Step 1: 选取样本岗位（每个序列选2-3个代表性岗位）
Step 2: BEI访谈高绩效员工（每个岗位至少3人）
Step 3: 能力编码（从访谈文本中提取行为指标）
Step 4: 能力维度整合（归类合并，删除重叠）
Step 5: 定义分级标尺（每项能力4-5级描述）
Step 6: AI协同能力等级内置（每级都要有）
Step 7: 验证词典（与现有高绩效员工匹配测试）
```

---

## Step 2：能力维度选择框架

### 2.1 通用能力（所有序列、所有职级）

| 能力维度 | 定义 | 为什么必要 |
|---------|------|---------|
| 批判性思维 | 基于证据进行逻辑推理，识别假设和偏见 | AI时代信息过载，判断力比记忆更重要 |
| 持续学习 | 主动获取新知识并转化为行动 | AI加速知识更新，半衰期缩短 |
| 人际协作 | 与他人有效合作，包括跨层级跨部门 | 组织的基础设施 |
| 沟通表达 | 清晰传递信息，并根据受众调整 | 专业价值的放大器 |
| 问题解决 | 定义问题、分析根因、设计并执行解决方案 | 专业序列的核心交付 |
| 结果导向 | 设定目标、持续追踪、交付可衡量成果 | 组织存在的理由 |
| 适应韧性 | 在不确定性中保持效能，快速调整 | VUCA时代的生存能力 |

### 2.2 按序列的差异化能力

| M管理序列额外要求 | P专业序列额外要求 | T技术序列额外要求 |
|-----------------|-----------------|-----------------|
| 团队领导 | 专业深度 | 技术敏锐度 |
| 战略规划 | 创新贡献 | 细节精确 |
| 决策担当 | 知识传播 | 系统思维 |
| 资源调配 | 跨团队影响 | 工具效率 |

### 2.3 AI时代新增能力（所有序列都要）

| AI相关能力 | 定义 | Level 1-5 简述 |
|-----------|------|------------|
| AI工具应用 | 选择、配置、使用AI工具提升效能 | L1:基础→L5:系统集成 |
| 人机协作判断 | 知道什么时候用AI，什么时候不用 | L1:被动→L5:战略配置 |
| AI输出评估 | 批判性审视AI生成内容的准确性和适用性 | L1:信任→L5:审计优化 |
| AI伦理意识 | 理解AI的偏见局限和合规要求 | L1:了解→L5:风控把关 |

---

## Step 3：BEI访谈方法

### 3.1 访谈框架

BEI（Behavioral Event Interview）基于"STAR"原则：

```
S - Situation（情境）: 当时是什么情况？
T - Task（任务）: 你面临的任务/挑战是什么？
A - Action（行动）: 你具体做了什么？为什么？
R - Result（结果）: 结果如何？你学到了什么？
```

### 3.2 访谈问题示例（高绩效样本）

```
针对"问题解决"能力的访谈问题：
1. 给我讲一个你遇到过的最复杂的问题，当时你怎么处理的？
2. 什么时候你需要在信息不完整的情况下做决策？你怎么做？
3. 讲一个你最初解决方案失败但最终成功的例子。
4. 你用什么方法确保你解决了问题的根本原因而不是表面症状？

针对"AI协作"的补充问题：
5. 你目前使用哪些AI工具？你如何判断什么任务适合用AI？
6. 举一个你发现AI输出有问题的例子，你是怎么处理的？
7. 你的工作中哪些部分你觉得AI永远无法替代？
```

### 3.3 每岗位建议样本量

```
最少：3人（高绩效）+ 1人（中等绩效，用于对比）
最佳：5人（高绩效）+ 2人（中等绩效）
```

---

## Step 4：能力编码与整合

### 4.1 编码流程

从访谈文本中提取"行为片段"，每个片段标注：
- 对应的能力维度
- 该行为的复杂度/影响范围
- 出现频率

### 4.2 能力整合原则

```
合并条件：
- 两个能力在>60%的访谈中表现相同行为 → 合并
- 两个能力在>80%的岗位上都要求 → 保留更通用的

删除条件：
- 只有<20%的访谈样本提到该能力 → 删除或降为次要能力
- 该能力无法用行为区分高绩效和中等绩效 → 删除
```

### 4.3 典型岗位的能力数量控制

```
建议数量：
- 每个岗位 6-10 项能力（含3-5项通用 + 3-5项专业）
- 能力过多 → 评价时权重分散，失去焦点
- 能力过少 → 无法区分不同岗位的差异
```

---

## Step 5：分级标尺设计

### 5.1 分级原则

每项能力的分级描述必须满足：
1. **行为锚点** — 有具体可见的行为描述，不是程度词
2. **递进清晰** — 级别之间的差异是质变，不是量变
3. **可观察** — 他人能识别和评估该行为
4. **AI感知** — 每级都要标注AI协同行为（新增要求）

### 5.2 分级模板

```
能力名称：[能力维度名称]
能力定义：[一句话定义]

Level 1 - 基础
  行为描述：
  AI协同表现：

Level 2 - 发展
  行为描述：
  AI协同表现：

Level 3 - 熟练
  行为描述：
  AI协同表现：

Level 4 - 精通
  行为描述：
  AI协同表现：

Level 5 - 卓越
  行为描述：
  AI协同表现：
```

### 5.3 完整示例："问题解决"能力

```
能力名称：问题解决
能力定义：通过系统性地定义、分析和解决问题，交付可衡量成果的能力。

Level 1 - 基础
  行为描述：识别明确的、重复出现的问题；在指导下执行已知解决方案；
            将无法解决的问题上报给相关人员。
  AI协同表现：使用AI工具（如ChatGPT）查询常见问题的标准答案；
              对AI给出的建议进行基础验证。

Level 2 - 发展
  行为描述：独立分析问题的多个可能原因；提出2-3个可行方案并做简要对比；
            在标准流程内优化解决方案。
  AI协同表现：能够编写有效Prompt获取问题分析框架；
              用AI辅助收集数据，但自己判断哪些数据相关。

Level 3 - 熟练
  行为描述：定义复杂、非结构化问题，主动收集信息；设计并执行新解决方案；
            评估方案效果并迭代；影响他人认同问题优先级。
  AI协同表现：使用AI做根因分析，并能识别AI分析中的逻辑漏洞；
              训练或微调过领域专用AI工具。

Level 4 - 精通
  行为描述：解决跨部门、跨系统的复杂问题；建立问题解决的方法论和工具；
            推动组织层面的流程改进；预防未来类似问题的发生。
  AI协同表现：设计人机协作的问题解决流程，明确AI和人的分工边界；
              建立团队AI工具使用规范并推广。

Level 5 - 卓越
  行为描述：解决没有先例的战略性难题；创造新的问题解决范式；
            在行业内分享方法论；培养他人的问题解决能力的系统性方法。
  AI协同表现：主导AI问题解决系统的设计（如专家系统、知识库）；
              对AI问题解决能力进行伦理和安全审查。
```

---

## Step 6：词典产出格式

### 完整词典结构

```markdown
# [公司名] 胜任力词典 v[X.X]

## 1. 通用能力（所有序列）
### 1.1 批判性思维 [...]
### 1.2 持续学习 [...]
### 1.3 人际协作 [...]
[... 完整7项通用能力 + 完整分级标尺 ...]

## 2. 管理序列（M）专业能力
### 2.1 团队领导 [...]
### 2.2 战略规划 [...]

## 3. 专业序列（P）专业能力
### 3.1 专业深度 [...]
### 3.2 创新贡献 [...]

## 4. 技术序列（T）专业能力
### 4.1 技术敏锐度 [...]
### 4.2 细节精确 [...]

## 5. AI协同能力（所有序列）
### 5.1 AI工具应用 [...]
### 5.2 人机协作判断 [...]
### 5.3 AI输出评估 [...]
### 5.4 AI伦理意识 [...]

## 6. 各序列各职级能力要求矩阵
| 能力 | M1 | M2 | M3 | P1 | P2 | P3 | ...
|------|----|----|----|----|----|----|---
| 批判性思维 | 2 | 3 | 4 | 1 | 2 | 3 | ...
| 问题解决 | 3 | 3 | 4 | 2 | 3 | 4 | ...
| AI工具应用 | 2 | 3 | 3 | 2 | 3 | 4 | ...
（数字表示该级别要求达到的Level）
```

---

## Step 7：词典维护机制

```
更新触发条件：
- 每半年一次例行review
- 业务战略重大调整
- AI工具重大变化（出现新一代工具）
- 评价数据发现能力要求与实际脱节

更新流程：
评估新版词典 → 校准会审议 → 更新词典版本号 → 通知使用者
```

---

## 触发条件

当用户提供以下内容时，触发本模块：
- "需要建一套能力模型/胜任力模型"
- "帮我定义某岗位的能力要求"
- "能力词典怎么建/更新"
- "如何衡量一个人的能力水平"
- 接收到 job-level 的产出后，需要下一步能力建模时


path: references/job-evaluation.md
content: # 职级评价（任职资格评定）

## 输入与输出

**前置依赖：** competency-dictionary 产出的胜任力词典
**输入：** 被评价人信息、目标职级、行为证据、词典
**输出：** 《个人评价报告》——三因子评分、职级建议、能力差距分析

> **前置检查：** 没有胜任力词典就不做评价。评价必须基于明确的能力标准，否则是无效评价。

---

## Step 1：评价前准备

### 1.1 确认被评价人的基础信息

```
□ 姓名：___________   □ 岗位：___________   □ 当前职级：___________
□ 目标职级：_________ □ 在现职级年限：_____ □ 评价类型：晋升/年审/转岗/初评
□ 所属序列：M / P / T / S（如有AI序列：AI-P / AI-M）
```

### 1.2 确认评价依据的词典版本

```
□ 词典版本号：____________（评价前必须锁定版本，避免标准漂移）
□ 该版本词典日期：____________
□ 如词典有更新，是否追溯使用新版：□ 是 / □ 否（提前决定）
```

---

## Step 2：证据收集

### 2.1 证据类型与来源

| 证据类型 | 来源 | 权重 |
|---------|------|------|
| **行为证据** | BEI访谈、360反馈、项目文档 | 最高（直接行为）|
| **成果证据** | 绩效数据、项目产出、OKR完成情况 | 高（可衡量）|
| **AI效能证据** | AI工具使用日志、项目中AI贡献比例 | 中（AI时代新增）|
| **他人评价** | 直属上级、同事、下游协作方 | 参考 |
| **自我评估** | 被评价人自述 | 参考 |

### 2.2 证据收集模板

对词典中的每一项能力，收集以下证据：

```
能力：[从词典中选择一项能力]
需要达到的Level：[根据目标职级确定]

证据记录表：
┌─────────────────────────────────────────────────────────┐
│ 证据1                                                      │
│ 情境（S）：                                            │
│ 任务（T）：                                            │
│ 行动（A）：                                            │
│ 结果（R）：                                            │
│ 证据类型：□ 行为 / □ 成果 / □ AI效能 / □ 他人评价       │
│ 置信度：□ 高 / □ 中 / □ 低（是否有文档支撑）            │
├─────────────────────────────────────────────────────────┤
│ 证据2 ...                                               │
│ ...                                                      │
└─────────────────────────────────────────────────────────┘
```

### 2.3 AI效能证据的特殊收集方式

AI协同能力是新增维度，需要特别记录：

```
AI效能证据模板：
□ 使用了哪些AI工具（列出工具名）
□ 在该任务中，AI完成了多少比例的工作（估计：__%）
□ 人类在该任务中的不可替代贡献是什么
□ 是否存在AI误用/过度依赖的情况
□ AI输出的质量由谁把关、如何验证

注意：AI效能证据不用于"证明人不如AI"，而是用于
"评估人在人机协作中的判断力和把关能力"
```

---

## Step 3：Korn Ferry Hay 三因子评分

> 三因子是全球最广泛使用的岗位评价方法。这里将其改造用于**人的评价**（而非岗位评价）。

### 3.1 三因子定义（人的维度）

| 因子 | 人的维度含义 | 对应词典能力 |
|------|------------|------------|
| **Know-How** | 知识、技能、经验的综合水平 | 批判性思维 + 持续学习 + 对应专业能力 |
| **Problem Solving** | 在不确定环境中思考和决策的深度 | 问题解决 + 适应韧性 + AI输出评估 |
| **Accountability** | 对他人和组织的实质影响范围 | 结果导向 + 人际协作（影响范围）|

### 3.2 三因子评分量表

```
Know-How（KH）
  等级   分值    描述
  -------- ----   ----------------------------------------
  KH1     50     执行标准化任务，需要基础指导
  KH2     87     执行多样化任务，需要定期指导
  KH3     125    执行复杂任务，偶尔需要指导
  KH4     165    执行高度复杂任务，几乎不需要指导
  KH5     200    创造新方法，领导领域发展
  [注：数字为Hay标准点值，可用于后续薪酬映射]

Problem Solving（PS）
  PS1 = 15% of KH  （高度结构化环境，重复性问题）
  PS2 = 25% of KH  （有结构但需要判断，常见问题）
  PS3 = 33% of KH  （复杂环境，复杂问题）
  PS4 = 50% of KH  （极度复杂，战略性未知问题）
  PS5 = 75-100% of KH （前沿领域，无先例问题）

Accountability（AC）
  AC1     10%   个人操作员：对自己任务负责
  AC2     25%   小组长：对自己+1-2人负责
  AC3     50%   经理：对自己团队负责
  AC4     75%   总监：跨多个团队/部门负责
  AC5     100%+  VP+：对事业部/公司整体负责
```

### 3.3 综合评分

```
总因子分 = KH点值 + (KH × PS%) + (KH × AC%)

该总分对应到内部职级体系的哪个级别？
→ 通过与同职级同事的分布比较来判断最终职级建议
```

---

## Step 4：校准会机制

> 评价必须经过校准，单人评价无效。

### 4.1 校准会参与方

```
必须参加：
□ 直属上级（评价第一负责人）
□ 隔级上级（评价监督）
□ HRBP（标准一致性把关）

可选参加：
□ 合作紧密的平级同事
□ 被评价人本人（只汇报结果，不参与讨论）
```

### 4.2 校准会流程

```
时长：每人15-20分钟（如果评价10人，会议约3小时）
流程：

1. 评价人陈述（5min）
   - 评价人陈述三因子评分及依据
   - 朗读关键行为证据

2. 参会人质疑（5min）
   - 其他参会人提问："这个评分是否低估/高估了？"
   - 所有质疑必须有证据支撑，不能是主观印象

3. 讨论并确认（5min）
   - 达成一致评分
   - 记录分歧及理由（如有）

4. 职级建议（2min）
   - 根据校正后评分，对照职级序列表给出职级建议
   - 明确是否建议晋升/维持/降级
```

### 4.3 校准会公平性检查清单

```
□ 是否有同序列跨部门的比较？（防止单一领导"注水"）
□ 证据是否充分（至少有2-3个有效证据才能支持某一能力的某一Level）？
□ AI效能证据是否被适当纳入？（不能因为"用了AI就扣分"）
□ 历史评价数据是否被正确使用？（避免今年和去年矛盾）
```

---

## Step 5：评价报告输出

### 5.1 报告模板

```markdown
# 职级评价报告

## 基本信息
| 项目 | 内容 |
|------|------|
| 被评价人 | [姓名] |
| 当前岗位 | [岗位名称] |
| 当前职级 | [职级] |
| 目标评价职级 | [职级] |
| 评价类型 | [晋升/年审/转岗/初评] |
| 评价日期 | [日期] |
| 词典版本 | [vX.X] |

## 三因子评分

| 因子 | 评分 | 关键依据 |
|------|------|---------|
| Know-How | KH[X] | [一句概括] |
| Problem Solving | PS[X]% | [一句概括] |
| Accountability | AC[X]% | [一句概括] |
| **综合因子分** | **[总分]** | [定位：相当于L_X左右] |

## 能力评价明细

| 能力 | 要求Level | 实际评估 | 证据支撑 | 差距 |
|------|----------|---------|---------|------|
| 批判性思维 | 3 | 3 | [证据摘要] | ✓达标 |
| 问题解决 | 3 | 2 | [证据摘要] | ⚠差距1级 |
| ... | ... | ... | ... | ... |

## AI协同能力评价（新增）

| AI能力 | 要求Level | 实际评估 | 关键证据 |
|--------|----------|---------|---------|
| AI工具应用 | 3 | 3 | [证据] |
| 人机协作判断 | 3 | 2 | [证据] |

## 综合建议

```
职级建议：L[X] → L[Y]（建议晋升 / 维持当前 / 观察期）
核心优势：[1-2项核心优势]
主要差距：[1-2项需提升的能力，附具体建议]
发展计划：[未来6-12个月的提升方向，1-3条]
评价置信度：□ 高 / □ 中 / □ 低（证据充分性判断）
```

## 签名确认

```
评价人：____________  日期：____________
隔级确认：____________  日期：____________
HRBP：____________  日期：____________
```

---

## Step 6：评价后的反馈机制

### 6.1 向被评价人反馈

```
反馈原则：
□ 反馈在评价完成后5个工作日内进行
□ 反馈必须包含：评分+证据，不只是结论
□ 反馈必须给出具体的1-3条发展建议
□ 允许被评价人提出申诉（有正式申诉通道）
□ AI协同能力的反馈要特别说明"把关能力"，而非"替代人的价值"
```

### 6.2 申诉机制

```
申诉触发条件：被评价人认为评价有明显偏差
申诉时效：收到反馈后10个工作日内
申诉受理：隔级上级 + HRBP 联合重审
申诉结果：维持原评价 / 修改评价 / 新评价（须全体同意）
```

---

## Step 7：评价数据的应用

```
评价数据流向：
┌──────────────┐
│ 个人评价报告  │→ ① 薪酬调整依据
│              │→ ② 晋升决策依据
│              │→ ③ 个人发展计划（IDP）输入
│              │→ ④ 团队能力地图建设
│              │→ ⑤ 词典本身的有效性验证（聚类分析）
└──────────────┘
```

---

## 关键原则（红线）

1. **没有词典不评价** — 能力标准必须先于评价存在
2. **没有证据不评分** — 每项能力的评分必须有具体行为证据
3. **没有校准不确认** — 单人评价无效
4. **AI不是扣分项** — 用AI完成工作是现代职场正常能力，不因此扣分
5. **评价公开标准** — 评价标准应对被评价人透明（词典即标准）
6. **评价有保鲜期** — 评价结果在12个月内有效，超期需重评

---

## 触发条件

当用户提供以下内容时，触发本模块：
- "怎么评定某人的职级"
- "任职资格怎么写"
- "帮他做个晋升评估"
- "我要评价张三的能力水平"
- 提供了被评价人信息+词典后，要求开始评价


path: references/job-level.md
content: # 职级体系设计

## 输入与输出

**前置依赖：** org-design 产出的职类序列
**输入：** 组织规模、行业特性、职类序列、现有职级体系（如有）
**输出：** 《职级序列表》—— 职级数量、级间距、晋升通道、宽带薪酬映射

---

## Step 1：职级数量决策

职级数量由两个因素决定：

```
组织成熟度：
  创业期/快速增长 → 职级少（L1-L3），快速晋升通道
  稳定期 → 职级多（L1-L9），细分层级
  衰退期/转型期 → 重新定义

岗位复杂度：
  单一业务 → 4-6级足够
  多元业务/职能复杂 → 7-9级
```

**参考标准（知识型组织）：**

| 组织类型 | 建议职级数 | 典型使用场景 |
|---------|----------|------------|
| 扁平型 | 3-4级 | 小型创业团队（<50人）|
| 标准型 | 5-6级 | 成长期公司（50-500人）|
| 精细型 | 7-9级 | 大型组织/集团（500人以上）|

---

## Step 2：典型职级序列表（L1-L9）

### M 管理序列

| 级别 | 通用职级名称 | 核心标志 |
|------|------------|---------|
| M1 | 主管/Team Lead | 带1-5人，负责小组执行 |
| M2 | 经理 | 带5-15人，负责部门/职能模块 |
| M3 | 高级经理 | 带10-30人，跨职能协调 |
| M4 | 总监 | 带20-50人，对业务线负责 |
| M5 | 高级总监 | 负责多条业务线或重要职能 |
| M6 | VP / 副总裁 | 负责大区/事业部，战略参与 |
| M7 | SVP / 高级副总裁 | 负责集团核心板块 |
| M8 | CRO/COO/CFO等CXO | 向CEO汇报，集团决策层 |
| M9 | CEO | 最高决策者 |

### P 专业序列（以科技/产品为例）

| 级别 | 通用职级名称 | 核心标志 |
|------|------------|---------|
| P1 | 初级专员 | 在指导下执行任务 |
| P2 | 中级专员 | 独立完成分配任务 |
| P3 | 高级专员/Senior | 独立承担完整模块 |
| P4 | 专家/Lead | 技术/专业决策，辅导P1-P3 |
| P5 | 高级专家 | 跨模块影响，方法论建设 |
| P6 | 首席专家/Principal | 领域级影响力，标准制定者 |
| P7 | 资深首席/Distinguished | 公司级影响力 |
| P8 | Fellow | 行业级影响力 |
| P9 | 学术 Fellow | 行业标杆，如ACM Fellow |

---

## Step 3：双通道模型

建立管理序列（M）和专业序列（P）的等价值映射：

```
P4 = M1（专业影响力范围 ≈ 主管管理幅度）
P5 = M2（专业深度 = 经理管理幅度）
P6 = M3（跨模块 = 高级经理）
P7 = M4（业务线级 = 总监）
```

**为什么要双通道：**
- 不是所有人都想做管理
- 顶级专家的价值可以远超管理者
- 防止"彼得原理"（晋升到不胜任位置）

**设计检查：**
```
□ P通道顶端是否等于M通道顶端？（否则P到顶了就只能转M）
□ 同一级别内，P和M的薪酬范围是否大致对齐？
□ 是否有明确的P↔M转换机制（通常需要申请+评估）？
```

---

## Step 4：宽带薪酬设计

每个职级的薪酬带宽公式：

```
带宽 = (最大值 - 最小值) / 最小值

建议带宽：
- L1-L3（基础层）：带宽 40-60%（技能学习期，差异小）
- L4-L6（骨干层）：带宽 50-80%（能力分化期）
- L7-L9（战略层）：带宽 80-120%（高度差异化）

重叠度：相邻两级之间建议重叠 10-20%
（重叠使晋升不因薪酬倒挂而卡死）
```

---

## Step 5：职级名称标准化

原则：内部职级名称 ≠ 市场上流通的Title（避免市场溢价/折价干扰）

```
内部职级体系（实际管理用）
    ↓ 翻译
市场Title（对外招聘用，对标市场）
```

---

## Step 6：晋升机制

### 晋升条件（通用标准）

| 条件类型 | 说明 |
|---------|------|
| **时间门槛** | 在当前级别至少N年（建议：L1-3至少1年，L4-6至少2年，L7+至少3年）|
| **绩效门槛** | 连续2年绩效在Top X%（建议：前15-20%）|
| **能力门槛** | 满足下一级别胜任力要求（证据支撑）|
| **编制门槛** | 下一级别有HC空缺 |

### 晋升评估频率
- L1-L4：每半年评估
- L5-L7：每年评估
- L8-L9：不定期，通常配合重大业务变化

---

## Step 7：AI对职级体系的冲击

### 7.1 新增"AI杠杆率"维度

每个岗位的职级现在都要考虑"AI杠杆率"：

```
AI杠杆率 = 该岗位用AI放大的产出 / 该岗位总产出

- 低杠杆（<20%）：执行层，AI作为工具  → 传统职级
- 中杠杆（20-50%）：分析师/策划层  → 职级不变，但胜任力标准变化
- 高杠杆（>50%）：设计/策略层  → 新职级命名可能产生
- 极高杠杆（>80%）：创新/架构层  → AI原生岗位，传统无法对标
```

### 7.2 典型AI原生职级

| 新职级 | 定义 | 对标传统 |
|--------|------|---------|
| Prompt Engineer | 专精AI交互设计 | UX设计师 |
| AI Trainer / Finetuner | 领域模型微调 | 算法工程师 |
| AI Operator | AI工具链管理+效能优化 | 运维工程师 |
| AI Ethics Specialist | AI伦理审查 | 法务/合规 |
| Head of AI Productivity | 组织AI效能管理 | COO |

### 7.3 职级压缩风险

AI加速了低级别工作，导致：
- 部分L1-L2岗位消失或被合并
- L3-L4的能力要求整体上移
- 晋升通道"缩短"但"加宽"

---

## Step 8：产出《职级序列表》模板

```markdown
# [公司名] 职级序列表 v[X.X]

## 1. 职级概览
| 级别 | M管理序列 | P专业序列 | T技术序列 | S技能序列 |
|------|----------|----------|----------|----------|
| L9 | CEO | Fellow | - | - |
| L8 | CXO | 资深首席 | - | - |
| L7 | SVP | VP | - | - |
| L6 | VP | 首席专家 | 高级技术专家 | - |
| L5 | 高级总监 | 高级专家 | 技术专家 | 高级技师 |
| L4 | 总监 | 专家/Lead | 高级工程师 | 技师 |
| L3 | 高级经理 | 高级专员 | 工程师 | 高级技工 |
| L2 | 经理 | 中级专员 | 初级工程师 | 技工 |
| L1 | 主管 | 初级专员 | 助理工程师 | 操作工 |

## 2. 晋升通道图
（文字描述各通道之间的转换规则）

## 3. 薪酬带宽（待与薪酬模块对接）
| 级别 | 最小值 | 中位值 | 最大值 | 带宽 |
|------|--------|--------|--------|------|
| L9 | ... | ... | ... | ...% |
| ... | ... | ... | ... | ...% |

## 4. AI渗透率评估
| 级别 | 平均AI渗透率 | 主要变化 |
|------|------------|---------|
| L1-L3 | 高 | 执行层被压缩 |
| L4-L6 | 中 | 能力要求上移 |
| L7-L9 | 低 | 影响相对小 |

## 5. 新增AI原生岗位（如有）
| 岗位名称 | 职级定位 | 核心职责 | 对标传统 |
|---------|---------|---------|---------|
| ... | ... | ... | ... |

## 6. 待解决的职级问题
（记录尚未解决的职级边界争议或特殊案例）
```


path: references/org-design.md
content: # 组织架构设计

## 输入与输出

**输入：** 战略目标、业务复杂度、人员规模、现有架构图、协作模式
**输出：** 《架构说明书》—— 部门划分、职类序列、汇报关系、核心决策流

---

## Step 1：战略对齐

设计架构之前，先明确：

```
1. 我们的核心战略是什么（1-3条）？
2. 关键业务能力是什么（客户价值链上的1-3个环节）？
3. 我们的竞争优势来自哪里（技术/渠道/品牌/成本）？
```

这三条决定架构的**重心**在哪里。

---

## Step 2：McKinsey 7S 现状诊断

对现有架构做7要素对齐评估：

| 要素 | 类型 | 内容 |
|------|------|------|
| Strategy | 硬 | 战略目标、资源配置优先级 |
| Structure | 硬 | 汇报关系、部门划分、层级 |
| Systems | 硬 | 流程、审批、数据系统 |
| Shared Values | 软 | 文化、价值观、行为准则 |
| Skills | 软 | 组织核心能力、差异化能力 |
| Style | 软 | 管理层决策风格 |
| Staff | 软 | 人才结构、人才密度 |

**诊断方法：** 对每个S打分（1-5），识别"断点"——7个S中断点最多的地方就是最需要改的地方。

---

## Step 3：复杂度系数模型

部门划分的决策依据：

```
复杂度系数 = f(业务复杂度, 决策频率, 协同依赖度, 监管要求)

业务复杂度：
  - 单一业务线 → 系数 1.0
  - 多业务线但同类 → 系数 1.3
  - 多元业务 → 系数 1.8

决策频率：
  - 日常运营决策 → 适合放一线
  - 战略/例外决策 → 适合放高层

协同依赖度：
  - 高内聚低耦合 → 独立部门
  - 强依赖 → 归并同类项
```

---

## Step 4：职类序列定义

组织内所有岗位归入四大序列（职类）：

| 序列 | 定义 | 典型岗位 | 晋升特点 |
|------|------|---------|---------|
| **M 管理序列** | 对人负责，对团队产出负责 | 经理/总监/VP/CEO | 以管理幅度和战略影响范围晋升 |
| **P 专业序列** | 对专业深度负责，单人不带团队 | 工程师/设计师/分析师 | 以专业深度和影响范围晋升 |
| **T 技术序列** | 对技术实现负责 | 技工/技术员/运维 | 以技术等级和资质认证晋升 |
| **S 技能操作序列** | 对操作执行负责 | 操作工/客服/助理 | 以技能熟练度和资质晋升 |

**注意：** AI时代新增 `AI` 序列——负责AI系统设计/训练/治理的岗位，可归入P或新建。

---

## Step 5：AI时代的架构新增考量

### 5.1 人机协同架构层级

```
Level 1 - 工具化:  AI作为个人效率工具，架构不变
Level 2 - 流程化:  AI嵌入业务流程，岗位边界开始模糊
Level 3 - 角色化:  AI作为协作者出现，产生"人机混合岗"
Level 4 - 系统化:  AI成为组织架构设计的一个维度
```

### 5.2 新增AI治理职能

在现有架构中增加以下AI相关职能节点（根据公司规模决定放在哪层）：

- **AI伦理审查** — 对AI应用进行合规和伦理把关
- **模型资产管理** — AI模型版本、权限、数据治理
- **人机协作体验** — AI使用体验、Prompt库管理、AI效能评估

### 5.3 决策层级扁平化机会

AI替代了部分信息中介和审批节点，可能导致：
- 某些中层管理职位被压缩
- 一线员工决策权扩大
- 组织向"哑铃型"演变（高层决策+一线执行，中间压缩）

---

## Step 6：汇报关系设计

核心原则：**一个人只有一个直接汇报对象（紧急情况例外）**

```
设计检查清单：
□ 每个部门有且只有一个负责人
□ 跨部门协作通过"产品/项目"机制而非固定汇报
□ 新增岗位先问：是否有现有岗位可以承担类似职责？
□ 管理幅度：一线主管 8-15人，中层 5-9人，高层 3-7人
□ AI渗透率高的部门，管理层级可以更扁平
```

---

## Step 7：产出《架构说明书》模板

```markdown
# [公司名] 组织架构说明书 v[X.X]

## 1. 战略定位
（核心战略1-3条）

## 2. 组织架构图
（文字描述 + 隐去人名的组织结构）

## 3. 部门划分
| 部门 | 核心职能 | 定位（利润中心/成本中心/赋能中心）| 关键协作部门 |
|------|---------|------------------------------|------------|

## 4. 职类序列
| 序列 | 定义 | 说明 |
|------|------|------|
| M 管理 | ... | ... |
| P 专业 | ... | ... |
| T 技术 | ... | ... |
| S 技能 | ... | ... |

## 5. 汇报关系（关键路径）
（CEO → X → X → 一线的简要路径说明）

## 6. 决策流
| 决策类型 | 决策主体 | 决策周期 |
|---------|---------|---------|
| 日常运营 | ... | ... |
| 战略投资 | ... | ... |
| 人事任免 | ... | ... |

## 7. AI渗透率评估
| 部门/岗位 | 当前AI渗透率(低/中/高) | 主要AI工具 | 架构调整建议 |
|-----------|---------------------|-----------|------------|

## 8. 待解决的设计问题
（记录尚未解决的架构问题，留待后续决策）
```

---

## 触发条件

当用户提供以下内容时，触发本模块：
- 新的组织架构图（文字描述或草图）
- 部门调整、汇报关系变化
- 战略目标变化
- 问"我们应该怎么组织"类似问题


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)