Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0

• правила использования/защиты данных;

• правила разграничения доступа;

• правила мониторинга и отчетности;

• технические правила, связанные с запросами к данным, преобразованием данных, интерфейсами между приложениями и т. п.;

• юридические правила;

• финансовые правила;

• правила мониторинга и измерений;

• нормативные правила.

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

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

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

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

Все это серьезным образом влияет на выбор и использование машины бизнес-правил. Это также объясняет тот факт, что многие проекты инициирует IТ-подразделение, которому необходимо описать работу приложений. Вне зависимости от того, кто инициирует движение к выявлению, описанию и рационализации правил, технология должна предусматривать ввод правил множеством бизнес-подразделений и последующее их слияние в едином репозитории, дающее на выходе единое описание, версии, синонимы, антонимы и т. п. с надлежащим контролем качества. Эти требования должны быть учтены в возможностях обращаться к правилам, ограничивать доступ и менять их. Машина бизнес-правил должна соответствовать требованиям, которые будут к ней предъявляться в вашей компании.

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

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

Типичные сценарии использования репозитория правил таковы.

Централизованная кодификация знаний организации:

• описание шаблонов правил для взаимодействий с клиентами, таких как соответствие требованиям, кросс-продажа, продажа более дорогого товара и т. д., включающих:

• скоринг-карты – на основе скоринга и ранжирования;

• деревья решений – на основе логики «если – то»;

• карты решений – на основе значений одной или двух переменных;

• таблицы решений – на основе последовательности проверочных условий;

• создание, согласование, тестирование и внедрение правил;

• хранение правил, обеспечивающее доступ к правилам для всей организации.

Поиск имеющихся описаний правил для целей:

• определения последовательности выполнения шагов в ходе моделирования процесса;

• генерации приложений BPMS;

• модернизации унаследованных приложений;

• определения требований к интерфейсам унаследованных приложений.

Поддержка вызова правил из программ и контроль за использованием правил:

• устранение конфликтов и избыточности правил;

• выявления правил, которые больше не соответствуют правовым требованиям;

• повышение качества правил – ясность, целостность, отсутствие дублирования.

Анализ SLA, KPI, улучшения по методике шести сигм и т. п.

Управление качеством и обеспечение согласованности правил и наборов правил:

• управление изменениями правил;

• управление созданием новых правил;

• информирование обо всех точках обращения к правилу для оценки последствий его изменения;

• тестовое использование правила;

• управление доступом к правилам.

Анализ взаимосвязи правил и их использования по схеме «что, если»: