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

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

Вторая проблема — универсальность. Курсы учат рисовать одну схему для всех сотрудников заказчика разом. Как будто топ-менеджер, руководитель среднего звена и исполнитель — это один и тот же человек. На практике у них три разных видения мира. В итоге схемы работают усредненно — а значит, посредственно.

И наконец, схемы рисуют, не сообщая, а зачем они? Для презентации руководству, для инструкции рядовому исполнителю или для чего-то еще?

В этой статье я покажу, как встроить Систему в схемы бизнес-процессов, адаптировать их под разные уровни аудитории и применять на практике — под конкретные задачи.

Что на самом деле хочет руководство от внедрения Системы?

Снизить бардак и воровство до приемлемого уровня. Можно сколько угодно говорить про “прозрачность”, “эффективность” и “цифровую трансформацию”. Но в голове у руководителя предприятия обычно крутится простая мысль: «Кто, что и когда сделал — и где меня пытаются обмануть?»

И если он увидит на вашей схеме ответ на этот вопрос — ваше предложение его зацепит.

Как это реализовать?

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

Выберем сквозной процесс, т.е. затрагивающий несколько подразделений. Это позволит наглядно показать, как Система обеспечивает взаимодействие между ними. Возьмем «Закупку ТМЦ» — процесс, знакомый практически любому предприятию.

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

Что изображено на блок-схеме?

Разберем схему по шагам:

1. Сотрудник подразделения Закупки вводит в программу данные о поступлении ТМЦ.

2. Система фиксирует поступление.

3. Система автоматически рассылает указания: в Закупки — подать заявку на оплату и в Бухгалтерию — отразить поступление в учете.

4. Подразделения Закупки и Бухгалтерия выполняют указания Системы.

5. Система фиксирует результаты их действий.     

6. После регистрации заявки на оплату, Система извещает Казначейство о необходимости ее рассмотреть.    

Принципы построения схемы

1. Система получает собственную дорожку

В BPMN-диаграмме для Системы (учетной программы) выделяется отдельная дорожка. На ней отражаются действия программы: запись данных и рассылка сообщений другим участникам процесса.

Зачем это нужно: чтобы высшее руководство видело не просто «кто кому передал бумажку», а где процесс идет автоматически, а где требует участия человека.

2. Дорожка Системы выделяется цветом

Цвет позволяет мгновенно отличить действия Системы от действий людей. Это визуальный якорь: взгляд сразу выхватывает зону ответственности программы.

3. Указания Системы — в отдельном визуальном ключе

Действия Системы по отправке указаний выделяются цветом дополнительно. Почему? Потому что это ключевой механизм координации. Без него процесс распадается на изолированные участки.

4. Вместо сотрудников — подразделения

Схема адресована высшему руководству, поэтому в ролях мы используем не отдельных сотрудников, а подразделения предприятия. Это соответствует уровню обобщения, который ожидает топ-менеджмент.

5. Ограничиваем количество участников

Чтобы схема легко читалась, ограничиваемся двумя основными подразделениями процесса. В нашем примере — это Закупки и Бухгалтерия.

6. Третий человеческий участник — без детализации, но в кадре

В процессе «Закупка ТМЦ» участвует еще и Казначейство. Как его показать, не перегружая схему?

Классический BPMN предлагает вынести его за границы процесса и обозначить абстрактным прямоугольником. На практике такой элемент мало что объясняет — читатель схемы либо игнорирует его, либо задает лишние вопросы.

Я предлагаю другой подход: добавить Казначейство в схему и кратко написать, что там происходит, но без детализации.

С точки зрения BPMN это неканонично. Зато наглядно, надежно и практично. Это мое осознанное отступление от стандарта — такое же, как и выделение Системы в отдельную дорожку.

Что дает такой подход?

• Схема не перегружается. Мы показываем ровно столько, сколько нужно для понимания.

• Виден полный контур процесса. Понятно, что происходит за пределами основного ядра.

• Появляется возможность расширения. Если схема приживается и активно используется, мы можем добавлять новых участников и детализировать их действия. Аккуратно нарушая правило «не более 10–15 элементов в схеме».

BPMN для нас — не догма, а руководство к действию

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

В нашем случае задача — показать руководству, как Система координирует действия подразделений и следит за порядком на предприятии. И с этой задачей мы справляемся.

Что видит руководитель предприятия?

Он видит не просто движение документов между людьми, а управляемый процесс, где Система координирует и контролирует действия сотрудников.

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

Достаточно дополнить эту схему примерами указаний, которые рассылает Система, образцами управленческих отчетов — и у вас готова цепляющая презентация. Презентация того, как именно система поддерживает порядок в бизнесе.

Чего хотят мидлы?

Многого, конечно. Но есть одно общее желание, которое объединяет всех руководителей среднего звена: четкие границы ответственности.

Почему это так важно? Потому что невероятно обидно, когда ты свою часть работы сделал идеально, кто-то другой провалил свою, а ответственность размывается на всех.

Ниже — схема того же бизнес-процесса «Закупка ТМЦ», но уже в представлении для руководителей среднего звена.

Главное отличие: если в версии для высшего руководства мы показывали взаимодействие подразделений, то здесь мы показываем взаимодействие через Систему конкретных сотрудников и их зоны ответственности.

Где использовать такую схему?

Рабочий вариант — приложение к инструкции о разделении ответственности между сотрудниками (или между подразделениями, которые они возглавляют).

Схема становится не просто иллюстрацией, а рабочим инструментом:

• При конфликтных ситуациях — показывает, где произошел сбой.

• При приеме нового сотрудника — наглядно объясняет его зону ответственности.

• При настройке прав доступа — помогает понять, кому какие права нужны.

Что хотят рядовые сотрудники?

Понятных правил игры. Исчерпывающего ответа на вопрос: «Что именно мне делать, в каком порядке и где нажимать?»

Им нужны четкие инструкции: как работает Система, какую кнопку жать и в какой ситуации. И чем гуще написан мануал, чем больше в нем скриншотов — тем лучше.

Но к инструкции об обязанностях сотрудника нужна еще и схема процесса. Чтобы можно было быстро понять, что необходимо делать, не перечитывая десятки страниц. Это удобно. И в этом — практическое применение подобных схем для этой аудитории.

Схема для исполнителя

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

Главное отличие от предыдущей схемы: основных участников теперь всего двое — Человек и Система. Но исполнителю все равно полезно знать «откуда ноги растут» у процесса, кто его инициировал. Поэтому «Закупки» тоже присутствуют, но без подробностей.

Из нового — наличие подпроцесса. Это фактически ссылка на дополнительную инструкцию + блок-схему на случай, если что-то пойдет не так.

Желательно, чтобы у исполнителя были инструкции на все случаи — тогда он спокоен и эффективен. Не гадает, не ждет подсказки, а просто действует по готовому алгоритму.

Подведем итоги

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

Например:

• Руководству нужна картина контроля и координации.

• Мидлам — границы ответственности.

• Исполнителям — четкий порядок действий.

Если вы это учитываете — схемы, скорее всего, начинают работать. Если нет — они, вероятно, останутся красивыми картинками, которые никто не использует.

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