Взгляд ITSM-консультанта на основные проблемы реализации проектов по построению отчетности на примере процесса управления инцидентами c помощью Business Objects

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

Оценка эффективности IT-подразделений может проводиться на основе данных, собираемых системой автоматизации процессов ITSM (IT Service Management). Но далеко не в каждой современной системе автоматизации присут ствует встроенный механизм генерации и предоставления аналитической информации.

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

В данной статье рассмотрены основные проблемы, возникающие в проектах по построению отчетности, реализуемых средствами специализированных программных продуктов Business Objects XI и Crystal Reports XI, а также приведены возможные варианты решения возникающих проблем, выработанные в соответствии с практическим опытом реализации проектов по построению отчетности для процесса управления инцидентами, автоматизированного при помощи программного обеспечения HP OV Service Desk.

Информативность отчета - результат рационального подбора KPI (ключевых показателей)

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

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

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

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

Рис. 1. Диаграмма выполнения заявок

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

Для проведения анализа на более низком уровне, скажем на уровне IT-подразделений или IT-специалистов, возникает потребность в формировании показателей эффективности для каждой из соответствующих ролей. Здесь становятся актуальными две проблемы:
1. Отсутствие данных, необходимых для расчета определенных показателей эффективности. Поскольку выбор показателей основан на информации, присутствующей в базе данных системы автоматизации процесса управления инцидентами, для обеспечения наличия требуемых данных необходимо учитывать потенциальную потребность формирования отчетности еще на этапе настройки системы, заблаговременно добавив в нее необходимые поля и заложив соответствующую логику их заполнения.
2. Несовместимость показателей эффективности. При реализации практически любого проекта по отчетности возникают ситуации, когда заказчик может попытаться включить в отчет как можно большее число всевозможных показателей, не задумываясь не только об их реальной необходимости и информативности, но и об их совместимости между собой. Такую проблему можно решить за счет привлечения к составлению отчетов специалистов, имеющих достаточный уровень квалификации в области формирования KPI.

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

Например, формула для расчета показателя «среднее время самостоятельного выполнения заявок IT-специалистом» может изменяться в зависимости от критериев, обозначающих факт начала и окончания обработки заявки. В одном случае фактом начала обработки заявки может быть принята дата и время назначения ее соответствующему специалисту, в другом - началом обработки может стать момент первого открытия заявки специалистом в интерфейсе системы HP OV Service Desk.

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

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

Согласованная концепция - основа успешного проекта

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

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

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

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

Рис. 2. Форма отчета

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

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

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

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

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

Плюсы

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

Минусы

• Рекомендованные отчеты могут не учитывать всех показателей эффективности, используемых в компании заказчика.
• Как правило, сравнительно простой интерфейс, в полной мере не использующий всех нововведений, доступных в программных продуктах Crystal Reports XI и Business Objects XI, к примеру, таких как динамические или каскадные параметры.

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

Плюсы

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

Минусы

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

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

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

Точность оценки трудозатрат характеризует уровень компетентности консультантов

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

Одним из вариантов решения такой задачи может стать формирование детального технического задания (ТЗ) на создание отчета по каждой из вошедших в концепцию форм. Например, в ТЗ на создание отчета в среде Crystal Reports XI подробно расписываются все формулы, входные параметры, фильтры, элементы, создающие основное наполнение отчета. Таким образом, формирование ТЗ не только исключает неоднозначность трактовки формулировок или формул расчета KPI, но и предоставляет возможность максимально увеличить точность оценки трудозатрат. Для того чтобы оценить трудозатраты, исполнитель анализирует созданное ТЗ, последовательно рассматривая четыре основных фактора, влияющих на трудозатраты при реализации отчета:
1. Способ реализации отчета с использованием продуктов Crystal Reports XI и Business Objects XI. При совместном использовании продуктов Crystal Reports XI и Business Objects XI появляется возможность реализовать отчеты как минимум тремя различными способами (см. рис. 3):

Рис. 3. Способы реализации отчетов

• Первый способ. Полностью реализовать отчет средствами редактора Crystal Reports XI. При этом все работы, в том числе настройка подключения к базе данных системы HP OV Service Desk, написание sqlзапроса, построение интерфейса отчета и программирование формул реализуются в редакторе Crystal Reports XI.
• Второй способ. Реализовать отчет, используя связку «бизнес-модель (Business View) + Crystal Reports XI». В такой конфигурации подключение к базе данных, настройка связей между таблицами, написание sqlзапросов, создание и настройка параметров могут быть реализованы в бизнес-модели, входящей в состав Business Objects XI, при подключении к которой в редакторе Crystal Reports XI осуществляется оставшаяся часть работ по созданию интерфейса отчета и программированию формул.
• Третий способ. Реализовать отчет, используя связку «Юниверс» (модель метаданных, построенная при помощи модуля Universe Builder, входящего в состав продукта Business Objects XI + Crystal Reports XI. Использование Universe Builder, входящего в состав Business Objects XI, предоставляет возможность построить собственную модель метаданных на основе существующей структуры базы данных системы HP OV Service Desk. Также необходимо определить в ней объекты, связи между ними и задать параметры. Часть работ, связанная с созданием интерфейса отчета и программированием формул, осуществляется в редакторе Crystal Reports XI.

В каждом отчете, реализуемом первым способом, потребуется отдельно указывать источник данных, формировать необходимую структуру табличных связей или писать sql-запрос. К тому же при размещении отчетов на веб-сервер Business Objects XI также понадобится указать источник данных для каждого размещаемого отчета. Все это делает данный способ не очень удобным и не очень актуальным при наличии возможности использования бизнес-модели или «Юниверса», снимающих такого рода неудобства.

Прямым назначением «Юниверса» является построение моделей данных для работы с OLAP-кубами. Его применение целесообразно, если заказчик обладает достаточным уровнем компетенции и планирует самостоятельно формировать те или иные отчеты путем агрегирования данных по объектам, представленным в «Юниверсе». В таком случае проект по построению отчетности может заключаться в формировании модели метаданных на основе объектов, задействованных в процессе управление инцидентами (заявка, инцидент, рабочее задание, рабочие группы, организации, сотрудники), содержащей их детальное описание на русском языке, конфигурацию их свойств и взаимосвязей.

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

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

2. Суммарная сложность реализации отчета в редакторе Crystal Reports XI. Практика реализации отчетов в редакторе Crystal Reports XI показывает, что наиболее трудоемким является программирование формул.

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

Каждой формуле присваивается определенное фиксированное значение в баллах. После градации всех формул подсчитывается суммарное количество баллов в отчете. Баллы определяют количество рабочих часов, которое потратит исполнитель на реализацию формул. Соответствие часов работы баллам устанавливается на основе опыта реализации отчетов и может изменяться в зависимости от уровня компетентности программиста. В случае если отчет полностью реализуется в редакторе Crystal Reports XI, потребуется выставить дополнительные баллы на создание sql-запроса к базе данных системы HP OV Service Desk.

Фактически исполнитель определяет трудозатраты на реализацию всех элементов (формул, параметров, элементов дизайна, группировок и фильтров), описанных в ТЗ и входящих в состав отчета, в среде Crystal Reports XI на основе своей экспертной оценки.

3. Специфика реализации процесса управления инцидентами на базе системы HP OV Service Desk. Данный пункт подразумевает оценку трудоемкости работ по расчету определенных показателей эффективности или получению определенных данных на основе информации, хранящейся в базе данных системы HP OV Service Desk.

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

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

В случае если заказчик просит реализовать механизм расчета времени обработки заявки на основе данных истории, исполнитель, оценив трудозатраты на реализацию подобной формулы в Crystal Reports XI, может предложить добавить дополнительное поле, сохраняющее нужную дату, на интерфейс системы HP OV Service Desk и на его основе вести необходимые расчеты.

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

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

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

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

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

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

Необходимо добавить, что помимо затронутых выше проблем, при выполнении подобных проектов актуальна проблематика непосредственной реализации выдвинутых и зафиксированных в ТЗ требований заказчика средствами продуктов Business Objects XI и Crystal Reports XI. Данная проблема возникает из-за функциональных ограничений рассматриваемых продуктов. Она приводит к увеличению трудозатрат на поиски обходных решений и, как следствие, к сдвигу установленных проектных сроков.

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