首页 > 代码库 > 瓶颈法则
瓶颈法则
瓶颈法则源于约束理论(Theory of Constraints, ToC),由Dr Eliyahu Goldratt提出并于1984年发表于他的著作《The Goal》中。
法则指出:每个系统,无论运转优劣,都有至少一个约束(即瓶颈)限制其产能。
这个法则使我们可以推断出一个流程中响应时间和性能的限制,这是IT服务和软件开发项目的重要信息。
专注于通过解决瓶颈改善成效是提升盈利能力最快和最卓有成效的途径。瓶颈可以包括组织内部或外部的人、信息、工具、过程。
瓶颈是指在一个流程中限制或阻碍流动的环节,通常为子流程或者活动形式。瓶颈处的吞吐率会比其他环节要低。换言之,瓶颈是一项在工作通过系统最终完成的过程中,所花时间最长的一个环节。
例如,让我们看一下洗衣服的“清洗-烘干-折叠”这个流程:
瓶颈时烘干机,因为在整个流程中,这个环节的前置时间最长的。
过程涉及到不同的人、活动和工具,而且其中任何一点都具有不同的效率。因此,流程中的活动必须以顺序的方式执行,例如:
清洗-烘干-折叠
办理登机手续 - 行李检查 - 登机
需求定义- 分析 - 设计 - 实现 - 测试 - 交付
如何解决瓶颈?
在David Anderson的著作《看板方法》中,你可以更详细的了解如何解决由于产能受限资源造成的瓶颈以及由资源可用性不足造成的瓶颈。
这里我仅对解决瓶颈的方法进行总结:
- 充分利用瓶颈资源:确保资源仅从事他所专业从事的工作,分配其余活动给其他资源。
例如,我们有一个软件集成的专家,但是由于它参与了大量的项目因而成为了瓶颈。方法之一是只让他做集成任务,其他的任务分配给其他团队成员。 - 增加资源可用性 - 资源用更短时间回到可用状态。
例如:继承专家可以每周投身到每个项目中1天。更有效的方式是每周投身到每个项目2个半天,而非每周一整天。 - 自动化一部分活动。
- 增加资源(抬高瓶颈) - 通常是代价最大的方案。
继续上面的例子,增加资源相当于聘用另一个对软件集成领域具备必要的知识和经验的人。
原文:http://berriprocess.com/en/todas-las-categorias/item/47-ley-del-cuello-de-botella
瓶颈法则
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。