Kitabı oku: «Бизнес-процессы», sayfa 3

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 актуальны и здесь.

3
Концепции и языки моделирования

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

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

Основная цель – с одной стороны, представить и разъяснить процедуры на предприятии соответствующими моделями; для этого прежде всего в разделе 3.2 будут обсуждены различные точки зрения на моделирование бизнес-процессов. Цель, кроме того, подвергнуть разработанные таким образом модели тщательному анализу для определения возможностей усовершенствования. Применение сетей Петри (раздел 3.3) также дает возможность провести имитацию процедур, отраженных в процессных моделях, тем самым уже получая оценку эффективности их исполнения на предприятии. Помимо моделирования самих процедур, далее должны быть описаны и смоделированы бизнес-объекты, которые создаются, изменяются или уничтожаются в результате процессов или отдельных действий (см. раздел 3.4). Наконец, структура предприятия в целом также будет учтена при моделировании (раздел 3.5).

3.1. Введение

3.1.1. Моделирование

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

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

Целью моделирования в информационных технологиях может быть:

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

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

● подтверждение желательных и нежелательных свойств системы до ее построения;

● поддержка взаимодействия между различными группами людей, вовлеченными в разработку, такими как разработчики и пользователи, бизнес-аналитики и программисты;

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

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

● описание системы как основы для техобслуживания.

Для моделирования различных аспектов системы существуют различные языки моделирования. Многообразие возможных вариантов простирается от формально-математических, или логических (логика высказываний или логика предикатов), нотаций через графические (как используемые здесь для описания процессов или объектов) и программные (как Java или C#) языки вплоть до разговорных речевых оборотов. В дальнейшем здесь для интересующих нас задач моделирования бизнес-процессов мы будем использовать специальную форму сетей Петри, так называемые XML-сети, так как они имеют точно определенную семантику, одновременно позволяя посредством графического представления осуществлять интуитивно понятное моделирование и точную спецификацию ключевых структур данных.