Как изменился подход государства и бизнеса к переходу на российские ИТ-продукты. Подкаст TAdviser

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

Мы опросили порядка 700 участников, в том числе представителей ИТ-компаний: системных интеграторов, разработчиков ПО, реселлеров, интернет-магазинов, провайдеров облачных услуг. Также опросили представителей государственных организаций – полностью бюджетных и с госучастием. Бюджетных учреждений было большинство – порядка 90%. Кроме того, опросили представителей малого и среднего бизнеса. Елена Истомина, Directum: Как no-code меняет стоимость проекта 6.1 т

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

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

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

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

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

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

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

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

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

А с точки зрения сложностей, есть ещё глобальная сложность: раньше хоть импортозамещение и было, но не в столь активной фазе. У всех уже была своя сложившаяся история. Например, если говорить про прикладной софт и офисные пакеты, там, конечно, доминировал Microsoft, и все к нему привыкли: т.е. всё хорошо, мы можем смотреть в импортозамещение, но сейчас всё работает. Психологическая сложность в том, что теперь приходится реально выбирать, тратить силы и искать какие-то решения из уже сложившихся. Это, конечно, непросто.

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

Есть, например, Microsoft, у которого есть ОС Windows, установленная на 70% компьютеров, серверов. И если я разработчик прикладного или промежуточного софта, то, естественно, я буду ориентироваться на лидеров рынка, на тех, кто занимает бо́льшую его часть. Значит, я войду в их экосистему и гарантированно буду иметь успех. То же самое происходит во всех сферах, не только в ИТ.

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

Если брать мировой опыт – IBM, например, если пересчитывать количество продуктов в его портфеле, то это бесчисленное количество – сотни продуктов. И если быть объективным, IBM сам ничего не разрабатывал: он это всё скупал – патенты, вендоров и т.д. Кто сталкивался с крупными проектами, в том числе на IBM, прекрасно понимают, что два продукта IBM не всегда между собой совместимы. Это разные продукты, им просто маркетинговым образом переделали «шапку». Поэтому зачастую уже в рамках проекта обеспечивается эта совместимость.

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

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

Петр Василенко: Конечно. Более того, всё это было продиктовано именно запросами пользователей. Они транслировали, что необходима совместимость с таким-то пакетом, с форматами файлов и т.д. Запрос шёл непосредственно от них.

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

По поводу функционала тоже важный момент. Но все, кто глубоко погружался в те или иные системы инфраструктурного, прикладного или инструментального слоя, прекрасно понимают, что утилизация (в классификации Microsoft – consumptions) софта, т.е. насколько полноценно пользователь применяет заложенный в ПО функционал, – это большая проблема даже для самых крутых лидеров рынка. Потому что все знают на примере Excel, где гигантское количество функций, из него можно сделать ERP, BI – всё, что угодно, но этим пользуется 0,5% специалистов, которые работают в Excel. Вопрос функционала зачастую очень раздутый, и 80% функций используют меньше 5% пользователей или, наоборот, 5% функций используют 95% пользователей.

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

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

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

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

И мы подходим под тот критерий российских вендоров, которых ты в начале упоминал, потому что мы с 2006 года развиваем «Автограф». Он был нишевым отраслевым решением для САПР, довольно специфическим и узкоспециализированным. А с 2018 года мы его стали функционально развивать именно для замены Visio. То, что сейчас наш продукт успешно внедряется, что пользователи не кладут его на полку, а начинают в нём активно работать, достигнуто только за счёт того, что мы с 2018 года не «из головы» дорабатывали продукт. Мы вместе с пользователями его пилотировали, собирали обратную связь, дополняли функционал тем, чем необходимо, что-то меняли в интерфейсе.

Благодаря этому сейчас продукт работает, несмотря на то, что у нас есть не всё, что есть в Visio. И мы честно об этом заявляем. У нас есть порядка 85%, которые позволяют решать практически все те же самые задачи, что и Visio. До конца года мы планируем закрыть 100%.

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

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

Петр Василенко: Это действительно очень важный вопрос, который нам многие задают. Для того, чтобы на него полноценно ответить, необходимо копнуть чуть глубже. Как я сказал, мы развиваем продукт с 2006 года, когда этого open source ещё не было. Продукт «Автограф» разработан нами с нуля. Но в момент, когда потребовалось реализовать совместимость с российскими ОС, наш технологический стек не позволил это сделать. Поэтому пришлось искать какие-то пути, решения, и в качестве промежуточного решения мы взяли open source. Хотелось сделать быстро и выдать завтра, но в итоге всё равно у нас ушло на это много времени. Мы серьёзно относимся к ИБ, и наши пользователи зачастую используют его в КИИ, поэтому нам потребовалось 1,5 года, чтобы привести продукт в порядок, вычистить все «дыры» и уязвимости под капотом. Это, во-первых.

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

Если говорить о том, что есть сейчас, мы реализовали большую работу с точки зрения совместимости, по пожеланиям пользователей добавили импорт чертежей САПР – тот же формат dwg AutoCAD. И ещё провели большую работу по русификации, справке, функции по орфографии. У нас есть большой список, мы его предоставляем для ознакомления тем, кому интересно.

Сергей Игнатов: Я бы дополнил Петра по этому вопросу. Те, кто в курсе, кто погружен в историю с современной разработкой, прекрасно понимают, что в основе практически любого создаваемого продукта лежит тот или иной кусок open source. Сейчас разработка – это, скорее, пазл Lego, нежели низкоуровневое программирование времён ассемблера. Поэтому куски кода или готовые модули могут встретиться в любом продукте, будь то Microsoft или IBM. Red Hat, в конце концов. Red Hat – это вообще компания, которая построила свой бизнес на приведении в соответствие open source кода для своих продуктов, по большому счёту.

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

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

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

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

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

Петр Василенко: Тут важно оговориться, что я имел в виду движок. Это база нашего ПО, на которой оно будет работать. Она будет полностью своя. А связано это с тем, что open source решения и этот код зачастую не сильно изменяем. Чтобы развивать ПО, ты должен управлять тем, что у тебя внутри, и когда у тебя внутри «кирпич», который невозможно изменить, с этой проблемой мы сталкиваемся зачастую в open source. Мы хотим чётко прогнозировать развитие своего продукта, иметь возможность добавлять туда все необходимые программные модули, делать все интеграции и не зависеть от внутренней структуры и архитектуры. При этом, конечно, в разработке продукта мы, как и все, используем различные библиотеки. Но ядро должно быть своим.

Сергей Игнатов: Если, например, брать ОС, то, понятно, что все они сделаны на Linux. А если прикладной софт, то, я бы сказал, 50/50, потому что есть компании, которые не заморачиваются и изначально берут готовую основу, но с минимальным функционалом, фиксируют её и дальше делают отдельное направление в разработке продукта. А кто-то, как компания ИМСАТ, уже давным-давно существует на рынке и куёт свой продукт с нуля, постепенно, вдумчиво отрезая всё лишнее и оставляя нужное. Таких компаний тоже предостаточно, я считаю. Хотя, ни тот, ни другой способ не является правильным или неправильным.

Петр Василенко: Тут важно упомянуть, что есть успешные кейсы в обоих случаях. И если подводить точку в использовании open source, важно, какой получился конечный продукт. Если компания взяла open source решение и выдала его в таком же виде, то какой смысл его внедрять? А если это действительно серьёзная переработка, функционально она сильно отличается и большие планы по развитию продукта, то совсем другое дело. Мне кажется, рынок хорошо разбирается в этих тонкостях.

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

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

Петр Василенко: Я, например, не могу вспомнить кейсы, когда у какой-нибудь инсорсинговой компании получилось бы самостоятельно сделать серьёзный пакет общераспространённого прикладного софта вроде офиса или чего-то аналогичного. Зато я слышал много примеров, когда инсорс-команды создавали крутые продукты для внутренних пользователей, связанные с технологической базой. Если компания занимается производством, у неё есть специфические процессы, которым нужна автоматизированная система, которая отвечает именно их требованиям, тут, наверное, без инсорсинга не обойтись.

Сергей Игнатов: Когда общаешься с партнёрами и заказчиками в неформальной обстановке, зачастую обсуждаешь какой-то громкий кейс, когда, например, «Делимобиль», т.е. коммерческий заказчик, переходил на «МойОфис», или когда целый банк перевели на отечественные прикладные и инфраструктурные решения, сразу начинаются рассуждения. Понятное дело, пришли люди «сверху», сказали, закупили и перешли – они никуда не денутся. Это необъективный процесс, нерыночный механизм.

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

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

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

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

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

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

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

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

Петр Василенко: Совсем недавно. Мы ещё сейчас только меняем везде название.

Петр Василенко: Меняется наш логотип, как разработчика, вендора, а логотип продукта останется без изменений. Тут лучше не менять, а то пользователи потом запутаются.