HR-координатор
Контролирует календарь, формирует заказы, обрабатывает исключения и отслеживает доставку.
Ограничение
Видит только данные, необходимые для организации поздравления.
Кейс: Портал заказа цветов и подарков сотрудникам
Закрытый HR-портал, где единица работы — карточка поздравления, а не витрина букетов. Контур замыкается от календарного события сотрудника до подтверждённого вручения.
Карточка проекта
Содержание
Отрасль и клиент
Рынок и задача
Клиент — компания с головным офисом и региональными подразделениями в Беларуси. За поздравления с днями рождения, юбилеями работы, рождением ребёнка и профессиональными достижениями отвечает HR-координатор. Это не заявка, резерв и заселение сотрудников: там единица работы — койка на период объекта, здесь — поздравление к календарной дате.
Каждое утро координатор сверяет календарь с кадровой выгрузкой, уточняет у руководителей формат, выбирает композицию или подарок, передаёт данные поставщику и отдельно контролирует доставку. В спокойные дни процесс выглядит управляемым. Проблемы начинаются при совпадении нескольких событий, смене адреса, отсутствии позиции или переносе вручения.
Портал не заменяет кадровую систему и не продаёт цветы рознице. Он превращает подтверждённый повод в контролируемый заказ: от автоматического черновика до фиксации результата.
Масштаб первой версии
Сотрудники~900
Офисы6
Заказы70–120 / мес.
Пик доставок30–40 / день
| Показатель | Значение |
|---|---|
| География | Беларусь, 6 городов |
| Сотрудники | ~900 |
| Заказы поздравлений | 70–120 в месяц |
| Пиковая нагрузка | до 30–40 вручений в один день |
| Основные поводы | день рождения, юбилей работы, рождение ребёнка, профессиональное достижение |
| Варианты вручения | в офисе, по домашнему адресу, через представителя подразделения |
| Контур пилота | один офис, ограниченный набор поводов, один поставщик |
| Основной процесс | От кадрового события до подтверждённого вручения |
Нужен не корпоративный интернет-магазин, а операционный портал вокруг календаря событий и карточки заказа.
Роли
Руководитель подразделения
Подтверждает повод, выбирает формат и согласует текст открытки.
Ограничение
Не видит личные адреса и события других подразделений.
Сотрудник
Заранее указывает допустимый способ вручения и поддерживает адрес в актуальном состоянии.
Ограничение
Не видит готовящиеся для него поздравления.
Представитель поставщика
Подтверждает заказ, сообщает о замене, меняет статус исполнения и прикладывает подтверждение.
Ограничение
Получает доступ только к переданным ему заказам.
Как было
Поздравление жило в таблице и почте
В начале месяца координатор выгружал даты из кадровой системы и переносил их в отдельную таблицу: сотрудник, подразделение, предполагаемый подарок, ответственный руководитель. Дальше процесс шёл вручную — через письма, сообщения и повторные сверки.
Восемь шагов без единой карточки
- Координатор проверял, работает ли сотрудник в нужную дату и в каком офисе он будет находиться.
- Руководитель подразделения подтверждал повод и выбирал текст поздравления.
- Адрес доставки уточнялся в переписке.
- Вариант подарка выбирался из присланного поставщиком каталога.
- Состав заказа копировался в письмо.
- Поставщик подтверждал наличие и временной интервал.
- Изменения возвращались в переписку и вручную переносились в таблицу.
- После доставки координатор запрашивал подтверждение и отмечал заказ выполненным.
Корневая проблема
Главная ошибка возникала не на этапе выбора букета. Она появлялась на переходах между участниками. Руководитель подтверждал заказ в одном канале, поставщик предлагал замену в другом, а в таблице оставалась первоначальная версия. Координатору приходилось вручную восстанавливать состояние: что согласовано, где доставка, кто должен ответить и не изменился ли адрес.
Ещё одна таблица делает список аккуратнее, но не управляет жизненным циклом. Для каждого поздравления одновременно нужны актуальность кадрового события, место и интервал вручения, ограничения получателя, состав, текст открытки, подтверждение поставщика, допустимые замены, состояние доставки, история и следующее действие.
Центральная сущность продукта — не корзина цветов, а карточка поздравления.
Решение
Карточка объединяет повод, получателя, заказ и доставку в одной истории со статусом и обязательным следующим действием. Карточка, а не витрина, ведёт процесс и в магазине инструментов для груминга: там сохранённый рабочий комплект до заказа.
Она создаётся автоматически из подтверждённого события или вручную для непланового повода. Внутри — сотрудник и подразделение, тип и дата, инициатор, способ и адрес вручения, состав, текст открытки, интервал, допустимые замены, статус, комментарии, история, подтверждение вручения и следующее действие.
Заказ не считается готовым к передаче поставщику, пока не заполнены обязательные поля. Система показывает не абстрактную ошибку, а конкретный шаг: уточнить адрес, выбрать замену, согласовать текст или подтвердить время.
Это не розничный контур среза: учёт свежести в цветочном ритейле закрывает уценку и списания витрины. Здесь каталог существует только как доступные позиции для города и даты внутри корпоративной карточки. Розничный самовывоз из зоомагазина — другой контур: покупатель сам оформляет заказ и подтверждает замену.
Как работает новый процесс
- Система получает кадровое событие и проверяет, нет ли уже созданной карточки.
- HR-координатор видит новый черновик в рабочей очереди.
- Портал подставляет подразделение, город, допустимый способ вручения и стандартный сценарий.
- Руководитель получает запрос на подтверждение и выбирает текст открытки.
- Координатор выбирает доступную композицию и дополнительный подарок.
- Система проверяет обязательные поля и переводит карточку в состояние «Готово к заказу».
- Заказ передаётся поставщику в структурированном виде.
- Поставщик подтверждает наличие или предлагает замену.
- После согласования заказ переходит в исполнение.
- В день события портал контролирует интервал и выделяет отклонения.
- После вручения поставщик фиксирует результат и при необходимости прикладывает фотографию.
- Карточка закрывается, история остаётся для внутреннего контроля.
Координатор больше не просматривает все заказы подряд. Он работает только с очередью карточек, в которых требуется решение человека.
Основные сценарии
Плановое поздравление
Система создаёт карточку из кадрового события. Координатор проверяет данные, руководитель подтверждает формат, заказ уходит поставщику.
Результат: готовое поздравление с интервалом вручения и ответственным исполнителем.
Неплановое событие
Руководитель вручную создаёт запрос, выбирает сотрудника и указывает повод. Координатор проверяет запрос и запускает стандартный процесс.
Результат: неплановое поздравление проходит те же правила и не остаётся в личной переписке.
Изменение места вручения
Если сотрудник изменил способ получения до передачи заказа, портал обновляет карточку и повторно проверяет доступность позиций. После подтверждения поставщика изменение становится исключением.
Результат: адрес не «теряется» в чате, а проходит повторную проверку.
Замена отсутствующей позиции
Поставщик отмечает отсутствие и предлагает допустимые варианты. Эквивалентная замена подтверждается координатором одним действием; существенное изменение возвращается руководителю.
Результат: в карточке остаётся согласованная версия состава, а не сообщение «поставим похожее».
Проблема при доставке
Поставщик переводит заказ в статус «Не удалось вручить» и указывает причину. Карточка сразу появляется в очереди отклонений. Координатор выбирает новое время, другого получателя в офисе или отмену.
Результат: отклонение видно в рабочее время, а не после ручного запроса.
Карточка дня рождения сотрудника — не карточка свадебной флористики: там смета зон оформления и монтаж на площадке, здесь — закрытый HR-контур к дате сотрудника.
Главный экран: очередь ближайших поздравлений
Основной экран — не аналитическая панель, а рабочая очередь. Координатору нужно понимать, какой заказ требует действия сейчас. Это тот же принцип management by exception, что и очередь отклонений клининговой сети, только единица работы здесь — карточка поздравления, а не задание на уборку.
В верхней части — переключатели «Сегодня», «Ближайшие 7 дней», «Месяц». Ниже — фильтры по офису, подразделению, поводу, поставщику и статусу.
Карточки группируются по смыслу: нужно уточнить данные; ожидается подтверждение руководителя; готово к передаче; требуется согласовать замену; сегодня в доставке; есть отклонение; завершено.
В строке видны сотрудник, повод, дата, город, состав, интервал, статус и следующее действие. Просрочка считается относительно даты события и текущего этапа. Если процесс идёт по плану, карточка остаётся компактной; при отклонении строка раскрывает причину и доступные действия.
Карточка как единое рабочее пространство
Карточка открывается поверх очереди или на отдельной странице и отвечает на четыре вопроса: кого поздравляют, что согласовано, что происходит с доставкой, кто и что должен сделать дальше.
Слева — событие и получатель. В центре — состав, открытка и параметры доставки. Справа — статус, следующее действие и таймлайн.
При выборе подарка координатор видит только позиции, доступные для города и даты. Состав не меняется после подтверждения поставщика без новой версии. Текст открытки хранится внутри карточки: руководитель выбирает шаблон, правит и подтверждает. После передачи поставщику правки текста требуют повторного согласования.
Личные данные отделены от общих сведений. Руководитель видит город и способ вручения, но не домашний адрес. Полный адрес открывается координатору и поставщику после перевода заказа в исполнение.
Доставка внутри карточки — статус интервала и фото результата, а не маршрутизация службы последней мили: трекинг и фото вручения курьерской доставки закрывают сеть курьеров, здесь поставщик фиксирует исход конкретного поздравления.
Бизнес-правила
- На одно подтверждённое событие одного сотрудника создаётся только одна активная карточка.
- Карточка не передаётся поставщику без получателя, города, даты, интервала, состава и согласованного текста.
- Домашний адрес используется только при выбранном сотрудником способе вручения.
- Поставщик получает личные данные только после подтверждения заказа.
- Изменение состава после подтверждения создаёт новую версию.
- Заказы с истекающим сроком автоматически поднимаются выше в очереди.
- Разрешённая замена не меняет тип подарка и не нарушает ограничения получателя.
- Фотография вручения не обязательна, если сотрудник запретил такую фиксацию.
- Закрытый заказ нельзя редактировать: исправление оформляется отдельной записью в журнале.
- Уведомления не заменяют рабочую очередь: они сообщают о срочных исключениях, состояние хранится в портале.
MVP
Первая версия замыкает один процесс: кадровое событие → подготовка поздравления → передача поставщику → контроль доставки → подтверждение результата. События импортируются из структурированного файла. Заказы уходят поставщику через защищённый кабинет или формируемое системой письмо — так процесс проверяется до дорогих двусторонних интеграций.
В первой версии
Пользователи, роли и разграничение доступа
Импорт сотрудников и событий
Календарь поздравлений
Рабочая очередь координатора
Карточка поздравления
Каталог доступных цветов и подарков
Согласование текста и состава
Структурированная передача заказа поставщику
Статусы доставки и обработка исключений
Уведомления в портале и по электронной почте
Журнал изменений
Выгрузка операционного отчёта
Осознанно отложено
Несколько поставщиков с правилами распределения
Массовые праздничные кампании
Автоматическая маршрутизация доставок
Отдельное мобильное приложение
Генерация поздравительных текстов
Углублённая аналитика по подразделениям
Полноценный двусторонний обмен с кадровой системой и системами поставщиков
UX, стек и план
Очередь вместо витрины
Ценность создаётся после того, как повод уже известен. Координатор возвращается в очередь и видит просрочки, замены и одно следующее действие. Каталог открывается внутри карточки, а не как отдельный магазин.
Архитектура
Выбран профиль компактной операционной B2B-системы: закрытый портал, единый контур авторизации, без отдельного frontend-сервиса и публичного API.
Client
Очередь, фильтры, календарь и карточка обновляются без полной перезагрузки. Vue закрывает формы и группировку статусов; Inertia сохраняет единый репозиторий и серверную маршрутизацию Laravel.
API
Модули: пользователи и оргструктура, сотрудники и события, каталог, карточки поздравлений, согласования, заказы и доставки, уведомления, интеграции, журнал аудита. Все бизнес-правила живут в Laravel, чтобы интерфейс координатора, кабинет руководителя и зона поставщика не расходились.
Data
Сотрудники, события, версии заказов, статусы, история действий и ограничения доступа. Индексы и встроенный полнотекст закрывают поиск по сотрудникам, подразделениям и заказам без отдельного поискового движка.
Queue
Импорт событий, создание запланированных карточек, рассылка и формирование отчётов идут через Jobs с очередью в PostgreSQL. При нагрузке в несколько сотен операций в месяц Redis и Horizon в первую версию не входят.
Storage
Файлы доступны только авторизованным пользователям с подходящей ролью. В PostgreSQL остаются метаданные и права.
Infrastructure
Один сервер с веб-приложением, планировщиком и отдельным worker. PostgreSQL и файловое хранилище входят в регламент копирования. Pest покрывает создание карточек, дедупликацию событий, переходы статусов, доступ к личным данным и замены. Playwright проверяет создание заказа, согласование, подтверждение поставщиком и завершение доставки.
На первом этапе сознательно не используются микросервисы, Redis, WebSocket, отдельный поисковый движок и Kubernetes: предметный контур связан, статусы не требуют постоянного соединения, нагрузка MVP укладывается в один экземпляр.
План на 12–14 недель
Срок разработки и пилота — 12–14 недель. Внедрение идёт вокруг одного офиса и ограниченного набора поводов, затем параллельная сверка со старой таблицей и масштабирование.
0 нед
14 нед пилот
- 2 нед1
Анализ процесса и прототипирование
Типы событий, обязательные поля, статусы, правила доступа и сценарии исключений. Отдельно фиксируется, какие сведения можно передавать поставщику и на каком этапе.
- 2 нед2
Проектирование интерфейсов и модели данных
Очередь, карточка, кабинет руководителя и зона поставщика. Проверяются кадровые записи, названия подразделений, города, даты и предпочтения по вручению; дубли и устаревшие адреса убираются до первого импорта.
- 6–7 нед3
Разработка первой версии
Роли, импорт, календарь, очередь, карточка, каталог, согласования, передача заказа, статусы доставки, уведомления и журнал.
- 2 нед4
Тестирование и подготовка данных
Pest и Playwright по критическим маршрутам, сверка импорта, обучение координатора и поставщика на пилотном офисе.
- 2–3 нед5
Пилот и стабилизация
Один офис и ограниченный набор поводов: календарь, согласования, работа поставщика, неудачная доставка. Короткий период параллельной сверки с таблицей, затем таблица только для контроля полноты переноса. После стабилизации статусов подключаются остальные подразделения.
Метрики
Цифры — результаты пилота: сопоставимые заказы за период до запуска и после стабилизации процесса в одном офисе. Измерение строится по журналу событий портала: для каждого заказа видны время создания, длительность этапов, возвраты на уточнение, число изменений и момент обнаружения отклонения.
| Метрика | Состояние до | Стало в пилоте | Как измеряется |
|---|---|---|---|
| Время подготовки ежедневного списка | 30–40 минут | не более 10 минут | От открытия рабочего дня до готовой очереди ближайших поздравлений |
| Заказы без явно указанного следующего действия | около 20% | менее 3% | Доля активных карточек без исполнителя или срока обязательного шага |
| Карточки с поздним уточнением адреса | около 15% | менее 5% | Адрес изменён после перевода в «Готово к заказу» или уже у поставщика |
| Пропущенные или поздно обнаруженные события | около 7% | менее 2% | Повод появился в очереди позже правила типа события и города |
| Повторный ввод одних и тех же данных | 3–5 операций на заказ | не более одной | Копирование состава, адреса и текста между таблицей, почтой и каталогом поставщика |
| Обнаружение отклонения доставки | после ручного запроса | в течение 15 минут после фиксации статуса | От отметки поставщика до появления карточки в очереди отклонений |
| Полные карточки перед передачей поставщику | около 75% | более 98% | Обязательные поля заполнены до статуса «Готово к заказу» |
Риски и выводы
Риски
| Риск | Вероятность | Влияние | Снижение |
|---|---|---|---|
| Устаревшие кадровые данные | Средняя | Высокое | Проверка импорта, отчёт о неполных записях, назначение ответственного |
| Сотрудники не обновляют адреса | Высокая | Среднее | Периодическое подтверждение профиля и офисная доставка по умолчанию |
| Руководители поздно согласовывают поздравления | Средняя | Среднее | Срок ответа, напоминание и стандартный сценарий при отсутствии решения |
| Поставщик не обновляет статусы | Средняя | Высокое | Простой кабинет, обязательные контрольные статусы и пилотный регламент |
| Избыточный доступ к личным данным | Низкая | Высокое | Ролевой доступ, скрытие адреса, журнал просмотра и ограниченный срок хранения |
| Сотрудники продолжают вести параллельные таблицы | Средняя | Среднее | Короткий переходный период и портал как единый источник состояния |
| Каталог не отражает фактическую доступность | Средняя | Среднее | Дата актуальности, подтверждение поставщика и управляемый сценарий замены |
Как изменилась работа
До
- календарь жил в выгрузке и таблице;
- руководитель подтверждал повод в переписке;
- адрес уточнялся отдельными сообщениями;
- состав копировался в письмо поставщику;
- замена оставалась в одном канале, таблица — в другом;
- статус доставки запрашивался вручную;
- координатор восстанавливал состояние каждого заказа.
После
- повод становится карточкой с владельцем и сроком;
- руководитель отвечает только за содержание поздравления;
- адрес и способ вручения живут в карточке;
- поставщик получает структурированный заказ;
- замена создаёт версию с автором;
- отклонение доставки поднимается в очередь;
- координатор разбирает исключения, а не все заказы подряд.
Главный результат — не цифровой каталог цветов, а предсказуемый корпоративный процесс. Компания сохраняет человеческий характер поздравления, но убирает зависимость от памяти координатора, разрозненной переписки и ручного восстановления событий.
Обсудить проект
Нужен похожий контур — обсудим. Услуги на Laravel · Каталог решений.
