Внутреннее приложение для заявок и согласований

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

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

Выберите один вид заявок

Возьмите процесс с понятным окончанием. Заявка на оборудование заканчивается согласованием или отказом; закупка и выдача устройства могут стать отдельными этапами позже. Если сразу объединить закупки, отпуска и служебные поездки, у формы появятся несовместимые поля и правила.

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

Первые примеры заполните вымышленными данными. Проверять структуру можно на записи «Монитор для учебного рабочего места» без реальных фамилий и документов.

Разделите роли и действия

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

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

Задайте статусы и условия перехода

Для учебного процесса подойдут статусы «Черновик», «На согласовании», «Согласована», «Отклонена» и «Выполнена». Важны условия перехода: например, отклонение требует комментария, а выполненной может стать только согласованная заявка.

Составьте короткий список запретов. Автор не должен переводить обращение в «Согласована». Повторное нажатие не создаёт ещё одну заявку. Изменение суммы после согласования должно либо отправлять запись на повторное рассмотрение, либо быть запрещено. Выберите одно правило заранее.

История решений пригодится при споре: кто изменил статус, когда и с каким объяснением. Наличие красивой ленты событий в интерфейсе проверьте повторным открытием карточки и другим аккаунтом.

Подготовьте задание для конструктора

Создай внутреннее веб-приложение для согласования заявок на оборудование.

Роли: автор заявки, согласующий руководитель, исполнитель.
Поля: номер, название оборудования, обоснование, сумма, автор,
согласующий, дата создания, статус, комментарий решения.
Статусы: Черновик, На согласовании, Согласована, Отклонена, Выполнена.

Экраны: мои заявки, заявки на согласование, карточка и форма.
Автор может редактировать только свой черновик и отправить его на рассмотрение.
Согласующий принимает или отклоняет назначенную заявку.
При отклонении комментарий обязателен.
Исполнитель отмечает выполнение согласованной заявки.
Записывай историю смены статуса и показывай текущего ответственного.

Используй вымышленные учебные записи. Не подключай почту, платежи и рассылки.
Проверь права на сервере, а не только видимость кнопок.
Если сохранение, роли или история пока не реализованы, явно сообщи об этом.

В Mottorable можно начать со сценария создания внутреннего сервиса. После генерации пройдите один маршрут целиком, затем добавляйте исключения. Общая подготовка задания разобрана в гайде по созданию веб-приложения.

Проверьте доступ двумя аккаунтами

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

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

Проверьте также одновременную работу: два согласующих открыли одну карточку и приняли разные решения. Приложение должно объяснить конфликт и показать фактическое состояние записи.

Запустите пилот и соберите обращения

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

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

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