Сравнивать гибель людей с сорванным внедрением ERP неприлично. Но организационный механизм, который приводит к трагедиям и к обычным корпоративным провалам, старше проектного управления и узнаётся мгновенно.

Перед первым выходом шведского военного корабля «Ваза» летом 1628 года капитан Сёфринг Ханссон организовал испытание остойчивости. Тридцать человек перебегали с борта на борт. После трёх пробегов корабль кренился настолько опасно, что вице-адмирал Клас Флеминг остановил испытание, опасаясь опрокидывания у причала. Но королю о результате не доложил. Густав II Адольф находился на войне и письмами требовал скорее вывести корабль в море. «Ваза» прошла около 1300 метров и затонула. На расследовании ответственность сдвинули к уже умершему кораблестроителю Хенрику Хюбертссону, работавшему по одобренному королём проекту. Дальше пришлось бы задавать вопросы самому королю, поэтому не наказали никого.

Перед запуском Challenger в январе 1986 года инженеры подрядчика возражали против старта при низкой температуре. Руководство подрядчика изменило первоначальную рекомендацию не запускать шаттл, а руководители программы более высокого уровня не были проинформированы ни об этой рекомендации, ни о продолжающихся возражениях инженеров. Через 73 секунды после старта Challenger разрушился, погибли семь членов экипажа. Комиссия Роджерса обнаружила не только техническую причину, но и дефект процесса принятия решений.

В обоих случаях опасность была известна. Но знание находилось у одних, право окончательного выбора – у других, выполнять решение должны были третьи, а после катастрофы начинался поиск человека, которому можно задним числом приписать и знание, и полномочия, и ответственность.

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

Ты же видел риск. Почему не остановил?

Вопрос кажется справедливым. РП действительно знал о риске, сообщал о нём и выносил его на комитет. Возможно, мог говорить жёстче, написать отдельное письмо или раньше поставить вопрос ребром. Но этот вопрос скрывает другой:

Кто владел бизнес-результатом, ради которого запускался проект, и были ли у этого человека полномочия изменить процесс, назначить исполнителей, обеспечить данные и принять последствия решения?

Пока проект шёл, этих полномочий у руководителя проекта не было. После провала оказалось, что ответственность была именно у него.

---

Пока риск был на слайде, он принадлежал всем

Проект по обновлению ERP-системы производственного предприятия вышел за сроки и бюджет. После запуска обнаружились ошибки в производственных спецификациях. Система некорректно списывала материалы, искажала остатки, вслед за ними менялись производственные планы, а затем и планы продаж. Чтобы понять, откуда пошёл сбой, пришлось разбирать уже работающую систему, возвращаться к перенесённым данным и переделывать часть того, что команда считала завершённым.

У каждого участника совещания появилась проблема, которую нужно было объяснить своему руководству. Спонсор наконец увидел, сколько будет стоить исправление. Руководителю проекта со стороны заказчика предстояло объяснить, почему известный риск месяцами оставался без владельца и решения. Моё руководство получило недовольного клиента, срыв сроков и угрозу потерять часть оплаты. Претензии предъявили мне. Не один человек – все.

Надо было сказать по-другому. Написать отдельное письмо. Жёстче обозначить последствия. Быть настойчивее. Ты же руководитель проекта.

Я пытался защищаться: поднял реестр рисков, статусные отчёты и слайды, на которых проблема была выделена задолго до запуска. Напомнил, что вопрос обсуждался с директором по производству, РП заказчика и проектным комитетом. Но кому это было интересно? Реестр не исправлял спецификации, отчёты не возвращали потерянные месяцы, презентации не восстанавливали маржинальность. Документы доказывали только одно: произошедшее не было неожиданностью.

И именно поэтому они почти усиливали обвинение. Раз понимал последствия – почему не добился решения?

Формально в этих претензиях была доля правды. Я действительно мог остановить миграцию и потребовать не очередного обсуждения, а выбора: производство выделяет людей и заполняет спецификации; неподготовленные объекты исключаются из миграции; либо уполномоченный руководитель явно принимает последствия продолжения. Я этого не сделал. Зарегистрировал риск, несколько раз вынес его на обсуждение, но не превратил в обязательное управленческое решение.

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

Это была моя профессиональная ошибка: я не поставил вопрос достаточно жёстко. Но она не делала меня владельцем производственного процесса. До провала содержательное решение мне не принадлежало. После провала оказалось, что мне принадлежала вся ответственность.

«У вас же есть опыт»

За несколько месяцев до того совещания всё выглядело гораздо спокойнее. Вместе с новой ERP требовалось перенести производственные спецификации – данные о материалах, операциях и рабочих центрах. В старой системе они годами заполнялись вручную. Часть информации устарела, часть не соответствовала новой модели учёта, а некоторых необходимых атрибутов раньше не существовало.

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

Для таких случаев требовался не более умный алгоритм, а человек со стороны производства, который мог подтвердить: «Да, именно так мы должны работать» – или признать, что старое правило больше не соответствует реальности. Такого человека мог назначить директор по производству. Проектная команда могла подготовить перечень вопросов, сгруппировать спецификации, предложить правила массового заполнения и показать последствия ошибок. Но подтвердить, как должно работать конкретное предприятие, мы не могли.

Ответ прозвучал примерно так:

У вас же есть опыт автоматизации производственных предприятий. Заполните пока исходя из своего опыта – что-то вроде средней температуры по больнице. А когда у нас будет время, мы актуализируем.

Сама формулировка казалась прагматичной. Спорных спецификаций было относительно немного, использовались они нечасто. Останавливать из-за них миграцию означало задерживать проект, а каждый дополнительный месяц стоил заказчику денег. Снимать технологов с выпуска в разгар производственного плана – тоже реальная цена, а не каприз директора. Временное заполнение выглядело разумным компромиссом: сейчас запустимся, потом спокойно наведём порядок.

Проблема была не в том, что стороны не понимали друг друга, а в том, что компромисс не превратили в решение. Никто не определил, кто вернётся к данным после запуска, не появился срок актуализации, не были выделены специалисты производства и не установили критерий приемлемости временных значений. Не было человека, который явно сказал бы: «Я разрешаю использовать спецификации в таком виде и принимаю последствия». Было лишь общее ожидание, что позже у кого-нибудь появится время. Не появилось.

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

Опыт консультанта помогает задать точный вопрос. Он не даёт права ответить за владельца процесса. Можно десятки раз внедрять производственные системы и всё равно не знать, какой материал конкретный завод должен списывать в конкретной операции. Техническая команда умеет переносить правила, но не должна незаметно становиться их автором. У нас экспертизу интегратора превратили в замену отсутствующего владельца данных, а временное предположение – в основу продуктивной системы.

Когда такая спецификация использовалась, ошибка переставала быть строкой в таблице:

неподтверждённая спецификация → неправильное списание материалов → недостоверные остатки → ошибочный производственный план → изменение плана продаж → повторная миграция и переделка уже выполненной работы.

Новая ERP не создала ошибку – она сделала её последовательной. Внешне проект продолжал двигаться: данные загружались, задачи закрывались, процент готовности рос. Но внутри системы уже находились решения, которых никто не принимал. Мы переносили данные, а хозяина их достоверности у проекта не было.

Риск был зарегистрирован, но не был управляем

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

Плохие решения редко приходят на комитет с табличкой «сейчас мы создадим проблему на девять месяцев». Обычно они выглядят как временный компромисс между понятными интересами. Реестр мог содержать вероятность, последствия и мероприятия, а RACI – показывать, кто выгружает данные, преобразует, проверяет и загружает. Но эти инструменты не отвечали на главные вопросы: кто определяет готовность данных к запуску, кто может обязать производство выделить людей, кто вправе исключить часть спецификаций из первой очереди, кто принимает задержку, кто разрешает продолжить работу с неподтверждёнными данными и кто отвечает не за заполнение таблицы, а за то, что после запуска предприятие сможет правильно планировать производство.

Можно идеально распределить работы и не распределить ни одного решения. В нашем проекте никто не был обязан к определённой дате обеспечить подтверждённые производственные спецификации или официально выбрать альтернативный путь. Проект несколько раз коллективно согласился вернуться к вопросу позже.

Так появляется бездействие, которое легко принять за решение. Люди обсудили проблему, внесли риск в документы, на статусе никто не возразил против продолжения, работы не остановились – значит, вроде бы договорились. Но обсуждение не является решением, отсутствие возражений не означает принятия риска, а продолжение работ не доказывает, что кто-то осознанно выбрал последствия.

Проект двигался не потому, что уполномоченный человек решил продолжать. Он двигался потому, что никто не решил остановиться.

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

Кто всё-таки отвечает за результат

В предыдущей статье этой серии я закончил обещанием: способ проверки выгоды сам по себе ничего не меняет. Кто-то должен владеть результатом, иметь полномочия изменить процесс и отвечать за то, что заявленная выгода действительно получена.

Владелец бизнес-результата – не почётная фамилия в паспорте проекта и не буква A в RACI. Это человек, который принимает ожидаемое изменение как своё обязательство и способен собрать необходимые рычаги в работающую конструкцию. Он должен ответить на пять вопросов:

1. Что именно должно измениться после запуска?

2. Как мы поймём, что изменение действительно произошло?

3. Какие процессы, данные, решения и действия людей необходимы для результата?

4. Что я вправе изменить, если цепочка не срабатывает?

5. Что я буду делать, если результат не возникает в согласованный срок?

Если человек может только принять систему на испытаниях, он владеет приёмкой, а не бизнес-результатом. Если формулирует пожелания, но не вправе изменить процесс, он представляет потребность, но не владеет её реализацией. Если после запуска не получает метрики результата и не участвует в проверке эффекта, его роль заканчивается раньше, чем появляется выгода.

Одного универсального владельца «всего проекта» обычно нет. Нужно различать объекты ответственности.

Владелец бизнес-результата отвечает за изменение, ради которого проект начался, и остаётся ответственным после технического запуска. Владелец процесса определяет, как должна работать компания, какие правила правильны и какие исключения допустимы. Владелец данных отвечает не за формат файла, а за полноту, актуальность и пригодность данных для работы процесса. Спонсор даёт инициативе организационную силу: разрешает конфликты функций, выделяет ресурсы и принимает решения, цена которых выходит за пределы полномочий отдельных подразделений. ИТ и архитектор отвечают за возможности системы, технологическую реализуемость, архитектурные ограничения и последствия решений. Руководитель проекта отвечает за управляемость пути к результату: выявить зависимость, подготовить варианты, назвать владельца решения, установить срок, показать последствия и вовремя эскалировать бездействие.

РП не становится владельцем бизнес-результата только потому, что лучше остальных видит всю картину. Он не может принять за производство его правила, за владельца данных – достоверность справочника, за спонсора – финансовый риск, а за руководителей подразделений – обязательство выделить людей. Его обязанность – не решить за всех, а не позволить всем сделать вид, что решение не требуется.

В нашем проекте ожидаемым результатом была не загрузка определённого количества спецификаций. Предприятие должно было после запуска корректно выпускать продукцию, списывать материалы, рассчитывать остатки и строить производственные планы. Для этого требовались подтверждённые спецификации, специалисты производства, возможность задержать запуск или сократить первую очередь и право принять финансовые последствия выбранного варианта. Руководитель проекта исполнителя не управлял этими рычагами и не мог единолично владеть результатом.

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

Роли не принимают решений

Даже если роли определены правильно, в понедельник утром команде всё равно требуется ответ на конкретный вопрос:

Мы переносим неподтверждённые спецификации в продуктивную систему или нет?

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

Реестр рисков показывает, что может произойти.

RACI показывает, кто участвует в работе.

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

В карту не нужно заносить каждое согласование макета или дату встречи. Она нужна для решений, отсутствие которых меняет бизнес-результат, сроки, бюджет, объём, качество, архитектуру, данные или возможность эксплуатации. Хорошая запись начинается не с «проработать вопрос», а с конкретного выбора:

Определить порядок работы с производственными спецификациями, которые невозможно однозначно обогатить автоматически.

Дальше появляется конкретный владелец содержательного решения – не «бизнес», не «заказчик» и не «комитет». У решения могут быть обязательные участники, но последнее слово не должно растворяться между ними. Затем проект приносит не проблему, а варианты с ценой каждого: выделить специалистов и подтвердить данные; исключить объекты из первой очереди; продолжить с временными значениями и явно принять риск; остановить зависимую часть миграции.

Руководитель проекта не обязан быть нейтральным секретарём. Если один путь профессионально предпочтительнее, его нужно обозначить и объяснить. Следом устанавливается конкретный срок – не «как можно скорее» и не «до запуска», а дата, после которой отсутствие ответа меняет план.

Самое спорное поле – действие без ответа. Когда выбор находится в пределах моих полномочий, я заранее указываю, что сделаю при отсутствии решения. Например, если бизнес не определил приоритет двух функций, команда продолжит работу по текущему критическому пути. Но молчание нельзя превращать в согласие там, где нужны чужие полномочия или непосредственные действия другой стороны. Данные не становятся достоверными от отсутствия ответа.

Если нужно выделить людей, подтвердить бизнес-правило, исправить данные или принять финансовый риск, допустимы только явное решение, эскалация и при необходимости остановка зависимой части работ. Эскалация здесь – не жалоба начальству, а штатный способ получить решение там, где конфликт вышел за пределы полномочий участников.

Как должна была выглядеть карта решений

В том проекте такой карты у меня ещё не было. Таблица ниже – ретроспективная реконструкция, а не восстановленный проектный документ.

В том проекте клетка «Действие без ответа» осталась бы пустой. И эта пустота была бы самым полезным содержанием карты: она показывает, что решение обязано подняться выше. РП мог остановить зависимую часть работ, если такое право было закреплено, но не мог своим уведомлением подтвердить данные или принять за заказчика финансовый риск.

В реестре можно было написать: «Возможны ошибки списания и планирования. Требуется участие производства». Все могли согласиться и ничего не сделать. Карта ставит участников в менее удобное положение: до контрольной загрузки нужно выбрать вариант. Недостаточно сказать «риск услышали» – нужно выделить людей, сократить объём, принять последствия либо остановить зависимую часть работ.

Карта не гарантирует, что руководители выберут безопасный вариант. Она делает решение видимым: кто его принял, какие альтернативы рассматривались, какие последствия были известны и кто обязан выполнить необходимые действия.

Когда карта решений не работает

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

Сравните две формулировки:

Нам нужно принять решение до пятницы, потому что после этого начнётся контрольная миграция. Вот три варианта, мы рекомендуем второй. Без решения неподготовленные объекты придётся исключить из загрузки.

Ранее неоднократно сообщалось о необходимости своевременного принятия решения. В случае отсутствия ответа ответственность за последствия находится на стороне заказчика.

Первая помогает действовать, вторая готовит будущий спор. Карта также не должна превращаться в журнал всех вопросов проекта: в неё включаются решения, отсутствие которых меняет результат, существенные ограничения или обязательства. Остальное остаётся в задачах, бэклоге и протоколах.

Нельзя назначать владельцем удобного адресата, который часто бывает на встречах, но не имеет необходимых полномочий. Нельзя прятать ответственность за словом «комитет», если у него нет формального порядка принятия обязательных решений. Нельзя считать молчание принятием финансового, регуляторного или бизнес-риска.

Фиксация не освобождает РП от убеждения. Иногда риск нужно перевести в деньги, показать цепочку последствий, провести отдельную встречу и несколько раз переформулировать проблему. В моём случае я, вероятно, недостаточно ясно показал, что речь идёт не о нескольких редко используемых строках, а о каскаде от списания материалов до плана продаж. Это моя часть ответственности.

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

Главный тест карты прост:

Какое действие изменится после принятия решения?

Если ответа нет, перед нами, вероятно, не решение, а обсуждение, пожелание или попытка зафиксировать будущую претензию.

Что можно сделать завтра

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

1. Сформулируйте изменение в работе

Не «спецификации перенесены», а «производственный план строится на подтверждённых спецификациях, материалы списываются корректно, остатки позволяют принимать реалистичные обязательства». Пока изменение нельзя сформулировать, назначать владельца рано – ему ещё нечем владеть.

2. Назовите одного владельца бизнес-результата

Спросите: если через три месяца после запуска результат не будет получен, кто обязан собрать участников, определить причину и добиться изменений? Если ответ – «руководитель проекта», хотя проект уже закрыт и команда распущена, владельца результата, вероятно, нет.

3. Проверьте его рычаги

Может ли он назначить специалистов, изменить приоритет подразделения, потребовать исправления данных, утвердить правила процесса, согласиться на перенос срока, сократить объём или принять остаточный риск? Если нет – расширьте полномочия, назначьте другого владельца либо заранее определите роль спонсора.

4. Найдите решения, которые нельзя оставить команде

Пройдите цепочку от результата назад. Какие данные нужно подтвердить? Какие правила установить? Кто должен выделить ресурсы? Кто выбирает между сроком и качеством? Кто принимает последствия компромисса? Не записывайте «проработать» и «обеспечить взаимодействие». Запишите конкретный выбор.

5. Заполните минимальную версию карты

Для начала достаточно восьми полей. Пять служебных полей – «Почему решение требуется сейчас», «Владелец бизнес-результата», «Кто готовит решение», «Кто принимает остаточный риск» и «Фиксация» – можно добавить, когда решение становится межфункциональным, дорогим или необратимым. Маршрут эскалации обычно лучше установить общим регламентом компании, а не повторять в каждой карточке.

 После заполнения должно быть понятно, кто выбирает, между чем, к какой дате, что вправе сделать РП и где его полномочия заканчиваются.

6. Подтвердите конструкцию с владельцем результата

Не отправляйте таблицу молча. Проведите короткий разговор:

Мы ожидаем от проекта такой результат. Для него нужны такие изменения процесса и данных. Вот решения, которые потребуются от вас и других руководителей. Вот полномочия, без которых результат недостижим. Готовы ли вы принять эту роль и что нужно изменить в конструкции проекта?

Человек может сказать, что не управляет нужными подразделениями, не готов отвечать за метрику или не вправе принять риск. Это не провал разговора, а ранняя диагностика проекта. Лучше узнать до реализации, что обещанная выгода не имеет владельца, чем после запуска объяснять, почему система работает, а бизнес-результат не появился.

Ответственность появляется не после провала

В нашем проекте запуск отложился на полгода. Из-за переделки уже выполненной работы общий сдвиг достиг девяти месяцев. Исправлять спецификации в итоге пришлось тем самым специалистам, которых я просил назначить в самом начале.

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

Проиграли все.

Никто не сэкономил деньги и не избежал работы. Мы лишь перенесли её в будущее, где она стала дороже, сложнее и болезненнее. У меня до сих пор нет удобного ответа на вопрос: «Ты же видел риск. Почему не остановил?» Я действительно должен был поставить вопрос жёстче и превратить риск в обязательный выбор. Не сделал риск достаточно дорогим до того, как он стал дорогим на самом деле.

Но признание этой ошибки не превращает меня во владельца производственных правил. Я мог остановить движение проекта, но не мог назначить технологов заказчика, подтвердить достоверность спецификаций или принять за спонсора дополнительные расходы.

Руководитель проекта отвечает за управляемость пути к результату. Владелец бизнес-результата – за то, что организация действительно прошла этот путь. Если результат зависит от процессов, данных и действий нескольких подразделений, должен быть человек, который принимает его как своё обязательство и собирает необходимые полномочия. А у каждого критического выбора – конкретный владелец решения.

Назначить их нужно до того, как риск превратится в деньги. Потому что после этого организация почти всегда находит ответственного.

Только это уже не управление проектом.

Это назначение виновного.

Следующая статья – о том, что именно должен изменить владелец результата, и почему без этого правильное распределение полномочий тоже не спасает.