Правило, которое знают все, но никто не проверял
«Отгружаем только при подписанном акте». «Скидку больше 15 % согласует финансовый директор». «Отдел не может подчиняться собственному подотделу». Такие правила есть в каждой компании. Обычно они живут в регламенте, в голове главного бухгалтера и в сотне исключений, о которых помнит один человек.
Проблемы начинаются на стыках. Скидка 15 % — это «больше 15» или «15 и больше»? Что делать, если акт подписан, но оплаты нет, а клиент постоянный? Когда правил десяток, противоречия между ними не видит никто, пока не случится спорная отгрузка. А если такие вопросы решает ИИ, он может уверенно ошибиться.
LOGUS решает это по принципу «логику не угадывают, её считают». Правило становится процессом, который можно запустить, проверить на всех значениях и показать, почему ответ именно такой.
Как LOGUS работает вместе с другими сервисами
LOGUS — общий движок логики для всей системы, поэтому его правила работают там, где идёт сама работа.
- Оргструктура. TEAMUS проверяет оргсхему через LOGUS: нет ли колец подчинения, когда отдел в итоге подчиняется сам себе. Это первый и постоянный потребитель движка.
- Задачи. В TASKUS логика запускается прямо на холсте: процесс согласования рисуется рядом с задачами и выполняется на настоящих данных.
- ИИ-сотрудники. Агенты из AGENTUS отдают LOGUS вопросы «можно или нельзя», «сколько положено», «какой статус дальше» и получают ответ с уровнем доверия, а не правдоподобную догадку.
- Производство. В OPTIMUS на LOGUS построен конфигуратор изделий: какие сочетания параметров допустимы, а какие нет.
- Личный ассистент. В Assistentus есть помощник «Логос»: правило можно описать голосом или текстом, а схема сохранится заметкой.
Что делает ИИ, а что считает движок
Разделение здесь важное. ИИ помогает сформулировать: превращает ваше описание в схему, пишет проверочные сценарии по тексту задания, предлагает точечные правки. А проверяет не ИИ, а решатель и прямой перебор вариантов.
Поэтому каждый ответ LOGUS идёт с честной пометкой:
- Доказано — правило проверено решателем или полным перебором всех входов;
- Пересчитано дважды — результат посчитан двумя проходами одного вычислителя;
- Вычислено — результат посчитан один раз;
- Оценено — полной проверки не было, и это сказано прямо;
- Расхождение — расчёты не сошлись, нужна проверка человеком.
Если правило неверно, LOGUS не просто говорит «ошибка», а приводит контрпример: «при сумме 15 000 и статусе „постоянный“ отгрузка без акта разрешена, хотя не должна». Если правила противоречат друг другу, он показывает наименьший набор конфликтующих правил — понятно, что именно переписывать.
Пример: правило скидок за пять минут
Допустим, руководитель продаж пишет: «Скидка до 10 % — решает менеджер. От 10 до 20 % — руководитель отдела. Больше 20 % — финансовый директор. Постоянным клиентам можно на 5 % больше без согласования».
LOGUS строит из этого процесс с формой ввода: размер скидки, статус клиента, кто согласовал. Затем сам пишет сценарии проверки по тексту задания и прогоняет граничные значения: 10 %, 10,01 %, 20 %, 25 % для постоянного клиента. На одном из них выясняется, что правило «плюс 5 %» позволяет менеджеру дать постоянному клиенту 14,9 % без руководителя, хотя руководитель имел в виду другое. Это видно до того, как деньги ушли, а не на разборе квартала.
После правки правило получает отметку «Доказано», а ИИ-агенты и сотрудники начинают пользоваться им одинаково. Новая версия правила не стирает старую: в журнале видно, что и когда изменилось.
Как внедряется
Первые правила обычно появляются сами во время внедрения PRANUS: оргструктура, которую строит агент внедрения, сразу проверяется LOGUS. Дальше вы добавляете правила по мере надобности — описываете словами, проверяете на граничных значениях и подключаете к задачам или ИИ-агентам. Отдельного проекта по «моделированию процессов» не нужно.
Для кого
- Собственникам и руководителям, которые хотят, чтобы правила компании выполнялись одинаково, а не по памяти.
- Финансистам и юристам: лимиты, согласования, условия отгрузки и скидок, которые нельзя нарушить.
- Аналитикам и тем, кто описывает бизнес-процессы: таблицы решений и состояния заказа проверяются на тупики до запуска.
- Командам, которые доверяют решения ИИ-агентам и хотят, чтобы агент не придумывал ответ там, где его можно посчитать.
Посмотреть, как ваше правило станет проверяемым процессом, можно на демонстрации PRANUS.