Какие продукты может предложть своим клиентам управляющая компания или застройщик
Что и для кого?
Предметная область
Продукт: Диспетчерская - обслуживание жильцов
Бизнес-процесс: Управление заявками клиентов
Провайдер сервиса: Управляющая (недвижимостью) компания
Возможный стейкхолдер: Крупный застройщик с большими обёмами
Подрядчик: Вендор специализированного отраслевого промышленного решения
Целевое решение: Диспетчерская как облачный сервис
Интеграции: Внутренние ИС, в том числе, КХД
Цели
Улучшение качества обслуживания клиентов (собственники и арендаторы жилых и торговых помещений)
Повышение эффективности работы сотрудников (диспетчеры и инженеры)
Улучшение бизнес-метрик и показателей
Обеспечение прозрачности и управляемости бизнес-процессов и финансовых показателей
Сокращение издержек на эксплуатацию, поддержку и развитие информационной системы
Оптимизация продуктовых показателей и метрик
- product market fit
- time to market
- adoption
- mau\dau
- etc
Использование отраслевой экспертизы и синергетического эффекта
Высвобождение IT и продуктовых ресурсов и экспертизы для развития перспективных направлений:
- Застройщик.Ремонт - сервис и маркетплейс по первичному и текущему ремонту и дизайну помещений
- Застройщик.Аренда - региональная платформа по управлению арендой жилых и коммерческих помещений
- Застройщик.Финанс - площадка для торговли первичными и производными финансовыми инструментами, обеспеченными профильными активами
Стратегия
Перейти на промышленное облачное решение
Передать на аутсорсинг комплекс организационных и IT-процессов по обслуживанию и развитию сервиса и решения
Оптимизировать финансовые потоки и показатели
Обоснование
Текущее состояние (гипотетическая архитектура)
Бизнес-процесс работы с заявками клиентов реализован на базе следующих (компонентов) информационных систем (ИС):
- диспетчерская - front для диспетчеров
- хранилице заявок и их статусов - back и интеграционая шина
- front для инженеров - мобильное приложение
- front для клиентов - мобильное приложение
- оменклатурно-справочная инфорация - по объектам и сотрудникам (инженерам)
- управление доступами и KYC
Решение создано, эксплуатируется и поддерживается собственными силами, и развёрнуто на собственной инфраструктуре.
Недостатки (гипотетическое усреднение)
Сложно и дорого поддерживать и развивать как саму ИС, так и инфраструктуру, равно как и соответствующую экспертизу внутри компании
Решение устарело с точки зрения требований бизнеса, функционала и архитектуры
В ходе эксплуатации выявлены существенные недостатки и просчёты проектирования. Например, связанные с использованными в решении структурами данных и их иерархией. Устранение этих недостатков и дальнейшее развитие функционала и архитектуры ИС собственными силами сложно, долго и дорого.
Целевое состояние
Внедрено облачное решение компании, предосталяющей промышленное решение в качестве облачного сервиса. Решение заменяет back и фронт для диспетчеров, инженеров и клиентов.
Сделана интеграция с внутренними ИС.
Проведена миграция данных и процессов.
Эксплуатация и поддержка передана компании-провайдеру сервиса.
Выстроен процесс обновления и развития (в том числе, в форме заказной доработки) функционала ИС силами компании Habex
Преимущества
Оптимизация процессов эксплуатации, поддержки и развития ИС - предсказуемость затрат и сроков, снижение рисков
Оптимизация финансовых потоков - CAPEX → OPEX
Доступ к отраслевой экспертизе и возможность масштабирования функционала и области применения решения
Высвобождение внутренних ресурсов и экспертизы для применения в других задачах и предметных областях
Возможность для улучшения продуктовых и бизнес-метрик
Бизнес-требования
Нефункциональные требования
Требования
- доступности, производительности и отказоустойчивости
- уровня сервиса - SLA
- обязательств по развитию платформы - патчи, релизы, CSD
Целевые показатели (с учётом возможностей масштабирования)
- Объём необходимых (облачных) ресурсов
- Скорость обмена данными
- Плотность потока данных
- Количество и объём заявок
- Количество пользователей
Функциональные требования
Front
Диспетчер
Требования по
- фильтрации и поиску открытых заявок
- работе с историей заявок
- изучению и анализу истории заявки
- одновременной работе с несколькими заявками
- редактированию и дополнению содержимого заявки
- изменению статуса заявки
- обмену информацией с инженером и жильцами - может быть реализовано с помощью дополнительных статусов
- работе со структурой объектов
- работе с личными бизнес-показателями
Инженер
Требования по
- работе с назначенными заявками - принять, отказаться, комментировать, изменить статус (в том числе, запросить информацию)
- запросу истории заявок (и работ) по объекту или жильцу
- работе с личными бизнес-показателями
Пользователь (жилец)
Требования по
- созданию заявок - различные каналы
- просмотру информации и статуса по открытым своим заявкам и по истории своих заявок
- редактированию и отзыву заявки и созданию повторной, или связанной заявки
- возможности присоединиться к коллективной заявке - по совпадению (или взаимосвязи) объектов - с возможностью в дальнейшем работать (почти!) как со своей заявкой
Администратор
Управление пользователями и доступами
Изучение и анализ логов и отчётов в том числе, по бизнес-показателям
Продвинутые инструменты анализа заявок (как открытых, так и истории)
Back
Базовые требования к функционалу работы с
- заявками
- аналитикой и отчётами
- ролями и объектами системы, включаю структуру данных
Интеграции
Требования по интеграции с
- внутренними информационными системами
- (временно) с Legacy платформой
- дополнительными функциональными модулями провайдера, например, аналитическим, или CRM
Требования безопасности
Требования контроля и управления доступа к данным и функционалу
Ролевая модель, в том числе доступа к данным
Вводная (гипотетическое требование от ИБ): хранилище (КХД) должно быть on premise (не в облаке)
Требуется понять
- что (какие данных), как и когда отправлять в КХД из облака (и обратно)
- как синхронизировать данных в облаке и КХД и как обеспечить целостность данных
- и продумать архитектуру интеграцию облака с КХД
Простейший вариант (если это устроит ИБ)
В КХД храним только закрытые заявки (историю заявок). При этом, на достаточную для целей аналитики и отчётности глубину, оставляем историю в облаке.
Что касается структуры данных (нормативно-справойной информации) то какая-то их часть хранится в облаке. Хотя бы метаданные, позволяющие диспетчеру в режиме on-line проследить привязку заявки к объектам - возможно, без и полной информации об этих объектах. В идеале, в облаке должна храниться синхронная копия всей структуры данных.
Дорожная карта
- Сбор, уточнение и согласование требований, в том числе межпроектных
- Разработка и согласование итоговой архитектуры, включая структуры данных и необходимые интеграции
- Оценка трудозатрат, включая внутренние → оценка сроков и бюджета
- Проработка рисков
- Разработка процессов взаимодействия и схемы коммуникаций
- Определение состава пилота (MVP, PoC) и последующих этапов ввода функционала, миграции данных и переключение заявок и пользователей
- Защита проекта
- Старт основной части проектных работ
- (Итеративно) контроль, коррекция, отчётность
- Тестирование, включая UAT
- Миграция данных
- Переключение нагрузки - пробный запуск (большой пилот - возможно в форме A\B теста)
- Переключение всей нагрузки на новое решение
- Вывод из эксплуатации legacy решения