«Корпоративная система» — слишком широкая формулировка для оценки и выбора архитектуры. Под ней могут иметь в виду внешний кабинет клиента, внутренний портал сотрудников, автоматизацию одного процесса или специализированное рабочее место.
Эта страница остаётся навигатором: она помогает определить тип задачи и перейти к более точному направлению, не смешивая разные пользовательские сценарии в одно универсальное решение.
Если система предназначена для клиентов, дилеров или партнёров
Когда человек находится вне штата компании и должен самостоятельно работать со своими заказами, документами, статусами или заявками, задача относится к внешнему цифровому сервису.
B2B-порталы и личные кабинеты →
Там отдельно рассматриваются организации и роли, изоляция данных, внешняя авторизация, ERP/CRM/1С/API-интеграции и приёмка полного self-service сценария.
Если система предназначена для сотрудников
Когда пользователи — сотрудники компании, а задача связана с внутренними заявками, согласованиями, знаниями, коммуникациями и доступом к корпоративным сервисам, нужен другой пользовательский и доверительный контур.
Корпоративный портал для сотрудников →
В нём ключевыми становятся корпоративная идентичность, жизненный цикл доступа, подразделения и роли, внутренние данные и интеграции с действующими системами.
Если главное — маршрут, статус и правило процесса
Портал не нужен для каждого процесса. Когда ценность задачи заключается в том, чтобы формализовать этапы, ответственных, статусы, согласования, эскалации и исключения, сначала рассматривается автоматизация бизнес-процессов.
Пользовательский портал может позднее стать одним из интерфейсов такого процесса, но процессная логика не должна появляться только ради портала.
Если нужно специализированное рабочее место
Операторская система, внутренний учётный инструмент или приложение под уникальную операцию могут не быть порталом вообще.
Для таких задач основной маршрут — заказная разработка ПО: пользователи, бизнес-правила, данные, интеграции, архитектура и критерии приёмки определяются вокруг конкретного рабочего сценария.
Если новый интерфейс не нужен
Если существующие системы уже подходят пользователям, но не обмениваются данными, отдельное приложение может быть лишним. В этом случае задача относится к интеграциям и API.
Как выбрать направление
| Вопрос | На что указывает ответ |
|---|---|
| Пользователь — клиент, дилер или партнёр? | B2B-портал / личный кабинет |
| Пользователь — сотрудник и нужен общий внутренний вход? | Портал сотрудников |
| Главная проблема — статусы, правила и согласования? | Автоматизация бизнес-процессов |
| Нужен уникальный инструмент под конкретную операцию? | Заказная разработка |
| Интерфейс уже есть, но системы не обмениваются данными? | Интеграции и API |
Если в одном проекте сочетаются несколько строк, сначала определяются границы: какой контур отвечает за пользователя, где живёт процесс и какая система остаётся источником истины.
Что подготовить до первой встречи
Достаточно описать, кто основной пользователь, какое действие он должен выполнить, какие данные для этого нужны, где эти данные находятся сейчас, какие системы уже работают и какой результат должен быть проверен на первом этапе.
Не нужно заранее выбирать технологический стек или называть задачу «порталом», если пользовательский сценарий ещё не определён.
Общий вход в направление — разработка программного обеспечения. Подробнее о специализированной команде — на stdev.by.