CC BY
327
ФУНКЦИОНАЛЬНЫЕ И ПРОЦЕССНЫЕ МОДЕЛИ БИЗНЕС-ПРОЦЕССОВ
УДК 65:330
Юрий Филиппович Тельнов,
д.э.н., профессор, проректор Московского государственного университета экономики, статистики и информатики Эл. почта: [email protected]
Игорь Григорьевич Федоров,
к.т.н., профессор кафедры «Прикладная информатика в экономике», Московский государственный университет экономики, статистики и информатики Эл. почта: [email protected]
Различие между функциональные и процессные моделями заключается в методологии создания, первые получаются путем функциональной декомпозиции системы, а вторые - путем процессной. Анализ отраслевых моделей SCOR и eTOM показал, что они созданы путем функциональной декомпозиции и, т.о. являются функциональными, а не процессными. В работе предложен метод построения процессной модели сверху вниз.
Ключевые слова: процесс, функция, справочная модель,SCOR, eTOM.
Yuri F. Telnov,
PhD in Economics, vice-principal Moscow State University of Economics, Statistics and Informatics E-mail: [email protected]
Igor G. Fedorov,
Doctorate of Technological Science,
Professor, the Department of Application
Informatics in Economics
Moscow State University of Economics,
Statistics and Informatics
E-mail: [email protected]
FUNCTION AND PROCESS MODELS OF BUSINESS PROCESS
The differences between function and process models consist in the methodology of creation. The function models are worked out via the functional decomposition system and process ones are worked via the process system. The analysis of industry model SCOR and eTOM has revealed that these models was created via functional decomposition as well as they are functional. The authors offer the design method of process model top down.
Keywords: process, function, reference model, SCOR, eTOM.
1. Введение
Из работ Хаммера и Чампи [1] очевидно различие функционального и процессного подхода к управлению предприятием. В качестве решения проблемы перехода к процессному управлению они предлагают радикальное переосмысление и кардинальную переработку бизнес-процессов и для этого рекомендуют провести моделирование бизнес-процессов предприятия.
Для моделирования бизнес-процессов применяются различные методологии и нотации [2]. Однако, многие популярные сегодня техники моделирования приводят к созданию функциональных моделей. Возникает законный вопрос: можно ли переходить к процессному управлению через функциональное моделирование, нет ли тут противоречия. В этой связи стоит задуматься над определением процессной и функциональной моделей, выяснить методику построения процессной модели.
В настоящей статье будет сделана попытка проанализировать основные методики моделирования бизнес-процессов. Предполагается показать, что различия в трактовке функциональной и процессной моделей носит методологический характер. Для доказательства будем использовать приемы системного анализа и методологию SADT. Для иллюстрации выбраны справочные модели SCOR и eTOM, вместе с тем, выводы окажутся применимы для других справочных моделей бизнес-процессов.
Мы так же предложим методику раскрытия модели процесса методом сверху вниз, основанную на анализе этапов жизненного цикла информационных объектов. В заключение, обсудим правила именования бизнес-процессов.
2. Нотация и методология
Часто методологию моделирования подменяют нотацией, а это не одно и то же. Методология определяет подходы к моделированию, а нотация помогает зафиксировать результаты. Напрашивается аналогия с музыкой, где музыкальная композиция и нотная грамота суть разные вещи. В качестве примера рассмотрим нотацию IDEF0 [3], неразрывно связанную с методологией SADT [4]. Будет ошибкой называть нотацию IDEF0 методологией или сказать, что SADT есть нотация. Аналитики, которые при анализе процесса не опираются на соответствующую методологию, рискуют допустить ошибки моделирования.
В качестве примера вспомним, модели IDEF0 принято называть функциональными, однако многие используют в нотацию для описания процессов. Не может ли оказаться, что некоторые модели, которые мы используем для описания бизнес-процессов в отрыве от методологии, по сути, являются функциональными?
Наше утверждение: не нотация, а методология определяет, является ли модель функциональной или процессной. Мы покажем, что многие модели, которые преподносятся как процессные, на самом деле являются функциональными.
3. Процесс или функция
Многие авторы отмечают схожесть понятий процесс и функция и возникающую вследствие этого путаницу. Этой теме посвящено множество публикаций [5,6,7]. Особо хочется выделить статью Чарли Беца «Ongoing Confusion of Process and Function» [8]. Автор проанализировал справочные модели семейств ITIL, CMMI и COBIT. Он сравнил трактовку термина «процесс», используемую в этих моделях с определением, сформулированным Шарпом и МакДермоттом [9]: «бизнес-процесс есть последовательность взаимосвязанных рабочих задач, инициированная некоторым событием, и направленная на достижение конкретного результата, ценного для заказчика и других заинтересованных сторон». В этом определении подчеркивается ориентированность процесса на результат:
•Результат самая важная часть процесса, без результата не бывает процесса;
Для каждого экземпляра исполняющегося процесса результат должен быть идентифицируемым и счетным. Если результат невозможно сосчитать, то мы имеем дело с функцией, а не процессом;
•Правильное имя процесса явно указывает на результат или конечное состояние процесса, продукт, который будет разработан, услугу и так далее.
Благодаря приведенным критериям появляется возможность понять, имеем ли мы дело с процессом или функцией. Если результат исполнения можно иден-
тифицировать и сосчитать, то перед нами процесс, если нельзя, значит функция. Ч. Бец приводит многочисленные примеры несоответствий трактовки термина процесс в справочных моделях ITIL, CMMI и COBIT данному определению. Например, управление инцидентами, изменениями, качеством и т.д. не являются процессами, результат не счётен. Далее автор делает предположение, что именно различие в трактовке термина «бизнес-процесс» м.б. одной из главных проблем, возникающих при практическом внедрении справочных моделей.
Ч. Бец написал то, о чем многие подозревали, но боялись сказать: справочные модели, называемые Operation Reference, в большинстве случаев являются функциональными моделями, а не процессными. Чарли ссылается на свой опыт и здравый смысл, мы добавим новые аргументы в поддержку его тезиса.
4. Процесс описывает работу
Из приведенного выше определения можно понять, что процесс описывает работу, которую необходимо выполнить, что бы получить запланированный продукт или услугу. Что бы Вы стали делать, что бы спланировать работу? Можно предложить воспользоваться приемами проектного менеджмента, тем более, что многие отмечают существенные сходства между процессом и проектом [10]. Для этого следует создать список работ, которые необходимо выполнить, а затем, составить расписание исполнения указанных работ. В проектном менеджменте список работ получил название структурированная декомпозиция работ. Разработано множество техник составления такого списка, обычно используется декомпозиция работ. Однако, никто не задумывается о влиянии выбора стратегии декомпозиции на результат. Что бы исследовать способы декомпозиции процессов, воспользуемся методологией SADT.
5. Структурный анализ и Техника Проектирования SADT
Давайте вспомним, методология SADT [11] предполагает рассматривать сложный объект как иерархическую многоуровневую модульную систему. Концепция декомпозиции предполагает разделять исходный объект на составляющие, но таким образом, чтобы из компонентов можно было восстановить, синтезировать исходный объект. Таким образом, система рассматрива-
ется как фиксированное упорядоченное множество объектов и отношений между ними. Авторы БЛОТ рассматривают несколько способов декомпозиции системы.
1. Функциональная декомпозиция позволяет получить перечень всех действий, которые необходимо выполнить, чтобы добиться запланированного результата. В результате получается функциональная модель, которая не привязана к конкретной организационной структуре предприятия.
2. Декомпозиция в соответствии с известными стабильными подсистемами приводит к созданию иерархии, привязанной к существующей структуре организации. Как следствие, модель окажется неприменима к организации с иной структурой. Вместе с тем, она помогает понять распределение работ между подразделениями, например, какие работы выполняет бухгалтерия, а какие экономический отдел.
3. Декомпозиция, основанная на отслеживании жизненного цикла какого-либо объекта позволяет увидеть очередность основных этапов процесса. Однако реальные процессы имеют более сложные сценарии исполнения.
4. Декомпозиция по физическому процессу показывает последовательность действий, направленную на получение конкретного результата, отвечает на вопрос «Как выполняется работа?» и обеспечивает получение процессной модели.
Можно предположить, что именно способ декомпозиции определяет тип результирующей модели. Если использовалась функциональная декомпозиция, полученную модель можно классифицировать как функциональную, она отвечает на вопрос: «что делать»? Если же применялась декомпозиция по процессу, то результирующую модель можно назвать процессной, она отвечает на вопрос: «как выполнять работу?»
Авторы БЛОТ рекомендуют функциональную декомпозицию, но не отвергают остальные стратегии. Но последователи, забыв рекомендации, используют только функциональную декомпозицию. Интересно, что за моделями ГОЕБО прочно закрепилось название функциональная диаграмма [12]. Последнее верно лишь в случае использования функциональной декомпозиции. Но если использовать декомпозицию по этапам жизненного цикла, с помощью диаграммы ГОЕБО можно
описывать процесс.
6. Модель SCOR
Давайте исследуем справочную модель логистической деятельности SCOR [13]. Модель делится на три уровня, именуемые: Process Types, Process Categories, Process Elements. Документация упоминает четвертый уровень Implementation Level, который не входит в состав модели, но, как считают авторы SCOR, может быть «легко» получен из справочной модели. Если проанализировать, какие стратегии использовались при создании модели SCOR (см. рисунок 1), выяснится, что она построена путем функциональной декомпозиции.
Что бы построить верхний уровень модели авторы задают вопрос: «что делает логистическая компания?». Ответом является перечень видов деятельности: Plan, Source, Make, Deliver, Return. Возможно, некоторым покажется, что это декомпозиция по жизненному циклу, но, в таком случае, следовало бы явно выделить объект, этапы жизненного цикла которого мы анализируем. Поскольку объект не выделен, декомпозицию следует рассматривать как функциональную. Этот уровень называется Типы «процессов».
Второй уровень описывает «конфигурацию процессов». Каждый из элементов первого уровня подвергается функциональной декомпозиции, например, деятельность Plan разделяется на: Plan Source, Plan Make, Plan Deliver, Plan Return. Аналогично производится декомпозиция остальных видов деятельности.
Последний, третий уровень модели показывает процессные элементы, те самые кирпичики, из которых планируется строить сквозные процессы. Процессный элемент представляет собой цепочку операций, выстроенную в порядке, определяемым последовательностью жизненного цикла продукта (мы специально опускаем метрики и KPI модели SCOR, поскольку они не входят в круг нашего рассмотрения). Например, Source Stocked Products выстраивается в следующую цепочку:
Schedule Product Deliveries (S1.1) ^ Receive Product (S1.2) ^ Verify Product (S1.3) ^ Transfer Product (S1.4) ^ Authorize Supplier Payments (S1.5)
В данной цепочке выделен общий для всех элементов объект, под названием Product, поэтому имеет место декомпозиция по этапам жизненного
цикла.
Авторы модели утверждают, что собственно процессы м.б. составлены из процессных элементов третьего уровня. Это действительно так, однако они умалчивают немаловажную деталь, что бы найти нужный фрагмент, придется перебрать десятки процессных элементов, полученные трехкратной функциональной декомпозицией. Процедура напоминает сборку паззла, с числом фрагментов превышающим сотню. Рисунок 2 иллюстрирует сложности, которые возникают при выборе процессных элементов, составляющих сквозной процесс [14].
Модель SCOR скромно умалчивает о возникающих трудностях, однако аналогичные проблемы, возникающие при работе с моделью eTOM, нашли отражение в официальной документации Tele Management Forum.
T. Модель eTOM
Карта операций оператора связи eTOM, разрабатываемая Tele Management Forum, представляет собой справочную модель для классификации и описания всех работ оператора телекоммуникационных услуг связи [15]. Цель описания - определить основные понятия и компоненты из которых, как из кирпичиков, строится система управления.
Карту ошибочно называют моделью процессов. Анализ карты показывает, что она построена методом функциональной декомпозиции. Руководящие документы по eTOM регулярно упоминают термин бизнес-процесс, в т.ч. сквозные процессы, например, «Выполнение», «Обеспечение» и «Бил-линг» (Fulfillment, Assurance and Billing). Однако эти «процессы» не соответствуют определению бизнес-процесса, данному Шарпом и МакДермот-том, поскольку результат их исполнения не является счетным, нельзя сказать сколько операций выполнила компания за промежуток времени.
Для правильного понимания трактовки процессов в модели eTOM необходимо рассмотреть документ «GB921F - Representative process Flows» (примеры построения цепочек потоков работ) [16]. Документ призывает различать иерархию процессных элементов (описанных в eTOM) и цепочку потоков работ (workflow). Документ следует воспринимать как иллюстрацию, демонстрирующую, что переход к потокам работ возможен, но не как практическое руководство. Описы-
Level
No.
ftk
/
Nöt in Scope
Description
Top Levet
(Process Ttfjes}
Configuration Level
(Process Categories)
Frocess Element Level
(Deoom posed Processes)
Schematic
Plan
Source Mike
___
Rétufrt
Implementation Level
(Dficwnposea ftrassa dements I
Рис. 1. Уровни модели SCOR
Рис. 2. Сборка процесса из элементов
вается только общий подход, сценарии показывают лишь некоторые из возможных взаимосвязей. Рисунок 3 демонстрирует переход от модели еТОМ к цепочке процесса. Как и в случае БСОЯ, процедура объединения процессных элементов в цепочку потоков работ не алгоритмизирована.
8. Справочная модель
Справочная модель представляет собой «идеальный» взгляд на деятель-
ность организации. Две компании, работающие в одной сфере бизнеса, выполняют одинаковые наборы действий, однако очередность операций в них может отличаться, поскольку предприятия обладают различной организационной структурой, производственной культурой и т.д. Справочная модель есть каталог функций, иерархически организованный справочник работ, в котором перечислены все действия, выполняемые
субъектами [17]. Считается, что имея «полный» набор функций, можно скомпоновать систему, применяя повторно используемые компоненты. Справочная модель обычно строится путем функциональной композиции, поскольку этот способ является наиболее естественным для анализа системы, т.о. ее следует классифицировать как функциональную.
Сила и преимущество справочной модели заключается в том, что она строится сверху вниз и определяет иерархию компонентов системы. Благодаря многоуровнему устройству она позволяет выбирать подходящий для конкретного рассмотрения уровень детализации.
9. Проблема построения процессной модели
Проблема перехода от справочных моделей БСОЯ и еТОМ к моделям потоков работ заключается в том, что в результате многократной, повторной функциональной декомпозиции теряется логическая связь, описывающая очередность выполнения процессных элементов. Восстановить потерянную связь трудоемко, что затрудняет практическое применение справочных моделей.
Поскольку построить процессную модель сверху вниз затруднительно, на практике используется подход снизу вверх. Вспомним, методики раскрытия процесса предполагают интервьюирование участников с целью узнать порядок выполнения работ. Такой способ достался нам в наследство от производственных процессов, которые имеют линейную последовательную структуру. Мы же имеем дело с бизнес-процессами, логика которых описывается более сложными алгоритмами. Немудрено, что проектирование модели бизнес-процесса методом снизу вверх приводит к запутанным и трудно читаемым схемам. Например, среди критиков ВРМК бытует мнение, что исполняемые модели перегружены деталями и трудно понятны [18]. Считается, что сложность есть неотъемлемое свойство исполняемых моделей, нотации ВРМЫ и т.д.
Интересно вспомнить, авторы БЛБТ предупреждали: «результатом декомпозиции по процессу может стать слишком детальное описание системы, которое не будет в полной мере учитывать ограничения, диктуемые функциями друг на друга . При этом может оказаться скрытой последовательность
Рис. 3. Пример процесса телекоммуникационной компании
управления» [4]. Они нас предупреждали, но мы, за давностью лет, забыли предостережение и снова наступаем на те же грабли.
Можно утверждать, сложность и запутанность модели есть следствие проектирования снизу вверх. Если бы нам удалось осуществить проектирование модели бизнес-процесса сверху вниз и прийти к процессной декомпозиции, мы получили бы стройную иерархическую модель, причем процесса «в понимании ВРМ профессионалов».
10. Построение процессной модели сверху вниз
Как было показано выше, проблема построения справочной модели не в функциональной декомпозиции, она, безусловно, нужна и полезна, а в ее и многократном повторении. Предлагаемая методика предполагает чередование функциональной декомпозиции с упорядочиванием элементов по этапам жизненного цикла.
Выявление процесса сверху вниз нужно осуществлять последовательно. Следует начинать с функциональной декомпозиции, которая помогает определить, какие действия надо совершить, что бы добиться некоторого ожидаемого результата, т.о. мы построим верхний уровень функциональной декомпозиции процесса. Аналитик может пока не задумываться о реальном порядке операций, используемом в данной конкретной организации, не должен стремиться к глубокой степени детализации.
На следующем шаге следует расставить выявленные работы в порядке,
определяемом этапами жизненного цикла [19]. Для этого следует выделить основной информационный объект процесса. В производственных процессах основным объектом является продукт, но в бизнес-процессах продукт, обычно, возникает не в ходе, а в результате исполнения процесса. С каждым процессом связан один или несколько информационных объектов. Когда мы говорим, что объект является основным для процесса, мы имеем в виду, что он фиксирует результат исполнения операции, отдельного этапа или всего процесса целиком и, тем самым, связывает входы и выходы.
После того, как мы нашли основной информационный объект, определи его свойства, можно выполнить декомпозицию процесса по этапам жизненного цикла основного объекта. Может оказаться, что не все элементы, полученные путем функциональной декомпозиции, удастся выстроить в цепочку, не страшно, возможно фрагменты принадлежат другому процессу.
В результате мы выделим цепочку этапов выполнения, которая образует основной сценарий исполнения процесса (Happy path). В некоторых нотациях цепочку этапов изображают в виде Value Chain диаграмм, мы же их будем показывать на схеме как линейную последовательность подпроцессов.
Основной сценарий не предполагает показывать альтернативные варианты исполнения и ветвления. Поэтому следующим шагом модель следует уточнить: (а) расширить - добавить в основной сценарий пропущенные ва-
рианты исполнения, (б) углубить - детализовать каждый из подпроцессов. Методика расширения основного сценария путем добавления в него всех остальных вариантов исполнения будет представлена как отдельная работа. Что бы углубить модель следует повторить процедуру декомпозиции отдельного этапа исполнения, так как это было описано выше.
Процесс может состоять из иерархически вложенных повторно используемых компонентов. Не надо считать, что каждый подпроцесс есть уровень декомпозиции и ограничивать декомпозицию, так как это рекомендует БЛЭТ. Следует проводить декомпозицию до тех пор, пока не достигнут уровень операций или уровень действий [20]. Для аналитического моделирования достаточно опуститься на уровень операций, но для создания исполняемой модели бизнес-процесса, надо стремиться к уровню действий. Последовательное многократное использование декомпозиции по этапам жизненного цикла не нарушает логической связи очередности исполнения функций.
В заключение, можно рекомендовать тщательно следить за объектом процесса. Смена объекта процесса является сигналом для аналитика, что процесс, который он считал монолитным, на самом деле представляет собой цепочку взаимодействующих подпроцессов.
11. Обсуждение
Толковый словарь определяет процесс, как последовательность смены состояний некоторого объекта [21] во времени. Мы определили понятие «основной информационный объект процесса». В результате выполнения операций состояние информационного объекта изменяется, образуя, тем самым, процесс. Мы предлагаем выявлять процесс с помощью декомпозиции по этапам жизненного цикла главного объекта. Давайте обсудим, как эти предложение соотносятся с рекомендациями из главы 5 в книге Шарпа и МкДер-мотта (Таблица 1).
Мы видим, что эти предложения хорошо согласуются и дополняют рекомендации Шарпа и МкДермотта. Анализ основного информационного объекта становится мощным инструментом, с помощью которого аналитик сможет быстро и эффективно выявлять бизнес-процесс.
Шарп и МкДермотт показали, что названия: «Маркетинговая деятель-
ность», «Продажа оборудования», «Биллинг» указывают не на процесс, поскольку результат не является счетным. Обратим внимание, в этих названиях вместо глагола стоит отглагольное существительное. В большинстве европейских языков от одной глагольной основы можно образовать две формы отглагольных существительных: имя действия и имя действующего лица. Например, от глагола проверить образуются два отглагольных существительных: проверка и проверяющий. Получается вполне логично, процесс есть работа, именуется глаголом. Функция, то что надо сделать - именем действия. Роль исполнителя обозначается именем действующего лица. Т.о. в названии функции отсутствует глагол, нет работы, поэтому нельзя подсчитать результат.
12. Функция и процесс
Проведенный анализ помогает выявить различия между функциями и бизнес-процессами. Первые определяют состав работ, вторые включают информацию, об очередности действий, временные характеристики исполнения, бизнес-правила. Бизнес-процесс есть рецепт, способ, технология достижения заранее запланированного результата. Технология есть совокупность методов и инструментов для достижения желаемого результата, способ производства. С помощью технологии стало возможно воспроизводить одинаковые изделия со стандартным качеством и за приемлемую цену. Цель технологии в том, чтобы разложить процесс достижения какого-либо результата на элементарные составляющие, зафиксировать их, сделать повторяемым и воспроизводимым. Разве не об этом же говорят классики процессного подхода?
Последнее наблюдение дает основание уточнить определение процесса,
данное Шарпом и МкДермоттом. Говоря о характеристиках результата процесса они отмечают, что он должен быть индивидуально идентифицируемым и счетным. Надо обязательно добавить, результат должен быть повторно воспроизводимым. Именно воссоз-даваемость результата есть основное требование бизнеса. Это уточнение, кстати, позволит однозначно разделить процессы и проекты.
13. Выводы
Научная новизна настоящей работы заключается в применении методологии системного анализа БЛЭТ для исследования моделей бизнес-процессов. В результате удалось показать, что различие между функциональными и процессными моделями обусловлено выбором метода декомпозиции. Функциональная декомпозиция приводит к функциональным моделям, а процессная - к процессным. Отсюда следует, что большинство справочных моделей, полученных методом функциональной декомпозиции, описывают не процессы, а функции.
Прикладная ценность работы заключается в практических рекомендациях, помогающих бизнес-аналитику в построении процессной модели сверху вниз. Для этого предлагается определить основной информационный объект процесса, изменения которого фиксируют результат выполнения отдельной операции, этапа или всего процесса целиком. Сосредоточив внимание на основном объекте, аналитик получает мощный инструмент анализа процесса.
Для выявления процесса аналитику рекомендуется чередование функциональной декомпозиции с упорядочиванием элементов по этапам жизненного цикла.
Для именования процесса рекомендуется использовать пару: глагол плюс
Таблица 1. Анализ предложений по раскрытию процесса
Рекомендации Шарпа I! МкДермотта Наши предложения
Процесс именуется парой глагол плюс существительное. Глагол обозначает работу, а существительное-основной информационный объект процесса.
Правильное имя процесса явно указывает на результат -продукт или услугу. Имя процесса указывает на основной информационный объект.
Начинать выявление процесса е выделения основных 'этапов. Выявлять этапы процесса следует путем декомпозиции по этапам жизненного цикла основного информационного объекта.
Изменение соотношения выходов н входов этапа процесса говорит о необходимости выделить подпроцесс. Смена основного информационного объекта свидетельствует о том. что монолитный процесс распадается на цепочку взаимодействующих подпроцессов.
существительное. Не рекомендуется именовать процесс отглагольным существительным. Такое название не содержит глагола, следовательно, не указывает на работу, результат не м.б. сосчитан.
Предлагаемая методика раскрытия бизнес-процесса сверху вниз на практике доказала свою эффективность и может быть рекомендована бизнес аналитикам, которые стремятся создавать по настоящему процессные модели.
Литература
1. Hammer M. What is Business Process Management? Handbook on Business Process Management 1, Introduction, Methods, and Information Systems, Editors vom Brocke J., Rosemann M., Springer-Verlag Berlin Heidelberg 2010
2. Тельнов Ю.Ф. «Реинжиниринг бизнес-процессов», Финансы и статистика, 2005.
3. Draft Federal Information Processing Standards Publication 183. s.l. : Department of Commerce, National Institute of Standards and Technology, Computer Systems Laboratory, 1993 December 21
4 Марка Д. и МакГоуэн К.; «Методология Структурного Анализа и Проектирования (SADT)»; (Marca, D.A., and C.L. McGowan. (1988). SADT: structured analysis and design technique. McGraw-Hill Book Co., Inc.: New York.)
5. Евдокиенко В. «Бизнес-процессы, процессное управление и эффективность» [В Интернете]. www.iteam.ru/publications/strategy/ section_18/article_1681
6. Королёв В.А., Стариков Н.П., «Системно-процессное моделирование -ключ к качественному менеджменту», Доклад на 5-й Международной конфе-рен-ции «Теория и практика внедрения современных систем менеджмента» (Украина, г. Одесса, 30.03-01.04.2005 г.)
7. Harmon P., The Scope and Evolution of Business Process Management, Handbook on Business Process Management 1, Introduction, Methods, and Information Systems, Editors vom Brocke J., Rosemann M., Springer-Verlag Berlin Heidelberg 2010
8. Charles T. Betz; «ITIL®, COBIT®, and CMMI®:Ongoing Confusion of Process and Function», BPTrends October 2011; http://www.bptrends.com/ publicationfiles/10-04-2011-ART-
Betz-Final.pdf
9. Alec Sharp and Patrick McDermott; «Workflow Modeling—Tools for Process Improvement and Application Development», Artech House 2001
10. Хармон П. «Processes vs. Projects», BPTrends v 8, Nr 14, July 2010; [Online] http://www.bptrends.com/ publicationfiles/advisor20100727.pdf
11. Марка Д. и МакГоуэн К.; «Методология Структурного Анализа и Проекти-рования (SADT)»; (Marca, D.A., and C.L. McGowan. (1988). SADT: structured analysis and design technique. McGraw-Hill Book Co., Inc.: New York, NY)
12. Reader's Guide to IDEF0 Function Models. Accessed 27 Nov 2008 [Online] http://www.archives.gov/era/pdf/rmsc-19951006-dod-rm-function-and-information-models.pdf
13. Supply-Chain Operations Reference-model;«Overview of SCOR Version 6.0»; Supply- Chain Council, Inc, . Pittsburgh, PA 15238 : s.n. www.supply-chain.org.
14. SCOR v 9 for ARIS; IDS Scheer,
15. Tele Management Forum, «Enhanced Telecom Operations Map® (eTOM) The Business Process Framework For The Information and Communications Services Industry» GB921 вер.7.0.
16. ITU-T Recommendation M.3050.3; «eTOM -Representative process flows»; TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU;
17. Owen, J. Business Function Modelling eBook. John Owen's Integrated Modelling Method . [Online] http://integrated-modeling-method.com/ imm-bpm-business-process-modeling-store/business-function-modeling-ebook/.
18. van der Weel, H. «Will BPMN completely replace EPC?», BrainStormCentral [Online] http:// brainstorm.leveragesoftware.com/ group_discussion.aspx?DiscussionID= 546330866b9549508e7c9b49e3e00b3b
19. Фёдоров И. Г. «Как не асфальтировать коровьи тропы, Методика раскрытия процесса сверху вниз», Сборник МЭСИ
20. Фёдоров И. Г. «О функциональном и процессном моделировании бизнес-процессов», Открытые системы, № 8, 2011, http://www.osp.ru/os/2011/08/ 13011140/
21. Словарь Merriam-Webster Online, www.merriam-webster.com
References
1. Hammer M. What is Business Pro-
cess Management? Handbook on Business Process Management 1, Introduction, Methods, and Information Systems, Editors vom Brocke J., Rosemann M., Springer-Verlag Berlin Heidelberg 2010
2. Telnov Yu.F. "Reengineering of business processes," Finance and Statistics, 2005.
3. Draft Federal Information Processing Standards Publication 183. s.l. : Department of Commerce, National Institute of Standards and Technology, Computer Systems Laboratory, 1993 December 21
4. Marca, D.A., and C.L. McGowan. (1988). SADT: structured analysis and design technique. McGraw-Hill Book Co., Inc.: New York.)
5. Evdokienko V. "Business processes, process management and the effectiveness of' [On the Internet].
www.iteam.ru/publications/strategy/ section_18/article_1681
6. Korolev V.A., Starikov N.P., "System-Process modeling - the key to quality management", Paper presented at the 5th International Conference, Feren-tion, "Theory and practice of implementation of modern systems of manage-ment" (Ukraine, Mr. . Odessa, city 30.0301.04.2005)
7. Harmon P., The Scope and Evolution of Business Process Management, Handbook on Business Process Management 1, Introduction, Methods, and Information Systems, Editors vom Brocke J., Rosemann M., Springer-Verlag Berlin Heidelberg 2010
8. Charles T. Betz; «ITIL®, COBIT®, and CMMI®:Ongoing Confusion of Process and Function», BPTrends October 2011; http://www.bptrends.com/publica-tionfiles/1 0-04-20 1 1 - ART-Ongoing%20Confusion%20of% 20Process%20and%20Function-Betz-Final.pdf
9. Alec Sharp and Patrick McDermott; «Workflow Modeling—Tools for Process Improvement and Application Development», Artech House 2001
10. Harmon P.«Processes vs. Projects», BPTrends v 8, Nr 14, July 2010; [Online] http://www.bptrends.com/pub-licationfiles/advisor20100727.pdf
11. Marca, D.A., and C.L. McGowan. (1988). SADT: structured analysis and design technique. McGraw-Hill Book Co., Inc.: New York, NY.)
12. Reader's Guide to IDEF0 Function Models. Accessed 27 Nov 2008 [Online] http://www.archives.gov/era/pdf/ rmsc-19951006-dod-rm-function-and-in-
formation-models.pdf
13. Supply-Chain Operations Refer-ence-model;«Overview of SCOR Version 6.0»; Supply- Chain Council, Inc, . Pittsburgh, PA 15238 : s.n. www.supply-chain.org.
14. SCOR v 9 for ARIS; IDS Scheer,
15. Tele Management Forum, «En-hanced Telecom Operations Map® (eTOM) The Business Process Framework For The Information and Communications Services Industry» GB921 Bep.7.0.
16. ITU-T Recommendation M.3050.3; «eTOM -Representative process flows»; TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU;
17. Owen, J. Business Function Modelling eBook. John Owen's Integrated Modelling Method . [Online] http://inte-grated-modeling-method.com/imm-bpm-business-process-modeling-store/busi-ness-function-modeling-ebook/.
18. van der Weel, H. «Will BPMN completely replace EPC?», BrainStorm-Central [Online] http://
brainstorm.leveragesoftware.com/ group_discussion.aspx?DiscussionID= 546330866b9549508e7c9b49e3e00b3b
19. Fedorov I.G. "How not to asphalt cow trails, Method drop-ment of the process from top to bottom," Collection of MESI
20. Fedorov I.G. "On the functional and process-modeling business processes," Open systems, № 8, 2011, http:/ /www.osp.ru/os/2011/08/13011140/
21. Dictionary Merriam-Webster Online, www.merriam-webster.com
