Как описать бизнес-процесс в 1С

Описание бизнес-процесса в 1С — это перевод реальной последовательности работ компании (согласование заявки, обработка заказа, приём сотрудника) в формализованную схему, которую система сможет контролировать: назначать задачи, отслеживать сроки и фиксировать результат каждого этапа. Без такого описания процесс живёт «в головах» сотрудников, а любая автоматизация упирается в неформальные договорённости.

Работа состоит из двух частей: аналитической (понять и зафиксировать, как процесс устроен на самом деле) и технической (смоделировать его в конфигурации 1С — встроенными механизмами бизнес-процессов, подсистемой согласования или внешними инструментами). Ошибки чаще всего случаются в первой части: схему рисуют «как должно быть по регламенту», а не «как работают люди», и внедрённый процесс начинает мешать.

Ниже — практический порядок действий: от сбора информации до проверки работающего процесса, с разбором типовых ошибок и ограничений.

Определите границы и цель процесса

Первый шаг — договориться, что именно описываем. У процесса должны быть понятный стартовый триггер (создан документ, поступила заявка, наступила дата), измеримый результат (заявка согласована, заказ отгружен) и владелец — человек, отвечающий за процесс целиком. Если результата сформулировать нельзя, процесс описывать рано: получится бесконечная цепочка задач без точки завершения.

Отдельно зафиксируйте, зачем процесс переносится в 1С. Типичные цели: контроль сроков согласования, исключение «потерянных» заявок, автоматическая маршрутизация по сумме или подразделению, накопление статистики по этапам. Цель определяет глубину проработки: для контроля сроков достаточно трёх-четырёх точек маршрута, для маршрутизации по условиям потребуется продумать все ветвления.

Соберите фактическую последовательность шагов

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

Для каждого шага зафиксируйте: название действия в формате «глагол + объект» (проверить комплектность, согласовать бюджет), исполнителя или роль, входные данные, результат, типичную длительность. Особое внимание — точкам принятия решения: кто и по какому критерию выбирает дальнейший путь. Именно эти условия потом лягут в карту маршрута.

Нарисуйте схему процесса до настройки в 1С

Схема на бумаге или в редакторе (draw.io, Bizagi Modeler, даже PowerPoint) — обязательный промежуточный артефакт. Для процессов 1С удобна нотация BPMN: стартовое событие, задачи, шлюзы (ромбы условий), завершающее событие. Даже упрощённая блок-схема сильно лучше текстового перечня — на ней сразу видны циклы, тупики и параллельные ветки.

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

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

Выберите инструмент реализации в 1С

В зависимости от конфигурации и сложности процесса доступны три подхода. Первый — типовые механизмы согласования: во многих конфигурациях (1С:ERP, «Документооборот», «Управление торговлей» с расширениями) есть готовые подсистемы согласования заявок, договоров, цен. Это быстрый путь, если процесс укладывается в линейную цепочку утверждений.

Второй подход — объект метаданных «Бизнес-процесс» с картой маршрута: точки старта, действия, условия, выборы вариантов, параллельные разветвления и слияния. Каждая точка действия порождает задачу исполнителю (объект «Задача»), адресуемую по роли или конкретному пользователю. Это вариант для процессов с ветвлениями, возвратами и параллельным согласованием.

Третий подход — внешние BPM-системы с интеграцией по API, когда процессы выходят далеко за рамки учётной системы. Для большинства сценариев внутри 1С это избыточно, но при сквозных процессах с участием нескольких систем может быть оправдано.

Сравнение подходов

Типовое согласование

Быстрый старт без программирования; ограничение — линейная или простая маршрутизация, слабая гибкость условий

Бизнес-процесс с картой маршрута

Ветвления, параллельность, возвраты, автоматические действия; требует работы в конфигураторе и тестирования

Внешняя BPM-система

Сквозные процессы между системами; минус — сложность интеграции и поддержки

Смоделируйте карту маршрута и задачи

При работе с объектом «Бизнес-процесс» в конфигураторе переносите схему в карту маршрута: точка старта, точки действий (каждая порождает задачу), точки условий с проверкой реквизитов объекта (сумма, подразделение, вид операции), точки выбора варианта, где решение принимает человек, точки разделения и слияния для параллельных веток, точка завершения.

Адресацию задач настраивайте через роли и объекты адресации (например, роль «Руководитель подразделения» + измерение «Подразделение»), а не через конкретных пользователей. Для каждой задачи определите срок исполнения и поведение при просрочке: уведомление, эскалация руководителю или автоматический переход. Автоматические шаги (проверка остатка, смена статуса документа) реализуйте обработчиками точек маршрута, чтобы не порождать лишние задачи.

1. 1
   Создайте объект «Бизнес-процесс» и свяжите его с объектом «Задача»
2. 2
   Нарисуйте карту маршрута: старт, действия, условия, завершение
3. 3
   Настройте адресацию задач через роли, а не конкретных пользователей
4. 4
   Задайте сроки исполнения и обработчики автоматических точек
5. 5
   Создайте формы задач с нужными реквизитами и кнопками решения
6. 6
   Протестируйте все ветки, включая отклонение и возврат на доработку

Протестируйте процесс на копии базы

Запускайте процесс только после проверки на тестовой копии. Пройдите каждый сценарий: прямой путь, отклонение на каждом шлюзе, возврат с повторным согласованием, просрочка задачи, отсутствие исполнителя по роли (например, руководитель в отпуске, и роль никому не назначена). Последний случай — частая причина «зависших» процессов: задача уходит на пустую роль и никем не видна.

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

Типичные ошибки и контроль результата

Чаще всего страдают от четырёх ошибок: описание «как надо» вместо «как есть», адресация на фамилии вместо ролей, отсутствие веток отклонения (процесс умеет только согласовывать) и чрезмерная детализация — когда на каждый клик создаётся задача и пользователи начинают саботировать систему. Оптимум — задача на осмысленный этап работы, а не на каждое действие.

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

Контрольные точки

Как проверить результат

Прохождение процесса

Норма

Экземпляр доходит до завершения по каждой ветке без ручного вмешательства

Тревожный признак

Задачи зависают или уходят «в никуда»

Адресация

Норма

Задачи назначаются по ролям, при пустой роли есть эскалация

Тревожный признак

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

Права доступа

Норма

Исполнитель видит задачу и документ, лишний доступ отсутствует

Тревожный признак

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

Отчётность

Норма

По процессу видно этап, исполнителя и срок

Тревожный признак

Состояние экземпляров можно узнать только вопросом к разработчику

Частые вопросы

Можно ли описать процесс без программирования?

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

Чем бизнес-процесс отличается от задачи в 1С?

Задача — единичное поручение исполнителю. Бизнес-процесс — маршрут, который порождает задачи по мере прохождения точек и управляет их последовательностью, условиями и завершением.

Что делать с уже запущенными экземплярами при изменении схемы?

Безопасный путь — завершить или корректно остановить старые экземпляры и запускать новые по обновлённой карте. Изменение маршрута «на лету» для активных экземпляров рискованно: задачи могут потерять связь с точками маршрута.

Как назначить заместителя на время отпуска?

Через механизмы ролевой адресации: добавьте заместителя в роль или используйте штатные функции замещения/перенаправления задач, если они есть в конфигурации. Проверьте настройку заранее, а не в день ухода сотрудника.

Сколько этапов должно быть в процессе?

Строгой нормы нет. Ориентир: одна задача — один осмысленный этап работы с проверяемым результатом. Если этапов больше десяти, проверьте, не дробите ли вы действия одного исполнителя; если два-три — возможно, достаточно простого статуса документа без процесса.

Нужна ли нотация BPMN, если схема простая?

Формально — нет. Но даже для простого процесса схема с явными условиями и ветками отклонения дисциплинирует описание и служит документом согласования с участниками до начала разработки.