Импортозамещение: цель или средство?

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

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

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

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

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

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

Краткосрочная перспектива

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

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

Разрешить это противоречие путем привлечения дополнительных ресурсов, повышения квалификации специалистов или распараллеливания работ невозможно. Так же, как и невозможно полностью отказаться от заимствования исходного кода извне, поскольку российская часть сообщества Open Source мала и вряд ли сможет обеспечить исправление ошибок или выполнение даже мелких доработок на уровне ядра. И главное — кто за это будет нести ответственность, что особенно важно в случае специальных применений. Кроме того, возникает ряд дополнительных вопросов. Можно ли говорить об устранении технологической зависимости, если разработка программного продукта кардинально зависит от зарубежного сообщества программистов? Каковы гарантии того, что это сообщество является и будет оставаться независимым? Каковы гарантии того, что это сообщество вообще продолжит существовать в среднесрочной и долгосрочной перспективе? Все эти вопросы особенно актуальны в контексте создания отечественной ОС.

Для определения «отечественности» программного обеспечения эксперты ассоциации «Руссофт» предложили достаточно простой набор требований, которым должен удовлетворять российский производитель или правообладатель ПО (www.russoft.ru/letter.pdf, Приложение 3): это российские юридические лица, в которых не менее чем 51% доли в уставном капитале или акций принадлежит прямо или косвенно российским физическим или юридическим лицам. Однако неясно, каким образом отечественные разработчики должны гарантировать поддержку и развитие своих продуктов в среднесрочной и долгосрочной перспективе, а при отсутствии таких гарантий возможно появление фирм-однодневок.

Среднесрочная и долгосрочная перспектива

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

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

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

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

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

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

Рис. 1. Циклический процесс импортозамещения

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

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

Рис. 2. Субъекты процесса импортозамещения

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

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

Следует заметить, что по причине своей немногочисленности внутренние потребители ПО, например СУБД [2, 3], не всегда способны обеспечить эксплуатацию систем в различных режимах работы, что скажется на степени их отлаженности, а значит, и на качестве. Даже если крупные внутренние потребители (Сбербанк, госкорпорации, федеральные ведомства и т. п.) перейдут на отечественное ПО, то все равно системы не пройдут промышленного тестирования во всем возможном спектре задач.

Продвижение

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

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

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

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

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

***

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

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

Литература

1. Андрей Тюлин, Игорь Жуков, Дмитрий Ефанов. На страже конфиденциальной информации // Открытые системы.СУБД. — 2001. — № 10. — С. 20–25. URL: http://www.osp.ru/os/2001/10/180520 (дата обращения: 15.03.2015).
2. Виталий Максимов и др. Защищенная реляционная СУБД «Линтер» // Открытые системы.СУБД. — 1999. — №11–12. — С. 69–79. URL: http://www.osp.ru/os/1999/11-12/177904 (дата обращения: 15.03.2015).
3. Сергей Муравьев, Сергей Дворянкин, Игорь Насенков. СУБД: проблема выбора // Открытые системы.СУБД. — 2015. — № 1. — С. 22-24. URL: http://www.osp.ru/os/2015/01/13045322 (дата обращения: 20.03.2015).

Константин Селезнев (skostik@relex.ru) — ведущий инженер-программист, Виталий Максимов (vitamax@relex.ru) — заместитель генерального директора группы компаний «РЕЛЭКС» (Воронеж).