ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 04.12.2019
Просмотров: 4021
Скачиваний: 5
76
При
таком
уровне
специализации
один
менеджер
уже
не
в
состоянии
обеспечить
принятие
управленческих
решений
с
должным
качеством
.
Управле
-
нием
проектами
занимается
целая
группа
.
Как
правило
,
один
менеджер
контро
-
лирует
группу
родственных
проектов
,
возможно
более
близких
по
номенклату
-
ре
используемых
ресурсов
,
либо
один
большой
проект
,
либо
одну
составную
работу
проекта
,
реализуемого
в
масштабах
региона
или
национальной
эконо
-
мики
.
В
связи
с
этим
возникает
необходимость
согласования
использования
ре
-
сурсов
между
проектами
,
управляемыми
разными
менеджерами
,
а
технология
PERT
требует
расширения
инструментальными
средствами
,
упрощающими
со
-
гласование
.
Программа
Microsoft Project
поддерживает
три
способа
взаимодействия
между
менеджерами
:
♦
подпроекты
;
♦
ресурсные
пулы
;
♦
серверы
проектов
.
Выбор
одного
из
них
зависит
от
сложности
решаемых
задач
,
обуслов
-
ленной
,
в
свою
очередь
,
тем
,
насколько
поддаются
упорядочению
взаимозави
-
симости
совместно
выполняемых
проектов
.
Подпроекты
используются
самостоятельно
либо
в
сочетании
с
двумя
ос
-
тальными
способами
.
Условие
использования
подпроектов
без
обращения
к
ре
-
сурсным
пулам
либо
серверу
проектов
следующее
:
можно
выделить
группы
ра
-
бот
,
использующих
непересекающиеся
подмножества
ресурсов
1
.
Пример
подобной
ситуации
—
управление
несколькими
небольшими
однородными
проектами
,
которые
выполняются
силами
фирм
-
заказчиков
услуг
по
управлению
проектами
и
требуют
надзора
со
стороны
специалистов
опреде
-
лённого
профиля
(
инженеров
,
юристов
,
врачей
и
т
.
д
.)
на
протяжении
всего
хода
их
выполнения
.
Обеспечение
услугами
по
надзору
берёт
на
себя
организация
,
управляющая
совокупностью
проектов
.
В
этом
случае
перераспределение
ре
-
сурсов
между
фирмами
-
заказчиками
обычно
невозможно
по
организационным
причинам
,
и
условия
использования
подпроектов
выполняются
.
С
точки
зрения
программной
реализации
подпроект
представляет
собой
самостоятельную
модель
проекта
,
реализованную
в
виде
отдельного
файла
Mi-
crosoft Project,
созданную
и
используемую
одним
менеджером
нижнего
звена
1
Обычно
литература
по
анализу
проектов
указывает
ещё
одно
условие
:
отсутствие
связей
между
работами
,
относящимися
к
разным
подпроектам
.
При
использовании
совре
-
менных
версий
Microsoft Project
выполнение
этого
условия
не
требуется
;
но
в
целях
повы
-
шения
скорости
вычислений
рекомендуется
выделять
подпроекты
так
,
чтобы
связей
между
работами
,
относящимися
к
разным
подпроектам
,
было
как
можно
меньше
.
77
(
возможно
,
при
поддержке
вспомогательного
персонала
).
Этот
менеджер
опре
-
деляет
все
исходные
данные
для
модели
своего
проекта
и
осуществляет
(
либо
организует
)
его
мониторинг
.
Генеральный
менеджер
имеет
модель
генерального
проекта
—
совокуп
-
ности
совместно
выполняемых
проектов
,
где
подпроекты
представлены
в
фор
-
ме
составных
работ
.
Данные
о
последних
содержатся
не
в
файле
модели
,
ис
-
пользуемой
генеральным
менеджером
,
а
в
соответствующем
файле
менеджера
низшего
звена
.
Файлы
подпроектов
целесообразно
размещать
в
персональных
каталогах
(
папках
)
менеджеров
нижнего
звена
на
файловом
сервере
локальной
вычисли
-
тельной
сети
организации
.
При
использовании
подпроектов
без
ресурсных
пулов
ни
один
ресурс
не
должен
описываться
более
чем
в
одной
модели
проекта
:
каждый
менеджер
ра
-
ботает
только
с
ресурсами
,
находящимися
в
его
ведении
.
Все
расчёты
выпол
-
няются
в
файле
,
содержащем
данные
о
модели
генерального
проекта
:
в
против
-
ном
случае
возможности
оптимизации
расписания
,
связанные
с
изменением
сроков
выполнения
работ
в
других
подпроектах
,
не
будут
реализованы
.
Схема
информационного
обмена
между
компонентами
проекта
для
случая
,
когда
один
из
трёх
подпроектов
доступен
генеральному
менеджеру
только
для
чтения
,
представлена
на
рис
.11.
Генеральный
проект
Подпроект
I
Подпроект
II
Подпроект
III
(
только
чтение
)
Даты
и
время
,
затраты
Исправления
Параметры
работ
и
ресурсов
,
данные
мониторинга
Рис
. 11.
Схема
информационного
взаимодействия
моделей
генерального
проекта
и
подпроектов
в
Microsoft Project
на
рабочем
месте
генерального
менеджера
.
78
З а м е ч а н и е
.
В
приведённом
на
рис
.11
примере
генеральный
менеджер
имеет
полномочия
вносить
изменения
в
подпроекты
I
и
II.
Он
может
воспользоваться
ими
при
крайней
необходимости
,
но
с
организа
-
ционной
точки
зрения
подобной
практики
следует
избегать
как
в
целях
разграничения
ответственности
,
так
и
во
избежание
путаницы
,
принятия
взаимно
противоречащих
решений
.
Хороший
стиль
управления
проекта
-
ми
предполагает
,
что
генеральный
менеджер
распределяет
только
ресур
-
сы
,
назначаемые
на
подпроекты
в
целом
,
а
также
на
работы
,
не
вошедшие
ни
в
один
из
подпроектов
.
Он
не
вмешивается
в
работу
менеджеров
низ
-
шего
звена
.
В
целях
разделения
ответственности
файлы
подпроектов
можно
защитить
от
вмешательства
генерального
менеджера
средствами
опера
-
ционной
системы
.
Но
тогда
менеджер
подпроекта
,
чтобы
получить
дан
-
ные
о
согласованном
расписании
,
составленном
генеральным
менедже
-
ром
,
должен
будет
открыть
файл
генерального
проекта
.
Генеральный
проект
(
только
чтение
)
Подпроект
I
(
только
чтение
)
Подпроект
II
(
только
чтение
)
Подпроект
III
Даты
и
время
,
затраты
Параметры
работ
и
ресурсов
,
данные
мониторинга
Рис
. 12.
Схема
информационного
взаимодействия
моделей
генерального
проекта
и
подпроектов
в
Microsoft Project
на
рабочем
месте
менеджера
подпроекта
III.
Если
генеральный
проект
не
содержит
конфиденциальной
информации
,
которая
не
должна
быть
доступна
менеджерам
подпроектов
,
то
генеральному
менеджеру
рекомендуется
предоставить
своим
подчинённым
доступ
к
файлу
генерального
проекта
на
чтение
.
Тогда
менеджеры
нижнего
звена
получат
воз
-
можность
наблюдать
влияние
изменений
,
вносимых
ими
в
модель
проекта
или
79
в
данные
мониторинга
,
на
оперативный
план
,
не
дожидаясь
интеграции
произ
-
ведённых
корректировок
в
генеральный
проект
.
В
этом
случае
менеджер
под
-
проекта
открывает
файл
генерального
проекта
,
но
вносит
необходимые
измене
-
ния
только
в
свой
подпроект
.
Возникающие
при
этом
информационные
потоки
отражены
на
рис
.12.
Для
создания
подпроектов
требуется
установить
связь
между
файлом
генерального
проекта
и
файлами
подпроектов
.
Для
этого
:
1)
создать
файлы
,
в
которых
будут
храниться
подпроекты
;
2)
ввести
в
них
данные
моделей
подпроектов
;
3)
создать
файл
генерального
проекта
;
4)
повторить
для
каждого
файла
подпроекта
следующие
действия
:
ус
-
тановив
табличный
курсор
в
первую
свободную
строку
таблицы
работ
гене
-
рального
проекта
,
дать
команду
Insert Project…
и
указать
требуемый
файл
подпроекта
1
;
5)
добавить
в
файл
генерального
проекта
данные
о
работах
и
ресурсах
,
контролируемых
непосредственно
генеральным
менеджером
;
6)
установить
связи
между
работами
генерального
проекта
и
,
если
тре
-
буется
,
работами
из
разных
подпроектов
(
последнего
по
возможности
следует
избегать
);
7)
настроить
права
доступа
к
файлам
или
обратиться
к
администрации
локальной
вычислительной
сети
с
соответствующим
поручением
.
З а м е ч а н и е
.
Ничто
,
кроме
организационных
трудностей
,
не
запрещает
подпроектам
содержать
подпроекты
более
низкого
уровня
.
Однако
хороший
стиль
управления
проектами
предписывает
по
возмож
-
ности
ограничиваться
одним
уровнем
вложенности
подпроектов
.
При
этом
достигается
более
чёткое
разделение
ответственности
и
упрощается
взаимодействие
с
администрацией
вычислительной
сети
,
особенно
в
слу
-
чаях
технических
сбоев
.
Связи
между
работами
,
относящимися
к
разным
файлам
,
уста
-
навливаются
непременно
до
разграничения
прав
доступа
к
файлам
.
Для
этого
следует
:
♦
открыть
файл
генерального
проекта
;
♦
выделить
две
связываемые
работы
(
сначала
предшествующую
,
затем
,
при
нажатой
клавише
[Ctrl], —
зависимую
);
1
Если
все
файлы
подпроектов
находятся
в
одном
каталоге
,
их
можно
связать
с
гене
-
ральным
проектом
одной
командой
,
выделив
все
требуемые
файлы
по
обычным
правилам
Windows ([Ctrl]+
щелчок
мышью
).
80
♦
нажать
псевдокнопку
Link Tasks
( )
на
панели
инструментов
Stan-
dard
.
Можно
вводить
информацию
о
связях
непосредственно
в
столбец
Prede-
cessors
таблицы
работ
,
придерживаясь
того
же
синтаксиса
описания
связей
,
ко
-
торый
порождается
вышеописанной
процедурой
.
З а м е ч а н и е
.
Если
работы
подпроекта
имеют
связи
с
работами
других
подпроектов
или
генерального
проекта
,
то
при
открытии
файла
подпроекта
работы
,
с
которыми
установлена
связь
,
отображаются
в
таб
-
лице
работ
и
выделяются
особым
цветом
—
обычно
серым
.
Ресурсные
пулы
обычно
используются
совместно
с
подпроектами
для
согласования
использования
ресурсов
между
ними
.
Однако
их
можно
исполь
-
зовать
и
для
согласования
использования
одних
и
тех
же
ресурсов
между
раз
-
личными
проектами
,
расписания
которых
не
связаны
ничем
,
кроме
общих
ре
-
сурсов
.
Ресурсные
пулы
создают
в
тех
случаях
,
когда
одни
и
те
же
ресурсы
ис
-
пользуются
на
отдельных
работах
различных
проектов
или
подпроектов
и
су
-
щественно
влияют
на
планы
их
выполнения
.
Ресурсный
пул
размещается
в
одном
из
файлов
Microsoft Project.
Для
не
-
го
рекомендуется
выделять
отдельный
файл
,
таблица
работ
в
котором
не
запол
-
няется
.
Для
создания
ресурсного
пула
следует
:
♦
создать
пустой
файл
для
ресурсного
пула
;
♦
ввести
в
файл
ресурсного
пула
все
данные
о
ресурсах
,
подлежащих
совместному
использованию
в
разных
проектах
;
♦
установить
связь
проектов
с
ресурсным
пулом
:
в
каждом
из
файлов
,
содержащих
модели
проектов
,
использующих
ресурсы
из
пула
,
дать
команду
Tools
→
Resource Sharing
→
Share Resources…
,
в
появившемся
диалоговом
окне
установить
переключатель
Use resources From:
и
в
соответствующем
поле
ввода
указать
путь
к
файлу
ресурсного
пула
.
Файл
ресурсного
пула
должен
быть
доступен
всем
его
пользователям
на
чтение
и
запись
—
вот
почему
не
следует
помещать
его
в
файл
,
содержащий
модель
какого
-
либо
проекта
,
в
том
числе
генерального
.
Информационные
пото
-
ки
,
возникающие
при
использовании
ресурсного
пула
,
представлены
на
рис
.13.
С
момента
установления
связи
с
ресурсным
пулом
в
таблице
ресурсов
будут
отображаться
все
ресурсы
,
представленные
в
пуле
,
а
также
ресурсы
,
спе
-
цифические
для
данного
проекта
и
отсутствующие
в
ресурсном
пуле
.
Добавление
нового
ресурса
в
таблицу
ресурсов
подпроекта
не
приводит
к
его
добавлению
в
ресурсный
пул
.
Такой
ресурс
будет
доступен
только
рабо
-
там
данного
подпроекта
.
Если
необходимо
использовать
его
и
в
других
подпро
-