2. Постановка задачи на изменение процессов
Правильно поставить задачу – значит наполовину решить ее.
Как вы яхту назовете, так она и поплывет.
Мне кажется, что этому вопросу уделяется незаслуженно мало внимания. Как минимум непропорционально его важности. Между тем точность постановки задачи во многом определяет итоговый результат любой трансформации.
1.2.1. От бизнес-задачи к изменению процесса
В моей практике почти не встречалось случаев, когда руководство компании-клиента перед началом проекта, посвященного изменению процесса, знало/понимало бы или (еще круче) могло сформулировать задачу на это изменение.
ПРИМЕР
Трейдинговая компания, специализирующаяся на угле и ферросплавах, перед внедрением ERP-системы решила навести порядок в бизнес-процессах. Соответственно в техническое задание для консультантов была вписана задача совершенствования основного бизнес-процесса. И далее – никакой ее конкретизации, только описание технологических шагов: диагностика, выявление проблем, их анализ и пр.
В ходе проекта консультанты пытались добиться единого понимания топ-менеджерами того, что означает это самое совершенствование. Вот список (передан общий смысл) названных топами проблем наивысшего приоритета (подчеркну, что речь в интервью шла именно о проблемах процесса, то есть интервьюируемые пытались фокусироваться именно на процессе, как они его себе представляли!).
1. Проблемы во взаимодействии с бухгалтерией на аутсорсинге.
2. Нехватка своевременной управленческой отчетности.
3. Отсутствие единой планово-учетной системы.
4. Функционал, полномочия и ответственность подразделений не согласованы и не доведены до сотрудников.
5. Много ручной работы.
6. Низкая скорость и качество документооборота.
7. Размытая ответственность на многих участках, дублирование, невыполнение важных функций, непрозрачные и неэффективные взаимодействия между подразделениями.
Целый ряд этих проблем не решается в рамках проекта по совершенствованию основного бизнес-процесса. Требуется выход за его рамки, работа с корпоративной ИТ-архитектурой (проблемы 2, 3, 5, 6), системой управления и организационной структурой (проблемы 1 и 4). В рамках проекта возможно серьезно заняться проблемой 7 и частично – проблемами 5 и 6. Поэтому в итоге задача на совершенствование основного бизнес-процесса была сформулирована так.
1. Исправить локальные проблемы процесса, в том числе:
• отладить взаимодействие и координацию между подразделениями, а также процедуры эскалации;
• обеспечить разгрузку руководителей, где это допустимо;
• регламентировать процесс.
2. Оптимизировать скорость и качество документооборота и принятия решений, ликвидировать временные потери, в том числе:
• за счет максимального использования стандартных условий и заготовок контрактов, а также ликвидации потерь времени обеспечить среднюю длительность согласования контрактов не более двух дней;
• обеспечить участие в процедуре согласования и подписания контрактов всех ключевых подразделений – правового, финансового, операционного и трейдингового.
Казалось бы, в чем проблема? После обсуждения того, что беспокоит топов, сузили задачу до сферы ответственности собственно процесса. Но психологически топы изначально настраиваются на то, что в результате таких проектов будут решены все проблемы, которые их беспокоят и которые они упоминали в интервью. Происходит это чаще всего потому, что само понятие «процесс» им малознакомо и слабо ими ощущаемо. Поэтому, когда в итоговом списке остается меньшая часть, а некоторые топы вообще не видят того, о чем говорили, их энтузиазм резко улетучивается.
Почему же так происходит? Почему бизнес-задача так «усыхает», когда мы пытаемся выставить ее бизнес-процессу, «лежащему внутри»?
Дело в том, что решение в значительной степени зависит также от участвующих в процессе людей и используемых технологий, что является отражением так называемого золотого треугольника «Люди – Процессы – Технологии» (рис. 1).
Рис. 1. «Золотой треугольник» PPT Framework
Концепция «Люди – Процессы – Технологии» (People – Process – Technology)[3] – популярный бизнес-метод. Она утверждает, что для максимизации эффективности организационных изменений следует сбалансировать все три компонента и поддерживать равновесие между ними. Эту концепцию часто называют «золотым треугольником» (Golden Triangle) или PPT Framework. Принято считать, что автором концепции является доктор Гарольд Ливитт (Harold Leavitt), американский психолог управления, который разработал ее основные положения в 1960-е годы.
ПРИМЕР
Бизнес – производство определенной категории товаров повседневного спроса. Компания пытается выстроить продажи в обход федеральных дистрибьюторов, которые занимают в отрасли очень сильные позиции. Да и в целом действующая модель взаимодействия с торговыми каналами перестала удовлетворять руководство компании из-за того, что не позволяет выдерживать конкуренцию, притом что продуктовая линейка, по различным независимым оценкам, – из лучших на рынке.
Компания начала решение задачи с аудита системы продаж. В результате требуемые изменения оказались рассредоточены по различным областям (рис. 2). И бизнес-процессы тут – лишь одна из них.
Рис. 2. Локализация элементов решения бизнес-задачи в различных подсистемах управления (иллюстрация к примеру)
В частности, оказалось, что блоки маркетинга и продаж в группе компаний из-за личностного конфликта их руководителей фактически изолированы. Сквозные процессы и сотрудничество упразднены, общение происходит через генерального директора.
В этой ситуации, с одной стороны, понятна конкурентная слабость коммерческого блока, а с другой – невозможно выстраивание каких бы то ни было новых эффективных процессов. Поэтому, прежде чем ставить задачи для изменения собственно процесса, нужно было бы решить ряд проблем в других областях.
Результатом аудита стал план развития системы продаж. Процессный блок в нем был представлен одним проектом, который стартовал через два месяца после начала реализации плана, поскольку в первую очередь следовало решить стратегические и системные вопросы. Задачи на проект совершенствования процессов были сформулированы так.
• трансформировать (частично спроектировать, частично усовершенствовать, устранить очевидные легко решаемые проблемы) на уровне взаимодействия руководителей/подразделений процессы «Планирование продаж» и «Планирование закупок» с целью установить горизонт скользящего интегрированного планирования продаж, закупок и движения денежных средств шесть месяцев;
• спроектировать необходимые для эффективной работы, но отсутствующие в настоящее время процедуры взаимодействия блока маркетинга и блока продаж.
Таким образом, изменение процесса довольно редко является исчерпывающим решением бизнес-задачи, беспокоящей руководство компании. Чаще всего это лишь один из компонентов. Другое дело, что почти всегда системные изменения отражаются на том, как компания работает, а значит, на ее процессах. То есть решение большинства бизнес-задач в конце концов приводит к изменению процессов.
Однако при этом имеет право на жизнь и успешное применение другая парадигма: реализуя концепцию Continious Process Improvement (CPI)[4], компания может на постоянной основе мониторить эффективность и совершенство своих процессов. Обнаруживая проблемы и занимаясь их решением, компания должна понимать место процессов в системе управления. При необходимости она может выходить за рамки чисто процессных изменений, например пересматривая функционал, ответственность и полномочия подразделений, да и саму их нарезку, то есть занимаясь вопросами оргструктуры. А затем уже на новой базе перестраивать процессы, то есть двигаться от эффективности процессов к решению бизнес-задач.
Упражнение
Выберите процесс, который в вашей компании в наибольшей степени нуждается в изменении, с вашей точки зрения. Попробуйте сформулировать бизнес-задачу и задачу на изменение процесса. Они различаются или совпадают? Почему?
1.2.2. Показатель процесса и показатели изменения процесса
Изложенное в предыдущем параграфе позволяет сделать и другой важный вывод. Казалось бы, соблазнительно в формулировке задачи на изменение процесса использовать его показатели, ведь именно они говорят о процессных характеристиках.
Например, для процесса «Продажи» характеристикой производительности является объем продаж. Безусловно, это его ключевой показатель результативности (КПР). Но характеристика ли это только и именно процесса? Нет! Почему? Процесс может быть одним и тем же, но в различных условиях давать разный результат в части производительности (в данном случае процесс продаж остается неизменным, а объем продаж с течением времени меняется радикально). Предположим, у нас изменился персональный состав отдела продаж – мы заменили новичков опытными сотрудниками или наоборот. Или получили возможность использовать электронные документы во взаимодействии с клиентом, проводить видео-конференц-коллы. Возможно, мы создали товар-бестселлер. Либо экономика вошла в полосу кризиса и т. п. Показатель может меняться в разы.
Поэтому постановка задачи на изменение требует анализа: какой из параметров и субпараметров «золотого треугольника» препятствует росту КПР – люди, технологии (во всем их многообразии) или процессы. Если процессы, то в чем именно этот «тормоз»? И тогда задача на изменение должна ставиться в отношении «тормоза».
Таким образом, поставить задачу на изменение процесса «Продажи» в виде «Увеличить объем продаж» – некорректно. Надо определить, где в решении этой бизнес-задачи зона ответственности процесса, и именно там искать KPI для постановки задачи на изменение. Например, процесс должен быть способным к обработке не менее чем 100 клиентских запросов в день с соблюдением стандартных параметров: коммерческое предложение (КП) должно быть отправлено не более чем через неделю с момента поступления запроса. Или если нас беспокоит оперативность отклика на запросы клиента, то постановка задачи может быть такой: сократить время подготовки КП на 20 %.
Таким образом, в общем случае показатель процесса не есть показатель для его изменения.
Впрочем, можно подойти к решению задачи улучшения процессов и «снизу вверх», выбирая для всех процессов важный КПР и ставя задачу его улучшить, то есть для процесса «Продажи», например, «Увеличить объем продаж». И далее искать способы решения этой задачи, не ограничиваясь (важно!) коррекцией процессов, а при необходимости выходя за их рамки. То есть такая задача имеет уровень системы управления и стратегии, а не процесса (в большинстве случаев). Конечно, принимаемые системные решения чаще всего найдут отражение в процессах, но решение принимается за рамками процесса.
ПРИМЕР
Компания столкнулась с падением рыночного спроса, в результате чего уменьшился объем продаж. Действующая система управления бизнес-процессами на основании критического падения значения КПР процесса «Продажи» инициирует поиск решений возникшей проблемы. Рассматриваются различные гипотезы, в частности: ввод новых продуктов, апгрейд существующих, в целом пересмотр продуктовой линейки, изменение состава групп фокусных продуктов. В части процессов рассматривается частная задача – повышение их коэффициента полезного действия (КПД), то есть отношения числа заключаемых контрактов к количеству лидов. При этом предполагается, что входной напор (количество лидов) довольно слабый.
В то же время на подъеме рынка, если бы достигаемые значения объема продаж были существенно ниже плановых, следовало бы искать аналогичные процессные решения (по увеличению КПД) при сильном входном напоре. То есть, несмотря на внешнюю схожесть, при различных характеристиках окружения процесса решаются разные задачи (и, соответственно, принимаемые решения различны), хотя исходный процесс может быть одним и тем же.
Таким образом, постановка задачи на изменение процесса абсолютно контекстна и в значительной степени зависит от характеристик бизнес-среды, состояния используемых ресурсов, этапа развития компании, ее долгосрочных и текущих задач и приоритетов.
И как следствие: нет идеальных процессов, подходящих всем и при любых условиях! Точно так же, как нет идеальных стратегий, идеальных наборов KPI для компании, должностной позиции и сферы деятельности. Все это контекстно, поэтому бессмысленно и вредно искать готовые решения (разве что в качестве «рыбы»), надо учиться решать задачу для своей ситуации!
Упражнение
В отношении процесса, выбранного в упражнении после параграфа 1.2.1, определите KPI процесса и KPI изменения процесса. Они различны или совпадают? Почему?
1.2.3. Некоторые нюансы постановки задачи на изменение процесса
Изменение процесса – это проект или процесс?
Есть два подхода к изменению процесса. Если мы меняем процесс проектным образом, нам следует сформулировать, чего именно мы хотим от него добиться. Причем сделать это нужно по возможности четко и в цифрах, например: сократить время выполнения процедуры на 30 %. В этом случае понятно, когда надо завершать работу, – когда результат будет получен! И можно рассчитывать на то, что это ограниченная по времени работа. Другой подход предполагает, что изменением процесса мы занимаемся постоянно. Тогда изначальная постановка задачи максимально широкая, фактически речь просто идет об улучшении процесса или повышении его эффективности (что бы это ни значило в тот момент). То есть задача превращается в «тему». Ограничений никаких, полная свобода самовыражения и амбиций. Просто надо постоянно доказывать, что те или иные изменения реально полезны бизнесу и овчинка стоит выделки. Не надо путать этот подход с реализацией цикла CPI: в последнем задачи на изменения возникают при определенных условиях, четко формулируются и решаются в ходе отдельного проекта.
Взгляд на изменение снаружи и изнутри процесса
Допустим, нас интересует качество процесса. Трактовок этой характеристики может быть много. Скажем, мы проводим мониторинг клиентского мнения и качество процесса истолковываем как его «удовлетворение клиентскому ви́дению». Казалось бы, подберем соответствующий показатель – и дело в шляпе? А как с этим ви́дением связана такая характеристика, как «наличие и серьезность клиентских рекламаций»? Скорее всего, в ви́дении клиента она просто не возникает (зачем ему заниматься рекламациями? Он хотел бы процесс без проблем, более того, с wow-эффектом!). А для компании как раз работа с рекламациями может быть весьма серьезным вопросом именно для того, чтобы добиться «соответствия клиентскому ви́́дению». Значит, нам надо разделять некую идеальную картинку (которая есть в клиентском ви́дении) и ту, которую можно считать перспективной на текущем этапе развития компании!
Сколько измерений /метрик у задачи на изменение?
Помимо основной характеристики, на которую мы направляем изменение, у процесса есть и другие. Например, стабильность и воспроизводимость результатов процесса характеризует «повторяемость». Возможно, оптимизируя качество, мы попутно захотим сосредоточиться на этой характеристике? Или, сокращая время исполнения процесса, можем (и чаще всего должны) обозначить «цену вопроса»: не за счет качества и стоимости, например. Тогда в постановке задачи появляются дополнительные характеристики и показатели. Вообще, сколько показателей должно присутствовать в постановке задачи на изменение? Простые размышления приводят к тому, что в большинстве случаев задача на изменение – многомерная конструкция. Если не учесть эту многомерность сразу, она все равно всплывет при принятии решения, годится ли то или иное решение задачи для реализации. Со стороны такая процедура будет напоминать чистую вкусовщину (и обычно ею и являться), будучи прямым следствием небрежно поставленной задачи.
Какая информация о показателе достоверна?
Следовательно, когда речь идет о показателях, которые являются обработкой оценок, надо разделять те, что получены извне, например потребителями результатов процесса, и изнутри, его участниками. Скажем, нас интересует обработка службой технической поддержки запросов клиентов (тут даже неважно, внутренних или внешних по отношению к компании). Предположим, что, как это часто бывает, специалист службы сам решает, в какой момент ему закрыть заявку. Вот уж тут взгляды на показатели типа «среднее время выполнения заявки» могут сильно различаться в зависимости от того, опрашиваем ли мы клиента или считаем значение по данным чата, в котором специалист с ним общался. Бывает, что при таком подходе клиент вынужден инициировать целый ряд заявок по одному и тому же поводу (которые его визави закрывает после шаблонного ответа по ключевым словам), пока ему удастся достучаться до оператора службы техподдержки со своей проблемой.
Реализация управленческих решений в процессах: сила в деталях
Как мы уже установили в предыдущей главе, в проектах регламентации, организационных изменений и автоматизации процессы не являются главным объектом изменений, их фокусом. Скорее ключевые решения этих проектов должны быть реализованы в деталях через процессы. Но эти ключевые решения не охватывают все детали, а значит, оставляют значительную степень свободы в том, как реализовать конкретный процесс. Например, мы как компания переходим от работы с крупными дистрибьюторами к взаимодействию с розницей (скажем, таково решение штаб-квартиры или акционеров). Меняется управленческая модель. Решение принято и должно быть реализовано. Но в деталях процесс обработки заказа и поставки продукции, например, можно реализовать по-разному. А как именно – самостоятельная задача, в которой новая схема дистрибуции – просто входящее условие или ограничение. Качество решения этой задачи может либо усилить, либо дискредитировать управленческое решение.
Процессу для изменения нужна детальная задача
Аналогичным образом обстоит дело, допустим, в проекте внедрения системы класса workflow[5]. Эта технология практически не ограничивает свободу проектировщика процесса. А в ходе проекта регламентации процессов приходится постоянно принимать решения, какие практики перенести в нормативный документ. А может, существующие алгоритмы не годятся и следует что-то изменить? Например, процесс содержит явные ошибки, которые надо устранить. То есть задачи типа «обеспечить в процессах реализацию организационного решения/работоспособность ИТ-системы/нормативные решения» все равно следует детализировать и уточнять в отношении конкретных процессов, иначе есть риск получить формально работоспособные, но неудовлетворительные с точки зрения эффективности процессы.
«Опрокидывание» проекта изменения процессов
Делать это следует без фанатизма, чтобы не превратить проект в совершенно другую работу – по трансформации процессов. В этом случае, если приоритет трансформации станет выше приоритета, например, автоматизации, проект «опрокидывается»: ИТ-решение становится лишь средством и замысел проекта начинает плыть и искажаться, требуя значительно бо́льших трудозатрат и внимания именно к управленческим изменениям, а не к ИТ, что чревато фиаско по срокам, бюджету и результату. И тогда логика процессной трансформации может вызывать вопросы к бывшей «главной» задаче и подвергать ее сомнению, а то и приводить к изменению. Такие качели явно не в интересах организации. Определение приоритетов и формирование четкой цели – прерогатива более раннего этапа. Когда дело доходит до процессов, должно быть уже четко понятно, чем мы занимаемся. Именно поэтому задача изменения процессов в проектах регламентации/оргизменений/трансформации всегда имеет второй приоритет, хотя представляет собой чуть ли не основное по объему содержание работ. Тем не менее ставить задачу и определять целевые показатели для измененных процессов следует обязательно!
1.2.4. Задача на изменение процесса: эволюция и формулировки
Думаю, сказанное ранее должно свидетельствовать о том, что задача на изменение конкретного процесса имеет явную эволюционную суть. Откуда бы она ни происходила, где бы ни находились «ее корни»: снаружи процесса, в системе управления или внутри процесса, задача должна постепенно уточняться до состояния, генерирующего практически однозначное решение. То есть она эволюционирует путем постепенной утраты степеней свободы.
ПРИМЕР
Компания имеет высокий уровень дебиторской задолженности. Такая ситуация создает для нее проблемы с развитием. Решая их, компания обратила внимание на процесс «Управление дебиторской задолженностью (ДЗ)», который находится в зачаточном состоянии в виде отдельных процедур типа подготовки и отправки писем-напоминаний клиентам. Все остальное реализуется по специальному решению. Изначально формулировка задачи на изменение звучала как «минимизация ДЗ». Легко понять, что такую задачу можно рассматривать как цель процесса, но как задача на изменение она не годится (см. параграф 1.2.2).
Поэтому следующим шагом был поиск ответа на вопрос «За счет чего?», и этим ответом оказалось: «За счет повышения управляемости», то есть осуществления регулярной осмысленной деятельности по управлению ДЗ. Выдвинута гипотеза, что для этого необходимо спроектировать цельный процесс (вместо скудного набора разрозненных процедур), отдельные шаги которого инициируются событиями, связанными с превышением пороговых значений параметров ДЗ (ее сроков и суммы), а также зависящими от категории контрагента, а не случайными решениями менеджмента. Ограничениями выступили время и стоимость процесса, которые были определены путем обсуждения потенциальных участников, владельца и куратора процесса.
В итоге в качестве KPI изменения процесса использовалось «Наличие полного цикла управления всеми видами ДЗ на протяжении всего жизненного цикла ДЗ».
Таким образом, для постановки задачи на изменение процесса мы должны:
• определить требуемое направление изменения;
• максимально его детализировать, все время отвечая на вопрос «За счет чего?» или «Каким образом?»;
• достигнув предела в текущем понимании того, как следует решать задачу, фиксировать ее формулировку и приняться за решение: разобраться с процессом, проанализировать его и искать подходящие варианты;
• увидев возможность сузить задачу, уточнить ее и переформулировать. Это позволит точнее понять параметры проекта по изменению процесса, снизить риски неуспешности и перерасхода ресурсов.
Задача должна содержать целевое значение оптимизируемого параметра и ограничения на остальные параметры и используемые инструменты улучшения. Например: сократить стоимость процесса на 20 %, не увеличив время выполнения и не снизив качество результата, только за счет локальных решений (то есть ограниченных рамками процесса).
Очень важно понимать, что постановка задачи диктует направленность описания, локальной диагностики и анализа. Например, если мы проектируем процесс с нуля или почти с нуля, как в примере, приведенном в этом параграфе, то не тратим время на описание и локальную диагностику. Мы сразу строим целевой процесс. Если же речь идет о стоимости текущего процесса, нам при его описании понадобится информация об элементах стоимости, а также (менее детально) о параметрах ограничений (например, времени выполнения тех или иных процедур).
Для формулировки задачи на изменение процесса вполне подходит метод SMART, предписывающий цели быть конкретной, измеримой, достижимой, важной и определенной по срокам.
SMART – сокращение от англ. Specific (конкретный), Measurable (измеримый), Achievable (достижимый), Relevant (соответствующий, важный), Time bound (ограниченный во времени, определенный по срокам).
1.2.5. Выбор KPI для изменения процесса
По мере уточнения задачи на изменение процесса появляется шанс определить KPI собственно изменения, то есть измеритель, который однозначно ответит на вопрос, добились ли мы необходимого или ожидаемого успеха в процессной трансформации. Если мы ограничиваемся качественным описанием задачи, то попадаем в ситуацию субъективных оценок: мнение об успехе и конце работ будет определяться личностью (квалификацией, опытом, взглядами, интересами и т. п.) того, кто выносит суждение. Известная ситуация: «Угадайте, что я задумал! Нет, не угадали, я уже передумал!» – причина многих конфликтов.
При этом выбранный показатель должен относиться именно к процессу, не выходить за его рамки. Отсюда прямое следствие: на ранней стадии, когда мы имеем дело с бизнес-задачей, решение которой лежит не только в процессе, но и в системе управления в целом, определять KPI изменения процесса абсолютно бессмысленно!
Резюме: любое изменение процессов должно сопровождаться постановкой задачи в виде KPI. Но делать это надо тогда, когда задача сузится до процесса. По такому показателю мы увидим успех изменения процесса. По главному показателю процесса, скорее всего, сможем судить об успехе решения бизнес-задачи в целом!
Показатели процессов, как известно[6], делятся на два вида:
КПР – ключевой показатель результативности (KPI процесса, или Process KPI) – характеризует результат процесса. Например, для процесса «Продажи» обычно очевидный КПР – «Выручка за период». Замечу, что этот показатель описывает множество экземпляров процесса, реализованных в конкретных рыночных и внутренних для компании условиях за определенный временной период. Как правило, не может быть выбран в качестве показателя изменения процесса, но годится как KPI для решения бизнес-задачи;
КПХ – ключевой показатель хода процесса (KPI хода процесса, или Process Execution KPI) – характеризует ход процесса. Допустим, для процесса «Квартальное планирование закупок» примером КПХ может быть бинарный показатель «Проект квартального плана закупок подготовлен и поступил на согласование до 25-го числа месяца, предшествующего кварталу».
KPI изменения процесса – обычно вариант КПП (ключевого показателя проекта), связанный с КПР или КПХ (то есть ведет к их изменению). Например, мы готовим коммерческие предложения Х дней (время выполнения процедуры «Подготовка и отправка КП клиенту» равно Х дней). Обычно компанию и ее клиентов это устраивает. Но, допустим, время от времени появляются «срочные» клиенты или «горящие» тендеры, требованиям которых эта характеристика не удовлетворяет. Компания ставит задачу скорректировать свою процедуру, дополнив ее вариантом процесса «Срочная подготовка и отправка КП клиенту». KPI проекта изменения процесса тогда выглядит как, скажем, «Время выполнения варианта процесса не более Х – 2 дня без потери качества, стоимость варианта не должна превышать стоимость основной процедуры более чем на 20 %».
С другой стороны, процессные KPI выступают в качестве измерителей процессных характеристик[7]. Среди них можно выделить три базовых параметра или группы: Время выполнения – Стоимость – Качество (рис. 3). К ним обычно могут быть сведены все требования к улучшению. Этот «треугольник параметров» напоминает «проектный треугольник» (рис. 4): Срок – Бюджет – Результат/Объем (Scope) – и имеет сходный смысл[8].
Рис. 3. Базовые параметры (группы характеристик) бизнес-процессов
Рис. 4. «Проектный треугольник»
Время выполнения процесса можно, как правило, отнести к КПР. Но иногда этот показатель является КПХ. Например, если мы говорим о процессе планирования и бюджетирования, то это время «отхода поезда», после которого ценность результата (бизнес-плана и бюджета) резко падает.
Стоимость процесса (подробнее см. в параграфе 2.4.3) – тоже чаще всего КПР. Но в ситуациях, когда эта характеристика для результата не особо важна или ею даже можно пренебречь, может являться контрольным КПХ.
К группе «Качество» относятся прочие характеристики: результативность, определенность, управляемость, повторяемость, гибкость, качество результата и эффективность, производительность или мощность процесса и т. д.
С организационной точки зрения выбор KPI – предмет обсуждения и дискуссий с[9]:
• владельцем процесса (ВП) – он представляет интерес процесса изнутри;
• клиентами процесса, непосредственно заинтересованными в результате;
• топ-менеджерами – смежниками, которых изменение процесса может касаться весьма чувствительным образом;
• куратором процесса – он в большинстве случаев защищает системный взгляд на бизнес-задачу;
• руководителями компании, если процесс достаточно высокого уровня или значимости, а также в случае, если бизнес-задача выходит за рамки компетенции куратора процесса.
Их в идеале консолидированное мнение дает фокус желаемых изменений.
Конечно, поставить задачу на улучшение процесса в формате «сократить стоимость процесса на 20 % при сохранении качества, измеряемого как процент приемки продукта внутренним ОТК без замечаний, притом что время выполнения не превысит нормативное» – весьма желательный вариант. Однако практика показывает: это все-таки редкость, что объясняется невысоким в целом уровнем процессной зрелости большинства организаций[10]. Наблюдение за собственными процессами, определение и измерение их показателей либо вообще не проводятся, либо имеют небогатую историю. В результате менеджеры просто не могут поставить задачу в таком четком виде: они не имеют для этого достаточной информации и, главное, понимания процесса.
Поэтому, даже сузив задачу до рамок процесса, зачастую менеджмент вынужден ограничиваться «мягкими» (то есть не определяемыми однозначно и объективно) формулировками KPI типа «увеличить управляемость процесса». И определять, удалось ли это сделать, путем голосования топ-менеджеров, например. То есть в этом случае рабочей группе приходится ориентироваться на понимание управляемости различными менеджерами, пытаться находить компромиссные решения, устраивающие большинство.
ПРИМЕР
Девелоперская компания провела аудит системы управления проектами, по результатам которого рекомендовано, помимо прочего, реализовать программу проектно-процессной регламентации, то есть регламентации процессов, относящихся к управлению девелоперским проектом. Одновременно предпринята попытка трансформации. Далее приведены список выбранных для регламентации процессов и формулировки задач на их изменение.
• Управление реализацией сквозного проекта.
Задача: разработка единого регулярного, эффективного и удобного процесса управления сквозным проектом на базе функционирующего Проектного Комитета (ПК).
К моменту начала реализации программы процесс представлял собой набор процедур низкого уровня зрелости. Никакого ПК в организации не было.
• Разработка и утверждение план-графика и бюджета строительного проекта.
Задача: повышение эффективности планирования строительных проектов с точки зрения обеспечения в отношении проектных план-графиков, бюджетов доходов и расходов и cash-flow-календарей:
• синхронизации;
• фиксации статусов;
• своевременной корректировки;
• своевременной детализации;
• максимальной реалистичности сроков;
• сокращения сроков согласований;
• полноты мероприятий план-графиков;
• автоматизации (с низкими трудозатратами и без дополнительных закупок).
К моменту начала реализации программы проект тащил за собой (часто с опозданием по отношению к реализации) процедуры планирования, которые в значительной степени реализовывались кулуарно и без необходимого согласования и вовлечения ответственных сотрудников.
• Управление регламентной базой.
Задача: целевой процесс должен обеспечить в отношении регламентных документов:
• «навязчивую» доступность и простоту использования;
• фиксацию статуса;
• регулярное обновление;
• введение бизнес-роли ответственного сотрудника за разработку и актуальность в отношении каждого регламентного документа;
• актуальность и контроль исполнения;
• своевременное упразднение.
Процесс пришлось проектировать с нуля, так как сформированной и управляемой регламентной базы в компании не было, действия в отношении нормативных документов носили эпизодический характер.
Ну и в любом случае всегда есть место для ошибок и неверной постановки задач. Несколько дней назад столкнулся со следующим примером.
ПРИМЕР
Организация – банк. Рассматривается процесс кредитования юридических лиц от получения заявки до принятия решения о выдаче кредита или об отказе. Рассуждения аналитика: процесс кредитования приносит банку деньги. Когда результатом процесса является отказ, активности, связанные с обработкой заявки, становятся чистыми потерями. Поэтому анализировать нужно экземпляры процесса, приведшие к отказу. Задача – минимизировать отказы в процессе.
К чему приводит такой подход? Особенно если еще и мотивирование специалистов кредитного отдела увязать с процентом одобренных заявок на выдачу кредита, чтобы минимизировать отказы. Понятно, что банк станет выдавать кредиты в сомнительных, рискованных и просто опасных с точки зрения возврата случаях. Надо ли это банку? Если же оценивать отказы, вызванные не несоответствием потенциального кредитора условиям, которые банк предъявляет к заемщикам, а процедурными заморочками, когда ничем не запятнанный заявитель не смог дойти до получения кредита, то это явно пойдет на пользу процессу. В то же время бизнес-задача для банка, скорее всего, могла бы звучать как «повышение эффективности (или доходности, например) направления кредитования» – и тогда, возможно, стоит посмотреть и на продвижение сервиса, и на соответствие предлагаемых условий рыночной ситуации и стратегии банка и т. п. Так задача совершенствования самой процедуры принятия решения получит свой приоритет и точную формулировку.
Упражнение
После чтения параграфов 1.2.3–1.2.5 вы бы скорректировали KPI изменения процесса, определенный в ходе выполнения упражнения к параграфу 1.2.2?
1.2.6. Предварительная оценка экономического эффекта
Очень часто начало работ по изменению процессов обуславливается получением спонсорами радужных оценок экономического эффекта. Типа «Зачем это все и что это нам даст?». В такой редакции вопрос звучит в компаниях, которые только начинают знакомиться с процессным менеджментом или вообще рассматривают потенциальный проект как разовое действие. Желание, в принципе, вполне законное и резонное, поэтому и в компаниях с развитым процессным управлением такая процедура присутствует, правда, относятся к ней несколько иначе.
В чем же проблема? Дело в том, что на начальном этапе речь идет об оценке еще не существующего решения задачи. То есть решение не выработано, его нет, неизвестны как его положительные эффекты, так и затраты, которые с ним связаны. Исключение составляют проекты, когда процесс не меняется (по крайней мере, это не цель проекта), например проекты регламентации и формализации процессов, а также когда внедряется заранее известный процесс (ряд проектов автоматизации, предполагающих замену существующего процесса некоторым стандартным, «зашитым» в ИТ-решении). Однако в проектах, связанных с организационными изменениями, трансформацией процесса, а также автоматизацией усовершенствованного процесса, никто заранее не может сказать, какое решение будет выработано, насколько эффективным оно окажется и насколько высоко будет оценено лицами, принимающими решение. Будет ли принято решение о внедрении, в чем именно оно будет заключаться и какие затраты потребуются на сопровождение внедряемого решения.
Понятно, что такие трудности влекут за собой низкую достоверность результата самой оценки. Причем на этом этапе повышение достоверности либо невозможно (для этого надо выполнить проект), либо нецелесообразно, так как возможно только уточнение второстепенных параметров, которое в отсутствие самого решения утонет в неопределенностях более высокого порядка и приведет к бессмысленной трате средств и времени.
Естественно, что такие оценки «плюс-минус километр» не воспринимаются достаточно серьезно и не проверяются по окончании проекта «на сбычу». Но если в «опытной» организации это понятно всем участникам действа, то менеджмент компаний-новичков испытывает по этому поводу большое разочарование и расстройство вплоть до отказа от потенциального проекта: «Зачем нам кот в мешке?» Здесь поможет только повышение квалификации руководства в области процессного управления.
Казалось бы, если оценка экономического эффекта на этом этапе настолько недостоверна, стоит ли вообще ею заниматься? Единого ответа для всех и на все случаи нет. Иногда это действительно потеря времени, а иногда (особенно при невысокой процессной зрелости организации) само по себе это упражнение может быть весьма полезным. Оно заставляет фокусироваться на том, что нужно компании, привлекает внимание к важным влияющим факторам, выстраивает приоритеты для команды проекта.
Для оценки экономического эффекта (ЭЭ) используется следующий подход:
ЭЭ = ∑pi – Zd – Zin – Zs,
где pi – оценка i-го ожидаемого эффекта; Zd – затраты на разработку дизайна нового процесса; Zin – затраты на внедрение нового процесса; Zs – затраты на сопровождение нового процесса после внедрения.
Сумма ожидаемых эффектов. При ее расчете необходимо сформулировать все ожидаемые от изменения процесса эффекты: что мы хотим получить, чего добиться? Как прямые результаты, так и косвенные. Важно, что формулируемые эффекты можно условно разделить на количественные («сокращение среднего времени выполнения процесса с шести рабочих дней до пяти») и качественные (например, «повышение уровня обслуживания клиентов»). Затем каждый эффект нужно «монетизировать» – провести логическую и оценочную цепочку от первоначальной формулировки до финансового «выхлопа», например:
• «повышение уровня обслуживания клиентов» или «получение некоего сертификата соответствия» – мы предполагаем, что это решение привлечет, скажем, 10 % дополнительных клиентов от наших конкурентов, так как станет нашим преимуществом. Это даст прирост оборота 10 %;
• «сокращение трудозатрат участников процесса на 20 %». Зная мощность входного потока (количество экземпляров процесса в месяц, например) и посчитав текущие трудозатраты и их стоимость, можно прикинуть ежемесячный эффект для процесса. Однако надо иметь в виду, куда этот излишек трудозатрат будет направлен! Если сокращение сопровождается физическим сокращением персонала или переводом «лишних» сотрудников на дефицитные позиции, эффект имеет шансы быть закрепленным. В противном случае такие результаты имеют тенденцию «растворяться»;
• «сокращение среднего времени выполнения процесса с шести рабочих дней до пяти». Этот кейс в свое время имел место в компании, выпускавшей и устанавливавшей пластиковые окна и двери из профиля Rehau. Исследование, выполненное компанией, показало, что скорость исполнения заказа (максимум в течение недели) довольно чувствительна для клиентов, что подтверждал отток заказов и снижение оборота в последние месяцы, поскольку конкурентам удалось решить эту проблему. Сокращая время выполнения заказа, компания рассчитывала восстановить потерянный поток заказов и постепенно увеличивать его за счет преимущества в качестве. Здесь также «монетизация» выражается в росте оборота
и так далее.
Надо иметь в виду и то, что возможны и негативные эффекты. Например, повышая уровень обслуживания, мы предполагаем, что увеличим стоимость процесса. Такие эффекты также следует учесть, то есть, думая о позитивном результате, все время спрашивать себя: «Какой ценой?»
Затраты Z оцениваются как сумма трудозатрат участников (разработки, внедрения или сопровождения), помноженных на стоимость их рабочего времени, а также включают стоимость привлекаемых дополнительных ресурсов различного характера, в том числе затраты на изменение ресурсного и инфраструктурного ландшафта процесса (софт, оборудование, инструменты, офисы, наем персонала и пр.).
Все эффекты и затраты имеют различное распределение во времени. Есть разовые и постоянные. Постоянные могут меняться (увеличиваться и уменьшаться) с течением времени. Например, затраты на разработку и на внедрение процесса – разовые, совершаются в течение времени проекта разработки и внедрения соответственно. Ожидаемые эффекты, как правило, постоянные, обычно постепенно нарастающие до некоторого насыщения (допустим, оборот за счет дополнительных клиентов растет в течение полугода и доходит до 10 % прироста – см. примеры ранее).
Есть затраты инвестиционного характера. Например, новый процесс требует нового софта и оборудования. Такого рода затраты следует учитывать по амортизационной модели (прикинуть время использования и разделить на него стоимость) – списывать постепенно.
Описанные прикидки дадут распределение по времени дополнительных доходов и расходов, связанных с изменением процесса. Итоговую оценку надо привести к одной цифре, которая и будет ЭЭ. Для этого по приведенной ранее в этом параграфе формуле считаем ЭЭt для каждого отрезка времени (обычно – по годам, хотя можно и помесячно или поквартально). Затем постараемся учесть стоимость денег:
ЭЭ = ∑ЭЭt / (1 + R)t,
где R – ставка дисконтирования, соответствующая выбранным временным отрезкам, например годовая, если считаем годовые эффекты; t – год (или другой выбранный временной отрезок) наблюдения эффектов от изменения процессов, меняется от 0 (начальный год проекта, к которому мы и приводим оценку) до n – горизонта, на котором мы еще хотим учитывать эффекты. Дело в том, что, во-первых, изменения в деятельности организации сейчас происходят очень быстро и мы не можем рассчитывать, что процесс после нашего изменения будет сохраняться в таком виде сколько-нибудь длительное время. Во-вторых, в условиях неопределенности (см. ранее) мы вряд ли будем одобрять «неочевидные» решения, не обещающие быстрой отдачи. На практике в таких расчетах мне встречались горизонты не более трех лет.
Таким образом, в проектах изменения бизнес-процессов на этапе постановки задачи оценка экономического эффекта чаще всего является некоторой прикидкой. И лишь когда решение будет разработано, когда будет составлен план его внедрения и сопровождения, можно получить достаточно достоверную оценку экономического эффекта разработанного изменения. В этот момент можно принимать решение о том, стоит ли овчинка выделки, то есть стоит ли внедрять разработанное решение. Иначе говоря, старт проекта изменения процессов в определенной мере содержит риски невозврата инвестиций. Осознание этого факта зачастую мешает менеджменту, заведшему разговор об экономическом эффекте при старте проекта, принять положительное решение, дать отмашку. Компании же, которые выбрали процессный менеджмент как корпоративную парадигму управления, используют предварительную оценку экономического эффекта для уточнения задачи и расстановки приоритетов в предстоящем проекте.
Упражнение
Сделайте предварительную оценку экономического эффекта изменения процесса, выбранного ранее (см. упражнения после параграфов 1.2.1, 1.2.2 и 1.2.5).
1.2.7. Продажа проекта
Оценка экономического эффекта – важная часть продажи проекта, неважно, внутренней (когда инициаторы проекта продвигают его в своей организации) или внешней (когда компания-клиент общается со сторонней консалтинговой организацией).
Однако ЭЭ не единственный фактор, влияющий на принимаемое решение. Проекты изменения процессов относятся к так называемым большим проектам, которым соответствуют «большие продажи». И хотя в моей практике было несколько случаев (пересчитать можно по пальцам одной руки), когда акционер давал отмашку, просто исходя из прежнего опыта работы с нами, не ведя переговоров по деталям и условиям, решения о «процессных» проектах почти никогда не принимаются эмоционально, без серьезного осмысления.
Вопросы продаж/продвижения проектов не являются предметом этой книги, однако я все-таки очень рекомендую всем читателям, связанным с развитием процессного управления, как минимум познакомиться с технологией SPIN-продаж[11]. Думаю, это будет весьма полезное чтение.
Здесь я хочу только обратить внимание на один важный аспект: чем точнее и детальнее поставлена задача, тем «вменяемее» и само коммерческое (или внутреннее) предложение на проект, оценка экономического эффекта, оценка бюджета и ресурсов, сроков и т. п. Чем более расплывчата задача, тем больший запас на риски неопределенности приходится закладывать тому, кто готовит предложение на проект. Пухнет бюджет, снижается эффект, сам разговор становится менее предметным. Поэтому на начальном этапе (до старта, хотя, как мы показали ранее, и после старта тоже!) необходимо самое серьезное внимание уделить постановке задачи!
Часто сталкиваемся с вопросом: всегда ли нужно ставить задачу на трансформацию? Иногда (обычно ИТ-шники или «быстрые» менеджеры) рассуждают так: посмотрим, что и как с процессом, – если что-то найдем и если будет надо, мол, тогда исправим. Такой подход имеет смысл, когда никто в организации не знает (и не хочет разобраться!), что нужно от процесса. То есть если поставить задачу – проблема. Так бывает. Во всех прочих случаях задачу ставить надо. Иначе получаем как минимум два негативных фактора:
• «посмотрим, что и как с процессом» – проблемная задача: когда не знаешь, что искать, как найти что-то действительно важное?
• тогда нужно очень достоверно и всесторонне считать экономический эффект. Иначе организации грозят серьезные ошибки и при принятии решения о коррекции процесса по результатам «бесцельного поиска», и по последствиям такой корректировки, вплоть до отрицательных.