Привет! Меня зовут Александр Гумановский, и я строю архитектуру бизнес-процессов в компании Hoff Tech. Мы разрабатываем удобные решения для One Retail, а один из наших ключевых клиентов — сеть гипермаркетов мебели и товаров для дома Hoff. 

Процессный подход последнее время набирает популярность, и о нем говорят едва ли не на каждом углу. В этом тексте речь пойдет не о преимуществах или недостатках концепции (таких статей уже много на Хабре). Я расскажу о реальном опыте внедрения подхода на примере Hoff Tech — со всеми трудностями и неудачами, но и, конечно, с успехами. Обо всем этом под катом. 

Что такое процессный подход

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

Другими словами, каждое подразделение может по отдельности выкраивать рукава, пришивать пуговицы и так далее, а в итоге костюм не подходит потребителю, не «сидит». А вот оценка от результата — удобно сидящего костюма и довольного клиента — это тот показатель, что можно и нужно оценить в самом процессе и деятельности каждого его участника.

Управление бизнес-процессами имеет две составляющие: 

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

Вторая — то, как компания подходит к самому управлению процессами. Как планирует, разрабатывает, внедряет, мониторит показатели и оптимизирует процесс, а затем, на основе полученных данных, вновь планирует, разрабатываети внедряет. И так далее. 

Постоянное совершенствование — важная часть процессного подхода.

Hoff Tech на старте внедрения процессного подхода

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

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

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

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

Первые шаги и первые сложности

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

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

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

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

Пересмотр стратегии

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

Так мы стали использовать другой подход: 

• смотрели на существующие или запланированные проекты;

• определяли процессы, которые необходимы для реализации проекта из классификатора процессов или добавляли их туда, если они отсутствовали;

• определяли кроссфункциональные процессы и цепочку создания ценности;

• подтверждали у бизнеса выделенные процессы и их место в классификаторе.

Затем аналитики описывали эти процессы, автоматизировали их и согласовывали с бизнесом. 

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

Сейчас у нас выделено около 800 процессов. При этом мы больше сосредоточены на основных процессах, которые влияют на клиента, —  это продажи, логистика и обслуживание. 

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

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

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

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

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

Первые результаты внедрения процессного подхода

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

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

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

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

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

То есть первоначально была выстроена высокоуровневая модель, которая дала понимание взаимодействий по процессам и показала участки цепочек, на которых возникают проблемы. Это пример классического подхода: найти источник и причины проблемы, а потом ее устранить, а не «тушить пожары», думая, что таким образом устраняем проблему. В итоге, мы смогли повысить индекс качества поставщика на 10%, что изначально было целью проекта.

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

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

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

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

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

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

Задачи и перспективы (и напутствие тем, кто сейчас на пути к процессному подходу)

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

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

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

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

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

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