Шеер. Бизнес-процессы. Основные понятия. Теория. Методы
Подождите немного. Документ загружается.
Одна из особенностей OLAP состоит в том, что она позволяет анализировать информацию
под разными углами зрения. Можно, например, анализировать стоимость по определенным
регионам, временным периодам и бизнес-процессам. OLAP сортирует значения различных
объектов-прототипов (регионов, периодов, процессов и]т.]д.), раскладывая их параллельно осям
многомерных кубов. Приведем пример конкретного запроса OLAP: «Какова стоимость каждого
процесса в таком-то регионе за период с 1-го по 3-й месяц?» Если оценивать эти же данные в
других ракурсах, то запрос может выглядеть следующим образом: «Какова стоимость такого-то
процесса в каждом регионе за прошлый квартал?» Владельцы предприятий могут использовать
управленческую информационную систему (EIS) для объединения полученной информации о
текущих бизнес-процессах. Оценки EIS можно предварительно сконфигурировать в
соответствии с логикой модели процесса, особенно — модели данных. В качестве оценок и
параметров отчетности часто используются комбинации следующих сегментационных
структур:
организационные структуры: жесткая группировка организационных планов по
юридическим лицам, коммерческим, технологическим и функциональным секторам,
подразделениям, стоимостным центрам и]т.]д.;
структуры продукции: сортировка по изделиям, товарным группам, типам продукции
и]т.]д.;
региональные структуры: сортировка по странам, штатам, территориям, регионам и]т.]д.;
типы потребителей и продаж: сортировка по потребительским группам, типам
потребителей, типам продаж, каналам сбыта;
временные структуры: сортировка по периодичности отчетов (ежемесячно,
ежеквартально, ежегодно) и отчетному периоду (месяц, квартал, год);
характеристики и показатели бизнеса: сортировка по доходу, вкладу, прибыли, стоимости
процессов и]т.]д.;
категории данных: сортировка по прогнозам, целевым показателям, фактическим
показателям, отклонениям.
Данные уровня I, особенно результаты эталонного сравнения и имитационных
экспериментов, тоже можно использовать как источники для систем класса EIS. Важнейшими
источниками являются также результаты мониторинга процессов, составления графиков и
регулирования мощностей на уровне II, основанные на информации о выполнении процессов на
уровне III.
Рис. 39. Отчетность по отклонениям в управлении бизнес-процессами
Стратегия интеллектуальных запросов («добыча данных») позволяет владельцам
процессов безошибочно выходить на процессы, имеющие прямое отношение к запрашиваемой
информации. Идея «добычи данных» состоит в умении сформулировать образец запроса во
81
всей совокупности структурированных и неструктурированных данных, получить в ответ
информацию, которая иначе вряд ли попала бы в поле зрения, и выдавать эту информацию
конечному пользователю.
Мы не будем здесь останавливаться на оценках, которые сводятся к простому
документированию плановой процедуры бизнес-процессов.
На рис. 39 показана схема отчетности по отклонениям (исключениям) в управлении
бизнес-процессами. Эта схема позволяет одним взглядом охватить все проблемные участки на
предприятии. Заштрихованные области показывают, какие процессы требуют немедленных
корректировок (темно-серые), а какие — дальнейшего анализа (светло-серые).
Незаштрихованные области представляют процессы, где дальнейший анализ не требуется.
Подробный анализ выделенных процессов может вскрыть дополнительные возможности
оптимизации.
Г.2.4. Непрерывное совершенствование процессов — адаптивный
инжиниринг бизнес-процессов
Инжиниринг бизнес-процессов — это не одноразовое мероприятие, а постоянная задача
для того, кто за них отвечает. В японской парадигме управления «кайзен» (kaizen — в переводе
«медленная, непрекращающаяся оптимизация»), акцент делается именно на необходимости
постоянной адаптации и оптимизации бизнес-процессов.
Помимо идеи непрерывного эволюционного совершенствования бизнес-процессов,
существует более революционная реинжиниринговая концепция Хэммера и Чампи. При
реинжиниринге бизнес-процессов перед предприятием ставится задача начать все как бы с
нуля.
Рис. 40. Реинжиниринг и непрерывное совершенствование
82
Оба подхода имеют свои достоинства. В определенной ситуации, когда у предприятия
появляется шанс радикально переосмыслить структуру своей деятельности, внеся в нее
фундаментальные изменения, можно провести реинжиниринг. Но и после его завершения
процессы остаются в постоянном движении. Возникают новые организационные формы,
появляются новые образцы ведения бизнеса, которые можно взять за прототип, изобретаются
новые технологии, наконец, приобретаются знания и опыт, связанные с недавно внедренными
процессами. Все это влечет за собой необходимость адаптации новых процессов. Для описания
потребностей предприятия в совершенствовании как нельзя лучше подходит такое широко
известное понятие, как «турбулентная среда».
В процессе планирования и управления бизнес-процессами достаточно выражено
выявляются различные причины для проведения реинжиниринга, которые связывают между
собой уровни инжиниринга и управления, как показано на схеме обратной связи АБИ (см. рис.
24). Рис. 40 иллюстрирует колебания между фазами реинжиниринга и непрерывного
совершенствования.
При реализации фундаментальных реинжиниринговых проектов компании нередко
осуществляют внедрение крупномасштабных ИС или миграцию на более совершенные системы
(предпочитая, например, интегрированное стандартное программное решение). Это позволяет
избежать применения к старым процессам новой технологии. Организации, ограниченные в
средствах, также выигрывают от более рационального внедрения программного обеспечения.
Кроме того, эту фазу можно использовать для усиления у сотрудников мотивации к
совершенствованию процесса реинжиниринга. Например, для усовершенствования процесса
могут потребоваться следующие изменения:
модификация функциональной процедуры,
объединение нескольких функций,
модификация потока управления,
модификация организационных обязанностей,
модификация используемых данных,
модификация систем ИТ.
Рис. 41. Различные типы моделей
83
Бизнес-процессы считаются устойчивыми, когда изменения в корпоративной среде не
требуют или почти не требуют модификации бизнес-процесса. Если возникает необходимость в
модификациях, их стоимость зависит от степени сложности адаптации процесса. Очевидно, что
бизнес-процессы должны быть устойчивыми и адаптируемыми, хотя эти показатели с трудом
поддаются количественным оценкам.
На всех этапах реинжиниринга и непрерывной оптимизации бизнес-процессы следует
четко документировать. Это является обязательной предпосылкой для их оценки на стадии
анализа. На рис. 40 функция документирования представлена «хранилищем процессов».
Именно здесь хранятся корпоративные знания организации о процессах и информация о
процессах-прототипах. Здесь же можно собирать модели текущих, унаследованных и даже
будущих процессов, которые послужат фундаментом для организационной перестройки в
будущем.
Подобный путь разработки моделей иллюстрируется на рис. 41. Если хранятся и прошлые
модели, то успех или неудачу мероприятий в процессе реинжиниринга можно оценивать путем
сравнения моделей.
Рис. 42. Метамодель контроля версий модели
Для хранения версий основных моделей необходим контроль версий. Метамодель такого
контроля представлена на рис. 42. Модели и их составляющие элементы связываются с классом
ВРЕМЯ и, таким образом, несут на себе «печать» времени. Соответствующие данные хранятся
в объектах данных ВЕРСИЯ МОДЕЛИ или ВЕРСИЯ ЭЛЕМЕНТА МОДЕЛИ. Версии моделей
состоят из связанных с ними версий элементов модели. Термин «элемент модели» охватывает
широкий круг понятий, таких как функции, данные, организационные единицы, выход и его
взаимосвязи. Из этих элементов можно построить модели реальных процессов.
При помощи отношения *:* с одной версией модели можно связывать несколько версий
одного и того же элемента модели. Это позволяет избежать автоматической генерации новых
версий модели при незначительных изменениях в ее элементах. Модели в масштабе
корпорации состоят из нескольких сотен или даже тысяч элементов, что существенно
осложняет контроль версий. С другой стороны, контроль версий обеспечивает прозрачность
управления бизнес-процессами. Кроме того, контроль версий является неотъемлемой частью
корпоративной памяти организации.
84
Г. З. Управление потоками работ (workflow)
Рассмотренные аспекты инжиниринга и планирования бизнес-процессов ориентированы
на менеджеров, занимающихся вопросами управления бизнесом. Использование технологии
workflow позволяет трансформировать бизнес-процессы в инструменты ИТ.
Рис. 43. От модели бизнес-процесса — к реальной процедуре
Как правило, управлять всем бизнес-процессом при помощи одной прикладной системы
невозможно. Очень часто для этого требуется ряд прикладных систем для организации продаж,
закупок, производства и учета. Даже комплексные стандартные прикладные системы имеют
пробелы, которые необходимо восполнить с помощью специализированных систем или
стандартных приложений от других поставщиков. Ни одна из этих систем сама по себе не
способна определять состояние всего процесса (например, состояние обработки конкретного
заказа на каждом этапе). Поэтому имеет смысл вынести общее управление процессом на
отдельный уровень вместо того, чтобы распределять ответственность между несколькими
системами. Этот уровень называется «workflow» или уровень «потока работ».
Системы класса workflow передают обрабатываемые объекты (документы) с одного
рабочего места на другое. В идеале эта передача осуществляется электронными средствами —
от компьютера, установленного на одном рабочем месте, к компьютеру, где выполняется
следующая операция. Для этого требуется детальное описание процедуры применительно к
конкретному типу процесса и указание на соответствующего исполнителя.
Поток документов, изображенный на рис. 24, включает «папку», содержащую
электронные ссылки на функциональные компоненты, которые нужно активизировать, и
необходимые для обработки данные, которые передаются с одного рабочего места на другое.
85
На рис. 43 показано, как процесс, описанный на уровне инжиниринга, приобретает черты
реального процесса на уровне выполнения. Вместо перечня общих наименований
организационных единиц мы видим теперь имена конкретных сотрудников, вместо общих
обозначений заказов — ссылки на конкретных клиентов. По завершении той или иной
операции система класса workflow забирает исходящий документ из электронного ящика
одного менеджера и пересылает его в электронный ящик для входящих сообщений на
компьютере следующего менеджера. При наличии нескольких менеджеров документ может
рассылаться по нескольким ящикам. Как только один из менеджеров приступает к обработке
документа, из остальных ящиков его копии удаляются. На рис. 44 изображен экран системы
workflow со значками корзин для входящих и исходящих бумаг и буферов обмена
Рис. 44. Экран системы workflow (пример использования буферов обмена)
Системы workflow содержат информацию о состоянии процесса обработки, времени
выполнения и пользователях каждого бизнес-процесса и при необходимости выдают данные
для оценки стоимости и времени, а также предоставляют информацию для мониторинга
процессов. Именно поэтому системы workflow являются фундаментом для управления
процессами на уровне II
Процессы на уровне workflow могут быть представлены графически на экране монитора
каждого пользователя. Это делает более понятной организационную подоплеку бизнес-
процессов. Если говорить о мониторинге процессов (см. правое окно на рис 36), то ключевую
роль в этом контексте играют диаграммы EPC. Сюда входят такие детали, как указание
конкретных сотрудников и выбор пути выполнения процесса из различных альтернативных
вариантов, представленных в общем описании бизнес-процесса. Это позволяет пользователям
видеть, какая роль им отводится в процессе, кто их «предшественники» и «преемники». Они
также видят, что, скажем, в данном примере к ним имеет отношение только левая ветвь бизнес-
процесса, поскольку поток управления в правой ветви удален. А в связи с тем, что конкретный
пользователь следующей функции еще не назван, то указано только имя подразделения.
Пользователь на следующем операционном этапе будет назван лишь после выполнения данной
функции в соответствии с текущей нагрузкой
86
Рис. 45. Структура процесса до и после внедрения коллективной организации работ
При внедрении систем workflow мы разграничиваем процессы с четко определенной
структурой и процессы, для которых последовательность выполнения определена лишь в
общих чертах. Для многих операционных и повторяющихся процедур, скажем, для обработки
заказов или ссуд, функции, их последовательность, ветви процесса и организационные единицы
заведомо известны. Такие процессы хорошо структурированы и могут быть описаны, например,
методом EPC.
Другие процессы можно описать лишь частично, поскольку функции становятся известны
только с началом фактической обработки, последовательность этапов обработки
устанавливается применительно к конкретной ситуации, а организационные единицы
определяются в зависимости от конкретных требований. Такие процессы считаются слабо
структурированными и поддаются лишь частичному моделированию. Например, их функции
можно только перечислить в списках «к исполнению». Точная последовательность функций
определяется коллективно в ходе выполнения, а ответственность за ее соблюдение возлагается
на непосредственных исполнителей. В системах workflow, разрабатываемых специально для
конкретных случаев, сотрудники сами определяют своих «преемников».
На первый взгляд может показаться, что системы workflow предназначены только для
управления четко определенными процессами. Слабо структурированные процессы
поддерживаются программным обеспечением класса groupware, функциональные возможности
которого ограничиваются электронной почтой, видеоконференциями, коллективными
конференциями и другими аналогичными средствами и которое не требует каких-либо навыков
логического построения процессов.
В реальной жизни всегда приходится иметь дело со структурами и того и другого типа.
Системы workflow имеют в своем составе функции «обработки исключений», что позволяет
изменять управление бизнес-процессом по ситуации прямо в ходе его выполнения. Эти
функции можно связать с программными решениями для коллективной работы, так что
системы workflow и groupware будут дополнять друг друга. В будущем их, по всей вероятности,
даже можно будет интегрировать. На рис. 45 показано, как хорошо структурированный процесс
вследствие его переориентации на принципы коллективной работы может быть превращен в
слабо структурированный, где обязательным предписанием является только список «к
исполнению». На рис. 46 представлены различные этапы структурирования процессов
workflow.
Благодаря стандартам интерфейсов, разработанным Коалицией по управлению workflow
(WfMC), различные системы workflow теперь могут быть связаны с помощью интерфейсов
прикладного программирования (API). В настоящее время изучаются стандарты интерфейсов
для моделирования процессов на уровне инжиниринга (уровень I), управления (уровень II) и
прикладных систем (уровень IV). Они классифицируются на основе модели-прототипа,
представленной на рис. 47.
87
Рис. 46. Различные степени структурирования процессов workflow
Рис. 47. Модель-прототип, разработанная WfMC
88
Рис. 48. Типы и экземпляры бизнес-процесса
Такие стандарты обычно представляют собой решение по минимуму, поскольку они
приводят требования сторон к наименьшему общему знаменателю. Однако все же они являются
ценными вспомогательными средствами для дальнейшей разработки открытой архитектуры
программного обеспечения, ориентированной на процессы. Но для реальных приложений
наиболее успешным методом остается разработка индивидуальных интерфейсов между
соответствующими системами.
Для того чтобы непосредственно передавать системам workflow данные, поступающие с
уровня I моделирования процессов, каждый экземпляр должен создаваться в соответствии с
шаблонами моделей. Обязательным условием является также возможность управлять данными
экземпляров. Кроме того, модели экземпляров должны быть модифицируемыми в случае
обработки исключений.
Экземпляры обычно поддерживаются прикладными системами. Системы workflow, в
основе которых лежат концепции управления процессами, не зависят ни от каких конкретных
приложений. Благодаря тому, что данные об экземплярах (например, время начала и окончания
события) фиксируются автоматически без каких-либо дополнительных прикладных модулей
(«начать обработку заказа» или «начать процесс изготовления»), они поддерживаются
моделями, располагающимися на уровне I репозитория ARIS.
На рис. 48 приведен фрагмент бизнес-процесса «обработка заявки на ссуду» на уровне
типов и на уровне экземпляров. На метауровне объект-экземпляр связывается с каждым
объектом-типом отношением 1:* (см. рис. 49). В разделе Д.2 «Уровни моделирования» мы
подробно рассмотрим, как модели экземпляров встраиваются в концепцию ARIS (в частности, в
мета- и мета
2
-структуру репозитория).
Рис. 49. Связь между объектом-типом и объектом-экземпляром на метауровне
89
Г.4. Прикладные системы
Системы workflow инициируют работу приложения на уровне АБИ посредством команды
CALL, избавляя пользователей от необходимости разбираться в тонкостях прикладной
системы. Как только команда CALL активизирует обработку варианта (экземпляра) процесса,
система workflow вызывает экран соответствующее приложение вместе с информацией,
необходимой для данного процесса. Наряду с комментариями относительно используемых
программ обработки эта информация содержит комментарии базы данных, хранящиеся в
электронной папке событий.
Для управления программами при помощи системы workflow требуется достаточно
высокая степень структурирования программных модулей. Кроме того, эти модули должны
быть доступны извне для системы workflow.
Далее мы кратко обсудим различные возможности управления традиционными
стандартными программами посредством процессов. Затем рассмотрим объектно-
ориентированные методы, которые становятся все более актуальными и подводят к идее
компонентного программного обеспечения. Принципы построения инфраструктуры,
заложенные в концепции АБИ, позволяют получить информацию об архитектуре, а также
многократно использовать программные компоненты.
Г.4.1. Традиционные стандартные программные решения
Традиционные стандартные программные решения для различных аспектов бизнеса
представляют собой интегрированные прикладные системы, управляемые транзакциями.
Нередко эти решения состоят из интегрированных программ и предполагают программное
управление процессами, что не вполне вписывается в концепцию АБИ, где управление
реализуется системами workflow.
Однако при условии разбивки прикладных систем на компоненты и при наличии у них
интерфейса для вызова удаленных процедур (RPC) системы workflow могут инициировать
выполнение этих программных модулей или транзакций. Например, SAP R/3 располагает
интерфейсом для вызова удаленных функций (RFC). При применении независимых систем
workflow для управления стандартными программами последние разделяются на функции
обработки и поток управления, поступающий от workflow. Это означает, что производитель
больше не отвечает за целостность решения. Для переноса этого гибкого метода на архитектуру
стандартных программных решений в этих решениях используются специализированные
системы workflow для управления процессами. К сожалению, такие системы workflow зачастую
тесно связаны с конкретной системой и не подходят для решений, в основе которых лежат
гетерогенные системы.
Эти модели позволяют конфигурировать стандартные программы при условии, что такие
программы описаны семантическими моделями, связанными с репозиторием системы.
90