Построение моделей, регламентирующих принятие решений

Преимущества моделирования решений

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

• Моделирование решений делает бизнес-процессы менее сложными, более устойчивыми к изменениям и более простыми в управлении;
• Модель требований к принятию решений обеспечивает необходимую структуру для внедрения системы управления бизнес-правилами (BRMS), поддерживающую итерационную и гибкую разработку (Agile);
• Увязка проектов настройки интеллектуального анализа данных и прогнозной аналитики (BI системы и обработка Больших Данных) с моделью принятия решений связывает аналитику с бизнес-результатами и помогает обеспечить успешное развёртывание аналитических систем;
• Понимание решений, относящихся к информационной панели или среде поддержки принятия решений, структурирует знания и ставит во главу угла действия и результаты.

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

Ориентация на действия

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

Ценность формализации

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

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

Нетривиальность

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

Измеряемость воздействия

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

Типы решений

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

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

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

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

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

• Определить, имеет ли клиент право на получение льготы;
• Подтвердить полноту счета-фактуры;
• Рассчитать скидку на заказ;
• Оценить с каким поставщиком риск поставки меньше;
• Выбрать условия кредита;
• Отсортировать претензии для стандартной обработки

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

• Идентификация и/или авторизация – имеет ли этот клиент/потенциальный клиент/гражданин право на использование этого продукта/услуги?

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

• Проверка – действительно ли это требование или счёт-фактуру надо обрабатывать?

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

• Расчёт – какая цена/тариф правильна для этого продукта/услуги?

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

• Риск – насколько вероятна обещанная поставщиком дата доставки, и на какой скидке мы должны настаивать в случае её нарушения?

Принятие решения, которое включает оценку риска, будь то риск доставки или кредитный риск, требует сбалансированной политики, регулирования и некоторого формального анализа рисков. Использование бизнес-аналитики для оценки рисков в значительной степени заменило «внутреннюю проверку», а модели прогнозной аналитики позволяют встраивать такие оценки рисков непосредственно в ИТ системы;

• Мошенничество – насколько вероятно, что это заявление является мошенническим, и как мы должны его обработать?

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

• Бизнес-возможность – что представляет собой лучшую возможность максимизировать доход?

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

• Максимизация – как можно использовать эти ресурсы для достижения максимальной эффективности?

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

• Назначение – кто должен увидеть эту транзакцию следующей?

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

• Таргетинг – что именно мы должны сказать этому человеку?

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

Моделирование решений

Моделирование решений состоит из четырёх этапов, которые выполняются итеративно:

1. Определите решения.

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

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

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

Как идентифицировать решения?

Определение решений в процессах

При поиске решений в бизнес-процессах есть два основных ключа:

• Когда бизнес-процесс должен обрабатывать несколько сценариев, моделирование принятия решений в этом процессе с использованием только шлюзов и ответвлений может стать очень сложным. Гнёзда шлюзов с небольшим количеством промежуточных задач часто представляют собой процесс принятия решений, смоделированный в бизнес-процессе. Моделирование решений заменяет множество шлюзов единственной, явной точкой принятия решения – задачей принятия решения. Это проясняет поведение процесса, упрощает определение необходимости изменения процесса или решения и позволяет изменениям в подходе к принятию решений быть независимыми от изменений процесса.
• Экземпляры процессов часто ждут, пока элементы будут помещены в списки задач или в очереди. Причина помещения экземпляра процесса в шаблон удержания обычно заключается в том, что необходимо принять решение. Распознавая это как решение и автоматизируя его, транзакции перемещаются, поэтому в списках задач или в папке входящих сообщений остаются только исключения. Даже если вы решите оставить всё как есть, моделирование и понимание самого решения поможет в обучении, обеспечении согласованности и определении областей для улучшения.

Изучение показателей эффективности

Другой подход – посмотреть на ключевые показатели эффективности (KPI) и другие показатели, которые используются в рассматриваемой области(ях) деятельности. Любой KPI или показатель ценен только в том случае, если он помогает мотивировать подходящее поведение, подразумевая, что чьи-то действия могут изменить значение этого KPI или показателя. Изучая KPI и метрики и выясняя, когда и где люди делают выбор, который перемещает KPI / метрики вверх или вниз, команда проекта может определять решения. Каждая возможность сделать выбор, выбрать действие из возможного набора действий – это решение. Для начала команда проекта может просто спросить у бизнес-экспертов, какие решения имеют значение для KPI или метрики, но может оказаться, что люди не знают, что выбор, который они делают ежедневно, это явные решения. В таком случае надо попросить экспертов понаблюдать в течение недели какой выбор они часто делают. Не во всех компаниях есть качественная система ключевых показателей эффективности, поэтому такой подход не всегда будет полезен. Однако стоит попробовать, поскольку понимание ключевых показателей эффективности поможет определить решения и прояснить, как выглядит «хорошее решение».

Мозговой штурм

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

Изучение результатов бизнес-аналитики

Многие компании используют инструменты Business Intelligence (Bl) для создания большого количества отчетов, построения информационных панелей, обработки информационных запросов и выгрузки данных в Excel для анализа. Хотя отчасти причиной этой деятельности может быть необходимость отслеживать происходящее, большая часть бизнес-аналитики предназначена для улучшения процесса принятия решений. В результате эти выходные данные BI можно использовать для формирования списка принимаемых решений: когда кто-то говорит, что получил конкретный отчет или смотрит на информационную панель, команда проекта может спросить: «Что дальше?», чтобы увидеть, какие действия могут быть предприняты в результате. Перечисляя возможные действия, которые могут быть предприняты при чтении отчета, аналитики могут ограничить круг решений, принимаемых в результате работы с аналитической информацией. Рассматривая те действия, которые были предприняты в связи с отчетом, они могут найти последующие действия. Так можно выйти на набор или типы транзакций, в которых люди всегда «делают одно и то же». Здесь задействуются решения, которые могут быть подходящими для автоматизации.

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

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

• Те модули или компоненты, которые часто меняются и в отношении которых запросы на изменение поступают регулярно или имеют большое количество невыполненных работ, часто являются компонентами принятия решений. Это связано с тем, что процесс принятия решений является очень гибким и регулярно меняется в ответ на внешние стимулы, такие как новая политика, правила, изменения цен конкурентов и многое другое;
• Модули, которые генерируют множество исключений или согласований, особенно те, которые генерируются гораздо больше сейчас, чем в прошлом, также часто являются модулями принятия решений. Исключения передаются людям, чтобы они могли принять решение, которое система не может. Это, естественно, означает, что в рассматриваемом модуле всё остальное время принимаются решения;
• Любое место в существующей системе, где у пользователей есть много жёлтых стикеров на экранах или другие способы делать заметки о навигации и использовании системы, заслуживает проверки. Примечания о ценах и скидках, конкретные инструкции при работе с клиентом и многое другое часто записываются вне системы, потому что процесс принятия решений, закодированный в ней, слишком сложно изменить.

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

Описание и оценка решения

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

Список обычно включает имя и краткое описание каждого решения. Это важно, но на этом этапе для каждого решения необходимо собрать дополнительные данные:

• Вопрос и разрешённые ответы
• Деловой контекст
• Организационный контекст
• Контекст применения.

Вопросы и разрешенные ответы

Вопросы – мощный инструмент для объяснения решения. Посмотрите на каждое решение и определите вопрос, на который нужно ответить, чтобы принять решение. Убедитесь, что из вопроса ясен предмет решения, сроки и объём или ограничения. Сделайте это как можно точнее и избегайте вопросов, которые начинаются с «Как» или используют Я/Мы.

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

Таблица 1: примеры вопросов.

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

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

Таблица 2: допустимые типы ответов.

Бизнес-контекст

В дополнение к свойствам основного вопроса и разрешенных ответов стандарт DMN (Decision Management Notation) помещает решения в контекст, связывая их с различными объектами.

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

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

Эта связь между решением и показателем расскажет вам о двух вещах:

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

Организационный контекст

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

• Кому принадлежит решение? Кто решает, как следует принимать решение? Кто одобряет выбранный подход? Кто решит, что мы будем решать так, а не так? Кто будет поддерживать бизнес-правила для этого решения?
• Кто принимает решение? Часто одна часть или уровень организации владеет решением, но другая часть или уровень принимает решение изо дня в день. Например, решением о ценообразовании может владеть руководство продаж, но решения о ценообразовании принимают сотрудники отделов продаж. Если решения автоматизированы или частично автоматизированы, то организационная единица, которая передаёт решение заказчику или поставщику, также может считаться лицом, принимающим решения;
• Кого ещё волнует решение? Хотя многие решения принимаются только владельцами и исполнителями, иногда есть другие части организации, которые могут проявить интерес и ожидать, что их мнение будет принято во внимание. DMN позволяет связывать организационные единицы только в качестве владельцев и лиц, принимающих решения. Наш опыт показывает, что также полезно отслеживать те организационные единицы, которые заинтересованы и влияют на решение по какой-либо причине.

Контекст применения

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

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

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

Определение требований к решению

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

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

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

Требования к входным данным

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

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

Старайтесь сосредотачиваться не на базах данных или системах управления контентом, а на типе информации, хранящейся в них. Здесь разрабатывается модель требований, а не техническая архитектура.

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

Для важных входных данных может быть полезно записать:

• Является ли информация внутренней или внешней по отношению к организации?
• Это структурированные, неструктурированные или полу-структурированные данные?
• Насколько сложны данные и где можно найти дополнительную информацию?

Используемые для решения знания

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

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

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

Чтобы сформировать надежный список источников знаний, ответьте на следующие вопросы:

• Что предписывает мне что я должен делать?
• Откуда приходит указание, что мне следует делать?
• Откуда знать, что я могу делать в такой ситуации?
• Кто знает, что я, вероятно, буду делать?
• Информация откуда/от кого помогла бы мне сделать это лучше?
• «Если бы мы только знали __________, мы могли бы принять более выгодное решение»

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

Для всех источников знаний стоит задокументировать:

• Какие знания необходимы - политика, регулирование, экспертиза, передовая практика или аналитика?
• Насколько сложны знания?
• Где можно найти дополнительную информацию?

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

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

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

Детализация и уточнение модели

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

Процесс на этом этапе включает в себя следующие шаги:

• Детализировать решение
• Уточнить входные данные
• Уточнить регламентирующие знания
• Определить входные данные для аналитики
• Повторять до полной ясности

Декомпозиция решений

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

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

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

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

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

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

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

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

Уточнение входных данных

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

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

Уточнение регламентирующих знаний

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

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

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

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

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

Добавление входных данных для аналитики

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

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

Создание результирующей модели решений

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

• Цели, на которые влияют решения

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

• Затрагиваемые решения

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

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

– С точки зрения контекста этих решений, как эти решения вписываются в более широкий процесс принятия решений. Это взгляд вверх по иерархии решений;

• Источники бизнес-правил

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

• Требуемая аналитика

Аналитика, на которой сфокусирована модель, должна быть описана вместе с информацией, анализируемой для ее получения, а также их регламентирующими источниками знаний (например, документ с описанием методологии анализа). Здесь потребуются дополнительные сведения о возможных методах, рисках и проблемах, общих для рассматриваемого вида аналитики и т.д.;

• Применение и организационный контекст

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