В головах одних граждан проекты и процессы смешаны до полного слияния, в головах способных их отличить друг от друга – категорически противопоставляются. Результатом этого является парадоксальная ситуация, когда эти две взаимно-дополняющие сущности разделены нерушимой стеной: в управленческом сознании, в инструментарии автоматизации и далее везде. Особенно мощно это разделение в средствах автоматизации, которые просто в принципе относятся к разным классам – системы управления проектами и системы автоматизации разных процессов (документооборот, хелпдеск).
Движущим мотивом для данного материала послужило понимание, что нередко встречаются бизнес-задачи, которые не могут быть эффективно разрешены в рамках только одного из подходов. Например, крупные проекты, подразумевающие строительство типовых сравнительно малых объектов, но в большом количестве. Примеры – проекты комплексного оснащения, в которых автор принимал участие, проект веб-камер для выборов, т.е. любые проекты, где возможно типизировать и параметризировать предмет деятельности.
Целью настоящего материала является отчетливое изложение общности и различий, а так же размышления об интеграции и происходящих из оной сложностях.
Определения:
Прое́кт (от лат. projectus — брошенный вперед, выступающий, выдающийся вперёд) — согласно новому стандарту ISO 21500 — уникальный набор процессов, состоящих из скоординированных и управляемых задач с начальной и конечной датами, предпринятых для достижения цели. Достижение цели проекта требует получения результатов, соответствующих определённым заранее требованиям, в том числе ограничения на получения результатов, таких как время, деньги и ресурсы. (с) Википедия
Минимальный квант работы проекта будем для простоты называть ЗАДАЧЕЙ.
С определениями процесса – несколько сложнее:
Процесс — совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующая входы в выходы» или в английском варианте «Process — set of interrelated and interacting activities which transforms inputs into outputs». (с) ИСО 9001:2000
Минимальный квант работы процесса назовем ШАГ.
На уровне бытовой эрудиции очевидно, что «проект» суть однократно исполняемый процесс, в котором каждый шаг исполняется не более одного раза. На этом сходство заканчивается, и начинаются отличия, сведенные в таблицу.
|
Сравнение |
Проект |
Процесс |
|
Подход |
Детерменистический. Хороший план должен быть выполнен без отклонений. |
Вероятностный. Хорошо поставленный процесс находится в пределах сроков исполнения на каждом шаге с достаточной вероятностью. |
|
Повторяемость |
Не подразумевается методологией. Каждый проект — уникален. |
Изначально подразумевается многократная повторяемость. |
|
Формат определения |
Единственная сущность – проект. Все вариации и изменения по сути разные версии одной сущности. |
Определяется двумя сущностями
Как правило, определение фиксируется для экземпляра в момент его порождения. Обычно в случае изменения определения (новой версии) уже стартованные процессы происходят по определению на момент старта, вновь стартуемые – по новой версии определения. |
|
Совокупная продолжительность |
Большая (недели, месяцы и годы) |
Небольшая (часы, дни, недели) |
|
Определенность продолжительности |
Плановая продолжительность определена. Остальное – отклонения. |
В общем случае можно определить только максимальную продолжительность, либо несколько значений максимальной продолжительности в зависимости от условных ветвлений процесса и числа повторений циклических участков. |
|
Параметризация |
Неограниченный и не структурированный список «входных» параметров. Параметры учитываются на фазе планирования, изменения параметров приводят к перепланированию (версии) |
Предопределенный список входных и выходных параметров. Порядок исполнения процесса (число и последовательность шагов) зависят от значения параметров на этапе выполнения процессов. |
|
Вариативность планирования |
Структура задач определяется на фазе планирования. Все задачи должны быть выполнены. |
Порядок и количество выполняемых шагов зависят от параметров. Не все шаги обязательно должны быть выполнены в конкретном экземпляре процесса. |
|
Кратность выполнения задач/шагов |
Однократное выполнение любой задачи |
Возможность циклического возврата и неоднократного выполнения шагов внутри экземпляра процесса. |
|
Параллельное выполнение |
Параллельное выполнение задач разными ресурсами, перепланирование в случае ресурсного конфликта. |
Изначально заданное массово-параллельное выполнение шагов, выделение ресурса в порядке приоритета с ожиданием шагов в очереди. |
|
Метод назначения ресурса |
Выполняющий задачу конкретный ресурс определяется на старте либо назначается административно. |
Тип необходимого ресурса определяется определением процесса. Динамическое распределение шагов по ресурсам требуемого типа через автоматизированный или ручной «подхват из очереди». |
|
Предмет управленческого контроля и аналитики |
Проект в целом и состояние задач. |
Статистика по совокупности процессов. |
|
Методы управленческого анализа |
Аналитический. Отклонения от плана, риски, проблемы и т.д. |
Статистический. Статистика и OLAP в разрезе шагов, состояний, элементов данных. Выделение отклонений, анализ экземпляров с отклонениями (аналогично проекту). |
|
Способ прогнозирования |
Планирование с расчетом ресурсов. |
Оценка вероятности исполнения за определенное время исходя из прогнозируемой плотности потока стартующих процессов и вероятностных характеристик задаваемых параметров. Моделирование. |
|
Соотношение трудозатрат продолжительности |
Общей практикой является связывание трудоемкости задачи с продолжительностью через ресурс. Как правило, длительность задачи равна времени ее выполнения при 100% занятости назначенного ресурса. Продолжительность проекта определяется «критическим путем» |
Продолжительность шага не связано с трудоемкостью в пределах этого шага. Максимальное время нахождения процесса на определенном шаге и его трудоемкость нормируются отдельно. Как правило, трудоемкость отдельного шага и всего процесса существенно (в разы, на порядки) меньше, чем время на шаг/время по всему маршруту. Для ветвящихся процессов невозможно определение единого пути, время по разным путям – разное. |
|
Способ управленческой реакции |
Фокусировка на конкретных задачах. Перепланирование исходя из приоритетов, целей и ограничений проекта. |
Управление ресурсами по типам. Увеличение или уменьшение ресурсов исходя из статистических оценок по совокупности множества процессов. |
|
Управление приоритетами |
Ручной режим, каждый конфликт ресурсов требует принятия решений. |
Автоматическое упорядочивание очереди в соответствии с заданными приоритетами. |
|
Вложенность |
Проекты /подпроекты могут быть структурированы в единое дерево |
Не предопределенная. Шаг процесса может инициировать экземпляр процесса другого типа, как с ожиданием и использованием результата (в составе процесса), так и с продолжением породившего процесса без ожидания результата. Единая иерархия вложенности отсутствует. |
|
Набор данных |
На старте не определен полностью, единый для всего проекта. |
Набор данных процесса определяется по составу и типу на уровне определения процесса, но уникален по значениям для каждого экземпляра процесса. Разные шаги работают с разным подмножеством из набора данных процесса, те или иные элементы данных, не определенные ранее, определяются в ходе выполнения шагов процесса. Для каждого шага определен по типам набор входных и выходных данных. Ветвление процесса может зависеть от данных. |
|
Структура управления |
Централизованно-иерархическая. «Управляющий проектом» осуществляет управление прямыми ресурсами и координацию выделенных ресурсов в «матричных» структурах. Каждый проект имеет своего «хозяина» |
Полностью распределенная. Управляющий определенным типом ресурсов отвечает за соответствие фактических параметров выполнения шагов заданным. Определение процесса (тип процесса) имеет функционального владельца, но каждый экземпляр процесса так же имеет инициатора-«бенефициара», не управляющего ресурсами. |
Вот так получается, что при наличии некоторой условной общности — вещи это ну прямо очень разные. Можно ли примирить их и в рамках единой модели заставить работать и проекты и процессы? Можно ли сделать процессы частью проекта? Я уверен, что не только можно, но и нужно! И я даже имею мысли как сделать это красиво.
Но пока на этом все. Оставшиеся многобуков о путях интеграции коня и лани неожиданно заинтересовали людей, разрабатывающих софт для управления бизнесом. И потому продолжение либо появится в формате «вот как оно сделано», либо в формате теоретизирования, если в дело не пойдет. Оставайтесь в эфире!