Как написать регламент образец процесса

Настоящая инструкция по делопроизводству (далее – Инструкция) утверждается с целью установления единых требований к подготовке, обработке, хранению и использованию документов общества с ограниченной ответственностью «АБВ» (далее – Общество).

Информационный блок «Область применения» повествует о том, когда и при каких обстоятельствах пригодится этот ЛНА. Он может состоять из одного-двух предложений или даже сливаться с предыдущей информацией о целях разработки ЛНА.

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

Затем в разделе «Общие положения» приводится список нормативно-методических документов и внутренних регламентов компании, на основе которых составлен текст этого ЛНА. Впрочем, некоторые компании предпочитают выводить его в отдельный раздел «Нормативно-методическая документация». Источники располагаются в порядке значимости: сначала нормативные документы (кодексы, законы, постановления, инструкции и т.д.), затем стандарты, методические рекомендации. Завершают список внутренние регламенты.

Следующим блоком описывается порядок применения ЛНА: кто отвечает за его исполнение, кто контролирует исполнение, что последует за неисполнение требований документа.

Завершают раздел сведения о порядке утверждения ЛНА, введения его в действие, изменения и отмены.

Термины, определения, сокращения 

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

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

Например:

Термины, определения, сокращения

Основной текст 

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

Объем ЛНА 

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

Структура текста 

Нужно ввести стандартные правила структурирования текста, например:

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

1. Заголовок главы;

1.1. Заголовок раздела;

1.1.1. Заголовок подраздела;

1.1.1.1. Содержание пункта подраздела.

Нельзя путать «уровень рубрикации» с количеством пунктов. Пятого уровня рубрикации – 1.1.1.1.1. – уже быть не может, а на четвертом уровне может быть сколько угодно пунктов, например, 12.4.14.57.

Приложения 

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

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

Например:

Бланк приказа по основной деятельности

Мы привели минимальный набор разделов ЛНА. Некоторые организации могут расширить его. Например, существует практика создания раздела «Документация», в который вносятся все документы, образующиеся в процессе выполнения регламентированных работ, с указанием ответственного подразделения и даже срока хранения. Безусловно, такая практика очень помогает в составлении номенклатуры дел и в целом в процессе хранения документов.

Оформление ЛНА 

Титульный лист 

При желании организация может оформлять свои ЛНА с титульным листом (Пример 1). Главное, чтобы было принято окончательное решение относительно его использования: или на всех ЛНА без исключения, или вовсе без него. Без титульного листа вполне можно обойтись, оформляя ЛНА на общих фирменных бланках для документов.

Форма титульного листа приведена в ГОСТ Р 7.0.97-2016.

Титульный лист ЛНА

Пункты и списки 

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

Списки в тексте ЛНА

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

Заголовки, гиперссылки, формат 

Большинство ЛНА сегодня используются в электронном виде. Это нужно учитывать при их разработке и оформлении. Цель разработчика нормативного документа – сделать свое детище максимально удобным в использовании. Его должно быть не просто комфортно читать, но и находить в нем информацию, перемещаться между разделами, прямо из текста пункта переходить в упомянутое в нем приложение и обратно.

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

Быстрое перемещение между структурными единицами документа достигается путем системы гиперссылок. Это очень полезно, например, если к пункту ЛНА имеется приложение. Из текста пункта ставится гиперссылка на приложение, а из приложения – обратно на пункт (Пример 2). Также ставятся быстрые переходы в любые точки текста.

Оформление гиперссылок

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

Гиперссылки в ЛНА

Работа над ЛНА 

Стандартизации подлежат также процессы работы над ЛНА – от разработки проекта до передачи на хранение.

Подготовка проекта 

Исполнитель приступает к работе над ЛНА в двух случаях: по собственной инициативе или исполняя задание руководства. Задание может быть изложено в распорядительном документе, поручении, резолюции на письме или записке. Его лучше задокументировать, чтобы рассчитать срок подготовки проекта ЛНА. Что касается инициативы, то ее можно и ограничить. Например, некоторые компании устанавливают в своих регламентах, что инициировать ЛНА может только структурное подразделение статусом не ниже управления.

Согласование 

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

И состав согласующих лиц, и сроки согласования для ЛНА можно взять из Примерной инструкции по делопроизводству (пп. 4.4 и 4.6 соответственно).

Согласование ЛНА

Утверждение

Главное, что необходимо установить относительно утверждения ЛНА в компании, – то, что утверждение возможно двумя способами: лично должностным лицом и распорядительным документом.

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

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

Регистрация 

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

Регистрация ЛНА

Ознакомление 

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

Внесение изменений 

За время действия многих «долгоиграющих» ЛНА в них не раз могут вноситься изменения. Порядок внесения описывается в регламенте. Указываются виды изменений ЛНА, обязанность вносить их распорядительным документом, а главное – как внедрить изменения в уже действующий документ.

Отмена 

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

Хранение 

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

Предлагаем вам пример инструкции по работе с локальными нормативными актами (Пример 3).

Локальный нормативный акт о работе с ЛНА

Локальный нормативный акт о работе с ЛНА

Локальный нормативный акт о работе с ЛНА

Локальный нормативный акт о работе с ЛНА

Локальный нормативный акт о работе с ЛНА

Резюме 

1. «ЛНА об ЛНА» необходим на зрелом этапе жизненного цикла организации, когда все установившиеся процессы регламентируются.

2. В «ЛНА об ЛНА» устанавливаются виды ЛНА, используемые в организации, правила их структурирования и оформления.

3. В «ЛНА об ЛНА» устанавливаются общие правила (независимо от вида ЛНА) подготовки проектов, согласования, утверждения, учета, изменения, отмены, хранения регламентирующих документов организации.

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

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

По нашему мнению, хороший пример должен обладать следующими свойствами:

  1. Он должен представлять собой документ, который уже реально где-то работает. Проще говоря — пример должен поступать из практики, которая уже доказала свою эффективность.
  2. Он должен охватывать и описывать большинство востребованных составляющих. Иными словами — в примере вы должны увидеть 80% описания того, с чем столкнетесь при самостоятельной разработке.
  3. Пример должен представлять информацию, которую способно понять большинство. Если пример регламента процесса будет рассказывать о ядерном синтезе, это будет малопонятно для широкой аудитории.

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

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

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

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

Управление проектами по реализации заказов

Регламент бизнес-процесса

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

  • Операционный департамент
  • Департамент логистики и закупок
  • Департамент эксплуатации
  • Отдел сертификации
  • Конструкторский отдел

Ответственным, за содержание регламента и обеспечение его выполнения, является Директор по проектам. Актуальная версия регламент 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 Внесение изменений в процесс

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

Порядок внесения изменений в процесс:

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

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

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. Доступ к регламенту

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


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

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

Регламент: зачем он нужен компании и как его составить

Опубликовано: 16 сентября 2020

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

Для начала определим, что означает это понятие:

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

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

Зачем разрабатывать регламент

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

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

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

Кому нужен регламент

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

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

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

Комментарий эксперта:

Владимир Маринович, бизнес-философ, бизнес-ангел, акционер Gett

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

Расчетный счет с бонусами портала «Ближе к делу»: специальные условия при открытии счета, курс по маркетингу и доступ к клубу предпринимателей.

Плюсы регламента

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

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

С чего начинать?

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

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

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

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

Последующие шаги достаточно просты и рутинны:

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

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

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

Обязательно будут появляться погрешности и неточности. Главное — не унывать и не опускать руки!

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

Любая компания – маленькое государство со своими законами и порядками. Точнее, со своими устоями, а вот порядок как раз и приходится наводить «законами» – регламентами, инструкциями, распоряжениями и т.д.

Придя в новую компанию, сотрудник, как правило, в первый же рабочий день получает на руки кипу бумаг на изучение – регламенты по тем или иным процессам в компании. «Это Вам на ознакомление, – весело рапортует HR. – Сколько Вам нужно времени на прочтение?» Что ж, если человек пришел из крупной структурированной компании с отлаженными процессами, вопросов у него не возникает, он внимательно изучает документы. Но, к сожалению, встречаются люди, которые искренне недоумевают: «Зачем? Зачем переводить бумагу? Мир и его процессы меняются быстрее, чем вы успеете описать их! Работать можно и так».

Два лагеря, два кардинально противоположных мнения. Кто прав? Не берусь судить за все компании. Возможно, где-то есть «великие» фирмы, способные эффективно функционировать в условиях непрописанных стандартов, без четких границ и функционалов работников. Мне не довелось работать в таких организациях.

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

Алгоритм разработки

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

ШАГ № 1: Найти проблему

«О, да у меня куча проблем! – воскликнет практически каждый. – С какой начинать-то?» Начинать всегда с той, без решения которой невозможно дальше дышать свободно. Здесь по классике составляем список «необходимых регламентов» и определяем, где «болит сильнее», а где «еще можно подождать».

Для бизнеса любая проблема = рабочая задача.

Объясню на примере. Допутим, есть проблема – нет учета командировок сотрудников в 1С, периодически сталкиваемся с некорректным учетом потраченных в них денежных средств. Из наличия проблемы следует задача – научить менеджеров корректно оформлять командировки и отчитываться по ним.

ШАГ № 2: Определить «вход» и «выход» процесса

Наш процесс: Василий планирует…

Как бухгалтеру-аутсорсеру составлять регламенты для своей работы

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

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

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

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

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

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

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

Инструкция по составлению регламента

  1. Выбираем бизнес-процесс или задачу, которую требуется выполнить.
  2. Определяем исходные данные и конечную цель.
  3. Какие задачи нужно решить для достижения цели.
  4. Находим взаимосвязь между задачами и выстраиваем верную хронологическую последовательность.
  5. Регламент пишется для определенного исполнителя,так что определяем дополнительно, кто будет ответственным за выполнения процесса.
  6. Объясняем, как должна выполняться каждая задача и с помощью каких инструментов.
  7. Чтобы проанализировать результат и узнать на каком этапе была допущена ошибка, определяем показатели для оценки.
  8. Выбранные показатели вы должны контролировать и следить за их достижением.
  9. Тестируем, мониторим и испытываем на себе полученную инструкцию.
  10. Исправляем ошибки и недочеты. Знакомим исполнителя с регламентом и запускаем в работу.

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

Регламенты служат на благо бизнеса

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

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

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

Автоматизация: Битрикс.24

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

Переносите свои бизнес-процессы в онлайн. На курсе Школы Бухгалтерского Бизнеса научат, как работать с помощью Битрикс.24.

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

  1. Платформа оборудована всеми необходимыми инструментами для работы: онлайн чат, планировщик задач (календарь), безопасный облачный диск и файловый обменник, интерфейс для просмотра новостей. Переводим переписку и общение сотрудников из различных мессенджеров на одну общую, созданную для работы, платформу.
  2. Битрикс позволяет назначать и передавать задачи ответственному исполнителю или группе. Созданные справочники CRM позволяют настроить тайм-менеджмент и заложить фундамент будущих бизнес-процессов.
  3. Универсальность позволяет объединить все каналы коммуникаций, и получить данные о заявках, оставленных на сайте, электронной почте, в чат-ботах, мессенджерах, IP телефонии. В итоге всё самое важное и нужное в одном месте и можно раздавать задачи, расставлять приоритеты, делегировать полномочия.
  4. Переносите готовые или создавайте с нуля необходимые регламенты по выполнению бизнес-процессов и взаимодействию с клиентами. Определяйте регулярные и шаблонные задачи.
  5. Все выполненные действия сводятся в отчет и определяется их эффективность ( KPI)
  6. Битрикс поможет настроить маркетинг и проанализировать продажи. Для этого прописываются сценарии лидогенерации, выбираются лид-магниты и автоворонки (об этих понятиях как-нибудь тоже поговорим). Собранные данные с посадочных страниц попадают в индивидуально настраиваемую CRM-форму. Отсюда рождается правдивая аналитика и мониторинг выполнения заказов.
  7. Позволяет углубить автоматизацию бизнеса и постоянно совершенствоваться.

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

Понравилась статья? Поделить с друзьями:
  • Как написать резюме для университета
  • Как написать резюме для студента на практику
  • Как написать резюме для репетитора
  • Как написать резюме для прохождения практики
  • Как написать резюме для проекта