The Phoenix Projectでは、工場見学の1つで、各ワークステーションが人、機械、測定、プロセスの組み合わせであると言われます。結局のところ、人、サーバー、KPI、および指示があります。
ただし、プロセス（サポートチケットのライフサイクルなど）をモデル化するたびに、これを考慮するのに苦労します。
私のワークフローの状態は通常次のとおりです。
これらの各状態のサイクルタイプ、スループット、およびキュー時間を非常に簡単に測定できますが、これがMan、Machine、Methodの概念に正しかったとは思いません。それはイライラして本で示唆されているが、拡張されていないアイデアです...
待機時間は使用率の関数であることがわかっているため、人とサーバー（限られたリソース）の混雑度を監視することが重要です。私の測定を単純な有限状態機械から本の人、機械、方法、プロセスのアイデアに拡張するための定義されたプロセスはありますか？
回答:
彼らが話しているのは、カイゼン 5M（人、機械、材料、方法、測定）です。これは、プロセスのすべてのステーションでの継続的な改善へのアプローチであり、Msは改善の可能なポイントであり、それに対応する質問があります（5Q）。このプロセスのように、石川図を使用して質問を作成する方法を説明するように、環境が6日追加される場合があります。これらはTPS / リーンマニュファクチャリングの本質的なものです。しかし、改善は利用率ではなく、品質の改善です。システムのスループットに逆効果であるため、利用に努めません。
人間、機械、材料、方法、測定は簡単に分離できないことを理解することが重要です。時には、機械、材料、測定が一方に、人間と方法が他方に来ることがあります。あなたはそのワークステーションで人と方法を置き換えることができます。
ソフトウェア開発に関しては、ソフトウェア（機械）、問題（素材）、コードの品質/受け入れ（測定）、人（プログラマー）、方法（開発プロセス）があります。男性は機械でトレーニングを行い、作業中の材料に慣れ、必要な測定を理解し、プロセスを学習します。それらはすべて人間の脳内に住んでいるので、一度学習すると簡単に分離されません。メソッドの変更は、人間がまだ完全に内部化していない場合にのみ可能です。そうでない場合は、人間とメソッドを変更するのが簡単になります。また、機械、材料、および測定は、多くの場合、自動化と構成によって結び付けられています。それが、それらがダイアグラムの反対側に描かれている理由です。
この本を注意深く読んだ場合、バリューチェーンのボトルネック以外の利用についてはあまり触れていません。ボトルネックを高めて活用するため。この本では、かんばんを含むいくつかの方法が採用されています。
プロセスの個々のステーションを最適化する必要はありません（顧客->サポート->開発->レビュー->テスト->ユーザー受け入れ->導入->顧客）、これらのワークステーション間の移行をモデル化する必要があります、監視するそれらの依存関係と仕掛品を（WIP）は、システムを通って移動します。通常、問題追跡ソフトウェア（またはかんばんシステム）を使用します。これは、製造における資材追跡と同等です。クリティカルチェーンプロセスでWIPがワークステーションの前に積み重なる場所では、ボトルネックが見つかります。これがKaizan（5Ms、5Qs）を使用して最適化する場所です。
注： 各バリューチェーンは顧客で開始および終了する必要があるため、プロセスの開始および終了の両方で顧客を追加します。