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

Не нашел возможности отредактировать свой предыдущие пост, поэтому пишу отдельный. Забыл указать, что рассмотрение работы с воронкой продаж в статье по приведенной ссылке сделано именно с точки зрения теории ограничений. Да, воронка продаж — не совсем обычный объект для теории ограничений. Именно из за того, что на каждом этапе происходят огромные потери (коэффициент конверсии 0,01 и меньше). Один из выводов — при анализе необходимо двигаться от «конца» воронки к «началу». Другой вывод — необходимость учитывать элементы, которые в обычной воронке продаж вообще неучитываются, например правила компании и ее убеждения. Они как раз и находятся в самом начале «модернизированной воронки продаж». Соответствующая статья с большим количеством примеров ограничивающих убеждений опубликована здесь www.e-xecutive.ru/management/sales/1986158-integrirovannaya-truba-prodazh-bolshe-chem-voronka. Кстати, Роман Горбачев в своем последнем примере обсуждаемой статьи как раз приводит пример, когда убеждение является ограничивающим (шрам и кошачий запах)

Руслан, мне кажется, для верхнего уровня управления (где у вас дорожная карта), подходит метод критической цепи (управление проектами по теории ограничений). Одновременно он бы учел ограниченность ресурсов и выстроил бы проекты в зависимости от их загрузки. Рассматривали ли вы такую возможность? Если да, по какой причине отказались от использования?
По сравнению с предыдущей публикацией я заметил, что вы перестали оценивать длительность задач (по крайней мере не стало черных квадратов с цифрами). По какой причине?
Теория ограничений предполагает, что для управления потоком задач необходимо ограничивать число задач во всей системе на основе пропускной возможности ограниченного ресурса. Мне же показалось, что вы ограничиваете непосредственное число задач у него. Но ведь есть еще задачи, которые уже в системе, но до него просто не дошли?