Трансформация бизнес-процессов: анализ
Хороший процесс лучше плохого.
2.1. Анализ и разработка направлений совершенствования процессов. Введение
Уже лучше совсем не помышлять об отыскании каких бы то ни было истин, чем делать это без всякого метода.
2.1.1. Основы анализа процессов
Вопреки весьма распространенной практике следует сказать: бесцельный анализ – бессмысленное и беспощадное действо. Поиск абстрактных возможностей для улучшения часто приводит как раз к новым, более серьезным проблемам (см. пример, описанный в параграфах 1.1.1 и 1.3.4).
Когда такой веерный вариант анализа может быть оправдан? Когда неудовлетворенность процессом есть, а задачу на изменение поставить не удается. То есть перед нами такой процесс, набравший «блох» (клубок проблем разного типа). И тогда задача фактически (на мозговой подкорке аналитика) звучит как «устранить основные проблемы процесса».
Иногда можно встретить такие инициативные действия внутри компании, когда добрые самаритяне ищут возможности улучшения процесса и предложения «продают» руководству. Что называется, «это жизнь». Ничего плохого в таких активностях нет, они просто не особо эффективны. Важно помнить, что в этих случаях надо аккуратно и достоверно считать эффект и соотносить его с интересами компании, чтобы изменения были позитивными.
Как мы указывали в главе 1.5, в ходе диагностики цель совершенствования процесса не особо важна, хотя и задает направленность исследования. При этом широкий сбор информации может дать такие зацепки, которые при использовании техники «Пять почему» вполне могут оказаться связанными с решаемой проблемой. А вот на этапе анализа именно цель выступает главным фактором.
Задачи анализа процесса (рис. 13):
• независимый (от результатов диагностики) поиск ошибок, слабых мест и уязвимостей/несовершенств в процессе, исследование процесса в деталях;
• определение проблем, решение которых приведет к улучшению значения KPI совершенствования процесса;
• поиск возможных вариантов решения проблем. Иногда помогает переформулирование проблем в вид, пригодный для решения (когда формулировка проблемы является заданием для ее решения). На этом этапе достаточно укрупненной формулировки решения, детали прорабатываются позднее.
Рис. 13. Анализ процесса в ходе его совершенствования
Например, цели совершенствования могут звучать так:
• сокращение времени реализации процесса без дополнительных затрат и потери качества результата;
• снижение потенциального ущерба от выявленных рисков процесса с учетом затрат на противорисковые мероприятия без потери качества результата;
• повышение управляемости процесса с приемлемыми затратами и т. п.
Для проведения анализа используем все доступные средства и инструменты, которые обещают быть полезными в нашей ситуации, с учетом нашей задачи и нашего процесса. Различные виды и инструменты анализа процессов работают с разными видами проблем и ошибок, нацелены на разные задачи. Их, конечно, стоит занести себе на «подкорку», чтобы использовать в нужной ситуации.
Хочу также обратить внимание читателя на обстоятельства, которые будут весьма полезными при анализе.
Структура процесса. Функции в составе процесса могут быть разделены на такие группы, как:
«корневая» часть – последовательность функций, непосредственно направленных на получение результата и необходимых для этого. Отсутствие какой-либо из этих функций приводит к тому, что результат процесса не будет достигнут;
функции передачи и приемки «эстафеты» в выполнении процесса. Являются следствием разделения труда, компетенций и ответственности в организации, отражают ее оргструктуру и принятое в ней на текущий момент распределение функционала и полномочий;
управленческие «навороты» – функции планирования, учета (регистрация и обработка информации: расчет KPI, справки и отчеты и т. п.), контроля (сравнения «план – факт»), анализа (причин отклонений), принятия решений (совещания и пр.).
Разделяя функции процесса таким образом, мы по-разному к ним относимся при разработке корректирующих мер. Например, можем пересматривать распределение функций, полномочий и ответственности, если это нужно для ускорения процесса. Скажем, за счет ликвидации передачи исполнения другому подразделению, делегировав его функцию тем участникам, которые выполняют предыдущие и последующие функции. Функции управления также не являются функциями «созидания», они нагружают процесс дополнительным временем и стоимостью.
Добавленная стоимость. Функции процесса можно также разделить на:
добавляющие ценность или реальную стоимость процессу. Они непосредственно связаны с результатом процесса и удовлетворением клиентских потребностей. Обычно таких «неубиваемых» функций очень мало;
добавляющие стоимость для организации (несущие так называемое business value). Клиенту эти функции не нужны, но они могут быть важны для организации, обеспечивать ее эффективное функционирование. Например, сюда может быть отнесена подготовка управленческих отчетов. Правда, при условии, что они действительно востребованы и влияют на принимаемые решения;
не добавляющие ценности/стоимости. Например, исправление ошибок и переделки, сбор и сохранение чего бы то ни было на всякий случай (когда очевидной и понятной потребности в этом нет), контроль «работы сотрудников», согласования/одобрения/утверждения и т. п.
Такая классификация процессных функций наряду с определением признака «корневая/передающая/управленческая» позволяет осознанно подходить к анализу процесса и поиску решений, правильно понимать их значение и корректно ставить вопрос-задачу. Как оптимизировать корневые функции, добавляющие стоимость? Можно ли сократить что-то из управленческих функций или функций с business value? Может ли быть скорректировано распределение функций, полномочий и ответственности, чтобы ликвидировать передачу выполнения процесса? Возможно ли устранить функции, не добавляющие стоимости? Например, перевозка продукции, сырья и материалов часто нужна из-за того, что расположение мест производства не является оптимальным. Если запасы находятся там, где в них есть потребность, функция перевозки излишня.
Ошибки в описании процесса «как есть» (см. параграф 2.1.4). Качественное описание – весьма важный фактор. Неправильно понимая процесс, мы можем фокусироваться на несуществующих или незначительных фактах в ущерб реальным и существенным. Такой анализ может генерировать ложные заключения и действия. Появление и доведение до практического применения технологии Process Mining (см. главу 2.10) позволяет радикально решить проблему достоверности описания.
Риск увязнуть в анализе и потерять темп проекта. Это особенно актуально, если процесс довольно большой. Если такая угроза реальна, следует спуститься по иерархии вниз и анализировать подпроцессы, стараясь не упускать из виду общую задачу. При анализе полезно задействовать как внутренних экспертов (занятых в процессе и находящихся вне его), так и сторонние ресурсы (консультантов или модераторов/фасилитаторов), которые привносят свежий взгляд или помогают его продуцировать.
Попутные «рацпредложения». Довольно часто в ходе анализа процесса обнаруживаются какие-то возможности его улучшения, прямо не направленные на достижение поставленной цели совершенствования. Принимая решение, что с ними делать (отбросить, или отработать, или отложить на потом), надо учитывать следующие аспекты:
• их рассмотрение и отработка отвлекают от решения основной задачи;
• следует аккуратно оценить эффект и ориентироваться на нижнюю оценку;
• важно принять во внимание влияние реализации «рацпредложения» на решаемую задачу.
Упражнение
Используя модели, построенные при выполнении упражнения в параграфе 1.5.5, классифицируйте функции процессов по признакам «корневая/передающая/управленческая» и «добавляющие ценность процессу/добавляющие ценность организации/не добавляющие ценности».
2.1.2. Разработка вариантов совершенствования процессов
Непосредственным «выхлопом» анализа являются различные варианты решения выявленных проблем или использования обнаруженных возможностей совершенствования процесса. Поиск таких вариантов часто осуществляется в форме мозгового штурма – распространенного метода разработки решений различного рода. Он реализуется в два шага.
На первом шаге задача состоит в свободной и неограниченной генерации идей. Предполагается, что они могут (и должны!) быть сколь угодно безумными и нетривиальными. Впрочем, и очевидные тоже сгодятся. Основные правила первого этапа мозгового штурма:
• выбирается ведущий/модератор;
• формулируется вопрос для разработки идей;
• участники самостоятельно накидывают идеи и озвучивают их;
• критика и оценка, возражения запрещены;
• предложения фиксируются.
На втором этапе следует бережно обсудить зафиксированные идеи, стараясь понять и уточнить их смысл, определить их ценность. Многие «заготовки» решений на этом этапе отбрасываются, остаются наиболее удачные, «финалисты». Такие варианты решений выявленных проблем, устранения ошибок и есть результат анализа процессов.
При отбраковке «непроходных» идей стоит использовать следующий набор критериев:
• насколько рассматриваемое решение соответствует достижению цели совершенствования. Например, если целью совершенствования является «сокращение времени реализации процесса без дополнительных затрат и без потери качества результата», то мы оцениваем потенциал сокращения времени и проверяем отсутствие негативного воздействия на стоимость процесса и качество результата;
• каковы ориентировочные сроки и стоимость внедрения решения. На этом этапе, конечно, еще нет детальной проработки решения, поэтому оценки весьма приблизительные, однако они могут быть сделаны и иногда влияют на выбор решения определяющим образом;
• каковы дополнительные эффекты, связанные с реализацией решения. Скажем, некоторые решения могут быть весьма радикальными, и организации следует принять во внимание готовность к ним.
В последние годы часто применяется электронный мозговой штурм (online brainstorming), использующий интернет-технологии. Анонимность позволяет избавиться от боязни оценки и самоцензуры (когда участники штурма в ожидании своей очереди высказаться пугаются или передумывают).
Кроме того, часто используются такие методы групповой работы, как совещания или дискуссии, реже – метод Дельфы, кольцевой метод и др. Далее приводится короткая характеристика этих методов.
Совещание – групповое обсуждение, в ходе которого решение принимает руководитель.
Дискуссия – вариант совещания, когда решение принимается коллегиально, но утверждается руководителем.
Обычно ведущий совещания или дискуссии делает вводное сообщение, в котором описывает факты и проблему, а также (опционально) предлагает вариант решения проблемы (иногда такие материалы предварительно рассылаются). Затем участники высказываются и обсуждают различные мнения и предложения, постепенно двигаясь к решению.
Метод Дельфы (в честь знаменитого древнегреческого оракула) – решение проблемы в несколько этапов:
• создается рабочая группа;
• она собирает экспертные мнения участников;
• рабочая группа обрабатывает мнения, составляет сводную справку, где группирует сходные варианты и выделяет существенно различающиеся группы мнений;
• участников информируют о результатах обработки. Авторам редких и особых мнений предлагается дополнительно аргументировать свои предложения или пересмотреть их;
• процедура повторяется до тех пор, пока варианты решения не стабилизируются или не сойдутся. Обычно 3–4 раундов достаточно.
• Японский метод кольцевого принятия решения Кингисе. Составляется список экспертов по возрастанию позиции или уровня компетенции: вначале младшие, затем старшие. Проект решения по очереди направляется им на рассмотрение. Каждый эксперт составляет свое заключение и прилагает его к проекту. Заключение касается как самого проекта решения, так и предыдущих заключений. Руководитель рассматривает заключения экспертов и принимает окончательное решение (хотя иногда применяются более хитрые схемы его выбора). Кстати, когда такая схема реализуется очно, она носит название «метод военного совета», так как широко применялась для принятия решений на офицерских собраниях.
Решения следует не только продуцировать такими специальными активностями, но и накапливать в ходе анализа. Важно, что финальная их оценка должна производиться по окончании этапа анализа, когда ясна полная картина.
Сами потенциальные направления совершенствования могут быть выражены в различных действиях. Например, распространены такие:
ликвидация, уничтожение, исключение. Выражается в устранении лишних операций, документов, расходов, препятствий, итераций, выводе из процесса лишних исполнителей/участников и т. п.;
упрощение, сокращение. Это спрямление процесса, сведение разветвленных процедур к одному сценарию, «облегчение» логики и «навороченности»;
изменение, обновление, апгрейд. Выражается в применении новых технологий и решений, изменении логики процесса, расширении его возможностей;
интенсификация, ускорение, автоматизация и т. п. Сокращение времени реализации как за счет изменения процессного дизайна, так и за счет применения различных информационных технологий;
унификация, стандартизация. Приведение дизайна процесса к некоему образцу или стандарту;
системные управленческие изменения. Корректировка принципов взаимодействия сотрудников и подразделений, распределения их функций, полномочий, ответственности и т. д. Процессы корректируются в соответствии с новыми принципами и системными решениями
и другие.
Упражнение
Оцените предложения, сформулированные в ходе локальной диагностики процесса при выполнении упражнения из параграфа 1.5.5, по критериям, приведенным выше в этом параграфе.
2.1.3. Приемы и методы анализа
В ходе совершенствования процесса главным объектом обычно является некий его параметр, например время реализации. Оно может зависеть от множества других параметров: квалификации исполнителей, филиала организации, действий и типа контрагентов, сезонного фактора, уровня исполнительской дисциплины, сложности входящих условий и факторов (например, сложности обрабатываемой заявки) и т. д. и т. п. То есть:
Х = F(α1, α2, α3, α4… αN),
где Х – оптимизируемый параметр процесса; αi (i = 1… N) – параметры, от которых зависит Х. Каждый из них также может быть непростой функцией (допустим, сложность заявки на закупку зависит от вида закупаемого ресурса, требуемых сроков поставки, необходимого финансирования и т. п.).
Таким образом, влияя на различные параметры-аргументы, мы получаем то или иное изменение оптимизируемой функции. Поскольку аргументов много и вид зависимости практически всегда неизвестен, очень важным фактором успешного анализа становится правильно заданный вопрос. В значительной степени это искусство аналитика: задать содержательный вопрос «в точку», подобрать походящий инструмент анализа и получить яркий содержательный ответ, что позволит найти направление действий для совершенствования.
В то же время неправильно поставленный вопрос уводит анализ «не в ту степь» (например, см. миф 4 в параграфе 2.10.5).
Вообще, хочу обратить внимание на проблему эксперта. Безусловно, есть методы анализа, которые поддаются воспроизведению по принципу «делай раз, делай два». Однако качество результатов и ценность продуцируемых идей по корректировке определяющим образом зависят от экспертизы аналитика. В формировании его квалификации главную роль играет сочетание знаний (что решается освоением правильной литературы и обучением, в том числе на практике), опыта (дело наживное), понимания бизнеса как системы на всех его уровнях и во всех взаимосвязях (которое приходит, когда количество знаний и опыта переходит в качество) и креативности как врожденного, но до определенной степени поддающегося развитию свойства. Привлечение к совершенствованию ключевых процессов квалифицированных экспертов хотя бы периодически – нередко вопрос формирования конкурентных преимуществ.
Приемов и методов анализа огромное количество. Более того, это множество открыто и расширяется как специалистами «для себя», так и путем публикаций, как профессиональных, так и не очень.
Наиболее широко используемые и популярные методики и приемы можно классифицировать по следующим признакам:
по объектам анализа (рис. 14). Такие методы фокусируются на некоторой характеристике, параметре, факторе, задаче или возможности;
применяемым в организации системам менеджмента (рис. 15). Фокус и приемы, на которых сосредоточивается управление, диктуют взгляд на процессы и методы анализа. Системы менеджмента содержат «встроенные» приемы анализа, которые следуют системной парадигме и с этой же точки зрения оценивают применимость всех прочих приемов;
точке зрения интересанта или важной для него аудитории (рис. 16).
Рис. 14. Классификация методов анализа процессов по объекту
Рис. 15. Распространенные системы менеджмента
Рис. 16. Методы анализа процессов с точки зрения релевантных для организации сил
В каждой из классификаций речь идет об одних и тех же методах и приемах, просто сгруппированных по-разному. Более того, одни и те же приемы могут попадать в разные «колодцы», то есть нередко не имеют четкой принадлежности. Фактически ситуация похожа на инструменты практикующего хирурга, уложенные в наборе по-разному. Аналитику хорошо бы знать их все и использовать «под задачу».
Важно понимать, что анализ практически никогда не бывает «чистым». Логика и обнаруживаемые факты ведут его по формальным инструментам причудливыми путями: анализировали время – вышли на низкую квалификацию участников процесса – занялись анализом ресурсов и т. п.
Здесь мы рассмотрим наиболее часто встречающиеся методы. Надеюсь, мне удалось собрать достаточно полную «коллекцию».
В различных источниках можно встретить упоминание в числе методов анализа таких, как ранжирование, выделение проблемных областей или SWOT-анализ процесса. Если мы говорим о конкретном процессе, то эти приемы не являются методами анализа по следующим причинам.
SWOT-анализ сводится к прямым ответам на вопрос: «Каковы возможности, угрозы, слабые и сильные стороны процесса?» В отношении процесса «возможности» означают де-факто «Что можно сделать с процессом?», то есть направления совершенствования. Без анализа. Угрозы – это «Что может произойти с процессом, если оставить все как есть?», то есть фантазии по поводу следствий проблем, которые, в свою очередь, представляют собой «слабые стороны процесса». Или по поводу утраты сильных сторон, которые вообще являются странной «похвальбой». Ценность такого «анализа» близка к нулю, а может быть и отрицательной, поскольку он игнорирует собственно целенаправленный поиск причин неэффективности в том или ином аспекте и возможных путей корректировки, совершенствования. Процесс – неудачный объект для SWOT-технологии.
Ранжирование – это один из приемов диагностики системы процессов (см. параграфы 1.3.7 и 1.5.2). К анализу конкретного процесса это не имеет отношения.
Выделение проблемных областей – это метод диагностики (первичного установления фактов), а не анализа (см. параграфы 1.5.3–1.5.5)!
Ну и в заключение этого обзора хочу обратить внимание читателя на ключевую роль достоверности описания и диагностики процесса. Многократно приходилось сталкиваться с тем, что титаническая аналитическая работа и детальная проработка планов совершенствования «убивается» внезапно всплывшей информацией о том, что процесс устроен не так, как описано, или о том, что реальные проблемы процесса совсем не те, на которых были основаны рекомендации по его корректировке.
Невнимание к этому фактору (борьба с несуществующими проблемами и процессом-миражом) может оказаться очень дорогой ошибкой. К счастью, есть отличная новость для хорошо автоматизированных процессов – технология Process Mining, которая гарантированно извлекает реальный процесс из журналов событий (см. главу 2.10). Но и «ручные» процессы можно неплохо оградить от этой опасности (см. параграф 2.1.4).
2.1.4. Анализ соблюдения методологии и ошибок при описании процессов
Проблема невнятного, некорректного, неполного или ошибочного описания процессов – это распространенное явление.
ПРИМЕР
При описании процесса А могут быть упущены используемые при выполнении некоторой функции документы, просто не обозначены на модели. А при анализе модели процесса В, в котором эти документы создаются, была проведена их проверка на востребованность. Не найдя документов в других процессах, аналитик делает вывод о том, что они никому не нужны, и, довольный собой, предлагает их упразднить, не создавать, чем упростить процесс В, сэкономить на трудозатратах и т. п. Если такое предложение будет реализовано, процесс А столкнется с проблемами отсутствия нужной информации, которые придется решать либо постоянными запросами на создание нужного документа, либо развертыванием скандала по поводу поспешно принятого решения об уничтожении документа. А теперь представьте, что эта ошибка массовая, то есть повторяется во многих функциях, относящихся к разным процессам. В этом случае будут дезавуированы многие рекомендации, что очевидно приведет к резкому снижению доверия как к прочим результатам проекта, так и к его участникам, а то и к самой технологии.
К похожим результатам может привести небрежное отношение к наименованиям объектов, когда один и тот же сотрудник, или один и тот же документ, или одна и та же программа названы по-разному. Например, «клиент-менеджер» и Sales Manager, «Сводный отчет» и «Отчет по просроченной дебиторской задолженности на конец месяца», «Эксель» и MS Excel.
При этом часто к описанию процессов относятся пренебрежительно, считая, что это вопрос «школьный» и что главное – это анализ и выводы. Нельзя сказать, что это совсем неправда. Но тогда «школьники», занимающиеся описанием, должны быть «отличниками».
Описанные в примере ошибки – это не проблемы процесса, как нетрудно понять. Но на таком описании строится наше представление об этом процессе, на ложном представлении базируются неверные выводы анализа, а на них – неподходящие коррективы и планы действий, которые либо способны принести прямой вред, либо вызывают недоумение. Поэтому цена ошибки в описании велика.
Проблемы описания можно разделить на две категории:
• несоблюдение методологии и технологии описания, когда моделировщик нарушает Соглашения по моделированию или правила работы, установленные внутри проекта, например создает в модели новый документ, а не копирует его из модели-классификатора[23];
• ошибки по сути, когда (хотя и корректно с точки зрения методологии) в модели отражена неверная или неполная информация, например, пропущен документ или неверно указан исполнитель функции.
Приведу пару примеров ошибок описания.
Ошибки интерфейса. Крайне распространенная ошибка, которую почти гарантированно можно найти в моделях «как есть»:
• вход/выход процесса не совпадает с соответствующим входом/выходом смежного процесса;
• результат работы первого процесса передается второму (например, как показано на рис. 17, если подобное допускается Соглашениями), а тот, согласно описанию смежного процесса, его не получает (то есть там ни у одной функции нет такого входящего документа);
• интерфейсы процесса (вход/выход) не совпадают с входом/выходом его подпроцессов (так называемая иерархическая ошибка интерфейса).
Рис. 17. Отображение передачи документа из процесса в смежный процесс в модели в нотации EPC
Ошибки применения классификаторов. Используемые в описании объекты (документы, подразделения, должности, ИТ-системы и т. п.) отсутствуют в моделях классификаций (классификаторе документов, модели организационной структуры, классификаторе ИТ-систем и т. п.).
Как же и когда следует решать проблему ошибок описания?
Во-первых, как уже упомянуто, утвержденная методология моделирования должна быть в самом начале проекта формализована в виде специального документа, который обычно называется «Соглашения о моделировании» (или «по моделированию»). Кроме того, проектная группа может создавать внутреннюю инструкцию, в которой описываются процедурные и технологические договоренности. Заботой руководителя проекта является такая организация работы, чтобы изложенные в этих документах принципы были уверенно и проверяемо выполнены.
С точки зрения соблюдения методологии проверке обычно подлежат:
• организация хранения моделей (группировка по папкам);
• наименование модели;
• наименования объектов;
• отображение и соответствие интерфейсов на разных уровнях;
• заполнение атрибутов модели;
• заполнение атрибутов объектов;
• отображение связей (типов связей) между объектами;
• наличие объектов в моделях-классификаторах.
Такой надзор осуществляют руководитель проекта описания или методологический эксперт непосредственно в ходе моделирования на постоянной основе. Чем раньше ошибки будут выявлены и устранены, тем лучше. Правильным шагом является также разбор обнаруженных ошибок с командой моделирования, что помогает в поддержании ее тонуса.
Во-вторых, следует предпринимать особые меры, чтобы избежать ошибок по сути. Как повысить уверенность в отраженной на моделях информации? Вот некоторые «фишки»:
• использовать как минимум два взгляда на модель, то есть двух и более экспертов по процессу, которые должны ее подтвердить;
• по возможности моделировать текущие процессы в группе (но именно рядовых исполнителей, без «довлеющего внимания» руководства);
• эксперты по процессу должны подписывать модель («с моих слов записано верно»);
• тщательно и постоянно «обрабатывать» как самих экспертов по процессу, так и их руководителей. Первые должны понимать важность отражения в моделях реальной правдивой ситуации и свою ответственность за это, а вторые – оказывать первым всяческую поддержку. Нельзя допускать эксцессов «защиты мундира»;
• фокусировать внимание моделировщиков на полноте и скрупулезности отражения информации о процессе в модели;
• бросающиеся в глаза шероховатости, неясные моменты и кажущиеся нелогичности следует разбирать сразу же. То есть уточнять, действительно ли это так, как отражено, нет ли тут недопонимания или некорректного отображения. Такой подход должны применять и моделировщики, и методологические эксперты.
Упражнение
Попробуйте провести аудит/оценку своих моделей (старых, например, если есть, или моделей, построенных при выполнении упражнения из параграфа 1.5.5) пары смежных процессов по перечисленным в этом параграфе направлениям, в том числе поискать упомянутые здесь ошибки.