Глава 4. Описание бизнес-процессов организации.

4.1. Цели описания бизнес-процессов организации.

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

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

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

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

_{Таблица 4.1.1. Возможные ситуации с описанием процессов.}

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

Сформулируем цели описания процессов для организаций разного размера.

Небольшая организация (10–100 человек).

Возможные цели описания процессов (моделирования) в небольшой организации:

1. Четкое определение зон ответственности руководителей по ключевым направлениям деятельности.

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

3. Анализ и улучшение деятельности.

4. Подготовка к автоматизации деятельности, в том числе процессов.

5. Первые шаги по созданию культуры процессного управления у сотрудников (обучение процессному ви́дению).

Средняя организация (100–1000 человек).

Возможные цели описания процессов (моделирования) в организации среднего размера:

1. Четкое определение зон ответственности руководителей на всех уровнях управления.

2. Оптимизация взаимодействия структурных подразделений за счет стыковки процессов по входам/выходам.

3. Системное описание процессов в формализованном виде. Централизованное хранение и актуализация моделей процессов. Постоянное использование моделей процессов для регламентации: регламенты выполнения процессов, инструкции по выполнению процессов, положения о взаимодействии и т. д.

4. Тиражирование стандартов деятельности (например, в филиалы).

5. Обучение сотрудников.

6. Автоматизация процессов.

7. Анализ и улучшение деятельности.

8. Развитие культуры процессного управления у сотрудников.

Крупная организация (> 1000 человек).

Возможные цели описания процессов (моделирования) в крупной организации:

1. Четкое определение зон ответственности руководителей на всех уровнях.

2. Оптимизация взаимодействия структурных подразделений за счет стыковки процессов по входам/выходам.

3. Создание системы процессов организации. Системное описание процессов в формализованном виде на нескольких уровнях (создание так называемой объектной модели организации). Централизованное хранение (в промышленной базе данных) и актуализация моделей процессов.

4. Автоматизация создания регламентирующих документов (при помощи выгрузки из среды моделирования на основе стандартных шаблонов). Формирование нормативно-методических документов: регламенты выполнения процессов, инструкции по выполнению процессов, положения о подразделениях, должностные инструкции. Формирование других отчетов: штатное расписание, карточки должности, карта грейдов[82], цели и показатели для управления процессами и т. д.

5. Описание и регламентация процессов управления на всех уровнях.

6. Анализ возможных изменений (реализация сценариев «что если?») в модели организации: 1) создание нового подразделения с передачей ему операций процессов других подразделений; 2) ликвидация подразделения с передачей его процессов другим подразделениям.

7. Тиражирование стандартов деятельности (например, в филиалы).

8. Выполнение внутреннего аудита.

9. Подбор персонала (на основе подробной информации о выполняемых сотрудником процессах).

10. Обучение сотрудников.

11. Автоматизация процессов.

12. Анализ и улучшение деятельности.

13. Управление знаниями о деятельности организации.

14. Вовлечение руководителей и сотрудников подразделений в работу по описанию и стандартизации деятельности организации.

15. Развитие культуры процессного управления у сотрудников.

4.2. Что нужно для успешного описания процессов в масштабах организации?

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

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

4.2.1. Формулировка целей описания процессов.

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

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

Цели описания процессов должны быть четко сформулированы в проектном документе. Возможными целями описания могут быть:

• анализ и последующая оптимизация процессов;

• разработка регламентирующих документов;

• подготовка к автоматизации процессов;

• прочее.

В 2011 году компания BPTrends провела исследования в области моделирования бизнес-процессов. Респондентами стали представители почти 16 000 зарегистрированных участников сообщества BPTrends и посетители соответствующего сайта (Северная Америка – 36 %, Европа – 32 % и т. д.). Поскольку деятельность BPTrends охватывает весь диапазон вопросов, составляющих часть понятия «бизнес-процесс», к исследованию были привлечены управленцы и практики, заинтересованные в комплексном подходе к процессному управлению.

BPTrends: «Моделирование процессов – актуальный метод, используемый практиками в сфере процессного управления, чтобы получать, систематизировать и передавать информацию о бизнес-процессах. Модели процессов могут быть изображены на рабочей доске, бумаге или представлены в цифровой форме в различных видах программного обеспечения для их моделирования. Они могут быть как абстракциями, определяющими фазы деятельности, так и детализированными изображениями осуществленных шагов и принятых решений в ходе конкретной операции. Например, менеджер может нарисовать на листе бумаги три прямоугольника для представления трех фаз, через которые обычно проходит его организация в ходе аудита. Специалист по программному обеспечению может изобразить множество прямоугольников со стрелками и ромбами для точного отражения решений, которые требовались для одобрения нового кредитного счета. И то и другое можно назвать моделями процесса, поэтому в рамках этого исследования термин “моделирование процесса” использовался очень широко для возможности рассмотрения всех видов моделирования…».

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

_{Рис. 4.2.1. Как вы используете моделирование бизнес-процессов?}

На первом месте (81 %) стоит пункт «Вместе с реинжинирингом и совершенствованием процессов». Это означает, что около 81 % компаний используют моделирование как средство для описания, анализа и оптимизации бизнес-процессов.

На втором месте – пункт «Для передачи информации о процессе». Иными словами, это использование описания процессов для последующей регламентации, размещения информации о процессах на портале организации и т. п.

4.2.2. Нотация моделирования процессов.

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

При выборе нотации полезно обратить внимание на следующее. Если описание процессов делается для создания регламентирующих документов, то схемы процессов должны быть просты и интуитивно понятны сотрудникам организации, информативны при минимальном наборе используемых графических символов. Нет смысла усложнять графическое представление – полезную информацию вполне можно вывести в нормативно-методические документы в виде таблиц и текста. Выбранная нотация должна быть понятна большинству сотрудников без специального обучения и длительного освоения. Конечно, можно заставить людей описывать процессы в любых нотациях (например, в UМL[83]) при помощи совершенно разных средств моделирования, но затраты на внедрение таких нотаций/систем обычно значительны. Чрезмерно сложная нотация и средство моделирования сделают методы процессного управления доступными для узкого круга профессионалов из отдела организационного развития или IT-отдела, а преимущества процессного подхода не будут реализованы в полной мере.

Замечу, что если предполагается описывать процессы исключительно в целях последующей автоматизации, то лучше всего использовать нотацию BPMN[84] 2.0.

Сформулируем простые критерии для выбора нотации моделирования процессов на операционном уровне:

• в нотации представлен минимально необходимый набор графических элементов для описания процессов типа Work Flow (поток работ);

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

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

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

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

4.2.3. Репозиторий и среда моделирования процессов.

Представьте, что вам поручили разработать регламент выполнения какого-то процесса компании. Ситуация складывается удачно – у вас стоит MS Visio. Вы создаете новый файл, начинаете рисовать схему процесса, затем сохраняете ее, включаете в регламент, согласуете его с руководителями и т. п. Через два месяца нужно сделать еще один документ по той же процедуре. Кроме вас еще несколько руководителей и специалистов компании время от времени мастерят регламенты процессов. В результате в организации появляется множество схем, описанных в различных форматах и инструментах. Они хаотично хранятся в файлах на компьютерах разных пользователей. Как можно оценить такое положение дел? Неужели так работать удобно? Скорее всего, нет. Сложившуюся ситуацию можно охарактеризовать так:

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

• единого стандарта моделирования процессов нет;

• единого места для хранения схем процессов нет;

• внесение изменений в регламентирующие документы требует ручной работы;

• доступ сотрудников к информации по процессам затруднен;

• информация, формализованная в схемах и описаниях процессов, быстро устаревает.

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

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

А если в вашей компании полный порядок, означает ли это, что:

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

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

• выполняется описание процессов в специализированной системе с последующей автоматической генерацией (выгрузкой) регламентирующих документов в МS Word или MS Excel;

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

• обеспечен легкий и быстрый доступ сотрудников к информации по процессам (например, через внутренний портал)?

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

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

Безусловно, репозиторий бизнес-процессов полезен – это база знаний о деятельности компании. Если она будет полной и актуальной, то обеспечит возможность:

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

• с минимальными трудозатратами формировать регламентирующие документы:

– регламенты выполнения бизнес-процессов;

– регламенты управления бизнес-процессами;

– технологические инструкции;

– положения о подразделениях;

– должностные инструкции сотрудников;

– прочее;

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

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

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

• прочее.

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

Создание электронного репозитория бизнес-процессов – это инвестиция в будущее компании. Почему? Судите сами: внедряя репозиторий, вы:

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

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

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

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

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

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

При выборе среды моделирования, которая позволит создать репозиторий бизнес-процессов организации, важно обратить внимание на следующие ее возможности:

• простота и интуитивная понятность интерфейса;

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

• хранение информации о деятельности компании в базе данных (например, в СУБД MS SQL Server);

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

• размещение моделей на портале организации;

• работа в многопользовательском режиме.

Пример. Вы описываете процесс обслуживания оборудования. Для ряда операций нужно вывести в регламент текстовое описание, фотографии агрегатов, список используемых расходных материалов и т. д. Это легко сделать, используя возможности среды моделирования. После внесения информации в систему готовый регламент обслуживания оборудования генерируется в виде файла MS Word за считанные минуты.

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

Описанная ситуация годится для любого бизнес-процесса независимо от объекта деятельности.

Говоря о практическом использовании репозитория, следует отметить, что:

• для поддержания репозитория требуются квалифицированные специалисты;

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

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

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

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

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

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

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

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

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

_{Рис. 4.2.2. Какие три свойства средств моделирования процессов вы считаете самыми важными?}

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

Обратите внимание, что только 10 % опрошенных считают важной способность легко переходить от модели к коду программного обеспечения. Для остальных важнее оказались другие требования. Например, 36 % указали на «Способность создавать простые модели процессов», а 56 % – на «Способность сохранять модели и данные о процессах в репозитории». Эти факты говорят о том, что компаниям, которые используют моделирование процессов для анализа, оптимизации и документирования (регламентации), нужны:

• простая, но стандартная нотация моделирования;

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

4.2.4. Методики описания процессов.

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

• стандарт описания бизнес-процессов («Соглашение о моделировании бизнес-процессов»);

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

• инструкция по администрированию среды моделирования;

• прочее.

К сожалению, вопрос методического обеспечения проекта не всегда учитывается руководителями, принимающими решения о приобретении и внедрении среды моделирования процессов.

4.2.5. Наличие необходимых специалистов.

Важнейший фактор успешного внедрения – наличие в организации нескольких специалистов, которые могут:

• разрабатывать и изменять систему процессов организации;

• согласовывать процессы по входам/выходам;

• проводить интервью, получать и структурировать информацию по процессам;

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

• настраивать среду моделирования, в том числе формировать шаблоны отчетов для выгрузки регламентирующих документов;

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

• обучать сотрудников организации принципам и методам описания процессов;

• прочее.

Разработка и внедрение в организации системы описания процессов – довольно сложный и длительный (3–6 месяцев) проект, для успешного выполнения которого руководители организации должны выделить адекватные человеческие и финансовые ресурсы.

Пример. В торгово-производственной компании среднего размера приняли решение описывать бизнес-процессы. После проведения формального тендера приобрели среду моделирования процессов. Одному из сотрудников организации было поручено ее использовать. На методическое обеспечение, обучение персонала, настройку системы (справочники, отчеты) денег не выделили. В результате уполномоченный сотрудник в течение нескольких месяцев пытался описывать процессы на свой страх и риск. Полученные модели оказались весьма сомнительного качества. Кроме того, попытка документировать процессы окончилась неудачей, поскольку: а) заранее не были продуманы требования к информации, которую следовало использовать в описаниях процессов; б) у сотрудника, работающего со средой моделирования, не хватило квалификации для настройки необходимых шаблонов отчетов.

4.3. Объектная модель организации.

В этом параграфе мы обсудим вопрос создания так называемой объектной модели организации.

Моделирование организации предполагает определение и подробное описание таких объектов, как:

• процессы;

• владельцы/исполнители процессов (подразделения, должности, бизнес-роли);

• ресурсы: документы, файлы, ТМЦ65;

• инициирующие и завершающие события;

• термины;

• цели и показатели деятельности;

• физические лица, занимающие соответствующие должности;

• прочее.

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

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

В результате моделирования появляется объектная модель организации[85] – упорядоченная совокупность объектов, связанных между собой определенными способами.

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

Объектная модель реализуется только в виде соответствующей базы данных. Ее структуру, разработанную для решения задач бизнес-моделирования, можно называть метамоделью[86] организации.

На рис. 4.3.1 показано, как в результате деятельности по моделированию с использованием метамодели получается комплексная объектная модель организации.

_{Рис. 4.3.1. Связь объектной модели и метамодели организации.}

Метамодель организации, по сути, – это совокупность связанных таблиц СУБД (системы управления базы данных), и она может расширяться по мере необходимости. Например, для такого класса объектов, как должность, можно дополнительно определить следующие атрибуты:

• наименование должности;

• номер грейда;

• лицо, назначающее сотрудника на данную должность;

• лицо, осуществляющее представление на данную должность;

• показатели оценки эффективности;

• прочее.

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

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

4.4. Архитектура типовой среды моделирования процессов.

Сейчас на рынке представлено множество программных продуктов для моделирования деятельности организации. Эти продукты относятся к так называемым средствам Business Process Architecture или Enterprise Architecture, то есть программным инструментам, предназначенным для проектирования бизнес-процессов и бизнес-архитектуры компании. Руководителям и специалистам, внедряющим процессный подход, важно понимать общую архитектуру систем такого класса.

Рассмотрим архитектуру типовой среды моделирования процессов, представленную на рис. 4.4.1. Такая среда, как правило, имеет модульную структуру, которая определяется соответствующими сервисами. В конкретных системах сервисы могут объединяться в рамках единых программных решений, а также существовать и использоваться по отдельности в виде модулей.

_{Рис. 4.4.1. Архитектура типовой среды моделирования процессов.}

Информация о деятельности организации (справочники процессов, подразделений, документов, схемы процессов) хранится в промышленной базе данных, например MS SQL Server. Есть отдельный сервис, который используется для администрирования: создания/изменения/архивирования баз данных, создания новых пользователей, назначения прав доступа и т. д.

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

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

Основной сервис среды моделирования – сервис описания[87], где можно:

• создавать различные справочники:

– процессов;

– подразделений;

– должностей;

– документов;

– терминов;

– прочее;

• формировать схемы:

– процессов;

– организационных структур;

– прочее[88];

• описывать объекты модели:

– заполнять текстовые поля (например, указывать название процесса, его начало, завершение, требования к срокам);

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

– выбирать нужные типы (например, указывать тип подразделения: «департамент» или «отдел»);

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

– прочее;

• формировать отчеты:

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

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

• осуществлять анализ и изменение объектной модели:

– создавать/корректировать/удалять процессы, подразделения, документы;

– переназначать исполнителей процессов;

– выявлять процессы без назначенных исполнителей;

– выявлять документы, которые никто не использует;

– прочее.

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

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

Для управления командной работой служит сервис администрирования, в рамках которого:

• выполняются настройки интерфейса системы;

• выполняются настройки ряда справочников;

• создаются/редактируются группы пользователей системы;

• определяются права для групп пользователей и отдельных пользователей;

• выполняются настройки, необходимые для отслеживания изменений в системе;

• прочее.

Сервис формирования отчетов служит для разработки шаблонов различных отчетов (генератор отчетов). При помощи определенного функционала (в системах это может быть реализовано по-разному) квалифицированный пользователь проектирует запрос к базе данных и определяет формат вывода информации в документ MS Word или MS Excel. При построении отчета его тестируют на реальной или специально подготовленной для этого объектной модели. Готовые отчеты доступны конечным пользователям системы. Из системы можно выгружать готовые к согласованию и утверждению нормативно-методические документы (регламенты, положения, инструкции) и другие нужные в практической работе документы.

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

Очень полезен сервис выгрузки моделей в НТМL-формат. Он используется для размещения моделей процессов на интранет– или интернет-сервере организации. Все сотрудники (имеющие соответствующие права) могут оперативно просматривать данные на этом сервере, то есть вся регламентирующая информация по процессам становится доступной рядовому персоналу.

Анализ процессов выполняется на сервисе анализа. Как правило, он дает возможность проводить имитационное моделирование процессов, анализировать затраты и т. д.

Современная среда моделирования бизнес-процессов – это сложный пакет программных продуктов, для успешного внедрения которого организации нужны сотрудники с нужной компетенцией и опытом.

4.5. Структурные модели процессов организации.

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

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

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

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

Для формирования структурных моделей используются соответствующие нотации: IDEF0, ARIS Value Added Chain, Value Stream Map (информационные потоки) компании Toyota, модель цепочек создания ценности и др. Информация о них содержится во многих публикациях, поэтому в своей книге я не стану касаться этого вопроса.

Структурные модели процессов, как правило, применяются для:

• описания, анализа бизнес-модели организации и определения возможных направлений ее реорганизации;

• разработки системы бизнес-процессов организации по принципу «сверху вниз»;

• системного описания процессов, которые необходимо автоматизировать (например, в ЕRР-системе);

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

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

_{Рис. 4.5.1. Пример структурной модели торговой компании}[89].

На рис. 4.5.1 видно, что в модели выделено семь групп процессов. Цель ее построения – демонстрация возможного варианта определения и группировки процессов торговой компании. Такая модель может быть представлена руководителям верхнего уровня для согласования. В дальнейшем модель используется при построении системы процессов организации.

На рис. 4.5.2 та же модель, что и на рис. 4.5.1, только выполненная в стандарте IDEF0.

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

_{Рис. 4.5.2. Пример структурной модели процессов торговой компании[90]. Стандарт IDEF0.}

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

Вопрос пользы структурных моделей для решения задач бизнес-моделирования спорный. С моей точки зрения, построение сложной, многоуровневой системы процессов организации в одной модели IDEF0 (или в другой нотации) излишне. Если соблюдать все формальные правила, то в такой модели может получиться семь-восемь уровней декомпозиции. Реальную же ценность для последующего описания и регламентации имеют один-два нижних уровня, где выполняются конкретные операции и осуществляется реальный документооборот. Именно на этих уровнях процессы можно описать в формате Work Flow и при помощи этих описаний сформировать регламенты работы сотрудников («регламент процесса», «инструкция по выполнению процесса» и т. п.). Вопрос в том, как разработать адекватный реальному бизнесу иерархический справочник процессов[91]. Если можно обойтись без сложной (понятной только бизнес-аналитику) структурной модели процессов, то и не нужно ее создавать.

Примечание. В крупной, давно работающей компании построение сложной структурной модели может не принести ожидаемого результата. Дело в том, что топ-менеджмент вряд ли решится перекраивать весь бизнес по модели в IDЕF0. А с точки зрения регламентации на операционном уровне все верхние уровни (3–5-й) в модели IDEF0 бесполезны. Другое дело, если нужно спроектировать новый бизнес. Эта работа выполняется по принципу «сверху вниз», так как действующих процессов и самой компании пока нет. Анализ структуры и связей процессов на верхнем и среднем уровнях полезен для принятия решений о структуре будущей организации и закреплении групп процессов за подразделениями.

Итак, структурная модель процессов нужна:

• бизнес-аналитикам для понимания деятельности организации и создания адекватной системы процессов (в первую очередь для корректного перехода к процессам уровня Work Flow – регламентируемым или автоматически исполняемым в ВРМS процессам);

• руководителям организации для:

– уточнения зон ответственности, целей и задач их деятельности;

– анализа и совершенствования архитектуры бизнеса;

• руководителям и бизнес-аналитикам при проектировании нового бизнеса.

Замечу, что среди руководителей компаний желающие работать со структурной графической моделью процессов верхнего уровня встречаются редко. Поэтому многоуровневая структурная модель (например, в IDЕF0) – удел узкого круга бизнес-аналитиков. В лучшем случае руководители используют диаграмму первого уровня, которую размещают на стенде с нормативно-методической документацией.

4.6. Модели процессов на операционном уровне.

В этом параграфе мы рассмотрим модели процессов на операционном уровне. Они отображают последовательность выполнения операций процесса (подпроцессов) во времени. Их обычно называют «модели Work Flow»[92].

Сейчас существует множество нотаций типа Work Flow, при помощи которых можно описывать процессы операционного уровня. Рассмотрим основу формирования моделей и некоторые важные аспекты их применения.

4.6.1. Нотации типа Work Flow.

На рис. 4.6.1 показаны основные элементы, которые используются практически во всех современных нотациях Work Flow. Можно выделить пять основных:

1. События.

2. Операторы логики (по-другому их называют: блоки решения, ветвления/развилки, шлюзы/гейтвеи[93]).

3. Операции процесса.

4. Стрелки типа «Связь предшествования».

5. Стрелки типа «Поток объектов».

События служат для определения границ процесса. Они могут указывать на его начало и завершение. Кроме того, возможны промежуточные события, возникающие по ходу выполнения процесса. Примеры именования событий: «Поступила заявка клиента на отгрузку продукции», «Утвержден план проекта», «Подписана накладная», «8.00 понедельника» и т. п. Как видно на рис. 4.6.1, в различных нотациях события показаны при помощи разных условных обозначений. Особняком стоит BPMN 2.0[94] (см., например, [9]). В рамках этой нотации внутри графического элемента «Событие» могут присутствовать различные маркеры: таймер, сообщение, триггер и т. д.

_{Рис. 4.6.1. Основные элементы нотации Work Flow.}

Операторы логики служат для описания ситуаций, связанных с ветвлением процесса. Оно может произойти по разным причинам (например, принятие решения, проверка условия). Операторы логики бывают трех типов[95]: логическое «И», логическое исключающее «ИЛИ», логическое неисключающее «ИЛИ».

На рис. 4.6.2 приведен пример использования операторов логики при построении схемы типа Work Flow (графические обозначения операторов логики на схеме условные).

_{Рис. 4.6.2. Использование операторов логики.}

При использовании логического оператора «И» (ситуация 1) после операции 1 выполняются операция 2 и операция 3.

При использовании логического оператора исключающее «ИЛИ» (ситуация 2) после операции 1 выполняется одна из двух операций – 2 или 3.

При использовании логического оператора неисключающее «ИЛИ» (ситуация 3) после операции 1 выполняется операция 2, либо операция 3, либо операции 2 и 3.

Условные обозначения для операций процесса (задач, действий, функций) выглядят практически одинаково во всех нотациях типа Work Flow.

Важный элемент схемы Work Flow – связи. Они представлены при помощи стрелок определенного вида. Первый тип – стрелки «Связь предшествования». Без них построение модели типа Work Flow невозможно. Стрелка «Связь предшествования», связывающая две операции, показывает, что вторая операция начинает выполняться только после завершения первой. Можно сказать, что стрелки «Связь предшествования» демонстрируют развертку процесса во времени.

Стрелки «Поток объектов» используются на схемах типа Work Flow для описания потоков документов и информации[96].

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

В следующих разделах рассмотрим наиболее известные нотации моделирования.

4.6.2. Простая блок-схема.

Нотация «Простая блок-схема» реализована в МS Visio. На рис. 4.6.3 показаны элементы этой нотации и фрагмент соответствующей схемы. В полном объеме нотация применяется редко.

_{Рис. 4.6.3. Нотация «Простая блок-схема» в MS Visio.}

Вообще в МS Visio представлено несколько сложных нотаций типа «Блок-схема». Видимо, поэтому они не нашли широкого применения, хотя и были включены в набор нотаций, поставляемых с системой.

Нотация «Простая блок-схема» в самом доступном и часто используемом варианте содержит всего несколько элементов:

• процесс;

• решение;

• ручная операция (реже);

• документ;

• данные;

• стрелка (для отображения связей между объектами схемы).

При помощи этой нотации можно показать потоки данных, если необходимо описывать процессы для автоматизации.

Рассмотрим некоторые особенности применения простой блок-схемы, в частности применение стрелок. Сотрудники компании, формирующие схемы при помощи простой блок-схемы, придерживаются двух подходов:

• не именуют стрелки вообще;

• стараются присваивать стрелкам, связывающим элементы схемы, простые и понятные названия.

На рис. 4.6.4 показан пример применения простой блок-схемы в одной из компаний. Применены все пять типов элементов. Тем не менее схема выглядит вполне читаемой и понятной пользователю – сотруднику компании.

_{Рис. 4.6.4. Пример схемы в нотации «Простая блок-схема».}

Нотация «Простая блок-схема» часто подвергается в организациях различным вариациям:

• изменяется смысл элемента «Решение» (его используют в качестве операции процесса);

• по-разному используют стрелки связей (именуют или не именуют и т. п.);

• по-разному используют стрелки связей в сочетании с объектом «Документ»;

• прочее.

Интересно, что нотация «Простая блок-схема» в том или ином виде часто используется специалистами по менеджменту качества при описании процессов СМК, так как она самая простая из известных.

Преимущества простой блок-схемы (с сокращенным до минимума количеством элементов):

• простота формирования графических схем процессов;

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

• минимальная потребность в обучении сотрудников;

• наличие доступных инструментов для описания процессов (MS Visio, MS Word).

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

• внутренний стандарт использования этой нотации;

• внутренний стандарт формирования, хранения и актуализации файлов со схемами процессов.

Масштабное использование в компании нотации «Простая блок-схема» без современного средства моделирования неэффективно.

4.6.3. Нотация ARIS eEPC.

[97].

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

ARIS eEPC – одна из первых нотаций, получившей широкую известность на российском рынке. Она относится к нотациям Work Flow. Особенности нотации – наличие элементов типа «Событие» и операторов логики «И», неисключающее «ИЛИ», исключающее «ИЛИ».

В качестве примера рассмотрим процесс, представленный на рис. 4.6.5, который начинается с события «Поступил заказ клиента». Оно инициирует операцию «Выполнить учет заказа в системе», которую проводит менеджер отдела сбыта. Для работы он использует систему учета заказов. Результат операции отображается событием «Учет заказа выполнен». После этого менеджер по сбыту осуществляет операцию «Выполнить анализ на соответствие номенклатуре». Ее результат – два альтернативных события: «Заказ соответствует номенклатуре» и «Заказ не соответствует номенклатуре». Процесс ветвится. Для отображения ветвления процесса используется символ логического исключающего «ИЛИ».

_{Рис. 4.6.5. Схема процесса в нотации ARIS eEPC.}

^{* ПЭО – планово-экономический отдел.}

Операция «Уведомить клиента о невозможности выполнения заказа» может выполняться в двух случаях: если заказ не соответствует номенклатуре или если производство невозможно. Для отображения на схеме процесса этих вариантов используется символ логического «ИЛИ».

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

Почему возникает такой эффект? Это результат описания множества возникающих при выполнении процесса ветвлений при помощи формальных логических операторов. Делать это приходится по строгим правилам. В результате появляется формально правильная, но громоздкая, плохо воспринимаемая схема. Впрочем, это проблема почти всех нотаций Work Flow. Для специалиста, который занимается моделированием постоянно, выбор ARIS eEPC в качестве инструмента описания вполне адекватен.

Следует отметить, что типичная схема в АRIS eEPC:

• не годится для автоматизации в системе класса BPM (Business Process Management) (нужно применять дополнительный транслятор, переводящий ее в нотацию BPMN, с последующей ручной доработкой);

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

Итак, нотация ARIS eEPC не предназначена для описания автоматически исполняемых процессов и неудобна для восприятия из-за своей сложности. Моделирование в АRIS eEPC не дает значительных преимуществ ни для автоматизации, ни для регламентации. Это классическая, формально правильная, но неудобная для восприятия нотация.

Несмотря на перечисленные проблемы, применение нотации ARIS eEPC и соответствующего средства моделирования, безусловно, позволяет создать в организации качественную, комплексную процессную модель. Многие крупные и средние российские компании используют ARIS eEPC для описания и регламентации бизнес-процессов. Могу предположить, что в этих компаниях постепенно произойдет переход от нотации ARIS eEPC к более сложной, но и более выразительной (с точки зрения задач бизнес-моделирования) нотации BPMN 2.0.

4.6.4. Нотация BPMN.

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

Разработана она компанией Business Process Management Initiative и поддерживается Object Management Group после слияния организаций в 2005 году. Предыдущая версия BPMN – 1.2, последняя версия – 2.0[98].

Нотация BPMN появилась относительно недавно. Она ориентирована на описание так называемых исполняемых процессов, то есть процессов, которые поддерживаются системами автоматизации операционных процессов – BPM.

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

• получение заявок клиентов;

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

• формирование графика доставки;

• обработка ждущих (отложенных) заявок;

• контроль остатков, рассылка информационных писем клиентам;

• изменение статуса товара в базе;

• обработка отказов.

На рис. 4.6.6 показан процесс «Обработка заявки и выставление счета клиенту», описанный в нотации BPMN. Схема рис. 4.6.6 содержит три объекта типа Gateway, восемь – типа Event и четыре операции (действия, задачи). Как видим, процесс совсем несложный, но количество условных обозначений, нужных для его описания, значительно.

_{Рис. 4.6.6. Фрагмент модели процесса в нотации BPMN 2.0.}

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

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

• руководители сами готовы активно осваивать нотацию BPMN;

• предполагается активно использовать схемы процессов в ВРМN для автоматизации операционных процессов.

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

4.6.5. Нотация «Процедура» среды моделирования Business Studio.

Сейчас одним из распространенных инструментов бизнес-моделирования стала среда Business Studio[99]. В этой системе реализованы четыре нотации: IDEF0, «Процесс», «Процедура», eEPC.

Нотация IDEF0 используется для построения моделей верхнего уровня, а «Процедура» и еЕРС – для создания моделей типа Work Flow.

Рассмотрим подробнее нотацию «Процедура» (см. рис. 4.6.7), так как она наиболее проста и удобна для описания бизнес-процессов организации. Основные элементы нотации – это:

• операция («Действие» в терминологии Business Studio);

• событие;

• блок «Решение»;

• стрелка типа «Связь предшествования»;

• стрелка типа «Поток объектов»;

• междиаграммная ссылка (МДС);

• сноска (текстовый комментарий);

• дорожки.

_{Рис. 4.6.7. Схема процесса в нотации «Процедура» среды моделирования Business Studio.}

Ниже привожу рекомендации по использованию нотации «Процедура» в организации.

Размеры используемых шрифтов, визуальный вид объектов, цветовое кодирование могут быть реализованы в типовых настройках Business Studio. Как правило, данные настройки делаются один раз и не должны в последующем изменяться пользователями.

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

Схема процесса располагается на листе формата А4. Какие-либо изменения размера листа, как правило, не допускаются. Это ограничение дает возможность документировать схемы процессов в привычном формате (включать в регламентирующие документы компании). Отмечу, что это важное требование и им не стоит пренебрегать.

Рекомендуемое количество операций на одном листе – от 3 до 12. Если операций более 15, необходимо либо агрегировать их, либо попытаться разбить процесс на несколько подпроцессов.

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

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

Операции процесса должны быть связаны между собой стрелками типа «Связь предшествования». Если после выполнения операции необходимо поставить блок «Решение», то связи операций с этим блоком также отображаются при помощи стрелок «Связь предшествования».

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

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

На рис. 4.6.8 представлены варианты именования операции процесса в формате «глагол + существительное». Также показаны ошибки, часто допускаемые при именовании операций.

_{Рис. 4.6.8. Именование операций процесса.}

Стрелки типа «Связь предшествования» показывают последовательность выполнения операций процесса во времени. Каждая именованная стрелка в Вusinеss Studio – объект базы и хранится в справочнике стрелок. К именованным стрелкам типа «Связь предшествования» можно привязывать объекты из справочника «Объекты деятельности» (например, бумажные или электронные документы). К неименованным стрелкам привязать объекты невозможно. На рис. 4.6.9 показаны правильные и неправильные варианты применения стрелок на схеме процесса. Стрелки должны быть привязаны к операциям. Наличие стрелок, не привязанных к операциям (либо междиаграммным ссылкам), не допускается. Стрелки необходимо именовать. Нельзя использовать короткие, абстрактные названия: «да», «договор», «поступило письмо», «информация». Они должны быть подробные, конкретные и отражать контекст того процесса, в рамках которого создаются.

_{Рис. 4.6.9. Использование стрелок типа «Связь предшествования».}

Стрелки типа «Связь предшествования» желательно именовать, указывая:

• название документа в именительном падеже;

• описание результата выполнения операции в терминах события.

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

• при использовании блока «Решение»;

• при описании межпроцессного взаимодействия при помощи информационного потока с использованием междиаграммных ссылок.

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

На рис. 4.6.10 показаны правильные и неправильные варианты применения стрелок на схеме процесса.

_{Рис. 4.6.10. Использование стрелок типа «Поток объектов».}

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

Стрелки необходимо обязательно именовать, но нельзя использовать короткие, абстрактные названия типа «Договор», «Письмо», «Информация». Они должны быть подробными, конкретными и содержать наименование или отражать суть тех документов/информации, которые используются в рамках моделируемого процесса.

Стрелки типа «Поток объектов» можно именовать, указывая название документа (формулировку информационного потока) в именительном падеже.

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

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

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

На рис. 4.6.11 показаны правильные и неправильные варианты применения на схеме объектов типа «Событие».

_{Рис. 4.6.11. Использование событий.}

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

Блок «Решение» именуется при помощи существительного. Примеры:

• «Проверка принятого решения»;

• «Проверка применимости условий типового предложения»;

• «Сравнение величины запрашиваемой скидки с возможной»;

• «Определение соответствия классификатору…».

На рис. 4.6.12 показаны правильные и неправильные варианты применения на схеме процесса блока «Решение».

_{Рис. 4.6.12. Использование блока «Решение».}

Блок «Решение» необходимо использовать на схеме процесса при возникновении ситуации, требующей применения оператора исключающего логического «ИЛИ» (рис. 4.6.12, ситуация 1). В случае применения блока «Решение» необходимо дополнительно использовать стрелку «Поток объектов» для описания информационного потока между операциями процесса (если он существует). Ситуация 2 некорректна в части именования блока «Решение» и стрелок. Ситуация 3 некорректна, так как требовалось применение блока «Решение».

Для упрощения графической схемы в Вusinеss Studio[100] блок «Решение» не используется при возникновении ситуации, требующей применения оператора исключающего логического «ИЛИ» при объединении двух веток процесса (ситуация 4), а также оператора «И» (ситуация 5).

Для моделирования межпроцессного взаимодействия в Вusinеss Studio используют междиаграммные ссылки.

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

На рис. 4.6.13 показаны правильные и неправильные варианты применения на схеме процесса междиаграммных ссылок.

_{Рис. 4.6.13. Использование междиаграммных ссылок.}

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

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

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

Схема процесса в нотации «Процедура» при кажущейся простоте весьма информативна и удобна для описания. Можно сформулировать следующие преимущества этой нотации (в случае ее использования в Вusinеss Studio):

• представлен минимально необходимый набор графических элементов для описания процессов типа Work Flow (поток работ);

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

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

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

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

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

• можно выгружать и редактировать схемы в МS Visio (при необходимости).

Среда моделирования Business Studio позволяет быстро создавать процессную модель компании. Информацию о процессах можно выгружать из системы в виде регламентирующих документов в требуемом формате.

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

4.7. Информативность графических схем процессов.

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

• «Простая блок-схема» (с отображением движения документов, с использованием блока «решение»);

• «Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»);

• «Процедура» системы Business Studio (один из возможных вариантов представления);

• ARIS eEPC.

В качестве тестового примера я выбрал простой и понятный процесс. Результаты его описания представлены на рис. 4.7.1–4.7.5.

_{Рис. 4.7.1. Схема процесса в нотации «Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение»).}

_{Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день.}

На рис. 4.7.1 последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов – при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых зависит последующий ход процесса. Такой подход к использованию ромбиков – весьма распространенное явление. Но вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если вдуматься, то ценность (смысл) рисования этих ромбиков не очевидна. Что это за объекты – операции процесса, события? Вроде бы ни то ни другое. Это, скорее, операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе ромбик был бы полноценной операцией сравнения условий. Но на схеме процесса нужно показывать реальные объекты – процессы, выполняемые людьми, документы, информационные системы. Задумайтесь, корректно ли показывать ромбики отдельно от операции процесса на схеме? Вместо этого можно:

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

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

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

Сформулируем плюсы и минусы рассмотренного (рис. 4.7.1) способа использования ромбиков.

Простая блок-схема в МS Visio (с движением документов, с использованием блока «Решение»). Плюс. 1. Наглядное отображение логики выбора тех или иных выходов процесса. 2. Акцентирование внимания исполнителя на точке принятия решения/ветвление процесса в зависимости от условий. 3. Схема процесса перегружена информацией. Минус. 1. Вынос логики принятия решения за пределы операции процесса (некорректно с точки зрения формальной декомпозиции процессов). 2. Неудобства при документировании процесса (приходится дублировать ромбики текстом при формировании текстового описания операции). 3. Ромбики часто используются слишком формально, без реальной необходимости.

На рис. 4.7.2 приведен пример того же процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на рис. 4.7.1. Схема на рис. 4.7.2 выглядит гораздо проще: от графических элементов не рябит в глазах, а с точки зрения информативности она понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению, то, комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании. (Еще раз замечу: не вся информация о процессе должна быть представлена на его графической схеме. При работе с объектной моделью значительная часть сведений хранится в виде атрибутов объектов в базе данных.).

_{Рис. 4.7.2. Схема процесса в нотации «Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение»).}

_{Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день.}

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

Простая блок-схема в МS Visio (без движения документов, без использования блока «Решение»). Плюс. 1. Простота и наглядность для исполнителя. 2. На лист можно поместить больше информации, чем в случае формата, использованного на рис. 4.7.1. Минус. 1. Логика принятия решений скрыта внутри операций процесса. 2. Графическую схему целесообразно сопровождать таблицей с текстовым описанием операций процесса.

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

На рис. 4.7.3 показана схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки «Решение»[101] использованы нестандартным образом – не как графический элемент для отображения ветвления (оператор логики, развилка, гейтвей), а как полноценная операция процесса, связанная с принятием решений. Использование ромбика (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты ромбика можно внести любую текстовую информацию: описание, начало, завершение, требование к срокам и т. п.

_{Рис. 4.7.3. Процедура системы Business Studio (вариант с нестандартным использованием блоков «Решение»).}

_{Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день.}

Вторая особенность схемы процесса на рис. 4.7.3 – применение стрелок. Для отображения последовательности операций полезно использовать стрелку с одним наконечником – стрелку «Связь предшествования». Для отображения движения документов применяют стрелку с двумя наконечниками. Но именно в Вusinеss Studio можно пользоваться только одним типом стрелок – стрелками «Связь предшествования», а к именованным стрелкам привязывать необходимое количество документов, которые определены в справочнике объектов деятельности. Такой подход позволяет сократить количество графических элементов на схеме процесса и при этом вывести в регламент процесса необходимую информацию о входящих и исходящих документах.

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

Тот факт, что название стрелки в Вusinеss Studio не зависит от документов, которые к ней привязаны, позволяет именовать стрелки понятным и удобным для сотрудников образом. Например, к стрелке предшествования «Подготовлен комплект отчетов» можно привязать комплект конкретных документов. Название стрелки в этом случае указывает исполнителю на событие, завершившее предыдущую операцию, – «Сформировать отчет по инкассации за день». (Замечу, что в методологии компании СТУ[102] стрелка после операции процесса – это сущность, а не событие. После блока «Решение» можно показывать его возможные результаты.).

Плюсы и минусы графического представления процесса на рис. 4.7.3 показаны ниже.

Процедура системы Business Studio (вариант с нестандартным использованием блоков «Решение»). Плюс. 1. Простота представления. 2. Акцентирование внимания исполнителя на операции, связанной с принятием решения/ветвлением процесса. 3. На листе формата А4 может располагаться большой объем информации (возможны разночтения). Минус. 1. Блок «Решение» не декомпозируется. 2. Неоднозначность в именовании стрелок.

Обратите внимание, что в Вusinеss Studio нотация «Процедура» может использоваться по-разному.

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

_{Рис. 4.7.4. Схема процесса в нотации ARIS eEPC (сформирована в Business Studio).}

_{OR – неисключающее логическое «ИЛИ»; XOR – исключающее логическое «ИЛИ».}

Замечу, что схема процесса в нотации ARIS eEPC занимает намного больше места, чем схемы на предыдущих рисунках. Трудоемкость ее формирования также гораздо выше.

Схема процесса в нотации ARIS eEPC (построена в Вusinеss Studio). Плюс. 1. При формировании схемы выдерживается строгая, формальная логика процесса. 2. Четко определены все события, возникающие по ходу процесса. Минус. 1. Сложность восприятия. 2. Трудоемкость формирования схемы. 3. У сотрудников должны быть специальные навыки и опыт интерпретации подобных схем. 4. Информационная избыточность. 5. Занимает слишком много места, что неудобно для документирования.

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

_{Рис. 4.7.5. Схема процесса в нотации BPMN 2.0.}

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

При описании процессов на операционном уровне нужно стремиться к простоте и понятности схем для сотрудников. Использование сложных нотаций приводит к:

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

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

• значительному увеличению трудозатрат бизнес-аналитиков на формирование схем;

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

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

4.8. Формирование регламентирующих документов на основе описания процессов.

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

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

На рис. 4.8.1 показана структура процессов управления транспортным отделом (ТО) крупной торговой компании, разработанная в рамках проекта, в котором я в свое время принимал участие.

_{Рис. 4.8.1. Структура процессов управления транспортным отделом.}

Представлен процесс управления транспортным отделом (ТО) торговой компании «Оптима» (г. Ижевск). Описание процессов выполнено в среде моделирования Business Studio. На рисунке слева видно дерево процессов, в котором процессы управления структурированы по соответствующим контурам.

Для описания объекта модели «Управление ТО» и контуров управления использована нотация «Процесс». Это наиболее простая нотация в Вusinеss Studio, но в рамках предложенной задачи ее использование вполне адекватно.

Для описания процессов внутри контуров управления использована нотация «Процедура». На рис. 4.8.1 показана кросс-функциональная схема процесса «Корректировка потребности в автотранспорте на месяц/квартал». В рамках данной модели все процессы управления описаны в виде подобных схем.

Для каждого процесса управления и для каждой операции процесса были заполнены текстовые атрибуты:

• содержание деятельности;

• начало процесса;

• результат процесса.

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

Для выгрузки описания процессов управления из Вusinеss Studio был разработан специальный отчет, который включает информацию о процессах на трех уровнях:

1. описание контура управления;

2. описание процесса в контуре управления;

3. описание операций процесса (в табличной форме) и схему процесса.

На рис. 4.8.2 показана работа мастера отчетов среды моделирования Business Studio. При помощи системы так называемых привязок была сформирована необходимая структура отчета. Затем создали и отредактировали шаблон отчета – регламент процесса управления на трех уровнях. После этого готовый отчет был сохранен в папке пользовательских отчетов среды моделирования Business Studio и запущен на выполнение для объекта «Управление ТО» (рис. 4.8.3).

_{Рис. 4.8.2. Мастер отчетов Business Studio. Разработка регламента управления на трех уровнях.}

_{Рис. 4.8.3. Запуск отчета для объекта «Управление ТО».}

Отчет, запущенный для объекта модели «Управление ТО», сгенерировал документ в МS Word и вывел всю информацию о контурах и процессах управления в нужном формате. Автоматически было получено содержание документа (рис. 4.8.4).

_{Рис. 4.8.4. Содержание регламента процесса управления, полученное автоматически в результате запуска отчета в среде моделирования Business Studio.}

_{Рис. 4.8.5. Вывод информации о процессе управления в табличной и графической форме.}

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

• номер операции;

• наименование операции;

• исполнитель;

• инициирующие события;

• входящие документы;

• описание операции;

• завершающие события;

• исходящие документы.

Графическая схема процесса представлена в кросс-функциональном виде. Объем регламента процесса управления составил для процесса «Управления ТО» около 70 страниц в МS Word, что совсем немного для такого значительного количества процессов.

Отмечу, что среда моделирования Business Studio позволяет формировать и выгружать практически любые отчеты, нужные для регламентации деятельности организации, в том числе:

• регламенты выполнения процессов;

• положения о подразделениях;

• должностные инструкции (на должности и роли).

4.9. Особенности создания корректных схем процессов.

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

4.9.1. Корректное определение границ процесса.

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

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

_{Рис. 4.9.1. Выход за границы процессов.}

4.9.2. Привязка к системе процессов.

В предыдущем случае мы говорили о том, что процесс «ушел не туда». Еще одна из причин такой ситуации – отсутствие системного ви́дения бизнес-процессов организации. Если иерархического справочника процессов нет, то при попытке описать какой-то процесс, скорее всего, возникнет ситуация захвата областей из других процессов и т. п. Затем последуют малопродуктивные споры, как провести границы. Поскольку переделка схем требует времени, появляется искушение согласовать кривые границы процессов и т. д. (рис. 4.9.2).

_{Рис. 4.9.2. Конфликты на границах процессов.}

4.9.3. Декомпозиция – слишком длинные процессы.

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

Если схема процесса все-таки получилась слишком длинной (более 12–15 операций), следует внимательно ее проанализировать.

Возможно, что:

• на схеме представлено несколько процессов, а не один;

• операции процесса неоднородны (по длительности выполнения, требуемым ресурсам и т. п.);

• в процессе появилась «грыжа» (см. ниже);

• прочее.

В любом случае схему процесса стоит переделать. Исключения составляют ситуации, когда схемы специально рисуют на бумаге формата А3, чтобы детально отразить все шаги и взаимодействия. Но увлекаться увеличением формата листов для схем процессов не стоит. А3 – это максимально допустимый размер. Рисовать и печатать схемы процессов на А2 или А1 категорически не рекомендуется (рис. 4.9.3).

_{Рис. 4.9.3. Чрезмерно длинные процессы.}

4.9.4. Процесс в процессе, или «Процессная грыжа».

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

_{Рис. 4.9.4. «Процессная грыжа».}

Можно предложить следующие решения проблемы:

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

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

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

4.9.5. Примитивизация – рисование процесса по «хвостам».

Одна из распространенных ошибок неопытного бизнес-аналитика – попытка описать бизнес-процесс, последовательно характеризуя операции по работе с документом (рис. 4.9.5). Если цель работы – создать маршрут движения документа, то это нормально. Если же надо описать именно бизнес-процесс, то такой подход приводит к ошибкам. Ведь кроме операций по работе с документом в процессе существует еще множество важных действий: получение информации, ее анализ, различные согласования, принятие решений. Бизнес-аналитик должен видеть картину целиком, а не только маршрут движения одного документа.

_{Рис. 4.9.5. Схема документооборота вместо схемы процесса.}

4.9.6. Однородность процесса.

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

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

_{Рис. 4.9.6. Различный масштаб процессов.}

4.9.7. Связи между процессами, оборванные входы/выходы.

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

На схеме процесса не допускаются оборванные входы и выходы (рис. 4.9.7). Всегда должны стоять ссылки на соответствующие процессы поставщиков и потребителей информации/документов.

_{Рис. 4.9.7. Оборванные входы/выходы процессов.}

4.9.8. Нарушение нотации моделирования.

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

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

_{Рис. 4.9.8. Чрезмерно сложные схемы процессов.}

4.9.9. Проверка на здравый смысл.

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

Целесообразно обратить внимание на:

• ненужное повторение операций;

• перегрузку исполнителей;

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

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

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

• неоправданное усложнение (лишние, устаревшие операции);

• узкие места различного характера;

• недостаточное обеспечение ресурсами;

• прочее.

_{Рис. 4.9.9. Проверка на здравый смысл.}

4.10. Рекомендации по внедрению среды моделирования процессов.

Внедрение среды моделирования процессов в масштабах организации – важный и сложный проект. Для его успешного выполнения нужно разработать план, адекватный задаче. Предлагаю один из возможных вариантов такого плана[103].

Для крупной компании внедрение среды моделирования – серьезный проект, который может состоять из трех этапов[104]:

1. Выбор и тестирование среды моделирования.

2. Опытная эксплуатация среды моделирования.

3. Внедрение среды моделирования в масштабах компании.

Этап 1. Выбор и тестирование среды моделирования:

• определение потребностей внутренних пользователей;

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

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

• установка пробной версии среды моделирования (два-три рабочих места);

• создание пилотной модели организации:

– описание двух-трех процессов на двух уровнях;

– описание фрагмента организационной структуры;

– описание некоторых документов, терминов, ТМЦ;

– формирование пилотных отчетов (регламентов выполнения бизнес-процессов);

• тестирование среды моделирования на основе пилотной модели:

– тестирование функциональных возможностей системы;

– тестирование выгрузки отчетов (регламентирующих документов);

– тестирование управления изменениями;

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

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

• принятие решения и закупка среды моделирования;

• установка системы (три-пять конкурентных лицензий);

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

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

Этап 2. Опытная эксплуатация среды моделирования:

• администрирование системы:

– создание групп пользователей и определение прав доступа;

– настройка функционала контроля внесения изменений в систему;

• анализ и внесение необходимых изменений в метамодель:

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

– анализ возможностей метамодели с точки зрения хранения информации, необходимой для выгрузки отчетов;

– определение и внесение необходимых дополнений в метамодель (структуру данных);

– определение требований по использованию метамодели при моделировании организации;

• ввод в систему необходимых справочников:

– иерархический справочник процессов организации (возможно, путем импорта системы процессов организации из файла MS Excel);

– иерархический справочник подразделений и должностей;

– справочник бумажных и электронных документов (уровня компании);

– справочник терминов;

– прочее.

• разработка и тестирование необходимых шаблонов регламентирующих документов и других отчетов;

• разработка решений по интеграции с другими системами («экспорт – импорт»);

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

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

• анализ эффективности функционирования среды моделирования; внесение необходимых изменений в регламенты работы с системой.

Этап 3. Внедрение среды моделирования в масштабах компании:

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

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

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

• разработка плана описания процессов организации;

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

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

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

1. Общие положения.

1.1. Назначение и область действия.

1.2. Используемые сокращения.

1.3. Термины и определения.

1.4. Нормативные ссылки.

2. Ведение справочников в Вusinеss Studio.

2.1. Справочник «Процессы».

2.2. Справочник «Субъекты».

2.3. Справочник «Объекты деятельности».

2.4. Справочник «Управление».

3. Описание процессов в Вusinеss Studio.

3.1. Элементы нотации «Процедура» Business Studio.

3.2. Описание операций процесса.

3.3. Использование стрелок типа «Связь предшествования».

3.4. Использование стрелок типа «Поток документов».

3.5. Использование событий.

3.6. Использование блока «Решение».

3.7. Использование междиаграммных ссылок.

3.8. Использование сносок.

4. Схемы организационной структуры в Вusinеss Studio.

4.1. Используемые графические элементы.

5. Заполнение атрибутов объектов модели.

5.1. Заполнение атрибутов процесса.

5.2. Заполнение атрибутов операции процесса.

5.3. Заполнение атрибутов стрелок.

5.4. Заполнение атрибутов субъекта деятельности.

5.5. Заполнение атрибутов объекта деятельности.

5.6. Заполнение атрибутов целей и показателей.

6. Приложения.

6.1. Пример схемы процесса в нотации «Процедура» Business Studio.

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

1. Общие положения.

1.1. Назначение.

1.2. Термины, определения и сокращения.

2. Общее описание процесса управления изменениями.

3. Типы изменений и распределение ролей и ответственности за управление изменениями.

4. Изменения справочников.

4.1. Организационная структура.

4.2. Процессы.

4.3. Объекты деятельности (документы, ТМЦ, программные продукты).

4.4. Цели и показатели.

4.5. Прочее.

5. Изменение схем процессов.

6. Изменение шаблонов отчетов.

7. Изменение метамодели.

8. Архивирование и восстановление объектной модели.

9. Изменение прав доступа.

10. Изменение версии системы (переход на новые версии).

11. Изменение решений по интеграции с другими системами.

В заключение приведу пример графика проекта по созданию репозитория бизнес-процессов организации на платформе среды моделирования Business Studio (рис. 4.10.1).

_{Рис. 4.10.1. График Ганта создания репозитория бизнес-процессов на платформе среды моделирования Business Studio.}

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

Для эффективного использования системы нужно разработать архитектуру (систему) бизнес-процессов компании. Удобно это делать в МS Excel, но можно и сразу в системе. Далее полученная архитектура процессов переносится в Вusinеss Studio – создается иерархический справочник процессов. Этот справочник – основа для накопления знаний о процессах в рамках электронного репозитория.

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

Чтобы выгрузить из репозитория информацию о процессах в необходимой форме (регламенты, инструкции, положения и т. п.), нужно определить требования к этим документам. При проектировании шаблонов отчетов увязываются между собой требования к документам и возможности системы. Например, если мы хотим видеть в документе какой-то атрибут бизнес-процесса, надо понимать, какую информацию и как следует заносить в репозиторий. Создание шаблонов для выгрузки сложных регламентирующих документов может потребовать изменений объектной модели Business Studio. Это легко делается при помощи специального инструмента Meta Edit, входящего в комплект поставки системы (в версии Enterprise).

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

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

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

4.11. Список литературы.

1. Репин В. В. Бизнес-процессы компании: построение, анализ, регламентация. – М.: Стандарты и качество, 2007.

2. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: Стандарты и качество, 2004.

3. Руководство пользователя Business Studio (2012).

4. Руководство технического специалиста Business Studio (2012).

5. Создание пользовательских отчетов Business Studio. Методика (2012).

6. Маклаков С. В. Моделирование бизнес-процессов с АIIFusiоn Process Modeler. – М.: Диалог-МИФИ, 2008.

7. Черемных С. В., Семенов И. О., Ручкин В. С. Структурный анализ систем: IDEF-технологии. – М.: Финансы и статистика, 2001.

8. Моделирование бизнеса. Методология ARIS. Практическое руководство / М. Каменнова [и др]. – М.: Серебряные нити, 2001.

9. Silver B. BPMN Method and Style: A levels-based methodology for BPM process modeling and improvement using BPMN 2.0. – Cody-Cassidy, 2009.