Александрова Т.В., Голубев С.А., Колосова О.В., Туккель И.Л. и др. Управление инновационными проектами. Часть 2. Инструментальные средства и практикум управления проектами

Подождите немного. Документ загружается.

Институт инноватики http://ii.spb.ru/

и прокомментированные диаграммы возвращаются автору, и он вносит кор-

рективы в модель. Если это необходимо, исправленная модель вновь распро-

страняется среди читателей для нового цикла согласования.

Формальный механизм рассмотрения и одобрения диаграмм поддержи-

вается полем Status и правилами создания новых версий диаграмм, осущест-

вляемыми с помощью поля Number.

При работе с большими проектами обычно специально выделяется че-

ловек-библиотекарь, который выполняет всю работу по распространению

диаграмм и обеспечения цикла автор-читатель.

Определение цели создания модели

Модель не может разрабатываться без определенной задачи или четко

поставленной цели. Определение цели моделирования включает в себя необ-

ходимость ответа на следующие вопросы:

– Зачем моделируется данный процесс?

– Что будет показывать модель?

– Как читатели модели могут ее использовать?

Определение цели моделирования позволяет команде аналитиков сосре-

доточить усилия для ее достижения. В случае отсутствия цели моделирова-

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

Пример цели: Определить задачи каждого работника цеха и понять, как

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

по профессиональной подготовке для каждой должности.

Модель создается для того, чтобы ответить на набор вопросов. Эти во-

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

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

– Какие задачи решает мастер?

– Какие задачи решает рабочий?

– Кто контролирует готовую продукцию?

– Кто осуществляет промежуточный контроль?

– Какие инструменты нужны для выполнения технологической операции?

Точка зрения

Несмотря на важность учета мнения различных специалистов относи-

тельно описываемых в модели аспектов системы, модель должна создаваться

с позиций только одной определенной точки зрения. Другие точки зрения

могут быть отражены в других моделях.

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

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

различными задачами персонала, поэтому модель должна разрабатываться

только с позиции начальника цеха.

Институт инноватики http://ii.spb.ru/

Очень важно придерживаться единственной точки зрения в процессе

моделирования. Это подобно четкому выбору цели избавит от необходимо-

сти уделять внимание несущественным деталям и от постоянного перестраи-

вания модели.

Может быть полезным построить модель той же системы с другой точ-

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

Границы модели

Одно из основных свойств модели функций – возможность выяснить

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

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

ние моделирования, они должны быть определены вначале, чтобы управлять

процессом моделирования. Как и в случае с целью моделирования, без опре-

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

в этом случае границы системы будут расти одновременно с моделью.

Границы имеют два аспекта: полнота и глубина. Полнота определяет объ-

ем информации, предоставляемый диаграммой (горизонтальный уровень).

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

Чтобы правильно определить границы, много внимания уделяется раз-

работке контекстной диаграммы. Часто перед проектированием контекстной

диаграммы создают сразу диаграмму первого уровня декомпозиции (сле-

дующий уровень за контекстом). Это позволяет определиться с контекстом

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

их входы и выходы. Контекстная диаграмма задает границы модели, инфор-

мация, содержащаяся в ней очень важна и критична. Изменения контекстной

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

все диаграммы модели.

Когда определены границы модели, становится понятным, какую ин-

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

Наименование функции системы

В соответствии с предлагаемой последовательностью работы над моде-

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

цы модели. После чего начинается работа над контекстной диаграммой, со-

держащей единственный блок, представляющий функцию системы. Описа-

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

Определение Входа, Управления, Выхода и Механизма функции

Чтобы изобразить стрелки на IDEF0-диаграмме, рекомендуется начинать

с выхода функции, затем определить входные данные, после чего – механизм

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

Институт инноватики http://ii.spb.ru/

функция в системе существует для достижения какого-либо конкретного ре-

зультата. Если определить результат работы функции затруднительно, то это

может быть знаком того, что существует возможность улучшить бизнес-

процесс.

Определение Выходов

Важно отметить следующее: модель должна описывать функционирова-

ние системы в любых ситуациях. Это означает, что если какая-то ситуация

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

модели. Многие начинающие разработчики моделей забывают учитывать не-

благоприятные результаты работы функции. Например, функция "Изготовить

деталь", конечно, имеет выход – деталь. Однако нельзя забывать, что воз-

можны и бракованные детали, которые нужно обозначать отдельным выхо-

дом. Выходы, соответствующие неудачному выполнению функции, исполь-

зуются обычно в обратных связях. Важно отобразить все возможные ситуа-

ции, а потом предоставить право экспертам решать, какая информация долж-

на остаться в модели, а какая нет.

Определение Входов

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

ва выхода. В производственных процессах чтобы понять, что является вхо-

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

ния "выхода". Однако, в информационной индустрии исходные данные ис-

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

В этом случае исходные данные нельзя делать входом: они отображаются с

помощью стрелок управления.

Часто существует соблазн называть входные и выходные данные одина-

ково. Обычно это означает, что либо функция не имеет большого значения в

описываемом бизнес-процессе, либо выход назван неправильно. Разрешить

эту проблему можно использованием квалифицирующих и поясняющих слов

в названиях входов и выходов, чтобы названия отображали преобразование

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

ные о клиенте", а выход "подтвержденные данные о клиенте". В этом случае

и входом и выходом функции являются данные о клиенте, но слова "исход-

ные" и "подтвержденные" поясняют выполняемое преобразование данных.

Определение Механизма

Под механизмом понимаются люди, машины, механизмы, компьютеры,

приспособления и т.д. являющиеся материальными ресурсами для выполне-

ния функции.

Институт инноватики 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.

Необходимо отметить, что декомпозируемый блок, несмотря на иерар-

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

расположенных на диаграмме декомпозиции. Диаграмма декомпозиции про-

сто показывает, как работает родительский блок.

Институт инноватики http://ii.spb.ru/

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

Правила построения диаграмм обеспечивают следующие возможности,

необходимые методологии системного анализа:

– Использование универсальной синтаксической единицы (IDEF0-

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

тельные средства.

– Ограничение сложности диаграммы обеспечивается ограничением ко-

личества блоков на ней. Рекомендуемое число блоков от 3 до 6.

– Взаимное положение блоков на диаграмме позволяет подчеркнуть

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

доминированием блоков. Блок, расположенный в левом верхнем углу диа-

граммы, является наиболее доминантным, в правом нижнем – наименее. Бо-

лее доминантный блок накладывает ограничения на выполнение менее доми-

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

одним из входов (вход, управление, механизм) для менее доминантного бло-

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

во времени (менее доминантная выполняется после более доминантной, т.к.

только в этом случае для нее сформирована вся входная информация), так и

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

– При разработке диаграммы обязательно учитываются и корректируют-

ся параметры декомпозируемого блока. Это позволяет более четко изложить

задачи и функции блока в диаграмме верхнего уровня. В то же время достига-

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

– Все функции на диаграмме должны иметь приблизительно одинако-

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

ставление о декомпозируемом блоке.

Стратегии декомпозиции

Качество разработанной модели зависит от подхода, принятого аналити-

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

используемые стратегии. Для каждой системы в зависимости от цели модели

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

комбинировать их.

1. Функциональная декомпозиция заставляет обдумывать, что делает сис-

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

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

вариант работы SADT-аналитика. Поэтому самой важной на диаграмме являет-

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

2. Декомпозиция в соответствии с функциями, которые выполняют эле-

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

ляет собрать информацию о системе, чтобы потом перейти к более обосно-

ванной декомпозиции. Рекомендуется применять при описании документо-

оборота по системе P3: People, Paper, Procedures.

Институт инноватики http://ii.spb.ru/

3. Декомпозиция на уже известные стабильные подсистемы.

4. Декомпозиция, основанная на отслеживании жизненного цикла систе-

мы по переработке (продвижению) объекта, представляющая собой этапы

превращения (модификации) исходного продукта (например, заготовки) в

результат.

5. Если ничто другое не подходит, то необходимо простое описание фи-

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

на для описания уже существующих систем для последующего более глубо-

кого описания. При таком подходе плохо прослеживаются взаимосвязи и кон-

тур управления. При всех своих недостатках этот подход можно использовать

как первый шаг к созданию более представительной модели.

Алгоритм анализа системы

Сбор информации о системе. Выбор цели и точки зрения

Это основополагающие параметры модели. Цель выбирается на основе

списка вопросов, на которые модель должна ответить. Точка зрения пред-

ставляет позицию, с которой описывается система.

Создание диаграммы A-0 и диаграммы декомпозиции A0

1. Составление списка данных. Это список объектов, имеющих значение

на данном уровне декомпозиции. Функциональная декомпозиция более эф-

фективна, если начинается с составления списка данных.

2. Составление списка функций. Это список функций, которые опериру-

ют с данными из предыдущего списка. Несколько функций могут иметь одни

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

различных типов данных.

3. Построение диаграммы:

– расположить блоки на странице (с учетом доминирования),

– нарисовать основные дуги, представляющие ограничения,

– нарисовать внешние интерфейсные дуги,

– нарисовать все оставшиеся дуги.

Создание диаграммы A-0

Обобщение диаграммы A0 приводит к получению верхней диаграммы

модели A-0. Эта операция очень важна, так как позволяет проверить адекват-

но ли название модели тому, что делает система, убедиться в полноте внеш-

них интерфейсов системы (дуг),выполнить окончательное утверждение цели

и точки зрения модели. Создание диаграммы A-0 заключается в изображении

блока A0 и записи цели и точки зрения под этим блоком.

Дальнейшая декомпозиция (декомпозиция ограниченных объектов)

Диаграмма первого уровня декомпозиции A0, а также все последующие

диаграммы декомпозиции, предоставляют интерфейсные ограничения (кон-

текст) для дочерних диаграмм. Кроме того, модель уже обладает целью и

Институт инноватики http://ii.spb.ru/

точкой зрения. Это делает процесс дальнейшего проектирования более фор-

мализованным и требуемая степень детализации достигается выполнением

следующего рекурсивного процесса:

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

самого содержательного блока с точки зрения доминирования, функциональ-

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

Лучшим для начала декомпозиции не обязательно будет самый сложный для

понимания блок.

2. Рассмотрение объекта, определенного этим блоком.

3. Создание новой диаграммы (по алгоритму, подобному построению

диаграммы A0).

4. Выявление недостатков новой диаграммы.

5. Создание альтернативных декомпозиций.

6. Корректировка новой диаграммы.

7. Корректировка всех связанных с ней диаграмм.

Когда останавливать декомпозицию

Цель моделирования содержит список вопросов, на которые должна от-

вечать модель. Когда мы можем по диаграммам, составляющим модель, най-

ти ответы на эти вопросы, цель моделирования считается достигнутой и ра-

боту по созданию модели можно прекращать.

Если же цель моделирования еще не достигнута, то необходимо выпол-

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

необходимые вопросы. При этом необходимо строго соблюдать границы мо-

дели, заложенные в контекстной диаграмме, и диаграммы декомпозиции

первого уровня A0. При необходимости описание функций нижнего уровня

можно проводить с использованием других методологий: IDEF3 или DFD,

предназначенных для детального описания процессов.

1.5. Программный комплекс PROJECT EXPERT

Одной из первых и вместе с тем несомненно удачной отечественной

разработкой в области программных комплексов, ориентированных на

управление проектами, явился созданный фирмой "Про-Инвест Колсалтинг"

пакет Project Expert.

Доступная в настоящее время пятая версия пакета поддерживает всю

цепочку реализации проекта и обеспечивает решение большинства задач,

возникающих при управлении проектом на этапах от замысла и планирова-

ния до реализации.

При помощи Project Expert менеджер проекта может:

– провести обобщенный анализ бизнес-идеи;

Институт инноватики 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, техноло-

гий, стал более удобным интерфейс программы.

Институт инноватики http://ii.spb.ru/

Блок анализа

Анализ чувствительности

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

участникам

Расчет стандартных финансовых коэффициентов и показателей

эффективности

Анализ ва

иантов п

оекта

Блок группирования проектов

Суммарный отчет о движении денежных средств группы проектов

Вариантный анализ

Анализ эффективности группы проектов

Блок контроля реализации проекта

Ввод актуальных данных о развитии проекта

Актуализация данных Cash Flow

Генерация детальных отчетов рассогласования фактических и

планируемых данных (инвестиционного плана, плана продаж, плана

производства и т.п.)

Генерация отчета рассогласования Cash Flow

Блок моделирования

Моделирование окружающей среды и внешних условий функциони-

рования предприятия (налоги, инфляция, схема бух. учета и т.п.)

Моделирование денежных потоков, посредством описания бизнес-

операций.

Блок генерации финансовых документов

Отчет о прибылях и убытках (О финансовых результатах)

Отчет о движении денежных средств (Cash Flow)

Бухгалтерский баланс

Отчет об использовании прибыли

Генератор отчетов

Формирование описательной части бизнес-плана

Формирование стандартных отчетных таблиц

Построение графиков и диаграмм

Печать отчетных документов

Рис. 17. Функциональная структура пакета Project Expert

Институт инноватики http://ii.spb.ru/

Построение модели

Определение потребности в

финансировании

Разработка стратегии

финансирования

Анализ финансовых

результатов

Формирование и печать

отчета

Анализ данных о текущем

состоянии проекта

Рис. 18. Процесс использования Project Expert

Microsoft Project (MS Project) позволяет эффективно управлять проектом

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

туризацию проекта путем разделения его на этапы, задачи и подзадачи, вы-

явить критические задачи (задачи, длительность которых существенно влия-

ет на длительность реализации всего проекта), получить сетевой график и ка-

лендарный план проекта, осуществить назначение ресурсов задачам проекта,

эффективно контролировать загрузку ресурсов. Пакет поддерживает все не-

обходимые типы связей между задачами: FS (Finish-Start), SS (Start-Start),

FF(Finish-Finish).

Поддерживая современные информационные технологии, пакет MS Pro-

ject позволяет импортировать данные из файлов, созданных в среде других

приложений, например MS Excel и MS Access. Неоспоримым достоинством

пакета является наличие встроенного языка программирования Visual Basic