ARTICLE 04 · Organization Design · 2025-12-21

10 人团队能缩减到 5 人吗?用 AI 重新设计工作流程

买了工具就指望员工干得更快,人数是减不下来的。想用 AI 减少人手,要把工作的路径重新梳理一遍:砍掉不产生价值的步骤,合并岗位,让系统从头到尾接手标准化的工作。

10 人团队能缩减到 5 人吗?用 AI 重新设计工作流程
要点速览
  • 先别问能减掉几个人,先看清实际工作把时间耗在了哪里。
  • 在提速之前,先砍掉那些本来就不该存在的工作,否则就是在花钱加快没必要的事。
  • 人手怎么调整,要等看到一整轮的真实数字之后再决定。

1. 10 人团队能缩减到 5 人吗

老实说,有时可以,有时不行。张口就说“肯定可以”的人,多半还没看过真实数据。眼下能先回答的问题是:团队的时间现在都花在了什么地方。

在某些流程里确实做得到,但在弄清实际工作由哪些部分组成之前,不要先定人数目标。如果十人团队有一半时间花在复制数据、制作文件和追进度上,把人工介入(Human Touch)减少 50%,团队就可能缩小,或者能承接两倍的工作量。如果大部分工作是谈判、现场检查或维护客户关系,同样的目标就可能不现实。

要从需要达到的产能算起,别从想裁掉的人数算起。比如公司每月要处理 5000 笔业务,15 分钟内回复客户,差错率低于 1%。然后再设计:系统处理多少笔,人工处理多少笔例外,总共需要多少人工小时。这样算出来的决定,比笼统地宣布削减开支更站得住脚。

换个问法把“要减掉几个岗位”换成“用了 AI 以后,这个流程每项工作需要人工介入几分钟”。后一个数字可以测试、可以改进;前一个数字往往让团队还没看到新的工作方式,就先抵触起来。

2. 根据真实发生的事件画流程图

别拿三年前写的文件当起点,要看系统里留下的痕迹,了解工作实际是怎么流转的。这些数据往往和团队以为的情况差得不少,正好借此看清实际问题。

先砍掉不必要的工作,再把剩下的自动化
先砍掉不必要的工作,再把剩下的自动化

选一个流程,从头到尾跟着真实的工作走一遍,记下负责人、打开的系统、输入的数据、做出的决定、实际动手的时间和等待的时间。要把人工处理时间(Touch Time)和等待时间(Wait Time)分开,因为一项工作可能只要做 40 分钟,却要排队等三天。如果审批还是照旧要等,把录入时间压缩到 20 分钟,客户也不会更快拿到结果。

把员工阅读、总结、复制、转换格式、查找信息、比对或发提醒的每个环节都标出来,这些都可以考虑交给 AI 和自动化。需要建立信任、为后果负责或者对例外情况做决定的环节,应该留给人。

步骤分析问题处理方式
接收任务数据是否来自多个渠道自动汇总并拆分数据
准备需要查找或复制什么AI 汇总资料并起草
决策规则明确,还是例外很多按自动规则处理,或转交给人
交付需要生成哪些文件、更新哪些系统工作流自动接着执行
跟进谁负责记着并催办按事件自动提醒

3. 先砍掉不必要的工作,再做自动化

把不必要的步骤做得更快,仍然是浪费。要检查:每份报告是否真的有人看?同样的数据要填几次?多层审批真能降低风险,还是只是沿袭下来的老规矩?客户是否要重复提交公司手里已有的资料?接入 AI 之前,先删减、合并、统一标准。

根据实测的工作量计算人手,别按现有人头来算
根据实测的工作量计算人手,别按现有人头来算

举个例子,有家公司让员工给销售、经理和财务分别做三种格式的汇总。这时用不着做三套 AI,先商定一套共用的数据,各部门再按需要查看各自的视图就行。另一家公司每笔交易的折扣都要审批,可其中 80% 都在标准范围内。设定一个自动审批的区间,比用 AI 更快地起草审批邮件更能缩短等待时间。

正确的顺序消除 → 简化 → 标准化 → 自动化 → 引入 AI。如果一上来就用 AI,公司就会花钱做一套复杂的系统,去模仿一个本来就不该存在的流程。

4. 真正可行的人 + AI 团队模式

把工作分成三条通道。第一条是直通(Straight-through),处理标准个案,系统从接收到完成全程包办,不需要人插手。第二条是审核(Review),AI 把材料准备齐全,人在短时间内检查并审批。第三条是例外(Exception),信息不全、风险高或者涉及特殊客户的工作,转交给专家处理。

标准个案由系统直接处理,例外情况连同完整信息一起转给人
标准个案由系统直接处理,例外情况连同完整信息一起转给人

目标是减少需要排队等人处理的工作,并不要求每项工作都走自动通道。例如客服团队可以让系统直接关闭 60% 的标准问题,为 25% 准备好回复供人检查,再把 15% 转给专家。这样即使客户数量增加,团队也不需要维持原来的人数。

团队主管的角色也会变:过去是分派任务、追进度,以后是看例外情况的仪表盘,分析系统为什么转交,调整数据或规则,让直通率(Straight-through Rate)提高。员工则要擅长质量检查、处理疑难个案,并给出有条理的反馈。

5. 按工作量重新计算人手,别凭感觉

用一个简单公式:每月工作量 × 每项工作需要人工介入的分钟数 ÷ 每人每月的有效工作分钟数。假设每月 6000 项工作,原来每项花 12 分钟,合计 72000 分钟。新系统上线后,如果 65% 自动完成,25% 只需检查 3 分钟,10% 的疑难个案各花 20 分钟,人工工作量就降到 16500 分钟,减少了 75% 以上。

别以为员工每月有足足 160 小时可以用在产出上,要扣掉开会、培训、请假和行政事务。通常取一个保守的数字,比如每月 100–120 个有效工时,再为高峰期和意外故障留出余量。人手算得太紧,一遇到业务量上涨或 AI 服务中断,整套安排就会垮掉。

STP Rate系统自行完成的工作占比
Review Min.每项工作的平均检查分钟数
Peak Buffer高峰期的备用产能

6. 管理转型,别让员工把问题藏起来

如果团队认为,帮 AI 改进的反馈很快就会换来裁员,员工自然会把经验留在自己手里,系统不好用时也不吭声。企业主应该坦诚地沟通计划,讲清楚试行期多长、按什么标准做决定、有哪些转岗机会。做不到的事不要承诺,但要做到公平,并给员工留出准备的时间。

写给开发团队 · 技术细节

第一步是业务量增加时不再招人。能做到的话,先通过内部调岗和自然减员(Natural Attrition)来调整。明确新的岗位,比如流程负责人(Process Owner)、AI 质量审核员(AI Quality Reviewer)、客户专员(Customer Specialist)或自动化协调员(Automation Coordinator),并提供和实际工作挂钩的培训。如果裁员后没人留下来维护系统,上线几个月后效率就会下滑。

激励要按团队的成果来定,比如处理周期(Cycle Time)、质量和能服务的客户数量,看起来忙了多少小时不能算数。员工发现系统性错误时应该得到认可,因为这些信息能在扩大规模之前把问题挡住。

7. 小团队更依赖系统带来的风险

人少了,知识和后备能力可能随之流失。必须准备系统宕机时用的运维手册(Runbook)、最低限度的手工作业方法,以及每个系统的负责人名单。不要让外部开发商成为唯一了解整个工作流的人。公司必须能导出自己的数据,也能查看自己的日志。

要留意不声不响的错误,比如 AI 分错了类却没人发现,客户收到的回复看起来不错却没解决问题,或者系统专挑简单的工作做,疑难个案一直积压。要设定抽样检查(Sampling)规则,让人抽查自动完成的工作,隔一段时间测试一次高风险情况,业务量增加时也要检查费用。

削减人工产能之前
  • 系统至少平稳度过一个高峰期
  • 有好几周的质量数据,演示效果不算
  • AI、API 或核心系统宕机时有应对方案
  • 团队调整后,有流程负责人和质量审核人员

8. 8 周行动计划

  1. 第 1 周:选定流程,收集工作量、时间、质量和人数的基线数据。
  2. 第 2 周:画流程图,砍掉不必要的步骤,划分三条工作通道。
  3. 第 3–4 周:搭建“AI 准备、人工检查”的系统,用历史数据测试。
  4. 第 5 周:在一个小组试行,实测人工介入的时间,记录例外情况。
  5. 第 6 周:只对标准个案开放直通处理,加上监控和停止按钮。
  6. 第 7 周:重新计算产能,设计新的岗位分工和备用排班。
  7. 第 8 周:决定扩大、调整还是停止,同时拿出以数据为依据的人手计划。

总结:十人团队能不能缩减到五人,取决于重新设计之后标准工作的占比和人工介入的多少。从流程和服务水平入手,让 AI 接手重复性工作,设立例外通道,再根据真实数据计算产能。成本要降得下来、又不反弹,质量、后备知识和责任归属都得同时守住。

DNA MAKER · SOLUTION BLUEPRINT

先重新设计流程,再回答人数的问题

真正能用的流程图,要来自实际干活的人,三年前写的文件派不上用场。所以我们根据过去真实发生的事件画流程图,依据是系统里留下的痕迹,比如工作进入和离开每个状态的时间、返工的次数,以及工作卡得最久的环节。这些数据常常会推翻团队原来的一些认识,问题也就看清了。在谈减员之前,我们会先砍掉不必要的工作,因为把本不该存在的工作做得更快,钱就白花了。

我们和团队主管一起推进的步骤

接下来,我们设计人 + AI 的团队模式,写清楚哪些部分由系统接手、哪些由人负责、质量怎么衡量,再搭建支撑这种模式的系统,包括任务队列、审批节点,以及主管每周查看实际工作量用的仪表盘。在流程调整后至少跑完一整轮、看到数字之前,我们不建议对人手做决定。如果您的团队正在争论该不该减员,不妨先把真实流程测量一轮。

软件工程术语表

讨论如何测量和重新设计工作流程时,会用到这组术语。

术语是什么通俗示例高管应问开发团队的问题
Process Map标出每个步骤负责人和耗时的实际工作流程图从接到订单到发货的工作流程图这张图是根据真实数据画的,还是只靠访谈?
Bottleneck处理能力有限、拖慢整个流程的环节所有工作都要等同一个人审批现在的瓶颈在哪里?用什么来衡量?
Wait Time工作停在那里、没人处理的时间文件等审批等了两天,检查却只要 10 分钟我们的总耗时里,实际动手的时间占百分之多少?
Capacity团队或系统在一段时间内能承接的最大工作量团队每周能处理 200 项工作如果工作量增加 30%,我们需要增加什么?
Dashboard汇总关键数字、一眼就能看清状态的界面主管每周都能看到积压的工作和等待时间这个界面上的数字多久更新一次?从哪里来?