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

TL;DR

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

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

• Диагностический паспорт полезен не набором полей, но качеством проверки и полномочиями вернуть инициативу на доработку.

• Диагностика может привести не к запуску проекта, но к изменению постановки, разделению инициативы, принятию риска или отказу от автоматизации.

• В конце статьи есть заполненный пример и компактный шаблон диагностического паспорта.

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

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

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

Идея автоматизации не была искусственной: болезнь существовала. Но диагноз ещё никто не поставил.

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

Назначили меня.

---

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

Ответ бизнеса был логичным: у нас есть срок и бюджет, поэтому давайте определим, что из всего этого можно в них уложить. Нужно сделать что-нибудь – поручение сверху о проекте уже есть.

Бизнес не отказывался разбираться. Он защищал управленческое обязательство: срок уже прозвучал, финансовый коридор обозначили, руководство ожидало движения. Возвращаться с сообщением «мы пока выясняем, существует ли здесь проект» было неудобно.

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

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

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

Лекарство показали раньше диагноза

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

Ошибка возникла в другом месте. Презентация ответила на вопрос:

Как может выглядеть современное управление закупками?

Но организация восприняла её как ответ на другой:

Что именно мешает нам управлять закупками?

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

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

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

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

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

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

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

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

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

Кому выгоден ранний старт

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

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

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

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

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

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

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

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

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

Как получить мандат на диагностику

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

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

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

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

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

Скрытый текст

Позднее бизнес-заказчик поддержал переход от одного проекта к программе и участвовал в длительном пересогласовании сроков и бюджета с руководством.

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

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

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

По моим тогдашним оценкам, контур охватывал около пятидесяти подразделений, в отдельных массивах могло находиться 20–35% потенциальных дублей, а закупщики оценивали ручную работу, сверки и Excel примерно в две трети рабочего времени. Формального аудита этих показателей не проводилось.

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

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

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

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

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

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

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

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

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

Жалоба, проблема, причина и решение

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

В нашем случае симптомы были вот такие:

• разрозненные закупки,

• разные цены и сроки,

• дефицит или наоборот, избыточные запасы,

• ошибки ручной консолидации и отсутствие сквозной прослеживаемости.

Проблема же находилась уровнем выше:

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

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

Здесь работает простой тест:

Хорошая формулировка проблемы сохраняет смысл после удаления названия продукта.

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

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

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

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

Где заканчивается диагностика

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

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

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

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

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

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

Диагностический паспорт бизнес-инициативы

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

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

В этом нет методологического пробела. Анализ ситуации, оценка потребности и формулировка проблемы уже существуют в Business Case, Needs Assessment, Project Charter, Lean A3, Problem Statement, BRD и других практиках. Разрыв возникает не между методологиями, а между методологией и корпоративной практикой: документы, задуманные как основание для решения, систематически вырождаются в форму его согласования.

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

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

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

Качественный паспорт должен выдерживать содержательную проверку:

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

• гипотезы причин отделены от подтверждённых фактов;

• определён контур процессов, данных и систем за пределами инициатора;

• названы владельцы результата, процессов, данных и решений либо честно зафиксировано их отсутствие;

• предлагаемое решение связано с конкретной проблемой, а не только с функциями продукта;

• критические неизвестные не спрятаны под формулировкой «уточнить в ходе проекта»;

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

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

Опасен не пустой паспорт. Опасен паспорт, заполненный полностью, но не проверенный по существу.

Какое решение должен дать паспорт

Паспорт не обязан завершаться одобрением инициативы. Он должен создать основание для одного из решений:

1. подтвердить проблему и перейти к формулированию ценности;

2. изменить формулировку проблемы;

3. разделить инициативу на несколько проектов;

4. сузить первую реализацию, сохранив законченную бизнес-логику;

5. продолжить с явно принятым риском;

6. вернуть инициативу на дополнительную диагностику с конкретными вопросами и ответственными;

7. отказаться от автоматизации как преждевременного решения;

8. прекратить инициативу.

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

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

Хорошая диагностика не обязана сохранить проект. Она обязана сохранить компании возможность принять осознанное решение.

Как выглядел бы паспорт в нашем случае

Это не копия реального документа, а реконструкция по материалам проекта и моим воспоминаниям.

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

Шаблон для практического применения

Для типовой инициативы первый диагностический цикл может состоять из 2–4 встреч по 1,5–2 часа, анализа доступных материалов и нескольких дней на сведение противоречий. Результатом обычно становятся 3–5 содержательных страниц. Для крупных программ объём будет больше, но он должен определяться ценой ошибочного старта, а не желанием описать компанию полностью.

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

Где инструмент ломается

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

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

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

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

Проект начинается не с паспорта

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

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

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

Диагностика не раздула проект. Она показала реальный масштаб изменений.

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

Правильно поставить диагноз и провести лечение ещё не означает доказать, что пациенту стало лучше.

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

—*- Следующая статья серии будет о ценности: как перейти от слов «прозрачность», «эффективность» и «снижение трудозатрат» к проверяемым выгодам, критериям успеха и метрикам, связывающим требования с бизнес-результатом -*-