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

Миф 1. В России много умных программистов, и они наверняка уже создали замену SAP, Oracle и IBM.

До недавнего времени в стране не было значимых стимулов для создания отечественных средств разработки информационных систем корпоративного уровня и готовых решений на их основе. Задачи базовой автоматизации операционного и стратегического уровня управления в больших корпорациях давно закрыты платформами и решениями зарубежных вендоров. Они и сейчас занимают доминирующее положение на российском корпоративном рынке. По данным открытых источников об объеме выручки единственным ведущим игроком на внутреннем рынке платформ корпоративной автоматизации была и остается компания «1С» — ближайшие конкуренты отстают на порядок. По данным опросов сообщества «1С» в 2022 году, в среднем с одной базой «1С» одновременно работает от 11 до 500 пользователей и таких инсталляций 73% из всех имеющихся в стране, 72% разработчиков «1С» работали с базами данных размером от 11 до 500 Гбайт. Поэтому нет ничего удивительного, что российские корпорации ранее не выбирали «1С:Предприятие», а предпочитали SAP, Oracle, Microsoft, Infor и IBM, изделия которых ориентированы на высокие нагрузки на уровне архитектуры технологических платформ и обеспечены профессиональными инструментами разработки с большим сообществом. Особенно важно, что готовые решения подобных вендоров были обеспечены консультантами и проектной экспертизой для внедрений в корпоративном секторе.

В итоге сейчас на российском рынке готовых решений для замены ушедшим игрокам просто нет. Корпорации, которые решились на эксперименты с масштабным внедрением «1С:ERP Управление предприятием», — герои-первопроходцы. Можно быть уверенным, что их проекты поднимут стоимость разработчиков «1С» и сделают жизнь предприятий среднего и малого бизнеса еще тяжелее. Причина — средний возраст разработчика «1С» сейчас 35–44 года, и, как свидетельствует статистика, новички не спешат пополнять их ряды. Технологии «1С» пока не очень популярны среди выпускников профильных ИТ-специальностей — сообщество изолировано в масштабах принятых технологий разработки. Работа в технологической платформе «1С» слишком отдалена от профессиональной разработки, хотя на ее освоение требуется столько же времени, сколько и на любую подобную, но более распространенную в мире. В результате сообщество маргинализируется.

Бытует мнение, что помочь смогут бывшие отечественные специалисты SAP и Oracle, но это маловероятно. Во-первых, крупные холдинги, да и некоторые государственные корпорации не заинтересованы в замене платформы базовой автоматизации. Инвестиции выполнены, процессы выстроены, имеются экосистема команд для поддержки решений и методология управления проектами. Мотивация специалистов для переучивания не ясна — для них это полная смена парадигмы и потеря квалификации. Повторюсь — времени для становления специалистом «1С:Предприятие» требуется столько же, сколько и SAP, но навыки слабо совместимы из-за проприетарной природы обоих вендоров. Во-вторых, доработка платформы «1С:Предприятия» до корпоративных стандартов требует по сути создания нового продукта. Эта платформа была выпущена почти 20 лет назад, и пока продукты для ее замены компанией «1С» не анонсированы. После анонса на раскатку и переход к тиражированию платформы потребуется минимум 3–5 лет для выхода на рынок и формирования пула специалистов.

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

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

Миф 2. С помощью платформы Low-code можно заменить корпоративную ERP-систему.

Могут ли платформы Low-code обеспечить отечественные корпорации инструментами быстрого создания приложений с минимальными усилиями разработчиков и заменить корпоративные системы? После выхода Указа Президента РФ № 166 от 30.03.2022 г. «О мерах по обеспечению технологической независимости и безопасности критической информационной инфраструктуры Российской Федерации» вендоры платформ Low-code усилили пропаганду тезиса о возможностях импортозамещения корпоративных информационных систем ушедших западных разработчиков. Даже в «1С» стали говорить, что на самом деле платформа«1С:Предприятие 8» — это тоже Low-code. К счастью, подобный популизм прекратился:

  • разработчик Low-code — это гражданский разработчик, не обладающий навыками проектирования корпоративных систем, а профессиональные разработчики избегают работы с Low-code, так как это новый и ненужный для них инструмент;
  • платформы Low-сode проектировались для прототипирования бизнес-приложений с помощью готовых шаблонов и инструментов визуального программирования; кастомизация шаблонов и интеграция в корпоративный ландшафт часто возможна, но так же сложна, как и в традиционной разработке;
  • платформы Low-сode слабо поддерживают принятые в современной разработке процессы совместной работы над проектом, имеют строго проприетарную природу и, как следствие, vendor lock-in, отсутствие у пользователей возможности сменить поставщика.

Фактор vendor lock-in особенно актуален при выборе технологии создания cистем базовой автоматизации, от которых зависит устойчивость бизнеса. Связывать устойчивость компании с проприетарной технологией, на которой разработку ведут гражданские специалисты, это то же самое, что в 2023 году стартовать новый проект на SAP. В обоих случаях в скором будущем придется опять все переделывать.

Резюме. На рынке разработки корпоративных информационных систем для каждой задачи существуют специализированные инструменты. Платформы Low-code созданы для того, чтобы простые задачи сделать быстро с помощью привлечения гражданских разработчиков. Сложное сделать просто затруднительно или невозможно. Для импортозамещения модулей базовой автоматизации нужно выбирать технологии, ориентированные на профессиональных разработчиков с открытой архитектурой, большим комьюнити и без vendor lock-in.

Миф 3. Исследовательские центры апробирования ИТ нужны только научным организациям, а не коммерческим предприятиям.

Движение цифровой трансформации в корпоративном секторе ускорило создание разнообразных технологий и продуктов на их основе, преобразив ландшафт традиционных ERP-cистем. Многообразие технологий обусловлено усложнением архитектуры информационных систем, которые, в свою очередь, вынуждены сегодня обрабатывать все больше данных и автоматизировать множество бизнес-процессов, работающих с различными каналами взаимодействия как с клиентами, так и между собой. Привычная в начале нулевых грань между классами систем ERP, CRM и EСM размывается. Разработчики развивают платформный подход за счет добавления все новой бизнес- и системной функциональности (например, Salesforce) или, наоборот, специализируются на конкретном аспекте автоматизации (стек ELK — Elasticsearch, Logstash и Kibana). В таких условиях ИТ-менеджерам, ответственным за выработку и принятие решений по способу достижения целей цифровой трансформации, становится все сложнее отдать предпочтение той или иной технологии — без испытаний и пилотирования прототипов редко получается сделать обоснованный выбор. Руководствоваться только материалами на сайте вендора — это большой риск упустить детали.

Ситуация с применением новых технологий в корпоративном секторе усложняется наличием внутренних нормативов по организации закупок. Для проведения закупки менеджеру по цифровизации необходимо четко сформулировать периметр проекта, определить бизнес- и нефункциональные требования. На начальном этапе адаптации технологии составление закупочной документации только добавляет неопределенности и формирует не подтвержденные данными ограничения будущего проекта. Частично эту проблему решают процедуры RFI (Request For Information), однако это те же закупочные процедуры с циклами от трех месяцев на сбор предложений потенциальных контрагентов, их последующий анализ и подведение итогов. Все это увеличивает время на опробование и внедрение новации и закладывает основу для будущих коллизий с вендором на этапе внедрения проекта.

Представьте, что бизнес сформулировал задачу по повышению уровня удовлетворенности клиентов за счет повышения эффективности процесса обработки заказов покупателей на предприятии. Заказы приходят по различным каналам продаж и в процессе своего жизненного цикла проходят этапы от проектирования до отправки заказа клиенту. Проектируемая система на каждом этапе должна информировать клиента о стадии выполнения заказа по предпочтительному каналу коммуникаций и в процессе жизненного цикла формировать все сопроводительные первичные документы. Описанную задачу можно реализовать с помощью платформ CRM, ECM, ERP, BPM, интеграционной платформы и платформы быстрой разработки бизнес-приложений, каждая представлена различными системами лицензирования, ценообразования и подходами к организации разработки. В одном случае вендор берет деньги за исполняемую среду, в другом за инструменты разработки. Для интеграционной платформы стоимость внедрения равна нулю, тогда как для cистем CRM, ECM и BPM она может быть выше стоимости лицензий. Затруднительно сравнивать эти подходы в рамках одной конкурсной процедуры на основе общей системы критериев. В результате для упрощения составляется набор критериев в соответствии с уже используемыми в компании технологиями и все альтернативные подходы просто отсекаются, отдавая предпочтение предыдущему опыту.

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

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

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

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

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

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

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

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

Один из заметных примеров успешных промышленных решений, основанных на свободном ПО, — система оркестрации контейнеров Kubernetes. Благодаря своей гибкости и масштабируемости Kubernetes нашла широкое применение в различных отраслях, от стартапов до крупных корпораций. Ее активное развитие и поддержка происходят благодаря значительному сообществу разработчиков, включая технологических гигантов, вносящих свой вклад в улучшение и оптимизацию платформы. Второй пример — платформа GitLab для контроля версий, совместной разработки программного обеспечения и автоматизации процессов непрерывной интеграции и непрерывного развертывания ПО. Если посмотреть на представленные на российском рынке платформы для автоматизации процессов внутренней разработки, то почти наверняка там будет GitLab. Ну и, конечно, Java — один из самых популярных языков программирования. В 2010 году Oracle приобрела Sun Microsystems, а в 2017 году передала Java Enterprise Edition (Java EE) сообществу Eclipse Foundation, которое продолжило разработку платформы под названием Jakarta EE. Передача стандартных библиотек в Open Source привела к образованию множества других фреймворков и библиотек для разработки приложений. Одним из таких фреймворков стал Spring Boot — среда для быстрого создания автономных приложений на основе Java с минимальной конфигурацией. Сегодня Spring Boot — стандарт де-факто для разработки бэкенд-приложений на Java.

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

Резюме. Open Source уже давно стал драйвером распространения и внедрения новаций. С этим согласились и крупные международные вендоры.

***

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

Виктор Фадеев (v.fadeev@haulmont.com) — директор по развитию платформы Jmix (Самара).