Как связать бизнес-процессы и результат

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

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

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

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

Переход с этапа 1 на этап 2 — это не естественное развитие событий, он требует соответствующих навыков и удаётся не всем. Если совершить его неправильно, то может быть получен обратный эффект: мы будем внедрять в процесс улучшения, которые исполнители будут обходить стороной. Процесс не будет соблюдаться полностью, а через некоторое время он не будет соблюдаться совсем. В лучшем случае удастся сохранить контроль и не вернуться к первоначальному хаосу. В худшем — процесс может «умереть».

Как мы перешли на второй этап? Забегая вперёд, скажу, что нам не потребовалось ничего сверхъестественного. Мы использовали простые и действенные инструменты.

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

Звучит неплохо, но в реальности сотрудник не работает только с одним бизнес-процессом. Даже у исполнителя с чётко описанной зоной ответственности их несколько. Со временем каждый из них «обрастает» большим количеством улучшений. В результате получается несколько внушительных чек-листов, которые хоть и описывают, что и как нужно сделать в каждом случае, но слишком сложны в использовании.

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

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

Как выйти из этой ситуации и перейти с этапа 1 на этап 2? Как связать те улучшения, которые вы описываете в процессе, с непосредственным результатом? Мы совершили этот переход с помощью автоматизации в системе управления проектами.

Как это выглядит на практике для руководителей проектов внедрения в вендоре? В системе управления проектами создаётся новый проект. Автоматически система создаёт структуру задач и подзадач, которая описывает типовые шаги процесса управления проектами: «Провести установочную встречу с заказчиком», «Обсудить проект с инженерами» и т. д. Внутри каждой задачи есть описание с задачами более низкого уровня: «Зафиксировать риски по результатам обсуждения…», «Сделать коммуникацию на…». Местами даны ссылки на отдельные разделы описанного процесса. Список таких шагов можно сформировать, основываясь на своде знаний по управлению проектами.

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

Кроме того, автоматизация помогла ответить на наиболее популярное возражение команды: «Нужно тратить слишком много времени на то, чтобы заводить задачки». Они создаются автоматически; от сотрудника требуется только завести проект в системе управления проектами.

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

Со своей стороны я, как руководитель, получил возможности:

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