Методология планирования и реализации проектов импортозамещения ПО и СВТ в органах государственной власти

Автор: Иван Израйлев, начальник управления по работе с предприятиями оборонно-промышленного комплекса «ЛАНИT-Урал».

Нам повезло стать современниками российского проекта перехода на импортонезависимую IT-архитектуру. У специалистов сложился полный спектр мнений по этому поводу, от драматических до восторженных. Определённо ясно одно: процесс неизбежен. В Стратегии развития информационного общества в Российской Федерации на 2017-2030 годы, утвержденной указом президента Российской Федерации от 9 мая 2017 года, указана задача: «Заменить импортное оборудование, программное обеспечение и электронную компонентную базу российскими аналогами, обеспечить технологическую и производственную независимость и информационную безопасность». Эта задача за последние 3,5 года подкреплена внушительным объемом нормативно-правовых актов.

На тактическом уровне созданы и продолжают создаваться ключевые элементы поддержки импортозамещения. Реестр отечественного программного обеспечения уже серьезно изменил и рынок, и подход к построению перспективных информационных систем в организациях, а постановления правительства РФ №719 (от 17.07.2015) и №968 (от 26.09.2016) в ближайшее время произведут такую же революцию в части средств вычислительной техники.

О методическом обеспечении импортозамещения

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

Хочу представить вашему вниманию комплексную методологию проведения проектов по переходу на импортонезависимое ПО и СВТ, которая сформировалась на базе научно-технического задела нескольких проектов по миграции. Методология создана на базе ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», серьёзного, интегрированного с международным, стандарта по управлению жизненным циклом ПО, с адаптацией процессов для управления жизненным циклом СВТ.

Проекты импортозамещения ПО и СВТ рассматриваются в разрезе процессов управления их жизненным циклом и декомпозируются на 12 функциональных блоков для проработки:

• процессов управления жизненным циклом ПО и СВТ, как в рамках проекта по миграции (процессы управления импортозамещением), так и в рамках последующей эксплуатации импортонезависимого ПО и СВТ;
• необходимых технологических компонентов для проведения проекта импортозамещения;
• необходимых ресурсов для проведения проектов импортозамещения и последующей эксплуатации импортонезависимого ПО и СВТ.

Планирование проектов импортозамещения ПО и СВТ

Первый этап – создание «Дорожной карты импортозамещения ПО и СВТ» с целью разработки обоснования и планирования на верхнем уровне. Структура документа может быть такой:

1. Описание текущей ситуации в организации
2. Цели и задачи импортозамещения ПО и СВТ
3. Организация проектных работ
4. Анализ альтернатив импортозамещаемому ПО и СВТ
5. Высокоуровневый план проектов импортозамещения
6. Ожидаемые результаты импортозамещения, критерии успеха и механизмы измерения

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

Следующий этап – создание руководящего документа «Стратегия импортозамещения ПО и СВТ» с детализацией на среднесрочный период. Структура этого документа может выглядеть так:

1. Обоснование, основные цели и задачи (разделы из «Дорожной карты импортозамещения ПО и СВТ»)
2. Детальный план проектов импортозамещения (для каждого проекта):
   • Организация проектных работ в разрезе этапов проектов:
     • Содержание работ
     • Результаты
     • Ресурсы
     • Трудозатраты
     • Длительность
     • Стоимость
   • Детализация задач проекта в нотации Ганта (или другой, принятой в организации)
   • Расчет спецификаций ПО и СВТ и полной стоимости проекта
3. Организация процессов управления жизненным циклом ПО и СВТ в рамках «Стратегии импортозамещения ПО и СВТ» (процессы управления импортозамещением).

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

Во-первых, практика показывает, что в части ПО, особенно общесистемного, почти всегда существует экономический эффект от миграции, и часто – ощутимый. Безусловно, он зависит от текущей ситуации – существуют ли планы по закупкам или обновлению лицензий западных производителей (то есть, собственно, есть ли с чем сравнивать)? В любом случае, лучший результат получается с привлечением специалистов по лицензированию западных производителей ПО и при проведении экономических расчетов на перспективу 3-6 лет. Лучшие экономические результаты получаются при сравнении с трёхлетними программами лицензирования компании Microsoft для государственных организаций. Мы сталкивались с интересным эффектом, когда после анализа экономических показателей организация серьезно перетасовывала портфель проектов под получение максимального быстрого экономического эффекта, выдвигая наиболее выгодные проекты вперед во времени. Здесь нужно быть предельно аккуратными, и не набрать лишних рисков. Правильнее будет спланировать последовательность работы исходя из технологических принципов, чтобы минимизировать затраты на обеспечение совместимости приложений.

Во-вторых, при планировании модернизации техники необходимо обратить пристальное внимание на новое постановление правительства РФ №968 (от 26.09.2016) и ожидаемые изменения в постановление правительства РФ №719 (от 17.07.2015) в части вычислительной техники. Ориентируясь на закон 188-ФЗ (от 29.06.2015) полагаем, что в ближайшее время для органов государственной власти будут актуальны следующие критерии при закупках СВТ:

1. У производителя СВТ должны быть права на конструкторскую документацию в объёме, достаточном для производства и модернизации соответствующей вычислительной техники (делать можно где угодно, но в случае чего чтобы была возможность производить на территории РФ);
2. У производителя СВТ должны быть права на исходные коды встроенного микропрограммного обеспечения производимой вычислительной техники (речь прежде всего о базовой системе ввода-вывода, BIOS);
3. Сертификация встроенного микропрограммного обеспечения производимой вычислительной техники на отсутствие недекларированных возможностей;
4. Осуществление на территории РФ ряда операций по монтажу, сборке, тестированию и др.

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

Реализация проектов импортозамещения ПО и СВТ

Переходим к организации проектных работ. Рассмотрим 12 функциональных блоков – процессов управления жизненным циклом ПО и СВТ:

1. Обеспечивающая инфраструктура

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

Инфраструктура, необходимая самому проекту – это мощности для резервного копирования данных пользователей с АРМ: объём может быть невероятным (и его нужно спрогнозировать). Соответственно, на время проекта может появиться отдельная (мощная) система хранения (много площадок? слабые каналы? тогда несколько таких систем) и ПО, которое умеет централизованно копировать данные (по шаблону, из разных мест) напрямую со всех АРМ, и потом восстанавливать их в соответствии со стандартами организации (обычно часть данных в рамках проекта переносится на сервера) уже на новую ОС. Нужны ресурсы для документов, для взаимодействия и т.п.: каналы, мощности, объёмы. Группа обеспечения должна не подставить остальных коллег, и заранее спланировать, настроить и предоставить необходимые проекту сервисы.

Вторая часть, как правило, связана с изменениями в текущей инфраструктуре. Например, мы переносим АРМ пользователей (далее я буду иллюстрировать именно на этом, наиболее сложном примере), но сервера пока не трогаем. Возникает вопрос: «В какой домен войдут мигрировавшие АРМ на отечественных ОС?» Если мы решили эту проблему, то далее нужно внедрить технологию совместимости прав пользователей на файловых серверах, на принт-серверах и т.п. В целом, группа отвечает за обеспечение инфраструктурой тех изменений, которые мы проводим.

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

2. Управление стандартными образами АРМ

На этом этапе производятся выбор, обоснование и разработка стандартов на:

• Операционную систему
• Базовое общесистемное ПО
• Стандартное (для всей вычислительной техники) прикладное ПО

Для серверов (при большом их количестве) эти работы также имеют смысл, но наиболее критичная часть – это, конечно, АРМ пользователей. Стандарты задаются для всех АРМ, с целью создания так называемого «стандартного образа». Дело в том, что за некоей границей, условно – 100-200 АРМ, оббежать их по порядку физически невозможно, надо автоматизировать операцию миграции АРМ (мы ведь полностью переустанавливаем ОС и все существующее ПО – немыслимый объём работ). Для этого необходимо создать «стандартный образ» АРМ, и это актуально как в случае с новой техникой, а особенно – если техника у пользователя остается старая.

Особое внимание необходимо уделить внедрению механизмов создания и сопровождения «стандартных образов» АРМ. Задайтесь вопросом – сколько именно в рамках даже простого проекта вам придется сгенерировать разных образов? Драйвер добавить – новый образ, изменить любую настройку – новый образ, устранение ошибок на этапе тестирования – 100 новых образов. Нужно построить машину для быстрой генерации образов, обеспечить тщательный учет состава образа до мелочей, контроль изменений и организацию работ команды вокруг этого, а также средства доставки до АРМ (сколько у вас площадок? в скольких муниципальных образованиях? с какими каналами?).

В результате должен появится «стандартный образ» АРМ со стандартным набором ПО для всех пользователей. Идеально, если он получится один, обычно выходит 2-1 (конечно, всегда останутся уникальные пользователи, но их число нужно минимизировать). Также должны появиться средства сопровождения изменений в образах АРМ.

3. Управление прикладными системами

Несмотря на стандартизацию образов АРМ, не всё ПО стоит у всех. Изрядное (на практике до 70%) количество программ стоит только у определенных людей или групп (например, платное ПО ограниченного количества), поэтому приличный объём прикладного ПО нельзя включать в базовый образ. Значит, нужно организовать анализ прикладных систем, не входящих в состав «стандартного образа» АРМ.

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

Обратите внимание – это один из самых трудоёмких этапов работ. Во-первых, у организации в 500 АРМ вполне может быть 60-80 разновидностей различного ПО, и каждый раз после инвентаризации ПО (отдельная серьёзная задача) количество различного ПО на местах удивляет IT-специалистов. Каждую систему нужно подготовить для удалённого развертывания (мы помним, что ногами миграция не делается) – могут быть несколько различных технологий, да и просто объем работ немаленький (60-80 программ, каждая в среднем 1-3 дня работы специалиста).

Отдельный элемент – средства доставки ПО до АРМ. Это сердце всего проекта, а впоследствии – сердце процесса управления изменениями АРМ. И это, конечно, не просто удалённая «скриптозапускалка», а технология, которая позволяет, прежде всего, детально описать процедуру миграции АРМ: например, вначале скопировать данные пользователя, перезагрузить, разбить диск, скачать и развернуть базовый образ, перезагрузить, уточнить перечень дополнительных систем, которые конкретно этому пользователю нужны, в нужном порядке с соблюдением зависимостей установить их, а также установить необходимые библиотеки для их работы. Создать технологию так, чтобы она работала на любом железе идеально – филигранная работа, а значит, средства доставки ПО должны быть продвинутыми и обладать серьёзными возможностями для обратной связи (будет много отладки).

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

4. Совместимость прикладных систем

Наконец то мы добрались до момента, когда открыто признаем – приличная доля вашего ПО, работающая на Microsoft, под Linux не заработает. Более того, при всех сверхусилиях, в переходный период (3-5 лет) ПО для платформ Microsoft будет в каждой организации.

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

Группа совместимости критически зависит от группы тестирования и, безусловно, занимается наиболее творческой работой. Для приложений, которые сами на Linux не запускаются, необходимо сделать выбор, обоснование и реализацию механизмов работы таких прикладных систем – эмуляция, виртуализация различных типов (локальная, удаленная, контейнерная), терминальный доступ, или как вариант для группы приложений – инфраструктура удаленных виртуальных АРМ (возможно, с доставкой ярлыков на рабочий стол Linux) и т.п. К сожалению, общего подхода (кроме VDI) нет. Для разных приложений имеет смысл применять свою технологию – что-то можно эмулировать бесплатно, что-то только платно, что-то работает в терминале, а что-то нет.

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

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

5. Миграция данных и настроек пользователей

Это крайне специфические работы, поэтому они вынесены в отдельный этап.

Первая часть работы – анализ неструктурированных пользовательских данных (файлов, хранимых локально и на серверах), оптимизация структуры и типов данных, разработка стандартов по управлению пользовательскими данными, ограничениями и местами расположения данных. Стоит отметить, что работа по анализу сложна организационно. Во-первых, нужно разработать критерии, например, найти очень большие файлы на АРМ, вроде фильмов, отследить хранение данных в нестандартных местах, выявить нетипичные форматы, странную структуру и т.п.: десятки сценариев, чтобы сделать аналитическую работу качественно за ограниченное время. Во-вторых, сложность в том, что решение по удалению данных или изменению места/структуры их хранения может принять только пользователь или его руководитель. Нужно делать механизм согласования, чтобы пользователь зашёл, проставил «галки» (нужно/не нужно, согласен с изменениями/не согласен), и будьте готовы к разбирательствам. На эту работу рекомендуются предельно уравновешенные специалисты, желательно понимающие специфику работы разных отделов в организации.

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

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

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

6. Информационная безопасность

Это типовой этап работ, требующий, однако, высокого профессионализма.

Проводится анализ требований к автоматизированным системам, разработка и/или оптимизация систем защиты информации, нормативной документации, обеспечение соответствия автоматизированных систем требованиям приказов ФСТЭК России №17, №21 и других.

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

С другой стороны, некоторые уже аттестованные АС просто физически невозможно мигрировать в рамках проекта (по крайней мере быстро), поэтому нужна плотная совместная работа с группой совместимости, чтобы принять решения, что с ними делать и как они будут вписаны в новый IT-ландшафт организации.

Обратите внимание: некоторые отечественные операционные системы имеют сертификаты ФСТЭК России на встроенные средства защиты информации и отсутствие недекларированных возможностей, как правило, с лихвой перекрывающие все требования к АС в органах государственной власти. Обычно у отечественных операционных систем блестящая экономика по сравнению с наложенными средствами защиты для Windows, которые нужно приобретать отдельно.

В результате должна быть обеспечена информационная безопасность, АС подготовлены к аттестации на ГИС, ИСПДН, и т.д. Использован момент тотальной перестройки инфраструктуры для системной актуализации подходов к построению АСЗИ в организации.

7. Организация работ по миграции

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

Это не значит, что группа приступает к работе в конце проекта, наоборот, она интегрирует коммуникации между группами. Например, именно здесь может возникнуть понимание того, что на разработанный стандартный образ АРМ никогда и никак не «заедет» технология на базе Wine, потому что специфика графической оболочки не позволяет нормально делать copy-paste в эмулированных приложениях, и нечего группе совместимости эту технологию брать в расчёт. На этом этапе работают архитекторы всего проекта – они должны думать обо всех применяемых технологиях.

Более того (забегу немного вперед), в конце, когда отработали все группы, а группа миграции оттестировала все компоненты, в общем-то не остается ничего сложного. Если в начале проекта аккуратно на 1-2 машины лояльных к IT пользователей (в идеале – хорошо бы им быть в отпуске), с непременным присутствием технических специалистов на местах запускается миграция. Что-то не выходит – откатываются, исправляют, запускают опять пока с грехом пополам не «заведётся» в ручном режиме. В середине уже чуть увереннее мигрируют отделы по 20-30 машин, с небольшими сбоями на 2-5 машинах, устраняемыми удаленно и быстро. В конце проекта – основной сезон работы группы миграции. Товарищи спокойно сидят на месте, мигрируя по 100 АРМ в день, все полностью автоматически с 1-2 незначительными ошибками на 100 машин, а скорость миграции ограничена только пропускной способностью сети – коммутаторы дымятся. Этап массовой миграции в проектах импортозамещения, как это ни удивительно, скоротечен и очень приятен. Такова награда за предшествующий титанический труд.

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

8. Офисные прикладные системы

Миграция Microsoft Office на любую другую офисную систему – чудовищная головная боль. Более того, проблема офисных систем в том, что это давно уже не совсем прикладное ПО, оно больше похоже на общесистемное и проникает всюду. Например, мало мигрировать офис, нужно еще в 40 программах мигрировать экспорт отчетов, часто отладить печать, ещё чаще – интеграционный обмен (вот и аукнулись все эти «простые» прошлые решения). В органах государственной власти работа с документами — это основной бизнес-процесс. Поэтому необходимо создать отдельную группу для этой крайне рискованной части работ, а также для руководства и контроля всех функциональных групп проекта в части офисных систем.

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

По поводу перехода на формат ODF – это более чем возможно, и существует хорошая практика. Уже давно есть непротиворечивое нормативно-правовое обоснование такого перехода – ГОСТ Р ИСО/МЭК 26300-2010, и на него всё чаще и чаще ссылаются свежие акты, например, постановление Правительства РФ № 325 (от 23.03.2017).

На практике примерно 70% всех офисных файлов можно с качеством 99% перевести в свободный формат автоматически. Примерно 10% офисных файлов – невозможно перевести никогда, таковы, например, документы со скриптами, или огромные файлы экономистов (а это иногда десяток файлов, связанных между собой ссылками), когда это уже не офисный файл, а целое «приложение», которое лучше пока не трогать. Для них, а также на случай, когда прислали что-то сложное извне, нужно делать отдельные «АРМ совместимости» с лицензионным Microsoft Office. Их обычно виртуализируют и обеспечивают удобную доставку для потребителей. Оставшиеся 20% файлов перевести можно, но с доработкой руками. Большой и тяжелый труд, тем не менее, при автоматизации и упорстве это возможно сделать за разумные сроки.

Результат – максимальный процент АРМ переведён на импортонезависимое офисное ПО. Документы переведены в открытый формат, внедрён стандарт организации по форматам документов. Обеспечена существенная часть экономического эффекта от импортозамещения.

9. Тестовая лаборатория

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

Практика показывает, что на базе почти любого крупного органа государственной власти смело можно открывать музей компьютерной техники. Вы найдете весь ассортимент процессоров, как минимум, Intel и AMD, разнообразие чипсетов, сетевых карт, видеокарт, а также принтеров, сканеров, МФУ, экзотических ноутбуков, моноблоков и так далее, часто – на очень глубокую историческую перспективу. Эти обстоятельства важны даже при миграции на новые версии Windows, что уж говорить об отечественных операционных системах. На всё это еще наложим кучу приложений, которые печатают, сканируют, соединяются, работают совместно, а также вспомним, что группа совместимости подходит к делу творчески и запускает все это на Linux весьма нетривиальными способами.

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

Принцип простой – проводится инвентаризация техники, делается репрезентативная выборка данных инвентаризации для реализации полноценной тестовой инфраструктуры, приближенной к инфраструктуре организации. Затем, грубо говоря, в чулане устанавливается некоторое количество (например, с десяток) различных АРМ на разных чипсетах, процессорах и т.п., и рядом – полнофункциональный единый операционный механизм от группы миграции. Далее любые изменения – новая версия образа, настройки приложений, средств доставки и т.п. разворачивается на этих АРМ, а потом устраняются сбои и происходит отладка результатов работы для всех групп.

Замечу, что никакие виртуальные машины не заменят полноценных тестов на реальном «железе». Более того, даже тестовая лаборатория не отражает реальные «полевые» условия, потому что машины в организации, как правило, представляют из себя плод неуправляемых многолетних изменений, и то, что стоит на столах у пользователей, невозможно воссоздать в лаборатории. Поэтому, как мы обсуждали ранее, даже при идеальной 100% отработке в тестовой лаборатории операционный механизм все равно нужно в начале миграции применять аккуратно на 1-2 машинах лояльных к IT пользователей.

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

Результат должен быть таков – разработана и внедрена Программа и методика испытаний на всех фазах жизненного цикла ПО и СВТ.

10. Взаимодействие с пользователями

Как вы понимаете, предстоит большой объём коммуникаций с пользователями, и это лучше сразу специально организовать. Например, «простой» кусочек работ – при массовой миграции (помним, что мы замахнулись аж на 100 машин в день) созвонится с каждым пользователем и убедиться, что ему действительно удобно сегодня с 14.00 до 16.30 в рамках приказа по организации освободить свой персональный ПК, не трогать его в процессе миграции, а при необходимости звонить в службу поддержки по выделенному номеру телефона. Вспомним, что с пользователями нужно согласовывать миграцию данных (непременно сопровождающуюся удалением ненужных на взгляд ИТ-службы файлов и серьёзными изменениями структуры и мест расположения данных). В общем – коммуникаций очень много и не по разу. Ну и, конечно, пользователи сами будут вам звонить.

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

От себя скажу, что на практике миграция на импортонезависимое ПО – достаточно нервозный процесс, даже если проектные группы не допускают просчётов и сбоев. Это глобальное, существенное изменение в огромном куске жизни большого количества людей. Среднестатистический сотрудник органа государственной власти проводит со своим персональным АРМ более половины бремени бодрствования. Гораздо больше, чем, например, со своими супругами и детьми. И теперь вы серьезно меняете внешний вид и поведение этого спутника жизни сотрудника. Представьте, насколько это может быть важно для людей. Если вам повезёт действительно качественно (и душевно) организовать работу с пользователями, вы устраните самый главный, самый ключевой риск импортозамещения. Группа поддержки должна уметь эффективно смягчать те изменения, которые несет этот проект.

Результат – пользователи не отторгают систему. У команды проекта и руководства организации минимизирован расход нервного ресурса.

11. Управление проектом

Центральный элемент методологии – управление проектом – является классическим. Просто проекты эти очень сложные.

12. Перевод в эксплуатацию

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

Посмотрите ещё раз на все потоки работ вместе (Рис. 1) Кроме собственно того, что мы импортозаместим – что у нас еще остаётся? А остаётся у нас тонна накопленных знаний, высококлассный технический инструментарий и отличная, организованная команда людей, которая умеет в ИТ-инфраструктуре своей организации устанавливать совершенно любое ПО (включая перспективное) на совершенно любые СВТ по щелчку пальцев. Точнее, конечно, не по щелчку, вначале принимается решение включить ПО в «стандартный образ» или в репозиторий, затем осуществить сборку, провести анализ совместимости (со всеми системами!), обновить механизм централизованного управления данными и настройками, отработать политики ИБ, провести эффективное автоматизированное тестирование, отладку в «идеал», внести изменения в ОРД и т.д. и т.п., всё ,что мы обсуждали выше. Многие вещи – с невиданным ранее качеством и скоростью.

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

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

И, конечно, достижение нашей стратегической цели, её возможно сформулировать так: «Эффективное выполнение текущих и перспективных нормативно-правовых актов в области импортозамещения ПО и СВТ в соответствии со стратегией развития информационного общества в Российской Федерации на 2017-2030 годы».

Заключение

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

Мне кажется, что мы с вами являемся свидетелями именно такого значимого – ИТ Проекта. Дай Бог нам всем удачи на этом пути!