Открытые вопросы — нужен взгляд¶

Шесть вопросов, на которые я сам ответить не могу или ответ зависит от банковской/юридической практики. Если у тебя есть мысль по любому из них — кнопка комментария рядом.

Цвета вопросов:

🟡 Хорошо бы услышать. Проект может двигаться без ответа, но решение получится сильнее, если ты выскажешься.
🔴 Без тебя застрял. Не могу двигаться дальше до твоего ответа.
✅ Закрыт. Решение принято, видно ниже после твоего комментария от такой-то даты.

Сейчас все шесть — 🟡. Красных нет, ничего не блокирует.

1. 🟡 Какой минимум собственников должен быть в здании, чтобы показывать там бенчмарк¶

Зачем это нужно. В решении про двухуровневую платформу мы договорились, что собственник видит не индивидуальные ставки соседей, а обезличенный бенчмарк по своему зданию (средняя, медиана, перцентили). То же — банк-кредитор, видящий контекст по зданию своего заёмщика. Это работает, только если в здании достаточно разных собственников, чтобы из агрегата нельзя было вычислить чужие ставки.

В чём сложность. Если в здании 3 собственника, и одному показывают «средняя ставка по сегменту = 1100, минимум 800, максимум 1500» — он легко может вычислить ставку каждого из двоих соседей, особенно если знает их площади. Это уже не обезличивание.

Стандарт макро-аналитики (по локации, не по зданию) — минимум 5 наблюдений от 3 разных собственников. Это работает в большом радиусе. На уровне отдельного здания этот же порог может быть либо слишком жёстким (тогда бенчмарк по зданию почти никогда не покажется), либо недостаточным (на маленьком здании 5 наблюдений всё равно деанонимизируются).

Варианты, между которыми выбираем.

Тот же стандарт, что для макро: ≥5 наблюдений, ≥3 собственников. На наших объектах работает на Кластере 73 и Нововатутинской, не работает на Пяловской и точно не на Черёмушках.
Жёстче для микро: ≥10 наблюдений, ≥4 собственников. Безопаснее, но бенчмарк по зданию почти никогда не покажется — фича становится бесполезной.
Мягче для микро: ≥3 наблюдений, ≥2 собственников. Работает почти везде, но деанонимизация всё ещё возможна методом исключения.
Гибрид: ≥5 наблюдений, ≥3 собственников + дополнительное правило: «доля одного собственника в сегменте не больше 50%». Это блокирует ситуацию «один крупный собственник вычисляет всех остальных».

Что я думаю сам. Склоняюсь к гибриду. Обычный k-anonymity не защищает от случая «один владелец почти всего здания», а в коммерческой недвижимости такие случаи встречаются часто. Дополнительное правило про долю — простое и закрывает эту дыру.

Что важно от тебя. Как банк смотрит на достаточность обезличивания? Есть ли в банковской практике стандарт «безопасной доли одного источника в агрегате»? Если ты скажешь «слабо, нужно ещё жёстче» — задам вопросы юристу, как формализовать. Если скажешь «достаточно» — фиксируем гибридный вариант и идём дальше.

💬 Прокомментировать

2. 🟡 Как банк хочет видеть платежи, которые поступают не напрямую собственнику, а через ТСН¶

Зачем это нужно. В реальной жизни часть платежей от арендаторов идёт не напрямую конкретному собственнику, а в общую кассу здания через ТСН (или аналогичный коллективный орган). Например, общая электроэнергия, охрана, уборка общедомовых пространств — это собирается ТСН, а потом распределяется между собственниками по их долям.

В чём сложность. Когда банк смотрит на cash flow заёмщика-собственника для скоринга или мониторинга кредита, ему нужна полная картина поступлений — включая то, что приходит через ТСН. Иначе денежный поток выглядит меньше реального, и банк недооценивает доходность объекта.

Технически это значит, что Dominium должен: - Видеть платежи, которые приходят в ТСН. - Понимать, как они распределяются между собственниками. - Показывать в кабинете каждого собственника его долю этих поступлений.

Варианты, между которыми выбираем.

Полностью моделировать поступления ТСН в Dominium. ТСН становится таким же активным участником, как любая управляющая компания: ведёт договоры с арендаторами общедомовых ресурсов, биллит, получает деньги. Распределение по собственникам — событие в системе. Плюс: полная картина. Минус: ТСН может не пользоваться Dominium, и тогда данных просто не будет.
Учитывать вход средств от ТСН как "переводы извне". ТСН в Dominium не моделируется. Каждый собственник вручную или автоматически (по выписке) фиксирует поступления от ТСН как обычный входящий платёж с пометкой «от ТСН по такому-то периоду». Плюс: проще. Минус: теряется детализация, банк видит «пришло X от ТСН», но не понимает, за что и почему столько.
Опционально моделировать ТСН (если оно само пользуется Dominium). Если ТСН активный пользователь системы — собственники видят детализацию. Если нет — собственники сами вручную фиксируют входящие.

Что я думаю сам. Третий вариант (опционально). Заставлять каждое ТСН пользоваться Dominium нереалистично, особенно на старте. Но если оно подключено — даём детализацию.

Что важно от тебя. Достаточно ли банку «вход средств от ТСН» как обобщённой строки, или действительно нужна детализация каждой статьи (электроэнергия, охрана, уборка)? Если детализация важна — это сильный аргумент подталкивать ТСН к подключению, и фича сама по себе становится привлекательной для банков.

💬 Прокомментировать

3. 🟡 Гранулярность согласия собственника на использование его данных¶

Зачем это нужно. Когда собственник регистрируется в Dominium, он подписывает оферту: его обезличенные данные используются в рыночной аналитике, банки-партнёры её видят, он сам получает доступ к бенчмаркам по своим сегментам. Это базовая сделка.

В чём сложность. Можно по-разному нарезать «согласие» на части. Минимум — одна общая галочка «согласен на всё». Максимум — отдельные галочки на каждый вид использования. Между ними — компромиссы.

Варианты, между которыми выбираем.

Одна галочка «согласен на всё». Простота для пользователя. Все сценарии одобрены сразу. Минус: если собственник не хочет участвовать только в одном виде аналитики (например, не хочет, чтобы его данные шли в перепродаваемые отчёты для клиентов банков, но не возражает против обычной макро-аналитики) — он вынужден отказаться от всего.
Раздельные галочки по видам использования. Для каждого вида — отдельное согласие: (а) использование в обезличенных макро-агрегатах, (б) использование в микро-бенчмарках по своему зданию, (в) использование в отчётах, которые банк-партнёр перепродаёт клиентам, (г) использование данных для предиктивных моделей (Этаж 3 в будущем). Плюс: гибкость, точное согласие. Минус: сложнее для пользователя, может отпугнуть на регистрации.
Двухуровневое. По умолчанию — общее согласие на «обычную аналитику»: макро + микро + чтение банком-кредитором. Раздельно — на «продвинутые случаи»: перепродажа, предиктивные модели. Так покрываются 95% случаев одной галочкой, а оставшиеся 5% получают тонкую настройку.

Что я думаю сам. Двухуровневое. Простота для большинства, гибкость для тех, кто хочет.

Что важно от тебя. Как с этим работают банки в схожих случаях (использование клиентских данных для разных целей)? Какой уровень гранулярности юридически достаточен и не вызывает претензий регуляторов? Это влияет на текст оферты, который будет писать юрист.

💬 Прокомментировать

4. 🟡 Что собственник получает взамен за участие в аналитике — экономика обмена¶

Зачем это нужно. Использование данных собственника в обезличенной аналитике — это обмен. Он отдаёт свои данные, получает что-то взамен. Принципиально мы договорились на простую формулу: участвуешь — получаешь доступ к рыночным бенчмаркам; отказался — не получаешь. Это уже стимул участвовать.

В чём сложность. Простой формулы «доступ к бенчмарку» может оказаться недостаточно. Особенно для крупных собственников, которые сами хорошо знают рынок и не очень нуждаются в бенчмарках. Или для собственников, которые хотят бóльшего участия в монетизации (если их данные перепродаются банком, может, им часть выручки?).

Варианты, между которыми выбираем.

Простой обмен: дал данные — получил бенчмарки. Никаких денежных расчётов. Plus: просто, понятно, нет головной боли с биллингом собственников. Минус: крупные собственники могут не видеть мотивации.
Обмен с тарифами: разные уровни участия дают разный доступ. «Базовый» (просто бенчмарк по сегменту), «Премиум» (бенчмарки + сравнения + алерты), «Платный API» (раз в день выгрузка). Плюс: разные сегменты получают что хотят. Минус: сложнее объяснить, сложнее администрировать.
Долевая модель: часть выручки от перепродажи данных банками возвращается собственникам, чьи данные использованы. Например, 10% от каждого перепродаваемого отчёта делится между собственниками сегмента пропорционально их вкладу. Плюс: справедливо для крупных собственников. Минус: технически сложно реализовать честно, и юридически непросто.

Что я думаю сам. На старте — простой обмен. Через год-два, если будет видно что крупные собственники не идут — добавлять долевую модель. Но это уже другой продукт по сути.

Что важно от тебя. Видишь ли ты крупных собственников, которые не пойдут в систему без финансового стимула? Если да — на старте надо думать о долевой модели или о тарифах. Если нет — простого обмена достаточно.

💬 Прокомментировать

5. 🟡 Как описывать бизнес арендатора для сегментации в аналитике¶

Зачем это нужно. Когда мы строим бенчмарк по сегменту «офис 100–200 м² в локации X», важно учитывать тип бизнеса арендатора: автосервис, кафе, юридическая фирма, склад. Потому что один и тот же офис, сданный кафе, имеет совсем другую доходность и платёжную дисциплину, чем тот же офис, сданный юридической фирме.

В чём сложность. Чем точнее описание бизнеса арендатора — тем точнее аналитика. Но тем сложнее её собирать (управляющий должен заполнить дополнительные поля при заведении договора), и тем больше шансов на ошибки в категоризации.

Стандарты в России — ОКВЭД (классификатор видов экономической деятельности). В нём около 1500 кодов. Но реальная коммерческая практика работает с примерно 30-50 типами: ресторан, кофейня, продуктовый магазин, парикмахерская, медицинский кабинет, IT-офис, складская площадь и т.д.

Варианты, между которыми выбираем.

Полный ОКВЭД. Точно, но при заведении договора управляющий должен выбирать из 1500 кодов. Никто этого делать не будет.
Свой укрупнённый справочник на 30-50 категорий. Собран из практики: «общепит», «розничная торговля», «офис IT», «офис юридический», «склад», «производство» и т.д. Заполняется одним кликом. Покрывает 95% случаев.
Свой справочник + опциональное уточнение через ОКВЭД. Базово — укрупнённая категория. По желанию — точный код ОКВЭД. Аналитика работает на базовом, ОКВЭД — для отчётов и интеграций.

Что я думаю сам. Третий вариант. Покрытие реальных кейсов одним кликом, точность для тех, кто готов её обеспечить.

Что важно от тебя. В банковской практике как сегментируют бизнес заёмщиков — по ОКВЭД целиком, по укрупнённым отраслям, как-то ещё? Если у банков уже есть свои сложившиеся сегменты — имеет смысл их использовать для совместимости. Какие именно?

💬 Прокомментировать

6. 🟡 Список ролей: кто видит что в системе¶

Зачем это нужно. В Dominium одновременно работают много типов пользователей: собственники, управляющие, арендаторы, банки, оценщики, госорганы, ТСН. У каждого свой набор прав. Точный список ролей и матрица их прав — это большой документ, который определяет, как работает доступ во всей системе.

В чём сложность. В первоначальном техзадании зафиксировано 11 ролей: Собственник, CEO УК, Акционер, Asset Manager, Property Manager, Leasing Manager, Главный инженер, Бухгалтер, Юрист, Арендатор, Банк/Инвестор. По ходу работы добавились системные роли (Аудитор, Администратор, Сервисный аккаунт), а часть бизнес-ролей возможно избыточна.

Параллельно есть вопрос: каким именно объёмом доступа обладает каждая роль, особенно сотрудник управляющей компании. Сейчас рабочая гипотеза: сотрудник УК видит данные тех собственников, с которыми у УК активный договор управления. То есть как только договор расторгнут — доступ автоматически пропадает. Это правильное направление, но нужны детали.

Варианты, между которыми выбираем.

Оставить 11 ролей из исходного техзадания. Технические роли (admin, service_account) описать отдельно как «системные», не считать в 11. Плюс: преемственность. Минус: некоторые роли могут оказаться лишними на практике.
Расширить до 14 ролей (11 бизнес + 3 системных). Все на одном уровне. Плюс: полная картина. Минус: больше документации без явной пользы.
Пересмотреть с нуля. Опираться не на априорные роли, а на реальные сценарии работы. Возможно, получится 7-8 ролей вместо 11. Плюс: точно под реальные потребности. Минус: переделка существующих документов.

Что я думаю сам. Пересмотреть аккуратно: оставить большинство ролей из 11, выкинуть очевидно избыточные (Акционер, например — не очень понятно, что он делает в системе ежедневно), добавить системные. Получится 9-12 ролей.

Что важно от тебя. В банковской практике с какими ролями ты сталкиваешься в системах ваших клиентов? Какие реально используются, какие лежат мёртвым грузом? Если у тебя есть мнение, кто из 11 «лишний» — давай выкинем заранее, не строя.

💬 Прокомментировать

Что происходит после твоего комментария¶

Ты отвечаешь на любой из вопросов через кнопку комментария.
Мне приходит уведомление в Telegram с пометкой, на какой именно вопрос ты ответил.
Я учитываю твой ответ в работе:
Либо принимаю предложенный вариант — тогда вопрос закрывается с пометкой «✅ закрыт после комментария Никиты от такой-то даты».
Либо есть нюанс, который требует обсуждения — пишу тебе в Telegram, обсуждаем, потом фиксирую.
Закрытый вопрос переезжает на страницу «Какие решения приняли и почему» с указанием, что повлияло на выбор.

Так в проекте остаётся след того, как твои мнения формируют продукт. Это часть той самой хроники, про которую написано на странице «Что сделано» — доказуемая логика, по которой строится проект.

— Рома