Кейсы CodeVibers / LikeXR Спроектировать внедрение

LikeVR ERP: внутренняя система как продукт

Внутренняя ERP-система LikeVR — это не просто инструмент, а потенциальный продукт. Мы разбираем, как вынести её за пределы компании, сохранив гибкость, безопасность и скорость.

Что такое «внутренняя система как продукт»?

Это подход, при котором внутренняя ИТ-система (например, ERP, CRM, автоматизация склада) проектируется и развивается не только под текущие нужды компании, но и с учётом потенциальной коммерциализации: выделение API, модульности, документации, контроля доступа и масштабируемой архитектуры. В случае LikeVR — ERP-система, изначально созданная для управления производственными процессами, теперь может быть адаптирована под клиентские нужды без переписывания с нуля.

Архитектурный паттерн: «ERP-ядро + модули»

flowchart TD
    A[Клиентский интерфейс] --> B[API Gateway]
    C[Внутренние сервисы (LikeVR ERP)] --> D[Ядро: данные, бизнес-логика, агенты]
    D --> B
    B --> E[Модуль: склад]
    B --> F[Модуль: производство]
    B --> G[Модуль: финансы]
    D --> H[AI-агенты: прогноз, оптимизация]
    style D fill:#2d3b4e,color:#fff
    style B fill:#4a5f75,color:#fff

Ядро — единый источник данных и бизнес-правил. Модули — независимые слои, подключаемые по API. Такой подход позволяет легко адаптировать систему под клиента, не ломая ядро.

Пример: как LikeVR ERP обрабатывает заказ

1. Клиент (внутренний или внешний) отправляет запрос через API: POST /orders с данными о продукте, объёме, сроке.

2. API Gateway проверяет токен, логирует запрос и передаёт в OrderProcessingAgent.

3. Агент проверяет наличие ресурсов, запускает оптимизацию графика и создаёт задачи для модулей: «склад», «производство», «логистика».

4. Каждый модуль возвращает статус в ядро; изменения фиксируются в единой БД (PostgreSQL + TimescaleDB).

5. Результат возвращается клиенту через API, а лог агента сохраняется в отдельный поток (Kafka).

Псевдокод: API-обработчик заказа

// Псевдокод: обработчик заказа в API-слое
POST /orders
{
  "client_id": "c_123",
  "product_id": "p_456",
  "quantity": 100,
  "deadline": "2025-09-15T10:00:00Z"
}

// Внутри обработчика:
const order = validateAndNormalizeOrder(req.body);
const agent = new OrderProcessingAgent({
  context: { client_id, product_id },
  tools: [inventoryCheck, productionScheduler, logisticsPlanner],
  permissions: { can_override_deadline: false }
});
const result = await agent.run(order);
return { status: 'success', order_id: result.id, eta: result.eta };

Типичные ошибки при «продуктизации» ERP

  • Смешение конфигурации и кода — жёстко зашитые правила под текущий бизнес-процесс. Решение: вынос правил в конфигурационные профили (JSON/YAML) с версионированием.
  • Отсутствие audit trail — невозможно отследить, кто и когда изменил данные. Решение: логирование всех изменений в отдельный поток (Kafka + ClickHouse).
  • Один API на всех — внутренние и внешние клиенты используют один эндпоинт. Решение: разделение на /internal/* и /public/* с разными правилами валидации и квотами.

Чеклист: что проверить перед выводом ERP на внешний рынок

  • ✅ Все бизнес-правила вынесены в конфигурацию (без hardcode)
  • ✅ Есть полная документация API (OpenAPI 3.0)
  • ✅ Поддержка OAuth2 + JWT с гранулярными ролями
  • ✅ Аудит всех изменений в БД (включая soft delete)
  • ✅ Модульность: каждый модуль — отдельный сервис/модуль в коде
  • ✅ Агенты с fallback и Human-in-the-loop (см. @code_vibers)
  • ✅ Тесты нагрузки и отказоустойчивости (chaos engineering)

Роли и ответственность в ERP-продукте

flowchart LR
    subgraph "Управление"
        CTO[CTO / digital-директор] -->|стратегия| PROD[Продакт]
        PROD -->|требования| DEV
    end

    subgraph "Разработка"
        DEV[Dev-команда] -->|API| INTEG[Интегратор]
        DEV -->|конфиг| CONFIG[Конфигуратор]
    end

    subgraph "Эксплуатация"
        CONFIG -->|профиль| CLIENT[Клиент]
        INTEG -->|интеграция| CLIENT
        CLIENT -->|обратная связь| PROD
    end

    style DEV fill:#2d3b4e,color:#fff
    style PROD fill:#4a5f75,color:#fff

Ключевой принцип: конфигурация — не задача разработчиков. Конфигураторы и интеграторы получают готовые профили, а не правят код. Это ускоряет внедрение и снижает риски.