Мы перешли в опытно-промышленную эксплуатацию. До полноценного промышленного запуска было ещё далеко, но отчитываться уже было о чём. Основные контуры работали, подразделения начали собирать консолидированную потребность не в Excel, а в единой системе, пользователи осваивали новые процессы.

На управляющем комитете я именно об этом и рассказывал: что запущено, что работает, какие задачи ещё остаются. Спонсор выслушал и задал вопрос, который я помню почти дословно:

Хорошо, вы всё замечательно рассказываете. А давайте сейчас спросим бизнес. Что скажут директора заводов? Как закупщики отреагировали на систему? Им легче стало работать? Система действительно помогает им по сравнению с тем, что было раньше?

У меня не было хорошего ответа.

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

---

Нам было что показать. Просто нас спрашивали не об этом

Ответить спонсору мы могли. Более того, у нас был вполне убедительный проектный отчёт. Мы могли предъявить подключённые подразделения, работающие контуры, переведённые процессы и отказ от части Excel-файлов. Через систему пошёл больший объём закупок, в том числе операции, которые раньше могли оставаться за пределами общего информационного контура.

Это были реальные результаты. Проблема не в том, что они ничего не значили. Проблема в том, что спонсор спрашивал о другом.

Он не спрашивал, работает ли система. Он спрашивал, помогает ли она закупщикам.

Запущенные контуры на этот вопрос не отвечали. Даже отказ от Excel сам по себе не доказывал, что ручной работы стало меньше. Раньше сотрудник сводил данные в таблице, а теперь мог создавать заявку на недостающий элемент справочника, проходить согласования и контролировать, чтобы номенклатура, статья затрат или категория появились вовремя. Одну ручную операцию можно убрать из процесса и одновременно добавить несколько новых. Формально автоматизация состоялась. Стало ли от неё легче – отдельный вопрос.

Мы ответили привычно:

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

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

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

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

Я говорю «мы», но не хочу прятаться за коллективной ответственностью. Мне самому вопрос спонсора был неудобен. Я был тем самым айтишником, которому проще продолжать разговор о работающих контурах и выполненных требованиях. Всё это можно было показать, проверить и включить в протокол. Разговор о том, стало ли легче закупщикам, выводил нас на территорию, где убедительных доказательств у проектной команды не было.

Подготовить конструкцию будущего результата руководитель ИТ-проекта не мог в одиночку. Для этого требовались спонсор, владелец процесса, непосредственные исполнители и ИТ. Но из этого не следует, что ИТ могло ограничиться функциональным объёмом. Спроектировать способ проверки – не значит гарантировать бизнес-эффект. Это значит заранее договориться, какое изменение мы ожидаем, на каких условиях оно возможно и как поймём, что гипотеза сработала.

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

Ошибка произошла не в конце, когда мы не подготовили красивый отчёт об эффекте. Мы вошли в реализацию, не спроектировав доказательство ценности в начале.

Как ценность превращается в функциональный объём

На уровне инициативы всё обычно звучит убедительно: единая система закупок, консолидация потребностей заводов, сокращение дублей и ручной работы, прозрачность, экономия за счёт объёмов, контроль запасов, дисциплина. Так и пишутся служебные записки. Формулировок достаточно, чтобы объяснить, почему инициативу следует поддержать, но недостаточно, чтобы понять, что именно должно измениться и как это изменение будет проверяться.

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

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

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

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

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

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

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

Такая подмена удобна обеим сторонам. Бизнесу функции позволяют не брать на себя слишком жёсткие обязательства. Сказать «закупщикам должно стать легче» недостаточно конкретно, но безопасно. Если определить, что именно означает «легче», придётся зафиксировать текущее состояние и признать, что часть результата зависит не от ИТ, а от правил работы со справочниками, полномочий, дисциплины подразделений и решений руководителей.

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

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

Между функцией и выгодой находится изменение работы

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

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

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

Каждый переход здесь может быть подтверждён, оставаться допущением или быть неизвестным. И в каждом месте возможен конкретный разрыв.

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

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

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

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

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

Кому именно стало легче?

Даже когда общая цепочка срабатывает, ценность распределяется по организации неравномерно. Руководство получает единый обзор и возможность управлять большим объёмом закупок. Центральная функция – больше данных и влияния на локальные решения. Один сотрудник избавляется от ручной консолидации, другой принимает на себя контроль качества данных и сопровождение новых заявок.

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

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

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

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

Карта выгод: не перечень обещаний, а проверка цепочки

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

Сам подход не новый. Impact Mapping связывает бизнес-цель с участниками, требуемыми изменениями их поведения и поставляемыми результатами; карта показывает допущения и цепочку рассуждений от функции к цели. Benefits Dependency Network связывает инвестиционные цели и выгоды с необходимыми бизнес-изменениями и ИТ-возможностями, а также делает видимой ответственность за изменения и выгоды. PMI рассматривает управление выгодами как работу по их выявлению, получению во время реализации и поддержанию после передачи результата бизнесу. В этой статье я не предлагаю новый фреймворк. Я использую прикладную карточку, в которой отдельно фиксирую исходное состояние, допущения, статус выгоды и управленческое решение по ней – элементы, которые в знакомых мне корпоративных документах нередко оставались размытыми. [1][2][3]

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

Для каждого перехода достаточно трёх обозначений:

• подтверждено – есть данные, правило или принятое решение;

• допущение – связь выглядит разумной, но ещё требует проверки;

• неизвестно – данных или решения пока нет.

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

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

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

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

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

Не начинайте с KPI

После разговора о выгодах почти неизбежно возникает предложение: давайте просто назначим KPI. Сколько дублей должно исчезнуть? На сколько процентов сократить трудозатраты? Какую экономию получить за счёт укрупнения лотов?

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

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

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

Такой KPI мог случайно оказаться достижимым, оказаться недостижимым или быть выполнен за счёт действий, не создающих ценности. Количество процедур можно сократить объединением заявок, но одновременно увеличить срок ожидания или страховой запас. Число зарегистрированных дублей можно уменьшить запретом на новые элементы справочника, заставив пользователей выбирать приблизительно подходящую номенклатуру и вести уточнения в комментариях. Количество операций в Excel можно сократить, перенеся те же действия в интерфейс системы.

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

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

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

Каждый из этих результатов описывает проект точнее, чем назначенный заранее процент.

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

Плохой KPI защищает прежнюю уверенность. Хорошая метрика позволяет её проверить.

Не всякое требование обязано приносить деньги

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

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

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

Карту выгод нельзя заполнить в одиночку

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

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

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

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

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

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

Работа с картой должна закончиться не схемой, а решением. Компания может подтвердить основание инициативы, провести пилот или дополнительный замер, добавить необходимое условие, сузить обещание первой очереди, отложить часть объёма или отказаться от неподтверждённой выгоды. Это сделает презентацию менее эффектной, зато после запуска не придётся обещать «посчитать потом» то, способ проверки чего никто не спроектировал.

Карта выгод тоже умеет врать

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

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

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

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

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

Рабочий инструмент не обязан остановить инициативу. Но он должен сохранять возможность её изменить.

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

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

Карточка проверки выгоды

Для нашей закупочной программы один фрагмент мог бы выглядеть так:

Это ретроспективная реконструкция. В проекте такой карточки не было, а предложенные метрики не применялись. Её смысл не в том, чтобы задним числом доказать ценность, а в том, чтобы показать вопросы, которые следовало вынести на обсуждение до фиксации объёма.

На каждом переходе задаются одни и те же вопросы: что должно произойти после появления функции; кто начнёт действовать иначе; почему он действительно будет так действовать; какие данные и полномочия ему нужны; что может разорвать связь; как мы увидим изменение; что будет означать отрицательный результат.

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

Например:

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

Или:

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

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

Практический результат карты – не заполненная таблица, а изменившееся решение о проекте.

ИТ не обязано гарантировать бизнес-эффект

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

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

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

Но и противоположная позиция не выдерживает проверки:

Мы реализуем согласованный функционал, а получит ли бизнес результат – не наша проблема.

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

ИТ не обязано гарантировать конечную выгоду. Оно обязано участвовать в проверке причинной цепочки и показывать, когда архитектурное решение, данные или сокращение объёма разрывают связь с заявленным результатом. Бизнес, в свою очередь, не может передать ИТ цель «повысить эффективность», а после запуска вернуться только за обещанной цифрой. Если выгода зависит от процесса, полномочий и поведения сотрудников, эти изменения становятся частью инициативы, даже если не входят в техническое задание.

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

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

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

Об этом – следующая статья серии.

---

Родственные подходы и источники

1. Gojko Adzic, Impact Mapping: официальный сайт и материалы о связи целей, акторов, изменений поведения и результатов поставки.

2. John Ward, Elizabeth Daniel, Joe Peppard, Managing the Realization of Business Benefits from IT Investments: Benefits Dependency Network и связь выгод с бизнес-изменениями и ИТ-возможностями.

3. Project Management Institute, Benefits Realization Management Framework: выявление, получение и поддержание выгод на протяжении жизненного цикла инициативы.