Бизнес-процессы
Шрифт:
ARIS Express от фирмы Software AG: www.ariscommunity.com/aris-express/.
bflow Toolbox (Open Source): www.bflow.org/.
Horus от фирмы Horus software GmbH: www.horus.biz/.
Signavio Process Editor от фирмы Signavio GmbH: https://www.signavio.com/products/process-editor/https://tap.tibco.com/storefront/trialware/tibco-business-studio-community-edition/prod15312.html.
TIBCO Business Studio от фирмы TIBCO Software Inc.: https://www.signavio.com/products/process-editor/https://tap.tibco.com/storefront/trialware/tibco-business-studio-community-edition/prod15312.html.
2
Практическое введение в инжиниринг бизнес-процессов
Проектирование бизнес-процессов отнюдь
Эта глава знакомит с практическим подходом к инжинирингу бизнес-процессов на основе моделей, намеренно абстрагируясь от деталей моделирования и обходясь без введения в общую методологию. Для этого обратитесь к главе 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-сетей (это станет очевидным далее в этой главе).
В процессе управления контактами лиды последовательно квалифицируются дальше, что отражается в основных данных о клиенте. Цель здесь – выявить реальные возможности продажи, которые должны интенсивно обрабатываться и в конце концов вылиться в коммерческое предложение. В идеале оно должно привести к заказу клиента. Разумеется, неудачи в процессе продаж также учитываются: потерянные возможные продажи и потерянные заказы сводятся в хранилище объектов «Потерянный заказ» и там подвергаются анализу. Доступ к основным данным клиента во время этого анализа предоставляется только на чтение, что отображается через простую связь без стрелки. Хранилище объектов «Данные клиента» представлено в сети два раза – копия показана пунктиром. Помимо центрального процесса продажи, в сети также принято во внимание действие по управлению эффективностью продаж, которое оценивает прогноз продаж, заключающий в себе информацию о содержании и статусе актуальных предложений.