Импортозамещение - ничего нет хуже «кусочной» инфраструктуры

Автор: Сергей Курьянов, директор по стратегическому маркетингу «ДоксВижн».

Уже больше 5 лет слово «импортозамещение» не покидает новости и аналитику компьютерных изданий и каналов. Однако реальность 2022 года выдвинула эту тему на первый план и в текущих задачах многих ИТ-директоров и архитекторов.

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

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

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

3) Юридические риски – возможные судебные иски за нелицензированное использование западного ПО. Это является преступлением не только по законам стран юрисдикций западных вендоров, но и по законам РФ. И санкции там предусмотрены серьёзные, кратные стоимости ПО.

На последнем пункте остановимся подробнее. 28 декабря 2022 года министр цифрового развития, связи и массовых коммуникаций Российской Федерации Максут Игоревич Шадаев объявил, что в России будет принято постановление о «принудительном лицензировании» ПО, вендоры которого ушли из России и отказали нашим предприятиям в продлении лицензий и технической поддержке. Постановление в момент написания этой статьи ещё не вышло, но на словах министр сказал, что один из возможных вариантов – принудительное лицензирование, по которому предприятия, продолжающие использовать это ПО, освобождаются от преследования за «пиратство», обязавшись платить на специальные счета «некоторую долю» от лицензионных платежей. Из этих средств, в частности, будет возможна компенсация западным вендорам при их возвращении в Россию.

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

Другим форматом финансовой поддержки является создание Индустриальных Центров Компетенции (ИЦК), призванных обобщить потребности в рамках отрасли, прежде всего в индустриальном ПО (CAD/CAM/PLM и подобное), и выбрать перспективных отечественных вендоров для создания замены западных продуктов. При этом вендор получит до 80% компенсации затрат на разработку, оставшуюся часть затрат вкладывает сам заказчик. Этот формат будет применяться для тех систем, у которых нет хороших отечественных аналогов, а рынок одной отрасли в одной стране недостаточен для того, чтобы вендор мог финансировать разработку своими средствами.

В любом случае, любой из перечисленный форматов господдержки достаточно сильно повлияет на рынок, и нам стоит ожидать в 2023 году начала волны слияний и поглощений на рынке ПО. Крупные заказчики будут покупать перспективных разработчиков для создания собственного отраслевого индустриального ПО на государственные деньги, а крупные интеграторы – перспективных разработчиков горизонтальный прикладных систем уровня CRM, ECM, BPM и ERP.

Автору ближе рынок прикладных горизонтальных систем, дальше мы будем рассматривать импортозамещение этого класса ПО на примере ECM/BPM платформ.

Импортозамещение прикладной системы – структура и границы проекта

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

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

К инфраструктуре для прикладного ПО, в первую очередь, относятся операционная система (ОС) и система управления базой данных (СУБД). ОС надо рассматривать и серверную, и десктоп, хотя наличие полнофункционального веб-клиента у Системы позволяет сосредоточиться на детальном рассмотрении альтернативных серверных ОС. От ОС неотделимо множество служебных систем, которые тут названы «обвязкой». Это средства информационной безопасности, виртуализации, резервного копирования, служба каталогов, система мониторинга и десятки других компонент. В отечественных ОС обычно обвязка является слабым местом, поскольку они применялись для базирования специализированных систем или сервисов (почтовых систем, гейтов, специализированных прикладных систем узкого применения). Сейчас вендоры ОС прикладывают огромные усилия для ликвидации этой лакуны, но рассчитывать на то, что они создадут комплекс обвязки, подобный ушедшему Windows, пока нельзя. Поэтому, на наш взгляд, одним из главных критериев выбора ОС является срок её присутствия на рынке, инсталляционная база и отраслевой профиль заказчиков.

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

В результате в приоритет Минцифры включены три системы Astra Linux разработки (ГК «Астра»), ОС «Альт» (ALT Linux от «Базальт СПО») и «Ред ОС» (разработки «Ред Софт»). Все эти системы базируются на Linux, но сильно отличаются по программной платформе (Framework) и обвязке, поэтому портирование системы на другую ОС Linux будет непросто, небыстро и недёшево. Это надо учитывать, чтобы по возможности не отрезать себе оптимальный выбор Системы, сделав выбор ОС без детального анализа.

Что касается СУБД, то к наиболее популярным можно отнести:

  • На базе Open Source PostgreSQL:
    • PostgresPro;
    • Лира-Р.
  • ClickHouse разработки Яндекс.
  • Tarantool разработки VK Group.
  • СУБД ЛИНТЕР - разработки научно-производственного предприятия «Реляционные экспертные системы» (РЕЛЭКС).

Наиболее популярной на рынке крупных предприятий на сегодня является PostgresPro.

Выбирая инфраструктуру под корпоративные системы управления, надо учитывать их приоритетность для вас. Например, если ERP требует под себя «Astra Linux», а CRM «Альт», но для вас в приоритете именно ERP, потому что вы либо не видите ей альтернатив, либо она уже внедрена у вас, и мигрировать на альтернативную систему слишком дорого, выбирайте в инфраструктуре Astra Linux и ищите альтернативную ERP под Альт Linux.

Ни в коем случае не надо плодить зоопарк из инфраструктурных ОС. Именно поэтому мы считаем, что импортозамещение прикладной системы вторично по отношению к инфраструктуре.

Облако или In-House? Ответ для крупных предприятий на сегодня однозначный – частное облако в вашем дата-центре. Возможно, потребуется интеграция с функциональными расширениями в публичных облаках. Например, для проверки контрагента по реестрам.

Немаловажно учитывать «окружение» прикладной системы. Для ECM/BPM – это электронная почта, мессенджеры и офисный пакет. Нужно, чтобы окружение также было импортозамещающим, удовлетворяло требованиям пользователей других управленческих систем и было совместимо с ними технически.

Как планировать проект?

Ну вот, наконец, с инфраструктурой вы определились. Как планировать проект миграции Системы?

Главное - нельзя допустить «кусочную» архитектуру управления контентом и бизнес-процессами, повторяя исторически сложившуюся. За то время, пока вы работали на сложившейся архитектуре, управление документами давно вышло «за пределы канцелярии» и стало единым комплексом с управлением бизнес-процессами. Теперь это называется Content Services Platform (CSP).

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

Рассмотрим пример – договоры и связанные с ними документы.

«Кусочная» архитектура подразумевает, что сами договоры как документы формируются в CRM, согласовываются и утверждаются в СЭД, их исполнение контролируется в департаментах закупок, продаж и сервисов, скорее всего, в той же СЭД, а вот транзакционные документы, доходы и затраты по договору формируются и хранятся в ERP.

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

У меня получилось 3, умноженное на количество бизнес-процессов, использующих этот контент.

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

Именно поэтому нужна единая корпоративная СЭД/ECM/BPM (CSP) платформа, обеспечивающая единство среды хранения контента, архивов и движок управления бизнес-процессами.

Большинство современных систем управления поддерживают внешнее хранение документов и доступ к ним по ссылкам из системы, с которой привык работать конкретный пользователь. Например, бухгалтер достаёт эти документы по клику в ERP, а менеджер по клику в CSP, но работают они, на самом деле, с одним документом в рамках общего для них бизнес-процесса. В ERP-системе, по существу, объектом является не документ, а хозяйственная операция, поэтому доставать документ по ссылке из операции очень естественно и удобно. При изменении документа ссылка укажет именно на его актуальную версию. Появление изменений и дополнений к документу можно автоматически подсвечивать в интерфейсе ERP, а проведение новой операции – в CSP. Для этого выбираемая вами Система должна обладать необходимыми готовыми шлюзами и развитым документированным API. Именно так организовано взаимодействие 1С:Предприятия и Docsvision во многих внедрениях.

Теперь к вопросу об изменениях системы в процессе эксплуатации. Современная корпоративная СЭД/ECM/BPM (CSP) платформа должна содержать платформу Low Code, позволяющую вносить изменения в модели документов и процессов практически без программирования.

Согласно определению, Low-Сode-платформа позволяет создавать приложения с небольшим количеством кода. То есть большинство функций приложения (80%) реализуются из готовых компонентов путём конструирования с помощью визуальных инструментов разработки, и только в небольшом количестве случаев (20%) возникает необходимость программирования для решения нетиповых задач. Да и сам процесс программирования сводится к написанию некоторого количества скриптов и нестандартной обработки событий, что не требует такой высокой компетенции, как при создании приложений с нуля.

В результате удаётся существенно сократить издержки на внедрение новых автоматизированных процессов – приложения на Low-Сode-платформе создавать проще и дешевле, а также снизить зависимость от разработчиков приложений – решения, созданные с помощью технологий Low-Сode, могут сопровождать и даже развивать внутренние сотрудники организации, и для этого не нужна глубокая компетенция в области разработки кода. При использовании Low Code внесение изменений радикально ускорится, и система будет синхронизирована с появлением новых требований, без необходимости держать команду квалифицированных программистов «на всякий случай». В частности, Low-Code российской CSP платформы Docsvision признана лучшим в рамках премии «Приоритет» в 2021 г.

Резюме

Несколько советов, которые стоит сохранить в памяти по итогам.

  1. Выбор ИТ-инфраструктуры первичен по отношению к выбору прикладных систем.
  2. Выбирая ИТ-инфраструктуру, ни в коем случае нельзя плодить «колхоз», когда одна прикладная система будет работать на одной ОС или СУБД, а другая – на другой.
  3. При выборе ОС надо смотреть на время её пребывания на рынке (опыт), количество инсталляций и отраслевой профиль заказчиков. А также на развитость «обвязки».
  4. При импортозамещении прикладных систем, работающих с документами и бизнес-процессами, ни в коем случае нельзя повторять сложившуюся «кусочную» систему хранения документах в разных системах – нужно использовать корпоративную ECM/BPM платформу.
  5. Платформа должна содержать набор инструментов Low-Code для быстрой разработки и модификации бизнес-процессов и моделей документов.


Реклама ООО «ДоксВижн»

9500

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

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