Бизнес-процессы. Моделирование, внедрение, управление

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

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

Приведем пример фрагмента системы процессов для иллюстрации структурного подхода (табл. 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. Вспомогательные процессы…

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

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

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

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

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

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

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