Бизнес-правила противоречат друг другу: как найти пробелы до настройки процесса

Одна заявка, два уверенных ответа

Сотрудник просит оборудование и отмечает заявку как срочную. Аналитик читает правила: оборудование направляется в закупки, срочные заявки — дежурному. Оба пункта понятны. Но кто должен получить именно эту заявку? Разработчик предлагает поставить проверку срочности первой. Представитель закупок считает, что вид заявки важнее. В документе ни того, ни другого нет.

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

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

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

Что именно мы проверяем

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

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

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

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

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

Сначала перечислим возможные входы

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

Получается 2 × 3 × 2 = 12 сочетаний. Это число не измеряет поток реальных обращений. Оно задаёт размер конечной области, которую мы намерены проверить полностью. Заявка без обоснования входит в эту область, хотя последующее решение может вернуть её инициатору. «Допустимо получить на входе» и «разрешено исполнять» — разные условия.

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

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

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

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

Три исходных правила и полный перебор

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

Теперь проверим каждое сочетание против всех строк. Мы не останавливаемся на первом совпадении. Результат ниже воспроизведён собственным расчётом НТА; это синтетический опыт, а не журнал работы BPMSoft.

Получены семь входов с единственным совпадением, два конфликта и три пробела. Можно проверить результат вручную: всё оборудование подходит R1, все срочные заявки — R2, а R3 добавляет только обычный доступ с обоснованием. Пересечение первых двух строк находится в срочном оборудовании независимо от наличия обоснования.

×

Полный перебор 12 сочетаний учебной модели: 7 единственных совпадений, 2 конфликта и 3 пробела. Это не статистика реальных заявок.

Особенно полезны строки 2, 5, 6 и 10. Они однозначны, но отправляют дальше заявки без обоснования или без срочности. Перебор не объявляет такое поведение ошибкой: исходные правила именно это разрешают. Если владелец хотел обязательного уточнения, в документе недостаёт его решения. Так обнаруживается граница между логической проверкой и проверкой смысла.

Почему пересечение ещё не всегда противоречие

Добавим только для рассуждения четвёртую строку, повторяющую R3: обычный доступ с обоснованием направляется в ИТ. Для входа №7 теперь подходят две строки, но различных ответов по-прежнему один. Это избыточность или разрешённое пересечение — в зависимости от выбранных правил таблицы. Называть его конфликтом маршрутов было бы неточно.

Спецификация OMG DMN 1.5, раздел 8.2.11.1 различает способы обработки совпадений. Unique требует отсутствия пересечений; Any допускает совпавшие строки с одинаковыми выходами; First выбирает первую подходящую строку. Priority использует приоритет выходных значений, а не порядок строк. Отсутствие пересечений само по себе не доказывает полноту покрытия.

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

Есть ещё практическая тонкость: сравнивается весь результат. Если обе строки назначают ИТ, но одна задаёт другой срок или уведомляет другого участника, выходы уже могут различаться. В нашей модели результат состоит только из маршрута. Расширение результата потребует расширить сравнение; одного совпадения названия очереди станет недостаточно.

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

Пустое значение требует собственного смысла

«Срочность не указана» в нашем примере означает отсутствие сведения. Это не доказательство обычной срочности. Если заменить неизвестное значение обычным, вход №11 станет похож на №7 и получит маршрут ИТ. Пробел исчезнет, но вместе с ним исчезнет различие, которое никто не разрешал устранять.

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

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

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

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

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

Что на самом деле делает приоритет

Вернёмся к срочному оборудованию. Если читать R1 раньше R2 и брать первое совпадение, ответом будут закупки. Если поменять их местами, ответом станет дежурный. Условия и текст результатов не изменились, однако для входов №3 и №4 изменилось поведение. Это подтверждено повторным расчётом нашего примера.

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

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

Приоритет самих результатов — ещё один вариант. Можно договориться, что определённый выход сильнее другого независимо от расположения строк. Но надпись «важнее» требует предметного основания: кто имеет право задать эту иерархию и относится ли она ко всем входам? Число в служебной колонке не создаёт такого полномочия.

Наконец, ветка «иначе» закрывает только вопрос отсутствия совпадений, если действительно применяется после проверки остальных строк. Она не устраняет их пересечение. Если отправить все непокрытые входы в ИТ, пробелы исчезнут, но два конфликта останутся. А неизвестная срочность получит действие, которое владелец ещё не выбирал. Удобный ответ проверяющего не должен стать скрытым автором регламента.

Как превратить находку в вопрос владельцу

Сообщение «правила противоречат друг другу» слишком общее. Владелец может согласиться с ним, не приняв никакого решения. Лучше показать вход №3: оборудование, срочная заявка, обоснование есть. Далее привести R1 с ответом «закупки» и R2 с ответом «дежурный», после чего спросить, какой один следующий маршрут требуется.

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

Для пробела вопрос другой. Возьмём вход №11: доступ, срочность не указана, обоснование есть. Здесь нет двух конкурирующих ответов. Нужно выбрать обработку отсутствующего сведения или подтвердить, что такой вход не должен доходить до этой точки. Подтверждение недопустимости требует реального ограничения на входе, а не удаления неудобной строки из отчёта.

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

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

Исправленная таблица после явного решения

Чтобы завершить опыт, зададим сценарное решение условного владельца. Это не реально полученное согласование клиента. Без обоснования заявка возвращается инициатору. При обосновании и неизвестной срочности требуется уточнение. Обоснованная срочная заявка передаётся дежурному. Обоснованная обычная заявка на оборудование идёт в закупки, на доступ — в ИТ.

Теперь запишем решение пятью непересекающимися строками. Каждая строка содержит все необходимые ограничения; перестановка строк не должна менять ответ.

Почему строки не пересекаются? N1 отличается от остальных наличием обоснования. Среди заявок с обоснованием N2, N3 и последние две строки разделены срочностью. N4 и N5 различаются видом заявки. Почему покрытие полное? Каждый вход сначала относится к одному из двух состояний обоснования; при его наличии три значения срочности исчерпываются, а обычные заявки делятся по двум видам. Здесь полнота следует из объявленной области, а не из количества строк.

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

×

Сценарное решение задано до расчёта. Все 12 входов имеют один результат; все 120 перестановок пяти строк сохраняют ответ.

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

Как перенести результат в BPMSoft

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

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

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

В ISTQB CTFL 4.0.1, раздел 4.2.3 покрытие таблицы решений связано с проверкой допустимых сочетаний условий. Наш набор мал, поэтому можно проверить его целиком. Для сложного процесса сокращение набора требует отдельного обоснования; несколько удачных примеров нельзя называть полным покрытием.

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

Где заканчивается доказательство

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

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

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

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

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

Рабочая карточка одного спорного входа

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

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

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

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

Где уместна помощь НТА

Если спорное правило связано с неясными ролями или данными, полезно начать с обследования, а не с размещения элементов на схеме. Такой порядок раскрыт в материале о внедрении CRM без автоматизации старых ошибок. НТА может помочь описать процесс, согласовать условия и подготовить проверяемую реализацию на BPMSoft. Это проектная работа, а не обещание готовой кнопки поиска всех противоречий.

Если вопрос шире одной точки решения, стоит вернуться к тому, когда компании нужна BPM-система. Таблица отвечает за конкретный выбор. Управление целым процессом дополнительно требует состояний, ответственности, сроков и обработки исключений. Хорошо составленное правило полезно в этой работе, но не заменяет её.

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

Тест понедельником

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

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

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

Важное уведомление

Материал носит информационный характер и не является индивидуальной консультацией, проектной документацией, инструкцией по внедрению или гарантией результата. Применимость описанных подходов зависит от процессов, систем, данных, требований безопасности и иных условий конкретной организации. Перед внедрением или изменением ИТ‑систем необходимо самостоятельно оценить риски и привлечь профильных специалистов.