Проект «Компас»

У каждого решения есть предмет рассмотрения. Смена дат возвращает заявку к нужному шагу, сохраняя прежнюю историю.

Демонстрационный проект 404gen: интерфейс, модель процесса и решения на примере. Клиентское внедрение и показатели бизнеса здесь не заявляются.

О проекте

• Задача: Согласование намерения поездки
• Основание решения: Версия дат, состава и цели
• Роли: Автор, согласующий и координатор

Задача

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

Проект посвящён маршруту решений и истории версий. Расчёты выплат, обязательные документы и учётные правила в демонстрацию не включены.

Риски исходного процесса

Ответ относится к старым датам

Снимок рассмотрения проверяется перед действием.

Неясно, у кого следующий шаг

Текущий ответственный виден в маршруте.

Изменение затёрло прошлое

Предыдущая версия и решение остаются в истории.

Решение

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

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

Как устроен продукт

1. Карточка поездки. Цель, участники, даты и состояние сведений. Зачем: Решение опирается на содержимое заявки.
2. Сравнение версий. Выделены значимые изменённые условия. Зачем: Новая дата не скрывается в общей форме.
3. Маршрут решений. Роли и текущая точка ожидания. Зачем: Понятно, кто продолжает процесс.
4. История рассмотрения. Ответ, версия и фактический исполнитель. Зачем: Результат не теряет основание после замещения.

Что помогает пройти сценарий

Версия решения

Согласование относится к одному снимку.

Повтор рассмотрения

Смена дат возвращает заявку к актуальному шагу.

Защита старой ссылки

Устаревший ответ не применяется к новым условиям.

Ключевые сценарии

Согласовать поездку

Решение привязано к прочитанной версии дат.

На входе: Открыта заявка v1; решений ещё нет.

1. Прочитать текущие даты поездки.
2. Согласовать просмотренную версию.
3. Проверить историю решений.

На выходе: В истории есть решение по v1.

Если что-то пошло не так: Повторное согласование той же версии недоступно.

Критерий приёмки: Запись решения содержит номер рассмотренной версии.

Изменить даты

Новый состав поездки не наследует согласование старого.

На входе: Версия v1 согласована и остаётся открытой у согласующего.

1. Изменить даты заявки.
2. Сравнить текущую и просмотренную версии.
3. Проверить доступность согласования старого просмотра.

На выходе: Текущая версия v2 ожидает рассмотрения; решение v1 сохранено.

Если что-то пошло не так: Ответ по открытому устаревшему снимку блокируется.

Критерий приёмки: У v2 нет чужого согласования, а история v1 не исчезла.

Рассмотреть изменения

Актуальные условия открываются до повторного решения.

На входе: Заявка стала v2, согласующий ещё видит v1.

1. Открыть актуальную версию.
2. Прочитать изменённые условия.
3. Согласовать v2 и проверить историю.

На выходе: Есть два отдельных решения: по v1 и по v2.

Если что-то пошло не так: Обновление просмотра само по себе не означает согласование.

Критерий приёмки: Решение v2 появляется только после отдельного действия пользователя.

Роли пользователей

Сотрудник

Подать достаточные сведения и понять следующий шаг.

Что нужно уточнить перед рассмотрением?

Согласующий

Прочитать условия и последствия своего ответа.

Эту ли версию я сейчас согласовываю?

Координатор

Продолжить организацию на актуальном основании.

Что изменилось после предыдущего решения?

Как устроено технически

Версионная модель

Содержательные изменения отделены от технических правок.

Права и замещение

Проверяются актуальные полномочия действующего пользователя.

Передача событий

Календарь и другие системы получают согласованную версию.

Что входит в разработку

• Одна заявка с датами
• Решение по исходной версии
• Изменение значимого условия
• Сравнение и защита устаревшего просмотра
• Журнал рассмотрения

План реализации

1. Описать действующий маршрут и владельца правил.
2. Определить значимые поля и повторное рассмотрение.
3. Проверить смену условий на прототипе.
4. Подключить оргконтекст, календарь и учётные процессы.
5. Провести пилот с изменениями и замещениями.

Что замеряем после запуска

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

Стек

Версионная модель, Права и замещение, Передача событий.

Все кейсы · Услуга · Калькулятор стоимости

Интерфейс и устройство процесса

Визуализация, схема и локальная демонстрация показывают разные стороны решения. Внешние системы не подключены.