Регламент бизнес-процесса описывает, кто, что, в какой последовательности и к какому сроку делает в процессе, и как поступать в нестандартных ситуациях. По хорошему регламенту новый сотрудник может выполнить свою часть работы без устных пояснений, а участники из разных отделов одинаково понимают, кому и когда передавать результат.
Что такое регламент бизнес-процесса
Назначение документа
Возьмем согласование заявки на закупку. Сотрудник подает заявку, специалист по закупкам проверяет ее, финансовый отдел подтверждает бюджет, руководитель принимает решение. Если правила существуют только в головах, каждый действует по-своему: одни заявки согласуют за день, другие возвращают из-за поля, о котором инициатор не знал.
Регламент фиксирует эти правила письменно: какие роли участвуют, какие шаги в каком порядке выполняются, какие сроки установлены и что делать при отказе, возврате или отсутствии согласующего. Документ нужен, чтобы процесс шел одинаково при любом составе исполнителей.
Отличие от инструкции и схемы
Инструкция обычно описывает действия одного сотрудника: как заполнить форму, как провести проверку. Схема процесса показывает порядок шагов и развилки. Регламент объединяет правила всего процесса: участников, порядок, сроки, исключения и ответственность. Он может включать схему и ссылаться на инструкции.
В разных компаниях эти термины используют по-разному. Где-то регламентом называют должностную инструкцию, где-то положение об отделе. Важнее договориться о содержании документа, чем о его названии.
Когда нужен регламент
Повторяющаяся работа и передача между отделами
Регламент нужен, если появляются признаки:
- одну и ту же работу разные сотрудники делают по разным правилам;
- непонятно, кто отвечает за шаг, особенно на стыке отделов;
- заявки часто возвращают на доработку из-за одних и тех же ошибок;
- новые сотрудники долго осваивают процесс и учатся на ошибках;
- процесс планируют автоматизировать.
Больше всего пользы регламент приносит в сквозных бизнес-процессах, которые проходят через несколько подразделений.
Когда не стоит усложнять документ
Для простого действия, которое выполняет один человек, хватит короткой инструкции. Объем регламента зависит от сложности процесса. Заполнять все разделы шаблона ради объема не нужно: пустые формальные разделы только мешают найти нужное правило.
Что включить в регламент бизнес-процесса
Цель, границы и результат
В первой части указывают, зачем нужен процесс и где он начинается и заканчивается:
- событие запуска: что запускает процесс;
- условия завершения: когда процесс считается выполненным;
- получатель результата: кто его получает и в каком виде;
- входные данные и связанные документы: формы, шаблоны, другие регламенты.
Если в компании есть карта бизнес-процессов, в регламенте указывают место процесса на ней: какой процесс передает сюда работу и куда уходит результат.
Участники, действия и сроки
Основная часть описывает работу по шагам. Для каждого шага указывают роль ответственного (именно роль, без фамилии, чтобы документ не устаревал при смене сотрудников), действие, срок или правило его определения и обязательные проверки.
Исключения и контроль
Отдельно описывают нестандартные ситуации: отказ, возврат на доработку, неполные данные, отсутствие сотрудника и замещение, эскалацию при просрочке. В конце указывают показатели процесса, владельца документа, номер версии и дату вступления в силу.
| Раздел | Вопрос | Что указать | Короткий учебный пример |
|---|---|---|---|
| Цель | Зачем нужен процесс? | Результат для получателя | Закупка согласована и передана на исполнение |
| Границы | Где начало и конец? | Событие запуска и условие завершения | От подачи заявки до передачи в отдел закупок |
| Участники | Кто участвует? | Роли и их ответственность | Инициатор, специалист по закупкам, финансовый контролер, руководитель |
| Шаги и сроки | Что и когда делается? | Порядок действий, сроки, входы и выходы | Проверка заявки за 1 рабочий день |
| Исключения | Что делать, если что-то пошло не так? | Отказ, возврат, замещение, эскалация | При отсутствии руководителя решение принимает заместитель |
| Контроль | Как понять, что процесс работает? | Показатели и порядок их проверки | Доля заявок, по которым решение принято за 7 рабочих дней |
| Управление документом | Кто отвечает за актуальность? | Владелец, версия, дата, место хранения | Владелец: финансовый директор, версия 1.2 |
Как разработать регламент по шагам
Разобрать реальную работу
Начните с того, как процесс идет сейчас. Поговорите с участниками каждого шага, разберите вместе с ними 5-10 реальных случаев, соберите действующие инструкции и список проблем. Регламент, написанный по рассказу руководителя без участия исполнителей, часто описывает идеальный процесс, который не совпадает с работой.
Согласовать последовательность и ответственность
Постройте простую схему процесса: шаги, развилки, участники. Для схем удобна нотация BPMN 2.0, но подойдет и блок-схема с дорожками. Определите условия решений (при какой сумме нужно согласование руководителя) и порядок передачи результатов между участниками.
Написать и проверить текст
Пишите короткими действиями: «Специалист по закупкам проверяет заполнение полей». Используйте одинаковые названия ролей и документов во всем тексте. Давайте ссылки на формы и шаблоны. Готовый текст пройдите вместе с исполнителем, который не участвовал в написании: если он задает вопросы, текст нужно уточнить.
Учебный пример регламента согласования заявки
Паспорт процесса
Все условия и сроки в примере учебные.
- Цель: согласовать закупку в срок и передать ее на исполнение.
- Инициатор: сотрудник любого подразделения.
- Участники: специалист по закупкам, финансовый контролер, руководитель подразделения.
- Старт: инициатор отправил заявку через систему.
- Результат: согласованная заявка передана в отдел закупок или инициатор получил отказ с причиной.
Таблица действий
| Шаг | Роль | Входные данные | Действие | Срок или условие | Результат |
|---|---|---|---|---|---|
| 1. Подача | Инициатор | Потребность, коммерческое предложение поставщика | Заполняет заявку и прикладывает документы | В момент возникновения потребности | Заявка отправлена |
| 2. Проверка | Специалист по закупкам | Заявка с вложениями | Проверяет полноту данных и соответствие правилам закупок | 1 рабочий день | Заявка принята или возвращена |
| 3. Возврат на доработку | Инициатор | Комментарий проверяющего | Дополняет данные и отправляет повторно | 3 рабочих дня, иначе заявка закрывается | Исправленная заявка |
| 4. Согласование бюджета | Финансовый контролер | Принятая заявка | Проверяет наличие бюджета по статье | 2 рабочих дня | Бюджет подтвержден или нет |
| 5. Решение | Руководитель подразделения | Заявка с подтверждением бюджета | Одобряет или отказывает с указанием причины | 2 рабочих дня | Решение по заявке |
| 6. Передача на исполнение | Специалист по закупкам | Одобренная заявка | Передает заявку закупщику своего отдела | 1 рабочий день | Заявка в работе |
| 7. Контроль | Специалист по закупкам | Статусы заявок | Отслеживает просроченные шаги и запускает эскалацию | Ежедневно | Список просрочек и принятые меры |
Нестандартные ситуации
Пример с одним успешным маршрутом мало что проверяет. Основные проблемы процесса обычно возникают в исключениях.
| Ситуация | Правило | Ответственный | Следующий шаг |
|---|---|---|---|
| Неполная заявка | Проверяющий указывает в комментарии, каких данных не хватает | Специалист по закупкам | Возврат инициатору, шаг 3 |
| Отказ в бюджете или решении | Причина отказа обязательна, заявка закрывается | Финансовый контролер или руководитель | Инициатор может подать новую заявку |
| Согласующий отсутствует | Решение принимает назначенный заместитель | Руководитель отсутствующего согласующего назначает заместителя заранее | Шаг продолжается у заместителя без изменения срока |
| Просрочка шага | Через 1 рабочий день после срока вопрос передают руководителю участника | Специалист по закупкам | Руководитель участника решает вопрос или переназначает задачу |
Точно описанные правила процесса можно перенести в систему в виде проверок и ролей. Пример такой системы: в «МБ РУС» в решении для гарантийного обслуживания на BPMSoft настроено около ста правил автоматической проверки заявок, для дилеров и сотрудников «МБ РУС» сделаны отдельные интерфейсы, а для инженеров по гарантии, сервисных консультантов, руководителей и бухгалтеров заданы свои роли.
Как проверить регламент до утверждения
Проверка обычного случая
Возьмите типовую заявку и пройдите ее по документу с сотрудником, который будет работать по регламенту. На каждом шаге он должен понимать, какое действие выполнить, где взять данные и кому передать результат.
Проверка исключений
Затем пройдите нестандартные случаи: отказ, возврат, отсутствие согласующего, просрочку. Документ проходит проверку, если ни один путь не заканчивается тупиком.
Чек-лист приемки документа:
- Цель, событие запуска и результат описаны.
- У каждого шага есть роль ответственного, срок и результат.
- Названия ролей и документов одинаковы во всем тексте.
- Описаны отказ, возврат, замещение и эскалация.
- Есть правило изменения срока, если ситуация нестандартная.
- Все ссылки на формы и документы работают.
- Указаны владелец документа, версия и дата вступления в силу.
- Исполнитель, не участвовавший в написании, прошел документ без вопросов.
Как внедрить регламент в работу
Согласование и обучение
Назначьте владельца регламента. Объясните участникам, что меняется по сравнению с текущей работой, и дайте доступ к актуальной версии. Формальное утверждение само по себе ничего не гарантирует: если сотрудники не знают о документе или он неудобен, процесс продолжит идти по-старому.
Пробный запуск
Проведите по новому регламенту несколько реальных случаев. Соберите замечания участников и исправьте неоднозначные правила. Порядок утверждения зависит от компании: где-то нужен приказ, где-то достаточно решения владельца процесса.
Как поддерживать регламент в актуальном состоянии
Версия и ответственный
За документ отвечает владелец. Он решает, кто вносит изменения, как фиксируется дата вступления новой версии в силу и где хранится актуальный документ. Старые версии лучше сохранять в архиве: они понадобятся при разборе спорных случаев.
Поводы для пересмотра
Регламент пересматривают, когда меняется продукт, структура компании или информационная система, а также когда одни и те же проблемы повторяются. Универсального срока обязательного пересмотра нет. Удобный момент для сверки документа с реальной работой: окончание пробного периода или любое заметное изменение процесса.
Ошибки при подготовке регламента
Неясные действия и роли
- Общие фразы без результата: «обеспечивает контроль качества». Проверка: можно ли понять, что конкретно сделать и как узнать, что сделано.
- Обязанности без полномочий: сотрудник отвечает за срок, но влияния на смежный отдел у него нет. Проверка: есть ли у ответственного способ эскалации.
- Неработающие ссылки на формы и документы. Проверка: пройти по каждой ссылке.
- Несогласованные сроки: суммарный срок шагов больше общего срока процесса. Проверка: сложить сроки шагов.
Документ не совпадает с работой
- Слишком большой текст, в котором нельзя быстро найти правило. Проверка: найдет ли сотрудник ответ на вопрос за минуту.
- Забытые исключения. Проверка: пройти отказ, возврат и отсутствие сотрудника.
- Устаревшая версия в общем доступе. Проверка: совпадает ли дата документа с датой последних изменений процесса.
Как перенести правила процесса в BPMSoft
Что подготовить для автоматизации
Регламент служит хорошей основой для настройки процесса в системе. Для этого из документа берут участников и роли, условия развилок, данные на каждом шаге, сроки и правила решений. В BPM-системе BPMSoft по этим правилам настраивают маршрут заявки, задания участникам, сроки и эскалацию.
Если при настройке выяснилось, что правила регламента противоречат друг другу или не работают, их сначала согласуют с участниками и меняют в документе, затем в системе. Подробнее о том, как связаны документы и управление бизнес-процессами, рассказано в отдельной статье.