Александр Голиков: Продукты САПР должны жить в рынке

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

Легкие системы — это системы 2D.

Черчение и приложения к чертежным системам. Средний класс — это 3D-моделирование, это расчеты, это системы проектирования управляющих программ (УП) для станков с числовым программным управлением (ЧПУ). Отдельные системы данного типа могут использоваться автономно или интегрироваться друг с другом через универсальные форматы обмена. Например, на выходе системы трехмерного моделирования CAD 3D-модель изделия может быть передана в систему расчетов, то есть в CAE-систему. Или, предположим, она может поступить в систему для проектирования управляющих программ для станков с ЧПУ — CAM-систему. Информация может централизованно храниться в системе PDM, которая управляет всеми инженерными данными по изделию. Эти системы решают, в принципе, задачи и проектирования, и расчетов, и подготовки производства, и хранения информации об изделии, но общая задача выполняется за счет интеграции отдельных независимых ИТ-инструментов. Этот класс систем представлен и отечественными продуктами, в частности разработками «Аскон» и ее партнеров. Что же касается отечественных тяжелых систем, то их пока нет.

Что такое тяжелые системы? Функционально они делают, условно говоря, то же самое, что и интегрированные средние системы. Но это более развитая функциональность и другой принцип архитектуры программного комплекса. В тяжелых системах идет работа с единой информационной моделью изделия (она может, например, храниться в базе данных либо быть реализована иначе). Эти решения применяются для наиболее трудоемких задач — проектирования сложных изделий (работа с огромными сборками), их расчетов и моделирования поведения в реальном времени. В частности, когда мы говорим о проектировании целого самолета: вся электронная модель изделия собирается в единой базе (что позволяет не работать постоянно с 3D-моделью самолета целиком, не перегружать технику излишней на этот момент информацией, работать по блокам, узлам, отсекам, имея возможность в любой момент охватить весь проект целиком). Россия сегодня, в силу советского прошлого, в силу сильной инженерной школы, одна из немногих стран, которая обладает компетенциями по всем ключевым сегментам, всем ключевым областям PLM от проектирования (CAD) и расчетов (CAE) до технологических систем (CAM, САПР-ТП). И один из немногих коммерческих математических «движков», ядер, которых в мире насчитывается всего пять- шесть, — собственная разработка нашей компании. Речь идет о геометрическом ядре C3D, на котором построен «Компас-3D».

Да. Так получилось, что у нас есть конкурентоспособные отечественные продукты, представленные во всех классах. Они доказали свою востребованность — все эти годы нам приходилось конкурировать на полностью открытом отечественном рынке с мировыми глобальными лидерами. У нас в стране не было никаких заградительных барьеров для западного ПО, не было никакого протекционизма и государственной поддержки. То, что отечественные производители занимают 20–25 процентов рынка, — это показатель того, что мы предлагаем качественные продукты. Более того, многие зарубежные производители, открывающие производство в России, для своих инженерных подразделений выбрали российское ПО. С продуктами «Аскон» работают Даймлер КамАЗ Рус. (совместное предприятие КамАЗа и немецкого автомобилестроительного концерна Daimler), машиностроительный концерн Camozzi, заводы японских компаний Komatsu и Hitachi, многие зарубежные производители автокомпонентов, вышедшие в последние годы на наш рынок. Российские разработчики САПР участвуют и в международной научной кооперации. Так, компания «Тесис» для проекта «Живое сердце» (The Living Heart) выполняет расчеты движения крови в своей системе FlowVision, и эти расчеты признаются более точными, чем сделанные в зарубежной CAE- системе. Да, пока российский инженерный софт закрывает не все задачи по самым сложным изделиям. Но в своем классе он решает их качественно и надежно, иначе его бы просто никто не покупал. Для того чтобы иметь альтернативу западному ПО в проектировании любой техники, мощности наших систем пока недостаточно. Мы честно говорим, что ускоренное развитие, создание за десять-пятнадцать лет отечественного комплекса тяжелого класса без определенной государственной поддержки — невозможно.

Да, теперь серьезно изменились геополитические условия, и правительство вернулось к тому, о чем мы говорили уже многие годы: надо поддерживать отечественную софтверную отрасль. В частности, эта работа велась все последние годы Ассоциацией разработчиков программных продуктов «Отечественный софт», объединяющей сегодня уже более 130 ведущих отечественных разработчиков программных продуктов. Работая с правительством, мы всегда обращали внимание на то, что есть два весомых аргумента в пользу поддержки отечественного софтвера. Первый фактор — экономический, потому что чем больше производится внутри страны, тем выгоднее для нее. Центры компетенции будут в России, они будут развиваться, и это прямое благо для государства, это рабочие места, это налоги и так далее. С другой стороны, поскольку Россия все-таки претендует на то, чтобы быть не объектом, а субъектом политики, то технологическая и информационная безопасность не пустой звук. К сожалению, наши предложения не были услышаны. Но серьезное обострение международной обстановки высветило то, что сегодня информационные технологии являются кровеносной и нервной системой любой экономики и очень серьезно подвержены внешним угрозам. Вирусная атака на объекты ядерной программы Ирана, манипуляция GPS-данными во время грузинских событий — таких примеров множество.

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

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

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

Естественно, но не мы одни. Формировать свои консорциумы могли все желающие. В том числе те, кто вообще раньше не занимался разработкой инженерного ПО. Назывались различные цифры требуемого финансирования от пяти-шести до 63 миллиардов рублей. Последняя цифра была названа представителями МГТУ и КГТУ.

Да. Коллеги убеждены, что, получив 63 миллиарда, можно нанять пару тысяч программистов и решить любую задачу. Это все равно как если бы «Аскон», занимаясь софтом, взялся бы за дальнемагистральный самолет. Какие проблемы, дайте NN миллиардов, а я найму КБ Сухого или МиГ, кого-то куплю, кого-то возьму на субподряд — и все сделаю. Вот такая примерно логика. Но это крайности. Конечно, и реальные лидеры в своих сегментах ПО тоже объединялись и делали предложения.

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

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

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

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

Пока я описал то, как видят ситуацию разработчики. Есть свое видение ситуации и проблем у органов власти. А есть еще одна сторона — возможные потребители. Это наши промышленные корпорации, прежде всего из оборонно-промышленного комплекса. При отсутствии геополитических проблем многие из них оснащались западным софтом, инвестировали в него немалые деньги. Были выстроены бизнес-процессы, обучены люди. Продукты Dassault Systemes или Siemens PLM установлены на сотнях рабочих мест. И тут вдруг появилась проблема: санкции, импортозамещение… Поставьте себя на место этих предприятий. Даже если бы имелось полностью готовое альтернативное отечественное решение, функционально закрывающее все их задачи, представьте объем средств, сил и времени для замены всех ИТ-систем. Долгие годы шло внедрение, шла адаптация, какие-то вещи дорабатывались непосредственно под эти предприятия. Теперь этот путь надо пройти заново, переобучить людей, по новой отладить весь процесс. Это очень непростая и затратная задача, наверняка будут сбои. А для промышленных предприятий ИТ – не самоцель, это всего лишь инструмент. Они проектируют свои самолеты, ракеты, танки (и далее по всему списку) и думают: а может, проблемы рассосутся? Плюс к этому, чтобы в группах по разработке ТТХ участвовать, предприятиям надо для этого выделять экспертов. И чтобы эти эксперты отработали в хорошем режиме несколько месяцев. Но все профессионалы, потенциальные эксперты, заняты на своей основной работе, да и никто не платит за это. Поэтому иногда, когда спрашивают руководителей и ИТ-директоров предприятий: «Вы за импортозамещение?», они отвечают: «Мы не возражаем! Мы за отечественные классные продукты! Принесите нам чудо не хуже заморского, и мы посмотрим!» Впрочем, надо отметить, что промышленные потребители действительно стали более лояльны к отечественным продуктам. Раньше они могли говорить: «Мы будем внедрять только самые крутые системы, чтобы как у мировых лидеров», даже если функционал этих систем был для них избыточен на 50–70 процентов. Сейчас же есть понимание, что это дорого, плюс есть определенные угрозы. Они разговаривают с отечественными производителями, готовы выделять пилотные участки для апробации и отладки применения российских систем у себя. И если они видят, что вместо импортного более дорогого CAD можно с не меньшей эффективностью применять наш «Компас», начинаем полномасштабную работу по замене.

Такую замену уже реализовали «Гражданские самолеты Сухого» (производитель лайнера Sukhoi Superjet 100), отказавшиеся от AutoCAD в пользу «Компаса». Масштаб импортозамещения составил более ста рабочих мест, это существенно. Пример из другой отрасли — Дальневосточный проектный институт «Востокпроектверфь», который тоже перешел с AutoCAD на «Компас». У коллег из компании «Нанософт» есть хороший пример взаимодействия с холдингом «Газпром проектирование», где изначально планировалась крупная закупка продуктов компании Autodesk на двести с лишним миллионов рублей. Эту закупку отменили, и на большинстве рабочих мест, куда хотели поставить ПО Autodesk, будет работать российский nanoCAD.

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

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

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

Дальнейшая история легко прогнозируется. Авторы альтернативной концепции снова будут говорить: «У нас огромный задел, еще пять-семь лет — и будет просто чудо, всех заткнем за пояс, дайте еще десять миллиардов». Где тут рынок?

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

Но помимо того, что наступает кассовый разрыв и нет генерации дохода, есть еще одна проблема. Проблема, которая также является краеугольной при реализации любых импортозаместительных проектов. У нас государство устами федеральных органов исполнительной власти говорит: «Мы не можем финансировать коммерческие компании. Мы можем финансировать какие-то проекты, но права на них принадлежат тому, кто платит за это деньги, то есть государству». А это значит — никому. Продукт, если он не развивается, будет мертворожденным. Когда не определен его владелец, продукт нельзя ни сопровождать, ни развивать. Можно, конечно, создать ГосНИИ для разработки ГосPLM, вспомнив социалистическое прошлое.

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

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

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

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

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

Мы создавали консорциум под своим интеграторским зонтиком, объединяя собственные компетенции в области PDM, CAD, MDM, САПР ТП с компетенциями партнеров в области CAE, CAM, EDA (систем проектирования электронных изделий, печатных плат). Пул предприятий-заказчиков может быть товариществом, которое они создают именно для формирования требований, для приемки результата, для контроля реализации.

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

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