CC BY
332
№ 5 (41) 2012
И. Г. Фёдоров, канд. техн. наук, профессор Московского государственного университета экономики, статистики и информатики
Системный подход к выявлению бизнес-процессов методом «сверху вниз»
Любая реорганизация бизнеса начинается с анализа бизнес-процессов компании. Но если процессы еще не формализованы, их необходимо вначале выявить и построить соответствующие модели. Предлагаемая методика построения модели процесса методом «сверху вниз» позволяет обнаружить все сценарии исполнения бизнес-процесса.
Введение
Выявление процесса — процедура, направленная на обнаружение способов исполнения какой-либо деятельности с целью построения модели бизнес-процесса. Бытует мнение, что процесс можно выявить методом «снизу вверх», интервьюируя участников [1]. Такой способ достался в наследство от производственных процессов, имеющих линейную, последовательную структуру. Однако логика бизнес-процессов имеет сложный алгоритм, неудивительно, что проектирование модели процесса указанным методом приводит к запутанным и трудно читаемым схемам [2]. Выявление процесса методом «снизу вверх» включает опрос участников, сбор исторических данных, затем из многочисленных и зачастую избыточных деталей синтезируются процессы и подпроцессы [3]. Поскольку процедура синтеза не формализована, каждый аналитик использует собственные приемы и методы, так что моделирование становится своего рода ремеслом, тогда как задача требует инженерного решения.
Построенные данным методом модели имеют множество недостатков. Они перегружены деталями и трудно понимаемы [4]. Считается, что сложность есть свойство конкретных нотаций, но это неверно, запутанность есть следствие отсутствия методики выявления. Большинство моделей вряд ли можно назвать полными, посколь-
ку они описывают отдельные наиболее очевидные маршруты, по которым исполняется наибольшее число процессов, забывая, что в реальности сценарий функционирования существенно более сложный. Часто модели не точны, не достигают нужного уровня детализации. В функционально ориентированных системах, где человек играет активную роль, а ИТ-система — подчиненную, пропуск какого-либо сценария на этапе моделирования или недостаточная точность модели не являются критичными, так как человек определяет порядок исполнения. Но в процессно-ориентированной системе маршрут обработки заранее определен, пропуск сценария или недостаточная точность недопустимы, поскольку корректное исполнение процесса окажется невозможным.
Цель данной работы — представить бизнес-аналитику пошаговую инструкцию действий, которая поможет выявить модель бизнес-процессов методом «сверху вниз», найти и зафиксировать все варианты их исполнения. Полученная диаграмма процесса будет иерархической, где верхний уровень даст концептуальное представление о процессе и его окружении, а нижний — опишет детали, существенные для исполнения.
В рамках настоящей работы рассмотрим только вопросы выявления и моделирования бизнес-логики процесса и не будем определять участников процесса и их роли. Договоримся также рассматривать изолирован-
№ 5 (41) 2012
ный процесс, который не взаимодействует с другими процессами, это позволит исключить из рассмотрения вопросы процессной хореографии.
Состояние проблемы выявления сценариев исполнения
Для выявления вариантов использования А. Кобэрн предложил определять основной сценарий исполнения, а затем добавить все отклонения от него [5]. Цель абсолютно правильная, однако метод выявления основного и дополнительных сценариев не ясен. Во-первых, не вполне корректно определять основной маршрут как наиболее короткий путь достижения цели процесса (так, например, отказ в выдаче кредита есть кратчайший путь, но вряд ли его можно назвать основным сценарием). Во-вторых, рекомендация выделить основной сценарий, определить типичный ход событий, линейную последовательность шагов, наиболее быстро приводящую главное действующее лицо к цели, хотя и правильная, но остает-
* ся мало полезной, автор не объясняет, как I добиться результата. Т. Корсон предложил
рассматривать иерархию вариантов использования, показал, что вариант не является ^ результатом функциональной декомпозиции процесса [6], но не предложил путь к выяв-¡5 лению процесса.
® Для того, чтобы сделать схему процесса § читаемой и понятной, Б. Сильвер предла-§■ гает создавать иерархическую модель, где & верхний уровень дает общее представление | о процессе, показывает его взаимодействие с другими процессами, а также внешние § сущности, образующие окружение процесса са. Все детали исполнения процесса долж-| ны быть «спрятаны» на нижних уровнях [7].
-О
* Идея абсолютно верная, однако непонят-§ но, как построить иерархию процесса, рас-Ц крывая его методом «снизу вверх». Дело
в том, что аналитику трудно понять, по ка-
| кому принципу надо группировать операции
К в подпроцессы, которые выносятся на верх-
¿1 ний уровень диаграммы.
Методология SADT
Каждый процесс описывает определенную работу. Рассмотрим декомпозицию работы на операции и действия. Обратимся к методологии SADT, которая определяет основные правила структурного подхода, в том числе стратегии декомпозиции [8]:
1. Функциональная декомпозиция базируется на анализе функций системы.
2. Структурная декомпозиция в соответствии с известными стабильными подсистемами.
3. Декомпозиция жизненного цикла заключается в выявлении этапов обработки некоторого объекта.
4. Декомпозиция по физическому процессу, основанная на отслеживании деталей изменения состояния некоторого объекта.
Можно предположить, что способ декомпозиции определяет тип результирующей модели [9]. Если использовалась функциональная декомпозиция, полученную модель следует классифицировать как функциональную, она отвечает на вопрос: что делать. А если применялась декомпозиция по процессу, то модель следует называть процессной, она отвечает на вопрос: как выполнять работу. Интересно, что авторы SADT отмечают: «Результатом декомпозиции по процессу может стать слишком детальное описание системы, которое не будет в полной мере учитывать ограничения, диктуемые функциями друг на друга. При этом может оказаться скрытой последовательность управления». Поэтому они рекомендуют данную стратегию только «в крайнем случае, когда не понятно, как действовать» [8].
Итак, сложности, возникающие при раскрытии процессов методом «снизу вверх», предсказаны в SADT и предопределены выбором стратегии декомпозиции. Забыв это предупреждение, повторно сталкиваемся с известной проблемой. Будем строить методику раскрытия процесса в рамках системного подхода.
№ 5 (41) 2012
Идентификация процесса
Обычно процесс связан с некоторым объектом, который подвергается обработке по ходу выполнения процесса и на выходе формирует некоторый продукт. Например, выдача банковского кредита начинается с обработки заявки клиента, а процесс предоставления услуги телекоммуникационной компании начинается с оформления заказа.
Для выявления границ процесса следует начать с рассмотрения фаз жизненного цикла соответствующего объекта. Например, банковский кредит имеет следующие фазы: а) принять решение по заявке; б) обслуживать кредит (зарегистрировать кредитный договор в БИС, выдать заем, принимать платежи, рассылать уведомления и т. д.); в) взыскать задолженность; г) закрыть кредитный договор. Причем каждый этап связан со своим объектом. Границы анализируемого процесса могут не совпадать с рассматриваемыми этапами жизненного цикла. Например, процесс «принять решение по заявке» совпадает с границами соответствующей фазы, а процесс «выдать кредит» объединяет фазу «принять решение по заявке» и два подпроцесса второй фазы «зарегистрировать кредитный договор в БИС» и «выдать заем». Такое объединение допустимо, если аналитик отдает себе отчет в результатах.
Далее процессу необходимо выбрать название, которое должно отражать его основную цель и определять результат. Рассмотрим ситуацию, когда клиенту отказывают в выдаче кредита. Для процесса «выдать кредит» отказ рассматривается как брак, поскольку результат не достигнут, а для процесса «принять решение по заявке» любое обоснованное решение, включая отказ, рассматривается как успех, браком же в этом случае считается ошибочное или запоздалое решение. Изменяя название процесса, тем самым корректируем его границы.
Если процесс шире этапа жизненного цикла, все покрываемые фазы следует яв-
но выделить в модели процесса, они образуют цепь взаимодействующих подпроцессов [3]. Если предполагается автоматизиро- ® вать только часть этапа жизненного цикла, за выбранный фрагмент надо рассматривать в контексте всего этапа, ведь важно достижение главной цели, а не промежуточного результата. Например, в рамках процесса можем легко обнаружить возвраты для повторной обработки, а в рамках этапа выявить такие повторы значительно труднее. К тому же, в конечном счете интересует управление всем процессом, а не фрагментом. Недостаточно ограничить длительность этапа, он может исполняться вовремя, тогда как весь процесс целиком — с опозданием из-за повторного исполнения этапов.
Таким образом, аналитик должен рассмотреть анализируемый процесс в контексте этапов жизненного цикла соответствующего продукта. Он должен понять, совпадают ли границы процесса с этапами жизненного цикла. Введем понятие «объект управления».
Объект управления
Процесс описывает последовательность изменения состояния системы во времени. В производственном процессе фиксируются изменения состояния материального продукта. Но в бизнес-процессе изменение состояния системы фиксируется в информационных объектах, которые не имеют материального представления [3]. Следует решить, как определять состояние сложной системы, включающей множество информационных объектов.
В информационной системе со сложной структурой число состояний и переходов между ними может стремительно увеличиваться, что затрудняет анализ. Чтобы упростить модель, предложены переменные состояния1, могущие принимать лишь ограничен-
1 Переменные состояния ввел Э. Дейкстра, он предлагал сначала определить набор состояний системы и лишь затем строить ее алгоритм.
№ 5 (41) 2012
ное число априорно установленных значений и определяющие состояние всей системы. Хотя количество переменных и число потенциальных значений каждой из них считается конечным, результирующее множество состояний может оказываться необозримо большим [10, 11]. Чтобы ограничить число состояний, рассматриваемых в отдельный момент времени, принято выделять одну переменную состояния, которая определяет поведение системы на определенном интервале ее функционирования, она становится объектом управления. Например, в рассмотренных выше примерах объектом управления являются документы «Заявка» или «Заказ», имеющие сложную структуру, любое сочетание их атрибутов может рассматриваться как состояние. С целью сокращения числа состояний предложено разделять количественные и качественные изменения объекта управления, последние происходят при определенном сочетании количественных изменений [12]. Например, объект «Заявка» включает: имя клиента, адрес, описание заказа. Ввод имени клиента изменяет » соответствующее поле документа, но опе-I рация будет завершена, только когда будут введены все необходимые данные. Например, выполнение операций «рассмотреть ^ заявку» или «калькулировать заказ» приводит к качественному изменению состояния ¡5 заявки или заказа. Качественное состоя® ние называют комплексным (сложным), ес-§ ли его поведение можно декомпозировать §■ на отдельной диаграмме состояний, где бу-& дут рассматриваться только изменения количественных параметров переменной состояния. Таким образом, можно говорить § о иерархической вложенности диаграмм | состояния и иерархической декомпозиции § переменной состояния.
со Ьс
| Методика выявления процесса | методом «сверху вниз»
'5
| Выявление процесса «сверху вниз» нуж-
К но осуществлять последовательно. Приме-
¿1 ним декомпозицию по функциям, а затем
по этапам жизненного цикла объекта управления — таким образом построим верхний уровень модели процесса. Аналитик пока не должен стремиться к глубокой степени детализации. Далее обсудим критерий глубины раскрытия процесса.
Основной сценарий исполнения
Основным (Happy path) называется такой сценарий выполнения процесса, в ходе которого все операции завершаются результативно и с приемлемым качеством, никаких отклонений в исполнении процесса не наблюдается. Следуя определению, работы, включенные в основной сценарий, связаны только безусловными переходами, ветвлений на схеме нет. Чтобы выявить основной сценарий, следует создать структурную декомпозицию работ, а затем расположить работы в порядке очередности их исполнения.
Функциональная декомпозиция
Согласно А. Кобэрну, исполняя процесс, преследуем определенную цель [13]. На первом этапе главную цель следует декомпозировать на задачи, которые подлежат решению, чтобы процесс завершился успешно. Для каждой задачи определим результат, который свидетельствует, что задача решена и цель достигнута. Теперь можно переходить к декомпозиции по этапам жизненного цикла.
Декомпозиция по этапам жизненного цикла объекта управления
Декомпозиция процесса по этапам жизненного цикла помогает расположить работы в порядке их исполнения. Эта декомпозиция не предполагает анализа ветвлений процесса, этапы располагаются в естественном порядке следования, они связаны безусловными переходами и таким образом образуют основной сценарий исполнения процесса. Можем оформить каждый этап как подпроцесс, тогда основной сценарий будет изображаться цепочкой подпроцессов, связанных безусловными переходами (рис. 1).
№ 5 (41) 2012
Процесс 0
ЬО
РгосезэНарруРаШ Основной сценарий исполнения
{ N / /• "Ч
Подпроцесс 1 —► Подпроцесс 2 —► Подпроцесс 3 —► Подпроцесс 4
И Е 0 И
нэ
Рис. 1. Основной сценарий исполнения процесса
Основной сценарий не предполагает показ альтернативных вариантов исполнения и ветвления, поэтому следующими шагами модель следует уточнить: а) расширить — добавить в основной сценарий пропущенные варианты исполнения; б) углубить — детализовать каждый из подпроцессов.
Метод нахождения альтернативных сценариев
Каждый этап связан с решением соответствующей задачи. Результат выполнения этапа есть показатель продукта, он фиксируется в переменной состояния. Продолжение процесса зависит от результата завершения очередного этапа, рассмотрим два сценария:
1. Ожидаемый результат этапа достигнут — нормальное продолжение.
2. Результат не достигнут — брак.
В случае достижения результата продолжается основной сценарий. Самый простой случай — если вариант продолжения только один, однако бывают ситуации, когда продолжений несколько, причем выбор нужного маршрута осуществляется путем анализа показателей продукта. Например, принято положительное решение по кредиту, но дальнейшая обработка зависит от величины запрашиваемого займа, в случае незначительной суммы можно пропустить дорогостоящие проверки заемщика. Таким образом, возникают альтернативные сценарии: во-первых, может исполняться следующий по порядку этап, во-вторых, если показатель больше (меньше) порогового значения, происходит обгоняющий переход вперед, в обход очередных этапов. Возникает вопрос, какой из этих ва-
риантов должен войти в основной сценарий? Здесь следует вспомнить, что основной сценарий включает только безусловные переходы, поэтому исполнение следующего этапа есть главный сценарий, а обгоняющий переход в обход очередного этапа должен рассматриваться как дополнительный.
Рассмотрим второй сценарий: результат этапа не достигнут, произошел брак. В этом случае возможны два варианта продолжения:
1. Исправимый дефект, который можно устранить путем повторной обработки. В этом случае осуществляется замедляющий переход назад.
2. Брак, отказ от дальнейшей обработки, окончание работ по данному экземпляру процесса, переход на конец исполнения.
В общем виде схема процесса, построенная путем анализа показателей продукта, изображена на рис. 2.
Альтернативный сценарий
на основе анализа показателей исполнения
В случае если аналитик не рассмотрит показатели исполнения в ходе моделирования, он не заложит в бизнес-логику корректирующие действия, осуществляемые в случае выхода показателей за пределы допустимого коридора значений. Легко представить ситуацию, когда время или себестоимость исполнения ограничены, при превышении порогового значения предусмотрены управляющие воздействия. Рассмотрим далее принципы контроля времени исполнения процесса (контроль себестоимости осуществляется аналогично).
9
со
0
■э
1
и:
=5
№ 5 (41) 2012
Результат
Исправимый дефект, повторная обработка ^^ Брак, отказ от обработки
Рис. 2. Поиск сценария исполнения путем анализа показателей продукта
I
со
I
55
0 ?
1
со
о £
0 &
1
I
I
й Ьс
I
I
Й £
Расписание исполнения
Декомпозиция по этапам жизненного цикла помогает построить расписание исполнения процесса. Для этого лимит времени, отводимый на исполнение всего процесса, следует распределить между этапами обработки. Таким образом, отмечаем вехи — контрольные точки на карте процесса, которые должны быть достигнуты к определенному сроку. Рисунок 3 показывает принцип формирования расписания процесса.
Управляющие воздействия
Первое, что нужно сделать, — ограничить время исполнения этапа и определить реакцию на превышение норматива. К сожалению, лимитировать отдельные этапы недостаточно, каждый может выполняться в нормативное время, а весь процесс с запозданием, вследствие возвратов для повторной обработки. Необходимо ограничить время всего процесса, независимо от того, на каком этапе происходит обработка. Для этого следует использовать асинхронные измерения, реализуемые с использованием механизма обработки исключительных ситуаций. Например, если истек последний срок, обработка документа может стать бесполезной, процесс следует прервать, где бы ни находился документ.
1-й этап
2-й этап
Завершение 1-й этап
Альтернативный сценарий -бизнес-исключения
Устоялось мнение, что клиент, инициировавший заказ, уже не вправе его изменить или отменить. Но в реальности заказчик может поменять свои планы. Должны ли мы в случае отмены довести текущий экземпляр процесса до конца или можно прервать его исполнение и не нести ненужные затраты? Аналитик должен задать себе вопрос, с какими просьбами может обратиться клиент. Для каждой просьбы нужно описать отдельный сценарий.
Кроме того, аналитик должен предусмотреть реакцию на внешние события, которые изменяют запланированное течение процесса и позволяют провести исполнение по нестандартному сценарию. Для этого нужно задать себе вопросы: какие внешние асинхронные события могут произойти, как они повлияют на ход исполнения процесса. Схема процесса должна описывать соответствующие бизнес-исключения.
Альтернативный сценарий - ручное управление
В бизнесе часто случается, что процесс должен быть исполнен в обход стандартных правил, например, по указанию вышестоящего начальства, поэтому следует предусмотреть: во-первых, перехват управления
3-й этап
Завершение 2-й этап
4-й этап
->- Время
Завершение 3-й этап
Конец
Рис. 3. Расписание исполнения процесса
10
№ 5 (41) 2012
от исполнителя, а во-вторых, режим нестандартной, не предусмотренной моделью, передачи управления. В первом случае необходимо предусмотреть иерархию перехватов исполнения, чтобы забрать работу сотрудника мог только его непосредственный руководитель. Во втором случае, когда менеджер примет управление, он должен иметь возможность передвинуть экземпляр процесса в другую точку, но в пределах своей компетенции. Наконец, владелец процесса может перехватить управление в любой точке и вручную переместить его в обход стандартных правил обработки. С одной стороны, такой сценарий очень полезен, поскольку позволяет исполнить процесс, который по каким-то причинам «застрял» или должен исполняться не по правилам. С другой стороны, он очень опасен, поскольку открывает путь исполнения в обход стандартных проверок. Защитой в данном случае может служить система аудита, которая фиксирует исполнение всех экземпляров, в том числе нестандартных, и принятые по ним решения.
Углубление степени детализации модели процесса
Процесс может состоять из иерархически вложенных повторно используемых ком-
понентов: подпроцессов, операций и действий. Действием называется работа, выполняемая участником над объектом процесса, изменяющая этот объект количественно, но не приводящая к изменению качественного состояния. Например, участник ввел новые данные, но это не означает, что обработка документа окончена. Операцией будем называть совокупность действий, приводящую к изменению качественного состояния объекта [14]. Для аналитического моделирования достаточно опуститься на уровень операций, но для создания исполняемой модели бизнес-процесса надо стремиться к уровню действий (рис. 4).
Моделирование уровня операций
На данном этапе предстоит выявить действительный порядок исполнения операций, образующих подпроцесс, при этом возникает опасное желание сразу начать моделирование «снизу вверх». В такой момент аналитик должен вспомнить о цели подпроцесса (она известна из модели верхнего уровня) и декомпозировать ее на список задач, которые надо решить, чтобы достигнуть поставленной цели. Только после этого можно начать располагать операции в нужной последовательности, как это делалось на уровне процесса.
сы
Процесс
И
ЬО
Основной сценарий процесс
СИ
г ( \ ( /* \
Подпроцесс 1 -► Подпроцесс 2 —► Подпроцесс 3 —► Подпроцесс 4
0 У ' 0 0 0 ]
Л)
со
0
■э
1
и:
=5
Основнойсценарийподпроцесс 'V
Опрерация 2.1
И
Операция 2.2
И
ЬО
Презентационная логика
СИ
Действие 2.2.1
И
Действие 2.2.2 ^Л |
ЕЕ Ги
Рис. 4. Порядок углубления детализации процесса
11
№ 5 (41) 2012 ' -
Следует помнить, что функции, которые решают общую задачу, могут оказаться в разных частях модели процесса. И наоборот, одна операция процесса может выполнять сразу несколько функций, например, проверка заемщика по банковской ИС позволяет уточнить данные о личности клиента и о его финансовом состоянии. Таким образом, проектируя порядок операций процесса, необходимо постоянно сверяться с функциональной декомпозицией, это поможет удостовериться, что все запланированные действия выполнены, дублирования функций нет. Альтернативные сценарии подпроцесса исполнения пишутся так же, как описано выше.
Моделирование презентационной логики
Операции, в свою очередь, могут включать сложную последовательность элементарных действий, образующих презентационную логику процесса. Например, одна операция может задействовать несколько экранных форм, причем порядок их смены и очередность заполнения отдельных полей определяются презентационной логикой. При выявлении последовательности операций процесса было решено рассматривать только комплексные состояния. Теперь, переходя к определению действий, образующих операцию, следует иерархически декомпозировать объект управления, чтобы выявить его доступные состояния. Далее следует повторить процедуру выявления, описанную выше.
Обсуждение результатов
Результат обсуждения, как рекомендации статьи соотносятся с предложениями, сформулированными в гл. 5 книги А. Шарпа и П. МакДермотта (3), представлен в табл. 1.
Заметим, что рекомендации по выявлению процесса согласуются и дополняют предложения. Используя имя информационного объекта в названии процесса, подпроцесса или отдельной операции, можем отслеживать стадии их исполнения. Важные решения, принимаемые по ходу исполнения, изменяют статус основного информационного объекта и определяют вехи процесса. Таким образом, наблюдение за основным информационным объектом становится основой метода выявления процесса.
Заключение
Научная новизна настоящей работы заключается в применении методологии системного анализа SADT для раскрытия бизнес-процессов методом «сверху вниз». В качестве объекта управления предлагается выбирать бизнес-объект, который играет роль переменной состояния, изменения которого фиксируют результат выполнения отдельной операции, этапа или всего процесса целиком. В приведенном рассмотрении границы процесса определялись этапом жизненного цикла объекта управления. Если реальная задача потребует рассмотрения процесса большего охвата, его надо представить в виде цепочки
I
со
I
55
0 ?
1
со
о £
0 &
1
I
I
СО Ьс
I
I
Й £
Таблица 1
Сравнение подходов по раскрытию процесса
Предложения А. Шарпа и П. МакДермотта Рекомендации статьи
Процесс именуется парой «глагол плюс существительное» Глагол обозначает работу, существительное — основной информационный объект процесса
Имя процесса явно указывает на результат — продукт или услугу Имя процесса указывает на основной информационный объект, который подвергается обработке и на выходе формирует некоторый продукт или услугу
Начинать выявление процесса с выделения основных этапов Выявлять этапы процесса путем декомпозиции по этапам жизненного цикла основного информационного объекта
Веха процесса — важный результат исполнения этапа или процесса целиком Веха процесса определяется изменением статуса основного информационного объекта
№ 5 (41) 2012
взаимодействующих процессов, где каждый имеет свой объект управления [3]. Прикладная ценность работы заключается в рекомендациях и методе построения процессной модели «сверху вниз». Сосредоточив внимание на объекте управления, аналитик получает мощный инструмент анализа процесса.
Практический опыт применения предложенного метода выявления процессов показывает его эффективность, аналитик в состоянии самостоятельно выявить основной сценарий, все точки альтернативных ветвлений процесса, но не всегда может сам определить то место на диаграмме, куда нужно направить альтернативный переход. Аналитик может самостоятельно выявить случаи, когда необходимо обработать бизнес-исключение, хотя он не всегда может определить логику этой обработки. Таким образом, метод не исключает необходимости обратиться за консультацией к эксперту предметной области. Однако аналитик задает эксперту конкретные вопросы и вправе ожидать четкие ответы. Это очень важно, так как позволяет избежать опасности, если эксперт забудет рассказать о каком-либо альтернативном сценарии.
Итак, предлагаемый метод помогает избежать зависимости от желания и способности эксперта предметной области раскрыть детали процесса. Практика показывает, что, когда эксперт предметной области видит самостоятельную работу аналитика, он начинает более продуманно и точно отвечать на вопросы. Поскольку предлагаемая техника описывает четкую последовательность шагов раскрытия процесса, происходит процесс избавления от субъективизма, связанного с квалификацией и опытом аналитика.
Полученная в результате анализа модель получается иерархической, структурированной, удобной для понимания. Представителям бизнеса могут показаться интересными верхние уровни иерархии, поскольку их не интересуют мелкие детали, но важна логика процесса. Для технологов и экспертов, напротив, будет интересна детализация уровней операций и действий. Представленный метод раскрытия бизнес-процесса
на практике доказал свою эффективность Ц и может быть рекомендован бизнес-аналитикам, которые стремятся создавать испол- ® няемые модели бизнес-процесса [15]. ss
Список литературы
1. Харрингтон Д., Эсселинг К, ван Нимвеген Х. Оптимизация бизнес-процессов. СПб.: Азбука, 2002.
2. Тельнов Ю. Ф. Реинжиниринг бизнес-процессов. М.: Финансы и статистика, 2005.
3. Sharp A, McDermott P. Workflow Modeling — Tools for Process Improvement and Application Development: Artech House, 2001.
4. WeelH. van derWill BPMN completely replace EPC?: BrainStormCentral [Online] URL: http://brainstorm.le-veragesoftware.com/group_discussion.aspx?Discus sionID=546330866b9549508e7c9b49e3e00b3b.
5. Cockburn A. Writing Effective Use Cases. NY: Ad-dison-Wesley, 2000.
6. Korson T. Misuse of Use Cases. 1998. URL: http:// software-architects.com/publications/korson/kor-son9803om.htm.
7. Silver B. BPMN Method and Syle.: Cody-Cassidy Press, 2009.
8. McGowan C, Marca D. SADT: structured analysis and design technique. NY: McGraw-Hill Book Co., Inc., 1988.
9. Тельнов Ю. Ф., Фёдоров И. Г. Сравнительный анализ справочных моделей // Прикладная информатика. Вестник УМО. 2011. № 4.
10. SamekM. A Crash Course in UML State Machines. 2009. URL: www.state-machine.com.
11. Шалыто А. А. SWITCH-технология. Алгоритмизация и программирование задач логического управления. СПб.: Наука, 1998.
12. Harel D. A Visual Formalism for Complex Systems. Science of Computer Programming. 1987.
13. Lee J. Goal-Based Process Analysis: A Method for Systematic Process Redesign. In Proc. of Conf. on Organizational Computing Systems, Milpitas CA: 1993.
14. Фёдоров И. Г. Сравнительный анализ нотаций моделирования бизнес-процессов // Открытые системы. 2011. № 8.
15. Фёдоров И. Г., Курышев К. С. и др. Особенности проектирования системы управления бизнес-процессами на примере электронного ВУЗ // Открытое образование. 2012. № 4.
