После пилота. Как не потерять управление при переходе к промышленной эксплуатации
Граница, которой нет
Где заканчивается проект и начинается реальная эксплуатация? В теории этой границей является подписание акта приемки.
При этом эксперты напоминают, что акт приемки сам по себе — формальность, за которой начинается совсем другая история, когда внезапно оказывается, что старые правила работы с системой уже не работают, а новые еще не написаны. Также распространено мнение, что на практике часто остаются задачи, которые охватывают периоды и до, и после запуска. Например, проект планируется с датой завершения, скажем, 1 сентября. Все пребывают в счастливом заблуждении, что с этой даты система начнет работать. И в своей основе-то да, система сама по себе работает, но все еще остаются такие задачи, как обучение всех пользователей, миграция полного объема исторических данных, обработка исключений и изменения в бизнес-требованиях. Причем зачастую все эти задачи не планировались заранее, а появились в процессе внедрения.
По мнению эксперта, ключевым сигналом к тому, что у системы началась «настоящая взрослая жизнь», будет не согласованная дата, а тот факт, что хотя бы один пользователь решил в этой системе хотя бы одну свою задачу. С этого момента у системы появляется ответственность.
Таким образом, хороший пилот заканчивается не словами «робот работает», а словами «да, это полезно, давайте дальше».
Если подытожить высказывания экспертов, то все они, по сути, вращаются вокруг простой мысли о том, что многие воспринимают запуск как финишную черту и возможность, наконец, спокойно почилить. Но на самом деле это старт. И если вы не готовы к марафону, лучше не выходите на дистанцию.
Риски, которые не прописаны в ТЗ
Специалисты перечислили целый букет рисков, которые проявляются после пилота, и почти все они связаны с людьми, а не с технологиями.
Характерно, что именно эту проблему, назовем ее «риск утечки знаний», отмечают практически все. Технический директор Qlever Solutions Андрей Харлак добавляет еще четыре типовых риска: качество данных, неприятие системы пользователями, архитектурные ограничения и постоянное расширение требований со стороны бизнеса. Последствия этих рисков действительно важны. Если нет владельцев данных и единых правил, пользователи получают разные результаты из разных источников. Неудобные отчеты и несоответствие привычным сценариям вызывают отторжение. И, наконец, если на пилоте производительности существующих аппаратных средств не хватает, а «хотелки» никогда не заканчиваются, то при масштабировании система задыхается.
Александр Бочкин (генеральный директор Инфомаксимум) смотрит на риски с двух сторон — клиентской и вендорской. Для клиента основной риск — что внедрение не перейдет в полноценное использование. Технически все реализовано, но у команды нет понятной «дорожной карты»: «сотрудники просто не понимают, какие задачи система помогает решать и какую пользу дает лично им. Новое ПО превращается в дополнительную нагрузку». Для вендора ситуация зеркальная: если клиент не научился работать с системой, растет число типовых обращений в поддержку, что увеличивает стоимость сопровождения.
Но самый, пожалуй, самый показательный риск описал представитель Rubytech.
При этом попытка решить задачу за счет расширения штата рассматривается экспертом как отдельный риск. По его словам, распространен сценарий, когда задачу пытаются решить, бросая в атаку команду разработчиков. Компания нанимает значительное число специалистов и приступает к развитию собственных продуктов, рассчитывая вывести их на рынок. Сценарий, как правило, повторяется: сначала расходы на ИТ снижаются, затем штат увеличивается до тысяч, ФОТ растет без ограничений, специалисты дублируют существующие решения, и в итоге компания работает на тех технологиях, в которых компетентна нанятая команда.
Ну и как тут не вспомнить фразу из фильма «Офицеры»? «Командир обязан думать, понимаете? Думать, а не шашкой махать». В ИТ-мире после пилота шашка наголо с криком «Ура!» уже не поможет. Нужно думать о том, как удержать знания, как масштабировать инфраструктуру и как не дать бизнесу задавить систему бесконечными «хотелками», о чем, кстати, будет отдельный разговор, не переключайтесь.
Кто за штурвалом?
Ответ на вопрос о том, кто владеет системой после ее внедрения на первый взгляд очевиден: кто за все платит, тот всем и управляет. Но эксперты утверждают, что это верно лишь с некоторыми оговорками.
Дмитрий Бутмалай считает, что владельцем системы является бизнес, поскольку именно он ее финансирует. Но тут же добавляет, что ключевое значение имеет то, как выстроена эксплуатация. Эксперт описывает две полярные модели: традиционную, где разработчик передает ПО эксплуатирующему подразделению, и противоположную, где все работы выполняет разработчик, а заказчик предоставляет ресурсы по модели частного облака. Между ними, по его мнению, находится ряд промежуточных слоев, включая DevOps.
Есть важное уточнение, согласно которому у системы должен быть назначенный официальный владелец системы с соответствующими полномочиями и бюджетом на развитие.
При этом Роман предлагает еще и разделять бизнес-владельца, который отвечает за ценность, и технического владельца, который отвечает за работоспособность и доступность. Разграничение фиксируется в матрице RACI.
Андрей Харлак для BI и DWH-систем предлагает совместную модель. По его мнению, «аналитическая система находится на стыке бизнеса и ИТ, поэтому ни одна из сторон не может полноценно управлять ею самостоятельно». В зрелых компаниях появляется отдельная роль Data Product Owner как своего рода связующее звено.
А вот Антон Фокин (Qtim) смотрит на вопрос проще: «Go-live воспринимают как конец: подписали акт, отчитались наверх, распустили команду, срезали бюджет. А по факту именно в этот момент нагрузка максимальная, пользователи только пришли, вопросы сыплются пачками. То есть людей убирают ровно тогда, когда они нужнее всего».
Создается впечатление, что вопрос владельца не только и не столько про назначения, сколько про готовность бизнеса взять на себя ответственность за новую систему. А назначение владельца, ответственного за эксплуатацию, или назовите эту должность как хотите, это важный элемент мозаики. Но важно также понимание бизнес-логики ИТ-службой и способность продукта жить своей жизнью, а не быть «галочкой». Если чего-то из этого не будет, то неудачное внедрение практически гарантировано и ваш назначенец даже при наличии блестящих управленческих данных рискует стать мальчиком для битья.
Это неудобная правда. Ни вендоры, ни интеграторы обычно не говорят этого вслух, чтобы не обидеть заказчиков, но в ИТ-практике сплошь и рядом назначают такого «владельца» или «ответственного за систему», давая ему ноль рычагов, когда бюджет не его, команда не его, сроки спущены сверху, а бизнес-логику он узнает уже после того, как все сломалось. И когда система не взлетает, крайним делают именно его.
В итоге владелец системы становится владельцем проблем, а бизнес продолжает делать вид, что все под контролем, пока следующий пилот не покажет те же "отличные" результаты. Чтобы этого не случилось, эксперты назвали еще ряд проблем и предложили решения, которые подразумевают больше, чем назначение владельца.
Техдолг и бесконечный тюнинг
Казалось бы — разделяй и властвуй. Но как выделить в отдельные направления поддержку, развитие, исправление ошибок, техдолг и новые бизнес-требования? И нужно ли вообще это делать? Этот вопрос оказался одним из самых болезненных. И на него эксперты смотрят каждый со своей колокольни.
Начнем с техдолга. Не секрет, что простые и поспешные технические решения зачастую приводят к накоплению проблем в коде и архитектуре системы, что может вызывать необходимость доработки или полного переосмысления ее в будущем. Эксперт Rubytech предлагает полностью отказаться от накопления техдолга и рассматривать все работы как части единого процесса. Он сравнивает техдолг с бесконечным тюнингом автомобиля вместо покупки нового. Дмитрий Бутмалай предлагает модель перехода к эксплуатации, в соответствии с которой за ПСИ следует стандартный циклический процесс PPDIO или «перевернутая восьмерка» DevOps. «Это стандартный цикл сервисной компании, который не делится на изолированные части, а последовательно переходит из одной стадии в другую», — говорит он.
Существует и такой вариант — единое окно для любых обращений, включая поддержку, исправление ошибок, работу с техдолгом и небольшие доработки. А для более сложных можно сделать отдельный трек.
Однако даже такой подход требует железобетонной организационной базы. Иначе все эти категории останутся лишь красивыми словами на презентации.
Анастасия Бурмистрова из СЭД ТЕЗИС предлагает проводить мониторинг с реальными порогами срабатывания. «Должна быть зафиксированная матрица прав доступа, регламент об уровне сервиса с эскалацией по уровням критичности и бэкап, восстановление из которого хотя бы раз проверили разработчики. Часто все это делают для галочки к приемке, и первый серьезный сбой показывает, что план восстановления никто не тестировал», — сетует она.
А чтобы система вообще не попала в эксплуатацию с «дырами», Денис Нагаев, CTO OSMI IT, советует задать себе неудобный вопрос до запуска: а что будет, если она начнет ошибаться в реальном бизнес-процессе?
По мнению экспертов, разделение должно быть не формальным, а содержательным. Главное здесь — это не путать поддержку с попыткой удовлетворить растущие требования к продукту со стороны бизнеса или заказчика. С одной стороны, эти требования отражают меняющиеся потребности рынка, стратегии компании или пожелания пользователей. С другой стороны, нужно уметь сосредотачиваться на развитии самых важных функций. Иначе система превращается в «швейцарский нож», который пытается делать все и сразу, но в итоге толком не справляется ни с чем.
Поддержка как айсберг
Как должна быть устроена поддержка? Эксперты утверждают, что это не просто «горячая линия». Дмитрий Бутмалай (Rubytech) считает, что поддержку пользователей должна вести сервисная служба, а не эксплуатация, а оборудование и системное ПО лучше отдать внешнему партнеру. Он также отмечает, что его компания перешла к модели «одного окна» для всего стека.
По мнению Александра Бочкина, поддержка должна начинаться еще на пилоте и включать не только техническую помощь, но и консультации, разбор ошибок и обучение, причем разное обучение для разных ролей. По его словам, в Инфомаксимум для этого выстроен отдельный контур информационно-консультационного сопровождения, включающий уроки, практические задания и базу знаний.
А как это выглядит на практике для массовых систем? Команда СЭД ТЕЗИС описывает стандартную модель трех линий поддержки. Первая закрывает типовые обращения, вторая разбирается в логике процессов и конфигурации, третья уже подключает разработчиков, но только если есть отдельный канал для запросов на доработку. «Если его нет, пользователи заваливают поддержку абстрактными просьбами, и уровень работы по реальным инцидентам проседает», — отмечает команда СЭД ТЕЗИС, и мы еще вернемся к их советам в заключительном разделе.
Иными словами, эксперты так или иначе подводят нас к тому, что возможности поддержки ограничены не железом, а головами. И главная ошибка здесь в традиционном откладывании на «завтра» того, что нужно сделать сегодня. Заказчики думают о поддержке в последнюю очередь по принципу «Сначала строим систему, а потом думаем, кто будет ее поддерживать». В реальности поддержка должна быть заложена в проект с самого начала.
Иллюзия контроля
Какие показатели помогают понять, что система действительно под контролем? Эксперты считают, что одних технических метрик недостаточно.
Роман Мезенцев предлагает разделять бизнес-метрики, измеряющие полезность, и технические (нагрузка на процессоры и память). При этом он добавляет еще один важный слой, предлагая испытания на непрерывность.
Андрей Харлак (Qlever Solutions) рекомендует отслеживать показатели на четырех уровнях: инфраструктура, качество данных, эксплуатация и бизнес-эффект. На инфраструктурном уровне эксперт предлагает отслеживать доступность и время отклика, качество данных измерять их полнотой и количеством ошибок, на этапе эксплуатации мониторить количество регулярно работающих пользователей, а к показателям бизнес-эффекта он относит сокращение времени на подготовку отчетности и уменьшение ручной работы.
Ольга Конарева, руководитель консалтинга и обучения Just AI и лидирующий в обзоре эксперт по количеству ТБА (трехбуквенных аббревиатур), предлагает оценивать систему по четырем группам показателей. Экономические, по ее мнению, должны включать возврат инвестиций (ROI) и сокращение операционных затрат (OPEX). Операционные показатели она предлагает измерять долей автоматизированных операций и временем ответа системы. К качественным относит точность работы AI-инструментов и индекс потребительской лояльности (NPS). А технические показатели, по ее словам, отражают стабильность работы и производительность при росте нагрузки. Такой набор, считает эксперт, позволяет увидеть не только, работает ли система, но и приносит ли она реальную пользу бизнесу.
Команда СЭД ТЕЗИС добавляет, что достаточно смотреть на три показателя. Это доступность, качество данных и активность пользователей. Они предупреждают: если мерить только аптайм, можно получить идеально работающую систему, которой никто не пользуется.
И это, пожалуй, главный парадокс контроля. Можно настроить мониторинг всего, что движется, но если система не приносит пользы, то все эти цифры ничего не стоят. Как говорил персонаж из кинофильма «Служебный роман»: «Если бы не было статистики, мы бы даже не знали, насколько хорошо мы работаем». Но статистика показывает лишь то, что вы решили измерить. А измерить реальную пользу гораздо сложнее, чем аптайм.
Популярные модели граблей
По отзывам экспертов можно буквально составить рейтинг ошибок, которые компании чаще всего допускают при переходе от пилота к промышленной эксплуатации. Первая и главная ошибка заключается в том, что люди в компаниях путают понятия «запустили» и «внедрили». В ситуациях, когда люди тяготеют к старым методам работы, эксперт из Qtim предлагает переход на новую систему по принципу «не умеешь — научим, не хочешь — заставим».
«На бумаге система в проде, галочка стоит, а половина людей продолжает вести свой Excel, потому что привычнее и никто не заставил перейти. Меряют успех фактом запуска, а не тем, пользуются ли реально и появился ли эффект. Если осталась лазейка делать по-старому, ей воспользуются. Внедрение — это когда старый способ закрыт, а новый удобнее, а не когда "система принята в эксплуатацию"», — говорит Антон Фокин.
Вторая проблема тоже классическая. Это когда систему масштабируют без пересмотра инфраструктуры и процессов. Команда СЭД ТЕЗИС напоминает о важности стресс-тестов. «То, что работало на полусотне пользователей, может развалиться на паре тысяч. Временные решения, придуманные на пилоте, переезжают в прод как есть».
Третья ошибка — недооценивать объем обучения. Наталия Кашичкина отмечает, что обучение полного набора будущих пользователей часто проводится сразу после финального тестирования, но система еще не готова, не содержит полных данных. В результате обучение проходит на тестовых данных, не покрывающих все случаи. Пользователи приходят в систему и сталкиваются с вопросами, которые не возникали в обучении.
«Самая частая ошибка в том, что компании воспринимают пилот как отдельный проект. Сделали робота, убедились, что технология работает, и остановились. Мы всегда рекомендуем ещё до старта договориться, что будет, если пилот окажется успешным. Кто будет принимать решение о масштабировании? Есть ли бюджет? Какие процессы станут следующими? Если об этом не подумать заранее, даже успешный пилот может так и остаться разовым экспериментом», — считает Алексей Николаев из Primo RPA.
В России, согласно данным, которые приводит Ольга Конарева, «только 7–10% пилотных проектов больших технологических компаний, запущенных в 2025 году и связанных с внедрением LLM, чат-ботов и агентов, дошли до полноценного внедрения. Остальные 90% либо остаются в стадии пилотирования, либо трансформируются, либо закрываются». И причина не в технологиях, а в отсутствии инфраструктуры, операционной поддержки и организационной модели.
«Импортозамещение требует доработки системы, и чем больше данных и нагрузка, тем существеннее объем изменений в коде, а в ряде случаев и в бизнес-логике. Как правило, этот фактор не учитывается», — отмечает Дмитрий Бутмалай. Например, когда «разработчик, ранее ограниченный в ресурсах, получает высокопроизводительное импортонезависимое решение — и перестает уделять внимание качеству кода, полностью загружая инфраструктуру».
По его словам, обычно подсказки при вводе поискового запроса обеспечиваются небольшим кэшем, а в одном решении при вводе каждой новой буквы система выполняла полное сканирование базы — и это оставалось незамеченным до ошибочного обновления, нарушившего индексы.
Система есть, эффекта нет
Один из самых болезненных вопросов постпилота касается успешно введенных в эксплуатацию систем, которыми никто не пользуется. Эксперты попытались дать ответ на вопрос о том, кто виноват и что делать, если система формально внедрена, но пользователи обходят ее, данные заполняются плохо, а бизнес-эффект не виден. Можно начать с разговора с пользователями. Так проще всего понять, в чем причина.
Провести аудит использования, превратив аналитику в ежедневный инструмент, найти «чемпиона» внутри бизнеса, который «хорошо понимает процессы, активно использует систему и готов продвигать ее среди коллег», советует Андрей Харлак. Регулярное обучение, развитие функциональности с учетом новых потребностей и постоянный диалог с пользователями позволяют постепенно повысить доверие.
Жизнь после запуска
За всеми этими рисками, метриками и моделями поддержки скрывается простая, но неудобная истина: переход от пилота к промышленной эксплуатации давно перестал быть технологической задачей и стал задачей управленческой и, если можно так сказать, человекозависимой.
Эксперты в один голос говорят про качество данных, владение, обучение и поддержку. Но компании все равно экономят на аудите, назначают ответственных по совместительству, распускают команду сразу после подписания акта и надеются, что «все как-нибудь само образуется». Не образуется. Будут месяцы простоя, сорванные планы и уволившиеся команды.
«Важно решать проблемы не в одиночку, а совместно с партнерами — интегратором и вендором. Нередко проблема, с которой столкнулся один заказчик, уже была решена у другого», — говорит Дмитрий Бутмалай. И это, пожалуй, главный урок: никто не владеет всей полнотой знаний. И чем раньше компания это признает, тем быстрее она перестанет наступать на одни и те же грабли.
В конечном счете успешным считается не тот проект, который завершился в срок, а тот, после которого система действительно приносит пользу, а команда не разбегается в ужасе. А чтобы этого не случилось, главное — не почивать на лаврах, перепутав старт с финишем, а наоборот, не снижая скорости, идти на второй круг и продолжать действовать исходя из того, что после пилота все только начинается.
Опубликовано 07.09.2026
