Pereat mundus, fiat reglamentum («Пусть погибнет мир, но да будет регламент»).
1.5.1. Плюсы и минусы регламентации. Место процессных регламентов в регламентной базе организации
Регламент – это внутренний нормативный документ организации, который описывает требуемый порядок действий подразделений и сотрудников. Имеет ограниченную сферу действия, то есть описывает лишь часть всей деятельности. Процессный регламент описывает реализацию того или иного процесса/процедуры, то есть смотрит на деятельность как на процесс.
Преимуществ у регламентации много, и не все они очевидные. Например, регламентация (работающая!) позволяет:
• сделать работу организации более надежной и предсказуемой;
• повысить зрелость процессов (см. главу 3.4);
• повысить качество хода и результатов процесса, поскольку выполнение работы по регламенту – правильный для организации на этот момент времени способ получить результат17;
• дать сотруднику инструкцию, работая по которой он будет уверен, что поступает правильно;
• руководителю ослабить постоянный личный контроль при наличии уверенности, что сотрудники работают по регламенту. Он понимает, что они знают, что делать, и может рассчитывать, в частности, на самоконтроль;
• облегчить совершенствование процессов, так как снимает необходимость извлекать ситуацию «как есть» путем интервью, например. Кроме того, легко выявлять ошибки из-за нарушения регламента;
• получить экономию на обучении персонала. Вместо формирования учебной программы и привлечения наставника можно составить регламент и довести его до сотрудников. Контроль усвоения и применения, а также того, как все получается на деле, завершает процедуру обучения/адаптации. И работает как для новых сотрудников, так и для «старичков», осваивающих новые участки деятельности. В сложных случаях эти методы можно сочетать, но без актуального регламента коэффициент полезного действия (КПД) такой деятельности весьма низок;
• измерять эффективность работы подразделений и сотрудников.
Правда, вся эта красота возможна только тогда, когда регламент «правильный» и «живой». К сожалению, очень часто оба этих требования не выполняются.
Иногда утверждается, что регламентация ограничивает/убивает свободу творчества и продуктивную импровизацию сотрудников. Но тут надо разделять регламентацию вообще и неразумную регламентацию. Конечно, если описать сотруднику его действия вплоть до частоты дыхания и взмахов головой, то такая детальность уж точно повредит. Однако если уровень регламентированных действий разумен, а сами инструкции вводятся там, где действительно надо избежать фантазий, то такая регламентация ничего не убьет, а если что и ограничит, так только неэффективные вариации действий и хаос.
Вторая опасная для регламентов тема – так называемые «мертвые» регламенты. Если регламент есть, но устарел, то его, естественно, никто не будет исполнять. Если он при этом не отменен, то создается ситуация, когда какие-то регламенты (тогда уж что уж ☺), приказы и решения можно не выполнять, а какие-то, может, и сто́ит. И решать это предлагается самим сотрудникам. Руководству таких компаний, чтобы добиться исполнения своих решений, всегда требуется дополнительно прикрикнуть на сотрудников – никто особо серьезно эти бумажки не воспринимает. Они ведь не имеют обязательной силы!
Именно два этих фактора и создают легенду о том, что регламентация = бюрократия. Ведь когда регламенты неразумные и/или «мертвые», это однозначно вредное для компании дело. Мы же поговорим о том, как реорганизовать Рабкрин создать разумную и живую регламентацию.
Упражнение
С какими плюсами и минусами регламентации вы сталкиваетесь в своей организации?
1.5.2. Состав регламентной базы
Итак, целевая ситуация в отношении регламента процесса такова:
• он есть;
• он актуален, не устарел, не требует переработки. А когда требует, то тут же (то есть в тот момент, когда необходимость корректировки установлена на уровне принятия такого рода решений) и дорабатывается;
• он разумно написан, то есть содержит именно то описание процесса, которое в компании считается правильным и наилучшим в этот момент времени. Уровень детализации таков, что регламент регулирует только те действия, которые должны выполняться строго определенным образом, и оставляет необходимую степень свободы и простор для творчества (если оно там допустимо, конечно ☺);
• он есть обязательное и понятное руководство к действию по факту, то есть о его существовании известно исполнителям, они готовы его выполнять (знают, что и как там написано, согласны со своей ответственностью по его исполнению);
• он исполняется.
Разрабатывая План перехода к целевым процессам (План внедрения) в части создания или изменения внутренних нормативных документов, необходимо хорошо представлять себе территорию, на которую мы вторгаемся. Какие документы в настоящее время регламентируют эту деятельность? Какие документы ее касаются? Что именно вообще стоит искать?
Начиная работу с процессами, бизнес-аналитики нередко моделируют процесс «как есть» в лоб, не пытаясь изучить относящуюся к нему действующую нормативную базу. И возникает потрясающая ситуация: в организации есть описание процесса в документах СМК (формально действующее, хотя о нем редко кто знает, к сожалению), есть «старые» регламенты, написанные сотрудником, уже покинувшим компанию, но в свое время добившимся их утверждения, есть написанные на коленке инструкции для сотрудников авторства руководителя департамента (которые он почему-то никому не показывает, кроме «своих»), а по окончании проекта трансформации процесса недрогнувшей рукой аналитики пишут мероприятия «регламентировать процедуру», «регламентировать порядок» и т. п.
Возникает дикая каша бумаг по поводу одного и того же процесса (да и не только его, захватываются и разные подсистемы управления, например документооборот, планирование и пр.). Происходит это как по причине того, что состав регламентной базы участникам проектов трансформации неизвестен (и нередко немудрено: там нет порядка, там чудеса, там леший бродит, русалка…), так и потому, что технология поддержания документов регламентного характера в актуальном состоянии в компании отсутствует.
В то же время внутренний регламент – это ключевой инструмент менеджмента компании, необходимый для эффективного управления бизнесом. Не умеем его поддерживать = у нас нет этого инструмента. И приходится его заменять ручным управлением, голосом, лексикой и пр.
Совокупность регламентных документов образует регламентную базу организации. Что туда входит? Надо сказать, что границы регламентной базы нечеткие, это вопрос внутренней договоренности. Есть документы на грани: то ли регламент, то ли просто закон, то ли декларация о смыслах (например, документ «Ценности компании»), то ли просто техническая информация. Например, есть технические инструкции по использованию оборудования – регламентный ли это документ? В разных компаниях на этот вопрос ответят по-разному.
Мое мнение: к регламентным документам стоит относить документы, разработанные и утвержденные внутри компании, описывающие нормативным образом (обязательным для исполнения) действия сотрудников и важные для выбора действий факторы (цели, показатели и прочие такого рода вещи).
Состав регламентной базы может быть следующим:
правовая документация (устав юридического лица, сертификаты, лицензии и т. п.) – состав этой группы документов весьма вариативен;
стратегические документы бизнеса (стратегии разного рода (бизнес-, корпоративные, функциональные и пр.), цели, миссия, ви́дение, ценности, кодексы и т. п.);
процессные регламенты, интересующие нас в первую очередь. Но само название не должно закрывать нам глаза на то, что какой-то документ службы качества под названием «ДП (документированная процедура) “Закупки”» – это на поверку как раз претендент на то, чтобы быть процессным регламентом;
положения о подразделениях, описывающие их состав, функционал, полномочия и ответственность (чисто в функциональной нарезке);
положения о подсистемах управления (документообороте, организационной структуре и т. п.). Иногда называются стандартами, например Стандарт проектного управления;
функциональные политики – главный инструмент Координаторов функциональных направлений18. Например, Политика в области информационной безопасности или Коммерческая политика;
• документы, регламентирующие порядок действий конкретного сотрудника (должностные инструкции, рабочие инструкции, описывающие порядок выполнения отдельных функций, и пр.). Иногда эти документы так и называются – «Порядок …». В этом случае они могут быть и небольшими процессными регламентами, то есть описывать действия нескольких сотрудников в процедуре;
• технологические документы (описывающие работу с техническими объектами) и пр.
Еще раз подчеркну, что состав регламентной базы – дело внутренней договоренности в организации.
Упражнение
Постройте модель-классификатор19 документов, входящих в регламентную базу вашей организации.
1.5.3. Процессные регламенты – приоритеты разработки
Центральная группа документов регламентной базы – это процессные регламенты. В совокупности они описывают львиную долю деятельности организации.
Надо ли регламентировать все процессы? Нет, не надо. Регламент – вещь не бесплатная: его надо разработать и поддерживать в актуальном состоянии. А это время и ресурсы, причем это постоянные расходы, не разовые. Овчинка должна стоить выделки. То есть существование регламента должно окупаться, польза от его применения должна существенно и неоспоримо перевешивать затраты на разработку и актуализацию.
Какие процессы надо регламентировать? Собственно, те, в которых существование регламента очевидно полезно. Начинать надо с тех процессов, которые при ранжировании попадают в правый верхний квадрант фазовой плоскости «Потенциал оптимизации/неудовлетворенность процессом – важность процесса для организации» (рис. 9)20.
Рис. 9. Приоритеты регламентации процессов
Такое ранжирование можно проводить на разных уровнях детализации, то есть формировать перечень процессов как из Модели процессов верхнего уровня (МПВУ), так и на более детальных уровнях. Другое дело, что уже даже на уровне 2 количество процессов составит несколько сотен. Как же в таком случае корректно отобрать процессы для регламентации?
Я рекомендую такую последовательность действий.
• В первую очередь следует сформулировать свою стратегию действий в отношении регламентации процессов. Если эта задача подчинена задачам трансформации (совершенствования и реинжиниринга процессов), то специально о ранжировании для определения приоритета регламентации говорить не имеет смысла. Тогда регламенты создаются и корректируются в рамках проектов трансформации согласно соответствующему плану. Если же задача регламентации приоритетна, то мы должны как минимум часть плана проектов трансформации посвятить именно этой задаче. И начинать следует с оценки требуемых результатов (в том числе своей производительности) на горизонт полгода-год.
• Затем мы проводим ранжирование процессов с МПВУ. Отбираем процессы, наиболее близкие к правому верхнему углу фазовой плоскости. При этом отбрасываем процессы, и без того попавшие в проекты трансформации (там регламентация пойдет своим чередом), но отбираем с запасом по отношению к целевому объему результатов (практика подсказывает – раза в полтора больше).
• Далее берем детализацию второго уровня отобранных процессов и проводим ранжирование для них. Нередко оказывается, что причина отнесения процесса верхнего уровня к неудовлетворительным – не весь процесс, а несколько его подпроцессов – там сосредоточен основной потенциал совершенствования. Чаще всего на этом уровне процессы уже вполне компактные, чтобы можно было говорить о соотношении «один процесс – один регламент». Однако при необходимости можно повторить процедуру и на третьем уровне, аналогично отобрав только те подпроцессы, которые толпятся в правом верхнем углу.
Иногда можно встретить рекомендации при отборе процессов для регламентации специально учитывать их частоту. По моему опыту, при проведении ранжирования менеджмент организации, выставляя оценки неудовлетворительности и важности процесса, учитывает этот фактор. Редкий процесс, не являющийся повседневным, так сильно раздражает руководителей и так часто оценивается как важный.
Упражнение
Проведите ранжирование процессов организации с точки зрения приоритета их регламентации (не только с нуля, но и от существующей базы, когда необходима актуализация или корректировка регламента). Составьте план работ по регламентации на ближайший год с учетом потенциально доступных (или мобилизуемых при наличии политической воли руководства) ресурсов.
1.5.4. Процессные регламенты – нюансы разработки
Как избежать дублирования при регламентации процессов?Процессные регламенты довольно хорошо сопоставляются с процессными моделями. Можно (и часто нужно) в самих Соглашениях по моделированию предусмотреть привязку регламентов как входящих документов к процессам, процедурам, функциям (в зависимости от детальности модели). Обычно на 2–3-м уровне детализации это уже приводит к соотношению «один процесс – один регламент». Иногда же процесс может описываться в двух или более регламентах (или – шире – регламентных документах). Тут возможны три ситуации.
Регламенты описывают процесс встык, без того, чтобы какие-то функции остались неописанными, и без нахлеста (дублирования). Почти идеальная ситуация. Лучше было бы, если бы нарезка процессов и регламентов совпадала.
• Между регламентированными областями остаются пробелы – не описанные в регламентах процессы/процедуры/функции. Здесь мы должны опираться на принятые решения по приоритету регламентации (см. ранее). Если белое пятно значительно по размеру (и, соответственно, по объему работ по регламентации), то его очередь наступит в свое время. Если оно незначительно, то обычным разумным решением было бы расширить границы описания одного из регламентов (впрочем, иногда и обоих).
• Самый сложный случай, когда фрагмент процесса попал в два и более регламентных документа. Тут придется выделить главный документ (учитывая приоритет процессного регламента), а в остальных документах в соответствующих местах разместить ссылку на него. Нельзя допускать дублирования нормативных текстов или, что особенно опасно, расхождения норм в разных документах. Само по себе дублирование нормативных текстов несет опасность такого расхождения в будущем. Да и поддержание норм в актуальном состоянии весьма усложняется.
Такая ситуация – случай нередкий на старте внедрения процессного управления. Часто это происходит, когда в компании есть документы формальной СМК и документы реального управления, которые сталкиваются во многих процессах. При этом практически всегда статус документов рядовым сотрудникам неизвестен, а то и непонятен.
В ситуации версионности нормативных документов сотрудник может сам выбирать, чем ему руководствоваться, если не имеет четких указаний от руководства. Поэтому разрешить эту коллизию надо как можно скорее.
Таким образом, имея модели процессов, можно синхронизировать с ними архитектуру процессных регламентов.
Еще один нередко обсуждаемый вопрос: надо ли отдельно и специально регламентировать управление процессом? Вообще, функции управления (планирование, учет, контроль, анализ и корректировка) являются частью процессных цепочек, а не висят в воздухе отдельно от процесса. Поэтому, если процесс корректно описан или спроектирован, управление будет его частью. И искусственно выдирать его из процесса не нужно, просто вредно.
Нужны ли так называемые регламенты подразделений? Эта категория нормативных документов прямо соответствует понятию «процессы подразделений». Собственно, сама компания может восприниматься как подразделение. И ее зона ответственности – установить правила взаимодействия подразделений верхнего эшелона (департаментов, управлений). Внутри этих подразделений, в свою очередь, есть задача урегулировать важные участки взаимодействия подразделений второго уровня (служб, отделов) и т. д.
Но здесь важно понимать, что регламентируемые цепочки – это всегда фрагменты процессов, затрагивающих различные службы. Например, процесс продажи – это не процесс департамента продаж. Там задействованы и финансовые, и производственные, и логистические, и юридические, и прочие подразделения. Поэтому если регламент взаимодействия на уровне департаментов не удовлетворяет кого-то из директоров департаментов, то у него два пути: добиться нужной степени детализации общего регламента либо расписать для своих сотрудников те функции, где такая детализация требуется. Вообще, довольно часто так называемые процессы подразделений – это процедуры, практикуемые руководителями этих подразделений (летучки, подведение итогов и прочие такого рода вещи). А им писать самим себе регламенты – дело сомнительной целесообразности. С приходом нового начальника такие ритуалы редко продолжают жить.
Впрочем, наиболее важные процессы детализируются всеми подразделениями-участниками «до дна колодца» (то есть вплоть до рядовых сотрудников).
1.5.5. Уровень детализации регламента
Насколько детальным должен быть регламент? С одной стороны, если он очень общий, то не сможет отразить ключевые (важные для компании) подробности процесса. А если чересчур детальный, то его сложно выполнять и контролировать, вообще с ним работать, менять например. Сложно даже запомнить. Такие регламенты нередко выполняются приблизительно, плюс-минус ☺. Таким образом, детализация – явно оптимизационная задача.
В то же время, как мы уже разбирали, разные процессы изначально требуют разной детализации. Да что там, некоторым процессам регламентация противопоказана ☺. В то же время важные для компании (прямо влияющие на создаваемый продукт, его качество, критические параметры – стоимость и пр.) высокочастотные процессы со значительным объемом взаимодействия сотрудников, особенно относящихся к разным подразделениям, – кандидаты на весьма подробный регламент.
Итак, основные факторы, влияющие на детальность регламента:
важность (влияние на критические параметры бизнеса) и сложность (частотность, число взаимодействий, вариативность и «неочевидность») процесса;
корпоративная культура компании, в первую очередь стиль управления (предпочтения лидеров в использовании регламентов как инструмента управления, стремление к детальной четкости vs склонность к управлению идеями, лозунгами, понятиями и пр.);
• размер компании. Крупные компании с помощью регламентов борются с хаосом в процессах. У них просто нет иного выхода. В этом смысле они напоминают фундаментально отстроенные цеха-конвейеры – мощные, высокопроизводительные, экономичные и т. п. Малые компании чаще всего имеют весьма ограниченные регламентированные области (если вообще они есть). Это дает им возможность быстро перестраиваться под изменившиеся условия или запросы. Ну а микропредприятиям вообще рано заниматься регламентацией, хорошо работают ручные методы. Соответственно, такие предприятия серьезно проигрывают крупным в отлаженности, но выигрывают в гибкости. Средний бизнес – переходная зона. Растущие средние предприятия часто активно занимаются отладкой процессов, используя регламенты как инструмент. Предприятия же, для которых средний размер целесообразен и соответствует рациональному размеру в отрасли, могут демонстрировать и детальную регламентированность, и практическое отсутствие таковой. Это в значительной степени вопрос корпоративной культуры, как я упомянул ранее.
Еще несколько тезисов, имеющих отношение к уровню детальности.
Регламент должен быть коротким, максимально простым, скупым на слова и точным в их подборе. Как в классике: «Тост на охоте должен быть краткий, как команда, как выстрел! Иначе времени на отдых не останется!»21 Чем больше по объему и «водянистее» регламент, тем менее вероятно, что он будет исполняться. Рекомендуется укладываться в пять страниц сущностного текста без титула, обязательных листов и приложений.
Очевидные вещи и всякие выписки/цитаты из сторонних документов (законов, нормативных актов и пр.) включать в него категорически запрещено. Регламент должен содержать правила, устанавливаемые компанией.
• Иногда утверждают, что в регламенте должны быть только те нормы, выполнение которых можно контролировать. А иначе, мол, он не будет исполняться. Это не совсем так. При составлении регламента стоит делать проверку на предмет: а если исполнитель поступит не так, как написано? Почему он может поступить иначе? Во многих случаях такого мотива нет, и вполне можно полагаться на самоконтроль сотрудника. Если нарушение регламента никакой выгоды не приносит, а в случае, когда будет обнаружено, создает неприятности или не дает возможности получить результат, с которым связано вознаграждение сотрудника, то вряд ли последний выберет такой вариант действий. В тех же случаях, когда нарушение может иметь мотив (например, упрощение себе жизни), следует предусматривать антимеры. Это может быть и специальный контроль, но лучше работает связь антимер с мотивированием на правильные действия.
ПРИМЕР
Клиент-менеджер после переговоров с клиентом должен вносить данные о них в CRM-систему. Многие делают это неохотно. Можно ежемесячно запускать скрипт по системе, который проверяет внесение записей о переговорах по календарю клиентского менеджера, куда, в свою очередь, вносятся все встречи и контакты с клиентами. Отсутствие записей может быть стоп-фактором при выплате бонуса, поводом к передаче клиента другому менеджеру. А пустые поля в календаре и отсутствие встреч с клиентами – тормозом на пути категорийного роста. В такой ситуации клиентскому менеджеру проще и выгоднее выполнять установленный регламент процесса.
1.5.6. Форматы процессного регламента
Процессный регламент описывает процесс, то есть повторяющуюся цепочку действий. В отличие от него Положения описывают, как правило, какую-то подсистему управления (документооборот, планово-бюджетную систему, учетную систему, процессное управление, проектное управление и т. п.).
Регламенты могут создаваться в различных форматах.
Текстовый – наиболее распространенный и привычный для большинства вариант. Однако все меньше сотрудников в состоянии одолевать long-read – длинные текстовые документы, что заставляет работодателей искать упрощенные и «веселые» форматы.
Табличный – работать с ним не очень удобно. Документ получается громоздким, одни ячейки заполнены, а соседние – пустые. В среднем таблица оказывается скорее пустой. Кроме того, если сценарий процесса разветвлен, если есть варианты, то работать с описанием такого процесса в таблице весьма непросто. В то же время форма таблицы дисциплинирует в плане полноты информации, а получить такой регламент из модели автоматически (с помощью скриптов) – весьма соблазнительная возможность.
Регламент в виде моделей – такие регламенты довольно популярны в компаниях, продвинутых в части процессного управления. Но для этого используемая нотация должна быть интуитивно читаемой. Этому требованию лучше всего удовлетворяют нотации ЕРС, в том числе с так называемыми плавательными дорожками (swimlane), на которых отражаются действия конкретного исполнителя (сотрудника, подразделения, бизнес-роли), и блок-схемы. Чаще встречается дублирование текстового регламента моделью (в этом случае нотация может быть более мудреной).
С использованием инфографики, когда текст заменяется схемами или рисунками. Подходит для относительно простых процессов и хорошо воспринимается, такой регламент легко понять. Однако для сложных процессов языка инфографики не хватает.
Регламент-видеоролик с тайм-кодом – скорее экзотика, встречается редко. Иногда используется как дополнение к основному формату (обычно текстовому). Тайм-код помогает быстро перемещаться по видео и находить нужные точки и фрагменты.
• «Электронный регламент» – автоматизированный (чаще всего с использованием BPM-системы) процесс, который самостоятельно движется по шагам в системе, что не дает возможности сотруднику выйти из колеи процесса. В этом варианте система сама является регламентом и сама же контролирует процесс. Вариант весьма привлекательный, но не для всех процессов подходит. Да и просто в моменте не до всех процессов доходят автоматизирующие руки, и там приходится использовать другие форматы.
Во всех этих случаях источником информации может и должна быть грамотно построенная модель процесса («как есть» или «как должно быть» – для разных задач используются разные исходники). Хочу обратить внимание на то, что не только регламент процесса может быть создан на базе модели. Например, по этой технологии разрабатываются технические задания (ТЗ) на доработки в корпоративной информационной системе (ИС). Если модели охватывают всю предполагаемую область автоматизации, то можно сделать ТЗ на внедрение ИС. Если модели созданы для всех процессов, в которых участвует подразделение, то можно автоматически получить (при соответствующей детализации) должностные инструкции сотрудников и Положение о подразделении. Для таких задач пишут специальные программы, извлекающие необходимую информацию из моделей и переносящие ее в утвержденный шаблон документа (так называемые скрипты).
Упражнение
Разработайте регламент для выбранного вами процесса в наиболее эффективном с вашей точки зрения и для вашей ситуации формате. При разработке учтите рекомендации параграфов 1.5.4 и 1.5.5.
1.5.7. Структура процессного регламента
Далее приведена типовая структура текстового процессного регламента. Надо сказать, что излишнее увлечение вопросами формы – признак тревожный. Как забывчивость намекает на склероз, так и фанатизм по поводу структуры – на бюрократизм ☺.
Титульный лист (лист с логотипом или еще какая-то красота):
• шапка «Утверждаю» и дата;
• название (и шифр/номер, если принято в компании) регламента;
• списки участвовавших (согласовано, разработчик/исполнитель);
• списки ответственных лиц – Владелец процесса и Владелец регламента. Тут следует отметить, что Владелец процесса – первый кандидат на роль Владельца регламента его собственного процесса. Иногда может делегировать эту функцию кому-то из своих сотрудников (участнику этого процесса). Но это не снимает с Владельца процесса ответственности за регламент.
Лист версий (встречается нечасто). Правда, ценности в нем не вижу, так как в регламентной базе должны храниться только актуальные документы, все предыдущие версии должны со штампом «Недействителен» (как бумажным, так и электронным) попадать в архив.
Общие положения:
• цель/назначение документа – что за документ, для чего разработан. Например, процессный регламент, регулирует взаимодействие подразделений в основном процессе О3. Продажи, соответствует третьему уровню детализации (и ссылка на модели ЕРС – источник информации);
• область и условия применения – для кого предназначен данный регламент, действия каких подразделений и должностных лиц в нем регламентируются. Здесь могут быть ссылки на другие нормативные документы организации, например описывающие особые ситуации, исключенные из этого регламента (допустим, тендерные процедуры). Важно категорически исключить повторное описание одного и того же! Кроме того, тут обозначаются условия, при которых документ действует или не действует (при наличии таковых).
Глоссарий: термины и сокращения – обычно определения и расшифровки списком или в табличной форме в алфавитном порядке.
Основной текст регламента – кто и когда (например, специалист по оплате труда, еженедельно в пятницу до 18:00) что делает. Что используется в качестве входных документов (например), что на выходе. В какой ИС выполняется функция и т. д. Таким образом шаг за шагом описывается весь процесс. Как было указано раньше, текст этой части должен быть оптимально детализирован и не превышать пяти страниц. Этот раздел пишется на основе модели процесса.
Порядок внесения изменений в регламент. Если в компании есть общий порядок, описанный, например, в Положении о регламентной базе или Положении о документообороте, то этот раздел лишний.
Лист ознакомления с регламентом.
Контрольные процедуры и ответственность. Этот раздел вводится, если лицо, ответственное за контроль исполнения регламента, не совпадает с ВП или Владельцем регламента и/или ответственность за нарушение норм регламента не носит общий характер, описанный в других нормативных документах (например, в Положении о регламентной базе). Тогда указывается контролер исполнения регламента, описываются его действия при обнаружении нарушений регламента и ответственность нарушителей.
• Приложения. Обычно в виде приложений оформляются модель процесса, шаблоны используемых в процессе документов и прочие объемные формы (таблицы, схемы, диаграммы, расчеты и т. п.).
Язык регламента, как я уже писал, должен быть простым (прямой порядок слов, короткие предложения) и экономным (ни одного лишнего слова). Всевозможные перечисления оформляются как перечни или выносятся в приложения. Все термины расшифровываются и поясняются в глоссарии. Для одного объекта используется один термин (без синонимов!). Во время применения регламента его Владелец должен вылавливать ситуации неоднозначной или неверной трактовки текста и вносить коррективы, которые позволили бы избежать этого в будущем.
Упражнение
Нуждается ли разработанный вами после параграфа 1.5.6 регламент в доработке с учетом рекомендаций параграфа 1.5.7? Если да, доработайте его.
1.5.8. Поддержание регламентов в актуальном состоянии
Главная проблема заключается не в том, чтобы создать регламент, а в том, чтобы научиться его поддерживать в актуальном состоянии. Для этого организация должна иметь специальный процесс, результатом которого является актуальная регламентная база (РБ).
Отсутствие такого процесса приводит к тому, что привычным состоянием дел является такое, когда как минимум некоторые регламенты устарели и по негласному внутреннему соглашению выполняться не должны. А раз так, то у сотрудников нет обязанности выполнять какие бы то ни было регламенты. Ведь список «настоящих» отсутствует, а значит, можно самому решать, как именно действовать. И менеджмент компании теряет регламенты как инструмент управления. Все это цена неумения поддерживать их в актуальном состоянии. Этот вопрос настолько важен, что по разным поводам я в каждой из книг процессной трилогии приводил модель процесса «Управление регламентной базой».
Между тем ничего особо хитрого в этой технологии нет. Рассмотрим в качестве примера процесс, изображенный на рис. 10. Верхняя цепочка процедур описывает процесс создания и внедрения регламента (от инициирования разработки до внесения в РБ и доведения до участников процесса). Этим процессом владеют практически все предприятия. А не хватает им двух фрагментов процесса, показанных ниже, – мониторинга исполнения и актуальности регламентных документов (РД) с последующими действиями, выполняемыми при необходимости: корректировкой или отменой/упразднением и выводом документа из РБ. Кроме того, полезно время от времени проводить инвентаризацию РБ, которая помогает устранить прорехи в процедуре мониторинга.
Рис. 10. Пример процесса «Управление регламентной базой» (укрупненно)
Самой важной в рассматриваемом процессе является процедура «Мониторинг исполнения и актуальности РД РБ». Именно она позволяет организации постоянно иметь базу актуальных регламентных документов. На рис. 11 показан пример такой процедуры. Как видно из модели, мониторинг осуществляется по нескольким веткам: Владельцы процессов обязаны вести его в постоянном режиме, есть ежегодная процедура проверки, проводимая руководителем Управления документооборота, осуществляется постоянная работа с «рацпредложениями» сотрудников, кроме того, регламенты подлежат контролю при реализации любых изменений в опасных областях (оргструктура, проекты ИТ). Ну и реализуется выборочный контроль нижнего уровня (опрос участников процессов). В целом эта эшелонированная процедура призвана не пропустить назревшие корректировки документов.
Упражнение
Разработайте процесс «Управление регламентной базой» для вашей организации на уровне VAD2 и EPC3 (см. примеры на рис. 10 и 11).
Рис. 11. Пример процедуры «Мониторинг исполнения и актуальности РД РБ»