Ответы на вопросы до старта проекта

Можно прийти как с готовым техническим заданием, так и с описанием проблемы или процесса, который хочется улучшить. На старте важнее понять участников, текущий порядок работы, данные, ограничения и желаемый результат.

Да. Для крупных задач часто разумнее сначала запустить ограниченный модуль, отдельный процесс, одну организацию или один канал взаимодействия. Это позволяет проверить решение в реальной работе до масштабирования.

Срок зависит от масштаба продукта, количества ролей, интерфейсов, интеграций и готовности исходных данных. Небольшие задачи можно запускать поэтапно, а крупные системы разбивать на самостоятельные релизы.

Стоимость формируется после разбора состава первого этапа: какие процессы автоматизируем, какие интерфейсы нужны, сколько ролей и интеграций будет в системе. До разработки фиксируем понятный объём работ и границы этапа.

Не обязательно. Обычно нужен человек, который хорошо понимает рабочий процесс и может принимать решения со стороны организации. Если есть собственные ИТ-специалисты, взаимодействуем с ними по интеграциям, инфраструктуре и данным.

Да. Новый продукт можно связать с существующими API, базами данных, корпоративными системами, телефонией, таблицами, реестрами и другими источниками данных.

Нет. Во многих проектах правильнее сохранить существующие системы и создать между ними единый рабочий контур: интерфейс, интеграционный слой, автоматизацию или дополнительный сервис.

Архитектура размещения определяется требованиями проекта. Возможны выделенный сервер, инфраструктура заказчика или отдельное серверное окружение продукта. Это обсуждается до запуска.

Да. Мы проектируем продукты так, чтобы функциональность можно было развивать поэтапно: добавлять роли, процессы, организации, отчёты, интеграции и новые каналы взаимодействия.

После запуска можно продолжить сопровождение продукта: анализировать реальную работу, исправлять узкие места, улучшать интерфейсы и последовательно добавлять новые возможности.

Да. Боты остаются одним из инструментов автоматизации. Но сначала определяется сам процесс, а уже затем подходящий канал: мессенджер, веб-интерфейс, телефония, оператор, API или их комбинация.

Да. Например, обращение может прийти из мессенджера, попасть в рабочую систему сотрудника, вызвать уведомление, запись в базе данных и дальнейший ответ пользователю через тот же или другой канал.

Голосовой канал полезен там, где требуется массовое информирование, приём звонков, повторяющиеся телефонные сценарии или связь с пользователями, которым удобнее телефон, чем приложение или мессенджер.

Да. Автоматизация может полностью находиться внутри информационной системы: маршрутизация заявок, изменение статусов, уведомления сотрудников, отчётность, контроль сроков и обмен данными между сервисами.

Единая диспетчерская служба — реализованный цифровой продукт для взаимодействия региона, организаций сферы ЖКХ, диспетчеров, мастеров и жителей в едином информационном контуре.

Платформа объединяет обращения жителей, события и отключения, адресный контур, уведомления, работу сотрудников и мастеров, аналитику и интеграции с внешними системами.

Да. На отдельной странице продукта размещены реальные экраны системы, описание архитектуры, возможностей и официальные документы.

Да. Через страницу контактов можно отправить запрос на демонстрацию и описать организацию или задачу, для которой рассматривается система.