Бесплатный фрагмент - Разработка архитектуры бизнес-процессов компании в Business Studio

1. Введение. Зачем нужна архитектура процессов компании?

1.1. Для кого и для чего написана эта книга

Вы держите перед собой книгу — краткое практическое пособие по построению архитектуры бизнес-процессов компании с использованием нотаций IDEF0, BPMN и программного продукта Business Studio. В книге достаточно подробно разобраны правила использования нотации IDEF0. Нотация BPMN рассматривается только в части интеграции схем BPMN в общую архитектуру процессов компании. Читателям, которые хотели бы начать использовать BPMN, рекомендую обратиться к книге [3] в «Списке рекомендуемой литературы».

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

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

Кроме построения архитектуры, другие методы и инструменты внедрения Системы управления бизнес-процессами компании рассматриваться не будут, так как по этой теме есть ряд вполне актуальных книг (см., например, [1]).

Данная книга поможет вам:

1. научиться использовать нотацию IDEF0 для проектирования бизнес-процессов;

2. освоить базовый функционал программы Business Studio в части создания моделей процессов в нотации IDEF0;

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

Книгу могут использовать как подготовленные читатели (специалисты по орг. развитию, бизнес-аналитики), так и все желающие изучить метод проектирования бизнес-процессов с использованием нотации IDEF0 (нотация BPMN рассматривается только в части интеграции с моделями в IDEF0).

Представленные подходы могут быть использованы при построении архитектуры бизнес-процессов в других нотациях (например, в ARIS VAD) и программных продуктах после некоторой адаптации.

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

1.2. Функциональный и процессный подходы к управлению

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

Как правило, функциональный процесс сам по себе не создает законченный результат ни для компании в целом, ни для ее клиентов. Этот результат носит промежуточный, частичный характер. Только несколько функциональных процессов, определенным образом взаимодействующих между собой, могут создавать результат, действительно важный для организации и/или ее клиентов (в широком смысле).

Справа на рисунке 1 показано, как из функциональных процессов «собраны» два сквозных процесса — А и Б. Часть функциональных процессов невозможно (либо нерационально) отнести к сквозным процессам, но их можно определенным образом сгруппировать в рамках архитектуры. (Чуть ниже я дам определение сквозного процесса).

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

При этом никто не мешает руководителям подразделений применять базовые методы процессного управления к своим функциональным процессам. Четкое определение их границ, регламентация и автоматизация помогут повысить эффективность работы организации. Эффект, безусловно, будет. Но не такого масштаба, как от оптимизации и управления сквозными процессами масштаба компании в целом или ее крупных сегментов.

1.3. Необходимые определения

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

Архитектура бизнес-процессов — совокупность определенных в компании взаимосвязанных бизнес-процессов различного уровня, представленных в виде моделей в нотациях IDEF0 и BPMN (eEPC), созданных с использованием программного продукта Business Studio (ARIS, iGrafx, Elma и т.п.).

Приведу еще определение архитектуры системы из Википедии:

Архитектура системы — принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию.

Если во втором определении заменить слово «элемент» на «бизнес-процесс», то получится хорошее определение архитектуры бизнес-процессов компании. Далее в книге вы сможете ознакомиться как раз с принципами методологии построения такой системы с использованием нотации IDEF0 и программного продукта Business Studio.

Можно дать и другие определения архитектуры. Вам важно выбрать какое-то одно и постоянно использовать его при выполнении проекта.

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

Архитектура состоит из процессов. Приведу рабочее определение:

Бизнес-процесс — устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя.

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

Чтобы определить бизнес-процесс, необходимо установить его границы. Для этого нужно определить входы и выходы, а также условия начала и завершения процесса (события).

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

Замечу, что при создании графических диаграмм в нотации IDEF0, понятие «Событие» не используется, так как нотация IDEF0 не является нотаций типа Work Flow.

Входы и выходы — это информационные или материальные объекты: файлы с информацией, документы на бумажном носителе, материалы для производства и т. п. Требования к каждому входу/выходу должны быть четко определены (специфицированы) в документах и согласованы со всеми заинтересованными сторонами: с поставщиками и потребителями процесса, руководством вышестоящего уровня и, в некоторых случаях, с государством.

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

На рис. 2 показано, что бизнес-процесс выполняется по определенной «технологии». По сути, это продуманная система действий, выполнение которых приводит к получению результата с заданными, повторяющимися характеристиками. Для практического выполнения нужны ресурсы — люди, оборудование, информационные системы и проч. Они связаны между собой в том смысле, что отсутствие необходимого оборудования или людей повлечет за собой изменение технологии. Наоборот, цель изменения (оптимизации) бизнес-процесса может повлечь за собой изменения в требованиях к ресурсам.

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

Слева на рис. 2 показан график нагрузки на бизнес-процесс. Объекты («Входы»), которые нужно обрабатывать, поступают с определенной интенсивностью в течение определенного времени. Например, необходимо обрабатывать партию из 5 деталей каждые 2 минуты. В этом случае график нагрузки будет дискретным — с равномерным интервалом. Другой пример — суточный график количества посетителей для супермаркета, на котором будут видны периоды пиковой нагрузки.

Итак, нагрузка на бизнес-процесс — это количество объектов, поступающих на вход процесса, которое нужно обработать за единицу времени. Однако, возможности процесса ограничены, в первую очередь, по ресурсам. Используемая технология выполнения процесса и ресурсы (оборудование, люди) определяют производительность процесса — возможность преобразовывать определенное количество объектов за единицу времени. На рис. 2 снизу показан график производительности процесса. На нем видны ступеньки. Это может быть, например, из-за того, что вводилось/выводилось из эксплуатации оборудование, добавляли людей в рабочие смены и т. п.

Что будет с объектами, которые бизнес-процесс не в состоянии пропустить через себя из-за ограничений по производительности? Они встанут в очередь — см. соответствующий график на рис. 2.

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

На рис. 2 показаны цели и показатели, а также владелец бизнес-процесса. Цели и показатели нужны для управления процессом. Производительность является одним из ключевых показателей. Кроме нее, важно измерять результативность (план/факт по полученным результатам), эффективность (отношение результата к затраченным на его получение ресурсам), показатели качества (например, уровень дефектов в выходах процесса).

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

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

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

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

1.4. Иерархическое представление бизнес-процессов

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

Модель не должна быть слишком сложной. Эта сложность может стать препятствием для анализа, обоснования и внедрения изменений.

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

Группа процессов, в свою очередь, декомпозирована на процессы, один из которых разделен на операционные процессы.

---

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

Визуально на рис. 3 показаны четырехугольники различного размера. Чем ближе к основанию пирамиды, тем они меньше. Этот означает, что бизнес-процессы различных уровней отличаются по масштабу. Тем не менее, к каждому из них применимы подходы, как к объекту управления (см. рис. 2).

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

На рис. 3 не показаны связи между бизнес-процессами, так как это чрезмерно усложнило бы схему. Но вы мысленно можете представить себе большое количество стрелок, соединяющих между собой четырехугольники. Это представление будет одним из возможных для понимания сути иерархической архитектуры бизнес-процессов компании.

Бизнес-процессы различных уровней иерархии нужно как-то называть. Можно, например, использовать способ, представленный организацией APQC (American Productivity & Quality Center) в так называемой модели Cross Industry Process Classification Framework (PCF). В рамках этой модели определены следующие уровни процессной архитектуры:

Уровень 1 — Категория — представляет наиболее высокий уровень процессов в организации.

Уровень 2 — Процессная группа — указывает на следующий уровень процессов и представляет собой группу процессов.

Уровень 3 — Процесс — это следующий уровень декомпозиции после процессной группы. Он может включать ключевые элементы, необходимые для выполнения процесса так же, как и элементы, связанные с вариантами и переделками.

Уровень 4 — Операция — показывает ключевые события, возникающие при выполнении процесса.

Уровень 5 — Задача — представляет собой следующий уровень иерархической декомпозиции после операций. Задачи являются более раздробленными и в значительной степени зависят от отрасли.

Видно, что в APQC, по сути, нет четких определений уровней. Есть лишь некоторое их описание.

Взяв названия уровней из APQC, в ряде проектов я использовал следующие определения:

Категория бизнес-процессов — совокупность групп бизнес-процессов, объединенных по критериям общности поставленных целей и единства методов создания ценности для потребителей.

Группа бизнес-процессов — совокупность процессов, объединенных по критериям общности поставленных целей и единства методов создания ценности для потребителей.

Процесс — совокупность взаимосвязанных операционных процессов, выполняемая одним или несколькими субъектами (подразделение, должность, роль).

Операционный процесс — ограниченная совокупность операций, выполняемая одним и более субъектами (должность, роль).

Операция процесса — ограниченная совокупность транзакций, выполняемая одним субъектом (должность, роль) или модулем информационной системы/программного продукта.

Транзакция — часть операции, которая может быть выполнена только целиком, либо вообще не выполнена.

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

С технической точки зрения проще и удобнее было бы вообще не вводить определения для процессов разных уровней иерархии, а просто называть «Процесс 1-ого уровня», «Процесс 2-ого уровня» и т. п. При этом принципиально важными являются следующие три момента:

1. на определенных уровнях сверху (1—3, иногда 1—4) для описания процессов могут использоваться модели только структурного типа (например, нотация IDEF0);

2. с некоторого уровня (4 или ниже) для описания процессов используется принципиально другой тип моделей — Work Flow (например, нотации eEPC или BPMN);

3. необходимо корректно увязывать между собой структурные модели (IDEF0) и модели типа Work Flow (eEPC и BPMN) в рамках единой архитектуры бизнес-процессов организации.

Выше я использовал термин «структурная модель». Приведу общее определение из Википедии: «Структура — определённая взаимосвязь, взаиморасположение составных частей, строение, устройство чего-либо». В философии «Структура — совокупность связей между частями объекта». Поэтому нужно сделать следующее определение:

Структурная модель бизнес-процесса — модель, включающая в себя части процесса и связи между этими частями, представляющие собой однонаправленные потоки объектов (информация, документы, материальные ресурсы).

Модель Work Flow бизнес-процесса — модель, включающая в себя части процесса и связи между этими частями, показывающие последовательность выполнения частей процесса во времени.

1.5. Цели создания архитектуры бизнес-процессов

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

Топ-менеджмент и собственники компании:

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

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

• возможность анализа и обоснования изменений в организационной структуре и бизнес-процессах;

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

• создание единой процессной платформы для всех проектов и инициатив по изменению деятельности компании, в первую очередь, по автоматизации системы синхронизованных между собой бизнес-процессов (в BPM-приложениях, СЭД);

• наличие актуальной регламентной базы по бизнес-процессам;

• накопление знаний по выполнению и совершенствованию бизнес-процессов.

Руководители и специалисты:

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

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

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

• возможность использовать модели процессов для разработки требований к автоматизации и настройке систем класса BPMS, СЭД и др.;

• возможность использования базы знаний для совершенствования бизнес-процессов;

• возможность обучать новых сотрудников.

Процессный офис (Отдел организационного развития):

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

• создание единой процессной платформы для всех проектов и инициатив по изменению деятельности, в первую очередь, по автоматизации системы синхронизованных между собой бизнес-процессов (в BPM-приложениях, СЭД и др.);

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

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

• накопление знаний по выполнению и совершенствованию бизнес-процессов.

1.6. Требования к архитектуре бизнес-процессов как к объекту управления

Архитектура бизнес-процессов компании сама по себе является сложной системой, т.е. объектом, требующим управления.

В рамках архитектуры приходится использовать модели разного типа. Как правило, на 1—4 уровне используются диаграммы процессов структурного типа, например, сформированные в нотации IDEF0. На нижележащих уровнях используются диаграммы класса Work Flow, например, разработанные в нотации BPMN (eEPC).

На структурных диаграммах в нотации IDEF0 стрелки используются для моделирования потоков информационных и материальных объектов. На диаграммах в нотации BPMN базовый тип связи — это стрелка типа Sequence flow (поток управления). Стрелки такого типа показывают хронологический порядок, в котором выполняются операции процесса. Кроме того, на схемах в нотации BPMN можно дополнительно показывать потоки информации.

Переход от диаграммы одного типа к диаграммам другого типа сопряжен с рядом проблем методического характера, которые можно практически решить с учетом возможностей конкретной среды моделирования, в частности, Business Studio.

Еще одной практической проблемой является неравномерный рост иерархии сверху-вниз. Это означает, что некоторые «ветки» архитектуры могут быть глубже других. Для их адекватного описания приходится использовать структурные диаграммы в нотации IDEF0 на большем количестве уровней, чем 3. Поэтому один бизнес-процесс может быть представлен несколькими уровнями диаграмм в архитектуре процессов.

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

Таблица 1. Уровни бизнес-процессов.

Из таблицы 1 видно, что на уровне 3 «Процессы» может быть два уровня диаграмм. Так же это возможно на уровне 4 «Операционные процессы». Обратите внимание — начиная с уровня 4, для формирования графических схем используется нотация BPMN.

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

Таблица 2. Требования к архитектуре
бизнес-процессов.

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

Если архитектура будет построена не с использованием реального потока объектов, а при помощи некоторых абстрактных, обобщенных стрелок, то практически определить границы бизнес-процессов в рамках модели не получится.

Замечу, что в Business Studio технически можно определить руководителей, ответственных за выполнение процессов, без определения входов/выходов процессов. Для этого достаточно иметь реестр процессов в виде справочника. Назначение ответственных осуществляется путем определения связи между субъектом (должность, роль) и процессом (через интерфейс системы). Однако с точки зрения практики, такое назначение будет довольно абстрактным до тех пор, по четко не будут определены границы соответствующих процессов.

Для определения границ нужно четко определить, какие документы (информация) и материальные ресурсы пересекают эти границы. Нужно определить спецификации, показатели оценки, методы и средства измерения. Но надо четко понимать, что детальное определение границ всех процессов по входам/выходам может повлечь за собой большой объем работы по идентификации и занесению в среду моделирования соответствующей информации о процессах (например, по ходу так называемой «паспортизации процессов»).

При создании архитектуры процессов компании нужно четко понимать возможности и знать ограничения, связанные как с используемой нотацией, таки и функционалом Business Studio.

2. Методика построения архитектуры процессов: общий обзор

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

Общая методика построения архитектуры бизнес-процессов компании в Business Studio включает в себя следующие этапы:

1. Разработка модели организационной структуры компании.

2. Формирование реестров функциональных бизнес-процессов подразделений и основных справочников.

3. Создание контекстной модели бизнеса в нотации IDEF0 (уровень «0»).

4. Разработка моделей (или реестров) категорий бизнес-процессов в нотации IDEF0 (уровень «1»).

5. Разработка моделей (или реестров) процессных групп в нотации IDEF0 (уровень «2»).

6. Разработка моделей (или реестров) процессов в нотации IDEF0 (уровень «3»).

7. Разработка моделей операционных процессов в нотации BPMN (уровни «4» и «5»).

8. Перегруппировка объектов в справочниках объектов деятельности (если будет принято такое решение).

Методика разработана с учетом ее применения в конкретной среде моделирования, а именно — в Business Studio. При использовании другого программного обеспечения Методику необходимо скорректировать.

Этап 1. Для каждого бизнес-процесса в архитектуре должны быть определены исполнители и ответственные. Ими могут являться подразделения, должности или роли. Поэтому на первом этапе целесообразно создать модель организационной структуры компании в Business Studio.

Этап 2. Необходимо выполнить анализ деятельности подразделений и определить реестр бизнес-процессов (на 2-3-х уровнях представления) для каждого функционального подразделения. Реестры заносят в Business Studio в виде иерархического справочника. Заполняются справочники документов, информации, материальных ресурсов, информационных систем, баз данных, терминов. Группировка объектов в справочниках осуществляется на основе структуры функциональных подразделений. Таким образом, получаем реестры функциональных процессов подразделений.

Этап 3. Разрабатывается контекстная модель бизнеса (диаграмма А-0, уровень «0») (или отдельного сквозного процесса). Для этого определяются и группируются поставщики и потребители компании, а также другие субъекты, которые с ней взаимодействуют. Определяются входы/выходы для бизнеса компании в целом.

Этап 4. Выполняется анализ деятельности компании. Выбирается принцип группировки категорий процессов. Разрабатывается диаграмма А0 (уровень 1).

Этап 5. Разрабатываются модели для каждой процессной категории, включающие группы процессов. При определении групп процессов используются реестры функциональных процессов подразделений, разработанные на Этапе 2.

Этап 6. Разрабатываются модели процессов для каждой процессной группы. Процессы формируются из реестров функциональных процессов подразделений.

Этап 7. Разрабатываются модели операционных процессов для каждого процесса. Операционные процессы могут создаваться непосредственно в процессной модели или формироваться из реестров функциональных процессов подразделений.

Этап 8. Выполняется перегруппировка объектов в справочниках (кроме справочника «Процессы») для перехода от функциональной к выбранному типу процессной модели. Новая группировка осуществляется в соответствии со структурой категорий и групп процессов компании.

На каждом этапе работы возникает ряд практических нюансов и проблемы, которые будут рассмотрены ниже.

2.2. Инструмент Business Studio

Разработка архитектуры бизнес-процессов осуществляется в программном продукте Business Studio.

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

Формирование диаграммы процессов в Business Studio 4 осуществляется при помощи движка MS Visio, встроенного в интерфейс системы.

Business Studio позволяет формировать сложные диаграммы бизнес-процессов и увязывать их между собой по входам/выходам.

Для дальнейшей работы с книгой вам потребуется Business Studio. Связавшись с автором (info@bpm3.ru), можно получить временную полнофункциональную версию системы на срок один месяц для разработки архитектуры бизнес-процессов вашей компании.

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

2.3. Требования к ресурсам

Для того, чтобы выполнить проект разработки архитектуры бизнес-процессов вашей компании, как минимум, необходимы:

1. Решение Генерального директора (или собственника).

2. Сформированная временная рабочая группа (ВРГ) из 3—5 человек, включая руководителя проекта.

3. Установленная среда моделирования процессов Business Studio.

4. Ресурс рабочего времени (в рамках проекта):

• Генеральный директор — 6—8 часов.

• Руководители департаментов — 6—8 часов (на каждого).

• Руководители отделов — 12—16 часов (на каждого).

• Участники рабочей группы — от 80 часов (на каждого).

5. Помещение для проведения совещаний ВРГ, проектор, принтер и проч.

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

3. Разработка модели организационной структуры

3.1. Формирование справочника орг. структуры компании

Итак, мы приступаем к практической части. Откройте Business Studio. Вы видите интерфейс следующего вида (см. рис. 4). Наверху представлена лента вкладок, которую можно свернуть. В меню «Главная» есть кнопка «Навигатор объектов». Ей можно воспользоваться, если вы случайно закрыли Навигатор.

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

На Этапе 1 создания архитектуры бизнес-процессов нам потребуется справочник «Субъекты». Необходимо кликнуть по нему левой кнопкой мышки. Откроется справочник субъектов — тоже пока пустой.

Справочник «Субъекты» в Business Studio служит для описания организационной структуры и структуры ролей. В этом справочнике создается и поддерживается в актуальном состоянии модель организационной структуры компании. Объекты модели компании, которые можно создавать в справочнике «Субъекты» в Business Studio принято называть «Субъекты».

Таблица 3. Типы субъектов в справочнике «Субъекты».

Для начала создадим субъект «Компания» (см. рис. 5). Для этого поместите курсор на любую часть белого поля и нажмите правую кнопу мышки. В появившемся меню выберите «Добавить» и «Подразделение». Присвойте название «Компания» созданному субъекту.

Кроме подразделения можно добавить должность, внешнего субъекта и роль. Папки могут использоваться для группировки, например, ролей при создании ролевой структуры компании.

Выделите мышкой субъект «Компания» в справочнике «Субъекты», по правой кнопке выберите «Добавить» и «Должность», как показано на рисунке 6. Созданный субъект назовите «Генеральный директор».

Если вы выберите команду «Добавить на этот уровень», то должность появится в справочнике на одном уровне с подразделением «Компания». Так делать в данном случае не нужно.

То, что должность находится ниже структурного подразделения по иерархии — нормально. Такой подход к формированию модели организационной структуры используется в Business Studio. К нему просто нужно привыкнуть.

Под субъектом «Генеральный директор» создайте следующие подразделения:

1. Департамент продаж.

2. Департамент закупок.

3. Производственный департамент.

4. Технологический департамент.

5. Инженерно-технический департамент.

6. Финансовый департамент.

7. Юридический департамент.

8. Департамент по работе с персоналом.

---

После того, как вы создадите все департаменты, нужно упорядочить их так, как в списке. Для этого выделите мышкой «Департамент продаж». Нажмите правую кнопку мыши и выберите «Свойства». На закладке «Основные» найдите «№ п/п». Поставьте там цифру «1» (см. рис. 7). Нажмите кнопку «Сохранить», распложенную слева. Она сохраняется объект модели, не закрывая окно ввода. Напротив, кнопка «Сохранить», расположенная справа, сразу закрывает окно после сохранения. Не закрывая окно, выберите мышкой в справочнике субъект «Департамент закупок». В «№ п/п» поставьте цифру 2. Нажмите левую кнопку «Сохранить». Далее присвойте каждому субъекту номер в соответствии с представленным выше списком. После этого нажмите кнопку «Обновить дерево» в Навигаторе.

Как вы видите, список департаментов в справочнике соответствуют списку, представленному в книге.

Далее в справочнике «Субъекты» вам нужно последовательно создать несколько уровней подразделений и должностей, как показано на схеме организационной структуры компании (см. рисунок 10).

Фрагмент готового справочника орг. структуры компании показан на рисунке 9.

3.2. Формирование диаграммы оргструктуры компании

После того, как вы создали в справочнике все субъекты в соответствии со схемой, представленной на рис.10, необходимо сформировать диаграмму орг. структуры в Business Studio. Для этого нужно два раза кликнуть мышкой по субъекту «Компания». Первичную настройку можно не выполнять.

Диаграмма, которую вы увидите, будет разительно отличаться от схемы орг. структуры, представленной на рис. 10. Необходимо ее доработать в части:

• расположения названий внутри пиктограмм субъектов (подразделения, должности);

• цветов;

• расположения объектов на диаграмме.

Для того, чтобы схема орг. структуры (автоматически сформированная Business Studio) уместилась на лист формата А4, пришлось существенно изменить ее вручную, передвигая объекты.

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

Кстати, верхняя «Лента вкладок» была свернута для экономии места. Это легко сделать самостоятельно.

3.3. Рекомендации по именованию подразделений и должностей

При формировании справочника организационной и ролевой структуры («Субъекты») в Business Studio необходимо придерживаться определенных правил:

• моделирование организационной структуры всегда начинается с субъекта типа «Подразделение». Далее субъекты типов «Подразделение» и «Должность» чередуются в иерархическом порядке;

• допускается показывать в справочнике должность подчиненного сразу под должностью руководителя, если в подразделении не определены нижестоящие структурные подразделения (пример: для «Начальник отдела…» подчиненный объект модели — субъект «Специалист…»);

• требования к формулировке названий подразделений:

— название подразделения указывается с заглавной буквы без точки в конце;

— в названии не должны повторяться названия подразделений вышестоящего уровня (например, «Отдел… Управления… Департамента»);

— сокращения не допускаются;

• требования к формулировке названий должностей:

— название должности указывается с заглавной буквы без точки в конце;

— в названии руководящей должности должно быть указано название управляемого подразделения со строчной буквы (например, «Руководитель департамента по продажам»);

— для должности, не являющейся руководящей, использование названия подразделения в названии должности не допускается;

— сокращения не допускаются.

3.4. Рекомендации по созданию и именованию ролей

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

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

Присваивание ролей для должности осуществляется через вкладку «Роли субъекта» для субъекта типа «Должность». Одна должность может быть связана с несколькими ролями и на одну роль могут быть назначены разные должности.

При создании ролей в Business Studio необходимо придерживаться определенных правил:

• в названии роли допускается использование оборотов «Менеджер по…» (в случае, если такое название отсутствует в штатном расписании) и «Сотрудник, ответственный за…»;

• название роли должно отражать основную функцию роли в процессе (Пример: «Менеджер по регистрации претензий по качеству готовой продукции…»);

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

• название роли должно иметь следующую структуру: существительное + «конкретизирующее дополнение»;

• количество слов в названии роли не должно превышать 8 слов, не включая предлоги, союзы и междометия (пример: «Регистратор приказов по основной деятельности»);

• исключениями из предыдущих пунктов являются устоявшиеся названия, принятые в бизнес-среде (пример: «Системный администратор»);

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

4. Формирование реестров функциональных бизнес-процессов подразделений и основных справочников

4.1. Формирование реестров функциональных бизнес-процессов

После формирования модели орг. структуры можно приступить к анализу деятельности функциональных подразделений компании. Участники ВРГ (временной рабочей группы) должны ознакомиться с нормативно-методическими документами, регламентирующими деятельность подразделений. Затем проводятся интервью с руководителями подразделений, цель которых — собрать информацию и сформировать реестры бизнес-процессов функциональных подразделений. Функциональные бизнес-процессы можно заносить сразу в Business Studio следующим образом — см. рис. 11.

Обратите внимание на следующее:

1. В справочнике «Процессы» создана папка «Функциональные бизнес-процессы».

2. В этой папке созданы папки следующего уровня в соответствии с организационной структурой — указаны названия Департаментов и отделов.

3. В папке отдела (в данном примере — это нижний уровень) создана модель в нотации IDEF0, диаграмма А-0 названа «Контекст», диаграмма А0 названа «Процессы отдела…»;

4. Определены функциональные бизнес-процессы отделов.

Обратите внимание на следующие особенности используемого метода:

• папки с названием должностей сотрудников не создаются и функциональные процессы уровня сотрудников в этих папках не определяются;

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

Кстати индексы А1 и т.п., которые вы видите, автоматически созданы системой Business Studio с учетом принятых правил использования нотации IDEF0. При желании, эти индексы можно изменить или вообще отключить.

Сокращение ТКП означает «Технико-коммерческое предложение». Сокращение ГП означает «Готовая продукция».

В Business Studio для каждого процесса должны быть определены исполнители. Для этого нужно открыть по правой кнопке «Свойства» процесса, найти слева вкладку «Основные» и в списке «Субъекты» выбрать соответствующее подразделение из справочника «Субъекты» (или перетащить из справочника «Субъекты» мышкой). Так же нужно выбрать тип связи «выполняет».

На рис. 12 показан пример. Мышкой выбрать процесс «А1 Сбор информации о рынке». По правой кнопке открыты его свойства. Из справочника «Субъекты» выбран «Отдел маркетинга», выбран тип связи «выполняет».

Так можно сделать для всех определенных функциональных бизнес-процессов.

Для примера разберем функциональные процессы отдела маркетинга. После обработки интервью, в Business Studio получился следующий реестр процессов этого отдела:

1. А1 Сбор информации о рынке.

2. А2 Проведение опросов клиентов.

3. А3 Анализ цен конкурентов.

4. А4 Формирование рекомендаций по ассортименту и ценам.

5. А5 Размещение рекламных объявлений.

6. А6 Анализ удовлетворенности клиентов.

7. А7 Разработка дизайна нового продукта.

8. А8 Участие в инициативах по повышению производительности.

9. А9 Переписывание цен конкурентов на выставках.

То, что вы получили такой реестр после интервью, не означает, что он является правильными и исчерпывающим. Практика показывает, что приходится запрашивать дополнительную информацию и уточнять реестр еще 2—3 раза. Проблема состоит в субъективности восприятия структуры и границ процессов у руководителей и сотрудников до внедрения процессного управления в компании.

Каждый процесс в этом полученном списке (реестре) должен удовлетворять следующим критериям:

• соответствие по масштабу;

• не быть разовой работой (поручением, проектом);

• не являться частью процесса из этого же списка.

Общее требование — количество бизнес-процессов в списке не должно превышать 8—9.

Если внимательно посмотреть на представленный выше список процессов отдела маркетинга, то сразу видно, что:

1) процесс «А2 Проведение опросов клиентов» является подпроцессом для процесса «А6 Анализ удовлетворенности клиентов»;

2) процесс «А8 Участие в инициативах по повышению производительности», собственно, процессом не является — его можно спокойно удалить из списка;

3) процесс «А9 Переписывание цен конкурентов на выставках» является подпроцессом для процесса «А3 Анализ цен конкурентов»;

4) процесс «А6 Анализ удовлетворенности клиентов» дублируется с таким же процессом в отделе продаж — нужно выяснить почему. Скорее всего, можно будет создать один процесс в рамках Департамента продаж в целом.

Далее надо внимательно посмотреть на список функциональных бизнес-процессов отдела — вполне возможно, что будет целесообразно объединить некоторые процессы. Это даст возможность сократить количество процессов в реестре отдела до приемлемого количества (лучше до 3—5). Группировка должна быть не формальной, а реальной. То есть, если процессы связанны по входам/выходам и служат для получения одного результата, их можно смело сгруппировать. На следующем этапе, при формировании диаграмм в IDEF0, будет наглядно видно, как они увязаны в единый бизнес-процесс.

На рис. 13 показан результат работы с реестрами отделов маркетинга и продаж. Что изменилось:

1) создан объект «Процессы департамента продаж»; в нем создан подпроцесс «А1 Анализ удовлетворенности клиентов», в который перенесен процесс «Проведение опросов клиентов»; в дальнейшем нужно будет внимательно изучить, какие еще подпроцессы входят в процесс «А1 Анализ удовлетворенности клиентов»;

2) перегруппированы процессы отдела маркетинга;

3) перегруппированы и частично переименованы процессы отдела продаж.

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

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

На рис. 13 видно, что, например, иерархия процессов отдела маркетинга «растет» неравномерно. Почему это плохо? Это может означать, что процессы, представленные на одном уровне модели, имеют различный масштаб. Это говорит о том, что работа по определению процессов проведена недостаточно тщательно.

Важно сформулировать правило «роста иерархии»: «Если в реестре бизнес-процессов одного уровня у какого-то процесса определены подпроцессы (на один уровень вниз), то у всех остальных так же должны быть определены подпроцессы (на один уровень вниз).

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

Использовать это правило нужно вдумчиво и аккуратно.

Обратите внимание, что если у всех процессов определены подпроцессы на один уровень вниз, а у какого-то одного на 2 уровня в низ, то этот факт не рассматривается как проблема. Но целесообразно обратить внимание на те ветки архитектуры, которые «растут» быстрее других. Возможно, стоит подумать и перегруппировать процессы.

Количество бизнес-процессов на каждом уровне не может быть меньше 2-х (кроме контекстной диаграммы) и больше 8—9. В некоторых компаниях принимают решение допускают наличие 10 процессов на одном уровне (диаграмме в нотации IDEF0).

На следующих рисунках 14—15 показаны реестры после проведения дополнительного анализа (путем интервьюирования и обработки информации) и выравнивания глубины функциональных бизнес-процессов отдела маркетинга и продаж.

Обратите внимание, что процессы были существенно перегруппированы и названия изменены. Возникли некоторые процессы, информации о которых ранее не было. Точнее она просто не была получена от руководителя и сотрудников отдела маркетинга, либо была зафиксирована некорректно. Процесс «Переписывание цен конкурентов на выставках» был удален из реестра (информация о нем осталась в рабочих материалах проекта). Если бы мы его оставили в качестве подпроцесса для «Сбор информации о конкурентах», то пришлось бы в соответствии с правилом равномерного роста иерархии декомпозировать все подпроцессы А1.1 — А1.4. (см. рис. 14. В дальнейшем, при детальной проработке процессов нижнего уровня, этот процесс, возможно, будет использован.

На рисунках видно, что нераскрытыми остались папки с процессами руководителей. Что это за процессы? Это процессы, которые входят в стандартный цикл управления по целям: целеполагание, планирование, организация, мониторинг и контроль, анализ отклонений, принятие и контроль исполнения решений, анализ результатов выполнения процесса за период.

Для директора по продажам был получен следующий реестр бизнес-процессов (см. рис. 16).

Некоторые процессы из этого списка вызывают сомнения:

• «Подписание ТКП для клиента» — это не процесс, а операция в рамках сквозного процесса «Формирование ТКП для клиента».

• «Проведение переговоров с ключевыми клиентами» — это, возможно, подпроцесс для процесса «Привлечение новых клиентов».

• «Согласование спец. скидок для клиентов» — это не процесс; вполне вероятно, то это одна из операций процесса «Проведение переговоров» или «Разработка спецификаций к договору».

• «Участие в еженедельных совещаниях у Генерального директор» — вообще не процесс.