Инструкция по бизнес процессу пример

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

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

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 Заказ РКД

 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. Краткое описание процесса

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

Картинка с сайта: deep-vision.one

Карточка бизнес-процесса «Управление проектами по реализации заказов»

2. Границы процесса

2.1 События начала

События начала инициируют выполнение процесса.

Картинка с сайта: deep-vision.one

Границы бизнес-процесса: событие начала

2.2 Входы

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

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

Картинка с сайта: deep-vision.one

Описание поставки входов в бизнес-процесс

2.3 Продукты

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

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

Выполненные работы — комплекс монтажных и пуско-наладочных работ, в соответствии с Договором. Продукты процесса данного типа:

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

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

• РКД — рабочая конструкторская документация поставляемого оборудования, согласно спецификации контракта. РКД должна быть заверена конструкторским отделом компании и одобрена со стороны заказчика. Основной продукт процесса.
• ЭД — эксплуатационная документация поставляемого оборудования, согласно спецификации контракта. ЭД должна быть заверена отделом эксплуатации и одобрена со стороны заказчика. Основной продукт процесса.
• Методики испытаний — описание методик испытаний поставляемого оборудования, в соответствии со спецификацией контракта. Методики испытаний должны быть подготовлены в соответствии с формами и требованиями морского и речного регистра. Основной продукт процесса.
• СТО — сертификаты типового одобрения для поставляемого оборудования, в соответствии со спецификацией контракта. СТО должны быть заверены морским и речным регистром. Основной продукт процесса.
• СИО — сертификаты индивидуального одобрения для поставляемого оборудования, в соответствии со спецификацией контракта. СИО должны быть заверены морским и речным регистром. Основной продукт процесса.
• Пультовые схемы — конструкторские схемы пульта судовождения. Схемы обязаны получить одобрение КД судостроительного завода. Основной продукт процесса, в случае наличия пульта судовождения в спецификации контракта.
• Электромонтажные схемы пульта — схемы пульта судовождения для выполнения электромонтажных работ. Схемы обязаны получить одобрение КД судостроительного завода. Основной продукт процесса, в случае наличия пульта судовождения в спецификации контракта.
• Состав монтажного комплекта — перечень инструментов и расходных материалов для осуществления монтажа оборудования. Должен быть выполнен по установленной форме «Монтажный комплект» и утвержден отделом эксплуатации. Вторичный продукт процесса.
• Первичная документация — первичная сопроводительная документация поставки оборудования. Документация обязана соответствовать фактически поставленному оборудованию. Оригиналы документов должны содержать соответствующим печати и подписи сторон. Вторичный продукт процесса.
• Акт приема оборудования — акт, который подписывает заказчик, при приеме оборудования на своем складе. В Акте должно быть указано лицо, со стороны заказчика, осуществившее прием оборудования. Оригиналы документов должны содержать соответствующим печати и подписи сторон. Вторичный продукт процесса.
• Акт приема выполненных монтажных работ — акт, который подписывает заказчик, при приеме монтажных работ. В Акте должно быть указано лицо, со стороны заказчика, осуществившее прием оборудования. Оригиналы документов должны содержать соответствующим печати и подписи сторон. Вторичный продукт процесса.
• Акт приема выполненных пуско-наладочных работ — акт, который подписывает заказчик, при приеме пуско-наладочных работ. В Акте должно быть указано лицо, со стороны заказчика, осуществившее прием оборудования. Оригиналы документов должны содержать соответствующим печати и подписи сторон. Вторичный продукт процесса.
• Карточка проекта — описание результатов проекта, по установленной форме. Заполняется менеджером проекта и согласовывается всеми заинтересованными сторонами, при закрытии проекта. Карточка проекта должны быть подготовлена на основании установленной формы и не должна иметь незаполненных полей. Вторичный продукт процесса.

Картинка с сайта: deep-vision.one

Описание передачи продуктов процесса клиентам

2.4 События окончания

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

Картинка с сайта: deep-vision.one

Границы бизнес-процессов: событие окончания

3. Выполнение процесса

3.1 Диаграммы модели бизнес-процесса

Картинка с сайта: deep-vision.one

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

Картинка с сайта: deep-vision.one

3.1.2 Заказ РКД

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

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

3.2 Процедуры, бизнес-правила и скрипты

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

Картинка с сайта: deep-vision.one

Процедуры, бизнес-правила и скрипты

Время выполнения операций

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

Картинка с сайта: deep-vision.one

Время выполнения операций бизнес-процесса

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

3.4 Участники процесса

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

Картинка с сайта: deep-vision.one

Участники бизнес-процессов 

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

3.5 Ресурсы и инфраструктура

3.5.1 Перечень ресурсов

• Рабочее место сотрудника — предоставляется сотруднику компании по умолчанию. По нормативу, на процесс необходимо два рабочих места. Стоимость одного рабочего места составляет 124.000 руб. Рабочее место используется многократно, стоимость использования в процессе составляет Х руб. Относится к типу Оборудование. Единица измерения — единица.
• MS Project — предоставляется новому сотруднику по заявке в Департамент ИТ, после чего является частью рабочего места сотрудника. По нормативу, для выполнения процесса необходимо две лицензии MS Project. Стоимость одной лицензии составляет 18.000 руб. Все программное обеспечение используется многократно, стоимость использования в процессе составляет Х руб. Относится к типу Программное обеспечение. Единица измерения — лицензия.
• Navision — предоставляется новому сотруднику по заявке в Департамент ИТ, после чего является частью рабочего места сотрудника. По нормативу, для выполнения процесса необходимо две лицензии Navision. Стоимость одной лицензии составляет 16.000 руб. Все программное обеспечение используется многократно, стоимость использования в процессе составляет Х руб. Относится к типу Программное обеспечение. Единица измерения — лицензия.
• Легковой автомобиль — предоставляется по заявке в Службу обеспечения. По нормативу, на выполнение процесса необходимо два автомобиля. Стоимость одной единицы составляет 760.000 руб. Легковой автомобиль используется многократно, стоимость использования в процессе составляет Х руб. Относится к типу Транспортное средство. Единица измерения — единица.
• Комплект средств индивидуальной безопасности посетителя склада — предоставляется ответственным сотрудником, при посещении склад. Комплект средств должен быть выдан до входа на территорию склада. Каждый посетитель склада должен получить индивидуальный комплект. Стоимость одного комплекта составляет 8.000 руб. Каждый комплект используется многократно, стоимость использования в процессе составляет Х руб. Относится к типу Инструмент. Единица измерения — комплект.
• Финансовые средства для оплаты проездных билетов, проживания и питания сотрудника в командировке — выдаются сотруднику по заявке в Бухгалтерию. Расчетный норматив на процесс — 800.000 руб. Может быть изменен в соответствии с бюджетом проекта. Финансовые средства в процессе расходуются полностью, в соответствии с отчетными документами. Относится к типу Финансовые средства. Единица измерения — рубль.

Картинка с сайта: deep-vision.one

3.5.2 Матрица использования ресурсов

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

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 Матрица ответственности управления процессом

Картинка с сайта: deep-vision.one

Матрица ответственности управления бизнес-процессом

4.2 Осуществление управления

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

Владелец Процесса несет ответственность за:

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

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

4.2.2 Внесение изменений в процесс

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

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

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

4.3 Ключевые требования к процессу

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

Картинка с сайта: deep-vision.one

Ключевые требования к бизнес-процессу

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

4.4 Ключевые показатели эффективности

• Длительность проекта — показатель хода процесса, отражающий время, на протяжении которого был осуществлен проект. Длительность проекта соответствует длительности одной итерации процесса. Показатель фиксируется в системе MS Project. Датой начала считается дата создания паспорта проекта, дата окончания — дата закрытия паспорта проекта в MS Project. Ответственным за актуализация данных в MS Project является Менеджер проектов, в рамках своих проектов. Мониторинг и анализ показателя осуществляется ежемесячно. Ответственным за мониторинг и анализ показателя является Директор по проектам. Анализ показателя предполагает сравнение планового и фактического значения, накопительно, на текущий месяц и выявление расхождений. В случае выявления расхождения, превышающего 10%, владелец процесса должен провести углубленный анализ для определения причин расхождения. Затем, владелец процесса, должен принять решение и организовать корректирующие действия, если это необходимо для соблюдения сроков проекта. При организации корректирующих действий, владелец процесса может задействовать любые заинтересованные стороны, в том числе осуществлять взаимодействие с заказчиком.
• Стоимость проекта — показатель хода процесса, отражающий суммарную стоимость всех расходов, связанных с реализацией проекта. Стоимость проекта соответствует стоимости одной итерации процесса. Показатель фиксируется в системе Navision, на основании данных управленческого учета. Ответственным за актуализацию данных в Navision является Менеджер проекта. Допускается отставание данных в Navision от фактических в одну неделю. Мониторинг и анализ показателя осуществляется ежемесячно. Ответственным за мониторинг и анализ показателя является Директор по проектам. Анализ показателя предполагает сравнение планового и фактического значения, накопительно, на текущий месяц и выявление расхождений. В случае выявления расхождения, превышающего 5%, владелец процесса должен провести углубленный анализ для определения причин расхождения. Затем, владелец процесса, должен принять решение и организовать корректирующие действия, если это необходимо для соблюдения сроков проекта. При организации корректирующих действий, владелец процесса может задействовать любые заинтересованные стороны, в том числе осуществлять взаимодействие с заказчиком. По договоренности с заказчиком, могут быть внесены изменения в бюджет проекта. Изменение осуществляется согласно процедуре «Изменение договорных условий»
• Соответствие поставки спецификации проекта — показатель продукта процесса, который отражает, на сколько итоговая поставка соответствует первоначальной спецификации проекта по договору. Состав первоначальной спецификации является частью первоначального бюджета, который заводится в Navision в процессе Продажи. Фактически поставленное оборудование также отражается в Navision, на основании Актов приема оборудования заказчиком. Ответственным за внесение данных по фактически поставленному оборудованию является руководитель отдела закупок. Мониторинг и анализ показателя осуществляется ежеквартально. Ответственным за мониторинг и анализ является Директор по проектам. Любое отклонение, а значит расхождение первоначальной и фактической спецификации, должно быть зафиксировано и согласованно с заказчиком. Ответственным за согласование и документальное оформление изменений является Менеджер проекта.
• Оценка проекта заказчиком — клиентский показатель, отражающий насколько заказчик удовлетворен результатом и ходом реализации проекта. Оценка осуществляется посредством анкетирования пяти участников проекта, со стороны заказчика. За получение анкет и расчета итоговой оценки отвечает Менеджер проекта. Анкеты и итоговые оценки являются приложением к карточке проекта и входят в комплект документов для защиты проекта. Расчет показателя осуществляется в подпроцессе Защита проекта.
• Оценка проекта участниками — клиентский показатель, который отражает удовлетворенность проектом внутренних клиентов, участников и заинтересованных сторон. Оценку выполняют участники проекта следующих организационных единиц: отдел закупок, отдел логистики, департамент эксплуатации, финансовый департамент, проектный отдел. Для оценки, внутренним участникам проекта рассылается анкета, которую они заполняют и направляют менеджеру проекта. Менеджер проекта несет ответственность за сбор данных и расчет итоговых оценок. Анкеты и итоговые оценки являются приложением к карточке проекта и входят в комплект документов для защиты проекта. Расчет показателя осуществляется в подпроцессе Защита проекта.

Картинка с сайта: deep-vision.one

Описание расчетов и значений KPI

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 Ревизия процесса

Картинка с сайта: deep-vision.one

Ревизия бизнес-процесса

5.3 Перечень изменений

Картинка с сайта: deep-vision.one

Перечень изменений бизнес-процесса

5.4 Словарь терминов и сокращений

• ПМ — менеджер проектов
• РКД — рабочая конструкторская документация
• ЭД — эксплуатационная документация
• СТО — сертификат типового одобрения
• СИО — сертификат индивидуального одобрения
• РМРС — Российский морской регистр судоходства
• РРРС — Российский речной регистр судоходства

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

5.5 Условные обозначения

Описание элементов нотации BPMN 2.0, в которой выполнены модели процесса, доступна по ссылке.

6. Доступ к регламенту

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

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

Картинка с сайта: deep-vision.one

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

Регламент процесса. Подробная инструкция

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

Читать

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

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

РЕГЛАМЕНТ КАК ДОКУМЕНТ 

Регламенты строго индивидуальны и могут действовать только в той организации, которая утвердила их для себя. Так, при составлении инструкции по делопроизводству обычно используют ГОСТ Р 6.30-2003 «Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов» и Методические рекомендации по внедрению ГОСТ Р 6.30-2003*. На основе этих документов создаются внутренние инструкции и в небольшом магазине, и в ОАО федерального уровня. А вот, например, порядок прохождения внутренних документов, установленный в одной организации, может совершенно не подходить для другой.

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

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

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

Какие процессы подлежат регламентации?

СТРУКТУРА И СОДЕРЖАНИЕ РЕГЛАМЕНТА 

Как правило, регламент состоит из следующих основных разделов:

1. Общие положения.
2. Термины, определения, сокращения.
3. Описание процесса.
4. Ответственность.
5. Контроль.

Подробнее содержание разделов регламента представлено в таблице.

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

К числу основных реквизитов документа относят:

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

Кстати

МОДЕЛЬ БИЗНЕС-ПРОЦЕССА 

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

Картинка с сайта: www.profiz.ru

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

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

ПОРЯДОК РАБОТЫ НАД РЕГЛАМЕНТОМ 

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

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

1. напрямую (руководитель собственноручно расписывается на документе);
2. косвенно (путем издания приказа) (см. Пример 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

Регламент бизнес-процесса «Контроль исполнения документов»

Общество с ограниченной ответственностью «Перспектива»
(ООО «Перспектива»)

РЕГЛАМЕНТ №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. Контроль

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

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

Картинка с сайта: mwi.me

Одна из самых популярных CRM – «Битрикс24». На этой платформе можно создать и с ожидаемым результатом реализовать бизнес-процесс. В данной статье рассмотрим пошаговый алгоритм постановки и выполнения задачи на примере простой сделки, требующей автоматизации.

Пошаговое проектирование бизнес-процесса: основные этапы

Подготовка, запуск и реализация бизнес-процесса в CRM «Битрикс24» включает несколько этапов:

1. Постановка конкретной задачи. Важно понять, чего нужно добиться в итоге, то есть после успешного завершения бизнес-процесса.
2. Описание алгоритма. Этот этап позволяет структурировать решение задачи, разделить его на последовательные, взаимосвязанные действия.
3. Формирование шаблона процесса. Это инструмент, который поможет внедрить в бизнес и реализовать необходимый алгоритм действий.
4. Предварительное тестирование. Это проверка корректности созданного шаблона, которая поможет выяснить, будет ли процесс правильно работать.
5. Введение в эксплуатацию. На данном этапе выбирается руководитель, а также устанавливается автоматический старт бизнес-процесса.
6. Непосредственно использование. Если всё сделано верно, то бизнес-процесс будет корректно работать.

Ниже рассмотрим подробнее каждый шаг.

Задача

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

Алгоритм

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

Картинка с сайта: mwi.me

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

Шаблон

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

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

Добавление шаблона для сделок

Чтобы добавить соответствующий шаблон, необходимо найти в интерфейсе «Битрикс24» раздел настроек и выбрать в нём подраздел настроек CRM. Если в главном меню такого нет, возможно, данный пункт находится в крайнем правом углу, в области с названием «Ещё».

Картинка с сайта: mwi.me

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

Картинка с сайта: mwi.me

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

Настройка добавленного шаблона

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

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

Картинка с сайта: mwi.me

Для окна настроек шаблона открываются разные вкладки. Первая – «Основное». Её заполнение мы рассмотрели выше. Вторая вкладка – «Параметры». Здесь можно вводить данные для запуска бизнес-процесса, а также для обмена информацией между несколькими БП.

Третья вкладка – «Переменные». Тут хранятся временные сведения, добавляемые и используемые в ходе процессов и автоматически удаляемые после их завершения. Последний пункт – «Константы». В него включается информация постоянная, не подвергаемая изменениям при протекании БП.

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

Чтобы указать «Константу», нажмите на соответствующую вкладку и в ней заполните несколько полей:

• Идентификатор. Сюда вводятся цифры, латинские буквы и знаки подчёркивания. Если вы случайно совершите ошибку и впишете другой символ, система сразу оповестит вас об этом.
• Название. Тут могут указываться любые символы. Но лучше сделать название ёмким, понятным, информативным.
• Описание. Данное поле можно не заполнять, так как в рассматриваемом примере всё предельно ясно и без уточнений. Но всё же лучше добавить разъясняющую информацию, например, короткую фразу типа «Минимальный размер суммы для проверки сделки руководителем».
• Тип. Тут нужно установить вид целого числа.

Картинка с сайта: mwi.me

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

Картинка с сайта: mwi.me

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

Картинка с сайта: mwi.me

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

Картинка с сайта: mwi.me

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

Картинка с сайта: mwi.me

Картинка с сайта: mwi.me

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

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

Картинка с сайта: mwi.me

Александр Апраксин

Директор компании MWI

12 + лет работаем с руководителями по маркетингу

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

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

137
способов привлечения клиентов

Пример маркетингового
плана на 3 месяца

KPI отдела маркетинга

Создание блок-схемы

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

Итак, наш разработанный алгоритм – это «Если сумма сделки равна 100 000 рублей или больше, то нужно назначить руководителя наблюдателем». Открывайте раздел конструкций, тут ищите действие «Условие». Наводите на него курсор, зажимайте правую клавишу компьютерной мышки и перемещайте пункт в зону серого треугольника, расположенного между полями «Начало» и «Конец».

Картинка с сайта: mwi.me

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

Картинка с сайта: mwi.me

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

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

Картинка с сайта: mwi.me

Перейдём к веткам условий. Их по умолчанию две. И для разбираемого в качестве примера задания такое количество как раз подходит. Но можно добавлять сколько угодно ответвлений. Для этого используйте расположенный справа от названия знак плюса – «+».

Выполним настройку ветки, находящейся слева. Присвоим ей наименование «ДА». Для «Типа условия» следует установить вариант «Поле документа». Это обобщённое название элемента, используемого для запуска бизнес-процесса.

Картинка с сайта: mwi.me

Ниже появится область поля документа, где надо выбрать сумму. Далее устанавливайте конкретное условие. Так как в нашем примере это сумма от 100 000 рублей, то подойдёт «не меньше». Затем нужно ввести значение, нажав на кнопку его вставки (три точки).

Картинка с сайта: mwi.me

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

Картинка с сайта: mwi.me

Затем нужно будет сохранить полностью настроенную левую ветку, кликнув на соответствующую кнопку.

Картинка с сайта: mwi.me

Результат рассмотренных выше работ – внедрение в блок-схему проверки для условия: если сумма заключаемой сделки, введённая в поле «Сумма», не меньше установленного значения константы, равного 100 000 руб.

Далее нужно установить условие для правой ветви. В качестве заголовка тут будет достаточно указать «НЕТ». Тип – «Истина».

Картинка с сайта: mwi.me

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

Для добавления в лог следует пользоваться действием «Запись в отчёт», которое можно найти в разделе «Прочее».

Картинка с сайта: mwi.me

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

Картинка с сайта: mwi.me

Чтобы в правую ветку условия добавить «Запись в отчёт», нужно данное действие скопировать – зажать кнопку «Ctrl» на клавиатуре и перетащить поле. Без нажатия «Ctrl» вы просто переместите действие без его копирования.

Картинка с сайта: mwi.me

В новом сформированном действии нужно скорректировать текст. Вместо «ДА» впишите «НЕТ».

Картинка с сайта: mwi.me

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

Далее левую ветку нужно дополнить наблюдателем, используя действие с названием «Изменение наблюдателей» (найти его вы сможете в разделе «CRM»).

Картинка с сайта: mwi.me

Тут оставляйте вариант «добавить». Для установки наблюдателя нажимайте на кнопку вставки с тремя точками.

Картинка с сайта: mwi.me

Нужный нам наблюдатель размещается в константе с наименованием «Руководитель». Её и следует выбрать.

Картинка с сайта: mwi.me

Картинка с сайта: mwi.me

Шаблон полностью готов. Его нужно сохранить.

Картинка с сайта: mwi.me

Запуск с тестированием

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

Картинка с сайта: mwi.me

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

Картинка с сайта: mwi.me

Картинка с сайта: mwi.me

В карточке в качестве наблюдателя выбран тестовый сотрудник.

Картинка с сайта: mwi.me

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

Если бизнес-процесс работает корректно, можно начинать заключительный этап.

Введение в эксплуатацию

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

Картинка с сайта: mwi.me

Картинка с сайта: mwi.me

Второе дело – установка автозапуска. Отметить нужно одновременно два чекбокса: «При изменении» и «При добавлении». Такое решение связано с тем, что сумма может задаваться как на этапе добавления новой сделки, так и при её изменении.

Картинка с сайта: mwi.me

Готовый бизнес-процесс запущен и может корректно работать.

Общая информация о бизнес-процессах

Зачем нужны бизнес-процессы? Они могут решать несколько задач:

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

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

Картинка с сайта: mwi.me

Какими бывают бизнес-процессы? В CRM «Битрикс24» предусмотрено три их вида:

• «Общие». Они свойственны всем компаниям. К ним относятся создание счетов для оплаты, отправка сотрудников в отпуска с подготовкой отпускных листов. Расположение – в разделе процессов во вкладке «Компания».
• «Мои процессы». Это активность отдельного пользователя, доступ к которой открывается администратором CRM. Для поиска этого раздела нужно открыть вкладку бизнес-процессов.
• «CRM и бизнес-процессы». Путь к ним проходит через пункт меню «CRM», раздел настроек, подразделы автоматизации и БП. Для быстрого перехода к доступным процессам можно воспользоваться «Живой лентой».

Создание

Для формирования простого БП нужно:

1. Зайти в «Живую ленту», открыть «Ещё», выбрать «Процессы», а потом кликнуть на кнопку создания нового БП.
2. Откроется окно, во вкладке настроек которого задаются имя с описанием и облегчающий сортировку индекс важности. Также можно установить изображение.
3. Во вкладке доступа отмечайте уполномоченных лиц. Эти сотрудники, указанные по именам, которые в своих личных профилях смогут посмотреть задачу.
4. К каждому шагу БП можно делать примечания через вкладку подписей.

Для дополнения БП условием применяют действие «Задача». Далее следует кликнуть на шестерёнку, установить все важные параметры, как это было рассмотрено в нашем примере.

Картинка с сайта: mwi.me

Заключение

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

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