Дмитрий Зиновьев

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

Как правило, BI[1]-системы создаются с использованием ряда промышленных инструментов, как для обработки данных, так и представления их конечному пользователю. Такие инструменты, как например, SAP Business Objects Edge BI, IBM Cognos BI, MicroStrategy обеспечивают наличие в созданной системе развитого и стабильного пользовательского интерфейса с фиксированным набором функциональных возможностей и технических параметров, которые не требуют дополнительной проработки в ходе проекта. Это означает, что функциональные требования к системе будут сосредоточены на соста...

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

Рисунок  3. Пример настройки типов требований и их атрибутов

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

Как уже говорилось, через импорт из XLS возможно создание не только объектов, но и вза...

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

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

Предположим, что у нас в  модели имеется два типа требований: аналитические задачи (стереотип Analytical task) и показатели (Indicator). Аналитические задачи выстроены в иерархии по подразделениям (стереотип Task group), а показатели – по видам анализа (стереотип Subject area). При этом, для каждой задачи через связь (Traceability link) указаны те показатели, которые требуются для решения задач.

Рисунок 1. Зависимость задач от показателей

В модели задачи и показатели разнесены в разные пакеты.

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

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

Сложность для аналитика заключается в необходимости многократного поиска необходимых таблиц и полей для каждого требования. Отчасти проблему можно было бы решить, используя матричное представление для связей (dependency matrix view), но даже для средних по объему моделей, где количество таблиц составляет десятки – работа с матрицей становиться практически невозможной, поскольку такой объем информации не вмещается ни в один дисплей.

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

Разумным выходом из ситуации будет предоставление аналитику сходного с Excel по простоте интерфейса для ввода целевых структур в меппинге через стандартные средст...

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

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

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

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

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

Сложность для аналитика заключается в необходимости многократного поиска необходимых таблиц и полей для каждого требования. Отчасти проблему можно было бы решить, используя матричное представление для связей (dependency matrix view), но даже для средних по объему моделей, где количество таблиц составляет десятки – работа с матрицей становиться практически невозможной, поскольку такой объем информации не вмещается ни в один дисплей.

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

Разумным выходом из ситуации будет предоставление аналитику сходного с Excel по простоте интерфейса для ввода целевых структур в меппинге через стандартные средст...

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

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

Предположим, что у нас в  модели имеется два типа требований: аналитические задачи (стереотип Analytical task) и показатели (Indicator). Аналитические задачи выстроены в иерархии по подразделениям (стереотип Task group), а показатели – по видам анализа (стереотип Subject area). При этом, для каждой задачи через связь (Traceability link) указаны те показатели, которые требуются для решения задач.

Рисунок 1. Зависимость задач от показателей

В модели задачи и показатели разнесены в разные пакеты.

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