Оптимизация расходов на корпоративную Java-разработку: меньше команда — дешевле результат
Еще несколько лет назад вопрос «на чем разрабатывать корпоративные приложения» для большинства крупных российских компаний не стоял. SAP, Oracle, IBM и другие мировые вендоры уверенно закрывали потребности крупных предприятий в технологических платформах. Новые сервисы — будь то формы для работы с договорами, заявками или отчетами — создавались «как есть»: дорого, но надежно, престижно и с привлечением консультантов и методологов.
Содержание |
Что изменилось
После 2022 года компании оказались в новых условиях. Им пришлось искать альтернативные подходы к созданию корпоративных приложений. Цифровая повестка никуда не исчезла: бизнесу по-прежнему нужно выпускать новые сервисы и цифровизировать процессы — под давлением регуляторных требований, изменений на рынке и технологических вызовов. Вопрос выбора платформы для внутренних систем стал ключевым для CIO и руководителей разработки.
В некоторых случаях готовые ИТ-продукты справляются с задачей — на российском рынке есть проверенные решения, например, в сегменте ECM, WMS, HRM, GRC. Но во многих ситуациях невозможно перевести на них существующие системы, которые последние 10–15 лет кастомизировались под специфику бизнеса.
Как выбрать технологический стек с учетом будущего развития технологий корпоративной разработки, кадрового рынка и стратегии компании?
Для бизнеса технологический стек — это не спор о преимуществах языков программирования или фреймворков. Это вопрос стоимости внедрения изменений и владения системой.
Особенности корпоративных информационных систем
Уточним: корпоративные информационные системы — это не просто витрины данных, а повседневные рабочие инструменты сотрудников. В них данные вносятся, обрабатываются и сохраняются в соответствии с бизнес-процессами, а затем передаются в аналитические системы и корпоративные хранилища.
Главная «точка контакта» сотрудника с системой — экранная форма пользовательского интерфейса. От качества и скорости разработки таких форм зависит, насколько быстро можно внести изменения в бизнес-процесс или заполнить важные данные. Пользовательские формы — «вечный двигатель» корпоративных ИС
«Кровавый энтерпрайз» живет на таблицах и формах. Причем речь идет не о простых полях ввода, а о сложных интерфейсах с десятками полей, валидациями, бизнес-правилами и интеграциями с внешними системами. Именно они определяют, как работает сотрудник каждый день, и какого качества данные поступают в хранилище.
Не случайно проектирование корпоративных приложений в 80 % случаев начинается с построения пользовательских форм и описания бизнес-логики в виде workflow.
Поэтому для ИТ-менеджеров стоимость разработки этих форм критична: каждое изменение бизнес-процесса влечет за собой доработку интерфейсов, проверок и интеграций. Выбор технологии разработки напрямую влияет на скорость доставки изменений, стоимость реализации и владения системой.
От чего зависят затраты на разработку корпоративных систем
Рассмотрим ключевые нефункциональные требования, которые сильно влияют на скорость и стоимость даже самых простых изменений.
Современные корпоративные системы — это веб-приложения.
Фронтенд и бэкенд разделены, но должны работать как единое целое. На бэкенде сосредоточена бизнес-логика, а на фронтенде — визуальная часть и взаимодействие с пользователем. Создание современного корпоративного веб-приложения — это почти всегда результат работы разработчиков с разной специализацией. Конечный результат зависит от правильности выбора архитектуры и уровня слаженности команды. Недостаточное регулирование в области контроля архитектуры приложений порождает издержки, вызванные избыточной сложностью проектов и недостатком компетенций. Как правило, негативные факторы проявляют себя на длинной дистанции — 2-3 года.
Веб-приложения кроссплатформенны.
Они должны одинаково работать в браузере на ноутбуке, на терминале в офисе или на планшете в командировке. Поэтому любые изменения в форме нужно тестировать сразу в разных средах и на разных устройствах. Дополнительный вклад в стоимость внесения изменений накладывают требования информационной безопасности, которые команде разработки важно обеспечить на всех используемых в компании платформах.
Сложность изменений как следствие многослойности.
Добавление одного нового поля в форму — это не просто строка ввода. Это многоступенчатый процесс изменений на всех слоях приложения, от структуры хранимых данных до добавления компонентов на пользовательской форме. С точки зрения стоимости изменений — это означает, что даже при малейшем изменении включается в работу вся команда разработки: аналитик, фронт- и бэкенд разработчик, тестировщик.
В корпоративном ландшафте такие изменения занимают не недели, а месяцы — с учетом согласований, тестирования и развертывания. Поэтому выбор платформы становится стратегическим решением: от него зависит, сколько времени и денег компания потратит на создание, поддержку и развитие систем, обеспечивающих ее повседневную работу.
Три стратегии корпоративной разработки
Сегодня корпоративные ИТ-подразделения вынуждены искать баланс между скоростью цифровизации и стоимостью разработки. ИТ-менеджеры принимают решение об использовании технологии на основе экономических эффектов, которые позволят усилить рыночные позиции, оптимизировать расходы и избежать возможных убытков. На практике это выражается в выборе одной из трех стратегий.
Первый путь — повышение продуктивности традиционной разработки.
Самый трудоемкий путь.
В компаниях по-прежнему широко используют Java (Spring Boot вместе с React или Angular) и .NET (.NET Core с Blazor, React или Angular). Такой подход обеспечивает максимальную гибкость: можно реализовать практически любую логику, кастомизацию UI и интеграцию. Но за гибкость приходится платить:
- Команды разрастаются: нужны фронтенд, бэкенд, DevOps, QA.
- Координация между ролями создает дополнительные издержки и неопределенность.
- Проекты стоят дорого, сроки постоянно сдвигаются, а стоимость поддержки растет.
Решение — поиск инструментов повышения продуктивной разработки, направленных на снижение рутинных операций и сокращение возможных ошибок применения технологий.
Второй путь — Low-code платформы.
После ухода западных вендоров на рынке активизировались отечественные игроки — Elma, Comindware, GreenData, SimpleOne. Эти платформы позволяют оперативно собрать прототип и показать его бизнесу. Однако иллюзия легкости быстро рассеивается при попытке создать кастомный продукт под сложную бизнес-задачу. Low-code плохо масштабируется, страдает при высоких нагрузках и затрудняет долгосрочную поддержку.
Кроме того:
- Модель лицензирования «за пользователя» создает постоянные операционные издержки.
- Код нельзя перенести на другую платформу.
- Особенно страдают команды, которым нужно создавать продукты для последующей дистрибуции на открытом рынке — такая задача все чаще встречается в корпоративной разработке.
Full-stack платформы разработки
Компактные команды разработки делают ставку на фуллстек платформы, которые дают максимальную стандартизацию решений и унификацию ролей в команде. Сюда относятся платформы Jmix (стек Java), Django (стек Python), Laravel (стек PHP), Next.js/Nuxt.js (стек JavaScript/TypeScript). Этот класс решений представляет компромисс между скоростью изменений и гибкостью.
Фулл-стек платформы дают скорость и удобство, близкие к low-code, но при этом контроль и прозрачность разработки, характерные для традиционного подхода. Такой вариант особенно важен для корпоративного сектора, где цена ошибки велика, а от команды ждут предсказуемости и быстрой окупаемости.
Jmix: Less Code платформа для разработки бизнес-приложений
Jmix — это представитель класса фуллстек-платформ разработки корпоративных приложений.
В отличие от low-code решений, в Jmix сохраняется полный контроль над кодом: разработка ведется на Java и Kotlin, без скрытых проприетарных механизмов. Для ИТ-директоров это означает прозрачность архитектуры, возможность проверять и дорабатывать решения без привязки к вендору. Если чего-то не хватает — не надо никого ждать, можно сделать самим по шаблону или переопределить реализацию конкретной функции без потери совместимости.
Второй важный принцип, который характеризует работу с Jmix — высокая продуктивность разработки. Платформа сокращает издержки на доставку изменений и владение конечным цифровым продуктом. Это достигается за счет стандартизации архитектуры приложений, продуктивных визуальных инструментов разработки и готовых функциональных блоков. Благодаря этому команды стабильно выходят на релизы в срок. Активная коммуникация с большим профессиональным сообществом в разных отраслях сформировала современный облик платформы.
В результате разработка на Jmix сочетает два ключевых фактора: гибкость профессиональной разработки и снижение проектных рисков за счет стандартизированной платформенной основы. Инструменты разработки приложения доступны как для разработчиков, так и для системных аналитиков. Бизнес-пользователи могут быстро выполнять кастомизации приложений в рамках своих прав доступа.
Мы верим, что данный подход позволяет минимизировать негативные эффекты Shadow IT в корпорациях, но не за счет вовлечения в разработку бизнес-пользователей, а за счет повышения продуктивности ИТ-служб.
Экономика Less Code на примере проекта B2B CRM
Как оценить экономический эффект при внедрении технологической платформы Less Code разработки в реальных бизнес-кейсах?
Рассмотрим проект создания специализированной CRM-системы для работы с B2B клиентами. Почему этот случай можно назвать показательным? Дело в том, что почти всегда корпоративные клиенты имеют индустриальную специфику при работе со сбытовой сетью. Специфичными являются схемы комплектования продуктов и сервисов, сложные правила ценообразования и многообразие вариантов поставки. Попытки создания приложений такого класса с помощью low-code инструментов в основном заканчиваются обманутыми ожиданиями по срокам проекта и возможностями кастомизации.
Предположим, разработка первой стабильной версии на традиционном стеке займет 12 месяцев. Сравним с использованием Jmix.
Для подсчета экономического эффекта ROI платформы Jmix воспользуемся формулой: ROI = (Экономическая выгода — Стоимость внедрения технологии) / Стоимость внедрения технологии
Где экономическая выгода вычисляется по формуле:
Экономическая выгода = Выгода от сокращения числа ролей + Выгода от сокращенного времени разработки + Выгода от сокращения TCO
Теперь оценим влияние использования платформы Jmix на каждый из параметров по сравнению с традиционной разработкой.
Сокращение числа ролей
Рассмотрим состав типовой команды разработки проекта на традиционном стеке технологий
Для расчета кейса примем следующее значение параметров:
- Общее количество полных ставок на проекте — 5,25
- Стоимость одной полной ставки инженера, включая налоги, составит 6 млн руб./год
Jmix унифицирует часть ролей в команде разработки, не разрушая при этом привычный технологический процесс. С помощью Jmix бэкенд-разработчик разрабатывает все приложение целиком, используя один язык программирования Java или Kotlin. За счет фулл-стек архитектуры Jmix приложений исчезает необходимость в отдельном фронтенд приложении, а следовательно, вдвое сокращаются расходы на тестирование и развертывание. В результате использование Jmix снижает общий размер команды до 3,85 ставки вместо 5,25. Расшифровка представлена на обновленной схеме структуры команды в разрезе ставок.
Экономическая выгода от сокращения ролей составит 8,4 млн руб., как результат перемножения стоимости одной ставки 6 млн. руб. на количество выбывших ставок 1,4.
Сокращенное время разработки
В состав платформы Jmix входят инструменты продуктивности, которые минимизируют избыточный код проекта. Все участники разработки фокусируются только на бизнес коде и не тратят время на инфраструктурные аспекты.
Наибольший вклад в сокращение времени разработки оказывают:
- Визуальные инструменты поддержки разработки модели данных, экранов, бизнес-процессов, ролей пользователей и т.д.;
- Совместная работа аналитиков и разработчиков в едином информационном пространстве на основе принятых в профессиональной разработке инструментов;
- AI-помощник в процессе разработки подсказывает лучшие практики и помогает быстро разобраться с ошибками;
- Готовые к использованию компоненты, которые работают по системе — подключи и используй;
- Исключение из процесса разработки фронтенда сокращает временные затраты на согласование и тестирования модулей приложения;
- Бизнес-функциональность доступна для модификации в самом приложении без привлечения разработчика и точную настройку пользователи делают сами.
Jmix сокращает время реализации проекта на 25% от общего времени по сравнению с традиционной разработкой на Java стеке. Рассчитаем размер экономической выгоды от сокращения времени реализации по шагам:
Шаг 1. Определить базу рабочих часов сотрудников для расчета
Для расчета берется стандартная рабочая норма 1 600 часов в год на одного сотрудника (FTE). Обратите внимание, что мы берем не все время сотрудника в год, а уменьшенное на отпуска, больничные и повышение квалификации. Команда проекта после оптимизации составляет 3,85 FTE, следовательно, база рабочих часов сотрудников составит
3,85 × 1 600 ч = 6 160 ч/год.
Шаг 2. Расчет размера выгоды за счет сокращения времени реализации проекта
Платформа позволяет ускорить выполнение задач примерно до 25%. В рабочих часах это составит 1 540 ч (= 25% × 6 160 ч) — это трудозатраты, которые можно высвободить. Расчетным путем получаем среднюю ставку одного инженера в размере 6 000 000 ₽ / 1 600 ч = 3 750 ₽/ч.
Соответственно, размер выгоды за счет сокращения времени реализации проекта составит: 1 540 ч × 3 750 ₽ = 5 775 000 ₽.
Сокращение TCO (Total Cost of Ownership)
При разработке с использованием less-code платформы Jmix результатом работы является приложение, которое принадлежит компании.
Нет платежей за конечных пользователей. Нет платежей за инфраструктуру развертывания. Нет ограничений на дистрибуцию готовых решений.
Единожды вложившись в освоение технологии, компания получает регулярные обновления платформы от команды Jmix и оплачивает только стоимость платных версий инструментов для продуктивной работы. Для удобства входа в технологию базовый набор инструментов предоставляется открыто и бесплатно.
В данном кейсе мы рассчитываем экономический эффект применительно к традиционной разработке. Для оценки стоимости владения можно взять количество ставок разработчиков, которые требуются для обновления и поддержки своих собственных, так называемых «домашних» фреймворков. По данным исследований команды «Хоулмонт» поддержка своего фреймворка редко бывает дешевле половины ставки квалифицированного разработчика. Именно это значение и возьмем для расчета стоимости экономического эффекта.
Стоимость внедрения
Стоимость внедрения технологии включает платные инструменты для продуктивной разработки и затраты на изучение Jmix. Инструменты лицензируются в привязке к рабочим местам разработчиков. Оплата взимается только за тех специалистов, которые используют инструменты продуктивности в проекте, в нашем случае для разработки CRM системы.
Стоимость изучения складывается в первую очередь из времени, которое требуется команде на освоение и опробование платформы. Для быстрого входа в технологию команда Jmix предоставляет широкий спектр бесплатных возможностей от открытой документации до коммьюнити-канала в мессенджере Телеграм. Команды могут также воспользоваться услугами учебного центра и пройти интенсив от специалистов команды разработки.
В модельном примере стоимость внедрения оценивается в 2,5 млн. руб.
Расчет срока окупаемости использования Jmix
Подставляем значения всех эффектов в итоговую формулу — получаем срок окупаемости технологии 2 месяца! И это без учета фактора экономического эффекта от более раннего внедрения самого цифрового продукта. Более того, в модельном кейсе все издержки на освоение и опробование технологии отнесены на один проект, хотя в реальности эта же команда сделает множество проектов, и срок окупаемости наступит еще быстрее.
Дополнительно на схеме представлен срок окупаемости при инвестициях в технологию продуктивной разработки Jmix. Срок окупаемости для типового проекта B2B CRM составит 2 месяца. Для расчета срока окупаемости использована следующая формула:
Срок окупаемости (в месяцах) = Стоимость внедрения / (Экономическая выгода - Стоимость внедрения) / 12
Почему именно Java?
Наибольший эффект Less Code платформа Jmix дает при создании разнообразных приложений бэкофиса и B2B фронт-офиса в случае, если в стеке технологий компании присутствует Java разработка.
Java или Kotlin являются основными языками для разработки Jmix приложений. За Java закрепилась устойчивая ассоциация со сложностью разработки и большим количеством инфраструктурного кода. Это статья не предназначена для того, чтобы адвокатировать технологический стек Java перед другими. Тем более, что сложность Java — это отражение трудности самой корпоративной разработки во всем многообразии кейсов. С первого дня команда разработки Jmix делала ставку именно на Java в связи с тем, что:
- Java развивается по стандартам. Для любого технического решения описана спецификация, а набор используемых при разработке компонентов уже устоялся. В противоположность, например, JavaScript стеку, где изменения продолжают активно «бурлить»;
- Java имеет самую мощную технологическую поддержку в России благодаря усилиям отечественных команд Axiom JDK и «Группы Астра»;
- Java на протяжении 30 лет отлично показывает себя в крупном энтерпрайзе. Это означает, что технология будет популярна еще как минимум столько же лет;
- Сообщество Java активно развивается благодаря профессиональным сообществам технологических лидеров в финансовой отрасли (Сбер, Т-Банк, Альфа-Банк) и пр.;
- Для технологического стека Java в России созданы 2 отечественных IDE — OpenIDE и GigaIDE с поддержкой от вендоров Хоулмонт, Axiom JDK, «Группы Астра» и Сбера.
В совокупности набор этих факторов формирует мощный фундамент для продолжения активной популяризации Java в России.
С 2025 года команда Jmix начала проводить регулярные митапы команд разработчиков в Москве и Санкт-Петербурге, чтобы лучше слышать потребности рынка и совершенствовать продукт для укрепления технологического лидерства.
Сегодня разработка на Jmix уже ведется в банковском секторе, ритейле, энергетике и госсекторе. За счет того, что платформа Jmix не включает в себя ограничений вертикальных рынков, независимые команды создают отраслевые решения и завоевывают ниши ушедших с рынка иностранных вендоров.
Как начать использование Jmix в компании
Начать легко. Обычно компании запускают пилотный проект: аналитик и бэкенд-разработчик за 2–4 недели создают рабочее MVP и демонстрируют его бизнес-заказчику. Сравнение с традиционным стеком делает решение очевидным — и вопрос о масштабировании снимается сам собой.
Приглашаем вас на вебинар с подробным разбором кейсов применения Jmix по теме: «Оптимизация расходов на корпоративную Java-разработку: меньше команда — дешевле результат». Покажем и расскажем больше практических кейсов, дадим рекомендации по первым шагам для формирования команды.
