Концепция «Алатырь» — от текущего состояния к идеальной картине¶

Периметр: магистральное направление — платформа alatyr-service и её фундамент, на котором уже сейчас идут первые продажи и постепенно наращиваются услуги.

Базовые принципы организации¶

Эти принципы выше конкретных проектов и этапов. Из них следует вся архитектура и порядок работ.

Принцип 1. Инфраструктура — это фундамент, не проект. Локальная RAG-платформа, VPS-контур, менеджер секретов, сама база знаний обслуживают все бизнес-проекты одновременно. Они не в одном ряду с проектами, а под ними.

Принцип 2. Проект — единица бизнес-смысла, не юрлицо и не окончательная категория. Проекты живые: рождаются, растут, сливаются друг с другом, дробятся, уходят в дремлющее состояние. Кожа сегодня — практика, завтра может стать разделом эко-фермы. Строительный контур со временем возможно сольётся с Alatyr Service. Архитектура должна поддерживать такие движения без переписывания.

Принцип 3. Юрлица — инструмент оформления, не проекты. ИП и будущие ООО — способы легально проводить работы и деньги через проекты. Один проект может использовать несколько юрлиц, одно юрлицо — несколько проектов.

Принцип 4. Продажи не ждут завершения архитектуры. Магистраль — фундамент, на котором первые продажи уже идут. Каждый новый этап расширяет ассортимент услуг, но продажи не останавливаются.

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

Идеальная картина через 24 месяца¶

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

Сам основатель как первый и главный тенант со своим портфелем объектов
Второй юридический контур внутри платформы для смежных услуг
Внешние тенанты — небольшие региональные подрядчики без своей IT-инфраструктуры, использующие Алатырь как SaaS для собственных объектов
Корпоративные заказчики с изолированным контуром на отдельном тенанте под их конкретный профиль безопасности

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

Платформа продаёт два коммерческих контура поверх паспорта:

Контур мониторинга и реакции. Платформа наблюдает за системами объекта, автоматически классифицирует события через ИИ-агента, эскалирует по регламенту (собственник, диспетчерская, экстренные службы, лицензированный партнёр ГБР). Абонентка 5–25 тыс. ₽/мес с объекта, маржа высокая — предельные затраты на следующий объект малы.

Контур маркетплейса работ. Заявка на плановую или срочную работу распределяется в пул исполнителей — собственная бригада или партнёрский подрядчик. Исполнитель получает не звонок, а карточку с полным паспортом. Платформа удерживает 20–35% с работы, обеспечивает документооборот заказчика, гарантирует качество независимо от того, какая бригада поехала.

Оба контура работают синергично: мониторинг создаёт заявки для маркетплейса.

Дополнительные линии услуг нарастают поверх стабильного фундамента:

Мониторинг IP-инфраструктуры и удалённое администрирование серверов, роутеров, СХД
ИИ-агенты ролей (секретарь, сметчик, делопроизводитель) как отдельная услуга
Активный мониторинг охранной и пожарной сигнализации как премиальный слой абонентки
On-premise инсталляция для корпоративного заказчика в его собственном контуре

Целевая экономика на горизонте 24 месяцев: портфель из десятков объектов на постоянном обслуживании собственной командой плюс несколько крупных пилотов; партнёрские исполнители в пуле; несколько внешних SaaS-тенантов.

Что уже есть сегодня¶

Это не «предстоит сделать», это работающий фундамент, на котором строится всё остальное:

Публичная витрина alatyr-service.ru с посадочными: техническая служба для бизнеса, обслуживание видеонаблюдения, приёмка существующих систем на обслуживание
Гостевой checkout без регистрации, оплата через ЮKassa, чеки, доставка
CRM-контур с ролями (админ, менеджер, мастер, клиент), заявками, объектами, договорами, счетами, актами
Двусторонняя синхронизация счетов и актов с «Моё Дело», автоматический импорт объектов и контрагентов, автозаполнение реквизитов через ЕГР по ИНН
Каталог услуг на базе МойСклад с резервированием остатков и гостевым checkout
Объект как workspace с вкладками договоров, материалов, версий проектов, писем и журнала работ
Единый жизненный цикл документов — архивирование, восстановление, редактирование метаданных, каскадное удаление с блокировкой при финансовых зависимостях
ИИ-контур объекта — RAG-ассистент, привязанный к объекту, с изоляцией знаний; извлечение ключевых условий договоров из PDF/DOCX в черновик с подтверждением оператором
Собственная инфраструктура хранения — файлы клиентов не уходят в сторонние облака
Проверяемые бэкапы с изолированным restore-check
Мультитенантный якорь — базовые сущности и API для будущего разделения тенантов
Приватная инфраструктурная база знаний как единый источник правды для команды и ИИ-агентов

Три слоя платформы, из которых складывается идеал¶

Концепция удобно раскладывается на три слоя. Каждый слой имеет свой этап зрелости и своё время выхода в production.

Слой 1. Данные объекта (паспорт как ядро)¶

Всё остальное строится на этом слое. Пока паспорт не полный и не переносимый — ни маркетплейс, ни внешние тенанты, ни on-premise не работают.

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

Идеал: любой объект можно экспортировать одним архивом и импортировать в другой инстанс платформы без потерь.

Слой 2. Операционный контур (что делается вокруг паспорта)¶

Как объект живёт день ото дня после приёмки: заявки, работы, документы, отчётность.

Что входит: заявка → объект → договор → смета → счёт → акт с автосинхронизацией в «Моё Дело»; управление исполнителями (свои и партнёры) с назначением на объект, ставками, сменами, начислениями; работа с материалами по движению; управление кабинетами клиентов и мастеров.

Идеал: любая работа проходит по единой цепочке от заявки до акта; исполнитель получает полный контекст; клиент видит статус в своём кабинете.

Слой 3. Коммерческие контуры (как платформа зарабатывает)¶

Модель монетизации: два основных контура плюс вспомогательные услуги.

Что входит: контур мониторинга и реакции; контур маркетплейса работ; SaaS для внешних тенантов; корпоративный on-premise-контур; дополнительные линии услуг (IP-мониторинг, ИИ-агенты как услуга, активный мониторинг тревог, оцифровка, VPS-инфраструктура для клиента).

Идеал: предсказуемая абонентская модель поверх мониторинга, прозрачная маркетплейсная комиссия, понятная SaaS-цена для партнёрских тенантов.

Этапы: от текущей точки к идеалу¶

Этапы построены как лестница созревания слоёв. Каждый следующий этап опирается на закрытые предыдущие. Внутри этапа задачи выполняются параллельно, между этапами — последовательно.

Этап 0. Стабилизация текущего контура¶

Цель: снять критический технический долг и мелкие регрессии, чтобы дальше не тормозило.

Что делаем:

Ротация всех унаследованных секретов
Разбор оставшихся регрессий в CRM-контуре
Второй VPS в российской юрисдикции как staging/DR-контур — снимает вопрос КИИ на переговорах и даёт безопасное место для крупных изменений
Финальная сборка руководства по эксплуатации в базе знаний

Этап 1. Завершение паспорта объекта и мультитенантности¶

Цель: довести слои 1 и 2 до состояния, когда любую новую задачу можно писать в архитектуре мультитенантности без страха переписки.

Что делаем:

Полный разнос идентификаторов тенанта по данным, middleware, изоляция файлов, аудит
Перевод основной БД в промышленную СУБД как техническая предпосылка мультитенантности
Единый жизненный цикл документов: договоры → допники → счета → акты → сметы в связной цепочке с версионированием
Единая связка «заявка → объект» с автоматическими переходами по оплате и финансовой сводкой
Двухмерная изоляция знаний в RAG (по тенанту и по объекту)

Параллельно идут первые платные продажи текущему тенанту — платформа боевая, продажи не ждут завершения архитектуры.

Этап 2. Контур мониторинга и реакции как коммерческий продукт¶

Цель: первый контур монетизации становится продаваемой услугой с прозрачной ценой и договором.

Что делаем:

Модуль активного мониторинга инженерных систем: сетевая доступность, статус потока видеокамер, целостность архива, статус тревог, состояние резервного питания
Регламент событий: справочник типов событий, правила эскалации, каналы уведомлений (email, мессенджеры, SMS, звонок)
ИИ-агент диспетчерского слоя: автоматическая классификация события, выбор канала реакции, подтверждение оператором для эскалации к внешним службам
Договор мониторинга, прайс, типовые SLA-пакеты
Партнёрство с лицензированным охранным предприятием под ГБР для реагирования
Внутренняя приборная панель мониторинга по всем объектам на обслуживании

Этап 3. Контур маркетплейса работ¶

Цель: второй контур монетизации — заявки на работы распределяются в пул исполнителей по паспорту объекта.

Что делаем:

Управление пулом исполнителей: профили внешних подрядчиков, специализации, географическая привязка, история работ, рейтинг
Правовая рамка: платформа как агент между заказчиком и исполнителем либо как заказчик работ у подрядчика
Модуль назначения заявки: правила распределения (география, специализация, загрузка, рейтинг)
Мобильный интерфейс исполнителя: получение задачи, паспорт объекта, чеклист работ, фото-подтверждение
Финансовый контур: удержание комиссии, автоматические выплаты исполнителям, документооборот с ФНС
Приёмка работ клиентом: акт от платформы, рейтинг исполнителя

Этап 4. Внешние тенанты и корпоративный контур¶

Цель: платформа продаётся не только своим объектам, но и партнёру или корпоративному заказчику как SaaS с изолированным контуром.

Что делаем:

Тарифная модель тенанта, UI переключателя, onboarding нового тенанта, разделение справочников на глобальные и tenant-local, изоляция ИИ-контекста по тенанту
Публичный self-serve onboarding: страница «создать компанию», автосоздание тенанта, seed данными, выбор тарифа
Аттестация ФСТЭК под профиль корпоративного заказчика при появлении конкретного клиента
On-premise-инсталляция как отдельный конфигурационный контур с документированным разворачиванием у заказчика

Этап 5. Дополнительные линии услуг (параллельно, начиная с этапа 2)¶

Цель: нарастить портфель услуг поверх основных контуров без риска для магистрали.

Что делаем (по мере входа реального спроса):

Мониторинг IP-инфраструктуры и удалённое администрирование как отдельный продукт
ИИ-агенты ролей (секретарь, сметчик, делопроизводитель) как отдельные подписки внутри тенанта
Оцифровка документов, архивная работа
VPS-инфраструктура и настройка удалённого доступа для клиента как отдельный продукт
Услуги смежного юрлица (частный сектор, печать, реставрация) как отдельная витрина, использующая ту же платформу через второй тенант

Ключевой принцип последовательности¶

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

Продажи не ждут завершения архитектуры. Магистраль — это фундамент, на котором первые продажи уже идут. Каждый новый этап расширяет ассортимент того, что можно продать, — но продажи не останавливаются.

Что этот документ не решает¶

Специально не входит в концепцию, чтобы не размывать магистраль:

DeFi-анализатор — отдельный проект, живёт своим циклом
Alatyr Taverna — соседний бренд, не пересекается с сервисной платформой
Строительный контур — денежный источник, отдельный от платформы, но продолжает работать как двигатель денежного потока и источник кейсов
Земля, эко-ферма и глэмпинг — долгосрочный проект вне текущего roadmap

Все они остаются в общей бизнес-системе, но не влияют на порядок задач в alatyr-service.