Тернистый путь к портфельному Kanban
В статье я опишу историю развития системы управления портфелем проектов в инжиниринговой компании Uniscan-research. Мы начинали с небольшой команды в 15 человек и одним проектом на всех, а пришли к команде, у которой более 70 человек и десятки R&D-проектов в параллели.
Сейчас буду вставлять свои пять копеек..
1. ДТР неправильно применили "нежелательное явление" оно ЯВЛЕНИЕ его можно наблюдать, а "ОТСУТСТВУЕТ что-то" наблюдать нельзя, поэтому это не может быть корневым НЖЯ.
2. В статье не указано КАК вы строили Цепь. Если как обычно "декомпозиция", то это не ТОС-подход и конечно он сломался (необходимость перестраивать цепи). Так как фокусировка на цели в ТОС-подходит происходит в самом начале при построении через Дерево Перехода.
3. При применении CCPM с эшелонированием по ресурсу ограничению у вас сразу выпало бы WIP на проекты, а не после.
4. Полноценная Цепь - не только выравнивание по ресурсам, но буфер защищающий проект от неопределенности. В статье не указано что вы использовали диагональный буфер. Это значит что полноценный CCPM не запутсился
5. Стоимость просрочки есть с ТОС — называется Деньго-День-Прохода (TDD) и считается немного по разному для разных сред. Для этого не нужна была книжка The Flow , а нужно было лучше разобраться с решениями ТОС для проектов.
6. Высокая неопределенность содержания - это нарушение базовой посылки CCPM , поэтому есть несколько вариантов адаптации: TameFlow approach, Reliable Scrum, Agile+CCPM, Pulse Management (http://pulsemanagement.org)
Теперь пару комментариев:
1. Для эшелонирования проектов и вообще для работы в ваших условиях мы сделали решение BIPULSE. Чтобы само пересчитывалось и был расчет прогноза.
2. Расчет индексов отставания TOC-way я сделал через 2 показателя в зависимости от типов проекта
http://pulsemanagement.org/rules-priority-mli/ Money Loss Rate
http://pulsemanagement.org/rules-priority-mlr/ Mone Loss Index
Это показатели в соответствии ТОС терминами: Стоимость задержки - сколько денег мы потеряем если не возьмем такой же проект в работу по расписанию.
Вы так все сложно завернули.
Когда столь простая задача канбан-методом решается вполне элегантно.
Спасибо за замечания. Не готов сейчас ввязываться в переписку о корректности и полноте использования теории ограничений. Статья не об этом.
Мы много экспериментировали вокруг TOC, и что-то прижилось, что-то нет. Как использовать CCPM для планирования и управления научными проектами с высокой степенью неопределенности - тема для отдельной большой статьи. Тем более что у нас во многих проектах scrum, так что там вообще не к чему прицепить CCPM. Да и не нужен он там.