Пример регламента процесса, который работает. Данная статья — пример продуманного и эффективного регламента, который вы можете использовать в качестве образца. Именно такие регламенты, с учетом пожеланий клиента, становятся результатом нашей работы по описанию и регламентации бизнес-процессов.
Вместо предисловия: каким должен быть хороший пример регламента процесса
По нашему мнению, хороший пример должен обладать следующими свойствами:
- Он должен представлять собой документ, который уже реально где-то работает. Проще говоря — пример должен поступать из практики, которая уже доказала свою эффективность.
- Он должен охватывать и описывать большинство востребованных составляющих. Иными словами — в примере вы должны увидеть 80% описания того, с чем столкнетесь при самостоятельной разработке.
- Пример должен представлять информацию, которую способно понять большинство. Если пример регламента процесса будет рассказывать о ядерном синтезе, это будет малопонятно для широкой аудитории.
Следуя этим принципам, мы подготовили для вас отличный пример регламента процесса. Безусловно, документ «вычищен», таким образом, чтобы нельзя было идентифицировать компанию, для которой он был разработан. Также, в данном примере, указана не вся информация из реального документа. Впрочем, мы позаботились о том, чтобы это не повлияло на возникновение смысловых потерь. В процессе прочтения вы можете заметить определенные недостатки, связанные с недостатками самого процесса. Мы решили не убирать их. Регламент описывает реальный процесс, до оптимизации. А в реальных процессах всегда есть множество недостатков.
В отдельных местах мы даем свои комментарии, которые в настоящем документе не указываются. Такие комментарии выделены курсивом.
Настоятельно рекомендуем держать под рукой инструкцию по подготовке регламента, которую мы публиковали ранее. Не будет лишним и освежить в памяти информацию о том, что такое эффективный регламент процесса.
Представленный пример регламента процесса ориентирован на печатную версию документа. Несмотря на то, что мы предпочитаем документы, адаптированные для электронного использования, формат обычного, печатного документа, пока что еще очень популярен.
Управление проектами по реализации заказов
Регламент бизнес-процесса
Данный регламент описывает границы, выполнение и управление бизнес-процессом Управление проектами по реализации заказов. Выполнение процесса обязательно в соответствии с данным регламентом. Регламент должны знать и использовать следующие структурные организационные единицы:
- Операционный департамент
- Департамент логистики и закупок
- Департамент эксплуатации
- Отдел сертификации
- Конструкторский отдел
Ответственным, за содержание регламента и обеспечение его выполнения, является Директор по проектам. Актуальная версия регламент 1.0 от 24.08.2017
Оглавление
1. Краткое описание процесса
2. Границы процесса
2.1 События начала
2.2 Входы
2.3 Продукты
2.4 События окончания
3. Выполнение процесса
3.1 Диаграммы модели бизнес-процесса
3.1.1 Управление проектами по реализации заказов
3.1.2.1 Заказ РКД
3.2 Процедуры, бизнес-правила, скрипты
3.3 Время выполнения операций
3.4 Участники процесса
3.5 Ресурсы и инфраструктура
3.5.1 Перечень ресурсов
3.5.2 Матрица использования ресурсов
3.6 Документы процесса
4. Управление процессом
4.1 Матрица ответственности управления процессом
4.2 Осуществление управления
4.2.1 Общие положения
4.2.2 Внесение изменений в процесс
4.3 Ключевые требования к процессу
4.4 Ключевые показатели эффективности
5. Приложения
5.1 Связанные документы и нормативные ссылки
5.2 Ревизия процесса
5.3 Перечень изменений
5.4 Словарь терминов и сокращений
5.5 Условные обозначения
6. Доступ к регламенту
1. Краткое описание процесса
Бизнес-процесс Управление проектами по реализации заказов, является одним из основных процессов компании. Процесс предназначен для обеспечения выполнения заказов клиентов, в соответствии с контрактом. Обеспечение выполнения условий контракта — основная и единственная цель данного процесса. Для выполнения данной цели, механизм реализации процесса направлен на координацию действий разных подразделений и процессов компании.
Название процесса | Управление проектами по реализации заказов | |
№ процесса | О2 | |
Тип процесса | Основной | |
Владелец процесса | ФИО | Иванов Иван Иванович |
Должность | Директор по проектам | |
Структурное подразделение | Операционный департамент | |
Контакты | -//- | |
Основное событие начала | Подписан Акт приема-передачи договора | |
Основной вход процесса | Пакет документации проекта | |
Основной поставщик процесса | БП «Передача контракта менеджеру проекта» | |
Основное событие окончания | Проект закрыт | |
Основной продукт процесса | Реализованные работы по проекту | |
Основной клиент процесса | Внешний заказчик |
2. Границы процесса
2.1 События начала
События начала инициируют выполнение процесса.
Событие | Уведомление о событии | Инициатор события | Связанный вход |
Подписан Акт приема-передачи договора | По электронной почте | БП «Передача контракта менеджеру проекта» | Пакет документации проекта |
2.2 Входы
Все входы процесса представлены в виде пакета документов, который необходим для начала и выполнения процесса. Пакет документов состоит из:
- Договор — договор на реализацию проекта, заключенный между компанией Х и Заказчиком.
- Спецификация — приложение к Договору, в котором указан перечень поставляемого оборудования, перечень выполняемых работ, а также, установленные сроки ключевых этапов проекта.
- Описание особых условий — приложение к Договору, в котором указаны условия, выходящие за рамки спецификации. К таким условиям могут относиться особые условия доставки и хранения оборудования, выполнения монтажных, пуско-наладочных работ, ходовых испытаний и прочее.
- Бюджет — утвержденный, с Заказчиком, бюджет проекта. Бюджет также является приложением к Договору.
- Политическая карта проекта — отдельный документ, раскрывающий особенности заинтересованных сторон проекта.
- Список рисков по договору — перечень рисков, финансовая оценка, в случае наступления, а также описание порядка работы с риском, в том числе, распределение ответственности в случае наступления риска. Не является приложением к Договору, однако является результатом процесса Контрактация.
- Акт приема-передачи проекта — акт, который подписывает специалист по продажам и менеджер проекта. Акт содержит перечень документов, который передает специалист по продажам, а менеджер проекта принимает. Акт является результатом процесса Передача контракта менеджеру проекта.
- Календарный план проекта — внутренний календарный план проекта, разработанный на основании сроков ключевых этапов проекта, согласно Спецификации, а также оценки этапов проекта, его участниками.
- Список контактов заказчика — перечень представителей заказчика, с которыми будет осуществляться взаимодействия в проекте и контактных данных.
Описание поставки входов в процесс
Вход процесса | Поставщик | Тип поставщика | Способ поставки | Ответственный за поставку |
Договор | Передача контракта менеджеру проекта | Внутренний бизнес-процесс | Папка проекта на сетевом ресурсе | Менеджер по продажам |
Спецификация | Передача контракта менеджеру проекта | Внутренний бизнес-процесс | Папка проекта на сетевом ресурсе | Менеджер по продажам |
Описание особых условий | Передача контракта менеджеру проекта | Внутренний бизнес-процесс | Папка проекта на сетевом ресурсе | Менеджер по продажам |
Бюджет | Передача контракта менеджеру проекта | Внутренний бизнес-процесс | Папка проекта на сетевом ресурсе | Менеджер по продажам |
Политическая карта проекта | Передача контракта менеджеру проекта | Внутренний бизнес-процесс | Папка проекта на сетевом ресурсе | Менеджер по продажам |
Список рисков по договору | Передача контракта менеджеру проекта | Внутренний бизнес-процесс | Папка проекта на сетевом ресурсе | Менеджер по продажам |
Акт приема-передачи проекта | Передача контракта менеджеру проекта | Внутренний бизнес-процесс | Папка проекта на сетевом ресурсе | Менеджер по продажам |
Контактные данные заказчика | Передача контракта менеджеру проекта | Внутренний бизнес-процесс | Папка проекта на сетевом ресурсе | Менеджер по продажам |
Календарный план проекта | Передача контракта менеджеру проекта | Внутренний бизнес-процесс | Папка проекта на сетевом ресурсе | Менеджер по продажам |
2.3 Продукты
Продукты процесса представлены 3 типами: оборудование, выполненные работы и документы.
Оборудование — весь перечень оборудования и комплектующих, который должен быть поставлен, в соответствии с Договором. Продукты процесса данного типа:
- Поставленное оборудование — оборудование, предназначение для поставки заказчику, по контракту. Перечень и спецификация оборудования должны соответствовать спецификации контракта. Основной продукт процесса.
Выполненные работы — комплекс монтажных и пуско-наладочных работ, в соответствии с Договором. Продукты процесса данного типа:
- Выполненные монтажные работы — реализованные работы по монтажу оборудования, согласно контракта. Сроки и бюджет выполнения монтажных работ обязан соответствовать план графику и бюджету проекта. Основной продукт процесса.
- Выполненные пуско-наладочные работы — реализованные работы по пуско-наладке оборудования, согласно контракта. Сроки и бюджет выполнения пуско-наладочных работ обязан соответствовать план графику и бюджету проекта. Основной продукт процесса.
Документы — все документы, которые используются в других процессах, а также являются обязательными, с точки зрения выполнения договорных условий. Продукты данного типа:
- РКД — рабочая конструкторская документация поставляемого оборудования, согласно спецификации контракта. РКД должна быть заверена конструкторским отделом компании и одобрена со стороны заказчика. Основной продукт процесса.
- ЭД — эксплуатационная документация поставляемого оборудования, согласно спецификации контракта. ЭД должна быть заверена отделом эксплуатации и одобрена со стороны заказчика. Основной продукт процесса.
- Методики испытаний — описание методик испытаний поставляемого оборудования, в соответствии со спецификацией контракта. Методики испытаний должны быть подготовлены в соответствии с формами и требованиями морского и речного регистра. Основной продукт процесса.
- СТО — сертификаты типового одобрения для поставляемого оборудования, в соответствии со спецификацией контракта. СТО должны быть заверены морским и речным регистром. Основной продукт процесса.
- СИО — сертификаты индивидуального одобрения для поставляемого оборудования, в соответствии со спецификацией контракта. СИО должны быть заверены морским и речным регистром. Основной продукт процесса.
- Пультовые схемы — конструкторские схемы пульта судовождения. Схемы обязаны получить одобрение КД судостроительного завода. Основной продукт процесса, в случае наличия пульта судовождения в спецификации контракта.
- Электромонтажные схемы пульта — схемы пульта судовождения для выполнения электромонтажных работ. Схемы обязаны получить одобрение КД судостроительного завода. Основной продукт процесса, в случае наличия пульта судовождения в спецификации контракта.
- Состав монтажного комплекта — перечень инструментов и расходных материалов для осуществления монтажа оборудования. Должен быть выполнен по установленной форме «Монтажный комплект» и утвержден отделом эксплуатации. Вторичный продукт процесса.
- Первичная документация — первичная сопроводительная документация поставки оборудования. Документация обязана соответствовать фактически поставленному оборудованию. Оригиналы документов должны содержать соответствующим печати и подписи сторон. Вторичный продукт процесса.
- Акт приема оборудования — акт, который подписывает заказчик, при приеме оборудования на своем складе. В Акте должно быть указано лицо, со стороны заказчика, осуществившее прием оборудования. Оригиналы документов должны содержать соответствующим печати и подписи сторон. Вторичный продукт процесса.
- Акт приема выполненных монтажных работ — акт, который подписывает заказчик, при приеме монтажных работ. В Акте должно быть указано лицо, со стороны заказчика, осуществившее прием оборудования. Оригиналы документов должны содержать соответствующим печати и подписи сторон. Вторичный продукт процесса.
- Акт приема выполненных пуско-наладочных работ — акт, который подписывает заказчик, при приеме пуско-наладочных работ. В Акте должно быть указано лицо, со стороны заказчика, осуществившее прием оборудования. Оригиналы документов должны содержать соответствующим печати и подписи сторон. Вторичный продукт процесса.
- Карточка проекта — описание результатов проекта, по установленной форме. Заполняется менеджером проекта и согласовывается всеми заинтересованными сторонами, при закрытии проекта. Карточка проекта должны быть подготовлена на основании установленной формы и не должна иметь незаполненных полей. Вторичный продукт процесса.
Описание передачи продуктов процесса клиентам
Продукт | Клиент | Тип клиента | Получатель | Способ передачи |
Поставленное оборудование | Заказчик | Внешний | РП со стороны заказчика | Поставка через транспортную компанию |
Выполненные монтажные работы | Заказчик | Внешний | РП со стороны заказчика | Очная встреча |
Выполненные пуско-наладочные работы | Заказчик | Внешний | РП со стороны заказчика | Очная встреча |
РКД |
|
|
|
|
ЭД |
|
|
|
|
Методики испытаний | Заказчик | Внешний | РП со стороны заказчика | Через папку на сетевом ресурсе |
СТО | Заказчик | Внешний | РП со стороны заказчика | Курьер |
СИО | Заказчик | Внешний | РП со стороны заказчика | Курьер |
Пультовые схемы |
|
|
|
|
Электромонтажные схемы пульта |
|
|
|
|
Состав монтажного комплекта | Монтаж оборудования | Внутренний процесс | Руководитель сервисного отдела | Через папку на сетевом ресурсе |
Первичная документация | Бухгалтерский учет | Внутренний процесс | Бухгалтер по первичной документации | Лично в руки |
Акт приема оборудования |
|
|
|
|
Акт выполненных работ (монтажные работы) |
|
|
|
|
Акт выполненных работ (ПНР) |
|
|
|
|
Карточка проекта | Управление проектами | Внутренний процесс | Директор по проектам | Очная встреча |
2.4 События окончания
События окончания определяют условие, при выполнении которого, процесс будет считаться завершенным.
Событие | Как становится известно о событии | Где фиксируется событие | Связанный продукт | Что инициирует событие |
Проект закрыт | Уведомление о закрытии бюджета проекта в Navision | Navision | Карточка проекта | БП «Оценка эффективности реализованного проекта» |
3. Выполнение процесса
3.1 Диаграммы модели бизнес-процесса
3.1.1 Управление проектами по реализации заказов
3.1.2.1 Заказ РКД
Данный пример регламента процесса содержит только две диаграммы. Прочие диаграммы процесса в примере не приводятся. Полная версия регламента включает в себя все диаграммы модели бизнес-процесса, а также комментарии и пояснения к диаграммам.
Примеры и иллюстрации практического использования нотации BPMN можно найти здесь.
3.2 Процедуры, бизнес-правила и скрипты
Приведенный ниже перечень правил и процедур обязателен для выполнения в процессе. Описание правил и процедур содержится в отдельных документах, доступных по указанным ссылкам.
Наименование | Тип | Актуальная версия | Дата обновления | Ссылка |
Оформление заявки на закупку оборудования | Процедура | 2.14 | 16.07.2018 | Ссылка на документ |
Оформление заявки на изготовление сертификатов | Правило | 1.0 | 01.02.2017 | Ссылка на документ |
Согласование приема оборудования на складе заказчика | Правило | 1.0 | 11.09.2014 | Ссылка на документ |
Оформление заявки на проведение монтажных работ | Процедура | 1.7 | 20.08.2019 | Ссылка на документ |
Оформление заявки на проведение пуско-наладочных работ | Процедура | 1.7 | 20.08.2019 | Ссылка на документ |
3.3 Время выполнения операций
Указанное время выполнения операций является не строго обязательным, но рекомендованным и используется для оценки эффективности процесса.
Родительский процесс | Операция |
Трудозатраты |
||
Минимум | Среднее | Максимум | ||
Заказ РКД, ЭД и методик испытаний | Сумма | 115 мин | 202 мин | 350 мин |
Заказ РКД, ЭД и методик испытаний | Подготовка и отправка заявки на отрисовку схем | 10 мин | 20 мин | 60 мин |
Заказ РКД, ЭД и методик испытаний | Внести отрисовку схем в план КО | 5 мин | 7 мин | 10 мин |
Заказ РКД, ЭД и методик испытаний | Заказать разработку РКД, ЭД и методик испытаний | 90 мин | 150 мин | 240 мин |
Заказ РКД, ЭД и методик испытаний | Проверить готовность документации | 10 мин | 25 мин | 40 мин |
… | … | … | … | … |
Данный пример регламента процесса содержит ограниченное описание времени выполнения операций. В полную версию регламента включено описание всех операций процесса.
3.4 Участники процесса
- Менеджер проектов (ПМ) — выполняет основную часть операций процесса. Роль ПМ выполняют сотрудники, занимающие одноименные должности. ПМ входят в состав Операционного департамента и напрямую подчиняются Директору по проектам. Для выполнения процесса необходим один сотрудник, выполняющий роль ПМ. В ряде случаев, ПМ может принимать роль и выполнять операции, находящиеся в зоне ответственности помощника ПМ.
- Помощник менеджера проектов — выполняет, относительно, небольшую часть операций процесса. Роль помощника ПМ выполняют сотрудники, занимающие одноименные должности. Помощник ПМ находится в прямом подчинении ПМ и входят в состав Операционного департамента. Для выполнения процесса необходим один сотрудник, выполняющий роль помощника ПМ.
Роль | Менеджер проектов | Помощник менеджера проектов | … | |
Должность | ||||
Менеджер проектов | 1 | 2 | ||
Помощник менеджера проектов | 1 | |||
… | ||||
Обозначения пересечений | ||||
1 – должности присвоена эта роль | ||||
2 – иногда эта должность выполняет эту роль | ||||
3 – эта должность может выполнять эту роль, в качестве исключения |
Данный пример регламента процесса ограничен описанием только двух участников процесса. Полная версия регламента включает в себя описание всех участников.
3.5 Ресурсы и инфраструктура
3.5.1 Перечень ресурсов
- Рабочее место сотрудника — предоставляется сотруднику компании по умолчанию. По нормативу, на процесс необходимо два рабочих места. Стоимость одного рабочего места составляет 124.000 руб. Рабочее место используется многократно, стоимость использования в процессе составляет Х руб. Относится к типу Оборудование. Единица измерения — единица.
- MS Project — предоставляется новому сотруднику по заявке в Департамент ИТ, после чего является частью рабочего места сотрудника. По нормативу, для выполнения процесса необходимо две лицензии MS Project. Стоимость одной лицензии составляет 18.000 руб. Все программное обеспечение используется многократно, стоимость использования в процессе составляет Х руб. Относится к типу Программное обеспечение. Единица измерения — лицензия.
- Navision — предоставляется новому сотруднику по заявке в Департамент ИТ, после чего является частью рабочего места сотрудника. По нормативу, для выполнения процесса необходимо две лицензии Navision. Стоимость одной лицензии составляет 16.000 руб. Все программное обеспечение используется многократно, стоимость использования в процессе составляет Х руб. Относится к типу Программное обеспечение. Единица измерения — лицензия.
- Легковой автомобиль — предоставляется по заявке в Службу обеспечения. По нормативу, на выполнение процесса необходимо два автомобиля. Стоимость одной единицы составляет 760.000 руб. Легковой автомобиль используется многократно, стоимость использования в процессе составляет Х руб. Относится к типу Транспортное средство. Единица измерения — единица.
- Комплект средств индивидуальной безопасности посетителя склада — предоставляется ответственным сотрудником, при посещении склад. Комплект средств должен быть выдан до входа на территорию склада. Каждый посетитель склада должен получить индивидуальный комплект. Стоимость одного комплекта составляет 8.000 руб. Каждый комплект используется многократно, стоимость использования в процессе составляет Х руб. Относится к типу Инструмент. Единица измерения — комплект.
- Финансовые средства для оплаты проездных билетов, проживания и питания сотрудника в командировке — выдаются сотруднику по заявке в Бухгалтерию. Расчетный норматив на процесс — 800.000 руб. Может быть изменен в соответствии с бюджетом проекта. Финансовые средства в процессе расходуются полностью, в соответствии с отчетными документами. Относится к типу Финансовые средства. Единица измерения — рубль.
3.5.2 Матрица использования ресурсов
Рабочее место сотрудника | MS Project | Navision | Легковой автомобиль | Комплект средств индивидуальной безопасности | Финансовые средства | |
Заказ РКД, ЭД и методик испытаний | 2 | 2 | 2 | -//- | -//- | -//- |
Заказ сертификатов, закупки и доставки оборудования | 2 | 2 | 2 | -//- | -//- | -//- |
Приемка на нашем складе | 2 | 2 | 2 | 1 | 2 | -//- |
Заказ доставки на склад заказчика | 2 | 2 | 2 | -//- | -//- | -//- |
Прием оборудования на складе заказчика | 2 | 2 | 2 | 2 | 2 | 300.000 |
Заказ монтажных работ | 2 | 2 | 2 | -//- | -//- | -//- |
Сборка пульта судовождения | 2 | 2 | 2 | 1 | -//- | 100.000 |
Контроль выполнения ПНР | 2 | 2 | 2 | 2 | -//- | 300.000 |
Завершение / защита проекта | 2 | 2 | 2 | -//- | -//- | 100.000 |
… | … | … | … | … | … | … |
В ячейках матрицы указаны нормативы использования ресурсов в операциях процесса |
Данный пример регламента процесса частично описывает ресурсы процесса. Полная версия регламента включает в себя описание всех ресурсов.
3.6 Документы процесса
- Форма заявки на закупку оборудования — используется для оформления заявки на закупку и дозакупку оборудования по проекту. Актуальная версия — 1.0 от 24.08.2017. Ответственный за актуализацию документа — Руководитель отдела закупок. Форма доступна по ссылке.
- Форма Акта приема оборудования — актуальная версия 1.0 от 24.08.2017. Ответственный за актуализацию документа — Директор по проектам. Форма доступна по ссылке.
- Форма Акта выполненных монтажных работ — актуальная версия 1.0 от 24.08.2017. Ответственный за актуализацию документа — Директор по проектам. Форма доступна по ссылке.
- Форма Акта выполненных пуско-наладочных работ — актуальная версия 1.0 от 24.08.2017. Ответственный за актуализацию документа — Директор по проектам. Форма доступна по ссылке.
- Форма паспорта проекта — паспорт проекта содержит в себе описание ключевых параметров проекта, целей, задач, ограничений и рисков. За подготовку паспорта проекта отвечает Менеджер проекта. Актуальная версия формы 1.0 от 24.08.2017. Ответственный за актуализацию документа — Директор по проектам. Форма доступна по ссылке.
- Форма карточки проекта — карточка проекта заполняется Менеджером проекта по итогам реализации проекта, до подведения итогов. Карточка проекта является основным документом, который используется в подпроцессе Защита проекта. Актуальная версия формы 1.0 от 24.08.2017. Ответственный за актуализацию документа — Директор по проектам. Форма доступна по ссылке.
- Порядок защиты проекта — регламентирующий документ, в котором описан порядок подготовки и осуществления защиты проекта. Актуальная версия формы 1.0 от 24.08.2017. Ответственный за актуализацию документа — Исполнительный директор. Форма доступна по ссылке.
4. Управление процессом
4.1 Матрица ответственности управления процессом
Планирование | Организация | Контроль | Анализ | Изменение | |
Менеджер проекта | Выполняет / Несет ответственность | Должен быть проинформирован / Принимает решение | Выполняет | Должен быть проинформирован | Принимает решение / Выполняет / Несет ответственность |
---|---|---|---|---|---|
Помощник менеджера проекта | Выполняет | Выполняет | |||
Типы ответственности: выполняет, несет ответственность, принимает решение, должен быть проинформирован |
4.2 Осуществление управления
4.2.1 Общие положения
Владелец Процесса несет ответственность за:
- Доведение до всего персонала важности исполнения положений нормативных документов и удовлетворения требований клиентов процесса;
- Определение целевых показателей для процесса и соответствие этих целевых показателей задачам Компании;
- Регулярный анализ хода процесса и своевременную разработку корректирующих и предупреждающих действий;
- Обеспечение всех необходимых ресурсов для выполнения работ в рамках настоящего процесса.
Владелец процесса осуществляет управление процессом, выполняя планирование, мониторинг, контроль, анализ и принятие управленческих решений.
Владелец процесса производит планирование мероприятий по улучшению процесса.
Для контроля за ходом и результатом процесса, удовлетворенностью клиентов, используется набор показателей, утвержденных в настоящем регламенте.
Владелец процесса осуществляет контроль показателей процесса, продуктов процесса путем сравнения полученных фактических значений показателей с плановыми/нормативными значениями.
Владелец процесса осуществляет мониторинг удовлетворенности клиентов процесса путем сравнения полученных фактических значений показателей со значениями показателей за предыдущий период. Если отклонения показателей выходят за допустимые границы, то Владелец процесса действует в соответствии с документированной процедурой «Корректирующие и предупреждающие действия».
4.2.2 Внесение изменений в процесс
Владелец процесса, а также любой участник или заинтересованное лицо может инициировать внесение изменений в процесс. Изменение процесса его владельцем осуществляется в рамках полномочий владельца процесса и соответствует общему порядку изменения процесса. Если изменение инициирует участник или заинтересованное лицо, он должен донести предложение об изменении владельцу процесса, в любой форме.
Порядок внесения изменений в процесс:
- Анализ данных и оценка предложения об изменении процесса.
- Первичная оценка мероприятий по изменению процесса.
- Принятие решения об изменении. Если изменение признано целесообразным, но выходит за рамки полномочий владельца процесса, он должен согласовать изменение с вышестоящим руководителем — генеральным директором.
- Разработка, планирование и организация мероприятий по изменению процесса. В том числе актуализация регламента процесса.
- Фиксация реализованных изменений в регламенте.
- Доведение изменений до участников процесса и заинтересованных сторон.
Помните — данный пример регламента процесса отражает содержание реального документа, разработанного для компании, в соответствии с ее требованиями. Ваши требования, в том числе к управлению процессом, могу существенно отличаться.
4.3 Ключевые требования к процессу
Ниже представлен перечень требований, обязательных для исполнения всеми участниками процесса.
Требование | Тип требования | Описание | Источник требования | Механизм обеспечения |
Соблюдение сроков контракта | Ход процесса | Сроки поставки оборудования клиенту, а также сроки выполнения монтажных и пуско-наладочных работы обязаны соответствовать срокам, заявленным в контракте | Директор по проектам | Контроль прохождения реперных точек проекта |
Соблюдение утвержденного бюджета | Затраты процесса | Бюджет проекта не должен превышать бюджет, согласованный при передаче контракта менеджеру проекта | Директор по проектам | Контроль освоения бюджета проекта в Navision |
… | … | … | … | … |
Данный пример регламента процесса содержит небольшое количество требований к процессу. Полная версия регламента содержит все требования, которые необходимо выполнять в процессе.
4.4 Ключевые показатели эффективности
- Длительность проекта — показатель хода процесса, отражающий время, на протяжении которого был осуществлен проект. Длительность проекта соответствует длительности одной итерации процесса. Показатель фиксируется в системе MS Project. Датой начала считается дата создания паспорта проекта, дата окончания — дата закрытия паспорта проекта в MS Project. Ответственным за актуализация данных в MS Project является Менеджер проектов, в рамках своих проектов. Мониторинг и анализ показателя осуществляется ежемесячно. Ответственным за мониторинг и анализ показателя является Директор по проектам. Анализ показателя предполагает сравнение планового и фактического значения, накопительно, на текущий месяц и выявление расхождений. В случае выявления расхождения, превышающего 10%, владелец процесса должен провести углубленный анализ для определения причин расхождения. Затем, владелец процесса, должен принять решение и организовать корректирующие действия, если это необходимо для соблюдения сроков проекта. При организации корректирующих действий, владелец процесса может задействовать любые заинтересованные стороны, в том числе осуществлять взаимодействие с заказчиком.
- Стоимость проекта — показатель хода процесса, отражающий суммарную стоимость всех расходов, связанных с реализацией проекта. Стоимость проекта соответствует стоимости одной итерации процесса. Показатель фиксируется в системе Navision, на основании данных управленческого учета. Ответственным за актуализацию данных в Navision является Менеджер проекта. Допускается отставание данных в Navision от фактических в одну неделю. Мониторинг и анализ показателя осуществляется ежемесячно. Ответственным за мониторинг и анализ показателя является Директор по проектам. Анализ показателя предполагает сравнение планового и фактического значения, накопительно, на текущий месяц и выявление расхождений. В случае выявления расхождения, превышающего 5%, владелец процесса должен провести углубленный анализ для определения причин расхождения. Затем, владелец процесса, должен принять решение и организовать корректирующие действия, если это необходимо для соблюдения сроков проекта. При организации корректирующих действий, владелец процесса может задействовать любые заинтересованные стороны, в том числе осуществлять взаимодействие с заказчиком. По договоренности с заказчиком, могут быть внесены изменения в бюджет проекта. Изменение осуществляется согласно процедуре «Изменение договорных условий»
- Соответствие поставки спецификации проекта — показатель продукта процесса, который отражает, на сколько итоговая поставка соответствует первоначальной спецификации проекта по договору. Состав первоначальной спецификации является частью первоначального бюджета, который заводится в Navision в процессе Продажи. Фактически поставленное оборудование также отражается в Navision, на основании Актов приема оборудования заказчиком. Ответственным за внесение данных по фактически поставленному оборудованию является руководитель отдела закупок. Мониторинг и анализ показателя осуществляется ежеквартально. Ответственным за мониторинг и анализ является Директор по проектам. Любое отклонение, а значит расхождение первоначальной и фактической спецификации, должно быть зафиксировано и согласованно с заказчиком. Ответственным за согласование и документальное оформление изменений является Менеджер проекта.
- Оценка проекта заказчиком — клиентский показатель, отражающий насколько заказчик удовлетворен результатом и ходом реализации проекта. Оценка осуществляется посредством анкетирования пяти участников проекта, со стороны заказчика. За получение анкет и расчета итоговой оценки отвечает Менеджер проекта. Анкеты и итоговые оценки являются приложением к карточке проекта и входят в комплект документов для защиты проекта. Расчет показателя осуществляется в подпроцессе Защита проекта.
- Оценка проекта участниками — клиентский показатель, который отражает удовлетворенность проектом внутренних клиентов, участников и заинтересованных сторон. Оценку выполняют участники проекта следующих организационных единиц: отдел закупок, отдел логистики, департамент эксплуатации, финансовый департамент, проектный отдел. Для оценки, внутренним участникам проекта рассылается анкета, которую они заполняют и направляют менеджеру проекта. Менеджер проекта несет ответственность за сбор данных и расчет итоговых оценок. Анкеты и итоговые оценки являются приложением к карточке проекта и входят в комплект документов для защиты проекта. Расчет показателя осуществляется в подпроцессе Защита проекта.
Описание расчетов и значений KPI
Показатель | Единица измерения | Формула | Стандартный диапазон |
Длительность проекта | Месяц | =дата закрытия паспорта проекта в MS Project – дата создания паспорта проекта в MS Project | 32 – 44 месяцев |
Стоимость проекта | Рубль | =сумма затрат по проекту в Navision | -//- |
Соответствие поставки спецификации проекта | % | =кол-во единиц соответствующих единицам к поставке в первоначальном бюджете / количество единиц в первоначальном бюджете | 94-100% |
Оценка проекта заказчиком | Балл | = среднее по каждому разделу анкеты, всех анкет | 85-100 |
Оценка проекта участниками | Балл | = среднее по каждому разделу анкеты, всех анкет | 80-100 |
5. Приложения
5.1 Связанные документы и нормативные ссылки
- Положение об управлении проектами. Актуальная версия 1.0 от 24.08.2017. Ссылка на документ.
- Книга знаний по управлению проектами. Актуальная версия 1.0 от 24.09.2017. Ссылка на документ.
- MS Project — инструкция для менеджера проектов. Актуальная версия 1.0 от 24.08.2017. Ссылка на документ.
- Navision — инструкция для менеджера проектов. Актуальная версия 1.0 от 24.08.2017. Ссылка на документ.
5.2 Ревизия процесса
Дата | Ревизию провел | Результат |
24.08.2018 | Иванов И.И. | Изменения не требуются. Процесс соответствует внутренним потребностям. |
… | … | … |
5.3 Перечень изменений
Дата | Изменение | Автор изменения |
24.09.2017 | В перечень связанных документов добавлена Книга знаний по управлению проектами. | Иванов И.И. |
… | … | … |
5.4 Словарь терминов и сокращений
- ПМ — менеджер проектов
- РКД — рабочая конструкторская документация
- ЭД — эксплуатационная документация
- СТО — сертификат типового одобрения
- СИО — сертификат индивидуального одобрения
- РМРС — Российский морской регистр судоходства
- РРРС — Российский речной регистр судоходства
Данный пример регламента процесса не включает в себя полный перечень терминов и сокращений.
5.5 Условные обозначения
Описание элементов нотации BPMN 2.0, в которой выполнены модели процесса, доступна по ссылке.
6. Доступ к регламенту
Для сотрудников компании, доступ к регламенту неограничен. Предоставление данного регламента третьим лицам допускается только по согласованию с генеральным директором, с обязательным оформлением соглашения о неразглашении информации. Информация, представленная в данном регламенте составляет коммерческую тайну.
Как вы считаете, это хороший пример регламента процесса? Нам также было бы интересно узнать ваше мнение о составе и структуре документа. Вы можете поделится мнением или задать вопросы в комментариях к данному посту.
Не забудьте прочитать описание того, что из себя представляет эффективный регламент процесса и инструкцию по его разработке.
Практик говорит о сложных вещах максимально простым языком. Дан пошаговый алгоритм разработки регламентов бизнес-процессов и советы по их внедрению.
Любая компания – маленькое государство со своими законами и порядками. Точнее, со своими устоями, а вот порядок как раз и приходится наводить «законами» – регламентами, инструкциями, распоряжениями и т.д.
Придя в новую компанию, сотрудник, как правило, в первый же рабочий день получает на руки кипу бумаг на изучение – регламенты по тем или иным процессам в компании. «Это Вам на ознакомление, – весело рапортует HR. – Сколько Вам нужно времени на прочтение?» Что ж, если человек пришел из крупной структурированной компании с отлаженными процессами, вопросов у него не возникает, он внимательно изучает документы. Но, к сожалению, встречаются люди, которые искренне недоумевают: «Зачем? Зачем переводить бумагу? Мир и его процессы меняются быстрее, чем вы успеете описать их! Работать можно и так».
Два лагеря, два кардинально противоположных мнения. Кто прав? Не берусь судить за все компании. Возможно, где-то есть «великие» фирмы, способные эффективно функционировать в условиях непрописанных стандартов, без четких границ и функционалов работников. Мне не довелось работать в таких организациях.
Опыт показывает: как минимум сложные и наиболее важные бизнес-процессы, в которых задействовано много людей, нужно регламентировать. Текучка кадров – это дополнительный аргумент за регламентацию. Тогда при замене специалистов будет проще обучать «новобранцев» и поддерживать бизнес-процесс в задуманном виде. Его правильная регламентация позволяет понять каждому участнику: кто, что, где, когда, зачем делает.
Алгоритм разработки
Мне не раз приходилось писать регламенты «с нуля» и корректировать существующие. В конечном итоге, проанализировав накопившийся опыт, пришла к тому, что при написании любого регламента необходимо пройти 7 шагов.
ШАГ № 1: Найти проблему
«О, да у меня куча проблем! – воскликнет практически каждый. – С какой начинать-то?» Начинать всегда с той, без решения которой невозможно дальше дышать свободно. Здесь по классике составляем список «необходимых регламентов» и определяем, где «болит сильнее», а где «еще можно подождать».
Для бизнеса любая проблема = рабочая задача.
Объясню на примере. Допутим, есть проблема – нет учета командировок сотрудников в 1С, периодически сталкиваемся с некорректным учетом потраченных в них денежных средств. Из наличия проблемы следует задача – научить менеджеров корректно оформлять командировки и отчитываться по ним.
ШАГ № 2: Определить «вход» и «выход» процесса
Наш процесс: Василий планирует…
На определенной стадии своего развития организации приходится регламентировать основные бизнес-процессы, т.е. описывать ход их выполнения в локальных нормативных актах. В таком документе, как регламент, поэтапно освещается ход процесса, над которым работают сразу в нескольких подразделениях. Вряд ли секретарю поручат разработку регламента сложного производственного процесса, а вот делопроизводственного – вполне вероятно.
В этой статье рассматривается регламент как вид документа, его структура и основные реквизиты, а также приводится пример регламента одного из важнейших процессов в ДОУ – контроля исполнения задач по документам.
РЕГЛАМЕНТ КАК ДОКУМЕНТ
Наш словарик
Регламент в коммерческой организации – это организационно-распорядительный документ, в котором пошагово описывается определенный бизнес-процесс с момента его начала до завершения.
Регламенты строго индивидуальны и могут действовать только в той организации, которая утвердила их для себя. Так, при составлении инструкции по делопроизводству обычно используют ГОСТ Р 6.30-2003 «Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов» и Методические рекомендации по внедрению ГОСТ Р 6.30-2003*. На основе этих документов создаются внутренние инструкции и в небольшом магазине, и в ОАО федерального уровня. А вот, например, порядок прохождения внутренних документов, установленный в одной организации, может совершенно не подходить для другой.
Ознакомившись с регламентом, новый сотрудник подразделения должен понять, в чем состоят его задачи, и оперативно включиться в процесс.
Обычно регламенты бизнес-процессов разрабатывают приглашенные в организацию представители консалтинговой компании. Но им не обойтись без помощи работников, которые ежедневно выполняют эти процессы.
Когда в бизнес-процесс вовлечены несколько структурных подразделений (такой процесс называется сквозным), один регламент способен заменить длительную внутреннюю переписку. Ведь работник одного отдела не может подчиняться начальнику другого, так почему же он должен принимать эстафету и выполнять какие-то действия без распоряжения своего непосредственного руководителя? В обычных условиях руководителям отделов приходится вступать в переписку. Если же имеется регламент, то работники разных подразделений включаются в выполнение процесса, не дожидаясь указания «сверху».
Какие процессы подлежат регламентации?
Иметь отдельные регламенты на все рабочие процессы, несомненно, очень удобно. Однако у этой медали есть и оборотная сторона, а именно:
- регламентирование требует серьезных денежных вложений: хорошие консультанты стоят дорого, как и рабочее время собственных сотрудников;
- любой процесс постоянно развивается: появляются новые технические условия работы, к его выполнению приходят новые, по-другому обученные люди, и схема процесса, составленная сегодня, может до неузнаваемости измениться через год. За этим тоже нужно следить, что означает новые затраты;
- подход к выполнению процесса, когда «шаг в сторону равносилен побегу», не способствует проявлению работниками инициативы, а ведь никто, в конечном счете, не сумеет оптимизировать процесс лучше тех, кто непосредственно работает над ним;
- внедрение регламента практически гарантированно влечет за собой сопротивление работников, причем как непосредственных участников процесса, так и многочисленных «сочувствующих». Преодоление сопротивления – целый этап внедрения регламента, требующий и временных, и материальных ресурсов.
Таким образом, регламентированию подлежат в первую очередь типовые процессы. Они будут выполняться в организации всегда, независимо от внешней ситуации. Перечень процессов, подлежащих регламентированию в конкретной организации, составляется строго индивидуально, исходя из множества факторов.
СТРУКТУРА И СОДЕРЖАНИЕ РЕГЛАМЕНТА
Как правило, регламент состоит из следующих основных разделов:
- Общие положения.
- Термины, определения, сокращения.
- Описание процесса.
- Ответственность.
- Контроль.
Подробнее содержание разделов регламента представлено в таблице.
Раздел |
Содержание раздела |
Общие положения |
|
Термины, определения, сокращения |
Определение терминов и разъяснение сокращений, используемых в тексте регламента. Термины приводятся в алфавитном порядке. Каждый из них пишется с новой строки в единственном числе, а его определение указывается через тире без слова «это». В качестве источника определений желательно использовать законодательные акты, государственные стандарты и другие нормативные документы |
Описание процесса |
Пошаговое описание процесса. Для удобства этот раздел делится на подпункты, каждый из которых соответствует очередному этапу процесса. В разделе указываются работники, задействованные в выполнении, описываются действие и результат |
Ответственность |
Ответственность участников процесса за неисполнение регламента (дисциплинарная, административная, уголовная). Последняя касается обычно сложных производственных процессов, связанных с риском для здоровья и жизни работников |
Контроль |
Указание Ф.И.О. должностного лица, ответственного за контроль исполнения регламента, а также, при необходимости, средства контроля |
ОСНОВНЫЕ РЕКВИЗИТЫ РЕГЛАМЕНТА
К числу основных реквизитов документа относят:
- наименование организации;
- дату и номер документа, место его составления;
- гриф утверждения;
- наименование документа;
- текст документа;
- приложение (если есть);
- визы согласования.
Кстати
Требования к оформлению перечисленных реквизитов установлены ГОСТ Р 6.30-2003. Методические рекомендации по внедрению ГОСТ Р 6.30-2003 разъясняют и конкретизируют порядок внедрения и применения данного стандарта.
МОДЕЛЬ БИЗНЕС-ПРОЦЕССА
В качестве приложения к регламенту может выступать модель бизнес-процесса. Ее принято изображать графически (см. схему), но допустимо также составить таблицу и даже описать процесс вербально. Графические модели бизнес-процессов создаются с помощью специального программного обеспечения.
То, что на первый взгляд кажется хитросплетением линий и геометрических фигур, на самом деле представляет собой строгий порядок действий при выполнении того или иного процесса, в нашем случае – процесса делопроизводства. Схема бизнес-процесса гораздо удобнее для восприятия, чем текст того же регламента. На ней четко видно, кто и с чего начинает каждый этап, чем его заканчивает и кому передает эстафету в работе над процессом.
На графической модели бизнес-процесса «Согласование проекта документа» представлены такие ключевые параметры бизнес-процесса, как входы и выходы, клиенты и участники. Каждый новый работник, глядя на модель, оперативно включится в выполнение своего процесса на определенном этапе и будет знать, как вести себя в любой рабочей ситуации, связанной с ним.
ПОРЯДОК РАБОТЫ НАД РЕГЛАМЕНТОМ
Работа над регламентом ничем не отличается от работы над любым другим организационно-распорядительным документом: сначала составляют проект документа, который согласовывают с заинтересованными должностными лицами, затем его утверждает руководитель организации или уполномоченное им лицом. Наконец, участники процесса знакомятся с регламентом под роспись и получают на руки его копии.
Утверждение регламента может производиться несколькими способами:
- напрямую (руководитель собственноручно расписывается на документе);
- косвенно (путем издания приказа) (см. Пример 1). В данном случае в гриф утверждения будут внесены регистрационные данные приказа.
Пример 1
Приказ об утверждении и введении в действие
регламентов бизнес-процессов
Общество с ограниченной ответственностью «Перспектива»
(ООО «Перспектива»)
ПРИКАЗ
23.07.2014 № 456-Пр
г. Москва
Об утверждении и введении в действие регламентов бизнес-процессов
В целях совершенствования процедур делопроизводства ООО «Перспектива»
ПРИКАЗЫВАЮ:
1. Утвердить и ввести в действие с 01.08.2014 регламенты следующих бизнес-процессов:
1.1. Регистрация и учет документов.
1.2. Контроль исполнения документов.
1.3. Хранение и поиск документов.
2. Назначить ответственным за выполнение требований, указанных в п. 1 данного приказа, административного директора Легостаева А.В.
3. Начальнику канцелярии Паршиной В.К. обеспечить ознакомление работников ООО «Перспектива» с настоящим приказом под роспись и передать копии утвержденных регламентов в структурные подразделения ООО «Перспектива» до 30.07.2014.
4. Контроль исполнения настоящего приказа оставляю за собой.
Генеральный директор Максимов Д.А. Максимов
С приказом ознакомлены:
Легостаев А.В. Легостаев 24.07.2014
Паршина В.К. Паршина 24.07.2014
П.А. Карпенко
23-78
Регламент бизнес-процесса «Контроль исполнения документов» приведен в Примере 2.
Пример 2
Регламент бизнес-процесса «Контроль исполнения документов»
Общество с ограниченной ответственностью «Перспектива»
(ООО «Перспектива»)
УТВЕРЖДЕНО Приказом генерального директора ООО «Перспектива» от 23.07.2014 № 456-Пр |
РЕГЛАМЕНТ №7
бизнес-процесса «Контроль исполнения документов»
1. Общие положения
1.1. Регламент бизнес-процесса «Контроль исполнения документов» (далее – Регламент) определяет порядок контроля исполнения заданий по документам в ООО «Перспектива» (далее – Организация).
1.2. Требования и правила Регламента распространяются на все структурные подразделения Организации.
1.3. Утверждение Регламента, внесение в него изменений и отмена производятся приказом генерального директора Организации.
1.4. Работники Организации обязаны знать и выполнять требования Регламента. Все вновь принятые на работу сотрудники Организации должны быть ознакомлены руководителями структурных подразделений с установленным порядком контроля исполнения документов в Организации.
2. Термины, определения, сокращения
2.1. В Регламенте используются следующие термины и определения:
Автор задачи – работник, направивший исполнителю электронное сообщение, содержащее задание.
Документ – зафиксированная на носителе информация с реквизитами, позволяющими ее идентифицировать.
Задание – поручение руководителя.
Задача – см. задание.
Исполнитель – работник Организации, которому поручено исполнение задачи.
Контроль – совокупность действий, обеспечивающих своевременное исполнение документа.
Ответственный исполнитель – работник из числа исполнителей, обладающий правом координации работы других исполнителей. В резолюции указывается первым.
Резолюция – реквизит, содержащий указания должностного лица по исполнению документа. Включает в себя фамилии, инициалы исполнителей, содержание поручения (при необходимости), срок исполнения, подпись и дату.
Руководитель – должностное лицо, выносящее резолюцию.
Срок исполнения – календарная дата исполнения задачи. Срок исполнения документа начинается со дня его регистрации в канцелярии Организации и исчисляется в календарных днях. Документы подлежат исполнению в следующие типовые сроки:
– с конкретной даты исполнения – в указанный срок, если документ поступил в Организацию не позже чем за три дня до истечения указанного срока;
– без указания конкретной даты исполнения и специальных пометок – в течение 30 дней;
– без указания конкретной даты, с пометкой «Срочно» или «Немедленно» – в течение трех дней;
– без указания конкретной даты, с пометкой «Оперативно» – в течение 10 дней.
3. Описание процесса
3.1. Постановка документа на контроль.
3.1.1. Контролю подлежат все зарегистрированные документы, требующие исполнения.
3.1.2. Основанием для постановки документа на контроль является резолюция генерального директора Организации или его заместителя.
В резолюции указываются:
– исполнитель документа;
– срок исполнения задачи;
– при необходимости – содержание задачи.
3.1.3. Получив документ с резолюцией, секретарь генерального директора или секретарь заместителя генерального директора (далее – Секретари) готовят скан-копию документа с резолюцией. Отсканированный документ помещается в папку «На контроле».
3.1.4. Файл копии документа вкладывается в электронное сообщение, направляемое исполнителю.
3.1.5. В параметрах электронного сообщения устанавливается срок исполнения задачи и включается опция уведомления автора задачи о ее получении.
3.1.6. После получения электронного сообщения с задачей исполнитель направляет автору задачи уведомление о ее получении.
3.1.7. В случае если исполнитель получает задание, содержание которого находится за пределами его компетенции, он обязан уведомить об этом автора задачи в течение одного рабочего дня с момента получения задания. Автор задачи, получив подобное уведомление, представляет руководителю документ для повторной резолюции.
3.2. Выполнение задания.
3.2.1. Исполнитель выполняет поставленную перед ним задачу в установленный в резолюции срок.
3.2.2. Если последний день исполнения задачи приходится на нерабочий день, документ подлежит исполнению на следующий рабочий день.
3.2.3. Если выполнить задание в установленный в резолюции срок не представляется возможным, исполнитель обязан доложить об этом руководителю до истечения срока выполнения и объяснить причину задержки. Если причина является уважительной, руководитель может продлить срок выполнения задачи.
3.2.4. В случае если срок выполнения задачи был продлен руководителем, автор задачи изменяет срок ее выполнения в электронной карточке документа.
3.3. Отчет о выполнении задания.
3.3.1. Выполнив задание, исполнитель формирует отчет о выполнении, который направляется автору задачи в виде электронного сообщения. Отчет о выполнении задания должен быть информативным и содержать конкретное описание действий и принятых мер. В случае если для выполнения задачи потребовалось составить документ, его регистрационные данные указываются в отчете о выполнении задачи.
3.3.2. Получив отчет о выполнении задачи, автор задачи ставит статус «Выполнено» в электронной карточке документа. Документ изымается из папки «На контроле» и помещается в дело.
3.3.3. В случае если автор задачи не получил отчет о выполнении задачи в срок, указанный в резолюции, он направляет исполнителю электронное сообщение-запрос с требованием указать причину невыполнения задачи. О невыполнении задания автор задачи докладывает руководителю с приложением объяснений исполнителя. Если причина является уважительной, руководитель может продлить срок выполнения задачи.
3.3.4. В случае если срок выполнения задачи был продлен руководителем, автор задачи изменяет срок выполнения в электронной карточке документа.
3.4. Формирование отчета о выполнении задач.
3.4.1. Секретари ежемесячно формируют отчет о выполнении задач по документам, который представляют руководителю.
В отчете указывается:
– общее количество поставленных задач за отчетный период;
– количество выполненных задач;
– количество задач с продленным сроком исполнения;
– количество задач, не выполненных в срок.
При наличии задач, не выполненных в срок, указываются также фамилии исполнителей данных задач.
4. Ответственность
Работники Организации, независимо от занимаемых должностей, несут дисциплинарную ответственность за ненадлежащее исполнение или неисполнение требований настоящего Регламента.
5. Контроль
Контроль исполнения Регламента осуществляет административный директор Организации.
*Организационно-распорядительная документация. Требования к оформлению документов. Методические рекомендации по внедрению ГОСТ Р 6.30-2003 (утверждены Росархивом).
Статья опубликована в журнале «Секретарь-референт» № 9, 2014.
УТВЕРЖДАЮ
_______________________/Ф.И.О./
«____»_________________200___г.
Регламент процесса
«Закупочная деятельность в ООО «Техснаб»
Разработал
Согласовано
_______________ /____________/. _______________/
./
«_____»___/__________200____г.
Проверил
________________/ /
_______________/ /
________________/ /
«_____»_______________200___г.
ООО |
Процесс |
||
Лист |
Дата |
ОГЛАВЛЕНИЕ
1. НАЗНАЧЕНИЕ И ОБЛАСТЬ
ПРИМЕНЕНИЯ……………………………………………………………
2. НОРМАТИВНЫЕ ССЫЛКИ
3. ОПРЕДЕЛЕНИЕ ТЕРМИНОВ, ОБОЗНАЧЕНИЯ
И СОКРАЩЕНИЯ………………………….
4. ВЛАДЕЛЕЦ ПРОЦЕССА, ВХОДЫ И ВЫХОДЫ
ПРОЦЕССА…………………………………..
5. РЕСУРСЫ
ПРОЦЕССА…………………………………………………………………………………………….
6. ВЫПОЛНЕНИЕ ПРОЦЕССА ОФОРМЛЕНИЯ
ДОГОВОРА АРЕНДЫ………………………
7. ОТВЕТСТВЕННОСТЬ РУКОВОДСТВА ЗА
УПРАВЛЕНИЕ ПОЦЕССОМ………………..
8. АНАЛИЗ ДАННЫХ СО СТОРОНЫ
РУКОВОДСТВА……………………………………………….
9. ДОКУМЕНТИРОВАНИЕ И
АРХИВИРОВАНИЕ…………………………………………………….
10. ПОРЯДОК ВНЕСНЕИЯ
ИЗМЕНЕНИЙ……………………..:……………………………………………
11.
РАССЫЛКА……………………………………………………………………………………………………………
12. ЛИСТ РЕГИСТРАЦИИ
ИЗМЕНЕНИЙ……………………………………………………………………
13. ОЗНОКОМЛЕНИЕ
СОТРУДНИКОВ………………………………………………………………………
ООО |
Процесс |
||
Лист |
Дата |
1. Назначение и область применения
1.1. Настоящий регламент процесса
устанавливает порядок выполнения
Процесса закупок на предприятии ООО
«Техснаб» и предназначен для:
а) обеспечения закупок товарно-материальных
ценностей, соответствующих определенным
требованиям для производства качественного
деревообрабатывающего оборудования;
б) постоянного улучшения качества и
результатов процесса.
1.2. Требования настоящего регламента
процесса распространяются на все функции
и работы, выполняемые в ходе выполнения
Процесса закупок в отделе закупок ООО
«Техснаб», а также при взаимодействии
с различными соисполнителями и
субподрядчиками.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #