Нельзя было достоверно определить доступность
Статус «свободно» устанавливался вручную. Таблица могла не учитывать новое резервирование, продление проживания или неподтверждённый выезд.
Корпоративный портал размещения сотрудников
Как обеспечить сотрудника жильём до его прибытия, а не после возникновения проблемы. Портал замыкает контур заявка → резерв → заселение и держит единое состояние размещения, а не набор таблиц и переписок.
Карточка проекта
Содержание
Контекст
Пятница, 16:30
Руководитель регионального подразделения сообщает HR-специалисту: в понедельник на производственную площадку выходят десять новых сотрудников. Им необходимо жильё.
HR передаёт список координатору размещения. Тот проверяет таблицу свободных мест, связывается с администраторами общежитий и вручную распределяет сотрудников по комнатам. Через несколько часов выясняется, что часть указанных мест занята людьми, которым продлили командировку. Информация о продлении осталась в переписке и не попала в общую таблицу.
Четырёх человек переводят на другой объект проживания. Обновлённый адрес получают не все. Утром один сотрудник приезжает по старому адресу, а администратор нового объекта не находит его в списке заселяемых.
Проблема заключается не в невнимательности отдельных сотрудников. Компания управляет размещением через несвязанные списки, сообщения и устные подтверждения. У процесса нет единого состояния, ответственного и обязательного следующего действия.
Клиент и граница продукта
Клиент — крупная производственно-монтажная компания, которая направляет сотрудников на временные объекты в разных регионах Беларуси.
Компания использует собственные общежития, служебные квартиры и помещения партнёрских организаций. Сотрудники приезжают индивидуально и группами, переводятся между площадками, продлевают сроки работы или уезжают раньше запланированной даты.
Портал обеспечивает жильём своих людей на период работ и не ведёт воронку сделок агентства недвижимости: не продаёт квартиры и не собирает лиды покупателей.
Система не заменяет кадровый учёт, управление недвижимостью или обслуживание зданий. Она отвечает за достоверное размещение конкретного сотрудника на конкретный период. Выбор самой производственной площадки — отдельный продукт: аренда склада и производства под технологический процесс.
Масштаб
Сотрудники с периодической потребностью700
Одновременно проживающие180–240
Объекты проживания14
Учитываемые места310
| Показатель | Значение |
|---|---|
| Сотрудники, которым периодически требуется размещение | 700 |
| Одновременно проживающие | 180–240 |
| Объекты проживания | 14 |
| Комнаты и квартиры | 96 |
| Учитываемые места | 310 |
| Новые заявки и перемещения | 110–150 в месяц |
| Координаторы размещения | 3 |
| HR-специалисты и руководители подразделений | 22 |
| Администраторы объектов | 9 |
Портал замыкает один рабочий контур: потребность в размещении → заявка → подбор места → резервирование → уведомление участников → фактическое заселение → продление, перемещение или выезд.
Как было
Информация существовала в нескольких версиях
Кадровые данные хранились во внутренней учётной системе. Свободные места — в таблице координатора. Фактически проживающие сотрудники — в списках администраторов. Заявки поступали через почту, мессенджеры и телефонные звонки.
Каждый инструмент решал локальную задачу, но ни один не показывал весь жизненный цикл размещения.
Типовой процесс
- Руководитель сообщал HR о новом сотруднике или переводе.
- HR собирал сведения и отправлял запрос координатору.
- Координатор уточнял даты и особые условия.
- Возможные места искались в таблице.
- Доступность дополнительно проверялась у администратора.
- Адрес и время заселения отправлялись сотруднику сообщением.
- Администратор отмечал прибытие в собственном списке.
- Координатор вручную обновлял общую таблицу.
- Перед окончанием срока руководитель сообщал о выезде или продлении.
- При отсутствии сообщения место могло оставаться занятым только фактически или только в таблице.
Где возникали ошибки
Заявка не имела жизненного цикла
Сообщение о необходимости жилья не превращалось в управляемую задачу. У него не было обязательного статуса, срока обработки и следующего действия.
Резерв смешивался с проживанием
Если координатор предварительно указывал место в таблице, другим пользователям было непонятно, подтверждено оно или только рассматривается.
Изменение периода нарушало следующие размещения
Продление оформлялось заменой даты или сообщением администратору. При этом место уже могло быть обещано следующему сотруднику.
Участники получали разные версии информации
Координатор, администратор и сотрудник могли видеть разные адреса, даты и номера комнат.
Отклонения обнаруживались слишком поздно
Если сотрудник не приехал, администратор мог сообщить об этом только на следующий день. Если человек не выехал, конфликт обнаруживался при прибытии следующего жильца.
Корневая проблема
Компания учитывала сотрудников и помещения, но не управляла самим размещением.
Ещё одна таблица могла сделать список аккуратнее, но не решила бы проблему пересечения периодов, временных резервов, подтверждения прибытия и контроля последующего выезда.
Поэтому центральной сущностью портала становится карточка размещения сотрудника. Она связывает:
- сотрудника;
- подразделение и инициатора;
- причину размещения;
- объект работ;
- плановый период;
- назначенное место;
- временный резерв;
- подтверждение сотрудника;
- фактическое заселение;
- продление или перемещение;
- завершение проживания;
- ответственных и историю изменений.
У каждого активного размещения должен быть текущий статус и одно понятное следующее действие.
Концепция
Корпоративный портал создаёт единую операционную среду для HR, координаторов, администраторов объектов и размещаемых сотрудников.
Портал не просто показывает свободные комнаты. Он управляет переходом от потребности в жилье к подтверждённому результату. Гражданский наём комнаты у частных жильцов — другой продукт: там рабочий центр — проект заселения в комнату с соседями, а не корпоративное общежитие и служебная квартира.
Ключевые роли
HR или руководитель
Обеспечить сотрудника жильём к нужной дате.
В портале
Создаёт заявку, указывает период и отслеживает результат.
Ограничение
Не назначает место самостоятельно.
Координатор размещения
Подобрать место без конфликтов и завершить оформление.
В портале
Обрабатывает очередь, резервирует место, управляет исключениями.
Ограничение
Отвечает сразу за несколько объектов.
Администратор объекта
Подготовить объект и подтвердить факт проживания.
В портале
Видит прибытия и выезды, фиксирует события, сообщает о проблемах.
Ограничение
Работает только со своим объектом.
Сотрудник
Получить актуальные инструкции.
В портале
Просматривает размещение, подтверждает получение, сообщает об изменении.
Ограничение
Видит только собственные данные.
Основные сущности
- сотрудник;
- заявка;
- размещение;
- объект проживания;
- помещение;
- место;
- период недоступности;
- событие истории.
Как работает новый процесс
- HR выбирает сотрудника из кадрового справочника.
- Указывает объект работ, даты и особые условия.
- Система проверяет обязательные данные.
- Заявка попадает в очередь координатора.
- Портал показывает места, доступные на весь период.
- Координатор создаёт временный резерв.
- После подтверждения место закрепляется за сотрудником.
- Сотрудник получает единую инструкцию.
- Администратор видит сотрудника в списке ожидаемых прибытий.
- В день приезда администратор подтверждает заселение.
- Перед завершением периода система создаёт задачу на выезд, продление или перемещение.
- После подтверждённого выезда место снова становится доступным.
Автоматизация отвечает за проверки и контроль переходов. Человек принимает решение, если подходящего места нет, сотрудника требуется поселить вместе с определённой бригадой или объект неожиданно становится недоступным.
Главный экран: рабочая очередь координатора
Координатору не нужен общий dashboard как основная точка входа. Его ежедневная задача — понять, какие размещения требуют действия прямо сейчас. Поэтому главным экраном становится рабочая очередь — по той же логике management by exception, что и очередь отклонений клининговой сети, только единица работы здесь — карточка размещения, а не задание на уборку.
Быстрые состояния
В верхней части показываются операционные группы:
- новые заявки — 12;
- назначить место — 7;
- резерв истекает сегодня — 3;
- прибытие не подтверждено — 4;
- оформить продление — 6;
- требуется перемещение — 2.
Рабочая таблица
Колонки: сотрудник, подразделение, объект работ, требуемый период, объект проживания, место, статус, следующее действие, срок, ответственный.
Система сортирует записи не только по дате создания. Выше поднимаются ситуации, в которых приближается важное событие, но обязательный шаг ещё не выполнен.
Панель выбранной заявки
При выборе строки справа открывается карточка с контекстом: данные сотрудника, параметры заявки, история размещений, подходящие варианты, предупреждения, комментарии, вложения и основное действие.
Если мест нет, портал не позволяет скрыть проблему произвольным назначением. Заявка получает статус «Требуется решение», а координатор видит причину.
Календарь занятости
Общее количество свободных мест не отвечает на главный вопрос координатора: доступно ли конкретное место на весь период проживания.
Экран занятости строится как календарная сетка:
- по вертикали — объекты, комнаты и места;
- по горизонтали — дни или недели;
- внутри — резервы, подтверждённые размещения и периоды недоступности;
- цвет показывает состояние;
- фильтры ограничивают город, объект, тип помещения и нужный период;
- пересечения блокируются до сохранения.
Состояния места
- свободно;
- временно зарезервировано;
- подтверждено;
- занято;
- ожидается выезд;
- недоступно;
- требует проверки.
Статус «Свободно» не устанавливается вручную. Он вычисляется на основании активных размещений и периодов недоступности.
Если координатор изменяет даты, система немедленно повторяет проверку. При конфликте показывается не общее сообщение об ошибке, а конкретное пересекающееся размещение.
Карточка размещения
Карточка становится единой историей проживания сотрудника.
Сотрудник
ФИО, подразделение, руководитель, телефон, объект работ и особые условия.
Период
Плановые и фактические даты, ожидаемое время прибытия и дата завершения.
Назначенное место
Объект, адрес, помещение, номер места и ответственный администратор.
Текущий статус
- заявка создана;
- проверяются варианты;
- место зарезервировано;
- размещение подтверждено;
- ожидается прибытие;
- сотрудник заселён;
- требуется продление;
- ожидается выезд;
- размещение завершено;
- требуется решение.
Следующее действие
Система показывает одно основное действие, исполнителя и срок:
Администратору подтвердить прибытие до 09:30.
История
Временная шкала включает создание заявки, изменение дат, резервирование, уведомления, подтверждение сотрудника, заселение, продление, перемещение и выезд.
События нельзя бесследно исправить задним числом. Изменение создаёт новую запись с автором и временем.
Мобильный сценарий сотрудника
Сотруднику не нужен сложный личный кабинет. Ему требуется компактная адаптивная страница, которая даёт адрес, место и правила заселения на период работ, а не персональную инструкцию гостя после брони на одну ночь.
На экране отображаются:
- статус размещения;
- адрес;
- дата и время прибытия;
- объект, комната и место;
- имя администратора;
- контакт для связи;
- необходимые документы;
- правила заселения;
- действие «Подтвердить получение»;
- действие «Сообщить об изменении».
Если место меняется, старая инструкция становится недействительной. Сотрудник получает новую версию и повторно подтверждает её получение.
Рабочий экран администратора объекта
Администратор видит только закреплённые за ним объекты и действия текущего дня.
Разделы списка:
- прибывают сегодня;
- должны выехать;
- ожидают продления;
- не прибыли вовремя;
- выезд не подтверждён;
- помещения временно недоступны.
Чтобы подтвердить заселение, администратор открывает запись, сверяет сотрудника и нажимает «Подтвердить прибытие».
Если человек не приехал, выбирается действие «Не прибыл». Запись автоматически попадает в очередь координатора.
Резерв не превращается в фактическое проживание без подтверждения администратора.
Бизнес-правила
Резервирование
- Место резервируется на определённый период.
- Пересекающиеся подтверждённые размещения запрещены.
- Временный резерв имеет срок действия.
- Истёкший резерв снимается или передаётся на ручную проверку.
- Изменение дат запускает повторную проверку доступности.
- Период недоступности помещения имеет приоритет над новым резервом.
Заселение
- Инструкция формируется только после подтверждения места.
- Сотрудник и администратор получают одинаковые данные.
- Факт прибытия подтверждает администратор.
- После контрольного времени неподтверждённое прибытие становится отклонением.
- Сотрудник не считается заселённым только на основании активного резерва.
Продление
- До окончания периода автоматически создаётся следующее действие.
- Продление проходит новую проверку доступности.
- Если место уже назначено другому сотруднику, система требует выбрать иной вариант.
- Изменение периода сохраняется отдельным событием.
Выезд
- После подтверждения выезда место освобождается автоматически.
- Неподтверждённый выезд получает статус «Требует проверки».
- Досрочный выезд пересчитывает доступность.
- Отмена не удаляет историю размещения.
Доступ
- HR видит сотрудников своего подразделения или зоны ответственности.
- Координатор видит объекты и заявки закреплённого региона.
- Администратор видит только свой объект.
- Сотрудник видит только собственное размещение.
- Просмотры и изменения чувствительных данных журналируются.
Ключевые сценарии
Плановое размещение одного сотрудника
HR создаёт заявку → координатор выбирает доступное место → сотрудник получает инструкцию → администратор подтверждает прибытие → размещение становится активным.
Результат: сотрудник заселён, а фактическая занятость отражена в системе.
Групповое размещение бригады
HR загружает список → портал создаёт связанные заявки → координатор подбирает места на одном или нескольких объектах → система проверяет каждого сотрудника → администратор получает единый список прибывающих.
Результат: группа размещена без потери персональных статусов.
Продление проживания
Система создаёт задачу → руководитель подтверждает новый период → портал проверяет доступность → координатор оформляет продление или перемещение.
Результат: продление не создаёт скрытого конфликта со следующим заселением.
Незаезд
Контрольное время прошло → подтверждения нет → система создаёт отклонение → координатор уточняет ситуацию → резерв сохраняется, переносится или отменяется.
Результат: место не остаётся неопределённо занятым.
Временное закрытие комнаты
Администратор указывает период недоступности → система находит затронутые размещения → координатор получает очередь переназначения → сотрудники получают обновлённые инструкции.
Результат: изменения обрабатываются до прибытия людей.
Завершение проживания
Администратор подтверждает выезд → размещение закрывается → место возвращается в доступный фонд → история сохраняется.
Результат: плановая и фактическая занятость синхронизированы.
MVP
Первая версия должна замкнуть процесс от заявки до подтверждённого освобождения места. Кадровый учёт остаётся во внешней системе: в MVP входит импорт сотрудников из кадровой выгрузки, а не замена ERP.
В первой версии
1. Авторизация и ролевая модель
2. Справочник сотрудников
3. Справочник объектов, помещений и мест
4. Создание и обработка заявок
5. Календарь занятости
6. Проверка пересечений и временные резервы
7. Карточка размещения и журнал событий
8. Рабочие очереди координатора и администратора
9. Адаптивная страница сотрудника
10. Уведомления о ключевых событиях
11. Операционные отчёты по занятости и отклонениям
12. Импорт исходных справочников
Отложено
Сложный автоматический подбор по совокупности предпочтений
Управление обслуживанием помещений
Интеграция с системой пропусков
Координация корпоративного транспорта
Прогнозирование будущей загрузки
Кабинет внешнего объекта проживания
Нативное мобильное приложение
Обработка неструктурированных заявок с помощью ИИ
ИИ не является ключевой частью MVP. Основная проблема решается едиными сущностями, правилами периодов, обязательными статусами и своевременной фиксацией фактических событий.
Стек и план
Техническая архитектура
Для первой версии используется модульный монолит. Заявки, периоды, резервы и фактическая занятость тесно связаны, поэтому их разделение на независимые сервисы только усложнило бы согласованность данных.
Client
Интерфейс основан на таблицах, фильтрах, формах и рабочих панелях; календарь занятости требует управляемого клиентского состояния. Один frontend закрывает desktop-сценарии координатора и мобильные сценарии администратора и сотрудника. PWA и offline-режим в первую версию не входят: работа предполагает стабильное подключение на корпоративных объектах.
API
Предметные блоки: сотрудники и доступ, объекты проживания, заявки, размещения, доступность и резервы, уведомления, отчёты, журнал событий. Проверка пересечений выполняется на сервере внутри транзакции: два координатора не могут одновременно закрепить одно место на пересекающиеся периоды.
Data
В базе остаются сотрудники, объекты, периоды, статусы и история событий размещения.
Queue / cache
Очереди уведомлений, фоновые задачи и кратковременные блокировки при конкурентном резервировании.
Storage
Документы и вложения заявок. В PostgreSQL остаются метаданные и права доступа.
Infrastructure
Единое окружение разработки и эксплуатации, обработка запросов и статики, восстановление данных, доступность приложения и расследование ошибок.
Интеграции первой версии: импорт сотрудников из кадровой выгрузки, email- и SMS-уведомления, экспорт операционных отчётов, корпоративная авторизация, если она уже используется заказчиком.
План на 12–14 недель
Срок подготовки и запуска MVP — 12–14 недель.
0 нед
14 нед MVP
- 2 нед1
Подготовка данных и правил
Инвентаризация объектов, помещений и мест; сверка фактически проживающих; описание статусов; определение владельцев данных; согласование правил резерва, заселения, продления и выезда; очистка справочника сотрудников.
- 2 нед2
Проектирование
Карта исходного процесса, модель жизненного цикла размещения, прототип рабочей очереди, прототип календаря, карточка размещения, тестирование исключений.
- 6–7 нед3
Разработка
Роли и доступ, справочники, заявки и размещения, резервы и календарные ограничения, рабочие очереди, мобильные сценарии, уведомления, отчёты и журналирование.
- 2 нед4
Пилот
Два объекта и одно подразделение. Проверяются соответствие системной и фактической занятости, корректность периодов, понятность статусов, скорость оформления заявки, дисциплина подтверждения прибытия и выезда, продления и уведомления. Старые таблицы временно сохраняются только для сверки.
- 1 нед5
Масштабирование
Для каждого объекта: назначить администратора, сверить занятость, загрузить структуру комнат и мест, закрыть устаревшие записи, провести обучение и перевести объект на работу через портал.
Метрики
| Метрика | Состояние до | Целевое состояние |
|---|---|---|
| Медианное время от полной заявки до подтверждения места | 1–2 рабочих дня | до 4 рабочих часов |
| Активные заявки без следующего действия | около 27% | менее 5% |
| Конфликтующие назначения одного места | 4–6 в месяц | не более 1 |
| Сотрудники без подтверждённой инструкции перед приездом | около 18% | менее 3% |
| Обнаружение неподтверждённого прибытия | до следующего рабочего дня | до 30 минут после контрольного времени |
| Подготовка отчёта о фактической занятости | около 3 часов | до 15 минут |
| Размещения с полной историей событий | около 55% | более 95% |
Как рассчитываются метрики
- Время обработки — от регистрации полной заявки до подтверждения места.
- Запись без следующего действия — активное размещение без исполнителя или срока.
- Время обнаружения незаезда — период между плановым прибытием и созданием отклонения.
- Полная история — наличие обязательных событий от создания заявки до заселения или закрытия.
- Конфликт назначения — пересечение активных размещений одного места.
Риски и выводы
Риски
| Риск | Вероятность | Влияние | Снижение |
|---|---|---|---|
| Исходная занятость не соответствует таблицам | Высокая | Высокое | Инвентаризация и подтверждение каждого активного размещения |
| Заявки продолжают поступать через сообщения | Высокая | Высокое | Единая точка регистрации и запрет подтверждения вне портала |
| Администраторы поздно отмечают события | Средняя | Высокое | Мобильный список дня, напоминания и очередь отклонений |
| Руководители передают неточные даты | Средняя | Среднее | Обязательные поля и отдельная процедура продления |
| Уведомление не доставлено сотруднику | Средняя | Среднее | Контроль доставки, повторный канал и подтверждение получения |
| Персональные данные видит лишний пользователь | Низкая | Высокое | Ролевая модель, ограничение по объектам и журнал доступа |
| Параллельный учёт создаёт несколько версий | Высокая во время пилота | Высокое | Ограниченный переходный период и формальное определение основной системы |
Развитие продукта
После стабилизации основного процесса портал можно развивать на основании накопленных данных:
- Прогнозировать загрузку объектов по планам подразделений.
- Подбирать совместное размещение для бригад.
- Управлять периодами ремонта и недоступности помещений.
- Координировать размещение с прибытием корпоративного транспорта.
- Предоставить внешним объектам ограниченный кабинет подтверждения.
- Анализировать причины незаездов, срочных перемещений и продлений.
- Извлекать данные из входящих списков с помощью ИИ и передавать результат координатору на проверку — разбор входящих списков после стабилизации процесса, а не вместо правил периодов и статусов.
Как изменилась работа
До
- свободное место определялось по строке в таблице;
- заявка существовала в переписке;
- резерв смешивался с фактическим проживанием;
- продление незаметно меняло будущую занятость;
- сотруднику отправляли несколько сообщений;
- администратор сообщал о прибытии звонком;
- выезд мог не попасть в общий учёт;
- координатор вручную искал несоответствия;
- руководитель запрашивал сводку отдельно.
После
- доступность рассчитывается на заданный период;
- у заявки есть статус, ответственный и срок;
- резерв, подтверждение и заселение разделены;
- продление проходит новую проверку;
- сотрудник получает одну актуальную инструкцию;
- факт прибытия фиксируется в карточке;
- без подтверждения система создаёт отклонение;
- портал формирует очередь проблемных ситуаций;
- состояние строится из событий процесса.
Корпоративный портал не просто переносит список сотрудников и мест в браузер. Он превращает размещение в управляемый жизненный цикл: от возникновения потребности до подтверждённого выезда.
После внедрения координатору не нужно вручную поддерживать несколько версий действительности. Портал связывает сотрудника, период, место и фактическое событие, а человеку оставляет ситуации, в которых действительно требуется решение.
Обсудить проект
Нужна разработка портала размещения сотрудников, рабочих очередей и календаря занятости, MVP на Laravel + Vue — см. разработку на Laravel. Другие концепции — в каталоге решений (раздел «Решения» в навигации выше).
