|
Персональные инструменты |
|||
|
|
Процессы: ключевые vs сквозныеМатериал из CustisWiki
Содержание[убрать]ВведениеВопрос «как автоматизировать сквозные бизнес-процессы?» поднимается в профессиональных кругах достаточно часто. Мы же, прежде чем перейти к вопросу автоматизации, попробуем разобраться, почему в компании могут возникнуть сквозные процессы и является ли их появление таким уж необходимым или неизбежным. Определимся с терминамиТрадиционно под сквозными бизнес-процессами понимают такие процессы, которые протекают более чем через одно структурное подразделение компании. При этом сквозные процессы могут быть как ключевыми, то есть определяющими содержание бизнеса и составляющими основу его конкурентного преимущества, так и второстепенными (сюда также стоит отнести инфраструктурные процессы). Ключевые бизнес-процессы — это процессы, ориентированные непосредственно на производство продукции, представляющие ценность для клиента и обеспечивающие получение дохода предприятием. Второстепенные бизнес-процессы предназначены для обеспечения выполнения ключевых процессов. Наше дальнейшее внимание будет сосредоточено именно на ключевых сквозных процессах. Недостатки сквозных процессовКритическими точками сквозных ключевых процессов являются «стыки», неизбежные при переходе процесса из одного подразделения в другое. Далее мы остановимся на трех важнейших аспектах, которые отрицательно сказываются на качестве сквозных процессов и их последующей автоматизации. 1. Потеря контекста «на стыках». При переходе процесса из подразделения в подразделение неизбежно происходит потеря контекста. Зачастую к концу цепочки исполнители уже не понимают, какой результат был запланирован в ее начале. Для наглядности рассмотрим примеры.
2. Потеря эффективности при передаче процесса из одного подразделения в другое. Когда ключевой процесс идет в рамках одного подразделения, есть возможность оптимизировать его в целом. Если ключевой процесс является сквозным, то обычно выполняется его локальная оптимизация в рамках отдельных подразделений. Это приводит к образованию «узких горл» на стыках.
3. Потеря управляемости. В отсутствие «хозяина» ключевого сквозного процесса ответственность за конечный результат не персонифицирована. Это ведет к потере управляемости. Владелец процесса отвечает за результат и «проталкивает» свой процесс на стыках по всей цепочке. Но если несколько ключевых процессов проходят через одно подразделение, то их «хозяева» начнут конкурировать за ресурсы.
Чем эффективнее протекают ключевые бизнес-процессы, тем лучше работает компания в целом. Для повышения эффективности сквозных ключевых процессов часто предлагается выстраивать систему управления так, чтобы у каждого отдельного процесса был один «хозяин». Однако это не решает проблему, поскольку, во-первых, не обеспечивает целостного восприятия процесса всеми участниками, во-вторых, при наличии в компании большого количества процессов неизбежно приводит к конкуренции между владельцами ресурсов и владельцами ключевых процессов и, в-третьих, сильно усложняет всю систему управления компанией. Как избавиться от сквозных ключевых процессовНесмотря на перечисленные недостатки, сквозные ключевые процессы достаточно часто встречаются в реальной жизни. По нашему опыту, причины их появления могут быть разными.
На наш взгляд, от таких ситуаций нужно избавляться и при проектировании придерживаться подхода «по возможности никаких сквозных ключевых процессов». Ключевой процесс должен целиком лежать внутри одного подразделения. Это, по сути, означает, что на этапе оргпроектирования нужно выстраивать структуру так, чтобы каждый ключевой бизнес-процесс выполнялся внутри одного подразделения. Связь между подразделениями должна осуществляться второстепенными процессами. Типичный случай сквозных ключевых процессов можно представить на примере классического банка с фронт-, мидл-, бэк-офисом и разными типами банковских продуктов. Такое деление позволяет решать проблему разной скорости протекания процессов на каждом слое, когда технически сложно или невозможно отразить операцию одновременно на всех слоях структуры. Эта же схема соответствует обычным службам небольшого интернет-магазина. Фронт-офис в нем — это витрина в интернете, мидл-офис — это операторы, обеспечивающие обработку и доставку заказов, бэк-офис — это система учета заказов. Руководствуясь заявленным подходом, мы можем постараться спроектировать оргструктуру компании таким образом, чтобы в ней не было сквозных ключевых процессов. Для начала представим компанию в виде черного ящика, на входы которого поступают запросы извне. Среди входящих запросов выделим наиболее важные или критические для бизнеса. Назовем ключевыми те процессы внутри компании, которые обеспечивают адекватные ответы на них. Например, закрытие счета в банке можно не считать критическим процессом, а вот заключение договора с новым клиентом — это важно. Заключение сделки на бирже — это срочно, а выдача ипотечного кредита — не так срочно, так как тут время отклика исчисляется не секундами, а днями. В ходе оргпроектирования будем стремиться оптимизировать выполнение ключевых процессов. Для этого детально их опишем и постараемся выстроить структуру так, чтобы ключевые бизнес-процессы целиком выполнялись в рамках одного подразделения. Есть, однако, важные сквозные процессы, которые нельзя отнести к ключевым, поскольку они не влияют на конкурентные преимущества компании. Например, важная внутренняя функция получения управленческого баланса в конце каждого дня. Она не нужна какому-то конкретному ключевому процессу, но нужна компании в целом. Такая функция выделяется и планируется в условиях ограничений, заданных спроектированными ранее ключевыми процессами. Если проектировать структуру компании, последовательно придерживаясь описанных выше принципов, получится картина, представленная на рис. 3. Вертикальные прямоугольники обозначают подразделения, специализированные для выполнения отдельных ключевых процессов, а горизонтальные — сквозные процессы, второстепенные и инфраструктурные. Если бы не нужно было поддерживать единство предприятия, то можно было бы под каждый ключевой процесс создать отдельный бизнес. Тогда получилось бы много небольших компаний без связывающих их сквозных процессов. По такому принципу устроены многопрофильные холдинги. Но если ключевые процессы являются составляющими одного бизнеса, то при проектировании придется учитывать связующие их сквозные процессы. Поэтому не всегда получается выделить ключевые процессы «в чистом виде». Решение об окончательной компоновке ключевых и инфраструктурных сквозных процессов — это результат творческой деятельности, который существенно зависит от конкретной компании. Например, функция подбора персонала. Как правило, ее считают инфраструктурной. Если HR-подразделение будет одно на всю компанию, тогда его место в «горизонтальном» слое. А если функция подбора персонала критична для какого-то ключевого процесса, то логично поместить ее в соответствующее бизнес-подразделение. Автоматизируй этоДо недавнего времени исторически сложившиеся сквозные ключевые процессы поддерживала парадигма применения единых систем масштаба предприятия — монолитных банковских и ERP-систем. Но постепенное наращивание функциональных возможностей привело к тому, что монолитные системы стали слишком сложны и трудно развиваемы. Современные технологические возможности и подходы к проектированию и разработке корпоративных ИТ-систем позволяют снижать системную сложность путем создания не менее эффективных децентрализованных систем. Логика построения бизнес-подразделений, основанная на выделении ключевых процессов, позволяет четче фокусировать компанию на конкурентных преимуществах, независимо и асинхронно развивать отдельные сегменты бизнеса. Идея отказа от сквозных ключевых процессов в бизнес-архитектуре совпадает с современным трендом в ИТ на создание декомпозированных систем из слабо связанных компонентов. Такой подход позволяет развивать каждый компонент независимо, что добавляет гибкости и мобильности ИТ-системам, а в конечном итоге — и всему бизнесу. Репликация: База Знаний «Заказных Информ Систем» → «Процессы: ключевые vs сквозные» Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||