Процедуры управления программой


Содержание

11.4. Управление программами и портфелями проектов

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

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

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

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

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

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

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

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

Программа и портфель проектов — инструменты реализации стратегического плана организации.

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

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

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

Рис. 11.4. Области применения управления портфелями проектов

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

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

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

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

— куратор (директор) программы. Отвечает за стратегию и политику ее реализации, поддержку программы внешним окружением;

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

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

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

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

Группы процессов управления программой перечислены ниже:

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

— процессы планирования. Определяется оптимальный план действий для достижения выгод и выполнения объема работ по программе;

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

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

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

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

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

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

— общие требования к разработке документов, утверждению документации и решений в рамках программы;

— общий подход к управлению изменениями;

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

— общие подходы к управлению рисками, проблемами, выгодами;

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

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

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

Рис. 11.5. Жизненный цикл программы

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

Анализ осуществимости и обоснование программы включает:

— определение целей программы и их соответствия стратегическим целям организации;

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

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

— согласование и утверждение устава программы ключевыми заинтересованными сторонами;

— утверждение совета управления программой;

— назначение руководителя программы;

— разработка плана запуска программы.

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

Как правило, при принятии решения об одобрении (отклонении) программы рассматриваются следующие факторы:

— стратегическое соответствие долгосрочным целям организации;

— анализ выгод: определение выгод, планирование их достижения;

— предварительный бюджет, необходимый для реализации программы;

— общий объем доступных ресурсов;

— риски, связанные с программой.

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

Результатами первого этапа жизненного цикла являются:

— решение переходить к следующему этапу реализации;

— устав программы, где фиксируется видение, ключевые цели, ожидаемые выгоды, ограничения по программе и предположения, которые будут учитываться при планировании;

— назначение руководителя программы;

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

— план этапа «Определение программы».

Второй этап: определение программы. Цель второго этапа — создать и согласовать с основными заинтересованными сторонами план управления программой. К работам второго этапа можно отнести:

— уточнение соответствия миссии, видения, ценности программы целям организации;

— дополнительную проработку и оценку технической и экономической осуществимости программы;

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

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

— определение предварительной команды управления программой.

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

— формирование команды программы;

— формирование офиса управления программой;

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

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

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

Четвертый этап: исполнение программы и достижение выгод. Цель этого этапа — инициировать проекты, входящие в состав программы, и координировать цели для достижения запланированных выгод.

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

На этом этапе выполняются следующие работы:

— формирование структуры проектов в рамках программы;

— создание организационных структур и запуск процессов контроля исполнения проектов;

— обеспечение менеджерами проектов определенной методологии управления ими;

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


— анализ прогресса (динамики продвижения) в реализации плана программы;

— определение изменений, которые могут повлиять на управление программой или запланированные выгоды;

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

— определение рисков и проведение соответствующих действий по их уменьшению;

— определение проблем и проведение корректирующих воздействий;

— координация эффективного использования ресурсов в программе и проектах;

— обзор запросов на изменения и одобрение дополнительных работ (при необходимости);

— коммуникации с участниками и советом управления программой.

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

— обсуждение выгод с участниками и куратором программы;

— мотивация и роспуск команды программы: должно быть сделано все необходимое для перевода членов команды на другие работы;

— демонтаж инфраструктуры: должно быть сделано все необходимое для перевода ресурсов (оборудования) с целью их дальнейшего использования;

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

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

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

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

— согласование проектов и других компонентов портфеля в соответствии со стратегией;

— обеспечение сбалансированности проектов между собой как частей одного портфеля;

— оценка стоимости и взаимосвязей проектов портфеля;

— определение доступности ресурсов и расстановка приоритетов;

— включение проектов в портфель и исключение их из портфеля.

Рис. 11.6. Процессы и взаимосвязи управления портфелем проектов

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

1)наблюдательный совет управления портфелем;

2)менеджер (директор) портфеля проектов;

3)офис управления портфелем проектов.

В стандартах PMI процессы управления портфелем представлены двумя группами:

1)группа процессов выравнивания портфеля включает процессы управления им, позволяющие оценить проекты и принять решение о включении/исключении их из состава портфеля;

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

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

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

Delay(l) — задержка выполнения программы на 1 миллисекунд.

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

Пример. Halt(N) — прекращение выполнения программы и передача управления системе программирования (если выполнялся .PAS-файл) или DOS (если выполнялся .ЕХЕ-файл). N — код завершения программы, передаваемый в операционную систему.

ПРОЦЕДУРЫ И ФУНКЦИИ ДЛЯ УПРАВЛЕНИЯ ПРОГРАММОЙ

Дата добавления: 2014-11-27 ; просмотров: 340 ; Нарушение авторских прав

halt(результат) выход из программы, результат — код завершения (целое число)
exit выход из процедуры или функции пользователя
break выход из цикла
readkey остановка программы до нажатия клавиши; значение функции — код нажатой клавиши (символа); символ клавиши на экране монитора не отображается.
delay(время) остановка программы; время — время задержки (миллисекунды (мс)) 1 мс. = 1 / 1000 с.

Округленные значения частоты звука для нот октавы, герц (процедура sound(n))

Нота Частота (малая октава) Нота Частота (первая октава)
До До
Ре Ре
Ми Ми
Фа Фа
Соль Соль
Ля Ля
Си Си
До До

ОПЕРАЦИИ НАД ЧИСЛАМИ

ФУНКЦИИ

1.0

Функция Назначение Пример вызова Результат
abs(число) абс. значение числа abs(-3.5) +3.5
arctan(тангенс-угла) арктангенс числа arctan(0)
cos(угол) косинус угла(рад.) cos(pi) -1
exp(число) Экспонента exp(1) 2.718281828.
frac(число) дробная часть числа frac(3.5) 0.5
int(число) целая часть числа int(3.5) 3.0
ln(число) нат. Логарифм ln(2.718281828)
odd(число) проверка нечетности odd(3) True
pi число пи pi 3.141592.
random(число) “случайное” число random(10) Число в [0;10]
sin(угол) синус угла(рад.) sin(pi)
sqr(число) квадрат числа sqr(2.0) 4.0
sqrt(число) квадратный корень sqrt(25.0) 5.0

ПРОЦЕДУРЫ

Процедура Назначение Пример вызова Результат
inc(число) увеличить на 1 inc(n) n := n + 1
dec(число) уменьшить на 1 dec(n) n := n — 1

СТРУКТУРЫ ДАННЫХ

СТРОКИ

Модель организации данных строки (s[0]=длина строки, 0

Каркас управления программой

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

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

  • Новые возможности, продукты и услуги.
  • Бизнес-план.
  • Стратегические цели.
  • Изменение.
  • Прочие инициативы.

Определения управления программами

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

Центральное агентство по вычислительной технике и телекоммуникациям (CCTA)

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

Группа управления программами (PMG)

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

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

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

«Интерактивное выполнение проекта», Роберт Баттрик

Определение: Управление программой проектов – ключевая задача управления, так как эта группа проектов переведет вас из нынешнего состояния в лучшее будущее.
В своей книге «Интерактивное выполнение проектов» Роберт Баттрик определяет три разных вида программ:

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

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

Сообщество по управлению проектами (APM)

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

В своей статье «Осмысление управления программами» Гленн Стрейндж определяет три критических ошибки.

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

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

Цели управления программой

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

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

  • Установка базового плана.
  • Согласование должностных обязанностей.
  • Планирование программы.
  • Определение приоритетов проекта.
  • Взаимодействие с заинтересованными лицами.
  • Отчетность о ходе работ.
  • Управление выгодами.
  • Управление качеством.
  • Управление риском.
  • Разрешение проблем.
  • Завершение программы.

Основы

Управление программой – средство контроля над управлением проектами. Группа связанных проектов, не управляемых как программа, скорее всего, сойдет с верного пути и не даст желаемого результата. В основе управления программой имеется восемь важных сфер:

  • Концепция
  • Цели и задачи
  • Масштаб
  • Структура
  • Подход
  • Управление ресурсами
  • Обязанности
  • Реализация выгод


Кратко рассмотрим каждую сферу поочередно.

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

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

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

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

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

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

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

Рисунок 1. Каркас управления программой

  • Направленность на выработку крупных организационных изменений или выгод.
  • Больший контроль за счет видимости всех проектов в программе.
  • Понимание зависимостей проекта.
  • Четко определенные должностные обязанности.
  • Единственную линию коммуникации с управляющим комитетом или спонсором.
  • Оптимальное использование ресурсов во всех проектах.
  • Использование эффекта масштаба и максимизацию ценности.
  • Управление риском во всех связанных проектах.
  • Механизмы оценки реализации выгод.

В данном каркасе имеется 4 стадии.

Четыре стадии

В управлении программой имеется четыре стадии:

  1. Установление программы.
  2. Планирование программы.
  3. Выработка программы.
  4. Завершение программы.

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

Рисунок 2. – Схема стадий управления программой

Стадия 1: Установление программы

Это высокоуровневый процесс, в ходе которого определяются стратегия и направление организации. Исходя из них, определяются программы, призванные реализовать эти стратегии. Для каждой программы вырабатывается документ, описывающий экономическое обоснование, согласование со стратегией, масштаб и ожидаемую коммерческую цель или выгоды. Все выгоды должны быть рассортированы по их важности. Предлагается три категории – A, B и C. К A относятся наиболее ценные выгоды, обычно 20% программы вырабатывают 80% выгод. К B относятся выгоды, считающиеся важными, но не обязательными. К C относятся выгоды, отсутствие реализации которых не скажется на успехе программы. Данная классификация используется руководителем программы для оценки степени успешности, достигнутой к концу программы.

Стадия 2: Планирование программы

На этапе планирования происходит проектирование программы. Руководитель программы при установлении программы делает следующее:

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

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

Стадия 3: Выработка программы

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

Стадия 4: Завершение программы

Как и проекты, программы имеют ограниченную продолжительность и завершаются после того, как они достигают своих определенных коммерческих целей или выгод. Перед завершением программы руководитель программы должен показать управляющему комитету или руководству, что желаемые выгоды были реализованы, обычно это называется реализация выгод. Речь идет о выгодах, определенных на первой стадии, установление программы. Так как выгоды были рассортированы, измерить успех легко, например, 100% выгод категории ‘A’ было реализовано. В качестве финальной задачи руководитель программы должен просмотреть все программу и задокументировать любые извлеченные уроки, которые обеспечат эффективное выполнение последующих программ.

Вывод

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

Управление процессами

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

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

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

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

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

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

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

5. Диспетчер (ядро) компонент управляющей программы, которыйзапускает на выполнение какой-либо процесс.

Рис. 2.1. Компоненты управляющей программы реального времени

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

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

2. Тактовый уровень уровеньприоритетов системных процессов, который присваивается периодическим процессам.

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

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

Управление процессами – это выбор процесса на выполнение, выделение для него ресурсов памяти, процессора и запуск процесса.

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

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

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

Рис. 2.2. Действия управляющей программы при запуске процесса

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

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

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

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

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

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

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

Процедуры управления программой

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

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

Проверьте и утвердите программу, убедитесь в следовании стандартам и в соответствии видению.

Убедитесь, что проводятся регулярные проверки и в наличии подотчётности, а также в наличии руководства проектов, стейкхолдеров и поставщиков.

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

Выследите основные издержки вместе с административными издержками программы.

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

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

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

Отличия от управления проектами

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

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

Другое видение [4] состоит в том, что программа всего лишь либо большой проект, либо набор (или портфель) проектов. В таком случае целью использования программы является использование положительного эффекта масштаба и снижение координационных издержек и рисков. Задача менеджера проекта — успешно завершить свой проект. Менеджер программы, с другой стороны, может не интересоваться индивидуальными проектами, но он озабочен совокупным результатом или конечным состоянием. Например, программа финансового института может включать в себя проект, который направлен на использование преимуществ растущего рынка, а другой — на защиту от неблагоприятных сторон падающего рынка. Эти проекты противоположны по своим успешным исходам, но входят вместе в одну и ту же программу.

В соответствии с видением, где результатом программ являются последствия, а проектов — продукты, менеджмент программ заинтересован в выполнении нужных проектов. Менеджер программы сравнивается с игроком в шахматы, а проекты — используемые или жертвуемые фигуры [5] . Менеджмент проектов, напротив, заинтересован в правильном выполнении проектов. И также в соответствии с этим видением, успешные проекты выполняются вовремя в рамках бюджета и требований, в то время как успешные программы приносят долгосрочные улучшения организации. Улучшения обычно выявляются через пользу, которую они приносят. Организация должна выбрать группу программ, которые наиболее близко соответствуют её стратегическим целям, в то же время оставаясь в рамках своих возможностей. С другой стороны, видение программы как просто большого проекта или набора проектов предполагает, что программа должна быстро принести осязаемую пользу.

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

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

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

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

Множество программ занимаются созданием возможности для изменения. Польза от этого будет только тогда, когда возможность передаётся линейному руководству и применяется головной организацией. То есть, программная команда сама не может принести пользу. Польза есть только от использования новой возможности.

Программы, как правило, создаются для выполнения стратегических целей, например стать четвёртым по размеру супермаркетом в регионе к 2015 году или снизить потери на 5% за два года.

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

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


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

Главным отличием между программным и проектным управлением является сама природа проекта [6] — у проекта всегда есть конкретная дата завершения, иначе это выполняющаяся программа.

Одно из видений на различия между проектом и программой в бизнесе таково:

  1. Проект уникален и ограничен во времени. Программа не прекращается и выполняется согласно бизнесу для достижения определённых результатов.
  2. Проект предназначен для достижения результатов (output или deriverable) и его успех зависит от достижения нужного результата в нужный срок и по нужной цене.
  3. Программное управление включает в себя управление проектами, что, в целом, улучшает производительность организации. Успех программы измеряется выгодой (benefit).
  4. Выгода является мерой улучшения организации и может включать в себя увеличенный доход, увеличенную прибыль, сниженные издержки, сниженные потери или урон окружающей среде, увеличение числа удовлетворённых клиентов. Для федеральных и местных правительственных организаций выгода может заключаться в лучшем качестве предоставления услуг обществу.
  5. На пути достижения нужных результатов бизнес-программы уясняют бизнес-ограничения и определяют нужные для достижения целей процессы на основании имеющихся ресурсов. Улучшение процессов — это непрерывная операция, что сильно отличает программу от проекта.
  6. На самом нижнем уровне менеджеры проектов управляют индивидуальными проектами. Они находятся под контролем менеджера программы, который отчитывается спонсору (или совету директоров).
  7. Как правило для изменения предустановленных рамок проекта существует процесс. Программа приходится реагировать на изменения в стратегии и на изменения в среде, в которой меняется организация.

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

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

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

Дополнительные факты

C 2007-го года PMI на основе «Standard for Program Management» проводит аттестацию менеджеров программ — PgMP® (Program Management Professional)

Управление программой аудитов

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

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

Последовательность процессов управления программой аудитов приведена на рис. 8 [28], который иллюстрирует также применение цикла PDCA к управлению программой аудитов.

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

Важнейшие обязанности менеджера программы аудитов:

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

Рис. 8. Последовательность процессов управления программой аудитов

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

Менеджер программы аудитов должен установить контакты с владельцами процессов, чтобы использовать процесс аудита в качестве основного входа в процессы улучшения. Существует несколько способов структурировать программу аудита, чтобы удовлетворить требованиям ГОСТ ISO 9001:2011:

  • • разделить стандарт на несколько основных процессно ориентированных частей и проводить аудит безотносительно к процессам организации. Такой способ, игнорирующий процессы СМК организации, не является эффективным [50];
  • • структурировать программу относительно ключевых процессов СМК, выделенных в руководстве по качеству. Такой подход называется горизонтальным аудитом. Поскольку процессы охватывают функции, выполняемые в организации, такой способ позволяет охватить основные функции и стыки между функциями в процессе. Недостатком данного подхода является игнорирование многих стыков процессов в системе, хотя это может быть преодолено путем тщательного планирования аудита;
  • • структурировать программу аудитов относительно функций, выполняемых в организации. В каждый аудит нужно включать все процессы, в которых проверяемая функция выполняется. Такой подход часто называется вертикальным аудитом. Его преимуществом является охват всех ключевых процессов и их взаимодействий внутри проверяемой функции. Данный подход является эффективным, поскольку каждая функция должна быть проверена минимум один раз за один цикл аудитов. На практике программа аудита может состоять из комбинации рассмотренных подходов, что делает ее более гибкой.

Объем программы аудитов согласно стандарту ISO 19011:2011 может меняться в зависимости от размера, вида деятельности организации, природы, функциональности, сложности и уровня зрелости СМ К, подвергаемой аудиту, а также в зависимости от следующих факторов:

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

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

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

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

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

Если аудитор или группа по аудиту не могут понять основные требования к объекту аудита или оценить их важность и в силу этого не могут планировать результативный аудит, необходимо привлечь к работе технического эксперта (стандарт ISO 19011:2011 подчеркивает, что технические эксперты не могут выполнять функции аудиторов в группе по аудиту).

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

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

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

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

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

Задача мониторинга и анализа программы аудитов — определить, достигнуты ли поставленные цели, и выявить возможности улучшения. Рекомендуется рассматривать следующие показатели:

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

программы аудитов до ее завершения:

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

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

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

Процесс «Управление релизами» — для постпроектной поддержки или развития продукта

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

Процесс «управление релизами», один из стека процессов ITSM, как раз и предлагает решение для формальной приоритизации и группировки запросов пользователей (запросов на изменения, инцидентов) в общие пакеты доставки — «релизы».

В данной статье кратко раскрываются следующие темы:

  • применимость процесса — когда имеет смысл его внедрять
  • основные этапы процесса, активности, вовлеченные ресурсы и результаты
  • планирование релизов: календарь, объем, параллельное выполнение
  • некоторые проблемы доставки в релизах

Применимость процесса

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

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

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

Этапы процесса

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

1. Draft

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

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

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

Ресурсы:

  • Аналитики (ведущий аналитик)
  • Заказчики
  • Менеджер релиза

2. Scope

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

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

3. Approval

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

Результат:
Сформировано финальное содержание релиза.

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

4. Work in progress

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

Результат:
Заявки, включенные в содержание релиза — разработаны. Передача заказчику на приемочное тестирование.

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

5. Testing

Активности:
Проведение приемочного тестирования заказчиком, исправление выявленных ошибок, проведение необходимых доработок (по согласованию)

Результат:
Содержимое релиза протестировано, принято заказчиком, и готово к распространению.


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

6. Deployment

Активности:
Пакет изменений передается в эксплуатацию. Публикация новой версии продукта в продуктивной среде.

Результат:
Изменения перенесены в продуктивную среду и доступны заказчику

7. Closure

Активности:
Завершение работ над пакетом изменений: необходимые формальные шаги (документы, акты, счета ), обсуждение внутри команды результатов релиза.

Результат:
Формальное завершение работ. Улучшения процесса.

Планирование релизов

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

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

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

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

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

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

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

    Планирование релизов от объема доставки

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

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

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

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

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

    В дальнейшем будем обсуждать только детали, касающиеся релизов с фиксированной длительностью.

    Календарное планирование релиза

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

    Для этого можно попробовать использовать следующие данные, которые у вас могут быть на основании завершенного проекта:

    • примерное соотношение между ресурсами аналитиков и разработчиков при работе на одну задачу. Например, «если аналитик потратил на требования 5 человеко*дней, то затраты на разработку и тестирование составят примерно 10 человеко*дней».
    • аналогично — соотношение между анализом требований, и длительностью приемочных испытаний
    • состав команды: количество аналитиков, разработчиков, тестировщиков.

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

    Длительность этапов «Deployment» и «Closure» обычно устанавливается фиксированной, поскольку они на прямую не зависят от объема изменений. Разумеется, если зависимость в вашем случае существует — она должна учитываться.

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

    В любом случае — используйте инструменты, предназначенные для календарного планирования (как, например MS Project). Особенно это важно при создании календаря с пересекающимися во времени релизами, поскольку нужно будет тщательно контролировать загрузку ресурсов.

    Одновременное выполнение нескольких релизов

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

    • Аналитики — максимально загружены на этапе Scope и Test, менее загружены на этапах Draft и Work in progress. Во время Work in progress аналитики часто вовлечены в работу с Разработчиками, в случае необходимости поясняя требования.
    • Разработчики — максимально загружены в период Work in progress. В зависимости от реализации процесса, на этом этапе ведётся работа по запросам на изменения, вошедшим в утвержденное содержание релиза. При этом в остальное время могут заниматься исправлением дефектов, рефакторингом кода, и прочими полезными делами.
    • Заказчики — вовлечены в период сбора требований (Scope) и приемочного тестирования (Testing). В остальные периоды — вовлечение заказчика незначительное.

    Таким образом, ожидаемым шагом по оптимизации загрузки ресурсов — параллельное выполнение двух (или более) релизов, спланированных так, чтобы ресурсы постоянно переключались между одинаковыми этапами последующих проектов. То есть, например, аналитик, завершив стадию анализа для релиза R1, переключался на стадию анализа релиза R2. Аналогично — для разработчиков и заказчиков.

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

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

    Определение содержимого поставки при фиксированной длительности релиза

    Посмотрим, из чего складывается ожидаемый объем содержимого релиза.

    Фаза анализа требований

    Объем заявок на изменения, которые могут быть проанализированы к рамках этапа «Scope» представляют максимальную неопределенность. Действительно — пока аналитик не начнет анализировать заявку, не поймет о чем идет речь, сказать сколько займет полный анализ очень сложно. Конечно, предварительный анализ заявок на стадии «Draft» поможет дать первую оценку, но ее можно использовать для распределения заявок между аналитиками — в зависимости от их специализации и опыта. Кроме того, необходимо учитывать, что аналитик вовлечен в приемочное тестирование — так что, анализом требований и передачей в разработку нагрузка на аналитика в рамках релиза не заканчивается.

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

    Подготовка технического решения

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

    Может случиться, что подготовка спецификаций занимает больше положенного времени и не укладывается в рамки стадии «Scope» — тогда запрос на изменение автоматически «выбывает» из содержимого текущего релиза.

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

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

    Фиксация содержимого проекта

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

    Итак, без учета переноса готовых запросов с предыдущих релизов — объем содержимого релиза ограничен сверху количеством проанализированных заявок (определяется ресурсами Аналитиков). Ограничения по ресурсам Разработчиков могут дополнительно сокращать объем релиза.

    Известные проблемы

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

    Переключение контекста при параллельных релизах

    При планировании параллельных релизов возникает ситуация, когда все ресурсы — Аналитики, Заказчики и Разработчики должны «переключаться» между релизами. В частности, сценарии переключения следующие:

    • Аналитик закончил анализ (стадия «Scope») для релиза R1 и переключился на сбор анализ для следующего релиза R2. Ему прийдется переключится обратно в контекст релиза R1 для поддержки приемочного тестирования.
    • Аналогичный шаблон переключений — у Заказчика, особенно, если его запросы на изменения идут в последующих релизах.
    • У разработчиков переключение контекста выражено меньше — только в случае если нужно переключаться между новой разработкой и старыми дефектами.

    «Переключение контекста — это плохо». Действительно, это приводит к снижению эффективности, потере фокуса на задаче, и может привести к задержках на ключевых этапах процесса.

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

    Ресурсные конфликты при нарушении календаря релиза

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

    Исходя из конструкции этапов релиза и перехода между ними — наибольший негативный эффект имеет задержка этапов разработки и тестирования. Фазы анализа («Draft», «Scope», «Approval») имеют возможность понизить содержание релиза за счет переноса неоконченных заявок на следующий релиз — и это воспринимается заказчиком, обычно, легче, чем перенос из после утверждения содержания релиза.

    Взятие «повышенных обязательств»

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

    В качестве меры по можно использовать пессимистичную оценку объема ресурсов при фиксации содержимого релиза на этапе «Approval». Вообще тема «недооценки задачи/переоценки собственных сил и как с этим бороться» — очень дискуссионная. И решение очень сильно зависит от организационного окружения, в котором работает команда.

    Реализация «больших» задач

    Довольно часто в ходе анализа выясняется, что объем задачи не помещается во временные рамки этапа «Work in progress» — требуемый объем не получается разработать и доставить в рамках одного релиза.

    Если увеличить ресурсы Разработчиков не представляется возможным, остается два возможных путей решения этой проблемы:

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

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

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

    Устранение дефектов в контексте релизов

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

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

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

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

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

    Заключение

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

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

    5 Управление программой аудита


    .: Дата публикации 08-Фев-2012 :: Просмотров: 25566 :: :.

    5.1 Общие положения

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

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

    ПРИМЕЧАНИЕ. Такой подход известен как аудит, основанный на оценке рисков. Настоящий международный стандарт не содержит руководящих указаний по проведению таких аудитов.

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

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

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

    На рис. 1 представлена блок-схема управления программой аудита.

    ПРИМЕЧАНИЕ 1. Данный рисунок иллюстрирует применение цикла PDCA (планируйте -делайте — проверяйте — действуйте) к настоящему международному стандарту.

    ПРИМЕЧАНИЕ 2. Указанные на рисунке номера разделов и подразделов являются номерами соответствующих разделов и подразделов данного международного стандарта.

    Рис. 1. Блок-схема процесса управления программой аудита

    5.2 Установление целей программы аудита

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

    Эти цели могут быть основаны на итогах рассмотрения:

    1. приоритетов, имеющихся у руководства организации;
    2. коммерческих и других намерений, относящихся к бизнесу;
    3. характеристик процессов, продукции и проектов и любых изменений в этих характеристиках;
    4. требований к системе менеджмента;
    5. правовых (законодательных и нормативных) и контрактных требований, а также других требований, которые организация обязалась выполнять;
    6. потребностей в оценивании поставщиков;
    7. потребностей и ожиданий заинтересованных сторон, включая потребителей;
    8. уровня деятельности аудитируемой организации, отражающего степень повторяемости несоответствий или инцидентов или жалоб со стороны потребителей;
    9. рисков аудитируемой организации;
    10. результатов предыдущих аудитов;
    11. уровня зрелости системы менеджмента, подвергаемой аудиту.

    Примерами целей программы аудита могут быть:

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

    5.3 Разработка программы аудита

    5.3.1 Обязанности и ответственность лица, осуществляющего управление программой аудита

    Лицу, осуществляющему управление программой аудита, следует:

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

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

    5.3.2 Компетентность лица, осуществляющего управление программой аудита

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

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

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

    5.3.3 Установление объема программы аудита

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

    ПРИМЕЧАНИЕ. В некоторых случаях, в зависимости от структуры аудитируемой организации или характера ее деятельности, программа аудита может состоять только из одного аудита (например аудита деятельности в рамках небольшого проекта).

    Другими факторами, влияющими на глубину программы аудита, являются следующие:

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

    5.3.4 Выявление и оценка рисков для программы аудита

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

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

    5.3.5 Разработка процедур для программы аудита

    Лицу, осуществляющему управление программой аудита, следует разработать одну или несколько процедур, устанавливающих (в той степени, в которой это применимо) порядок осуществления следующего:

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

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

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

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

    5.4 Реализация программы аудита

    5.4.1 Общие положения

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

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

    5.4.2 Установление целей, области и критериев для конкретного аудита

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

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

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

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

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

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

    5.4.3 Выбор методов проведения аудита

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

    ПРИМЕЧАНИЕ. Руководящие указания по выбору методов проведения аудита представлены в приложении В.

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

    5.4.4 Формирование команды по аудиту

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

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

    ПРИМЕЧАНИЕ. В разделе 7 содержатся руководящие указания по определению компетентности, требуемой членам команды по аудиту, и описание процесса оценивания аудиторов.

    При решении вопроса о количественном и качественном составе команды по аудиту для проведения конкретного аудита следует учесть:

    1. обеспечивает ли совокупная компетентность членов команды по аудиту потребности, необходимые для достижения целей аудита, принимая во внимание область и критерии аудита;
    2. сложность аудита, а также то, является ли аудит комбинированным или совместным;
    3. методы, которые должны быть выбраны для проведения аудита;
    4. правовые (законодательные и нормативные) и контрактные требования, а также другие требования, которые организация обязалась выполнять;
    5. необходимость обеспечения независимости членов команды по аудиту от аудитируемой деятельности, а также исключения любых конфликтов интересов [см. принцип е) в разделе 4];
    6. способность членов команды по аудиту результативно взаимодействовать с представителями аудитируемой организации и работать совместно;
    7. язык, на котором будет проходить общение во время аудита, а также социальные и культурные особенности аудитируемой организации. Эти проблемы могут быть разрешены либо путем приобретения и наличия соответствующих навыков у самих аудиторов, либо посредством обращения за помощью к техническим экспертам.

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

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

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

    5.4.5 Возложение ответственности на руководителя команды по аудиту за конкретный аудит

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

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

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


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

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

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

    5.4.6 Управление результатами реализации программы аудита

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

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

    5.4.7 Управление записями по программе аудита и их сохранение

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

    a) записи, относящиеся к программе аудита, такие, как:
    — документально оформленные цели и объем программы аудита;
    — записи, относящиеся к рискам в отношении программы аудита;
    — записи об анализах результативности программы аудита;
    b) записи, относящиеся к каждому конкретному аудиту, такие, как:
    — планы аудитов и отчеты об аудитах;
    — отчеты о несоответствиях;
    — отчеты о корректирующих и предупреждающих действиях;
    — отчеты о действиях, осуществленных по завершении аудитов (если таковые были);
    c) записи, относящиеся к персоналу, участвующему в аудитах, по таким вопросам, как:
    — результаты оценивания компетентности и деятельности членов команды по аудиту;
    — формирование команд по аудиту и отбор членов команд;
    — записи о поддержании и повышении компетентности.

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

    5.5 Мониторинг программы аудита

    Лицу, осуществляющему управление программой аудита, следует проводить мониторинг хода ее реализации, оценивая при этом:

    1. степень соответствия программам, графикам проведения и целям аудитов;
    2. деятельность членов команды по аудиту;
    3. способность команд по аудиту реализовать план аудита;
    4. информацию, получаемую в качестве обратной связи от высшего руководства, аудитируемых организаций, аудиторов и других заинтересованных сторон.

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

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

    5.6 Анализ и улучшение программы аудита

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

    При проведении анализа программы аудита следует рассмотреть:

    Управление программой аудита

    Основные этапы аудита

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

    — подготовка к аудиту;

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

    Начальное планирование аудита

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

    Начальное планирование аудита включает в себя следующие действия:

    — определение необходимых спецификаций или требований, по которым будет проводиться аудит. В зависимости от вида и масштаба аудита такими спецификациями могут быть – стандарт ИСО 9001:2008 (ИСО 9001:2000), документированные процедуры системы качества, документированные требования на процессы или отдельные регламенты и правила работы.

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

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

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

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

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

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

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

    Детальное планирование и согласование условий проведения аудита

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

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

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

    — Распределение аудиторов по подразделениям. В том случае, когда аудиторов несколько, необходимо спланировать работу аудиторов по подразделениям. Как правило, распределение аудиторов по подразделениям указывается в программе аудита. Для случая внутреннего аудита важно обратить внимание на соблюдение требований объективности аудита. Распределение внутренних аудиторов должно быть выполнено таким образом, чтобы они не проверяли свою собственную работу или работу своего подразделения.

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

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

    Открытие аудита

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

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

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

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

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

    Проверка на местах

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

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

    При проверке на местах, аудиторам необходимо:

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

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

    — Установить соответствие или несоответствие требованиям – установить соответствия или несоответствия можно только на основании ответов сотрудника и их сравнения с выборочной проверкой работы сотрудника или каких-либо документов, записей.

    — Записать результаты наблюдений и проверок – это одно из обязательных требований. По ходу аудита, аудитор обязан вести записи аудита и точно фиксировать все результаты проверок.

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

    Закрытие аудита

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

    — Определение общего количества несоответствий по всем проверенным подразделениям –необходимо посмотреть, что за несоответствия в подразделениях выявлены, есть ли повторяющиеся несоответствия, какое количество несоответствий. Большое количество повторяющихся несоответствий говорит об их системном характере.

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

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

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

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

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

    Управление программой аудита

    Общие положения

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

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

    Организация может разработать более одной программы аудита.

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

    Ответственные за управление программой аудита должны:

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

    b) определять необходимые ресурсы и обеспечивать их наличие.

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

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

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

    Дата добавления: 2020-10-27 ; просмотров: 1101 | Нарушение авторских прав

    Илон Маск рекомендует:  Об этом учебнике<a>
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL