авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 || 3 | 4 |   ...   | 5 |

«РОССИЙСКАЯ ФЕДЕРАЦИЯ МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ...»

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

Работа по совершенствованию процессов происходит в виде неболь ших проектов. Проекты совершенствования по системе «Шесть сигм» могут быть разными по длительности и экономическому эффекту, могут затраги вать одно или сразу несколько подразделений компании. Используется две методологии DMAIC (Define, Measure, Analyze, Improve, Control) и DFSS (Design for Six Sigma). Подход DFSS используется при построении нового процесса, в то время как, методология DMAIC применяется при модифика ции старого процесса. Оба процесса осуществляются на основе одних и тех же принципов:

• искренний интерес к клиенту;

• управление на основе данных и фактов;

• ориентированность на процесс, управление процессом и совер шенствование процесса;

• проактивное (упреждающее) управление;

• сотрудничество без границ (прозрачность внутрикорпоративных барьеров);

• стремление к совершенству плюс снисходительность к неудачам.

PDF created with pdfFactory Pro trial version www.pdffactory.com Методология DMAIC основана на последовательности этапов, приве денных в таблице 3.1.

Таблица 3.1 –Последовательность этапов DMAIC Название этапа Действия Определение Определение целей, масштаба, проблемы и основных этапов проекта. Определение ключевых требований клиента и важней (Define) ших факторов процесса, которые необходимо улучшить.

Измерение Сбор данных (о важнейших факторах) и оформление собранных данных в удобном для анализа виде.

(Measure) Анализ (Ana- Выявление главных причин изучаемых дефектов.

lyze) Совершенствов Разработка решений по устранению основных причин дефектов.

ание (Improve) Внедрение новых решений в полномасштабный процесс.

Контроль (Con- Отладка эффективной системы контроля и коррекции изменен ных факторов процесса. Подведение итогов результата проекта.

trol) Подход DFSS реализуется последовательностью этапов, приведенных в таблице 3.2.

Таблица 3.2 – Последовательность этапов DMADV.

Название этапа Действия Определение Определение цели и масштабов проекта и требований заказчика (как внешнего, так и внутреннего).

(Define) Измерение Измерение потребностей и спецификаций клиентов.

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

(Measure) Анализ (Ana- Анализ параметров процесса для достижения соответствия тре бованиям заказчиков.

lyze) Проектирование Детальная разработка процесса для достижения соответствия требованиям заказчиков.

(Design) Проверка (Veri- Проверка разработанного процесса, в том числе на его соответ ствие нуждам клиента.

fy) При разработке процесса по «Шести сигмам» активно используются аналитические методы (такие, как развертывание функции качества, анализ видов и последствий отказов, бенчмаркинг, планирование эксперимента и др.). Уделяется большое внимание сбору данных о потребителе и на каждом этапе преобразуются «потребности» в «требования», что дает возможность увязать их между собой.

PDF created with pdfFactory Pro trial version www.pdffactory.com ИСО 9000 - Система менеджмента качества /23/ Первая страна, в которой предприятия получили существенный эф фект от внедрения TQM стала Япония. Фактически уже с шестидесятых го дов многие компании Японии применяли методы, основанные на философии TQM. В 1979 г. в Великобритании появились стандарты BS 5750, основан ные на правилах и процедурах, воплощающих концепцию TQM. Спустя во семь лет международная организация ИСО на основе британских стандартов создала серию ISO 9000, которые в настоящее время объединяют стандарты:

• ISO 9000:2005 (аналог ГОСТ Р ИСО 9000-2001) — Системы ме неджмента качества. Основные положения и словарь • ISO 9001:2000 (ГОСТ Р ИСО 9001-2001)— Системы менеджмен та качества. Требования • ISO 9004:2000 (ГОСТ Р ИСО 9004-2001)— Системы менеджмен та качества. Рекомендации по улучшению деятельности • ISO 19011:2003 (ГОСТ Р ИСО 19011-2003) — Рекомендации по аудиту систем менеджмента качества и/или охраны окружающей среды.

К ним также относится группа стандартов экологического менеджмен та ИСО 14000.

Стандарт не гарантирует качество продукции. Цель ИСО 9000 — вне сти согласованность и объективность в действия системы контроля качества поставщика. Предполагается, что ИСО 9000 будет использоваться в отноше ниях между компаниями, обычно в форме потребитель/поставщик. Стандарт помогает компаниям формализовать их систему управления процессом про верки качества и соответствия продукции. Отличия в подходах ИСО 9000 и TQM показано в таблице 3. PDF created with pdfFactory Pro trial version www.pdffactory.com Таблица 3.3 – Отличия стандартов ИСО 9000 и методологии TQM.

ISO 9000 TQM Нет необходимости фокуса на определенного Фокус на определенного потребителя потребителя Не интегрировано в корпоративную стратегию Интегрированная стратегия компании Фокус на технические системы и процедуры Фокус на философию, концепции, инст рументы и методологию Вовлеченность всех сотрудников не обязатель- Подчеркивает необходимость вовлече на ния всех сотрудников Не фокусирует на непрерывном улучшении Непрерывное улучшение и TQM являются синонимами, в результате чего TQM представляется непрерывным и не оканчивающимся путешествием в каче ство Ответственность за качество должна быть Каждый сотрудник ответственен за ка определена и документально оформлена, но чество часто ответственность за качество возлагается на соответствующие подразделения, например, отдел качества Возможность фокуса на подразделения Организация всех подразделений, функ ций и уровней В основном статичен Подразумевает изменение процесса и культуры Стандарты ISO 9000 приняты более, чем в 90 странах мира. Сама ISO не производит сертификацию по ISO 9000, этим занимаются специально сформированные аудиторские организации в отдельных странах. Фактически сертификация производится не по ISO 9000, а по спецификации ISO 9001:2000. Сертификат ISO 9000 необходим предприятиям: работающим на международных рынках или с международными поставщиками, которые требуют наличия такого сертификата;

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

Центральное место в стандарте ГОСТ Р ИСО 9000-2001 «Системы ме неджмента качества. Основные положения и словарь» занимает процесс, как «совокупность взаимосвязанных или взаимодействующих видов деятельно сти, преобразующих входы в выходы».

PDF created with pdfFactory Pro trial version www.pdffactory.com На рисунке 3.4 приведена, основанная на процессном подходе, система менеджмента качества, описанная в семействе стандартов ИСО 9000. Он по казывает, что заинтересованные стороны играют существенную роль в пре доставлении организации входных данных. Наблюдение за удовлетворенно стью заинтересованных сторон требует оценки информации, касающейся восприятия заинтересованными сторонами степени выполнения их потребно стей и ожиданий, т.е. качества выпускаемой продукции. Эта информация оп ределяет стратегию менеджмента.

Рисунок 3.4 – Модель системы менеджмента качества, основанной на процессном подходе В данной модели отражены два основных понятия, которые будут ин тересовать нас дальше: качество и жизненный цикл продукции. Качество степень соответствия присущих характеристик потребностям или ожидани ям, которые могут быть установлены, или обычно предполагаются, или явля ется обязательными (потребность или ожидание могут обозначаться единым PDF created with pdfFactory Pro trial version www.pdffactory.com термином - требование). Стандарт ИСО 9001:2000 выделяет четыре группы процессов, связанных с системой менеджмента качества: процессы управ ленческой деятельности руководства;

процессы обеспечения ресурсами;

про цессы жизненного цикла продукции;

процессы измерения, анализа и улуч шения.

Имеются четыре общие категории продукции: услуги;

программные средства;

технические средства;

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

Европейский Фонд менеджмента качества (EFQM) Некоммерческая организация, созданная в 1987 году четырнадцатью ведущими европейскими компаниями (Bosh, BT, Bull, Ciba-Geigy, Dassault, Electrolux, Fiat, KLM, Nestle, Olivetti, Philips, Renault, Sulzer, Volkswagen) при поддержке Комиссии ЕС. Целью его образования было содействие повыше нию конкурентоспособности европейской экономики путем распространения новых подходов к менеджменту, создание стимулов к обучению его основам и возможностей признавать успехи в этой области. Официальный сайт орга низации - http://www.efqm-rus.ru/first.php, а сайт Российской партнерской ор ганизации EFQM (Всероссийская организация качества) - http://www.efqm rus.ru/first.php.

PDF created with pdfFactory Pro trial version www.pdffactory.com Организация в 1991г. Разработала модель делового совершенствования, которая в настоящее время положена в основу ежегодного конкурса на На граду EFQM за Совершенство (EFQM Excellence Award - ЕЕА)20.

Основы принципы концепции EFQM следующие:

Ориентация на результаты. Совершенство – это достижение резуль татов, которые удовлетворяют все заинтересованные стороны.

Ориентация на потребителя. Совершенство – это создание ценностей для потребителя.

Лидерство и постоянство цели. Совершенство – это видимое и вдох новляющее лидерство в сочетании с постоянством целей.

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

Развитие и вовлеченность персонала. Совершенство – это обеспече ние максимального вклада работников путем их развития и вовлечения.

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

Развитие партнерства. Совершенство – это развитие и поддержка партнерских отношений, добавляющих ценность.

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

В основе модели лежит, так называемая, логика RADAR, которая со стоит из четырех элементов:

• Results- результаты;

• Approach – подход;

В США аналогично присуждается премия Болдриджа, а в Японии - премия Деминга.

PDF created with pdfFactory Pro trial version www.pdffactory.com • Deployment – развертывание;

• Assessment and Review - оценка и пересмотр.

Эта логика устанавливает, что организации необходимо:

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

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

3. Системно развертывать подходы, чтобы обеспечить их полную реализацию.

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

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

Управление успешными программами (Managing Success ful Programmes - MSP) (OGC) /19-21/ Данная методология разработана Office of Government Commerce (OGC) (бывшая CCTA). OGC - независимый офис Казначейства Великобри тании, подотчетный главному секретарю Министерства финансов. OGC раз работал и поддерживает целый ряд программ, целью которых является по PDF created with pdfFactory Pro trial version www.pdffactory.com вышение эффективности работы правительства и гражданского сектора, в целом.

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

MSP различает результат и эффект (суммарную выгоду).

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

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

Программы MSP определяют «Декларируемое видение»22 и «Рабочий проект».

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

Рабочий проект описывает структуру и состав измененной организа ции, которая должна продемонстрировать возможности, выраженные в дек Программа определяется, как ряд связанных друг с другом проектов, управление которыми координируется для достижения преимуществ и степени управляемости, недоступных при управлении ими по отдельности. Программы могут содержать элементы работ, имеющие к ним отношение, но лежащих за пределами содержания отдельных проектов программы. /PMBoK/ Vision Statement – в литературе переводится как «Заявление о видении компании».

Заинтересованное лицо или заинтересованная сторона (stakeholder) –индивидуум или группа лиц, которые будут существенно затронута результатом программы или процессом ее выполнения.

PDF created with pdfFactory Pro trial version www.pdffactory.com ларированном видении (Vision Statement). С точки зрения бизнес - процессов план является детальным описанием организации, людей, информационных систем, инфраструктуры и данных.

Программа MSP определяет:

• Декларированное видение.

• Рабочий проект.

• Экономическое обоснование.

• Организацию.

• Портфель проектов.

• Профили эффектов • Карта заинтересованных сторон.

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

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

Профили эффектов - законченное описание каждого эффекта, ожидае мого от программы.

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

Мероприятия по управлению программами MSP определены стратеги ческим охватом:

Управление качеством;

• Управление заинтересованными сторонами;

• Управление проблемами;

• PDF created with pdfFactory Pro trial version www.pdffactory.com Управление риском;

• Управление эффектом;

• Управление ресурсами;

• Планирование и контроль.

• Проблема (Issue) - трудность, запрос, беспокойство или изменение, ко торое затрагивает программу и требует вмешательства управления и дейст вий для ее решения. Проблемы (в отличие от рисков) неожиданны и могут возникнуть в любое время.

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

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

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

• план программы;

• план реализации эффекта;

• план коммуникации.

План программы включает:

портфель проектов;

описание рисков и прогноз успешного выполнения плана;

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

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

PDF created with pdfFactory Pro trial version www.pdffactory.com MSP определяет следующую последовательность процессов (рисунок 3.5).

Рисунок 3.5 – Последовательность процессов MSP.

Идентификация программы Мандат программы определяет стратегические цели высокого уровня программы. Разрабатывается резюме программы, которое формально одоб ряется главным ответственным владельцем (Senior Responsible Owner – SRO) и спонсирующей группой.

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

Управление программой PDF created with pdfFactory Pro trial version www.pdffactory.com В процессе описаны меры, которые требуются при утверждении и осу ществлении управления программой. Проекты, составляющие программу, и действия по их выполнению сгруппированы в транши. Каждая транша пре доставляет ступенчатое изменение возможностей, которое позволяет оце нить реализацию эффекта. В конце каждого транша определяется точка про верки, в которой программа может быть формально оценена в терминах ее продвижения к цели.

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

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

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

Применение MSP дает возможность получить следующие преимуще ства:

PDF created with pdfFactory Pro trial version www.pdffactory.com Более эффективная реализация изменений, в связи с тем, что их можно спланировать и внедрить интегрированным способом без неблагоприятных последствий на текущие бизнес - операции.

Приведение в соответствие стратегии с уровнем проекта. Эффек тивная реакция на стратегические инициативы путем интеграции стратегии и проектов.

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

Улучшение качества риска менеджмента.

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

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

Повышает эффективность исполнения.

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

Более эффективная координация и контроль комплексной сово купности операций путем четкого определения ролей и обязан ностей по управлению портфелем проекта.

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

Достижение последовательной системы новых или скорректиро ванных правил, стандартов и трудовых практик посредством ин PDF created with pdfFactory Pro trial version www.pdffactory.com тегрированного определения, планирования, поставки и обеспе чения требуемых изменений.

В тоже время, MSP имеет следующие недостатки и ограничения.

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

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

Управление рисками (Management of Risk - M_o_R)/28/ M_o_R был издан в 2002г. Office of Government Commerce (OGC - неза висимый офис Казначейства Великобритании) с целью: "оказания помощи организациям в создании эффективной структуры для выработки и обосно вания решений, связанных с рисками". В 2007г. данная методология была модифицирована. Модификация была вызвана изменениями, происходящими в мире. Авторы приводят, в качестве примера, следующие важные события:

• казначейство Британии пересматривает Оранжевую книгу, в ко торой были определены основные принципы и понятия управле ния риском, используемые в первом выпуске M_o_R);

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

o Combined Code on Corporate Governance, опубликованном в 2006г. в Великобритании, o соглашение 2004г. Базеле II (Банк международных урегу лирований, Швейцария), o методологиЯ Sarbanes-Oxley, опубликованная в 2002г. в США (о ней смотрите ниже).

Как и все методологии, развиваемые и поддерживаемые OGC, M_o_R представляет целую индустрию, которая включает: центр знаний;

публика PDF created with pdfFactory Pro trial version www.pdffactory.com ции;

тренинг (в этой области существует целый ряд аккредитованных цен тров по тренингу);

консалтинг;

аккредитация.

Данный фреймворк был разработан с целью его применения в других методологиях, поддерживаемых OGC: ITIL, PRINCE 2, MSP. На нем основа на концепция управлениями рисками, используемых в рабочих книгах сек ций: Delivery Lifecycle (жизненный цикл поставки), IT Practitioners (ИТ спе циалист-практик) и Procurement (приобретение).

Основные положения и структура фреймворка M_o_R.

Фреймворк представлен четырьмя разделами: принципы (M_o_R prin ciples), подход (M_o_R approach), процесс (M_o_R process), внедрение и оценка (Embedding and reviewing M_o_R).

Надо отметить, что M_o_R понимает риск, как негативное опасное со бытие (угроза), так и позитивные возможности.

Принципы:

• Организационный контекст.

• Вовлечение заинтересованных сторон.

• Организационные цели.

• M_o_R подход.

• Отчетность.

• Роли и обязанности.

• Структура поддержки.

• Индикаторы раннего оповещения (Early warning).

• Цикл анализа.

• Преодоление барьеров при внедрении M_o_R.

• Благоприятная культура.

• Непрерывное усовершенствование.

Методология предусматривает эволюционное развитие этих принци пов. В M_o_R утверждается, что внедрение всех принципов одновременно PDF created with pdfFactory Pro trial version www.pdffactory.com невозможно. Следовательно, необходимо рассмотреть вопросы их поэтапно го внедрения, руководствуясь эффектом, который может дать внедрение того или иного принципа. На рисунке 3.6 показан один из примеров последова тельности применения этих принципов.

Рисунок 3.6 – Диаграмма, реализующая одну из последовательностей внедрения принципов M_o_R.

Подход M_o_R.

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

Политика менеджмента рисков (Risk Management Policy) - определя ет политику управления рисками в организации.

PDF created with pdfFactory Pro trial version www.pdffactory.com Руководство процессов менеджмента рисков (Risk Management Process Guide) – описывает последовательность шагов и действия реализации менеджмента рисков, связанных с ними.

Планы менеджмента рисков (Risk Management Plans) – описания под робностей организационной деятельности менеджмента рисков.

Подход M_o_R определяет такие понятия, как:

• склонность и способность к риску;

• уровень допустимого риска;

• эскалация процедур;

• роли и обязанности;

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

• неотъемлемый риск в сравнение с несистематическим риском.

В старой редакции M_o_R рассматривается четыре категории реакции на риск '4T's' -Transfer – перенос ответственности, Tolerate- допускать, Treat – обходить, Terminate- снижение риска. В новой редакции, используются тер мины, широко распространенные в современной литературе:

• сокращение (reduction);

• удаление (removal);

• передача или перенос ответственности (transfer);

• задержание (retention);

• разделение (share).

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

Процесс M_o_R PDF created with pdfFactory Pro trial version www.pdffactory.com Процесс M_o_R описывается четырьмя простыми шагами (в контексте M_o_R шаги называются процессами):

• идентификация;

• оценка;

• план;

• выполнение.

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

Рисунок 3.7 – Цикл процессов M_o_R.

Для каждого процесса определены следующие параметры (рисунок 3.8):

• цели процесса - ключевые результаты процесса;

• вход процесса - информация, которая будет преобразована про цессом;

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

PDF created with pdfFactory Pro trial version www.pdffactory.com • барьеры процесса - возможные ограничения, которые могут пре пятствовать завершению процесса;

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

• задачи процесса – действия, выполняющие преобразование вхо да в выходы.

Рисунок 3.8 – Параметры процесса.

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

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

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

PDF created with pdfFactory Pro trial version www.pdffactory.com • описание организационных перспектив (в новой редакции M_o_R рассматривает организационные уровни, как четыре взаимодействующие перспективы в пределах их организацион ного контекста);

• секцию методов и технологий;

• секцию контроля готовности (Health check) M_o_R;

• модель зрелости M_o_R (модели зрелости - ценный инструмент, который помогает организовать развитие организации в направ ление эталона, т.е. оценить текущее состояние (зрелость) управ ления риском и понять, как и когда проводить усовершенствова ние);

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

Стандарты в области управления проектов В русском языке понятие «проект» прочно ассоциируется с прототи пом, прообразом предполагаемого или возможного объекта, состояния /34/. В настоящее время, распространяется понимание проекта, как некоторого осо бенного вида деятельности.

Область «Управление проектам» представлена многочисленными стан дартами. Этот факт вполне объясним. Наибольшие затраты и потери в стра тегическом менеджменте связаны с проектами. В качестве примера можно рассмотреть тот факт, что внедрение ERP систем в 50% случаев признаны неудовлетворительными, т.е. данные проекты либо не были доведены до конца, либо выполнены с превышением выделенных ресурсов. В таблице 3. приведены некоторые стандарты в области управления проектами с их крат кой характеристикой /35/.

PDF created with pdfFactory Pro trial version www.pdffactory.com Таблица - 3.4 Перечень стандартов в области управления проектом.

Название стандарта Краткое описание Введение в свод знаний по управлению проектами, разработанное в PMBOK PMI Институте проектного менеджмента (Project Management Institute, (Project Management PMI), США.

Body Of Knowledge) Последняя версия — 2004 год. В разработке четвертое издание (вы ход – 2008 г.) ICB есть на английском, французском, немецком. Был разработан ICB IPMA на основе британских, швейцарских, немецких и французских (International стандартов компетенции. Каждая национальная ассоциация вправе Competence Baseline устанавливать свои стандарты компетенции, базируясь на ICB и International Project местную культуру.

Management Associ 25 стран подписали с IPMA соглашение.

ation) PRINCE изначально был разработан как стандарт для ведения PRINCE государственных ИТ проектов Великобритании, но вскоре он (PRojects IN получил более широкое распространение. PRINCE2 вышел в Controlled Environ как универсальный метод управления проектами. Кроме ments) Великобритании применяется в некоторых областях еще в более Это руководство описывает полный набор процедур и механизмов BSI BS по управлению проектами. Пользователю рекомендуется выбирать (British Standards те элементы, которые наиболее подходят конкретному проекту.

Institution British Основа для планирования и реализации проектов. Имеет широкое Standard 6079) применение во многих областях производства, общественном сек торе.

В Китае PMBOK Guide был принят как базовый, на основе которо C-PMBOK го был разработан национальный стандарт управления проектами (Chinese-PMBOK) С-PMBOK.

Первая версия — 2001 г.Последняя версия — 2006 г.

Определяет основы проектного менеджмента.

DIN DIN сотрудничает с IPMA.

(Deutsches Institut Впервые вышел в 1987 году.

fr Normung 69901) V-Modell был разработан в 1992 году для регулирования создания V-Modell программного обеспечения в немецкой федеральной администра ции.

Современная версия V-Modell является V-Model XT, которая была утверждена в феврале 2005 года.

V-Modell (VEE) представляет собой скорее набор стандартов в области проектов, касающихся разработки новых продуктов.

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

ISO 10006:2003 — Системы управления качеством — Руководство ISO 10006: по управлению качеством в проектах. Разработано Международной (International Организацией по Стандартизации.

Standards Organization) Стандарт разработан для управления космическими проектами в NASA Project 1995 г. (для внутреннего использования).

Management PDF created with pdfFactory Pro trial version www.pdffactory.com Название стандарта Краткое описание Стандарты компетенции для Управления Проектом.

OSCEng Впервые издан в 1997 г. Последняя версия — 1999 г.

(Occupational Stan dards Council for Engineering) GAPPS в январе 2007 объявил о начале внедрения глобальных GAPPS (Global стандартов компетенции для менеджеров проектами. Стандарт был Alliance for Project разработан международной командой специалистов из Performance Stan профессиональных организаций из Азии, Австралии, Европы, dards) standard Северной Америки, России и ЮАР.

PRINCE2 - методология руководства проектом /29, 30/ Первоначально был разработан в 1989г. Central Computer and Telecom munications Agency (CCTA) в Великобритании, как стандарт для руководства IT проектом. Теперь широко используется и является «de facto» стандартом для руководства проектами в Великобритании. В настоящее время PRINCE является торговой маркой OGC (Office of Government Commerce). Методоло гия основывается на PROMPT (Projects, Resources, Organisation, Management of Planning and Technician), методе руководства ИТ проектом, созданным Simpact Systems Ltd в 1975г. PROMPT был принят CCTA в 1979г. как стан дарт для использования во всех правительственных проектах по информаци онным системам. Методология PRINCE2, как и выше перечисленные стан дарты OGC M_o_R, ITIL, MSP, является коммерческим продуктом. Познако миться с условиями использования их можно на официальной странице OGC - http://www.ogc.gov.uk.

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

PRINCE2 признанный в мире продукт международного класса, являю щийся стандартом в области управления проектом. Он воплощает многолет нюю практику управлением проектом. Данный метод руководства проектом PDF created with pdfFactory Pro trial version www.pdffactory.com обеспечивает высокую гибкость и адаптируемость, что позволяет использо вать его в широком спектре областей. PRINCE2 включает большое разнооб разие дисциплин и действий, требуемых для реализации проекта.

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

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

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

В проекте, выполняемом по методологии PRINCE2, есть следующие особенности:

• определен конечный жизненный цикл;

• определены и измеримы результаты проекта;

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

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

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

PRINCE2 не охватывает все аспекты руководства проектом. Из PRINCE2 исключены хорошо представленные в других методологиях аспек ты руководства проектом такие, как: лидерство, управление навыками лю дей, детализированное описание инструментальных средств и методик руко водства проектом.

В данной методологии определено большое количество документов, файлов и списков регистрации. Эти документы могут стать причиной в пло PDF created with pdfFactory Pro trial version www.pdffactory.com хомасштабируемом, маленьком проекте необоснованно большому объему работы. Многообразие ролей и специализация их обязанностей может при вести к конфликтам, особенно, в неуспешном проекте. Поэтому требуется письменное согласование обязанностей ролей в процессе SU (Starting up a project - Старт проекта).

PRINCE2 - метод руководства проектом, ориентированный на процесс ную организацию. PRINCE2 определяет 45 отдельных подпроцессов, кото рые организованы в восемь процессов (рисунок 3.9):

1. Старт проекта (Starting Up a Project - SU).

2. Планирование (Planning - PL).

3. Инициализация проекта (Initiating a Project - IP).

4. Руководство проектом (Directing a Project - DP).

5. Управление и контроль стадиями (Controlling a Stage -CS).

6. Управление поставкой продукта (Managing Product Delivery MP).

7. Управление границами стадий (Managing Stage Boundaries - SB).

8. Закрытие проекта (Closing a Project - CP).

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

SU1 Назначение руководителя правления проектом и руководителя проектом.

SU2 Подбор команды управления проектом.

SU3 Назначение команды управления проектом.

SU4 Подготовка проектного задания.

PDF created with pdfFactory Pro trial version www.pdffactory.com SU5 Определение методов проекта.

SU6 Планирование стадии инициализации.

Рисунок 3.9- Модель процессов PRINCE2.

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

PL1 Разработка плана.

PL2 Определение и анализ продукта.

PL3 Идентификация действий и взаимосвязей.

PL4 Оценка.

PDF created with pdfFactory Pro trial version www.pdffactory.com PL5 Планирование.

PL6 Анализ риска.

PL7 Завершение плана.

Инициализация проекта (IP) Основывается на процессе «Старт процесса» (SU), при этом расширя ется описание действий и проектного задания с целью формирования эконо мического обоснования. Определяется метод, обеспечивающий качество вы полнения проекта, который согласовывается с общим подходом его выпол нения. Создан комплект документов полного плана проекта, который пред ставляется правлению проектом для согласования.

IP1 Планирование качества.

IP2 Планирование проекта.

IP3 Уточнение экономического обоснования и рисков.

IP4 Формирование мероприятий по управлению и контролю проектом.

IP5 Формирование комплекта проектной документации.

IP6 Создание документа инициализации проекта.

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

DP1 Разрешение инициализации.

DP2 Утверждение проекта.

DP3 Утверждение плана стадии или плана исключений.

DP4 Обеспечение специального руководства.

DP5 Санкционирование закрытия проекта.

Управление стадиями (CS) PDF created with pdfFactory Pro trial version www.pdffactory.com PRINCE2 предлагает разбить проект на стадии. Подпроцессы этой группы предписывают, как управлять каждой стадией, при этом фокусирует ся внимание на методах определения группы работ и их санкционирование.

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

CS1 Санкционирование группы работ.

CS2 Оценка прогресса.

CS3 Регистрация проблем проекта.

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

CS5 Обзор состояния стадий.

CS6 Отчет о ключевых моментах проекта.

CS7 Выбор управляющего воздействия.

CS8 Эскалация проблем проекта.

CS9 Прием завершенной группы работ.

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

MP1 Прием комплекса работ.

MP2 Выполнение комплекса работ.

MP3 Выпуск комплекса работ.

Управление границами стадии (SB) Процесс управление стадиями (CS) определяет, что должно быть сде лано в пределах стадии. Управление границами стадии (SB) определяет, что должно быть сделано к концу стадии. Очевидно, что в конце стадии должен быть создан план следующей стадии, при этом полный план проекта, реестр PDF created with pdfFactory Pro trial version www.pdffactory.com рисков и экономическое обоснование, должны по мере необходимости кор ректироваться. Процесс также охватывает действия, которые требуется осу ществить в случае выхода стадий за свои границы. В случае завершения ста дии процесс регламентирует отчетность.

SB1 Планирование стадии.

SB2 Обновление плана проекта.

SB3 Обновление экономического обоснования проекта.

SB4 Обновление реестра рисков (Risk Log).

SB5 Представление отчета об окончании стадий.

SB6 Создание плана исключений.

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

CP1 Прекращение выполнения проекта.

CP2 Идентификация действий доработки в процессе эксплуатации.

CP3 Анализ оценки проекта.

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

Руководство проектом - сложная дисциплина и было бы неправильно предполагать, что слепое применение PRINCE2 приведет к успешному про екту. С другой стороны, можно утверждать, что не все аспекты PRINCE2 бу дут использоваться во всех проектах. Поэтому, для каждого проекта нужно использовать адаптацию PRINCE2 и масштабирование ее принципов в соот ветствии с задачами конкретного проекта. При этом, необходимо определить PDF created with pdfFactory Pro trial version www.pdffactory.com - какие из процессов и как будут использоваться в данном проекте. Масшта бирование проекта дает возможность приспособить PRINCE2 к возможно стям данного проекта, но с другой стороны, велика опасность того, что суще ственные элементы методологии могут быть опущены. Для того, чтобы про тиводействовать отрицательным тенденциям масштабирования, APM Group разработала модели зрелости PRINCE2 /31/. На рисунке 3.9 представлены модели зрелости, зарегистрированные APM Group.

Рисунок 3.9 Модели зрелости PRINCE2.

Модель P2MM (PRINCE2 Maturity Model) включает три уровня зрело сти. Модель определяет ключевые действия, которые являются частью эф фективно организованного процесса управления проектом. Исходя из этого, можно определить те ключевые действия, которые нужно использовать в ор ганизации для достижения следующего уровня зрелости. В модели описана процедура анкетирования организации и дано объяснение возможным ре зультатам этого анкетирования.

PDF created with pdfFactory Pro trial version www.pdffactory.com MINCE2- Модель зрелости проекта /32, 33/ Модель MINCE (акроним Maturity INcrements IN Controlled Environ ments инкремент зрелости в управляемой среде) разработана, для того, что бы:

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

• описать стандартным методом результат оценки проекта;

• указать, что нужно сделать для увеличения уровня зрелости.

В настоящее время версия 1.0 доступна (http://www.xs4all.nl/~meisnerr/test/downloads/quickreference.htm). Представ лен, хотя и в неполном виде, интерактивный справочник, разработанный в QwikiWeb.

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

Уровень зрелости, согласно методике MINCE, может быть оценен на основе трех различных подходов: бронзовый, серебренный или золотой.

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

Он обеспечивает быструю оценку проектной зрелости.

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

MINCE определяет пять уровней зрелости (в соответствии с моделью EFQM):

• действия, • процессы, PDF created with pdfFactory Pro trial version www.pdffactory.com • системы, • цепочки поставок, • качество.

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

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

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

• Золотой отчет: Включает большое количество секретной инфор мации, основанной на интервью сертифицированными специали стами по золотому MINCE. Эти специалисты являются служащими организации.

Для увеличения уровня зрелости организации MINCE определяет семь разновидностей типов действий (Action Flavors). Выбор типов действий ос нован на результатах отчетов. Обычно, несколько из этих типов доминируют, другие относят к менее срочным. Разновидности типов действий были опре делены в работах профессора A. Cozijnsen:

• AF1: Ускорение • AF2: Расширение • AF3: Углубление PDF created with pdfFactory Pro trial version www.pdffactory.com • AF4: Сохранение • AF5: Адаптирование • AF6: Взаимодействие • AF7: Детализирование (Explicitation ) Модель MINCE основана на представлении организации в виде шести башен (рисунок 3.10). В модели, башни организации образно сравниваются с фортификационными укреплениями, при этом, высота башни ассоциируется с уровнем зрелости проекта:

Башня I: Люди;

Башня II: Методы и технологии;

Башня III: Клиент;

Башня IV: Реализация;

Башня V: Знание;

Башня VI: Службы поддержки.

Рисунок 3.10 – Башни MINCE.

В модели MINCE определены пять критериев ассоциированных с баш нями, каждый из критериев представляет различную перспективу (рисунок 3.11):

Критерий A: Лидерство;

Критерий B: Штат;

PDF created with pdfFactory Pro trial version www.pdffactory.com Критерий C: Политика;

Критерий D: Средства;

Критерий E: Инструкции.

Рисунок 3.11 – Критерии, ассоциированные с башнями MINCE.

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

Управление проектом (PMBoK PMI) /36/ Институт управления проектами (Project Management Institute - PMI) был основан в 1969г, первоначально для того чтобы определить общие прак тики в проектном менеджменте в различных отраслях. Сегодня он объединя ет в ассоциацию более 260000 участников из 171 страны мира. В нашей стра не действует московское, санкт- петербургское и иркутское отделение PMI.


(сайт московского отделения http://www.pmi.ru/)/ Первое издание PMBOK24 было опубликовано в 1987г. Оно явилось ре зультатом семинаров, инициированных в начале 80-х гг. PMI. Параллельно Project Management Body of Knowledge (Свод знаний по управлению проектом) (PMBоK) PDF created with pdfFactory Pro trial version www.pdffactory.com был разработан Моральный кодекс и критерии для аккредитации центра под готовки и аттестации. Позже был опубликован второй вариант PMBOK (1996г. и 2000г.), на основании комментариев, полученных от членов.

PMBOK был признан в качестве стандарта Американским национальным ин ститутом по стандартам (ANSI) в 1998г. и позже Институтом инженеров по электротехнике и электронике (IEEE). Третий вариант PMBOK был опубли кован в 2004г., со значительными улучшениями в структуре документа, до бавлениями к процессам, терминами и доменами программы и портфеля.

Институт управления проектами использует PMBOK в качестве осно вы для построения вледующих направлений деятельности образующих ин дустрию PMI:

• сертификация профессионалов по управлению проектами (РМР);

• образование и обучение в области управления проектами, пре доставляемое зарегистрированными провайдерами обучения PMI (PMI Registered Education Providers, R.E.P.);

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

Поскольку данный стандарт рассматривается как базовое справочное руководство, он не является всеобъемлющим или исчерпывающим. В допол нение к PMBoK, а также для адаптации его к конкретным условиям, PMI бы ли разработаны следующие материалы:

1. Government extension to PMBoK. Управление проектами со сто роны правительств.

2. Construction extension to PMBoK. Управление проектами в строи тельстве.

3. Practice Standard for Earned Value Management. Эта методология включает описание плана, расписания, затрат проекта.

Применима для всех областей знаний.

PDF created with pdfFactory Pro trial version www.pdffactory.com 4. Practice Standard for Project Configuration Management. РСМ опи сывает содержимое проекта, необходимую документацию.

5. Practice Standard for Work Breakdown Structures - Second Edition.

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

6. DoD Project Management (Department of Defence Project Manage ment). Ведение проектов в Министерства обороны США (адапти рованный вариант PMBOK для нужд министерства).

7. The Standard for Program Management. Нацелен на предоставление детального описания программного управления, а также на эф фективные коммуникации и координацию между группами.

8. Project Manager Competency Development Framework Был создан в помощь менеджерам проектов для понимания и усовершенство вания своих компетенций.

9. Organizational Project Management Maturity Model (OPM3). Пре доставляет механизмы, необходимые организациям для измере ния своей зрелости по отношению к организации передовой практике ведения проектов.

10. The Standard for Portfolio Management. Создан для руководства по процессам, которые обычно считаются наилучшими практиками в портфельном менеджменте. Сфокусирован на портфельном управлении в программном и проектном менеджменте.

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

«Временное предприятие» означает, что данная деятельность опреде ленные во времени точки начала и завершения.

PDF created with pdfFactory Pro trial version www.pdffactory.com «Уникальность продукции и результата» означает, что данная группа достигает этого результата в данных условиях только один раз. В после дующих случаях или группа или условия или задачи будут отличаться от этого проекта. Интересно, что возведение типового здания тоже относится к проекту.

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

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

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

PDF created with pdfFactory Pro trial version www.pdffactory.com Рисунок 3.12 – Экспертные области, необходимые для команды управ ления проектом.

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

PDF created with pdfFactory Pro trial version www.pdffactory.com от нее ожидается. В конце фазы проводится анализ26, в результате которого получают разрешение на закрытие фазы и на инициализацию следующей фа зы. На рисунке 3.13 отображена связь между результатами поставки фаз и проекта и жизненным циклом проекта и жизненным циклом продукта проек та, который используется в операционной деятельности бизнес процессов.

Рисунок 3.13 – Жизненный цикл проекта (показаны результаты постав ки фаз) и жизненный цикл продукта проекта.

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

заказчик/пользователь;

исполняющая организация;

члены команды проекта;

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

спон сор;

источники влияния27, офис управления проектом (PMO).

"выход из фазы" (phase exit), "межфазовые шлюзы" (phase gates), "точки критического анализа" (kill points).

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

PDF created with pdfFactory Pro trial version www.pdffactory.com Указывается, что если даже организация не выполняет самостоятельно проект уровень ее организационной зрелость, а именно зрелость ее системы управления проектами, культуры, стиля, организационной структуру оказы вает существенное влияние на ход выполнения проекта.

Основной структурной единицей проекта является процесс. Процесс это ряд взаимосвязанных действий и операций, выполняемых для достиже ния заранее определенных продуктов, результатов или услуг. Процессы управления проектом подразделяются на два вида: процессы общие для большинства проектов и процессы, ориентированные на продукт. Процессы, ориентированные на продукт определяются из жизненного цикла проекта и являются индивидуальными для каждого проекта. Данный стандарт посвя щен процессам общим для большинства проектов. Эти процессы с одной стороны объединены в группы28, а с другой стороны их взаимодействие об разует элементы, называемые областями знаний29. Эти два измерения обра зуют среду организации PMBoK. В третей главе рассматриваются группы процессов, а в четвертой области знаний.

Процесс управления проектом представлены в виде отдельных элемен тов с точно определенным интерфейсом. Идея взаимодействия процессов ос нована на цикле У. Деминга «Планирование-исполнение-проверка воздействие». В соответствии с этим процессы объединяются в пять групп (рисунок 3.14):

• Группа процессов инициации. Определяет и авторизует проект или фазу проекта.

Группа процессов управления проектом (Project Management Process Group) Логическое объединение процессов управления проектом, описанное в руководстве к своду знаний по управлению проектами Область знаний по управлению проектами (Project Management Knowledge Area) Особая область управления проектами, определяемая ее требованиями к знаниям и описываемая в терминах ее составных процессов, практик, входов, выходов, инструментов и методов.


PDF created with pdfFactory Pro trial version www.pdffactory.com • Группа процессов планирования. Определяет и уточняет цели и планирует действия, необходимые для достижения целей и со держания, ради которых был предпринят проект.

• Группа процессов исполнения. Объединяет человеческие и другие ресурсы для выполнения плана управления проектом дан ного проекта.

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

• Группа завершающих процессов. Формализует приемку про дукта, услуги или результата и подводит проект или фазу проекта к правильному завершению.

Рисунок 3.14- Взаимосвязь групп процессов.

На рисунке 3.15 приведена общая схема взаимодействия групп процес сов.

PDF created with pdfFactory Pro trial version www.pdffactory.com Рисунок 3.14 – Детализированное взаимодействие между группами процессов.

PDF created with pdfFactory Pro trial version www.pdffactory.com На рисунке приведены не все потоки данных и не все взаимодействие между процессами. В тоже время данная схема дает полную картину взаимо действия процессов. В PMBoK отмечается, что каждая группа процессов вы полняется равномерно не на всем протяжении проекта. Так, например, на на чальных фазах проекта наибольшая доля работ ложиться на группу процес сов планирования, в то время как в конце проекта - на группу процессов за вершения.

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

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

2. Управление содержанием проекта: связано с определением и контролем того, что включено или не включено в проект.

3. Управление сроками проекта: включает процессы, обеспечи вающие своевременное завершение проекта.

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

5. Управление качеством проекта: осуществляется на основе сис темы управления качеством при помощи правил и процедур, а также действий, направленных на постоянное улучшение процес са, предпринимаемых на всем протяжении выполнения проекта.

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

PDF created with pdfFactory Pro trial version www.pdffactory.com 7. Управление коммуникациями проекта: процессы, необходи мые для обеспечения своевременной и соответствующей подго товки, сбора, распределения, хранения, выборки и конечного размещения проектной информации.

8. Управление рисками проекта: процессы, относящиеся к плани рованию управления рисками, их идентификации и анализу, реа гированию на риски, мониторингу и управлению рисками проек та.

9. Управление поставками проекта: процессы закупки или при обретения тех необходимых продуктов, услуг или результатов, которые производятся вне команды проекта (рассматриваются с двух точек зрения: продавца и покупателя).

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

Руководство по менеджменту качества при проекти ровании (ГОСТ Р ИСО/МЭК 10006-2005) /37-39/ Стандарт представляет собой руководство по менеджменту качества при проектировании. В нем выделяются для этой специфической области принципы и методы управления качеством, применение которых важно для достижения целей менеджмента качества. Стандарт должен рассматриваться как развитие принципов и практических методов стандартов серии ИСО 9000. Поэтому он ссылается на руководство по процессному подходу и на описания процессов качества проектируемой продукции, изложенные в ИСО 9004. Качество рассматривается в двух аспектах: качество процессов проекта и качество проектируемой продукции. Кроме того акцентируется внимание на применение системного подхода при создании качества процессов и про ектируемой продукции.

PDF created with pdfFactory Pro trial version www.pdffactory.com Хотя основной структурной единицей стандарта является процесс, концепция стандарта существенно отличаются от концепций управления проектом, изложенные в PMBoK, начиная с определения проекта.

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

Если в PMBoK уникальность определяется уникальностью выхода проекта, то в ИСО 10006 уникальность относится к процессам проекта. В тоже время акцентируется внимание на ограниченность сроков, стоимости и ресурсов30.

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

Проектам присущи следующие особенности:

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

• проекты обладают некоторой степенью риска и неопределенно сти;

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

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

• персонал для выполнения проекта может быть принят в проект ную организацию на время выполнения проекта (в процессе про Ресурсы — это оборудование, комплектующие изделия, финансы, информация, материалы, программное обеспечение, персонал, услуги и площади.

PDF created with pdfFactory Pro trial version www.pdffactory.com екта персонал, как и проектная организация, могут быть измене ны);

• проект может со временем быть изменен под воздействием внут ренних и внешних факторов.

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

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

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

• ориентация на потребителя;

• руководство;

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

• процессный подход;

• системный подход к менеджменту;

• постоянное улучшение;

• принятие решения основанного на фактах;

• взаимовыгодное отношение с поставщиками.

PDF created with pdfFactory Pro trial version www.pdffactory.com Рисунок 3.15- Группы процессов стандарта ИСО Р 1006-2005.

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

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

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

• владельцев процессов и установить их полномочия и ответствен ность;

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

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

PDF created with pdfFactory Pro trial version www.pdffactory.com Заключение В данной главе приведен вариант классификации стандартов и фрейм ворков, используемых в области информационного менеджмента. Также здесь приводится описание стандартов в области менеджмента качества и управления проектов. В четвертой главе будут приведены некоторые фрейм ворки в области архитектуры предприятия и архитектуры информационных систем. В пятой главе приводятся некоторые стандарты в области создания ИТ инфраструктуры и ИТ сервис менеджмента. Формат учебного пособия не позволяет привести описание всех известных стандартов, методологий и ме тодик в такой обширной области, определенную нами в первой главе как об ласть информационного менеджмента.

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

PDF created with pdfFactory Pro trial version www.pdffactory.com 4. Методологии разработки и построения архитектуры предприятия, информационных систем и ПО В данной главе не ставится задача дать полный обзор существующих методологий в области построения архитектуры. В настоящее время данная область представлена в мире большим количеством методологий, стандартов и фреймворков. Описание некоторых из них занимает несколько десятков страниц, других - несколько сот страниц. В данной главе, в качестве приме ров, приводятся немногих методологии построения и описания архитектуры предприятия, информационных систем и программного обеспечения.

Архитектурный фреймворк консорциума Open Group (ТOGAF) /42/ TOGAF (The Open Group Architecture Framework31) - является методо логией32 разработки и построения архитектуры предприятия, состоящей из совокупности детальных методов и ряда инструментов поддержки, создан ных с целью. Данная методология разработана консорциумом OMG (Object Management Group), которая владеет всеми правами на этот продукт. В силу этого, TOGAF может использоваться свободно любой организацией, желаю щей разработать архитектуру своего предприятия.

TOGAF версии 1 была создана в 1995 на основе технических архитек турных фреймворков для информационного менеджмента (the Technical Ar chitecture Framework for Information Management - TAFIM), который был Framework — термин, имеющий размытое значение. Обычно используется в программировании, обозначая "простую концептуальную структуру, используемую для решения сложной, проблемной задачи".

Значение этого термина существенно зависит от контекста его использования. Часто этот термин не переводится /ВИКИПЕДИЯ/. В данном пособии framework может называться: фреймворк или структурный каркас.

Методология (от метод и... логия) - учение о структуре, логической организации, методах и средствах деятельности /34/.

PDF created with pdfFactory Pro trial version www.pdffactory.com поддержан Министерство обороны США (DoD - Department of Defense). В результате целенаправленных инвестиций правительства США на основе TAFIM был разработан TOGAF.OMG ежегодно публикует на своем вебсайте новые версии данного продукта.

«Архитектура» имеет размытое толкование. Ниже приводится опреде ление архитектуры из различных источников:

• «организационная структура системы, определяющая разбиение системы на части, связи между этими частями, механизмы взаи модействия и основные руководящие принципы для проектиро вания системы» /18/;

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

• «программная архитектура представляет собой набор существен ных решений касающихся организации программной системы, таких как: выбор структурных элементов и их интерфейсов, из которых слагается система;

поведение, определяемое взаимодей ствием этих элементов;

объединение этих структурных и функ циональных элементов в более крупные подсистемы;

архитек турный стиль, исповедуемый в данной организации» /41/.

Приведем еще несколько определений архитектуры данных в /17/:

• «в индустрии ИТ нет одного, единственно правильного стандарта на определение архитектуры ИТ, поэтому общие соглашения внутри организации важнее теоретической точности»- Giga Group;

• «архитектура – это инвестиция в стандарты процессов, техноло гий и интерфейсов в целях улучшения возможностей организа ций и уменьшения стоимости разработки и сопровождения ин PDF created with pdfFactory Pro trial version www.pdffactory.com формационных систем, при этом преимущества инвестиций в ар хитектуру распространяются на несколько проектов сразу, но не все эти проекты могут быть известны в момент разработки архи тектуры» »- Giga Group;

• «архитектура – это общий план или концепция, используемая для создания системы, такой как, здание или информационная сис тема;

абстрактное описание системы, ее структуры, компонентов и их взаимосвязей;

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

TOGAF строго не поддерживает терминологию стандарта ANSI/IEEE 1471-200033. В TOGAF термин "архитектура", в зависимости от контекста ее использования, имеет два значения • формальное описание системы, или детальный план системы на компонентном уровне, которое можно использовать в качестве руководства по реализации этой системы;

• структура компонентов и их взаимосвязей, принципы и норма тивы управления их проектирования, а со временем и их разви тия.

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

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

Концепции стандарта ANSI/IEEE 1471-2000 развиты в стандарте ISO/IEC 42010:2007 Systems and software engineering - Recommended practice for architectural description of software-intensive systems PDF created with pdfFactory Pro trial version www.pdffactory.com Сегодняшние CEO34 знают, что эффективное управление и эксплуата ция информации c помощью информационных технологий является ключом к успехам в бизнесе, а также обязательным средством для достижения пре имуществ в конкурентной борьбе. Архитектура обеспечивает стратегический контекст развития ИТ системы в ответ на постоянно изменяющиеся потреб ности окружающей бизнес - среды. Хорошая (эффективная) архитектура предприятия позволит достигнуть правильного баланса между эффективно стью ИТ и новшествами в бизнесе.

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

• более эффективны действия IT:

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

o увеличенная мобильность приложений;

o улучшенная интероперабильность и удобство управлением системой и сетью;

o совершенствование возможности решать проблемы мас штаба предприятия, подобно безопасности;

o более легкая модернизация и обмен компонентами систе мы;

• лучшую отдачу существующих инвестиций, уменьшение риска будущих инвестиций:

o уменьшенная сложность ИТ инфраструктуры;

o максимальный возврат инвестиций в существующую ИТ инфраструктуру;

Chief Executive Officer - генеральный директор (корпорации), директор-распорядитель (фирмы), директор (предприятия) /Lingvo 12/.

PDF created with pdfFactory Pro trial version www.pdffactory.com o гибкость в выборе решения в ИТ: покупка, выполнение или аутсорсинг;

o полное устранение риска в новых инвестициях и издержек использования ИТ;

• более быстрое, простое и более дешевое приобретение:

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

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

В TOGAF рассматриваются четыре вида "архитектуры", которые обычно принимаются как подмножества полной архитектуры предприятия:

• бизнес - архитектура;

• архитектура данных;

• архитектура приложений;

• технологическая архитектура.

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

Версия Enterprise TOGAF является фреймворком (каркасом или струк турой) архитектуры, который включает ряд методов и инструментов для раз работки широкого диапазона различных аспектов ИТ архитектуры. Это по зволяет пользователям ИТ проектировать, оценивать и строить правильную архитектуру их организации, что уменьшает затраты на планирование, про ектирование и реализацию архитектурных решений, основанных на откры тых системных решениях.

Центральное место в TOGAF занимает надежный, основанный на прак тике метод – «Метод построения архитектуры TOGAF» (Architecture Devel opment Method - ADM), который используется для того, чтобы определить PDF created with pdfFactory Pro trial version www.pdffactory.com потребности бизнеса в архитектуре, осуществить разработку архитектуры в соответствии с этими потребностями, используя как элементы TOGA, так и другие архитектурные активы, доступные организации.

Многие архитектурные фреймворки уровня предприятия уже сущест вуют и широко признаны. Каждый из них имеет свои специфические пре имущества и недостатки. Они обсуждены в части IV «Ресурсная база, другие архитектуры и фреймворки».

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

Метод, который может быть использован при построении любого признанно го фреймворка предприятия, по мнению архитектора, является применимым и при построении специализированной архитектуры. В качестве примеров общепризнанных фреймворков можно привести: Zachman Framework /43-45/, Federal Enterprise Architecture Framework (FEAF) /46/, Treasury Enterprise Ar chitecture Framework (TEAF) /47/ и C4ISR/DoD Framework.

TOGAF ADM не предписывает определенный набор материалов по ар хитектуре предприятия - хотя он описывает набор в конкретном примере.

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

Фактически, TOGAF не предписывает определенный набор "представ лений архитектуры". Он описывает таксономию (иерархическую структуру) примера для видов представлений, так, чтобы архитектор мог продумать и обосновать свою разработку. Формулируются руководящие принципы, осно PDF created with pdfFactory Pro trial version www.pdffactory.com вываясь на которые, архитектор может выбрать фреймворк, а для выбранно го структурного каркаса разработать специальное представление.



Pages:     | 1 || 3 | 4 |   ...   | 5 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

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