Как сделать регламент бизнес процесса, который будет работать

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

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

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

Простота восприятия

Чем проще документ, тем проще с ним работать. Это не означает, что документ нужно “порезать” вдоль и поперек. Нет. Но когда описание процедуры представляет из себя 70 страниц убористого текста (а мне довелось видеть такие примеры), работать с этим невозможно. Его просто никто не дочитает до конца.

Регламент бизнес процесса должен быть написан простым языком

Документ, написанный простым языком, легко читается и воспринимается. Регламент НЕ должен быть похож на заключение судмедэксперта или американского юриста. Чем проще прочитать и воспринять текст, тем больше полезной информации дойдет и осядет в головах сотрудников. Не надо писать “во избежание получения травм на производстве остерегайтесь подносить руки к работающему станку”. Можно сказать проще и действеннее – сунешь руку, оторвет пальцы. Проще. Меньше слов. А главное, все сразу понятно.

Избегайте “корявых” формулировок

Никакой воды

Пожалуйста, не пишите текст ради текста. Уберите всю “воду”. Давайте честно – никто не читает в документах разделы “Общие положения”, “Область действия” и “Назначение документа”. Кроме того, очень часто эти разделы в разных документах абсолютно идентичны. Сделайте лучше отдельный документ под названием “Положение о регламентах” и дайте на него ссылку в документах. Если кому-то эта информация понадобится, он ее найдет и прочитает. То же касается всех “одинаковых” разделов. Сделайте их отдельными документами и ссылайтесь там, где это необходимо. Чем меньше воды, тем более “рабочим” становится регламент бизнес процесса.

Избегайте текста там, где это можно сделать

Графические модели бизнес процессов, схемы, иллюстрации и фотографии – все это должно быть в регламенте. С чего вы взяли, что регламент бизнес процесса – это скучный и формальный документ? Вовсе нет. Это документ, который должен быть эффективен в использовании. Тогда он работает. А графика воспринимается быстрее и глубже текста. Именно поэтому хорошо подготовленная модель бизнес процесса может полностью заменить собой регламент. Моделируйте процессы и используйте модели в качестве регламентов.

Простая структура – простая работа с документом

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

Не делайте так!

Форма и содержание регламента должно быть согласовано между заинтересованными сторонами

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

… разные точки зрения на бизнес процесс

Точки зрения в бизнес процессах – это очень важная составляющая. У владельца процесса одна точка зрения. У исполнителя другая. А у менеджера третья. Точка зрения – это то, как участник смотрит на процесс. Это тот набор и форма подачи информации, которая нужна и удобна ему для работы. Поэтому регламент бизнес процесса должен быть составлен таким образом, чтобы удовлетворять точки зрения всех заинтересованных сторон. Есть, конечно, вопрос удобства использования – идеально, когда регламент представляет из себя электронный документ с возможностью отображения разных точек зрения. Это позволяет тем или иным заинтересованным сторонам “очистить” то, что они читают, от ненужной для них информации. Это высший пилотаж. Но так нужно делать. К примеру, мы в нашей компании именно так и делаем.

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

Простота использования

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

Регламент бизнес процесса должен быть под рукой

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

Регламенты должны существовать в электронном виде

Логическое продолжение предыдущего пункта. Если у сотрудника “где-то там на полке” лежит стопка документов, то это равнозначно их отсутствию. Ну не будет человек искать в кипе бумаг то, что ему нужно. Кроме того, сама работа с бумажными документами весьма трудоемка. Бумажные документы ограничены в функциональности. Очень тяжело работать с схемами процессов на бумаге, перемещаться между уровнями описания и менять точки зрения модели. Все регламенты должны существовать в электронном виде и лучше всего, если в специальной системе, которая позволяет обеспечить удобство поиска и работы с документом.

Часть электронного регламента бизнес процесса “Закупка”

Используйте специализированное ПО или сервисы для управления регламентами

Кто сказал, что регламент не может выглядеть как интернет- страница? Это очень удобно. Регламент может быть создан на движке Wiki, сделан в виде внутреннего сайта или базироваться на специальных сервисах. Таким сервисом может быть, к примеру, Confluence от компании Atlassian. У электронных документов есть множество преимуществ, большинство из них связано с удобством поиска, наличием перекрестных ссылок и возможностью масштабировать данные для изучения. Поверьте, перенос регламентов бизнес процессов в электронную систему может стать самым важным шагом на пути к эффективности.

Удобный поиск и взаимосвязи документов

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

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

Простота использования в достаточности

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

Актуальность

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

Регламент бизнес процесса работает только тогда, когда актуален

Вот очевидно же. Но нет. Я часто наблюдаю обратную ситуацию – существует множество версий документов и никто не знает, какая версия актуальная. Иногда присылают последнюю версию документа, а через какое-то время “самую актуальную” версию. Регламент бизнес процесса и информация в нем должны соответствовать реальной жизни. Вот как в жизни выполняется процесс, так он и должен быть описан в регламенте. Это, кстати, еще одна из причин, по которой регламент должен быть написан простым языком. За ширмой формальных формулировок часто скрывают реальные действия.

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

Актуализируйте системно, а не “как попало”

Регламент бизнес процесса должен быть актуализирован в двух случаях: изменился процесс, пришла пора актуализировать документ. У каждого документа есть жизненный цикл, который предполагает периодический пересмотр документа. Это означает, что у каждого регламента должен быть период, в течение которого нужно поднимать документ и проверять на соответствие действительности. Регламенты разных процессов требуют разной периодичности пересмотра. Это может быть несколько лет или несколько недель. Зависит от “оборачиваемости” процесса. За актуализацию регламентов должен отвечать владелец процесса. Информация о том, с какой частотой должна производится актуализация, должна быть заложена в регламент. И да, должен быть график актуализации.

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

История изменений – обязательная составляющая регламента

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

У сотрудников не должно быть доступа к “старым” версиям документов

Знаете, как минимизировать ошибки? Исключить вероятность их возникновения. Если у сотрудников не будет доступа к старым версиям документов, они не допустят ошибку на основании “ну я же не знаю, где написано правильно”. Любой документ, с которым работает сотрудник, должен быть только последней версии. Все предыдущие версии должны просто изыматься. Это, кстати, позволяет убрать один из вариантов ухода от ответственности, связанный с вышеуказанным высказыванием.

У процесса и регламента бизнес процесса должен быть один владелец

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

Согласованность

Только то, что создано совместно, совместно будет принято.

Привлекайте все слои заинтересованных лиц для создания регламентов

Под слоями я понимаю разные уровни иерархии компании. Пусть в создании регламента бизнес процесса примет участие не только менеджмент бизнес процесса, но и линейные сотрудники. В конце концов, принятие участия в разработке – это один из способов снижения сопротивления. Если человек принимал в чем-то участие, то он будет сопротивляться итоговому результату в меньшей степени.
Также важно, чтобы все понимали: регламент – это рабочий документ. И всем с ним дальше работать. Так что его нужно делать «как для себя». А еще точнее, для себя в том числе. Такой процесс создания не прост. Будет много споров и «поправок», но итоговый результат будет того стоить. Главное, чтобы работа велась на равных. Чтобы менеджмент не давил авторитетом и давал всем сотрудникам высказаться и внести свои предложения.

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

Регламент бизнес процесса должен быть согласован заинтересованными сторонами

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

Презентация регламента

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

Информирование об изменениях в существующих регламентах – кропотливый, но самый важный труд

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

Информирование сотрудников должно происходить на основании матрицы ролей

Матрица ролей – инструмент, который позволяет не только контролировать и распределять ответственность за бизнес процесс, но также определять и вовлекать в работу заинтересованные стороны. Качественно проработанная матрица позволяет легко понять – кто и в какой информации о процессе или его изменении заинтересован. Вот, кстати, еще одна причина использовать специализированные сервисы – в них можно настроить автоматическое уведомление об изменениях на основании ролей.
Используйте матрицу RACI, в которой:
– R (Responsible) – роль, которая непосредственно несет ответственность за выполнение бизнес процесса.
– A (Accountable) – роль, которая принимает решения относительно хода или результатов процесса.
– C (Consult) – роль, которая оказывает то или иное влияние на процесс. Чаще всего к данной роли относятся «поставщики» процесса.
– I (Inform) – роль, которая должна быть проинформирована о ходе / результате процесса. Как правило, это клиенты процесса.

Матрица RACI – отличный инструмент распределения ролей

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

Нужно удостовериться в том, что регламент бизнес процесса прочитан и понят

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

Вместо резюме. Регламент бизнес процесса должен отражать реальное выполнение процесса, и с ним нужно работать. Измените восприятие сотрудников и объясните, что это рабочий документ, а не очередная «важная» бумажка. Сделайте регламент удобным и понятным. Всегда держите документацию актуальной и изымайте устаревшее. Используйте электронные сервисы и документы.
Помните – есть дизайн, а есть пользовательский опыт. Последний может дать ответы на многие вопросы.

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

структура, основы, цели, методы, оптимизация

Отвечает Дмитрий Бочаров.

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

2. Сформировав матрицу ответственности, переходят на уровень управления документами. Организационно-распорядительная документация во многом регламентируется законодательными актами, но и внутренние регламенты могут определять еще массу местных специфических документов.

3. Далее возможны варианты: инициатива сверху или снизу. Педант продумает все заранее, приобретет необходимое оборудование и софт, а затем будет строго спрашивать. Но не всегда у руководства в такой момент появляется понимание кем, как и что будет делаться на практике. Иногда компетенций руководства недостаточно для определения способов выполнения задач. Порой начальство говорит: «Давай ввяжемся в драку, а там посмотрим». Со временем формируется некоторая практика, когда исполнитель начинает задумываться, как бы упростить задачи или автоматизировать их.

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

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

5. Для моделирования бизнес-процессов применяется специализированное программное обеспечение. От бесплатных онлайн-сервисов до внутрисетевых решений от гигантов индустрии.

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

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

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

А структура инструмента зависит от структуры управления. Конечно, можно просто принять содержание и структуру “по умолчанию”, но тогда это будет уже из разряда:

Хорошо быть девочкой в розовом манто. Можно и не в розовом, но уже не то.

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

• Принятые в компании носители документов – у вас принято работать “с бумагой” или “цифрой”? Спойлер – настоятельно рекомендую использовать электронные версии регламентов.
• Процессы согласования, изменения и управления регламентами.
• Степень зрелости бизнес процессов.
• Состав и точки зрения заинтересованных сторон на бизнес процесс.
• Требования заинтересованных сторон к регламенту.
• Цели и задачи, которые регламенты выполняют в компании.

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

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

Раздел 1 – Краткое описание

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

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

Все пункты краткого описания обязательны для размещения.

• Название процесса. Несмотря на то, что в регламенте указывается заранее определенное название процесса, все же еще раз напомню. Название процесса должно быть уникальным и отражать его суть. Быть уникальным – это значит, что второго такого названия процесса или функции не существует в вашей компании.
• Сквозной номер процесса. Если у вас используется нумерация процессов, то номер должен быть указан здесь. Если нумерации нет – просто пропустите этот пункт. Как правило, если вы используете информационную систему для управления регламентами, то потребность в нумерации отпадает.
• Тип процесса. К какому типу относится процесс: основной, вспомогательный или процесс управления.
• Цель / назначение процесса. Очень краткое описание того, зачем существует и какие цели преследует бизнес процесс. Описание должно быть таким, чтобы читателю сразу стало понятно, о чем речь.
• Владелец процесса. Имя, должность и структурная организационная единица, к которой относится владелец процесса. Можно сразу указать или дать ссылку на контакты владельца процесса. Информация о должности и принадлежности к организационной единице нужна для того, чтобы читателю было понятно – в чьей со структурной точки зрения зоне ответственности находится данный процесс.
• Основное событие начала. Основное событие, которое стартует выполнение процесса. Событий начала может быть множество, но всегда существует основное – это такое событие, которое инициирует выполнение процесса с наибольшей вероятностью.
• Основной вход. Входов также может быть несколько, но всегда есть что-то самое главное, с чем работает процесс. И да, это может быть целый набор.
• Основной поставщик. Название внутреннего процесса, который поставляет вход в рассматриваемый процесс. Если же вход поступает из внешнего источника, то указываем как есть. Например, Поставщик А или Поставщик конкретного продукта. Либо любое другое название, которое позволит однозначно понять, кто вне компании отвечает за поставку входа в процесс.
• Основное событие окончания. Событие или условие, при выполнении которого мы считаем процесс завершенным. Событий окончания может быть несколько, но, как правило, только одно является основным, потому что только при наступлении этого события, процесс достигает своей цели. Все остальные события окончания являются отклонениями от основного, желаемого сценария и в этом разделе не указываются.
• Основной продукт. Многие процессы производят несколько продуктов. Они могут быть основными (как правило, основной продукт один) и второстепенными. Основной продукт – это то, ради чего существует весь процесс. Ради этого продукта все выполняется.
• Основной клиент. У любого продукта есть клиент. Внутренний или внешний. В кратком описании обязательно указать – кто является клиентом рассматриваемого процесса. Под “кто” я понимаю внутренний процесс, конкретное лицо, организационную единицу или внешнего клиента.

Раздел 2 – Границы процесса

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

Входы

Обязательно

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

Желательно

• Краткое описание входа – иногда бывает полезно дать краткое описание входа.
• Тип поставщика – поставщики бывают внутренними и внешними. Внутренние поставщики могут быть процессами, организационными единицами или системами. Внешний поставщик – сторонняя организация или лицо. Внутренний процесс – в таком случае в поле поставщик должно быть указано название соответствующего процесса. Организационная единица – если процесс неизвестен, но известно, какая орг единица поставляет вход, то указывается название орг единицы. Например, бухгалтерия. Система – вход может поступать из какой-то системы. Например? Это может быть система мониторинга, которая генерирует заявку или сигнал при наступлении определенного события.
• Способ поставки – описание того, как вход попадает в рассматриваемый процесс. Принесли, пришло курьером, голубиной почтой… Все это способы поставки.
• Ответственный за поставку – если на стороне поставщика есть конкретная роль, должность или человек, который несет ответственность за поставку входа, его нужно указать.

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

Обязательно

• Название события. Перечислите все события, стартующие выполнение процесса. Как я уже говорил выше, событий может быть несколько.
• Уведомление о событии. Крайне важно не только понимать, но и описать, как участники процесса узнают о том, что произошло событие, которое начинает процесс. Чтобы увидеть вспышку на солнце, нужно смотреть на солнце, не на землю)

Желательно

• Инициатор события – если событие является следствием другого процесса, порождается одним из внутренних или внешних участников, то это необходимо указать. Например, если событием начала является «Получена заявка клиента», то инициатором будет сам клиент. Если мы говорим о процессе Обработка заявок клиентов. Если же заявка поступает в процесс Сборки заказа, то она может поступать из процесса Обработка заявок клиентов.
• Связанный вход – если вместе с событием поступает вход (а такое, как вы уже знаете, происходит далеко не всегда), то нужно указать, какой вход связан с событием начала. Из вышеуказанного примера: если событием начала является Получена заявки клиента, то связанным входом будет заявка. Этот пример прост и очевиден, но часто все не так просто.

Продукты

Обязательно

• Название продукта – название продукта, который производит процесс.
• Тип продукта. Как я говорил ранее, есть основные и второстепенные продукты. Основной продукт – это то, ради чего существует процесс. Получение основного продукта – это основная задача процесса. Второстепенные продукты – все остальное, что появляется в результате выполнения процесса и используется где-то еще. С этой точки зрения первичная документация, которая появляется в результате процесса продаж, является второстепенным продуктом.
• Клиент – у каждого продукта, основного или второстепенного, должен быть клиент. Если клиента не существует, то процесс не нужен. В регламенте процесса обязательно нужно указать, кто является клиентом каждого продукта.
• Характеристики продукта – перечислите характеристики продуктов процесса, которыми они, продукты, обязательно должны обладать до передачи клиенту. Если вернуться к примеру с первичной документацией, то такими характеристиками могут быть: наличие печати и подписи поставщика, наличие подписи ответственного за прием продукции и так далее. Также к характеристикам можно отнести результат выполнения определенных операций. Например, документ проверен до передачи в бухгалтерию. Регламент процесса не может существовать без описания характеристик продуктов.
• Требования к продукту – требования к продукту задает его клиент. Требования обязательно вносить в регламент процесса. Это позволит в любой момент проверить, насколько процесс обеспечивает выполнение требований к продукту. Список требований также необходимо рассматривать в качестве соглашения между участниками процесса и его клиентами. Соглашение – это договоренность о том, что участники берут на себя обязательства выполнить требования через механизм реализации процесса.

Желательно

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

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

Обязательно

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

Желательно

• Где фиксируется событие. Если событие окончания где-то фиксируется, будь то информационная система, документ, журнал, или просто мелом на  заборе, то совсем не лишним будет это указать в регламенте.
• Связанный продукт. Если вместе с событием окончания связан какой-то продукт процесса, это также желательно указать. Иногда это очевидно, но иногда вовсе нет.
• Что инициирует событие. Очень часто, но не всегда событие окончания одного процесса одновременно является событием начала другого процесса. В таком случае будет правильно указать процесс, который «стартует» благодаря событию окончания рассматриваемого процесса.

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

Это можно сделать с помощью правильного наименования. Если один процесс завершается событием “Отчет Х отправлен”, то связанное событие начала должно называться “Отчет Х получен”.

Раздел 3 – Выполнение процесса

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

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

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

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

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

Обязательно

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

Желательно

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

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

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

Обязательно

• Наименование операции
• Минимальное время выполнения
• Среднее время выполнения
• Максимальное время выполнения

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

Здесь необходимо указать роли всех участников процесса.

Обязательно

• Роль участника
• Количество единиц, необходимых для выполнения процесса. Обратите внимание, это не количество человек, которое участвует в выполнении процесса. Количество единиц – это количество каждой роли, которая нужна для выполнения процесса один раз. Если в процессе обслуживания клиентов есть роль «специалист по продажам», то количество будет 1, если только у вас не принято работать с клиентом сразу двум специалистам. При этом роль “кассир”, которая также может быть в данном процессе, может выполняться тем же человеком, который выполняет роль специалиста по продажам.  Если говорить о процессе монтажа оборудования, в котором задействована целая монтажная бригада, то в таком процессе количество единиц в роли «монтажник» будет явно не 1.

Желательно

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

Матрица “роль-должность”

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

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

Обязательно

• Ресурс – собственно наименование ресурса, который используется в процессе.
• Учетная единица – килограммы, штуки, метры, борзые щенки и так далее.
• Количество на процесс (норматив) – принятое количество, которое используется или расходуется в процессе.
• Источник / где взять – где сотрудник может взять этот ресурс, если это необходимо.

Желательно

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

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

Документы процесса

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

• Все управляющие документы: регламенты, положения, описание процедур и правил, скрипты, приказы и так далее. Законодательные и нормативные акты также относятся к управляющей документации.
• Пользовательские инструкции, базы знаний, статьи wiki и так далее.
• Первичная бухгалтерская документация.
• Стандартизированные или принятие в компании формы документов, которые используются в процессе.
• Техническая и технологическая документация.
• Отчеты
• Договоры
• Прочие документы, которые используются, появляются в процессе или оказывают влияние на него.

Обязательно

• Наименование документа
• Дата выпуска документа – дата вступления в силу
• Ссылка на документ – как правило, нет смысла прикладывать все документы к регламенту и можно просто дать ссылку на документ в электронном виде или указать, где его можно найти.

Желательно

• Номер версии – если документ имеет версионность, то можно указать номер актуальной версии.
• Ответственный за актуализацию – конкретный сотрудник или организационная единица, которая несет ответственность за то, чтобы документ существовал в актуальном состоянии. Если такого человека нет (что, как вы сами понимаете, не очень хорошо), нужно указать человека, который в состоянии ответить на вопрос относительно актуальности документа.
• Тип документа – внутренняя типология документов помогает структурировать всю документацию. Типология может быть основана как непосредственно на типе документа (приказ, положение, регламент и т.д), так и, например, на источнике документа, типе источника (внутренний / внешний) и так далее.

Примечание – документы, которые относятся к входам и продуктам процесса, указываются в соответствующем разделе. Дублировать информацию в этом разделе не нужно.

Всегда старайтесь избегать дублирования.

Если что-то находится в одном разделе, нежелательно, чтобы это же относилось и к другим разделам.

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

Раздел 4 – Управление процессом

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

Матрица ответственности

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

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

В такой матрице основным принципом построения является отношение участников процесса к управленческому циклу, а точнее, к его расширенному варианту:

• Планирование
• Организация
• Выполнение
• Контроль
• Улучшение / изменение

Один и тот же участник не может выполнять операцию и контролировать ее выполнение!

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

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

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

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

Матрица ответственности выполнения подпроцессов / этапов процесса.

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

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

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

Матрица ответственности за выполнение процесса

Матрица ответственности – это не обязательная, но весьма полезная составляющая регламента процесса.

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

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

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

Ключевые требования

Существует 2 основных типа требований: требования к продуктам процесса и к ходу его выполнения. В некоторых отраслях имеет смысл дополнительно выделять тип требований, исходящих от регулирующих и контролирующих органов.

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

Все поля обязательно указывать

• Требование – краткое наименование требования
• Тип требования – к чему относится требование: продукт, ход процесса и т.д.
• Описание – описание требования, достаточное для понимания того, что имеется в виду и как это выражается в процессе
• Источник требования – внешний или внутренний источник требования. Внутренним источником, как правило, является или какой-то документ (например, приказ), или некое заинтересованное лицо. Чаще всего таким лицом является владелец другого процесса. Внешние требования тоже часто закреплены в документах, однако некоторые требования могут существовать в виде договоренностей с внешними сторонами. Это ни в коем случае не исключает требование из списка. Более того, порой соблюдение таких договоренностей может иметь даже большее значение.
• Механизм обеспечения – поле, которое не всегда используется, но может иметь существенное значение. Каждое требование должно выполняться через сам процесс. Это значит, что процесс должен быть выстроен таким образом, чтобы требование гарантированно выполнялось. Иногда имеет смысл дополнительно объяснить, через какие действия в процессе обеспечивается выполнение требования.

Показатели бизнес процесса

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

Обязательно

• Показатель – наименование показателя
• Формула расчета – формула, по которой рассчитывается данный показатель
• Где фиксируется – необходимо указать, в какой системе или документе происходит запись показателя.
• Способ фиксации – существует два способа: вручную или автоматически. Да, если показатели не фиксируются автоматически в некой системе, это вовсе не повод отказываться от его фиксации и дальнейшего анализа. Просто это придется делать руками.
• Стандартный диапазон значений – диапазон значений, который принят в качестве стандартного для данного показателя. Можно указывать диапазон в виде «от… до …», но я бы рекомендовал использовать 3 варианта значений: минимальное, среднее и максимальное.

Желательно

• Краткое описание показателя – наименование показателя не всегда отражает его суть, поэтому может быть полезным объяснить, что отражает показатель.
• Тип показателя. Есть 3 основных типа показателя процесса:
  • • Показатели хода процесса – время выполнения процесса, стоимость процесса и так далее.
    • Показатели продукта процесса – показатели, которые отражают характеристики продуктов процессов. Например, количество изделий, которые выпускает процесс за один подход.
    • Клиентские показатели. Фактически это показатели удовлетворенности клиентов процесса. Например, количество не принятых клиентом изделий.
• Источник данных – указание источника данных позволяет убрать вопросы, связанные с релевантностью исходных данных. Кроме того, некоторые показатели могут выводиться на основании нестрогих методов анализа. В таком случае особенно важно объяснить источник.
• Действия при отклонении – при правильной организации процессного управления существует специальный процесс, который запускается в случае возникновения отклонения для любого процесса. Но в определённых случаях в процессе могут существовать специальные процедуры и мероприятия для таких случаев. Если такие есть, то укажите их здесь.
• Периодичность мониторинга – с какой частотой человек, который несет ответственность за контроль показателя, наблюдает за ним и производит анализ.
• Ответственный за мониторинг – собственно это тот, кто отвечает за наблюдение за показателем.
• Представление для анализа – где можно ознакомиться с показателем. Это может быть система, специфическая выгрузка из системы, отчет или какой-то иной документ.

Приложения

• Связанные документы и нормативные ссылки. Когда регламент выполняет в том числе формальную функцию, может быть, необходимо указать связь регламента с внутренними и внешними документами, а также дать нормативные ссылки. Необязательный пункт.
• Ревизия процесса. Указывается дата ревизии, кто провел и что в итоге: были внесены изменения или нет. Под ревизией имеется в виду, что кто-то посмотрел, как работает процесс и соответствует ли реальная жизнь тому, что написано в регламенте.
• Перечень изменений. Перечень внесенных в регламент изменений с указанием даты и лица, внесшего изменение.
• Словарь терминов и сокращений – думаю, тут все понятно.
• Условные обозначения. Перечень значений элементов нотации, в которой выполнены модели процессов.
• Формы и образцы документов. Если вы решили, что регламент должен включать в себя образцы и формы документов, то лучше всего это сделать в виде приложения.

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

Чаще всего можно увидеть регламент процесса, в котором общие положения вынесены в начало документа. Да ладно! Вот скажите, кто-нибудь реально это читает? Нет? Ну а раз нет, значит, это не нужно. Почти.

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

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

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

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

1. Регламент процесса должен быть понятен. Это значит, что если понятия и термины, которые используются в регламенте, могут быть непонятны в вашей компании, используйте свои. Упрощайте язык. Пусть будут не входы, а “то, что нужно для начала процесса”. Пусть будет не продукт процесса, а “результат”. Пусть будет не событие начала, а “старт” или “условие начала”. А так далее.
2. Вводите термины и определения постепенно. Нужно время, чтобы новые термины прижились.
3. Согласовывайте регламент по мере его разработки. Вовлекайте заинтересованные стороны в его создание. Сопричастность позволяет снизить уровень сопротивления.
4. Используйте информационные системы! Уходите от бумажных регламентов!

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

О том, как заставить регламент работать, можно прочитать здесь.

Подписывайтесь на нашу новостную рассылку, чтобы не пропустить новые статьи.

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

Глоссарий. Регламент процесса

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

Статья из Википедии:

Регламент — (от франц. reglement, от regle — правило).

1. Правила, устанавливающие, регулирующие порядок и время проведения мероприятий и действий, осуществления деятельности, ограничивающие их определенными пределами. Например, регламент проведения собраний, совещаний, конференций. Установление и контроль за соблюдением таких правил называется регламентацией;
2. Название некоторых актов международных конгрессов и конференций.

Регламент процесса (Регламент бизнес-процесса) — это один из видов документов, которые разрабатываются в процессе проектирования системы управления предприятием. Регламент говорит о последовательности выполнения работ, их очередности и результатах отдельных блоков работ. Часто регламент процесса также отвечает на вопрос КАК выполнять отдельные работы, т.е. содержит методическую информацию.

При регламентации деятельности помимо собственно регламентов, подготавливаются:

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

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

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

Система бизнес-моделирования Business Studio является удобным инструментом для осуществления регламентации бизнес-процессов, поскольку позволяет автоматически формировать регламенты бизнес-процессов по разработанной модели системы управления компании.

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

Опыт построения организационного управления в ритейле (Процессный офис в ритейле)

Методика «Проектирование системы управления»

Business Studio, нотация «Процедура»: границы процессов, события, стрелки

Разработка технологического паспорта рабочего места при описании бизнес-процессов на платформе Business Studio