Enterprise-разработка: чем отличается от обычной и когда нужна бизнесу

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

30 августа 2026 Бизнес 15 мин чтения

---

Что такое enterprise-разработка простыми словами

Enterprise (от англ. enterprise — предприятие) — это разработка систем для организации, а не для одного отдела или одного сценария. Такой системой одновременно пользуются сотрудники разных подразделений, партнёры, оптовые покупатели и клиенты. У каждой группы свой набор прав, свои экраны и свои данные.

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

Практически enterprise-проект узнают по трём признакам:

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

Распространённое заблуждение — считать, что «enterprise» означает только «долго и дорого». Уровень задают требования, и часть из них закрывается готовыми компонентами: авторизация, личный кабинет, уведомления, оплата и обмен с учётной системой давно решены типовым образом. Уникальной остаётся бизнес-логика компании. Что входит в такие проекты, описано на страницах корпоративных приложений и разработки ПО на заказ.

Чем enterprise-разработка отличается от обычной

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

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

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

Типы корпоративных систем и B2B-платформ

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

Один и тот же бизнес нередко нуждается сразу в нескольких типах: оптовый кабинет для юридических лиц, внутренний сервис для менеджеров и приложение для склада. Отдельные направления описаны на страницах B2B-приложений для продаж юридическим лицам, информационных сайтов и порталов, SaaS-платформ под ключ и платформ для обучения.

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

Требования, которые добавляет масштаб компании

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

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

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

Архитектура и стек: из чего собирают корпоративную систему

Корпоративная система почти всегда состоит из четырёх частей: серверной части с бизнес-логикой, хранилища данных, интерфейсов для разных ролей и обменного слоя, через который система общается с остальными продуктами компании.

Серверная часть и данные

Серверную часть мы строим на Python: Django — когда нужны админка, права и отчётность из готовых компонентов, FastAPI — когда нужен быстрый программный интерфейс для мобильных клиентов и внешних систем. Данные хранятся в PostgreSQL, окружение собирается в Docker, чтобы тестовый и боевой стенды повторяли друг друга. Разбор подхода — в статье про веб-приложения на Django.

Интерфейсы для сотрудников и партнёров

У корпоративной системы обычно два интерфейса: рабочее место в браузере и мобильное приложение для тех, кто работает вне офиса. Оба собираются из одной кодовой базы на Flutter — это открытый фреймворк, из которого выходят приложения для iOS, Android, RuStore, веб и Telegram Mini Apps. Общая база сокращает и разработку, и дальнейшее сопровождение: правку бизнес-логики не приходится повторять в двух командах. Подробнее — на странице кроссплатформенной разработки на Flutter.

Обмен данными

Обменный слой — самая недооценённая часть корпоративного проекта. Он отвечает за то, чтобы заказ, заведённый в кабинете партнёра, дошёл до учётной системы ровно один раз, а при недоступности источника встал в очередь и ушёл позже. Для этого у каждой операции есть уникальный ключ, а у обмена — очередь, повторные попытки и наблюдение за сбоями. Принципы описаны в материале про проектирование REST API, состав работ — на страницах ERP-интеграции и интеграции с CRM.

Что берут готовым, а что пишут под компанию

Мы собираем продукты из готовых модулей и дописываем код там, где у компании собственная логика. Каталог, личный кабинет, оплата, уведомления, программа лояльности и обмен с 1С — это готовые модули платформы FITTIN, которые настраиваются под бренд. Права доступа под структуру холдинга, договорное ценообразование для оптовых покупателей или отраслевой документооборот — это кастомная разработка на исходном коде. Такое разделение обычно и определяет итоговую смету.

Порядок разработки: семь шагов от обследования до эксплуатации

Состав шагов одинаков для любого корпоративного проекта. Меняется глубина каждого шага и то, сколько подразделений в нём участвует.

Шаг 1. Обследование и цели (3–10 рабочих дней)

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

Шаг 2. Требования и техническое задание (10–20 рабочих дней)

Собираются сценарии по каждой роли, права доступа, состав данных, требования к безопасности и критерии приёмки. Результат — подписанное техническое задание, по которому считается смета. Типичная ошибка — не позвать службу безопасности: её требования приходят на приёмке, и права доступа переделывают целиком.

Шаг 3. Архитектура и договор обмена (5–15 рабочих дней)

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

Шаг 4. Дизайн интерфейсов под роли (10–20 рабочих дней)

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

Шаг 5. Разработка и интеграции (от 20 рабочих дней)

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

Шаг 6. Тестирование, нагрузка и безопасность (10–20 рабочих дней, параллельно с разработкой)

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

Шаг 7. Запуск, обучение и передача в эксплуатацию (5–15 рабочих дней)

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

Сумма минимальных длительностей всех семи шагов — около 63 рабочих дней. Календарный срок обычно короче, и вот почему: подготовительные шаги идут параллельно на разных ролях, тестирование ведётся одновременно с разработкой, а готовые модули не пишутся заново под каждый проект. Точный срок называют после обследования, когда известно состояние систем заказчика. Что чаще всего сдвигает даты, собрано в чек-листе по бюджету и срокам.

Когда бизнесу нужна enterprise-разработка

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

1. Процесс разошёлся с системой. Учёт ведётся в таблицах и переписке, данные переносят руками, а сверка занимает несколько дней в месяц. Это первый признак: процесс вырос, а инструмент остался прежним.
2. Несколько юридических лиц, городов или складов. Появляются свои цены, свои остатки и свои правила согласования. Универсальный инструмент перестаёт справляться, потому что не знает про структуру компании.
3. Партнёры просят самообслуживание. Оптовые покупатели хотят видеть свои цены, остатки и документы без звонка менеджеру. Это прямой запрос на B2B-платформу для юридических лиц.
4. Требования безопасности приходят снаружи. Крупный контрагент, отраслевой регулятор или собственная служба безопасности требуют разграничения прав, журнала действий и хранения данных на согласованных условиях.
5. Унаследованная (legacy) система стала тормозом. Продукт работает, но его некому развивать: разработчик ушёл, документации нет, каждое изменение занимает недели. Отправная точка здесь — аудит кода, а не переписывание с нуля.
6. Компания переходит на отечественное ПО. Зарубежный продукт больше не согласуют закупка и служба безопасности; нужна замена с сопоставимым набором функций.

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

Когда этот уровень не нужен и что выбрать вместо него

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

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

Команда и роли на корпоративном проекте

Состав команды на таком проекте шире, чем на обычном, и часть ролей находится на стороне заказчика. Без них проект встаёт на согласованиях.

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

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

Если своя команда есть, но ей не хватает рук по конкретному направлению, работает усиление: специалисты подключаются к вашим процессам и вашему трекеру задач. Направления — серверная разработка, Flutter и Dart, тестирование, инфраструктура и бизнес-аналитика. Что выгоднее в конкретной ситуации, разобрано в статье про внешнюю разработку и внутреннюю команду.

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

Стоимость корпоративного проекта складывается из двух частей: объёма собственной логики компании и состояния систем, к которым предстоит подключаться. Два одинаковых по описанию проекта расходятся вдвое, если в одной компании учётная система типовая, а в другой переписана под себя за десять лет.

Две модели оплаты

Fixed Price — фиксированная сумма за фиксированный объём работ; подходит, когда техническое задание готово и состав работ не меняется. Time & Materials — оплата по фактически отработанным часам и ставкам ролей; подходит для исследовательских задач и для развития работающего продукта. На корпоративных проектах модели часто сочетают: первый выпуск по фиксированной цене, дальнейшее развитие по часам. Разбор обеих моделей — в статьях Time & Materials против Fix Price и сравнение моделей разработки.

Три варианта и порядок затрат

Первая строка — рыночный ориентир для полностью заказной системы, вторая — наша модель, третья — сопровождение чужого продукта. Модель платформы состоит из трёх частей: единоразовая интеграция под бренд за срок до 30 рабочих дней; ежемесячные лицензионные платежи, в которые уже включены все затраты на техническую поддержку команды FITTIN, — собственная команда разработки для базового сопровождения не требуется; новый функционал и доработки — отдельно, по Time & Materials с прозрачной сметой и оценкой в часах перед стартом задачи. Действующие составы пакетов опубликованы на странице тарифов.

Семь факторов, которые двигают смету

• Число ролей и глубина прав. Пять ролей с простыми правами и двадцать ролей с правами по филиалам — разный объём работ.
• Количество интеграций и состояние методов обмена. Готовые опубликованные методы у заказчика — одна цена, их отсутствие — другая.
• Степень доработки учётной системы. Нетиповые документы и регистры почти всегда означают работы на стороне заказчика.
• Объём данных. Десятки тысяч позиций требуют отдельного внимания к поиску и скорости интерфейса.
• Требования к доступности. Резервирование, копии и проверенное восстановление — это отдельная инфраструктура.
• Требования безопасности. Журнал действий, разграничение прав и правила хранения персональных данных влияют на архитектуру.
• Число подразделений-участников. Чем больше согласующих сторон, тем длиннее подготовительные шаги.

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

Как выбрать подрядчика: десять вопросов до договора

Корпоративный проект — это долгие отношения: система живёт годами и требует сопровождения. Вопросы ниже стоит задать до подписания договора, а ответы — получить письменно.

1. Кто пишет техническое задание и входит ли оно в стоимость? Документ с ролями, сценариями и критериями приёмки — основание сметы.
2. Есть ли опыт интеграций с учётными системами? Попросите описать один такой проект: какие сущности передавались и как решали сбои обмена.
3. Как устроена приёмка? Что именно проверяется помимо функций: нагрузка, права доступа, восстановление после сбоя.
4. Что происходит после запуска? Время реакции, порядок обращений, кто отвечает за обновления — фиксируется в договоре.
5. Что остаётся у компании? Состав документации, права на код и условия дальнейшего сопровождения определяются договором под конкретный проект.
6. Кто в команде и на каком проценте занятости? Список ролей с именами полезнее, чем общее число специалистов в компании.
7. Юридическое лицо, договор и соглашение о неразглашении. Проверьте аккредитацию подрядчика в реестре аккредитованных IT-компаний Минцифры.
8. Как ведётся учёт часов? При оплате по отработанным часам у заказчика должен быть доступ к оценкам и списанному времени.
9. Возьмётся ли подрядчик за унаследованный продукт? Готовность провести аудит кода и взять чужую систему на техническую поддержку — показательный ответ.
10. Есть ли кейсы со сравнимым масштабом? Не по отрасли, а по числу ролей, интеграций и филиалов.

Типичные ошибки на стороне заказчика собраны в отдельном материале — ошибки заказчика при разработке, а как искать команду — в статье где найти хорошего разработчика. Отраслевые обзоры российского онлайн-рынка, полезные для оценки масштаба задачи, публикует Data Insight.

Кейсы: корпоративные сценарии в проектах

Корпоративные требования чаще всего появляются там, где у компании много филиалов, свои цены по городам и продажи юридическим лицам. Цифры ниже приведены со страниц кейсов.

В Gulliver Family под одной системой работают четыре бренда и пять направлений продаж: на приложение приходится 50% дохода ритейлера и 80% мобильного трафика бренда. В Finn Flare продукт работает на двух рынках — Россия и Казахстан — с мультивалютностью; после перехода на единую кодовую базу бюджет проекта оказался в 2,5 раза меньше, а скорость разработки — в 1,5 раза выше, выпуск занял около 30 рабочих дней. В «Европа Маркет» сеть гипермаркетов обслуживает 149 839 пользователей с наличием по конкретным магазинам. В DAISYKNIT переносили работающую систему со стороннего решения — клиентская база сохранилась полностью. В Alexander Bogdanov продукт обслуживает сеть из 30 монобрендовых и 200 партнёрских магазинов в 150 городах при объёме более 150 тыс. изделий в год.

Остальные проекты собраны в разделе кейсов. Смежные задачи описаны на страницах кастомных сайтов и ИИ-ассистента для сотрудников.

Итог: enterprise-разработка на одной странице

Корпоративный уровень задают требования, а не бюджет. Шесть решений, принятых до старта работ, определяют и срок, и итоговую смету:

1. Опишите процесс как он есть. Карта процесса и список работающих систем — основание для всего остального.
2. Составьте матрицу ролей и прав. Кто что видит и что может изменить — до проектирования экранов.
3. Сделайте карту интеграций. Какие данные, в какую сторону, с какой частотой и что произойдёт при сбое обмена.
4. Позовите службу безопасности на этапе требований. Позже её условия стоят переделки, а не согласования.
5. Разделите проект на очереди. Ключевой сценарий в первую, отчётность и порталы — во вторую.
6. Назначьте владельца системы. Один человек с правом принимать решения по спорным требованиям.

Команда — федеральная команда FITTIN с центром разработки в Воронеже: распределённая модель даёт эффективные ставки без потери качества. Платформа FITTIN входит в реестр российского ПО под номером 2487103.

Что делать дальше:

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

Часто задаваемые вопросы

Чем enterprise-разработка отличается от обычной разработки ПО?

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

Сколько стоит разработка корпоративной системы?

Смета зависит от семи факторов: числа ролей и глубины прав, количества интеграций и состояния методов обмена у заказчика, степени доработки учётной системы, объёма данных, требований к доступности и безопасности, числа подразделений-участников. Рыночный ориентир для полностью заказной системы — от 5 000 000 ₽ на старте. Если значительная часть сценариев типовая, дешевле выходит модульная платформа: единоразовая интеграция под бренд, ежемесячная лицензия с включённой поддержкой команды и доработки по фактически отработанным часам. Действующие цифры опубликованы на странице тарифов, ориентир под свой сценарий считает калькулятор стоимости.

Сколько времени занимает разработка корпоративного приложения?

Сумма минимальных длительностей семи шагов — около 63 рабочих дней, но по календарю проект идёт быстрее: подготовительные шаги выполняются параллельно на разных ролях, тестирование ведётся одновременно с разработкой, а готовые модули не пишутся заново. Полностью заказная система до первого выпуска обычно занимает 120–240 рабочих дней. Если часть сценариев закрывается готовыми модулями платформы, интеграция под бренд занимает до 30 рабочих дней, а уникальная логика добавляется дальше отдельными очередями. Точный срок называют после обследования систем заказчика.

Можно ли доработать существующую систему вместо разработки новой?

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

Как корпоративная система работает с 1С и другими учётными системами?

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

Чем B2B-платформа отличается от интернет-магазина?

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

Обязательно ли отечественное ПО для корпоративной системы?

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

Кто отвечает за поддержку системы после запуска?

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

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.