Анализ требований
Приложение: Таск менеджер
Потребители:
- Горничные (хаускипинг)
- Техническая (инженерная) служба
- ИТ служба
- Ресторанная служба
- Ресепшен
- Хаусмены
- Менеджеры по продажам
Прогнозируемое количество пользователей: 20-50 на отель
Проблемы и требования:
Проблема 1: Отсутствие единой системы для передачи задач между подразделениями
AS-IS (как есть):
- Ресепшен выступает посредником между всеми службами
- Передача задач через звонки и мессенджеры (WhatsApp)
- Информация может теряться, забываться
- Ресепшен перегружен, особенно в часы пик (например, при заезде группы)
TO-BE (как должно быть):
- Автоматизированная система для передачи задач
- Каждое подразделение имеет прямой доступ к системе
- Возможность создать задачу и передать ее напрямую нужному подразделению
- Ресепшен убирается как обязательный источник синхронизации
Базовый функционал (MVP):
- Создание задачи
- Передача задачи нужному подразделению
- Принятие задачи исполнителем
- Отметка о выполнении
- Возможность создать встречную задачу (если требуется)
Проблема 2: Невозможность документировать выполнение задач с помощью фото/видео
AS-IS:
- Фотографии отправляются через мессенджеры (WhatsApp)
- Нет централизованного хранения
- Сложно найти историю выполненных работ
TO-BE:
- Возможность прикрепления фотографий к задаче
- Применимо для всех служб:
- Горничные: фото до и после уборки
- Техническая служба: фото выполненного ремонта (труба, унитаз и т.д.)
- ИТ служба: фото расставленного оборудования
- Возможность показать результат заказчику
- Фиксация состояния объекта
Требование: Возможность прикрепления файлов и фотографий к задачам
Проблема 3: Сложность ввода информации в процессе работы
AS-IS:
- Много времени тратится на набор текста
- Сотрудники вынуждены писать длинные сообщения
TO-BE:
- Голосовой ввод с автоматической транскрипцией в текст
- Ускорение процесса создания и комментирования задач
Требование: Интеграция системы распознавания речи (голосовые сообщения → текст) Примечание: Потребуется использование платных сервисов (западных или отечественных)
Проблема 4: Отсутствие автоматизации повторяющихся задач
AS-IS:
- Регулярные задачи (раз в неделю, месяц) создаются вручную каждый раз
TO-BE:
- Автоматическое создание периодических задач по расписанию
- Применимо для:
- Горничных (регулярная уборка определенных зон)
- Технической службы (плановое обслуживание оборудования)
Требование: Функционал создания регулярных задач с настройкой расписания
Проблема 5: Отсутствие учета расходных материалов
AS-IS:
- Информация о материалах не фиксируется нигде
- Невозможно отследить остатки и планировать закупки
- Не хранится в других системах (в PMS такой информации нет)
TO-BE:
- Складской модуль внутри системы
- Учет материалов по службам:
- Горничные: полотенца (разных видов), косметика
- Техническая служба: лампочки, расходники
- Первоначальный ввод остатков
- Списание при выполнении задач
- Понимание объемов работы (например, работы прачки)
Требование: Модуль учета материалов Примечание: Это НЕ MVP, но важная часть. Может использоваться не только в Таск менеджере.
Приложение: Модуль управления мероприятиями (Events Management)
Потребители:
- Менеджеры по продажам
- Служба хаусменов
- ИТ служба
- Ресторанная служба
- Инженерная служба
Проблемы и требования:
Проблема 6: Неэффективное управление задачами для мероприятий
AS-IS:
- Менеджер по продажам вручную составляет "фанкшн" или "меморандум" (Word документ)
- В документе описываются все задачи для разных служб:
- Застройка зала (расстановка столов, стульев)
- Предоставление оборудования (проектор, экран)
- Организация кофе-брейка
- Перестройка зала
- Документ рассылается службам
- Задачи могут быть упущены или не замечены
- Отсутствует единый контроль выполнения
TO-BE:
- Менеджер описывает мероприятие в системе один раз
- Система автоматически создает задачи для каждой службы
- Автоматическая генерация "фанкшн"
- Все задачи отслеживаются в единой системе
- Массовое создание связанных задач для разных подразделений
Требование:
- Возможность массового создания задач (bulk task creation)
- Описание мероприятия с автоматической декомпозицией на задачи
- Привязка задач к конференц-залам и времени
- Формирование документа "фанкшн" на основе введенных данных
Примечание: Функционал, который можно продавать отдельным модулем. Пока не решен полноценно ни одной существующей системой.
Приложение: Горничные (расширенный модуль для Таск менеджера)
Потребители:
- Горничные
Проблемы и требования:
Проблема 7: Отсутствие контроля процесса уборки номеров
AS-IS:
- Горничная получает распечатку номеров из PMS
- Выполняет уборку
- Сообщает о завершении устно или через мессенджер
- Нет фиксации времени начала/окончания уборки
- Нет фото-подтверждения качества
TO-BE:
- Горничная видит номер в приложении
- Нажимает "Начать уборку"
- Фотографирует номер до уборки
- Выполняет уборку
- Фотографирует номер после уборки
- Отмечает завершение
Требование: Специализированный интерфейс для горничных с пошаговым процессом уборки и обязательным фотографированием
Приложение: Интерфейс для гостей (Guest Interface)
Потребители:
- Гости отеля
Проблемы и требования:
Проблема 8: Перегрузка ресепшена запросами от гостей
AS-IS:
- Гость звонит на ресепшен с запросом (принести халат, тапочки и т.д.)
- Ресепшен записывает запрос
- Ресепшен создает задачу в Таск менеджере или пишет в WhatsApp
- При большой загрузке (заезд группы):
- Трубки не берутся
- Запросы забываются
- Теряется информация о номере
TO-BE:
- Гость самостоятельно создает запрос через:
- Telegram-бота
- Готовый консьерж-сервис
- Другой интерфейс
- Базовые услуги доступны по кнопкам (принести халат, тапочки и т.д.)
- Возможна интеграция с AI для обработки свободных запросов
- Задача автоматически попадает нужному подразделению
- Ресепшен разгружается
Требование:
- Интерфейс для гостей (бот/веб-приложение)
- Набор базовых услуг с кнопками
- Автоматическое создание задач в Таск менеджере
- Опционально: интеграция с AI для обработки текстовых запросов
Примечание: Может быть интеграцией с существующим консьерж-сервисом, который нужно будет доработать
Общие требования к архитектуре:
- Модульная структура: Возможность продажи отдельных модулей
- Базовый функционал может быть бесплатным: Freemium-модель для привлечения пользователей
- Единая точка доступа: Все службы работают в одном приложении, а не в разных мессенджерах
- Масштабируемость: Архитектура должна поддерживать добавление новых модулей
Список всех подразделений (требуется уточнить полный список):
- Хаускипинг (горничные)
- Техническая (инженерная) служба
- ИТ служба
- Ресторанная служба
- Ресепшен
- Хаусмены
- Служба консьержа
- Прачечная
Следующие шаги:
- Уточнить полный список подразделений
- Детализировать требования для каждого подразделения
- Определить приоритеты функций (MVP vs расширенный функционал)
- Создать архитектуру с учетом модульности
- Получить доступ к тестовой среде существующих систем