Чем регламент отличается от должностной инструкции и положения: разбираем на примерах
В логистической компании бизнес-аналитик получил задачу: «Опиши процесс согласования заявок на закупку». Через три дня он принёс готовый документ и назвал его должностной инструкцией закупщика. Руководитель вернул документ: «Ты описал процесс — это регламент, а не ДИ». Оба были по-своему правы: документ действительно получился хорошим, но попал не в ту категорию. И это не формальность — от правильной классификации зависит, кто подписывает документ, кто его обновляет и как он применяется в спорных ситуациях.
Три документа — три разных вопроса
Каждый тип документа отвечает на свой вопрос. Путаница возникает потому, что все три так или иначе «про работу» — но про разные её срезы. Вот простая точка разграничения:
- Положение отвечает на вопрос: «Зачем существует эта единица и кому она подчиняется?» — описывает структуру, подчинённость, задачи и функции подразделения или органа. Это документ про статус.
- Регламент отвечает на вопрос: «Как устроен этот процесс от начала до конца?» — описывает последовательность действий, роли участников, сроки и точки передачи результата. Это документ про взаимодействие.
- Должностная инструкция отвечает на вопрос: «Что именно делает этот конкретный человек?» — описывает функции, права, ответственность и ЦКП (целевой конечный продукт) одной роли. Это документ про человека.
Связь между ними прямая: положение создаёт структурный контекст, регламент описывает, как в этой структуре движется работа, а должностная инструкция фиксирует вклад каждого участника в эту работу. Аналитик бизнес-процессов работает прежде всего с регламентом — и именно из него вытекают ДИ.
Кейс: один процесс — три документа
Возьмём конкретную ситуацию: производственное предприятие, процесс обработки рекламации от клиента. В нём участвуют менеджер по работе с клиентами, инженер качества и руководитель производства.
Клиент пришёл с жалобой, и обнаружилось, что ни один из трёх сотрудников не знал, кто именно должен ответить в первую очередь и что передать следующему. Документы в компании были, но описывали каждого отдельно — без связки. Ошибка заказчика: отдел кадров написал три ДИ, описав функции каждой роли изолированно, не зафиксировав процесс взаимодействия между ними.
Аналитик бизнес-процессов начал с доски в Miro: нарисовал Flowchart всего процесса — кто получает рекламацию, кому передаёт, в какой срок, с каким результатом. Из этой схемы родились три документа: регламент обработки рекламаций (описывает весь поток), обновлённые фрагменты ДИ каждого участника (описывают их шаги в процессе) и корректировка положения об отделе качества (где теперь явно прописана функция рассмотрения претензий). Три разных документа, один источник — модель процесса.
Сравнение по ключевым параметрам
| Параметр | Положение | Регламент | Должностная инструкция |
|---|---|---|---|
| Отвечает на вопрос | Зачем? Кому подчиняется? | Как устроен процесс? | Что делает этот сотрудник? |
| Объект описания | Подразделение, орган, служба | Процесс с участием нескольких ролей | Одна конкретная должность |
| Количество участников | Не указывается | Несколько — из разных подразделений | Один |
| Раздел «Взаимодействие» | Возможен — с другими службами | Основа документа | Не включается (только в регламент) |
| Кто утверждает | Директор или собственник | Директор или уполномоченный зам | Директор (гриф или приказ) |
| Когда обновляется | При реорганизации структуры | При изменении процесса | При изменении функций должности |
| Инструмент разработки | Текстовый документ, структурная схема | Flowchart, схема в Miro | Текстовый документ на основе модели процесса |
Типичные ошибки при работе с этими документами
- В ДИ прописывают взаимодействие. Раздел «Взаимодействие с другими подразделениями» — это элемент регламента, не должностной инструкции. Когда он попадает в ДИ, документ начинает дублировать регламент, а при изменении процесса требует двойного обновления.
- Регламент пишут без схемы процесса. Текстовый регламент без Flowchart — почти всегда неполный: в нём нет визуальной точки передачи результата, и участники по-разному интерпретируют, кто что делает. Схема в Miro или на любой онлайн-доске — это не украшение, а основа документа.
- Положение и регламент смешивают в один документ. «Положение об отделе закупок» иногда содержит пошаговое описание процесса согласования заявок. Это перегружает документ и делает его неудобным для обновления: изменился процесс — надо переписывать всё положение.
- ДИ создаётся без опоры на регламент. Если сначала писать ДИ, а потом пытаться «собрать» из них регламент — ничего не сойдётся. Правильная последовательность обратная: сначала модель процесса и регламент, потом из него вычленяются роли и формируются ДИ.
Как применять это прямо сейчас
Возьмите любой конфликт или «провис» в работе своей компании за последние месяц-два — ситуацию, когда задача не была выполнена и никто не считал её своей. Задайте два вопроса: «Этот сбой произошёл внутри одной роли или на стыке нескольких?» Если на стыке — нужен регламент. Если внутри одной роли — достаточно уточнить ДИ.
Умение разграничить эти документы и выбрать нужный инструмент под конкретную ситуацию — один из базовых навыков бизнес-аналитика и аналитика бизнес-процессов. Строить такие модели практически, на реальных процессах своей компании, учат на практическом курсе по оптимизации бизнес-процессов.
