Практическое введение в инжиниринг бизнес-процессов
Проектирование бизнес-процессов отнюдь не новая дисциплина, она, в принципе, так же стара, как и разделение труда в производстве товаров и услуг. Чисто эмпирический подход с течением времени дополнился инженерной компонентой, поэтому на сегодняшний день мы говорим об инжиниринге бизнес-процессов. Он описывает проектирование, или дизайн, бизнес-процессов, их анализ, улучшение и оптимизацию, а также документирование операционной деятельности и основные условия. На практике для этого слишком часто применяют исключительно неформальные инструменты — например, обычные тексты, таблицы и графики. За такую незамысловатость нередко приходится платить несоответствиями и неполнотой в полученном описании процессов. В результате — опасные и дорогостоящие дефекты качества в практической реализации соответствующих процессов. Справиться с затруднениями здесь помогут формальные графические методы моделирования, которые делают возможным ощутимое улучшение качества проектирования бизнес-процессов и их последующего внедрения.
Эта глава знакомит с практическим подходом к инжинирингу бизнес-процессов на основе моделей, намеренно абстрагируясь от деталей моделирования и обходясь без введения в общую методологию. Для этого обратитесь к главе 3 и в особенности главе 4 этой книги.
2.1. Постановка задачи
Для практического введения в инжиниринг бизнес-процессов рассмотрим типичный сценарий из области продаж: сбыт комплексных продуктов, который, как правило, подразумевает многоэтапный цикл продаж. Работа ведется исключительно с бизнес-клиентами, включая как существующих, так и потенциальных, с которыми до сих пор не были установлены активные деловые отношения. Процесс продажи осуществляется командой, поддерживающей тесные контакты с целевыми клиентами в различных сферах и на различных уровнях принятия решений.
Конкретная цель инжиниринга бизнес-процессов не имеет значения в данной вводной главе. Важно понять, как взаимосвязи реального мира понимаются, анализируются и отображаются в модели бизнес-процессов. Эта модель затем служит для визуализации бизнес-процессов, содействуя таким образом особенно продуктивной и эффективной форме коммуникации, когда дело доходит до определения предметных требований к процессу. Важно понимать, что отображение реальных взаимозависимостей в модели с четко определенным синтаксисом и семантикой есть нечто гораздо большее, чем простой сбор и упорядочивание требований: анализ требований диктуется правилами моделирования и сталкивается с ошибками, упущениями, несоответствиями, а также с избыточностью информации и действий.
2.2. Анализ и моделирование процедур
Первый вопрос, ответить на который стоит в инжиниринге бизнес-процессов, звучит довольно просто: «С чего начать?» «С процедур, конечно!» Насколько очевиден такой ответ (раз бизнес теперь в первую очередь мыслит категориями процедур), настолько, однако, на практике часто начинают с организационной структуры. Почему? Такой старт, совершенно очевидно ведет к бизнес-процессам, завязанным на организационную структуру, а не на потребности бизнеса, которые отражены непосредственно в процедурах. Причины постановки вопросов оргструктуры на первое место во многих случаях следует искать в желании удержать и расширить сферы влияния. Поэтому мы настоятельно рекомендуем на первом этапе сосредоточиться на процедурах и сознательно абстрагироваться в первую очередь от организационной структуры. Только тогда, когда процедуры рассматриваются вне оков организационной структуры, можно ожидать истинного совершенствования процессов вплоть до процессной инновации.
2.2.1. Моделирование бизнес-процедур с помощью сетей Петри
Итак, обратимся к бизнес-процедурам процесса продаж. Бизнес-процедуры по сути своей состоят из последовательности действий и связанного с ними потока объектов. Действия могут выполняться вручную или быть по меньшей мере частично автоматизированными с использованием информационно-коммуникационных технологий. Под объектами понимаются документы, данные, знания и даже короткие сообщения или контрольные сигналы. Реальные товары (продукция, сырье, вспомогательные и производственные материалы и т.д.) также интерпретируются как объекты.
Первая задача — отобразить процедуры рассматриваемого процесса продажи в формальной графической модели. Для этого мы применим так называемые XML-сети — особую форму сетей Петри, названных так в честь немецкого математика Карла Адама Петри. В течение многих лет они хорошо зарекомендовали себя для моделирования динамических систем. В моделировании бизнес-процессов сети Петри сохраняют свои позиции благодаря простоте графического представления в сочетании с их выразительностью. Это особенно верно в отношении XML-сетей. При этом достигается высокая точность модели, а операционная семантика позволяет проводить формальный анализ и динамическое имитационное моделирование. Главная характеристика XML-сетей — это описание объектов в XML (сокращение от Extensible Markup Language). Использование языкового каркаса XML (в настоящее время отраслевого стандарта в области электронной обработки документов и бизнес-процессов) позволяет, например, охватывать в деталях структуры объектов или удобно формулировать правила выполнения действий, а также открывает новые любопытные области применения.
Моделирование даже относительно простого процесса продаж — задача нетривиальная: из неструктурированной базовой информации о бизнесе должны быть извлечены действия и потоки объектов, а затем отображены в виде структурированной модели. Предлагаемый Horus метод, описанный в главе 4, — это метод, проверенный на практике. Рис. 2.1 дает обзор процесса продаж, представленного в виде сети Петри. Как часто встречается на практике, процессу дается имя (чаще на английском языке), которое позволяет делать выводы о входах и выходах процесса — здесь контакт преобразуется в заказ клиента (Sales Contact-to-Order). То есть процесс начинается с контакта и включает в себя ряд мероприятий и потоков объектов, чтобы в конечном итоге сформировать заказ от клиента.
Процесс продаж описывается в сети Петри, начиная с предварительной квалификации контакта и преобразования его, таким образом, в квалифицированный контакт продажи (лид). Одновременно производится запись основных данных о клиенте. Наряду с действиями, представленными в виде прямоугольников, в сети содержатся хранилища объектов (кружки), откуда действия по направлению стрелок извлекают объекты (пример: контакт) либо куда помещают объекты (пример: лид и основные данные клиента). В данной модели пока еще не видно использование XML или XML-сетей (это станет очевидным далее в этой главе).
В процессе управления контактами лиды последовательно квалифицируются дальше, что отражается в основных данных о клиенте. Цель здесь — выявить реальные возможности продажи, которые должны интенсивно обрабатываться и в конце концов вылиться в коммерческое предложение. В идеале оно должно привести к заказу клиента. Разумеется, неудачи в процессе продаж также учитываются: потерянные возможные продажи и потерянные заказы сводятся в хранилище объектов «Потерянный заказ» и там подвергаются анализу. Доступ к основным данным клиента во время этого анализа предоставляется только на чтение, что отображается через простую связь без стрелки. Хранилище объектов «Данные клиента» представлено в сети два раза — копия показана пунктиром. Помимо центрального процесса продажи, в сети также принято во внимание действие по управлению эффективностью продаж, которое оценивает прогноз продаж, заключающий в себе информацию о содержании и статусе актуальных предложений.
2.2.2. Декомпозиция процессной модели
При рассмотрении сети на рис. 2.1 сразу видно, что пришлось намеренно абстрагироваться от многих деталей. Возникает множество вопросов, которые вполне можно рассматривать как преимущество моделирования: как, кем и в какой хронологии осуществляется управление контактами, как из квалифицированного контакта возникает в конечном счете возможность продажи? Также за действием «Управление предложениями», представленным в сети только как простой прямоугольник, скрывается отдельный сложный процесс с собственными действиями, потоками объектов и правилами. На это указывает хотя бы хранилище объектов «Утвержденное предложение» на выходе. На эти и подобные вопросы можно ответить, если сами действия сети еще более детально описать в отдельной модели-декомпозиции.
Как пример на рис. 2.2 представлена декомпозиция действия «Лидогенерация» с рис. 2.1. О наличии декомпозиции этого действия на рис. 2.1 говорит затенение на его значке. На рис. 2.2 хранилища объектов, которые уже существуют в вышестоящей сети, обозначены прямоугольной рамкой (здесь: «Контакт», «Данные клиента» и «Квалифицированный лид»).
Из декомпозиции видно, что для лидогенерации используются различные каналы продаж. Помимо активного участия в маркетинговых мероприятиях, где в непосредственном контакте с клиентами можно добыть их контактные данные, контакты для продажи также могут быть получены по телефону через колл-центр, посредством электронной почты, факса или обычной почты. В модели также видны различные сценарии обработки контактной информации. В то время как в колл-центре контакты непосредственно регистрируются в клиентской базе, контактная информация, полученная по почте, факсу или с мероприятий, вводится в базу вручную и в отдельных случаях даже сканируется. Интересен также анализ входящих факсов и сообщений электронной почты, который, где это уместно, может автоматически инициировать отправку информационных материалов клиенту.
Уже из этого короткого описания процедуры ясно, что графическая модель процесса в форме сети Петри или XML-сети сама по себе недостаточна для определения всех значимых деталей. Помимо соотнесения моделей, в которых описываются статические аспекты процесса (см. разделы 2.3 и 2.4), к графическим элементам необходимо добавить краткие текстовые описания. Важно, чтобы эти описания были сформулированы четко, понятным языком, с прилежным использованием общепринятой специализированной лексики. Предпочтительны короткие и лаконичные предложения; также доказали свою эффективность маркированные списки. Важно, чтобы уже показанное графически еще раз не повторялось в описании, однако дополнительная информация должна быть достоверной, чтобы пополнить и облегчить понимание графической модели. Как гласит эмпирическое правило, текстовые описания не должны превышать половины страницы формата А4. Если этого объема недостаточно, стоит подумать о дальнейшей декомпозиции. Конкретные образцы документов, скриншоты или неформальные наброски, прикрепленные к формальным элементам, исходя из практики, значительно способствуют пониманию модели. Это в целом верно и для подмоделей.
2.3. Бизнес-объекты и потоки объектов
Модель процедур со своими действиями и потоками объектов формирует центральную опорную точку модели бизнес-процессов. И поскольку бизнес справедливо ставит процедуры на первый план, на деле многие проекты по инжинирингу бизнес-процессов также ограничиваются анализом процедур. Наша цель, однако, — рассмотреть все значимые аспекты бизнес-процесса. Только так можно быть уверенным, что процесс проанализирован и охвачен во всей полноте. Поэтому далее мы обращаемся к бизнес-объектам, над которыми производят операции процедуры процесса.
Бизнес-объекты создаются, читаются, модицифицируются и потребляются действиями бизнес-процесса (цикл CRUD: Create, Read, Update, Destroy). При этом они могут быть не только документами (контракты, деловые бумаги и т.п.), объектами базы данных (например, основные данные клиента или данные по операциям), сообщениями (SMS, электронная почта и т.д.), но и материальными товарами, такими как продукты или сырье. В нашем вводном примере бизнес-объекты представлены в виде модели бизнес-объектов. Бизнес-объекты описываются посредством их атрибутов и их связей (отношений) с другими бизнес-объектами. Бизнес-объекты, как правило, сложны и вдобавок путем объединения (агрегации) нескольких объектов и их связей образуют так называемую совокупность, или агрегат. Здесь мы не будем рассматривать агрегаты, более подробная информация об этом есть в главе 3.
2.3.1. Создание объектной модели
Рис. 2.3 дает наглядное представление об объектной модели нашего процесса продаж. Каркас образуют объекты, изображенные в виде прямоугольников с закругленными краями. В верхнем текстовом поле каждого прямоугольника указывается наименование объекта. Объекты соединены друг с другом посредством связей (отношений), каждой из которых дается наименование. В модели-примере клиент размещает заказы. Для каждой связи указывается мощность, которая определяет, с каким минимальным и максимальным количеством объектов прикрепленного типа связан данный объект. К примеру, для связи между «Клиентом» и «Заказом клиента» мощность имеет значение <0..n> со стороны «Клиента», то есть у Клиента может не быть совсем или быть любое количество заказов (от 0 до n). «Гусиная лапка» на другом конце связи отражает эту мощность графически. Поскольку, однако, заказ клиента присваивается только одному клиенту, мощность <1..1> в направлении Клиента обозначена простой линией связи.
Для каждого объекта задаются ключевые атрибуты (например, «Номер клиента» для клиентов) и описательные атрибуты (например, атрибуты «Имя», «Адрес», «Классификация» и «Платежеспособность» для клиентов). Следует в разумных пределах ограничить усилия по построению моделей, как правило, выбирая только незаменимые для понимания объекта атрибуты (или требуемые для формальной спецификации правил исполнения в XML-сети). Поэтому некоторые объекты могут обходиться без атрибутов, как в случае с объектом «Предложение». Простые условия целостности, касающиеся самого объекта, задаются непосредственно в объекте. В приведенном примере для объекта «Заказ клиента» требуется, чтобы сумма заказа не равнялась нулю.
В центре графической объектной модели находится особенно интересный фрагмент: отражен жизненный цикл контакта с клиентом («Лид»), который в идеале открывает возможность продажи (обратите внимание на мощность <0..n>, которая показывает, что существуют лиды, которые (пока) не привели к возможной продаже). Из возможности продажи (мощность <0..1> говорит, что данный объект может существовать и без предшествовавшего лида) может вытекать ноль, одно или несколько предложений (мощность <0..n>) и, следовательно, эквивалентное количество заказов клиента. Такая «модель жизненного цикла» довольно часто встречается на практике. Несомненно, выразительность объектной модели подчеркивают ее связи и мощности. Кроме того, очевидно, что анализ объектной модели позволяет делать выводы о правильности и полноте бизнес-процедур, что особенно ценно для обеспечения качества.
Разумеется, так же изящно могут быть отображены и рекурсивные связи, как видно на примере прогноза продаж: регионы продаж четко упорядочены в виде иерархической структуры, так что прогноз региона включает в себя прогнозы продаж в подчиненных регионах.
Представляет интерес также использование специализаций (также известных как Is-A-связи), как показано на примере объекта «Потерянный заказ» («является»). Мы говорим о потерянных заказах в контексте упущенных возможностей продаж или предложений. Через специализацию происходит наследование свойств (ключей, атрибутов, условий целостности, связей) специальным объектом от вышестоящего объекта, то есть против направления стрелки — от «Предложения» к «Потерянному заказу».
2.3.2. Типизация объектов
После того как в объектной модели определены бизнес-объекты разрабатываемого процесса, рекомендуется установить связи с моделью бизнес-процедур: путем привязки типов объектов к хранилищам объектов можно в простой форме типизировать объекты модели бизнес-процедуры. Объекты объектной модели формально назначаются хранилищам объектов XML-сети. Такая интерпретация дает возможность судить о структуре и свойствах объектов, содержащихся в хранилищах объектов. Кроме того, становится возможным в действиях определить правила исполнения, используя содержимое объектов. Таким образом, можно сравнить друг с другом атрибуты входных объектов или определить, как значение атрибута объекта на выходе вычисляется из атрибутов входных объектов.
Рис. 2.4 сводит выдержку из модели бизнес-процедуры с рис. 2.1 воедино с объектной моделью с рис. 2.3. От хранилищ объектов стрелки указывают на объекты, посредством которых задается тип соответствующего объекта. Таким образом определяются ключевые и описательные атрибуты объектов. Кроме того, условия целостности гарантируют, что, например, в хранилище объектов «Заказ клиента» действительно могут быть сохранены только заказы с контрактным значением, отличным от нуля.
2.4. Процессно-ориентированные организационные структуры
Модель бизнес-процедур в виде XML-сети и объектная модель уже воплощают структуру модели бизнес-процессов. К тому же соотносимость модели обеспечивает идеальную отправную точку для статического анализа качества. На этой основе теперь можно сформировать организационную структуру, строго ориентированную на бизнес-процессы. На практике при проектировании организационных структур всегда преобладают аспекты, которые не могут быть получены из модели бизнес-процесса: стратегия компании, карьерные возможности, навыки и опыт персонала, затраты на оплату труда, вопросы трудового права и тому подобное. На данном этапе от этого следует абстрагироваться.
На рис. 2.5 представлена организационная структура, ориентированная на рассматриваемый процесс продаж. Выделяются три региона продаж: Германия, Европа / Ближний Восток / Африка (EMEA) и остальной мир (RoW). Оперативные функции сосредоточены в бэк-офисе. Центр взаимодействия отвечает за процесс Contact-to-Lead (от первого контакта до потенциального клиента), то есть генерацию контактов, их регистрацию, первичную обработку и предварительную квалификацию. Обработка возможностей продажи, формирование предложений и получение заказов, то есть процесс Lead-to-Order (от потенциального клиента до заказа), входит в обязанности региональных подразделений продаж. Их работа поддерживается входящими в состав бэк-офиса службами послепродажного обслуживания и приема заказов. В то время как центр взаимодействия, службы приема заказов и послепродажного обслуживания административно подчинены бэк-офису, для них также существует еще один канал отчетности перед подразделением продаж по Германии, что видно по пунктирным линиям. Такая структура весьма характерна, когда хочется избежать опасностей слабого взаимодействия между подразделениями, снижающего общую производительность. Отчетность напрямую в организационную единицу, «близкую» к рынку, часто обеспечивает значительно лучшую ориентацию на рынок.
Здесь мы оставим наш вводный пример, который помог дать первое впечатление о возможностях, вытекающих из инжиниринга бизнес-процессов на основе моделей. В следующих главах будут подробно рассмотрены используемые языки моделирования в рамках общей методологической концепции.
2.5. Целостный подход к управлению бизнес-процессами
Как и в нашем примере, управление бизнес-процессами является важной составляющей продолжительного успеха многих процветающих компаний, шагающих в ногу со временем. При этом, как уже говорилось, необходимо полностью описать и задокументировать различные аспекты бизнес-процессов, имеющие значение для компании, и сделать их прозрачными для всех причастных лиц, чтобы надлежащим образом обеспечить их участие. Помимо полной документации, цель управления бизнес-процессами — это усовершенствование, или оптимизация, процессов. Однако это может происходить в различных направлениях. Как показано на рис. 2.6, в принципе есть несколько возможных целей, или несколько непрерывно осуществляемых видов деятельности по управлению бизнес-процессами.
- Дизайн. Управление бизнес-процессами впервые организуется и вводится. Процессы данной компании подлежат проектированию.
- Инжиниринг. Спроектированные процессы внедряются и готовы для исполнения. При этом важно эффективное использование ресурсов, а также надлежащее соединение моделей бизнес-процедур, бизнес-объектов и организационной структуры.
- Мониторинг. Существующие и уже внедренные бизнес-процессы подвергаются постоянному контролю для выявления и устранения узких мест в ходе процесса или распределения ресурсов. Управление бизнес-процессами должно постоянно совершенствоваться, непрерывно либо с заданными временными интервалами, с целью достичь постоянной оптимизации бизнес-процессов функционирующей организации.
- Реинжиниринг. Уже внедренное управление бизнес-процессами в силу изменившихся основных условий частично или полностью перестраивается или оптимизируется.
Дизайн бизнес-процессов означает проектирование и формирование процесса перед его реализацией. На практике это встречается, как правило, только в тех случаях, когда совершенно новые области деятельности нужно интегрировать в существующий процессный ландшафт или поддержать новые технические возможности (например, при переходе от стационарного торгового бизнеса к электронной коммерции).
Инжиниринг бизнес-процессов означает непрерывное совершенствование и оптимизацию процессов. При этом доказавшие свою эффективность процессы сохраняются и интегрируются с усовершенствованными или частично переработанными процессами. Так изменения происходят не слишком резко и осуществляются шаг за шагом. Таким образом, с одной стороны, снижается риск, который преобразования всегда несут с собой, а с другой — повышается их принятие целевой аудиторией. Необходимым условием для такой революционной формы развития бизнес-процессов является их постоянный мониторинг. Только так можно заблаговременно выявить слабые места, отобразить и оценить влияние внедренных изменений.
Все вышеизложенные цели требуют тщательного определения бизнес-процессов, а также их последовательной документации, чего можно добиться через моделирование.
Метод для реинжиниринга бизнес-процессов (РБП), первоначально предложенный Hammer и Champy в 1993 году, подразумевает радикальное изменение существующего процессного ландшафта. Для достижения наилучших результатов все процессы разрабатываются заново. Однако процессы, доказавшие свою эффективность, остаются нетронутыми. Из-за серьезных изменений, которые, как правило, порождает такой радикальный подход, модель не смогла добиться признания «в чистом виде» в действующей практике. С другой стороны, переконструирование целых подразделов компании может и будет осуществляться.
Общепринятым в настоящее время является целостное управление бизнес-процессами, которое, с одной стороны, принимает во внимание уже предложенные здесь к рассмотрению аспекты моделирования бизнес-процедур, бизнес-объектов заодно с организационным моделированием, а с другой — учитывает как взгляд с позиции бизнеса (абстрагирование от процессов), так и уровень сервисов (реализация процессов и их составных частей) (рис. 2.7).
Для моделирования и анализа бизнес-процессов, как уже говорилось, могут быть использованы разные методы, один из которых более подробно описан в главе 4. Здесь мы только упомянем, что моделирование может происходить как «сверху вниз» (метод возрастающей специализации, «Top-down»), так и «снизу вверх» (метод возрастающей абстракции, «Bottom-up»). Какой из методов (или их комбинацию) выбрать — зависит от конкретных обстоятельств. Тем не менее метод «сверху вниз» предпочтителен в большинстве случаев.
2.6. Дополнительная литература
Прозрачное и понятное введение в моделирование можно найти, помимо прочих, в книгах Dutton (1993) и Weske (2007), анализ конкретных ситуаций также у Scheer (2000 a, б). Введение в сети Петри дано у Reisig (2011), в XML — у Vonhoegen (2009).
Объектная модель, рассмотренная здесь, очевидным образом связана с моделью сущность-связь (ER-модель, Entity-Relationship Model, ERM), впервые предложенной Chen (1976): в отличие от нашего вводного примера, где вполне достаточно двузначных мощностей связей, ERM модели используют не только их (см. рис. 2.3).
Прочие ссылки на литературу по отдельным затронутым здесь темам даны в последующих главах, где они будут раскрыты более полно. Ссылки на информацию в интернете из главы 1 актуальны и здесь.
