2015-04-06
1461
План управления расписанием определяет, как будут осуществляться контроль и управление расписанием проекта.
Базовый план расписания является составляющей плана управления проектом и основой для измерения исполнения расписания и отчетности по ней в рамках базового плана исполнения.
Отчеты об исполнении задач дают информацию об исполнении расписания.
Одобренные запросы на изменение используются для обновления базового плана расписания и прочих компонентов плана.
Управление расписанием выполняют с использованием следующих инструментов и методов:
– Отчетность о прогрессе проекта включает в себя фактические даты начала и завершения и оставшуюся длительность незавершенных плановых операций. При использовании методики освоенного объема отчетность может содержать процент выполнения текущих плановых операций. Для упрощения подготовки периодической отчетности о прогрессе проекта удобно использовать типовые формы – шаблоны
– Система управления изменениями расписания должна быть согласована с процедурами интегрированного управления изменениями проекта и определяет порядок изменения расписания проекта; включает в себя работу с документами, системы отслеживания и уровни авторизации, необходимые для авторизации изменений; является частью процесса общего управления изменениями.
– Измерение эффективности. Методы измерения эффективности выдают отклонение по срокам и индекс выполнения сроков, используемые для оценки величины любых возникающих отклонений от расписания.
– Анализ отклонений. Ключевой функцией управления расписанием является проведение анализа отклонений по срокам. Сравнение директивных дат начала и выполнения с фактическими/прогнозируемыми дает информацию для осуществления корректирующих действий в случае задержки.
– Сравнительные диаграммы расписания. Для упрощения анализа исполнения расписания удобно пользоваться сравнительной столбиковой диаграммой, имеющей по два столбика для каждой плановой операции - текущее состояние и состояние одобренного базового плана расписания. На диаграмме наглядно отображаются места, где расписание обгоняет плановое и где отстает от него.
– Линия исполнения показывает, на какое количество времени каждая операция проекта опережает базовое расписание или отстает от него.
44. Процессы управления ресурсами проекта.
Управление ресурсами – одна из главных подсистем управления проектом. Включает процессы планирования, закупок, поставок, распределения, учета и контроля ресурсов, обычно трудовых и материально-технических. Управление финансовыми ресурсами осуществляется в рамках управления стоимостью.
В принципе понятие ресурс в методологии управления проектами трактуется широко: все, чем располагает проект, — в том числе трудовые, финансовые и материально-технические ресурсы, команда проекта, время, информация, знания и технологии — является взаимосвязанными ресурсами проекта. Основная задача управления ресурсами — обеспечить их оптимальное использование для достижения конечной цели управления проектом — формирования результата проекта с запланированными показателями.
В проектах рассматриваются две взаимосвязанные группы ресурсов:
– материально-технические. Сырье, материалы, конструкции, комплектующие; энергетические ресурсы. топливо; ресурсы типа «мощности» или технологические ресурсы; устанавливаемое оборудования и пр.;
– трудовые — осуществляют непосредственную работу с материально-техническими ресурсами.
Невоспроизводимые, складируемые, накапливаемые — в процессе выполнения работ расходуются полностью, не допуская повторного использования. Не задействованные в данный отрезок времени, они могут использоваться в дальнейшем. Воспроизводимые, нескладируемые, ненакапливаемые — в ходе работы сохраняют свою натурально-вещественную форму и, по мере высвобождения, могут задействоваться на других работах. Если эти ресурсы простаивают, то их неиспользованная способность к функционированию в данный отрезок времени не компенсируется в будущем, т. е. они не накапливаются. Поэтому ресурсы второго типа называют еще ресурсами типа «мощности».
Понятие ресурсов взаимосвязано с понятием «работа», поскольку ресурсы соотносятся не с проектом в целом, а с определенными работами, выполняемыми в запланированной последовательности, соответствующей календарному плану работ по проекту.
В рамках календарного планирования работ по проекту описываются потребности в ресурсах по работам в виде функции потребности. Потребность работы в складируемом ресурсе описывается функцией интенсивности затрат, показывающей скорость потребления ресурса в зависимости от фазы работы, либо функцией затрат, показывающей суммарный, накопленный объем требуемого ресурса в зависимости от фазы.
Управление ресурсами предусматривает ряд основных процессов, в т. ч. закупки, поставки, распределение ресурсов и управление запасами ресурсов.
Закупки ресурсов — центральный элемент системы управления ресурсами. Приведем основные понятия. Под закупками понимают мероприятия, направленные на обеспечение проектов ресурсами — т. е. имуществом (товарами), выполнением работ, передачей результатов интеллектуального творчества в связи с конкретным проектом. Закупки и поставки взаимосвязаны и, по сути, являются двумя сторонами процессов материально-технического обеспечения проекта.
На стадии планирования в рамках процесса управления человеческими ресурсами не предусматривается долгосрочное планирование, а составляется план для реализации первого этапа проекта. Основными задачами являются разработка организационной структуры проекта и подбор персонала.
Работа по планированию организационной структуры проводится менеджером проекта со стороны исполнителя совместно с менеджером со стороны заказчика. Путем переговоров достигается соглашение об уровне, на котором должно производиться утверждение выделяемых ресурсов заказчика и обсуждение требований к членам команды исполнителя. Администратор проекта фиксирует результаты переговоров.
Иерархические организационные диаграммы являются простым и наглядным инструментом для определения иерархии подотчетности, начиная с нижнего уровня организации до руководителя проекта.
45. Управление рисками.
Риск проекта - это кумулятивный эффект вероятностей наступления неопределенных событий, способных оказать отрицательное или положительное влияние на цели проекта. Риски подразделяются на известные и неизвестные. Известные риски идентифицируются и подлежат управлению - создаются планы реагирования на риски и резервы на возможные потери. Неизвестные риски нельзя определить, и следовательно, невозможно спланировать действия по реагированию на такой риск.
Событие риска - потенциально возможное событие, которое может нанести ущерб или принести выгоды проекту.
Вероятность возникновения риска - вероятность того, что событие риска наступит. Все риски имеют вероятность больше нуля и меньше 100%. Риск с вероятностью 0 не может произойти и не считается риском. Риск с вероятностью 100% также не является риском, поскольку это достоверное событие, которое должно быть предусмотрено планом проекта.
Последствия риска, если он случится, выражаются через дни расписания, трудозатраты, деньги и определяют степень воздействия на цели проекта.
Величина риска - показатель, объединяющий вероятность возникновения риска и его последствия. Величина риска рассчитывается путем умножения вероятности возникновения риска на соответствующие после действия.
Резерв для непредвиденных обстоятельств (или резерв для покрытия неопределенности) - сумма денег или промежуток времени, которые необходимы сверх расчетных величин для снижения риска перерасхода, связанного с достижением целей проекта, до приемлемого для организации уровня; обычно включаются в базовый план стоимости или расписания проекта.
Управленческий резерв - сумма денег или промежуток времени, не включаемые в базовый план стоимости или расписания проекта и используемый руководством для предотвращения негативных последствий ситуаций, которые невозможно спрогнозировать.
Планирование реагирования на риски включает разработку плана управления рисками - документа, разрабатываемого в начале проекта и представляющего собой график работы с рисками в течение всего ЖЦ проекта. План содержит следующую информацию.
Методология - определяет и описывает подходы, инструменты и источники данных, используемые для работы с рисками.
Роли и обязанности - раздел содержит описание, кто какую работу выполняет в ходе управления рисками проекта.
Бюджетирование - определяет бюджет для управления рисками проекта.
Временные рамки - устанавливают частоту процессов управления рисками.
Инструменты - раздел определяет, какие методы количественного и качественного анализа рисков рекомендуется применять и в каких случаях.
Контроль - раздел, определяющий формат плана реагирования на риски.
Отчетность - определяет способы документирования результатов действий по управлению рисками и сохранение информации в базе знаний для накопления опыта и извлечения уроков.
Примером методологии является дисциплина управления рисками MSF (Microsoft Solutions Framework). MSF описывает процесс непрерывного выявления и оценки рисков, их приоритизации и реализации стратегий по превентивному управлению рисками на протяжении всех фаз жизненного цикла проекта.
46. Анализ проектных рисков.
Оценку рисков рекомендуется начинать на стадии планирования проекта, поскольку в этот момент проектная группа и заинтересованные стороны начинают формировать видение проекта, его границ и рамок. С появлением каждого нового ограничения или допущения, связанного с проектом, начинает появляться все большее число рисков. Проектная группа должна инициировать мероприятия по обнаружению рисков как можно раньше. По результатам шагов анализа и планирования рисков необходимые планы по предотвращению и смягчению последствий должны быть сразу включены в календарный график проекта и его сводный план. Ход выполнения этих планов должен подвергаться мониторингу в рамках стандартного процесса управления проектом.
На этапе планирования в соответствии с принятой политикой и процедурами в процессе управления рисками организация должна осуществлять следующие действия:
– утвердить систематический подход к определению рисков, их оценке и обработке.
Системный подход предполагает введение классификации рисков, определение событий, влияющих на ход проекта и его результаты, определение способа выражения рисков. В отношении качества, затрат, сроков или технических характеристик определяют способ выражения рисков в соответствующих терминах, включая показатели там, где это возможно;
– идентифицировать риски.
Для идентификации рисков используют следующие методы.
Мозговой штурм. Целью мозгового штурма является создание подробного списка рисков проекта. Список рисков разрабатывается на собрании, в котором принимает участие 10-15 человек - члены команды проекта, часто совместно с участием экспертов из разных областей, не являющихся членами команды. Участники собрания называют риски, которые считают важными для проекта, при этом не допускается обсуждение выдвинутых рисков. Далее риски сортируют по категориям и уточняют.
Метод Дельфи аналогичен методу мозгового штурма, но его участники не знают друг друга. Ведущий с помощью списка вопросов для получения идей, касающихся рисков проекта, собирает ответы экспертов. Далее ответы экспертов анализируются, распределяются по категориям и возвращаются экспертам для дальнейших комментариев. Консенсус и список рисков получается через несколько циклов этого процесса. В методе Дельфи исключается давление со стороны коллег и боязнь неловкого положения при высказывании идеи.
Метод номинальных групп позволяет идентифицировать и расположить риски в порядке их важности. Данный метод предполагает формирование группы из 7-10 экспертов. Каждый участник индивидуально и без обсуждений перечисляет видимые им риски проекта. Далее происходит совместное обсуждение всех выделенных рисков и повторное индивидуальное составление списка рисков в порядке их важности.
Карточки Кроуфорда. Обычно собирается группа из 7-10 экспертов. Ведущий сообщает, что задаст группе 10 вопросов, на каждый из которых участник письменно, на отдельном листе бумаги, должен дать ответ. Вопрос о том, какой из рисков является наиболее важным для проекта, ведущий задает несколько раз. Каждый участник вынужден обдумать десять различных рисков проекта.
Опросы экспертов с большим опытом работы над проектами.
Идентификация основной причины. Цель этого процесса: выявить наиболее существенные причины возникновения рисковпроекта и сгруппировать риски по причинам, их вызывающим.
Анализ сильных и слабых сторон, возможностей и угроз (анализ SWOT). Цель проведения анализа - оценить потенциал и окружение проекта. Потенциал проекта, выраженный в виде его сильных и слабых сторон, позволяет оценить разрыв между содержанием проекта и возможностями его выполнения. Оценка окружения проекта показывает, какие благоприятные возможности предоставляет и какими опасностями угрожает внешняя среда.
Анализ контрольных списков. Контрольные списки представляют собой перечни рисков, составленные на основе информации и знаний, которые были накоплены в ходе исполнения прежних аналогичных проектов.
Метод аналогии. Для идентификации рисков этот метод использует накопленные знания и планы по управлению рисками других аналогичных проектов.
Методы с использованием диаграмм. К методам отображения рисков в виде диаграмм относятся диаграммы причинно-следственных связей и блок-схемы процессов, которые позволяют проследить последовательность событий, происходящих в данном процессе.
| Таблица 5.6. Сравнение методов идентификации рисков | ||
| Метод идентификации | Преимущества | Недостатки |
| Мозговой штурм | Способствует взаимодействию членов группы. Быстрый. Недорогой | Может проявиться преобладание одной личности. Можно сосредоточиваться только в конкретных областях. Требует сильного ведущего. Для оценки необходимо контролировать склонности группы |
| Метод Delphi | Нет доминирования одной личности. Может проводиться дистанционно, через электронную почту. Исключается проблема ранней оценки. Требует участия каждого члена группы | Занимает много времени. Высокая загрузка ведущего |
| Метод номинальных групп | Уменьшается эффект доминирующей личности. Обеспечивает взаимодействие участников. Дает упорядоченный список рисков | Требует много времени. Высокая загрузка ведущего |
| Карточки Кроуфорда | Быстрый. Легко реализуется. Должен участвовать каждый член группы. Вырабатывается большое количество идей. Можно проводить с группами большеобычного размера. Уменьшает эффект доминирующей личности | Меньшее взаимодействие между участниками |
| Опрос экспертов | Используется прошлый опыт | Эксперт может быть предвзятым. Требует много времени |
| Контрольные списки | Конкретный и упорядоченный. Легко использовать | Предвзятость. Может не содержать конкретных элементов для данного проекта |
| Метод аналогии | Использует прошлый опыт для исключения проблем в будущем. Подобные проекты содержат много сходных черт | Требует много времени. Легко получить результаты, не подходящие для данного случая. Аналогия может быть некорректной |
| Методы с использованием диаграмм | Ясное представление участвующих процессов. Легкость построения. Для них имеется много компьютерных инструментов | Иногда вводит в заблуждение. Может занимать много времени |
Идентифицированные риски документируются в так называемых реестрах рисков.
47. Методы снижения рисков.
Все методы, позволяющие минимизировать проектные риски можно разделить на следующие три группы.
Диверсификация, или распределение рисков, позволяющая распределить риски между участниками проекта. Распределение проектным рисков между его участниками является эффективным способом его снижения. Теория надежности показывает, что с увеличением количества параллельных звеньев в системе вероятность отказа в ней снижается пропорционально количеству таких звеньев. Поэтому распределение рисков между участниками повышает надежность достижения результата. Логичнее всего при этом сделать ответственным за конкретный вид риска того из его участников, который обладает возможностью точнее и качественнее рассчитывать и контролировать данный риск. Распределение рисков оформляется при разработке финансового плана проекта и контрактных документов.
Резервирование средств на покрытие непредвиденных расходов представляет собой способ борьбы с риском, предусматривающий установление соотношения между потенциальными рисками, влияющими на стоимость проекта, и размером расходов, необходимых для преодоления сбоев в выполнении проекта.
В случае если участники проекта не в состоянии обеспечить реализацию проекта при наступлении того или иного рискового события собственными силами, необходимо осуществить страхование рисков. Страхование рисков есть, по существу, передача определенных рисков страховой компании.
Эффективность методов снижения рисков определяется с помощью следующего алгоритма:
рассматривается риск, имеющий наибольшую важность для проекта;
определяется перерасход средств с учетом вероятности наступления неблагоприятного события;
определяется перечень возможных мероприятий, направленных на уменьшение вероятности и опасности рискового события;
определяются дополнительные затраты на реализацию предложенных мероприятий;
сравниваются требуемые затраты на реализацию предложенных мероприятий с возможным перерасходом средств вследствие наступления рискового события;
принимается решение об осуществлении или об отказе от противорисковых мероприятий;
процесс сопоставления вероятности и последствий рисковых событий с затратами на мероприятия по их снижению повторяется для следующего по важности риска.
48. Организация работ по управлению рисками.
Согласно стандарту ISO 15288, процесс контроля включает следующие действия:
- сообщение о мерах по обработке рисков и их статусе в соответствии с действующими соглашениями, политикой и процедурами;
- ведение учета рисков в течение всего жизненного цикла.
Учет включает определение текущего понимания рисков и отношения к мерам и ресурсам, связанным с реакцией на риски. Такой учет позволяет отслеживать историю рисков, что помогает при принятии решений и может оказаться примером для проектирования будущих систем.
Для обеспечения контроля и управления рисками на этапе планирования разрабатывают план реагирования на риски.
План реагирования на риски оценивает риски, определяет действия по увеличению числа благоприятных возможностей и сокращает вероятность влияния на проект отрицательных воздействий, обеспечивает готовность к возможным неблагоприятным воздействиям.
План реагирования на риски помогает детально проанализировать множество неопределенностей и обратить особое внимание на области проекта, имеющие наивысшие значения рисков, а также изыскать эффективные способы снижения рисков. Использование плана предоставляет возможность интеграции рисков непосредственно в процессе планирования и исполнения проекта и обеспечивает лучшее понимание целей проекта, содержания и хода исполнения. План также содержит информацию, необходимую для обоснования планирования действий в непредвиденных ситуациях, раннего предупреждения рисков и более реалистичного подхода к исполнению проекта.
На стадии ЖЦ ИС наиболее вероятно возникновение рисков, вызванных следующими обстоятельствами:
– неправильно определена область применения проекта;
– не определен спонсор проекта;
– не разработана стратегия реагирования на риски;
– не определены ожидания участников проекта;
– не установлена ответственность за обеспечение проекта материальными и финансовыми ресурсами.
Для смягчения последствий от рисков, вызванных вышеперечисленными причинами, рекомендуется в уставе проекта и определении проекта четко определять цели и результаты проекта, основные допущения и предположения, как со стороны заказчика, так и со стороны исполнителя, документально закреплять полномочия и ответственности между участниками проекта. Также необходимо определить степень участия в организации выполнения проекта заказчика, спонсора проекта и лиц, принимающих решение со стороны заказчика, и согласовать и документировать процедуры управления рисками проекта. Исполнителем должен быть выполнен анализ рисков, идентифицированных на стадии подготовки ТЭО проекта, с целью обеспечения резервных средств при планировании проекта и разработке мер по смягчению воздействий от возникновения рисков. Для снижения рисков проекта на ранней стадии планирования необходимо включить в план по материальным ресурсам необходимые требования к инфраструктуре проекта и согласовать с заказчиком области инфраструктуры, за которые он несет ответственность.
Процессы управления проектом группируются по их направленности, например, процессы, связанные со сроками, включаются в одну группу. Практически во всех проектах присутствуют группы процессов установления целей проекта, управления взаимосвязями процессов в проекте, сроками, затратами, ресурсами, кадрами, информационными потоками, менеджментом рисков. Структура всех процессов проекта связана с конфигурацией ИС таким образом, чтобы в любой момент осуществления проекта была возможность реализовать требования, предъявляемые к ИС на различных стадиях ее жизненного цикла. Она определяет отношения между видами деятельности, непосредственно касающимися процессов проекта и характеристиками создаваемой ИС. ИС на каждом этапе ее построения обладает определенной базовой для данного этапа конфигурацией. Соответственно, и процессы проекта должны быть выстроены таким образом, чтобы в результате их осуществления была достигнута именно эта конфигурация.
Управление конфигурацией ИС и процессами проекта позволяет координировать управление перечисленными видами деятельности, исходя из тех изменений, которые постоянно возникают в ходе реализации проекта.
Очевидно, что чем сложнее проект, тем сильнее проявляется взаимосвязь проектных рисков и, следовательно, тем более формализованным должно быть управление проектами для адекватного снижения этих рисков. В крупных проектах работы обладают высокой связностью, поэтому любые изменения в одном процессе так или иначе влияют на другие процессы проекта.
49. Управление коммуникациями проекта.
Управление коммуникациями проекта — управленческая функция, направленная на обеспечение своевременного сбора, генерации, распределения и сохранения необходимой проектной информации.
Под информацией понимают собранные, обработанные и распределенные данные. Чтобы быть полезной для принятия решений, информация должна быть предоставлена своевременно, по назначению и в удобной форме.
Для того чтобы проектные коммуникации наиболее эффективно решали задачи, стоящие перед проектом, еще на фазе планирования проекта необходимо четко сформулировать стратегию коммуникаций. Наиболее важным элементом планирования коммуникаций является идентификация получателей информации, далее следует озаботиться планированием содержания информационных сообщений, которое может значительно меняться в зависимости от адресата. Затем происходит выбор канала коммуникации и определение отправителя. За фактическим выполнением коммуникаций необходимо всегда осуществлять обратную связь, позволяющую корректировать действия в дальнейшем.
Относительно содержания любое сообщение на проекте должно включать в себя информацию следующего рода.
1. Удовлетворение потребности участников проекта понимать Участники проекта должны иметь возможность получить объективную, полную и непротиворечивую информацию о целях и задачах проекта и иметь возможность сформировать собственное рациональное мнение о проекте.
2. Удовлетворение потребности участников проекта чувствовать Заинтересованные стороны должны четко понимать, какие процедуры предусмотрены для организации их участия в принятии решений по проекту, есть ли каналы обратной связи, как они могут быть вовлечены в реализацию наиболее значимой для них части проекта.
3. Удовлетворение потребности участников проекта действовать Сотрудники должны быть проинформированы, какие средства,
методы, инструменты предусмотрены для их скорейшей адаптации в условиях новой организационно-функциональной среды бизнеса организации.
Каналы коммуникаций образуют 3 группы: формальные, специфичные для проекта и неформальные.
50. Информационные технологии и системы управления проектами.
Под информационной технологией понимают совокупность процессов сбора, передачи, переработки, хранения и доведения до потребителя.
Персональные компьютерные системы, оснащенные программным обеспечением для управления проектами, должны обеспечивать выполнение функций:
– работа в многопроектной среде;
– разработка календаря сетевого графика выполнения работ;
– оптимизация распределения и учет ограниченных ресурсов;
– проведение анализа «что-если»;
– сбор и учет фактической информации о сроках, ресурсах и затратах, автоматизированной генерации отчетов;
– планирование и контроль договорных обязательств;
– централизованное хранение информации по реализуемыми завершенным проектам и т. д.
Распределенные интегрированные системы в качестве основных инструментов используют: архитектуру клиент — сервер. Она позволяет рабочим станциям и одному или нескольким центральным ПК распределять выполнение приложений, используя вычислительную мощность каждого компьютера. Большинство систем клиент—сервер используют базы данных (БД) и системы управления базами данных (СУБД). Для успешного управления проектом необходимо, чтобы данные, полученные во время планирования и выполнения проекта, были всегда доступны всем участникам проекта.
Системы телекоммуникаций. Портативные компьютеры и программное обеспечение поддержки групповой работы, обеспечивают:
– обмен электронной почтой;
– документооборот;
– групповое планирование деятельности;
– участие удаленных членов команды в интерактивных дискуссиях средствами поддержки и ведения обсуждений;
– проведение «мозгового штурма», давая возможность его участникам высказывать свои мнения с помощью компьютеров, подключенных к одному большому экрану.
Целью информационной системы поддержки принятия решений является организация и управление принятием решений при разработке и реализации проектов на основе современных технологий обработки информации. Основными функциями этих систем являются:
– сбор, передача и хранение данных;
– содержательная обработка данных в процессе решения функциональных задач управления проектами;
– представление информации в форме, удобной для принятия решений;
– доведение принятых решений до исполнителей.
Интегрированная информационная система управления проектами:
– объединяет данные из различных подразделений и организаций, относящихся к конкретному проекту;
– обеспечивает хранение, сбор, и анализ управленческой информации относительно степени достижения целей проекта;
– создается для каждого проекта и является временной, так как проект представляет собой одноразовое предприятие;
– должна обеспечивать алгоритмы разрешения конфликтующих требований, возникающих по ходу обеспечения проекта;
– должна обеспечивать поддержку деловых взаимоотношений между исполнителями, временно объединенными в команду;
– является динамической системой, которая изменяется в зависимости от стадии проекта;
– является открытой системой, так как проект не является полностью независимым от бизнес-окружения и текущей деятельности предприятия.
– Основными функциональными элементами интегрированной информационной системы поддержки принятия решений на стадии выполнения проекта являются:
– модуль календарно-сетевого планирования и контроля работ проекта;
– модуль ведения бухгалтерии проекта;
– модуль финансового контроля и прогнозирования.
Важнейшим компонентом интегрированных информационных систем поддержки принятия решений являются системы управления базами данных (СУБД). Их основными функциями являются поддержка целостности, защищенности, архивации и синхронизации данных в условиях многопользовательской работы.
Существуют различные модели оценки ПО, наиболее распространенной из которых является N-бальная модель. Проведя такой сравнительный анализ различного программного обеспечения, можно принимать решение о выборе того или иного из них как по функциональным возможностям (количество набранных баллов в целом и по отдельным группам критериев), так и соотношению «цена / качество».
51. Особенности внедрения информационных систем управления проектами.
Внедрение информационной системы управления проектами включает подготовку функций управления проектами к вводу информационной системы в действие. Масштабы использования систем управления проектами в различных организациях могут существенно варьироваться. Сложность задач по внедрению зависит от масштабов организации, имеющейся структуры управления и степени автоматизации, масштабов и типа реализуемых проектов, степени вовлеченности в управление проектами внешних организаций.
Процессы управления проектами, и в частности процесс распределения ресурсов, могут иметь место в матричной структуре. Если организация консервативна в использовании традиционных структур управления, то вероятность успешного внедрения информационной системы достаточно невелика. Внедрение сложных информационных систем управления проектами требует большого количество ресурсов, необходимо знать место информационной системы в организации. Должна ли она использоваться на всех уровнях управления? Должна ли она использоваться только для высокоприоритетных проектов?
Информационная система может рассматриваться как замена живому и неформальному общению, передаче навыков и опыта внутри персонала. Она не должна ставить взамен этому жесткие каналы коммуникаций; внедрение информационной системы имеет меньше шансов на успех, если в организации нет понимания основных принципов управления проектами, либо у руководства отсутствует желание их изучать.
Внедрение системы для управления проектами в полном объеме может предусматривать использование целого ряда новых технологий. Реализация различных функций может влиять на работу разных подразделений и специалистов. Все это может привести к значительному усложнению проекта и делает проблематичным стабилизацию работы системы в целом; планирование перевода сразу всей организации на использование системы для управления проектами. Это подобно попытке связать сразу всех сотрудников крупной организации в локальную вычислительную сеть, вместо того, чтобы осуществлять подключение пользователей последовательно, отдел за отделом.
Общие рекомендации по внедрению программного обеспечения для управления проектами включают следующее: необходимо четко представлять цели и преимущества, ожидаемые от внедрения новой системы. Результаты внедрения системы должны быть согласованы со всеми, кто связан с ее внедрением или будет участвовать в ее эксплуатации; последовательное внедрение разработанных решений от «простого к сложному», от локальных целей к глобальным.
52. Влияние риска и неопределенности при оценке эффективности проекта.
Общая схема оценки эффективности Оценка эффективности проекта производится в три этапа, а первоначальным шагом является экспертная оценка общественной значимости проекта. Общественно значимыми считаются крупномасштабные, народнохозяйственные и глобальные проекты; на втором этапе рассчитываются показатели эффективности проекта в целом. Цель этого этапа — интегральная экономическая оценка проектных решений и создание необходимых условий для поиска инвестора. Для локальных проектов оценивается только их коммерческая эффективность и, если она оказывается приемлемой, рекомендуется непосредственно переходить ко второму этапу оценки. Для общественно значимых проектов оценивается в первую очередь их социально-экономическая эффективность. При неудовлетворительной оценке такие проекты не рекомендуются к реализации и не могут претендовать на государственную поддержку. Если же их социально-экономическая эффективности оказывается достаточной, оценивается их коммерческая эффективность; третий этап оценки осуществляется после выработки схемы финансирования. На этом этапе уточняется состав участников и определяются финансовая реализуемость и эффективность участия в проекте каждого из них.
Матрица вероятности и последствий содержит комбинации вероятности и воздействия, при помощи которых рискам присваивается определенный ранг: низкий, средний или высший. Матрица может содержать описательные термины или цифровые обозначения и строится на основании шкал оценки вероятности и оценки степени влияния возможного риска. Левый столбец матрицы содержит значения вероятности возникновения риска, в первой строке расположена шкала со значениями возможных последствий. Ячейки заполняются результатами перемножения значений этих шкал. Сопоставляя значение ячейки матрицы со шкалой оценки воздействия, риски можно разделить по категориям: малые, средние и большие. Рассмотрим матрицу вероятности и последствий, представленную на рис.
Риски, имеющие очень высокую вероятность, но незначительные последствия, а также риски, имеющие низкую вероятность и незначительные последствия, считаются рисками, не оказывающими воздействия (клетки таблицы серого цвета). Риски с очень большими последствиями, но малой вероятностью, как и риски с незначительными последствиями и высокой вероятностью (клетки светло-серого цвета), имеют среднее воздействие на проект. Риски, которым необходимо уделять особое внимание, имеют достаточно высокую вероятность и существенные последствия (клетки таблицы, окрашенные темно-серым цветом).
53. Процесс планирования информационных систем.
Планирование относится к наиболее важным процессам для проекта ИС, так как результатом его реализации является обычно уникальный объект или услуга. Объем и детальность планирования определяется полезностью информации, которую можно получить в результате выполнения процесса и зависит от содержания проекта.
Эти процессы могут повторяться и входить в состав итерационной процедуры, выполняемой до достижения определенного результата. Сам процесс планирования не может быть полностью алгоритмизирован и автоматизирован, так как содержит много неопределенных параметров и часто зависит от случайных факторов. Поэтому предлагаемые в результате планирования варианты плана могут отличаться, если они разрабатываются разными командами, специалисты в которых по-разному оценивают влияние на проект внешних факторов.
Основные процессы планирования ИС могут повторяться несколько раз, как в течение всего проекта, так и его отдельных фаз. К основным процессам относят:
– планирование содержания проекта и его документирование;
– писание содержания проекта, определение основных этапов реализации проекта, декомпозиция их на более мелкие и управляемые элементы;
– составление сметы, оценку стоимости ресурсов, необходимых для выполнения работ проекта;
– определение работ, формирование списка конкретных работ, которые обеспечивают достижение целей проекта;
– расстановку работ, определение документирование технологических зависимостей и ограничений на работы;
– оценку продолжительности работ, трудозатрат и других ресурсов, необходимых для выполнения отдельных работ;
– расчет расписания, анализ технологических зависимостей выполнения работ, длительностей работ и требований к ресурсам;
– планирование ресурсов, определение того, какие ресурсы потребуются для выполнения работ проекта;
– определение сроков работ (могут быть выполнены с учетом ограниченности ресурсов);
– составление бюджета, привязка сметных затрат к конкретным видам деятельности;
– создание плана проекта, сбор результатов остальных процессов планирования и их объединение в общий документ.
Вспомогательные процессы выполняются по мере необходимости.
Уровни планирования. Определение уровней планирования является также предметом планирования и проводится для конкретного проекта с учетом его специфики, масштабов, географии, сроков и т.п.
В ходе этого процесса определяется вид и число уровней планирования соответствующих выделенным пакетам работ по проекту, содержательные и временные взаимосвязи. Планы как выражение результатов процессов планирования должны образовывать в совокупности некоторую пирамидальную структуру, обладающую свойствами агрегирования информации, дифференцированной по уровням управления информированностью, эшелонироваться по срокам разработки. Уровни планирования и система планов должны строиться с использованием принципов «обратной связи», обеспечивающих постоянное сравнение плановых данных с фактическими и обладать большой гибкостью, актуальностью и эффективностью.
54. Принципы планирования фазы эксплуатации информационных систем.
Решение этой задачи включает следующие действия:
- извещение менеджмента проекта, заказчика и персонала.
Извещение менеджмента проекта, заказчика и персонала подразумевает информирование менеджеров проекта о планах высвобождения их персонала, проверке исполнения договорных обязательств, обсуждении планов высвобождения с персоналом проекта;
- подготовка оценки работы персонала.
Для выполнения оценки работы персонала используют методики и процедуры, принятые компанией;
- документирование результатов процесса управления персоналом. Все накопленные знания, приобретенные во время проекта, должны быть документированы и могут включать в себя:
o организационные диаграммы проекта, описания позиций и планы управления обеспечением проекта персоналом;
o принципы, методы урегулирования конфликтов и процедуры поощрения;
o специальные навыки и квалификацию определенных членов команды, обнаруженные в процессе исполнения проекта;
o проблемы и способы их решения, зафиксированные в журнале регистрации проблем проекта.
55. Подготовка инфраструктуры к фазе эксплуатации проекта ИС.
На фазе разработки и внедрения выполняется проверка соответствия результатов проекта требованиям проекта и завершение процесса управления конфигурации. Результатом данного этапа является обеспечение готовности управления конфигурацией заказчиком.
Для проверки соответствия выполняется аудит ключевых результатов.
В рамках аудита ключевых результатов менеджер по управлению конфигурацией демонстрирует руководителю проекта и заказчику соответствие полученных и запланированных результатов и наличие адекватного контроля результатов. Результаты данного подпроцесса в дальнейшем используются менеджером проекта при подписании заказчиком акта о приемке ключевых результатов проекта.
Менеджер по управлению конфигурацией готовит и согласовывает требования к аудиту и ключевым результатам проекта и обеспечивает проведение аудита. Администратор проекта обеспечивает подготовку отчетов о состоянии конфигурации, необходимых для проведения аудита.
Завершение процесса управления конфигурацией заключается в передаче заказчику ответственности за процесс конфигурации проекта, а также в подготовке и передачи архива с материалами проекта.
Менеджер проекта со стороны заказчика разрабатывает требования к завершению процесса управления конфигурацией, причем рекомендуется это выполнять на стадии планирования. Менеджер проекта от исполнителя согласовывает с заказчиком процедуру передачи инструментальных средств управления конфигурацией. Менеджер по управлению конфигурацией архивирует информацию по конфигурации проекта и организует процесс передачи архива.
Передача заказчику результатов процесса УК должна быть согласована с передачей результатов, связанных с разработкой и тестированием ИС. Для передачи архивных копий рекомендуется на этапе планирования разработать и согласовать с заказчиком соответствующую процедуру.
56. Осуществление итогов контроля качества проекта.
На фазе разработки и внедрения в рамках процесса управления качеством проводится работа проверки соответствия результатов этапа установленным критериям качества и стандартам.
К задачам этого этапа относится:
· проведение оценки организации контроля качества проектных работ;
· проведение аудита ключевых показателей.
Критическим фактором успеха на данной стадии является точное соответствие процедуры приемки этапа плану качества работ по проекту.
Исходной информацией являются отчеты по аудиту и комментарии к обзору качества.
57. Подготовка персонала к завершению проекта.
Методы и инструменты управления персоналом на данной фазе аналогичны ранее рассмотренным, тем не менее необходимо учитывать одну ключевую особенность - близкое завершение проекта и важность проверки готовности персонала к этому. Решение этой задачи включает следующие действия:
- извещение менеджмента проекта, заказчика и персонала.
Извещение менеджмента проекта, заказчика и персонала подразумевает информирование менеджеров проекта о планах высвобождения их персонала, проверке исполнения договорных обязательств, обсуждении планов высвобождения с персоналом проекта;
- подготовка оценки работы персонала.
Для выполнения оценки работы персонала используют методики и процедуры, принятые компанией;
- документирование результатов процесса управления персоналом. Все накопленные знания, приобретенные во время проекта, должны быть документированы и могут включать в себя:
o организационные диаграммы проекта, описания позиций и планы управления обеспечением проекта персоналом;
o принципы, методы урегулирования конфликтов и процедуры поощрения;
o специальные навыки и квалификацию определенных членов команды, обнаруженные в процессе исполнения проекта;
o проблемы и способы их решения, зафиксированные в журнале регистрации проблем проекта.
58. Реализация цикла тестирования.
59. Тестирование процессов, документов и отчетов.
На данной стадии ключевым процессом управления качеством является тестирование, однако оно должно сопровождаться рядом подготовительных действий, а также мерами по оценке критериев качества процессов, запланированных на предыдущей стадии.
– Оценка выполняется по ранее разработанным процедурам, на основании контрольных списков для проверки управления проектом и отчетности.
– Настройка рабочей среды.
– Настройка конфигурации (для системного тестирования).
– Настройка инфраструктуры, тестирование системы.
– Выполнение системного и пользовательского теста.
– Установка рабочей среды.
– Выполнение теста на запуск.
Процесс тестирования как таковой призван оценить степень соответствия функциональных характеристик реализованного решения первоначальным требованиям и обеспечить безболезненный перенос результатов проекта в операционную деятельность.
Основной целью выполнения тестирования является проверка того, что внедренные технологии и организационное обеспечение поддерживают новые способы работы компании. Ключевым объектом процесса тестирования служат тестовые сценарии, суть пошаговые инструкции для тестеров. Очевидно, что полный набор тестовых сценариев проекта должен охватывать как можно большее число возможных ситуаций (Гал-лопен).
Для обеспечения комплексной проверки функционирования внедренной системы необходимо реализовать цикл тестирования, состоящий из следующих упорядоченных этапов.
1. Функциональное тестирование
Выполнение этого вида тестирования производится сразу после настройки соответствующей функциональности и заканчивается, когда каждая часть настройки функционирует в соответствии с задокументированными требованиями.
2. Первое интеграционное тестирование
На этом этапе тестирования спроектированный прототип системы впервые проверяется целиком. Наивысший приоритет имеют работы по исправлению выявленных ошибок: одни ошибки могут блокировать прохождение сценария и идентифицировать другие ошибки. По окончании первого интеграционного тестирования производится оценка выполнимости перехода в продуктивную эксплуатацию результатов проекта.
3. Второе интеграционное тестирование
Оно выполняется после устранения всех ранее выявленных проблем и ошибок. В завершение этой фазы необходимо проверить, было ли запущено приемочное тестирование конечными пользователями. В то же время имеет смысл задержать приемочные тесты, если есть основания полагать, что качество системы не соответствует изначально установленным требованиям. Практика показывает: обнаружение большего числа ошибок в течение циклов приемочных испытанийзначительно снижает вероятность принятия системы заказчиком [5].
4. Первое пользовательское тестирование
Этому этапу цикла тестирования предшествует устранение ранее выявленных ошибок, обеспечение доступа пользователей к среде тестирования, объяснение тестерам всех процедур. Для обеспечения оперативного решения проблем и непрерывного отслеживания хода тестирования стоит организовать данное тестирование в одном месте. По итогам этого цикла тестирования необходимо:
– сформировать окончательное заключение о результатах;
– задокументировать все запросы на изменения;
– убедиться, что все тестовые сценарии утверждены;
– произвести окончательную оценку возможности перехода к продуктивной эксплуатации.
5. Окончательная настройка системы
На основе информации, полученной по итогам первого приемочного тестирования, а также зарегистрированных запросов на изменения, производится окончательная настройка системы и утверждение изменений. Корректная обработка этого этапа значительно упрощает процесс приемки, так как в систему были внесены изменения для обеспечения большего соответствия требованиям и уже имеющейся практике.
6. Второе пользовательское приемочное тестирование.
Это заключительный раунд тестирования: все тестовые сценарии, которые еще не были пройдены, должны быть пройдены и подтверждены. По успешном завершении этого цикла должен быть утвержден переход к продуктивной эксплуатации.
60. Моделирование жизненного цикла информационных систем.
Жизненный цикл (ЖЦ) информационной системы – это множество событий, происходящих с системой в процессе ее создания и использования.
Очевидно не все события, происходящие «в жизни» ИС подлежат планированию и управлению (это невозможно, да и не нужно). Поэтому с точки зрения проектирования ИС имеет смысл говорить о модели жизненного цикла.
Модель жизненного цикла ИС – это модель создания и использования ИС, отражающая ее различные состояния, начиная с момента возникновения необходимости в данном комплексе средств и заканчивая моментом его полного выхода из употребления у пользователей.
Модель жизненного цикла и технология проектирования
Ранее мы говорили, что технология проектирования задает последовательность действий, необходимых для получения проекта ИС. Очевидно, что выполнение каждого из таких действий означает переход информационно системы из одного состояния в другое. Таким образом, всякая технология проектирования однозначно описывает некоторую модель жизненного цикла. С другой стороны, построив модель жизненного цикла информационной системы, то есть определив:
– задачи, состав и последовательность выполняемых работ;
– получаемые результаты каждого выполняемого действия;
– методы и средства, необходимые для выполнения работ;
– роли и ответственность участников;
– иную информацию, необходимую для планирования, организации и управления коллективной разработкой ИС,
мы получим однозначное описание выбранной нами технологии проектирования. Таким образом, модель жизненного цикла – это неотъемлемая и важнейшая часть технологии проектирования информационных систем.
Этапы и стадии проектирования
Часто смешивают понятия «этап» и «стадия» проектирования. Иногда говорят об этапах или фазах жизненного цикла, шагах проектирования. Возникает вопрос: как правильно?
Следует помнить, что в разных международных стандартах используемая терминология может отличаться. Мы будем, по возможности, ориентироваться на терминологию отечественных ГОСТов. Этапом проектирования будем называть часть процесса создания ИС, ограниченную некоторыми временными рамками и заканчивающуюся выпуском конкретного продукта (модели, документации, текста программы и т. п.). По общности целей этапы проектирования могут объединяться в стадии. Например, стадия «Технический проект», стадия «Внедрение» и т.п.
Не зависимо от выбранного подхода, модель жизненного цикла ИС состоит из следующих стадий:
· Формирование требований к системе (предпроектная стадия, стадия системного анализа). В рамках данной стадии проводится исследование и анализ деятельности автоматизируемого объекта; значение имеют, разумеется, только те процессы, которые соответствуют целям и задачам этого объекта. В результате получается модель объекта, которую обычно описывают в терминах бизнес-процессов и бизнес-функций. Параллельно с этим выявляются недостатки существующих информационных систем (вспоминаем принцип преемственности) и формулируются потребности в совершенствовании системы управления объектом и/или автоматизации его отдельных функций. Требования должны быть экономически обоснованными. Результатом выполнения описанных этапов стадии является оформление технико-экономического обоснования (ТЭО) и технического задания (ТЗ) на разработку ИС. Обычно ТЭО оформляется как часть ТЗ. Кроме того, в ТЗ обязательно отражаются требования к ИС и ограничения на ресурсы проектирования (в первую очередь, сроки исполнения). Требования к ИС определяются как множество функций, реализуемых системой, а также описание предоставляемой ей информации.
· Проектирование (техническое проектирование, логическое проектирование). В соответствии с полученными требованиями проектировщики разрабатывают функциональную архитектуру ИС, которая отражает структуру выполняемых ей функций, и системную архитектуру ИС, которая представляет собой состав обеспечивающих подсистем. Построение системной архитектуры проводится на базе описания функциональной архитектуры ИС и фактически заключается в составлении технологии обработки информации с участием всех обеспечивающих подсистем ИС (в первую очередь, информационного, технического, и программного обеспечения). Результатом выполнения стадии проектирования обычно являются: 1) концептуальная, логическая и физическая модели данных ИС; 2) спецификации модулей ИС; 3) спецификация пользовательских интерфейсов ИС; 4) множество выбранных проектных решений, определяющих архитектуру ИС – в том числе выбранная платформа ПО, количество звеньев в архитектуре (однозвенная, двухзвенная [клиент-сервер или файл-сервер], трехзвенная) и др. Итоговый документ, завершающий стадию проектирования, – технический проект (ТП).
· Реализация (рабочее проектирование, физическое проектирование, программирование). Заключается в разработке и настройке программ информационной системы и наполнении информацией соответствующих баз данных. Важным этапом реализации является составление инструкций по эксплуатации для персонала ИС. Стадия завершается оформлением рабочего проекта (РП).
· Тестирование и внедрение (опытная эксплуатация). На этой стадии производится комплексная отладка ИС, проверка на соответствие модулей системы их спецификациям (наличие всех необходимых функций, отсутствие лишних функций), проверка надежности работы (восстанавливаемость после сбоев программного и аппаратного обеспечения, наработка на отказ и т.п.), обучение персонала. Сложные информационные системы обычно требуют опытного внедрения: например, сначала ИС устанавливается в одном отделе организации, затем постепенно к автоматизации подключаются остальные подразделения. Стадия внедрения завершается подписанием акта приемо-сдаточных испытаний – который устанавливает соответствие реализованной ИС требованиям заказчика.
· Эксплуатация (сопровождение). На этой стадии обеспечивается процесс штатной эксплуатации ИС, который помимо всего прочего включает в себя сбор рекламаций (претензий) и статистики о функционировании ИС, исправление ошибок и недоработок, оформление требований к модернизации ИС.
