Дата публикации оригинала: 2005-11-07
Автор оригинала: Ralph Kimball
Перевод на русский язык: Татьяна Лякишева
Оригинальный документ располагается здесь

В совете № 69 «Идентифицируем бизнес-процессы» Мардж Росс разъяснила, как важно идентифицировать бизнес-процессы организации при построении модели хранилища данных, и дала рекомендации о том, как это сделать. Теперь углубимся в некоторые детали.
Фокус на бизнес-процессах критически важен для успешной реализации решения в области хранилищ/BI по методу Кимбалла. Бизнес-процессы – это строительные блоки хранилища данных, создаваемого на основе многомерной модели. Мы предлагаем разрабатывать хранилище последовательно, итерационно, захватывая по бизнес-процессу за шаг. Вы спросите: что такого волшебного в бизнес-процессах? Как их выявление поможет нам в моделировании? Ответ заключается в том, что, правильная идентификация бизнес-процессов «запускает» весь процесс проектирования многомерной модели. Я не раскрою особого секрета, если скажу, что каждый бизнес-процесс порождает по крайней мере одну таблицу фактов, поэтому идентификация бизнес-процессов существенным образом определяет и то, какие таблицы фактов мы построим.

Вполне обычной является ситуация, когда один бизнес-процесс порождает две и более таблицы фактов. Чаще всего это происходит, если процесс затрагивает разные объекты (продукты), которые могут рассматриваться как подтипы одного супер-типа. В этом случае будет порождено несколько схожих, но отдельных таблиц фактов. Вот хороший пример из области медицинского страхования. Бизнес-процесс, связанный с выплатами по требованиям возмещения, может быть отражен в трех отдельных таблицах фактов: оплата расходов на амбулаторное обслуживание (посещения врача), расходов на пребывание в стационаре, а также расходов на оплату лекарственных препаратов.
Следствием некорректного определения бизнес-процессов становятся модели данных, которые никогда не будут реализованы, или (что еще хуже) – таблицы фактов на неподходящем, недопустимом уровне детальности. Если учесть, сколько уже написано нами на эту тему, излишне говорить (хотя вы не найдете этого в некоторых недавних аналитических обзорах), что мы поддерживаем реализацию хранилищ на основе многомерной модели, с максимально возможным уровнем детальности данных.
Хорошей проверкой на то, насколько корректно вы идентифицировали бизнес-процессы, станет описание гранулярности таблицы фактов. Если вы можете лаконично и четко определить детальный уровень фактов – вы и ваша модель в порядке. И напротив, если есть неясности касательно уровня детальности каждой записи в таблице фактов – вам еще есть над чем поработать. Скорее всего, вы смешали в одной таблице более одного бизнес-процесса. Отступите на шаг назад и внимательно посмотрите, где тот дополнительный бизнес-процесс, который нужно учесть в вашей модели.
Лучший способ понять бизнес-процессы – это слушать требования пользователей. К сожалению, когда эти требования излагаются, они не принимают сами собой форму описания бизнес-процессов. Пользователи лишь сообщают нам (в своей терминологии) потребности относительно анализа информации: какие виды анализа им нужны, и какие решения они хотели бы принимать на их основе. Если продолжить пример из области медицины, актуарии могут запросить анализ оценки страховой премии, отчеты по тенденциям применения и треугольники претензий, на которые они опираются в своей работе. Казалось бы, что здесь намекает на бизнес-процессы? Но в том-то и суть: изучив аналитические потребности пользователей, декомпозировать их до соответствующих бизнес-процессов. Это означает копнуть несколько глубже, понять данные и учетные системы, над которыми строится аналитика. Дальнейшее исследование в нашем примере в конце концов показывает, что все три аналитических задачи решаются на основе данных бизнес-процесса выплаты по требованиям страхового возмещения.
В некоторых случаях для расшифровки аналитических потребностей приходится приложить серьезные усилия. Ведь зачастую наиболее ценные для бизнес-пользователей возможности анализа связаны с несколькими бизнес-процессами. К сожалению, далеко не всегда очевидно, что задействовано более одного процесса. И в этом случае декодирование - гораздо более сложное дело, так как придется декомпозировать аналитическую задачу до уникальных типов и источников необходимых данных. Возвращаясь к нашему примеру, андеррайтер может запросить анализ коэффициента убыточности для принятия решений по возобновлению страхования. Если углубиться в детали, мы поймем, что анализ убыточности основан на сравнении суммы страховой премии с суммой затрат, связанных с требованием возмещения убытков, и по сути – на определении таким образом отношения между доходами и расходами. Тут уже задействуются два бизнес-процесса: выплата страхового возмещения и начисление страховой премии.
Поразмыслив над этим советом, вы поймете, как подойти к построению корпоративных информационных панелей. Информационная панель не относится к отдельному бизнес-процессу. Это скорее механизм отображения результатов множества (если не всех) бизнес-процессов компании. К сожалению, создание информационных панелей все еще нередко представляется (и принимается) командами хранилищ данных/BI как частная аналитическая задача.

Материал опубликован с разрешения компании Ralph Kimball Associates


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также: