Поделиться
Особенности национального импортозамещения: разбираем типичные проблемы (часть 1)
Процесс импортозамещения ИТ и ИБ в России идет уже много лет. Казалось бы, за это время в интернете и СМИ должны были появиться масса материалов от практиков, как нашим отечественным заказчикам лучше всего провести процесс импортозамещения, но, к сожалению, их очень немного. Чтобы исправить это упущение, публикуем серию материалов, написанных Станиславом Андросовым, руководителем отдела комплексных проектов группы компаний MONT.
Особенности национального импортозамещения
Предлагаю поделиться основными результатами нашего исследования выявления причин неудачных проектов импортозамещения. Этот анализ базируется на моем более чем 20 летнем опыте работы с американскими, европейскими, израильскими, азиатскими и российскими производителями. Большую часть времени я занимался swap-проектами (пер. с английского «замена», проектами по миграции целевого решения одного производителя на другого) в крупных заказчиках в России, странах СНГ и Турции, работая на стороне производителей и авторизованных дистрибьюторов.
Как показывает практика, большинство неудачных отечественных проектов импортозамещения имеют одни и те же проблемы. К моему большому удивлению, когда общаешься с заказчиками и вместе с ними анализируешь причины этих неудач, они искренне удивляются тому, что важнейшие этапы работ для любого успешного swap-проекта не были сделаны.
Прежде всего, классический swap-проект — это обычно миграция на более функциональное решение, которое имеет дополнительные расширенные возможности. Все иностранные вендоры, в которых я работал, считали, что из всех оказываемых ими услуг, проекты по миграции являются самыми сложными и ответственными, поэтому они в своем штате держат одну или две глобальные команды, которые занимаются только swap-проектами. В этих командах работают лучшие специалисты компании, которые плотно взаимодействуют с дирекциями по разработке (research and development). Инженеры в этих swap-командах всегда обладают хорошим практическим опытом работы с конкурентными решениями (обычно ранее работали у конкурирующего вендора, реже у заказчика), и одной из их важнейшей обязанностью является отслеживание появления нового функционала у конкурентных решений и информирование об этом команд разработки. Эти swap-команды — это так называемый инженерный «спецназ» любого вендора, который принимает участие в крупнейших swap-проектах на американском, европейском или азиатских рынках.
Самое интересное, что исходя из моего опыта, я вижу, что наши отечественные проекты по импортозамещению являются более сложными и требуют значительно больше ресурсов для успешной реализации, чем классические swap проекты, так как:
- Обычно это переход с более функционального иностранного решения на менее функциональное отечественное. Соответственно нужно заранее прорабатывать вопрос: какой ключевой для заказчика функционал текущего иностранного решения будет недоступен в отечественном решении и какими средствами, в какие сроки заказчик может получить этот отсутствующий функционал;
- Наши отечественные производители обычно не имеют необходимого инженерного вендорского опыта работы с заменяемым иностранным решением (в лучшем случае инженеру отечественного вендора показывали интерфейс этого иностранного решения, но как это решение реально работает “под капотом” данный инженер не знает). Поэтому в настоящее время проекты импортозамещения реализуются отечественными производителями фактически как новые greenfield проекты: когда параллельно с существующим иностранным решением разворачивается отечественное, после чего инженеры отечественного вендора просят заказчика рассказать, какие правила им нужно реализовать на новом решении, и затем обычно они вместе с заказчиком начинают разбираться почему некоторые политики работают не так или вообще не работают. Таким образом происходит классическое «блуждание в потемках», когда заказчик вместе с вендором бредёт от одной проблемы к другой, и никто не знает, какая будет следующей. При этом инженеры отечественного вендора знают, что пройдет определенное время и их перебросят на новый проект, а заказчик дальше будет общаться со службой технической поддержки отечественного производителя, которая часто просто не имеет необходимых ресурсов для решения его проблем.
Ключевые факторы успешной реализации swap-проекта
Когда я работал с глобальными вендорскими swap-командами, то усвоил их базовый принцип: «По факту заказчики не имеют необходимого опыта для успешной реализации swap-проектов, и не нужно пытаться им это доказывать». Поясню свою мысль: заказчики – это водители, которые хорошо знают интерфейс системы и умеют пользоваться настройками системы. Но есть еще два уровня:
- Инженеры авторизованного вендором сервисного центра, которые благодаря своим глубоким знаниям могут восстановить штатную работу системы, если она работает некорректно (или вообще не работает);
- Разработчики, которые глубже всех понимают, как система работает «под капотом» и имеют возможность ее «перебрать».
Соответственно ключевой фактор успешной реализации swap-проекта – это формирование команды с необходимой квалификацией, которая сможет провести корректное планирование миграции на целевую отечественную систему, её внедрение и при необходимости дальнейшее техническое сопровождение.
В swap-проектах в качестве первого шага всегда выполняется базовое функциональное сравнение политик текущего и нового решений. Для этого анализируется актуальный sysinfo текущей системы, который содержит все действующие политики, и затем готовится базовый документ с перечнем используемого заказчиком функционала. Далее этот перечень перепроверяется с заказчиком, ненужный функционал убирается, после чего готовится документ со сравнением используемого заказчиком функционала и возможностями нового решения. Обычно на этом первоначальном этапе выявляются первые расхождения в функциональных возможностях решений, которые сразу должны прорабатываться с заказчиком и отечественным вендором. В случае, если с заказчиком положительно решаются все открытые вопросы, т.е. заказчиком снимаются все вопросы по необходимости разработки вендором нового функционала (а это происходит, к сожалению, не всегда), тогда проект переходит на вторую стадию – разработка детального ТЗ (технического задания) на новую систему. В противном случае необходимо согласовать с отечественным производителем готовность разработки необходимого целевого функционала в рамках реализации данного проекта.
Возникает вопрос: почему в качестве первого шага выполняется именно анализ актуального sysinfo на соответствие функциональных возможностей текущего и нового решений? Ответ простой: обычно этот анализ выполняется квалифицированными специалистами за неделю, а проработка детального ТЗ на систему занимает от месяца до двух. Для примера во врезке представлен состав ТЗ на систему UEBA (систему агентского контроля действий пользователей). Добавлю, что самое детальное вендорское ТЗ делают разработчики: это документ, который обычно содержит десятки тысяч требований, но для решения нашей задачи импортозамещения такая детализация явно будет избыточной.
Таким образом наше ТЗ на систему UEBA содержит около 500 функциональных требований, а ТЗ на прокси-систему под 1000. При этом мы честно старались минимизировать количество пунктов, чтобы сделать наше ТЗ минимальным. Скажите честно, много ли вы встречали ТЗ на систему, в которых только технических пунктов более 100? Мне скажут: «Зачем нужна такая детализация? Вот раньше мы делали техническое ТЗ из 20-40 пунктов, и все было нормально». Здесь ключевой момент в том, что раньше обычно выбор происходил из лучших в мире на тот момент решений. Соответственно иностранные вендоры уточняли только какие-то значимые для себя моменты, а дальше считали, что с существующими функциональными возможностями своего решения они точно закроют все основные задачи заказчика. Плюс для ведущих международных производителей всегда большое значение имели репутационные риски, поэтому они не могли себе позволить «завалить» крупный проект, так как негативная пресса в одном регионе могла легко отразиться на выборе заказчиков в других частях света, а конкуренция на глобальном рынке всегда очень жесткая. К сожалению, в текущих реалиях отечественные производители часто не рассматривают серьезно возможные репутационные риски.
Следующий важный момент – качество проработки ТЗ с заказчиком и отечественным вендором. Как я писал выше, обычно заказчики не имеют достаточной компетенции, чтобы подготовить ТЗ требуемой для проекта импортозамещения глубины и качества, и соответственно заказчикам необходимо помогать не только в подготовке данного ТЗ, но и в его корректном заполнении, поясняя значимость ключевых функциональных требований. Если внешняя команда, которая помогает заказчику с проектом импортозамещения, поддерживает у этого заказчика текущее иностранное решение, тогда задача упрощается. Но если выбранная заказчиком команда не занимается технической поддержкой у этого заказчика текущего иностранного решения, тогда задача заполнения ТЗ сильно усложняется. А если эта команда не имеет глубокого «подкапотного» опыта работы с установленной у заказчика иностранной системой, то данная миссия видится почти невыполнимой.
Также важным моментом является корректная проработка с отечественным вендором заполненного заказчиком ТЗ с тщательной верификацией предоставляемых отечественным производителем ответов. Бывает, что отечественные вендоры в своих ответах выдают желаемое за действительное, и когда им указываешь на эти факты, они просто говорят: «Мы не так поняли данное функциональное требование». Поэтому необходимо хорошо знать реальные возможности отечественного решения в актуальном релизе ПО, чтобы на примере развернутой в лаборатории системы можно было показать, что именно хочет получить заказчик. Обычно первое согласование ТЗ занимает от одного до двух месяцев.
Как показывает практика, с очень большой вероятностью в ТЗ найдется функционал, который будет являться критичным для заказчика, и отсутствие которого не позволит ему начать пилот этого отечественного решения. Соответственно далее нужно подготовить для отечественного производителя детализированное целевое ТЗ на критически необходимый заказчику целевой функционал и ждать, когда он появится в новом релизе. Так же параллельно необходимо согласовать с вендором разработку функционала, который должен появиться к моменту начала внедрения данного отечественного решения у заказчика, подготовив детализированное ТЗ и на этот функционал.
Проходит в среднем год-полтора от начала пресейла по проекту, и наконец появляется релиз с нужным заказчику функционалом для пилотного тестирования, и вендор подтверждает, что дополнительно реализует нужный заказчику функционал к моменту начала внедрения. Прежде всего релиз нужно проверить в своей лаборатории и прогнать программу тестов. Обычно на этом этапе выявляется несколько (в лучшем случае) программных ошибок, которые не позволяют начать пилот у заказчика, поэтому в этом случае необходимо задокументировать эти программные баги и выслать полную диагностическую информацию вендору. Обычно за срок от нескольких месяцев до полугода отечественный вендор решает эти проблемы, и далее необходимо опять провести в своей лаборатории функциональное тестирование нового релиза отечественного решения, чтобы убедиться, что его можно пропилотировать у заказчика. Почему первое функциональное тестирование стоит делать в своей лаборатории? Ответ простой. Если эти программные ошибки выявит заказчик, то с высокой долей вероятности не получится оперативно решить эти проблемы, и далее заказчик завершит данный пилот с внутренним комментарием, что представленное на пилот решение оказалось слишком “сырым” и поэтому не может быть развернуто в продуктивной среде заказчика. И в результате заказчик сможет вернуться к повторному пилоту только через год, и это в лучшем случае.
После этого функциональное и нагрузочное тестирование у заказчика пройдет скорее всего успешно. Особенно если заранее вместе с вендором подготовить план действий в случае нештатной работы системы.
Итого мы получаем, что на реальную проработку проекта импортозамещения нужно закладывать полтора – два года. И это еще достаточно оптимистичный прогноз. Но, с другой стороны, не все так плохо. Этот процесс можно ускорить, и проект можно будет реализовать за год, с учетом необходимого времени для разработки отечественным производителем целевого функционала.
Во второй части этой статьи я планирую рассказать об основных критериях выбора внешней команды, которая позволит успешно с минимальными затратами для заказчика выполнить проект по импортозамещению целевого иностранного решения.
■ erid:Kra246ccoРекламодатель: ООО «МОНТ»ИНН/ОГРН: 7703313144 / ОГРН 1027739331014Сайт: www.mont.ru
Короткая ссылка
