Автоматизировать бардак нельзя навести порядок

В предыдущей статье о ГОЭЛРО я писал о программе «А»: прежде чем строить новые мощности, план предусматривал восстановление и реконструкцию существовавшего энергохозяйства. Сначала вернуть основанию работоспособность — и лишь затем возводить на нём новое. Исторически эта часть плана действительно называлась программой «А»; такое описание приводит, в частности, Минэнерго России.

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

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

По обе стороны баррикады спор обычно формулируют одинаково: кто должен диктовать автоматизацию — бизнес или ИТ?

Я всё больше думаю, что это неправильный вопрос.

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

Но одного разделения на «что» и «как» недостаточно. Именно здесь между бизнесом и ИТ годами ломают копья.

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

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

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

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

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

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

Это диагностика.

Проект, который появился раньше своей цели

Есть корпоративный ритуал, который мне приходилось наблюдать неоднократно.

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

Почти сразу проблема получает форму решения:

• Нужно внедрить новую ERP

• Нужно автоматизировать закупки

• Нужен единый справочник

• Нужно заменить зарубежные системы отечественными

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

Так возникает проект, который появился раньше собственной цели.

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

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

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

Теперь я не уверен, что такая оценка справедлива.

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

Новая ERP выглядит проектом. Пересмотр ответственности между подразделениями — уже не так убедительно.

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

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

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

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

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

После этого исходная цель меняется. Вместо «внедрить маршрут согласования» появляется задача унифицировать правила, распределить ответственность и только затем закрепить договорённости в системе.

Можно ли считать это провалом первоначальной постановки? Формально — да: бизнес просил одно, а получил другой проект. По существу — нет. Хуже было бы сохранить первоначальную цель только потому, что под неё уже согласовали бюджет.

Постоянство ошибочной цели — не признак зрелого проектного управления.

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

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

Исследование не прекращается. Оно маскируется под внедрение.

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

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

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

Сырая идея — нормальное начало исследования. Но это плохое основание для фиксации обязательств по реализации.

ИТ в такой ситуации должно иметь право сказать:

Сейчас мы не внедряем решение. Мы выясняем, какое решение вообще требуется.

Почему диагностика внутри реализации всегда дороже

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

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

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

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

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

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

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

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

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

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

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

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

Это уже не уточнение требований.

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

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

В этот момент проект впервые сталкивается со своей реальной стоимостью.

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

Изменился не объём работ внутри проекта. Изменилось представление о самом проекте. Но формально он продолжал жить со старым бюджетом и сроком.

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

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

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

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

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

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

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

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

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

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

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

Неопределённость не исчезает оттого, что инициативе присвоили статус «в реализации». Она просто становится дороже.

Что меняется, когда диагностика предшествует обязательствам

На стороне заказчика я увидел другой сценарий.

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

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

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

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

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

Участники выполняли свои операции, но по-разному понимали, где заканчивается ответственность одного подразделения и начинается ответственность другого. Одни считали, что передали результат. Другие — что получили только исходные данные для проверки. Возникали задержки и возвраты, но каждый участник мог доказать, что свою часть выполнил.

Процесс существовал. Ответственность за сквозной результат — нет.

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

Но цветной индикатор не отвечает на главный вопрос: кто должен принять решение, чтобы процесс продолжился?

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

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

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

Только после этого появилась реализация проекта. Её изменения проверялись одним вопросом:

Приближает ли это нас к той управляемости, ради которой проект был начат?

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

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

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

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

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

Первое полезное действие ИТ в такой ситуации — не изображать ускорение разработки, а вернуть инициативе честный статус.

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

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

Где заканчивается последнее слово бизнеса

Фраза «бизнес определяет требования, а ИТ их реализует» звучит разумно. Проблема начинается, когда её понимают буквально.

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

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

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

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

В автоматизации граница проходит не между «умным ИТ» и «некомпетентным бизнесом». Она проходит между бизнес-решением и отсутствием решения.

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

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

Люди способны чувствовать контекст и договариваться об исключениях. Система требует точного ответа:

• в какой момент заявка считается принятой;

• кто отвечает за достоверность реквизита;

• можно ли продолжить процесс при отсутствии документа;

• какой справочник является источником истины;

• кто вправе принять риск и разблокировать операцию.

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

Отсюда четыре типичных риска.

Вакуум решений. Система начинает управлять бизнесом не потому, что ИТ захватило власть, а потому, что бизнес оставил пустое место.

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

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

Ложная прозрачность. Руководство получает дашборд и видит, что процесс стоит. Но если ответственность не определена, никакая визуализация не создаст человека, уполномоченного принять решение.

А затем возникает самый удобный риск: виноватым становится ИТ. Бизнес видит неудобную систему и растущую стоимость изменений. ИТ видит реализованные требования и сохранённые по настоянию подразделений исключения. Обе стороны по-своему правы.

Система построена ИТ. Но её сложность часто является материальным слепком решений, которые бизнес не смог принять.

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

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

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

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

Вето без диктатуры

У идеи права вето есть очевидная уязвимость. Стоит дать ИТ формальное право останавливать проекты — и найдётся архитектор, который объявит неготовым любой процесс, не соответствующий его представлению о прекрасном.

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

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

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

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

Перед допуском к реализации должны существовать три опоры.

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

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

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

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

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

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

Если опор нет, инициатива возвращается в честный статус: диагностика, проектирование процесса или подготовка бизнес-решения.

В этом разница между вето и блокировкой.

Блокировка отвечает: «нет».

Отлагательное вето отвечает: «пока нет — и вот что должно произойти, чтобы стало можно».

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

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

Так бизнес получает защиту от архитектурной диктатуры, а ИТ — от принудительной автоматизации неопределённости.

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

Почему ИТ видит катастрофу, но продолжает внедрение

Если противоречия заметны, почему ИТ не останавливает проект?

Потому что в большинстве компаний оно не может этого сделать.

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

ИТ остаётся выйти ночью на путь с фонарём и проверить рельсы.

И обнаружить, что впереди они обрываются.

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

ИТ видит обрыв первым. Но права остановить поезд у него нет.

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

Главное — не снижать темп.

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

Если получится, все скажут, что опасности не было.

Если нет — спросят, почему ИТ не предупредило раньше.

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

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

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

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

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

В этот момент становится понятно, почему протокол не заменяет полномочия.

Фраза «риск зафиксирован» не означает, что риск управляется. Часто она означает, что команда документально подготовилась к будущему поиску виноватых.

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

У каждого есть ответственность за свою часть. За итог не отвечает никто.

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

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

Срок конкретен. Стратегическая цель растворима.

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

ИТ часто обвиняют в том, что оно тормозит бизнес. Но гораздо опаснее ИТ, которое никогда не тормозит. Оно принимает любую постановку, легко обещает сроки, переводит каждое противоречие в дополнительную настройку и героически запускает систему к объявленной дате.

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

Зрелость ИТ измеряется не только скоростью реализации. Иногда — способностью вовремя сказать:

Мы можем это разработать. Но пока не можем доказать, что именно это нужно строить.

И быть услышанным.

Остановить — не значит бросить

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

Формально позиция безупречна. Практически — бесполезна.

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

Если ИТ использует вето только для возврата проблемы заказчику, оно не защищает бизнес от ошибки. Оно отказывается участвовать в поиске решения.

Поэтому остановка должна создавать не тупик, а развилку.

ИТ обязано показать:

• конкретное противоречие и его последствия;

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

• стоимость и риски каждого варианта;

• решения, которые должен принять бизнес;

• условия, после выполнения которых реализация возобновится.

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

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

Диктатура говорит:

Будет так, потому что иначе архитектурно неправильно.

Безответственность говорит:

Решайте сами, это не наша проблема.

Зрелое ИТ говорит:

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

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

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

Но наиболее сложная обязанность ИТ начинается до снятия вето: помочь бизнесу перестроить процесс, не подменяя владельца.

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

Так ИТ превращается из контролёра готовности в участника подготовки изменений.

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

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

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

Настоящее вето звучит не как отказ:

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

Это не торможение изменений. Это управление их траекторией.

Сначала программа «А»

У автоматизации тоже есть своя программа «А».

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

Без этого информационная система не создаёт новый порядок. Она консервирует старый.

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

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

Спор «кто главный — бизнес или ИТ» изначально поставлен неправильно.

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

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

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

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

Одна сторона не может сказать: «Это ваша система — сами придумайте, как всё должно работать». Другая — «Это ваш бизнес — возвращайтесь, когда наведёте порядок».

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

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

Меняется другое: стороны перестают воспринимать друг друга как препятствие.

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

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

Но строить мост через этот обрыв они должны вместе.

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

Она начинается тогда, когда бизнес и ИТ перестают автоматизировать друг друга — и вместе начинают менять компанию.