数字工具越来越多,效率却未必跟着提高,常见的结果反倒是信息被切碎、脑子更累、产出质量下滑。智能转型就是一个有步骤的过程,把一堆越积越复杂的工具,变成有章法、互相打通的技术使用方式。目的并非为了少用工具而少用,是让这些工具作为一个整体协同运转,别再各自抢夺员工的注意力。 关键要点 数字工具太多会降低专注度、引起超负荷并增加时间浪费 智能转型是一套包括审计、集成、自动化和培训的策略 管好技术能够减少压力、提升生产力并改善工作质量 引言 当使用中的数字工具和平台数量超过员工有效管理并将其集成到日常工作中的能力时,就会发生技术超负荷。问题不在于程序数量本身,而在于缺乏使用它们的明确战略
如何识别工作流瓶颈并解决问题
工作流瓶颈并不是随机出现的,它们有规律可循。Formstack 与 Mantis Research 的一份报告发现,组织每年因流程低效最多可能损失 $130 万,而超过半数的员工每天至少要花两小时处理重复性任务。由此可见,识别和解决瓶颈不只是日常维护,而是一项核心运营能力,直接关系到企业的财务结果。
关键要点
如果能够提前识别问题领域,项目就不易出现延误
消除瓶颈后,完成任务所需的时间可显著缩短
花一些时间改进日常工作流程可以显著提升团队的生产力
引言
瓶颈大体分为两类:流程低效和资源分配失误。两者的表面症状相同,都是工作推进得比应有的速度慢,但需要的处理方式并不一样。如果用重新设计流程去解决资源分配问题,或者反过来,效果都很有限,因为真正的约束并没有被触及。
流程低效:
- 过时的工作方法。为另一种运营环境设计的流程,比如手动录入数据、逐级串行审批、只能当面协作,会带来摩擦,而且每运行一轮,摩擦就多积累一层。
- 过多的审查环节。审查和测试一旦超出质量控制的实际需要,就会拉长交付时间,质量却没有相应提高。多加一道审查从改善结果变成拖慢结果,这个临界点是可以找到的,而且经常被越过。
- 官僚化的审批结构。如果审批链要求那些并不真正受决策影响的相关方签字,就会增加协调负担,拖慢交付,也没有让责任更清楚。
- 可自动化的手工工作。在系统之间搬运数据、生成标准报表、对不同输入套用同一套规则,这类任务都适合自动化。让熟练员工去做这些事,会占用本该投入到需要判断力的工作上的精力。
- 没有明确产出价值的流程步骤。有些步骤之所以存在,只是因为一直都有,去掉它们也不会明显影响最终产出的质量。这些步骤只消耗资源,对结果没有帮助。
资源分配失误:
- 人手不足或负担过重的角色。当团队成员承担的职责超出自身能力时,产出质量会下降,交付也越来越不可靠。问题不在个人,而在于这种工作量结构本身难以为继。
- 过时或不充分的工具。工具在性能、功能或与其他系统的集成上跟不上当前的工作需求,就会给每一项依赖它的任务增加摩擦。
- 关键工作流组件的资金约束。在运营的关键环节上压缩投入,短期能省下一点成本,中期却会造成交付失败,因为团队只能用变通办法顶替本该到位的资源。
哪怕只解决其中一个结构性问题,也能看到可衡量的改善。复杂系统中的瓶颈往往不会消失,而是会转移。每解决一个,此前被主要瓶颈掩盖的下一个约束就会显露出来。正因为如此,系统地管理瓶颈会让改善随时间不断累积。
如何尽早发现瓶颈
早期识别是唯一不需要进行进度恢复的干预节点。一旦瓶颈造成延误,成本就已经产生;问题就变成了在解决之前还会累积多少额外延误。能够在产生可见产出失败之前识别约束信号的检测实践,因此比反应式监控更具价值——它们将干预窗口从损害发生之后前移到损害发生之前。
预测性分析——使用历史绩效数据和领先指标在新出现的约束演变为运营危机之前对其加以识别——是与之相对应的结构化方法。它通过建立基线绩效模式并监测历史上先于瓶颈出现的偏差来发挥作用,而不是等到瓶颈本身在产出指标中显现。
表明瓶颈正在出现的运营信号:
- 在各周期之间无法消解的积压堆积。不断增长的未完成工作队列——而非围绕稳定水平波动的队列——表明接收速率超过了完成能力。其结构性含义是减少工作量或提升能力,而非加大努力强度。
- 错过截止日期成为常态而非例外。在高复杂度时期偶尔错过截止日期在运营上是正常的。当错过情况在团队成员和项目类型间持续出现时,规划假设——范围、资源分配或时间线——便不再与运营现实相符。
- 资源约束在没有计划缓解的情况下收紧。当项目开始时尚可接受的人员、预算或工具约束随着项目推进而变得具有约束性时,剩余工作将在原始计划未曾考虑的条件下交付。
- 团队投入度指标下降。持续的低士气既是结构性问题的症状,也是绩效进一步下降的原因。它通常源自可识别的来源——超负荷、优先级不清晰、工具不足——这些在正确诊断后是可以解决的。
- 产出质量下降。在投入努力保持稳定的情况下随时间推移恶化的质量指标,表明当前结构无法在现有吞吐水平下维持质量。
- 沟通失败和协调缺口。当团队成员不了解他人正在进行的相关工作,或当决策在未让需要相关信息的相关方参与的情况下作出时,其代价通常以返工、冲突或遗漏依赖关系的形式在后期被发现。
一种系统化的早期检测方法是主动干扰测试——在工作流中有意引入受控故障,以识别系统在何处崩溃,并在这些故障在不受控环境中发生之前建立响应预案。这种实践,在技术情境中有时被称为混沌工程,将弹性视为经过设计的产物,而非理所当然的存在。了解更多:项目管理。
潜在的解决方案
解决瓶颈时,要分清哪些措施针对的是症状,哪些针对的是结构性原因。短期方案用来稳定局面,长期方案则改变产生瓶颈的结构。只用短期方案,瓶颈会在同样的结构节点上反复出现;只用长期方案,在重新设计完成之前,眼下的问题又一直得不到解决。
短期解决方案:
- 资源再平衡。把负担过重的成员或角色手上的工作分给负担较轻的人,可以在不改动底层结构的情况下缓解眼前的约束。这种再平衡本来就是临时性的,它为长期的结构性调整腾出空间,同时避免交付受到进一步影响。
- 临时的流程简化。在瓶颈点上降低流程复杂度,例如去掉可选的审查环节、合并审批步骤,吞吐量马上就能提升。简化后的流程未必是长期最优的,但在长期方案成形之前,它能先解决眼前的约束。
- 有针对性的技能开发。与其开展宽泛的培训计划,不如直接针对造成瓶颈的那项技能差距安排培训,这样见效最快。范围有意收得很窄:先解决约束,约束消除后再扩大培训范围。
- 对大批量手工任务的选择性自动化。有些任务本身并不复杂,却占用了团队不成比例的精力。把这些特定任务自动化,就能把工作量从约束点上移走,而不必重新设计周边流程。自动化的范围应当对准眼前的瓶颈,不必覆盖所有可以自动化的地方。
- 沟通结构改进。在协调出问题的环节建立更清晰的沟通规则,明确谁有决策权、进展按什么格式更新、问题沿什么路径上报,就能减少助长瓶颈的协调负担。
长期解决方案:
- 流程重新设计。在结构层面重建流程,去掉不必要的步骤,重新设计交接,调整工作顺序,才能触及根本原因,而不是绕着问题打转。重新设计应当拿引发它的那个瓶颈来检验,而不是凭空设计。
- 系统化的能力建设。面向全团队、专门弥补反复出现的能力差距的培训计划,可以降低技能不足在今后项目中造成瓶颈的频率。这类投入的回报会在多个项目周期中逐步累积。
- 工具升级。有些工具因为性能受限、集成失败或功能缺失而不断制造摩擦。换成符合当前运营要求的工具,就能消除一个会延续到每个依赖这些工具的项目中的结构性约束。
- 深度流程自动化。在人工判断几乎不增加价值的环节,把整个工作流而不只是单个任务自动化,就能彻底消除一类瓶颈,不必再一个周期一个周期地处理。这样做需要更多的实施投入,但长期带来的吞吐收益也相应更大。
- 主动的约束规划。把瓶颈识别与缓解直接纳入项目规划,而不是等问题出现后再应对,可以在整个项目生命周期中降低瓶颈出现的频率和严重程度。
有趣事实
各行各业的工作流瓶颈都有相似的规律:瓶颈造成的影响大多来自少数几个结构性原因,也就是人员配置结构、能力差距和工具是否够用。因此,针对这些方面进行有的放矢的调整,往往能带来不成比例的效率提升。延伸阅读:运营团队的任务管理软件。
相关文章:
有关流程改进的洞见,请浏览混合项目管理:结合敏捷与瀑布的平衡方法。
要提升团队效率,请查看什么是看板?可视化和管理工作流的指南。
要更好地进行资源管理,请阅读资源管理流程:通过有效规划改变项目的成功。
结论
管理工作流瓶颈是一项有固定步骤的运营实践:找出约束,分清症状和原因,先用短期措施稳住局面,再实施结构性修复,防止问题复发。瓶颈管理做得好的组织和做不好的组织,差距很少在于认识,更多在于有没有养成及早发现、有章法地解决问题的习惯。Taskee 的任务可视化与工作流跟踪功能在这两方面都能提供支持:在瓶颈造成延误之前让领先指标显现出来,并提供必要的运营背景,帮助你针对原因而不是症状来设计应对措施。
推荐阅读
"Theory of Constraints"
关于在现代商业环境中理解和解决运营瓶颈的全面指南。
"Lean Process Improvement"
通过系统化方法精简工作流并消除浪费的策略。
"The Phoenix Project"
瓶颈管理在 IT 运营中的实际应用,配以实用案例研究。