Какой тип регламента выбрать?

Автор: Дмитрий Пинаев
Информация об авторе

Ситуация

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

Анна Фуникова, Москва

Отвечает Дмитрий Пинаев, генеральный директор ГК «Современные технологии управления»:

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

Выбор типа регламента зависит прежде всего от того, кто будет его конечным «потребителем».

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

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

Настоящий документ является регламентом выполнения процедуры «А2.5 Прием и открытие заказов» процесса «А2 Продвижение и продажи» и разработан в целях:

  • Формирования единых правил и требований к выполнению процедуры;
  • Установления ответственности за результат процедуры;
  • Унификации и стандартизации документооборота.

Начало процесса — поступление заявки от клиента.

Основной результат процесса — сформированный заказ на продажу, внесенный в информационную систему (ИС).

Длительность процесса — 1 рабочий день.

Владелец процесса — начальник отдела продаж.

Исполнители процесса: основной исполнитель — отдел продаж; участвует конструкторский отдел.

При выполнении процесса следует руководствоваться следующей плановой и нормативно-методической документацией:

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

Описание действий процесса:

  1. Заявка заказчика на продукцию поступает из Договорного отдела менеджеру отдела продаж;
  2. Менеджер проверяет соответствие заявки условиям договора с заказчиком по списку продукции, количеству, срокам поставки:
    1. Если заявка не соответствует условиям договора, то ее необходимо уточнить у заказчика. Уточненная заявка вновь проверяется на соответствие условиям договора, в случае выявления отклонений, действия повторяются;
    2. Если заявка соответствует условиям договора, менеджер дополнительно в течение не более, чем 10 минут, выясняет, существует ли заказываемая продукция в информационной системе предприятия;
    3. Если такая продукция есть в наличии, менеджер в течение дня уточняет объем и срок исполнения заявки и вносит информацию в ИС;
    4. Если заказываемой продукции нет в наличии, менеджер формирует запрос в Конструкторско-технический отдел (КТО) на внесение в ИС всех необходимых данных по отсутствию товарно-материальных ценностей (ТМЦ):
      1. Регистрацию изделия в информационной системе осуществляет инженер-конструктор в течение 15 минут, и в этот же день направляет уведомление о внесении в ИС всех данных по необходимой продукции;
      2. Получив уведомление от КТО о внесенных в ИС данных по необходимой продукции, в течение дня уточняет объем и срок исполнения заявкии вносит заяву в ИС.
  3. Заявка в ИС создается на основании заявки от заказчика и отчетов об остатках на складе и движениях готовой продукции.

Таблица 1. Текстовый регламент (фрагмент)

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

Процесс Исполнители Входы Выходы
Объекты / условия От кого поступают Объекты / условия Кому передаются/ сроки
A2.5.1 Прием заявки от заказчика Менеджер по продажам Заявка от заказчика Договорной отдел Менеджер по продажам Заявка Менеджер по продажам
A2.5.2 Проверка спецификации заявки на соответствие условиям договора Менеджер по продажам Заявка Договорной отдел Менеджер по продажам Заявка Менеджер по продажам
В этот же день
A2.5.3 Заявка соответствует условиям договора? Менеджер по продажам Заявка Менеджер по продажам Да -> A2.5.5 Менеджер по продажам
Нет -> A2.5.4 Менеджер по продажам
В этот же день
A2.5.4 Уточнение заявки у заказчика Менеджер по продажам Заявка Менеджер по продажам Заявка Менеджер по продажам
Нет -> A2.5.3 Заявка соответствует условиям договора? Менеджер по продажам Заявка
A2.5.5 Проверка существования заказываемой продукции в ИС Менеджер по продажам А2.5.3. — Да
Заявка
Менеджер по продажам Продукция не существует -> A2.5.6 Менеджер по продажам
До 10 минут
Продукция существует -> A2.5.7
A2.5.6 Формирование запроса в КТО на внесение в ИС всех необходимых данных по отсутствующей продукции Менеджер по продажам А2.5.5. — Продукция не существует Менеджер по продажам Запрос на внесение в ИС отсутствующих ТМЦ Конструкторско-технический отдел
До 10 минут
A2.5.7 Регистрация изделия в ИС Конструкторско-технический отдел Запрос на внесение в ИС отсутствующих ТМЦ Менеджер по продажам Информация о внесении ТМЦ в ИС Менеджер по продажам
В этот же день
A2.5.8 Получение уведомления от КТО о внесенных в ИС данных по необходимой продукции Менеджер по продажам Информация о внесении ТМЦ в ИС Конструкторско-технический отдел Уведомление о внесении данных в ИС Менеджер по продажам
В этот же день
A2.5.9 Уточнение объема и срока исполнения заявки Менеджер по продажам A2.5.5. — Продукция существует Менеджер по продажам Заявка Менеджер по продажам
В этот же день
A2.5.10 Создание заявки в ИС Менеджер по продажам Заявка Отчеты об остатках на складе и движениях готовой продукции Менеджер по продажам Заявка в ИС Отдел продаж
Начальник отдела продаж
Менеджер
Конструкторско-технический отдел
Экономист по финансовой работе

Таблица 2. Табличный регламент

Решить эту проблему помогает использование графики — блок-схем, которые в виде рисунка представляют ход выполнения процесса (рисунок 1). При стартовом описании возрастают трудозатраты бизнес-аналитика, поскольку при построении блок-схемы необходимо мысленно структурировать процесс, выстроить его логику. Но результат того стоит — четкая визуализация (структура процесса и его взаимосвязи видны с первого взгляда) позволяет избежать ошибок и «лишних» шагов и способствует быстрому пониманию логики и последовательности работ персоналом.

Рисунок 1. Диаграмма бизнес-процесса в нотации Cross Functional Flowchart (Фрагмент регламента, автоматически сформированного в системе бизнес-моделирования Business Studio)

Для большего удобства коллективной работы с графикой разработаны специальные правила — системы условных обозначений для моделирования бизнес-процессов (нотации моделирования), их использование позволяет всем участникам процессов и бизнес-аналитикам «говорить на одном языке». Но не забывайте, что слишком сложные схемы могут быть непонятны сотрудникам компании. Поэтому необходимо продумать графический вид процесса (какую-то информацию вынести справочно, за блок-схему) и выбрать удобную для понимания персонала нотацию. Для создания технологических карт наиболее часто используют Basic Flowchart, Cross Functional Flowchart, EPC.

Сегодня наиболее распространен способ комбинированного описания — с помощью блок-схем, но с расшифровкой деталей процесса в таблице и/или текстом.

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

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

По данным CNews, компании, которые внедряют процессный подход, повышают качество работы на 20–30%. Количество жалоб со стороны клиентов сокращается на треть, а время, потраченное на процесс, — на 10–30%.

Опубликовано по материалам:
Журнал «Коммерческий директор» № 11, 2012

Рекомендуемые материалы по тематике