Например, клиент не стал заключать с вами договор или не внес предоплату. Это печально. Но схема процесса все равно остается прежней. Хотя если такая ситуация повторяется слишком часто, наверное, нужно в нем что-то улучшить.

«Нормальный» – то есть такой, как он выполняется в большинстве случаев. Если однажды в качестве клиента к вам обращался король – наверное, вы обслуживали его иначе, чем других клиентов. Но это – исключение. Не нужно заносить его в процесс. Только в случае, если вы решили стать постоянным поставщиком двора Его Величества – тогда сделайте для этого отдельный бизнес-процесс.

«Линейный» – то есть вы отражаете все шаги процесса как последовательные, идущие цепочкой друг за другом. Даже если некоторые из них в жизни выполняются параллельно, если в алгоритме есть циклы и ветвления.

Как же так? Мне как бывшему специалисту по ИТ и по управлению проектами[138], тоже было трудно к этому привыкнуть. Однако практика показывает, что если в чем-то можно допустить ошибки (накосячить), сотрудники обязательно сделают это. Поэтому с некоторой долей условности любой алгоритм можно представить как последовательный. Нюансы раскроете на более глубоких уровнях детализации (при необходимости). А если вы действительно обнаружили несколько разных вариантов выполнения – может быть, и правда процессов здесь несколько? Иногда имеет смысл их разделить. Обсудим это чуть позже.

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

• Смотрим на процесс с одной точки зрения – с колокольни РП, который отвечает за его выполнение[139]. Например, шаг, на котором вы получаете деньги от клиента, так и называется «Получение оплаты от клиента», а не «Оплата». Не вы платите, а он.

• Шаги называем отглагольными существительными. То есть производными от глаголов. Например, шаг называется не «Договор» и не «Заключить договор», а «Заключение договора».

Шаг – это всегда действие (поэтому не «Договор»). А почему существительное? Так благозвучнее получается.

• Описываем процесс «как есть» + ЗБР.

– Как есть – значит, как он выполняется на сегодняшний день. Если по-разному (у разных сотрудников, в разных филиалах, до получки и после) – определите, как чаще. И как лучше для бизнеса. Это и возьмите за основу.

– ЗБР – зона ближайшего развития[140]. То, что вы хотите внедрить в этом процессе в ближайшие 1–3 месяца (именно внедрить в работу). С одной стороны, не нужно ограничивать себя рамками того, как происходит сейчас. Ваша цель – улучшить работу компании. С другой – не сто́ит «улетать в космос». Так, в одной маленькой компании люди на сессии написали, что некий шаг будет выполнять маркетолог. А на наш удивленный вопрос ответили: «Ну ведь в приличной компании должен быть маркетолог!»

Оставайтесь в реальности.

Эволюция бизнеса, а не революция[141] приведет вас к успеху.

ЗДР, то есть зона дальнего развития, – это ваши идеи по поводу того, как можно улучшить этот процесс в более отдаленном будущем. Такие мысли полезно тоже записывать, сохранять и возвращаться к ним позже. Но не нужно заносить их в нынешнюю схему процесса, запутывая себя и коллег.

Часто встает вопрос: один перед нами процесс или несколько? Например, когда есть разные варианты его выполнения.

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

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

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

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

Двигаемся дальше. Перечень шагов процесса – это хорошо, но все же полноценным описанием его назвать пока сложно. А вот по итогам этой главы вы сможете создать схему, которую реально внедрить. И которая принесет компании пользу.

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

Для описания бизнес-процессов в мире разработаны десятки методологий, каждая из которых позволяет отобразить те или иные стороны работы компании. Это такие подходы, как ARIS, IDEF0 (SADT), IDEF3, DFD и многие другие (рис. 19). Однако, по нашему опыту, в большинстве случаев их применение неоправданно и даже вредно[142].