Многоуровневые регламенты процесса

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

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

Я не рекомендую использовать регламенты, содержащие более 2-х уровней процессного дерева.

Структура «идеального» регламента

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

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

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

Пример. Структуры «идеальных» регламентов.

Двухуровневый

регламент

Одноуровневый

регламент

Операционная

инструкция

Область применения формы регламента

Для регламентации сложных, комплексных — сквозных (межфункциональных) бизнес- процессов

Для регламентации процессов уровня подразделения или отдельных простых сквозных процессов

Для регламентации процессов нижнего уровня, выполняемых 1—2 исполнителями

Возможный объем, стр.

40-100

12-40

ОО

1

т

Структура

«идеального»

регламента

  • 1. Титульный лист.
  • 2. Паспорт регламента.
  • 3. Содержание.
  • 4. Общие положения (в том числе «Потребители»).
  • 5. Цели и показатели (процесса в целом).
  • 6. Графическая схема процесса.
  • 7. Описание подпроцессов.
  • 1. Титульный лист.
  • 2. Паспорт регламента.
  • 3. Содержание.
  • 4. Общие положения (в том числе «Потребители»).
  • 5. Цели и показатели.
  • 6. Графическая схема процесса.
  • 7. Описание операций процесса.
  • 1. Графическая схема процесса.
  • 2. Описание операций процесса (текст

и картинка (фото, чертеж, скрин экрана).

3. Приложения

Двухуровневый

регламент

Одноуровневый

регламент

Операционная

инструкция

  • 7.1. Общее описание подпроцесса «...» {главная цель, владелец, краткое текстовое описание, границы, нормативный срок выполнения).
  • 7.2. Цели и показатели подпроцесса «...».
  • 7.3. Графическая схема подпроцесса «...».
  • 7.4. Описание операций подпроцесса «...».
  • 7.5. Действия

в случае отклонений по подпроцессу «...».

  • 7.6. Ресурсы, необходимые для выполнения подпроцесса «...».
  • 7.6. Контрольные процедуры

по подпроцессу

  • 7.7. Ответственность и полномочия по подпроцессу «...».
  • 7.8. Интеграция по подпроцессу

8. Действия

в случае отклонений.

  • 9. Ресурсы, необходимые для выполнения процесса.
  • 10. Контрольные процедуры (методы контроля).
  • 11. Ответственность и полномочия.
  • 12. Интеграция.
  • 13. Приложения

Двухуровневый

регламент

Одноуровневый

регламент

Операционная

инструкция

8. Действия

в случае отклонений (по подпроцессам).

  • 9. Ресурсы, необходимые для выполнения процесса.
  • 10. Контрольные процедуры
  • (по процессу в целом).
  • 11. Ответственность и полномочия (по процессу в целом).
  • 12. Интеграция (по процессу

в целом).

13. Приложения (для процесса

и подпроцессов)

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

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

  • 1) выводить общие требования к ресурсам процесса, занесенные в соответствующие атрибуты (поля) процесса в целом;
  • 2) выводить сводную информацию по всем подпроцессам, группируя ее по видам ресурсов[1] (информация берется из атрибутов, заполненных по каждому подпроцессу);
  • 3) объединить 1-й и 2-й подход.

Другой пример. Мы можем выводить информацию по контрольным процедурам по каждому подпроцессу, а можем объединить информацию по подпроцессам и вывести ее в одном разделе «10. Контрольные процедуры...» в виде таблицы:

Пример.

Наименование

процесса

Наименование

контрольной

процедуры

Описание

Отв.

Период

Источники

данных

Результат

Процесс в целом

Процедура 1

Процедура 2

1

Подпро-

цесс «1»

Процедура 3

2

Подпро- цесс «2»

Процедура...

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

  • 1) показать всю информацию по каждому подпроцессу (как показано в примере «Структуры идеальных регламентов»);
  • 2) в разделе 7 «Описание подпроцессов» показать только общее описание, цели и показатели, графическую схему, описание операций, а всю остальную информацию поместить в соответствующие разделы регламента в целом, выполнив группировку:
    • • действия в случае отклонений;
    • • ресурсы;
    • • контрольные процедуры;
    • • прочие необходимые разделы.

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

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

Специальные формы регламентов

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

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

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

В общем, чем визуально нагляднее будет регламент, тем эффективнее он будет использоваться на практике.

  • [1] Например, по оборудованию.
 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ     След >