如何在DevOps世界中为人,机器,度量和过程建模?


17

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

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

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

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

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

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

Answers:


6

他们正在谈论的是Kaizen 5M(人,机器,材料,方法,测量)。它是过程中每个站点的持续改进方法,MS是可能的改进点,并且存在相应的问题(5Qs)。有时,环境会添加到第六个位置,例如在此过程中说明如何使用Ishikawa图构造问题。这些是TPS / 精益生产的基本要素。但是改进不是在利用率上,而是质量的提高。您永远不会为利用率而奋斗,因为这会不利于系统吞吐量

重要的是要理解人,机器,材料,方法和度量不容易分开。有时,机器,材料和测量在一侧同时出现,而人与方法在另一侧。因为您可以替换该工作站上的“人”和“方法”。

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

如果您仔细阅读该书,除了价值链的瓶颈之外,它并没有真正谈论利用率。为了提升和利用瓶颈。书中采用了几种方法,包括看板

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

注意: 我已经在流程的开始和结束时都添加了Customer,因为每个价值链都必须以Customer开头和结尾,否则它并不代表公司的价值。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.