Теория и практика реорганизации бизнес-процессов

 

Организация параллелизма при планировании бизнес-процесса

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

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

 

Глава 3. Методы и средства тестирования бизнес-процессов

 

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

План  тестирования должен содержать:

• Формулировку целей тестирования;
• Критерии качества тестирования;
• Потребности в ресурсах для достижения заданного критерия качества при выбранной стратегии.

 

Модель потоков данных бизнес-процесса

Для того чтобы обнаружить ошибки в бизнес-процессе в качестве управляющего каркаса  используют подграф уровня операций бизнес-процесса.

На втором этапе построения модели потоков  данных бизнес-процесса строится контекст данных.

 

Критерии тестирования бизнес-процессов

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

Критерий 1: требует, чтобы каждый элемент  среды данных тестируемой бизнес-операции был проверен по крайней мере однажды.

Критерий 2: требует, чтобы каждый элемент  контекста данных тестируемой бизнес-операции был проверен, по крайней мере, однажды.

Критерий 3: требует, чтобы каждый элемент  упорядоченного контекста данных тестируемой  бизнес-операции был проверен, по крайней мере, однажды.

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

 

Теорема о вложении критериев

Теорема: Любое множество маршрутов M, удовлетворяющее требованиям критерия Сi для 1<i<4, также удовлетворяет и требованиям любого из критериев Cj при 1<j<i.

Далее автор  рассматривает доказательство теоремы.

 

Генерация маршрутов тестирования

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

• Генерация множества маршрутов, обеспечивающего достижение заданного критерия тестирования;
• Генерация тестовых данных, обеспечивающих исполнение заданного маршрута.

Данный  параграф посвящён решению задачи 1. Здесь автор предлагает генератор  маршрутов тестирования, удовлетворяющих  критерию 1. Предлагаемый генератор  может использоваться как для  выборочного тестирования отдельных  наиболее критичных и/или сложных  операций бизнес-процесса, так и  для тестирования всего бизнес-процесса в целом.

В состав генератора входят:

1. Монитор, осуществляющий управление сеансом тестирования;
2. Блок генерации множества маршрутов тестирования, удовлетворяющего требованиям критерия 1;
3. Модуль генерации маршрута между узлом определения и узлом использования ИО по графу бизнес-процесса.

Далее автор  приводит алгоритм построения множества  маршрутов, удовлетворяющих требованию критерия 1.

 

Глава 4. Методы и средства оценки качества бизнес-процессов

 

Исследования  в области экономики (анализ конвейерного способа производства, анализ оргструктур  предприятий и др.) показали, что  для качественного бизнес-процесса существенными является соблюдение следующих условий:

1. Составляющие его бизнес-функции должны быть как можно более независимы (критерии сцепления);
2. Каждая из функций должна выполнять единственную, связанную с общей задачей подзадачу (критерий связности).

 

Критерий сцепления бизнес-процесса

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

• Уменьшение количества соединений между двумя функциями приводит к уменьшению вероятности появления «волнового эффекта» (ошибка одной функции влияет на работу других функций и всего процесса в целом);
• Упрощение процесса для понимания, насколько это возможно.

Фактически  понятие сцепления обобщает механизмы  передачи параметров между компонентами программных систем.

 

Критерий связности бизнес-процесса

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

 

Алгоритм определения типа связности

Критерии  сцепления и связности и ранжирование их типов позволяют оценивать  качество спроектированных бизнес-процессов  путём определения имеющих место  типов сцепления и связности  и оценки возможности их улучшения.

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

 

Порождение вариантов выполнения бизнес-процесса с учётом типа связности

Для построения возможных вариантов выполнения бизнес-процесса, учитывая тип его связности, используется механизм синтезируемых атрибутов и специальных методов синтеза.

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

Способы порождения вариантов выполнения бизнес-процессов:

1. Способ с использованием механизма синтезируемых атрибутов и соответствующих методов синтеза, позволяющий при порождении исключить цепочки, не удовлетворяющие соответствующему типу связности;
2. Способ модификации алгоритма вывода, состоящего из этапа построения всех возможных правильных цепочек без учёта типа связности и этапа анализа построенного множества цепочек на предмет удовлетворения соответствующему типу связности.

 

Глава 5. Методическое, алгоритмическое и программное обеспечение поддержки реорганизации бизнес-процессов

 

Цикл реорганизации бизнес-процесса и его автоматизируемые этапы

В основе любых работ по реорганизации  предприятия лежит понятие цикла  реорганизации бизнес-процесса, включающего  следующие этапы (перечисление от автора):

• Организационные мероприятия, предваряющие проведение работ по улучшению бизнес-процесса;
• Изучение процесса, включая его понимание, анализ и выявление узких мест;
• Анализ предложений по реорганизации;
• Выбор и аргументация приемлемого варианта;
• Собственно, реализация улучшения.

Автоматизации могут подвергаться лишь этапы изучения, анализа и  выбора. Далее автор рассматривает  приведённые этапы более детально.

 

Построение графа процесса.

В этом параграфе автор рассматривает  метод и реализующий его алгоритм построения графа бизнес-процесса.

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

 

Автоматизация планирования бизнес-процесса

Задача планирования (проектирования) бизнес-процесса является одной из наиболее трудоёмких при проведении реорганизации ввиду необходимости  построения и анализа огромного  числа вариантов. Основные этапы  разработанной для достижения этой цели методики приводит автор в данном параграфе.

Перечислю решаемые методикой задачи в их последовательности (перечисление от автора):

1. Автоматизированное уточнение графа бизнес-процесса на предмет возможности последовательности и параллельности выполнения бизнес-функций, а также введение значений синтезируемых атрибутов, ограничений на них и методов их синтеза.
2. Автоматическое построение грамматики бизнес-процесса на основании его графа.
3. Автоматическая генерация (на основании порождающей грамматики) множества всевозможных вариантов выполнения бизнес-процесса на основании набора его бизнес-функций (бизнес-операций).
4. Автоматический выбор подмножества вариантов на основании ряда объективных критериев.
5. Ранжирование лицом, принимающим решения (ЛПР), предъявленных ему и /или введённых им самим субъективных критериев присваивание этим критериям определённых весов.
6. Автоматический выбор нескольких наиболее подходящих вариантов выполнения бизнес-процесса.
7. Окончательное принятие ЛПР решения по планируемому бизнес-процессу.

 

Автоматизация верификации бизнес-процесса

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

Перечислю решаемые методикой задачи в их последовательности (перечисление от автора):

1. Автоматическое выявление типов сцепления и связности бизнес-процесса.
2. Анализ выявления типов сцепления и связности. Если эти типы не устраивают ЛПР, то определение приемлемых типов сцепления и связности.
3. Автоматическое порождение вариантов бизнес-процесса, имеющих определённые типы сцепления и связности.
4. Автоматическая генерация маршрутов тестирования бизнес-процесса.
5. Автоматический анализ каждого из сгенерированных маршрутов на предмет обнаружения ошибок в потоках данных бизнес-процесса.

 

Расширение традиционного CASE-пакета средствами поддержки реорганизации бизнес-процессов

Для реализации предлагаемых методов  и средств построения программных  систем поддержки управления реорганизацией бизнес-процесса в качестве примера  типового базового CASE-средства может быть предложен пакет «CASE. Аналитик». Такой выбор обуславливается следующими причинами (перечисление от автора):

1. Пакет является одним из наиболее функционально полных и обеспечивает построение функциональной, информационной и событийной моделей предметной области, используя при этом стандартные диаграммные техники.
2. Реализуемая пакетом методология структурного системного анализа Гейна-Сарсона является классической и используется в различных диалектах приблизительно в 90% имеющихся CASE-средств.
3. Опубликованы форматы выходных файлов пакета.
4. Пакет ориентирован на российский рынок, в частности генерация проектной документации выполняется пакетом в соответствии с требованиями отечественных ГОСТ.
5. Имеется большое количество наработанных моделей предприятий и учреждений различных типов и масштабов, выполненных в среде «CASE. Аналитик».