Осознание потребности

С чего вообще я озадачился бизнес-процессами? Озарение пришло в тот момент, когда в агентстве я столкнулся с огромным количеством вопросов:

• как быть в той или иной ситуации;

• как определить ответственного в той или иной ситуации;

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

• как решать проблемы с коммуникацией с клиентами и документооборотом;

• что делать с падающими показателями LTV, NPS и CSI.

Проблема понятна. Что дальше?

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

Первым делом я разработал карту бизнес-процессов.

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

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

Карта бизнес-процессов превращается...

Теперь пришла очередь начать описывать каждый бизнес-процесс:

• что есть точка входа;

• кто есть хозяин процесса, то есть ответственный;

• что должно быть сделано в рамках процесса;

• какой алгоритм этих действий;

• что есть точка выхода.

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

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

Регламенты, настало ваше время

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

Существует два основных метода разработки регламентов.

1. Регламенты пишет руководитель. Чаще всего именно этот подход и применяется. Но он имеет один большой минус: если руководитель не знает во всех мелочах, что должно быть в регламенте, то регламент получится плохой. Я, например, не SEO-специалист и написать хороший регламент для него просто не смогу.

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

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

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

Делу время, а задаче дедлайн

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

Приведу пример. SEO-специалист получает задачу по проведению комплексного аудита сайта. Срок у него на эту задачу 10 дней. Аккаунт-менеджер озвучивает в самом начале сотрудничества с клиентом фронт работ и договаривается на предоставление отчёта по аудиту через 14 дней. 4 дня — резервный срок, если что-то пойдёт не так. По регламенту сеошник сдаёт работу через 10 дней, далее через 10 дней аккаунт должен принять этот аудит, проверить его на соответствие разработанному фреймворку и передать его клиенту или отправить на доработку. Вот тут-то бизнес-процессы и начинают помогать наводить порядок в работе, что, несомненно, полезно.

Сто раз проверь, один раз внедри

Чтобы не разрушить существующую корпоративную культуру и усто́и, я рекомендую месяц или два проследить, как на практике работают разработанные вами регламенты. Допускаю, что регламенты могут содержать какие-либо изъяны, которые надо выявить и устранить в максимальном количестве. А тестирование как раз лучше всего проводить в так называемом скрытом режиме, когда сотрудники ещё работают по-старому, а вы их работу отслеживаете по-новому.

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

Когда всё пошло не по плану

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

Прилетает запрос от клиента на какую-то правку, которая не планировалась в регламенте никак, но мы её берём в работу. Это одновременно и большая наша проблема, и то, за что ценят нас клиенты. Мы работаем очень гибко. Если появляется более приоритетная задача, то мы можем по согласованию с клиентом поменять задачам сроки и приоритеты в нашем плане работ. Отсюда у нас начался бардак в Битриксе. И я был вынужден отказаться от автоматизации.

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

Так польза или вред?

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

Источник фото на тизере: Miracle Seltzer on Unsplash