Положение управление проектом строительства

Project management. Project network techniques. Descriptions and concepts.

Дата введения 2016-07-01

1 ПОДГОТОВЛЕН АНО «Международная академия менеджмента и качества бизнеса» совместно с ЗАО «Проектная ПРАКТИКА» при участии АО «НИЦ КД» на основе собственного перевода на русский язык немецкоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 «Стратегический и инновационный менеджмент»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 17 ноября 2015 г. N 1829-ст

4 Настоящий стандарт идентичен стандарту ДИН 69900:2009* «Проектный менеджмент. Техника сетевого планирования. Общие положения и терминология» («Project management. Project network techniques. Descriptions and concepts», IDT).

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

Управление стейкхолдерами (заинтересованными сторонами)

При применении настоящего стандарта рекомендуется использовать вместо ссылочного стандарта DIN соответствующие ему национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ.

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Настоящий стандарт разработан немецким рабочим комитетом NA 147-00-04 AA «Техника сетевого планирования и проектный менеджмент» NA 147 (NQSZ).

Настоящий стандарт включает в себя положения первых основополагающих стандартов по технике сетевого планирования DIN 69900-1:1987-08 и DIN 69900-2:1987-08. Данные стандарты ориентированы только на технику сетевого планирования и практически не рассматривают аспекты формирования перечней работ со сроками реализации и ленточные диаграммы, хотя они также могут рассматриваться в качестве сетевых графиков в табличной форме или сетевых графиков с календарно-масштабной сеткой при представлении в них информации о зависимостях. Вышеуказанные недостатки учтены при разработке настоящего стандарта.

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

Project plan — план управления проектом

Некоторые термины техники сетевого планирования в настоящем стандарте также не рассматриваются.

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

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

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

К основополагающим национальным стандартам Российской Федерации в области проектного менеджмента относятся:

1 ГОСТ Р ИСО 21500-2014 «Руководство по проектному менеджменту»;

2 ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом»;

3 ГОСТ Р 54871-2011 «Проектный менеджмент. Требования к управлению программой»;

4 ГОСТ Р 54870-2011 «Проектный менеджмент. Требования к управлению портфелем проектов».

1 Область применения

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

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

2 Нормативные ссылки

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

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

DIN 69901-5:2009 Project management. Project management systems. Part 5. Concepts (Проектный менеджмент. Системы проектного менеджмента. Часть 5. Термины и определения)

3 Термины и определения

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

3.1 элемент диаграммы проекта (element of project flow): Элемент, предназначенный для описания структуры проекта (работы, события, зависимости).

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

3.2 зависимость «начало начало» (AF) (start-to-start relationship): Отношение зависимости между началом одной работы и началом следующей за ней работы.

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

3.3 отношение зависимости (relationship): Количественно выражаемая связь между событиями и работами.

3.4 соединительный узел (connection node): Узел сетевого графика или частичного сетевого графика, от которого отходит или к которому ведет линия связи.

3.5 линия связи (connection): Соединение двух узлов различных сетевых графиков.

3.6 линия на графике (bar): Изображение работы на ленточной диаграмме с помощью узла, горизонтальная протяженность которого показывает длительность работы на оси времени.

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

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

3.8 определяющий путь (determining path): Путь, по которому определяется время события или работы.

3.9 элемент представления (element of representation): Элемент для представления работы.

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

3.10 продолжительность (D) (duration): Временной отрезок от начала работы и до конца или от старта до окончания проекта.

3.11 зависимость «окончание-окончание» (EF) (finish-to-finish relationship): Отношение зависимости между окончанием одной работы и окончанием следующей за ней работы.

3.12 событие, требующее принятия решения (decision event): Событие, в рамках которого существуют альтернативные пути дальнейшего развития проекта, требующие своевременного принятия решения.

3.13 узел принятия решения (decision node): Узел с различными входами и выходами (развилками), которые могут быть использованы по выбору для дальнейшего развития проекта.

3.14 сетевой график принятия решения (decision network): Сетевой график, который содержит не менее одного условия ИЛИ (стохастическая структура процесса).

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

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

3.15 работа, связанная с принятием решения (decision activity): Работа, по окончании которой существуют альтернативные пути развития проекта, требующие своевременного принятия решения.

3.16 событие (event): Элемент диаграммы, который описывает переход в определенное состояние.

3.17 сетевой график с представлением событий в виде узлов (EKN) (event-on-node network): Сетевой график, на котором события описываются и изображаются в виде узлов.

3.18 обобщенное отношение взаимосвязи (summary relationship): Отношение взаимосвязи между двумя событиями, которое представляет собой пути, не показанные при обобщении (укрупнении) сетевого графика.

3.19 обобщенная работа (summary activity): Работа, которая представляет детальные работы при обобщении (укрупнении) сетевого графика.

3.20 детальный сетевой график (detailed network): Сетевой график со структурой, детально описывающей работы проекта.

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

3.22 самое раннее положение (early position): Положение работы или события, которое, учитывая содержащиеся в сетевом графике условия, нельзя сдвинуть вперед.

3.23 ранний старт (FAT) (early start date): В методе критического пути это самый ранний из возможных моментов времени, в который могут начаться невыполненные части плановых операций (или проекта), вычисляемый на основании логики сети расписания, отчетной даты и любых ограничений на расписание. Ранний старт может меняться по ходу исполнения проекта и внесения изменений в план управления проектом.

3.24 самый ранний срок начала работ (FAZ) (early start time): Время начала работы, которое, учитывая содержащиеся в сетевом графике условия, нельзя сдвинуть вперед.

3.25 раннее начало работ (FA) (early start): Начало работы, которое, учитывая содержащиеся в сетевом графике условия, нельзя сдвинуть вперед.

3.26 ранний финиш (FET) (early finish date): В методе критического пути это самый ранний из возможных моментов времени, в который могут завершиться невыполненные части плановых операций (или проекта), вычисляемый на основании логики сети расписания, отчетной даты и любых ограничений на расписание. Ранний финиш может меняться по ходу исполнения проекта и внесения изменений в план управления проектом.

3.27 самый ранний срок окончания работ (FEZ) (early finish time): Время окончания работ, который, учитывая содержащиеся в сетевом графике условия, нельзя сдвинуть вперед.

3.28 ранняя дата (FT) (early date): Дата события, которую, учитывая содержащиеся в сетевом графике условия, нельзя сдвинуть вперед.

3.29 раннее время (FZ) (early time): Время события, которое, учитывая содержащиеся в сетевом графике условия, нельзя сдвинуть вперед.

3.30 раннее окончание работ (FE) (early finish): Окончание работы, которое, учитывая содержащиеся в сетевом графике условия, нельзя сдвинуть вперед.

3.31 общий временной резерв (GP) (total float): Промежуток времени, на который можно задержать раннее начало операции без нарушения срока завершения проекта. Резерв рассчитывается математически; его величина может изменяться в ходе проекта по мере внесения изменений в план проекта.

Примечание 1 — Для событий GP=SZ-FZ.

Примечание 2 — Для процессов GP=SAZ-FAZ или GP=SEZ-FEZ.

3.32 полный сетевой график (total network): Сетевой график, охватывающий весь проект.

3.33 укрупненный (приблизительный) сетевой график (rough network): Сетевой график со структурой, которая дает приблизительный обзор развития проекта.

3.34 наиболее вероятная продолжительность (HD) (most frequent duration): Продолжительность работы, которую следует ожидать при обычных условиях.

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

3.35 узел (сети) (node): Элемент представления для описания точки соединения.

Примечание — В зависимости от метода составления сетевого графика узел символизирует событие или работу.

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

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

3.37 максимальная продолжительность (MAXD) (maximum duration): Максимально допустимое значение продолжительности.

3.38 максимальный интервал времени (MAXZ) (maximum time interval): Временной показатель отношения взаимосвязи, который нельзя превышать.

3.39 техника многосетевого и частичного сетевого планирования (multi- and partial network technique): Методы общей обработки нескольких сетевых графиков.

3.40 контрольное (ключевое) событие (milestone, key event): Событие особого значения.

3.41 сетевой график с контрольными событиями (milestone network): Сетевой график, в котором преимущественно представлены ключевые события, соединенные друг с другом отношениями взаимосвязи.

3.42 минимальная продолжительность (MIND) (minimum duration): Минимальное значение, до которого может быть сокращена продолжительность.

3.43 минимальный интервал времени (MINZ) (minimum time interval): Временной показатель отношения взаимосвязи, значение которого не может быть ниже указанной границы.

3.44 средняя продолжительность (MD) (middle duration): Ожидаемая продолжительность работы, рассчитанная из оценочных значений.

Примечание — Обычная формула расчета MD=(OD+4HD+PD)/6.

3.45 последующая операция (работа) (successor activity): Работа, которая идет непосредственно за какой-либо работой.

3.46 сетевой график (NP) (network; network schedule): Графическое или табличное представление структуры работ, состоящее из работ или событий и отношений их взаимосвязи.

3.47 вид сетевого графика (network type): Тип сетевых графиков, характеризуемый единым принципом представления.

Пример — Сетевые графики с указанием работ в виде узлов, сетевые графики с указанием работ в виде стрелок, сетевые графики с указанием событий в виде узлов.

3.48 метод сетевого планирования (network method): Последовательность действий в соответствии с определенными правилами представления, расчета и т.д. сетевых графиков, например, техника оценки и анализа программ (PERT), метод критического пути (CPM).

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

3.49 модуль сетевого графика (network module): Логически завершенная часть сетевого графика, которая в качестве стандартного элемента предназначена для повторного использования.

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

3.51 техника сетевого планирования (NPT) (network technique, network scheduling): Метод анализа сроков (ранних и поздних) начала и окончания работ проекта, позволяет увязать выполнение различных работ во времени, получив прогноз общей продолжительности реализации всего проекта.

Примечание — Может учитывать время, затраты, ресурсы и другие величины.

3.52 уплотнение (сжатие) сетевого графика (network compression): Сокращение расписания путем сокращения длительности работ и отношений взаимосвязи сетевого графика при остающейся неизменной (постоянной) структуре процесса реализации проекта.

3.53 метод составления сетевого графика (network procedure): Метод соотнесения элементов процесса реализации проекта с элементами представления.

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

3.54 детализация сетевого графика (detailing a network): Детализация информации путем увеличения количества работ, событий и отношений взаимосвязи сетевого графика при остающейся неизменной (постоянной) структуре процесса реализации проекта.

3.55 соединение сетевых графиков (connecting networks): Объединение сетевых графиков с помощью связей.

3.56 разделение сетевого графика (network separation): Разделение сетевого графика на несколько (частичных) сетевых графиков.

3.57 обычная последовательность (окончание — начало ) (NF) (end-to-start relationship): Отношение зависимости между окончанием одной работы и началом следующей за ней работы.

3.58 продолжительность (длительность) использования ресурса (resource usage duration): Сумма значений продолжительности частичных этапов, во время которых с помощью технических ресурсов/персонала или группы ресурсов достигаются результаты работы.

3.59 оптимистическая продолжительность (OD) (optimistic duration): Продолжительность работы при самых благоприятных условиях.

3.60 пессимистическая продолжительность (PD) (pessimistic duration): Продолжительность работы при самых неблагоприятных условиях.

Примечание — Случаи наступления форс-мажорных обстоятельств не учитываются.

3.61 стрелка (arrow): Элемент представления для описания связи между двумя узлами.

Примечание — В зависимости от метода составления сетевого графика стрелка символизирует работу и/или отношение взаимосвязи.

3.62 окончание проекта (project finish): Срок или дата окончания проекта.

3.63 запуск проекта (project start): Срок, дата или интервал времени, с которого начинается проект.

Примечание — Запуск проекта осуществляется, как правило, по итогам организационного совещания или стартового семинара.

3.64 начальная дата проекта (project start date): Срок или дата, с которых начинается отсчет продолжительности проекта.

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

3.65 резерв (buffer): Что-либо заложенное в качестве резерва (запаса), обычно для того, чтобы справляться с отклонениями по времени и стоимости или с рисками.

Примечание — Отрицательные значения резерва показывают, что запас не покрывает запланированное потребление.

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

Примечание — Другие названия: простой (slack); общий временной резерв (total float); резерв пути (path float). См. также свободный временной резерв (free float).

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

3.68 фиктивная операция (dummy activity): Плановые операции нулевой длительности, служащие для отображения логических взаимосвязей в методе «операции на дугах» (методе стрелочных диаграмм). Фиктивные операции используются в том случае, когда логические взаимосвязи не могут быть описаны полностью или правильно с помощью дуг плановых операций. Фиктивные операции обычно графически отображаются в виде пунктирных линий со стрелкой.

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

Примечание 1 — В теории графов называется также кругом или циклом.

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

3.70 ключевая работа (ключевая операция) (key activity): Работа особого значения.

3.71 предел (bound, limit): Предельные значения (верхняя или нижняя граница) параметров времени, затрат и ресурсов за которые нельзя выходить.

Примечание — Пределы могут определяться для параметров времени, затрат и ресурсов (например, «предел времени», «предел ресурсов»).

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

Примечание — Заданный интервал может определяться для параметров времени, затрат и ресурсов (например, «заданный интервал времени», «заданный интервал затрат»).

3.73 самое позднее положение (late position): Положение работы или события, которое, учитывая содержащиеся в сетевом графике условия, нельзя сдвинуть на более поздние сроки.

3.74 позднее начало работ (SA) (late start): Начало работы, которое, учитывая содержащиеся в сетевом графике условия, нельзя сдвинуть на более поздние сроки.

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

3.76 самый поздний срок начала работ (SAZ) (late start time): Время начала работы, позже которого, учитывая содержащиеся в сетевом графике условия, нельзя сдвинуть начало работы.

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

3.78 самый поздний срок окончания работ (SEZ) (late finish time): Время окончания работы, которое, учитывая содержащиеся в сетевом графике условия, нельзя сдвинуть назад.

3.79 поздняя дата (ST) (late date): Дата события, которую, учитывая содержащиеся в сетевом графике условия, нельзя сдвинуть вперед.

3.80 позднее время (SZ) (late time): Дата события, которую, учитывая содержащиеся в сетевом графике условия, нельзя сдвинуть назад.

3.81 позднее окончание работ (SE) (late finish): Окончание работы, которое, учитывая содержащиеся в сетевом графике условия, нельзя сдвинуть назад.

3.82 предельный интервал (blocked interval): Область, ограниченная двумя пределами, в которой не должны находиться значения рассматриваемых в каждом случае величин.

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

3.83 зависимость «начало-окончание» (SF) (start-to-finish relationship): Отношение зависимости между началом одной работы и окончанием следующей за ней работы.

3.84 стандартный сетевой график (standard network): Сетевой график с установленной структурой хода реализации проекта, который предназначен для повторного применения.

Примечание — Устанавливаться могут и другие параметры, как, например, параметры времени и ресурсы.

3.85 начальное событие (start event): Событие в сетевой модели, не имеющее входных дуг (предшествующих работ или зависимостей).

Примечание — В проекте может быть больше, чем одно начальное событие.

3.86 стартовый (начальный) узел (start node): Узел, от которого только отходят стрелки.

3.87 стартовая работа (начальная операция) (start activity): Работа, которой в рассматриваемом сетевом графике не предшествует никакая другая работа.

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

3.89 дата (date): Термин, обозначающий день, месяц, год календаря и, в некоторых случаях, время дня.

3.90 независимое резервное время; независимый резерв (UP) (independent float): Промежуток времени, на который может быть сдвинуты или продлены событие и работа, если предшествующие им события и работы находятся в самом поздней точке, а идущие за ними события и работы находятся в самом ранней точке.

3.91 сетевая ленточная диаграмма (related bar chart): Ленточная диаграмма (диаграмма Ганта) с графическим представлением отношений взаимосвязи.

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

3.92 работа; операция (activity): Элемент процесса реализации проекта для определенного действия с обозначенным началом и концом.

3.93 предшествующая операция (predecessor activity): Работа, которая идет непосредственно перед какой-либо работой.

3.94 сетевой график по схеме «операция-узел» (VKN) (activity-on-node network): Сетевой график, при котором работы описываются в виде узлов.

3.95 сетевой график по схеме «операция-стрелка» (VPN) (activity-on-arrow network): Сетевой график, при котором работы описываются в виде стрелок.

3.96 путь (path): Связь между узлами, представленная в виде одной или нескольких следующих друг за другом стрелок.

3.97 временной интервал (Z) (time interval): Временной параметр характеризующий взаимосвязь (с задержкой, с опережением).

Примечание — Он может быть больше или меньше нуля либо равен нулю.

3.98 положение по времени (time related position): Результат расположения событий и процессов по времени с учетом всех имеющихся условий.

Пример — Для времени, затрат и ресурсов.

3.99 временной момент (time): Определенная точка в ходе выполнения проекта, положение которой описывается единицами времени (например, минутами, днями, неделями) и соотнесено с нулевой точкой.

3.100 завершающее событие (goal event): Событие, за которым в рассматриваемом сетевом плане не следует никакое другое событие.

3.101 завершающий узел (goal node): Узел, к которому только подходят стрелки.

3.102 завершающая работа (операция) (goal activity): Работа, за которой в рассматриваемом сетевом плане не следует никакой другой работы.

4 Техника сетевого планирования

4.1 Планирование хода реализации проекта и сроков

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

В основном используются следующие представления:

— перечень работ со сроками реализации;

— сетевой график (включая сетевой график с календарно-масштабной сеткой, называемый также сетевой ленточной диаграммой).

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

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

4.2 Контрольный перечень сроков реализации работ проекта

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

— название или описание работы;

— при сетевом представлении: номер предшествующей или последующей работы.

4.3 Ленточная диаграмма (диаграмма Ганта)

Данный вид представления часто называется также столбчатой диаграммой (гистограммой), диаграммой Ганта или графиком Ганта.

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

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

4.4 Сетевой график

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

Из трех возможностей представления для рациональной комбинации элементов хода реализации проекта и элементов представления (виды сетевых графиков см. в п.4.4.2.2) сегодня используются практически только сетевые графики с указанием работ в виде узлов (VKN). Если дополнить их контрольными точками, т.е. событиями особого значения, то из такого графика можно получить в укрупненном виде график с указанием промежуточных результатов, опуская работы и заменяя их соответственно отношениями взаимосвязи. Тогда этот график стал бы сетевым графиком с представлением событий в виде узлов (EKN). Сетевые графики, в которых работы обозначаются стрелками (VPN), сегодня редко применяются и имеют скорее историческое значение.

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

Таблица 1 — Привязка события или работы к самому раннему или позднему положению

Источник: gostassistent.ru

Управление проектами в организации: проверенные и новые методы

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

Процессы и стандарты управления

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

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

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

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

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

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

Сухие цифры

Эффективность проектно-ориентированного подхода измеряется в цифрах. Согласно подсчетам IPMA (Международной ассоциации управления проектами), внедрение методологии помогает сократить финансовые расходы на 15–20 % и временны́е — на 20–30 % [1] .

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

• PMBOK (Project Management Body of Knowledge) от американского института PMI;
• P2M, разработанный японской Ассоциацией управления проектами PMAJ;
• ICB от международной ассоциации IPMA;
• ISO 21500.

Кроме того, существует российский стандарт ГОСТ Р ИСО 21500-2014 — он является аналогом международного ISO 21500.

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

Инициация

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

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

Организация

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

Контроль

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

Завершение

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

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

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

Waterfall

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

Справка

Метод управления проектами Waterfall был разработан еще в 1970 году американцем У. Ройсом и долгие годы служил эталоном для разных отраслей деятельности. Например, компания Toyota использовала водопадный метод до 2000-х годов — до тех пор, пока не разработала собственные подходы к управлению проектами (Lean и Kanban) [3,4] .

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

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

В чем преимущества Waterfall-методологии управления проектами?

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

Тем не менее, например, программисты все чаще отходят от классического водопада в сторону новых гибких методов. Причина, конечно, в ограничениях жесткой каскадной модели, в невозможности внесения изменений. Это значит, что проект не получится оптимизировать «на ходу». Если в процессе выполнения выяснится, что команда не укладывается в установленные временны́е или бюджетные рамки, работы будут урезаны за счет фазы тестирования, следовательно, сохранится высокий риск ошибок. Их исправление после запуска продукта обойдется в среднем в 20 раз дороже, чем на стадии разработки [5] .

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

Agile

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

В чем главное отличие методологии управления проектами Agile от Waterfall?

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

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

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

Scrum

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

Главным инструментом Scrum являются бэклоги — списки приоритетных задач. Перед началом спринта команда разработки совместно с владельцем проекта решает, какие задачи должны быть выполнены в первую очередь (в текущем спринте). Ежедневно проводятся краткие совещания, в ходе которых каждый из разработчиков рассказывает, что сделал вчера, что планирует сделать сегодня, с какими проблемами столкнулся. В результате команда может быстро обнаружить препятствия и при необходимости изменить стратегию. По окончании каждого спринта проводится ретроспективный анализ, цели которого — оценить эффективность работы, сделать прогнозы для последующих итераций, выявить возможные проблемы [7] .

Scrum — один из самых структурированных методов в семействе Agile [8] . И, конечно, он обладает всеми достоинствами гибкой модели, прежде всего адаптивностью и клиентоориентированностью.

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

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

Для обеспечения удобства управления проектами разработаны специальные программные решения. Один из таких инструментов — система «Первая Форма». О ее особенностях рассказывает Денис Алексеевич Селезнев, генеральный директор компании:

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

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

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

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

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

P. S. Компания «Первая Форма» специализируется на разработке BPM-решений для автоматизации бизнес-процессов. Ведет свою историю с 2002 года, сегодня входит в топ-10 в своей отрасли [9] .

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

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

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

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

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

Корпоративные порталы помогают сотрудникам своевременно получать информацию о текущем положении дел в компании и в отделе.

• 1 https://www.gd.ru/articles/11751-upravlenie-proektami
• 2 https://pmpractice.ru/knowledgebase/managment/keypoints/process/
• 3 https://worksection.com/blog/waterfall.html
• 4, 5 https://worksection.com/blog/waterfall-vs-agile.html
• 6 https://habr.com/ru/company/edison/blog/313410/
• 7 https://habr.com/ru/post/247319/
• 8 https://4brain.ru/project/methods.php
• 9 https://www.tadviser.ru/index.php/BPM

Белоногова Нарцисса Николаевна Ответственный редактор

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

Экономический эффект внедрения BPM-систем для управления бизнес-процессами

СМИ «aif.ru» зарегистрировано в Федеральной службе по надзору в сфере связи, информационных технологий и массовых коммуникаций (РОСКОМНАДЗОР), регистрационный номер Эл № ФС 77-78200 от 06 апреля 2020 г. Учредитель: АО «Аргументы и факты». Интернет-сайт «aif.ru» функционирует при финансовой поддержке Федерального агентства по печати и массовым коммуникациям.

Все права защищены. Копирование и использование полных материалов запрещено, частичное цитирование возможно только при условии гиперссылки на сайт aif.ru.

Источник: aif.ru

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

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

При разработке стандарта учтены требования ISO 9001, ISO/TS1-6949, руководств APQP и ANPQP.

Стандарт введен впервые

1. Область применения
2. Нормативные ссылки
3. Определения
4. Обозначения и сокращения
5. Цели управления проектами
6. Классификация проектов
7. Проектная группа, состав и функции
8. Ход выполнения проекта
9. Внесение изменений в проект
10. Премирование участников проекта

1 ОБЛАСТЬ ПРИМЕНЕНИЯ

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

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

2 НОРМАТИВНЫЕ ССЫЛКИ

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

• ISO 9001 :2008 Система менеджмента качества. Требования.
• ISO/TS 169492009 Система менеджмента качества. Особые требования по применению стандарта ISO 9001 B автомобилестроении и организациях, поставляющих соответствующие запасные части.
• Руководство АРОР Перспективное планирование качества продукции и план управления.
• Система качества. Методические указания. Анализ видов и последствий вероятных отказов. Процесс.
• Система качества. Методические указания. Анализ видов и последствий вероятных отказов. Конструкция.
• Система менеджмента качества. Планирование качества перспективной продукции и план управления. Руководящий документ по применению руководства АРОР на предприятии.
• Регламент инвестиционного планирования. Руководящий документ.
• Система менеджмента качества. Планирование качества перспективной продукции. Руководящий документ по применению руководства ANPQP на предприятии.
• СТП Система менеджмента качества. Управление проектированием. Управление разработкой технологических процессов.
• СТП Система менеджмента качества. Управление разработкой испытательного оборудования.
• СТП Система менеджмента качества. Управление документацией и данными. Управление конструкторской документацией.
• СТП Система менеджмента качества. Управление документацией и данными. Управление технологической документацией.

3 ОПРЕДЕЛЕНИЯ

В данном стандарте предприятия использованы термины и определения, используемые в отечественных ГОСТ, a также в МС ISO 9000, ISO/TS 16949.

Инициатор проекта — это структурное подразделение или работник предприятия, которые вносят «предложение» об инициации проекта.

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

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

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

4 ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

• APQP — процедура планирования качества перспективной продукции
• ANPQP — совместная процедура планирования качества перспективной продукции Renault и Nissan.
• ГОСТ — государственный стандарт
• ДЭФ — дирекция по экономике и финансам
• КД — конструкторская документация
• КИА — контрольно-измерительная аппаратура
• ОРД — организационно-распорядительная документация
• PSW — заявка на одобрение автокомпонента
• РРАР — одобрение производства автокомпонентов
• СТО — средства технологического оснащения
• ТД — технологическая документация
• ТПП — технологическая подготовка производства
• ФЭП — финансово-экономические показатели

5 ЦЕЛИ УПРАВЛЕНИЯ ПРОЕКТАМИ

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

5.2 Повышение персональной ответственности непосредственных участников проекта.

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

5.4 Повышение качества выполняемых работ по проектам предприятия.

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

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

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

5.8 Соблюдение установленных сроков выполнения проекта.

5.9 Качественное выполнение процедур APQP (ANPQP) в проектах по разработке и подготовке производства новых изделий.

6 КЛАССИФИКАЦИЯ ПРОЕКТОВ

6.1 Проект

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

6.2 Виды проектов

6.2.1 По основной направленности:

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

6.2.2 По отношению друг к другу:

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

6.2.3 По срокам реализации (создания и функционирования):

• Краткосрочные (до 1 года);
• Среднесрочные (1-3 лет);
• Долгосрочные (свыше 3 лет);

6.2.4 По характеру инициирования:

Внешний (инициатор проекта не является структурным подразделением предприятиях

Внутренние (инициатор проекта является структурным подразделением предприятия);

6.2.5 По масштабам (чаще всего масштаб проекта определяется размером инвестиций):

• Малые проекты (до 0,25% годового объема продаж предприятия);
• Средние проекты (от 0,25% до 1,0% годового объема продаж предприятия);
• Крупные проекты (свыше 1‚0% годового объема продаж предприятия);

7 ПРОЕКТНАЯ ГРУППА, СОСТАВ И ФУНКЦИИ

7.1 Основной организационной структурой участников проекта является проектная группа.

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

7.3 Проектная группа создается на период осуществления проекта.

7.4 Проектная группа создается из числа работников предприятия.

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

7.6 Инициатор проекта — это структурное подразделение или работник предприятия, которые инициируют проект для удовлетворения потребностей заказчика.

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

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

Руководитель проекта выполняет следующие функции:

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

7.7.2 Конструктор проекта:

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

7.7.3 Технолог проекта:

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

7.7.4 Менеджер по производству:

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

7.7.5 Менеджер по снабжению:

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

7.7.6 Менеджер по качеству:

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

7.7.7 Менеджер по сбыту:

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

7.7.8 Экономист проекта:

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

7.7.9 Администратор проектов:

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

8 ХОД ВЫПОЛНЕНИЯ ПРОЕКТА

8.1 Любой проект имеет начало и окончание.

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

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

8.4 После утверждения проекта инвестиционным комитетом наступает следующая фаза — реализация.

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

Ответственность за подготовку приказа несут:

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

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

8.7 Проектная группа формируется исходя из следующих факторов:

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

8.8 Члены проектной группы непосредственно напрямую взаимодействуют друг с другом.

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

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

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

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

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

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

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

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

8.13 В план — графике должны быть отражены: (Приложение А)

• Этап/Задача/Работа
• Этапы план-графика должны быть составлены и содержать этапы планирования качества перспективной продукции руководства APQP и ANPQP.
• Исполнитель/Ответственный
• Дата, время плановое начала работ
• Дата, время плановое завершения работ
• Дата, время фактическое (вводится по мере выполнения проекта)
• Графа примечание

План должен соответствовать определенным требованиям:

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

План-график проекта разрабатывается в программе MS. Project.

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

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

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

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

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

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

8.19 Руководитель проекта готовит отчет руководству о завершении проекта.

9 ВНЕСЕНИЕ ИЗМЕНЕНИЙ В ПРОЕКТ

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

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

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

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

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

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

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

9.6 Изменения должны быть согласованы с заинтересованными службами.

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

10 ПРЕМИРОВАНИЕ УЧАСТНИКОВ ПРОЕКТНОЙ ГРУППЫ

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

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

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

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

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

Источник: gostost.ru

Положение и регламент управления проектами компании

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

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

Документ содержит три основных раздела:

1. Общие принципы, закладываемые в положение и технологию;
2. Роли — Зоны ответственности, выделяемые в управлении проектами;
3. Стандарт управления проектом.

2. Общие принципы

2.1. Цели настоящего положения

Целями разработки и внедрения настоящего положения являются:

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

2.2. Границы применения настоящего положения

Область применения настоящего положения:

От начала выполнения проектов компании до завершения выполнения проектов компании.

В область применения не входят:

1. Принятие решений о необходимости и выполнении проектов;
2. Выбор руководителя и участников проекта;
3. Предпроектное исследование (разработка общего видения целей и задач проекта);
4. Разработка факторов риска и средств по борьбе с ними;
5. Оперативное управление решением задач проекта (в том числе координация работ с внешними группами).

• Контрагент;
• Задача (предварительное понимание задачи);
• Назначенный руководитель проекта;
• Предварительный состав участников проекта.

• Завершенные работы;
• Подготовленная отчетная документация.

2.3. Модель управления проектами компании (критерии выбора решений)

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

1. Выделение только трех фаз проекта:

• Инициирование;
• Выполнение;
• Завершение.

2. Выделение четырех важнейших подсистем управления:

• Управление результатами;
• Управление временем и работами;
• Управление знаниями;
• Управление затратами.

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

Как дополнительная выделяется подсистема управления качеством.

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

В качестве экспертных идей настоящего положения предлагаются следующие:

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

В основу реализации модели управления проектами заложены следующие ключевые тезисы:

1. Технологические особенности бизнеса компании;
2. Организационное разделение ответственности между задачами целеполагания и выполнения работ по достижению поставленных целей;
3. Одна подсистема управления — один главный инструмент (но не единственный);
4. Документирование значимых для реализации проекта событий и результатов;
5. Основные знания компании выражаются в следующем:
6. Порядок работ (внутренний );
7. Шаблоны используемых документов по проекту;
8. наработки (конфигурации, настройки ).
9. Экспертный контроль реализации проектов.

3. Роли — зоны ответственности

Роли (зоны ответственности) описываются следующими понятиями:

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

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

Ответственность выражается в следующих формах:

1. Действия;
2. Принятие решений;
3. Утверждение — право высказывания мнения и влияние на принятие определенных решений;
4. Контроль — проверка соответствия результата определенным требованиям.

В настоящее время в компании выделяются следующие роли (представлены в виде краткого описания):

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

4. Стандарт управления проектом

4.1. Структура проектов

В настоящем стандарте рассматриваются правила управления проектами следующих типов:

1. Внутренние проекты — цели лежат в области развития компании и направлений деятельности компании;
2. Внешние проекты — развитие (услуги для) клиентов компании.

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

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

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

1. Управление результатами;
2. Управление работами и временем;
3. Управление знаниями;
4. Управление затратами;
5. Управление качеством — техническая подсистема, включаемая для упорядочивания (контроля качества) ведения документов по проекту.

4.3. Принципы регламента

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

Главными инструментами являются следующие документы (см. рис):

1. Резюме проекта;
2. Спецификация результатов;
3. ;
4. Смета затрат;
5. Экспертиза проекта.

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

• Форма извещения об отклонении;
• Ответственное лицо за принятие решения по отклонениям;
• Схема передачи извещения об отклонениях;
• Сроки передачи извещения об отклонениях;
• Инициатор рассмотрения извещения об отклонениях;
• Форма рассмотрения извещения об отклонениях;
• Список ролевых участников рассмотрения извещения об отклонениях;
• Сроки принятия решения по отклонениям.

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

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

• Ответственный;
• Требования к срокам выполнения;
• Наименование и статус исходящего документа.

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

Далее представлены характеристики каждой подсистемы управления проектом.

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

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

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

1. Инициирование проекта
   При инициировании проекта формируется первоначальная спецификация.
   Основная задача — корректно сформулированный результат, актуальный до начала выполнения проекта.
   Также здесь формируется раздел, описывающий запланированные результаты этапов работы (формируется руководителем проекта);
2. Выполнение проекта
   Основная задача — актуализация спецификации, её расширение и изменение.
   Отражение факта достижения выделенных результатов, вклад каждого участника проекта;
3. Завершение проекта
   Основная задача — подведение итогов и выделение достижений команды и каждого участника проекта.

Подсистема Управление временем и работами

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

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

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

1. Этап/Задача/ Работа;
2. Участник (и) (исполнитель и ответственный);
3. Дата, время плановое;
4. Дата, время фактическое;
5. Дата завершения работ (ориентировочная);
6. Причины отклонений.

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

Подсистема Управление затратами

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

1. Инициирование проекта
   Формируется плановая смета затрат.
   Основная задача — адекватная прогнозная оценка затрат, связанных с реализацией проекта;
2. Выполнение проекта
   Отражение факта понесенных затрат, расширение плановой части сметы;
3. Завершение проекта
   Подведение финансовых итогов проекта. Формирование результирующего отчета.

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

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

Основной инструмент подсистемы:

1. Инструменты предыдущих подсистем;
2. Используемые документы (рабочие и отчетные);
3. Используемые средства (ПАС);
4. Документ — Экспертиза проекта.

1. Инициирование проекта
   Формируется перечень используемых документов и ПАС, ссылки на проекты, инструменты которых можно взять за основу разработки нормативных.
   Также формируется документ экспертиза проекта с выделением событий, которые надо «экспертировать».
   Форма для документов и ПАС: Наименование, Назначение, Есть ли в наличии — где.
   Форма для инструментов: Перечень проектов, контактных лиц;
2. Выполнение проекта
   Для утверждения каждого этапа проекта привлекается эксперт (эксперты).
   Основная задача — анализ решений и результатов этапа до его завершения и отражение результатов экспертного анализа в документе Экспертиза проекта. Рекомендации экспертизы — являются обязательными для исполнения в проекте.
   События, которые необходимо экспертировать, определяются на этапе инициирования проекта;
3. Завершение проекта
   Сбор и обобщение материалов, размещение их на хранение.
   Подготовка Резюмирующего раздела документа экспертиза проекта.

Подсистема Управления качеством

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

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

1. Проектной документации, описанной выше;
2. Формальной документации, связанной с реализацией проекта (подробно рассматривается в регламенте ведения документации).

1. Документ — Резюме проекта;
2. Регламент ведения документации.

5. Регламент ведения документации

5.1. Управление результатами

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

Регламентные действия

Действия Ответственный Требования к срокам Документ Статус документа Инициирование проекта Выполнение проекта Завершение проекта

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

Отклонения

1. Руководитель направления;
2. Менеджер проекта;
3. Эксперт проекта № 1;
4. Эксперт проекта № 2.

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

5.2. Управление работами и временем

Регламентные действия

Действия Ответственный Требования к срокам Документ Статус документа Инициирование проекта Выполнение проекта Завершение проекта

Разработка внутреннего работ	Менеджер проекта	После подготовки спецификации результатов	Внутренний	На рассмотрение
Рассмотрение внутреннего , внесение корректив и замечаний	Руководитель направления	В течение дня после получения документа	Внутренний	Рассмотрен
Передача рассмотренного внутреннего на доработку менеджеру проекта	Руководитель направления	По завершении рассмотрения внутреннего	Внутренний	Рассмотрен
Разработка плана загрузки ресурсов проекта на основе формы внутреннего	Менеджер проекта	После получения внутреннего с замечаниями	Внутренний	Актуальный
Передача внутреннего работ на экспертизу	Менеджер проекта	По завершении разработки	Внутренний	На экспертизу
Экспертиза внутреннего работ	Эксперт	В течение дня после получения	Внутренний	Согласован
Передача внутреннего работ на утверждение руководителю направления	Эксперт	По завершении экспертизы	Внутренний	На утверждение
Утверждение внутреннего	Руководитель направления	В течение часа после получения документа	Внутренний	Утвержден
Передача документа на контроль качества документации	Руководитель направления	В течение часа после получения утвержденного документа	Внутренний	Утвержден
Контроль соблюдения требований к нормативной документации компании	Менеджер по качеству	В течение часа после получения	Внутренний	Согласован
Размещение на хранение, информирование участников проекта	Менеджер по качеству	В течение двух часов после проверки	Внутренний	Результирующий
Формирование еженедельного плана работ по каждому участнику проекта	Менеджер проекта	Не позднее 17:30 пятницы предыдущей недели	Внутренний	Актуальный
Отражение фактического выполнения плана	Менеджер проекта	До 17:30 пятницы отчетной недели	Внутренний	Актуальный
Завершающая обработка внутреннего	Руководитель направления	В течение недели после завершения проекта, если не оговорена срочность исполнения	Внутренний	На согласование
Контроль соблюдения требований к нормативной документации компании	Менеджер по качеству	В течение двух часов после получения	Внутренний	Согласован
Размещение на хранение, информирование участников проекта	Менеджер по качеству	В течение двух часов после проверки соблюдения требований к нормативной документации	Внутренний	Результирующий

Отклонения

1. Руководитель направления;
2. Менеджер проекта;
3. Эксперт проекта № 1;
4. Эксперт проекта № 2.

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

5.3. Управление затратами

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

Регламентные действия

Действия Ответственный Требования к срокам Документ Статус документа Инициирование проекта Выполнение проекта Завершение проекта

Подготовка плановой сметы затрат	Руководитель направления	После подготовки	Плановая смета затрат	На согласование, ДСП
Уточнение плановой сметы затрат	Менеджер проекта	В течение двух часов после получения	Плановая смета затрат	На согласование, ДСП
Передача плановой сметы затрат на утверждение Руководителю компании	Руководитель направления	После уточнения сметы затрат менеджером проекта	Плановая смета затрат	На утверждение, ДСП
Утверждение плановой сметы затрат	Руководитель компании	По мере возможности	Утвержденная плановая смета затрат	Утвержден, ДСП
Формирование отчетной части. Внесение корректив в смету.	Менеджер проекта	До 17:30 пятницы отчетной недели	Смета затрат	Актуальный, ДСП
Завершающая обработка документа	Менеджер проекта	В течение недели после завершения проекта	Смета затрат	Актуальный, ДСП
Довести до сведения руководителя направления	Менеджер проекта	В течение часа после завершения обработки документа	Смета затрат	На согласование, ДСП
Экспертиза сметы затрат	Руководитель направления	В течение часов после получения	Смета затрат	Согласован, ДСП
Передача проверенной сметы затрат на утверждение Руководителю компании	Руководитель направления	По окончании экспертизы	Смета затрат	На утверждение, ДСП
Подведение итогов	Руководитель компании	По мере возможности	Смета затрат	Утвержден, ДСП

Отклонения

1. Руководитель направления;
2. Руководитель компании;
3. Менеджер проекта.

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

5.4. Управление знаниями

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

Регламентные действия

Действия Ответственный Требования к срокам Документ Статус документа Инициирование проекта Выполнение проекта Завершение проекта

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

Отклонения

1. Руководитель направления;
2. Менеджер проекта;
3. Эксперт проекта № 1;
4. Эксперт проекта № 2.

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

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

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

Регламентные действия

Действия Ответственный Требования к срокам Документ Статус документа Инициирование проекта Выполнение проекта Завершение проекта

Актуализация требований по ведению проектной и формальной документации, связанной с реализацией проекта	Директор по качеству	По мере необходимости	СТП	Актуальный
Корректировка Регламента ведения документации в соответствии с установленными требованиями,	Менеджер по качеству	В течение дня после получения изменений требований по ведению документации	Регламент ведения документации	Актуальный
Передача актуализированного Регламента ведения документации на согласование Директору по качеству	Менеджер по качеству	После завершения корректировки Регламента ведения документации	Регламент ведения документации	На согласование
Ознакомление с Регламентом ведения документации	Директор по качеству	В течение дня после получения Регламента ведения документации	Регламент ведения документации	Согласован
Формирование (актуализация) балльной шкалы оценок регламентных действий	Директор по качеству	В течение дня после получения	Регламент ведения документации	На утверждение
Утверждение балльной шкалы оценок	Руководитель компании	По мере возможности	Регламент ведения документации	Утвержден
Размещение актуализированных документов	Менеджер по качеству	В течение часов после получения	Комплект подготовленных документов	Результирующий
Контроль соблюдения требований к нормативной документации компании, заполнение журнала несоответствий	Менеджер по качеству	По мере поступления документов на контроль	Журнал несоответствий проектной документации, часть 1	Актуальный
Текущий анализ несоответствий	Директор по качеству	До 17:30 пятницы отчетной недели	Журнал несоответствий проектной документации, часть 1	Актуальный
Итоговый анализ качества ведения проектной документации и эффективности информационного обмена в рамках проекта	Директор по качеству	В течение недели после завершения проекта	Журнал несоответствий (заполнена часть 2)	Результирующий

Отклонения

1. Директор по качеству;
2. Менеджер по качеству.

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

Источник: www.businessstudio.ru