Текст книги "Преимущество повторяемости – 2. Диагностика и анализ бизнес-процессов. Практическое руководство по бизнес-процессам"

1.4. Как организовать работы. Как вовлечь персонал

Путешествие в тысячу миль начинается с первого шага.

Лао-цзы, китайский философ VI–V веков до н. э.

Если все правильно организовать, то все правильно и пройдет.

Цитата из фильма «Рассказы» (2013, режиссер М. Сегал, Россия)

Кейс 1. Рассмотрим случай с организацией, «девственно невинной» с точки зрения процессов. Есть недовольство тем, как организована ее повседневная деятельность. Появилось относительно поверхностное знакомство с процессной теорией. Руководство считает, что надо начать отстройку процессов.

Начинать имеет смысл с построения карты процессов организации, или Модели процессов верхнего уровня[18]18
  Методику разработки МПВУ см. в: Вишняков О. Указ. соч.


[Закрыть], чтобы представить себе всю «поляну». Затем проводим оценку процессов, как описано в параграфе 1.3.7, и выносим их на фазовую плоскость (ранжирование процессов).

Далее имеет смысл отрейтинговать процессы с точки зрения «срочности задачи». Этот параметр – некая комбинация (сложноформализуемая в общем случае) из приоритетности и неудовлетворительности процесса. Чем они оба выше, тем выше очередность решения задачи.

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

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

Далее ставим задачу, как описано в главе 1.2. Иногда затруднительно сделать это с ходу. В этом случае может помочь диагностика – мы поговорим о ней в главе 1.5.

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

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

Типовой состав ПГ в этом случае:

• руководитель ПГ – он же обычно руководитель всего проекта. Правда, иногда руководитель проекта – обособленный менеджер, вне состава ПГ;

• члены ПГ – сотрудники внутреннего подразделения оргразвития. При его отсутствии – выделенные менеджеры, перед которыми ставится задача стать центром трансформации процессов организации (в виде обособленного подразделения, виртуального или физического, или по совместительству, на part time);

• сторонние привлекаемые консультанты или эксперты.

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

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

Результаты работы РГ по «их» процессам подлежат согласованию с заинтересованными менеджерами и подразделениями и утверждению кураторами[19]19
  Описание бизнес-ролей в процессном управлении см. в: Вишняков О. Указ. соч.


[Закрыть] процессов, как правило. Для этих целей иногда формируется Наблюдательный совет (НС) проекта, в который включаются согласующие и утверждающие сотрудники. Кроме того, если проект реализуются при существенном содействии консультантов, то в НС входят также представители их руководства (куратор и руководитель консультационного проекта).

Для «начинающих» организаций существенную сложность представляет ресурсное обеспечение работ по трансформации процессов (равно как и любых других работ по оргразвитию). Если речь идет о привлечении «играющих» сотрудников, то рекомендация «по умолчанию»: на проект выделяется до 20 % фонда рабочего времени. В ряде случаев это невозможно в силу специфики деятельности, иногда же удается выделить больший ресурс. Кроме того, значительное влияние на решение этого вопроса оказывает как корпоративная культура организации (как принято решать подобные вопросы), так и ее действующая система управления в целом (например, в части мотивирования. Бывают ситуации, когда сотрудники готовы заниматься вопросами трансформации в личное, сверхурочное время). Хочу подчеркнуть, что при планировании проекта важно такую оценку потребного и располагаемого временного ресурса сделать явно, чтобы определить реалистичные сроки. Несмотря на очевидность такой необходимости, по моему опыту, в 80 % подобных проектов приходится переносить сроки из-за излишней оптимистичности первоначальных планов, созданных по принципу «палец – потолок».

Преобразования демонстрируют максимальную эффективность в том случае, если удается обеспечить неформальное вовлечение сотрудников в проводимые работы. Методы и приемы решения этой задачи разнообразны, напомню только некоторые наиболее употребимые, по моим наблюдениям:

• придание работам высокого статуса (декларирование, поддержание, приоритет и т. д.);

• активные коммуникации в рамках проекта: участников – с руководством, НС, куратором и РП, сотрудников ПГ и РГ – между собой (совещания и летучки, расширенные коммуникации с вовлечением персонала организации, непосредственно не занятого в проекте);

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

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

 информационное обеспечение проекта (корпоративные портал, соцсети и СМИ, информационные рассылки и обращения руководства и пр.);

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

 привлечение к мозговым штурмам (brainstorming) в рамках проекта всех желающих (и могущих себе это участие позволить);

• формирование внутри проекта максимально свободной и неформальной мини-корпоративной культуры – это весьма способствует креативности;

 мотивирование (как материальное, так и нематериальное) участников проекта на достижение желаемых результатов;

 вознаграждение участников, добившихся «внеплановых» успехов.

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

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

Реализация проектов поставлена на поток, все необходимые проектные процедуры регламентированы. В том числе описаны процедуры вовлечения персонала: коммуникации, обратная связь, информационное обеспечение, обмен мнениями и предложениями, обучение, привлечение сотрудников к проектным активностям, мотивирование и пр. Обычно все это изначально составляет содержание «Положения о процессном управлении», куски которого в дальнейшем включаются в различные профильные регламентирующие документы («растворяются» в них), проникают в «кровь» организации.

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

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

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

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

1.5. Диагностика бизнес-процессов

Врачи хитры и коварны. Сначала спрашивают, где болит, а потом давят туда.

Народная мудрость

Диагностика – начальный этап работ по трансформации процессов. Объект исследования может иметь различный масштаб: от всех процессов организации (общая диагностика) до одной конкретной процедуры (локальная диагностика).

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

• сбор информации;

• обработка информации и формулировка выводов.

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

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

Типичная ошибка организаций, занимающихся трансформацией без привлечения сторонних сил, – пропустить диагностику под лозунгом «И так все всё знают!». Практически всегда (аккуратно говоря; например, в моей практике – просто всегда) это не так. Каждый сотрудник имеет свою картину происходящего, свои интересы и приоритеты, собственные представления о том, как надо, и т. п. Поэтому часто результаты диагностики оказываются сюрпризом для руководства.

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

Рассмотрим подробнее, как это делается.

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

Типичный состав работ общей диагностики:

 разработка Модели процессов верхнего уровня;

 ранжирование – оценка приоритетности/неудовлетворительности процессов, срочности их трансформации[20]20
  Упомянутые в первых двух пунктах перечня работы иногда выполняются заранее, до проведения диагностики.


[Закрыть] (см. параграф 1.3.7);

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

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

• формулировка задач на изменение конкретных процессов (см. главу 1.2);

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

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

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

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

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

Что такое качественно проведенная диагностика? Такая, которая приводит к таким результатам, как:

• МПВУ;

• фазовая плоскость (см. параграф 1.3.7) с процессами, нанесенными на нее;

• план трансформации процессов, содержащий:

• проблемы, связанные с процессами;

• первопричины проблем;

• проекты/мероприятия, устраняющие первопричины;

• задачи на изменение для проектов трансформации процессов;

• сроки реализации проектов;

• причинно-следственные связи для взаимосвязанных проектов;

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

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

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

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

 Сквозные – проблемы, касающиеся в целом всего бизнес-процесса, к которому относится рассматриваемый. Например, мы занимаемся процессом «Закупки сырья и материалов для собственного производства» и, анализируя установленный факт наличия постоянных претензий производственных подразделений к логистическим по объему и ассортименту поставок, выявили проблему «Отсутствие сквозного планирования деятельности по всему бизнес-процессу». Сотрудники компании вынуждены решать сквозные проблемы «заплаточным» образом. Например, закупщики могут «защититься» от производственников системой заявок и регламентом типа «что мы можем сделать, а что не можем», описывающим сроки, финансы и т. п. Но это решение не изменит ситуацию в целом, так как проблемы производственников останутся: получая постоянные указания по корректировке плана выпуска под текущую ситуацию, они будут работать в режиме лихорадки. Сквозные проблемы должны решаться для всего бизнес-процесса. Например, в описанном примере решение могло бы заключаться в корректировке процесса «Планирование деятельности» через разработку и корректировку сквозных синхронизированных планов.

 Локальные (специфические) – проблемы, локализованные внутри процесса/подпроцесса/процедуры. Например, проблема «Каналы продаж не готовы к выводу новых продуктов на рынок» не выходит за рамки процесса «Разработка и запуск новых товаров». Обычно такие проблемы могут быть решены в рамках рассматриваемого процесса (в описанном примере, скажем, при помощи процедуры «Разработка и реализация плана вывода новых продуктов на рынок») или относительно небольшими изменениями в связанных с ним процессах. Например, проблемы недостаточной квалификации клиентских менеджеров решаются в том числе корректировкой корпоративных процедур адаптации и обучения персонала.

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

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

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

Далее, в ходе интервью сотрудники компании часто произносят формулировки, которые:

• являются симптомами[21]21
  Симптомы проблем – факты, явления и признаки, говорящие о наличии проблемы, являющиеся ее следствием или проявлением, но не самой проблемой. Если сложно установить, проблема или симптом перед вами, по умолчанию лучше считать формулировку проблемой.


[Закрыть] проблем процесса. Например, рассматривается процесс «Реализация строительного проекта». Интервьюируемый говорит о том, что «подразделения работают несогласованно». Но это следствие какого-то управленческого сбоя. В итоге в конкретном случае проблемой может быть «Отсутствие согласованного оперативного плана проекта». В результате подразделения вынуждены самостоятельно формировать свои планы, отталкиваясь от ранее согласованных реперных точек (а чаще – от своего их понимания). Планы не согласуются и содержат различные сроки выполнения совместных работ, что приводит ко множеству производственных конфликтов и потерям компании. Например, затягиваются общие сроки проекта, так как вовремя не запускаются нужные процедуры. А это не устраивает инвесторов и т. п.;

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

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

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

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

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

Рис. 10. Пример дерева проблем (фрагмент)

В общем, если удалось с ходу получить корректную формулировку процессной проблемы – вам повезло!

Во-вторых, чтобы разобраться, чем вызваны те или иные симптомы, и дойти до формулировки проблемы, весьма эффективна техника «Пять почему», разработанная еще в 1940-х годах основателем Toyota Сакити Тоёдой. Получив формулировку симптома, раскручивайте ее до упора в проблему, спрашивая вновь и вновь: «Почему так происходит?» Упор наступает после разного количества «почему», пять – не догма.

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

Где остановиться? Стоит соотнестись с уровнем работ. Иногда первопричина настолько глобальна и неподъемна, что в рамках проекта точно нет смысла ею заниматься (например, какие-то проблемы могут быть следствием личных качеств собственника). То есть, раскрутив цепочку, при необходимости ее стоит подрезать сверху и упростить для простоты использования.

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

Рис. 11. Технология построения дерева проблем

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

Вставка-инструкция. Общая диагностика процессов организации – один из способов получить расширенный План проектов трансформации процессов (и системы управления!). В процессно зрелых организациях такие работы проводятся регулярно. Если ранжирование, например, выполняется ежегодно, то общая диагностика может применяться как альтернативный «подробный» метод раз в три года или одновременно с пересмотром стратегии. В план входят не только процессные, но и системные проекты.

Упражнение

Постройте дерево проблем процессов компании, применяя технику «Пять почему».

Упражнение

На основании построенного дерева проблем составьте расширенный план проектов трансформации процессов на ближайшие три года в формате, описанном в параграфе 1.5.2.