Рабы бизнес-процессов

Скованные одной цепью, 
Связанные одной целью.
/И. Кормильцев/

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

Гоню ли я на бизнес-процессы?

Нет! Бизнес-процессы — это круто. В любой компании, от небольшого ИП до гигантской корпорации, наличие бизнес-процессов — залог порядка и отсутствия разнообразных управленческих головных болей. Идеально: рутинная задача превращена в алгоритм с входными условиями, триггерами, ветвлениями и т.д. Только вместо машины алгоритм исполняют люди, для которых установлены сроки и мера ответственности. О такой задаче можно не заботиться, она выполняется на автомате, а ещё лучше, если она автоматизирована в рамках АСУ, в частности, CRM или ERP. 

Что важно для бизнес-процессов?

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

• Согласованность — весь набор бизнес-процессов в компании должен быть согласован и отрегулирован в части пересечений.

• Изменяемость — бизнес-процессы обязательно должны пересматриваться и улучшаться. Если процессы не эволюционируют, ваша компания топчется на месте (ну то есть отстаёт и от времени, и от конкурентов).

Что плохо для бизнес-процессов?

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

• Гонка за показателями. Если вы не оборонный завод, не фармацевтическая фабрика, не больница, не спецслужба и т.д., то есть от вашей работы напрямую не зависят жизни и безопасность людей здесь и сейчас, рабочие задачи — о, сюрприз! — можно отложить. И да, сделать качественно и глубоко одну, а потом уже взяться за остальные, даже если вы вылезаете из плана. В таких случаях качественная работа и глубинный подход не должны порицаться, а напротив, должны быть отмечены. В конечном итоге, и вы, и клиенты оцените то, что сделано продуманно и удобно, а не на коленке в спешке (прежде всего это, конечно, касается разработки, но и в других сферах ситуация схожая).

• Бессмысленность бизнес-процессов — разработка алгоритмов для выполнения задач в случаях, когда задачи не однородны, не повторяются, сильно меняются от старта к старту, имеют высокий уровень творческого компонента и т.д. Начинать однократную задачу с составления бизнес-процесса для неё — бюрократия и имитация работы. Для таких ситуаций есть гибкие модели управления, ситуативные подходы и много других способов взяться за дело и завершить его. 

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

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

Чтобы избежать части проблем, нужно правильно проектировать бизнес-процессы. Правильно их делать не в нотации BPMN, не в CRM, не на листке бумаги, а головой — хорошей, работающей, соображающей головой. Это очень важный нюанс, потому что один-единственный неграмотный, неэффективный или неумело собранный бизнес-процесс может нанести удар по продукту, команде, клиентам, прибыли. А ещё неэффективность бизнес-процессов чаще всего дорого стоит — причём это не метафора, а «дорого стоит» в смысле использования ресурсов и недополучения денег. 

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

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

Как работать с процессами?

Вообще для управления жизненным циклом бизнес-процессов в компании есть устоявшаяся и надёжная модель DMAIC (define, measure, analyze, improve, control, она же ОИАСК — определение, измерение, анализ, совершенствование, контроль), которая проводит команду по этапам и почти никогда не оставляет без позитивного эффекта на выходе (если только ваша команда не лебедь, рак и щука). Я буду на неё опираться, но некоторые моменты распишу подробнее, потому что, работая с RegionSoft CRM и нашими клиентами, вижу, что небольшие компании редко подходят к моделированию и использованию бизнес-процессов, а новичкам въехать в управленческий рай на модели DMAIC сразу довольно трудно.

Определение

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

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

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

• Выявить среди всех задач и действий цепочки процессов, зафиксировать что-то вроде MVP — готовую схему с подробностями о сроках, ответственных, переходах, событиях-триггерах.

• Собрать процессы в описанные алгоритмы в визуальном редакторе — это программа-минимум. Но, конечно, лучше использовать наработки XXI века и «загнать» бизнес-процессы в специальное ПО, например, в модуль CRM-системы. Преимуществ здесь несколько: мастер процессов (вас ведут «за ручку» при создании экземпляра процесса), рабочие триггеры (не нужно помнить о звонке или письме, при переходе с этапа на этап всё произойдёт автоматически), логирование (сразу видно, где процесс застопорился, кто сорвал дедлайн, где проблема), ну и аналитика (которая понадобится чуть позже).

• Собственно, запустить процессы — поработать с ними какое-то время, посмотреть на то, как изменилась работа команды, зафиксировать объективные и субъективные находки и недостатки, записать идеи. 

Да, сразу идеально скорее всего не получится, поэтому и есть в модели кроме D ещё 4 буквы.

Измерение

Это главный инструмент анализа эффективности проделанной работы. Цель автоматизации бизнес-процесса - скорость его протекания от начала до конца. Поэтому первое измерение нужно сделать ещё до автоматизации. Соберите данные о среднем времени прохождения процесса и зафиксируйте это значение. После внедрения автоматизации повторите эти замеры. Вы должны увидеть ускорение. Если этого не произошло, - вы неверно настроили автоматизацию. А вот если ускорение налицо, значит вы достигли главной первичной цели, и теперь можете продолжать накапливать статистические данные, чтобы в будущем ещё раз или даже несколько раз его усовершенствовать.

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

• Субъективная оценка ото всех, кто работает с бизнес-процессами каждый день: холдер процесса, сотрудники, исполнители, клиенты, кто угодно, кто есть в цепочке действий. Это самая ценная информация, потому что она добыта в условиях реальной работы.

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

• технические показатели: все ли этапы учтены, избыточен ли процесс, работают ли триггеры, встроена ли работа бизнес-процесса в контур автоматизации или существует сама по себе как формальность и т.д.

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

Анализ

Итак, цикл или циклы бизнес-процессов завершились, обратная связь собрана. Пришло время анализа для будущего рефакторинга процессов.

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

• Выявите слабые места во всех процессах. Определите успехи для каждого процесса.

• Найдите причины сбоев в процессах, опишите их.

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

• Не пожалейте время и декомпозируйте плохо работающие и зомби процессы. 

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

Готовьтесь меняться.

Совершенствование 

Этот этап такой же важный, как этап определения. Если хотите, это и есть этап переопределения — происходит глобальный рефакторинг и редизайн процессов. И здесь тоже не всё просто: он происходит не только в первый раз после создания и внедрения бизнес-процессов в компании, а фактически непрерывно:

• когда создаётся и тестируется новый процесс;

• когда устаревают существующие бизнес-процессы;

• когда меняются входные данные и цели процессов;

• когда меняются цели компании;

• когда происходят значимые изменения внешней среды, влияющие на бизнес-процессы.

А раз отладка процессов — штука перманентная, её… тоже нужно превратить в бизнес-процесс, то есть сделать максимально быстрой на старте, эффективной и рабочей даже на фоне новых условий и рисков. В принципе, базово для этого необходимо три основных условия:

• собирать обратную связь на непрерывной основе (можно без анализа, с анализом — удобнее);

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

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

Итак, как проводить рефакторинг?

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

• Упростить все процедуры, сделать их однозначными, понятными и логичными.

• Устранить лишние задачи и подзадачи — они мешают процессам, оттягивают время и ресурсы.

• Учесть все изменения, спроектированные на основе обратной связи и аналитики.

• Преодолеть сопротивление сотрудников, которые могут лениться менять процессы и преднамеренно искажать информацию, чтобы не погружаться в рефакторинг.

После того, как вы сделаете всё перечисленное, вы опять попадаете в цикл определение — измерение — анализ — совершенствование.

Контроль

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

Бизнес-процессы иногда называют пользовательским интерфейсом решения рабочих задач. И это по-настоящему классное определение: хорошо спроектированные бизнес-процессы действительно делают жизнь команды проще, более интегрированной в рабочий поток. Да, от бизнес-процессов легко отказаться, потому что разработка действенной системы процессов в компании — дело трудоёмкое, требующее времени и ресурсов. Но зачастую это приводит к возникновению хаоса. Более того, от оптимизации процессов и непрерывного их улучшения зависит гибкость и успешность всей команды. Но если вы проявите немного здорового упрямства и поработаете над бизнес-процессами, результат может получиться прямо космическим: буквально сквозь тернии разработки и автоматизации процессов к звёздам достижений команды. И это давно не пафос, а обычное дело для разумной команды, а не рабов процессов.

Алексей Суриков

Главный разработчик RegionSoft