Теория ограничений и доска задач

cartmendum — 07.10.2010 Те, кто читал «Цель» Голдратта, наверняка помнят три сакраментальных вопроса, которые задал Элайя, что бы испортить радость главного героя от покупки нового робота на заводе:
- Стали ли вы выпускать больше?
- Снизились ли ваши запасы?
- Уволили ли вы кого-либо?

Эти вопросы вытекают из "бухгалтерии" теории ограничений, которая на верхнем уровне достаточно проста и выражается простой формулой:
Где CF - Cash Flow (выручка), T – Throughput (производительность по денежному потоку), OE – Operation Expenses (операционные расходы), I – Inventory (запасы в системе)

Штуковина d( )/dt обозначает производную по времени или скорость изменения определенной величины.

Измерения на нашей доске начались именно с этих величин, но в несколько иной трактовке, так как ИТ отдел является вспомогательным подразделением в компании и по большому счету деньги только тратит.

В нашем случае этим 4-м переменным был выдан следующий смысл:

• CF – решенные бизнес задачи (абсолютное число и взвешенная сумма)
• T – число бизнес задач, решаемых в неделю, наша производительность (опять же, абсолютное число и взвешенная сумма)
• OE – задачи, которые нам приходится решать для «поддержания своего существования», например багфиксы, устранение факапов, внутренние задачи, не несущие прямой ценности бизнес-дивизионам компании (мы их называем Queue Jumper, так как обычно они возникают с приоритетом «бросить все и сделать»)
• I – начатые, но незавершенные задачи (в терминах доски, это любая задача, покинувшая колонку New)

Если бы мне пришлось иметь дело с деньгами, то это немножечко усложнило бы бухгалтерию. В этом случае пришлось бы следовать рекомендациям Детмера для некоммерческих учреждений (описано в его книжке "Теория ограничений Голдратта"), но в любом случае это бы ничего не испортило.

Каждая из этих переменных измеряется одновременно и как абсолютное число задач, и как их взвешенная сумма (у каждой задачи есть свой вес, обозначающий наше понимание ее трудоемкости). Пока я не могу сказать, что такой набор избыточен, в каждом случае полезны свои измерения.

Дальше как по книжке, что бы давать компании больше (увеличивать CF) можно:

1. Уменьшить OE (забить на все, что инициировано не бизнес-заказчиком). В свое время таким образом чуть не доигрались, накопив некислый «технологический долг» перед своими системами
2. Увеличить T. Сделать это можно несколькими способами, либо увеличив размер команды, либо подняв ее эффективность. Расширять штат (как и везде) никто не даст, а вот на эффективности положительным образом сказалась практика уменьшения числа задач в работе (I). При чем оказалось важно понизить именно абсолютное число задач, а не их взвешенную сумму. Как не крути, а 1 незавершенная задача в 10 очков выносит мозг заметно меньше, чем 5 незавершенных по 2 очка.

Это наш Throughput. Ежедневные измерения числа задач (синие точки) выполненных за последние 7 дней и их взвешенная сумма (зеленая линия).

Это наши «операционные затраты». До этой недели они составляли половину (а временами и больше) от общей выполненной работы. На этой неделе прямо скажем всплеск полезной работы. Есть несколько причин этому. Во-первых, серьезно перетрясли наше хозяйство в плане оптимизации. Во-вторых, закончился квартал и манагерский пыл по запросу «пипец-каких-важных-отчетов» угас. В-третьих, это не совсем операционные расходы, последнее время наши внутренние задачи стали решаться в планируемом порядке, а не по вакап-дривен методике. Эту метрику скоро надо будет переработать.

Это наши запасы незавершенного производства (Inventory). Как говорит Toyota Production System, чем ниже запасы, тем быстрее обнаруживаются проблемы и тем выше эффективность. Очень возможно. Эта величина измеряется с конца августа, и начались эти измерения именно потому, что объем «незавершенки» казался чрезмерно большим. Так и было. Стоило его понизить, как работать стало немножечко веселее.
 
А это все задачи на доске (Inventory + задачи, которые скоро им станут). Эта картинка показывает основное отличие нашего подхода от итеративной методологии (такой как Scrum, например). В скраме этот график имел бы пилообразную форму, с периодом равным длине итерации.


Это типа прелюдия к посту о том, почему иногда полезно взлабать свой тул и изобрести управление проектами заново, вместо того, что бы использовать что-то готовое.

Оставить комментарий

Популярные посты:

• Ранее
• Архив