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

Изменение процесса – это проект или процесс?

Есть два подхода к изменению процесса. Если мы меняем процесс проектным образом, нам следует сформулировать, чего именно мы хотим от него добиться. Причем сделать это нужно по возможности четко и в цифрах, например: сократить время выполнения процедуры на 30 %. В этом случае понятно, когда надо завершать работу, – когда результат будет получен! И можно рассчитывать на то, что это ограниченная по времени работа. Другой подход предполагает, что изменением процесса мы занимаемся постоянно. Тогда изначальная постановка задачи максимально широкая, фактически речь просто идет об улучшении процесса или повышении его эффективности (что бы это ни значило в тот момент). То есть задача превращается в «тему». Ограничений никаких, полная свобода самовыражения и амбиций. Просто надо постоянно доказывать, что те или иные изменения реально полезны бизнесу и овчинка стоит выделки. Не надо путать этот подход с реализацией цикла CPI: в последнем задачи на изменения возникают при определенных условиях, четко формулируются и решаются в ходе отдельного проекта.

Взгляд на изменение снаружи и изнутри процесса

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

Сколько измерений /метрик у задачи на изменение?

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

Какая информация о показателе достоверна?

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

Реализация управленческих решений в процессах: сила в деталях

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

Процессу для изменения нужна детальная задача

Аналогичным образом обстоит дело, допустим, в проекте внедрения системы класса workflow[5]5
  ИТ-решение для автоматизации выполнения бизнес-процессов.


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

«Опрокидывание» проекта изменения процессов

Делать это следует без фанатизма, чтобы не превратить проект в совершенно другую работу – по трансформации процессов. В этом случае, если приоритет трансформации станет выше приоритета, например, автоматизации, проект «опрокидывается»: ИТ-решение становится лишь средством и замысел проекта начинает плыть и искажаться, требуя значительно бо́льших трудозатрат и внимания именно к управленческим изменениям, а не к ИТ, что чревато фиаско по срокам, бюджету и результату. И тогда логика процессной трансформации может вызывать вопросы к бывшей «главной» задаче и подвергать ее сомнению, а то и приводить к изменению. Такие качели явно не в интересах организации. Определение приоритетов и формирование четкой цели – прерогатива более раннего этапа. Когда дело доходит до процессов, должно быть уже четко понятно, чем мы занимаемся. Именно поэтому задача изменения процессов в проектах регламентации/оргизменений/трансформации всегда имеет второй приоритет, хотя представляет собой чуть ли не основное по объему содержание работ. Тем не менее ставить задачу и определять целевые показатели для измененных процессов следует обязательно!

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

ПРИМЕР

Компания имеет высокий уровень дебиторской задолженности. Такая ситуация создает для нее проблемы с развитием. Решая их, компания обратила внимание на процесс «Управление дебиторской задолженностью (ДЗ)», который находится в зачаточном состоянии в виде отдельных процедур типа подготовки и отправки писем-напоминаний клиентам. Все остальное реализуется по специальному решению. Изначально формулировка задачи на изменение звучала как «минимизация ДЗ». Легко понять, что такую задачу можно рассматривать как цель процесса, но как задача на изменение она не годится (см. параграф 1.2.2).

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

В итоге в качестве KPI изменения процесса использовалось «Наличие полного цикла управления всеми видами ДЗ на протяжении всего жизненного цикла ДЗ».

Таким образом, для постановки задачи на изменение процесса мы должны:

• определить требуемое направление изменения;

• максимально его детализировать, все время отвечая на вопрос «За счет чего?» или «Каким образом?»;

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

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

Задача должна содержать целевое значение оптимизируемого параметра и ограничения на остальные параметры и используемые инструменты улучшения. Например: сократить стоимость процесса на 20 %, не увеличив время выполнения и не снизив качество результата, только за счет локальных решений (то есть ограниченных рамками процесса).

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

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

SMART – сокращение от англ. Specific (конкретный), Measurable (измеримый), Achievable (достижимый), Relevant (соответствующий, важный), Time bound (ограниченный во времени, определенный по срокам).

По мере уточнения задачи на изменение процесса появляется шанс определить KPI собственно изменения, то есть измеритель, который однозначно ответит на вопрос, добились ли мы необходимого или ожидаемого успеха в процессной трансформации. Если мы ограничиваемся качественным описанием задачи, то попадаем в ситуацию субъективных оценок: мнение об успехе и конце работ будет определяться личностью (квалификацией, опытом, взглядами, интересами и т. п.) того, кто выносит суждение. Известная ситуация: «Угадайте, что я задумал! Нет, не угадали, я уже передумал!» – причина многих конфликтов.

При этом выбранный показатель должен относиться именно к процессу, не выходить за его рамки. Отсюда прямое следствие: на ранней стадии, когда мы имеем дело с бизнес-задачей, решение которой лежит не только в процессе, но и в системе управления в целом, определять KPI изменения процесса абсолютно бессмысленно!

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

Показатели процессов, как известно[6]6
  Вишняков О. Указ. соч.


[Закрыть], делятся на два вида:

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

 КПХ – ключевой показатель хода процесса (KPI хода процесса, или Process Execution KPI) – характеризует ход процесса. Допустим, для процесса «Квартальное планирование закупок» примером КПХ может быть бинарный показатель «Проект квартального плана закупок подготовлен и поступил на согласование до 25-го числа месяца, предшествующего кварталу».

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

С другой стороны, процессные KPI выступают в качестве измерителей процессных характеристик[7]7
  Там же.


[Закрыть]. Среди них можно выделить три базовых параметра или группы: Время выполнения – Стоимость – Качество (рис. 3). К ним обычно могут быть сведены все требования к улучшению. Этот «треугольник параметров» напоминает «проектный треугольник» (рис. 4): Срок – Бюджет – Результат/Объем (Scope) – и имеет сходный смысл[8]8
  См., например, https://asana.com/ru/resources/project-management-triangle.


[Закрыть].

Рис. 3. Базовые параметры (группы характеристик) бизнес-процессов

Рис. 4. «Проектный треугольник»

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

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

К группе «Качество» относятся прочие характеристики: результативность, определенность, управляемость, повторяемость, гибкость, качество результата и эффективность, производительность или мощность процесса и т. д.

С организационной точки зрения выбор KPI – предмет обсуждения и дискуссий с[9]9
  Описание процессных бизнес-ролей см. в: Вишняков О. Указ. соч.


[Закрыть]:

• владельцем процесса (ВП) – он представляет интерес процесса изнутри;

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

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

• куратором процесса – он в большинстве случаев защищает системный взгляд на бизнес-задачу;

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

Их в идеале консолидированное мнение дает фокус желаемых изменений.

Конечно, поставить задачу на улучшение процесса в формате «сократить стоимость процесса на 20 % при сохранении качества, измеряемого как процент приемки продукта внутренним ОТК без замечаний, притом что время выполнения не превысит нормативное» – весьма желательный вариант. Однако практика показывает: это все-таки редкость, что объясняется невысоким в целом уровнем процессной зрелости большинства организаций[10]10
  Процессная зрелость, зрелость процесса – это степень, в которой конкретный процесс удовлетворяет требованиям определенности, управляемости, измеримости, контролируемости и результативности.


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

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

ПРИМЕР

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

• Управление реализацией сквозного проекта.

Задача: разработка единого регулярного, эффективного и удобного процесса управления сквозным проектом на базе функционирующего Проектного Комитета (ПК).

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

• Разработка и утверждение план-графика и бюджета строительного проекта.

Задача: повышение эффективности планирования строительных проектов с точки зрения обеспечения в отношении проектных план-графиков, бюджетов доходов и расходов и cash-flow-календарей:

• синхронизации;

• фиксации статусов;

• своевременной корректировки;

• своевременной детализации;

• максимальной реалистичности сроков;

• сокращения сроков согласований;

• полноты мероприятий план-графиков;

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

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

• Управление регламентной базой.

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

• «навязчивую» доступность и простоту использования;

• фиксацию статуса;

• регулярное обновление;

• введение бизнес-роли ответственного сотрудника за разработку и актуальность в отношении каждого регламентного документа;

• актуальность и контроль исполнения;

• своевременное упразднение.

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

Ну и в любом случае всегда есть место для ошибок и неверной постановки задач. Несколько дней назад столкнулся со следующим примером.

ПРИМЕР

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

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

Упражнение

После чтения параграфов 1.2.3–1.2.5 вы бы скорректировали KPI изменения процесса, определенный в ходе выполнения упражнения к параграфу 1.2.2?