Как описать бизнес-процесс обработки внутренних заявок сотрудников: практическое руководство

Внутренние заявки — это запросы сотрудников на IT-поддержку, HR-услуги, закупки, доступы, администрирование и другие корпоративные функции. Хаотичная обработка таких запросов приводит к потере сроков, дублированию работы, недовольству внутренних клиентов и невозможности масштабировать сервис. Описание процесса — первый шаг к прозрачности, измеримости и автоматизации.

Главный принцип: процесс описывают не для отчёта, а чтобы все участники понимали, кто, что, когда и зачем делает. Если после описания у исполнителя остаются вопросы «куда отправить», «кто согласует» или «каков срок» — описание неполное.

Подготовка: что собрать перед моделированием

Не начинайте рисовать схему в вакууме. Сначала зафиксируйте контекст:

• Каталог типов заявок. Перечислите все виды запросов, которые поступают в отдел: инциденты, сервисные запросы, изменения, доступы, расходники, отпуска, обучение, бухгалтерия, правовые вопросы. Для каждого типа укажите: типичный инициатор, ожидаемый результат, нормативный срок.
• Текущие каналы приёма. Email, портал, мессенджеры, устные обращения, бумажные формы. Важно понимать, как заявка попадает в работу сейчас, чтобы не потерять ни один канал при переходе на новый процесс.
• Участники и их роли. Кто регистрирует, кто классифицирует, кто исполняет, кто согласует, кто уведомляет инициатора. Часто одна и та же функция (например, «согласование закупки») выполняют разные люди в зависимости от суммы или категории.
• Существующие регламенты и SLA. Есть ли утверждённые сроки реакции и решения? Есть ли эскалация? Если формальных SLA нет — зафиксируйте де-факто практику как базу для улучшения.
• Интеграции и системы. Где живёт заявка: ServiceNow, Jira Service Management, Bitrix24, 1С, собственная разработка, Excel, почта. Какие системы должны обмениваться данными (AD, HRM, ERP, CRM, CMDB).
• Болевые точки текущего процесса. Опросите 5–10 частых инициаторов и 3–5 исполнителей. Типичные жалобы: «заявка висит неделю», «непонятно, на каком этапе», «потеряли в почте», «согласование уходит не тому руководителю».

Результат подготовки — документ-контекст (1–2 страницы), который станет входными данными для моделирования и защитой от упущений.

Выбор нотации и уровня детализации

Нет единой «правильной» нотации. Выбор зависит от аудитории и целей:

Нотация	Когда уместна	Ограничения
BPMN 2.0	Автоматизация в BPMS, сложные маршруты согласования, параллельные потоки, таймеры, исключения	Требует навыков чтения; избыточна для простых линейных процессов
Блок-схема (flowchart)	Коммуникация с бизнесом, обучение новичков, быстрые эскизы на доске	Слабая семантика для исключений, SLA, ролей; сложно поддерживать в актуальном состоянии
Swimlane (функциональная схема)	Показ ответственности между отделами/ролями, выявление «серых зон» передачи	Не показывает данные, таймеры, условия ветвления так наглядно, как BPMN
User Story Map / Use Case	Проектирование портала самообслуживания, бэклог автоматизации	Не заменяет процессную модель; дополняет её

Практический совет: Начните со swimlane-схемы для согласования с заказчиками процесса (руководителей функций). Затем, если планируется автоматизация, переведите ключевые сценарии в BPMN для технической команды. Держите обе версии синхронизированными.

Ключевые этапы процесса обработки заявки

Универсальный каркас процесса (reference model) для внутренних заявок выглядит так. Каждый этап может разворачиваться в подпроцесс в зависимости от типа заявки.

1. Приём и регистрация. Заявка попадает в единую точку входа (порт, email-бот, API). Система присваивает уникальный номер, фиксирует время создания, инициатора, канал. Автоматически или вручную заполняются обязательные атрибуты: категория, подкатегория, приоритет, SLA-класс.
2. Классификация и маршрутизация. Правила (автоматические или ручные) определяют: тип запроса (инцидент / сервисный запрос / изменение), очередь исполнителя (L1 / L2 / специализированная группа), необходимость согласования. Критически важно: классификация должна быть детерминированной, а не «по интуиции оператора».
3. Согласование (если требуется). Не для всех типов. Примеры: закупка > лимита, доступ к чувствительным данным, отпуск в пиковый период, изменение продакшн-среды. Согласование должно иметь дедлайн, эскалацию и возможность делегирования. Избегайте цепочек из 3+ согласующих — это признак неразработанной политики.
4. Исполнение / выполнение работы. Основной трудоёмкий этап. Включает: диагностику, сбор информации, выполнение действий, координацию с третьими сторонами (вендоры, подрядчики). Здесь важны чек-листы, базы знаний, доступ к CMDB/AD/HRM.
5. Контроль качества и закрытие. Исполнитель ставит статус «На проверке» или «Решено». Инициатор получает уведомление с просьбой подтвердить результат. Автозакрытие через N дней без возражений — стандартная практика (обычно 3–5 рабочих дней). При отказе — возврат на исполнение с комментарием.
6. Пост-обработка. Заполнение базы знаний (если решение типовое), анализ повторяющихся запросов (problem management), расчёт метрик, обратная связь инициатору (CSAT/NPS).

Для каждого этапа определите: входные критерии (Definition of Ready), выходные критерии (Definition of Done), ответственного (RACI), нормативный срок, возможные исключения.

Матрица ответственности (RACI) — не формальность, а рабочий инструмент

RACI для процесса заявок должен быть привязан к типам запросов, а не к процессу в целом. Пример фрагмента для типа «Запрос доступа к системе»:

Этап / Действие	Инициатор	Оператор L1 (Service Desk)	Администратор системы	Руководитель инициатора	Владелец процесса (Process Owner)
Создание заявки в портале	R	I	I	A	I
Проверка полноты данных, классификация	I	R/A	C	I	I
Согласование доступа (если требуется)	I	I	C	R/A	I
Техническое предоставление доступа	I	I	R/A	I	I
Подтверждение работоспособности	R/A	I	C	I	I
Закрытие заявки	I	R (авто)	I	I	A (метрики)

R — Responsible (исполняет), A — Accountable (несёт окончательную ответственность, один на действие), C — Consulted (консультируется до решения), I — Informed (уведомляется после).

Распространённая ошибка: назначать «A» сразу нескольким ролям. Это размывает ответственность. Если согласование нужно от двух сторон — сделайте два отдельных действия согласования, каждое со своим «A».

SLA и метрики: что измерять и зачем

Без SLA процесс не управляем. Минимальный набор метрик для старта:

• First Response Time (FRT) — время до первого осмысленного действия оператора (не авто-ответ). Цель: < 15–30 мин в рабочее время для высокого приоритета.
• Resolution Time / Time to Resolve — время от создания до статуса «Решено/Закрыто». Зависит от типа и приоритета. Пример: инцидент P1 — 4 часа, сервисный запрос «доступ» — 8 рабочих часов, закупка — 3–5 дней.
• SLA Compliance Rate — % заявок, закрытых в срок. Целевой порог: ≥ 90–95% для зрелого процесса.
• Reopen Rate — % заявок, возвращённых инициатором после закрытия. Индикатор качества исполнения. Норма: < 5–10%.
• First Contact Resolution (FCR) — % заявок, решённых на L1 без эскалации. Цель: рост со временем за счёт базы знаний.
• Backlog Aging — количество и возраст открытых заявок старше SLA. Еженедельный разбор — обязательная практика владельца процесса.
• CSAT / NPS инициаторов — опрос после закрытия. Даже простой смайлик даёт тренд.

Важно: SLA должны быть дифференцированы по приоритету (P1–P4) и типу заявки. Единый «3 дня на всё» не работает — он либо невыполним для инцидентов, либо немотивирующ для рутинных запросов.

Типичные ошибки при описании и внедрении

• Описание «как должно быть в идеале», игнорируя реальность. Схема с 5 согласованиями, которых нет в практике, будет саботироваться. Начинайте с «как есть» (as-is), затем проектируйте «как будет» (to-be) с пошаговым переходом.
• Скрытие исключений за фразой «по общему порядку». Исключения (VIP-пользователи, критичные системы, законные требования) составляют 10–20% объёма, но 80% конфликтов. Опишите их явно: отдельные swimlane или подпроцессы с условиями запуска.
• Отсутствие владельца процесса (Process Owner). Никто не отвечает за актуальность схемы, метрики, базу знаний, обучение новичков. Результат — процесс гниёт за 3–6 месяцев.
• Перегрузка атрибутами заявки. 30 обязательных полей на форме создания — гарантия того, что сотрудники будут звонить операторам или заводить «мусорные» заявки. Оставьте 5–7 критичных полей; остальное — по требованию или в подформах.
• Игнорирование канала «подойду к системному администратору лично». Если этот канал работает — он есть в процессе. Либо легализуйте его (быстрая регистрация в портале с телефона), либо дайте альтернативу, которая удобнее.
• Автоматизация незрелого процесса. Перенесение хаоса в Jira/ServiceNow не лечит хаос. Сначала выйдите на стабильные метрики в Excel/Google Sheets/простой доске, потом автоматизируйте.
• Нет механизма обратной связи от инициатора. Если сотрудник не может повлиять на приоритет, добавить информацию или оспорить закрытие — он перестаёт доверять системе.

Инструменты для описания и жизни процесса

Разделите инструменты моделирования и инструменты исполнения.

Моделирование и документация

• Draw.io / diagrams.net — бесплатно, работает в браузере, поддерживает BPMN, swimlane, экспорт в SVG/PDF. Хорош для версионирования через Git или Confluence.
• Lucidchart / Miro — удобны для совместных сессий, есть шаблоны, интеграция с Confluence/Jira. Платные.
• Bizagi Modeler / Camunda Modeler — десктопные BPMN-редакторы с валидацией, экспортом в XML для BPMS. Camunda — бесплатен, Open Source.
• Confluence / Notion / Wiki — для текстовых регламентов, RACI-таблиц, FAQ, версионирования. Схему вставляйте как изображение или embed.

Исполнение (Service Desk / ITSM / ESM)

• Jira Service Management (JSM) — популярный выбор для IT и ESM. Гибкие очереди, SLA, автоматизация, портал, интеграция с Confluence/Slack/Teams. Лицензирование по агентам.
• ServiceNow — энтерпрайз-уровень, мощный CMDB, Flow Designer, Performance Analytics. Дорого, долгая реализация.
• Bitrix24 / Planfix / AmoCRM (в режиме тикет-системы) — для малых и средних компаний, если уже есть лицензии. Ограниченная поддержка SLA и BPMN.
• iTop / GLPI / OTRS / Zammad — Open Source ITSM. Требуют администрирования сервера, но нет лицензионных отчислений.
• Power Automate / Make / n8n + SharePoint Lists / Google Sheets — low-code вариант для простых процессов без полноценной ITSM-системы.

Критерий выбора: зрелость процесса, бюджет, компетенции команды, требования к интеграциям (AD, HRM, ERP, телефония). Не покупайте ServiceNow для 50 заявок в месяц. Не загоняйте 5000 заявок в Google Sheets.

Валидация и внедрение: как не получить «мёртвый документ»

1. Walkthrough с ключевыми ролями. Пройдитесь по схеме с 1–2 представителями каждой роли (оператор L1, админ, руководитель, инициатор). Спросите: «Если завтра приходит такая заявка, что вы сделаете первым действием по этой схеме?». Зафиксируйте расхождения.
2. Пилот на ограниченном наборе типов. Не переводите всё сразу. Выберите 3–5 самых частых типов заявок (например: доступы, расходники, инциденты принтеров, HR-справки). Запустите в тестовой очереди 2–3 недели.
3. Еженедельные ретроспективы пилота. 30 минут: метрики, боли, предложения. Вносите правки в схему и регламент оперативно.
4. Обучение и чек-листы. Краткие памятки (1 страница) для оператора L1: «Как классифицировать», «Как эскалировать», «Чек-лист закрытия». Сложные инструкции — в базу знаний с ссылками из заявки.
5. Коммуникация для инициаторов. Анонс в корп. портале/рассылке: «Что изменилось, где создавать заявку, чему равны новые сроки, куда жаловаться, если не работает».
6. Переход в промышленную эксплуатацию. После пилота — поэтапное включение остальных типов. Назначьте Process Owner с KPI по SLA Compliance и актуальности документации.

Сценарии «если условия такие — действуйте так»

Практический чек-лист готовности описания процесса

Перед подписанием регламента пройдитесь по пунктам. Если хоть один «нет» — дорабатывайте.

• [ ] Для каждого типа заявки определены: категория, приоритет, SLA (FRT и Resolution), очередь исполнителя.
• [ ] Единая точка входа (порт/email/бот) покрывает ≥ 90% входящего трафика.
• [ ] Схема (swimlane/BPMN) показывает все этапы, решения, таймеры, эскалации, циклы возврата.
• [ ] RACI заполнена для каждого действия, нет ячеек с множественными «A».
• [ ] Исключения (VIP, критичные системы, закон) описаны отдельными ветками или подпроцессами.
• [ ] Форма создания заявки содержит только обязательные поля; опциональные — в подформах или по требованию.
• [ ] Механизм обратной связи инициатора: комментарии, отказ от закрытия, переоткрытие, CSAT.
• [ ] База знаний привязана к типам заявок; операторы L1 могут решить ≥ 60% типовых запросов без эскалации.
• [ ] Назначен Process Owner с календарным планом ревью (раз в квартал) и KPI.
• [ ] Есть план обучения новичков (операторы, согласующие, инициаторы) и репозиторий актуальных версий схем/регламентов.

Следующие шаги: от описания к зрелому сервису

Описание процесса — не финиш, а стартовая линия. После внедрения базовой версии работайте в трех направлениях:

1. Снижение трудоёмкости исполнения. Анализируйте топ-10 типов заявок по времени исполнения. Внедряйте автоматизацию (скрипты, RPA, самообслуживание через портал), базы знаний, шаблоны ответов. Цель — рост FCR и снижение Resolution Time.
2. Управление спросом (Demand Management). Регулярно (раз в месяц) разбирайте структуру входящих заявок: что можно убрать самообслуживанием, что — изменением политики (например, автоматический доступ при найме), что — обучением пользователей. Это единственный способ не расти штату линейно с ростом компании.
3. Расширение каталога услуг (Service Catalog). Переведите частые рутинные запросы в каталог с готовыми формами, автоматическим исполнением (провайзининг доступов, заказ ноутбука, генерация справок) и прозрачными сроками. Инициатор видит «меню», а не пустое поле «Опишите проблему».

Главный ориентир: процесс должен быть проще, чем его обход. Если сотрудник быстрее решит вопрос сообщением в чат — процесс проигрывает. Измеряйте, слушайте, итерируйте.

Материал носит информационный характер и отражает общие практики управления сервисами (ITSM/ESM). Конкретные SLA, роли, инструменты и правовые требования зависят от отрасли, размера организации, регуляторных актов и внутренних политик. Перед внедрением согласуйте регламент с владельцами рисков, ИБ, HR и правовым отделом.

Ситуация	Рекомендуемое решение
Заявок мало (< 50/мес), нет ITSM, команда 2–3 человека	Google Form + Google Sheets + Apps Script для уведомлений и SLA-таймеров. Swimlane в Draw.io. RACI в таблице.
Рост до 200–500 заявок/мес, появляются L2/L3, нужны отчёты	Jira Service Management (Cloud) или Zammad (self-hosted). Настройка SLA, очередей, портала, базы знаний.
Много согласований, параллельные потоки, нужна аудит-трасса	BPMN-движок: Camunda (self-hosted) или ProcessMaker. Моделируйте в Camunda Modeler, деплойте в движок.
Интеграция с 1С/ERP/HRM обязательна	Выбирайте инструмент с готовыми коннекторами или API. JSM + Assets / ServiceNow IntegrationHub / iTop с REST/JSON.
Процесс разный для филиалов / департаментов	Единый портал входа, затем маршрутизация по атрибутам (орг. единица, категория). Не дублируйте порталы.
Сотрудники привыкли писать в Telegram/Slack	Бот-приёмник, создающий заявку в ITSM и отвечающий номером. Не запрещайте канал — интегрируйте.