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

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

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

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

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

Проект к этому моменту шёл третий год.

---

Четыре дефицита

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

1. Нет функционального заказчика — дефицит субъекта.

2. Заказчик появился, но незрелый — дефицит модели.

3. Система готова, перехода нет — дефицит движения.

4. Переход продавили, получили имитацию — дефицит смысла.

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

---

Почему худший сценарий — это норма

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

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

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

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

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

---

Что такое триаж на внедрении

Дальше — по фазам. Но с одной оговоркой, которая меняет всё.

Задача каждой фазы — не спасти проект, а не отнять у следующей фазы её последний шанс.

Фазы не решаются, они передают наследство. И валюта наследства ровно одна — обратимость.

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

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

Ни один из описанных ниже ходов не спасёт проект. Они делают его провал дешевле и оставляют что-то работающее.

---

Фаза первая: денег дали, заказчика нет

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

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

• проект стоит в его личных KPI;

• он принимает окончательное решение по процессу: может сказать «работаем так», и обсуждение на этом заканчивается;

• у него есть время на проект в календаре.

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

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

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

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

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

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

---

Фаза вторая: заказчик есть, зрелости нет

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

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

Именно здесь fit-to-standard перестаёт быть способом сэкономить и становится обучающей конструкцией. У незрелого заказчика нет модели процесса, и стандарт вендора — единственная готовая модель, доступная ему прямо сейчас. Кастомизация до появления зрелости — это дорогая консервация текущего беспорядка в коде. Когда зрелость вырастет, кастомизация окупится; до этого она оплачивает воспроизведение того, от чего уходили.

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

«Чего изволите» как бизнес-модель

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

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

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

Fit-to-standard нигде не запрещён. Он просто сделан самым дорогим из возможных путей.

Одна фатальная клетка из четырёх

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

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

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

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

Вина обоюдная, но не симметричная

Незрелый заказчик по определению не знает, что он не знает — в этом и состоит незрелость. Подрядчик знает или обязан знать. Асимметрия компетенции даёт асимметрию ответственности.

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

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

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

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

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

---

Фаза третья: система есть, перехода нет

Самая недооценённая фаза. Аргументы проработаны, возражения сняты, презентация показана, все согласны. Никто не перешёл.

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

Второе — и это неприятно для отрасли. Каноническая модель принятия технологий (TAM) измеряет воспринимаемую полезность как рациональную оценку по шкале. Именно поэтому она хорошо предсказывает намерение и плохо предсказывает использование. Инструмент, которым тридцать лет меряют принятие, по построению меряет согласие, а не переход.

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

Влюбиться не в систему, а в себя

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

Для внедрения это надо делать по ролям и предельно конкретно. Не «я цифровой», а:

— «я тот, кто закрывает период, не сверяя руками»; — «я тот, кто отвечает на вопрос руководства за пять минут, а не за два дня».

Одна фраза «я тот, кто…» на каждую роль — и сразу проверка: есть ли в системе сегодня хоть что-то, что делает эту фразу правдой. Если для роли вписать нечего, эта роль не перейдёт, и давление ничего не изменит.

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

Почему страх — не тот рычаг

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

Ход рабочий по форме и опасный по содержанию.

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

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

Страх производит имитацию перехода. Не переход.

Более точную формулу дал Эдгар Шейн: изменение начинается, когда тревога выживания превышает тревогу обучения. Но поднимать первую опасно — она же блокирует освоение. Работает снижение второй: право быть некомпетентным на новой системе, отсутствие наказания за ошибку в переходный период.

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

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

Интерес как статья затрат

Вернёмся к трём полям и пятнадцати человеко-часам.

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

• пользователь наткнулся в работе — минуты;

• пользователь сам залез посмотреть — десятки минут;

• совещание — человеко-дни;

• продуктивная эксплуатация, когда ошибка уже ушла в отчётность — недели плюс репутация.

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

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

Опытную эксплуатацию не продлили. Её не было

Теперь самое неприятное наблюдение этой фазы.

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

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

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

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

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

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

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

---

Фаза четвёртая: продавили

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

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

Теневой контур. Работа ведётся в Excel, система заполняется по остаточному принципу. Самая заметная и самая безобидная форма — её хотя бы видно.

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

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

Тревога находится не там, где нужно поведение

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

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

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

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

Диагностика: не объём замечаний, а их грамматика

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

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

Замечание-заявка содержит собственное будущее действие автора: «сделайте это поле необязательным — и я закрою период за день». Автор поместил себя внутрь системы.

Замечание-алиби бессубъектно и открыто: «система не готова, не учтён случай N». Автор поместил себя снаружи и оформил доказательство.

Тест занимает одну секунду: есть ли в замечании «и тогда я». Если нет — это не обратная связь, это документирование непричастности, и журнал замечаний работает как папка алиби.

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

Соломка

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

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

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

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

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

---

Что будет дальше

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

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

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

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

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