Процессы: ключевые vs сквозные

Ссылки сюда (1) →

В журнале Intelligent Enterprise (№11/2012) опубликована статья Михаила Заборова, заместителя генерального директора по стратегическим проектам, посвященная сквозным бизнес-процессам и их автоматизации. Почему в компаниях возникают сквозные процессы и к каким последствиям для бизнеса это приводит? Как избежать сквозных ключевых процессов при оргпроектировании? Какие возможности могут предложить современные ИТ для автоматизации ключевых бизнес-процессов? Об этом — в статье «Процессы: ключевые или сквозные?» на сайте и в бумажной версии журнала.

Введение

Вопрос «как автоматизировать сквозные бизнес-процессы?» поднимается в профессиональных кругах достаточно часто. Мы же, прежде чем перейти к вопросу автоматизации, попробуем разобраться, почему в компании могут возникнуть сквозные процессы и является ли их появление таким уж необходимым или неизбежным.

Определимся с терминами

Традиционно под сквозными бизнес-процессами понимают такие процессы, которые протекают более чем через одно структурное подразделение компании.

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

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

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

Недостатки сквозных процессов

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

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

Пример 1-1. Как правило, при разработке веб-сайта продажу услуг и прием заказов выполняет один отдел, требования заказчика собирает другой, дизайном занимается третий, а разработкой и внедрением — четвертый. В результате может получиться как на популярной в ИТ-среде картинке про «программистов и качели». Это особенно опасно, когда от заказчика поступает большой поток информации: вероятность исказить или потерять детали контекста существенно возрастает.

Пример 1-2. Посетителям крупного торгового центра банк предлагает прямо на месте быстро оформить кредитную карту. Клиент готов оформить карту, но с условием, что кредитный лимит будет большим. Для этого он предоставляет всю необходимую информацию. Сотрудники банка принимают заявку, но при стандартном протекании процесса в банке оказывается, что предложение подразумевает очень небольшой фиксированный кредитный лимит. Особые условия клиента не учитываются, и для него выпускается карта со стандартным лимитом. Банк получил совершенно неудовлетворенного клиента, которому придется еще приложить усилия, чтобы отказаться от ненужной карты.

2. Потеря эффективности при передаче процесса из одного подразделения в другое. Когда ключевой процесс идет в рамках одного подразделения, есть возможность оптимизировать его в целом. Если ключевой процесс является сквозным, то обычно выполняется его локальная оптимизация в рамках отдельных подразделений. Это приводит к образованию «узких горл» на стыках.

Пример 2-1. Одно подразделение формирует заказы на поставку товара, другое отгружает товар со склада. Если при выводе на рынок нового товара первые набирают заказы, не учитывая возможности отгрузки, то это может закончиться тем, что склад перестанет справляться и товар вообще не попадет к покупателю. Случись такое один раз, бизнес найдет способ сгладить ситуацию. А если успех бизнеса зависит от умения быстро и эффективно выводить товары на рынок, то с такой конфигурацией процессов он потерпит неудачу.

Пример 2-2. Торговая сеть решает начать продажу одежды через интернет-магазин. Для удобства покупателей решено привозить несколько размеров одной модели на выбор. При такой организации процесса продаж возвраты становятся обычным явлением. Если не адаптировать стандартный процесс возврата, который сопровождается обязательной экспертизой, то у торговой сети очень быстро скопится большой объем товара, требующего специальных действий для его возврата в торговый оборот.

3. Потеря управляемости. В отсутствие «хозяина» ключевого сквозного процесса ответственность за конечный результат не персонифицирована. Это ведет к потере управляемости. Владелец процесса отвечает за результат и «проталкивает» свой процесс на стыках по всей цепочке. Но если несколько ключевых процессов проходят через одно подразделение, то их «хозяева» начнут конкурировать за ресурсы.

Пример 3-1. Во фронт-офисе банка заключена срочная сделка с VIP-контрагентом. Она попадает в мидл-офис, который должен рассчитать риски. Если там не установили этой сделке высокий приоритет, ее обработка выполняется в обычном порядке. В результате стандартная процедура может привести к срыву важного контракта.

Пример 3-2. Интернет-магазин торгует на условиях самовывоза товара покупателем. Иногда это оборачивается тем, что магазин вообще не фокусируется на процессе продаж. В результате покупатель вынужден брать на себя функцию «хозяина» процесса и самостоятельно проходить все его фазы — выписывать пропуск для прохода в офис магазина, оформлять заказ у менеджера, оплачивать товар в кассе, отправляться на склад за товаром, выписывать пропуск на вынос купленного товара. Едва ли он еще раз решится на покупку в таком интернет-магазине.

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

Как избавиться от сквозных ключевых процессов

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

• Они могут возникнуть из-за особенностей бизнеса, как это можно наблюдать в традиционном банке.

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

• Кроме того, они могут быть целенаправленно так спланированы в процессе оргпроектирования.

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

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

Рис. 1. Примеры классических оргструктур

Эта же схема соответствует обычным службам небольшого интернет-магазина. Фронт-офис в нем — это витрина в интернете, мидл-офис — это операторы, обеспечивающие обработку и доставку заказов, бэк-офис — это система учета заказов.

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

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

Рис. 2. Ключевые и второстепенные процессы внутри компании

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

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

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

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

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

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

Например, функция подбора персонала. Как правило, ее считают инфраструктурной. Если HR-подразделение будет одно на всю компанию, тогда его место в «горизонтальном» слое. А если функция подбора персонала критична для какого-то ключевого процесса, то логично поместить ее в соответствующее бизнес-подразделение.

Автоматизируй это

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

Современные технологические возможности и подходы к проектированию и разработке корпоративных ИТ-систем позволяют снижать системную сложность путем создания не менее эффективных децентрализованных систем.

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

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

---

Репликация: База Знаний «Заказных Информ Систем» → «Процессы: ключевые vs сквозные»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».