Текст бизнес-книги "Бизнес-процессы"

Автор книги: Томас Карле

Раздел: Зарубежная деловая литература, Бизнес-книги

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

1.2. Языки и методы моделирования

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

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

Впрочем, а как это выглядит на практике? В порядке вещей расплывчатости, противоречия, недопонимания и пробелы в коммуникации. Каждая группа по интересам в бизнес-сообществе думает лишь о своем специфическом ви́дении бизнес-процесса: руководство сосредоточено на показателях эффективности, бизнес-специалисты помнят только о собственных бизнес-приложениях и процедурах, ИТ-специалисты мыслят в структурах программного и аппаратного обеспечения. Понятно, что проблемы взаимопонимания заранее запрограммированы.

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

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

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

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

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

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

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

1.3. Инструменты для бизнес-сообществ

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

История проектирования бизнес-процессов на основе моделей тем временем возвращает нас назад более чем на 20 лет. После первых нерешительных начинаний в области средств автоматизированной разработки программного обеспечения (Computer-aided software engineering – CASE) моделирование бизнес-процессов пережило первый расцвет в контексте внедрения стандартных бизнес-приложений (SAP, приложения Oracle, PeopleSoft, Baan и т. д.). Помимо таких высокопрофессиональных инструментов, как ADONIS, ARIS, Bonaparte, Casewise и INCOME, на рынке появлялось все больше и больше низкотехнологичных средств, получивших развитие от простых графических программ, например Visio и iGrafx. Между тем сейчас мы наблюдаем второй расцвет, движущими силами которого, несомненно, служат темы управления бизнес-процессами (Business Process Management – BPM), разработка, управляемая моделями (Model Driven Development – MDD) и сервис-ориентированная архитектура (Service Oriented Architecture – SOA). Актуальные обзоры рынка показывают, что сегодня практически каждый поставщик прикладного и межплатформенного программного обеспечения может предложить по крайней мере один инструмент моделирования процессов.

Однако при ближайшем рассмотрении таких инструментов быстро выясняется, что они пригодны для использования в бизнес-сообществах только в ограниченном масштабе. Они требуют высокого уровня подготовки и навязывают пользователям образ действий, обусловленый не их нуждами, а особенностями программного средства. В большинстве случаев уровень сложности слишком высок (пример: многочисленность типов моделей в ARIS) либо ограниченные возможности абстрагирования уж слишком навязывают пользователю уровень реализации (пример: моделирование с BPMN), препятствуя важным творческим процессам моделирования. Но в «оправдание» подобных инструментов стоит отметить, что они возникли главным образом в то время, когда надобность участия целиком бизнес-сообществ в разработке бизнес-процессов еще не была признана и технические возможности для обеспечения продуктивной совместной работы (ключевое слово: Web 2.0) также еще не были в нашем распоряжении.

В результате многолетних исследований в Институте прикладной информатики и методов формализованного описания (AIFB) Технологического института Карлсруэ (KIT) и в Исследовательском центре информатики Карлсруэ (FZI) в сотрудничестве с отраслевым партнером PROMATIS Software GmbH появилось совершенно новое поколение средств для поддержки всего жизненного цикла моделирования бизнес-процессов под названием Horus[2]2
  Horus (Гор) – «Тот, кто далеко» – это один из самых важных богов в египетской мифологии. Как сокол, он поднимается в воздух и простирает свои крылья как Небеса над Землей; Солнце и Луна глаза его.


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

Horus обеспечивает платформу для моделирования, анализа и имитации с помощью сетей Петри. Она впечатляет простотой использования и запускается на всех распространенных операционных системах и мобильных устройствах. В качестве специального варианта сетей поддерживаются XML-сети. Платформа есть в бесплатном доступе и свободна для всех бизнес-сообществ, а так же для преподавания и исследований (Horus Freeware). Кроме того, в Horus software GmbH можно получить корпоративную версию (Horus Enterprise), для которого может также быть заключен контракт на поддержку.

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

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

1.4. Цели и структура данной книги

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

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

Глава 2 книги максимально погружает читателя к реальным условиям бизнес-среды. Здесь в доступной форме и с многочисленными практическими примерами описаны важнейшие основы инжиниринга бизнес-процессов на базе моделей. Основываясь на этом, глава 3 описывает соответствующие концепции и языки моделирования и формирует таким образом связный каркас для моделирования бизнес-процессов. Глава 4 представляет универсальный подход к проектированию бизнес-процессов на основе моделей – метод Horus. Его отправной точкой служит стратегический анализ, «встраивающий» бизнес-процессы в целостный корпоративный контекст. В главе 5 представлены конкретные примеры применения на практике. Книга завершается обзором перспектив инжиниринга бизнес-процессов в главе 6.

1.5. Дополнительная литература

Деятельность в области бизнес-процессов, их анализа и совершенствования восходит среди прочих к работам Hammer и Champy (1993). В 1990-е эта тема, в частности, рассматривалась в связи с управлением потоком работ (Workflow Management), см. Oberweis (1996) в сравнении с Van der Aalst и Van Hee (2004). В настоящее время литература, посвященная моделированию бизнес-процессов, полна заблуждений, поэтому мы отсылаем наших читателей на данный момент только к Becker с соавторами (2011), Scheer (2000a, b), Davis (2001) и Weske (2007). Тем же, кто предпочитает сухому изложению введение в тему в форме романа, рекомендуем Grosskopf с соавторами (2009).

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

● Business Process Management Initiative BPMI (объединилась с OMG – Object Management Group в 2005 году): http://www.omg.org/.

● Business Process Modeling and Simulation Forum: http://www.12manage.com/methods_business_ simulation_modeling.html#userforum/.

● Business Process Trends: www.bptrends.com/.

● Petri Nets World: www.informatik.uni-hamburg.de/TGI/PetriNets/.

Ссылки, приведенные далее, дают примеры систем моделирования бизнес-процессов, более подробная информация по которым доступна в интернете; данный список не претендует на полноту.

● 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. Анализ и моделирование процедур

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

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

Первая задача – отобразить процедуры рассматриваемого процесса продажи в формальной графической модели. Для этого мы применим так называемые XML-сети – особую форму сетей Петри, названных так в честь немецкого математика Карла Адама Петри. В течение многих лет они хорошо зарекомендовали себя для моделирования динамических систем. В моделировании бизнес-процессов сети Петри сохраняют свои позиции благодаря простоте графического представления в сочетании с их выразительностью. Это особенно верно в отношении XML-сетей. При этом достигается высокая точность модели, а операционная семантика позволяет проводить формальный анализ и динамическое имитационное моделирование. Главная характеристика XML-сетей – это описание объектов в XML (сокращение от Extensible Markup Language). Использование языкового каркаса XML (в настоящее время отраслевого стандарта в области электронной обработки документов и бизнес-процессов) позволяет, например, охватывать в деталях структуры объектов или удобно формулировать правила выполнения действий, а также открывает новые любопытные области применения.

Моделирование даже относительно простого процесса продаж – задача нетривиальная: из неструктурированной базовой информации о бизнесе должны быть извлечены действия и потоки объектов, а затем отображены в виде структурированной модели. Предлагаемый Horus метод, описанный в главе 4, – это метод, проверенный на практике. Рис. 2.1 дает обзор процесса продаж, представленного в виде сети Петри. Как часто встречается на практике, процессу дается имя (чаще на английском языке), которое позволяет делать выводы о входах и выходах процесса – здесь контакт преобразуется в заказ клиента (Sales Contact-to-Order). То есть процесс начинается с контакта и включает в себя ряд мероприятий и потоков объектов, чтобы в конечном итоге сформировать заказ от клиента.

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

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