Кейсы 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
Ключевой принцип: конфигурация — не задача разработчиков. Конфигураторы и интеграторы получают готовые профили, а не правят код. Это ускоряет внедрение и снижает риски.