Что делать, если вы решили запустить трансформацию бизнеса? Первые шаги в проектировании процессов.

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

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

Начало начал определиться с терминами, чтобы говорить на одном языке.

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

Первый шаг – это выбрать участников проектирования процессов.

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

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

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

«Почему меня не зовут на совещания, как я должен потом внедрять изменения».
it-руководитель

Мне прямо запомнилась эта фраза.

Представители смежных процессов должны проверять, что действия нового процесса положительно скажется на их деятельности. Например, если вы придумали идею, что вы копите все заказы и раз в неделю передаете их на следующий участок, то вы может в вашем отделе работа станет результативнее, но следующий участок будет сидеть неделю без заказов, а потом будет завален ими. Смотреть на процессы надо не отдельно от остальных, а в комплексе и всегда помнить, что главная задача любого процесса – удовлетворение клиентов. И тут надо помнить и о клиентах данного процесса, то есть о тех людях, которые работают с результатами вашей деятельности, так и (самое главное!) о конечных клиентах.

Ведь задача любой организации – удовлетворение потребителя.

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

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

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

Четвертое – фасилитатор. Это функцию может взять на себя руководитель проекта или же это может быть сторонний эксперт с необходимыми навыками. Он должен направлять команду, проектирующую процессы, модерировать совещания, должен знать как выстраивать бизнес-процессы и вести проекты. Если в штате нет специалиста с такими навыками, компания может взять стороннего эксперта, специализирующегося на бизнес-процессах.

Ключевая задача фасилитатора, чтобы ВСЕ участники проекта имели возможность высказать свои замечания и предложения по новому процессу. Это поможет и сделать новый процесс эффективнее, и вовлечет людей в проект и даст им почувствовать причастность к внедряемым изменениям. Именно это поможет на этапе внедрения не бороться с сопротивлениями команды, а эффективно работать над задачами.

Второй шаг – определиться с методом моделирования.

Это может быть как рисование нового процесса «от руки», так и использование сложных программных средств моделирования. Мы в работе использовали доску, ватман и стикеры. Было очень удобно, что вся команда была как бы объединена вокруг нее и исполнитель функции выходил к доске и клеил свой стикер, получалась хорошая командная работа.

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

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

Чаще всего простые схемы оказываются самыми лучшими.

Третий шаг – подготовка к проектированию процесса.

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

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

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

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

И подписывайтесь на мой Телеграмм-канал, пишу про эффективные процессы.

Александра Гостева

12
2 комментария