Есть разговор, который повторяется у меня примерно раз в квартал. Собственник или руководитель говорит: мы уже занимались процессами. Нарисовали схемы, наняли аналитика, часть даже автоматизировали. Толку ноль.
Я задаю один вопрос: а как вы выбирали, какие именно процессы улучшать?
Почти всегда ответ один – там, где болело сильнее всего.
Звучит разумно. И именно здесь проект чаще всего и умирает, задолго до первой схемы в BPMN.
Боль – плохой навигатор
Я видел компанию, где полгода приводили в порядок внутренний документооборот, пока средний срок обслуживания оптового клиента оставался таким, каким был. Все были заняты. Отчеты выглядели хорошо. Результата не было.
Боль громче всего там, где больше всего жалоб. А жалуются обычно на процессы, которые все видят: закупки, согласование договоров, оформление командировок, заявки в ИТ. Их действительно можно улучшить. Люди даже скажут спасибо. Но на выручку и маржу это, как правило, не влияет никак – потому что деньги компания зарабатывает совсем в другом месте, и болит там как раз тихо. Или не болит вообще, потому что все привыкли.
Отсюда простое правило, к которому я пришел довольно давно: выбор процессов для улучшения – это стратегическое решение, а не операционное. Его нельзя делегировать тому, кто громче всех жалуется.
Три вопроса до всякого моделирования
Прежде чем рисовать хоть одну схему, я разбираю с командой бизнес-модель. Не в академическом смысле, а в самом приземленном – три вопроса.
Кто наш клиент и какую его боль мы закрываем? Как мы на этом зарабатываем – из чего складывается выручка, что сидит в переменных расходах, где точка безубыточности? И на чем это все держится – какие процессы, люди и технологии обеспечивают то, что мы продаем?
Третий вопрос и дает то, что мне нужно: цепочку ценности. Набор ключевых процессов, которые генерируют деньги. Все остальное – управляющие и вспомогательные процессы, важные, нужные, но по сути рутина.
Тут важный момент. Бизнес-модель показывает только текущее положение. Она не говорит, куда компания идет. Поэтому дальше – видение, стратегические цели и показатели, оформленные через систему сбалансированных показателей.
Логика в ССП жесткая и, по-моему, до конца недооцененная: сверху финансовый показатель, под ним клиентский, под ним процессный, в основании – персонал. Хотим больше выручки – нужно больше клиентов. Хотим больше клиентов – надо менять процессы. Хотим, чтобы новый процесс заработал – надо обучить или нанять людей. Каждый уровень поддерживает предыдущий, и на каждом стоит цифра.
Матрица, которая экономит полгода
Дальше – самая недооцененная процедура во всей этой работе. Приоритизация.
Делается она просто. Строится таблица: в столбцах – стратегические KPI из ССП, в строках – процессы первого уровня. На пересечении ставится балл влияния процесса на показатель: 0 – не влияет, 1 – слабо, 2 – средне, 3 – сильно. Суммируем по строкам и смотрим, что получилось.
Первый раз это упражнение обычно вызывает неловкую тишину. Потому что выясняется, что процесс, вокруг которого весь год шли совещания, набрал два балла. А процесс, у которого нет ни владельца, ни регламента, ни бюджета, набрал четырнадцать.
Дальше я обычно добавляю вторую ось – сложность реализации. Тогда становится видно не только что важно, но и за что можно взяться в этом квартале, а что потребует года и денег. Начинать всегда лучше с того, что важно и при этом реализуемо: программа должна принести первый измеримый результат до того, как у спонсора закончится терпение. Оно заканчивается быстрее, чем принято думать.
Показатель действия, показатель процесса, показатель компании
Когда приоритетные процессы выбраны, начинается моделирование «как есть» – в BPMN 2.0, со всеми ролями, входами, выходами, рисками и, обязательно, показателями.
Вот на показателях я хочу остановиться, потому что здесь чаще всего халтурят.
У процесса должен быть один точный показатель эффективности. И этот показатель обязан поддерживать конкретный стратегический KPI компании. А внутри процесса нужно найти то действие, которое влияет на процессный показатель сильнее всех остальных вместе взятых. Я называю его мультипликатором.
Получается сцепка из трех звеньев: стратегический KPI – процессный показатель – показатель действия. Если хоть одно звено не сцепляется, дальше можно не идти: вы улучшаете процесс, который никак не связан с целями компании, и через год не сможете объяснить финансовому директору, за что он платил.
Мультипликатор, кстати, почти никогда не оказывается там, где его ждут. В моей практике это чаще всего было не производственное действие, а точка принятия решения – момент, когда работа останавливалась и ждала чьей-то подписи.
Самое дешевое решение обычно не ИТ-система
В геологоразведочной компании мы разбирали простои. Ожидания были стандартные: нужна система, нужен бюджет, нужна интеграция.
Мы построили пятнадцать карт процессов и увидели, что техника чаще всего стоит не потому, что ее нечем чинить, а потому, что непонятно, кто именно принимает решение. В итоге сработала матрица распределения ответственности – просто четкая фиксация того, кто что решает и кто кого не должен ждать. Ожидаемое сокращение простоев – около 20%. Без единой строчки кода.
В крупном государственном ведомстве, в проекте с международной организацией, мы прошли через семь процессов и сократили их в среднем на 20-25% по времени и сложности – в основном за счет устранения лишних передач ответственности и повторного ввода одних и тех же данных в разные формы.
В нефтетранспортной компании работа по непрофильным видам деятельности дала около 8,5 миллионов долларов за пять лет. Не потому что мы нашли одно гениальное решение, а потому что впервые посчитали себестоимость процессов раздельно и сравнили ее с рынком. Часть операций оказалось дешевле купить, чем содержать.
Здесь нужна оговорка, иначе меня поймут неправильно. Я не против ИТ и уж точно не против автоматизации. В компании, торгующей ГСМ оптом и в розницу, мы как раз автоматизировали – и время обслуживания клиента сократилось примерно на 20%. В том же государственном ведомстве отдельная инициатива по цифровизации дала еще около 20% по клиентским процессам.
Разница в одном: и там, и там автоматизация шла последней. После того как процесс был перерисован, а не вместо этого. Автоматизировать процесс «как есть» – значит зафиксировать в коде все его нынешние глупости и сделать их неисправимыми на несколько лет вперед. И оплатить это удовольствие по прайсу интегратора.
С искусственным интеллектом, кстати, ровно та же ловушка, только дороже. Сейчас модно навешивать ИИ на существующие процессы. Гораздо интереснее другое – проектировать целевой процесс, изначально исходя из того, что типовые суждения делает модель, а человек занимается исключениями. Это не то же самое, что «внедрить ИИ». Это другой процесс.
Где я сам ошибался
Долгое время я считал, что хорошая модель процесса продает себя сама. Покажешь людям цифры, покажешь, где они теряют два дня на пустом месте, – и они пойдут за тобой.
Не идут.
Люди не сопротивляются логике. Они сопротивляются потере понятного порядка, статуса, привычной зоны контроля, а иногда просто необходимости заново учиться в сорок пять лет. И если этим не заниматься отдельно, спроектированный процесс останется красивой схемой в папке.
Поэтому теперь у меня есть отдельный обязательный шаг, и занимает он от силы час. Я выписываю всех, кого изменение касается, и по каждому отвечаю на два вопроса: он за или против – и может ли он это изменение остановить. Дальше сразу видно, с кем нужно разговаривать в первую очередь, а с кем можно и потом.
Час работы объясняет потом очень многое. В том числе то, почему одни проекты доходят до конца, а другие тихо растворяются через три месяца после презентации.
И еще одно, что я понял не сразу: самый опасный человек в проекте – не тот, кто громко возражает. Этот как раз понятен, с ним можно работать. Опасен тот, кто на совещании молчит и кивает, а потом просто не подписывает.
Процессы не оптимизируются один раз
Последнее, о чем стоит сказать честно.
После внедрения нужен план-факт: сравнить показатели «как есть» и «как будет» на всех трех уровнях – действие, процесс, стратегия. Иногда результата нет. Тогда важно понять, где именно сломалось: в проектировании, в исполнении или еще на приоритизации, когда мы выбрали не тот процесс.
И кто-то в компании должен этим заниматься постоянно. В той же нефтетранспортной компании мы для этого создали центр компетенций по процессному управлению. Это тот орган, который держит показатели процессов, разбирает конфликты между процессной и функциональной вертикалями и решает, когда цикл запускается заново.
Потому что он запускается заново всегда. Компания меняет цели, рынок меняет условия, и процессы, оптимальные два года назад, снова становятся узким местом.
Процессное управление – это не проект с датой закрытия. Это привычка задавать один и тот же вопрос: а этот процесс вообще влияет на то, куда мы идем?
Большинство компаний этот вопрос не задают. И оптимизируют не то.
