Просматривая содержание курсов для аналитиков 1С, я заметил любопытную закономерность. Везде учат рисовать схемы бизнес-процессов. Но нигде не учат помещать в них ключевого участника — Систему. Ту самую учетную программу, ради демонстрации которой, вообще-то, вся эта красота и рисуется.
Вместо этого ее функции размазывают между участниками процесса, как масло по бутерброду. В результате Система есть везде и нигде. И по схемам невозможно понять, что она реально делает и за что бизнес платит деньги.
Вторая проблема - универсальность. Курсы учат рисовать одну схему для всех сотрудников заказчика разом. Как будто топ-менеджер, руководитель среднего звена и исполнитель — это один и тот же человек. На практике у них три разных видения мира. В итоге схемы работают усредненно — а значит, посредственно.
И наконец, схемы рисуют, не сообщая, а зачем они? Для презентации руководству, для инструкции рядовому исполнителю или для чего-то еще?
В этой статье я покажу, как встроить Систему в схемы бизнес-процессов, адаптировать их под разные уровни аудитории и применять на практике — под конкретные задачи.
Что на самом деле хочет руководство от внедрения Системы?
Снизить бардак и воровство до приемлемого уровня. Можно сколько угодно говорить про “прозрачность”, “эффективность” и “цифровую трансформацию”. Но в голове у руководителя предприятия обычно крутится простая мысль: «Кто, что и когда сделал — и где меня пытаются обмануть?»
И если он увидит на вашей схеме ответ на этот вопрос - ваше предложение его зацепит.
Как это реализовать?
Разберем мой подход на примере. Будем рисовать схему бизнес-процесса для одной конкретной цели — презентации работы программы высшему руководству заказчика.
Выберем сквозной процесс, т.е. затрагивающий несколько подразделений. Это позволит наглядно показать, как Система обеспечивает взаимодействие между ними. Возьмем «Закупку ТМЦ» — процесс, знакомый практически любому предприятию.
Рисовать будем в нотации BPMN 2.0. Она сегодня самая популярная и, что важно для нашей задачи, крайне удобна, чтобы выделить Систему в самостоятельного участника. Исходим из того, что процесс реализуется в программе 1С:ERP.
Что изображено на блок-схеме?
Разберем схему по шагам:
Сотрудник подразделения Закупки вводит в программу данные о поступлении ТМЦ.
Система фиксирует поступление.
Система автоматически рассылает указания: в Закупки — подать заявку на оплату и в Бухгалтерию — отразить поступление в учете.
Подразделения Закупки и Бухгалтерия выполняют указания Системы.
Система фиксирует результаты их действий.
После регистрации заявки на оплату, Система извещает Казначейство о необходимости ее рассмотреть.
Принципы построения схемы
1. Система получает собственную дорожку
В BPMN-диаграмме для Системы (учетной программы) выделяется отдельная дорожка. На ней отражаются действия программы: запись данных и рассылка сообщений другим участникам процесса.
Зачем это нужно: чтобы высшее руководство видело не просто «кто кому передал бумажку», а где процесс идет автоматически, а где требует участия человека.
2. Дорожка Системы выделяется цветом
Цвет позволяет мгновенно отличить действия Системы от действий людей. Это визуальный якорь: взгляд сразу выхватывает зону ответственности программы.
3. Указания Системы — в отдельном визуальном ключе
Действия Системы по отправке указаний выделяются цветом дополнительно. Почему? Потому что это ключевой механизм координации. Без него процесс распадается на изолированные участки.
4. Вместо сотрудников — подразделения
Схема адресована высшему руководству, поэтому в ролях мы используем не отдельных сотрудников, а подразделения предприятия. Это соответствует уровню обобщения, который ожидает топ-менеджмент.
5. Ограничиваем количество участников
Чтобы схема легко читалась, ограничиваемся двумя основными подразделениями процесса. В нашем примере - это Закупки и Бухгалтерия.
6. Третий человеческий участник — без детализации, но в кадре
В процессе «Закупка ТМЦ» участвует еще и Казначейство. Как его показать, не перегружая схему?
Классический BPMN предлагает вынести его за границы процесса и обозначить абстрактным прямоугольником. На практике такой элемент мало что объясняет — читатель схемы либо игнорирует его, либо задает лишние вопросы.
Я предлагаю другой подход: добавить Казначейство в схему и кратко написать, что там происходит, но без детализации.
С точки зрения BPMN это неканонично. Зато наглядно, надежно и практично. Это мое осознанное отступление от стандарта — такое же, как и выделение Системы в отдельную дорожку.
Что дает такой подход?
Схема не перегружается. Мы показываем ровно столько, сколько нужно для понимания.
Виден полный контур процесса. Понятно, что происходит за пределами основного ядра.
Появляется возможность расширения. Если схема приживается и активно используется, мы можем добавлять новых участников и детализировать их действия. Аккуратно нарушая правило «не более 10–15 элементов в схеме».
BPMN для нас — не догма, а руководство к действию
Стандарты важны, но они существуют для людей, а не люди для стандартов. Если нотация мешает донести мысль до заказчика — ее можно и нужно адаптировать. Главное, чтобы адаптация была осознанной и решала конкретную задачу.
В нашем случае задача — показать руководству, как Система координирует действия подразделений и следит за порядком на предприятии. И с этой задачей мы справляемся.
Что видит руководитель предприятия?
Он видит не просто движение документов между людьми, а управляемый процесс, где Система координирует и контролирует действия сотрудников.
Из схемы сразу видно — даже без чтения подписей — что Система выполняет больше действий, чем все участники процесса вместе взятые.
Достаточно дополнить эту схему примерами указаний, которые рассылает Система, образцами управленческих отчетов — и у вас готова цепляющая презентация. Презентация того, как именно система поддерживает порядок в бизнесе.
Чего хотят мидлы?
Многого, конечно. Но есть одно общее желание, которое объединяет всех руководителей среднего звена: четкие границы ответственности.
Почему это так важно? Потому что невероятно обидно, когда ты свою часть работы сделал идеально, кто-то другой провалил свою, а ответственность размывается на всех.
Ниже — схема того же бизнес-процесса «Закупка ТМЦ», но уже в представлении для руководителей среднего звена.
Главное отличие: если в версии для высшего руководства мы показывали взаимодействие подразделений, то здесь мы показываем взаимодействие через Систему конкретных сотрудников и их зоны ответственности.
Где использовать такую схему?
Рабочий вариант — приложение к инструкции о разделении ответственности между сотрудниками (или между подразделениями, которые они возглавляют).
Схема становится не просто иллюстрацией, а рабочим инструментом:
При конфликтных ситуациях — показывает, где произошел сбой.
При приеме нового сотрудника — наглядно объясняет его зону ответственности.
При настройке прав доступа — помогает понять, кому какие права нужны.
Что хотят рядовые сотрудники?
Понятных правил игры. Исчерпывающего ответа на вопрос: «Что именно мне делать, в каком порядке и где нажимать?»
Им нужны четкие инструкции: как работает Система, какую кнопку жать и в какой ситуации. И чем гуще написан мануал, чем больше в нем скриншотов — тем лучше.
Но к инструкции об обязанностях сотрудника нужна еще и схема процесса. Чтобы можно было быстро понять, что необходимо делать, не перечитывая десятки страниц. Это удобно. И в этом — практическое применение подобных схем для этой аудитории.
Схема для исполнителя
Ниже — схема части того же бизнес-процесса, но уже нарисованная для сотрудника-исполнителя.
Главное отличие от предыдущей схемы: основных участников теперь всего двое — Человек и Система. Но исполнителю все равно полезно знать «откуда ноги растут» у процесса, кто его инициировал. Поэтому "Закупки" тоже присутствуют, но без подробностей.
Из нового — наличие подпроцесса. Это фактически ссылка на дополнительную инструкцию + блок-схему на случай, если что-то пойдет не так.
Желательно, чтобы у исполнителя были инструкции на все случаи — тогда он спокоен и эффективен. Не гадает, не ждет подсказки, а просто действует по готовому алгоритму.
Подведем итоги
Схема бизнес-процесса не самодостаточна. Ее нужно создавать, учитывая, для какого документа мы ее рисуем, и кто будет ее потребителем. А у потребителя есть потребности. И крайне желательно, чтобы ваши схемы хотя бы какие-то из них могли удовлетворить.
Например:
Руководству нужна картина контроля и координации.
Мидлам — границы ответственности.
Исполнителям — четкий порядок действий.
Если вы это учитываете — схемы, скорее всего, начинают работать. Если нет — они, вероятно, останутся красивыми картинками, которые никто не использует.
И самое главное: Система — полноценный участник процесса. Если относиться к ней так же серьезно, как к сотрудникам, то схемы заговорят.
