<p>What they are talking about is <a href="https://en.wikipedia.org/wiki/Kaizen" rel="noreferrer">Kaizen</a> <a href="http://www.kaizenworld.com/kaizen-glossary.html" rel="noreferrer">5M</a> (Man, Machine, Material, Method, Measurement). It is approach to continuous improvement at every station in the process and the Ms are possible points of improvement and to which there is a corresponding question (5Qs). Sometimes Environment is added for 6th, like in this process that <a href="http://www.transition-support.com/6ms_to_6qs.pdf" rel="noreferrer">explains how to construct the questions</a> using the <a href="https://en.wikipedia.org/wiki/Ishikawa_diagram" rel="noreferrer">Ishikawa diagram</a>. These are pretty much essentials of the <a href="https://en.wikipedia.org/wiki/Toyota_Production_System" rel="noreferrer">TPS</a> / <a href="https://en.wikipedia.org/wiki/Lean_manufacturing" rel="noreferrer">Lean Manufacturing</a>. But the improvements are not in utilization, they are improvements in quality. You never strive for utilization as that is counterproductive to the <a href="https://devops.stackexchange.com/a/525/228">throughput of the system</a>.</p>

<p>It is important to understand that Man, Machine, Material, Method and Measurement are not easily separated. Sometimes Machine, Material and Measurement come on one side together and Man and Method on the other side. As you can replace a Man and a Method on that work station.</p>

<p>In terms of software development, you have Software (Machine), Issues (Material), Code Quality/Acceptance (Measurement), Man (Programmer) and Method (Development Process). The man trains on the machine and becomes familiar with it, with the material being worked on, understands the measurement required, learns the process. All those are living in the Man's brain and so are not easily separated once learned. Changing a Method is only possible if the Man has not fully internalized it yet, otherwise it gets easier to change Man and Method. Also Machine, Material and Measurement are often tied together through automation and configuration. That is why those are being drawn on opposite sides of the diagram.</p>

<p>If you read the book carefully, it does not really talk about utilization other than on the bottleneck of a value chain. In order to elevate and exploit the bottleneck. Several methods are employed for that in the book, including <a href="https://en.wikipedia.org/wiki/Kanban_(development)" rel="noreferrer">Kanban</a>. </p>

<p>You don't want to optimize the individual stations of your process (Customer->Support->Development->Review->Testing->User Acceptance->Deployment->Customer), but you need to model the transitions between those work stations, their dependencies and to monitor <a href="https://en.wikipedia.org/wiki/Work_in_process" rel="noreferrer">Work In Process</a> (WIP) moving through the system. Usually through an <a href="https://en.wikipedia.org/wiki/Issue_tracking_system" rel="noreferrer">Issue Tracking Software</a> (or Kanban system), which is equivalent to materials tracking in manufacturing. Where the WIP piles up in front of the work station in your critical chain process, you will find your bottleneck and that is the place where you want to optimize using Kaizan (5Ms,5Qs) </p>

<p><strong>Notice:</strong> <em>I've added Customer both at the start and the end of your process, as each value chain has to start and end with a Customer otherwise it does not represent value to the company.</em></p>

CC BY-SA 3.0
2017-03-15T01:02:42.237Z
2017-03-15T01:02:42.237Z
2017-04-13T13:01:29.297Z
Jiri Klouda
<p>In <a href="https://www.amazon.co.uk/Phoenix-Project-DevOps-Helping-Business-ebook/dp/B00AZRBLHO" rel="noreferrer">The Phoenix Project</a> when on one of the tours of the plant we're told that each workstation is a combination of Person, Machine, Measurement, and Process. This makes a lot of sense, after all we have people, servers, KPIs, and instructions.</p>

<p>However, whenever I model a process (the lifecycle of a Support Ticket for example) I struggle to take this into account.</p>

<p>My workflow states typically include:</p>

<ul>
<li>First Line Assistance</li>
<li>Tech/Dev/More Technical Team Assistance</li>
<li>Code Review</li>
<li>Testing</li>
<li>UAT</li>
<li>Deployment</li>
</ul>

<p>I can quite easily measure the cycle types, throughputs, and queue times of each of these states but I don't feel this does justice to the Man, Machine, Method concept. It's an idea which is frustratingly hinted at in the book but not expanded on...</p>

<p>We know that wait time is a function of utilisation so monitoring how busy people and servers (the finite resources) are is critical. Is there any defined process for expanding my measurements from a simple finite state machine to the Man, Machine, Method, Process idea in the book?</p>

<culture><metrics><systems><the-phoenix-project>
How to model Man, Machine, Measures, and Process in a DevOps world?
Liath
# How to model Man, Machine, Measures, and Process in a DevOps world?

(Asked by: username_0 on 2017-03-06)

In [The Phoenix Project](https://www.amazon.co.uk/Phoenix-Project-DevOps-Helping-Business-ebook/dp/B00AZRBLHO) when on one of the tours of the plant we're told that each workstation is a combination of Person, Machine, Measurement, and Process. This makes a lot of sense, after all we have people, servers, KPIs, and instructions.

However, whenever I model a process (the lifecycle of a Support Ticket for example) I struggle to take this into account.

My workflow states typically include:

* First Line Assistance
* Tech/Dev/More Technical Team Assistance
* Code Review
* Testing
* UAT
* Deployment

I can quite easily measure the cycle types, throughputs, and queue times of each of these states but I don't feel this does justice to the Man, Machine, Method concept. It's an idea which is frustratingly hinted at in the book but not expanded on...

We know that wait time is a function of utilisation so monitoring how busy people and servers (the finite resources) are is critical. Is there any defined process for expanding my measurements from a simple finite state machine to the Man, Machine, Method, Process idea in the book?

**Tags:** culture, metrics, systems, the-phoenix-project


---

## 1 answers

### Answer by username_1 on 2017-03-15. Score: 7 | Accepted answer

What they are talking about is [Kaizen](https://en.wikipedia.org/wiki/Kaizen) [5M](http://www.kaizenworld.com/kaizen-glossary.html) (Man, Machine, Material, Method, Measurement). It is approach to continuous improvement at every station in the process and the Ms are possible points of improvement and to which there is a corresponding question (5Qs). Sometimes Environment is added for 6th, like in this process that [explains how to construct the questions](http://www.transition-support.com/6ms_to_6qs.pdf) using the [Ishikawa diagram](https://en.wikipedia.org/wiki/Ishikawa_diagram). These are pretty much essentials of the [TPS](https://en.wikipedia.org/wiki/Toyota_Production_System) / [Lean Manufacturing](https://en.wikipedia.org/wiki/Lean_manufacturing). But the improvements are not in utilization, they are improvements in quality. You never strive for utilization as that is counterproductive to the [throughput of the system](https://devops.stackexchange.com/a/525/228).

It is important to understand that Man, Machine, Material, Method and Measurement are not easily separated. Sometimes Machine, Material and Measurement come on one side together and Man and Method on the other side. As you can replace a Man and a Method on that work station.

In terms of software development, you have Software (Machine), Issues (Material), Code Quality/Acceptance (Measurement), Man (Programmer) and Method (Development Process). The man trains on the machine and becomes familiar with it, with the material being worked on, understands the measurement required, learns the process. All those are living in the Man's brain and so are not easily separated once learned. Changing a Method is only possible if the Man has not fully internalized it yet, otherwise it gets easier to change Man and Method. Also Machine, Material and Measurement are often tied together through automation and configuration. That is why those are being drawn on opposite sides of the diagram.

If you read the book carefully, it does not really talk about utilization other than on the bottleneck of a value chain. In order to elevate and exploit the bottleneck. Several methods are employed for that in the book, including [Kanban](https://en.wikipedia.org/wiki/Kanban_(development)).

You don't want to optimize the individual stations of your process (Customer->Support->Development->Review->Testing->User Acceptance->Deployment->Customer), but you need to model the transitions between those work stations, their dependencies and to monitor [Work In Process](https://en.wikipedia.org/wiki/Work_in_process) (WIP) moving through the system. Usually through an [Issue Tracking Software](https://en.wikipedia.org/wiki/Issue_tracking_system) (or Kanban system), which is equivalent to materials tracking in manufacturing. Where the WIP piles up in front of the work station in your critical chain process, you will find your bottleneck and that is the place where you want to optimize using Kaizan (5Ms,5Qs)

**Notice:** *I've added Customer both at the start and the end of your process, as each value chain has to start and end with a Customer otherwise it does not represent value to the company.*


---

