Как выбрать между платформой и своей разработкой
Готовая платформа подходит, когда её диспетчерская, роли и обмен с вашей расчётной системой проходят нужные сценарии без постоянного ручного переноса. Собственное приложение имеет смысл, если нужные правила эксплуатации нельзя настроить в выбранной платформе: например, разные маршруты заявок по домам или связь с несколькими системами учёта. Между этими вариантами есть ещё один: оставить готовое ядро и разработать недостающий модуль.
Мы предлагаем сначала проверить три действия: житель отправляет обращение, диспетчер назначает работу, исполнитель возвращает результат. Затем повторить проверку с показанием и оплатой. Так станет видно, какие возможности уже есть у продукта, а какие придётся проектировать и оплачивать отдельно.
Готовые продукты уже поддерживают эту связку ролей. Например, Домопульт описывает единую платформу с диспетчерской, приложениями жителей и исполнителей. В руководстве Квартира.Бурмистр.ру показана передача назначенной заявки сотруднику. На демонстрации попросите пройти ваш маршрут целиком; наличие названия функции в презентации ещё оставляет открытыми правила её работы.
| Вариант | Когда подходит | Что проверить |
|---|---|---|
| Готовая платформа | УК готова работать по поддерживаемым правилам продукта. | Ваши роли, данные, конфигурацию биллинга и условия выхода. |
| Платформа + свой модуль | Основной процесс устраивает; есть отдельный пробел, например обмен с учётом. | Разрешённый API, права на данные, поддержку после обновлений обеих систем. |
| Собственное приложение | Нужные маршруты и интерфейсы требуют существенных изменений; УК готова развивать продукт. | Состав первой версии, ответственность за эксплуатацию, код, доступы и бюджет поддержки. |
Здесь мы рассматриваем обслуживание жилого дома после заселения. В кабинете коммерческого арендатора главными могут быть договор и услуги организации; у дольщика до передачи квартиры свои этапы сделки и приёмки. Перечень экранов похож, но права и рабочие операции различаются.
Иллюстрация сценария
От сообщения жителя к работе у подъезда
Проведите одно обращение через три роли
Допустим, для проверки вы выбрали незакрывающуюся дверь подъезда. Житель указывает место, прикладывает фото и получает номер обращения. Диспетчер видит объект, категорию, время поступления и историю; затем назначает исполнителя. Мастер принимает задание, сообщает о ходе работы и добавляет результат. После согласованной проверки житель видит завершение.
Мы предложим отдельно описать причины, по которым путь меняется: мастеру нужен доступ, требуется материал, обращение относится к другой службе или житель сообщает, что проблема осталась. Каждому такому случаю нужен понятный статус и ответственный. Иначе сотрудникам придётся договариваться по телефону, а приложение продолжит показывать прежнее состояние.
При проверке смотрите на события: заявку зарегистрировали, мастер принял назначение, результат согласовали. Уведомление на телефоне помогает заметить изменение, но сама история должна оставаться в кабинете. Для срочных и аварийных ситуаций заранее покажите жителю действующий канал связи с диспетчерской и согласуйте его место в процессе.
Свяжите жителя с помещением и лицевым счётом
Код из SMS подтверждает доступ к номеру телефона. Право видеть данные конкретного помещения система должна проверить отдельной процедурой. Например, УК сверяет сведения со своей базой и подтверждает привязку. В инструкции Домопульт активация номера на стороне УК связана с подключением лицевого счёта.
До выбора продукта мы предложим пройти четыре случая: у жителя несколько помещений, одним помещением пользуются несколько людей, арендатор сменился, лицевой счёт переоформили. Нужно решить, кому доступны начисления, переписка и документы, кто может передавать показания и как отзывается доступ. Исполнителю достаточно данных назначенного задания; доступ к платёжной истории всех квартир ему обычно не нужен.
Сам принцип понятного кабинета мы применили в CentreVisa: собрали заявку, статус и общение с консультантом в приложении визового сервиса. Клиент видит обращения в работе и завершённые, а переписка сохраняется рядом с заявкой. Для УК такой путь понадобится связать с адресом, правами жителя и правилами диспетчерской.
Наш проект: визовый сервис
CentreVisa: статус рядом с обращением
Мы сделали раздел заявок и чат с консультантом. Эти экраны показывают клиентский путь сопровождения.
Разделите показания, начисления и оплату
У этих операций разные источники и разные подтверждения. Житель передаёт показание, расчётная система принимает его по своим правилам и формирует начисление. Такую систему часто называют биллингом. Приложение показывает согласованные данные и время их обновления. Если УК поручает приложению новый расчёт начислений, понадобится отдельный состав работ: методика, исходные данные, проверенные примеры и приёмка с ответственными за расчёт.
Допустим, житель оплатил квитанцию и вернулся в приложение. Сначала сервер проверяет результат у платёжного провайдера, затем обмен передаёт или получает сведения для учёта. Сумма задолженности меняется после предусмотренного подтверждения расчётной системы. В документации ЮKassa описаны разные состояния платежа: ожидание и успешное завершение. Для выбранного банка или провайдера мы проверим его собственные правила.
| Данные | Источник и направление | Приёмочная проверка |
|---|---|---|
| Помещение и лицевой счёт | Согласованный реестр УК или биллинга → кабинет. | Тот же адрес и счёт; права нового и прежнего пользователя. |
| Показание | Житель → сервер приложения → расчётная система. | Принято или отклонено; повтор не создаёт вторую запись показания; замена прибора учтена. |
| Начисление и квитанция | Биллинг → сервер → житель. | Правильный счёт, период, сумма и дата обновления; результат перерасчёта. |
| Платёж | Провайдер → сервер; результат учёта → кабинет. | Платёж связан с нужным счётом; задержка, повтор уведомления и сверка. |
| Новости и документы | Уполномоченный сотрудник УК → нужный объект и аудитория. | Житель другого дома не получает закрытый документ; отмена публикации видна. |
Эту таблицу можно перенести в задание поставщику. Добавьте название системы, конкретные поля, допустимую задержку и сотрудника, который разбирает сбой. Например, при недоступном биллинге кабинет может показывать последнее полученное начисление с датой обновления; возможность оплаты в таком состоянии нужно согласовать с участниками процесса.
Уточните, что именно означает «интеграция с 1С»
Название 1С объединяет разные конфигурации, версии и способы размещения. Поэтому мы начинаем с названия программы, версии, доработок, доступной документации и тестовой базы. Затем проверяем каждое направление: получить начисления, передать показания, обновить лицевые счета, подтвердить оплату. Поддержка одного направления не доказывает работу остальных.
Хороший пример конкретности есть в документации Квартира.Бурмистр.ру: описана API-выгрузка из 1С квитанций и балансов в лицевые счета. API означает программный способ обмена. Для вашей УК остаётся проверить совместимость базы, поля, ошибки и необходимые обратные операции.
В собственной разработке обмен обычно проходит через сервер: приложение на телефоне запрашивает данные у своего сервера, а тот получает разрешённые сведения из учёта. Доступы к 1С остаются на серверной стороне. Один из возможных механизмов, OData, позволяет программно читать и записывать доступные объекты; документация 1С:Фреш описывает настройки состава объектов, проверки прав и ограничения сервиса. Выбор механизма зависит от конкретной базы и операции.
В «Бакаеве» мы помогли перенести локальную 1С в облако и связали её с админ-панелью мобильного магазина. Сотрудник меняет изображение товара в панели, сервер синхронизации передаёт изменение в 1С. Заказ из приложения отражается в остатках админ-панели и учёта; изменения со стороны 1С проходят обратный путь к приложению.
Наш проект: мобильный магазин
«Бакаев»: связали интерфейс и учёт
Мы настроили двусторонний обмен товарами, изображениями и остатками.
Из этой работы полезен принцип связанного пути данных. Для УК мы предложим проверить показание, которое отправили повторно после пропавшего ответа, перерасчёт уже показанной квитанции и платёж, который подтвердился у провайдера, но ещё не появился в биллинге. По журналу сотрудник должен понять, на каком участке остановилась передача и что делать дальше.
Сравните полную стоимость на одинаковом составе
Стоимость приложения управляющей компании складывается из запуска и дальнейшей работы. У готовой платформы уточните единицу тарификации: лицевой счёт, объект, пользователь или другой показатель. Например, FAQ Домопульт связывает цену с количеством лицевых счетов и регионом, а брендирование и индивидуальные доработки выделяет отдельно. Эти условия относятся к конкретному поставщику; для сравнения нужны его актуальное предложение и договор.
Мы предлагаем считать полную стоимость владения, или TCO, на одном выбранном горизонте и одном наборе домов. В обе оценки включите подготовку данных, подключение учёта, обучение, поддержку, уведомления по договорам провайдеров, изменения продукта и перенос при выходе. Добавьте работу сотрудников УК: кто будет подтверждать жильцов и разбирать ошибки обмена.
| Статья расходов | Что запросить в предложении |
|---|---|
| Запуск | Настройка домов, перенос данных, роли, обучение и проверка сценариев. |
| Интеграция | Подготовка вашей базы 1С, модуль обмена, тесты и ответственность за обе стороны. |
| Регулярные расходы | Подписка или инфраструктура, поддержка, резервные копии, уведомления и условия платежей. |
| Развитие | Стоимость новой функции, новых домов, обновлений 1С и поддержки изменений API. |
| Выход и передача | Выгрузка истории, вложений, справочников и прав; передача кода и доступов в собственной разработке. |
Например, два предложения могут по-разному трактовать «оплату ЖКУ»: одно включает только экран квитанции и переход к провайдеру, другое ещё подключает сверку с биллингом. До сравнения итоговой суммы уравняйте состав. Собственная разработка также требует регулярного бюджета: после выпуска остаются сервер, обновления, поддержка и работа с обращениями пользователей.
Попросите поставщика показать сложные случаи
Для закупки удобно отправить один список вопросов всем участникам. Мы рекомендуем попросить демонстрацию на обезличенных данных вашего дома и письменные ответы по ограничениям. Это позволит сравнить готовый продукт и заказную разработку по одинаковому результату.
- Как подключают и отключают жителя? Покажите несколько помещений, несколько пользователей одного помещения и смену арендатора.
- Как заявка проходит все роли? Создайте её, переназначьте исполнителя, верните на уточнение, завершите и откройте повторно по согласованному правилу.
- Какая база 1С поддерживается? Назовите конфигурацию, версии, требуемые доработки и состав каждого направления обмена.
- Что происходит при сбое? Покажите недоступный учёт, повтор показания и задержавшееся подтверждение оплаты. Кто видит ошибку и сверяет результат?
- Как устроены роли и история? Проверьте доступ к чужой квартире, назначенной работе и документам другого дома; покажите журнал важных действий.
- Что входит в договор? Уточните тарификацию, обучение, поддержку, доработки, инфраструктуру, обязательства по данным и восстановлению.
- Как УК заберёт данные? Запросите состав, формат, стоимость и порядок экспорта обращений, переписки, вложений, назначений и справочников после прекращения договора.
Отдельно согласуйте обязательные каналы информационного взаимодействия УК и связь с ними. Для ГИС ЖКХ есть свой интеграционный регламент; если обмен нужен, включите его в состав и приёмку отдельным пунктом. СКУД, домофония и юридически значимые действия тоже потребуют конкретных условий поставщиков и организации.
По персональным данным мы предложим вместе с ответственным УК определить основание обработки, состав сведений, роли сторон, доступы, сроки хранения и действия после отзыва доступа. Ответственность подрядчика и порядок обработки фиксируют в договоре; ориентир для такого разбора даёт закон о персональных данных. Один экран согласия не описывает весь процесс.
Запустите пилот на одном доме с ясной приёмкой
В первую версию мы предложим включить подтверждение связи жителя с помещением, обращения, диспетчеризацию, задания исполнителя, новости и документы объекта. Показания, начисления и оплату добавим в согласованном объёме после проверки источников. Для пилота достаточно одного дома, если он представляет ваши основные роли и процессы.
Сначала проверим всю цепочку на тестовых данных, затем согласуем подключение реальных пользователей и сотрудников. До этого УК определит ответственных, порядок срочных обращений, исправления ошибочных данных и действий при недоступном приложении. Жителям нужен понятный способ получить помощь и вне нового канала.
Результат пилота лучше оформить таблицей: сценарий, ожидаемое поведение, фактический результат, замечание и ответственный. Если критические операции проходят, можно обсуждать подключение остальных домов. Если часть работы всё ещё требует ручного переноса, у вас уже будет точный список доработок для поставщика или команды разработки.
Что ещё уточняют перед выбором
Можно ли начать с обращений без оплаты?
Да, если это соответствует задачам УК и сохраняет действующие каналы. Пилот может проверить заявки и исполнение; показания, начисления и оплату подключают отдельными согласованными этапами.
Нужен ли перенос 1С в облако?
Это зависит от размещения базы и разрешённого обмена. Сначала мы проверим доступные интерфейсы, права и инфраструктуру. В «Бакаеве» перенос был частью решения; для другой системы может подойти иной вариант.
Можно ли сохранить свою диспетчерскую?
Да, если её интерфейсы позволяют передавать обращения, назначения и результаты в нужном составе. Это проверяют по документации и тестовому сценарию до выбора платформы или разработки модуля.
Что будет с данными при смене платформы?
До договора согласуйте выгрузку лицевых счетов, обращений, переписки и вложений: формат, стоимость и порядок передачи. Затем проверьте, как эти сведения сопоставят с записями новой системы и кто сохранит доступ к истории.
Покажите путь обращения и учётные системы
Подготовьте обезличенный пример обращения, роли сотрудников, название и версию 1С или биллинга. На первом разговоре мы разберём путь жителя и исполнителя, составим карту обмена и предложим границы пилота на одном доме. Так появится основа для сравнения платформы и собственной разработки.
Состав работ по приложению управляющей компании обсудим после обращения. Оставьте удобный контакт в форме, чтобы договориться о разборе.