vigdorov/hotel-analysis
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
749c2b4e95046851d502193c956872b119854abc
hotel-analysis/Анализ требований.md

13 KiB
Raw Blame History

Назад

Анализ требований

Приложение: Таск менеджер

Потребители:

  • Горничные (хаускипинг)
  • Техническая (инженерная) служба
  • ИТ служба
  • Ресторанная служба
  • Ресепшен
  • Хаусмены
  • Менеджеры по продажам

Прогнозируемое количество пользователей: 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 для обработки текстовых запросов

Примечание: Может быть интеграцией с существующим консьерж-сервисом, который нужно будет доработать

Общие требования к архитектуре:

  1. Модульная структура: Возможность продажи отдельных модулей
  2. Базовый функционал может быть бесплатным: Freemium-модель для привлечения пользователей
  3. Единая точка доступа: Все службы работают в одном приложении, а не в разных мессенджерах
  4. Масштабируемость: Архитектура должна поддерживать добавление новых модулей

Список всех подразделений (требуется уточнить полный список):

  • Хаускипинг (горничные)
  • Техническая (инженерная) служба
  • ИТ служба
  • Ресторанная служба
  • Ресепшен
  • Хаусмены
  • Служба консьержа
  • Прачечная

Следующие шаги:

  1. Уточнить полный список подразделений
  2. Детализировать требования для каждого подразделения
  3. Определить приоритеты функций (MVP vs расширенный функционал)
  4. Создать архитектуру с учетом модульности
  5. Получить доступ к тестовой среде существующих систем