Бизнес-процессы: что об этом нужно знать продажникам

О бизнес-процессах говорят многие, часто, в самых разных ситуациях и с полной уверенностью, что все всех понимают при этом правильно. Ну бизнес-процессы же! Шо, не знаете? Я пока не встречал человека, который сам, по своей воле, мог сказать — не знаю. Вот в ходе допроса — да, а чтобы сам — не встречал. :)

На самом деле определений бизнес-процессов целая куча и понимают их зачастую разные люди несколько по-разному.

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

Ведь мы же слышим "бизнес-процессы", "бизнес-процессы продаж", "нам нужно оптимизировать наши бизнес-процессы продаж", "он хорошо контролирует бизнес-процессы продаж, но есть возможность повысить их эффективность".

Слышали шо-то такое? :)

Давайте об этом поговорим. :)


IBM определяет бизнес-процесс очень просто — как "последовательность действий, дающая полезный результат".

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

Что прикольно, украинская Википедия тут несколько выбивается из ряда, и дает такое определение: будь-яка діяльність, що має вхідний продукт, додає вартість до нього, та забезпечує вихідний продукт для внутрішнього або зовнішнього споживача. На всякий случай переведу: любая деятельность, имеющая некий входной продукт, прибавляющая ценность к нему и обеспечивающая выходной продукт для внутреннего или внешнего потребителя.

На самом деле это несколько ближе к достаточно "классическому" определению, принятому в стандарте ISO 9000:2000: это совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы (ссылки погуглите сами, описание можете глянуть, например, здесь).

Еще парочку определений можно глянуть тут, для общего понимания.

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

Так вот. Имеем что-то на входе процесса, процесс перемалывает это "что-то" и выдает уже что-то на выходе. Просто и понятно, см. рисунок:

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

Вообще, сам способ изображения (т.е. какие используются стандартные элементы, какой порядок, какие соглашения-договоренности и т.п.) называют нотацией.

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

В этой нотации у каждого процесса всегда должен быть хотя бы один вход и всегда должен быть хотя бы один выход (это очень оптимистическая нотация :) ).

Что еще есть у нее важного: это так называемые контроли (всегда — сверху, в виде входящих стрелок) и так называемые механизмы (всегда снизу, тоже в виде входящих стрелок).

Пример изображения процесса (это приблизительное изображение, показывающее сам принцип, тут мы не указываем описание "узла" и тому подобные формальные детали):

Естественный вопрос: а чего это повара обозвали механизмом? Ну вот такое вот звериное и бездуховное обличие капитализма, у них даже люди — это механизмы... :)

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

Это очень правильно и обосновано — и снимает все вопросы. Если просто вместо "перемолоть мясо" мы поставим по наивности "перемолка" или "работа мясорубки" то могут возникнуть вопросы, что именно мы имеем ввиду. Сам факт работы мясорубки? Рабочее времяпровождение повара? В общем, лучше четко и ясно обозначать глаголом (а в данной нотации это обязательно).

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

Что хочу сказать по данной нотации. Она — одна из целого семейства нотаций IDEF, а нолик как бы показывает, что она — самая "верхняя", самого верхнего уровня. Ею удобно описывать наиболее общие процессы. От главного процесса предприятия и, ступенчато, с помощью декомпозиции, все ниже и ниже.

Однако, в какой-то момент декомпозиции на все более детальные вещи — просто поверьте — она станет неудобной. Просто потому, что теряется сам смысл ее использования. Ведь зачем нам описание бизнес-процессов? Чтобы разобраться. А что нам даст описание, что в одну сторону входит мясо, а из другой выходит фарш? Да в общем-то ничего особенного.

Скажу больше, это можно изобразить и безо всяких нотаций. А как бы в виде т.н. flow chart. Вот тот, самый первый рисунок с мясорубкой — это на самом деле не блок-схема (там другое, там прямоугольнички, ромбики и прочие геометрические фигурки), а именно вот та самая "флоу чарт". Ее можно изображать с мясорубками, мясом, фаршем, человечками, чертиками и какими угодно другими фигурками. Она нужна просто для понимания последовательности процесса. Ведь процесс — это какая-то последовательность прежде всего. Даже если она иногда ветвистая, а не просто справа налево.

Блок схема выглядит примерно так (только надписей не хватает):

При этом ромбик — это разветвление, если вы заметили. Т.е. есть какой-то вариант, по которому дальше пойдет процесс.

Пример flow chart (тут я уже не от руки каракули нарисую, а использую все-таки компьютер, раз уже за ним сижу):

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

А знаете еще, что является характерной деталью процессов (и не является, например, проектов), но редко встречается в определениях? Оно просто, как правило, подразумевается — это повторяемость. Чувак в кепке может ходить к доктору не один раз, но по одному и тому же самому маршруту-алгоритму, с тем же успехом, много-много раз...

Даже больше: по этому же маршруту (или алгоритму) будут ходить другие люди — и тоже много-много раз, и тоже все с тем же успехом!

В этом, на самом деле, один  из приколов процессного подхода (это я про один, но есть еще) — повторяемость и предсказуемость (в идеале). Это позволяет, помимо прочего, сделать то самое, что по-модному называют оптимизацией. Если, конечно, есть что оптимизировать.

Например, если бы на схеме были бы какие-то немыслимые петли, то мы бы их увидели и "оптимизировали", сократив алгоритм до минимума.

Всегда ли мы имеем предсказуемость? К сожалению, не всегда.

Мы можем нарисовать так называемый "счастливый путь" (happy path):

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

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

Во-вторых, мы можем в очень общих чертах изобразить вышеуказанный happy path. Зачем нам это нужно? Мы можем указать не просто действия от фонаря, мы можем указать определенные вехи, которые будем контролировать. Давайте дам более вменяемый пример:

Как легко видеть, и это — тоже, по-прежнему, все тот же happy path. Однако, у этой очень условной конструкции уже есть некоторая польза: мы можем отслеживать каждое действие (овальный прямоугольник) и делать отчеты. Скольких пытались привлечь, скольким предложили презентацию, сколько передали в продажи и т.п.

У нас получится так любимая многими воронка продаж. В данном случае (они могут быть разные, если что):

Но вернемся к процессам.

Мы можем еще сделать такую интересную штуку, как матрицу ответственности.

Классический вариант — RACI-диаграмма (Responsible, Accountable, Consulted and / or Informed)

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

Сейчас вдаваться в детали не будем (может позже — или сами посмотрите в сети).

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

Вернемся к описанию процесса — что мы еще можем сделать? Можем показать в точности, как он будет "проистекать"? Если мы о сложных продажах — нет. Максимум — тот самый "счастливый вариант". Ну может с базовыми ветвлениями.

В остальных случаях шибко умные люди иногда говорят, что мы имеем дело с так называемыми ad hoc процессами. Т.е. как бы штучными процессами, ручной работы. Мы знаем точно составляющие, мы знаем вход-выход, но мы не знаем точного алгоритма. Может, нам десять раз придется показывать презентацию и переделывать решение (такое бывает, чего уж там). И провести кучу встреч. И задействовать кучу другого народа.

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

Кстати, про кучу другого народа.

В описаниях бизнес-процессов это очень часто находит определенное отражение. Например, участие каждого отдельного участника мы выделяем в "дорожку" (lane), тогда как весь процесс — это получается что-то вроде бассейна (pool):

Прямоугольники — это какие-то действия (поленился написать что-то конкретное), ромб — "развилка" или gateway.

К похожей схеме мы еще вернемся (надеюсь), но сейчас просто отвечу на мой любимый вопрос: а зачем все это нужно.

Могут быть разные задачи. Например, может стоять задача просто посмотреть, как идет процесс в общем виде, и нельзя ли что-то подсократить, упростить или наоборот, добавить (ну это редко).

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

А может стоять задача совсем другого порядка — четко описать именно алгоритм. В сложных продажах, как правило, мы не можем его предсказать. Однако, отдельные процедуры часто вполне поддаются описанию. Более того, иногда жесткое регламентирование просто что называется "просится", чтобы было четко понятно, конкретно кто, конкретно что, конкретно когда должен делать.

Не совсем "продажный" пример — работа справки. Там нужен четкий алгоритм.

Пример из продаж — работа колл-центра. Например, по холодным звонкам. У несчастного сотрудника должен быть четкий алгоритм (сценарий или, как сейчас это звучит на жаргоне, — скрипт) и четкое понимание, что он должен делать и говорить. А думать ему особо некогда — идет поток, конвейер.

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

Нам может понадобиться привязка к определенным событиям.

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

Пару объяснений. Кружочки — это т.н. события. Процесс начинается одним стартовым событием (надо сделать звонок) и заканчивается одним из четырех финальных событий, из которых одно — успешное. Прямоугольники с овальными краями — действия, на них распространяется правило выражать их глаголом (возможно, с дополнением). Стрелочки обозначают т.н. передачу управления (к следующему действию). Ромбики — это т.н. гейтвеи (gateway), обозначают разветвление маршрута (алгоритма) процесса.

Теперь прокомментирую по сути.

1. Диаграмма понятна даже самому тупому и для ее понимания особого образования не нужно.

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

3. Каждое действие можно и нужно сопровождать записью в системе CRM (вручную или автоматически — автоматически можно, например, записывать первое действие, т.е. сам факт звонка). Т.е. имеем контроль процесса на всех этапах.

4. Записи прекрасно формируются в отчет (возможна автоматизация).

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

Давайте немного усложним этот процесс — предположим, что обзванивает один, а на встречи ходит другой.

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

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

А что же мы отображаем? Мы отображаем в данном случае по сути то, что хотели бы видеть в отчете. Т.е. те вехи, которые нам в данном случае интересны. Были бы интересны другие детали — нет проблемы добавить.

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

Однако, у меня была задача попроще — просто показать пример.

На самом деле нотация (BPMN) с одной стороны довольно простая, с другой — в реализации 2.0 она может быть не просто описательной или аналитической, а уже исполняемой. Т.е. в отличие от всяких вышеприведенных картинок, есть возможность в некой системе (BPMS) запустить данный процесс на исполнение — что-то вроде того, как запускают на исполнение программы.

Однако, это целая отельная тема, а мы сейчас просто отметим, что такой оборот событий позволяет не просто нарисовать процессы, потом их автоматизировать, а потом (в совокупности на это может уйти два-три года, начиная с анализа процессов и заканчивая внедрением автоматизации) с прискорбием отметить, что жизнь поменялась и процессы поменялись вместе с ней. Это позволяет моделировать и запускать процессы практически в режиме "что нарисовал, то и исполняется".

Правды ради, это уже можно было делать с помощью специального языка BPEL (он так и называется — язык исполнения бизнес-процессов). Однако, он не получил такого широкого распространения — возможно, в том числе потому, что там диаграммы получаются неудобоваримыми для не-специалистов. Тогда как в случае BPMN диаграмма понятна всем, а не только программистам и аналитикам.

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

Предлагаю такое резюме: разные люди понимают под процессами разные вещи. В зависимости от поставленных задач, мне удобно изображать "глобальные" процессы в каком-то подобии нотации IDEF0, тогда как на более низком уровне обычно гораздо полезнее BPMN. Продавцам неплохо бы понимать, что именно имеет ввиду собеседник, когда он произносит какие-то модные термины.

По сути процессного подхода (как я его понимаю) поговорим отдельно, это тоже очень интересно и важно для понимания. :)