Владимир Репин - Бизнес-процессы. Моделирование, внедрение, управление
Система процессов может быть описана в файле MS Excel или в виде специального справочника в инструментальном средстве моделирования процессов[72].
Пример. Система процессов торгово-производственной компании представлена в виде графической схемы на рис. 3.1.1. Эта компания занимается производством и реализацией промышленной продукции.
Как правило, система процессов организации представляет собой иерархический справочник процессов следующего вида:
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-й уровень).
В табл. 3.1.1 представлены основные определения, которые можно использовать при формировании системы процессов организации.
Таблица 3.1.1. Определения уровней деятельности в системе процессов организации
Рис. 3.1.1. Пример представления системы процессов организации в виде графической схемы
Система процессов может строиться сразу в виде иерархического справочника процессов. Другой возможный вариант – описание модели деятельности компании на верхнем уровне в некоторой нотации с последующим представлением в виде иерархического справочника. Если речь идет о построении системы процессов для действующей организации, то, с моей точки зрения, полезно разрабатывать систему процессов сразу в виде справочника, не формируя графическую модель верхнего уровня. Форма справочника более понятна большинству руководителей. Далеко не все топ-менеджеры могут воспринимать сложные графические модели структурного типа (например, в нотации IDEF0[73]).
После того как система процессов в виде иерархического справочника построена, при необходимости могут быть созданы модели деятельности в виде графических схем. На уровнях 1–3 целесообразно использовать структурные типы моделей (например, IDEF0). С уровня 4 (для небольших компаний – с уровня 3), как правило, описание выполняют при помощи схем в формате Work Flow. Удобный способ их визуального представления – кросс-функциональные схемы, содержащие дорожки. На каждой дорожке указываются операции, выполняемые подразделениями/сотрудниками/бизнес-ролями. Пример: «начальник отдела продаж» – сотрудник, «инициатор договора» – бизнес-роль. Подробно методики описания графических схем в формате Work Flow рассмотрены в главе 4.
Пример. Аналогия с техническим устройством
Рассмотрим внутреннее устройство электронного прибора. В нем есть печатные платы с элементами, микросхемы, блок питания, жгуты проводов и т. п. Жгуты (шлейфы) состоят из нескольких проводков. Каждый проводок – проводник определенного, вполне конкретного электрического сигнала. Для работы устройства необходимо, чтобы конкретные провода были присоединены к конкретным элементам. В результате создается корректно работающая электрическая схема.
Аналогия с организацией следующая. Проводки – это потоки документов (информации) и материальных ресурсов, возникающие при выполнении процессов. Эти потоки являются конкретными – каждый документ выходит из одной операции процесса и входит в другую. Как можно объединить несколько потоков в один? В электрическом приборе это проводки, скрученные в жгуты (шлейфы). Они могут быть разного цвета и формы. Как именно отдельные проводки собраны в жгуты (шлейфы), определяет разработчик электронного прибора (инженер). Конструкция прибора может быть совершенно разная.
Так и в компании. При создании модели верхнего уровня объединение потоков и агрегирование операций процессов остается на совести бизнес-аналитика. Сделать это можно по-разному. Если при создании электронных приборов действуют хотя бы некоторые стандарты, то при создании системы процессов организации таких стандартов фактически нет[74]. Есть только нотации для создания графических схем и некоторое ви́дение типовой структуры категорий процессов на верхнем уровне («Продажи», «Производство», «Закупка»…). Но что получится в результате моделирования, очень зависит от компетенции и опыта бизнес-аналитика.
Обратим внимание на тот факт, что реальная жизнь начинается на уровне операционных процессов там, где возникает реальный документооборот (информационные потоки). Модели верхнего уровня – это некоторая абстракция, «дизайн» системы, который может быть выполнен по-разному. Поэтому ценность модели верхнего уровня определяется возможностью ее использования для оптимизации бизнес-модели организации, назначения зон ответственности руководителей и т. д.
Если модель организации на верхнем и среднем уровнях выполнена некорректно, то ее невозможно использовать на практике. Далеко не в каждой организации найдется опытный бизнес-аналитик, способный построить модель верхнего уровня, действительно имеющую ценность для управления.
Для уже действующих организаций можно ограничиться иерархическим перечнем процессов, а описание процессов в виде графических схем выполнять только на операционном уровне – уровне реального документооборота и потоков информации. Важно, чтобы практика определяла требования к модели, а не формализованная нотация ограничивала реальную практику бизнеса.
Пример. Согласно требованиям стандарта IDEF0 на схеме не может быть более 8 объектов деятельности (подпроцессов). Но в реальности часто требуется показывать большее число подпроцессов. Что делать в случае, если на схеме IDEF0 показано 12 подпроцессов? Создавать 3 отдельные модели по 5 + 4 + 3 подпроцесса в каждой? Агрегировать 12 подпроцессов на 3 подпроцесса («основные», «вспомогательные», «управленческие») с последующей декомпозицией? Однозначного ответа нет.
Как правило, на уровне операционных процессов в системе процессов компании определяются и согласуются между собой входы/выходы процессов. Вопрос определения и согласования входов/выходов не такой простой, как кажется. Дело в том, что определение входов/выходов – весьма неоднозначная и ресурсоемкая задача. Если есть уверенность в том, что система процессов построена адекватно (а это зависит от методики и опыта бизнес-аналитиков), то входы/выходы могут быть корректно определены уже на следующем этапе – описания бизнес-процессов. Конечно, при этом в систему придется вносить некоторые изменения. Но система процессов – не застывшая, а живая, развивающаяся модель деятельности организации. Поэтому не стоит бояться вносить в нее изменения. Важно определить и регламентировать правила их внесения.
