在菲尼克斯项目中,当参观工厂的其中一个时,我们被告知每个工作站都是人员,机器,测量和过程的组合。这毕竟很有意义,毕竟我们有了人员,服务器,KPI和说明。

但是,每当我对流程进行建模(例如,支持通知单的生命周期)时,我都很难做到这一点考虑在内。

我的工作流程状态通常包括:


一线协助
技术/开发/更多技术团队协助
代码审查
测试
UAT
部署

我可以很容易地测量每个状态的周期类型,吞吐量和排队时间,但是我不认为这样做人,机,方法概念的正义。这是一个令人沮丧地在书中暗示的想法,但并未在...上进行扩展。

我们知道等待时间是利用率的函数,因此监视人员和服务器(有限资源)的繁忙程度是很重要的。危急。书中有没有定义好的过程可以将我的测量范围从简单的有限状态机扩展到“人,机器,方法,过程”概念?

#1 楼

他们所说的是Kaizen 5M(人,机器,材料,方法,测量)。它是过程中每个站点的持续改进方法,MS可能是改进点,并且存在相应的问题(5Qs)。有时,环境会添加到第六行,例如在此过程中说明如何使用Ishikawa图构造问题。这些是TPS /精益生产的基本要素。但是改进不是在利用率上,而是质量的提高。您永远不会为利用率而努力,因为这会对系统的吞吐量产生不利影响。有时,机器,材料和测量在一侧同时出现,而人与方法在另一侧。您可以在该工作站上替换人工和方法。

在软件开发方面,您拥有软件(机器),问题(材料),代码质量/验收(度量),人工(程序员)和方法(开发过程)。这个人在机器上训练并熟悉它,正在处理的材料,了解所需的度量,学习过程。所有这些人都生活在人的大脑中,因此一旦学会就很难分离。仅当Man尚未完全内部化时,才可以更改方法,否则更改Man和Method会变得更加容易。此外,机器,材料和测量通常通过自动化和配置结合在一起。这就是为什么在图表的相反两边绘制这些内容的原因。为了提升和利用瓶颈。书中采用了几种方法,包括看板。

您不想优化流程中的各个工作站(客户->支持->开发->审查->测试->用户接受->部署->客户),但是您需要对这些工作站之间的转换进行建模,它们的依存关系并监视在系统中移动的在制品(WIP)。通常通过问题跟踪软件(或看板系统),它等同于制造中的物料跟踪。在关键链过程中,在制品堆积在工作站前面的位置,您会发现瓶颈,而这就是您要使用Kaizan(5Ms,5Qs)进行优化的地方

注意:已在流程的开始和结束时都添加了客户,因为每个价值链都必须以客户为起点和结尾,否则就不会代表公司的价值。