close

Вход

Забыли?

вход по аккаунту

?

Управление инновационными проектами. Часть 2. Методология управления инновационными проектами. - СПб. СПбГТУ 1999. - 100 с

код для вставкиСкачать
Санкт-Петербургский государственный технический университет
Институт инноватики
УПРАВЛЕНИЕ ИННОВАЦИОННЫМИ
ПРОЕКТАМИ
Часть 2
Инструментальные средства и практикум
управления проектами
Санкт Петербург
Институт инноватики
http://ii.spb.ru/
Авторы:
Т.В.Александрова
С.А.Голубев.
О.В.Колосова,
Н.Б.Культин, С.П.Некрасов, Ю.Р.Нурулин, И.Л.Туккель, В.С.Черняк.
Управление инновационными проектами. Учебное пособие в 2-х частях. Издание второе, переработанное и расширенное. Часть 2. Методология
управления инновационными проектами. / Т.В.Александрова, С.А.Голубев,
О.В-Колосова и др.; Под общ. ред. профессора. И.Л.Туккеля - СПб: СПбГТУ,
1999. -100 с., ил.
ISBN 5-7422-0033-1
Рассмотрены основные понятия и принципы структурирования проекта, как объекта управления. Дано подробное изложение принятой системы
классификации проектов, существующих и предлагаемых инструментальных
средств, автоматизирующих управление проектом на разных стадиях его
жизненного цикла. Приведено описание наиболее распространенных пакетов
прикладных программ, реализующих идеологию Project Management и примеры, иллюстрирующие их применение. В первой части учебного пособия
изложены основы методологии управления инновационными проектами, а во
второй части даны описания инструментальных средств и практикум.
Предназначено для студентов высших учебных заведений и слушателей программ повышения квалификации и дополнительного образования,
подготавливаемых по направлению "Инноватика".
Печатается по решению редакционно-издательского совета СанктПетербургского государственного технического университета.
ISBN 5-7422-0033-1
© Санкт-Петербургский государственный
технический университет, 1999
© И-Л.Туккель, 1999
1
Институт инноватики
http://ii.spb.ru/
ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ.............................................................................................................. 3
1. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА АВТОМАТИЗАЦИИ
УПРАВЛЕНИЯ ПРОЕКТАМИ.......................................................................... 7
1.1. Структура проекта и методологии структурного анализа....................... 7
1.2. Технология системного проектирования на базе типового решения... 11
1.3. Автоматизированные системы управления проектами ......................... 15
1.4. Технология структурного анализа и проектирования SADT ................ 16
1.5. Программный комплекс PROJECT EXPERT .......................................... 36
1.6. Программный комплекс Microsoft Prоject ............................................... 37
2. ПРАКТИКУМ ПО УПРАВЛЕНИЮ ПРОЕКТАМИ ..................................... 43
2.1. Лабораторные работы по методологии IDEF0 и программному
комплексу BPwin....................................................................................... 43
2.1.1. Лабораторная работа 1. Создание новой модели и
контекстной диаграммы ..................................................................... 44
2.1.2. Лабораторная работа 2. Создание следующих диаграмм модели . 48
2.1.3. Лабораторная работа 3. Разработка собственной модели .............. 50
2.2. Лабораторные работы по программному комплексу
РROJECT ЕXPERT.................................................................................... 50
2.2.1. Лабораторная работа 1. Построение модели.................................... 51
2.2.2. Лабораторная работа 2. Определение потребности и разработка
стратегии финансирования ................................................................ 53
2.2.3. Лабораторная работа 3. Анализ финансовых результатов и
формирование отчета.......................................................................... 55
2.3. Лабораторные работы по программному комплексу
МICROSOFT РROJECT 4.0...................................................................... 57
2.3.1 Лабораторная работа 1. Начало работы над проектом .................... 59
2.3.2. Лабораторная работа 2. Корректировка списка задач и
формирование структуры проекта .................................................... 61
2.3.3. Лабораторная работа 3. Назначение связей между задачами ........ 64
2.3.4. Лабораторная работа 4. Ресурсы проекта......................................... 67
2.3.5. Лабораторная работа 5. Назначение ресурсов задачам проекта .... 69
2.3.6. Лабораторная работа 6. Контроль за развитием проекта ............... 71
2.4. Лабораторные работы "Подбор команды проекта"................................ 73
2.4.1. Лабораторная работа 1. Персональный стиль управления............. 75
2.4.2. Лабораторная работа 2. Стиль управления в команде
исполнителей проекта ........................................................................ 76
ЦИТИРУЕМАЯ ЛИТЕРАТУРА .......................................................................... 78
2
Институт инноватики
http://ii.spb.ru/
ВВЕДЕНИЕ
Проект, как объект управления, обладает таким набором особенностей,
которые требуют использования специальных приемов и методов для
управления им. В течение примерно сорока последних лет управление проектами (УП) сформировалось как особая профессиональная область деятельности и самостоятельная дисциплина, вооружающая руководителей
проекта технологиями и инструментальными средствами планирования,
контроля и координации осуществления проектов.
Современная техника УП начала формироваться в США во время работы над такими крупномасштабными проектами как "Манхэттан" (атомная
бомба), "Поларис" (создание подводных лодок с баллистическими ракетами)
и "Аполлон" (космическая программа).
В конце 50-х годов в числе первых методов управления проектами были
разработаны методы сетевого планирования и управления:
– Диаграмма Гантта (Gantt chart – разделение всего проекта на
определенную последовательность составных частей) – широко используется в современных пакетах прикладных программ по управлению
проектами;
– PERT (Program Evaluation and Review Technique – техника оценки
и обзора проектов) – впервые использовалась в проекте "Полярис" фирмами
"Локхид" и "Буз Аллен";
– CPM (Critical Path Method – метод определения критического пути) – был разработан фирмой "Дюпон" для использования в крупных промышленных невоенных проектах.
В 60-е годы начался поиск новых методов управления и организационных структур проектов, способных быстро приспосабливаться к изменяющим условиям.
В 70-е годы широкое внедрение компьютерных систем обработки информации, растущие масштабы и сложность деятельности предприятий в
условиях жесткой конкуренции способствовало тому, что все большее
число компаний стало развивать и использовать методы управления
проектами.
В настоящее время уже и малые фирмы, осуществляющие относительно
небольшие проекты, все чаще начинают систематически подходить к подготовке, планированию и контролю осуществления своих проектов с использованием методов и средств управления проектами. Роль компаний, специализирующихся на разработке и реализации проектов существенно возросла, а
должность и профессия руководителя проекта (Project Manager) стала одной из престижных.
Диапазон обязанностей руководителя проекта как системного интегратора отличается широтой. Руководитель проекта должен согласовывать,
3
Институт инноватики
http://ii.spb.ru/
примерять, удовлетворять противоречивые интересы сред (социальной, организационной, технической, финансовой, политической), на пересечении которых реализуются все фазы жизненного цикла инновационного проекта: от
маркетинга и бизнес-планирования до разработки, комплектной поставки и
сдачи "под ключ". Руководитель проекта должен использовать специальные
методы управления, владеть современными инструментальными средствами
и обладать разными способностями. Разработкой этих методов и средств,
развитием системных способностей руководителей проектов занимается
иноватика – область знаний, охватывающая вопросы методологии и организации инновационной (нововведенченской) деятельности.
Применение методов и средств управления проектами позволяет не
только достичь результатов проекта требуемого качества, но и экономить
деньги, время, другие ресурсы, снижает риск и повышает надежность, так как
помогает:
– определить цели проекта и провести его обоснование;
– выявить структуру проекта (подцели, основные этапы работы и т.п.);
– определить необходимые объемы и источники финансирования;
– подобрать исполнителей, в частности, через процедуры торгов и
конкурсов;
– подготовить и заключить контракты;
– определить сроки выполнения проекта, составить график его реализации, рассчитать необходимые ресурсы;
– произвести калькуляцию и анализ затрат;
– планировать и учитывать риски;
– организовать реализацию проекта, в том числе подобрать "команду
проекта";
– обеспечить контроль за ходом выполнения проекта.
Выбор соответствующих методов и средств управления проектами, определяется прежде всего сложностью, масштабом и типом проекта. Причем,
основные сложности, в общем случае, возникают на начальных фазах проекта, когда должны быть приняты основные решения, требующие нетрадиционных методов и средств.
Сегодня мы живем в эпоху инноваций. Окружающий нас мир постоянно изменяется под воздействием движущих сил. Экономика, широкомасштабные социальные и политические изменения, демографическая ситуация, высокие технологии, появляющиеся на мировом рынке, а также
развитие теории организации систем, все это способствует появлению инновационных решений (и наоборот, изменения являются следствием
инноваций).
Предприятия должны уметь прогнозировать изменения и реализовывать
инновации таким образом, который позволит им извлекать преимущества из
4
Институт инноватики
http://ii.spb.ru/
происходящих изменений. Организационная культура фирмы, в конечном
итоге, определяет количество и тип проводимых инноваций.
Инновации необходимы для того, чтобы фирмы имели возможность: оставаться в бизнесе; получать преимущество в конкурентной борьбе; повышать качество продукции и услуг; восхищать потребителей; привлекать и сотрудничать с наилучшими исполнителями.
Инновационная деятельность в производстве и в обслуживании, в обработке и в эксплуатационных процедурах обязательна для успеха любой
организации. Какой бы ни была инновация, она определяется будущими потребностями рынка и реализуется через соответствующий инновационный
проект.
Итак, для широкого применения на практике методологии управления
проектами необходимо наличие:
– доступных и эффективных методов и средств управления проектами,
решающих задачи процесса реализации инновационного проекта;
– подготовленных специалистов в области управления проектами;
– мероприятий по созданию среды восприятия инноваций;
– рынка управления проектами.
Стало общепринятым оценивать последнее двадцатилетие ХХ века как
период, актуализирующий научно-технические инновации (нововведения).
Именно эта составляющая научно-технического прогресса ( другая его составляющая – научно-технические достижения) позволяет оживить экономику в период ее депрессии и сохранить конкурентоспособность в период
нормального функционирования. Необходимость консолидировать силы
для развития нововведенческой деятельности осознана и на общегосударственном уровне. В масштабах федеральной программы "Российская инжиниринговая сеть технических нововведений" и в масштабах Санкт-Петербургского государственного технического университета (СПбГТУ) лидером
этого направления является профессор, д.т.н., заслуженный деятель науки и
техники Российской Федерации В.Г.Колосов. Ему же принадлежит идея
создания в СПбГТУ Института инноватики для целенаправленной подготовки менеджеров инновационной сферы. Естественно, авторы благодарны
профессору Колосову за глобальную идею, позволившую им сосредоточиться на разработке инструментальных и образовательных средств инновационной деятельности.
Материал данного учебного пособия формировался и обсуждался на научном семинаре "Управление инновационными процессами", всем участникам которого авторы приносят свою благодарность. Необходимо поблагодарить также Д.Х.Дорантеса, ныне преподавателя университета Мехико, а два
года назад, когда вместе с ним было написано с его соавторством первое издание этого учебного пособия – аспиранта СПбГТУ.
5
Институт инноватики
http://ii.spb.ru/
Научно-методическая работа Института инноватики привела к формированию в 1999 году нового направления профессиональной подготовки, охватывающего многоуровневое высшее образование (бакалавры, специалисты,
магистры) и поствузовское образование (повышение квалификации, профессиональная переподготовка). Это направление получило название "Инноватика". Ему присвоен номер 553800. Данное учебное пособие адресовано прежде всего тем, кто проходит подготовку по указанным выше образовательным программам этого направления.
Данное учебное пособие состоит из двух частей: часть 1 – Методология
управления инновационными проектами; часть 2 – инструментальные средства и практикум управления проектами. Для удобства читателей каждая
часть издана отдельной книгой.
6
Институт инноватики
http://ii.spb.ru/
1. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА АВТОМАТИЗАЦИИ
УПРАВЛЕНИЯ ПРОЕКТАМИ
1.1. Структура проекта и методологии структурного анализа
Для выявления и определения целей, состава и содержания проекта, организации планирования и контроля процессов осуществления проектов необходимо определить и построить структуру проекта, на основе которой
строятся различные структурные модели проекта и его окружения, используемые в процессе управления проектом на протяжении всего его жизненного цикла. Структуризация является одним из эффективных элементов современной методологии управления проектами.
Преодолеть сложности начальных этапов создания системы призван
структурный системный анализ, который характеризуется тем, что строится достаточно наглядная и формализованная модель системы, обладающая
двумя важнейшими свойствами:
– структурированностью (при помощи небольшого числа типов структурных элементов);
– иерархией детализации (каждый структурный элемент может быть детально описан при помощи тех же методов, что и система в целом).
Структура проекта представляет собой иерархическую декомпозицию
проекта на составные части (элементы, модули), необходимые для планирования и контроля осуществления проекта.
Структура проекта должна удовлетворять следующим правилам:
1. Каждый уровень иерархии декомпозиции проекта должен иметь законченный вид или охватывать всю сумму частей проекта, представленного
на данном уровне детализации.
2. Сумма характеристик элементов проекта на каждом уровне иерархии
структуры должны быть равны.
3. Нижний уровень декомпозиции проекта должен содержать элементы
(модули), на основе которых могут быть ясно определены все данные, необходимые и достаточные для управления проектами (например: функциональные характеристики, объемы работ, стоимость, необходимые ресурсы, исполнители, связи с другими элементами и др.).
Структурные модели проекта используются на всех фазах жизненного цикла проекта для решения разнообразных задач, связанных с управлением проектом. Они могут отличаться по принципам декомпозиции проекта на
составные части. Из них наиболее распространены:
– ориентация на функции осуществления проекта;
– ориентация на объектно-конструктивные или функциональные части
проекта;
– системная смешанная ориентация.
7
Институт инноватики
http://ii.spb.ru/
Примером смешанной ориентации можно назвать базовую структурную
модель проекта Work Breakdown Structure (WBS), которая является композицией двух типов моделей – верхние уровни отражают декомпозицию проекта
с ориентацией на функции или объект, а нижние уровни отражают дальнейшую детализацию декомпозиции с ориентацией на работы, осуществляемые
в рамках проекта, вплоть до работ конкретного исполнителя.
Структурная модель проекта и принцип структуризации широко используются для построения других информационных моделей, применяемых в
управлении проектом. Отметим наиболее существенные из них:
− дерево целей;
− организационное дерево;
− матрица распределения ответственности и распределение работ по исполнителям;
− сетевая модель проекта или иерархическая система сетевых моделей;
− дерево стоимостей;
− структурная схема материально-технического обеспечения проекта;
− дерево распределения рисков и решений по его минимизации.
Существует особый класс методологий формализации коллективного
процесса анализа и проектирования, доведенных до их автоматизированного
использования в программных продуктах. Как показывает табл. 1, можно выделить три подхода к разработке систем:
– структурный подход (ориентация на описание процессов);
– объектно-ориентированный подход (основанный на представление
систем в виде совокупности объектов, классы которых образуют иерархию
на базе принципа наследования);
– информационная инженерия (ориентация на моделирование данных, а
затем – процессов).
Таблица 1. Инструментальные средства автоматизации системного проектирования
Методологии
Структурного анализа и проектирования:
- D. Ross, (SADT)
- E. Yourdon (DFD)
- K.Gane-T.Sarson, DeMarca (DFD)
- другие
Объектно-ориентированные методы:
- Booch/Jacobson/Rumbaugh (OOD)
- P.Coad – E.Yourdon (OOAD)
- Shlaer – Mellor (OODLE)
- Demeter, Henderson-Sellers
Информационная инженерия:
- Martin-Finkelstein, Porter, Goldkuhl
8
Программные продукты
SPECIFX, ER-BPwin, Design/IDEF
CASE/4/0
SSADM
Express-G, MetaEdit-Workbench
UML, OMT-GE
BPR, BFR
Институт инноватики
http://ii.spb.ru/
Из данных методологий, как уже отмечалось, особое место занимают
структурные методы анализа и проектирования, так как они позволяют
лучше понимать рассматриваемую проблему на начальных фазах при формировании концепции и проведения системного проектирования. Рассмотрим их более подробно.
Для структурных методологий характерны, кроме перечисленных общих
свойств структурного системного анализа, различные способы "борьбы" со
сложностью самой модели, например:
– ограничение числа элементов на каждом из уровней;
– ограничение контекста, включающего лишь существенные на каждом
уровне детали;
– использование строгих формальных правил записи.
Практически во всех методологиях структурного анализа используются
три группы средств моделирования:
– диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между ними (функциональное моделирование); чаще всего
используются DFD (Data Flow Diagrams) – диаграммы потоков данных и диаграммы SADT (IDEF0);
– диаграммы, моделирующие данные и их взаимосвязи (информационное моделирование); фактически стандартом здесь стали ERD (EntityRelationship Diagrams) – диаграммы "сущность-связь";
– диаграммы, моделирующие поведение системы, зависящее от времени
(динамическое моделирование); наиболее часто аспекты поведения системы
во времени моделируются при помощи STD (State Transition Diagrams) – диаграмм перехода состояний.
Различие между разновидностями структурного анализа заключается в
методах и средствах функционального моделирования: методологии, использующие методы, нотацию и технологию DFD (методологии K.Gane-T.Sarson,
DeMarca, и E.Yourdon,) и использующие SADT-методологию (D.Ross и др.).
1. DFD-методологии
В этих методологиях вместо реальных объектов рассматриваются отношения, описывающие свойства объектов и правила их поведения. Они применимы к системам обработки информации (например для разработки прикладного ПО – CASE), а не к системам с жесткими технологическими процессами.
1.1. Методологии K. Gane – T. Sarson, и T. De Marca
Отличительные признаки:
• моделирование от существующей системы до разработки новой (физической и логической моделей);
• стратегия построения требований для разработки новой системы состоит из:
9
Институт инноватики
–
–
–
–
http://ii.spb.ru/
моделирования текущих операций;
выявления причин выполнения именно этих операций;
добавления новых требований;
выбора границ автоматизации.
1.2. Методология E. Yourdon
Отличительные признаки:
– не рекомендуется моделировать текущую систему;
– добавлена предварительная фаза разработки, названная созданием основной модели (essential model);
– определена техника "событийного разбиения" (event partitioning), для
конструирования DFD-схемы;
– больше внимания уделяется информационному моделированию (посредством ER-диаграмм) и моделированию поведения (через STD-диаграмм);
– указано место прототипирования в жизненном цикле разработки;
– имеется описание семантики потоков и правила преобразования входных данных в выходные;
2. SADT-методология D. Ross.
Методология SADT выделяется среди современных методологий описания систем благодаря своему широкому применению, возможностью тиражирования результатов работ по крупным проектам, общностью охвата систем и отражения таких системных характеристик, как управление, обратная
связь и исполнители. Методология принята как американский стандарт вооруженных сил и имеет широкую область применения: от аэрокосмического
производства до реорганизации бизнес-процессов и обучения персонала.
Отличительные признаки:
– широко используемая в крупных проектах;
– ориентирована на "технологичность" процессов и на моделирование и
создание систем вообще (в последнее время широко используется для реорганизации бизнес-процессов – Business Process Reorganization BPR);
– формализованная типизация элементов схемы (вход, управление, выход, ресурс);
– динамическое моделирование и преобразование SADT-диаграмм возможно в сочетании с методом цветных сетей Петри.
Выбор той или иной методологии структурного анализа напрямую зависит от специфики предметной области, для которой создается модель (ориентированность на технологичность процессов и создание общих систем или на
обработку потоков информации).
Однако, наиболее общим и перспективным подходом к анализу и проектированию сложных систем является SADT-методология. В п. 1.4 будет дано
ее более полное описание.
10
Институт инноватики
http://ii.spb.ru/
1.2. Технология системного проектирования
на базе типового решения.
Одним из подходов к автоматизации процесса системного проектирования является технология проектирования на базе типового решения, рассматривающая типовое решение как набор инструментальных средств, позволяющих осуществлять быструю генерацию системы под конкретный заказ.
Такой прием проектирования безусловно ускоряет процесс создания
системы и придает ей инвариантность по отношению к разнообразию номенклатуры выпускаемой продукции, хотя при этом возможно появление избыточности показателей реализованной системы. Однако последнее обстоятельство сказывается положительно в процессе эксплуатации созданной системы, увеличивая протяженность ее эффективного жизненного цикла.
Рассмотрим принцип, по которому множество характеристик конкретной реализации X*, задаваемых техническими требованиями заказчика к проектируемой системе, ставится в соответствие с множеством исходных характеристик проблемно-ориентированной системы Х (типовое решение) и
сформулируем теорему о существовании предметно-ориентированной системы XQ как подмножества проблемно-ориентированной системы Х.
Теорема. Пусть заданы множество Х, содержащее "n" характеристик с
дискретными и непрерывными параметрами исходной проблемноориентированной системы, и множество X*, содержащее "n*" характеристик,
описывающих технические требования к конкретному решению
n
n*
i =1
i=1
Х= U X i и Х*= U X *i .
Для простоты, без потери общности решения, можно положить n=n*, т.е.
привести в соответствие перечень характеристик конкретного решения к характеристикам типового решения.
Предметно-ориентированное решение XQ = X ∩ X* будет существовать и
будет экономически оправданным, если выполняются условия необходимости и достаточности (рис. 1).
X
X*
X
Проблемноориентированное
решение
X*
X(1) … X(2) … X(k)
Конкретная реализация
Рис. 1. Проблемно-ориентированное решение, конкретная реализация и их адаптация
11
Институт инноватики
http://ii.spb.ru/
Будем считать, что определенное число m характеристик (m<n) этих
множеств, которые назовем "паспортными", определяют рамки номенклатурного ряда изделий и качество модулей технического оборудования (как
например, масса, габариты, материал, точность обработки, надежность отдельных технологических модулей и средств вычислительной техники и т.п.)
и обозначим их:
C = {Xj}⊂ Х, j=1,...,m — для типового решения;
C*= {X*j}⊂ X*, j=1,...,m — для конкретной реализации.
Остальные "n-m" характеристики, которые назовем "технико-экономическими", будут определять предварительные технико-экономические показатели (ТЭП) решений (как например, производительность, уровень автоматизации, общая надежность, стоимость системы, срок окупаемости и т.п.) и,
соответственно, обозначим для типового и конкретного решений:
V={V(k)}={Xλ(k)}={Xm+1(k), Xm+2(k), ... , Xn(k)}⊂Х;
V*= {X*λ}={V*m+1, V*m+2, ... , V*n}⊂X*;
где λ = m + 1,...,n , k = 1,...,K, K – натуральное число; т.е. имеем X = C ∪ V
и X* = C* ∪ V*, а природу этих подмножеств определим как:
С — подмножество характеристик с неизменяемыми параметрами, заданными по составу средств типового решения;
V — подмножество характеристик с варьируемыми параметрами типового решения, где каждое подмножество V(k)⊂V означает вариант значений
ТЭП, получаемый в процессе проектирования на базе типового решения, т.е.
при адаптации характеристик типового решения под конкретный заказ;
C* и V* — соответственно, подмножества характеристик с условно неизменяемыми и условно варьируемыми параметрами конкретного решения,
заданными по техническим требованиям заказчика, но допускающими модификации в процессе разработки и согласования технического задания с заказчиком. Именно эта стадия должна происходить по схеме – назовем ее
схемой "параллельной кастомизации" (от англ. customization – выполнение
заказа с удовлетворением индивидуальных потребностей заказчика), – по которой одновременно осуществляются этапы проектирования и утверждениясогласования удовлетворительного проектного варианта за счет вовлечения
заказчика в процесс системного проектирования и принятия решения;
Xλ(k) — функция от паспортных характеристик, генерирующая варианты
количественно-качественного состава технологического оборудования с соответствующим набором ТЭП и с ограничениями, заданными техническими
требованиями C* и V*.
Можно отметить, что по сути, число K определяет уровень стратификации и адаптационные возможности функционально-полных, экономически
целесообразных вариантов решения.
12
Институт инноватики
http://ii.spb.ru/
Условие необходимости. Возможность создания предметно-ориентированной производственной системы XQ определяется наличием или отсутствием пересечения множества типового решения X с множеством требуемой
конкретной реализации X*, иначе говоря, можно использовать технологию
системного проектирования на базе типового решения, если при одинаковых
внешних воздействиях U=U* на определенном интервале времени выполняется условие:
{C ∪ V} ∩ {C* ∪ V*} ≠ ∅
(1)
Условие достаточности. Элементы V(k) подмножества V определяют
адаптационные возможности типового решения. Если варьировать подмножество V различными значениями ТЭП, соответствующих функциональнополным вариантам компоновки и комплектации так, чтобы множество характеристик типового решения X покрывало согласованные с клиентом технические требования конкретного решения X*, то область экономически достаточного предметно-ориентированного решения XQ может быть определена.
Построим матрицу полного перебора сочетаний параметров типового
решения с параметрами конкретного решения, характеризующего условия
достаточности решения. Для этой цели введем следующие вспомогательные
подмножества, используемые в процессе сравнения типового и конкретного
решений:
∆C* = C* \ C — доля выполнения технических требований, не охваченная
мощностями типового решения по паспортным характеристикам, и соответствующее подмножество ∆C*д — допустимая заказчиком доля от C* для достижения компромиссного решения.
Аналогично, подмножество ∆V*(k) = V* \ V(k), k=1,...,K, и соответствующее ∆V*д.
Q = C ∩ C* — область пересечения паспортных характеристик соответствующих систем.
Q(k) = V(k) ∩ V* — область пересечения технико-экономических характеристик конкретного решения с соответствующими характеристиками k-го
варианта типового решения.
Тогда решение предметно-ориентированной системы, полученное по
допустимым значениям C и по выбранному, удовлетворяющему варианту Vпо
∈ {V(k)} (по – предметно-ориентированное решение) из набора техникоэкономических показателей комплексов будет иметь вид
XQ = C ∪ Vпо,
(2)
Как следует из матрицы полного перебора условий (табл. 2), решение
находится под ограничениями:
C* ⊇ Q ⊆ C; V* ⊇ Q(k) ⊆ V(k), ∅ ⊇ ∆C* ⊆ ∆C*д, ∅ ⊇ ∆V*(k) ⊆ ∆V*д, k=1,...,K (3)
13
Институт инноватики
http://ii.spb.ru/
Таблица 2. Матрица условий достаточности существования решения
1
2
3
4
5
6
Q(k)=∅,
k=1,...,K,
∆V*(k)=V*
Q(k)=V*,
(V*⊆V(k)),
∆V*(k)=∅
V*⊃Q(k)⊂V(k),
∆V*(k)⊆∆V*d
V*⊃Q(k)⊂V(k),
∆V*(k)⊃∆V*d
Q(k)=V(k),
(V(k)⊆V*),
∆V*(k)⊆∆V*d
Q(k)=V(k),
(V(k)⊆V*),
∆V*(k)⊃∆V*d
1
Q=∅,
∆C*=C*
2
Q=C*
(C*⊆C),
∆C*=∅
3
4
*
C ⊃Q⊂C, C ⊃Q⊂C,
∆C*⊆∆C*d ∆C*⊃∆C*d
∅
∅
∅
∅
∅
∅
∅
XQ
XQ
∅
XQ
∅
∅
XQ
XQ
∅
XQ
∅
∅
∅
∅
∅
∅
∅
∅
XQ
XQ
∅
XQ
∅
∅
∅
∅
∅
∅
∅
*
5
6
Q=C
Q=C
*
(C⊆C ),
(C⊆C*),
∆C*⊆∆C*d ∆C*⊃∆C*d
Следовательно, предметно-ориентированное решение как подмножество
проблемно-ориентированного (типового) решения существует тогда и только
тогда, когда выполняются условия (1)–(3).
Можно отметить, что следствием применения технологии проектирования на базе типового решения является присутствие некоторой, в общем случае ненулевой, функциональной избыточности (∆XQ) над мощностями, заданными по техническим требованиям заказчика. Оценка эффективности
достаточности решения является неформальной, договорной. Тогда выражения (2)-(3) для предметно-ориентированного решения могут быть записаны в
виде:
XQ = QQ ∪ ∆XQ, где QQ = Q ∪ Qпо, Qпо = Vпо ∩ V*,
∆XQ = ∆C ∪ ∆Vпо = (C \ C*) ∪ (Vпо \ V*)
Применение технологии системного проектирования на базе типового
решения позволяет уменьшить сроки проектирования и избежать на этом
этапе ошибок за счет использования отработанного проблемно-ориентированного решения.
Платой за совмещение подхода стандартизации (ускорение проектирования за счет использования типового решения) с подходом параллельной
кастомизации является наличие некоторой избыточности решения, которая, в
тоже время, увеличивает адаптируемость к выпуску нового вида продукции
уже в процессе эксплуатации системы.
14
Институт инноватики
http://ii.spb.ru/
1.3. Автоматизированные системы управления проектами
В настоящее время планирование и исполнение большого проекта переросло в методологию и технологию планового управления проектом, и успеха достигает тот, кто владеет современными методами и технологиями
управления проектами.
Как уже отмечалось, для эффективной реализации проектов необходимо:
– построение иерархии целей как самого проекта, так и будущей системы, которые только в общем случае совпадают;
– состояние полного взаимопонимания и скоординированности владельцев будущей системы, руководителей или управляющих проектом и исполнителей;
– наличие простой, ясной и насыщенной системы информационного и
коммуникационного обмена между участниками проекта;
– наличие финансовых, материальных, интеллектуальных, физических и
временных ресурсов;
– наличие эффективных систем планирования, мониторинга и управления.
Автоматизированные системы безусловно повышают качество осуществления проекта, в том числе за счет ускорения ввода и обработки информации, представления информации в наглядной форме.
Одним из критериев качества процесса управления инновационным проектом является время его выполнения:
n
∑ ti → min ,
i =1
где ti - длительность реализации i-го этапа проекта.
Фактор времени прямо влияет на экономические показатели как самого
проекта, так и изделий, которые поставляются на рынок в результате его
осуществления (рис. 2).
Существуют автоматизированные системы, ориентированные на начальные этапы (как в частности, для стадии системного проектирования) и
ориентированные на реализацию (управления реализацией проекта или так
называемые Project Management). Системы типа Project Management относятся к системам предназначенным для разработки календарного плана работ и сетевого графика проекта, включая длительность и затраты по стадиям проекта.
В табл. 3 перечисляются основные пакеты в каждом классе и их отличительные особенности. В последующих параграфах главы 1, приводится описание программных комплексов для поддержки фазы концепции (Project Expert), стадии системного проектирования (Design/IDEF) и стадии реализации
(MS Project).
15
Институт инноватики
http://ii.spb.ru/
Прибыль
1
Спад
рынка
Рост
рынка
2
1
3
2
5
4
Время
Жизненный цикл проекта
1 – с использованием средств автоматизации для сокращения
сроков реализации этапов проекта;
2 – без использования средств автоматизации.
Рис. 2. Рост прибыли за счет опережения выхода проекта на рынок
Таблица 3. Инструментальные средства автоматизации фаз реализации проекта
№
1
2
3
4
5
6
Отличительные
характеристики
Оценка инвестиционных
рисков
Кол-во работ/ресурсов
Кол-во календарей/ планов
Сетевые/иерархические
модели
Управление персоналом
Экспорт/импорт информ.
Project MS
Expert Project
отл.
норм.
норм.
удов.
Time
Line
удов.
Project PrimaWorkb. vera
удов.
удов.
View Prestige
Point
удов.
удов.
высок. высок высок. высок. высок. высок.
норм. норм. норм. высок. норм. высок.
удов.
удов.
удов.
хор.
удов.
удов.
удов.
удов
хор.
хор.
отл.
удов.
отл.
удов.
отл.
удов.
отл.
хор.
отл.
хор.
отл.
1.4. Технология структурного анализа и проектирования SADT
Методология IDEF0, изначально названная "Технология структурного
анализа и проектирования" Structured Analysis and Design Technique (SADT),
была разработана компанией SofTech, Inc в начале 60-х годов как дисциплина инжиниринга для разработки относительно сложных человеко-машинных
систем. На ее основе в конце 70-х ВВС США разработали методологию
IDEF0 (Icam DEFinition), которая являлась основной частью программы
ICAM (Integrated Computer-Aided Manufacturing – Интеграция Компьютерных
16
Институт инноватики
http://ii.spb.ru/
и Промышленных Технологий). IDEF0-технология быстро стала стандартом
Министерства Обороны США для разработки моделей процессов.
В 1993 году IDEF Users Group (сейчас Society of Enterprise Engineering –
SEE), вместе с National Institutes of Standards and Technology (NIST), выполнили работу по созданию стандарта IDEF0 для использования во всех гражданских и военных отделах правительства США и их представительствах.
Этот стандарт был опубликован как Federal Information Processing Standards
(FiPS) Publication 183.
Независимо от этого, но используя большинство таких же принципов,
стала популярной методология DFD (Data Flow Diagrams –Диаграммы потоков данных), которая использовалась для структурного проектирования (а затем и для структурного анализа) в проектах по разработке программного
обеспечения. DFD-модели имеют много общего с IDEF0-моделями и могут
использоваться совместно. Часто DFD-диаграммы используются для уточнения IDEF0-диаграмм.
Методология IDEF3 была разработана специально для проектов, финансируемых Armstrong Laboratories ВВС США. Эта технология предназначена
для документирования и описания процессов, выполняемых экспертамиспециалистами в предметной области, и для разработки моделей процессов,
где очень важно четко отображать последовательность и параллельность
процессов.IDEF3 не была оформлена как стандарт FiPS, однако получила
широкое распространение при реализации проектов Министерства Обороны
США как дополнение к методологии IDEF0.
Методология моделирования IDEF0 предназначена для анализа всей
системы как множества взаимодействующих взаимосвязанных функций.
Ориентация исключительно на анализ функций позволяет рассматривать
функции независимо от объектов, которые их выполняют. Функциональный
подход позволяет четко отделить проблемы анализа и проектирования от
проблем реализации.
IDEF0 – наиболее подходящий метод для анализа и логического проектирования. В основном он применяется на ранних стадиях проекта.
IDEF0 позволяет выполнять описание сложных объектов с помощью
простого и понятного графического языка.
Графический язык IDEF0 содержит только два символа (блоки и стрелки).
Простота синтаксиса языка сочетается с хорошо разработанным процессом
описания систем, который позволяет разрабатывать модели высокого качества.
Описание системы по правилам IDEF0 имеет четкую структуру. IDEF0модель представляет собой набор иерархически упорядоченных диаграмм. Каждая диаграмма описывает определенную функцию и состоит из нескольких
взаимодействующих взаимосвязанных подфункций, каждая из которых в свою
очередь может быть описана диаграммой. Таким образом, иерархия функций,
пример которой приведен на рис. 3, представляется иерархий диаграмм – рис. 4.
17
Институт инноватики
http://ii.spb.ru/
Управлять
компанией
0
Планирование
производства
Собрать
продукцию
(компьютеры)
4
3
Заказать
комплектующие
1
Поставить
задачи
производству
Управлять
складом
2
3
Разработать
расписание
(план-график)
производства
4
Вести учет
комплектующих,
требующих
первоочередного
использования 5
Установить
детали на
материнскую
плату
1
Собрать
Конфигурировать
2
3
Тестировать
4
Устранить
неисправности 5
Подготовить
документы
на отправку
изделия
6
Рис. 3. Декомпозиция функций
A0
A-0
A1
A2
A3
A0
A21
A11
A22
A12
A23
A13
A1
A24
A2
A231
A232
A233
A23
Рис. 4. Структура IDEF0-модели
18
Институт инноватики
http://ii.spb.ru/
IDEF0-модель в отличие от обычной декомпозиции функций, представленной на рис. 3, образованной исключительно вертикальными связями, содержит горизонтальные связи между функциями. Это позволяет не просто
описать структуру функций, но и их взаимодействие, придающее совокупности функции системные свойства.
Методология IDEF0 имеет много общего с процессом издания книг.
Часто набор IDEF0-моделей организуют в виде подшивки с оглавлением,
глоссарием и другими атрибутами книг. Отличие лишь в том, что для изложении материала вместо естественного используется специальный формальный язык. Такой набор моделей в IDEF0 называется папкой.
Первый шаг в работе по созданию IDEF0-модели – определение цели
моделирования (purpose). Цель моделирования определяется набором вопросов, на которые модель должна отвечать. В результате изучения модели читатель (пользователь) должен иметь возможность получить ответы на каждый из вопросов, поставленных в начале моделирования. Список этих вопросов представляет собой неотъемлемую часть документации модели. Аналогия: в предисловии к книге излагается цель ее написания.
Работа над моделью начинается с изложения цели, обобщающей все основные вопросы к системе.
Границы модели (scope) определяют степень детализации и глубину изложения информации в модели. Границы модели накладывают ограничения на
использование специальной терминологии, на необходимость комментирования специальной информации, относящейся к предметной области модели и
т.д. Границы определяются исходя из цели моделирования, подготовленности
читателей (пользователей) модели. Подобные данные обычно содержатся и в
предисловиях книг. Для разработки модели недостаточно только списка вопросов. Необходимо указать, насколько подробный ответ на каждый из этих
вопросов, с какой степенью детализации, должен получит читатель.
Точка зрения (viewpoint) – это позиция, с которой модель описывает систему. Точка зрения выбирается такой, чтобы модель охватывала установленные границы (scope) и удовлетворяла бы поставленной цели. Будучи однажды выбранной, точка зрения должна оставаться неизменной на протяжении
всей работы с моделью. Если необходимо, то для разностороннего описания
системы можно построить несколько моделей с различными точками зрения.
Примеры точек зрения: владелец фирмы, директор фирмы, клиент, поставщик, служащий и т.д.
IDEF0-диаграммы
На рис. 5 изображена типичная IDEF0-диаграмма на стандартном бланке. На диаграмме изображены несколько функций и взаимосвязи между ними
(их взаимодействие). Совокупность функций в своей взаимосвязи описывают
работу другой функции. Диаграмма описывает (декомпозирует) функцию.
19
Институт инноватики
http://ii.spb.ru/
Стандартный бланк содержит типовой заголовок и нижний колонтитул.
Элементы заголовка используются для того, чтобы отслеживать и документировать работу над моделью. Элементы нижней части бланка содержат информацию, идентифицирующую диаграмму: номер диаграммы и ссылку на
родительскую диаграмму.
Элементы заголовка бланка:
Поле
Used At
Author, Date,
and Project
Notes
1 2 3 4 5 6 7 8 9 10
Status
Working
Draft
Recommended
Publication
Reader, Date
Context
Назначение
Используется для ссылок на документы, где эта диаграмма используется. Часто это поле не заполняется.
Содержит имя автора, создавшего диаграмму, дату создания и название проекта, для которого эта диаграмма и модель разрабатывались.
Когда диаграмма, напечатанная на бумаге, редактируется, читатель
отмечает каждое появившееся замечание зачеркиванием цифры в
этом поле. В результате видно количество замечаний к диаграмме.
Статус отражает степень готовности диаграммы. Это поле используется при осуществлении формального цикла публикации, чтения
и редактирования модели.
Новая диаграмма, в диаграмму внесены большие изменения или
старая диаграмма переработана новым автором.
Диаграмма одобрена читателями. Она готова для рассмотрения руководителем проекта и для подробного комментирования.
Диаграмма и все сопровождающие ее комментарии рассмотрены и
одобрены. Изменения в диаграмме не предполагаются.
Диаграмма готова к печати и публикации.
Имя читателя и дата чтения (рецензирования).
Это эскиз родительской диаграммы, на которой выделяется родительский блок. Поле контекста на контекстной диаграмме содержит
слово TOP, что показывает отсутствие у нее родительской диаграммы в этой модели.
Элементы нижней части бланка:
Поле
Node
Title
Number
20
Назначение
Номер диаграммы. Он совпадает с номером декомпозируемого блока.
Название диаграммы, совпадающее с названием декомпозируемого
блока
Так называемый C-номер, уникальный номер, однозначно идентифицирующий ЭТУ диаграмму. Любая новая версия диаграммы будет
иметь свой C-номер. Обычно C-номер содержит инициалы автора как
уникальный идентификатор. Пример: JDM001. C-номера используются как номера страниц.
Если создается новая версия диаграммы, то новый вариант должен
содержать ссылку на старую диаграмму, например, JDM002
(JDM001). Это позволяет проследить хронологию совершенствования
модели.
Институт инноватики
http://ii.spb.ru/
AUTHOR:Marca
PROJECT: Механический цех
USED AT:
NOTES:
1
2
3
4
DATE:11/04/98
REV:
5
6
7
8
9
Требования по
срокам выполнения
задания
C1
10
WORKING
DRAFT
RECOMMENDED
PUBLICATION
Штамп "Принято"
READER
DATE
CONTEXT:
Справочник
стандартов
качества
C2
Статус задания
Готовая деталь
O1
O2
Управлять
выполнением
заданияA1
I1
Рабочий
комплект
Мастер
Сырье и заготовки
I2
Станки и
инструменты
Выполнить
задание Законченное или незаконченное задание
A2
Деталь с
биркой
Принятое, но
незаконченное
задание
Брак
A0
Принятое
задание
Рабочий
Персонал
механического цеха
M1
NODE:
Оценка степени
завершенности
задания
Чертеж
План
выполнения
задания
Контролировать
качество
выполненияA3
Контролер
TITLE: Изготовить нестандартную деталь
NUMBER:
Рис. 5. Типичная IDEF0-диаграмма
IDEF0-блоки
IDEF0-блоки, называемые функциями, обрабатывают или преобразуют
входные данные в выходные данные. Поскольку IDEF0 моделирует системы
как иерархически упорядоченную декомпозицию функций, первая функция,
которая определяется – это функция самой системы. IDEF0-блок, представляющий функцию моделируемой системы, называется контекстным (context).
IDEF0-блок изображается в виде прямоугольника, в котором вписано
название функции. Название обычно состоит из глагола, обозначающего, что
функция делает, и прямого дополнения, квалифицирующего производимое
действие. Название функции должно соответствовать выбранной точке зрения модели. Для специалиста, с позиции которого производится описание
системы, оно должно быть одновременно и понятно, и существенно.
Как было отмечено ранее, IDEF0-модель является системой иерархически упорядоченных IDEF0-блоков. Каждый IDEF0-блок (функция) может
быть декомпозирован (детально описан) на составляющие подфункции. Поскольку IDEF0 определяет всю систему как блок, ее декомпозиция заключа21
Институт инноватики
http://ii.spb.ru/
ется в определении того, из каких блоков состоит контекстный блок. Каждый
из блоков, составляющих диаграмму декомпозиции, может быть таким же
образом детально описан и т.д. Структура модели показана на рис. 4.
Такую декомпозицию часто называют моделированием сверху вниз, однако, это неправильное употребление термина. Функциональную декомпозицию более корректно рассматривать как пытливый сторонний взгляд на систему. Представление о системе разделяется на уровни детализации, где каждый последующий уровень предоставляет более детальную информацию о
предыдущем. Более детальный уровень не просто показывает структуру предыдущего, а выполняет его подробное описание. После подробного описания
функции наше представление о ней зачастую изменяется, становится более
полным. Увеличение и качественное изменение знаний отражается и на предыдущем уровне декомпозиции, где эта функция упоминается впервые.
Декомпозиция IDEF0-блока представляется теми же выразительными
средствами в виде набора IDEF0-блоков. Иными словами, функция рассматривается как совокупность составляющих ее подфункций. Эти подфункции в
своей взаимосвязи представляют собой именно декомпозируемую функцию.
Взаимодействие и связи между подфункциями (блоками) отображается с помощью дуг (arrows).
Интерфейс функции (стрелки)
Каждая функция имеет входные и выходные данные. Входные данные
используются или трансформируются в процессе ее выполнения. Выходные
данные представляют результат выполнения функции.
В IDEF0 входы функции подразделяются на три категории: помимо традиционного входа данных (input) выделяются управление (control) и механизм
(mechanism). Управление – это объекты, которые определяют и контролируют
способ, при помощи которого функция преобразует входные данные, причем
само управление не подвергается преобразованию в процессе выполнения
функции. Механизм – это те объекты, которые собственно и выполняют функцию преобразования входных данных в выходные. Объекты, являющиеся входом механизма, также не модифицируются в процессе выполнения функции.
Входные и выходные данные в IDEF0 отображаются с помощью дуг.
Стрелки, как и категории данных, бывают четырех типов:
I = Input – Вход
C = Control – Управление
O = Output – Выход
M = Mechanism – Механизм
Тип стрелки определяется тем, к какой стороне IDEF0-блока она присоединена (рис. 6) По первым буквам английских названий, система обозначения входных и выходных данных при помощи стрелок в IDEF0 называется
ICOM.
22
Институт инноватики
http://ii.spb.ru/
Управление
(Control)
Вход
(Input)
Функция
Выход
(Output)
Механизм
(Mechanism)
Рис. 6. Тип стрелки определяется стороной блока
С помощью стрелок представляются люди, предметы, концепции, события. Каждая стрелка должна иметь название, которое записывается около линии. Тогда как название функции – это фраза с глаголом, название стрелки –
всегда существительное. Название стрелки не всегда может быть правильно
понято читателем, поэтому рекомендуется давать текстовые комментарии к
стрелкам.
Вход данных (Input)
Вход данных представляет материалы, предметы или информацию, которые трансформируются в процессе выполнения функции с целью получения результата Стрелки входа соединяются с левой стороной блока. Некоторые блоки могут не иметь стрелок входа, поскольку не каждая функция преобразует или изменяет что-либо. Например, функция "Принять решение", которая заключается в анализе определенных факторов, не преобразует и не
модифицирует ни один из факторов. Принятое решение также не оказывает
никакого воздействия на исходный набор факторов. При этом факторы представляются входами управления.
Управление (Control)
Управление определяет как, когда и в каком случае выполняется функция, и какой результат от нее ожидается. Поскольку управление "руководит"
выполнением функции с целью достижения желаемого результата, каждая
функция (IDEF0-блок) должна иметь как минимум один вход управления.
Стрелки управления входят в IDEF0-блок сверху.
Управление часто представляется в виде правил, норм, процедур, стандартов. Они оказывают влияние на выполнение функции, не изменяясь при
этом сами. В том случае, если целью функции является изменение подобной
информации (правил, норм и т.д.), соответствующая ей стрелка должна быть
стрелкой входных данных функции.
23
Институт инноватики
http://ii.spb.ru/
Управление – это особый тип входных данных функции. Часто возникает вопрос, какого типа должна быть стрелка: вход или управление. В этом
случае рекомендуется выбирать управление; в дальнейшем, после уточнения,
стрелке присваивается требуемый тип.
Выход (Output)
Выход – это материалы, предметы, информация, производимые функции. Это результат выполнения функции. Каждый блок обязательно имеет
хотя бы одну стрелку выхода. Функции, которые не производят чего-либо
определенного, не могут быть смоделированы, они должны исключаться из
рассмотрения.
При моделировании непроизводственных процессов, выходом функции
часто являются данные, которые были обработаны или переработаны по алгоритму, определяемому функцией. Это становится важным при наименовании входных и выходных данных. Например, функция "Проверить платежеспособность покупателя" может иметь одинаково обозначенные входные и
выходные данные. Правильное обозначение данных предполагает, что в этом
случае входная стрелка будет названа "Исходные данные о покупателе", а
выходная "Проверенные данные о покупателе"
Механизм (Mechanism)
Механизм – это те ресурсы, при помощи которых выполняется функция.
В качестве механизма выступают люди, машины, оборудование, которые
обеспечивают все необходимое для реализации функции. IDEF0-блок может
не содержать стрелок механизма. Это объясняется тем, что знание механизма, осуществляющего функцию, зачастую не является целью моделирования
системы.
Варианты взаимодействия функций
Существует пять основных вариантов взаимодействия функций (связей
между функциями): выход-вход, выход-управление, выход-механизм, обратная связь выход-управление и обратная связь выход-вход. Эти типы взаимодействия, естественно, отображаются при помощи стрелок.
Связь выход-вход обозначает, что выполнение одной функции предшествует выполнению другой, и результат первой функции является входными
данными для другой. На рис. 7 функция "Закупить материалы" предшествует
выполнению функции "Обработать материалы".
Закупить
материалы
Материалы
Рис. 7. Связь выход-вход
24
Обработать
материалы
Институт инноватики
http://ii.spb.ru/
Связь выход-управление показывает влияние одной функции на другую.
При этом результат выполнения первой функции управляет выполнением второй. Это классический прием функциональной декомпозиции, которая и применяется в IDEF0. На рис. 8 "Согласованный план" управляет реализацией рекомендаций экспертов. Рекомендации никак не изменяются в процессе реализации, поэтому "Согласованный план" изображается стрелкой управления.
Рассмотреть
рекомендации
экспертов
Согласованный
план
Реализовать
рекомендации
Рис. 8. Связь выход-управление
Связь выход-механизм представляет ситуацию, в которой одна функция
предоставляет средства для реализации другой функции. На рис. 9 изображен
случай, когда для изготовления детали необходимо приготовить специальную оснастку.
Обратные связи по управлению или входу применяются в тех случаях,
когда блок получает информацию от блока, который сам выполняется на основе результатов работы первого блока.
Изготовить
деталь
Подготовить
оснастку
Оснастка
Рис. 9. Связь выход-механизм
Пример обратной связи выход-управление приведен на рис. 10 – оценка
эффективности хода проекта, реализуемого по принятому, плану управляет
модификациями самого плана. "Оценка эффективности" – безусловно, управляющая информация, поскольку функция "Разработать план проекта" никак
не модифицирует текущую оценку.
25
Институт инноватики
http://ii.spb.ru/
Оценка эффективности
хода проекта
Разработать план
проекта
Оценить
эффективность
выполнения
проекта
Рис. 10. Обратная связь выход-управление
Обратная связь выход-вход обычно используется для того, чтобы показать цикл исправлений, доработок. На рис. 11 приведен пример такой связи.
Красить детали
Крашеные
детали
Оценить
готовность детали
Готовые детали
Рис. 11. Обратная связь выход-вход
Также с помощью обратной связи выход-вход можно показать, как бракованные изделия используются в качестве сырья для того же процесса, в результате которого они были неудачно произведены. Например, так можно
отобразить процесс производства пластиковых бутылок, где некондиционные
изделия сразу же служат сырьем для производства других бутылок.
Разветвления и объединение стрелок
По сути, IDEF0 призван визуализировать взаимосвязь функций в системе. Выход функции может быть использован более, чем одной другой функцией. Стрелки в IDEF0 могут разветвляться (branch) и объединяться (split),
охватывая необходимые функции-блоки.
Стрелки являются иерархическими наборами объектов системы. Так как
стрелка редко представляет один объект, то хорошим стилем проектирования
является разветвление и объединение стрелок. Вся стрелка или ее часть может начинаться в одном или нескольких блоках и заканчиваться в одном или
нескольких блоках. Объединение стрелок необходимо с целью минимизации
количества стрелок и упрощения описания, а разветвление – для детализированного описания данных, поступающих на входы блоков.
26
Институт инноватики
http://ii.spb.ru/
При разветвлении или объединении каждая ветвь стрелки может получать свое название. Таким образом осуществляется декомпозиция объектов,
изображенных стрелкой. Если ветвь не получает своего названия, то она называется так же и содержит те же объекты, что и разветвляемая стрелка.
Примеры разветвлений и объединений
На рис. 12 приведен пример, где стрелка разветвляется только для того,
чтобы быть присоединенной к нескольким блокам, каждому из которых необходима вся информация, отображаемая стрелкой.
Правила и процедуры
Рис. 12. Разветвление с полной информацией
На рис. 13 в результате разветвления стрелки "Правила и процедуры"
для второго блока специально выделяются данные о правилах и процедурах
для персонала. Это показывает, что блоку 2 нужна только часть информации
содержащейся в стрелке.
Правила и процедуры
Правила и процедуры
для персонала
Рис. 13. Разветвление с выделенной информацией
27
Институт инноватики
http://ii.spb.ru/
Если ответвление стрелки имеет свое название, т.е. выделяет часть информации, то новое название должно отражать то, что ответвление является
подмножеством исходной стрелки. Разветвление стрелок позволяет осуществить декомпозицию данных, изображаемых стрелкой.
При объединении неименованных стрелок на рис. 14 имеется в виду, что
выходы обоих блоков имеют одинаковое название, и писать его около каждого блока нет необходимости.
Бракованные материалы
Рис. 14. Объединение "одинаковых" входов
На рис. 15 приведен пример, когда объединяются стрелки с разными названиями. Объединенная стрелка получает название, обобщающее ее составляющие.
Бракованные материалы
Отходы
Бракованные
детали
Рис. 15. Объединение "разных" входов
Туннели
Помещение стрелки в "туннель" позволяет скрывать несущественные
для диаграммы детали, или, наоборот, добавлять при описании важную для
изложения информацию.
В случае, если стрелки не было на родительской диаграмме (она не упоминалась ранее), а на текущей диаграмме она необходима, то туннель используется как точка входа или выхода стрелки из системы.
На рис. 16 приведена диаграмма, для которой "Персонал" является важнейшим механизмом, однако, скорее всего эта стрелка не будет нести новой
информации нигде больше в модели. Поэтому, стрелка "Персонал" появляет28
Институт инноватики
http://ii.spb.ru/
ся именно на этой диаграмме и отсутствует на родительской, и туннель является точкой входа этой стрелки в модель.
С помощью туннелей стрелки "Конструкторы" и "Диспетчеры" не попадают на диаграммы декомпозиции, поскольку эта информация, по всей видимости, излишняя. А стрелка "Технологи" будет представлена на диаграмме
декомпозиции. Здесь туннели служат точками выхода стрелок из системы.
Туннели позволяют избежать загроможденности диаграмм несущественными деталями.
Конструкторское Комплект
проектирование чертежей
2
( )
Конструкторы
Технологическое Технологическая информация
проектирование
3
Запуск в
производство
Технологи
Сопроводительная
документация
6
Диспетчеры
( )
Персонал
( )
Рис. 16. Помещение стрелок в туннель
Цикл Автор-Читатель
Исходные данные для разработки модели автор получает путем опроса
экспертов. Затем он формализует полученные знания, создавая IDEF0модель. Разработка модели – итеративный процесс: автор согласует текущие
результаты моделирования с экспертами, предоставившими информацию и с
потенциальными пользователями модели.
IDEF0-диаграммы рассматриваются и редактируются для того, чтобы
убедиться в их корректности и для улучшения их качества. Рецензирование
отдельных диаграмм и модели в целом реализуется через цикл авторчитатель.
Когда автор диаграммы готов предоставить диаграммы для рецензирования, он готовит папку (kit или folder) для каждого из читателей, которые
будут рецензировать модель и делать комментарии или заметки (notes) к диаграммам или связанной с ними текстовой информацией. Отрецензированные
29
Институт инноватики
http://ii.spb.ru/
и прокомментированные диаграммы возвращаются автору, и он вносит коррективы в модель. Если это необходимо, исправленная модель вновь распространяется среди читателей для нового цикла согласования.
Формальный механизм рассмотрения и одобрения диаграмм поддерживается полем Status и правилами создания новых версий диаграмм, осуществляемыми с помощью поля Number.
При работе с большими проектами обычно специально выделяется человек-библиотекарь, который выполняет всю работу по распространению
диаграмм и обеспечения цикла автор-читатель.
Определение цели создания модели
Модель не может разрабатываться без определенной задачи или четко
поставленной цели. Определение цели моделирования включает в себя необходимость ответа на следующие вопросы:
– Зачем моделируется данный процесс?
– Что будет показывать модель?
– Как читатели модели могут ее использовать?
Определение цели моделирования позволяет команде аналитиков сосредоточить усилия для ее достижения. В случае отсутствия цели моделирование будет носить пассивный и нерезультативный характер.
Пример цели: Определить задачи каждого работника цеха и понять, как
эти задачи связаны между собой, для того, чтобы написать учебное пособие
по профессиональной подготовке для каждой должности.
Модель создается для того, чтобы ответить на набор вопросов. Эти вопросы должны быть сформулированы заранее, и они служат основой для определения цели моделирования. Примеры вопросов:
– Какие задачи решает мастер?
– Какие задачи решает рабочий?
– Кто контролирует готовую продукцию?
– Кто осуществляет промежуточный контроль?
– Какие инструменты нужны для выполнения технологической операции?
Точка зрения
Несмотря на важность учета мнения различных специалистов относительно описываемых в модели аспектов системы, модель должна создаваться
с позиций только одной определенной точки зрения. Другие точки зрения
могут быть отражены в других моделях.
Точка зрения должна выбираться тщательно, исходя из поставленной
цели. В примере с цехом только начальник цеха знает все взаимосвязи между
различными задачами персонала, поэтому модель должна разрабатываться
только с позиции начальника цеха.
30
Институт инноватики
http://ii.spb.ru/
Очень важно придерживаться единственной точки зрения в процессе
моделирования. Это подобно четкому выбору цели избавит от необходимости уделять внимание несущественным деталям и от постоянного перестраивания модели.
Может быть полезным построить модель той же системы с другой точкой зрения для более полного описания функций системы.
Границы модели
Одно из основных свойств модели функций – возможность выяснить
границы как всей системы, так и функций отдельных ее компонент. Несмотря на то, что допускается возможность небольшого изменения границ в течение моделирования, они должны быть определены вначале, чтобы управлять
процессом моделирования. Как и в случае с целью моделирования, без определенных границ системы трудно понять, когда модель завершена, поскольку
в этом случае границы системы будут расти одновременно с моделью.
Границы имеют два аспекта: полнота и глубина. Полнота определяет объем информации, предоставляемый диаграммой (горизонтальный уровень).
Глубина определяет степень декомпозиции функций (вертикальный уровень).
Чтобы правильно определить границы, много внимания уделяется разработке контекстной диаграммы. Часто перед проектированием контекстной
диаграммы создают сразу диаграмму первого уровня декомпозиции (следующий уровень за контекстом). Это позволяет определиться с контекстом
модели, заглянув внутрь системы, рассмотрев ее основные функции, описав
их входы и выходы. Контекстная диаграмма задает границы модели, информация, содержащаяся в ней очень важна и критична. Изменения контекстной
диаграммы приводят к необходимости каскадного внесения исправлений во
все диаграммы модели.
Когда определены границы модели, становится понятным, какую информацию включать в модель, а какую нет.
Наименование функции системы
В соответствии с предлагаемой последовательностью работы над моделью, первым делом определяется цель, затем точка зрения и, наконец, границы модели. После чего начинается работа над контекстной диаграммой, содержащей единственный блок, представляющий функцию системы. Описание этой основной функции и определяет границы модели.
Определение Входа, Управления, Выхода и Механизма функции
Чтобы изобразить стрелки на IDEF0-диаграмме, рекомендуется начинать
с выхода функции, затем определить входные данные, после чего – механизм
и управление. Определить выходы функции легче всего, поскольку каждая
31
Институт инноватики
http://ii.spb.ru/
функция в системе существует для достижения какого-либо конкретного результата. Если определить результат работы функции затруднительно, то это
может быть знаком того, что существует возможность улучшить бизнеспроцесс.
Определение Выходов
Важно отметить следующее: модель должна описывать функционирование системы в любых ситуациях. Это означает, что если какая-то ситуация
возможна в условиях данного бизнес-процесса, она должна быть описана в
модели. Многие начинающие разработчики моделей забывают учитывать неблагоприятные результаты работы функции. Например, функция "Изготовить
деталь", конечно, имеет выход – деталь. Однако нельзя забывать, что возможны и бракованные детали, которые нужно обозначать отдельным выходом. Выходы, соответствующие неудачному выполнению функции, используются обычно в обратных связях. Важно отобразить все возможные ситуации, а потом предоставить право экспертам решать, какая информация должна остаться в модели, а какая нет.
Определение Входов
Входы трансформируются или используются функцией для производства выхода. В производственных процессах чтобы понять, что является входом, достаточно определить какие материалы используются для изготовления "выхода". Однако, в информационной индустрии исходные данные используются функциями, но зачастую не изменяются и не модифицируются.
В этом случае исходные данные нельзя делать входом: они отображаются с
помощью стрелок управления.
Часто существует соблазн называть входные и выходные данные одинаково. Обычно это означает, что либо функция не имеет большого значения в
описываемом бизнес-процессе, либо выход назван неправильно. Разрешить
эту проблему можно использованием квалифицирующих и поясняющих слов
в названиях входов и выходов, чтобы названия отображали преобразование
объекта за счет выполнения функции. Например, вход назван "исходные данные о клиенте", а выход "подтвержденные данные о клиенте". В этом случае
и входом и выходом функции являются данные о клиенте, но слова "исходные" и "подтвержденные" поясняют выполняемое преобразование данных.
Определение Механизма
Под механизмом понимаются люди, машины, механизмы, компьютеры,
приспособления и т.д. являющиеся материальными ресурсами для выполнения функции.
32
Институт инноватики
http://ii.spb.ru/
Определение Управления
Последним определяется управление, которое регулирует процесс выполнения функции. Управление обычно представляется в виде правил, норм,
законов, процедур, стандартов. Все функции (блоки) в IDEF0 должны иметь
хотя бы один вход управления.
В случаях неопределенности, к какому типу отнести данные (вход или
управление) – рекомендуется по умолчанию присваивать им статус управления.
Управление – это особая форма входных данных, которая не модифицируется и
не трансформируется в процессе и в результате выполнения функции.
Оценка степени готовности контекстной диаграммы
Когда контекстная диаграмма построена, нужно задать следующие вопросы:
– Охватывает ли контекстная диаграмма все моделируемые бизнесфункции?
– Согласуется ли она с целью, точкой зрения и границами модели?
– Одобряется ли контекстная диаграмма всеми участниками проекта по
разработке модели?
– Согласуется ли количество стрелок каждого типа с уровнем детализации информации? (Рекомендуется ограничивать количество стрелок каждого
типа шестью.)
Нумерация функций и диаграмм
Все IDEF0-блоки имеют номера. Номер состоит из буквенной и цифровой части. В качестве буквенной части обычно используется ‘A’ (Activity).
Цифровая часть содержит номер блока на диаграмме и номера всех родительских блоков (диаграмм).
Блок на контекстной диаграмме имеет номер A0. Диаграмма декомпозиции блока A0 содержит блоки A1, A2, A3, … Блок A1 декомпозируется в
A11, A12, A13, …A11 – в A111, A112, A113, …
Взаимосвязь блока и диаграммы декомпозиции
Каждый IDEF0-блок в случае необходимости может быть декомпозирован – детально описан IDEF0-диаграммой. При этом границы блока в точности соответствуют границам диаграммы. Все стрелки, соединенные с блоком,
появляются и на диаграмме декомпозиции.. Для диаграммы декомпозиции
эти стрелки становятся интерфейсными и каждая из них получает свой
ICOM-код, который состоит из буквы и цифры и обозначает тип стрелки и ее
порядковый номер среди стрелок этого типа на диаграмме. Примеры номеров
стрелок: I1, C1, O1, M1, I2, C2, M2.
Необходимо отметить, что декомпозируемый блок, несмотря на иерархическую организацию модели, никак не управляет выполнением блоков,
расположенных на диаграмме декомпозиции. Диаграмма декомпозиции просто показывает, как работает родительский блок.
33
Институт инноватики
http://ii.spb.ru/
Правила построения диаграмм
Правила построения диаграмм обеспечивают следующие возможности,
необходимые методологии системного анализа:
– Использование универсальной синтаксической единицы (IDEF0блока) позволяет обеспечить доступность изложения и необходимые выразительные средства.
– Ограничение сложности диаграммы обеспечивается ограничением количества блоков на ней. Рекомендуемое число блоков от 3 до 6.
– Взаимное положение блоков на диаграмме позволяет подчеркнуть
важность одних функций по отношению к другим. Это свойство называется
доминированием блоков. Блок, расположенный в левом верхнем углу диаграммы, является наиболее доминантным, в правом нижнем – наименее. Более доминантный блок накладывает ограничения на выполнение менее доминантных за счет того, что результат его деятельности (выход) может быть
одним из входов (вход, управление, механизм) для менее доминантного блока. Этим можно подчеркнуть как последовательность выполнения функций
во времени (менее доминантная выполняется после более доминантной, т.к.
только в этом случае для нее сформирована вся входная информация), так и
подчеркнуть зависимость одного процесса от другого.
– При разработке диаграммы обязательно учитываются и корректируются параметры декомпозируемого блока. Это позволяет более четко изложить
задачи и функции блока в диаграмме верхнего уровня. В то же время достигается полное соответствие интерфейсов блока и диаграммы декомпозиции.
– Все функции на диаграмме должны иметь приблизительно одинаковый уровень сложности, чтобы она давала цельную картину, дающую представление о декомпозируемом блоке.
Стратегии декомпозиции
Качество разработанной модели зависит от подхода, принятого аналитиком, для декомпозиции функций системы. Ниже приведены наиболее часто
используемые стратегии. Для каждой системы в зависимости от цели модели
и точки зрения необходимо выбирать наиболее подходящую стратегию, либо
комбинировать их.
1. Функциональная декомпозиция заставляет обдумывать, что делает система независимо от того, как она работает. Декомпозируются функции системы
независимо от того, где и как они выполняются. Это самый предпочтительный
вариант работы SADT-аналитика. Поэтому самой важной на диаграмме является связь блоков по управлению (взаимодействие функций системы).
2. Декомпозиция в соответствии с функциями, которые выполняют элементы системы. Так можно представить работу коллектива, цеха и т.д. Позволяет собрать информацию о системе, чтобы потом перейти к более обоснованной декомпозиции. Рекомендуется применять при описании документооборота по системе P3: People, Paper, Procedures.
34
Институт инноватики
http://ii.spb.ru/
3. Декомпозиция на уже известные стабильные подсистемы.
4. Декомпозиция, основанная на отслеживании жизненного цикла системы по переработке (продвижению) объекта, представляющая собой этапы
превращения (модификации) исходного продукта (например, заготовки) в
результат.
5. Если ничто другое не подходит, то необходимо простое описание физического процесса, происходящего в системе (подход не системный). Полезна для описания уже существующих систем для последующего более глубокого описания. При таком подходе плохо прослеживаются взаимосвязи и контур управления. При всех своих недостатках этот подход можно использовать
как первый шаг к созданию более представительной модели.
Алгоритм анализа системы
Сбор информации о системе. Выбор цели и точки зрения
Это основополагающие параметры модели. Цель выбирается на основе
списка вопросов, на которые модель должна ответить. Точка зрения представляет позицию, с которой описывается система.
Создание диаграммы A-0 и диаграммы декомпозиции A0
1. Составление списка данных. Это список объектов, имеющих значение
на данном уровне декомпозиции. Функциональная декомпозиция более эффективна, если начинается с составления списка данных.
2. Составление списка функций. Это список функций, которые оперируют с данными из предыдущего списка. Несколько функций могут иметь одни
и те же данные, в то же время одна функция может использовать несколько
различных типов данных.
3. Построение диаграммы:
– расположить блоки на странице (с учетом доминирования),
– нарисовать основные дуги, представляющие ограничения,
– нарисовать внешние интерфейсные дуги,
– нарисовать все оставшиеся дуги.
Создание диаграммы A-0
Обобщение диаграммы A0 приводит к получению верхней диаграммы
модели A-0. Эта операция очень важна, так как позволяет проверить адекватно ли название модели тому, что делает система, убедиться в полноте внешних интерфейсов системы (дуг),выполнить окончательное утверждение цели
и точки зрения модели. Создание диаграммы A-0 заключается в изображении
блока A0 и записи цели и точки зрения под этим блоком.
Дальнейшая декомпозиция (декомпозиция ограниченных объектов)
Диаграмма первого уровня декомпозиции A0, а также все последующие
диаграммы декомпозиции, предоставляют интерфейсные ограничения (контекст) для дочерних диаграмм. Кроме того, модель уже обладает целью и
35
Институт инноватики
http://ii.spb.ru/
точкой зрения. Это делает процесс дальнейшего проектирования более формализованным и требуемая степень детализации достигается выполнением
следующего рекурсивного процесса:
1. Выбор блока диаграммы. Декомпозицию рекомендуется начинать с
самого содержательного блока с точки зрения доминирования, функциональной сложности и влияния на декомпозицию других блоков этой диаграммы.
Лучшим для начала декомпозиции не обязательно будет самый сложный для
понимания блок.
2. Рассмотрение объекта, определенного этим блоком.
3. Создание новой диаграммы (по алгоритму, подобному построению
диаграммы A0).
4. Выявление недостатков новой диаграммы.
5. Создание альтернативных декомпозиций.
6. Корректировка новой диаграммы.
7. Корректировка всех связанных с ней диаграмм.
Когда останавливать декомпозицию
Цель моделирования содержит список вопросов, на которые должна отвечать модель. Когда мы можем по диаграммам, составляющим модель, найти ответы на эти вопросы, цель моделирования считается достигнутой и работу по созданию модели можно прекращать.
Если же цель моделирования еще не достигнута, то необходимо выполнять декомпозицию тех функций, понимание работы которых даст ответы на
необходимые вопросы. При этом необходимо строго соблюдать границы модели, заложенные в контекстной диаграмме, и диаграммы декомпозиции
первого уровня A0. При необходимости описание функций нижнего уровня
можно проводить с использованием других методологий: IDEF3 или DFD,
предназначенных для детального описания процессов.
1.5. Программный комплекс PROJECT EXPERT
Одной из первых и вместе с тем несомненно удачной отечественной
разработкой в области программных комплексов, ориентированных на
управление проектами, явился созданный фирмой "Про-Инвест Колсалтинг"
пакет Project Expert.
Доступная в настоящее время пятая версия пакета поддерживает всю
цепочку реализации проекта и обеспечивает решение большинства задач,
возникающих при управлении проектом на этапах от замысла и планирования до реализации.
При помощи Project Expert менеджер проекта может:
– провести обобщенный анализ бизнес-идеи;
36
Институт инноватики
http://ii.spb.ru/
– определить потребности в финансировании и подобрать подходящую
схему финансирования;
– описать налоговое окружение и его возможное изменение во время
реализации проекта;
– создать календарный план проекта;
– описать общие и прямые издержки проекта;
– получить аналитические финансовые таблицы (баланс, отчет о прибылях и убытках, кэш-флоу, отчет об использовании прибыли);
– рассчитать финансовые показатели проекта: эффективности инвестиций (BP – период окупаемости, PI – индекс прибыльности, NPV – чистая, приведенная величина дохода, IRR – внутренняя норма рентабельности), показатели рентабельности (ROI), показатели ликвидности и платежеспособности;
– получить показатели эффективности инвестиций, определить их чувствительность на изменение различных факторов внешней среды;
– сформировать и напечатать финансовый отчет проекта.
Функционально пакет Project Expert состоит из шести блоков (рис. 17),
каждый из которых предназначен для решения соответствующих задач и
включает в себя набор функциональных модулей, содержащих диалоговые
средства, позволяющие менеджеру проекта посредством описания бизнесопераций в интерактивном режиме сформировать имитационную модель
проекта.
Укрупнено процесс использования Project Expert для управления проектом может быть представлен в виде схемы, изображенной на рис. 18.
Опыт использования пакета Project Expert показал, что пакет является
весьма эффективным средством поддержки деятельности менеджера по управлению проектами различного назначения, в том числе и инновационными.
1.6. Программный комплекс Microsoft Prоject
Программный комплекс Microsoft Project является наиболее популярным
в среде менеджеров малых и средних проектов. Это объясняется достаточно
широкими возможностями пакета, удобным, и, что немаловажно, хорошо
знакомым большинству пользователей графическим интерфейсом.
Замечание. В настоящее время наиболее широко используются две, работающие в среде Windows 95/98, версии пакета Microsoft Project: Microsoft
Project 4.0 и Microsoft Project 98. Принципиальных отличий между этими
версиями нет. MS Project 98 вобрал все лучшее от своего предшественника.
Вместе с тем, в новую версию внесен ряд дополнений: обеспечена более тесная интеграция с другими компонентами популярного программного комплекса Microsoft Office, поддержка сетевых, в том числе и Internet, технологий, стал более удобным интерфейс программы.
37
Институт инноватики
http://ii.spb.ru/
Блок моделирования
Моделирование окружающей среды и внешних условий функционирования предприятия (налоги, инфляция, схема бух. учета и т.п.)
Моделирование денежных потоков, посредством описания бизнесопераций.
Блок генерации финансовых документов
Отчет о прибылях и убытках (О финансовых результатах)
Отчет о движении денежных средств (Cash Flow)
Бухгалтерский баланс
Отчет об использовании прибыли
Блок анализа
Анализ чувствительности
Анализ эффективности проекта по отношению к отдельным его
участникам
Расчет стандартных финансовых коэффициентов и показателей
эффективности
Анализ вариантов проекта
Блок группирования проектов
Суммарный отчет о движении денежных средств группы проектов
Вариантный анализ
Анализ эффективности группы проектов
Блок контроля реализации проекта
Ввод актуальных данных о развитии проекта
Актуализация данных Cash Flow
Генерация детальных отчетов рассогласования фактических и
планируемых данных (инвестиционного плана, плана продаж, плана
производства и т.п.)
Генерация отчета рассогласования Cash Flow
Генератор отчетов
Формирование описательной части бизнес-плана
Формирование стандартных отчетных таблиц
Построение графиков и диаграмм
Печать отчетных документов
Рис. 17. Функциональная структура пакета Project Expert
38
Институт инноватики
http://ii.spb.ru/
Построение модели
Определение потребности в
финансировании
Разработка стратегии
финансирования
Анализ финансовых
результатов
Формирование и печать
отчета
Анализ данных о текущем
состоянии проекта
Рис. 18. Процесс использования Project Expert
Microsoft Project (MS Project) позволяет эффективно управлять проектом
на различных этапах его реализации. Он дает возможность выполнить структуризацию проекта путем разделения его на этапы, задачи и подзадачи, выявить критические задачи (задачи, длительность которых существенно влияет на длительность реализации всего проекта), получить сетевой график и календарный план проекта, осуществить назначение ресурсов задачам проекта,
эффективно контролировать загрузку ресурсов. Пакет поддерживает все необходимые типы связей между задачами: FS (Finish-Start), SS (Start-Start),
FF(Finish-Finish).
Поддерживая современные информационные технологии, пакет MS Project позволяет импортировать данные из файлов, созданных в среде других
приложений, например MS Excel и MS Access. Неоспоримым достоинством
пакета является наличие встроенного языка программирования Visual Basic
39
Институт инноватики
http://ii.spb.ru/
For Application, что обеспечивает возможность разработки программных
компонент, обеспечивающих решение специфических задач.
Методика использования пакета Microsoft Project для управления инновационным проектом на этапе подготовки к реализации, целью которой является получение сетевого графика и календарного плана проекта, может быть
представлена в виде последовательности следующих шагов:
– создание календаря проекта (т.е. учет нерабочих и праздничных дней);
– составление списка задач, которые надо выполнить для успешной
реализации проекта;
– определение связей между задачами;
– выявление задач, длительность реализации которых существенно
влияет на длительность реализации всего проекта, и возможно, изменение
порядка выполнения задач проекта;
– формирование списка доступных для реализации проекта ресурсов;
– распределение ресурсов (назначение ресурсов конкретным задачам
проекта).
Составление
списка задач
Определение
связей между
задачами
Выявление
критических
задач
Формирование
списка
ресурсов
Распределение ресурсов
Рис. 19. Алгоритм использования MS Project на этапе подготовки проекта к реализации
Следует обратить внимание, что хотя методика подготовки проекта к
реализации представлена в виде последовательности следующих друг за другом этапов, алгоритм подготовки проекта к реализации не является линейным (рис. 19). Существуют этапы, выполнение которых может привести к
необходимости возврата к предыдущему шагу, например, с целью внесения
изменений и, возможно, дополнений в результат выполнения предыдущих
этапов. Таким образом, процесс подготовки проекта является итерационным.
Для иллюстрации использования методов управления проектами при
управлении инновационным проектом рассмотрим проект, который назовем
"Анализатор телефонных каналов". Для того чтобы создать анализатор телефонных каналов, нужно выполнить некоторую последовательность работ (в
терминах управления проектами – задач). Поэтому сначала надо составить
список задач проекта. Для приведенного примера в первом приближении
список может выглядеть так:
– Разработать и утвердить техническое задание.
– Разработать структурную схему системы в целом.
– Разработать структурные и принципиальные схемы блоков, изготовить и наладить их.
– Выполнить сборку и настройку системы.
40
Институт инноватики
http://ii.spb.ru/
– Провести испытание и сертификацию.
– Разработать документацию и обучить персонал.
Объемные, большие задачи, как правило, естественным образом состоят
из более мелких, поэтому они представляются как набор подзадач. Например, задача "Блок1" представляется в виде трех подзадач: "Функциональная
схема", "Принципиальная схема", "Монтаж" и "Наладка".
В реальном проекте задачи связаны между собой. Некоторые задачи могут выполняться одновременно, некоторые можно начать выполнять только
после завершения предыдущих. Поэтому важен не только список задач, но и
связи между задачами.
Пакет программ Microsoft Project позволяет легко составить список задач, разделить задачи на подзадачи, назначить связи между задачами. На
рис. 20 приведен вид экрана программы Microsoft Project для проекта "Анализатор телефонных каналов". В колонке Task Name приведен список задач
проекта, в колонке Duration – их длительность в часах (после цифры стоит
буква h) и в днях (после цифры стоит буква d). Длительность задачи определяется на основе принятых нормативных документов.
Рис. 20. Пример экрана программы Microsoft Project.
В правой части экрана приведена диаграмма Гантта (сетевой график)
проекта, которая позволяет видеть длительность задач и их взаимосвязи. При
41
Институт инноватики
http://ii.spb.ru/
помощи этой диаграммы можно обнаружить задачи, которые существенно
влияют на время выполнения всего проекта.
На рис 21. приведен фрагмент экрана со списком ресурсов, необходимых для реализации проекта "Анализатор телефонных каналов".
Рис. 21. Ресурсы, необходимые для реализации проекта
"Анализатор телефонных каналов"
В столбике Max. Units указано количество единиц ресурсов, доступное
для реализации проекта. В столбике Std. Rate – стандартная стоимость использования ресурса в течении часа, а в столбике Ovt.Rate – стоимость
сверхурочного использования ресурса.
Таким образом, пакет программ Microsoft Project позволяет составить
список задач проекта, разделить задачи на подзадачи, задать последовательность их выполнения, определить стоимость выполнения всего проекта, исходя из стоимости ресурсов. Кроме того, что особенно важно для малого
предпринимательства, назначить ресурсы (работников и оборудование) конкретным задачам проекта.
Особо следует обратить внимание на то, что если менеджер проекта одновременно реализуется несколько однотипных проектов, то объединив несколько проектов в один, можно выполнять распределение ресурсов между
проектами.
42
Институт инноватики
http://ii.spb.ru/
2. ПРАКТИКУМ ПО УПРАВЛЕНИЮ ПРОЕКТАМИ
2.1. Лабораторные работы по методологии IDEF0
и программному комплексу BPwin
Деятельность динамично развивающихся компаний всегда совершенствуется. В нынешних условиях для достижения успеха необходимо регулярно
корректировать работу организации в соответствии с рыночными потребностями, с желаниями клиентов.
Деятельность компании реализуется через бизнес-процессы. Путь к совершенствованию компании, к ее адаптивности лежит через изменение бизнес-процессов. Для этого необходимо четко представлять те процессы, которые существуют в настоящее время, какие процессы необходимы в будущем,
и как осуществить переход от текущего состояния к желаемому.
Подобные задачи решаются применением формальных методик моделирования (описания и анализа) бизнес-процессов. Одна из самых популярных
методологий данного класса – IDEF0 (см. п. 1.4).
IDEF0 обладает специальным графическим языком, с помощью которого выполняется описание бизнес-процессов, как функции, т.е. описываются
функции организации, которыми она должна обладать, чтобы достичь заданной цели. На первом этапе организация описывается в виде "черного ящика",
который преобразует исходные данные, материалы информацию в желаемый
результат деятельности системы. Далее производится детализация работы
этой основной функции. Описание выполняется в виде совокупности взаимодействующих подфункций, вместе составляющих исходную функцию.
Каждая подфункция, в свою очередь, может быть детально описана теми же
средствами, и так далее до получения подробного описания бизнес-процесса.
Результатом применения IDEF0 является модель, представляющая собой
набор иерархически упорядоченных диаграмм. Каждая диаграмма описывает
функцию и в то же время, сама состоит из функций, что допускает проводить
описание с необходимым уровнем детализации.
Подробное описание методологии IDEF0 было приведено в п. 1.4. Предлагаемый цикл работ посвящен изучению программного комплекса BPwin,
реализующего IDEF0.
Первые два занятия посвящаются знакомству с возможностями пакета и
методологией на примере уже готовой IDEF0-модели. Требуется создать несколько диаграмм из предложенных моделей. Для этого необходимо получить у преподавателя IDEF0-модель, которая будет воспроизводиться.
Последующие занятия заключаются в разработке собственных моделей,
описывающих либо функционирование какой-либо организации, либо выполнение определенного процесса.
43
Институт инноватики
http://ii.spb.ru/
2.1.1. Лабораторная работа 1. Создание новой модели и контекстной
диаграммы
Цель: выполнить первичное описание модели, определить цель, точку
зрения, границы, создать контекстную диаграмму A-0 и диаграмму ее декомпозиции A0.
Основные понятия и необходимые сведения о BPwin и IDEF0.
IDEF0-модель представляет собой иерархию диаграмм, описывающих
анализируемую систему (функции системы), а также текстовую информацию, ассоциированную с элементами диаграмм. Назначение модели и ее содержание определяется целью моделирования и точкой зрения, с позиций которой производится описание.
Диаграмма – это отдельная страница модели. Диаграмма может быть
контекстной (описывающей всю модель в целом) или диаграммой декомпозиции.
Программа BPwin – приложение Windows со стандартным MDIинтерфейсом. Каждое окно содержит одну диаграмму модели. Особенность
BPwin – наличие панели инструментов, необходимых для создания моделей.
Эта панель содержит следующие необходимые инструменты:
Указатель
Вставить процесс
Рисование стрелки
Привязка текста названия стрелки к изображению стрелки
Режим включается, если выбрано DisplayÆSquiggles
()
Т
Поместить стрелку в туннель
Вставить текст
Переход к родительской диаграмме
Переход к диаграмме декомпозиции
Программа работы
1. Получить у преподавателя IDEF0-модель, которая будет воссоздаваться в течение работы
2. Запустить BPwin.
3. Создать новую модель FileÆNew Model. После этого открывается
контекстная диаграмма A-0, содержащая единственный IDEF0-блок A0.
44
Институт инноватики
http://ii.spb.ru/
Этот блок A0 изображает функцию всей описываемой системы в целом.
Описать системы, построить ее модель – значит выполнить декомпозиции
блока A0 с необходимой степенью детализации. Декомпозиция проводится
по правилам методологии IDEF0: каждый блок-функция представляется диаграммой, содержащей набор взаимосвязанных блоков-функций, описывающих работу родительского блока. Однако, стратегия декомпозиции (неформальная часть методологии) определяется основными параметрами модели:
целью моделирования, точкой зрения и границами модели, которые определяет аналитик – разработчик модели.
4. Определить параметры модели.
Чтобы построить правильную IDEF-модель, необходимо первым делом
сформулировать и указать цель моделирования (Purpose), границы (Scope) и
точку зрения (Viewpoint). Эти важнейшие параметры могут модифицироваться в процессе работы, однако работать над моделью без их определения
крайне неэффективно и малорезультативно, т.е. аналитик всегда должен четко знать цель, границы модели и точку зрения, актуальные на данный момент. Чтобы документировать эти параметры необходимо воспользоваться
редактором свойств контекстной диаграммы EditorÆModel Definition.
Этот редактор состоит из двух форм для ввода информации о модели:
1) "Project Name" – название проекта, для которого разрабатывается
модель.
2) "Definition" –определение модели.
3) "Scope" – "границы" модели.
4) "Viewpoint" – точка зрения.
5) "Status" – степень завершенности модели (начинают с "Working").
Эта информация будет отображаться на IDEF-бланке.
6) "Time frame" – если описывается система "как есть", нужно выбрать
"AS-IS", если же описывается желаемое в будущем состояние системы, то
"TO-BE".
7) "Model Name" – название модели.
8) Кнопка "More..." позволяет увидеть второй экран редактора.
9) "Purpose" – цель построения модели.
10) "Source" – источники информации для модели.
11) "Author name" и "Initials" – имя и инициалы автора проекта.
Цель и точка зрения должны быть написаны в левом нижнем углу контекстной диаграммы. Для этого после того, как введена информация в редактор "Model definition", нужно выбрать инструмент Т (Text tool), указать место на диаграмме, где будет размещаться текст. Появится диалоговое окно,
предлагающее ввести текст для отображения (normal text block) или показать
цель (purpose) или точку зрения (viewpoint).
Чтобы показать цель, нужно выбрать purpose и нажать Ok. Чтобы показать точку зрения – выбрать viewpoint.
45
Институт инноватики
http://ii.spb.ru/
Любые текстовые комментарии на диаграмме можно вводить с помощью Text tool, выбирая режим Normal text block.
5. Посмотреть редактор параметров диаграммы.
Кроме указания параметров модели, как это было показано в предыдущем пункте, необходимо определять информацию для каждой диаграммы из
состава модели. Часть информации о модели автоматически является и характеристикой диаграммы, например, название модели, имя автора и т.п.,
другие характеристики задаются индивидуально для каждой диаграммы. Это
делается с помощью редактора диаграммы EditorÆDiagram Definition.
1) Поля "Model Name" и "Project Name" содержат информацию из редактора Model Definition и не позволяют ее изменять. Значения полей "Author
Name" и "Status" также берутся из Model Definition, но они допускают возможность корректировки.
2) Поля "Page Number" и "C-Number" позволяют задавать необходимые
обозначения для диаграмм. Первое предназначено для ведения произвольной
нумерации страниц диаграммы, второе – для введения нумерации, соответствующей хронологии создания диаграмм. В учебных целях не используется.
3) Поле "Used At" предназначено для ссылок на связанные диаграммы.
При обучении также не используется.
4) "Node Number" – содержит номер декомпозируемого (родительского)
блока. Не модифицируется.
5) "Diagram Text" – текстовое описание содержимого диаграммы.
6. Определить название блока A0, отображающего функцию системы.
На этом этапе необходимо дать название IDEF0-блоку верхнего уровня
(контекстному блоку). Для этого используется редактор "Name editor". Чтобы
вызвать этот редактор необходимо указать курсором требуемый IDEF0-блок
и нажатием правой кнопки мышки вызвать локальное меню. Локальное меню
содержит редакторы для всех параметров IDEF0-блока. Нужно выбрать
пункт "Name editor...".
В окне Name вводится название блока в том виде, в котором оно будет
появляться на диаграмме. Это название должно быть уникальным. Также рекомендуется вводить его большими буквами.
7. Описать блок A0.
Более подробную информацию о блоке, чем просто название, можно
указать в редакторе "Definition editor".
1) "Name" содержит название блока и позволяет его редактировать.
2) "Definition" – поле для текстового определение функции данного блока.
3) "Source" – источник информации, содержащейся в этом блоке.
4) "Status" – степень завершенности описания блока.
5) Развернутые комментарии о функции блока в произвольной форме
можно ввести с помощью редактора "Note editor".
46
Институт инноватики
http://ii.spb.ru/
8. Нарисовать стрелки, отображающие интерфейс блока A0.
Как только создается контекстная диаграмма, появляется необходимость
проводить стрелки (Input, Control, Output, Mechanism), являющиеся входами
или выходами блока, содержащегося на ней. На контекстной диаграмме
стрелки отображают входы и выходы системы. Для рисования стрелок используется инструмент "Arrow tool"
. Выбрав его, можно приступать к
рисованию дуг. Контекстная диаграмма содержит только граничные (интерфейсные) дуги. Граничные дуги начинаются или заканчиваются на границе
диаграммы, т.е. они входят или выходят в/из диаграммы.
Рисование дуги начинается с указания ее начала. Если дуга начинается
на границе диаграммы, то нужно указать на соответствующую границу (сторону) диаграммы и нажать и отпустить левую кнопку мышки. Затем нужно
указать точку назначения дуги и повторным нажатием левой кнопки дуга будет создана. Во время рисования дуги кнопку мышки НЕ НАДО держать нажатой. Объекты, которые могут быть источниками или приемниками дуг,
выделяются цветом, когда над ними находится курсор.
BPwin автоматически проводит дугу между двумя точками. Дуги рисуются как совокупность сегментов. Каждый сегмент можно перемещать, изменяя конфигурацию дуги. Перемещая сегменты, соответствующие началу и
концу дуги, можно менять источник и приемник дуги.
Методология IDEF0 требует наименования всех дуг. Для этого существует редактор "Name Editor", который можно вызвать через локальное меню
объекта-дуги.
9. Создать диаграмму декомпозиции первого уровня.
Создав контекстную диаграмму, мы готовы перейти к ее декомпозиции.
Для этого нужно создать диаграмму декомпозиции. Осуществляется это с
помощью следующих команд:
1) Выбрать инструмент "Go To Child Diagram"
.
2) Если диаграмма содержит больше, чем один блок, то необходимо
указать блок, который требуется декомпозировать. При наличии лишь одного
блока (как на контекстной диаграмме) такого указания не требуется.
Если блок, который был активизирован с помощью инструмента "Go To
Child Diagram", еще не обладает диаграммой декомпозиции, то появится диалог с вопросом о количестве блоков, которые появятся на диаграмме декомпозиции (методология IDEF0 рекомендует ограничивать количество блоков
на диаграмме числом от 3 до 6). В нашем случае диаграммы декомпозиции
еще не существует и необходимо ввести количество блоков на ней.
Если блок уже имеет диаграмму декомпозиции, то будет просто выполнен переход к ней.
Для диаграммы декомпозиции граничными дугами являются входные и
выходные дуги родительского блока. Работа над диаграммой декомпозиции
47
Институт инноватики
http://ii.spb.ru/
заключается в создании и описании блоков и в соединении их дугами, отображающими горизонтальные связи блоков одной диаграммы. Для создания
дополнительных блоков на диаграмме служит инструмент "Activity Box
.
Tool"
10.Дать названия и описать блоки, располагаемые на диаграмме A0.
11.Соединить интерфейсные стрелки с соответствующими им функциями.
12.Определить интерфейсы блоков (функций) на диаграмме декомпозиции
Интерфейсы блоков изображаются в виде стрелок. Эту работу рекомендуется начинать с определения выходов функций, затем входов, и, наконец,
механизма и управления.
13.Изобразить взаимосвязи между функциями.
14.После разработки диаграммы A0 вернуться к контекстной диаграмме
A-0 и проверить ее корректность.
15.Сохранить модель FileÆ Save.
2.1.2. Лабораторная работа 2. Создание следующих диаграмм модели
Цель: выполнять дальнейшую декомпозицию функций, использовать
средства навигации по модели.
В ходе предыдущего занятия были изучены все основные операции по
созданию IDEF0-модели средствами программы BPwin. Подробное описание
действий по созданию диаграмм, блоков, рисованию стрелок, наименованию
объектов модели и диаграммы можно найти в программе занятия 1.
Программа работы
1. Создать диаграмму декомпозиции для одного из блоков с диаграммы A0.
Декомпозицию функций системы нужно продолжать до тех пор, пока не
будет достигнута степень детализации, требуемая целью моделирования. Для
этого используется стандартная процедура описания выбранной функции с помощью IDEF0-диаграммы. Осуществляется это с помощью следующих команд:
1. Выбрать декомпозируемый блок.
2. Выбрать инструмент "Go To Child Diagram"
.
3. Указать блок, который требуется декомпозировать. При наличии лишь
одного блока (как на контекстной диаграмме) такого указания не требуется.
4. Ввести количество блоков, которые появятся на диаграмме декомпозиции (от 3 до 6).
48
Институт инноватики
http://ii.spb.ru/
Если блок уже имеет диаграмму декомпозиции, то будет просто выполнен переход к ней.
2. Разработать диаграмму декомпозиции.
Работа над диаграммой декомпозиции заключается в создании и описании блоков и в соединении их дугами, отображающими горизонтальные связи блоков одной диаграммы. Для создания дополнительных блоков на диа.
грамме служит инструмент "Activity Box Tool"
Граничными дугами диаграммы декомпозиции являются входные и выходные дуги родительского блока. Чтобы отойти от этого жесткого соответствия, для скрытия несущественных деталей используется инструмент "Tunnel tool" ( ).
Для отображения входов и выходов блоков и взаимосвязей между ними
используются стрелки. Стрелки изображаются с помощью инструмента "Arrow tool"
.
Прокомментировав диаграмму и все содержащиеся на ней объекты, установив все необходимые взаимосвязи между блоками, работу над диаграммой можно считать законченной.
3. Использовать средства навигации по модели
– переход к родительской
– Инструмент "Go To Parent Diagram"
диаграмме.
– Инструмент "Go To Child Diagram"
– переход к диаграмме декомпозиции.
До или после применения этого инструмента должен быть выделен декомпозируемый блок. Если для него уже существует диаграмма декомпозиции, то будет выполнен переход к ней. Если же не существует, то будет
предложено ее создать и указать количество IDEF0-блоков, содержащихся на
создаваемой диаграмме декомпозиции, после чего выполняется переход к
новой диаграмме:
EditÆ"Go To Diagram..." – переход к конкретной диаграмме;
EditÆ"Go To Activity..." – переход к конкретному блоку.
4. Создать диаграмму, содержащую структуру модели (дерево диаграмм) FileÆCreate Node Tree…, поэкспериментировать со свойствами этой
диаграммы, посмотреть разные способы отображения дерева диаграмм.
Диаграмма Node Tree предназначена для отображения структуры модели. На ней можно изобразить иерархическую структуру декомпозиции любого из блоков. Поскольку каждому блоку декомпозированному соответствует
одноименная диаграмма, то эта иерархия может рассматриваться и как взаимосвязь диаграмм модели. Имеется возможность указать количество уровней
иерархии, показываемых на диаграмме, а также настроить параметры отображения иерархии.
49
Институт инноватики
http://ii.spb.ru/
2.1.3. Лабораторная работа 3. Разработка собственной модели
Работа по созданию собственной модели состоит из тех же шагов, которые были выполнены в течение первых двух занятий, посвященных воссозданию предложенной модели.
Необходимо выбрать систему, которая будет описываться IDEF0-моделью. Это должна быть предметная область Вашего инновационного проекта: работа предприятия, создание фирмы, открытие магазина, какой-нибудь
привычный бытовой процесс, т.е. любой процесс, который решается с помощью выполнения разнообразных видов деятельности. Анализ объекта и разработка модели производится по правилам методологии IDEF0, описанным в
п. 1.4.
2.2. Лабораторные работы по программному комплексу
РROJECT ЕXPERT
Программный комплекс Project Expert, созданный российской фирмой
"Про-Инвест Колсалтинг", – это инструмент для построения финансовой модели предприятия, действующего в условиях рынка. Построенная при помощи Project Expert 5 детальная имитационноя модель может быть эффективно
использована для:
– разработки детального финансового плана предприятия;
– расчета бюджета предприятия и определения потребности в финансировании;
– разработки соответствующего международным требованиям инвестиционного проекта и бизнес-плана развития предприятия;
– контроля процесса реализации инвестиционного проекта.
Высокая скорость расчетов, расширенные функциональные возможности построения модели действующего предприятия, мощный генератор отчета, возможность групповой работы – все это делает Project Expert незаменимым инструментом для обеспечения процесса планирования и управления на
предприятии в условиях рынка.
Процесс работы с Project Expert может быть представлен в виде последовательности следующих шагов:
– построение модели;
– определение потребности в финансировании;
– разработка стратегии финансирования;
– анализ финансовых результатов;
– формирование и печать отчета;
– ввод и анализ данных о текущем состоянии проекта в процессе его
реализации.
50
Институт инноватики
http://ii.spb.ru/
Порядок выполнения цикла работ
Во время выполнения цикла работ обучаемый моделирует процесс
управления проектом. На первом занятии необходимо получить у преподавателя задание – проект, который будет "реализовываться" на протяжении последующих занятий.
В начале каждого занятия следует внимательно прочитать методические
указания к соответствующей работе, ответить на контрольные вопросы, затем – выполнить задание.
Отчет о выполненных работах
По результатам выполнения цикла работ необходимо представить отчет.
Отчет представляется в "бумажном" и "электронном" вариантах. Оба отчета
составляются в процессе выполнения работ, после выполнения каждой работы отчет дополняется соответствующей информацией.
Бумажный вариант отчета (представляется на бланке кафедры "Управление проектами") должен содержать:
1. Название и описание проекта.
2. Описание того, что было сделано на каждом лабораторном занятии
(например, "составлен список задач проекта").
3. Имя файла проекта и имя файла отчета.
4. Выводы, в которых должны быть отражены возможности пакета
Project Expert как инструмента финансового моделирования и анализа.
Электронный вариант отчета должен представлять собой файл, подготовленный с использованием редактора Microsoft Word. Отчет должен начинаться стандартным титульным листом. Содержательная часть отчета должна
состоять из следующих разделов:
1. Характеристика пакета Project Expert (назначение, возможности).
2. Краткое описание (название и содержание) этапов работы над проектом при использовании Project Expert.
3. Сведения о реализованном проекте (название, цель и стоимость проекта).
4. Список задач проекта.
5. Список ресурсов проекта.
6. Выводы (отразить возможности пакета Project Expert как инструментального средства финансового моделирования и анализа; перечислить задачи,
которые можно быстро и эффективно выполнить при помощи этого пакета).
2.2.1. Лабораторная работа 1. Построение модели
Процесс построения модели наиболее трудоемкий и требует значительной подготовительной работы по сбору и анализу исходных данных. Различ51
Институт инноватики
http://ii.spb.ru/
ные модули Project Expert независимы и доступны пользователю практически
в любой последовательности. Однако, отсутствие некоторых необходимых
исходных данных может блокировать доступ к другим модулям программы.
Независимо от того разрабатываете ли Вы детальный финансовый план или
хотите произвести предварительный экспресс-анализ проекта, Вы должны в
первую очередь ввести следующие исходные данные:
– дату начала и длительность проекта;
– перечень продуктов и/или услуг, производство и сбыт которых будет
осуществляться в рамках проекта;
– валюту расчета или две валюты расчета для платежных операций на
внутреннем и внешнем рынках, а также их обменный курс и прогноз его изменения;
– перечень, ставки и условия выплат основных налогов;
– для действующего предприятия также следует описать состояние баланса, включая структуру и состав имеющихся в наличие активов, обязательств и капитала предприятия на дату начала проекта.
Следующим этапом процесса построения модели является описание
плана развития предприятия (проекта). Для этого необходимо ввести следующие исходные данные:
– инвестиционный план, включая календарный план работ с указанием
затрат и используемых ресурсов;
– операционный план, включая стратегию сбыта продукции или услуг,
план производства, план персонала, а также производственные издержки и
накладные расходы.
Замечание. Фирма "Про-Инвест Консалтинг" выпускает несколько вариантов пакета Project Expert, которые имеют разные возможности. Наиболее мощными являются варианты Professional и Holding. В данном цикле
работ используется простой комплект – Micro.
Все варианты Project Expert имеют одинаковый интерфейс. Разделение
пакетов на категории выполнено путем блокирования некоторых команд:
пользователь видит соответствующую командную кнопку, однако в результате щелчка по кнопке действие не выполняется.
Задание
1. Запустите Projecr Expert Micro (команда Пуск/Программы/Projecr
Expert Micro/ Projecr Expert Micro).
2. Из меню Проект выберите команду Новый и в поля диалогового окна
Новый проект введите краткие сведения о проекте. Не забудьте указать имя
файла проекта. Для выбора папки, в которую будет помещен файл проекта,
используйте кнопку Пролистать.
52
Институт инноватики
http://ii.spb.ru/
3. Используя вкладки Проект, Компания и Окружение диалогового
окна Содержание (рис. 22) введите подробную информацию о проекте и его
окружении.
Рис. 22. Диалоговое окно Содержание
4. Используя команду Сохранить из меню Проект, сохраните проект
(файл проекта).
5. Выбором команды Выход из меню Проект завершите работу с Projecr
Expert Micro.
6. Запустите Microsoft Word, напишите отчет о проделанной работе,
сохраните файл отчета в своей рабочей папке.
2.2.2. Лабораторная работа 2. Определение потребности и разработка
стратегии финансирования
Для определения потребности в финансировании следует произвести
предварительный расчет проекта. В результате предварительного расчета определяется эффективность проекта без учета стоимости капитала, а также определяется объем денежных средств, необходимый и достаточный для покрытия дефицита капитала в каждый расчетный период времени с шагом
один месяц.
После определения потребности в финансировании разрабатывается
план финансирования. Пользователь имеет возможность описать два способа
финансирования:
– посредством привлечения акционерного капитала;
– посредством привлечения заемных денежных средств.
В процессе разработки стратегии финансирования проекта пользователь
имеет возможность промоделировать объем и периодичность выплачиваемых дивидендов, а также стратегию использования свободных денежных
средств (например: размещение денежных средств на депозит в коммерческом банке или приобретение акций сторонних предприятий).
53
Институт инноватики
http://ii.spb.ru/
Задание
1. Запустите Projecr Expert Micro.
2. Откройте проект, над которым Вы работаете. Для этого из меню Проект выберите команду Открыть и в появившемся диалоговом окне Открыть проект выберите файл нужного проекта. Для выбора папки, в которой находиться файл проекта, используйте список Каталоги, для выбора
диска – список Диски.
3. Составьте календарный план проекта. Для этого в диалоговом окне
Содержание выберите вкладку Инвестиционный план, в которой щелкните
на кнопке Календарный план. Используя диалоговое окно Календарный
план (рис. 23), введите этапы проекта. Характеристики этапа вводятся в диалоговое окно Редактирование этапа проекта (рис. 24), которое появляется в
результате щелчка на командной кнопке Добавить этап. Для связывания
этапов используйте командную кнопку Связывание.
Рис. 23. Диалоговое окно Календарный план
Рис. 24. Диалоговое окно Редактирование этапа проекта
54
Институт инноватики
http://ii.spb.ru/
4. Проверьте и, если нужно, внесите изменения в календарь проекта (для
этого в диалоговом окне Календарный план щелкните на командной кнопке
Календарь).
5. Используя вкладки Операционный план и Финансирование диалогового окна Содержание, задайте характеристики продукта и финансирование проекта.
6. Сохраните измененный проект и завершите работу с Projecr Expert Micro.
7. Запустите Microsoft Word, откройте файл отчета, созданный во время
выполнения предыдущей работы, внесите в отчет необходимые дополнения.
Не забудьте сохранить измененный отчет.
2.2.3. Лабораторная работа 3. Анализ финансовых результатов и
формирование отчета
В процессе расчетов Project Expert автоматически генерирует стандартные отчетные бухгалтерские документы:
– отчет о прибылях и убытках;
– бухгалтерский баланс;
– отчет о движении денежных средств;
– отчет об использовании прибыли.
Hа основе данных отчетных бухгалтерских документов осуществляется
расчет основных показателей эффективности и финансовых коэффициентов.
Пользователь может разработать несколько вариантой проектов в соответствии с различными сценариями их реализации. После определения наи
более вероятного сценария проекта он принимается за базовый. На основе
базового варианта проекта производится анализ чувствительности и определяются критические значения наиболее важных факторов, влияющих на финансовый результат проекта.
После завершения анализа проекта формируется отчет. В Project Expert
предусмотрен специальный генератор отчета, который обеспечивает компоновку и редактирование отчета по желанию пользователя. В отчет могут
быть встроены нс только стандартные графики и таблицы, но также таблицы
и графики, построенные пользователем при помощи специального редактора.
Также пользователь имеет возможность встраивания в отчет комментариев в
виде текста.
Задание
1. Запустите Projecr Expert Micro.
2. Откройте проект, над которым Вы работаете.
3. Используя вкладки Результаты и Анализ проекта ознакомьтесь с
сфоримрованными Project Expert характеристиками проекта и возможностями финансового анализа.
55
Институт инноватики
http://ii.spb.ru/
4. Сохраните измененный проект и завершите работу с Projecr Expert
Micro.
5. Запустите Microsoft Word, откройте файл отчета, созданный во время
выполнения предыдущих работ, внесите в отчет необходимые дополнения.
Не забудьте сохранить измененный отчет.
Рис. 25. Вкладка Результаты
Рис. 26. Вкладка Анализ проекта
Заключительное замечание
Одной из важных задач решаемых в процессе управления проектом является
ввод и анализ данных о текущем состоянии проекта. В Project Expert предусмотрены средства для ввода фактической информации о ходе реализации
проекта. Актуальная информация может вводится ежемесячно. На основе
введенной актуальной информации и плана сформируется отчет о рассогласованиях плановой и фактической информации, которая может быть использована в процессе управления проектом. К сожалению в версии Project Expert
Micro эта возможность, не доступна.
56
Институт инноватики
http://ii.spb.ru/
2.3. Лабораторные работы по программному комплексу
МICROSOFT РROJECT 4.0
Одним из современных методов эффективного управления в бизнесе является метод Project Managment (см. п. 1.6). Project Managment (управление
проектом) – современный метод организационного управления проектом в
условиях рыночной экономики. В основе концепции Projec Managment лежит
понятие "проект", которое можно определить так: "Это что либо, что задумывается, планируется и реализуется". В этом случае деятельность предприятия (фирмы) можно рассматривать как цепь, последовательность реализуемых проектов.
Целью реализации проекта, как правило, является создание чего-либо
нового, не существующего в данный момент. В результате реализации инновационного проекта появляется новое изделие, технология, производственная
линия.
Цикл реализации проекта может быть представлен как последовательность следующих этапов: замысел, реализация, передача заказчику. Удельный вес каждого этапа варьируется в зависимости от конкретного проекта, а
также его типа. В проектах, которые реализуются в сфере малого предпринимательства, как правило, особое место занимает этап реализации (под малым проектом здесь понимается проект, длительность реализации которого
обычно не превышает полугода, а затраты на реализацию исчисляются десятками тысяч рублей).
Для поддержки процесса управления проектом на различных этапах существует большое количество программных комплексов, целью применения
которых является повышение эффективности реализации проекта, т.е. выполнение как всего проекта в целом, так и его отдельных этапов в заданные
сроки и в рамках утвержденных ассигнований.
Основными задачами менеджера проекта является составление сетевого
графика (расписания) проекта, распределение ресурсов между задачами проекта и слежение за ходом реализации проекта.
Внедрение компьютерных технологий в практику реализации проекта
может оказать существенную помощь в эффективной реализации проектов.
Анализ существующих программных комплексов поддержки деятельности
по управлению проектами показал, что для малых проектов, в которых
удельный вес этапа реализации значителен, предпочтительным является пакет программ Microsoft Project. Он позволяет эффективно выполнить структуризацию проекта путем разделения его на этапы и подзадачи, выявить критические задачи (задачи, длительность которых существенно влияет на длительность реализации всего проекта), получить сетевой график проекта, осуществить назначение ресурсов задачам проекта, контролировать загрузку ресурсов.
57
Институт инноватики
http://ii.spb.ru/
Укрупнено методика использования пакета Microsoft Project для управления проектом может быть представлена в виде последовательности следующих шагов:
– создание календаря;
– составление списка задач;
– структуризация задач;
– назначение связей между задачами;
– выявление критических задач и, возможно, изменение связей между
задачами;
– составление списка ресурсов, доступных для реализации проекта;
– назначение ресурсов задачам проекта;
– слежение за ходом реализации проекта.
Порядок выполнения цикла работ
Во время выполнения цикла работ обучаемый моделирует процесс
управления проектом. На первом занятии необходимо получить у преподавателя задание – проект, который будет "реализовываться" на протяжении последующих занятий.
В начале каждого занятия следует внимательно прочитать методические
указания к соответствующей работе, ответить на контрольные вопросы. Затем надо выполнить задание.
Отчет о выполненных работах
По результатам выполнения цикла работ необходимо представить отчет.
Отчет представляется в "бумажном" и "электронном" вариантах. Оба отчета
составляются в процессе выполнения работ, после выполнения каждой работы отчет дополняется соответствующей информацией.
Бумажный вариант отчета должен содержать:
1. Название и описание проекта.
2. Описание того, что было сделано на каждом лабораторном занятии
(например, "составлен список задач проекта").
3. Имена файлов проекта и файла отчета.
4. Выводы, в которых отразить возможности пакета MS Project как инструментального средства управления проектом.
Электронный вариант отчета должен представлять собой файл, подготовленный с использованием редактора MS Word. Отчет должен начинаться
титульным листом. Содержательная часть отчета должна состоять из следующих разделов:
1. Характеристика пакета MS Project, как инструментального средства
управления проектом на этапе подготовки (назначение, возможности, типы
поддерживаемых связей между задачами).
58
Институт инноватики
http://ii.spb.ru/
2. Краткое описание (название и содержание) этапов подготовки проекта
к реализации.
3. Сведения о реализованном проекте (название, цель и стоимость проекта).
4. Список задач проекта.
5. Список ресурсов проекта.
6. Выводы (отразить возможности пакета MS Project как инструментального средства управления проектом; перечислить задачи, которые можно быстро и эффективно выполнить при помощи этого пакета).
2.3.1. Лабораторная работа 1. Начало работы над проектом
Цель работы: умение использовать пакет Microsoft Project для создания
календаря проекта и составления списка задач проекта.
Общие сведения
Календарь
Одной из задач, решаемых на этапе подготовки к реализации проекта,
является получение сетевого графика проекта. При построении сетевого графика MS Project использует календарь – таблицу, в которой отражены рабочие и нерабочие (выходные и праздничные) дни. Различают стандартный календарь и календари пользователя. Стандартный календарь предполагает, что
рабочими днями являются все дни недели, за исключением субботы и воскресенья, и рабочий день длится 8 часов. Календарь пользователя учитывает
реальные рабочие дни. Например, очевидно, что в России реальный календарь в январе и мае существенно отличается от стандартного.
При работе с проектом MS Project позволяет помимо базового календаря
использовать несколько календарей пользователя. Можно, например, создать
календарь для всего проекта в целом (основной календарь) и календарь для
отдельного ресурса, который будет учитывать особенности его использования (например, недоступность ресурса в определенные дни или месяцы).
Задачи проекта
Задача это некоторая деятельность которую надо выполнить, чтобы
завершить часть проекта.
Работа над проектом начинается с составления списка задач проекта.
Большие, сложные задачи, как правило, могут быть естественным образом
представлены в виде набора боле простых, более конкретных задач. Поэтому
при составлении списка сначала записывают общую (обобщенную) задачу,
затем – задачи из которых эта общая задача состоит (подчиненные задачи).
Замечание. При составлении списка задач проекта обычно используют
метод, который часто называют "сверху – вниз". Суть метода заключается в
том, что сначала составляют список главных (обобщенных) задач, затем этот
список уточняется, посредством добавления уточняющих задач (рис. 27).
59
Институт инноватики
Садовый дом
http://ii.spb.ru/
Садовый дом
Фундамент
Сруб
Крыша
Отделка
Садовый дом
Фундамент
Сруб
Крыша
Стропила
Фронтоны
Обрешетка
Кровля
Отделка
Пол
Двери
Окна
Рис. 27. Пример использования метода "сверху вниз" при составлении списка задач
проекта сверху вниз
Каждая задача проекта характеризуется длительностью, которая
измеряется в минутах, часах, днях и неделях.
Длительность обобщенной задачи определяется длительностью ее подчиненных задач. Длительность обобщенной задачи вычисляет MS Project.
Длительность подчиненной задачи нижнего уровня, т.е. задачи у которой нет подчиненных задач, определяется временем необходимым для ее выполнения одной единицей ресурса. Например, один рабочий копает траншею
в 5 метров 8 часов. Если для реализации проекта необходимо выкопать
траншею длинной в 10 метров, то длительность задачи "Траншея" равна 16
часам. Длительность подчиненной задачи задает менеджер проекта на основе
нормативной документации.
Контрольные точки проекта
В каждом проекте могут быть выделены этапы, после выполнения которых процесс реализации проекта переходит на новый качественный уровень.
Например, после этапа согласования требований с заказчиком начинается этап
подготовки технической документации. Можно считать, что последней задачей этапа согласования требований с заказчиком является задача утверждения
требований. Подобные задачи, как правило, должны выполняться в конкретный, заранее установленный, день, поэтому их называют контрольными точками. Длительность задач – контрольных точек принимают равной нулю.
Задание
1. Запустите Microsoft Project.
2. Создайте календарь проекта. Для чего из меню Options выберите команду Base Calendars, щелкните на кнопке New. В поле Name появившегося
60
Институт инноватики
http://ii.spb.ru/
диалогового окна введите имя календаря, например, Россия. Затем, просматривая календарь, установите реальные рабочие (Working) и нерабочие
(Nonworking) дни. Подтвердите необходимость сохранения созданного календаря щелчком на кнопке OK.
3. Используя диалоговое окно Project Information, которое появляется
при выборе из меню Options команды Project Info, установите предполагаемую дату начала реализации проекта (поле Start), задайте название проекта
(поле Project), название компании, реализующей проект (поле Company),
фамилию менеджера проекта (поле Manager). Используя раскрывающийся
список Calendar, задайте в качестве базового календаря проекта календарь,
созданный при выполнении предыдущего пункта задания. В поле Notes введите описание проекта (цель проекта, ожидаемый результат).
4. Используя таблицу ввода списка задач, которая активизируется при
выборе из меню View команды Task Sheet, введите названия задач проекта
(колонка Name). Для подчиненных задач нижнего уровня задайте длительность (колонка Duration). Единица измерения длительности задачи (h – час,
w – неделя, m – месяц) вводиться сразу за числом. Например, 2w, 5h.
Замечание. На первом этапе работы над проектом, когда задачи проекта
представлены в виде простого списка, длительность обобщенной задачи
равна длительности самой длительной подчиненной задачи. Позже, когда будут установлены связи между задачами, длительность обобщенной задачи
будет вычислена как сумма длительностей подчиненных задач.
5. Если выполнение какой-либо задачи должно начаться в определенный
день, то введите дату начала выполнения этой задачи (колонка Scheduled Start).
6. Используя команду Save из меню File, сохраните проект в своем рабочем каталоге.
7. Используя команду Exit из меню File, завершите работу с Microsoft
Project.
8. Начните работу по составлению отчетов ("бумажного" и "электронного") о цикле работ (см. раздел методических указаний "Отчет о выполненных
работах"). Файл отчета сохраните в своем рабочем каталоге.
2.3.2. Лабораторная работа 2. Корректировка списка задач
и формирование структуры проекта
Цель работы: умение вносить изменения в список задач проекта, умение
формировать структуру проекта путем повышения и понижения уровня задач
проекта.
Корректировка списка задач проекта
Во время работы над проектом довольно часто возникает необходимость
внести изменения в список задач проекта: добавить новую задачу (в том чис61
Институт инноватики
http://ii.spb.ru/
ле не только в конец списка), удалить ошибочно введенную, изменить порядок следования задач.
Добавление задачи
Чтобы добавить в список новую задачу, надо выделить задачу (щелкнуть
левой кнопкой мышки в поле ID задачи), перед которой нужно поместить новую задачу, и из меню Edit выбрать команду Insert или нажать клавишу
<Insert>. В результате этих действий в список задач будет добавлена пустая
строка в которую можно ввести новую задачу.
Удаление задачи
Чтобы удалить задачу, надо выделить эту задачу (щелкнуть левой кнопкой мышки в поле ID задачи)и из меню Edit выбрать команду Delete.
Перемещение задачи
Чтобы переместить задачу (или группу следующих одна за другой задач)
в другое место списка, надо выделить нужную задачу (задачи) и из меню Edit
выбрать команду Cut (Вырезать). Затем ВЫДЕЛИТЬ задачу, перед которой
надо поместить выделенные на предыдущем шаге задачи, и из меню Edit выбрать команду Paste (Вставить).
Формирование структуры проекта
Представление задач в проекта виде простого списка не достаточно наглядно. Простой список не отражает структуру проекта, связи между задачами, не позволяет видеть главные и подчиненные задачи. Гораздо удобнее задачи проекта представить в виде иерархического списка, в котором задачи
разделены по уровням.
Обычно во время работы над проектом сначала формулируется цель проекта (главная задача), затем она разбивается на фазы (крупные задачи), фазы
разбиваются на задачи, задачи – на подзадачи более низкого уровня и т.д. до
тех пор пока не будут определены все необходимые для завершения проекта
задачи. Таким образом, проект можно рассматривать как совокупность обобщенных и подчиненных задач. Обобщенная задача (summar task) своего рода
заголовок, она суммирует стоимость и длительность задач нижнего уровня.
Подчиненная задача (subordinate task) – это часть обобщенной задачи.
Рис. 28. Командные кнопки формирования структуры проекта
62
Институт инноватики
http://ii.spb.ru/
Перевести задачу с одного уровня на другой, сделать ее подчиненной
или главной (если задача уже является подчиненной) можно в режиме просмотра диаграммы Гантта, для перехода в который надо из меню View (Просмотр) выбрать команду Gantt Chart или в режиме просмотра списка задач
(команда Task Sheet из меню View). В этих режимах на панели инструментов
появляются кнопки, позволяющие формировать структуру проекта (рис. 28)
Замечание. В режиме просмотра диаграммы Гантта, рядом со списком задач выводится диаграмма Гантта, на которой подчиненные задачи
изображаются горизонтальными столбиками, обобщенные – скобками. При
этом, если подчиненные задачи начинаются одновременно, то длительность
обобщенной задачи полагается равной длительности наиболее длительной
подчиненной задачи. О том, как связать подчиненные задачи, т.е. указать,
что одна задача должна начинаться, например, только после окончания
другой, вы узнаете в следующей работе.
Чтобы понизить уровень задачи, сделать ее подчиненной, надо выделить
эту задачу и щелкнуть на кнопке со стрелкой вправо.
Чтобы повысить уровень задачи, сделать ее обобщенной, для задач за
ней следующих, надо выделить эту задачу и щелкнуть на кнопке со стрелкой
влево.
Следует обратить внимание, что при копировании или перемещении
обобщенной задачи все подчиненные задачи также копируются или перемещаются. Если надо переместить только обобщенную задачу, то сначала надо
перевести подчиненные задачи на уровень обобщенной.
Проект можно просматривать с различной степенью детализации.
Щелкните на кнопке со значком минус чтобы скрыть подчиненные задачи
текущей, выделенной, задачи. Если задача является обобщенной и подчиненные задачи скрыты, то нажмите на кнопку со значком плюс, чтобы просмотреть подчиненные задачи. Чтобы увидеть все скрытые задачи проекта, нажмите на кнопку с двумя плюсами.
Задание
1. Откройте файл проекта, над которым вы работаете.
2. Добавьте в начало списка задач название вашего проекта и сделайте
все введенные ранее задачи подчиненными этой задаче.
3. Сформируйте структуру своего проекта: определите главные и подчиненные задачи.
4. Просмотрите задачи проекта. Внесите в него необходимые изменения
(например, добавьте несколько новых, уточняющих задач).
5. Научитесь просматривать проект с различной степенью детализации.
6. Сохраните измененный проект.
7. Внесите дополнения в отчеты (электронный и бумажный).
63
Институт инноватики
http://ii.spb.ru/
2.3.3. Лабораторная работа 3. Назначение связей между задачами
Цель работы: знание типов связей между задачами, понятий "время опережения" и "время задержки"; умение связывать задачи проекта связями различного типа.
Связи между задачами
Задачи реального проекта связаны между собой во времени. Например,
некоторые задачи могут выполняться одновременно, другие не могут быть
начаты до тех пор пока не завершиться некоторая предыдущая задача. Поэтому после того, как составлен список задач и задачи распределены по
уровням (определены обобщенные задачи и подзадачи), необходимо установить связи между задачами.
Различают три типа связей между задачами проекта:
– конец-начало (finish-to-start, FS)
– начало-начало (start-to-start, SS)
– конец-конец (finish-to-finish, FF)
Чтобы назначить связь типа "конец-начало" между следующими в списке друг за другом задачами, надо выделить эти задачи и щелкнуть на командной кнопке Связать задачи (рис. 29) или из меню Edit выбрать команду
Link Task.
Рис. 29. Кнопка установки связи между задачами
Связи типа SS и FF, а также связь типа FS, если задачи, которые надо
связать, в списке задач не следуют одна за другой, устанавливаются с использованием формы задачи (Task Form). Чтобы установить связь между задачами, надо активизировать Task Form (рис. 30) и используя кнопки
Previous и Next выбрать задачу, для которой нужно установить связь (при
этом в поле Name отображается имя этой задачи). Затем в строку колонки ID
(рядом с колонкой Predecessor Name) ввести идентификатор (номер из списка задач) задачи, с которой связывается данная задача, а в поле Type – тип
связи (FS, FF или SS) и щелкнуть на OK.
Время задержки (опережения) выполнения задачи
Иногда между завершением одной задачи и началом другой должно
пройти некоторое время, или задача-приемник должна начинаться немного
раньше, чем завершится задача-родитель. Например, пол, после покрытия
лаком должен сохнуть 48 часов. Следовательно, задача "оборудование" может начаться только через 48 часов после завершения задачи "окраска".
64
Институт инноватики
http://ii.spb.ru/
Другой пример. Если монтируется линия электропередачи из 30 столбов, то
совсем не обязательно ждать, пока будут установлены все столбы, чтобы
приступить к монтажу проводов. Задачу монтажа можно начать после того,
как будут установлены, например, 5 столбов. Подобные ситуации моделируются заданием времени отставания (Lag Time) для задачи-приемника. Для
задания времени отставания (опережения) используют Task Form. Время отставания задается вводом положительного числа в поле Lag, опережения –
отрицательного.
Рис. 30. Форма задачи (Task Form) позволяет установить связи между задачами
Временной масштаб диаграммы Гантта
Диаграмму Гантта (Gantt Chart) удобно использовать для наблюдения
связей между задачами проекта. В левой части окна отображается список задач проекта, в правой – диаграмма Ганта. При этом задачи, длительность которых оказывает влияние на длительность всего проекта, отображаются
красным цветом.
Если проект длительный, то диаграмма Гантта не помещается в одном
окне. Это не всегда удобно. Microsoft Project позволяет настроить временной
масштаб диаграммы таким образом, чтобы в окне были видны сразу все задачи проекта.
В верхней части диаграммы Гантта выводится временная ось. Масштаб
оси устанавливается в диалоговом окне Timescale (рис. 31), которое появляется при выборе из меню Format команды Timescale.
65
Институт инноватики
http://ii.spb.ru/
Рис. 31. Используя диалоговое окно Timescale можно задать временной масштаб
отображения диаграммы Гантта.
Группа Major Scale диалогового окна Timescale используется для задания главного масштаба, группа Minor Scale – уточняющего. Для каждого из
масштабов можно задать единицу измерения (Units), способ ее отображения
(Label) и единицу приращения (Count).
Контрольные вопросы
1. Перечислите типы связей, которыми могут быть связаны задачи проекта.
2. Если некоторая задача может быть начата только через некоторое
время после завершения другой (например, из технологических соображений), то как этот факт отображается в модели проекта?
3. Если некоторая задача должна начинаться несколько позже, чем закончится другая задача проекта, то как этот факт отразить в модели проекта?
4. Если длительность проекта такова, что диаграмма Гантта не помещается в пределах экрана, то что и как надо сделать, чтобы вся диаграмма
Гантта была видна одновременно?
Задание
1. Откройте файл проекта, над которым вы работаете.
2. Установите связи между задачами проекта таким образом, чтобы модель проекта соответствовала реальному проекту.
3. Найдите в проекте задачи, которые должны выполняться с задержкой
относительно других задач, и задайте для них время задержки.
4. Найдите в проекте задачи, которые могут выполняться одновременно
с другими задачами, но с некоторым опережением начала их выполнения.
Задайте для этих задач время опережения.
66
Институт инноватики
http://ii.spb.ru/
5. Установите такой временной масштаб диаграммы Гантта, чтобы вся
диаграмма была видна в одном экране.
6. Сохраните файл проекта.
7. Внесите дополнения в отчеты (электронный и бумажный).
2.3.4. Лабораторная работа 4. Ресурсы проекта
Цель работы: знание понятия "ресурс", характеристик ресурса, как составной части проекта, умение составлять список ресурсов проекта.
Цена ресурса и стоимость задачи
Для выполнения задач проекта необходимы ресурсы: люди, оборудование, механизмы. За использование ресурса для реализации задачи надо платить. Стоимость использования ресурса определяется ценой ресурса и временем его использования. Цена ресурса измеряется в денежных единицах, отнесенных к единице времени (d- день, h-час, m-минута). Например, цена ресурса "грузовик" может быть 50 руб./h. Это означает, что если для выполнения
некоторой задачи необходимо использовать ресурс "грузовик" в течение двух
часов, то стоимость этого ресурса равна 100 руб.
Суммарная стоимость ресурсов, использованных для реализации задачи,
определяет стоимость этой задачи. Из стоимости ресурсов, использованных
для реализации задач проекта, складывается стоимость проекта в целом.
Ресурсы проекта
Работая над проектом нужно иметь список доступных ресурсов. Наиболее легко составить и просмотреть список ресурсов проекта можно в режиме
"Список ресурсов" (Resource Sheet), для перехода в который надо из меню
View выбрать команду Resource Sheet.
Замечание. В список ресурсов проекта следует включать только те ресурсы, использование которых влияет на время выполнения работ. Включать в список ресурсов материалы не надо.
В режиме Resource Sheet список ресурсов проекта отображается в виде
таблицы. Каждому ресурсу соответствует отдельная строка. Колонки таблицы содержат характеристики ресурсов проекта:
– Name – название ресурса.
– Initials – обозначение ресурса (краткое название).
– Group – название группы, к которой принадлежит ресурс. Например,
"Персонал" или "Оборудование".
– Мах. Units – количество единиц ресурса, доступных для реализации
проекта.
67
Институт инноватики
http://ii.spb.ru/
– Std. Rate – стандартная цена ресурса. Под стандартной ценой ресурса
понимается цена ресурса при использовании его в течение рабочего дня.
– Ovt. Rate (Overtime rate) – стоимость ресурса при использовании его за
пределами обычного рабочего дня, например сверхурочно или в нерабочие и
праздничные дни.
– Cost/Use – фиксированная стоимость использования ресурса, плата за
использование ресурса не зависящая от времени его использования (может
рассматриваться как дополнительная плата за использование ресурса).
– Accrue at (нарастать, увеличиваться) – определяет момент увеличения
стоимости задачи при использовании ресурса. Плата за ресурс может вноситься: в момент начала использования ресурса (в этом случае значение характеристики Accrue at устанавливают равным Start), после того как ресурс
использован (при этом характеристике Accrue at присваивают значение End)
или пропорционально времени его использования (в этом случае значению
Accrue присваивают значение Prorated).
– Code – код ресурса, в качестве которого обычно используют десятичное число.
При вводе значений в поля Std. Rate, Ovt. Rate и Cost/Use обозначение
денежной единицы можно не задавать, оно появится автоматически, после
завершения ввода.
MS Project позволяет задать требуемое обозначение денежной единицы
и ее положение (перед или после числа). Чтобы это сделать, надо из меню
Options выбрать команду Preferences и в появившемся диалоговом окне, в
строке Currency Symbol, задать обозначение требуемой денежной единицы,
например, руб., а в строке Symbol Position – положение обозначения (Before
– перед числом, After – после числа).
Контрольные вопросы
1. Перечислите характеристики ресурса.
2. Чем определяется стоимость задачи проекта?
3. Чем определяется стоимость проекта в целом?
Задание
1. Откройте файл проекта, над которым вы работаете.
2. Составьте список ресурсов, необходимых для реализации Вашего
проекта. Для каждого ресурса задайте цену (Std. Rate), цену при сверхурочном использовании (Ovt. Rate), величину фиксированной платы за ресурс (Cost/Use), количество ресурса, доступное в рамках реализации проекта (Max. Units) и другие характеристики.
3. Сохраните измененный проект.
4. Внесите дополнения в отчеты (электронный и бумажный).
68
Институт инноватики
http://ii.spb.ru/
2.3.5. Лабораторная работа 5. Назначение ресурсов задачам проекта
Цель работы: умение назначать ресурсы задачам проекта.
Стоимость и длительность реализации задачи
После того как сформирована структура проекта (составлен список задач, определены главные и подчиненные задачи, назначены связи между задачами) и составлен список ресурсов проекта, можно приступить к назначению ресурсов задачам проекта. В результате назначения ресурсов задачам
будет определена стоимость и длительность задач проекта.
Стоимость задачи определяется стоимостью ресурсов, необходимых для
ее реализации. Чем больше ресурсов требует задача, тем она дороже, тем
больший вклад вносит она в стоимость реализации проекта в целом.
Длительность реализации задачи зависит от количества единиц ресурса,
выделенных для ее реализации. Здесь надо вспомнить, что на этапе составления списка задач длительность каждой задачи задавалась в предположении,
что она реализуется одной единицей ресурса. После назначения ресурсов
длительность выполнения задачи определяется уже количеством единиц ресурсов, выделенных для ее решения. Например, длительность задачи "Траншея, 3 метра" равна 8-ми часам. При назначении этой задачи двух ресурсов
"землекоп", ее длительность сокращается до четырех часов.
Назначение ресурсов
Время реализации проекта зависит от длительности реализации задач,
которая в свою очередь зависит от количества ресурсов, выделенных для их
реализации. Таким образом, чем больше ресурса будет выделено задаче, тем
быстрее она будет выполнена. Следует обратить внимание, что некоторые
задачи, которые могут выполняться одновременно, могут требовать одинаковых ресурсов. При этом возникает проблема распределения ресурсов между
задачами: как распределить ресурсы таким образом, чтобы время реализации
всего проекта было минимальным? Очевидно, что в первую очередь ресурсы
надо выделять задачам, длительность которых определяет длительность реализации всего проекта (такие задачи называются критическими и на диаграмме Гантта изображаются красными прямоугольниками).
Чтобы назначить ресурс задаче, надо выделить, например в режиме просмотра диаграммы Гантта, задачу которой назначается ресурс, и щелкнуть на
кнопке "Ресурс" (рис. 32) или из меню Edit выбрать команду Assignment. Затем в появившемся диалоговом окне Resourсe Assigment, из раскрывающегося списка Recourses (рис. 33), выбрать нужный ресурс и щелкнуть на кнопке Add. В результате этих действий в нижней части окна появится окно формы задачи с информацией о задаче, которой назначается ресурс. В колонке
Resourse Name отображается имя назначенного задаче ресурса, в колонке
69
Институт инноватики
http://ii.spb.ru/
Units – количество единиц ресурса, а в колонке Work – количество работы,
которое должно быть выполнено для завершения задачи. Следует обратить
внимание, что при назначении задачи одной единицы ресурса, значения количества работы (Work) и длительности задачи (Duration) совпадают. Если
задаче назначить несколько единиц ресурса, то длительность задачи сокращается пропорционально количеству назначенных единиц, при этом величина количества работы не изменяется.
Рис. 32. Командная кнопка "Ресурс"
Рис. 33. Назначение ресурса в диалоговом окне Resource Assignment
Одной задаче можно назначить несколько разных ресурсов. Однако,
следует обратить внимание, что на длительность задачи влияет только первый из назначенных ресурсов. Остальные только изменяют стоимость задачи.
После назначения задачам ресурсов, необходимо убедиться, что ресурсы
назначены правильно, например, что некоторый ресурс не назначен нескольким задачам, которые выполняются одновременно, или какой-либо задаче не
назначено больше единиц ресурса, чем доступно для реализации проекта.
Сделать это можно просмотром списка ресурсов (команда Resource Sheet из
меню View), в котором неправильно назначенные ресурсы выделяются красным цветом.
После того как распределены ресурсы, можно просмотреть общую информацию о проекте. Для этого надо из меню Options выбрать команду
Project Status. Поля диалогового окна Project Status содержат информацию о
планируемых и действительных датах начала (Start) и завершения (Finish)
проекта (которые очевидно могут отличаться), о планируемой и действительной стоимости реализации проекта (Cost) , а также о проценте выполнения (% Complete) работ и длительности проекта.
70
Институт инноватики
http://ii.spb.ru/
Задание
1. Откройте файл проекта, над которым вы работаете.
2. Назначьте задачам проекта ресурсы. Используя режим просмотра списка ресурсов, убедитесь, что ресурсы задачам назначены верно.
3. Сохраните измененный проект.
4. Внесите дополнения в отчеты (электронный и бумажный).
2.3.6. Лабораторная работа 6. Контроль за развитием проекта
Цель работы: умение вводить информацию о выполненных задачах
проекта и проводить анализ состояния проекта.
После подготовки проект должен быть утвержден, например руководством или заказчиком, в результате чего появляется план проекта, в соответствии с которым осуществляется реализация проекта.
Замечание. Утвержденный до начала реализации план проекта называется базовым планом (baseline или plane).
В процессе реализации проекта менеджер проекта должен следить за ходом выполнения работ. Основной целью при этом является своевременное
обнаружение отклонений реализации проекта от намеченного плана и внесение изменений в проект (корректировка проекта) с целью минимизации этих
отклонений. Таким образом, в простейшем случае деятельность менеджера
по управлению проектом в процессе его реализации может быть сведена к
двум операциям: вводу информации о выполненных работах (задачах) и анализу состояния проекта.
Нарушения процесса реализации проекта, как правило, возникают из-за
задержек и из-за изменения стоимости проекта (обычно, увеличения).
Причиной задержек может быть:
– поломки оборудования;
– недостаточное финансирование;
– нехватка материалов;
– недооценка времени выполнения задачи;
– болезнь или увольнение сотрудников;
Причиной увеличения стоимости проекта может быть:
– увеличение длительности выполнения задачи;
– увеличение потребности в ресурсах;
– увеличение стоимости ресурсов.
Создание базового плана проекта
Базовый план проекта создается путем фиксации текущего состояния
проекта. Чтобы создать базовый план проекта, надо из меню Options выбрать
команду Set plan и в появившемся диалоговом окне щелкнуть на кнопке OK.
71
Институт инноватики
http://ii.spb.ru/
Ввод информации о состоянии проекта
Во время управления проектом необходимо фиксировать реальные даты
начала и завершения выполнения отдельных задач. Кроме того, во время выполнения задачи нужно фиксировать процент выполненной работы.
Для ввода данных о состоянии проекта (задач) надо из меню View выбрать команду Task Sheet, затем из меню Table команду Tracking. После
этого в поле Act. Start можно ввести реальную дату начала выполнения задачи, в поле Act. Finish – реальную дату завершения выполнения задачи, а в
поле % Comp. – процент выполнения задачи в момент ввода данных. Эту же
таблицу можно использовать для ввода реальной длительности (Act. Dur.) и
стоимости задачи (Act. Cost).
Данные о состоянии задачи можно ввести также в поля диалогового окна Tracking (рис. 34), которое появляется при щелчке на находящейся на панели инструментов кнопке Tracking (рис. 35.). Назначение полей этого диалогового окна очевидно.
Рис. 34. Диалоговое окно Tracking
Рис. 35. Командная кнопка Tracking
Анализ состояния проекта
Общую информацию о проекте можно увидеть в диалоговом окне
Project Status, которое появляется в результате выбора из меню Options команды Project Status.
Обычно менеджера интересует состояние не всех задач проекта, а только каких-то конкретных, например тех, которые выполняются в данное время. MS Project позволяет выделить из списка задач проекта только нужные,
удовлетворяющие определенному критерию. Делается это при помощи команд меню Filter. Некоторые команды меню Filter и соответствующие им
критерии отбора приведены ниже, в таблице.
72
Институт инноватики
Команда
All
Completed
Critical
In Progress
Overbudget
Summary Tasks
http://ii.spb.ru/
Критерий
Все задачи проекта
Задачи, завершенные к настоящему моменту
Критические задачи
Выполняемые в данный момент задачи
Задачи, затраты на выполнение которых превысили запланированные затраты
Обобщенные задачи
Задание
1. Откройте файл проекта, над которым вы работаете.
2. Если нужно, внесите изменения в проект и создайте базовый план проекта.
3. Моделируйте процесс реализации проекта, для чего для одной или нескольких задач проекта:
– установите, что задача выполнена полностью;
– укажите, что выполнение задачи начато позже (раньше) запланированной даты;
– укажите, что задача выполнена раньше запланированной даты;
– укажите, что для выполнения задачи потребовалось больше (меньше) единиц ресурса.
4. Внесите дополнения в отчеты (электронный и бумажный).
2.4. Лабораторные работы "Подбор команды проекта"
Осознание важности понятия интеллектуального капитала (ИК) для
реализации инноваций неизбежно приводит к необходимости разработки
средств, поддерживающих формализованные процедуры оценки ИК инновационного предприятия и в первую очередь – тех его составляющих, которые
зависят от личности субъекта инновационной деятельности, его характера и
культурных традиций, менталитета и т.п. В наибольшей степени различия в
культуре инновационной деятельности проявляются в ходе международных
проектов, когда в единой команде над одной проблемой работают представители различных стран с различными культурными традициями и своими менталитетами. С целью учета подобных различий разработаны системы тестов,
позволяющие оценить степень совпадения (или несовпадения) взглядов участников проекта, работающих в единой команде. На базе подобных тестов
создаются автоматизированные системы, позволяющие на основе компьютерной обработки результатов тестирования представить в наглядной форме
степень совпадения взглядов различных членов единой команды на те или
иные вопросы, связанные с управлением проекта. Анализ результатов тестирования позволяет оптимизировать социально-психологический климат в
73
Институт инноватики
http://ii.spb.ru/
команде управления проектом, что в конечном итоге приводит как к повышению эффективности управления конкретным проектом, так и к повышению ИК предприятия в целом. Примером автоматизированной системы
оценки социально-психологического климата команды управления проектом
может служить система “Innovations Across Cultural Bodies”, разработанная в
рамках программы INNOVATION Европейского Сообщества. Транснациональные команды менеджеров, работающие над общим инновационным проектом, могут использовать эту систему для следующих целей:
– определение культурно-психологических различий в подходах и стилях управления среди различных членов команды;
– развитие способностей членов команды преодолевать отрицательное
влияние этих различий на ход проекта;
– улучшение взаимопонимания между партнерами с различными стилями и опытом управления.
При управлении сложными проектами, как и во многих других сложных
ситуациях, отыскать "единственный наилучший путь" невозможно. В подобных случаях возможны различные стратегии поведения, и разные группы людей способны предлагать и отстаивать разные решения, которые на первый
взгляд кажутся противоречивыми, но часто отражают "различные части целой
истины". В этой связи разработана концепция "стилей управления", которая
отражает плюрализм возможного поведения членов команды проекта. Руководитель проекта должен анализировать различные стили управления, присутствующие в сформированной им команде, и пытаться соединить эти стили в
"наилучшую возможную культуру управления" для данного проекта.
При внимательном анализе возможных стилей управления становится
ясно, что каждый стиль характеризуется собственными частными моделями
предпочтений и неприятий управленческих установок, так называемых "дилемм", таких как:
– строгое следование утвержденным правилам/гибкость;
– поощрение индивидуальной свободы/групповой консенсус;
– ориентация на традиционные виды деятельности/работа на перспективу, и т.п.
Оценки данных установок не являются бинарными ("правда или ложь").
Они соответствуют сложной природе стилей управления, поэтому их компьютерная обработка нацелена на то, чтобы определить, какой из возможных
подходов наиболее адаптирован применительно к данной команде, сформированной для данного проекта.
Концепция "стилей управления" предполагает, что данное понятие есть
характеристика субъекта инновационной деятельности, которую он не может
легко и просто изменить. Наш стиль управления есть часть нашего "я", корпоративной и национальной индивидуальности. Поэтому решения относительно стилей управления не могут быть приняты на основе подходов, при74
Институт инноватики
http://ii.spb.ru/
емлемых для решения технических вопросов. Тем не менее, система позволяет обеспечить разумный подход к данной проблеме посредством анализа 12
различных "дилемм". Для решения этих дилемм предлагается соответствующий вопросник, поддержанный многовариантными типовыми ответами. На
основе полученных ответов формируется графическое изображение (примеры на рис. 36, 37, 38), позволяющее оценить стиль управления и его соответствие одному из четырех возможных "профилей менеджмента":
– "совокупность задач" или "управление в зависимости от обстоятельств";
– "система иерархий" или "управление в зависимости от личностей";
– "система отношений" или "управление в зависимости от описания работы";
– "рыночное предприятие" или "управление в зависимости от энтузиазма".
Очевидно, что в реальной жизни каждая личность представляет собой
некоторую совокупность различных стилей, однако система позволяет получить интегральную оценку, которая может служить исходной точной для
дальнейшего формирования квазиоптимального стиля управления в конкретной команде конкретного проекта.
Система предлагает пользователю выбрать один из шести возможных
ответов на каждый из 30 вопросов, касающихся различных аспектов социально-психологического климата в команде исполнителей проекта. На основе
компьютерной обработки полученных ответов формируется графическое
изображение персонального стиля управления конкретного индивидуума, которое может быть использовано для анализа следующих характеристик:
– персональный стиль управления пользователя системы;
– персональные стили управления членов команды исполнителей проекта;
– восприятие (оценка) членами команды исполнителей проекта доминирующего стиля управления в рамках данного проекта.
2.4.1. Лабораторная работа 1. Персональный стиль управления
Цель работы: описание субъективного (индивидуального) представления
идеального морально-психологического климата в команде исполнителей проекта.
Задание
1. Запустите программу Innovation Across Cultural Borders.
2. Выберите режим регистрации и зарегистрируйтесь как пользователь
системы.
3. Последовательно ответьте на каждый из 15 вопросов первой части вопросника, выбрав один из шести предлагающихся вариантов ответа, который
на Ваш взгляд в наибольшей степени соответствует Вашему представлению о
правильном ответе.
75
Институт инноватики
http://ii.spb.ru/
4. Сформируйте Ваш персональный график профиля менеджмента, выведите его на экран и сохраните в памяти.
5. Сравните Ваш персональный график с типовыми профилями и оцените, какой из них Вам ближе.
2.4.2. Лабораторная работа 2. Стиль управления в команде
исполнителей проекта
Цель работы: описание субъективного восприятия морально-психологического климата, сложившегося в команде исполнителей проекта.
Примечание: в качестве команды исполнителей проекта в данном случае
можно рассматривать студенческую группу или коллектив предприятия, на
котором Вы работаете.
Задание
1. Продолжите ответы на вопросы второй части вопросника.
2. Сформируете график профиля менеджмента в команде исполнителей,
выведите его на экран и сохраните в памяти.
3. Сравните Ваш персональный график с графиком команды и прокомментируйте имеющиеся различия.
Рис. 36.
76
Институт инноватики
http://ii.spb.ru/
Рис. 37.
Рис. 38.
77
Институт инноватики
http://ii.spb.ru/
ЦИТИРУЕМАЯ ЛИТЕРАТУРА
1. Бурков В.Н., Новиков Д.А. Как управлять проектами. -М: СИНТЕГГЕО, 1997. – 188 с.
2. Буч Г. Объектно-ориентированное проектирование с примерами применения. М.: Конкорд, 1992. – 376 с.
3. Воропаев В. И. Управление проектами в России. М.: "Аланс", 1995.
– 225 с.
4. Голубев С.А., Туккель И.Л. Информационная модель процесса выполнения проекта // Вестник машиностроения. -М.: 1999. № 2. С. 44-48.
5. Гэйн К., Сарсон Т. Структурный системный анализ: средства и методы. Пер с англ. Под ред. Козлинского А.В. М.: Эйтек, 1993.
6. Дорантес Д.Х., Туккель И.Л. Управление инновационными проектами: методология и инструментальные средства. /Учебное пособие первое
издание. -СПб: СПбГТУ, 1997. – 93 с.
7. Марка Д.А., МакГоуэн К. Методология структурного анализа и
проектирования SADT. Пер. с англ. М.: 1993, – 240 с.
8. Скютта Осмо. Инновационный менеджмент. Перевод с финского.
TACIS. 1999. – 179 c.
9. Сравнение и проблема выбора методов структурного системного
анализа. Калянов Г., Козлинский А., Лебедев В. // PC WEEK/RE, 27 августа,
1996, с. 46-50.
10.Твисс Б. Управление научно-техническими нововведениями: Сокр.
пер. с англ./ Авт. предисл. и науч. ред. К.Ф. Пузыня.- М.: Экономика, 1989.
– 271 с.
11.Туккель И.Л., Дорантес Д.Х. О системном проектировании компьютеризированных интегрированных производств на базе проблемноориентированного типового решения // Вестник машиностроения. М.: 1997.
№ 7. с. 47-50.
12.Чикало О. CASE и методология разработки ПО // PC WEEK/RE,
28 мая, 1996, с. 41-45.
13.Yourdon E. Modern Structured Analysis. N.Y.: Yourdon Press/ Prentice
Hall, 1989.
78
Документ
Категория
Без категории
Просмотров
43
Размер файла
919 Кб
Теги
инновационные, 1999, СПб, проектам, 100, часть, управления, спбгти, методология
1/--страниц
Пожаловаться на содержимое документа