Читать книгу "Бизнес-процессы. Моделирование, внедрение, управление - Владимир Репин"

1.1.2. Вклады.

1.1.3. Кредитование физических лиц.

1.1.4. Банковские карты для физических лиц.

1.1.5. Индивидуальные банковские ячейки (сейфы) для физических лиц.

1.1.6. …

1.2. Обслуживание юридических лиц.

1.3. Работа на финансовых и межбанковских рынках.

2. Вспомогательные процессы…

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

• большое количество уровней иерархии справочника процессов (реальные операции процессов появляются только на шестом уровне иерархии!);

• не выделяются сквозные процессы;

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

• возможное дублирование (например, процесс «Взимание комиссии» может быть типовым и запускаться с разными параметрами при оказании различных услуг; при рассматриваемом подходе он появляется несколько раз в разных частях системы);

• при внедрении новых продуктов/услуг придется перекраивать всю систему процессов.

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

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

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

1. Управленческие процессы

1.1. Управление финансами.

1.2. Управление персоналом.

1.3. Управление маркетингом

1.3.1. …

1.3.2. …

1.3.3. …

1.3.4. Управление продуктами.

1.3.4.1. Разработка и внедрение продуктов и услуг.

1.3.4.1.1. …

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

Пример. Процессы создания новых продуктов торгово-производственной компании

В крупной торгово-производственной компании в рамках категории «Развитие продукции и услуг» выделена процессная группа «Разработка новых и изменение текущих продуктов»:

3. Разработка новых и изменение текущих продуктов.

3.1. Управление разработкой новых и изменением текущих продуктов.

3.2. Поиск и отбор идей по новым продуктам.

3.3. Управление портфелем проектов по новым продуктам/изменениям текущих продуктов.

3.4. Управление проектом по разработке нового продукта/изменению текущего продукта.

3.5. Выполнение исследований по новому продукту/изменениям текущего продукта.

3.6. Проработка идеи нового продукта/изменения текущего продукта.

3.7. Разработка нового продукта/измененного текущего продукта.

3.8. Подготовка производства продукта.

3.9. Запуск производства продукта.

3.10. Вывод продукта на рынок.

3.11. Управление нормативно-технологической документацией.

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

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

3.3.3. Система процессов компании как «блюдо спагетти»

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

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

Приведу некоторые характерные признаки (не взаимоисключающие) «системы» процессов, построенной по принципу «блюдо спагетти»:

• наличие нескольких файлов с фрагментарным описанием сквозных процессов разного масштаба и важности;

• моделей процессов много, но единый иерархический справочник процессов отсутствует;

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

• графические схемы процессов чрезмерно сложные (количество операций превышает двадцать – тридцать);

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

• операции разных процессов частично дублируют друг друга.

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