Приложение I. Распределение бюджетов по уровням ответственности (к главе 1)
Приложение II. Пример карты процессов (к главе 3)
Приложение III. Обзор нотаций моделирования бизнес-процессов (к главе 3)
Стандарты графического описания бизнес-процессов (БП)
В настоящее время широко используются и очень популярны несколько стандартов описания бизнес-процессов:
• семейство стандартов IDEF (в частности, IDEFo, DFD, IDEF3);
• семейство стандартов ARIS (в частности, нотация eEPC);
• семейство стандартов UML (Usecase diagram, activity diagram);
• кроссфункциональная нотация.
Каждое из этих семейств стандартов представляет собой определенную методологию и реализовано рядом программных продуктов (CASE-средств). Наиболее популярное программное обеспечение (ПО), реализующее ту или иную методологию, представлено в табл. III.1.
Таблица III.1
Разумеется, в таблице представлены далеко не все программные продукты, которые реализуют ту или иную нотацию описания. На самом деле их значительно больше. Также нотации описания бизнес-процессов заложены в функциональные возможности программ семейства «1С: Предприятия 8».
Семейство стандартов IDEF
Стандарт моделирования бизнес-процессов IDEFo был принят в качестве такового в 1981 г. Исторически он возник из стандарта SADT (Structured Analysis and Design Teqnique), активно применявшегося с конца 1960-х гг., в частности Министерством обороны США. IDEF является аббревиатурой от ICAM DEFinition. ICAM – Integrated Computer Aided Manufacturing.
Семейство стандартов IDEF включает в себя ряд графических нотаций, которые могут быть использованы для моделирования БП:
• IDEFo – стандарт описания бизнес-процессов;
• DFD – диаграмма потока данных (DataFlow Diagram);
• IDEF3 – стандарт моделирования потока работ (workflow).
Более подробное описание данных нотаций моделирования приведено далее.
Семейство стандартов ARIS
ARIS расшифровывается как Arhitecture of Integrated Information Systems – архитектура интегрированных информационных систем. В методологию ARIS входит пять типов представлений моделей:
• организационные модели, описывающие иерархическую структуру системы: иерархию организационных подразделений, должностей, полномочий конкретных лиц и т. д.;
• функциональные модели, описывающие функции (процессы, операции), выполняемые в организации;
• информационные модели (модели данных), отражающие структуру информации, необходимой для реализации всей совокупности функций системы;
• модели процессов/управления, представляющие комплексный взгляд на реализацию деловых процессов в рамках системы и объединяющие вместе другие модели;
• модели входов и выходов, описывающие потоки материальных и нематериальных входов и выходов процедур, включая, в частности, потоки денежных средств.
В каждом из этих типов моделей есть ряд нотаций, отличающихся методами моделирования, и число этих нотаций довольно велико. В частности, ARIS Toolset поддерживает ряд нотаций языка моделирования UML – Unified Modeling Language.
Число поддерживаемых ARIS нотаций довольно велико, и описывать каждую из них нецелесообразно. Имеет смысл дать основы нотации eEPC как наиболее, на наш взгляд, применимой для моделирования бизнес-процессов.
Нотация ARIS eEPC расшифровывается следующим образом: Extended Event Driven Process Chain – расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В табл. III.2 приводятся основные используемые в рамках нотации графические объекты.
Таблица III.2
В таблице указаны лишь основные виды пиктограмм, применяемые в данной нотации. Использование большего числа элементов допустимо, но делает модель плохо читаемой.
На рис. III.1 представлена простейшая модель eEPC, описывающая фрагмент бизнес-процесса предприятия.
Рис. III.1
На рис. III.1 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1, «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания:
• каждая функция должна быть инициирована событием и должна завершаться событием;
• в каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции, и выходить более одной стрелки, описывающей завершение выполнения функции.
Кроме этих правил существуют и другие важные правила формирования моделей в ARIS. Эти правила можно изучить при помощи методического материала «Методы ARIS», который устанавливается на компьютер одновременно с демоверсией продукта.
На рис. III.2 показано применение различных объектов ARIS при создании модели бизнес-процесса.
Каждый объект в системе ARIS Toolset, которая поддерживает метод описания бизнес-процессов ARIS, имеет определенный набор атрибутов. Пользователю предлагается воспользоваться стандартными атрибутами для описания объектов или ограниченным количеством так называемых пользовательских атрибутов.
Из рис. III.2 видно, что бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в eEPC визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе MS Project.
Рис. III.2
Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций).
Семейство стандартов UML
Аббревиатура UML расшифровывается как Unified Modeling Language– унифицированный язык моделирования.
UML предназначен в первую очередь для быстрого проектирования и разработки программных продуктов, и описание бизнес-процессов с его использованием целесообразно делать, если в конечном итоге требуется разработать корпоративную информационную систему, которая бы отражала особенности протекания бизнес-процессов на предприятии заказчика.
Язык UML был создан в компании Rational одним из ведущих идеологов объектно-ориентированного подхода к программированию Гради Бучем (Grady Booch), совместно с Джимом Рамбо (Jim Rumbaugh) и Иваром Джекобсоном (lvar Jacobson)в 1994 г.
UML включает в себя ряд типов диаграмм, некоторые из которых могут быть использованы для моделирования бизнес-процессов. В частности, это диаграмма прецедентов (Use-case diagram) и диаграмма действий (Activity Diagram).
Диаграмма прецедентов служит для моделирования типичных сценариев работы с системой.
Диаграмма прецедентов состоит из прецедентов (use-case) – типичных взаимодействий между пользователем и компьютерной системой, и субъектов (actor) – ролей, которые пользователи играют относительно системы. Также на ней могут быть указаны отношения между прецедентами: связь расширения (extends) и связь использования (uses).
Рис. III.3. Эффективность использования различных нотаций моделирования БП
Диаграмма действий имеет много общего с блок-схемой, но на ней можно также показывать параллельные процессы. Диаграмма состоит из действий – задач, которые должны быть выполнены человеком или компьютером – условных и безусловных переходов, и распараллеливания.
Основы нотаций описания бизнес-процессов IDEF0 и DFD
В основе методологии IDEFo лежат три основных понятия:
• функциональный блок (Activity Box);
• интерфейсная дуга (Arrow);
• декомпозиция (Decomposition).
Функциональный блок графически изображается в виде прямоугольника и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги», а не «производство услуг»).
Каждая из четырех сторон функционального блока (рис. III.4) имеет свое определенное значение (роль), при этом:
• верхняя сторона имеет значение «Управление» (Control);
• левая сторона имеет значение «Вход» (Input);
• правая сторона имеет значение «Выход» (Output);
• нижняя сторона имеет значение «Механизм» (Mechanism).
Рис. III.4
Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.
Интерфейсная дуга – второе важное понятие методологии IDEFo. Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.
Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта наименование должно быть оборотом существительного.
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т. д.) или потоки данных и информации (документы, данные, инструкции и т. д.).
В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей». Кроме того, «источником» (началом) и «приемником» (концом) каждой функциональной дуги могут быть только функциональные блоки, при этом «источником» может быть только выходная сторона блока, а «приемником» – любая из трех оставшихся.
Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь по крайней мере одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен проходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла.
При построении IDEFo-диаграмм важно правильно отделять входящие интерфейсные дуги от управляющих, что часто бывает непросто. К примеру, на рис. III.5 изображен функциональный блок «Обработать заготовку».
В реальном процессе рабочему, производящему обработку, выдают заготовку и технологические указания по обработке (или правила техники безопасности при работе со станком). Ошибочно может показаться, что и заготовка, и документ с технологическими указаниями являются входящими объектами, однако это не так. На самом деле в этом процессе заготовка обрабатывается по правилам, отраженным в технологических указаниях, которые должны соответственно изображаться управляющей интерфейсной дугой.
Рис. III.5
Другое дело, когда технологические указания обрабатываются главным технологом и в них вносятся изменения. В этом случае они отображаются уже входящей интерфейсной дугой, а управляющим объектом являются, например, новые промышленные стандарты, исходя из которых производятся данные изменения (рис. III.6).
Рис. III.6
Приведенные выше примеры подчеркивают внешне схожую природу входящих и управляющих интерфейсных дуг, однако для систем одного класса всегда есть определенные разграничения. Например, в случае рассмотрения предприятий и организаций существуют пять основных видов объектов: материальные потоки (детали, товары, сырье и т. д.), финансовые потоки (наличные и безналичные, инвестиции и т. д.), потоки документов (коммерческие, финансовые и организационные документы), потоки информации (информация, данные о намерениях, устные распоряжения и т. д.) и ресурсы (сотрудники, станки, машины и т. д.). При этом в различных случаях входящими и исходящими интерфейсными дугами могут отображаться все виды объектов, управляющими – только относящиеся к потокам документов и информации, а дугами-механизмами – только ресурсы.
Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEFo от других методологий классов DFD (Data Flow Diagram)и WFD (Work Flow Diagram).
Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии или, наоборот, – отдельные дуги не имеют практического смысла выше какого-то уровня. Например, интерфейсную дугу, изображающую «деталь» на входе в функциональный блок «Обработать на токарном станке», не имеет смысла отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. Но при этом бывает и необходимость избавиться от отдельных «концептуальных» интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEFo предусмотрено понятие туннелирования.
Обозначение «туннеля» (Arrow Tunnell) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока-приемника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет.
Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии; в таком случае они сначала «погружаются в туннель», а затем, при необходимости, «возвращаются из туннеля».
Третьим основным понятием стандарта IDEFo является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.
Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Модель IDEFo всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой и обозначается идентификатором «А-0».
Обычно IDEFo-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в соответствующем стандарте приняты соответствующие ограничения сложности:
• ограничение количества функциональных блоков на диаграмме тремя-шестью. Верхний предел (шесть) заставляет разработчика использовать иерархии при описании сложных предметов, а нижний предел (три) гарантирует, что на соответствующей диаграмме достаточно деталей, чтобы оправдать ее создание;
• ограничение количества подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг четырьмя.
Разумеется, строго следовать этим ограничениям вовсе не обязательно, однако, как показывает опыт, они являются весьма практичными в реальной работе.
Очень важно при построении модели четко обозначить цель (purpose) и точку зрения (viewpoint)модели.
Цель и точка зрения являются весьма важными моментами, влияющими на само содержание модели. Модель бизнес-процессов предприятия, которую создают с целью разработки корпоративной информационной системы, будет существенно отличаться от модели, созданной для регламентации деятельности подразделений компании.
Необходимо понимать, что модель БП с точки зрения главного инженера и с точки зрения главного бухгалтера будут существенно различаться. Точка зрения – это своего рода «фильтр» для процесса.
Основы DFD
В основе нотации DFD лежат следующие понятия:
• работа;
• дуга;
• внешняя ссылка;
• хранилище данных.
Работы в DFD обозначают функции или процессы, которые обрабатывают и изменяют информацию. Работы представлены на диаграммах в виде прямоугольников со скругленными углами.
Дуги (стрелки) идут от объекта-источника к объекту-приемнику, обозначая информационные потоки в системе документооборота.
Внешние ссылки указывают на место, организацию или человека, которые участвуют в процессе обмена информацией с системой, но располагаются за рамками этой диаграммы.
Хранилища данных представляют собой собственно данные, к которым осуществляется доступ, эти данные также могут быть созданы или изменены работами. На одной диаграмме может присутствовать несколько копий одного и того же хранилища данных.
Рис. III.7
В диаграммах потоков данных все используемые символы складываются в общую картину, которая дает четкое представление о том, какие данные используются и какие функции выполняются системой документооборота. При этом часто выясняется, что существующие потоки информации, важные для деятельности компании, реализованы ненадежно и нуждаются в реорганизации.
Основы кроссфункциональной нотации
Схема бизнес-процесса (далее – схема БП) предназначена для:
• возможности проверки регламентируемого бизнес-процесса до написания текста рабочего регламента;
• наглядного представления последовательности процедур в разработанном рабочем регламенте.
Схема БП является графическим представлением (сверху вниз) последовательно выполняемых процедур. В случае, когда операции в рамках одной процедуры выполняют различные лица, допускается изображение операции либо совокупности операций.
Лист схемы (рабочее поле схемы) должен быть оформлен следующим образом. Рабочее поле разделяется на четыре зоны:
• «Исполнители»;
• «Действия»;
• «Условия»;
• «Результаты».
Рис. III.8. Рабочее поле схемы
Требования к оформлению полей схемы
В зоне «Исполнители» должен быть указан субъект, который выполняет ту или иную процедуру (или субъекты, выполняющие процедуру).
В зоне «Процедура» должны быть указаны процедура и укрупненный перечень действия, которые выполняет субъект (субъекты).
В зоне «Условия» указываются условия процесса. Условия отражают различные разветвления процесса в зависимости от результата действия. При заполнении данной зоны необходимо помнить, что «незначимые» условия не отражаются на схеме. К «незначимым» условиям относятся такие, которые возвращают процесс на шаг назад (к предыдущей процедуре) или к самой же процедуре, но такие условия всегда отражаются в тексте регламента бизнес-процесса, в разделе 3 «Требования к процедурам».
В зоне «Результаты» отражаются все результаты процедуры.
Элементы схемы БП
При изображении регламентируемого БП рекомендуется использовать только элементы, приведенные в табл. III.3.
Таблица III.3
Состав элементов одной процедуры
Каждая процедура в схеме должна состоять из следующих элементов, размещаемых графически слева направо:
1) исполнитель;
2) процесс;
3) один или несколько результатов выполнения процесса.
В случае, если в ходе выполнения процесса возможны два различных варианта результатов, в процедуру (между процессом и результатом) добавляется элемент «Решение» с положительным и отрицательным вариантами результата.
Все однотипные элементы схемы БП должны быть одинаковой ширины и находиться на одной линии по отношению друг к другу. Описание каждого из элементов должно находиться внутри самого элемента (использование выносного текста не допускается).
Соединение элементов схемы БП
Элементы схемы соединяются между собой с помощью стрелок связи. Допускается изображать стрелки связи в качестве комбинации горизонтальных и вертикальных (но не наклонных!) отрезков (см. примеры ниже). Рекомендуется избегать пересечения стрелок связи.
Стрелки связи соединяют элементы следующим образом (указаны начало и конец стрелки):
1. Правая сторона исполнителя и левая сторона процесса.
2. Правая сторона процесса и левая сторона результата.
3. Правая (либо нижняя) сторона результата и верхняя (либо левая) сторона исполнителя следующей (либо иной) процедуры или бизнес-процесса.
При наличии условий, определяющих различные варианты результата выполнения процесса, п. 2 разбивается на два:
2а) правая сторона процесса и левая вершина решения;
2б) правая вершина решения и левая сторона результата при положительном решении (с написание «да» на стрелке), а также нижняя вершина решения и левая сторона результата при отрицательном решении (с написанием «нет» на стрелке).
На рис. III.9—III.11 приведены примеры графического изображения процедур.
Рис. III.9. Простая процедура
Рис. III.10. Процедура с несколькими результатами
Рис. III.11. Процедура с решением
Каждая из процедур в рамках регламентируемого БП должна быть соединена стрелками связи, при этом результат предыдущей процедуры является входящей информацией для исполнителя последующей. Если для выполнения регламентируемого БП используются результаты выполнения других бизнес-процессов (документы, БД, материальные объекты и пр.), сам бизнес-процесс и его результаты изображаются выше первой процедуры. Результат последней процедуры должен совпадать с конечным результатом.
Пример «Схема работ по разработке РР».
Рис. III.12. Пример схемы работ по разработке РР
Приложение IV. Структура организационно-нормативных документов (к главе 4)
К пакету регламентирующих документов, описывающих деятельность организации, относятся:
• положение о системе управления компании;
• положения о высших должностных лицах компании;
• положения о направлениях деятельности;
• положения о подразделениях;
• рабочие регламенты (регламенты бизнес-процессов);
• должностные инструкции;
• рабочие инструкции (методические рекомендации).
Положение о системе управления
Общие положения
Назначение документа.
Область применения.
Термины и определения.
Ссылки на иные нормативные документы.
Направления деятельности
Перечень направлений деятельности компании.
Принципы организации системы управления
Организационная структура компании.
Принципы организации системы управления, сгруппированные по организационным уровням (зависит от структуры компании).
Распределение полномочий и ответственности
Распределение полномочий и ответственности функциональных и организационных блоков.
Положение о направлении деятельности
Общие положения
Назначение документа.
Область применения.
Термины и сокращения.
Принципы осуществления деятельности
Принципы распределения ответственности.
Роли должностных лиц.
Требования к бизнес-процессам
Перечень бизнес-процессов.
Краткое описание каждого процесса.
Контроль и ответственность
Кто и каким образом контролирует выполнение требований настоящего документа.
Кто и каким образом отвечает за соблюдение требований настоящего документа.
Положение о подразделении
Общие положения
Назначение документа.
Наименование подразделения и компании, в структуру которой входит.
Кому подчиняется подразделение.
Структура подразделения.
Кто имеет право назначать и освобождать от должности сотрудников подразделения.
Кто осуществляет непосредственное руководство подразделением.
Кто должен знать и использовать в своей работе данный документ.
Какими документами в своей деятельности руководствуется.
Направления деятельности
Направления деятельности, которыми занимается данное подразделение.
Функции
В рамках каждого из направлений деятельности подразделение выполняет определенные функции, которые перечисляются в настоящем разделе.
Взаимоотношения
С какими подразделениями взаимодействует данное подразделение, для какой цели и какую информацию (документы) получает/передает.
Права
Указываются права руководителя и сотрудников подразделения, необходимые для осуществления деятельности подразделения.
Ответственность
Указывается ответственность руководителя и сотрудников подразделения за выполнение/невыполнение задач подразделения. Кто и какую ответственность налагает.
Должностная инструкция
Общие положения
Назначение документа.
Кому подчиняется сотрудник.
Документы, используемые в работе.
Необходимые знания, умения, навыки, необходимые на данной должности.
Основные задачи
Основные задачи – логическое объединение выполняемых функций.
Обязанности (функции)
Функции, которые должен выполнять сотрудник, сгруппированные по признаку единства задач.
Права
Права сотрудника в рамках осуществления деятельности.
Ответственность
Указывается ответственность за выполнение/невыполнение рабочих обязанностей.
Рабочая инструкция
Формат рабочей инструкции не устанавливается, он зависит от сути и содержания документа. Может быть не только в виде текста, но и в виде серии рисунков, отображающих порядок действий.
Приложение V. Пример плана проекта организационных изменений (к главе 4)
ОПЕРАЦИОННЫЙ ПЛАН СОЗДАНИЯ ТЕРРИТОРИАЛЬНОЙ ГЕНЕРИРУЮЩЕЙ КОМПАНИИ (ТГК)
Приложение VI. Метод инженера Ковалева (к главе 5)
Инженером Ф. Ковалевым предложен следующий алгоритм рационализации трудовых процессов:
1. Выбирается самая трудоемкая и достаточно распространенная рабочая операция.
2. Выявляются работники, которые выполняют ее наиболее успешно.
3. Выполняется хронометражное наблюдение за работниками.
4. Формируется новый, более рациональный трудовой процесс на основе использования передовых приемов труда.
5. Составляются инструкции по технологии осуществления нового трудового процесса.
6. Разрабатываются и внедряются организационно-технические мероприятия на рабочих местах, где выполняется рассматриваемая операция.
7. Работники обучаются новому трудовому процессу в установленные сроки.
8. Внедрение новой нормы труда.
Рассмотрим пример.
Пусть действующая норма времени на операцию составляет 27 минут. Практически все работники цеха ее выполняют. Однако рабочие Иванов, Петров и Сидоров регулярно перевыполняют норму, при этом обеспечивают высокое качество продукции.
В табл. VI.1 представлены результаты хронометражных наблюдений за передовыми рабочими.
Таблица VI.1
Существуют три подхода к установлению новой нормы:
1. Устанавливать новую норму как среднее время выполнения операции передовиками, т. е. 23 минуты. Однако в этом случае трудно определить причины перевыполнения действующей нормы. Поэтому основной массе рабочих будет сложно достичь более высокого профессионального уровня.
2. За новую норму принять результат лучшего передовика – Сидорова (22 минуты). Данную норму можно обосновать, изучив приемы труда данного конкретного работника.
3. Изучить и отобрать лучшие приемы труда передовых рабочих и установить новую норму времени в 19 минут. С одной стороны, она является обоснованной, а с другой – позволяет достичь более высоких результатов, так как обобщает опыт всех передовых рабочих. Именно этот подход использовал инженер Ф. Ковалев.
Приложение VII. Пример регламента по управлению издержками (к главе 7)
Содержание
1. Общие положения
1.1. Назначение
1.2. Область применения
1.3. Термины и определения
2. Инициация проекта по снижению издержек
2.1. Общая характеристика процесса
2.2. Определение основных направлений проекта. Выбор руководителя проекта
2.3. Формирование проектных групп и оценочной комиссии
2.4. Разработка проекта приказа
2.5. Согласование приказа
2.6. Утверждение приказа
3. Планирование работ проекта
3.1. Общая характеристика процесса
3.2. Постановка задачи руководителям групп проекта
3.3. Создание структурной декомпозиции работ
3.4. Расстановка сроков выполнения работ и контрольных точек
3.5. Планирование человеческих ресурсов
3.6. Утверждение плана проекта
4. Проведение укрупненного анализа направлений
4.1. Общая характеристика процесса
4.2. Сбор необходимой информации
4.3. Проведение предварительного анализа направлений (по блокам)
4.4. Объединение результатов анализа с расстановкой приоритетов
4.5. Разработка проекта уточненного перечня направлений
4.6. Корректировка и утверждение перечня направлений
5. Проведение детального анализа направлений СИ
5.1. Общая характеристика процесса
5.2. Сбор дополнительной информации о направлениях (поблочно)
5.3. Проведение детального анализа блоков направлений
5.4. Сведение результатов и оценка экономических эффектов от мероприятий
5.5. Формирование вариативной программы мероприятий
5.6. Формирование отчета о результатах анализа
6. Формирование программы мероприятий
6.1. Общая характеристика процесса
6.2. Ознакомление оценочной комиссии с результатами анализа
6.3. Проведение оценочной сессии
6.4. Формирование проекта программы мероприятий
6.5. Согласование проекта программы мероприятий
6.6. Утверждение программы мероприятий
7. Планирование реализации мероприятий
7.1. Общая характеристика процесса
7.2. Назначение исполнителей мероприятия
7.3. Формирование перечня работ для выполнения мероприятия
7.4. Определение сроков выполнения мероприятия и контрольных точек
7.5. Проведение совещания по определению рисков и согласованию плана
7.6. Утверждение плана реализации мероприятий
8. Организация и контроль реализации
8.1. Общая характеристика процесса
8.2. Проведение установочного рабочего совещания
8.3. Реализация мероприятия
8.4. Проведение внеплановых проверок реализации мероприятий
8.5. Проверка соблюдения сроков и качества выполнения работ
8.6. Разработка отчетных документов по результатам выполнения работ
8.7. Приемка выполненных работ. Оценка результатов.
9. Контроль и ответственность
4.1. Контроль выполнения процедур
4.1. Ответственность должностных лиц за соблюдение данной инструкции
Приложение 1
Приложение 2
1. Общие положения
1.1. Назначение.
1.1.1. Объединенный рабочий регламент предназначен для формализации правил проведения работ по снижению издержек в ООО «ZZZZ» (далее – компания).
1.1.3. Настоящий регламент вступает в силу с момента введения его в действие приказом генерального директора компании и действует до выпуска заменяющего или аннулирующего его документа либо до выделения филиала в самостоятельное юридическое лицо.
1.2. Область применения.
1.2.1. Регламент определяет последовательность выполнения процедур следующих процессов:
а) инициация проекта по снижению издержек (СИ) (п. 3);
б) планирование работ проекта (п. 4);
в) проведение укрупненного анализа направлений СИ (п. 5);
г) проведение детального анализа направлений СИ (п. 6);
д) формирование программы мероприятий (п. 7);
е) планирование реализации мероприятий (п. 8);
ж) организация и контроль реализации (п. 9).
1.2.2. Детальное «дерево процессов» представлено в приложении 1.
1.2.3. Отдельный процесс содержит 5–6 процедур, каждая из которых выполняется одним сотрудником или коллегиальным органом (комиссия, группа).
1.2.4. Модель процессов верхнего уровня представлена в приложении 2 Node: А-0, Ао.
1.2.5. Модели выполнения работ в процессах представлены в приложении 2 (Node: А1 – А7).
1.2.6. Данный регламент должны знать и использовать должностные лица компании, выполняющие работу по снижению издержек и перечисленные в соответствующем приказе генерального директора о начале работ.
1.3. Термины и определения.
1.3.1. В настоящем регламенте используются следующие термины:
а) инициатор работ – должностное лицо компании не ниже заместителя генерального директора;
б) руководитель проекта – должностное лицо компании не ниже директора по направлению деятельности;
в) оценочная комиссия – коллегиальный орган, принимающий решения относительно необходимости реализации каких либо действий. В оценочную комиссию могут входить должностные лица компании не ниже директора по направлению деятельности;
г) руководитель группы проекта по направлению – должностное лицо компании не ниже руководителя структурного подразделения (производственной единицы).
2. Инициация проекта по снижению издержек
2.1. Общая характеристика процесса.
2.1.1. Процесс состоит из следующих последовательно выполняемых процедур:
а) определение основных направлений проекта. Выбор руководителя проекта;
б) формирование проектных групп и оценочной комиссии;
в) разработка проекта приказа;
г) согласование приказа;
д) утверждение приказа.
2.1.2. Модель процесса представлена в приложении 2 Node: А1.
2.1.3. Условием начала работ по процессу является наличие потребности в реализации основного или дополнительного проекта по СИ. Потребность может быть высказана собственником, генеральным директором компании или директором по направлению деятельности компании.
2.1.4. Условием окончания работ по процессу являются выпуск и передача инициатором работ руководителю проекта утвержденного приказа о реализации проекта и перечня основных направлений проекта.
2.1.5. Действия, описываемые в рамках данного процесса, не распространяются на все процессы организации. Последовательность и правила выполнения работ, приведенные в настоящем разделе, регламентируют реализацию проектов компании по снижению издержек.
2.2. Определение основных направлений проекта. Выбор руководителя проекта.
2.2.1. Определение основных направлений проекта и выбор руководителя проекта производит инициатор работ после выявления потребности в снижении издержек компании.
2.2.2. Результатом выполнения данных работ является перечень основных направлений деятельности, составленный инициатором работ, устное извещение должностного лица компании о назначении его руководителем проекта и устное указание руководителю проекта о необходимости формирования групп проекта.
2.2.3. Перечень основных направлений деятельности, устные извещение и указание инициатор работ передает руководителю проекта в 3-дневный срок с момента выявления потребности в снижении издержек компании.
2.2.4. Если в ходе выполнения действий по данной процедуре инициатор работ принимает решение о привлечении к реализации проекта сторонних организаций, то вместо устного указания руководителю о необходимости формирования групп он дает указание о подборе сторонней организации, имеющей опыт проведения аналогичных работ.
2.3. Формирование проектных групп и оценочной комиссии
2.3.1. Формирование проектных групп и оценочной комиссии производит руководитель проекта после получения от инициатора работ документов и указаний, перечисленных в п.3.2.2.
2.3.2. При формировании проектных групп и оценочной комиссии руководитель проекта руководствуется следующими принципами:
а) группы проекта формируются отдельно, для каждого выделенного направления СИ;
б) группу проекта по направлению возглавляет руководитель, который в рамках проекта непосредственно подчинен руководителю проекта;
в) состав группы проекта определяется исходя из его специфики и сложности реализации;
г) в группу проекта могут входить специалисты различного профиля, при этом их квалификация должна быть достаточна для реализации проекта;
д) для управления коммуникациями проекта назначается секретарь проекта;
е) состав оценочной комиссии (комиссия по оценке мероприятий на целесообразность реализации и реальности достижения заявленного эффекта) определяется исходя из специфики и сложности проекта. При этом в ее состав могут войти должностные лица не ниже руководителя структурного подразделения компании;
ж) председателем с полномочиями организатора оценочного мероприятия является руководитель проекта. При этом руководитель проекта наряду с руководителями групп по направлениям представляет результаты работ на оценку комиссии.
2.3.3. Результатом проведения данных работ является «Состав рабочих групп и оценочной комиссии», документ (составленный в свободной форме).
3.3.4. Состав рабочих групп и оценочной комиссии руководитель проекта передает инициатору работ для включения в приказ о реализации проекта.
2.4. Разработка проекта приказа.
2.4.1. Разработку проекта приказа организует инициатор работ после получения от руководителя проекта состава проектных групп и оценочной комиссии.
2.4.2. В ходе организации разработки проекта приказа инициатор работ выполняет следующие действия:
а) поручает своему личному секретарю подготовить проект приказа о реализации проекта по снижению издержек на основании перечня основных направлений деятельности, а также состава проектных групп и оценочной комиссии;
б) поручает секретарю включение в приказ информации о назначении руководителя проекта;
в) поручает секретарю включение в приказ информации о системе мотивации проектного персонала;
г) поручает секретарю передачу проекта приказа на согласование руководителю проекта;
д) контролирует исполнение секретарем полученных указаний.
2.4.3. Результатом проведения данных работ является подготовленный проект приказа.
2.4.4. Секретарь инициатора работ передает проект приказа руководителю проекта на согласование в течение 1 рабочего дня с момента получения последнего указания по данному вопросу.
2.5. Согласование приказа.
2.5.1. Согласование приказа производит руководитель проекта после получения его проекта от секретаря инициатора работ.
2.5.2. В ходе согласования руководитель проекта осуществляет следующие действия:
а) проверяет приказ на полноту и правильность зафиксированной информации;
б) визирует проект приказа.
2.5.3. Результатом данной работы является завизированный руководителем проекта проект приказа.
2.5.4. Руководитель проекта передает завизированный проект приказа инициатору работ через его личного секретаря.
2.5.5. Если в результате проверки руководитель проекта выявляет неточности в предоставленной информации или не согласен с отдельными положениями, то он договаривается о встрече с инициатором работ, на которой разрешает возникшие вопросы.
2.6. Утверждение приказа.
2.6.1. Утверждает приказ инициатор работ, после получения согласованного его проекта от руководителя проекта.
2.6.2. В ходе утверждения инициатор работ осуществляет следующие действия:
а) проверяет приказ на полноту и правильность зафиксированной информации;
б) визирует проект приказа.
2.6.3. Результатом выполнения данных работ является утвержденный приказ о реализации проекта.
2.6.4. Инициатор работ передает утвержденный приказ руководителю проекта через секретаря в течение 1 рабочего дня после подписания для:
а) его выполнения;
б) ознакомления всех участников проекта.
2.6.5. Если в результате проверки инициатор работ выявляет неточности в предоставленной информации или не согласен с отдельными положениями, то он инициирует процесс внесения изменений в приказ с последующим повторным согласованием с руководителем проекта.
3. Планирование работ проекта
3.1. Общая характеристика процесса.
3.1.1. Процесс состоит из следующих последовательно выполняемых процедур:
а) постановка задачи руководителям групп проекта;
б) создание структурной декомпозиции работ;
в) расстановка сроков выполнения работ и контрольных точек;
г) планирование человеческих ресурсов;
д) утверждение плана проекта.
3.1.2. Модель процесса представлена в приложении 2 Node: А2.
3.1.3. Условием начала работ по процессу является наличие у руководителя проекта перечня основных направлений проекта и приказа о реализации проекта.
3.1.4. Условием окончания работ по процессу являются наличие в компании утвержденного плана проекта и факт его передачи руководителям групп проекта.
3.1.5. Действия, описываемые в рамках данного процесса, не распространяются на все процессы организации. Последовательность и правила выполнения работ, приведенные в настоящем разделе, регламентируют реализацию проектов компании по снижению издержек.
3.2. Постановка задачи руководителям групп проекта.
3.2.1. Постановку задач руководителям групп проекта производит руководитель проекта после получения от инициатора работ приказа о реализации проекта и на основании перечня основных направлений проекта.
3.2.2. При постановке задач руководитель проекта выполняет следующие действия:
а) распределяет направления проекта между группами проекта;
б) поручает руководителям групп проекта организовать разработку структурной декомпозиции работ по направлениям проекта и спланировать человеческие ресурсы после определения им сроков выполнения работ и контрольных точек;
в) определяет сроки и длительность выполнения поручения;
г) поручает секретарю проекта составить соответствующее распоряжение и передать его руководителям групп проекта.
3.2.3. Результатом данных работ является комплекс указаний в виде распоряжения о начале проекта, которое включает в себя деление направлений проекта между группами и сроки предоставления результатов работ.
3.2.4. Все указания и распоряжения даются руководителям групп в устном виде в рамках общего совещания по проекту, а затем дублируются в письменном (электронном) виде в формате распоряжения. Совещание и подготовка соответствующего распоряжения проводятся в течение 3 рабочих дней с момента получения руководителем проекта приказа о реализации проекта.
3.3. Создание структурной декомпозиции работ.
3.3.1. Формирование структурной декомпозиции работ (СДР) выполняет группа проекта по направлению, после получения от руководителя проекта распоряжения о начале проекта. Формированием структурной декомпозиции работ руководит руководитель группы проекта по направлению.
3.3.2. При формировании группой структурной декомпозиции работ руководитель выполняет следующие действия:
а) поручает специалистам группы разработать перечень работ необходимый, с их точки зрения, для реализации задач проекта;
б) контролирует процесс создания перечня с целью обеспечения высокой степени детализации, которая позволит расставить сроки выполнения каждой работы в интервале от 2 до 5 рабочих дней;
в) объединяет перечни специалистов в структурную декомпозицию работ и организует совещание группы по верификации и корректировке СДР;
г) корректирует и визирует СДР.
3.3.3. Результатом данных работ является завизированная руководителем группы проекта по направлению структурная декомпозиция работ.
3.3.4. Руководитель группы проекта по направлению передает СДР руководителю проекта в течение 5 рабочих дней с момента получения распоряжения о начале проекта.
3.4. Расстановка сроков выполнения работ и контрольных точек.
3.4.1. Расстановку сроков выполнения проекта и контрольных точек производит руководитель проекта после получения СДР от руководителей групп проекта по направлениям.
3.4.2. При выполнении работ по данной процедуре руководитель проекта выполняет следующие действия:
а) объединяет предоставленные СДР по направлениям в СДР проекта;
б) расставляет сроки выполнения каждой работы, руководствуясь желаемыми сроками реализации проекта, формируя тем самым расписание проекта;
в) определяет наиболее проблематичные в исполнении участки проекта и расставляет по ним контрольные точки;
г) определяет наибольшие разрывы в реализации проекта без контроля и расставляет соответствующие контрольные точки;
д) визирует полученное расписание проекта.
3.4.3. Результатом данных работ является завизированное руководителем проекта расписание проекта.
3.4.4. Руководитель проекта передает расписание проекта руководителям групп проекта по направлениям в течение 3 рабочих дней с момента получения от них СДР.
3.4.5. Если в ходе расстановки сроков выполнения работ руководитель выявляет неточность изложения СДР, нелогичность или работы, длительность которых превышает, по его мнению, 5 рабочих дней, то он инициирует внесение в СДР соответствующих изменений.
3.5. Планирование человеческих ресурсов.
3.5.1. Планирование человеческих ресурсов производят руководители групп проекта по направлениям после получения расписания проекта.
3.5.2. В ходе планирования человеческих ресурсов руководитель каждой группы проекта по направлению выполняет следующие действия:
а) соотносит каждого исполнителя группы проекта с работами проекта, перечисленными в расписании, избегая неравномерной загрузки специалистов с учетом их квалификации и сложности работ;
б) расставляет фамилии специалистов по работам внутри расписания, формируя тем самым проект плана проекта;
в) визирует проект плана.
3.5.3. Результатом данных работ является завизированный руководителями групп проекта по направлениям проект плана проекта.
3.5.4. Руководители групп проекта передают проект плана руководителю проекта для утверждения в течение 2 рабочих дней с момента получения расписания проекта.
3.6. Утверждение плана проекта.
3.6.1. Утверждает план проекта руководитель проекта, после получения его от руководителей групп.
3.6.2. При утверждении плана проекта руководитель выполняет следующие действия:
а) проверяет наличие виз всех руководителей групп;
б) проверяет распределение работ по исполнителям, анализируя равномерность загрузки;
в) визирует план проекта.
3.6.3. Результатом данных работ является утвержденный руководителем проекта план.
3.6.4. Руководитель проекта передает утвержденный план проекта руководителям групп проекта по направлениям для реализации в течение 2 рабочих дней.
3.6.5. Если в результате проверки наличия виз и распределения работ по исполнителям руководитель проекта выявляет недостаточность или неточность данных, то он организует внесение соответствующих изменений в план.
4. Проведение укрупненного анализа направлений
4.1. Общая характеристика процесса.
4.1.1. Процесс состоит из следующих последовательно выполняемых процедур:
a) сбор необходимой информации;
б) проведение предварительного анализа направлений (по блокам);
в) объединение результатов анализа с расстановкой приоритетов;
г) разработка проекта уточненного перечня направлений;
д) корректировка и утверждение перечня направлений.
4.1.2. Модель процесса представлена в приложении 2 Node: А3.
4.1.3. Условием начала работ по процессу является получение руководителем группы проекта:
а) обобщенного перечня основных направлений проекта по СИ от инициатора работ;
б) плана работ от руководителя проекта.
4.1.4. Условием окончания работ по процессу является скорректированный, утвержденный и переданный инициатором проекта руководителю группы проекта перечень основных направлений проекта для его последующего анализа.
4.1.5. Действия, описываемые в рамках данного процесса, не распространяются на все процессы организации. Последовательность и правила выполнения работ, приведенные в настоящем разделе, регламентируют реализацию проектов компании по снижению издержек.
4.2. Сбор необходимой информации.
4.2.1. Сбор необходимой информации организует руководитель группы проекта после получения:
a) обобщенного перечня основных направлений проекта по СИ от инициатора работ;
b) плана работ от руководителя проекта.
4.2.2. В процессе сбора информации руководитель группы проекта выполняет следующие действия:
а) определяет информацию, которую необходимо получить для последующего анализа направления СИ;
б) составляет список документов, в которых запрашиваемая информация может содержаться (калькуляция себестоимости, баланс, бюджеты, статистика по персоналу и др.);
в) определяет должностных лиц, которые могут предоставить соответствующую информацию.
г) определяет формат предоставления запрашиваемых данных (при личной встрече в процессе опроса или по электронной почте в указанные сроки согласно плану работ);
д) формирует запрос на предоставление необходимых для анализа документов;
е) организует взаимодействие участников группы проекта с представителями подразделений, владеющих информацией (при возникновении необходимости проведения опроса);
ж) консолидирует полученную информацию в комплект документов.
4.2.3. Результатом выполнения данных работ является сформированный комплект документов для анализа.
4.2.4. Сформированный комплект документов руководитель группы проекта передает специалистам группы проекта по направлению для последующего анализа.
4.2.5. Если руководитель группы проекта не получает в указанные сроки запрошенную информацию (или информация предоставляется не в полном объеме), он выясняет причины сложившейся ситуации и информирует об этом руководителя проекта.
4.3. Проведение предварительного анализа направлений (по блокам).
4.3.1. Проведение предварительного анализа направлений (по блокам) осуществляют участники группы проекта по направлению после получения от руководителя группы проекта комплекта документов для анализа.
4.3.2. Участники группы проекта по направлению под руководством руководителя группы осуществляют проведение предварительного анализа направлений (по блокам) при помощи анализа себестоимости, а именно:
а) ранжируют статьи затрат (по степени важности, доле в общем объеме себестоимости);
б) анализируют динамику изменения статей затрат за равные периоды времени (2–3 года);
в) готовят отчеты по результатам анализа.
4.3.3. Результатом выполнения данных работ являются отчеты о результатах предварительного анализа, сформированные каждым специалистом группы проекта.
4.3.4. Отчеты о результатах предварительного анализа направлений специалисты группы проекта передают руководителю проекта через руководителя группы проекта не позднее 5 дней с момента получения комплекта документов.
4.4. Объединение результатов анализа с расстановкой приоритетов.
4.4.1. Объединение результатов анализа с расстановкой приоритетов осуществляет руководитель проекта после получения отчетов о результатах предварительного анализа направлений от руководителя группы проекта.
4.4.2. Для объединения результатов анализа с расстановкой приоритетов руководитель проекта выполняет следующие действия:
а) проверяет наличие отчетов от всех групп проекта, участвовавших в проведении предварительного анализа направлений по блокам;
б) оценивает отчеты на полноту и адекватность проведенному анализу и корректирует анализируемый материал;
в) делает сравнительный анализ однотипных данных из всех отчетов;
г) вносит изменения в список направлений проекта по снижению издержек компании, ранжируя этот перечень по степени важности решения существующих проблем;
д) Дает устное распоряжение секретарю проекта подготовить проект уточненного перечня направлений.
4.4.3. Результатом выполнения данных работ руководителем проекта являются:
а) откорректированные результаты предварительного анализа направлений;
б) ранжированный по степени важности список направлений проекта по снижению издержек компании;
в) устное распоряжение секретарю проекта подготовить проект уточненного перечня направлений.
4.4.4.Откорректированные результаты анализа и ранжированный список направлений руководитель проекта передает секретарю проекта для разработки проекта уточненного перечня направлений проекта по СИ.
4.5. Разработка проекта уточненного перечня направлений.
4.5.1. Разработку проекта уточненного перечня направлений осуществляет секретарь проекта после получения от руководителя проекта:
а) откорректированных результатов предварительного анализа направлений;
б) ранжированного списка направлений проекта по степени важности снижения издержек.
4.5.2. В процессе разработки проекта уточненного перечня направлений секретарь проекта выполняет следующие действия:
а) оформляет полученный от руководителя проекта ранжированный список направлений проекта;
б) согласует проект уточненного перечня направлений с руководителем проекта;
в) передает проект документа инициатору работ на утверждение.
4.5.3. Результатом выполнения данных работ является проект уточненного перечня направлений.
4.5.4. Секретарь проекта передает инициатору работ проект уточненного перечня направлений на утверждение и результаты предварительного анализа направлений в течение 4 часов после получения от руководителя проекта соответствующего распоряжения.
4.6. Корректировка и утверждение перечня направлений.
4.6.1. Корректировку и утверждение перечня направлений осуществляет инициатор работ после получения результатов предварительного анализа направлений и проекта уточненного перечня направлений от секретаря проекта.
4.6.2. В ходе утверждения инициатор работ знакомится с результатами анализа, проектом перечня и, при согласованности своего мнения относительно необходимости дальнейшего анализа предлагаемых направлений, визирует перечень.
4.6.3. Результатом выполнения данных работ инициатором проекта является утвержденный уточненный перечень основных направлений проекта.
4.6.4. Уточненный перечень основных направлений проекта инициатор проекта передает руководителям групп проекта для дальнейшей работы по проекту снижения издержек компании в течение 2 рабочих дней с момента его получения.
5. Проведение детального анализа направлений СИ
5.1. Общая характеристика процесса.
5.1.1. Процесс состоит из следующих последовательно выполняемых процедур:
а) сбор дополнительной информации о направлениях (поблочно);
б) проведение детального анализа блоков направлений;
в) сведение результатов и оценка экономических эффектов от мероприятий;
г) формирование вариативной программы мероприятий;
д) формирование отчета о результатах анализа.
5.1.2. Модель процесса представлена в приложении 2 Node: А4.
5.1.3. Условием начала работ по данному процессу является наличие уточненного перечня основных направлений проекта у руководителя группы проекта.
5.1.4. Условием окончания работ по процессу является формирование и передача руководителем проекта секретарю проекта вариативной программы мероприятий и отчета о результатах анализа.
5.1.5. Действия, описываемые в рамках данного процесса, не распространяются на все процессы организации. Последовательность и правила выполнения работ, приведенные в настоящем разделе, регламентируют реализацию проектов компании по снижению издержек.
5.2. Сбор дополнительной информации о направлениях (поблочно).
5.2.1. Сбор дополнительной информации о направлениях (поблочно) организует руководитель группы проекта после получения от инициатора проекта уточненного перечня основных направлений проекта.
5.2.2. В ходе выполнения данной работы руководитель группы проекта выполняет следующей действия:
а) формирует перечень информации и документов, необходимых для детального анализа мероприятий по снижению издержек в рамках определенного блока направлений;
б) определяет должностных лиц компании, которые могут предоставить данную информацию;
в) формирует в письменной форме ряд запросов на информацию, необходимую для проведения анализа, и направляет запросы соответствующим должностным лицам компании. В запросе обязательно должны быть указаны формат и сроки предоставления требуемой информации;
г) после наступления указанных в запросах сроков получает необходимую для анализа информацию и проверяет ее на полноту и адекватность запросу;
д) сообщает группе проекта по направлению о поступлении необходимой для анализа информации.
5.2.3. Результатом выполнения данных работ является информация, необходимая для детального анализа мероприятий по определенному блоку направлений.
5.2.4. Полученная дополнительная информация передается сотрудникам группы проекта по направлению непосредственно после анализа этой информации руководителем группы проекта, но не позднее 2 рабочих дней с момента ее получения руководителем.
5.2.5. Если запрошенная дополнительная информация не поступает в указанный в запросе срок либо является не соответствующей запросу, руководитель группы проекта выясняет причины данной ситуации и докладывает руководителю проекта.
5.3. Проведение детального анализа блоков направлений.
5.3.1. Проведение детального анализа блоков направлений производят сотрудники группы проекта по направлению после получения информации для анализа от руководителя группы проекта.
5.3.2. В ходе выполнения детального анализа сотрудники группы проекта выполняют ряд действий, направленных на формирование предложений по мероприятиям, направленным на снижение издержек по рассматриваемому направлению:
а) анализируют информацию, переданную им, для выявления существующих или потенциальных проблем, влияющих на издержки компании по определенному направлению;
б) формируют ряд предложений по мероприятиям, направленным на устранение проблем и соответственно на снижение издержек. Выбор методов, с помощью которых разрабатываются предложения по мероприятия, не регламентируется;
в) Производят предварительную оценку экономии затрат компании от реализации мероприятий, а также затрат на реализацию каждого из мероприятий.
5.3.3. Итогом выполнения данных работ являются результаты анализа, представляющие собой перечень предложений по мероприятиям, направленным на снижение издержек по определенному блоку направлений.
5.3.4. Результат выполнения данных работ передается сотрудниками группы проекта по направлению руководителю группы проекта непосредственно после завершения детального анализа, но не позднее срока, указанного в плане проекта.
5.4. Сведение результатов и оценка экономических эффектов от мероприятий.
5.4.1. Сведение результатов и оценку экономических эффектов мероприятий производит руководитель группы проекта после получения от сотрудников группы проекта по направлению результатов анализа.
5.4.2. В ходе выполнения данной процедуры руководитель группы проекта по направлению выполняет следующие действия:
а) определяет методы оценки экономического эффекта для мероприятий;
б) организует выполнение оценки экономического эффекта каждого из мероприятий, для чего привлекает соответствующих специалистов компании или привлеченных консультантов;
в) ранжирует мероприятия по экономическому эффекту;
г) формирует сводный документ в виде перечня мероприятий и пояснительной записки к нему.
5.4.3. Результатом проведения данных работ является перечень мероприятий, направленных на снижение затрат компании по определенному блоку направлений.
5.4.4. Руководитель группы проекта передает подготовленный перечень мероприятий (в установленном формате) секретарю проекта не позднее срока, указанного в плане проекта.
5.5. Формирование вариативной программы мероприятий.
5.5.1. Формирование вариативной программы мероприятий выполняет секретарь проекта после получения перечня мероприятий от руководителей групп проекта по направлениям.
5.5.2. В ходе выполнения данной процедуры секретарь проекта выполняет следующие действия:
a) сводит в единый документ все перечни мероприятий, переданные руководителями групп проекта по направлениям;
б) группирует мероприятия в вариативной программе по направлениям, а также по признаку объема затрат на их реализацию (беззатратные, малозатратные и высокозатратные).
5.5.3. Результатом данной работы является подготовленная вариативная программа мероприятий, направленная на снижение издержек.
5.5.4. Секретарь проекта направляет вариативную программу мероприятий руководителю проекта для дальнейшего рассмотрения. Срок формирования и передачи вариативной программы мероприятий составляет не более 2 рабочих дней.
5.6. Формирование отчета о результатах анализа.
5.6.1. Формирование отчета о результатах производит руководитель проекта после получения от секретаря проекта вариативной программы мероприятий.
5.6.2. Итогом выполнения данных работ является отчет о результатах анализа, который содержит в себе перечень проблемных зон и оценку экономической эффективности мероприятий по снижению затрат в данных проблемных зонах.
5.6.3. Отчет о результатах анализа руководитель проекта передает секретарю проекта для распространения среди членов оценочной комиссии не позднее срока, указанного в плане проекта.
6. Формирование программы мероприятий
6.1. Общая характеристика процесса
6.1.1. Процесс состоит из следующих последовательно выполняемых процедур:
а) ознакомление оценочной комиссии с результатами анализа;
б) проведение оценочной сессии;
в) формирование проекта программы мероприятий;
г) согласование проекта программы мероприятий;
д) утверждение программы мероприятий.
6.1.2. Модель процесса представлена в приложении 2 Node: А5.
6.1.3. Условием начала работ по процессу является поступление секретарю проекта вариативной программы мероприятий и отчета о результатах анализа от руководителя проекта.
6.1.4. Условием окончания работ по процессу является утверждение инициатором работ программы мероприятий по снижению издержек.
6.1.5. Действия, описываемые в рамках данного процесса, не распространяются на все процессы организации. Последовательность и правила выполнения работ, приведенные в настоящем разделе, регламентируют реализацию проектов компании по снижению издержек.
6.2. Ознакомление оценочной комиссии с результатами анализа.
6.2.1. Ознакомление оценочной комиссии с результатами анализа организует секретарь проекта после получения отчета о результатах анализа и вариативной программы мероприятий от руководителя проекта.
6.2.2. В ходе выполнения данной процедуры секретарь проекта выполняет следующие действия:
а) готовит копии отчета о результатах анализа и вариативной программы мероприятий для распространения;
б) распространяет копии указанных документов среди членов оценочной комиссии;
в) по истечении времени на ознакомление с документами (не более 3 рабочих дней) организует подписание членами оценочной комиссии ознакомительного листа;
6.2.3. Результатом данных работ является подписанный всеми членами оценочной комиссии лист ознакомления с результатами анализа.
6.2.4. Лист ознакомления с результатами анализа отправляется секретарем проекта на хранение в архив проекта после того, как все подписи членов оценочной комиссии получены.
6.2.5. Если в ходе распространения результатов анализа и получения подписей в листе ознакомления выяснится, что кто-либо из членов оценочной комиссии в силу каких-либо причин (например, командировка, заболевание и т. п.) не может ознакомиться с результатами анализа в установленный срок, то секретарь проекта сообщает о данном факте руководителю проекта.
6.3. Проведение оценочной сессии.
6.3.1. Проведение оценочной сессии мероприятий производит оценочная комиссия после того, как все члены оценочной комиссии ознакомились с результатами анализа, что подтверждается их подписями в листе ознакомления. При этом дата начала оценочной сессии и ее продолжительность определяются планом проекта.
6.3.2. В ходе проведения оценочной сессии при оценке мероприятий члены комиссии руководствуются следующими принципами:
а) экономическая целесообразность реализации мероприятий;
б) адекватность использования заявленных в мероприятиях ресурсов компании;
в) вероятность достижения заявленного экономического эффекта от мероприятий.
6.3.3. Результатом данных работ является рекомендации по формированию программы мероприятий по снижению издержек.
6.3.4. Выработанные рекомендации члены оценочной комиссии передают секретарю проекта непосредственно после окончания оценочной сессии для формирования проекта программы мероприятий по снижению издержек.
6.3.5. Если в ходе проведения оценочной сессии у членов оценочной комиссии возникнут разногласия по каким-либо мероприятиям, то комиссия должна прийти к одному из вариантов путем голосования (по принципу большинства голосов).
6.4. Формирование проекта программы мероприятий.
6.4.1. Формирование проекта программы мероприятий производит секретарь проекта после получения от оценочной комиссии рекомендаций по формированию программы мероприятий по снижению издержек.
6.4.2. В ходе выполнения данной процедуры секретарь проекта формирует проект программы мероприятий по снижению издержек. Данный документ формируется из одобренных оценочной комиссией мероприятий вариативной программы.
6.4.3. Результатом данных работ является проект программы мероприятий по снижению издержек компании.
6.4.4. Проект программы мероприятий секретарь проекта передает руководителю проекта для согласования непосредственно после ее формирования. Срок формирования проекта программы мероприятий составляет не более 2 рабочих дней.
6.5. Согласование проекта программы мероприятий.
6.5.1. Согласование проекта программы мероприятий производит руководитель проекта после получения от секретаря проекта данного документа.
6.5.2. В ходе согласования документа руководитель проекта выполняет следующие действия:
а) рассматривает документ на предмет правильности оформления и содержания;
б) рассматривает документ на предмет полноты и адекватности отраженных в нем мероприятий;
в) визирует документ.
6.5.3. Результатом выполнения данных работ является проект программы мероприятий, завизированный руководителем проекта.
6.5.4.Завизированный проект программы мероприятий руководитель проекта передает инициатору работ для утверждения. Срок согласования проекта программы документа составляет не более 2 рабочих дней.
6.5.5. Если в результате рассмотрения проекта программы мероприятий руководитель проекта обнаружит его неполноту или неадекватность целям и задачам проекта, то он инициирует процесс внесения в проект документа исправлений и дополнений.
6.6. Утверждение программы мероприятий.
6.6.1. Утверждение программы мероприятий производит инициатор работ после получения от руководителя проекта данного документа.
6.6.2. В ходе утверждения документа инициатор работ рассматривает документ с точки зрения бюджета и экономического эффекта мероприятий и визирует документ.
6.6.3. Результатом данных работ является программа мероприятий по снижению издержек, завизированная инициатором проекта.
6.6.4. Утвержденную программу мероприятий инициатор проекта хранит у себя для дальнейшего использования при назначении ответственных за исполнение мероприятий. Утверждение документа должно быть произведено не позднее 2 рабочих дней после получения завизированного проекта программы мероприятий.
7. Планирование реализации мероприятий
7.1. Общая характеристика процесса.
7.1.1. Процесс состоит из следующих последовательно выполняемых процедур:
а) назначение исполнителей мероприятия;
б) формирование перечня работ для выполнения мероприятия;
в) определение сроков выполнения мероприятия и контрольных точек;
г) проведение совещания по согласованию плана;
д) утверждение плана реализации мероприятий.
7.1.2. Модель процесса представлена в приложении 2 Node: А6.
7.1.3. Условием начала работ по процессу является утвержденная инициатором работ программа мероприятий по СИ.
7.1.4. Условием окончания работ по процессу является утвержденный инициатором работ план реализации мероприятий, переданный руководителю группы проекта.
7.1.5. Действия, описываемые в рамках данного процесса, не распространяются на все процессы организации. Последовательность и правила выполнения работ, приведенные в настоящем разделе, регламентируют реализацию проектов компании по снижению издержек.
7.2. Назначение исполнителей мероприятия.
7.2.1. Назначение исполнителей мероприятия производит инициатор работ после утверждения программы мероприятий по снижению издержек.
7.2.2. Ответственными исполнителями мероприятий являются руководители групп проекта по направлениям снижения издержек (как правило), либо должностные лица компании не ниже руководителя структурного подразделения (отдел, производственная единица).
7.2.3. Результатом выполнения данных работ является распоряжение о назначении исполнителей работ, являющееся условием для начала формирования перечня конкретных работ по реализации мероприятия каждым руководителем группы проекта.
7.2.4. Назначение исполнителей мероприятия производит инициатор работ в трехдневный срок после утверждения программы мероприятий по снижению издержек.
7.3. Формирование перечня работ для выполнения мероприятия.
7.3.1. Формирование перечня работ для выполнения мероприятия производит руководитель группы проекта после ввода в действие распоряжения о назначении исполнителей работ по процессу снижения издержек компании и получения Программы мероприятий.
7.3.2. Результатом выполнения данных работ является сформированный перечень работ для выполнения мероприятия, составленный руководителем группы проекта на основе программы мероприятий.
7.3.3. Руководитель группы проекта передает перечень работ для выполнения мероприятия руководителю проекта.
7.3.4. Формирование перечня работ для выполнения мероприятия производит руководитель группы проекта в течение 3 дней с момента вступления распоряжения о назначении исполнителей работ по процессу снижения издержек компании в силу.
7.4. Определение сроков выполнения мероприятия и контрольных точек.
7.4.1. Определение сроков выполнения мероприятия и контрольных точек производит руководитель проекта после получения от руководителя группы проекта перечня работ для выполнения мероприятия.
7.4.2. Результатом проведения данных работ является расписание выполнения работ, включающее в себя информацию о работах, сроках их выполнения и контрольных точках, в которых руководитель проекта может определить процент выполнения плановых работ к отчетной дате.
7.4.3. Руководитель проекта передает расписание выполнения работ представителям руководящего состава проекта.
7.4.4. Определение сроков выполнения мероприятия и контрольных точек производит руководитель проекта в течение 2 дней после получения от руководителя группы проекта перечня работ для выполнения мероприятия.
7.5. Проведение совещания по определению рисков и согласованию плана.
7.5.1. Проведение совещания по определению рисков и согласованию плана реализации мероприятий организует инициатор работ после получения расписания выполнения работ от руководителя проекта.
7.5.2. В совещании участвует руководящий состав проекта, в который входят:
а) руководитель проекта;
б) руководители групп проекта;
в) секретарь проекта.
7.5.3. Руководящий состав проекта при согласовании плана реализации мероприятий вырабатывает следующие направления управления рисками:
а) планирование управления рисками, т. е. определяет подходы и планирует действия по управлению рисками проекта и мероприятия;
б) идентификация рисков, т. е. определяет риски, способные повлиять на проект, и документирует их характеристики;
в) качественный анализ рисков, т. е. проводит качественный анализ рисков и условий для определения их приоритетов по влиянию на цели проекта;
г) количественный анализ рисков, т. е. оценивает вероятность и последствия наступления рисковых событий и их влияния на цели проекта;
д) планирование реагирования на риски, т. е. разрабатывает процедуры и методики по снижению угроз для целей проекта;
е) мониторинг и управление рисками, т. е. мониторинг оставшихся рисков, идентификация новых рисков, исполнение планов по снижению рисков и оценка их эффективности на протяжении жизненного цикла проекта;
ж) внесение соответствующих изменений в проект плана реализации мероприятий;
з) согласование плана реализации мероприятий.
7.5.4. Результатом проведения данных работ является согласованный руководящим составом проекта документ «План реализации мероприятий», включающий в себя перечень работ, сроки их выполнения, ресурсы и требования к конечному результату.
7.5.5. Руководящий состав проекта передает согласованный план реализации мероприятия на утверждение инициатору работ.
7.6. Утверждение плана реализации мероприятий.
7.6.1. Утверждение плана реализации мероприятий производит инициатор работ после получения от руководящего состава проекта согласованный документ «План реализации мероприятий».
7.6.2. Утверждение плана реализации мероприятий инициатор работ производит, проверяя документ на соответствие следующим условиям:
а) ответственное лицо по каждой работе – непосредственный исполнитель;
б) срок выполнения каждой работы – от 2 до 5 дней;
в) у каждой работы должен быть результат;
г) результат выполнения работ – измеряемый и документируемый;
д) контрольные точки должны находиться на ключевых этапах выполнения работ.
7.6.3. Результатом данной работы является утвержденный руководителем проекта документ «План реализации мероприятий».
7.6.4. Инициатор работ передает руководителю группы проекта план реализации мероприятий для организации и контроля реализации утвержденных мероприятий.
7.6.5. Если в результате проверки проекта документа «План реализации мероприятий» инициатор работ сочтет его несоответствующим условиям его утверждения (см. п. 8.6.2), он имеет право передать документ на доработку руководящему составу проекта для исправления выявленных недочетов.
8. Организация и контроль реализации
8.1. Общая характеристика процесса.
8.1.1. Процесс состоит из следующих последовательно выполняемых процедур:
а) проведение установочного рабочего совещания;
б) реализация мероприятия;
в) проведение внеплановых проверок реализации мероприятий;
г) проверка соблюдения сроков и качества выполнения работ;
д) разработка отчетных документов по результатам выполнения работ;
е) приемка выполненных работ. Оценка результатов.
8.1.2. Модель процесса представлена в приложении 2 Node: А7.
8.1.3. Условием начала работ по процессу является переданный руководителю группы проекта утвержденный руководителем проекта документ «План реализации мероприятий» по СИ и распоряжение о назначении исполнителей работ.
8.1.4. Условием окончания работ по процессу является отчет о проделанной работе, а также выявленная в ходе выполнения работ потребность в реализации дополнительного проекта по СИ.
8.1.5. Действия, описываемые в рамках данного процесса, не распространяются на все процессы организации. Последовательность и правила выполнения работ, приведенные в на стоящем разделе, регламентируют реализацию проектов компании по снижению издержек.
8.2. Проведение установочного рабочего совещания.
8.2.1. Проведение установочного рабочего совещания организует руководитель группы проекта после получения плана реализации мероприятий и распоряжения о назначении исполнителей работ.
8.2.2. В процессе проведения установочного рабочего совещания руководитель группы проекта в соответствии с планом реализации проекта осуществляет постановку задач исполнителям работ.
8.2.3. Результатом данной работы является устное распоряжение о начале выполнения работ группой проекта по направлению в соответствии с поставленными каждому участнику группы задачами.
8.3. Реализация мероприятия.
8.3.1. Реализация мероприятия осуществляется группой проекта по направлению (в исключительных случаях под контролем группы) после:
а) получения перечня задач к исполнению от руководителя группы проекта и устного распоряжения о начале выполнения работ;
б) получения указаний по ходу реализации мероприятий от руководителя проекта или руководителя группы проекта.
8.3.2. Результатом выполнения данных работ является отметка в плане реализации мероприятий о выполнении поставленной задачи.
8.3.3. Группа проекта по направлению передает руководителю проекта план реализации мероприятий с отметкой о выполнении поставленной задачи для формирования отчетной документации по результатам выполнения работ.
8.4. Проведение внеплановых проверок реализации мероприятий.
8.4.1. Проведение внеплановых проверок реализации мероприятий осуществляет руководитель проекта, используя план реализации мероприятий. Проведение внеплановых проверок реализации мероприятий руководителем проекта обусловлено необходимостью оперативного контроля выполнения плана.
8.4.2. В ходе проведения внеплановых проверок руководитель проекта требует оперативные отчеты от специалистов группы проекта о ходе выполнения работ по плану.
8.4.3. Результатом проведения данных работ являются переданные группе проекта по направлению указания (в устной форме) по реализации проекта.
8.4.4. Руководитель проекта передает группе проекта по направлению указания по ходу реализации мероприятий с целью совершенствования процесса выполнения поставленных задач.
8.4.5. Если в результате проведения внеплановой проверки реализации мероприятий руководитель проекта обнаруживает существенные отклонения от плана (по срокам, объему, качеству и т. д.), то он может поступить следующим образом:
а) оформить ведомость проведения внеплановой проверки, в которую необходимо внести информацию о выявленной проблеме (формулировка проблемы, причина ее наступления, ФИО лица, ответственного за выполнение работы, предложения по ее устранению и сроки выполнения этих работ);
б) в случае, когда наступление проблемы связано с недостаточным знанием или пониманием сотрудником требований к нему, провести с ним разъяснительную беседу, а при необходимости обучение;
в) если проблему невозможно устранить в определенные по плану сроки или имеющимися ресурсами, согласовать с руководителем группы проекта и инициатором работ внесение изменений в план реализации мероприятий;
г) в случае, когда выявленная проблема связана с недобросовестным выполнением своих обязанностей, руководитель проекта принимает решение о мере ответственности исполнителя, итогом чего может стать отстранение исполнителя от выполнения работ по проекту.
8.5. Проверка соблюдения сроков и качества выполнения работ.
8.5.1. Проверка соблюдения сроков и качества выполнения работ осуществляется руководителем группы проекта в соответствии контрольными точками проекта, определенными в плане реализации мероприятий.
8.5.2. Результатом проведения данных работ является отметка в плане реализации мероприятий о выполнении поставленной задачи и указания исполнителям по ходу реализации мероприятий.
8.5.3. Руководитель группы проекта передает:
а) руководителю проекта план реализации мероприятий с отметкой о выполнении поставленной задачи для формирования отчетной документации по результатам выполнения работ;
б) группе проекта по направлению СИ указания по ходу реализации мероприятий с целью совершенствования процесса выполнения поставленных задач.
8.5.4. Если в результате проверки выяснится, что сроки выполнения работ или их качество не соответствуют показателям, определенным в плане реализации проекта, руководитель группы проекта должен поставить об этом в известность руководителя проекта для совместной выработки способа выхода из проблемной ситуации.
8.6. Разработка отчетных документов по результатам выполнения работ.
8.6.1. Разработка отчетных документов по результатам выполнения работ осуществляется руководителем проекта после получения плана реализации мероприятий с отметками о ходе выполнения поставленных задач.
8.6.2. К разрабатываемой на данном этапе документации относятся следующие отчетные документы:
а) документы проекта – переписка, докладные записки и описывающие проект документы. Эта информация должна содержаться, насколько это возможно и уместно, в систематизированном виде;
б) отчеты по проекту – формальные отчеты о состоянии проекта;
в) презентации проекта – команда проекта формально или неформально обеспечивает информацией любого или всех участников проекта. Информация должна соответствовать потребностям получателей и должна избирать подходящий метод презентации;
г) проект отчета о проделанной работе.
8.6.3. Результатом данной работы является сформированная отчетная документация по результатам выполнения работ.
8.6.4. Руководитель проекта передает инициатору работ отчетную документацию для последующей оценки результатов деятельности по проекту снижения издержек компании.
8.7. Приемка выполненных работ. Оценка результатов.
8.7.1. Приемку выполненных работ и оценку результатов деятельности по проекту снижения издержек компании осуществляет инициатор работ после получения от руководителя проекта отчетной документации по итогам выполнения работ.
8.7.2. Для приемки выполненных работ и оценки результатов инициатор выполняет следующие действия:
а) проверяет наличие всего перечня отчетной документации (см. п. 8.6.2);
б) производит сбор проектных материалов, подтверждение их соответствия окончательным спецификациям;
в) проводит анализ полноты и завершенности мероприятий (проверяет на соответствие план работ с итоговыми результатами);
г) осуществляет архивирование этой информации для последующего использования;
д) вырабатывает предложения и рекомендации по закреплению достигнутых показателей и последующей их доработки с целью повышения экономической эффективности от проведенных работ;
е) дополняет и утверждает отчет о проделанной работе.
8.7.3. Результатом данных работ является отчет о проделанной работе, включающий в себя перечень выполненных работ с оценкой результата их выполнения, а также выводы и рекомендации по итогам выполнения проекта.
8.7.4. Инициатор работ передает отчет о проделанной работе по снижению издержек руководителю компании/заказчику проекта.
8.7.5. Если в результате выполнения мероприятий будет выявлена потребность в реализации дополнительного проекта по снижению издержек, то инициатор проекта должен поставить в известность руководство компании о том, что необходимо организовать осуществление соответствующего проекта.
9. Контроль и ответственность
9.1. Контроль выполнения процедур.
9.1.1. Процедуры, требования к которым приведены в данной инструкции, являются обязательными для всех лиц, перечисленных в пункте 1.2.6.
9.1.2. Контроль соблюдения регламента осуществляет инициатор работ. При обнаружении нарушений в соблюдении требований инструкции инициатор работ проводит детальный анализ ситуации, в результате которого может принять следующие решения:
а) в случае, когда нарушение связано с недостаточным знанием или пониманием сотрудником требований к нему, проводит с ним разъяснительную беседу, а при необходимости – обучение;
б) в случае, когда нарушение связано с недобросовестным выполнением своих обязанностей, инициатор работ определяет меру воздействия на исполнителя и издает соответствующее распоряжение;
в) в случае, когда нарушение является систематическим и является следствием изменения условий выполнения работ, готовит предложения об изменении настоящей инструкции, которые оформляет в виде распоряжения.
9.2. Ответственность должностных лиц за соблюдение данной инструкции.
9.2.1. Все сотрудники и руководители, участвующие в выполнении работ несут дисциплинарную ответственность за соблюдение требований, приведенных в данной инструкции.
9.2.2. Наложение дисциплинарных взысканий за некачественное, несвоевременное или недобросовестное выполнение своих обязанностей проводится на основании приказа инициатора работ.
Приложение 1
Приложение 2
