Разбор техник BABOK: Моделирование решений

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

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

Техника BABOK «Моделирование решений» (Decision Modelling) предназначена для представления этой логики в явном виде. Она позволяет исследовать, какие решения принимает организация, какая информация для этого необходима и какие знания определяют результат.

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

Назначение техники

Согласно BABOK, назначение моделирования решений состоит в том, чтобы показать, как принимаются повторяемые бизнес-решения.

Ключевое слово здесь «повторяемые». Речь идет прежде всего о ситуациях, для которых можно определить входную информацию, применяемые правила и возможные результаты.

Например, решение о предоставлении клиенту отсрочки платежа может зависеть от истории сотрудничества, суммы заказа, просроченной задолженности и установленной кредитной политики. Если эти зависимости известны, их можно представить в модели, проверить на согласованность и использовать повторно.

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

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

Описание техники

Модель решения показывает, каким образом данные и знания объединяются для получения определенного результата.

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

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

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

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

В моделях могут учитываться определяющие и поведенческие бизнес-правила. Первые устанавливают характеристики и зависимости, вторые предписывают или ограничивают поведение.

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

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

Элементы техники

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

При этом для всех подходов существенны три составляющие: решение, информация и знания.

Таблицы решений

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

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

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

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

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

Деревья решений

Дерево решений представляет собой логику последовательной проверки условий.

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

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

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

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

Диаграммы требований к решениям

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

BABOK описывает четыре типа элементов такой диаграммы:

1. Решения. Представляются прямоугольниками и обозначают результаты, которые необходимо определить.
2. Входные данные. Представляются овалами и обозначают информацию, необходимую для принятия решений.
3. Модели бизнес-знаний. Представляют используемую логику: наборы правил, таблицы, деревья или аналитические модели.
4. Источники знаний. Обозначают документы или людей, выступающих источниками соответствующей логики.

Между элементами используются три типа связей.

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

Таким образом, диаграмма позволяет ответить не только на вопрос «Как принимается решение?», но и на вопросы «Что для него необходимо?» и «Откуда взялись соответствующие правила?».

Практическое применение

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

Например, «Определить допустимые условия оплаты заказа» является решением, тогда как «Проверить карточку клиента» представляет собой действие процесса.

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

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

Завершается работа согласованием модели с заинтересованными сторонами и определением порядка ее дальнейшего изменения.

Практический пример

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

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

Задача бизнес-аналитика состоит в формализации решения «Определить условия оплаты заказа».

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

Предположим, что организация утвердила четыре правила:

• При наличии просроченной задолженности отсрочка не предоставляется.
• При отсутствии задолженности и достаточном лимите постоянный клиент получает отсрочку на 30 дней.
• При отсутствии задолженности и достаточном лимите новый клиент получает отсрочку на 10 дней.
• Если доступного лимита недостаточно, заказ оформляется по предоплате независимо от категории клиента.

Эти правила можно представить таблицей:

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

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

Теперь давайте рассмотрим декомпозицию решения.

Общее решение «Определить условия оплаты» зависит от двух промежуточных решений: «Допустима ли отсрочка?» и «Какова продолжительность отсрочки?».

Первое использует данные о задолженности и кредитном лимите. Второе использует категорию клиента и результат первого решения.

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

Если кредитную политику утверждает финансовый директор, соответствующая связь позволит показать источник полномочий для используемой логики.

После построения модели бизнес-аналитик проверяет конкретные ситуации.

Например, постоянный клиент оформляет заказ на 300 000 рублей. Просроченной задолженности нет, доступный лимит составляет 500 000 рублей. Результат: отсрочка 30 дней.

Другой постоянный клиент оформляет заказ на ту же сумму, но располагает лимитом только 200 000 рублей. Результат: предоплата.

Наконец, новый клиент без задолженности и с достаточным лимитом получает отсрочку на 10 дней.

Все три результата следуют из одной модели, независимо от того, какой менеджер обрабатывает заказ.

Хорошие и плохие практики

Эффективная практика предполагает моделирование конкретного решения с четко определенными входами и результатами.

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

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

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

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

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

Типичные ошибки

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

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

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

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

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

Не менее губительно отсутствие источников знаний. Правила зафиксированы, но неизвестно, кто их установил и кто вправе изменять.

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

Практические рекомендации

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

Перед построением подробной модели полезно сформулировать три вопроса: какое решение принимается, на основании какой информации и с использованием каких знаний?

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

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

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

При работе с несколькими подразделениями необходимо отдельно согласовывать терминологию. Формально одинаковое название показателя еще не гарантирует одинаковый способ его расчета.

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

Ограничения техники

BABOK отмечает несколько преимуществ моделирования решений.

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

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

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

Вместе с тем BABOK указывает и на существенные ограничения.

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

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

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

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

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

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

Вместо заключения

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

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

BABOK предлагает для этого три взаимодополняющих подхода: таблицы решений, деревья решений и диаграммы требований к решениям.

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

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

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