一千萬個為什麽

搜索

如何衡量人的利用率?



鳳凰項目單圖在整本書中顯示,隨著一個人的工作量增加到高達90%,他們的等待時間呈指數增長。實際上,它在書中聲稱:

等待時間=(忙/百分比)

因此,如果每周40小時中有35個資源忙碌,那麽:

Wait Time = 0.875/0.125  = 8

但是,如果某個資源每周有40個小時中有39個忙,那麽:

Wait Time = 0.975/0.025  = 39

這是工作流程中等待的次數的乘積。這顯然是我們想要關註的事情!

所以,考慮到所有這些,我們將人員的利用率保持在合理的水平顯然是至關重要的。鑒於本書堅持這一公式的重要性,它就如何衡量這些價值提供了很少實際的建議。我的問題是,你怎麽能實際衡量一個人的百分比繁忙?

轉載註明原文: 如何衡量人的利用率?

一共有 1 個回答:

TL;DR: It is the wrong thing to measure. By measuring and increasing utilization in employees across the board, you create problems in the system and reduce overall throughput.

吞吐量會計

What you actually want to measure is throughput, inventory and operating expense all together and try to reduce inventory and reduce operating expenses while at the same time maximizing throughput. This method is known as 吞吐量會計.

在軟件開發中,庫存是尚未為客戶帶來好處的工作。任何已經完成但尚未發布的內容。吞吐量是對正在發布的客戶有用的工作量。所做的任何對客戶沒有直接作用的工作都被記錄為運營費用。

簡單的系統

In a 簡單的系統 with single human or multiple humans working independently with independent equipment as much as each one does will directly increase the throughput of the whole system. This leads to the common misconception that is basis for this question that increasing human utilization will lead to increased throughput in all systems. But you still measure the throughput of the system, inventory and operating expenses.

復雜系統

In a 復雜系統, even with as little as two dependencies, increased utilization of one part of the system can directly lead to decrease of utilization in the bottleneck, which decreases throughput of the whole system. Any increase in productivity outside of the bottleneck is a mirage.

Example: Team of software engineers has all code reviewed by the software architect, who also makes plans for new features. This person is a bottleneck, code not reviewed by the architect will simply increase inventory, if the architect does not have time, no new features will be properly planed. If you start measuring utilization of software engineers, they will each try to make more changes, rather than better changes. The time the architect will need to spend on each change will increase and the total time spent reviewing will increase further by the increased amount of changes to a point where no time would be left to plan new changes. Eventually the whole system grinds to a halt. If on the other hand they decrease utilization, even spend time idling, they spend longer on each change or peer reviews, this could lead to decrease in time required for reviews and eventually increase in throughput. This is just single team with 2 dependencies. Engineers depend on architect for new changes to be planed and for changes to be reviewed.

很明顯,在正確管理瓶頸並試圖獲得<�瓶頸生產力(其中小時增加)時,整個系統的吞吐量為小時即可。

這是鳳凰項目的真實信息,並直接來自約束理論 Eliyahu M. Goldratt。您也可以閱讀關於利用率思考vs吞吐量思考的文章。我還建議閱讀關鍵鏈過程管理

Remember: What you measure is what you get. And you definitely DO NOT WANT to get increased individual utilization. A road to Hell is paved with good intentions.