09.01.2012 16:51
  от автора
  Репин

Как создать архитектуру бизнес-процессов компании? Часть 1

В статье В.В. Репина рассматриваются различные подходы к разработке архитектуры (системы) бизнес-процессов компании. Приводится оценка «плюсов» и «минусов». Раскрываются важные практические аспекты построения системы процессов организации. Статья написана на основе опыта выполнения проектов для российских компаний (в 2010-2011 годах В.В. Репин принял участие в 8 проектах по разработке системы процессов).

Часть 1.
Цели построения архитектуры бизнес-процессов компании

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

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

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

Пример 2. В одной из крупных частных компаний (производитель снеков) был реализован проект по созданию архитектуры бизнес-процессов. Частично был выполнен так называемый «маппинг» с APQC – сравнение между собой двух моделей процессов за счет наложения одной на другую. Цели разработки системы процессов, согласованные руководством компании, включали следующие пункты:
• разработать уникальную процессную модель «ХХХ», которая бы за счет наличия четких связей с моделями APQC, CBM, SAP, DocsVision, СМК и реестром нормативных документов компании обеспечивала бы возможность:
- осуществлять расширение бизнеса (как в России, так в странах СНГ) за счет передачи знаний о процессах, используемых средствах автоматизации и соответствующих регламентирующих документах;
- системным образом осуществлять описание и регламентацию бизнес-процессов компании с использованием системы Business Studio 3.6.;
- создавать систему управления знаниями о деятельности компании.
Одна из неформальных целей разработки системы процессов заключалась в снижении зависимости от конкретных личностей – их субъективного видения состава и границ процессов, которые целесообразно выполнять для поддержания стабильного состояния и развития бизнеса.


Пример 3. Компания средняя по оборотам, но небольшая по численности. Разработка системы процессов потребовалась руководству для обеспечения «прозрачности» деятельности при условии активного роста бизнеса. Комплексная процессная модель (система процессов) позволила руководству по-новому взглянуть на модель бизнеса организации, усилить и реорганизовать ключевые направления деятельности компании.

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

В общем, можно говорить о следующих целях построения системы процессов компании:


Определение системы процессов компании

Что же представляет собой (система) процессов компании? Как правило, это иерархический справочник процессов следующего вида:

1. Процессная категория (1-й уровень).
1.1. Процессная группа (2-й уровень).
1.1.1. Процесс (3-й уровень).
1.1.1.1. Операционный процесс (4-й уровень).
1.1.1.1.1.Операция (5-й уровень).
1.1.1.1.1.1.Транзакция (6-й уровень).

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

После того, как система процессов в виде иерархического справочника построена, при необходимости могут быть созданы модели деятельности в виде графических схем. На уровне 1-3 целесообразно использовать структурные типы моделей (например, IDEF0). С уровня 4 (для небольших компаний – с уровня 3), как правило, описание выполняют при помощи схем в формате Work Flow. Удобным способом их визуального представления являются кросс-функциональные схемы, содержащие дорожки. На каждой дорожке указываются операции, выполняемые подразделениями/сотрудниками/бизнес-ролями. Пример: «Начальник отдела продаж» - сотрудник, «Инициатор договора» - бизнес-роль.

Заметим, что построение системы процессов компании и «тотальное» описание всех процессов – не одно и тоже. Система процессов – это иерархический справочник процессов со связями на операционном уровне (входы/выходы) и указанием ответственности. Для компании среднего размера можно разработать систему процессов за 2-3 месяца, в то время как описание ВСЕХ процессов на операционном уровне может занять несколько лет (в зависимости от количества выделенных ресурсов), что практически нецелесообразно.

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

Вернемся к вопросу определений. В одном из проектов создания системы процессов, нами были предложены следующие формулировки (см. таб. 1).

Таблица 1. Определения систем процессов.


Технически, для описания системы процессов компании можно использовать MS Excel (автору известны примеры крупных компаний, которые поддерживают репозиторий процессов в этой программе). Удобно показывать процессные категории на отдельных листах. Примером рассматриваемого представления является модель APQC. Модель процессов в MS Excel в дальнейшем переводится (импортируется) в соответствующий программный инструмент, например, в среду моделирования бизнес-процессов. Хотя «автоматизированный репозиторий бизнес-процессов» компании может быть реализован и другими программными средствами.

В качестве примера приведем фрагмент системы процессов некоторой небольшой организации:

Таб. 2. Фрагмент системы процессов.

      
Каким же образом разработать систему процессов, адекватно описывающую деятельность компании? В российской практике автор статьи сталкивался со следующими подходами:

  1. структурный подход;
  2. продуктовый подход;
  3. «блюдо» спагетти;
  4. CBM IBM (Component Business Model компании IBM);
  5. методика построения системы процессов на основе анализа модели цепочек создания ценности (ЦСЦ);
  6. смешанные подходы.
Рассмотрим каждый из указанных подходов более подробно.

Структурный подход к построению системы процессов компании

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

Важно отметить, однако, что 40-90% операционных процессов (в зависимости от степени «проектной» ориентированности организации) не являются «сквозными». Другими словами, их нецелесообразно определять в качестве «сквозных», т.к. они на 100% выполняются внутри соответствующих подразделений.

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

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

Приведем несколько примеров построения системы процессов на основе «структурного» подхода.

Таб.3. Фрагмент системы процессов из категории «Инженерно-техническое обеспечение»


Показанные в таб. 3. процессы практически все выполняются в Отделе главного механика. Только несколько процессов связаны с межфункциональным взаимодействием, например это процесс «8.2.7. Закупка ЗИП и инструмента для ремонта механического оборудования». В таб. 4. «сквозные» процессы выделены курсивом. В данном случае, «межфункциональность» процессов явно видна из состава его участников (Начальник производства, Начальник склада, технолог не подчиняются Главному механику).

В таб. 4. Показан фрагмент системы процессов другой компании. Все процессы, за исключением 6.4.5. не могут быт названы «сквозными». Они практически полностью выполняются силами сотрудников лаборатории. Между процессами 6.4.1. – 6.4.4. существует взаимодействие, но все они выполняются в одном подразделении. Поэтому в данном случае структурный метод построения системы процессов «работает» вполне нормально.

Таб.4. Фрагмент системы процессов из категории «Управление технологией и контроль качества»


Может возникнуть вопрос, по каким принципам выделяются процессы внутри структурного подразделения? Как правило, принимают во внимание на следующие моменты:

      
Продуктовый подход к построению системы процессов

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

Системы процессов, полностью основанные на «продуктовом» способе построения на практике встречаются довольно редко. Одним из ярких примеров является процессная модель деятельности банка. Приведем ее фрагмент:

1. Основные процессы.
1.1. Обслуживание физических лиц.
1.1.1. Расчетно-кассовое обслуживание физических лиц.
1.1.1.1. Текущие счета физических лиц.
1.1.1.1.1. Открытие текущего счета для физического лица.
1.1.1.1.2. Прием взносов на счет.
1.1.1.1.3. Проведение выплат со счета.
1.1.1.1.4. Взимание комиссии со счета.
1.1.1.1.5. Оформление доверенности на распоряжение счетом.
1.1.1.1.6. Оформление доверенности на распоряжение счетом.
1.1.1.2. Расчетное обслуживание.
1.1.1.3. Кассовое обслуживание.
1.1.1.4. Валютный контроль и валютные операции.
1.1.1.5. Денежные переводы по системам.
1.1.2. Вклады.
1.1.3. Кредитование физических лиц.
1.1.4. Банковские карты для физических лиц.
1.1.5. Индивидуальные банковские ячейки (сейфы) для физических лиц.
1.1.6. …
1.2. Обслуживание юридических лиц.
1.3. Работа на финансовых и межбанковских рынках.
2. Вспомогательные процессы.


«Плюсом» такого подхода является его кажущаяся простота – процессы выделяются на основе построения иерархического справочника продуктов и услуг, а на нижнем уровне – на основе анализа «технологии создания» соответствующего «элементарного» продукта/услуги. Но если внимательно посмотреть на полученную структуру процессов, можно увидеть несколько существенных «минусов»:


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

Приведем еще один фрагмент из рассматриваемой модели банка:

3. Управленческие процессы
3.1. Управление финансами.
3.2. Управление персоналом.
3.3. Управление маркетингом
3.3.1. …
3.3.2. …
3.3.3. …
3.3.4. Управление продуктами.
3.3.4.1. Разработка и внедрение продуктов и услуг.
3.3.4.1.1.      …

Обратите внимание, что процесс «Разработка и внедрение продуктов и услуг» попал на 4 (!) уровень иерархии. С моей точки зрения, для современных компаний (независимо от профиля бизнеса) в системе процессов должна быть категория «Разработка новых продуктов и услуг». Приведу пример из системы процессов крупной компании, которая выделяла значительные ресурсы на развитие продуктового ряда:

3.Разработка новых и изменение текущих продуктов.      
      3.1. Управление разработкой новых и изменением текущих продуктов.      
      3.2. Поиск и отбор идей по новым продуктам.
      3.3. Управление портфелем проектов по новым продуктам/изменениям текущих продуктов.      
      3.4. Управление проектом по разработке нового продукта/изменению текущего продукта.      
      3.5. Выполнение исследований по новому продукту/изменениям текущего продукта.      
      3.6. Проработка идеи нового продукта/изменения текущего продукта.      
      3.7. Разработка нового продукта/измененного текущего продукта.      
      3.8. Подготовка производства продукта.      
      3.9. Запуск производства продукта.      
      3.10. Вывод продукта на рынок.      
      3.11. Управление нормативно-технологической документацией.      

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

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

Продолжение следует в Части 2 настоящей статьи.
      
В.В. Репин, к.т.н., доцент, Исполнительный директор и партнер ООО «BPM Консалтинг Групп».

Январь 2012 г.

www.finexpert.ru - всё о процессном управлении!

Прочитать Часть 2