· прогноз стоимости по завершению проекта (EAC - estimate at completion) - имеет разные расчеты для различных ситуаций:

- при некорректности предыдущих оценок составляется новый прогноз (ETC - estimate to completion), тогда EAC = AC + ETC;

- если ранее возникшие непредвиденные отклонения не ожидаются в будущем, то EAC = AC + (BAC - EV);

- если же типичные отклонения ожидаются и в дальнейшем, EAC = AC + (BAC - EV) / CPI.

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

Осуществление контроля качества выполнения проекта основывается на плане управления проектом, метриках качества, контрольных списках качества и результатах измерение исполнения работ. Существует несколько основных инструментов и методов контроля [20]:

· причинно-следственные диаграммы - этот тип диаграмм позволяет анализировать взаимосвязь причин и следствий, более того, ее можно использовать для анализа рисков проекта;

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

· блок-схемы - помогают осуществлять контроль качества процессов и выявлять потенциальные возможности и угрозы;

· гистограммы - отражают наиболее частые причины появления проблем при исполнении процессов;

· диаграммы Парето - являются упорядоченными и ранжированными гистограммами, отражающими соответствие количества обнаруженных проблем количеству причин;

· диаграммы тренда - показывают историю и характер изменений, позволяют анализировать тенденции, изменения во времени, проводить прогнозирование;

· диаграммы разброса - отражают взаимосвязь двух параметров, на их основе можно установить возможную связь между изменениями;

· выборочные оценки - проводимые оценки, основывающиеся на плане качества.

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

2.2 Показатели эффективности выполнения проектов

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

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

· соблюдение графика проекта;

· соблюдение бюджета проекта;

· расчеты с заказчиком;

· успешность составления предыдущего прогноза;

· риски проекта.

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

· отклонение по срокам (SV);

· индекс выполнения сроков (SPI);

· отклонение по стоимости (CV);

· индекс выполнения стоимости (CPI).

Что касается мониторинга расчетов с заказчиками, для них вводится отдельный показатель:

· движение денежных средств (ДДС) проекта - отражает факт, сумму и дату получения оплаты за выполняемые работы по проекту.

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

· успешность составления прогнозов - сравнение ранее сделанного прогноза статуса проекта и текущего.

Отдельно нужно отметить организацию отслеживания рисков. Мониторинг и контроль рисков подразумевает процесс отслеживания идентифицированных рисков, мониторинг остаточных и идентификацию новых рисков, обеспечение применения планов реагирования на риски [14]. Выходными данными проводимого мониторинга будут являться:

· переработанные планы реагирования на риски (создаются при идентификации нового риска);

· корректирующие действия в соответствии с планом реагирования;

· запросы на изменения (изменения документируются для проверки выполнимости);

· пополнение базы данных рисков;

· обновление опросных листов для общей базы предприятия.

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

Рис. 8. Пример причинно-следственной диаграммы

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

· триггер риска - отражает состояние симптома риска.

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

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

· прогнозная маржинальная прибыль (MR - Marginal Revenue) - прогнозируемая разница между выручкой от реализации проекта и понесенными переменными затратами.

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

Рис. 9. Статусная модель проекта

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

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

® рассчитывается по формуле: утилизация = 100% * рабочее время, затраченное сотрудниками на проект /общий фонд рабочего времени;

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

® рассчитывается, как: доля объема работ, приходящаяся на управленческий персонал = 100%*рабочее время, затраченное управленческим персоналом / общий фонд рабочего времени;

· доля своих ресурсов в проекте - характеризует эффективность бюджетного планирования компании и центров ответственности за проекты; особенно важна в условиях ИТ-консалтинга, где компания стремится получить аванс за выполнение проекта и контролирует движение денежных средств;

® расчётная формула: доля своих ресурсов в проекте = 100% * затраты на оплату труда собственных ресурсов / суммарные (т.е. собственные + субподрядчики) затраты проекта;

· показатель статуса проекта - отражает общее положение выполнения проекта, может принимать различные значения, например: выполняется в соответствии с планом, имеет незначительные отклонения, имеет критические отклонения;

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

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

2.3 Программное обеспечение автоматизации управления проектами

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

· Microsoft Project - позволяет отслеживать прогресс проекта, проводить анализ работ, содержит множество функций для полноценного управления; позволяет выбрать методологию проектного управления реализуемого на предприятии; является наиболее распространённым однопользовательским решением на рынке малых проектов [8];

· Primavera - используется для отслеживания ресурсов, материалов и оборудования проекта; наибольшей популярностью пользуется на рынке сложных и длительных проектов (например, строительство) [9];

· Spider Project - интегрированная система управления проектами, позволяет составлять оптимальные расписания выполнения работ, используется организациями, требующими строгую стандартизацию и координацию проектной деятельности [10].

Для выбора наиболее подходящего обеспечения автоматизации стоит провести сравнительный анализ рассматриваемых средств, он представлен в таблице 1 [22, 23]. Критерии сравнения выбирались исходя из потребностей управления проектами в компании в целом и проведения мониторинга в частности. Данные по наличию / отсутствию функций были получены из открытых источников и веб-сайтов разработчиков. Поля, обозначенные, как «ограничен», предполагают использование дополнительного программного обеспечения для реализаций функций.

Таблица 1

Сравнение программных средств управления проектами

Критерий сравнения	Microsoft Project	Oracle Primavera	Spider Project
Сложность изучения, использования	Низкая	Высокая	Высокая
Обмен информацией с MS Office	Возможен	Ограничен	Ограничен
Интеграция с 1C, SAP через XML	Ограничена	Ограничена	Нет
Импорт смет в проектную систему	Ограничен	Ограничен	Нет
Сложность разработки структур работ	Низкая	Средняя	Низкая
Интерактивный регламент управления проектами	Да	Нет	Нет
Возможность создавать базу знаний из типовых элементов	Нет	Да	Нет
Возможность наличия более чем одной связи между работами	Нет	Да	Да
Структуры ресурсов	Да	Да	Да
Управление портфелями проектов	Да	Да	Нет
Планирование затрат	Да	Да	Да
Анализ план-факт	Да	Да	Да
Проектная статистика на базе OLAP - сервера	Да	Нет	Нет
Нормирование сроков работ от объемов работ	Да	Нет	Да
Управление движением денежных средств	Ограничено	Ограничено	Нет
Средства информирования высшего управленческого звена	Да	Да	Нет
Информирование о статусе работ топ-менеджеров	Да	Да	Нет
Формирование отчетности	Да	Да	Ограничено

В целом, можно сказать, что Spider Project проигрывает по многим рассматриваемым параметрам другим рассматриваемым инструментам. В нем реализовано множество функций, но многие из них сложны для использования. Что касается Primavera, эта система является более сложной и полной в сравнении с другими средствами. Она предлагает множество дополнительных модулей, которые охватывают все сферы управления проектами. У MS Project схожий, но менее полный функционал, кроме того, в нем слабо поддерживается учет материальных ресурсов, но для сферы ИТ-консалтинга такого вида ресурсы не являются основными. Для данного исследования было выбрано средство MS Project благодаря легкости и ясности использования, большому количеству возможностей настраивания полей, отчетов и широкому функционалу мониторинга проектов. Именно в этой среде и будет применяться разрабатываемый подход.

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

Кроме того, для хранения некоторых данных можно создать настраиваемые поля, они предназначены для хранения информации, необходимой пользователю, ей может быть как какое либо простое значение, так и рассчитываемая формула. В MS Project существует две группы настраиваемых полей: поля задач (содержат параметры задач проекта) и поля ресурсов (содержат параметры ресурсов проекта). В любую группу полей можно занести информацию о датах, длительности, трудозатратах, стоимости (задач или ресурсов), текстовые данные, числовые значения, флаг (значения «да» или «нет»). В каждом таком поле можно настроить отображение не текстового / числового значения, а определенного индикатора. Это может цветовой индикатор, зависящий от выполнения условия. Например, для определения статуса проекта и будут использоваться индикаторы, указанные выше (Рисунок 8).

Что касается выбранных отслеживаемых показателей, рассмотрим, как они будут отражены в MS Project:

· отклонение по срокам - будет отражено в поле с числовым значением для каждой задачи;

· индекс выполнения сроков - будет отражен в поле с числовым значением;

· отклонение по стоимости - будет отражено в поле с числовым значением для каждой задачи;

· индекс выполнения стоимости - будет отражен в поле с числовым значением;

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

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

· триггеры риска - будут отражены в настраиваемых полях с текстовым значением;

· прогноз стоимости по завершению работ - будет отражен в настраиваемых полях с числовым значением;

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

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

2.4 Отчетность выполнения проекта

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

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

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

Рассмотрим подробнее составляемые в MS Project отчеты. Программа позволяет пользователю не только получить стандартные (уже заданные) отчеты по проекту, но и составить их самому включив необходимые показатели и данные. Готовые отчеты разделяются на следующие группы отчетов:

· обзорные, включают в себя:

сводку по проекту;

задачи верхнего уровня;

критические задачи;

вехи;

рабочие дни;

· текущая деятельность, включают в себя:

не начатые задачи;

задачи, которые скоро начнутся;

выполняющиеся задачи;

завершенные задачи;

задачи, которые должны были начаться;

запаздывающие задачи;

· затраты, включают в себя:

движение денежных средств;

бюджет;

задачи с превышением;

ресурсы с превышением;

освоенный объем;

· назначения, включают в себя:

дела по исполнителям;

дела по исполнителям и времени;

список дел;

ресурсы с превышением;

· загрузка, включают в себя:

использование задач;

использование ресурсов.

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

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

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

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

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

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

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

3. Применение разработанного подхода

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

3.1 Описание проекта

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

Рассматриваемым проектом является проект по созданию технической инфраструктуры единой платформы хранения и управления электронным контентом для ОАО «Заказчик». Соответственно, проект выполняется для ОАО «Заказчик», которая является естественным монополистом в секторе передачи электроэнергии. Конечными заказчиками автоматизации являются Департамент информационных технологий и Департамент эксплуатации систем связи и информационных систем. Сокращенное наименование проекта: Техническая инфраструктура GCM, плановое время выполнения проекта - 11 месяцев. В результате выполнения работ должна быть создана техническая инфраструктура системы, обеспечивающая функционирование системы с должной производительностью и надежностью, построенная с учетом:

· оптимизации используемой в рамках проекта аппаратной, сетевой и программной архитектуры;

· переконфигурации системных компонентов программных приложений (СУБД, серверы приложений, контент-серверы).

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

· перевода документооборота на коллективную обработку на базе единой электронной системы;

· уменьшения сроков прохождения и трудоемкости обработки документов;

· организации оперативного архива электронных документов и поддержки работы архива бумажных документов.

После определения цели были поставлены задачи реализуемой системы:

· упорядочение процессов документооборота в филиалах;

· ускорение прохождения документов между генеральной дирекцией и филиалами;

· получение подробной и ясной информации о процессах документооборота;

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

· повышение производительности труда сотрудников филиалов выполняющих процессы документооборота;

· организация работы архива электронных документов и поддержка работы архива бумажных документов.

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

· сервер системы управления базами данных;

· серверы управления контентом (8 единиц);

· серверы приложений (16 единиц);

· серверы индексирования (8 единиц);

· серверная ферма терминального доступа;

· средства распределения нагрузки;

· система хранения данных СУБД;

· система хранения данных электронного контента;

· компоненты сети хранения данных;

· компоненты сети передачи данных;

· программное обеспечение резервного копирования данных системы;

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

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

· обследование существующей инфраструктуры заказчика, сбор информации и разработка технического задания на систему;

· техническое и рабочее проектирование системы (в т. ч. подготовка и согласование программы и методики испытаний и составление закупочных спецификаций и ведомости покупных изделий);

· монтаж, установка и настройка оборудования и программного обеспечения;

· проведение приемочных испытаний;

· опытно-промышленная эксплуатация системы, включая функциональное и нагрузочное тестирование;

· доработка и тонкая настройка функционирования с целью оптимизации производительности системы;

· разработка эксплуатационной и исполнительной документации, включая паспорт системы;

· приемно-сдаточные работы и подписание акта о вводе объекта в эксплуатацию.

Лист ресурсов показан на рисунке 10. Основными ресурсами проекта являются трудовые, материальные же были оплачены и поставлены заказчиком самостоятельно. Себестоимость проекта рассчитывалась на основе затрат на трудовые ресурсы. Лист задач, включающий все работы, их длительность, даты начала и окончания, себестоимость работ показаны на рисунке 11, эти значения являются базовым планом. Диаграмма Ганта, отражающая запланированный график работ, представлена на рисунке 12.

Рис. 10. Лист ресурсов проекта

На текущую дату (05.05.2016) проект находится на середине своего выполнения. Завершается выполнение этапа проектирования технической инфраструктуры, частично начаты работы по этапу внедрения, в частности, происходит контроль поставки оборудования. Даты выполнения некоторых задач вышли за плановые показатели, некоторые, наоборот, были выполнены быстрее. Диаграмма Ганта с отслеживанием представлена на рисунке 13.

Рис. 11. Задачи проекта

Рис. 12. Диаграмма Ганта



Рис. 13. Диаграмма Ганта с отслеживанием

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

3.2 Мониторинг показателей проекта с использованием MS Project

Во-первых, необходимо добавить вехи проекта для обозначения завершения важных этапов работ:

· для первого этапа «Сбор исходной информации и формирование требований к системе» - веха «Разработанное техническое задание на инфраструктуру»;

· для второго этапа «Проектирование технической инфраструктуры» - веха «Разработанный рабочий проект»;

· для третьего этапа «Поставка, установка, внедрение и сдача системы в эксплуатацию» - веха «Внедренная и испытанная система»;

· для четвертого этапа «Опытно-промышленная эксплуатация» - веха «Завершенная настройка и разработанная документация»;

· для пятого этапа «Техническое сопровождение системы» - вехи «Осуществление технической поддержки аппаратных компонент инфраструктуры» и «Осуществление технической поддержки программных компонент инфраструктуры»

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

Во-вторых, необходимо создать настраиваемые поля для отображения выбранных показателей в программном средстве. Показатели метода освоенного объема (отклонение по срокам, индекс выполнения сроков, отклонения по стоимости, индекс выполнения стоимости) должны быть рассчитаны по заданным формулам и интерпретированы относительно описанных значений [2.1]. Для наглядности их значения были выделены цветом, однако цветовые индикаторы полей в данном случае использовать неуместно, поскольку для отклонений и индексов важно анализировать полученное значение, а не только динамику. Полученные поля представлены на рисунке 14. Из полученных значений можно сделать вывод, что на данный момент в проекте наблюдается перерасход бюджета (SV < 0) и отставание по срокам (CV < 0), индексы отклонений выполнения <1, что указывает на отрицательную динамику. Однако значения индексов стоимости и сроков, 0,99 и 0,95, соответственно, очень близки к единице, а значит, при оперативном внесении изменений в план удастся сократить отклонения.

Далее рассмотрим настройку полей для учета расчетов с заказчиками - то есть движение денежных средств. На рисунке 15 представлены поля получения денежных средств и дат поступления средств для этапов работ.



Рис. 14. Настраиваемые поля показателей метода освоенного объема

Рис. 15. Настраиваемые поля движения денежных средств

Оплата аванса заказчиком производится перед каждым этапом работ, чаще всего в размере 50%. Остальные 50% оплачиваются после сдачи этапа. Факт получения денежных средств сопровождается цветовым индикатором, принимающим зеленый цвет при полной оплате; желтый - при частичной; красный - при отсутствии поступления средств. Пользователь может выбирать процентное значение оплаты (от 0 до 100). Дата получения средств указывает на последнюю дату платежа. На текущий момент получена оплата всех предыдущих завершенных этапов работ и аванс текущего этапа. Прогнозируется дальнейшая своевременная оплата заказчиком.

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

Таблица 2

Риски и триггеры рассматриваемого проекта

Риск	Последствия	Триггеры	Вероятность	Влияние	Оценка	Ранг	Меры реагирования
Требования к системе не полны	Система не удовлетворяет потребностям заказчика	Большое количество вносимых изменений в систему	0,3	0,3	0,3	Высокий	Проведение совещаний с заказчиком, уточнение требований
Неверно определены сроки реализации	Увеличение издержек выполнения проекта	Задержка сроков более чем на две недели	0,5	0,2	0,1	Средний	Резервирование части времени для доп. работ
Сложности с интеграцией системы	Некорректная работа с существующими системами	Большое количество проблем при реализации интеграции	0,4	0,4	0,2	Средний	Привлечение доп. Специалистов, резервирование времени для подготовки интеграции
Недовольство со стороны сотрудников заказчика	Отказ заказчиков от дальнейшего сотрудничества	Большое количество жалоб и отрицательных отзывов на этапе тестирования	0,5	0,2	0,1	Средний	Проведение обучения сотрудников заказчика

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

Рис. 16. Настраиваемые поля отслеживания рисков проекта

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

Рис. 17. Прогнозная стоимость по завершению проекта

Что касается маржинальной прибыли, плановым значением является: 1574375,01 руб. Прогнозным: 1571899,10 руб., эта разница и есть разница в прогнозной и плановой себестоимости проекта. Настраиваемые поля маржинальной прибыли представлены на рисунке 18.

Рис. 18. Прогнозная маржинальная прибыль проекта

Таким образом, после обзора всех показателей проекта, можно составить текущий статус проекта, который основывается как на текущих, так и на прогнозных значениях. Определение статуса ракурсов проекта представлено на рисунке 19. Ни один из аспектов не является критическим на данный момент, отклонения по бюджету и расписанию планируется устранить за счет сокращения времени поставки оборудования. Расчеты с заказчиком выполняются согласно плану, риски проекта отслеживаются и устраняются. Успешность составления прогнозов имеет отклонения, поскольку отражает не спрогнозированные превышения бюджета и расписания. Согласно разработанной статусной модели [2.2], общий статус проекта можно определить как «Имеет незначительные отклонения».

Рис. 19. Статусы ракурсов проекта

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

Для расчета показателя утилизации необходимы данные по трудозатратам в компании: на остальные проекты (2485 часов), на административные (324 часа), отсутствие на рабочем месте (172 часа), на рассматриваемый проект (950 часов). Значения приводятся для прошедшего месяца (01.04.2016-29.04.2016). Показатель утилизации = 87%, что говорит об очень высокой эффективности использования рабочего времени на предприятии, однако, при таком высоком значении может возникнуть конфликт ресурсов.

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

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

3.3 Отчетность по результатам мониторинга

Для визуализации значений и представления отчетности различным лицам были созданы шаблоны отчетов в excel, содержащие все необходимые поля, описанные во второй главе работы [2.4]. На рисунке 20 представлен шаблон отчета о статусе проекта. Содержащий общую информацию о статусах ракурсов, описание основных отклонений и общий статус проекта.

Рис. 20. Отчет о статусе проекта

На рисунке 21 представлен отчет куратора проекта. В нем внимание уделено данным о расчетах с заказчиком и общим показателям проекта.

Рис. 21. Отчет куратора проекта

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

Рис. 22. Отчет руководителя проекта

На рисунке 23 отображен отчет куратора со стороны заказчика, в котором присутствуют данные об оплате этапов, и общие данные по статусу проекта.

Рис. 23. Отчет куратора со стороны заказчика

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

Рис. 24. Отчет руководителя компании

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

Заключение

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

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

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

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

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

3. Разработана система отчетности для различных уровней проектного управления в ИТ-консалтинговой компании.

4. Проведен анализ программного обеспечения, используемого для автоматизации процессов управления проектами, и обоснован выбор MS Project в качестве платформы автоматизации процессов мониторинга в рамках предложенного подхода.

5. В MS Project были выполнены необходимые настройки, созданы пользовательские настраиваемые поля и индикаторы отклонений.

6. Предложенный подход апробирован на примере ИТ-консалтингового проекта. Подготовлена отчетность по результатам мониторинга данного проекта и по компании в целом.

Таким образом, разработанный подход включает в себя:

· систему количественных и качественных показателей мониторинга в выбранных областях;

· систему отчетности для разных уровней проектного управления;

· настроенное в соответствии с требованиями к осуществлению мониторинга программное обеспечение.

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

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

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

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

Список использованной литературы

1. Андросов М.А. Роль оценки и мониторинга в управлении проектом //Журн. Достижения вузовской науки. №15 / 2015. С. 110-117.

2. Балашов А.И., Рогова Е.М., Тихонова М.В., Ткаченко Е.А. Управление проектами: учебник для бакалавров. Под ред. Роговой Е.М.- М.: Издательство Юрай, 2013 - 383 с. - Серия: Бакалавр. Базовый курс.

3. Баронов В.В., Калянов Г.Н., Попов Ю.Н. Титовский И.Н. Информационные технологии и управление предприятием - М.: Компания АйТи, 2009. - 328 с.

4. Васильев Р.Б., Калянов Г.Н., Левочкина Г.А. Управление развитием информационных систем. Под ред. Г.Н. Калянова. М.: Горячая линия - Телеком, 2009, 376 с.

5. Васильев Р.Б., Левочкина Г.А. Вопросы определения критических факторов успеха в ИТ-консалтинге // Журн. Бизнес-информатика, 2014, № 2(28). С. 15-23.

6. Васильев Р.Б., Левочкина Г.А. Ключевые факторы успеха в ИТ-консалтинге // Качество. Инновации. Образование. 2012, №12(91). С. 57-65.

7. Васильев Р.Б., Левочкина Г.А. Лекция: Критические факторы успеха в ИТ-консалтинге. [Электронный ресурс]

8. Веб-сайт Microsoft Project [Электронный ресурс]

9. Веб-сайт Oracle Primavera [Электронный ресурс]

10. Веб-сайт Spider Project [Электронный ресурс]

11. Грей Клиффорд, Ларсон Эрик. Управление проектами: Практическое руководство. Пер. с англ. - М.: Издательство «Дело и Сервис», 2003 - 528с.

12. Калянов Г.Н, Левочкина Г.А. Направления продуктового ИТ-консалтинга // Журн. Автоматизация в промышленности, 2010. №9. С.40-44.

13. Кожитов Л.В., Златин П.А., Дёмин В.А. и др. Организация инновационной деятельности в вузе: Монография. М.: МГИУ, 2009. - 296с.

14. Кузнецова Е.В. Управление портфелем проектов как инструмент реализации корпоративной стратегии: учебное пособие. М;: Триумф, 2014. - с. 216.

15. Кузнецова Е.В. Финансовые показатели эффективности деятельности проектно-ориентированных компаний //Журн. Аудит и финансовый анализ. №2 / 2013. С. 370-373.

16. Ляндау Ю.В. Развитие методологии процессно-проектного управления. Диссертационная работа на соискание ученой степени доктора экономических наук. М., 2014. С. 360.

17. Мазур И.И., Шапиро В.Д., Ольдрогге Н.Г. Управление проектами: Учебное пособие / под общ. Ред. И.И. Мазура. - 2-е изд. - М.: Омега-Л, 2004. - с. 664.

18. Майстер Д. Управление фирмой, оказывающей профессиональные услуги. М.: Манн, Иванов и Фербер, 2012. 368 с.

19. Матяш Д.В. Организация системы мониторинга в процессе управления проектами компании // Журн. Известия Алтайского гос. университета. №2 (78) / том 2 / 2013. С. 265-268.

20. Руководство к Своду знаний по управлению проектами (Руководство PMBOK). 4-е издание, Project Management Institute, Inc.

21. Система показателей проекта [Электронный ресурс]

22. Сравнение Microsoft Project, Turbo Project, Primavera и Spider. [Электронный ресурс]

23. Сравнение Spider Project, MS Project + Turbo, Primavera + ПМСОФТ [Электронный ресурс]

24. Стандарт PMI PMBOK 5^th. Часть 1 [Электронный ресурс]

25. Тихонов Е.Н. Показатели сбалансированной системы показателей для ИТ-консалтинговой компании // Эл. научный журн. Современные исследования социальных проблем, 2012. № 7(15).

26. Троцкий М., Груча Б., Огонек К. Управление проектами. Пер. с польск. - М.: Финансы и статистика, 2011 - 304 с.

27. Фунтов В.Н. Основы управления проектами в компании. 2-е изд., доп. - СПб.; Питер, 2008. - 336 с: ил. - (Серия «Учебное пособие»).

28. Prabhanar Rao, P Seetharamaiah. Organizational Strategies and social interaction influence in software development effort estimation // Journal of computer engineering, 2014. Volume 16, Issue 2, Ver. 12. PP 29-40.

29. Whitty, S.J. and Schulz; M.F. THE PMBOK CODE - 20^th IPMA World Congress on Project Management; 1, 466-472, 2006.

Размещено на Allbest.ru