WWW.KNIGA.SELUK.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА - Книги, пособия, учебники, издания, публикации

 

Pages:   || 2 | 3 | 4 | 5 |   ...   | 6 |

«В.И. Грекул, Н.Л. Коровкина, Ю.В. Куприянов МЕТОДИЧЕСКИЕ ОСНОВЫ УПРАВЛЕНИЯ ИТ-ПРОЕКТАМИ Учебник Допущено Учебно-методическим объединением в области менеджмента в ...»

-- [ Страница 1 ] --

Основы информационных технологий

В.И. Грекул, Н.Л. Коровкина,

Ю.В. Куприянов

МЕТОДИЧЕСКИЕ

ОСНОВЫ УПРАВЛЕНИЯ

ИТ-ПРОЕКТАМИ

Учебник

Допущено Учебно-методическим объединением

в области менеджмента в качестве учебника

для студентов высших учебных заведений

направления подготовки «Бизнес-информатика»

Интернет-Университет БИНОМ.

Информационных Технологий Лаборатория знаний www.intuit.ru www.lbz.ru Москва 2010 УДК [004:005.8](075.8) ББК 65.386.8-211я73-1 Г80 Грекул В.И.

Г80 Методические основы управления ИТ-проектами: учебник / В.И. Грекул, Н.Л. Коровкина, Ю.В. Куприянов. — М.: ИнтернетУниверситет Информационных Технологий: БИНОМ. Лаборатория знаний, 2010. — 391 с.: ил., табл. — (Основы информационных технологий).

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

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

УДК [004:005.8](075.8) ББК 65.386.8-211я73- Полное или частичное воспроизведение или размножение каким-либо способом, в том числе и публикация в Сети, настоящего издания допускается только с письменного разрешения Интернет-Университета Информационных Технологий.

По вопросам приобретения обращаться:

«БИНОМ. Лаборатория знаний»

Телефон (499) 157-1902, (499) 157-5272, e-mail: binom@Lbz.ru, http://www.Lbz.ru © Интернет-Университет Информационных Технологий, © БИНОМ. Лаборатория ISBN 978-5-9963-0466-0 знаний, О проекте Интернет-Университет Информационных Технологий – это первое в России высшее учебное заведение, которое предоставляет возможность получить дополнительное образование во Всемирной сети. Web-сайт университета находится по адресу www.intuit.ru.

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

Обучение в университете ведется по собственным учебным планам, разработанным ведущими российскими специалистами на основе международных образовательных стандартов Computer Curricula 2001 Computer Science. Изучать учебные курсы можно самостоятельно по учебникам или на сайте Интернет-Университета, задания выполняются только на сайте.

Для обучения необходимо зарегистрироваться на сайте университета.

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

Книга, которую вы держите в руках, – очередная в многотомной серии «Основы информационных технологий», выпускаемой ИнтернетУниверситетом Информационных Технологий. В этой серии будут выпущены учебники по всем базовым областям знаний, связанным с компьютерными дисциплинами.

Добро пожаловать в Интернет-Университет Информационных Технологий!

Анатолий Шкред anatoli@shkred.ru Об авторе Грекул Владимир Иванович Кандидат технических наук, старший научный сотрудник, лауреат Государственной премии СССР в области науки и техники. Окончил Киевское высшее инженерно-авиационное военное училище ВВС по специальности «Автоматическое и приборное оборудование летательных и космических пилотируемых аппаратов». Более 30 лет работает в области создания информационных систем. Заведующий кафедрой корпоративных информационных систем Государственного университета – Высшая школа экономики. Имеет более 90 научных работ, из них 15 — учебно-методической направленности.

Коровкина Нина Леонидовна Окончила Московский институт инженеров железнодорожного транспорта по специальности «Математические и счетно-решающие приборы и устройства», квалификация по диплому – «инженер-математик».

Работала в Центральном экономико-математическом институте АН СССР, в Главном вычислительном центре Госплана СССР, с 1994 г. по настоящее время работает в Государственном университете – Высшей школе экономики в должности доцента на кафедре корпоративных информационных систем. Принимала участие в проектах, выполняемых по заказам Министерства образования Российской Федерации в рамках Федеральной целевой программы «Развитие единой образовательной среды», Министерства экономического развития и торговли в рамках ФЦП «Электронная Россия», Министерства информационных технологий и связи РФ в проекте по разработке профессиональных стандартов в области информационных технологий. Имеет 25 публикации, их них 14 – учебно-методической направленности.

Куприянов Юрий Викторович Окончил факультет бизнес-информатики Государственного университета – Высшая школа экономики. Принимал участие в ряде международных научно-прикладных проектов, реализованных совместно с европейским исследовательским центром в области ИС (ERCIS) и крупными международными компаниями (SAP, BMW, VW, GM-AvtoVAZ). Имеет опыт работы в ведущих мировых (SAP) и российских консалтинговых компаниях, где специализировался в области проектного управления и оценки эффективности внедрения информационных систем. С 2008 года работает в Государственном университете – Высшая школа экономики, является аспирантом.

Лекция 3. Разработка расписания проекта...................... Лекция 4. Планирование обеспечения качества в проекте......... Лекция 5. Планирование рисков проекта...................... Лекция 6. Планирование человеческих ресурсов проекта......... Лекция 7. Планирование коммуникаций и управления Лекция 8. Оценка реализуемости проекта...................... Лекция 9. Идентификация рисков проекта..................... Лекция 10. Управление проектом на фазе проектирования......... Лекция 11. Реализация плана коммуникаций и обучение пользователей. Подготовка перехода к следующей Лекция 12. Управление проектом на фазе разработки Адаптация модели жизненного цикла проекта............... Разработка технико-экономического обоснования............ Формирование бизнес-цели проекта........................ Идентификация и анализ участников проекта................ Формирование требований проекта........................ Формирование иерархической структуры проекта............ Формирование списка работ (операций) проекта............. Определение логической последовательности Оценка трудоемкости и потребности в ресурсах.............. Определение длительности операций....................... Концептуальная оценка стоимости проекта.................. Разработка базового плана по стоимости проекта............. Лекция 3. Разработка расписания проекта...................... Исходные данные для разработки расписания................ Результаты разработки расписания......................... Технология разработки расписания......................... Разработка расписания проекта методом Организация управления расписанием проекта.............. Лекция 4. Планирование обеспечения качества в проекте......... Разработка плана обеспечения качества..................... Регламент по управлению качеством в проекте............... Организация управления качеством....................... Лекция 5. Планирование рисков проекта...................... Основные понятия управления рисками................... Определение уровней вероятности возникновения рисков Пример процедуры управления рисками................... Лекция 6. Планирование человеческих ресурсов проекта......... Матрица ответственности проекта........................ Закрепление функций и полномочий в проекте............. Лекция 7. Планирование коммуникаций и управления Формирование стратегии коммуникаций................... Идентификация объектов управления Формирование базовой линии конфигурации проекта........ Организация управления конфигурацией проекта........... Организация документирования статуса Лекция 8. Оценка реализуемости проекта...................... Анализ достижимости запланированных бизнес-выгод....... Оценка реализуемости проектного расписания.............. Оценка доступности и загрузки человеческих ресурсов....... Оценка организационной готовности...................... Лекция 9. Идентификация рисков проекта..................... Подтверждение содержания проекта....................... Лекция 10. Управление проектом на фазе проектирования......... Формирование детальных планов стадии проектирования.... Уточнение плана управления проектом.................... Руководство и управление исполнением проекта............ Осуществление интегрированного управления изменениями.. Обеспечение качества проекта на этапе проектирования...... Обеспечение целостности элементов конфигурации......... Обновление реестра рисков на фазе проектирования......... Оценка и управление персоналом проекта.................. Определение уточненных требований проекта.............. Мониторинг содержания и объема проекта................. Оценка потребности в обучении пользователей............. Лекция 11. Реализация плана коммуникаций и обучение пользователей. Подготовка перехода к следующей Информирование участников проекта..................... Планирование обучения пользователей.................... Лекция 12. Управление проектом на фазе разработки Детальное планирование стадии разработки и внедрения..... Подготовка инфраструктуры Осуществление итогов контроля качества проекта........... Управление рисками настройки и внедрения................ Подготовка персонала к завершению проекта............... Переход к продуктивной эксплуатации.................... Методические рекомендации по дисциплине Приложение 1. Матрица задач жизненного цикла ИС............. Приложение 2. Примеры проектных документов................. Список использованной литературы............................. Термин «ИТ-проект» обычно используется для обозначения деятельности, связанной с использованием или созданием некоторой информационной технологии. Это приводит к тому, что ИТ-проекты охватывают очень разнообразные сферы деятельности: разработку программных приложений, создание информационных систем, развертывание ИТ-инфраструктуры и пр. В этой книге мы будем часто говорить о проектах создания информационных систем, подразумевая реализацию какихто информационных технологий.

С одной стороны, эти работы соответствуют классическому определению проекта [1, 23]: «Проект – это комплекс усилий, предпринимаемых с целью получения конкретных уникальных результатов в рамках отведенного времени и в пределах утвержденного бюджета, который выделяется на оплату ресурсов, используемых или потребляемых в ходе проекта». С другой стороны, они обладают известными отличительными особенностями:

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

• ответственность за результат проекта имеет «солидарный» характер. То есть здесь нельзя возложить ответственность за успех проекта только на исполнителя, точно так же, как нельзя говорить, что исключительно заказчик виновен в том, что проект не удался.

В ИТ-проекте должны создаваться определенные условия для взаимодействия сторон, и стороны, участвующие в нем, несут равную ответственность за результаты проекта;

• зачастую реализация ИТ-проекта предусматривает изменение существующих организационных структур на предприятии;

• обычно в ИТ-проект вовлечено множество подразделений организации;

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

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

Если говорить о реализации ИТ-проектов, следует обратить внимание на следующие особенности:

• зачастую в компании заказчика одновременно выполняются несколько ИТ-проектов;

• приоритеты выполнения проектов постоянно корректируются;

• по мере реализации проектов выполняется уточнение и корректировка требований и содержания проектов;

• велико влияние человеческого фактора: сроки и качество выполнения проекта в основном зависят от непосредственных исполнителей и коммуникации между ними;

• каждый исполнитель может принимать участие в нескольких проектах;

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

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

• происходит постоянное совершенствование технологии выполнения работ.

Анализ статистики показывает, что примерно 90 процентов ИТ-проектов аналогичны уже выполненным. У руководителя проекта имеется опыт реализации таких задач и понимание возможных проблем. В этих случаях иерархическая структура проекта и работ (ИСП/ИСР) формируется с применением подхода Top-down (сверху вниз), используется типовая структура проектной команды, планы проекта (план управления рисками, план коммуникаций и пр.) аналогичны планам предыдущих проектов. Однако 10 процентов проектов – инновационные, реализуемые «с нуля» и требующие творчества, нестандартных решений и управленческой смелости. Принятие решений в таких проектах характеризуется высокими рисками, что требует от руководителя глубоких знаний методики проектного управления и понимания особенностей её применения в сфере информационных технологий.

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

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

• фазы жизненного цикла проекта, этапов, работ и отдельных задач;

• организационная структура исполнителей проекта;

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

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

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

Ключевые слова: ТЭО, бизнес-цель, бизнес-причина, цели проекта, задачи проекта, требования заказчика, устав проекта Адаптация модели жизненного цикла проекта В данном учебном пособии по управлению ИТ-проектами в качестве концептуальной основы используется модель жизненного цикла информационных систем (ЖЦ ИС), описанная в стандарте ГОСТ Р ИСО/МЭК 15288. В соответствии с данным стандартом запуск каждого нового проекта подразумевает создание (или адаптацию уже имеющейся) модели ЖЦ, состоящей из стадий.

Процесс создания (или адаптации уже имеющейся) модели ЖЦ начинается с определения целей и результатов каждой из стадий, образующих структуру работ для детализированного моделирования процессов реализации ИТ. [10] Исходя из допущений базового стандарта, а также типовых этапов ЖЦ ИТ и принятой последовательности их реализации, авторами предлагается следующая модель ЖЦ ИТ, определяющая последовательность изложения материала в книге.

1. Планирование проекта 2. Проектирование 3. Разработка и внедрение 4. Эксплуатация и поддержка 5. Утилизация и обновление В таблице ниже представлены цели каждой из выделенных стадий ЖЦ (см. таблицу 1.1).

Приведенные этапы есть стадии жизненного цикла информационной системы и не тождественны жизненному циклу проекта. Жизненный цикл продукта отражает, что нужно сделать для создания, эксплуатации, поддержки и утилизации данного продукта, а жизненный цикл проекта – как нужно организовывать и управлять работой. Фаза ЖЦ продукта может включать в себя все этапы ЖЦ проекта (см. рис.1.1 (а, б)), и, в соответствии со стандартом ГОСТ Р ИСО/МЭК 15288 [10], предусматривает наличие этапов планирования, оценки и контроля, а также процесса принятия решения – шлюза (см. рисунок 1.1. (а)), через который происходит переход на следующий этап ЖЦ ИС и который является точкой мониторинга качества и точкой принятия решения о целесообразности продолжения проекта [10]. Необходимо отметить, что планирование, оценка и контроль характерны для любого цикла управления (например, цикл Лекция Таблица 1.1. Цели этапов жизненного цикла информационной системы Р ИСО/ (адаптиМЭК 15288) рованный) Цель этапа Замысел Планирование Оценка новых возможностей в деловой проекта сфере, разработка предварительных системных требований и проверка их осуществимости. Концептуальное планирование всего ЖЦ ИС Разработка Проекти- Создание проекта системы, которая рование удовлетворяет требованиям приобретающей стороны и может быть реализована, испытана, оценена, применена по назначению, поддержана при применении, в Производство Разработка Разработка (настройка) системы и внедрение в соответствии с требованиями приобретающей стороны, тестирование системы, реализация соответствующих организационно-технических мероприятий и развертывание поддерживающих систем, направленных на обеспечение корректной Применение Эксплуатация Использование внедренного продукта и поддержка в заданных условиях функционирования Поддержка Осуществление в процессе эксплуатации применения материально-технического снабжения, ремонта, которые обеспечивают непрерывное функционирование рассматриваемой системы и устойчивое предоставление Изъятие Утилизация Обеспечение удаления рассматриваемой и списание и обновление системы и связанных с нею обслуживающих и поддерживающих организационно-технологических подсистем. Поддержка планирования перехода на новую Демминга). Таким образом, использование их, в том числе на этапе «Эксплуатация и поддержка», носящем выраженный операционный (не проектный) характер, вполне обосновано.

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

Рис. 1.1. (а,б) Примеры соотношения жизненного цикла информационной системы и жизненного цикла проекта Лекция В то же время процессы, выполняемые в рамках одной стадии ЖЦ ИТ, могут иметь взаимосвязи как в рамках данной стадии, так и с процессами других стадий. Очевидно, что для успешного достижения целей проекта необходимо не только управлять каждым процессом в отдельности, но и обеспечить комплексный подход к управлению с учетом взаимосвязей, взаимозависимостей как отдельных процессов, так и групп процессов.

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

1. Управление интеграцией 2. Управление содержанием 3. Управление сроками 4. Управление стоимостью 5. Управление качеством 6. Управление рисками 7. Управление человеческими ресурсами 8. Управление коммуникациями 9. Управление конфигурацией Описание содержания каждой из перечисленных выше областей знаний и соответствующих им процессов приводится в таблице 1.2.

Таблица 1.2. Области знаний проектного управления Курс Методические основы управления ИТ-проектами Лекция Курс Методические основы управления ИТ-проектами Лекция Курс Методические основы управления ИТ-проектами Лекция Каждый из этапов ЖЦ ИТ и ЖЦ проекта предусматривает совокупность задач, с полной матрицей которых можно ознакомиться в Приложении 1.

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

Сделанные изменения должны быть задокументированы. Общие требования к процедуре модификации таковы: любой новый процесс жизненного цикла определяется и документируется в терминах его назначения, целей и результатов. Ответственным за такого рода модификации является, как правило, руководитель соответствующего проекта. В то же время утверждение адаптированной, сокращенной или дополненной модели ЖЦ ИС обычно производит офис управления проектами или иная организационная единица, в круг обязанностей которой входит поддержание целостности и актуальности корпоративной методологии управления проектами [8].

Приведенная процедура и шаблон документирования модификации ЖЦ ИТ являются одним из возможных вариантов оформления соответствующих действий над ЖЦ ИТ.

При адаптации модели ЖЦ ИТ в интересах организации или проекта в соответствии с применяемыми политикой и процедурами должны выполняться следующие действия.

1. Руководителем проекта (РП) определяются и документируются обстоятельства, воздействующие на адаптацию. Эти воздействия включают (но не ограничиваются) перечисленное ниже:

a) стабильность и разнообразие среды функционирования;

b) коммерческие или эксплуатационные риски, касающиеся заинтересованных сторон;

c) новизну, размеры и сложность;

d) дату начала и продолжительность применения;

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

h) бюджетный профиль и доступные организационные ресурсы;

i) готовность предоставления услуг обеспечивающими системами.

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

3. Далее руководитель проекта собирает входные данные от следующих заинтересованных сторон проекта:

a) правообладатели системы;

b) заинтересованные стороны соглашения, заключенного организацией;

c) стороны, вносящие вклад в организационные функции.

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

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

6. Модификация ЖЦ ИС приобретает локальный (для одного проекта и для одной (под)системы) или общекорпоративный харакИнициация проекта Лекция тер по решению проектного офиса, по результатам апробации предложенной РП модификации.

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

• приоритизация проектов в условиях ограниченных финансовых, человеческих и прочих ресурсов;

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

• обеспечение заинтересованности руководителей бизнес-подразделений в проекте;

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

Согласно последним исследованиям 75% компаний ставит именно такие цели при подготовке ТЭО, в то же время все лишь 40% из них считают, что используемые ими методы позволяют получить корректную оценку эффективности внедряемого ИТ-решения [7].

Помимо обозначенных задач ТЭО может обеспечивать входную информацию для устава проекта, рассматриваемый в данной книге как ключевой документ интегрированного управления проектом. Для того чтобы ТЭО обеспечивал качественную информацию, рекомендуется следуюКурс Методические основы управления ИТ-проектами щим образом структурировать идентифицированные бизнес-выгоды ИТпроекта (см. Таблица 1.4.).

В соответствии с предлагаемым подходом [7] бизнес-выгоды можно классифицировать по двум факторам: (1) характеру воздействия на бизнес и (2) степени определенност. Таким образом, каждая выгода по проекту размещается «на пересечении» соответствующих значений двух обозначенных факторов.

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

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

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

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

Таблица 1.4. Матрица структурирования выгод ИТ-проекта (адаптировано из [7]) После определения характера воздействия необходимо классифицировать каждую бизнес-выгоду по степени определенности (от менее определенных к более определенным): наблюдаемые, измеримые, количественные, финансовые.

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

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

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

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

количественных бизнес-выгод финансовыми данными. Агрегированные финансовые выгоды проекта образуют базу для построения финансовой модели проекта (ROI-модель) и расчета инвестиционных показателей: NPV, IRR, периода окупаемости.

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

Формирование бизнес-цели проекта Бизнес-цель – это описание фактора, побуждающего к выполнению проекта. Ее формирование производится на стратегическом уровне, то есть бизнес-цель выступает в качестве связующего звена между глобальными задачами, стоящими перед организациями, и планируемым к реализации проектом. При отходе от стратегического видения происходит смещение бизнес-цели в сторону тактических и даже операционных задач, на уровне которых целью проекта видится «просто выдать продукт», а не достичь какой-либо тактической цели, поддерживающей стратегические цели организации. Этого нельзя допускать: бизнес-цель проекта должна всегда носить тактический или стратегический характер, но в то же время быть предельно точной и ясной (очень редко удается применить широко известный метод SMART к построению бизнес-цели проекта).

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

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

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

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

• стратегические и тактические цели организации-заказчика;

• формулировка требований организации-заказчика;

• контракт;

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

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

В таблице 1.5 приведены требования к уставу проекта – перечислены обязательные разделы с необходимыми рекомендациями и пояснениями к их наполнению.

Таблица 1.5. Требования к уставу проекта 1. Название проекта Каждый проект должен иметь название, отражающее его суть и в то же время достаточно 2. Бизнес-причина Производственная необходимость, или самое возникновения общее описание проекта и требований проекта к продукту, производство которого является результатом выполнения проекта. Формулировка причины фактически дает ответ на вопрос, зачем выполняется данный проект. Причины возникновения проекта могут основываться на требованиях рынка, техническом прогрессе, юридических требованиях или государственном стандарте 3. Бизнес-цель Сформулирована заказчиком, исходя из стратегических и тактических целей компании, см.

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

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

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

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

Кроме того, организации, придающие значение себестоимости, имеют тенденцию указывать для основных событий специфику бюджета ресурсов или бюджета средств [18] 6. Участники проекта Перечисление заинтересованных сторон проекта, иными словами, круга лиц и организаций, на которых оказывает воздействие реализация данного проекта и которые сами могут воздействовать на него. Подробнее об участниках проекта см. раздел «Идентификация участников проекта»

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

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

Обратите внимание, что при составлении устава проекта допущения формулируются со стороны организации-заказчика об организацииисполнителе 9. Ограничения Ограничение указывает на условие, которое относительно нельзя нарушать в процессе создания продукта организации проекта, или условие, которому ни при каких и окружения, обстоятельствах не должен удовлетворять а также внешние продукт проекта. Ограничения к тому же ограничения указывают на возможности команды проекта • не менее 40% членов команды проекта, предоставляемых исполнителем, заняты на 100% Обратите внимание, что при составлении устава проекта ограничения формулируются со стороны организации-заказчика об организацииисполнителе и о проекте в целом 10. Объем денежных На данном этапе указывается сумма средств, средств, выделен- которую организация-заказчик готова выденых на достиже- лить на достижение сформулированной ние бизнес-цели бизнес-цели проекта. Указанная сумма является результатом определения порядка величины 11. Назначение Руководитель проекта назначается уставом руководителей проекта и формально приступает к выполнепроекта и общее нию своих обязанностей на следующий день определение после подписания устава проекта.

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

• формировать стратегические указания для менеджера проекта по ходу отслеживания результатов проекта;

Роль спонсора проекта обычно не предполагает работы с полной занятостью вне зависимости от размера проекта [8,18].

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

договоров на протяжении всего ЖЦ, организаАвторы рекомендуют включать в проект руководителей и двух спонсоров проекта – по одному от заказчика и исполнителя.

несущее смысла, если только это не специфический термин. Я прошу обратить на него внимание. М/б, сбора информации о текущем статусе?

функциональные руководители обычно выделяют для проекта своих подчиненных, только когда руководитель проекта составит план потребности в ресурсах, после определения состава работ проекта, и отправит официальный запрос на Таблица 1.6. Шаблон листа управления документом Лекция Рис. 1.2. Модель комплексного анализа участников и окружения проекта (Burnett, 1980). На рисунке ИКС – исследовательская команда спонсора После подготовки устава в соответствии с предложенным шаблоном рекомендуется произвести проверку его корректности. Автор устава, как правило, спонсор проекта, должен обязательно убедиться, что:

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

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

• в самом документе отсутствуют противоречия;

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

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

Идентификация и анализ участников проекта Заинтересованная сторона (участник, или стейкхолдер1) – это любое лицо, которое само оказывает влияние на проект или подвергается влиянию проекта и результатов его реализации [5].

На начальной фазе ЖЦ ИС, фазе планирования, целевой группой всегда является руководство компании, на которое следует обращать особое внимание и наиболее тесно взаимодействовать с ним. Кроме того, на данной фазе руководство компании будет и единственной точкой опоры проекта в организации, поэтому нужно четко себе представлять, чем отличаются руководители среднего звена от прочих сотрудников [5].

Вообще процесс идентификации заинтересованной стороны стоит начинать с построения карты участников проекта, на которой мы уже Рис. 1.3. Пример карты участников проекта (адаптировано из [5]) 1 От английского stakeholder – «заинтересованная сторона».

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

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

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

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

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

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

Для анализа воздействия участников на проект рекомендуется использовать шаблон, приведенный в таблице 1.7.

Анализ воздействия производится в разрезе двух аспектов.

1. Степень организационного влияния участника проекта Степень участия заинтересованной стороны проекта в принятии стратегически важных для компании решений, ее влияние на реализацию Таблица 1.7. Анализ воздействия участников проекта (адаптировано из [5]) различных инициатив. Крайне важно при подобном анализе не упустить из рассмотрения и неформальных лидеров организации.

2. Воздействие участников на реализуемый ИТ-проект Данный показатель характеризует, как конкретный участник может повлиять на проект, насколько важна его поддержка и опасно его неприятие результатов проекта.

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

Если анализ воздействия участников позволяет приоритизировать использование ограниченных ресурсов проекта, то оценка вовлеченности позволяет определить степень сопротивления различных участников проекта, которое характеризуется в разрезе двух аспектов [5].

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

2. Согласие Получилось ли достичь согласия с этим конкретным участником (группой участников проекта)? Разделяют ли они точку зрения руководителя проекта?

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

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

1. Союзники Поддерживают имеющиеся ожидания по проекту, в основном разделяют видение и, скорее всего, заинтересованы в результатах.

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

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

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

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

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

• ФИО и контактную информацию сотрудника;

• сведения об организационной единице, в которой работает сотрудник;

• определение функциональной роли сотрудника;

• категорию получаемых сообщений и их историю.

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

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

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

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

• «Большая картинка»

Место (под)процесса в сквозном процессе Интерфейс с предшествующим процессом Интерфейс с последующим процессом • Описание процесса Что? (типовой результат и его потребитель) Как? (последовательность шагов и показатели эффективности) Кто? (роли и присущая им квалификация) Чем? (используемые средства, инструменты, расходуемые ресурсы) • Документы Входящие документы Исходящие документы Регламентирующие документы 2. Проведение Рекомендуется планировать интервью исходя из максимальной продолжительности в 1,5 часа. Учитывая весьма ограниченное время, необходимо всегда приходить в указанный час, заранее продумать маршруты пути к месту встречи. Каждый участвующий в процессе общения с заказчиком должен оперировать одним и тем же набором вопросов в одинаковой Лекция Рис. 1.4. Принцип структурирования информации о бизнес-процессе последовательности, чтобы обеспечить порядок проведения переговоров и удобство при дальнейшем формировании протокола интервью.

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

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

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

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

• Определены ли факторы ценности для заказчика?

• Усвоила ли команда проекта эти факторы?

• Были ли факторы ценности интегрированы в процессы и проектные продукты?

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

Таблица 1.8. Шаблон протокола интервью Функция качества – это инструмент для работы с заказчиком, который позволяет встроить его требования в проект. Цель этого инструмента – убедиться, что требования заказчика интегрированы в каждую часть проекта, от определения (1) требований проекта и (2) установления характеристик решения до формирования (3) проектных работ и выстраивания (4) программы обеспечения качества.

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

На рисунке 1.6 отражена типовая структура «дома качества». Его заполнение производится в несколько этапов.

1. Подготовка требований заказчика Лекция Рис. 1.5. Схема и рекомендации по проведению интервью Требования заказчика – важнейшая информация при построении «дома качества». Как правило, это самый сложный этап, поскольку необходимо выяснить наиболее значимые условия заказчика. Основной объем информации о его потребностях был выявлен в процессе интервьюирования и на этапе подготовке ТЭО и устава проекта. При разработке функции качества рекомендуется ограничивать функцию качества 10-ю требованиями заказчика, в противном случае использование инструмента становится громоздким.

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

3. Формирование матрицы взаимосвязей На этом этапе происходит проверка отсутствия взаимных противоречий между сформулированными требованиями проекта, иными словами, происходит их попарное сравнение. Для обозначения связи могут использоваться разные символы: так, для показа положительной связи часто используют •, а для показа отрицательной – o. Идентифицированные отношения демонстрируют столкновение требований и возможность нахождения компромисса между ними, что позволяет увидеть условия проекта в совокупности, а не по отдельности.

4. Формирование матрицы отношений Заполнение матрицы отношений есть ключевой шаг построения «дома качества». Смысл ее заполнения состоит в том, чтобы убедиться, что все требования заказчика будут удовлетворены предложенными требованиями проекта. На пересечении соответствующего требования заказчика и требования проекта при наличии положительной связи ставится отметка, например, крестик. Если требование заказчика не поддерживается ни одним требованием проекта, значит, удовлетворение первого может вызвать ряд проблем. В обратной ситуации, когда проектное требование не соотносится ни с одним требованием заказчика, говорят об избыточности данного проектного требования. На крупных проектах иногда усложняют отношения между требованиями заказчика и проекта и вместо крестика используют числовые значения, характеризующие степень влияния требований проекта на реализацию заданного требования заказчика [5].

5. Субъективная оценка через сравнительный анализ На данном этапе происходит присвоение степени важности каждому требованию заказчика и проект сравнивается с другими проектами и/или текущим status quo. Сравнение выявляет сильные и слабые стороны проекта по отношению к аналогичным инициативам, определяет возможности для улучшения.

6. Объективная оценка через установку конечных целей Для обеспечения измерения и последующего контроля реализации требований проекта (а через них – и обеспечения требований заказчика) необходимо задать измеримые конечные цели по каждому требованию проекта, тем самым обеспечив объективную основу для управления ими.

Лекция Ключевые слова: ИСР, содержание проекта, пакеты работ и операции, оценка стоимости, смета, базовый план по стоимости.

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

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

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

1. Вспомогательные планы управления проектом, в число которых • план управления содержанием проекта;

• план управления расписанием проекта;

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

• план управления качеством проекта;

• план управления обеспечением персоналом;

• план управления коммуникациями проекта;

• план управления рисками проекта;

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

2. Базовая линия проекта, состоящая из:

• базового расписания проекта;

• базового плана по стоимости;

• базового плана по качеству;

• базового плана по конфигурации;

• реестра рисков.

3. Результаты анализа, проведенного проектной командой в отношении содержания, объема и сроков проекта.

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

Формирование иерархической структуры проекта Иерархическая структура работ (ИСР) – это ориентированный на результаты способ группировки элементов проекта, который упорядочивает и определяет общее содержание проекта. Работы, не включенные в ИСР, находятся за пределами содержания проекта [18].

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

Существуют два основных способа разработки ИСР: «сверху вниз» и «снизу вверх». Далее приводится описание подхода «сверху вниз».

1. Сбор исходной информации.

Разработка ИСР станет более легким и осмысленным делом, если будет доступна следующая информация:

• требования заказчика;

• пул доступных ресурсов;

• конкретная проектная ситуация.

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

В соответствие с принципом, лежащим в основе построения ИСР по фазам жизненного цикла, на 1-ом уровне происходит разбитие проекта на фазы. Этот принцип следования естественному жизненному циклу проекта весьма популярен в некоторых отраслях и, в принципе, значительно упрощает разработку расписания проекта. Хороший пример использования такого типа структурирования ИСР – проект разработки программного обеспечения, состоящий из таких фаз, как определение требований, высокоуровневое проектирование, низкоуровневое проектирование, написание кода и тестирование. Принцип разбития по системам подразумевает разбитие на составляющие физические системы и отображение их на уровне 1 ИСР. Этот подход широко распространен в ряде традиционных производственных отраслей, в которых ИСР больше напоминает спецификацию производственного образца. Разбиение ИСР по географическим зонам практикуется, в частности, в сфере строительства, где уровень 1 ИСР проекта может состоять из здания A, здания B и т. д. Что касается Лекция следующих уровней ИСР, многие специалисты практикуют гибридные ИСР, сочетающие два или три метода.

При выборе способа структурирования ИСР рекомендуется следовать принятому на предприятии или в отрасли стандарту, это позволит избежать сопротивления новому методу, которое неизбежно возникнет.

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

Для определения степени детализации ИСР нужна следующая информация:

• количество уровней в ИСР;

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

Так, для большинства средних и малых ИТ-проектов характерны ИСР со следующей детализацией:

• от трех до четырех уровней;

• от 15 до 40 пакетов работ;

• от 40 до 80 часов на средний пакет работ;

• от 3% до 7% общего бюджета рабочих часов на средний пакет работ [18].

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

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

Описание содержанием должно позволять оценить желаемый результат и выступать в качестве основы для составления базового плана соКурс Методические основы управления ИТ-проектами держания, которому необходимо следовать при выполнении всех работ проекта. В известном смысле описание содержания проекта можно сравнить с границами проекта – он говорит о том, что выход за границы не допускается без санкции руководителя и что все находящееся в этих границах представляет собой пространство решений, в котором разрешается действовать команде проекта.

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

К информации, имеющей ключевое значение для составления описания содержания проекта, относятся:

• устав проекта;

• формулировка требований организации-заказчика;

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

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

Таблица 2.1. Требования к описанию содержания проекта 1. Название проекта Каждый проект должен иметь название, отражающее его суть и в то же время достаточно яркое для привлечения внимания. Утвержденное 2. Цели и задачи Цель проекта формулируется, исходя из проекта требований заказчика и указанной в уставе бизнес-причины проекта, при этом она не повторяет формулировки бизнес-цели, отраженной в уставе, а отвечает на вопрос, КАК эта бизнесцель будет достигнута. Цель проекта должна Лекция 3. Требования Является элементом базового содержания к проектному проекта, входящего в план управления проектом.

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

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

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

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

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

• материалы и инструментарий – описание внедряемого ИТ-продукта с указанием вендора, названия, класса системы, описания функциональной и технической архитектуры системы, перечисление ее модулей 6. Первоначальная Является элементом базового содержания иерархическая проекта, входящего в план управления проектом.

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

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

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

10. Допущения Набор условий, которые должны быть выполнепроекта ны наряду с созданием продукта проекта для (со стороны достижения результата проекта. Допущения исполнителя) обуславливают риски проекта; во время проекта описания содержания проекта допущения формулируются со стороны организации-исполнителя об организации-заказчике 11. Ограничения Ограничение указывает на условие, которое проекта (со нельзя нарушать в процессе создания продукта стороны проекта, или условие, которому ни при каких исполнителя) обстоятельствах не должен удовлетворять продукт проекта. Ограничения к тому же указывают на возможности команды проекта по выбору Обратите внимание, что при составлении описания содержания проекта ограничения формулируются со стороны организации-исполнителя 12. Связь с прочими Любое возможное взаимодействие с другими текущими проектами должно быть отражено в описании программами содержания проекта. Недостаточно просто и проектами констатировать эту связь, необходимо указать, также детально описать, какие ресурсы подпадают под совместное использование и в каких 13. Первоначально На данном этапе, как правило, указываются уже сформулирован- известные риски и основные категории потенные риски циальных рисков (например, внешние, организационные, процедурные, технические, юридиПланирование проекта Лекция 14. Смета расходов Смета есть представление проектных затрат с указанием на проект по категориям, в качестве примера порядка величин см. шаблон в соответствующем разделе.

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

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

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

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

Рис. 2.1. Модель критических факторов успеха в динамике этапов жизненного цикла информационной системы Компетентный состав команды В составе команды проекта должны быть специалисты, обладающие необходимым опытом внедрения ERP-систем, Типична ситуация, когда данная группа представлена консультантами системного интегратора и техническими специалистами вендора. В то же время в проекте необходимо наличие сотрудников самой фирмы, с одной стороны – как основных носителей знаний о бизнес-процессах компании, с другой – для получения знаний о системе и формирования и развития соответствующих компетенций внутри компании [4, 6].

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

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

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

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

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

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

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

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

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

Лекция Процесс определения состава операций начинается с определения степени детализации операций. Количество операций должно быть достаточным для того, чтобы ответственный за пакет работ мог отслеживать ход исполнения и осуществлять координацию работ. Число операций не должно быть слишком большим, затрудняющим оценку общего состояния проекта с помощью системы отчетности о ходе выполнения проекта [20]. Например, команда решила ограничить количество операций проекта – не более 30, при этом любая операция должна иметь продолжительность не более 20 дней и не менее 10 дней.

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

при этом длительность (степень детализации) не рассматривается.

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

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

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

Исходной информацией для процесса определения списка работ являются [23]:

• методология внедрения ИС;

• описание содержания проекта;

• иерархическая структура работ (ИСР);

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

• декомпозиция;

• планирование методом набегающей волны;

• экспертная оценка.

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

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

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

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

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

Таблица 2.2. Пример списка работ Наименование Наименование операций пакета работ Обследование Формирование и согласование плана проведения интервью.

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

Проведение интервью для описания бизнес-процессов Лекция Описание Описание бизнес-процессов по функциональной бизнеспроцессов Описание бизнес-процессов по функциональной области Логистика.

Описание бизнес-процессов по функциональной области Персонал Разработка Разработка решений по функциональной архитектуре.

системы Подготовка функционального дизайна расширений.

Техническое проектирование расширений.

Техническое проектирование программ конвертации Разработка программ конвертации данных.

Планирование тестирования приложения и интеграционного тестирования Тестирование Разработка сценариев тестирования.

системы Подготовка тестовых данных.

Проведение тестирования по функциональным областям «Финансы», «Логистика», «Персонал».

Проведение интеграционного тестирования.

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

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

Взаимосвязи операций могут быть с перекрытиями, когда еще незавершенная операция имеет достаточно выходных элементов для начала зависящей от нее операции, или с параллельным выполнением операций [1].

Исходной информацией для процесса определения взаимосвязи операций могут быть [11]:

1) описание содержания проекта – содержит определение содержания продукта, включающее в себя характеристики продукта, котоКурс Методические основы управления ИТ-проектами рые могут повлиять на определение взаимосвязей операций, поэтому во избежание ошибок следует повторно проанализировать определение содержания продукта;

2) методология внедрения ИС;

3) результаты процесса определения состава операций;

4) список операций;

5) параметры операций;

6) список контрольных событий;

7) одобренные запросы на изменение.

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

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

Этот метод еще называется «операции в узлах», он используется в большинстве пакетов программного обеспечения для управления проектами.

Метод стрелочных диаграмм: метод построения сетевых диаграмм расписания проекта, где операции представляются в виде дуг, которые соединяются в узлах, показывающих их зависимости. Этот метод еще называется «операции на дугах».

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

Определение зависимостей. Для определения последовательности операций используется три типа зависимостей: жесткая (или обязательная), нежесткая (или произвольная) и внешняя.

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

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

Сетевые диаграммы расписания проекта – схематическое отображение плановых операций проекта и логических взаимосвязей (зависимостей) между ними. Сетевая диаграмма расписания проекта может быть построена вручную или при помощи программного обеспечения для управления проектом, например, Spider или MS Project. Она может включать в себя полную детализацию проекта или одну или несколько суммарных операций (пакет операций). На рис. 2.2 приведен пример представления расписания проекта в виде диаграммы Гантта MS Project.

Список операций (обновления). Если одобренные запросы на изменения являются результатом процесса определения взаимосвязей операПланирование проекта Лекция Рис. 2.2. Фрагмент расписания проекта в виде диаграммы Гантта MS ций, то создается обновленный список операций, включающий в себя эти изменения.

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



Pages:   || 2 | 3 | 4 | 5 |   ...   | 6 |
 


Похожие работы:

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Тверской государственный университет Факультет прикладной математики и кибернетики Кафедра вычислительной математики УТВЕРЖДАЮ Руководитель направления подготовки магистров д.ф.- м.н. доцент С.М.Дудаков 2012 года УЧЕБНО-МЕТОДИЧЕСКИЙ КОМПЛЕКС по дисциплине Плановая модель ветровой циркуляции в водоёме для магистров 2 курса очной формы обучения (3 семестр)...»

«Министерство образования и наук и Российской Федерации Федеральное агентство по образованию Российская академия наук Государственное образовательное учреждение высшего профессионального образования Московский физико-технический институт (государственный университет) Российский фонд фундаментальных исследований ТРУДЫ 49-Й НАУЧНОЙ КОНФЕРЕНЦИИ МФТИ СОВРЕМЕННЫЕ ПРОБЛЕМЫ ФУНДАМЕНТАЛЬНЫХ И ПРИКЛАДНЫХ НАУК Часть VII УПРАВЛЕНИЕ И ПРИКЛАДНАЯ МТЕМАТИКА 24–25 ноября 2006 года Москва – Долгопрудный 49-я...»

«КАТАЛОГ УЧЕБНОЙ ЛИТЕРАТУРЫ ДЛЯ ВУЗОВ Москва Инфра-М СОДЕРЖАНИЕ 1 000000000 УЧЕБНИКИ ДЛЯ ВСЕХ СПЕЦИАЛЬНОСТЕЙ И НАПРАВЛЕНИЙ УЧЕБНИКИ ДЛЯ ВСЕХ СПЕЦИАЛЬНОСТЕЙ И НАПРАВЛЕНИЙ 1 БЕЗОПАСНОСТЬ ЖИЗНЕДЕЯТЕЛЬНОСТИ 3 ЕСТЕСТВОЗНАНИЕ 5 ИНОСТРАННЫЙ ЯЗЫК 8 ИНФОРМАТИКА КУЛЬТУРОЛОГИЯ МАТЕМАТИКА ОТЕЧЕСТВЕННАЯ ИСТОРИЯ ПОЛИТОЛОГИЯ ПСИХОЛОГИЯ И ПЕДАГОГИКА РУССКИЙ ЯЗЫК И КУЛЬТУРА РЕЧИ СОЦИОЛОГИЯ ФИЛОСОФИЯ ЭКОНОМИКА ОБЩАЯ ЭКОЛОГИЯ 010000 ФИЗИКО-МАТЕМАТИЧЕСКИЕ НАУКИ

«ТЕХНИЧЕСКИЙ КОДЕКС ТКП 211-2010 (02140) УСТАНОВИВШЕЙСЯ ПРАКТИКИ ЛИНЕЙНО-КАБЕЛЬНЫЕ СООРУЖЕНИЯ ЭЛЕКТРОСВЯЗИ. ПРАВИЛА ПРОЕКТИРОВАНИЯ ЛIНЕЙНА-КАБЕЛЬНЫЯ ЗБУДАВАННI ЭЛЕКТРАСУВЯЗI. ПРАВIЛЫ ПРАЕКТАВАННЯ Издание официальное Минсвязи Минск ТКП 211-2010 УДК 621.395.74.001.2 МКС 33.040.50 КП 02 Ключевые слова: кабельные линии электросвязи, сеть проводного вещания, трасса кабеля, кабели волоконно-оптические и электрические, канализация кабельная, траншея, колодцы, муфты, вводы кабельные, оборудование...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ ФБГОУ ВПО ИРКУТСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ ОСНОВНАЯ ОБРАЗОВАТЕЛЬНАЯ ПРОГРАММА ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ Направление 230400.68Информационные системы и технологии Наименование программ подготовки: Анализ и синтез информационных систем. Биоинформатика. Технологическое моделирование деталей и машин с 3D допусками в САПР нового поколения. Наименование степени / квалификации магистр Форма обучения очная Иркутск 2011 г. 1 СОДЕРЖАНИЕ Стр....»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ Московский государственный университет экономики, статистики и информатики Цыбульская М.В. История политических и правовых учений Москва, 2003 УДК 32.8 ББК 66.1 Ц 938 Цыбульская М.В. История политических и правовых учений:. / Моск. гос. ун-т экономики, статистики и информатики. - М., 2003. – 114с. © Цыбульская Марина Владимировна, 2003 г. © Московский государственный университет экономики, статистики и информатики, 2003 г. 2 СОДЕРЖАНИЕ Введение 1....»

«1. Реут Д.В. Кентавр в интерьере. Кентавр. Методологический и игротехнический альманах, М.: 1991, N 1, с. 2 2. Реут Д.В. К микроанализу мегамашин. Кентавр, 1993, N 2, с. 47-51, 009EUT.ZIP from www.circle.ru 3. Реут Д.В. Ad marginem metodologia. Кентавр, 1995, N 2, с. 41-50. 4. Реут Д.В. Буриданово человечество. Международный конгресс Фундаментальные основы экологии и духовного здоровья человека. 27 сентября – 4 октября 1995 г. Алушта. Крым. Украина. Тезисы докладов. Часть 2, М.: 1996, с. 21 5....»

«А. Н. Л И Б Е Р М А Н ПОМНЮ Страницы жизни СанктПетербург 2006 1 Светлой памяти моей матери Анны Аркадьевны Кабищер посвящается 2 А. Н. Л И Б Е Р М А Н ПОМНЮ Страницы жизни Издание 2-е, исправленное и дополненное СанктПетербург 2006 3 Издание осуществлено при поддержке Центра информатики „Гамма-7” (г. Москва) Либерман Аркадий Нисонович Помню. Страницы жизни. СПб. Изд. 2-е, исправленное и дополненное, 2006 Автор этой книги – доктор медицинских наук, профессор, прожил большую жизнь, насыщенную...»

«1 ЭНЦИКЛОПЕДИЯ УЧИТЕЛЯ ИНФОРМАТИКИ II. Теоретические основы информатики Список статей 1. Измерение информации — алфавитный подход 2. Измерение информации — содержательный подход 3. Информационные процессы 4. Информация 5. Кибернетика 6. Кодирование информации 7. Обработка информации 8. Передача информации 9. Представление чисел 10. Системы счисления 11. Хранение информации 12. Языки Основными объектами изучения науки информатики являются информация и информационные процессы. Информатика как...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ФГБОУ ВПО Кемеровский государственный университет Новокузнецкий институт (филиал) Факультет информационных технологий РАБОЧАЯ ПРОГРАММА ДИСЦИПЛИНЫ ОПД.Ф.3 Базы данных для специальности 080801.65 Прикладная информатика в экономике Новокузнецк 2013 1 Сведения о разработке и утверждении рабочей программы дисциплины Рабочая программа дисциплины по выбору студента ОПД.Ф.3 Базы данных федерального компонента цикла ОПД составлена в соответствии с...»

«2 3 1. Цели освоения дисциплины. Цели освоения социологии: формирование общекультурных компетенций на основе изучения основных теоретических, методологических и практических проблем социологической науки; развитие личностных качеств, способствующих осуществлению профессиональной деятельности в сфере Прикладная информатика на высоком уровне. 2. Место дисциплины в структуре ООП бакалавриата. Социология входит в состав вариативной части гуманитарного, социального и экономического цикла дисциплин...»

«Мы не только занимаемся решением проблем образования и созданием современной образовательной среды для российской школы, не только обучаем, но и сами постоянно учимся. Мы считаем стремление к знаниям непременным условием успехов в науке, творчестве и бизнесе, залогом плодотворного сотрудничества между людьми. Институт новых технологий (ИНТ) Институт новых технологий (ИНТ) существует уже более 20 лет. Его создали профессионалы науки, образования, технологии. С самого начала своей деятельности...»

«Международный консорциум Электронный университет Московский государственный университет экономики, статистики и информатики Евразийский открытый институт П.А. Покрытан Теория антикризисного управления Учебно-практическое пособие Москва 2007 1 Теория антикризисного управления УДК 338.1 ББК 65.050 П 487 Покрытан П.А. ТЕОРИЯ АНТИКРИЗИСНОГО УПРАВЛЕНИЯ: Учебно-практическое пособие. – М.: Изд. Центр ЕАОИ, 2007. – 325 с. ISBN 978-5-374-00039-9 © Покрытан П.А., 2007 © Евразийский открытый институт,...»

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

«УДК 37 ББК 74 М57 Автор: Витторио Мидоро (Институт образовательных технологий Национального исследовательского совета, Италия) Консультант: Нил Батчер (эксперт ЮНЕСКО, ЮАР) Научный редактор: Александр Хорошилов (ИИТО ЮНЕСКО) Руководство по адаптации Рамочных рекомендаций ЮНЕСКО по структуре ИКТ-компетентности М57 учителей (методологический подход к локализации UNESCO ICT-CFT). –М.: ИИЦ Статистика России– 2013. – 72 с. ISBN 978-5-4269-0043-1 Предлагаемое Руководство содержит описание...»

«Борис Николаевич Малиновский История вычислительной техники в лицах Юрий Ревич при содействии Веры Бигдан, Киевский компьютерный музей История вычислительной техники в лицах. : К.: фирма КИТ, ПТОО А.С.К.; Киев; 1995 ISBN 5-7707-6131-8 Аннотация Книга посвящена жизни и творчеству первосоздателей отечественной цифровой электронной вычислительной техники — С.А. Лебедева, И.С. Брука, Б.И. Рамеева, В.М. Глушкова, Н.Я. Матюхина, М.А. Карцева и др. — замечательной плеяде ученых из воистину уникального...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Утвержден приказом Министерства образования и науки Российской Федерации от _200 г. № Регистрационный номер _ ФЕДЕРАЛЬНЫЙ ГОСУДАРСТВЕННЫЙ ОБРАЗОВАТЕЛЬНЫЙ СТАНДАРТ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ по направлению подготовки 3 м - Фундаментальная информатика и информационные технологии Квалификация (степень) магистр 2 ОБЩИЕ ПОЛОЖЕНИЯ Направление подготовки Фундаментальная информатика и информационные технологии утверждено приказом...»

«Секция 2 Дистанционное обучение и Интернет Topic 2 Distant Learning and Internet New Computer Technology in Education Troitsk, June, 29-30, 2004 XV International Technology Institute TECHNOLOGICAL BASIS OF EDUCATION IN MODERN UNIVERSITY Andreev A. (andreev@openet.ru), Lednev V. (hsfm@mifp.ru), Rubin Y. (yrubin@mifp.ru) Moscow international institute of econometrics, informatics, finance and law Abstract The article is devoted to the structure, contents and organization of education with use of...»

«Виталий Петрович Леонтьев Компьютер. Настольная книга школьника Аннотация Книга призвана помочь школьнику в освоении курса информатики. Простым и доступным языком изложены все необходимые сведения о современных компьютерах, операционной системе Windows ХР, подробно раскрыты принципы работы с пакетом Microsoft Office. Большой раздел посвящен Интернету: досконально описано, как подключиться к Сети, быстро находить необходимую информацию, защищаться от вирусов и хакерских атак. Используя это...»

«Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Амурский государственный университет Кафедра математического анализа и моделирования УЧЕБНО-МЕТОДИЧЕСКИЙ КОМПЛЕКС ДИСЦИПЛИНЫ КОМПЬЮТЕРНОЕ МОДЕЛИРОВАНИЕ Основной образовательной программы по направлению подготовки 010400.62 – Прикладная математика и информатика Благовещенск 2012 г. УМКД разработан канд. физ.-мат. наук, доцентом Масловской...»














 
© 2014 www.kniga.seluk.ru - «Бесплатная электронная библиотека - Книги, пособия, учебники, издания, публикации»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.