Читать онлайн «Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0». Страница 99

Хотя многие средства EA используют символы BPMN, взаимодействие их с BPMS складывается непросто. Это может быть проблемой, так как означает сосуществование двух наборов моделей, которые легко могут разойтись.

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

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

Машины бизнес-правил[206] обеспечивают выявление, описание и оптимизацию технологических и бизнес-правил. Также они предоставляют репозиторий, с помощью которого правила сопоставляются друг с другом на предмет конфликтов в определении или в контексте, обеспечивая тем самым их качество и отсутствие дублирования. Для сегодняшних движков характерен технический уклон, и их использование требует обучения и компетенции в технологиях.

На практике правила выглядят как выражения «если – то»: «если» (событие или значение), «то» сделать что-то. Поскольку список вещей, которые надо учитывать при принятии решений, может быть достаточно длинным и сложным, определение правил может оказаться серьезной задачей.

Обычно каждое правило можно отнести к одной из следующих категорий:

• правила функционирования бизнеса;

• правила принятия решений;

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

• процедурные правила и политики;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• историческая и текущая аналитика;

• развертывание правил для использования в приложениях и в BPMS.

• Валидация используемых правилами данных.

• Использование, редактирование, тестирование данных, работа с унаследованными данными.

Эффект, которого можно ожидать от использования машины бизнес-правил:

• экстернализация и стандартизация правил и словаря;

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

• более быстрое изменение ПО благодаря полной информации о правилах и использующих их программах;

• гибкое описание правил – унаследованные приложения, пояснения, документы;