Одноуровневый регламент выполнения процесса
Рассмотрим так называемый одноуровневый регламент выполнения процесса. Объект регламентации для этого документа:
Процесс 1:
1. операция 1.1;
2. операция 1.2;
3. …
n. операция 1.n.
Уровень, на котором рассматривается процесс 1, – относительный, а не абсолютный, то есть одноуровневый регламент может содержать описание процессных групп в рамках одной категории, процессов в рамках процессной группы, операции в рамках процесса (этот вариант используется чаще всего).
Для каждой операции нужно указать исполнителя, текстовое описание, входы/выходы, требования к срокам и другую необходимую информацию (в одной или нескольких таблицах). Нужно включить в документ графическую схему, отображающую все указанные операции. Полученный документ можно называть «Регламент процесса на одном уровне (одноуровневый регламент)» или «Инструкция по выполнению процесса».
Шаблон одноуровневого регламента представлен в приложении 2.
Предложенный шаблон одноуровневого регламента весьма прост, но имеет некоторые особенности.
В частности, в разделе 5 есть информация о целях и показателях, которые должны использоваться для управления процессом. Отмечу, что плановые и фактические значения показателей в регламенте не указываются. Они должны включаться в соответствующие плановые и отчетные документы по процессу.
В разделе 6 содержится информация о так называемых методах контроля. Строго говоря, контроль исполнения требований регламента предполагает выполнение некоторых процессов. Но для упрощения системы и сокращения числа регламентирующих документов в данном случае процессы контроля детально (в виде схем, подробных инструкций) не прописываются. Дается их краткое описание (в таблице). Такое решение, как, впрочем, и любое другое имеет свои преимущества и недостатки. К преимуществам, с моей точки зрения, можно отнести то, что владелец процесса, его руководитель, внутренний аудитор имеют информацию о том, где и как нужно проверять исполнение требований регламента. Информация о методах контроля представлена именно в том документе, который и нужно проверять.
Методы контроля следует привязывать к наиболее важным этапам процесса. Возможны методы контроля, предполагающие анализ результатов выполнения процесса в целом и т. п.
Еще раз подчеркну, что, описывая процесс и разрабатывая его регламент, мы определяем:
• цели и показатели контроля результативности и эффективности процесса;
• методы контроля исполнения требований.
При необходимости шаблон регламента процесса можно дополнить нужными разделами.
Двухуровневый регламент выполнения процесса
Объект регламентации двухуровневого регламента – это:
Процесс 1.
Процесс 1.1:
1. операция 1.1.1.;
2. операция 1.1.2;
3. …
n. операция 1.1.n.
Процесс 1.2:
1. операция 1.2.1;
2. операция 1.2.2;
3. …
n. операция 1.2.n.
Процесс 1.m:
1. операция 1.m.1;
2. операция 1.m.2;
3. …
n. операция 1.m.n.
Описание операций может быть представлено в виде таблиц. Для каждого процесса на уровне х. х (процесс 1.2) приводят схему процесса. Для процесса в целом также представляют общую графическую схему. Документ на этот процесс можно называть «Регламент процесса на двух уровнях (двухуровневый регламент)».
Можно разработать и трехуровневый[109], и даже четырехуровневый регламент. Но эти документы будут слишком объемными и сложными для использования.
Возникает вопрос: нужно ли делать одно– и двухуровневые регламенты для одной и той же деятельности? Все зависит от ситуации. Если регламентная база отсутствует (или находится в запущенном состоянии), то для начала разрабатывается система процессов (иерархический справочник процессов компании). Описание начинают с операционного (по сути, нижнего) уровня. При этом получаются одноуровневые регламенты, которые нужно своевременно утверждать и вводить в действие. Представим себе, что в течение некоторого времени многие процессы были описаны на уровне операций в виде одноуровневых регламентов. В данной ситуации вместо десятка одноуровневых сто́ ит разработать и ввести в действие один двухуровневый регламент. Также удобно сформировать двухуровневый регламент для сквозного процесса, содержащего несколько подпроцессов.
Положение о подразделении и должностная инструкция
Кроме регламентов процессов, полезно разрабатывать положения о подразделениях. При внедрении процессного управления эти положения можно создать, выявляя те процессы, в которых участвует соответствующее подразделение.
На уровне сотрудников (рис. 5.5.2) показаны инструкции по выполнению процессов (операционные карты). Это могут быть документы типа одноуровневого регламента или более детальные формы процессного представления деятельности. Например, в операционной карте на одном-двух листах показаны все действия, выполняемые отдельным сотрудником в рамках процесса более высокого уровня.
Обязательные документы на этом уровне – должностные инструкции, в приложения к которым могут включаться все операции, выполняемые соответствующей должностью в процессах организации.
Шаблоны положения о подразделении и должностной инструкции – в приложениях 3 и 4. Данные шаблоны нормативных документов построены таким образом, что могут быть полностью выгружены из среды моделирования бизнес-процессов Business Studio.
Процедура разработки и согласования НМД
Рассмотрим процедуру разработки, согласования, утверждения и ввода в действие НМД компании. Содержание этой процедуры зависит от следующих факторов:
• размера организации (по численности сотрудников, сложности организационной структуры);
• подхода к регламентации процессов (упрощенный, стандартный, сложный);
• наличия ресурсов, выделяемых на управление жизненным циклом НМД (персонал, инфраструктура);
• наличия системы электронного документооборота;
• прочее.
Далее рассмотрим процедуру, которая используется в небольших и средних по величине организациях. Использование системы электронного документооборота в данном случае не предполагается[110].
Титульный лист процедуры не приводится. Оглавление опущено. Комментарии к тексту приводятся курсивом.
ПРОЦЕДУРА УПРАВЛЕНИЯ НМД
ВНУТРЕННЕГО ПРОИСХОЖДЕНИЯ
5.6.1. Термины и определения
В процедуре используются следующие термины и определения (табл. 5.6.1):
Таблица 5.6.1. Термины и определения
Список терминов может быть расширен и переработан с учетом специфики конкретной компании.
Нормативные ссылки
При разработке этой процедуры использовались следующие документы внешнего происхождения (табл. 5.6.2):
Таблица 5.6.2. Документы внешнего происхождения
Список внешних НМД приводится в качестве примера.
При разработке этой документированной процедуры использовались следующие документы внутреннего происхождения (табл. 5.6.3):
Таблица 5.6.3. Документы внутреннего происхождения
Могут приводиться ссылки на НМД компании и внешние нормативные документы, которые были использованы при разработке процедуры.
Структура НМД
Структура НМД, используемая в организации, представлена в табл. 5.6.4.
Таблица 5.6.4. Структура НМД организации
Основными факторами, определяющими необходимость разработки/пересмотра (актуализации) НМД, могут быть:
• усовершенствование системы процессов организации;
• изменение структуры организации, перераспределение ответственности руководителей организации;
• изменение технологии работы;
• выявленное отсутствие необходимого нормативно-методического документа;
• усовершенствование системы НМД организации;
• результаты внутреннего или внешнего аудита системы процессов организации;
• указания руководителей, утверждающих документы;
• другие факторы, определяющие необходимость разработки/пересмотра (актуализации) документации по результатам текущей деятельности организации.
Это поясняющий текст, его можно убрать из реальной процедуры.
Инициация разработки НМД
Порядок инициации разработки НМД представлен на рис. 5.6.1. Инициаторами разработки НМД могут быть руководители организации до уровня отделов. При возникновении потребности в НМД инициатор разработки готовит обоснование необходимости его разработки в виде служебной записки и передает ее генеральному директору (ГД).
Рис. 5.6.1. Инициация разработки НМД
Кто может являться инициатором разработки НМД? Это зависит от размера организации и сложности структуры НМД. Как правило, инициатором разработки должен быть руководитель структурного подразделения или ведущий специалист.
ГД проверяет обоснованность заявки. Если заявка недостаточно обоснованна, то ГД уведомляет об этом инициатора в устной форме. Если необходимо совещание по обсуждению целесообразности разработки НМД, то ГД организует его.
Замечу: если в компании внедрена система электронного документооборота, то практически все действия, указанные в настоящей процедуре, могут быть автоматизированы. Для этого используют типовые маршруты и соответствующие задания исполнителям.
При необходимости ГД проводит совещание по обсуждению целесообразности разработки НМД. В совещании принимают участие инициатор разработки и согласующие руководители. По итогам совещания ГД принимает решение о целесообразности разработки НМД. Если это нецелесообразно, то ГД уведомляет инициатора разработки в устной форме (или по системе электронного документооборота)[111].
Если разработка НМД полезна, ГД визирует служебную записку на разработку НМД и передает ее помощнику ГД.
Разработка нормативно-методического документа типа «регламент» стоит дорого. Расчеты показывают, что одноуровневый регламент обходится в сумму от 20–30 до 50–60 тыс. рублей в зависимости от сложности описываемого процесса. При расчете принимались во внимание зарплата бизнес-аналитика, стоимость его рабочего места (инфраструктура), затраты на обеспечение связью и поддержание программных продуктов, стоимость рабочего времени сотрудников, которые были вовлечены в разработку и согласование документа.
Помощник ГД готовит проект распоряжения о разработке НМД и передает ГД.
Помощник ГД в данном случае отвечает за документооборот в организации. В более крупной компании это может быть специализированное подразделение (канцелярия, архив и т. п.).
ГД подписывает распоряжение о разработке/пересмотре НМД и передает своему помощнику.
Помощник ГД регистрирует распоряжение, ставит его на контроль и передает копию распоряжения ответственному разработчику (ОР). ОР получает копию распоряжения и приступает к разработке НМД.
Ответственный разработчик документа – это руководитель подразделения или ведущий специалист, который в соответствии с распоряжением обязан разработать нормативный документ за отведенное время. Хотя ответственному разработчику может помогать квалифицированный бизнес-аналитик, ответственность за разработку, контроль исполнения и последующую актуализацию документа целиком возлагается на ответственного разработчика. То есть ответственными разработчиками целесообразно назначать руководителей подразделений, которые потом будут оперативно контролировать исполнение требований соответствующих нормативных документов.
