Владимир Репин - Бизнес-процессы. Моделирование, внедрение, управление
Структурные подразделения взаимодействуют, получая ресурсы и передавая результаты выполнения внутренних операционных процессов друг другу. Анализ взаимодействия сотрудников, находящихся в различных подразделениях, помогает выявлять сквозные процессы. Несущественно, в какую именно часть системы будет включен сквозной операционный процесс. Важно корректно определить его границы и состав участников.
Если разработанная компанией методика построения системы процессов (в данном случае это структурный подход) не позволяет идентифицировать сквозные процессы, то ее нельзя признать подходящей.
Приведем пример фрагмента системы процессов для иллюстрации структурного подхода (табл. 3.3.1).
Таблица 3.3.1. Фрагмент системы процессов из категории «Управление технологией и качеством продукции»
В таблице приведен пример структуры процессов из группы «Контроль соблюдения технологии производства». Стоит обратить внимание на процессы «Участие в обработке претензий по готовой продукции» и «Участие в обработке претензий по сырью». Что это за объекты? Насколько они ценны для компании? Увы, они не имеют самостоятельной ценности. Это всего лишь части сквозных процессов «Обработка претензий потребителей по готовой продукции» и «Претензионная работа по сырью и материалам» соответственно.
Может возникнуть вопрос: по каким принципам выделяются процессы внутри структурного подразделения? Как правило, принимают во внимание следующие моменты:
• количество процессов составляет не более 10–12;
• каждый процесс должен заканчиваться результатом, имеющим ценность для деятельности подразделения и/или компании;
• процессы должны быть сопоставимы по масштабу;
• технология создания продуктов/услуг.
3.3.2. Продуктовый подход к построению системы процессов
Продуктовый подход к построению системы процессов организации предполагает, что иерархический справочник процессов строится на основе определения перечня продуктов/услуг и последующей декомпозиции процессов по каждому продукту/услуге. При этом рассматриваются процессы, необходимые для создания соответствующих продуктов/услуг.
Системы процессов, полностью основанные на продуктовом способе построения, на практике встречаются редко. Один из наиболее наглядных примеров – процессная модель деятельности банка. Приведу ее фрагмент:
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. Вспомогательные процессы…
Плюс такого подхода – его кажущаяся простота: процессы выделяются на основе построения иерархического справочника продуктов и услуг, а на нижнем уровне – на основе анализа технологии создания элементарного продукта/услуги. Но если внимательно присмотреться к полученной структуре процессов, заметим ряд существенных минусов:
• большое количество уровней иерархии справочника процессов (реальные операции процессов появляются только на шестом уровне иерархии!);
• не выделяются сквозные процессы;
• в модели не прослеживаются цепочки создания ценности, на которых держится весь бизнес (вместо этого представлена мозаика элементарных услуг);
• возможное дублирование (например, процесс «Взимание комиссии» может быть типовым и запускаться с разными параметрами при оказании различных услуг; при рассматриваемом подходе он появляется несколько раз в разных частях системы);
• при внедрении новых продуктов/услуг придется перекраивать всю систему процессов.
Заметим, что если на каждую услугу (продукт) разрабатывать свой регламент, то база нормативных документов компании (банка) усложнится и станет неудобной для работы.
В примере с банком есть еще один недостаток, не связанный с продуктовым подходом. Это применение в классификаторе понятия «основные процессы» (еще выделяют «вспомогательные» и «управленческие» процессы). С моей точки зрения, категории «основной» или «вспомогательный» не должны использоваться при построении иерархического справочника процессов, так как это порождает процессные псевдоуровни, усложняющие структуру. При помощи понятий «основной» или «вспомогательный» можно характеризовать процессы, причем на любом уровне иерархии. Кроме них могут вводиться и другие характеристики процессов: степень автоматизации, эффективность, важность для достижения целей бизнеса и т. д. Но они не могут служить основой для построения системы процессов компании.
Приведу еще один фрагмент из рассматриваемой модели банка:
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. Управление проектом по разработке нового продукта/изменению текущего продукта.
