1.5.1. Диагностика как метод исследования процессов
Диагностика – начальный этап работ по трансформации процессов. Объект исследования может иметь различный масштаб: от всех процессов организации (общая диагностика) до одной конкретной процедуры (локальная диагностика).
Диагностика – специфический метод исследования. Ее задача – снизить имеющуюся неопределенность, повысить степень информированности, обеспечить принятие решений. Проводится диагностика в два шага:
• сбор информации;
• обработка информации и формулировка выводов.
На первом шаге собирается информация о составе и проблематике объекта исследования, первопричинах проблем, возможных способах и методах их решения, в том числе задачах, которые могли бы быть поставлены. При этом фиксируется точка зрения сотрудников организации. Сторонний взгляд не привлекается, разве что для модерации и изъятия информации у «местных». Диагност выполняет роль следователя, его задача – набрать достаточный объем фактуры, чтобы «почувствовать» объект исследования.
На шаге обработки информации и формулировки выводов информация должна быть структурирована, осмыслена и использована для аргументированного ответа на вопросы диагностики.
Типичная ошибка организаций, занимающихся трансформацией без привлечения сторонних сил, – пропустить диагностику под лозунгом «И так все всё знают!». Практически всегда (аккуратно говоря; например, в моей практике – просто всегда) это не так. Каждый сотрудник имеет свою картину происходящего, свои интересы и приоритеты, собственные представления о том, как надо, и т. п. Поэтому часто результаты диагностики оказываются сюрпризом для руководства.
Привлекаемым силам (консультантам и экспертам) качественно проведенная диагностика дает возможность быстро и в деталях погрузиться в предмет работ.
Рассмотрим подробнее, как это делается.
1.5.2. Общая диагностика процессов
Общая диагностика проводится в отношении всей системы процессов организации. Такие работы нужны, когда организация хочет оценить всю свою деятельность в целом и сформировать план действий, в том числе в отношении отдельных процессов.
Типичный состав работ общей диагностики:
разработка Модели процессов верхнего уровня;
ранжирование – оценка приоритетности/неудовлетворительности процессов, срочности их трансформации[20] (см. параграф 1.3.7);
• выявление проблем процессов (с точки зрения всех заинтересованных и задействованных сил) и исследование, почему они возникают, в чем их первопричина (см. параграф 1.5.3);
• фиксация способов, которыми, с точки зрения менеджмента организации, можно решить выявленные проблемы, и последовательности их применения;
• формулировка задач на изменение конкретных процессов (см. главу 1.2);
• выявление наиболее актуальных задач трансформации процессов;
• анализ собранной информации и разработка плана действий (проектов) по трансформации процессов с учетом мнений менеджмента и выявленных приоритетов.
Важно помнить, что такой подход неизбежно приводит к списку мероприятий (проектов) широкого спектра в отношении системы управления в целом, не только локализованных в процессных цепочках. Результирующий план действий может содержать проекты, предполагающие применение всех методов трансформации процессов, а также выходящие за пределы собственно процессных решений.
Главная задача общей диагностики состоит в выборе процессов для изменения и определении подходящего метода изменений. Поэтому ответы на вопросы диагностики требуются довольно общие, необходимые и достаточные для решения главной задачи. Не следует на этом этапе углубляться в излишние детали.
Проводится общая диагностика обычно в виде интервью с руководителями и ключевыми сотрудниками, мнение которых важно учесть при разработке общего плана действий.
Что такое качественно проведенная диагностика? Такая, которая приводит к таким результатам, как:
• МПВУ;
• фазовая плоскость (см. параграф 1.3.7) с процессами, нанесенными на нее;
• план трансформации процессов, содержащий:
• проблемы, связанные с процессами;
• первопричины проблем;
• проекты/мероприятия, устраняющие первопричины;
• задачи на изменение для проектов трансформации процессов;
• сроки реализации проектов;
• причинно-следственные связи для взаимосвязанных проектов;
• планируемые результаты проектов;
• привлекаемые ресурсы (сотрудники и аутсорс, бюджет и пр.), проверенные на доступность в течение срока проектов.
1.5.3. Проблемы процессов
Важнейшей частью диагностики, как общей, так и локальной (см. далее), является идентификация процессных проблем. Различают три группы таких проблем.
Общие – проблемы, касающиеся всех или большинства процессов предприятия. Как правило, это проблемы системы управления, вышестоящие по отношению к проблемам процессов (поскольку системные проблемы кросс-процессны). Таковы, например, проблемы взаимодействия подразделений (скажем, нет механизмов горизонтального решения конфликтов и споров, руководители подразделений поодиночке выходят на руководство компании с «жалобами»). Или проблемы мотивирования (отсутствие системы, волюнтаристское вознаграждение по итогам года, когда сотрудники не понимают, что именно вознаграждается в компании). Решение таких проблем в рамках одного процесса иногда просто контрпродуктивно, так как создает перекосы в управлении и проблемы для корпоративной культуры. Например, введение системы мотивирования для конкретного процесса на фоне ее полного отсутствия в компании будет, с одной стороны, ориентировать ее участников на повышенное внимание именно к этому процессу в ущерб другим областям их деятельности, с другой – вызовет справедливые нарекания «обойденных» подразделений. Иногда локальное решение общей проблемы, устраняя ее и ее последствия для конкретного процесса, может послужить прототипом общего решения для предприятия (например, в части отладки взаимодействия подразделений). Но в этом случае важно, чтобы такое действие было предпринято осознанно и акцептовано со стороны высшего менеджмента. Иначе возникнет много разных «прототипов», свести которые к единому решению будет непросто (а это придется сделать, когда островки таких решений начнут сливаться).
Сквозные – проблемы, касающиеся в целом всего бизнес-процесса, к которому относится рассматриваемый. Например, мы занимаемся процессом «Закупки сырья и материалов для собственного производства» и, анализируя установленный факт наличия постоянных претензий производственных подразделений к логистическим по объему и ассортименту поставок, выявили проблему «Отсутствие сквозного планирования деятельности по всему бизнес-процессу». Сотрудники компании вынуждены решать сквозные проблемы «заплаточным» образом. Например, закупщики могут «защититься» от производственников системой заявок и регламентом типа «что мы можем сделать, а что не можем», описывающим сроки, финансы и т. п. Но это решение не изменит ситуацию в целом, так как проблемы производственников останутся: получая постоянные указания по корректировке плана выпуска под текущую ситуацию, они будут работать в режиме лихорадки. Сквозные проблемы должны решаться для всего бизнес-процесса. Например, в описанном примере решение могло бы заключаться в корректировке процесса «Планирование деятельности» через разработку и корректировку сквозных синхронизированных планов.
Локальные (специфические) – проблемы, локализованные внутри процесса/подпроцесса/процедуры. Например, проблема «Каналы продаж не готовы к выводу новых продуктов на рынок» не выходит за рамки процесса «Разработка и запуск новых товаров». Обычно такие проблемы могут быть решены в рамках рассматриваемого процесса (в описанном примере, скажем, при помощи процедуры «Разработка и реализация плана вывода новых продуктов на рынок») или относительно небольшими изменениями в связанных с ним процессах. Например, проблемы недостаточной квалификации клиентских менеджеров решаются в том числе корректировкой корпоративных процедур адаптации и обучения персонала.
1.5.4. Дерево проблем и алгоритм его построения
Сбор фактов, идентификация и формализация проблем не такая простая задача, как может показаться на первый взгляд.
Проблемы, если под ними мы понимаем сложные вопросы, трудности в развитии и функционировании, в данном случае в реализации процессов и управлении ими, могут носить как объективный (грубо говоря, всеми признаваемый), так и субъективный (когда речь идет об индивидуальных сложностях или ви́дении) характер. Кроме того, проблемы сильно переплетены и взаимосвязаны. При ближайшем и тщательном рассмотрении они образуют сложные многоуровневые графы с разными типами связей (причинно-следственных и двусторонних, например). При всем этом сами формулировки и «нарезка» проблем – это субъективное в значительной мере ви́дение объективной (по отношению к стороннему исследователю) картины. То есть разные аналитики представят разные, хотя и близкие по смыслу модели проблем процессов.
К счастью, для целей диагностики в подавляющем большинстве случаев достаточно «наброска» проблемной картины, чтобы понимать приоритеты и цели корректирующих действий.
Далее, в ходе интервью сотрудники компании часто произносят формулировки, которые:
• являются симптомами[21] проблем процесса. Например, рассматривается процесс «Реализация строительного проекта». Интервьюируемый говорит о том, что «подразделения работают несогласованно». Но это следствие какого-то управленческого сбоя. В итоге в конкретном случае проблемой может быть «Отсутствие согласованного оперативного плана проекта». В результате подразделения вынуждены самостоятельно формировать свои планы, отталкиваясь от ранее согласованных реперных точек (а чаще – от своего их понимания). Планы не согласуются и содержат различные сроки выполнения совместных работ, что приводит ко множеству производственных конфликтов и потерям компании. Например, затягиваются общие сроки проекта, так как вовремя не запускаются нужные процедуры. А это не устраивает инвесторов и т. п.;
• содержат в своей формулировке предполагаемое решение. Пример: компания – железнодорожный оператор подвижного состава сформулировала проблему «Отсутствие регламентов взаимодействия с Монополистом». Но почему это проблема? И в этом ли проблема? Желательно такие формулировки раскручивать, чтобы разобраться в ситуации, то есть пытаться идентифицировать те самые симптомы, говорящие как раз о том, с чем сталкиваются участники процесса. В данном случае в качестве симптомов названы «Низкое качество эксплуатации вагонов на инфраструктуре Монополиста» и «Невыполнение Монополистом нормативных сроков доставки вагонов». То есть нормативы на сроки доставки вагонов есть, но даже их наличие не спасает от нарушений? Почему же будет соблюдаться некий новый регламент? При ближайшем рассмотрении было выявлено, что документов, описывающих взаимодействие, хватало. То есть фактически проблема состояла в «Несоблюдении Монополистом договорных документов, регулирующих взаимодействие»;
не имеют отношения к проблемам процесса или крайне расплывчаты, а то и переводят частные ситуации на максимально верхний уровень (типа «Куда же смотрит президент?»). Например, в той же компании были попытки сформулировать проблему «Неполное соответствие организационной структуры решаемым задачам» как закулисье симптомов типа «Логистические схемы для перевозок почти не используются».
Чтобы эффективно разбираться с такими формулировками, хорошо применять, во-первых, так называемое дерево проблем. Это граф, связывающий симптомы проблем с проблемами, которые, в свою очередь, собраны в области компетенций или подсистемы управления (рис. 10).
Выстраивая дерево проблем, аналитик вынужден разбираться с каждой формулировкой: что это – проблема или симптом проблемы? Говорит ли этот признак о наличии чего-то «за спиной», что вызывает его? Или он вполне «самодостаточен»? Строго говоря, жесткого и однозначного определителя, как различить проблему и симптом, не существует. Во многом это управленческая компетенция аналитика. Симптомы вместе с их образующей проблемой создают такие кластеры в управленческом поле. Но и симптом можно принять за проблему и разбираться с ним отдельно, причем вполне успешно. «Разборки» же с проблемой ведут практически без дополнительных усилий к исчезновению целого семейства симптомов.
Кроме того, продумывая формулировки при построении дерева, аналитик должен стараться уходить от того, чтобы называть проблемой нереализованное решение, поскольку именно проблема вызывает то или иное решение. И названное сотрудниками решение не обязательно будет самым эффективным. Ну и надо активно поработать левым полушарием, отвечающим за логику и анализ, чтобы отфильтровать или переработать формулировки, не имеющие отношения к проблемам процессов.
Рис. 10. Пример дерева проблем (фрагмент)
В общем, если удалось с ходу получить корректную формулировку процессной проблемы – вам повезло!
Во-вторых, чтобы разобраться, чем вызваны те или иные симптомы, и дойти до формулировки проблемы, весьма эффективна техника «Пять почему», разработанная еще в 1940-х годах основателем Toyota Сакити Тоёдой. Получив формулировку симптома, раскручивайте ее до упора в проблему, спрашивая вновь и вновь: «Почему так происходит?» Упор наступает после разного количества «почему», пять – не догма.
Эта техника – прекрасный инструмент, помогающий двигаться от симптомов к проблемам, добираться до корневых причин, иначе называемых первопричинами. В результате вы получаете причинно-следственную цепочку, иногда с разветвлениями. Внизу нее – очевидно, симптомы, вверху – первопричины, в середине – проблемы того или иного уровня. Соотношение соседних проблем верхнего и нижнего уровней – это соотношение «проблема – следствие», как правило.
Где остановиться? Стоит соотнестись с уровнем работ. Иногда первопричина настолько глобальна и неподъемна, что в рамках проекта точно нет смысла ею заниматься (например, какие-то проблемы могут быть следствием личных качеств собственника). То есть, раскрутив цепочку, при необходимости ее стоит подрезать сверху и упростить для простоты использования.
Когда связи «симптомы – проблемы» установлены, стоит собрать полученные цепочки в пучки по подсистемам управления или процессам верхнего уровня, чтобы соотнести с зонами компетенции менеджеров, что облегчит работу с решениями и планом действий, да и просто сделает картину логичной (рис. 11). Кроме того, в этих зонах могут быть общие решения, снимающие несколько проблем разом (или претендующие на это).
Рис. 11. Технология построения дерева проблем
Весьма продуктивно строится дерево проблем в ходе практического семинара с участием всех релевантных менеджеров и экспертов организации. В этом случае удается уходить от субъективного взгляда, полученное дерево является предметом консенсуса. Если, конечно, этому не противоречит жесткая корпоративная культура, которая может не давать сотрудникам свободно и аргументированно дискутировать и обсуждать проблемы.
Вставка-инструкция. Общая диагностика процессов организации – один из способов получить расширенный План проектов трансформации процессов (и системы управления!). В процессно зрелых организациях такие работы проводятся регулярно. Если ранжирование, например, выполняется ежегодно, то общая диагностика может применяться как альтернативный «подробный» метод раз в три года или одновременно с пересмотром стратегии. В план входят не только процессные, но и системные проекты.
Упражнение
Постройте дерево проблем процессов компании, применяя технику «Пять почему».
Упражнение
На основании построенного дерева проблем составьте расширенный план проектов трансформации процессов на ближайшие три года в формате, описанном в параграфе 1.5.2.
1.5.5. Как проводится локальная диагностика
Локальная диагностика посвящена конкретному процессу, в отношении которого принято решение о трансформации. Потенциально она может преследовать две разные цели:
выбрать метод трансформации и уточнить задачу на нее. В этом случае диагностика представляет собой вариант общей (см. параграф 1.5.2), когда исследуемый объект состоит из одного процесса и нет задачи установить приоритет работ. Выполняется перед началом работ по изменению выбранного процесса, до его описания, чтобы сформулировать/поставить задачу и попутно решить, стоит ли его вообще описывать;
подготовить работы по анализу процесса и выбору направления его совершенствования. В этом случае метод трансформации выбран (совершенствование) и задача поставлена. Если как метод выбран реинжиниринг, диагностика не проводится.
Во втором случае локальная диагностика выполняется одновременно с описанием процесса. Причем поставленная задача на совершенствование непосредственно определяет требования к этому описанию с точки зрения фиксации необходимой информации[22].
Порядок работ в ходе локальной диагностики следующий:
• описывается выбранный процесс в соответствии с Соглашениями о моделировании, действующими в его отношении;
• выясняется, с какими проблемами (локальными!) процесса (как правило, в тесной привязке к функциям/шагам процесса) сталкиваются заинтересованные стороны – его участники, ВП, клиенты процесса/потребители результатов, вышестоящий менеджмент, координаторы функциональных направлений и пр.;
• разбираемся, почему возникают эти проблемы, в чем их первопричина;
• фиксируем, какие способы решения этих проблем рассматриваются или могли бы быть рассмотрены в организации, какие варианты решения видит сам интервьюируемый эксперт по процессу.
Проблемы, а также рассматриваемые или предлагаемые меры по их решению удобно показывать прямо на моделях процесса в мемополях, визуально привязанных к соответствующим функциям (пример приведен на рис. 12).
Важный вопрос: как влияет на локальную диагностику постановка задачи? Например, если мы хотим ускорить процесс, означает ли это, что все проблемы и «рацпредложения» надо сразу фильтровать, отбирая только те, что непосредственно связаны с сокращением времени?
В принципе, конечно, в дальнейшем в дело пойдут именно такие решения, которые ведут к достижению поставленной цели. Однако на этапе диагностики я не советую заранее захлопывать двери перед формулировками, на первый взгляд не относящимися к этой цели. Последующий анализ может показать, что наибольший потенциал улучшений скрыт как раз в неочевидных точках.
Рис. 12. Результаты описания и локальной диагностики
Упражнение
Выберите актуальный для вас процесс верхнего уровня организации, поставьте задачу на его трансформацию. Смоделируйте процесс в нотации VAD (7–13 функций). Проведите локальную диагностику на этом уровне и вернитесь к формулировке задачи на трансформацию. Она изменилась? Если предполагаемый метод трансформации – совершенствование, смоделируйте процессы на более низком (третьем) уровне в нотации ЕРС и одновременно сделайте детальную локальную диагностику.
1.5.6. Что дальше?
Итак:
общая диагностика позволяет определить приоритеты трансформации процессов организации, выбрать для каждого из них соответствующий метод, поставить/уточнить задачу;
локальная диагностика дает картину процесса с болевыми точками и взглядами организации и ее сотрудников на его изменение. То есть дает то, что врачи описывают в истории болезни в разделе «Объективно»:).
Теперь можно переходить к постановке диагноза и выбору метода лечения. То есть заняться анализом процесса, выбором направления действий, а затем детальной его проработкой. В методе совершенствования процессов это наиболее содержательная работа. Ей посвящен следующий раздел этой книги.
Что же касается метода реинжиниринга, он начинается сразу после общей диагностики и уточнения задачи (требований к целевому процессу), с проектирования целевого процесса. Технология работ будет описана в третьей книге настоящей серии.