Читать онлайн «Бизнес-процессы. Моделирование, внедрение, управление». Страница 38

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подход CBM (Component Business Model) компании IBM довольно интересен (табл. 3.3.2). Этот метод пока мало распространен в России, но некоторые крупные компании уже используют его для построения процессной модели бизнеса.

Таблица 3.3.2. Построение системы процессов компании на основе метода CBM

Для построения системы процессов компании в рамках модели CBM нужно:

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

• для каждой компетенции и для каждого уровня управления определить так называемые компоненты;

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

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

В модели CBM компоненты, по сути, это группы процессов. Привязка компонент к уровню управления весьма субъективна, как и сами уровни. На мой взгляд, уровни управления – узкое место CBM из-за отсутствия однозначных критериев отнесения к ним компонент. Мне встречались модели, в которых компоненты привязывались к нескольким уровням управления.

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

Как правило, после построения таблицы вида 3.3.2 определяют текущий уровень эффективности выделенных компонент. Затем путем цветового кодирования отображают в таблице состояние системы. Часть процессов (компонент) выделяют желтым или оранжевым фоном (низкая эффективность), часть – голубым (высокая эффективность) и т. п. Цветовое кодирование удобно использовать для формирования презентаций, представляемых руководителям компании. По ходу выполнения проекта на схеме изменяют цвета для оптимизированных (автоматизированных) процессов.

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

Наша команда консультантов[79] в настоящее время использует метод анализа бизнеса компаний на основе цепочек создания ценности (ЦСЦ).

Как само понятие ЦСЦ, так и выбор метода ее описания при помощи графических схем неоднозначны. Мы используем схемы ЦСЦ в качестве эскизных моделей. Они позволяют понять, как работает бизнес с процессной точки зрения.