Задача
Компания работала одновременно в нескольких моделях. Она могла построить и продать здание целиком, реализовать отдельные квартиры, передать объект оператору в долгосрочную аренду, управлять площадями сама или оставить объект в портфеле и обслуживать его жильцов. Одна и та же недвижимость последовательно проходила через строительный, коммерческий, договорной, финансовый и сервисный контуры.
До трансформации каждый из этих контуров жил отдельно — на бумаге и в разрозненных программах без устойчивой синхронизации. Один и тот же объект по-разному назывался в строительной документации, таблице отдела продаж, договоре аренды и системе управляющей компании. Фотографии, разрешения, планы, договоры и акты хранились отдельно от операционных записей.
Разрывы шли между собственниками и операционными подразделениями, девелопментом и стройкой, закупками, продажами и арендой, юристами и финансами, управляющей компанией и жителями — и отдельно между плановой BIM-моделью объекта и его фактическим состоянием на площадке.
Руководству приходилось сводить показатели вручную, а передача построенного объекта в продажи или эксплуатацию означала повторный ввод данных. Задачей была не автоматизация одного отдела, а единый цифровой контур, в котором переход между стадиями жизненного цикла — часть одного процесса.
Решение
Мастер-реестр недвижимости. Устойчивая иерархия: холдинг и юридическое лицо → портфель или девелоперская программа → проект и строительная площадка → здание → очередь, секция, этаж → квартира или арендуемое помещение → инженерная система и обслуживаемое оборудование. Модель позволяла по-разному коммерциализировать один и тот же актив: продать здание целиком, сдать одному оператору, разделить на самостоятельные помещения или оставить под управлением собственной эксплуатационной компании. При смене модели данные не копировались — менялись коммерческая структура и права, а исходная история объекта оставалась той же.
План против факта. Среда проектных данных фиксировала, какая версия модели предназначена для работы, какая находится на согласовании и какая стала утверждённой; утверждённый файл нельзя было незаметно заменить черновиком. Съёмка с дронов обрабатывалась фотограмметрическим контуром в облако точек и привязывалась к объекту, дате аудита и участку модели. Аудитор сравнивал запроектированную и фактическую геометрию, фиксировал отклонение в конкретной точке, прикладывал фото и измерение и назначал задачу на устранение. Готовность после этого перестала быть одним процентом из презентации: она считалась по принятым объёмам, контрольным точкам, закрытым замечаниям, наличию обязательных документов и состоянию зависимых инженерных систем.
Сделка без повторного ввода. OCR распознавал документы клиента в CRM или со сканирования на планшете и заполнял профиль, сотрудник проверял результат. Договор собирался по утверждённому шаблону из карточек клиента, объекта, юридического лица, коммерческого предложения и графика платежей — с сохранением версии шаблона и источников подставленных данных. Менеджер подписывал документ с клиентом на планшете; подписанная версия возвращалась в хранилище, меняла состояние сделки и запускала следующие задачи: оплату, передачу, оформление доступа, постановку объекта на обслуживание. Доступность помещения была общей для CRM, сайта и внешних площадок: резервирование меняло статус во всех каналах сразу.
Цифровой паспорт вместо повторной сборки комплекта. При вводе объекта в эксплуатацию хранилище документов формировало паспорт: утверждённые планы, исполнительную модель, перечень оборудования, регламенты, гарантии, контакты подрядчиков, акты и историю замечаний. Дальше замена лампы, авария инженерной системы и капитальный ремонт шли разными маршрутами, но ложились в общую историю объекта. Заявка жителя из мобильного приложения сразу попадала в нужную очередь, потому что система знала его помещение и договор: категория, приоритет и SLA, назначение бригады, задание в приложении выездного сотрудника с чек-листом, сканированием метки оборудования и списанием материалов, подтверждение жителя.
Права по сочетанию, а не по списку. Доступ вычислялся из роли, организации, подразделения, портфеля, объекта и типа данных: подрядчик видел только свой договорный объём и опубликованные версии, выездной сотрудник — задание и минимум данных жильца, житель — своё помещение, договор и заявки.
Ядро. Backend на Laravel с доменными модулями и общим API для веба, мобильных приложений и планшетов. Длительные операции — распознавание документов, формирование пакетов, публикация объявлений, обработка пространственных данных — вынесены в фоновые очереди, чтобы интерфейс не ждал. Отдельно спроектированы платформенные сервисы, без которых контуры расползлись бы обратно: мастер-данные и единые идентификаторы объектов, роли и делегирование полномочий, workflow-движок, хранилище документов с версиями, сквозной поиск и аудит действий. Внедряли не всё сразу, а по стадиям жизненного цикла, начиная с самого болезненного участка — сведения плана и факта на стройке.
Результат
Компания получила общую цифровую модель вместо бумаги и набора несвязанных программ. Собственники видят портфель, стройку, продажи, аренду, эксплуатацию и финансы в одной консолидированной картине, а не в сводке, собранной вручную к совещанию. Показатели считаются по общим для всех подразделений определениям, и любой агрегат раскрывается до исходного объекта и документа.
Объект перестал терять историю при переходе между стадиями. Построенное здание попадает в продажи и дальше в эксплуатацию вместе со своими планами, разрешениями, актами и фактическим состоянием — без повторного ввода данных и без расхождения в названиях между отделами.
Выездные сотрудники и аудиторы работают с площадки в мобильных приложениях, а не в блокноте, и результат осмотра сразу ложится в паспорт объекта. Житель и арендатор получили прямой канал с управляющей компанией: заявка не теряется в звонках, а становится частью истории помещения и договора обслуживания.
В едином контуре оказалось около 5000 объектов учёта разного типа и масштаба. Для каждого платформа связала стройку, коммерциализацию, договоры, эксплуатацию и управленческую аналитику в одну непрерывную историю.
