То есть это некая «мастер-модель», дающая понимание всей команде, как ее работа влияет на компанию в целом.
Правила построения VAD-модели процесса добавленной стоимости:
Для начала необходимо определить ключевые задачи компании или подразделения, которые характеризуют ее деятельность.
Далее выстраивается их логическая взаимосвязь.
Определяются и указываются владелец и подразделение, отвечающие за процесс.
Указываются главные документы, регулирующие бизнес-процесс.
Указывается дополнительная информация и необходимые ресурсы для выполнения бизнес-процесса.
К каждому верхнеуровневому бизнес-процессу прикрепляются ссылки на диаграммы более низкого уровня.
Пример VAD-схемы
SIPOC
Подход к описанию бизнес-процессов, являющийся инструментом в бережливом производстве. Название отражает всю суть подхода, который фокусируется на пяти составляющих:
Supplier (поставщик) человек или компания, которые поставляют ресурсы для выполнения бизнес-процесса (производство, деньги, материалы, данные);
Input (вход) ресурсы для бизнес-процесса: материалы, деньги, производственные мощности, данные);
Process (процесс) все те задачи, которые позволяют в результате работы преобразовать сырье в конечный продукт;
Output (выход) продукты деятельности бизнес-процесса;
Customer (заказчик) получатели услуги, те, кто пользуется продуктом бизнес-процесса.
Бизнес-процесс по SIPOC описывается с конца:
Определите заказчика бизнес-процесса;
Опишите итоговый продукт (выход), который нужен заказчику;
Выделите 57 ключевых операций бизнес-процесса;
Определите необходимые ресурсы (вход) для бизнес-процесса;
Определите поставщиков этих ресурсов
Ключевое преимущество скорость описания, возможность выявить лишние шаги, которые не создают ценность. Этот подход чем-то похож на VAD и является верхнеуровневым описанием. Позволяет выявить самые явные потери.
Событийная цепочка процессов (EPC)
Данный подход описывает бизнес-процессы в виде отдельных этапов/шагов процесса и событий, которые инициируют эти шаги, то есть получается структура «событие функция событие». Этот метод хорошо подходит для стандартизации бизнес-процессов и анализа потока документов и необходимой информации в рамках всего бизнес-процесса.
Основные элементы описания:
Событие то, что создает необходимость действия.
Функция это действие для получения нужного результата, в ответ на событие.
Исполнители те, кто реализуют функцию, в том числе утверждают, согласовывают и т. д.
Ресурсы это все то, что необходимо для реализации функции: деньги, информационные системы или отдельные модули, документы, операционные риски.
В отличие от предыдущего подхода, где начало было слева и финиш справа, здесь все стартует сверху и идет вниз.
Алгоритм описания:
Определяем, что у нас есть и чего мы хотим граничные события.
Описываем промежуточные события, которые есть внутри этого процесса и какие необходимо выполнить задачи / реализовать функции.
Добавляем всю необходимую информацию об исполнителях и ресурсах.
Анализ полноты и качества схемы, учитывает ли она все вариации и подпроцессы. При необходимости делаем дополнительные схемы для подпроцессов. Однако тут я рекомендую всегда помнить правило из первой книги одна схема, один лист или экран.
Плюс подхода возможность потом создать понятный регламент в виде текста или таблицы. Эта нотация довольно распространена, особенно в крупных организациях, так как с одной стороны стандартизует описание, а с другой достаточно гибкая. Например, ее часто используют для настройки ERP-систем.
BPMN 2.0 (Business Process Model and Notation 2.0)
BPMN на сегодня некий стандарт де-факто в описании бизнес-процессов с широким набором графических элементов для моделирования. Если для рядовых пользователей и руководителей это не самый удобный подход, то для бизнес-аналитиков это обязательный инструмент: описать в рамках этого подхода довольно большой процесс на одном листе будет трудно, кроме того, подход довольно строг, однако здесь более высокая детализация и легче выявить локальные ошибки.
Пример описания в этой нотации ниже.
Пример упрощенной BPMN-схемы
Что я наблюдаю в жизни и применяю сам
К сожалению, в 99% компаний или нет никакого описания бизнес-процессов, ни верхнеуровневого, ни тем более детализированного, или оно формально и сделано для галочки, а в жизни все работает иначе. И пока организация маленькая, 510 человек, это не страшно. Но после того, как она начинает расти, хаос становится все более дорогим удовольствием.
В своей жизни я подстраиваюсь под задачу, уровень зрелости компании и сотрудников. В основном это некий гибрид EPC и нотации Процедура (о ней подробнее по QR-коду в начале раздела), а иногда и простые блок-схемы.
Резюме 1 главы и рекомендации
Что важнее: организационная структура или описанные бизнес-процессы? С чего начинать? Это извечная дискуссия. Лично мое мнение: пока компания небольшая, идет ее становление или перестройка, подбор той бизнес-модели, которая будет давать результат, можно обойтись без бизнес-процессов. Если у вас есть организационная структура, четко прописаны функции, ключевой продукт и, желательно, метрики (я не вывожу это в обязательное условие, потому что видел единичные случаи качественно проработанной системы ключевых показателей), то вы не утонете в хаосе. Люди смогут между собой общаться и договариваться, а это ключевой элемент. Я бы даже сказал, что это полезное упражнение сначала научить людей работать сообща, разделив между ними полномочия, ответственность и ресурсы, а затем внедрять процессное управление. В итоге работа с орг. структурой позволит создать скелет системы управления, в том числе:
обеспечить эффективное использование ресурсов;
повысить производительность;
минимизировать потребность в регламентах, правилах, детализированных описаниях каждого бизнес-процесса, в общем, в работе с бумагой;
минимизировать риски для компании, особенно связанные с зависимостью от отдельных людей;
снизить перегруз людей и уровень текучки. Вместо одной-двух универсальных «рабочих лошадок» появится распределение задач, снизится неопределенность, из-за которой возникает стресс и выгорание;
разгрузить себя как руководителя: вам не придется часто вмешиваться в процессы и разбираться в конфликтах, так как система станет прозрачной, каждый будет понимать свою зону ответственности. Станет проще подбирать людей и готовить описания вакансий.
Кроме того, на ранних этапах, в том числе при запуске цифровизации, ваши бизнес-процессы будут меняться слишком часто, и постоянно их переделывать и актуализировать слишком дорогое удовольствие. А если описать и «заморозить», то вы теряете главное преимущество молодой команды ее гибкость. Исключение критичные процессы с высокими рисками и процессы бэкофиса, они зачастую стабильны и заниматься ими лучше изначально.
Однако после того, как первичный этап пройден, заниматься бизнес-процессами нужно. Необязательно фиксировать все и детализировано, но наиболее критичные процессы, где высоки риски, где начинают наблюдаться проблемы, описать хотя бы верхнеуровнево обязательно. У верхнеуровневых подходов есть главных плюс скорость и простота. А это уже даст эффект, а значит, ресурсы и мотивацию на углубленную работу.
У взрослых компаний возникает другая проблема бюрократия. Там уже нужен обратный подход упрощение бизнес-процессов. В общем, как всегда, поиск точки баланса, между хаосом и предпринимательством, и порядком с бюрократией.