Инструменты методики АЦТ, часть 12: управление проектами (Project Management), управление процессами (BPM), управление изменениями (Change Management) и водопадная модель (Waterfall)

Это двенадцатая статья цикла по инструментам методики «Аккордная цифровая трансформация». Открываем группу B «Управление проектами и процессами» — подгруппу B1 «Базовые методологии управления», инструменты B1-01, B1-02, B1-03 и B1-04.

B1-01 — Управление проектами (Project Management)

Откуда появился инструмент. Управление проектами как осознанная дисциплина сложилось в середине XX века. Первый шаг к формализации сделал американский инженер Генри Гант: около 1910–1915 годов он предложил диаграмму, наглядно показывающую задачи проекта во времени, — она используется до сих пор. Похожую идею, гармонограмму, еще раньше, в 1890-х, выдвинул польский инженер Кароль Адамецкий. Современная дисциплина оформилась в 1950-х на больших оборонных и инженерных проектах: тогда появились сетевые методы планирования — метод критического пути (CPM), разработанный в компании DuPont, и метод PERT, созданный для проекта баллистической ракеты «Поларис» ВМС США. В 1969 году в США основали Институт управления проектами (PMI), который закрепил профессию и выпустил свод знаний PMBOK, ставший отраслевым стандартом.

Суть и механика. Управление проектами — системный подход к планированию, выполнению и контролю проекта ради достижения результата в заданные сроки, бюджет и ресурсы. Суть подхода — разбить проект на управляемые элементы, распределить ответственность, оценить затраты деньгами, временем и материалами и создать единую базу для планирования и контроля. На протяжении проекта менеджер отслеживает сроки, бюджет и объем работ и реагирует на отклонения. Это каркас, внутри которого работают конкретные методы — диаграмма Ганта (B2-02), метод критического пути (B2-05) — и модели жизненного цикла, такие как водопадная (B1-04) или Agile (B1-05).

Управление проектами не выполняет работу за команду, но делает ход проекта прозрачным и управляемым.

Границы применимости. Подход оправдан для разовых начинаний с понятным результатом, сроками и бюджетом; для повторяющейся текущей деятельности уместнее управление процессами (BPM, B1-02). По методике это инструмент средней сложности (24 часа) — базовый каркас группы B. Сам по себе он задает рамку, но не диктует, как именно вести проект: для этого выбирают модель жизненного цикла и конкретные инструменты планирования группы B2.

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

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

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

• Проект без четких границ. Цель и объем размыты, рамки расползаются по ходу. → Зафиксировать результат, границы и критерии успеха на старте; изменения проводить управляемо (B1-03).
• Управление проектом для текущей деятельности. Проектный аппарат натягивают на повторяющиеся операции. → Для постоянных процессов использовать управление процессами (BPM, B1-02).
• План есть, контроля нет. Составили график и забыли, отклонения замечают в конце. → Отслеживать прогресс по контрольным точкам и реагировать на отклонения сразу.
• Вся ответственность на руководителе. Задачи не закреплены за исполнителями, всё держится на одном человеке. → Распределить ответственность по элементам структуры работ.

B1-02 — Управление процессами (Business Process Management, BPM)

Откуда появился инструмент. BPM выросло из давней традиции процессного мышления — от научной организации труда начала XX века до управления качеством (TQM, Six Sigma). Прямой предшественник — реинжиниринг бизнес-процессов (BPR): в 1990 году профессор Майкл Хаммер опубликовал в Harvard Business Review статью «Reengineering Work: Don’t Automate, Obliterate», а в 1993-м вместе с Джеймсом Чампи — книгу «Reengineering the Corporation», призвав не автоматизировать старые процессы, а перестраивать их заново. Реинжиниринг 1990-х часто проваливался из-за радикальности, и на смену пришло постоянное управление по полному циклу — от проектирования и исполнения до мониторинга и улучшения. В 2000-х BPM закрепился вместе с программными платформами и нотацией BPMN (B2-07).

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

BPM превращает разрозненную повторяющуюся работу в управляемый процесс с понятными шагами, показателями и возможностью улучшать его по циклу.

Границы применимости. BPM применим к повторяющимся, воспроизводимым процессам; эффект дает не разовое описание процессов, а постоянное управление ими по циклу. По методике это инструмент средней сложности (24 часа). Для моделирования процессов берут нотацию BPMN (B2-07), а более глубокая проработка вынесена в отдельный инструмент (B3-03). BPM улучшает процессы, но не заменяет работу с качеством (ISO 9001, A6-03) или потерями (бережливое производство, A2-05), хотя пересекается с ними.

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

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

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

• Описали процессы и остановились. Схемы нарисовали, но не управляют ими и не улучшают. → Запустить непрерывный цикл: мониторинг показателей, анализ, улучшение.
• Автоматизация неупорядоченного процесса. Кривой процесс автоматизируют как есть, закрепляя беспорядок. → Сначала упорядочить и упростить процесс, затем автоматизировать.
• Процессы без владельцев. Схемы есть, но никто не отвечает за процесс целиком. → Назначить владельца каждого процесса с ответственностью за его показатели.
• BPM как разовый проект. Процессы описывают под конкретную задачу и забывают. → Встроить управление процессами в постоянную практику.

B1-03 — Управление изменениями (Change Management)

Откуда появился инструмент. Управление изменениями как дисциплину описал немецко-американский психолог Курт Левин (1890–1947), основатель социальной психологии. В статье 1947 года он описал изменение как три стадии: «разморозка» (поколебать устоявшееся равновесие), собственно изменение и «заморозка» (закрепить новое состояние). Модель легла в основу почти всех последующих подходов. В 1996 году Джон Коттер в книге «Leading Change» развернул ее в восемь шагов — от создания чувства срочности до закрепления изменений в культуре. А консалтинговая фирма Prosci, основанная Джеффом Хайаттом, предложила модель ADKAR, которая ведет через изменение каждого отдельного человека: осознание, желание, знание, умение, закрепление. Все эти модели об одном — как провести людей и организацию через перемену и закрепить новое, преодолев естественное сопротивление.

Курт Левин — основатель социальной психологии

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

Нагляднее всего это видно при внедрении, которое прошло технически, но не прижилось.

Границы применимости. Управление изменениями нужно везде, где перемена затрагивает то, как люди работают, — при внедрении систем, процессов, новой структуры или культуры. По методике это сложный инструмент (30 часов): он требует и методик (модели Левина, Коттера, ADKAR), и постоянной работы с людьми. На уровне проекта он соединяется с контролем изменений по срокам и бюджету (B1-01, B4-02); на уровне всей организации это более широкая дисциплина, к которой методика возвращается в группах C и E (организационные изменения E3-02, кадровые C5-03). Управление изменениями не отменяет сопротивление, но делает его управляемым.

Чек-лист перед внедрением управления изменениями:

• Определены суть и цель изменения, понятные не только инициаторам, но и тем, кого оно затронет.
• Оценено влияние перемены на людей и процессы; выявлены вероятные источники сопротивления.
• Донесено, зачем изменение нужно: сотрудники понимают смысл, а не только факт перемены.
• Назначены лидеры изменения и проводники на местах, вовлечено руководство.
• Предусмотрены обучение и поддержка людей на время перехода.
• Заложено закрепление нового поведения, чтобы не было отката к старому.

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

• Изменение «спустили сверху». Перемену объявляют приказом, не объяснив смысла, — люди сопротивляются. → Формировать осознание и поддержку: объяснять, зачем меняемся, еще до внедрения.
• Техническое внедрение без людей. Систему или процесс внедрили, а сотрудников не подготовили — работают по-старому. → Сопровождать внедрение обучением и поддержкой, работать с сопротивлением.
• Нет закрепления. Изменение внедрили и отпустили, через время все вернулись к привычному. → Закреплять новое: показатели, поддержка, отказ от старых обходных путей.
• Изменение без оценки последствий. В проекте правки вносят на словах, проект тихо выходит за сроки и бюджет. → Ввести процедуру: запрос, оценка влияния, согласование, обновление плана.

B1-04 — Водопадная модель (Waterfall)

Откуда появился инструмент. Водопадную модель чаще всего связывают с американским ученым Уинстоном Ройсом (1929–1995), директором центра программных технологий Lockheed. В статье 1970 года «Managing the Development of Large Software Systems» он описал разработку как последовательность этапов, где каждый следующий опирается на результат предыдущего. Любопытно, что Ройс приводил эту простую линейную схему как рискованную и сам же предлагал ее дорабатывать — повторять цикл, добавлять обратные связи; он не называл ее «водопадом» и не считал идеальной. Название «водопад» закрепилось позже, впервые встречается в статье Белла и Тейера 1976 года, — а промышленность взяла на вооружение именно жесткий линейный вариант, который Ройс критиковал. Сама идея последовательных фаз восходит к более ранним работам (презентация Херберта Бенингтона, 1956) и к производственной и строительной логике, где этапы идут строго друг за другом.

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

Границы применимости. Водопадная модель уместна в проектах со стабильными, заранее понятными требованиями и высокой ценой ошибки документирования — в строительстве, машиностроении, оборонных и регулируемых отраслях. Там, где требования меняются по ходу и важна скорость обратной связи, выигрывают гибкие подходы (Agile / Scrum, B1-05). По методике это сложный инструмент (30 часов).

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

• Требования стабильны и могут быть полно зафиксированы на старте.
• Составлено подробное техническое задание, согласованное с заказчиком.
• Этапы (требования, проектирование, реализация, тестирование, эксплуатация) определены с критериями завершения каждого.
• Заложены время и ресурсы на полную документацию.
• Оценен риск позднего обнаружения ошибок: тестирование стоит в конце.
• Проверено, что гибкая модель (B1-05) здесь не подошла бы лучше из-за изменчивости требований.

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

• Водопад при нестабильных требованиях. Жесткую модель берут для проекта, где требования наверняка изменятся. → Для изменчивых требований выбирать гибкий подход (Agile / Scrum, B1-05).
• Требования зафиксированы небрежно. На старте требования собрали неполно, и пробелы всплывают в конце дорого. → Тщательно прорабатывать и согласовывать требования до перехода к проектированию.
• Тестирование отложено на финал и не учтено как риск. Проблемы вскрываются в самом конце. → Закладывать ранние проверки и риск позднего тестирования, как предупреждал еще Ройс.
• Слепое следование без обратных связей. Модель применяют буквально линейно, без возможности вернуться. → Предусмотреть обратные связи между этапами, как и предлагал автор исходной схемы.

Резюме

Четыре инструмента подгруппы B1 не образуют единой системы, но между ними есть ясная логика. В ее основе лежит различие двух типов деятельности: разовый проект, у которого есть начало и конец, и повторяющийся процесс, который идет постоянно. Управление проектами (B1-01) отвечает за первый тип, управление процессами (B1-02) — за второй.

Водопадная модель (B1-04) стоит уровнем ниже управления проектами — это одна из моделей жизненного цикла проекта, то есть выбор того, как именно его вести, когда требования стабильны. В той же роли рядом с ней находятся гибкие подходы (Agile / Scrum, B1-05), о которых пойдет речь в следующей статье.

Управление изменениями (B1-03) нужно и проектам, и процессам :то и другое приходится менять, а любое изменение упирается не только в план, но и в людей. Поэтому оно связано и с управлением проектом (контроль изменений по срокам и бюджету), и с организационной стороной — снижением сопротивления и принятием нового персоналом. В единый механизм эти инструменты не складываются, но вместе задают язык, на котором группа B описывает любую работу.

В следующей статье цикла продолжим разбор подгруппы B1 — гибкие и стандартные методологии управления: Agile / Scrum (B1-05), PRINCE2 (B1-06) и свод знаний PMBOK (B1-07).