- 先别问能减掉几个人,先看清实际工作把时间耗在了哪里。
- 在提速之前,先砍掉那些本来就不该存在的工作,否则就是在花钱加快没必要的事。
- 人手怎么调整,要等看到一整轮的真实数字之后再决定。
1. 10 人团队能缩减到 5 人吗
老实说,有时可以,有时不行。张口就说“肯定可以”的人,多半还没看过真实数据。眼下能先回答的问题是:团队的时间现在都花在了什么地方。
在某些流程里确实做得到,但在弄清实际工作由哪些部分组成之前,不要先定人数目标。如果十人团队有一半时间花在复制数据、制作文件和追进度上,把人工介入(Human Touch)减少 50%,团队就可能缩小,或者能承接两倍的工作量。如果大部分工作是谈判、现场检查或维护客户关系,同样的目标就可能不现实。
要从需要达到的产能算起,别从想裁掉的人数算起。比如公司每月要处理 5000 笔业务,15 分钟内回复客户,差错率低于 1%。然后再设计:系统处理多少笔,人工处理多少笔例外,总共需要多少人工小时。这样算出来的决定,比笼统地宣布削减开支更站得住脚。
2. 根据真实发生的事件画流程图
别拿三年前写的文件当起点,要看系统里留下的痕迹,了解工作实际是怎么流转的。这些数据往往和团队以为的情况差得不少,正好借此看清实际问题。

选一个流程,从头到尾跟着真实的工作走一遍,记下负责人、打开的系统、输入的数据、做出的决定、实际动手的时间和等待的时间。要把人工处理时间(Touch Time)和等待时间(Wait Time)分开,因为一项工作可能只要做 40 分钟,却要排队等三天。如果审批还是照旧要等,把录入时间压缩到 20 分钟,客户也不会更快拿到结果。
把员工阅读、总结、复制、转换格式、查找信息、比对或发提醒的每个环节都标出来,这些都可以考虑交给 AI 和自动化。需要建立信任、为后果负责或者对例外情况做决定的环节,应该留给人。
| 步骤 | 分析问题 | 处理方式 |
|---|---|---|
| 接收任务 | 数据是否来自多个渠道 | 自动汇总并拆分数据 |
| 准备 | 需要查找或复制什么 | AI 汇总资料并起草 |
| 决策 | 规则明确,还是例外很多 | 按自动规则处理,或转交给人 |
| 交付 | 需要生成哪些文件、更新哪些系统 | 工作流自动接着执行 |
| 跟进 | 谁负责记着并催办 | 按事件自动提醒 |
3. 先砍掉不必要的工作,再做自动化
把不必要的步骤做得更快,仍然是浪费。要检查:每份报告是否真的有人看?同样的数据要填几次?多层审批真能降低风险,还是只是沿袭下来的老规矩?客户是否要重复提交公司手里已有的资料?接入 AI 之前,先删减、合并、统一标准。

举个例子,有家公司让员工给销售、经理和财务分别做三种格式的汇总。这时用不着做三套 AI,先商定一套共用的数据,各部门再按需要查看各自的视图就行。另一家公司每笔交易的折扣都要审批,可其中 80% 都在标准范围内。设定一个自动审批的区间,比用 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 服务中断,整套安排就会垮掉。
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 周:选定流程,收集工作量、时间、质量和人数的基线数据。
- 第 2 周:画流程图,砍掉不必要的步骤,划分三条工作通道。
- 第 3–4 周:搭建“AI 准备、人工检查”的系统,用历史数据测试。
- 第 5 周:在一个小组试行,实测人工介入的时间,记录例外情况。
- 第 6 周:只对标准个案开放直通处理,加上监控和停止按钮。
- 第 7 周:重新计算产能,设计新的岗位分工和备用排班。
- 第 8 周:决定扩大、调整还是停止,同时拿出以数据为依据的人手计划。
总结:十人团队能不能缩减到五人,取决于重新设计之后标准工作的占比和人工介入的多少。从流程和服务水平入手,让 AI 接手重复性工作,设立例外通道,再根据真实数据计算产能。成本要降得下来、又不反弹,质量、后备知识和责任归属都得同时守住。
先重新设计流程,再回答人数的问题
真正能用的流程图,要来自实际干活的人,三年前写的文件派不上用场。所以我们根据过去真实发生的事件画流程图,依据是系统里留下的痕迹,比如工作进入和离开每个状态的时间、返工的次数,以及工作卡得最久的环节。这些数据常常会推翻团队原来的一些认识,问题也就看清了。在谈减员之前,我们会先砍掉不必要的工作,因为把本不该存在的工作做得更快,钱就白花了。
我们和团队主管一起推进的步骤
接下来,我们设计人 + AI 的团队模式,写清楚哪些部分由系统接手、哪些由人负责、质量怎么衡量,再搭建支撑这种模式的系统,包括任务队列、审批节点,以及主管每周查看实际工作量用的仪表盘。在流程调整后至少跑完一整轮、看到数字之前,我们不建议对人手做决定。如果您的团队正在争论该不该减员,不妨先把真实流程测量一轮。
SOFTWARE ENGINEERING GLOSSARY
软件工程术语表
讨论如何测量和重新设计工作流程时,会用到这组术语。
| 术语 | 是什么 | 通俗示例 | 高管应问开发团队的问题 |
|---|---|---|---|
| Process Map | 标出每个步骤负责人和耗时的实际工作流程图 | 从接到订单到发货的工作流程图 | 这张图是根据真实数据画的,还是只靠访谈? |
| Bottleneck | 处理能力有限、拖慢整个流程的环节 | 所有工作都要等同一个人审批 | 现在的瓶颈在哪里?用什么来衡量? |
| Wait Time | 工作停在那里、没人处理的时间 | 文件等审批等了两天,检查却只要 10 分钟 | 我们的总耗时里,实际动手的时间占百分之多少? |
| Capacity | 团队或系统在一段时间内能承接的最大工作量 | 团队每周能处理 200 项工作 | 如果工作量增加 30%,我们需要增加什么? |
| Dashboard | 汇总关键数字、一眼就能看清状态的界面 | 主管每周都能看到积压的工作和等待时间 | 这个界面上的数字多久更新一次?从哪里来? |
