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

Подходы

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

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

Документный подход –

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

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

Ресурсный подход –

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

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

Поточный подход –

предлагает взгляд на бизнес-процессы, как на потоки работ (заданий) исполнителей.

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

Датацентристский подход –

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

Суть подхода заключается в выделении в модели объектов учета специальных объектов типа «процесс», обладающих обязательным набором атрибутов (время начала/конца, исполнитель) и связями с объектами, которыми данный процесс манипулирует.

«ДОступный» подход –

основывается на описании прав доступа исполнителей к объектам модели учета.

В конечном счете, все, что исполнитель в какой-то момент может сделать с объектом учета, именно это он _должен_ сделать.

Совместимость описаний

Уровни детализации: декомпозиция и агрегирование.

Очевидно, что в зависимости от назначения описания бизнес-процессов, требования к детализации совершенно различные.

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

Множественность нотаций

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

Это позволяет компенсировать недостатки одних нотаций достоинствами других и выбирать для интервьюирования эксперта наиболее адекватную его образу мышления нотацию.

Обеспечение совместимости

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

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

Предложение

Предлагается применить датацентристский и «доступный» подходы для описания нотации, основанной на состояниях объектов учета, переходах между состояниями и агентах переходов.

Приводимые ниже рассуждения строятся «снизу-вверх», однако, поддержанные программным механизмом автоматизации декомпозиции, могут использоваться при описании бизнес-процессов в обратном направлении («сверху-вниз»).

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

Представляется возможным на основании предложенной нотации породить более традиционные – IDEF, EPC, USE-CASE, WorkFlow и т.п. А главное, наряду со схемой базы данных, из описания бизнес-процесса в такой нотации можно сгенерировать прототипы экранных форм пользовательского интерфейса.

2 комментариев на “Проблемы описания бизнес-процессов”

  1. По моему у Вас украли эту статью и поместили на другом сайте. Я её уже видела.

    Дата: Март 18th, 2014 | 11:47
  2. Александр Широков

    Ссылочку, пожалуйста!

    Дата: Март 18th, 2014 | 11:54

Оставить комментарий