Главная Транспортный налог Инструменты управления коммуникациями проекта. Планирование коммуникаций и управления конфигурацией в проекте

Инструменты управления коммуникациями проекта. Планирование коммуникаций и управления конфигурацией в проекте

Планирование коммуникаций и управления конфигурацией в проекте

Формирование стратегии коммуникаций. Идентификация объектов управления конфигурацией проекта. Процедура создания нового элемента конфигурации.

Инфраструктура проекта. Формирование базовой линии конфигурации проекта.

Организация управления конфигурацией проекта.

Организация документирования статуса элементов конфигурации.

Пример стратегии коммуникации.

Пример требований к инфраструктуре офиса проекта (фрагмент).

Пример процедуры создания инфраструктуры проекта.

Пример процедуры обеспечения хранения документов.

Пример процедуры подготовки документов.

Пример процедуры отчетности о деятельности.

Формирование стратегии коммуникаций

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

Относительно содержания любое сообщение на проекте должно включать в себя информацию следующего рода.

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

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

3. Удовлетворение потребности участников проекта действовать Сотрудники должны быть проинформированы, какие средства,

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

Пример стратегии коммуникации

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

1. Цели и задачи информирования участников проекта Например:

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

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

§ проинформировать сотрудников компании о проекте, его важности и выгодах;

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

§ поддерживать интерес к проекту на всех фазах его реализации;

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

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

§ сформировать образ проекта как открытой, прозрачной и доступной инициативы;

§ реализовать сбор сведений об ожиданиях/опасениях бизнес-экспертов о предстоящих изменениях;

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

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

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

2. Роли и обязанности

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

3. Целевая аудитория

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

1. Бизнес-эксперты

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

2. Ответственные за преобразования (1-го и 2-го уровня) Первый уровень представлен сотрудниками из числа руководителей

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

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

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

3. Конечные пользователи

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

4. Каналы коммуникаций

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

К коммуникационным каналам могут относиться как стандартные средства общения (телефон, электронная почта), так и более специфичные (совещания в группах, выездные семинары, сессии вопросов и ответов); кроме того, не следует упускать из виду и каналы коммуникаций , действующие по принципу pull, – это интернет-порталы, базы знаний и т.п. (см. рис. 7.1).

Рис. 7.1. Каналы коммуникаций и их воздействие

Для выявления эффективности существующих формальных каналов связи ниже приведен список рекомендованных вопросов.

1. Насколько быстро и как часто официальные решения руководства компании транслируются по этим коммуникационным каналам?

2. Какие заинтересованные стороны могут быть проинформированы посредством данного канала?

3. Насколько применим и действенен данный канал коммуникаций : есть ли ответственное лицо, возможно ли его использовать для внутренних и внешних коммуникаций?

4. Каким образом производится оценка данного канала коммуникаций ?

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

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

· Кто является (неформальным) лидером в организации?

· Чье мнение имеет наибольший вес при обсуждении важных вопросов?

· Каково отношение в организации к открытому распространению проектной информации и прозрачности деятельности смежных отделов?

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

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

Таблица 7.2. Пример матрицы коммуникаций

Условные обозначения

Формальные

Специфичные

Неформальные

0 Основной канал коммуникаций?Дополнительный канал коммуникаций

Совещания

Интернет

Телеконференции

Бюллетени

Инфо-сессии

Бюллетень проекта

Обучение

Стенды вопросов

Электронная почта

Общение в фойе

Телефонные разговоры

Участники проекта

Отдел сбыта

Руководство

среднего звена

Производствен-

ные отделы

Поставщики

Профсоюзы

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

Организация обратной связи по проекту

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

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

Мониторинг эффективности каналов информирования предполагает следующие аспекты:

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

· достаточная интенсивность поступающей информации;

· полнота информации, поступающей по установленным официальным каналам информирования.

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

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

Идентификация объектов управления конфигурацией проекта

Для введения в этот раздел, относительно редко выносимый на отдельное рассмотрение, дадим определение ключевым терминам.

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

Элемент конфигурации – результат проекта или компонент результата, контролируемый в рамках процесса управления конфигурацией.

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

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

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

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

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

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

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

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

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

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

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

Процедура создания нового элемента конфигурации

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

Инфраструктура проекта

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

· рабочие места;

· системы (серверы приложений и баз данных).

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

Пример требований к инфраструктуре офиса проекта (фрагмент)

Специальные помещения

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

Требования к помещениям

Помещение проектного офиса должно удовлетворять следующим требованиям:

на одного сотрудника должно приходиться не менее 5 м2 площади рабочей комнаты, рабочее место каждого сотрудника должно быть обеспечено:

· отдельным рабочим столом;

· стулом;

· двумя розетками электрической сети;

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

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

· телефонным аппаратом (по дополнительному обоснованию). Каждое помещение офиса должно быть обеспечено:

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

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

· одним шкафом для документов.

Рабочей группе проекта должна быть выделена в пользование рабочая комната для проведения переговоров, оборудованная:

· столом для заседаний;

· стульями;

· флип-чартом;

· экраном и проектором для проведения совещаний с участием 10 человек.

Обеспечение членов рабочей группы проекта персональными компьютерами :

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

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

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

Обеспечение рабочей группы проекта копировальной техникой Рабочая группа проекта обеспечивается заказчиком одним копировальным аппаратом с возможностью двухстороннего копирования листов формата А3 и А4 и автоматической подачей листов оригинала.

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

Обеспечение информационного обмена членов рабочей группы проекта

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

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

· Заказчик обеспечивает доступ в Интернет для всех членов рабочей группы проекта.

· Заказчик обеспечивает выделение адреса электронной почты каждому члену рабочей группы проекта.

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

Режим и место работы членов объединенной рабочей группы проекта

· Работы по проекту выполняются сотрудниками исполнителя или субподрядчика на территории заказчика и/или на территории исполнителя/субподрядчика.

· Начало рабочего дня для членов рабочей группы проекта – 9 часов 00 минут, окончание рабочего дня – 18 часов 00 минут, длительность обеденного перерыва – 1 час в интервале времени с 12:00 до 15:00. Руководители проекта от заказчика и исполнителя имеют право изменять режим работы для привлекаемых к проекту сотрудников при условии взаимного согласования таких изменений.

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

Пример процедуры создания инфраструктуры проекта

Для создания инфраструктуры необходимо:

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

· организовать установку оборудования – обеспечить доставку, провести установку и тестирование оборудования;

· обеспечить сервисное обслуживание оборудования – разработать график сервисного обслуживания;

· протестировать рабочую среду на предмет ее совместимости с требованиями к функциональности, совместимости и доступности.

Формирование базовой линии конфигурации проекта

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

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

Организация управления конфигурацией проекта

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

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

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

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

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

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

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

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

В зависимости от размера проекта некоторые пункты плана могут быть пропущены.

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

Организация документирования статуса элементов конфигурации

Пример процедуры обеспечения хранения документов.

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

Пример процедуры рассылки документов.

Пример процедуры подготовки документов

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

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

История изменений включает дату изменения, автора вносимого изменения.

Пример процедуры отчетности о деятельности

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

Проектные документы будут готовиться проектными группами в ходе всего проекта, в соответствии с планом работ по проекту.

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

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

Для выполнения документов будут использованы следующие программные средства:

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

· Microsoft Project 2010 – для подготовки планов проекта;

· Visio 2010 – для графического описания бизнес процессов.

Вся проектная документация будет храниться в электронном виде в библиотеке проекта.

Таблица 7.3. Структура плана управления конфигурацией
Раздел плана	Раздел плана	Требования к содержанию	Дополнительные комментарии
1. Введение		Введение в план УК представляет собой обзор содержания документа. Включает цели, область действия, определения, акронимы, сокращения, ссылки и обзор плана конфигурационного управления	Введение позволяет сделать документ более читаемым – объяснить основные моменты и расставить правильные акценты
1.1 Назначение		Содержит назначение документа "План конфигурационного управления"	Как правило, в назначение можно включить описание целей, которые решает данный план. Ведь план, в зависимости от размеров проекта, от географического распределения, также может различаться
1.2 Область применения		Краткое описание области применения плана; с какой моделью он связан, другие особенности, влияющие на документ	Зачастую можно описать подразделения, участвующие в процессе УК. Описать условия применения. При определении области полезно ответить для себя на ряд вопросов: Какова характеристика подконтрольных конфигурационных элементов? Чем должны управлять интерфейсы высокого уровня? Каковы временные рамки проекта? Каковы доступные ресурсы? Каковы подконтрольные сущности?
1.3 Определения, акронимы и сокращения	Definitions, Acronyms and Abbreviations	Представляет собой определения всех терминов, акронимов и сокращений, требующихся для точной интерпретации документа "План конфигурационного управления". Для предоставления этой информации можно воспользоваться ссылками на словарь проекта	Нам часто приходится сталкиваться с тем, что данный раздел либо игнорируют совсем, либо не придают ему особого значения. Те не менее, глоссарий – это составная и неотъемлемая часть ЛЮБОГО документа, плана УК в том числе.Здесь необходимо отразить и объяснить все термины УК и разрабатываемого продукта. Необходимо помнить, что хороший глоссарий позволит всем находиться в одном терминологическом пространстве. Вопросы: Определения легки и понятны всем участникам проекта? Есть ли список, на который можно легко сослаться? Необходимо ли определять данный термин?
		Этот подраздел представляет полный список всех документов, на которые имеется ссылка где-либо в "Плане конфигурационного управления". Идентифицируется каждый документ по названию, номеру отчета (если есть), дате и организации, его опубликовавшей. Указывается источник, из которого могут быть получены указанные документы. Для предоставления этой информации можно воспользоваться ссылками на приложения или другие документы	План УК редко разрабатывается сам по себе. Он является частью нормативно-методического обеспечения проекта. Нет смысла в плане повторять дословно разделы из других документов. Проще сформировать ссылку на документ, а в данном разделе указать все используемые источники (в том числе документы RUP, стандарты, международные и отраслевые стандарты). Вопросы: Применяются ли в плане положения, методики политики, уже используемые в организации?
		Обзор документа по разделам	Необходимо понимать, что не все участники проекта будут читать документ от корки до корки. Обзор необходим для того, чтобы впоследствии можно было читать те разделы, которые нужны в данный момент данной роли
2. Конфигурационное управление программным продуктом	Software Configuration Management		Один из основных разделов. Описывает все технические и технологические аспекты применения УК в проекте или организации. Количество подразделов и их вложенность могут отличаться от приведенных ниже
2.1 Организация, распределение ответственности и взаимодействия	Organization, Responsibilities and Interfaces	Указывается, кто будет ответственным за выполнение различных зада ч конфигурационного управления, описанных в ходе процессов конфигурационного управления	Данный пункт оговаривает не только список ответственных за выполняемые действия, но может описывать состав и взаимодействие между проектными группами. Данный аспект особенно важен, если речь идет о разработке, распределенной по нескольким географическим точкам. Эффективное дополнение данного раздела – подраздел, описывающий политику доступа. Это может быть простая таблица, в которой описывается в терминах применяемых средств автоматизации процесса, что можно выполнять отдельному участнику проекту, а что для него запрещено. Обычно для этого выбирают способ описания либо только доступных операций, либо только запрещенных.В дальнейшем данная политика перекладывается в средства реализации, где выставляются соответствующие разрешения и запрещения. В зависимости от выбранной проектной структуры (матричной или иерархической) адаптируется политика. Вопросы: Каковы возможности организации по штату для выполнения операций УК? Какова структура управления? Каков стиль управления? Кто будет ответственным за выполнение операций? Какие организационные изменения могут быть в течение жизни плана УК? Каковы планы по поддержке текущей организационной структуры? Какой уровень поддержки необходим для осуществления плана УК? Это единственный проект для руководства, или руководство управляет несколькими проектами одновременно? Как распределяется ответственность при возникновении нештатных ситуаций? Имеются ли особенности для этого проекта, которые могут повлиять на бизнес? Какие действия выполняет группа ССВ в проектном управлении при планировании? Прозрачно ли описаны роли участников?
2.2 Инструментарий, рабочая среда и инфраструктура	Tools, Environment and Infrastructure	Рассматриваются рабочая среда и программное обеспечение, которое будет использовано при выполнении функций конфигурационного управления в ходе жизненного цикла проекта или программного продукта. Описываются инструменты и процедуры, которые нужно использовать для версионного контроля объектов конфигурационного управления, создаваемых в ходе жизненного цикла проекта или программного продукта. Вопросы, рассматриваемые при настройке рабочей среды конфигурационного управления ожидаемый размер данных по программному продукту; распределение рабочей команды; расположение серверов и рабочих станций	Детальное описание данного пункта позволит, для начала, понять самим, какие средства разработки используются в компании (зачастую до начала внедрения в большой компании никто, кроме начальника отдела разработки, не представляет полного списка средств). Полный учет средств необходим еще и для того, чтобы определить методы интеграции средств разработки со средствами УК, ведь известно, что любое средство УК имеет ограниченные возможности по интеграции со средствами разработки. Задача менеджера УК и администратора в этом случае заключается в том, чтобы выбрать сторонние разработки, которые либо делают интеграцию более полной, либо просто добавляют саму интеграцию в используемое средство разработки + в средство УК. Не менее важно описать среду исполнения. Не все средства УК одинаково ставятся на всех платформах. Здесь могут быть особенности. Как вариант: сервер Linux, клиенты Windows. Не все средства УК умеют работать в подобной среде, что надо учитывать при выборе средства. Вопросы: Каковы организационные интерфейсы? Как взаимодействуют процессы? Каков перечень процессов для взаимодействия? Каковы интерфейсы между применяемыми средствами автоматизации? Какова зависимость между ними? Есть ли аппаратная зависимость? Где определены документы, регламентирующие процесс? Они утверждены? Каковы процедуры внесения изменений в эти документы? Каковы задействованные ресурсы (человеческие, оборудование)?
3. Программа конфигурационного управления	The Configuration Management Program
3.1 Конфигурационная идентификация	Configuration Identification		Доступны ли стандартные методы идентификации? В чем состоит используемая схема идентификации объектов УК? Связаны ли программная и аппаратная идентификация (для встроенных систем)? Какие спецификации и планы управления должны быть идентифицированы? Необходима ли специальная схема идентификации, чтобы отслеживать ПС третьей стороны? Есть ли разница в идентификации элементов в зависимости от типа приложений? Есть ли подтипы (например, компилятор C++ может работать с файлами с, срр, h, hpp и др)? Идентифицируются ли и хранятся скрипты автоматизированного тестирования?
3.1.1 Методы идентификации	Identification Methods	Описывается, как именуются, маркируются и нумеруются артефакты проекта или программного продукта. Схема идентификации должна покрывать оборудование, системное программное обеспечение, продукты внешних разработчиков и все артефакты разрабатываемого приложения, указанные в структуре директорий программного продукта; например, модели, планы, компоненты, тестовое ПО, результаты и данные, исполняемые файлы и т.д.	Очень важный пункт, в котором нужно описать все правила именования объектов УК. Также здесь должна быть детально расписана структура каталогов проекта. Обычно к моменту внедрения УК структура каталогов проекта складывается исторически, зачастую – спонтанно. Цель описания – выработать новую, более эффективную структуру. Практика показывает, что человек на этапе восстановления структуры может увидеть уязвимые или неэффективные места
3.1.2 Базовые версии проекта	Project Baselines	Базовые версии предоставляют официальный стандарт, на котором основывается последующая работа и для которого проводятся только авторизованные изменения. Описывается, в какой точке жизненного цикла проекта или продукта должны создаваться базовые версии. Наиболее общие базовые версии должны быть в конце каждой из фаз обследования, проработки проекта, построения системы и передачи в эксплуатацию. Базовые версии также могут создаваться в конце итераций внутри различных фаз или даже чаще. Определяется, кто может создавать базовые версии и что входит в их состав (обычно это интегратор, но может быть и по-другому)	Здесь описывается то, каким образом будет происходить сама работа в средстве УК: как будут ставиться метки, как выпускаться релизы, сколько ветвей для реализации проекта будет использовано и по какому принципу ветви будут именоваться. Обратите особое внимание на данный пункт – без него невозможна эффективная работа. При проработке пункта учитывается региональная раздробленность команды (влияет состав команд, количество регионов), интенсивность внесения изменений, количество выпускаемых релизов за единицу времени. Соответственно, в зависимости от данных показателей выбирается наиболее эффективный способ управления конфигурациями, что и отражается в данном разделе. Вопросы: Какой способ выбора базовых версий используется? Для всех ли элементов базовые версии строятся по одинаковым правилам? Кто разрешает создание базовых версий? Кто физически создает базовую версию? Как и по какому шаблону создаются базовые версии? Как осуществляется продвижение базовых версий? Как и кем осуществляется проверка базовых версий? Какова периодичность проверок? Используется ли существующий (устоявшийся) стандарт именования меток и ответвлений? – Есть ли иерархия между объектами? Какая?
3.2 Контроль конфигураций и изменении	Configuration and Change Control		Как известно, процесс УК состоит из двух частей -управление изменениями и управления версиями. Управление изменениями – неотъемлемая и важная часть процесса. Управлять необходимо любыми изменениями: от заявок пользователей до исправляемых дефектов. Данный раздел содержит полное описание всех запросов на изменения, включая атрибуты и жизненный цикл. Подробное описание – залог успешно построенного процесса УК. Очень часто для отслеживания существенных событий в проекте применяют уведомления различного вида. Как правило, это уведомления по электронной почте (например, при исправлении ошибки тестер получает уведомление и может приступить к тестированию). Укажите все типы уведомлений, которые применяются в проекте. Вопросы: Какие типы запросов планируется использовать в процессе УК? Каков полный цикл запросов на изменения? Будет ли храниться в системе УК справочная информация, или необходимо подключаться к имеющейся справочной информации? В какой информации, возможно, будут нуждаться члены ССВ? Каковы основные ожидания от автоматизации управления изменениями? При иерархической проектной структуре как будут приниматься решения по запросу? Необходимо ли управлять всеми запросами на изменения? Какой уровень детальности управления будет выбран (сколько шагов/этапов)? Обеспечивается ли отслеживание изменений в исходных текстах (есть ли связь между изменениями на верхнем уровнем и описанием изменений на уровне файлов)? Как исходный текст ассоциируется с запросом? Будет ли применена система оповещений?
3.2.1 Отработка и утверждение запросов на изменение	Change RequestProcessing and Approval	Рассматриваются процессы, которые обеспечивают внесение, рассмотрение и упорядочение проблем и изменений	Определяются типы запросов. Как правило, это дефект, запрос на расширение, задача и заявка. Состав типов может существенно меняться, главное – не сводить все управление изменениями к одному типу запросов (очень часто, кроме как дефектами компании, ничем не управляют)
3.2.2 Группа управления изменениями	Change Control Board(CCB)	Описывается, кто входит в состав группы управления изменениями, и процедуры, которым она следует, для отработки и утверждения запросов на изменение. В некоторых случаях указывается регламент сбора группы	Решение о принятии запроса от пользователя, решение о реализации новой технической идеи практически никогда не принимаются одним человеком. В любой компании это группа людей. В терминах стандартов данная группа называется ССВ. В данном разделе необходимо описать состав участников (как правило, это аналитик или постановщик, лидер группы разработчиков, лидер группы тестировщиков и представитель отдела маркетинга) и периодичность заседаний. Например, группа ССВ может собираться каждую неделю (по регламенту) либо по возникшей потребности (не рекомендуется). Вопросы: Каковы пределы полномочий группы? Одна группа на все проекты или несколько групп, каждая на свой проект? Если несколько, то каким образом они сотрудничают друг с другом? Есть ли иерархия ССВ? Кто отвечает за коммуникации между ССВ? Будет ли поддерживать система УК специальные запросы для организации встреч и выпуска протоколов по результатам? Есть ли потребность в выработке регламента для ограничения действий группы (жесткий регламент встреч с высокой степенью формализма)? Как различаются уровни привилегий в группе? Меняет ли введение группы ССВ установленный порядок принятия решений в организации? Введены ли в состав ССВ все ключевые участники, включая менеджера УК, менеджера проекта, лидера тестировщиков, лидера разработчиков и архитекторов? Каковы процедуры устранения разногласий (выпуск протокола разногласий или нечто иное)? Автоматизирована ли данная процедура?
3.3 Учет состояния конфигурации	Configuration Status Accounting
3.3.1 Хранение материалов проекта и выпуск релизов	Project Media Storage and Release Process	Описываются правила хранения и регламенты резервирования, действия на случай непредвиденных обстоятельств. Описание процесса выпуска релизов включает их содержание, для кого они предназначены и имеются ли какие-либо известные проблемы и инструкции по инсталляции (можно вынести в отдельное приложение)
3.3.2 Отчеты и проверки	Reports and Aidits	Рассматривается содержание, формат и цель запрашиваемых отчетов и проверок состояния конфигурации. Отчеты используются для получения данных о качестве программного продукта в любой заданный момент времени жизненного цикла программного продукта или проекта. Отчетность по дефектам, основанная на запросах на изменения, может обеспечить некоторые удобные индикаторы качества и, следовательно, предостеречь предупредить? Потому что предостеречь от чего-либо менеджеров и разработчиков об определенных критических областях процесса разработки	Отчетам следует уделить особое внимание. Только по отчетам можно проследить ход выполнения работ. Здесь необходимо определить отчеты по ролям участников проекта и описать их формат. Также рекомендуется сформировать регламент сбора отчета, то есть, с какой периодичностью собираются метрики (в реальном времени, раз в день… и т. д.). Желательно выделить различные типы отчетов и периодичность сбора их метрик. Вопросы: Есть ли необходимость в более чем одной ревизии для каждой базовой версии? Вовлечены ли субподрядчики в ревизию? Отчеты Вопросы: Какие метрики собираются в ходе проекта? Какие типы отчетов необходимо иметь? Каковы способы представления отчетной информации? Есть ли внешние отчетные документы для клиентов? Дифференцируются ли отчеты в зависимости от типа выполняемой участником роли в проекте? Доступны ли отчеты? Какие будут предусмотрены формальные шаги для получения отчетов? Какие типы нотификационных сообщений будут применяться? Отслеживаются ли тенденции в проекте? По каким отчетам? Как ведется учет (статически, динамически)? Какие средства используются для получения отчетов (допускается использование любого числа систем для получения достоверной и понятной информации о ходе проекта)?
3.3.3 Документирование		Раздел определяет способы и типы документов
3.3.3.1 Описание версии	\eision Description	Данный документ описывает диски, CD или другие носители, используемые для поставки ПО. Также данный раздел также определяет состав документов, поставляемых с версией ПО и доступных для конечных пользователей	Примерный состав документов: архив релизов с описанием (Release Media); описание релиза (Release Notes); описание функций; перечень решенных проблем в релизе; перечень новых возможностей; инструкция по установке ПО; инвентаризация, опись. Данный пункт может содержать основные правила формирования документов, отражать способ выпуска документов (ручной, автоматический). Требования к оформлению документов и шаблоны документов должны быть вынесены в приложение к плану УК. Перечень приведенных документов относится к выпуску ПС для каждой версии, релиза, патча. В зависимости от выбранной модели выпуска состав документов, а также их детальность могут различаться
3.3.3.2 Документирование процесса		Общие документы требуются в случаях, когда продукт разрабатывается для крупных организаций, а также в тех случаях, когда продукт представляет собой программно-аппаратный комплекс	Типовые документы для данного раздела: описание системы, в которой используется ПС; описание административного управления программными средствами системы; руководство системного администратора; руководство пользователя; паспорт на ПС (общие сведения о ПС, основные характеристики, комплектность, акты о приемке и снятии с эксплуатации… и т. д.). Требования к оформлению документов и шаблоны документов должны быть вынесены в приложение к плану УК
		Детально рассматриваются этапы работ для заказчика и внутренние, относящиеся к работам по УК для программного продукта или проекта. Эта секция обычно включает детальное описание того, когда может быть модифицирован сам план конфигурационного управления	В зависимости от выбранной модели может измениться содержание этапов. Рекомендуется описать, что выполняется в УК в зависимости от этапа проекта
5. Обучение и ресурсы	Training and Resources	Рассматриваются инструментальные средства, персонал и обучение, требуемые для реализации описанных в плане задач
6. Субподрядчики и контроль программного обеспечения со стороны поставщиков	Subcontractor and Vendor Software Control	Описывается, как будет интегрировано программное обеспечение, разработанное вне среды УК проекта	К работе над проектом могут привлекаться субподрядчики. Данный раздел описывает, каким образом будет происходить работа с субподрядчиком. Вопросы: Разработка ведется только в одно организации или в обеих? Каковы процедуры корректировки дефектов в разрабатываемом продукте? Автоматизированы ли они (полностью или частично)? Какие изменения допустимо вносить заказчику в исходные тексты после получения продукта? Ставится ли в известность об этом субподрядчик и в какой мере? Когда и как выполняются ревизии? Какой набор инструментальных средств используется заказчиком и субподрядчиком? Необходимы ли дополнительные модули синхронизации (для тех случаев, когда заказчик и подрядчик используют разные системы УК от разных производителей)? Как контролируется субподрядная организация? Кто отвечает за работу с субподрядчиком? Работает ли субподрядчик по своим процессам или заказчик обязывает его работать по собственным? Как решаются конфликты? Разрешено ли субподрядчику осуществлять полную сборку продукта у себя, или заказчик выделяет стенд для сборки на своей территории? Допускается ли субподрядчик к справочной информации заказчика (доступ к реальным базам данных, справочникам)?
Приложения		Состав приложений не определяется стандартами. Обычно включает в себя такие документы, как: регламенты; инструкции по использованию средств УК (как пользовательские, так и административные); различные методические пособия; планы обучения; инструкции по установке и администрированию средств УКит.д.	Руководствуйтесь целесообразностью внесения тех или иных изменений. Оцените, все ли попало в основные разделы плана. Если основные разделы слишком разрослись, то, возможно, нужно вынести из них часть информации в приложение

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

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

Что нужно отразить в плане коммуникаций:

Перечень всех участников проекта (как тех, кто непосредственно работает по проекту, так и тех, кто на него может как-то повлиять) с указанием имени, должности, роли и контактных данных. Когда в проекте больше 80 человек, иметь в одном месте все телефоны и мэйлы – бесценно. Для себя крайне желательно провести анализ всех участников на предмет влияния, возможности сделать вашему проекту сильно хорошо или сильно плохо, заинтересованности, стратегии взаимодействия и проч. (об этом мы еще поговорим), но в план коммуникаций это включать ни в коем случае нельзя.
Основные принципы коммуникации. Если соблюдение субординации – это ценность для вас, и в проекте это важно, то план – то самое место, где это нужно написать. В основные принципы коммуникации включаются те нормы и правила поведения, которые должны соблюдать команда для эффективной работы по проекту. Например, совещания начинаются ровно в указанное время (или, наоборот, не начинаются, пока все участники не соберутся). Или «на совещаниях по телефону не разговариваем». Включайте сюда только те пункты, соблюдение которых вы можете обеспечить. Например, очень плохая идея – установить правило «нет телефону на встречах», а самому все равно хвататься за смартфон при звонке спонсора (или жены), объясняя всем с большими глазами «ну это же спонсор!».
Используемые способы связи. Тут нужно перечислить, какие группы заинтересованных лиц какие каналы связи используют, а также убедиться, что они их действительно используют. Например, очень легко написать «мэйл» для заказчика (а что, он же у него есть), а потом через полгода узнать, что у него почту разбирает секретарша, и он ни одного вашего письма не видел. Типовой набор – корпоративный и мобильный номер телефона, система обмена сообщениями типа Lynс или Skype, электронная почта, системы видеоконференций, личные встречи и проч. В последнее время в планах все чаще появляются такие вещи как WhatsApp или Viber.
Табличка с перечнем плановых коммуникаций, включающая группу или перечень заинтересованных лиц, ответственного, регулярность, способ связи, содержание коммуникации, требования к коммуникации. Например:

№

Участники

Ответственный

Тип

Регулярность

Содержание

Требования

Комментарий

Группа «Руководители всех подразделений внутри контрактного департамента»

Руководитель проекта

Созвон по Skype

1 раз в 2 недели, 30 минут

1. Ознакомление с ходом проекта

2. Ознакомление с перечнем планируемых контрактов по проекту в ближайший месяц

3. Обсуждение хода уже заключенных контрактов

1. За 2 дня до созвона высылается повторное приглашение-напоминание

2. По итогам руководитель проекта готовит протокол

Петров П.П., Руководитель закупок материалов по РФ, отсутствует с 1 по 5 число каждого месяца (в командировке), в случае если созвон попадает на эту дату необходимо приглашать его заместителя Авдееву А.А.

Все участники проекта

Администратор проекта

Рассылка по email

Раз в месяц

Презентация с информацией о ходе проекта

Используется такой-то шаблон

–

В примере перечислена коммуникация типа «push» (мы практически «насильно» доносим информацию), но в этой же таблице можно указывать коммуникацию типа «pull» (участник сам отвечает за получение информации, например, зайти раз в неделю и посмотреть обновления списка задач на корпоративном портале).

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

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

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

Иногда план коммуникаций «бьют» на несколько для разных групп заинтересованных лиц, чтобы его было проще согласовать, с моей точки зрения это имеет смысл при 50+ участниках проекта. Основное правило тут – степень зарегулированности плана должна быть пропорциональна рискам его неисполнения и как-то коррелировать с количеством участников и объемом проекта Именно из-за ситуаций, когда на проект из 10 человек пишется план на 15 страниц, регламентирующий, сколько раз в неделю они вместе пьют кофе, и бытует мнение, что «управление проектами – это про бессмысленные бумажки».

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

Как всегда, ниже дежурный пример плана коммуникаций для проекта «ремонт дома», чтобы стало понятнее.

Исходим из того, что руководитель проекта я.

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

№

Участники

Ответственный

Тип

Регулярность

Содержание

Требования

Отрывок из главы А.В.Полковникова "Коммуникации проекта" из книги "Управление инвестициями"/ Под общ. ред. В.В. Шеремета. - М.: Высшая школа, 1998.

Процессы управления коммуникациями.

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

Планирование системы коммуникаций - определение информационных потребностей участников проекта (состав информации, сроки и способы доставки).

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

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

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

Планирование системы коммуникаций.

Для изучения потребностей и описания структуры системы коммуникаций обычно требуется следующая информация:

Логическая структура организации проекта и матрица ответственности.

Информационные потребности участников проекта.

Физическая структура распределения участников проекта.

Внешние информационные потребности проекта.

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

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

Доступностью технологий.

Квалификацией и подготовленностью кадров.

План управления коммуникациями включает в себя:

План сбора информации, в котором определяются источники информации и методы ее получения.

План распределения информации, в котором определяются потребители информации и методы доставки.

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

Расписание и частота взаимодействий.

Метод внесения изменений в план коммуникаций.

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

Оценка и отображение прогресса.

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

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

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

Сбор и распределение информации.

В рамках проекта существует потребность в осуществлении различных видов коммуникаций:

Внутренние (внутри команды проекта) и в нешние (с руководством компании, заказчиком, внешними организациями и т.д.);

Формальные (отчеты, запросы, совещания) и неформальные (напоминания, обсуждения);

Письменные и устные ;

Вертикальные и горизонтальные .

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

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

Автоматизированные методы предусматривают использование компьютерных технологий и современых средств связи для повышения эффективности взаимодействия.

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

Документирование хода работ.

Основные промежуточные результаты хода работ должны быть формально задокументированы.

Документирование результатов хода работ включает в себя:

Сбор и верификацию окончательных данных;

Анализ и выводы о степени достижения результатов проекта и эффективности выполненных работ;

Архивирование результатов с целью дальнейшего использования.

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

Управление коммуникациями и информационные технологии.

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

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

Эра господства больших ЭВМ, дорогостоящего специализированного программного обеспечения для управления проектами и дорогостоящих экспертов, умевших использовать это программное обеспечение продолжалась до середины 80-х годов. Использование автоматизированных систем управления проектами было ограничено организациями и проектами, бюджет которых позволял оплатить от $500.000 до $1.000.000 за установку соответствующих систем и привлечение специалистов.

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

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

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

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

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

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

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

План коммуникаций формализуется и детализируется в зависимости от потребностей проекта.

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

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

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

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

Основные промежуточные результаты хода работ должны быть формально задокументированы.

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

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

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

Информационные технологии и системы управления проектами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основными функциональными элементами интегрированной информационной системы поддержки принятия решений на стадии выполнения проекта являются: модуль календарно-сетевого планирования и контроля работ проекта; модуль ведения бухгалтерии проекта; модуль финансового контроля и прогнозирования. Важнейшим компонентом интегрированных информационных систем поддержки принятия решений являются системы управления базами данных (СУБД). Их основными функциями являются поддержка целостности, защищенности, архивации и синхронизации данных в условиях многопользовательской работы.

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

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

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

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

Обзор программного обеспечения по управлению проектами, представленного на российском рынке

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

Наиболее распространенное на российском рынке программное обеспечение для управления проектами. Программные продукты недорогой части рынка: Microsoft Project 2000, производитель- Microsoft Corporation.

Microsoft Project является на сегодняшний день самой распространенной в мире системой планирования проектов. Отличительной особенностью программы является ее простота и интерфейс, заимствованный от продуктов серии Microsoft Office 2000. Разработчики не стремятся вложить в пакет сложные алгоритмы календарно - сетевого и ресурсного планирования.

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

Более подробную информацию о Microsoft Project можно получить на http://www.microsoft.com/project.

TimeLine 6.5, производитель- Timeline Solutions Corporation.

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

Более подробную информацию о TimeLine 6.5 и сопутствующем программном обеспечении можно найти на http://www. tssolutions.

Spider Project, производитель - Spider Technologies Group.

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

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

Превосходя многие западные пакеты по мощности и гибкости отдельных функций, Spider Project, в целом, уступает в области программной реализации Профессиональные программные продукты фирмы WST Corporation.

OpenPlan - система управления проектами в рамках предприятия, представляющая собой профессиональный инструмент для многопроектного планирования и контроля. Предусматривает полный набор параметров для описания различных характеристик работ по проекту. Структуризация данных проекта обеспечивается использованием: структуры разбиения работ (WBS); структуры кодирования работ; иерархическая структура ресурсов (RBS);организационная структура предприятия (OBS). Система OpenPlan включает три основных программных продукта: OpenPlan Professional, OpenPlan Desktop и OpenPlan Enterprise, каждый из которых предназначен для решения задач определенных участников проекта: проект - менеджера, команды проекта, ответственных за выполнение работ, субподрядчиков и т. д.

OpenPlan Professional является рабочим инструментом менеджеров, управляющих крупными проектами, и: предоставляет мощные средства для ресурсного планирования в многопроектном режиме, включая поддержку иерархических ресурсов и ресурсных календарей. Имеется возможность планирования и контроля альтернативных и расходуемых ресурсов. Реализована методика освоенного объема; позволяет назначение зависимостей всех типов с временными задержками как в рамках одного проекта, так и между различными проектами; предоставляет гибкий инструмент построения табличных и графических отчетов.

OpenPlan Desktop является упрощенным вариантом OpenPlan Professional и используется как инструмент для работы с небольшими проектами или частью крупного проекта. Интеграция с OpenPlan Professional позволяет: использовать заготовленные в OpenPlan Professional шаблоны проектов с определенными в них кодами СРР, ССО, кодами работ, словарями ресурсов и т. п.; обеспечивать распределенную работу с проектами.

Оба программных продукта, OpenPian Desktop и OpenPlan Professional: позволяют учитывать риски; обеспечивают ограничение доступа к информации проектов; работают в архитектуре клиент/сервер на базе реляционных СУБД Oracle, Sybase и MSSQL Server; обеспечивают хранение данных в различных форматах; публикуют данные проекты на внешний (Интернет) и внутренний (Интранет) web-сайты.

OpenPlan Enterprise включает в себя основные характеристики OpenPlan Professional и интегрирован с ERP (система управления ресурсами предприятия) - приложениями. Это позволяет распределять данные проектов между другими информационными системами предприятия.

Более подробную информацию о серии программных продуктов OpenPlan можно найти на http://www.wst.com. Программные продукты фирмы Primavera Systems, Inc.

Все продукты этой фирмы разрабатываются в соответствии с идеологией Концентрического Управления Проектами (Concentric Project Management - СРМ), в основе которой лежит структурированный, интегрированный и масштабируемый подход к координации людей, команд и проектов. По сравнению с традиционной методологией управления проектами, в СРМ реализовано несколько важных преимуществ: визуализация данных позволяет отслеживать каждый проект, даже если реализуются одновременно несколько проектов, так как его результаты становятся прозрачными для компании. При этом возрастает роль расписаний по проекту, все менеджеры компании, включая самых главных, видят реальное состояние дел; координация инициирует диалог внутри компании. Если кто-либо отклоняется от стратегического курса компании, это немедленно выявляется и принимаются эффективные меры; усиление роли каждого исполнителя достигается за счет того, что люди знают, что их работа является частью выполнения общей большой задачи; конкурентные преимущества реализуются за счет специальных СРМ - средств анализа чувствительности и поддержки принятия решений, которые помогают выбрать наиболее конкурентоспособный проект, обеспечивающий наибольшую прибыль на инвестированный капитал. Primavera Project Planner (РЗ) 2.0-3.0 - программный продукт, предназначенный для календарно-сетевого планирования и управления с учетом потребностей в материальных, трудовых и финансовых ресурсах. Выполняет функцию центрального хранилища проектов, содержащего все данные расписания, где руководители и планировщики проекта создают единые структуры проекта.

SureTrak Project Manager (ST) 3.0 - аналогичный РЗ 2.0-3.0 инструмент, предназначенный для управления небольшими проектами, либо частями крупных проектов. Может быть использован проектировщиками и подрядчиками как инструмент планирования и контроля работ, заказчиками в качестве средства отслеживания хода проекта. SureTrak позволяет учесть все сложности, возникающие на этапе реализации проектов, включая недопоставки сырья или оборудования, задержки платежей, спрогнозировать величину денежных потоков и т. д.

Webster for Primavera используется совместно с РЗ 2.0-3.0 и позволяет участникам проекта просматривать список своих заданий и обновлять информацию об их выполнении из любой точки земного шара, используя для этого обычный web-броузер. Он обеспечивает доступ к данным проекта через внутрикорпоративную сеть Intranet или глобальную сеть Internet в режиме реального времени.

Monte Carlo for Primavera применяется для анализа рисков проекта, ведущихся в РЗ 2.0-3.0, и позволяет определять сроки работ и затраты на их выполнение с заданной вероятностью.

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

Новая линия программных продуктов Primavera Project Planner for the Enterprise (РЗе) поддерживает работу в архитектуре клиент-сервер, работает на базе таких реляционных СУБД, как Oracle и Microsoft SQL Server, за счет чего упрощается интеграция системы управления в существующую корпоративную информационную систему предприятия. По сравнению с РЗ 2.0-3.0 расширились возможности описания, данных работ, структуризации проекта: появилась поддержка организационной структуры предприятия и структуры ресурсов.

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

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

Более подробную информацию о программном обеспечении фирмы Primavera Systems, Inc. Можно узнать на http://www.primavera. msk.ru.

Artemis Views, производитель - Artemis International

Семейство Artemis Views состоит из набора модулей для автоматизации различных функций управления проектами: Project View, Resource View, TrackView, CostView. Все модули совместимый формат данных, работают в архитектуре клиент/сервер, поддерживают ODBC стандарт и легко интегрируются с популярными СУБД Oracle, SQLBase, SQLServer, Sybase. Каждый модуль может работать как независимо, так и в комбинации с другими. Цена на это традиционно недешевое ПО рассчитывается исходя из заказываемой конфигурации.

ProjectView позволяет: реализовать мультипроектную, многопользовательскую систему планирования и контроля проектов в организации; обеспечить механизм ограничения доступа при распределенной работе нескольких пользователей с проектом; формировать разнообразные отчеты за счет встроенных средств или с использованием специализированного ПО (например, Quest).

Resource View - специализированная система для планирования и контроля использования ресурсов. Поддерживаются средства выравнивания о оптимизации загрузки ресурсов.

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

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

На российском рынке представлено большое количество ПО для составления сметной документации, к которому относится: ABC, «Ресурсная смета», «Сметчик-строитель», АО «Багира», «Эксперт-Смета», «Оса», «РИК», «Инвестор» и др.

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

Интерфейсы программного обеспечения порой существенно отличаются друг от друга - существуют как ДОС, так и Windows - версии.

В разных сметных программах существуют различные возможности формирования и печати выходных форм - от простого вывода на принтер до передачи в широко распространенные приложения (MS Word, Excel и т. п.).

Особенности внедрения информационных систем управления проектами.

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

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

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

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

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

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

Мотивация

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

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

1) постоянные: принятые на предприятие без ограничения срока работы или по контракту на срок более одного года;

2) временные: принятые на предприятие на срок до двух месяцев или с целью замещения отсутствующего работника на период до четырех месяцев;

3) сезонные: устроенные на сезонную работу на срок до шести месяцев.

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

На основании выполняемых задач персонал подразделяется на две категории.

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

Цели подсистемы управления формированием человеческих ресурсов .

1) своевременное и качественное обеспечение предприятия соответствующими кадрами;

2) создание условий для максимальной реализации способностей работников и достижения целей организации.

Задачи подсистемы управления формированием человеческих ресурсов

1) прогнозирование и планирование потребности в работниках;

2) анализ спроса и предложения на рынке труда;

3) привлечение, подбор и отбор кадров;

4) адаптация вновь прибывших работников;

5) подъем эффективности выполняемых работ;

6) повышение качества деятельности работников;

7) повышение качества деятельности организации в целом;

8) рост уровня жизни работников;

9) совершенствование систем мотивации;

10) развитие инициативности и новаторства.

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

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

Формировать кадровый состав следует в соответствии со следующими показателями:

1) фактической численностью работников, включающей постоянных и временных работников, а также совместителей;

2) составом работников по характеру выполняемых видов деятельности (основным, вспомогательным, административным);

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

4) квалификационным уровнем человеческих ресурсов.

Эффективность использования человеческих ресурсов оценивается следующими показателями:

1) объемом производства, прибылью) на одного работника; 2) производительностью труда за единицу времени в натуральном и стоимостном выражении; 3) затрачиваемым временем на производство единицы продукции. Данный показатель используется в случае ориентации производства на один вид продукции и организации сферы услуг; 4) текучестью кадров; 5) показателем абсентеизма (отношением потерянного работниками рабочего времени к общему количеству рабочих часов за определенный период); 6) потерянной производительностью (произведением добавленной стоимости в час на количество потерянных часов, от неявки сотрудников на рабочие места); 7) коэффициентом внутренней мобильности (отношением числа сотрудников, подвергшихся ротации за определенный период, к среднему количеству сотрудников за тот же период); 8) общими издержками предприятия на оплату деятельности работников, включающую налоговые отчисления; 9) долями издержек на рабочую силу в общем объеме затрат; 10) издержками на одного сотрудника (отношением доли издержек на оплату труда к количеству работников на предприятии за определенный период); 11)издержками на оплату труда за один производительный час (отношением общих затрат на оплату труда к общему числу рабочих часов).

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

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

Условия успешного управления человеческими ресурсами: 1) четкость и достижимость поставленных целей; 2) глубина, объективность и комплексность анализа воздействия на систему управления человеческими ресурсами и организацию в целом; " 3) ясность и взаимосвязанность планов работы организации, а также обеспеченность их всеми видами ресурсов; 4) соответствие уровня квалификации персонала выполняемой работе; 5) совместное участие предельно большого количества сотрудников в разработке и реализации стратегических планов; 6) высокое качество контроля реализации стратегического плана и требований оценки его социально-экономической эффективности; 7) внедрение и использование современных средств труда и технологий; 8) делегирование полномочий, создание гибких условий труда. Необходимо обогащать труд, особенно создавать социально-психологический климат, недостаток которого способствует формированию высокой степени конфликтности между сотрудниками.

Факторы оценки профессионализма управления человеческими ресурсами : 1) профессиональная подготовка работников; 2) компетентность и мотивация профессиональной деятельности; 3) организационная среда реализации профессионализма.

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

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

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

2. Служащие - это работники, занимающиеся преимущественно умственным трудом.

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

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

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

Виды компетентности:

1) функциональный (профессиональные знания и способность их реализовать);

2) интеллектуальный (аналитическое мышление);

3) ситуативный (умение действовать по обстоятельствам);

4) социальный (коммуникабельность и умение добиваться поставленных целей).

К числу основных задач управления персоналом относят:

1. Помощь фирме в достижении цели.

2. Обеспечение фирмы квалифицированными и заинтересованными работниками.

3. Эффективное использование мастерства и способностей персонала.

4. Совершенствование систем мотивации.

5. Повышение уровня удовлетворенности трудом.

6. Развитие систем повышения квалификации и профессионального образования.

7. Сохранение благоприятного климата.

8. Планирование карьеры, то есть продвижение по службе, как вертикальное, так и горизонтальное.

9. Поднималась творческая активность персонала.

10. Совершенствование методов оценки деятельности персонала.

11. Обеспечение высокого уровня условий труда и качество жизни в целом.

Наиболее общие 3 задачи управления персоналом: обеспечение кадрами; эффективное использование кадров; профессиональное и социальное развитие кадров.

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

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

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

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

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

Microsoft Project является на сегодняшний день самой распространенной в мире системой планирования проектов. Отличительной особенностью программы является ее простота и интерфейс, заимствованный от продуктов серии Microsoft Office 2000. Разработчики не стремятся вложить в пакет сложные алгоритмы календарно - сетевого и ресурсного планирования. Программный продукт обеспечивает обмен проектной информацией между участниками проекта. Предоставляются возможности по планированию графика работ, отслеживанию их выполнения и анализу информации по портфелю проектов и отдельным проектам. В целом, Microsoft Project можно рекомендовать в качестве инструмента планирования и контроля небольших проектов пользователям-непрофессионалам в управлении проектами и новичкам.

TimeLine 6.5 , производитель- Timeline Solutions Corporation.

Spider Project , производитель - Spider Technologies Group.

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

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

OpenPlan - система управления проектами в рамках предприятия, представляющая собой профессиональный инструмент для многопроектного планирования и контроля. Предусматривает полный набор параметров для описания различных характеристик работ по проекту. Структуризация данных проекта обеспечивается использованием: структуры разбиения работ (WBS); структуры кодирования работ; иерархическая структура ресурсов (RBS);организационная структура предприятия (OBS). Система OpenPlan включает три основных программных продукта: OpenPlan Professional, OpenPlan Desktop и OpenPlan Enterprise, каждый из которых предназначен для решения задач определенных участников проекта: проект - менеджера, команды проекта, ответственных за выполнение работ, субподрядчиков и т. д. OpenPlan Professional является рабочим инструментом менеджеров, управляющих крупными проектами, и: предоставляет мощные средства для ресурсного планирования в многопроектном режиме, включая поддержку иерархических ресурсов и ресурсных календарей. Имеется возможность планирования и контроля альтернативных и расходуемых ресурсов. Реализована методика освоенного объема; позволяет назначение зависимостей всех типов с временными задержками как в рамках одного проекта, так и между различными проектами; предоставляет гибкий инструмент построения табличных и графических отчетов. OpenPlan Desktop является упрощенным вариантом OpenPlan Professional и используется как инструмент для работы с небольшими проектами или частью крупного проекта. Интеграция с OpenPlan Professional позволяет: использовать заготовленные в OpenPlan Professional шаблоны проектов с определенными в них кодами СРР, ССО, кодами работ, словарями ресурсов и т. п.; обеспечивать распределенную работу с проектами. Оба программных продукта, OpenPian Desktop и OpenPlan Professional: позволяют учитывать риски; обеспечивают ограничение доступа к информации проектов; работают в архитектуре клиент/сервер на базе реляционных СУБД Oracle, Sybase и MSSQL Server; обеспечивают хранение данных в различных форматах; публикуют данные проекты на внешний (Интернет) и внутренний (Интранет) web-сайты. OpenPlan Enterprise включает в себя основные характеристики OpenPlan Professional и интегрирован с ERP (система управления ресурсами предприятия) - приложениями. Это позволяет распределять данные проектов между другими информационными системами предприятия.

Бухгалтеру о налогах и кадрах. Налоги, бухгалтерия, отчетность, ККМ