`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Что для вас является метрикой простоя серверной инфраструктуры?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Рекомендации по управлению рисками в ИТ-проектах

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

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

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

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

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

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

Правильные отношения как залог успеха проекта

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

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

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

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

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

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

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

Управление большими объемами требований в BI-проектах – 2

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

Управление большими объемами требований в BI-проектах – 2

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление большими объемами требований в BI-проектах

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

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

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

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

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

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

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

Управление большими объемами требований в BI-проектах

Рисунок 1. Виды требований и их взаимосвязи

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

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

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

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

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

Управление большими объемами требований в BI-проектах

Рисунок 2. Просмотр свойств сущности в концептуальной модели данных, связанной с исходным требованием

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

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT