003 · 人力资源规划与组织设计
组织架构梳理与调整建议
这个场景解决什么问题
企业规模扩大后，组织架构容易保留过去的层级和汇报关系，同时不断叠加新部门、新岗位和审批节点。表面上看组织图仍然完整，实际可能出现决策链过长、职责交叉、管理幅度失衡、业务流程被部门墙切断等问题。
这个场景不是让 AI 重新画一张组织架构图，而是把战略、业务流程、部门职责、岗位和汇报关系放在一起检查：当前结构能否承接业务目标，问题发生在哪个接口，有哪些调整方案，以及调整会影响哪些人员、权限和流程。材料中关于 FDE 三层组织、制造企业扁平化和 AI 原生组织的案例只能作为结构设计参考，不能直接照搬到其他企业。
适用范围
- 公司扩张、并购或业务转型后的组织梳理
- 部门重叠、审批缓慢、跨部门协作不畅的诊断
- 新业务、新区域或 AI 团队的组织方案比较
- 组织扁平化、事业部制或端到端项目团队调整前的材料准备
- 组织架构图、汇报线和审批关系的一致性检查
组织调整涉及权责和人员安排。如果问题、目标和决策权限尚未明确，应先做诊断，不宜直接输出正式调整方案。
需要准备什么
- 公司战略、年度业务目标和核心价值链
- 当前组织架构图及历史版本
- 员工花名册：员工编号、部门、岗位、上级编号和工作地点
- 部门职责、岗位说明书和主要流程文件
- 审批权限表及跨部门协作规则
- 组织绩效、流程时长、员工调研或访谈材料
- 已知的问题案例，例如重复审批、责任空白或跨部门冲突
- 调整约束，包括预算、关键人员、法律程序和实施时间
具体操作步骤
第一步：明确组织调整要解决的业务问题
先把“组织臃肿”“协作不好”等笼统判断改写成可验证的问题：某类决策需要经过多少层、哪个流程等待时间最长、哪些部门承担相同任务、哪些业务结果没有明确责任主体。所有调整建议都应回到业务目标和价值链，而不是为了减少层级而减少层级。
第二步：还原当前组织结构
以员工编号和上级编号建立汇报关系，从最高负责人向下计算每名员工的层级、直接下属和间接下属。同步整理部门、岗位和实际承担的任务，检查架构图、花名册与审批表是否一致。
需要单独列出无上级、循环汇报、多人汇报、部门与上级不匹配及离职人员仍在架构中的情况，先由 HR 确认数据，再进行分析。
第三步：检查层级和管理幅度
统计组织总层级、最长管理链、各层人数和每名管理者的直接下属数。极宽或极窄的管理幅度只是异常线索：主管直接管理二三十人可能无法有效管理，只有一两个下属也可能意味着层级冗余，但不能仅凭人数认定该层级应撤销。
第四步：把部门职责映射到业务流程
从部门职责、岗位说明书和流程文件中提取“负责、参与、审核、审批、交付”五类动作，建立职责事项库。再按业务流程查看同一事项是否多人负责、关键节点是否无人负责、审批与执行是否混在同一角色，以及流程是否因部门切分而反复移交。
第五步：判断结构问题属于哪一类
把发现的问题区分为：
- 结构问题：层级、部门设置或汇报线不合理
- 权责问题：职责交叉、责任空白或审批权错位
- 流程问题：移交过多、等待时间长或业务链被切断
- 人员问题：岗位与能力不匹配、关键角色缺失
- 系统问题：组织、权限和审批数据不同步
避免把所有问题都归因于组织架构。流程和管理机制没有改变时，单纯移动部门通常不能解决问题。
第六步：形成两到三种调整方案
每个方案说明设计原则、部门与岗位变化、汇报线、审批权限、受影响流程、人员影响、实施成本和风险。可以比较精简层级、合并重叠职能、下放审批权限、建立端到端项目团队或设置独立新业务单元等做法。
案例中的 FDE 三层模型强调领域判断、战术支撑和工程交付相互制衡；AI 原生组织强调围绕人机协作重构流程。这些只能用于启发角色分工，不能作为企业必须采用的标准答案。
第七步：校验新结构能否运行
选择一个真实业务流程模拟：需求从哪里进入，谁负责、谁审批、谁交付，异常由谁处理，数据和结果如何留痕。检查新结构是否减少了无价值移交，同时保留必要的风险控制。
第八步：制定分阶段实施和沟通计划
明确架构、岗位、人员、权限、系统和制度分别何时调整，谁负责确认。重大调整应先在一个业务单元或流程试运行，再根据结果扩大。正式发布前还要准备员工沟通、岗位变更、交接和风险处置方案。
可以直接参考的提示词
请根据公司战略、当前组织架构、花名册、部门职责、岗位说明书、审批权限表和流程文件，协助完成组织架构诊断。原始文件不得修改。
1. 先列出材料范围、版本和缺失项，以员工编号和上级编号还原当前汇报关系。
2. 计算组织层级、最长管理链、各层人数、每名管理者的直接和间接下属数。
3. 列出无上级、循环汇报、多人汇报、部门与上级不匹配等数据问题，等待确认。
4. 按“负责、参与、审核、审批、交付”提取部门和岗位事项，形成统一职责事项库。
5. 识别职责重复、责任空白、审批与执行冲突、跨部门移交过多等线索，并引用来源文件。
6. 将问题区分为结构、权责、流程、人员和系统问题，不要把所有问题都归因于架构。
7. 在我确认诊断后，提出 2—3 种调整方案。每种方案说明部门与岗位变化、汇报线、审批权限、流程影响、人员影响、实施成本和风险。
8. 选择一个真实业务流程模拟新结构的责任和审批链，并输出分阶段实施及沟通计划。
注意：只提供数据分析和方案比较，不直接决定撤销部门、裁撤层级或调整具体人员。
最终会得到什么
- 当前组织架构和汇报关系数据表
- 层级、管理幅度及异常关系清单
- 部门和岗位职责事项库
- 结构、权责、流程、人员和系统问题清单
- 两到三种组织调整方案及影响比较
- 新结构的流程模拟、实施计划和沟通清单
验收检查
- 当前组织结构与花名册、汇报线和审批关系一致
- 每个异常都能追溯到数据或流程材料
- 管理幅度异常没有被直接等同于层级冗余
- 职责重叠、责任空白和流程问题已经区分
- 调整方案明确展示权责、流程、人员和系统影响
- 新结构通过至少一个真实业务流程模拟
- 案例中的组织模型没有被直接照搬
- 最终调整由管理层、HR 和相关业务负责人确认
常见问题
组织层级多，就一定要扁平化吗
不一定。层级是否有价值取决于业务复杂度、管理半径、风险控制和决策效率。应检查每一层承担的真实责任，而不是只看数量。
两个部门都在做相似工作，是否应该合并
先比较服务对象、输入输出、决策权限和专业要求。名称相似或任务部分重合不等于应该合并，也可能需要明确主责和协作接口。
能否根据花名册直接生成新架构
不能。花名册只能还原人员和汇报关系，无法说明业务价值链、真实流程和非正式协作。必须结合战略、职责和流程材料。
AI 团队应该独立建制还是嵌入业务部门
材料展示了独立单元、三层团队和端到端小队等不同做法，没有唯一答案。应根据 AI 能力是公共平台、核心业务还是局部工具，以及所需的业务协同方式选择。
人工复核、风险与责任边界
AI 可以还原关系、统计层级、比较职责和生成方案，但无法掌握组织政治、关键人员影响、非正式协作和劳动关系后果。组织调整可能涉及岗位、汇报对象、薪酬和劳动合同变化，必须由管理层、HR、业务负责人及必要的法务人员评估和批准。AI 输出不得直接作为撤岗、降职或解除劳动关系的依据。