Правила совместимости в CPQ: как запретить неверную конфигурацию до расчёта цены

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

Что такое правила совместимости в CPQ и зачем они нужны

Правило совместимости — это записанное в систему условие вида «если выбрано А, то допустимо только Б». Например: «если установлен бак на 500 литров, насос допускается с напором до 8 метров» или «если объект в сейсмическом районе, обязательна усиленная рама». Проверка происходит в интерфейсе, а не в голове инженера и не в переписке с производством.

От правил ценообразования они отличаются предметом. Скидочная матрица отвечает на вопрос «сколько это стоит», правила совместимости — «можно ли это вообще собрать и продать». Держать их в одной таблице удобно только на старте: дальше она превращается в нечитаемую конструкцию, в которой никто не может найти виновника ошибки.

Чем правило в системе отличается от проверки менеджером

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

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

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

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

Дальше начинается переделка: замена позиции, пересчёт цены, новый срок, звонок клиенту с извинениями. Если изделие уже частично изготовлено, часть затрат списывается в убыток. Если ошибку нашёл дилер на объекте — к затратам добавляется репутационный счёт, который выставляют не деньгами, а снижением доверия.

Какие типы правил описать в первую очередь

Описывать всё сразу не нужно: проект утонет в согласованиях. Начните с типов, которые закрывают основную часть ошибок в вашей номенклатуре. На практике это пять категорий.

Зависимости: «выбрал А — нужен Б»

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

Зависимости бывают односторонними и двусторонними. Если А требует Б, это не значит, что Б требует А. Путаница в направлении связи — типичная причина того, что система не даёт собрать корректный комплект.

Запреты: «А не сочетается с Б»

Запрет проще и жёстче зависимости. Он нужен там, где совместная установка технически невозможна или запрещена нормами: например, определённый тип автоматики не ставится на изделие с открытой камерой сгорания.

Запреты стоит формулировать максимально узко. Правило «эта серия несовместима с той серией» часто оказывается избыточным: несовместимы только два конкретных исполнения, а всё остальное прекрасно работает. Чем точнее запрет, тем меньше законных заказов он отсекает.

Количественные ограничения: минимум, максимум, шаг

Это правила про числа, а не про сочетания. Минимальная партия, максимальное количество секций, кратность упаковки, допустимый диапазон мощности. Они же закрывают ошибки ввода, когда менеджер пишет «3,5 штуки» или ставит количество ниже технологического минимума.

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

Инженерные расчёты: правило как формула

Часть ограничений — не таблица сочетаний, а расчёт. Расход воздуха зависит от площади сечения, напор — от длины трассы, теплопотери — от объёма помещения и сопротивления ограждающих конструкций. В CPQ это описывается формулой, которая пересчитывает допустимые варианты при каждом изменении параметров.

Именно этот тип правил чаще всего остаётся «в Excel у инженера». Пока расчёт живёт в отдельном файле, он не связан с прайсом и не проверяется автоматически. Перенос формул в систему — самая трудоёмкая, но и самая ценная часть проекта: она убирает разрыв между техническим подбором и коммерческим предложением.

Коммерческие и логистические ограничения

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

Здесь важно не превратить систему в бюрократический лабиринт. Коммерческое ограничение должно либо предлагать альтернативу, либо честно сообщать срок и условие, а не просто блокировать заказ.

Откуда брать правила, если они нигде не записаны

Главная сложность CPQ — не программирование, а извлечение знаний. Большая часть правил существует в виде опыта конструкторов, сервисных инженеров и начальника производства. Никто не держит их в документе, потому что «это же очевидно».

Разговор с конструкторами и сервисом

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

Полезный приём — просить не общее описание, а конкретные случаи. «Покажите три последних заказа, которые пришлось переделывать» работает лучше, чем «расскажите про правила совместимости». Из конкретных случаев правила извлекаются почти механически.

Рекламации и возвраты как источник правил

Гарантийные обращения — это готовый список того, что система должна была запретить. Если один и тот же узел регулярно выходит из строя в определённой комплектации, значит, либо правило отсутствует, либо оно есть, но не применяется.

Стоит просмотреть рекламации за последние полгода и отметить повторяющиеся сочетания условий. Каждое повторение — кандидат в правило. Это дешевле, чем ждать, пока проблема проявится в крупном заказе.

Как отличить правило от привычки

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

Проверочный вопрос простой: «что произойдёт, если это правило нарушить?». Если ответ — «получится брак, отказ, нарушение норм или невозможность сборки», это правило. Если ответ — «нам будет неудобно», это привычка, и её место в комментарии, а не в блокировке.

Как сформулировать правило, чтобы его поняли все

Правило живёт долго только тогда, когда его можно прочитать и проверить без разработчика. Поэтому формулировка важна не меньше логики.

Формула «условие — следствие — сообщение»

Каждое правило стоит описывать тремя частями. Условие: при каких обстоятельствах оно срабатывает. Следствие: что разрешено, запрещено или обязательно. Сообщение: что увидит пользователь и что ему делать дальше.

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

Текст ошибки, который помогает, а не раздражает

Сообщение «недопустимая комбинация опций» бесполезно. Оно не говорит, какая опция виновата и что делать. Хороший текст называет конфликт и предлагает выход: «выбранный насос не работает с баком 500 л — доступны баки 300 или 750 л».

Правильный текст ошибки экономит звонок инженеру. Пользователь не должен расшифровывать логику системы — система должна объяснить её сама, в одном предложении и на языке продаж, а не на языке кода.

Кто владеет правилом после запуска

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

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

Как проверить правила до запуска

Логику нельзя проверить «на глазок»: она проявляется только на реальных сочетаниях. Поэтому тестирование строят на истории заказов, а не на выдуманных примерах.

Прогон по реальным заказам за последний год

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

Такой прогон одновременно проверяет правила, прайс и интерфейс. Он же даёт менеджерам понятный аргумент: система воспроизводит их реальную работу, а не абстрактную схему из презентации.

Поиск «дыр»: конфигурации, которые проходят, но не собираются

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

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

Что делать с законными исключениями

Исключения будут всегда: нестандартный объект, старый парк оборудования, индивидуальный заказ крупного клиента. Запрещать их полностью — значит терять выручку. Разрешать всем — значит терять смысл правил.

Рабочая схема — правило плюс согласование. Система блокирует комбинацию, но предлагает запросить исключение с обоснованием; запрос уходит ответственному, решение фиксируется в истории заказа. Так исключение остаётся редким и управляемым, а не превращается в новую норму.

Что правила совместимости дают бизнесу

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

Второй эффект — меньше переделок. Ошибка, пойманная на этапе выбора, стоит ноль. Ошибка, пойманная на сборке, стоит материалов, времени, логистики и репутации. Разница между этими двумя точками и есть основная экономика проекта.

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

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

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

Как это связано с ценой, спецификацией и производством

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

Дальше в работу вступает цена. Она считается по правилам из скидочной матрицы уже для проверенной конфигурации, поэтому коммерческий расчёт не приходится переделывать после замечаний производства.

Если объяснить общую логику в одном месте, получится CPQ-система — контур, где подбор, цена, документ и заказ связаны одной моделью данных. Отдельные инструменты при этом остаются полезными: конфигуратор продукта решает задачу визуальной сборки, а правила совместимости обеспечивают корректность на любом уровне сложности.

Сроки и бюджет такого проекта зависят в первую очередь от объёма правил, а не от количества экранов. Ориентиры по стоимости есть в разделе цен, а оценку под свою номенклатуру можно получить через заявку на старт проекта.

Частые вопросы

Больше материалов — в блоге WOID, посмотреть инструменты — калькуляторы.