2.1 Общие сведения
Название проекта: "Автоматизированная система управления заявками на осмотр судов" (Портал "Осмотры судов")
Категория системы: "Адаптивная Web-система с элементами бизнес-аналитики"
Заказчик: (Инициатива Тазмар)
2.2 Текущая ситуация и анализ проблем
- Агенты за 72 часа до прибытия судна в порт создают заявку на вход в ПО PortCall
- Служба капитана порта получает заявку и, если судно приплывает из зарубежного порта, то отправляет список заявок в Службу контроля
- Служба контроля принимает решение о необходимости проведения осмотра подводной части судна, отправляет решение в Службу капитана порта.
- Служба капитана порта сообщает Агенту о необходимости осмотра судна
- Агент ищет Исполнителя, который сможет провести осмотр судна. Заключает с ним договор.
- Исполнитель выполняет осмотр подводной части судна и отправляет результаты осмотра в службу капитана порта
- Служба капитана порта отправляет результаты осмотра в службу контроля
- Служба контроля принимает решение о допуске судна в порт и сообщает решение Службе капитана порта
- Служба капитана порта сообщает итоговое решение о допуске судна в порт Агенту.
Существующие проблемы
- Отсутствие систематизированного процесса осмотра судов
- Высокий риск потери важной информации (заявки, результаты осмотра)
- Отсутствие истории заявок и прозрачности процесса работы с обращением Клиента на осмотр.
Текущий бизнес-процесс управления заявками представлен в нотации BPMN в Как есть сейчас: Бизнес-процесс оформления заявки на осмотр судна
Деятельность, которую хочется улучшить
- Оформление и согласование заявок;
- Составление отчетов о результатах осмотра;
- Коммуникации между заинтересованными лицами.
2.3 Цели разработки
Цели разработки системы:
- Снизить риск потерь информации и данных за счет систематизации заявок на осмотр судов💬
- Создать единый стандарт осмотра судов
Назначение системы
- Управление заявками на осмотр судов
2.4 Бизнес-требования
Постановление Правительства Российской Федерации от 25 ноября 2025 г. N 1867 “Об утверждении Правил согласования разрешения на заход следующих из иностранных портов судов в морские порты Российской Федерации с должностным лицом органа федеральной службы безопасности💬 и Правил проведения осмотра подводной части судов, прибывающих в морские порты Российской Федерации” - https://www.garant.ru/products/ipo/prime/doc/413032861/
2.5 Видение продукта
2.5.1 Функциональные модули системы
1) Справочники
Назначение: хранение справочных данных, управление
Список справочников системы:
- Порты, причалы и стоянки;
- Судна.
2) Заявки
Назначение: обработка заявок на осмотр
Функции:
- Создание, обработка и управление заявками на осмотр;
- Назначение Исполнителей;
- Планирование работ по осмотру;
- Фиксация результатов осмотра;
- Экспорт заявок;
- Прикрепление файлов в карточку Заявки.
- Генерация Актов по завершению осмотра.
3) Пользователи
Назначение: хранение данных пользователей, управление пользователями
Функции:
- Создание и управление пользователями
- Обновление данных пользователей
- Управление правами и доступами пользователей
- Настройки уведомлений
Новый бизнес-процесс управления заявками представлен в нотации BPMN Как будет: Бизнес-процесс оформления заявки на осмотр
Схема черного ящика (контекстная диаграмма) представлена в нотации C1 Контекстная диаграмма
Комментарии (8) · по состоянию на 2026-09-18
К фрагментам текста
[Ревью] Критично (MVP): качественные цели раздела 2.3 («снизить риск потерь информации», «создать единый стандарт осмотра судов») сформулированы без измеримых критериев — нет baseline, целевого показателя (%) и метода измерения. Без этого нельзя будет подтвердить достижение целей проекта.
В рамках инициативы нет конкретных измеримых показателей. Работаем пока без них
[Ревью] Не решено (принято как риск): подтверждаем, что измеримые метрики к целям раздела 2.3 (baseline, целевой %, способ измерения) сознательно не вводятся в рамках текущей инициативы. Фиксируем это как осознанно принятое решение/риск, не блокирующий MVP — вопрос остаётся открытым на будущее.
[Ревью] Пока актуально: цели/показатели раздела 2.3 не имеют измеримых метрик (baseline, целевой %, метод измерения). Новая страница решений (id 73075569) этот вопрос не закрывает — метрики к целям там не упомянуты. Оставляем как принятый риск для MVP, актуально для послед. этапов.
[Ревью] Критично (вне MVP, но важно для понимания): в п.2.2 фигурирует актор «Служба контроля», а в нормативной ссылке (п.2.4) и на диаграммах — «Федеральная служба безопасности». Не ясно, это одна и та же роль (переименование) или разные сущности — есть риск создать в системе две разные роли вместо одной.
Это одно и то же
[Ревью] Решено, спасибо — подтверждено, что «Служба контроля» и «федеральная служба безопасности» это одна и та же сущность, риска создания двух разных ролей нет.
[Ревью] РЕШЕНО — можно удалить. Подтверждено: «Служба контроля» и «федеральная служба безопасности» — одна и та же сущность, риск дублирования ролей снят.