Привет, меня зовут Любик Кислюк, и сегодня я хочу поделиться с вами своим опытом построения и сопровождения бизнес-процессов, а также расскажу о препятствиях, которые могут возникнуть у вас на этом пути, и как их преодолевать.
Должен отметить, что вне зависимости от должности, которую я занимал в разных компаниях, мне всегда очень помогал бизнес-аналитический майндсет, который я выработал на старте карьеры и который совершенствую по сей день. Для лучшего понимания моего опыта — далее пару слов о моем карьерном пути в IT:
- руководил веб-студией;
- работал ВА, а затем руководил отделом ВА в компании Verta Media (Adtelligent);
- занимал должность COO в компании Robosoft Industries;
- руководил RnD-отделом дополненной реальности в Snap Inc;
- во время работы в Snapchat, меня пригласили в Autodoc AG, чтобы построить в компании отдел маркетинговой аналитики и руководить им, чем сейчас и занимаюсь и о чем сейчас расскажу.
Задача — построение отдела в трансформирующейся компании
Когда я пришел в Autodoc, компания уже находилась в фазе трансформации из органически растущего бизнеса в крутую технологическую IT-компанию. В рамках этой трансформации, было необходимо перейти от интуитивного подхода в принятии бизнес-решений к data driven подходу, то есть к принятию решений, на основе данных.
Чтобы обеспечить переход, необходимо было построить отдел аналитики. На самом деле не только аналитики — есть еще дата-инженеры и разработчики, процессы сбора, трансформации и хранения данных и много чего еще, но статья не об этом. Важно также учесть, что отдел маркетинговой аналитики будет работать не в вакууме, а в плотном взаимодействии с другими департаментами компании, для чего необходимо выработать процессы и процедуры, которые не усложнят людям жизнь, а принесут максимум ценности с минимальным усложнением взаимодействия. Для того, чтобы все это организовать, необходимо выполнить несколько шагов.
Шаг 1. Аудит. Понять как это работает сейчас
Если перед вами стоит задача что-то трансформировать, начинайте с аудита текущей ситуации. Для этого достаточно просто выделить ключевых участников существующего процесса и провести с ними интервью. На интервью соберите информацию о том, как это работает сейчас: каков процесс от этапа постановки задачи до поставки решения, какие задействованы ресурсы, по каким правилам это работает.
Важно поговорить хотя бы с тремя ключевыми участниками: это позволит вам узнать как существующий процесс видят разные люди. Если они видят картину одинаково — значит люди синхронизированы, пусть и в старом процессе. Если же они опишут вам разные процессы, хотя на самом деле он один, значит, люди рассинхронизированы, и вам, помимо изменения процессов, нужно будет продумать еще и синхронизацию участников. Иначе какой смысл работать над новым классным процессом, если люди будут воспринимать его по-разному.
На этапе аудита важно не просто собрать информацию о процессе, а начать выстраивать доверительные отношения с участниками процесса. Во время интервью не просто собирайте информацию о текущем положении дел, а просите дать оценку происходящего, поделиться болями и идеями о том, как по мнению сотрудника можно это изменить. Во-первых, это позволит вам получить вариант решения проблемы, который можно будет «докрутить» до изящного уровня. Во-вторых, вы таким образом начинаете налаживать те самые доверительные отношения, ведь людям очень приятно, когда ценят их экспертное мнение, тем более что это мнение часто бывает полезным.
Люди должны понимать, что вы не очередной «манагер», который бездумно делает бюрократическое огораживание, а что вы настроены на то, чтобы отдел давал бизнесу максимум ценности, учитывая при этом интересы и боли участников процесса — как со стороны заказчика, так и со стороны исполнителей.
Результаты интервью конспектируйте в документ: можно делать пометки прямо во время беседы. После того, как вы побеседуете со всеми ключевыми участниками, соберите в целое то, что вы записали. На этом этапе станет понятно, что многие боли и проблемы пересекаются, и на самом деле их не так много, как казалось на первый взгляд. Теперь можно приступать ко второму этапу.
Шаг 2. Предложить изменения. Описать, как и что будет работать по-новому
После того, как аудит проведен и ясны «масштабы трагедии», необходимо разработать измененный флоу, который призван решить существующие проблемы (в идеале не создав новые). Данный флоу необходимо описать в формате, понятном для всех участников: в общем случае, будет достаточно хорошо структурированного гуглодока, который по желанию можно сдобрить несложными схемами, которые упростят понимание нового процесса.
В целом данный документ должен отвечать на следующие вопросы:
- Как поставить задачу на отдел: куда нажать в Jira, чтобы задача попала туда куда нужно и не потерялась.
- Как правильно описать задачу: шаблон с DoR, чтобы не затягивать этап дискавери и сразу указывать в задаче то, что нужно.
- Как выглядит жизненный цикл задачи: в идеале с привязкой к статусам задач в той же Jira для прозрачности.
- Как происходит приоритизация задач и утилизация бэклога. Возможны разные варианты: у нас, например, из-за большого потока задач от разных отделов, заказчики разбиты по тирам для упрощения приоритизации.
- На каком этапе и по каким правилам происходит приемка задач заказчиком.
- Какова политика работы с правками и изменениями в требованиях.
Цель второго шага — разработать новый бизнес-процесс. Причем совсем необязательно делать для этого BPMN или какие-то другие лихие схемы. Подойдет и кастомная блок-схема с текстовым описанием. Важнее не то, что вы использовали крутой инструмент, а чтобы это было понятно вам и людям, которым вы будете это презентовать.
Шаг 3. Собрать фидбек
Не спешите внедрять новый флоу, сразу после того как разработали его на бумаге, так как вы могли что-то не учесть, и здесь вам на помощь придет обратная связь от людей, для которых этот процесс и разрабатывается.
Попросите участников процесса покритиковать, «разнести» ваш документ. И относитесь к этому разносу правильно, ведь это делается не для того, чтобы поставить вашу экспертность под сомнение, а чтобы учесть максимум возможных проблем еще до запуска нового процесса.
Не бойтесь каверзных вопросов. Вы всегда можете ответить: «Хорошее замечание, спасибо. Пока у меня решения нет, над ним мне нужно будет поработать». Важно понимать, что эти вопросы могут подсветить проблемы, которые вы могли упустить.
После того, как получите обратную связь, внесите правки, которые учитывают всплывшие недостатки и проведите презентацию для всех причастных. Причем эта презентация не должна быть односторонней — у всех участников должна быть возможность задавать вопросы и уточнять детали.
Когда проводите презентацию каких-то нововведений, обязательно заранее присылайте участникам соответствующие документы для ознакомления. В противном случае, вы проведете презентацию, никто ничего не поймет и вопросов не будет, потому что люди не успеют погрузится в контекст.
Шаг 4: Побороть сопротивление
Когда аналитик начинает вносить изменения, он скорее всего встретится с сопротивлением. Даже если все согласились, будьте готовы к тому, что некоторые будут писать, что стало хуже/неудобно/непонятно.
Люди боятся перемен, потому что даже плохой процесс стал для них понятным и привычным. Люди привыкли «страдать по-старому» и привыкать к чему-то новому страшно. Вдруг лучше не будет, а переучиваться придется в любом случае.
Сопротивление вряд ли будет активным, особенно, если в разработку нового флоу были подключены все причастные, ведь сложнее оспаривать то, в чем сам ты принимал участие. Максимум сопротивления, которое вас ожидает — это жалобы на то, что стало непонятно или неудобно. Хочу отметить, что к этой обратной связи тоже стоит прислушиваться, ведь участники могут обратить ваше внимание на какие-то реальные проблемы. Для того, чтобы понять природу проблемы, просите аргументацию: «Почему это плохо/неудобно?». Если аргументация будет размытой, то скорее всего стоит просто поработать над тем, чтобы сотрудники лучше понимали процесс: провести воркшоп или Q&A-сессию.
Шаг 5: Сопровождение изменений
Очень частая ошибка — не следить за сопровождением изменений. Бизнес-аналитик может считать, что раз он сделал аудит и прописал процесс — на этом его задача завершена. Изменения не внедрены, пока все не привыкли к новому процессу и пока все его не соблюдают. Если процесс не соблюдается — он и не работает.
Еще один важный момент, который необходимо учесть — погружение в процесс новых сотрудников. В большую компанию часто приходят новые люди, и нужно продумать механизм, в котором новички будут знакомиться с процессами, иначе проблемы неизбежны: задачи будут приходить не на тот проект, не с теми компонентами и т.д.
Меньше проблем, если кадры «добираются» — тогда «старший» коллега поможет вписаться в процесс. Когда же кадры приходят на замену, то вместо одной функциональной единицы появляется нефункциональная единица, которая «начинает делать странное».
Жизненный цикл изменения бизнес-процесса: чек-лист
- Провести аудит существующего процесса, записать проблемы
- Записать все возможные решения каждой проблемы в одном документе
- Собрать фидбек со всех причастных со стороны бизнес и разработки.
- Внесите изменения в документацию.
- Сопровождайте изменения, пока им не начнут следовать все.
И помните, что оптимизировать бизнес-процессы в компании могут не только бизнес-аналитики. Если, например, саппорт-специалист увидел проблему в процессах и придумал как ее решить, — он тоже занимается управлением бизнес-процессами.