Инструменты методики АЦТ, часть 15: метод критического пути (CPM), метод освоенного объема (EVM), нотация BPMN и сети Петри

ОтДепартамент аналитики АЦТ

Это пятнадцатая статья цикла по инструментам методики «Аккордная цифровая трансформация». Завершаем подгруппу B2 «Визуализация и планирование» — инструменты B2-05, B2-06, B2-07 и B2-08.

Статья закрывает подгруппу B2. Если в прошлой части инструменты делали проект просто видимым, то здесь они его считают и проверяют. Четыре инструмента раскладываются на две пары. Метод критического пути (B2-05) и метод освоенного объема (B2-06) — это контроль проекта по срокам и деньгам. Нотация BPMN (B2-07) и сети Петри (B2-08) — описание и проверка процессов, одна наглядная, другая математическая. По трудоемкости все они выше базовых инструментов прошлой статьи: 24 часа на освоение у метода критического пути (средний), по 30–36 часов — у остальных трех (сложные).

B2-05 — Метод критического пути (Critical Path Method, CPM)

Откуда появился инструмент. Метод критического пути разработали в конце 1950-х американцы Морган Уокер из химической компании DuPont и Джеймс Келли из компьютерной фирмы Remington Rand. Задача была сугубо практической: на заводах DuPont простой во время плановых остановок и ремонтов стоил дорого, и требовался способ спланировать работы так, чтобы уложиться в кратчайший срок. В 1959 году они опубликовали работу «Critical-Path Planning and Scheduling», а расчеты впервые провели на компьютере UNIVAC. Сам термин «критический путь» пришел от разработчиков родственного метода PERT, который примерно тогда же создавали для проекта ракеты «Поларис». Известность CPM закрепил в 1966 году, когда его применили при строительстве башен Всемирного торгового центра в Нью-Йорке.

Суть и механика. Метод критического пути находит самую длинную по времени цепочку зависимых задач проекта — критический путь, который и определяет минимально возможный срок всего проекта. Задачи раскладывают по зависимостям, оценивают длительность каждой и строят сеть. Путь с наибольшей суммарной длительностью критичен: любая задержка на нем сдвигает срок всего проекта. Задачи вне критического пути имеют запас времени — их можно сдвигать в его пределах без вреда для срока. Метод показывает, на каких задачах нельзя терять ни дня, где есть свобода маневра и куда направить внимание руководителя.

Пример. В проекте параллельно идут несколько цепочек работ. Метод критического пути показывает: цепочка «проектирование → закупка оборудования → монтаж → пусконаладка» длиннее всех и занимает шесть месяцев — это и есть срок проекта. Задержка монтажа на неделю сдвинет сдачу на неделю. А оформление документации, идущее параллельно, имеет двухнедельный запас: его можно сдвигать, не трогая срок.

Границы применимости. CPM нужен там, где у проекта много взаимозависимых задач и важно понять реальный срок и узкие места по времени, — в строительстве, инженерии, сложных внедрениях. По методике это инструмент средней сложности (24 часа). Он работает с детерминированными оценками длительности: если оценки ненадежны, критический путь может оказаться другим, поэтому при высокой неопределенности его дополняют вероятностными методами (PERT). CPM считает сроки, но сам по себе не учитывает ограниченность ресурсов — для этого есть метод критической цепи (CCPM, B3-04). Результаты CPM удобно показывать на диаграмме Ганта (B2-02).

Чек-лист перед применением метода критического пути:

  • Составлен полный список задач проекта (на основе WBS, B2-04).
  • Определены зависимости между задачами: что должно завершиться до начала следующего.
  • Оценена длительность каждой задачи.
  • Построена сеть задач и рассчитан критический путь — самая длинная цепочка.
  • Определены резервы времени у задач вне критического пути.
  • Контроль сосредоточен на задачах критического пути; план обновляется при изменениях.

Типовые ошибки:

  • Внимание ко всем задачам поровну. Силы затрачивают на некритичные задачи с запасом, упуская критические. → Сосредоточить контроль на критическом пути.
  • Зависимости заданы неверно. Связи между задачами указаны небрежно, и критический путь рассчитан неправильно. → Тщательно выверять зависимости — основу расчета.
  • Оценки длительности неточны. Сроки задач взяты наугад, критический путь нереалистичен. → Оценивать длительность обоснованно; при неопределенности — диапазоном (PERT).
  • Путь рассчитали и забыли. При изменениях критический путь не пересчитывают, а он мог сместиться. → Обновлять расчет при сдвигах: критическим может стать другой путь.

B2-06 — Метод освоенного объема (Earned Value Management, EVM)

Откуда появился инструмент. Идея «освоенного объема» родилась еще в начале XX века у инженеров производства: они сравнивали фактически сделанную работу с планом и затратами, измеряя реальную выработку (понятие «заработанного времени» связывают с Фрэнком и Лилиан Гилбрет). В управление проектами концепцию принесло Министерство обороны США: в 1962 году «освоенный объем» формализовали в системе PERT/Cost, а в 1967-м закрепили как набор критериев C/SCSC для контроля затрат и сроков по оборонным контрактам. Систему долго считали громоздкой, и в 1996 году ее упростили и переименовали в Earned Value Management (32 критерия), а в 1998-м оформили национальным стандартом ANSI/EIA-748. Метод переняли NASA, энергетика и строительство.

Суть и механика. Метод освоенного объема оценивает состояние проекта, связывая три величины: сколько работы запланировали, сколько фактически сделали и сколько на это потратили. Ключевое понятие — «освоенный объем»: стоимость реально выполненной работы по плановым расценкам. Сравнивая его с плановым объемом, видят отставание или опережение по срокам; сравнивая с фактическими затратами — перерасход или экономию по деньгам. Главная ценность метода — раннее предупреждение: он показывает отклонения по стоимости и срокам не в конце, а задолго до него, и позволяет прогнозировать итоговую стоимость и дату, пока есть время вмешаться.

Пример. На середине проекта по плану должно быть выполнено работ на 5 млн рублей, фактически выполнено на 4 млн (это и есть освоенный объем), а потрачено 4,5 млн. Сравнение говорит сразу о двух проблемах: сделано меньше плана — отставание по срокам, и потрачено больше, чем стоит сделанное, — перерасход. Простой отчет «потрачено 4,5 из 10 млн» этого бы не показал: бюджет вроде цел. EVM же заранее сигнализирует, что при таком темпе проект выйдет и за сроки, и за бюджет.

Границы применимости. EVM оправдан на крупных и длительных проектах с понятным планом и бюджетом, где важен ранний контроль отклонений, — в гособоронзаказе, строительстве, инфраструктуре. По методике это сложный инструмент (30 часов): он требует дисциплины в учете факта и корректного базового плана. На маленьких и гибких проектах его аппарат избыточен. EVM измеряет ход против плана, поэтому опирается на качественные оценки (WBS, B2-04; сроки из CPM, B2-05); при недостоверном плане его цифры обманчивы.

Чек-лист перед внедрением метода освоенного объема:

  • Есть базовый план: объем работ (WBS), сроки и бюджет, распределенные по времени.
  • Налажен учет фактически выполненной работы и фактических затрат.
  • Для контрольных дат считают плановый объем, освоенный объем и фактические затраты.
  • Рассчитаны отклонения по срокам и по стоимости.
  • На основе отклонений строится прогноз итоговой стоимости и срока.
  • По сигналам метода принимаются корректирующие решения, пока есть время.

Типовые ошибки:

  • Контроль только по деньгам. Смотрят, сколько потрачено, не сопоставляя с объемом сделанного. → Считать освоенный объем: стоимость реально выполненной работы.
  • Недостоверный базовый план. Плановые объемы и сроки заданы условно, и отклонения бессмысленны. → Строить EVM на выверенных WBS, сроках и бюджете.
  • Прогресс на глаз. Степень готовности работ оценивают завышено, освоенный объем раздут. → Оценивать выполнение по четким правилам, без приписок.
  • Цифры без решений. Отклонения считают, но мер не принимают. → Использовать ранние сигналы для корректировки, а не для отчета.

B2-07 — Модель и нотация бизнес-процессов (BPMN)

Откуда появился инструмент. BPMN (Business Process Model and Notation) — стандартный язык схем для описания бизнес-процессов. Его создала организация Business Process Management Initiative (BPMI), выпустив версию 1.0 в мае 2004 года; ведущим автором был Стивен Уайт из IBM. Цель — свести воедино множество разнородных способов рисовать процессы и дать нотацию, понятную и бизнес-аналитику, и разработчику. В 2005 году BPMI слилась с консорциумом OMG (Object Management Group), который ведет стандарт до сих пор. Переломной стала версия BPMN 2.0 (2011): нотация превратилась в полноценную модель — схемы стали не только наглядными, но и пригодными для исполнения в программных системах. Позже BPMN закрепили и как международный стандарт ISO.

Суть и механика. BPMN — система условных обозначений, которая позволяет рисовать бизнес-процесс единообразной схемой: последовательность действий, события, точки принятия решений и их связи. Несколько базовых типов элементов: события (то, что запускает или меняет ход процесса), действия (выполняемые операции), шлюзы (логические развилки и слияния потоков), потоки (стрелки, задающие порядок) и артефакты (поясняющие элементы). Из этого набора собирается схема, одинаково понятная всем участникам. BPMN применяют, чтобы анализировать и оптимизировать процессы (видеть узкие места), стандартизировать их, готовить к автоматизации и обучать сотрудников.

Пример. Процесс обработки заявки на словах у каждого отдела свой, и стыки теряются. На схеме BPMN его рисуют единообразно: событие «поступила заявка» запускает цепочку действий, шлюз-развилка отправляет крупные заказы на согласование руководителю, а мелкие — сразу в работу, потоки задают порядок шагов. Сразу видно, где заявка простаивает и какие шаги можно вести параллельно. Один и тот же рисунок одинаково читают бизнес и ИТ, и по нему же процесс настраивают в системе.

Границы применимости. BPMN полезен везде, где процессы нужно описать, обсудить и улучшить общими силами бизнеса и ИТ, — при анализе, стандартизации и автоматизации процессов. По методике это сложный инструмент (36 часов): полный стандарт обширен. Для простых блок-схем его богатый набор может быть избыточен, а строгий математический анализ процесса лучше дают сети Петри (B2-08). BPMN описывает процессы (B1-02, B3-03) и служит основой для их автоматизации, в том числе через добычу процессов (H3-04).

Чек-лист перед применением BPMN:

  • Определены границы процесса: с какого события начинается и чем заканчивается.
  • Выделены участники процесса (дорожки) и их зоны ответственности.
  • Действия, события и развилки (шлюзы) описаны стандартными элементами BPMN.
  • Логика развилок задана однозначно: по какому условию куда идет поток.
  • Схема проверена на понятность и бизнесу, и техническим специалистам.
  • Уровень детализации соответствует цели (обзор, анализ или автоматизация).

Типовые ошибки:

  • Схема для своих. Рисуют произвольными значками, понятными лишь автору. → Использовать стандартные элементы BPMN — в этом смысл общего языка.
  • Избыточная сложность. В одну схему пытаются вместить весь процесс до мелочей. → Делить на уровни: обзор отдельно, детали — в подпроцессах.
  • Непонятная логика развилок. Шлюзы расставлены без четких условий, поток неоднозначен. → Явно задавать условие каждой развилки.
  • Схема в стол. Процесс описали, но не используют для анализа или автоматизации. → Применять схему по назначению: улучшение, стандарт, исполнение.

B2-08 — Сети Петри (Petri Nets)

Откуда появился инструмент. Сети Петри названы по имени немецкого математика Карла Адама Петри (1926–2010). Идею он, по собственному рассказу, придумал еще подростком в 1939 году, чтобы описывать химические процессы, а строго оформил в докторской диссертации «Связь с автоматами», защищенной в 1962 году в Техническом университете Дармштадта. Работа намного опередила свое время и поначалу почти не была замечена, но позже легла в основу теории параллельных и распределенных вычислений. За создание теории сетей Петри ученый получил в 2008 году премию «Пионер компьютерной техники».

Суть и механика. Сеть Петри — математический инструмент для моделирования динамических систем, где события происходят параллельно и асинхронно. Это ориентированный граф из вершин двух типов: позиций (состояний, изображаются кружками) и переходов (событий, изображаются планками), соединенных дугами; дуга всегда связывает вершины разных типов. В позициях находятся «фишки» (метки), и их расположение задает текущее состояние системы. Когда у перехода во всех входных позициях есть фишки, он срабатывает: фишки уходят из входных позиций и появляются в выходных, мгновенно меняя состояние. Так сеть формально, на языке математики, описывает поведение системы — и позволяет ее анализировать: проверять на тупики, зацикливания, недостижимые состояния.

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

Границы применимости. Сети Петри применяют там, где нужен строгий анализ систем с параллельными и асинхронными процессами, — в моделировании сложных бизнес-процессов, гибких производственных систем, протоколов. По методике это сложный инструмент (36 часов): он требует математической подготовки. Это аппарат анализа, а не наглядная схема для бизнеса: для общего описания процессов берут BPMN (B2-07), а сети Петри подключают, когда нужна формальная проверка. Их используют и в добыче процессов (H3-04) для анализа реальных процессов по логам.

Чек-лист перед применением сетей Петри:

  • Определена система, которую моделируют, и ее ключевые состояния и события.
  • Состояния заданы позициями, события — переходами, связи — дугами между ними.
  • Начальная разметка (расположение фишек) отражает исходное состояние системы.
  • Заданы правила срабатывания переходов в соответствии с логикой системы.
  • Модель проанализирована на тупики, недостижимые состояния и зацикливания.
  • Выбран подходящий вид сети (временная, стохастическая, цветная) под задачу.

Типовые ошибки:

  • Сеть Петри ради наглядности. Сложный математический аппарат берут там, где хватило бы простой схемы. → Для наглядного описания использовать BPMN (B2-07); сети Петри — для анализа.
  • Неверная модель системы. Состояния и переходы заданы неточно, и анализ относится не к той системе. → Выверять соответствие модели реальной логике процесса.
  • Модель без анализа. Сеть построили, но на тупики и достижимость не проверили. → Использовать сеть по назначению: формальная проверка свойств.
  • Чрезмерное усложнение. Систему моделируют в избыточных деталях, сеть становится необозримой. → Моделировать на уровне, достаточном для проверяемого свойства.

Резюме

Эти четыре инструмента закрывают подгруппу визуализации и планирования, поднимая ее с базового уровня на продвинутый. Если паспорт, WBS, диаграмма Ганта и канбан из прошлой статьи делают проект просто видимым, то здесь инструменты его считают и проверяют. Метод критического пути находит задачи, определяющие срок. Метод освоенного объема заранее ловит отклонения по срокам и деньгам. BPMN дает строгий общий язык для описания процессов, а сети Петри — математику для их проверки. Все четыре сложнее предыдущих (24–36 часов) и требуют либо дисциплины в данных, либо математической подготовки. Объединяет их одно: они переводят управление с интуиции на расчет, и расчет этот полезен ровно настолько, насколько достоверны заложенные в него оценки и планы.

В следующей статье цикла перейдем к подгруппе B3 «Оптимизация и интеграция» — бережливое управление проектами, роботизация процессов (RPA), управление бизнес-процессами (BPM) и метод критической цепи (CCPM).

Похожие записи