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

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

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

Зачем описывать процесс перед настройкой 1С

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

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

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

Шаг 1. Определите границы, цель и участников процесса

Начните с рамки: где процесс начинается и где заканчивается. Для нашего примера: процесс стартует с получения заявки от клиента и завершается отгрузкой товара и передачей документов покупателю. Всё, что до заявки (маркетинг, лидогенерация) и после отгрузки (претензии, возвраты), — отдельные процессы, их описываем отдельно.

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

Выпишите участников и их роли. В нашем примере: менеджер по продажам, менеджер по закупкам (если товара нет на остатке), кладовщик, бухгалтер, руководитель отдела продаж (согласование скидок). Для каждой роли укажите, какие действия она выполняет и какие документы создаёт.

Шаг 2. Соберите фактуру: интервью и наблюдение

Не описывайте процесс из кабинета. Поговорите с каждым участником отдельно: как он реально выполняет свою часть, какие документы открывает в 1С, где приходится «обходить» систему. Вопросы в лоб («как у вас устроен процесс?») дают регламентные ответы; спрашивайте про последний конкретный случай: «Расскажите, как вчера прошла отгрузка клиенту X».

Полезно пройти процесс по цепочке документов в самой 1С: откройте реальный заказ клиента, посмотрите связанные документы (реализация, счёт, УПД), сравните даты. Разрывы между датой заказа и датой отгрузки, непроведённые документы, счета без оплат — это факты о реальном процессе, а не о задуманном.

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

Шаг 3. Постройте схему процесса

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

Схема нашего примера: Заявка клиента → Менеджер оформляет «Заказ клиента» → Проверка остатков → {Товар есть?} → да: резервирование → Счёт на оплату → {Оплата получена?} → да: Кладовщик формирует «Реализацию товаров и услуг» → Отгрузка → Оформление УПД → Конец. Ветка «нет» из проверки остатков ведёт в подпроцесс закупки, ветка «нет оплаты» — к напоминанию клиенту или отмене заказа.

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

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

Шаг 4. Сопоставьте шаги процесса с документами 1С

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

Обратите внимание на колонку «Основание»: в 1С документы должны вводиться на основании, а не «с нуля». Это сохраняет связность цепочки, позволяет строить отчёты по структуре подчинённости и исключает расхождения сумм между заказом, счётом и реализацией.

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

Шаг 5. Опишите статусы, роли и точки контроля

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

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

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

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

Как проверить, что процесс работает

Цепочка документов

Норма

От заказа до УПД все документы связаны через ввод на основании

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

Документы созданы отдельно, суммы расходятся

Остатки после отгрузки

Норма

Складские остатки неотрицательные, резервы сняты корректно

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

Минус по складу, «висящие» резервы

Сроки по шагам

Норма

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

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

Реализация оформляется задним числом пачками

Оплаты

Норма

Каждая оплата распределена на заказ или реализацию

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

Нераспределённые платежи копятся

Шаг 6. Проверьте описание на реальных кейсах и типовые ошибки

Возьмите 2–3 реальные сделки за последний месяц и «прогоните» их по описанию: совпадает ли фактическая последовательность со схемой, все ли документы на месте, сработали ли ветки исключений. Расхождения — это не повод «подогнать» описание под идеал, а сигнал исправить либо описание, либо практику.

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

Когда описания недостаточно: подпроцессы и регламенты

Если ветка процесса сама состоит из нескольких шагов с участием разных людей (например, закупка при отсутствии товара), выносите её в отдельное описание-подпроцесс. На основной схеме остаётся один блок «Закупка под заказ» со ссылкой на детальный документ. Так схема остаётся читаемой, а детали не теряются.

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

Маршрут решения

Как выбрать глубину описания

Процесс выполняют 1–2 человека, шагов меньше десятиДостаточно схемы и таблицы шагов с привязкой к документам 1С

В процессе участвуют несколько отделов и есть согласованияДобавьте матрицу ролей и прав, статусную модель документов

Процесс регулируется законодательством или внешними требованиямиОформите полноценный регламент с контрольными точками и ответственными

Описание нужно для доработки 1СОтдельно зафиксируйте, какие шаги не закрываются типовым функционалом, с примерами данных

FAQ

Какую программу использовать для рисования схемы процесса?

Подойдёт любой инструмент, который умеет блок-схемы: Visio, draw.io (diagrams.net), Miro, даже PowerPoint. Важнее не инструмент, а единые обозначения и то, что схему смогут открыть и прокомментировать все участники. Храните исходник схемы там, где его найдут через год.

Нужно ли описывать процесс, если 1С уже работает?

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

Чем описание процесса отличается от инструкции пользователя 1С?

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

Кто должен описывать процесс: методолог, внедренец или сам сотрудник?

Оптимально — совместно. Сотрудники дают фактуру, методолог или специалист по внедрению структурирует её, замечает разрывы и связывает с возможностями 1С. Описание, написанное только сотрудником, часто пропускает «очевидные» для него шаги; написанное только внешним специалистом — не отражает реальную практику.

Как часто нужно пересматривать описание процесса?

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

Можно ли автоматизировать процесс сразу в 1С, минуя описание?

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