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