Моделирование бизнес-процессов

Модель SCOR была специально разработана для реализации управления цепями поставок.

Целью совета SCC является разработка и техническое описание стандартных моделей процессов (SCOR: Supply Chain Operation Reference) и обмен информацией между предприятиями, включенными в цепь поставок. С помощью SCOR-моделей должны быть созданы единые, сравнимые и приспособленные для оценки модели процессов внутри цепи поставок. SCOR описывает процессы управления цепочками поставок и сравнивает их с данными бенч-маркинга (сравнение с эталоном) и функциями программного обеспечения. В качестве вспомогательного средства SCOR располагает инструкциями, стандартизированной терминологией и общими показателями для проведения бенч-маркинга цепей поставок.

Планирование

Планирование

Поставщики Поставщик

внутренний или внешний

Изготовитель

внутренний или внешний

Рис. 10.1. Макроуровень SCOR-модели

Модель SCOR имеет трехуровневую структуру. В модели первого уровня принципиально различаются следующие основные виды деятельности и процессы: планы (все подготовительные виды деятельности по процессу, определение^ёсурсов, объединение требований служб снабжения, производства и размещение, планирование использования мощностей вплоть до распределения заказов), снабжение (описание процессов приобретения, получения, проверки и предоставления поступающих материалов), производство (все производственные процессы, начиная с требований на сырье и его получение, само производство вплоть до монтажа и упаковки), поставка (определение спроса, управление заказами и процесс сбыта, включая управление складами и транспортом) и обратные потоки[23] (return).

Эти основные процессы описываются более детально на следующих уровнях. Так, на втором уровне происходит дифференциация по 30 категориям «типовых» процессов, которые затем на третьем уровне конфигурируются с помощью элементов процесса с учетом отраслевых стандартных рекомендаций.

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

SCOR является описательной моделью, которая позволяет предприятию осуществить структурированный вход в проект создания цепи поставок (уровень 1), смоделировать настоящие и будущие цепи поставок на уровне бизнес-процессов и обеспечить сравнение каждого их элемента с данными бенч-маркинга (уровни 2/3), а также подготовить основу для реализации процессов с помощью конкретных ИТ.

Рис. 10.2. Уровни представления процессов в SCOR-модели

В SCOR-модели выделяют 5 макро-групп бизнес-процессов: type="disc"> Р - планирование S - получение материалов М - изготовление D - поставки DR - возвратные поставки

В каждой из этих групп происходит декомпозиция бизнес-процессов (см. рис. 10.3). К основным группам бизнес-процессов в SCOR относятся: Р1 - Планирование цепи поставок

4 Р2 - Планирование получения материалов •: РЗ - Планирование изготовления Р4 - Планирование поставок

Р5 - Планирование возвратных потоков (рекламации товаров, утилизация продукции) ЕР - Запуск плана в работу

S1 - Получение материалов для складирования S2 - Получение материалов по схеме «изготовления на заказ» S3 - Получение материалов по схеме «конструирования на заказ» ES - Запуск процесса получения материалов Ml - Изготовление на склад М2 - Изготовление на заказ М3 - Изготовление по конструированию на заказ ЕМ - Запуск процессов производства D1 - Поставка продукции на склад D2 - Поставка продукции на заказ D3 - Поставка продукции по конструированию на заказ

D4 - Поставка в розничную торговлю ED - Запуск поставок DR1 - Возвратная поставка бракованной продукции DR2 - Возвратная поставка гарантийной продукции DR3 - Возвратная поставка избыточной продукции ER - Запуск процессов возвратных поставок

Эти процессы далее описываются более детально на третьем уровне.

(Процесс-клиент) Потребности клиентов (D1.3) Объем заказов в работе (D1.11, D2.11, D3.11) Транспортировка (ЕР.З) Данные для планирования (ЕР.9) Агрегированные прогнозы спроса и бизнес-планы

План цепи поставок (Р2.1, Р3.1, Р.4) (процесс-клиент)

(Р2.4) Планы получения материалов (Р3.4) Планы изготовления продукции (Р4.4) Планы поставок продукции (ЕР.З) Данные планирования

(ЕР.5, ЕР6) Внешние и внутренние производственные мощности

(ЕР.5, ЕР6) План использования капитала

(ЕР.5, ЕР6) План аутсорсинга

(ЕР.8) Требования регламентов

(процесс-клиент) Запасы

Рис. 10.4. Пример описания процесса «Планирование цепи поставок» в SCOR [SCOR 7.0]

Основная ценность SCOR с точки зрения моделирования бизнес- процессов заключается в наличии стандартизированных бизнес-

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

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

Разработка концепции ARIS началась в середине 80-х гг. в Институте экономической информатики в университете г. Саарбрюкен (Германия) под руководством профессора A.-W. Scheer [137, 138]. С момента опубликования первого издания «Architektur integrierter Informationssysteme - ARIS» в 1991 г. идея документирования бизнес-процессов с помощью стандартных программных продуктов на основе разработки их моделей нашла широкое применение на практике.

Успешное развитие ARIS было во многом обусловлено широко распространенным в тот период идеям построения организации на принципах реинжениринга бизнес-процессов. На их основе разработанная А,- W. Scheer методология моделирования бизнес-процессов, основанная на идеях оптимизации организационных изменений в рамках BPR, сохранения базы знаний организации, использования документации процессов для сертификации по ISO 9000, определения затрат процессов и использования моделей для внедрения новых ИТ нашла широкий отклик и поддержку множества предприятий.

Во многом это было связано с сотрудничеством A.-W. Scheer с SAP/R3. Ему удалось убедить руководство SAP, что внедрение и экс

плуатация такой многофункциональной системы, как R3 требует надлежащей поддержки со стороны предпроектного моделирования процессов. Такая поддержка была реализована с помощью набора модулей ARIS for R/3, с помощью которых реализуется документирование и анализ результатов проекта. Начало использования ARIS в проектах SAP во многом определило дальнейшее развитие и повышение значимости методологий моделирования процессов.

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

Рис. 10.5. Взаимосвязь типов моделей, используемых в ARIS-архитектуре

[137,138]

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

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

В концепции ARIS был впервые сформулирован системный подход к предпроектной стадии внедрения ИТ на основе моделирования бизнес- процессов, ориентированного на их стандартизацию, документирование и улучшение. Реализация данного подхода нашла отражение в виде разработки специальных приложений, обеспечивающих автоматизацию моделирования бизнес-процессов, возможности их анализа, контроля и корректировки. IDEF (Integration Definition for Function Modeling - интегрированное функциональное моделирование)

Другим подходом к решению задач комплексного обследования предприятий и моделирования сложных систем явилась разработка стандартов и методологии семейства IDEF, позволяющих эффективно отображать и анализировать модели деятельности подобных систем [117, 118, 272]. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными.

К семейству IDEF можно отнести стандарты IDEF0 (методология функционального моделирования), IDEF1 (методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи), IDEF1X (методология построения реляционных структур и баз данных), IDEF2 (методология динамического моделирования развития систем, построенные на базе «раскрашенных сетей Петри» (CPN - Color Petri Nets); IDEF3 (методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях), IDEF4 (методология построения объектно

ориентированных систем и IDEF5 (методология онтологического исследования сложных систем).

Наиболее часто на практике используется методология функционального моделирования IDEF0, в основе которого лежат понятия функционального блока (Activity Box), интерфейсной дуги (Arrow), декомпозиция (Decomposition) и глоссария (Glossary). Функциональный блок графически изображается в виде прямоугольника (рис. 10.6) и представляет собой некоторую конкретную функцию в рамках рассматриваемой системы.

Рис. 10.6. Структура функционального блока [117]

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

Интерфейсные дуги (потоки или стрелки) соответствуют элементу системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label) и быть оборотом существительного. В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей». Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0.

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

позиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легкой для восприятия. В процессе декомпозиции функциональный блок подвергается детализации на другой диаграмме. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 - модели. UML (Unified Modeling Language - унифицированный язык моделирования)

Разработка UML (Unified Modeling Language) связана с именами J. Rumbaugh, I. Jacobson и G. Booch [18, 121, 133, 264]. Разработка языка UML началась в компании Rational в 1995 году с объединения методов G. Booch и развивавшейся в то время техники ОМТ (Object Modeling Technique). В 1997 году созданная общими усилиями многих компаний спецификация языка была принята группой OMG (рабочей группой по развитию стандартов объектного программирования).

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

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

системы, переводятся в исходный код 3GL или 4GL языков программирования и разрабатывается база данных системы.

Особенность UML заключается в том, что он оптимизирован для применения при разработке программных систем, что дает возможность максимально ускорить разработку программных продуктов и заметно улучшить качество получаемой системы. Кроме того, объектно- ориентированный подход позволяет легко включать в систему новые объекты и исключать устаревшие без существенного изменения жизнеспособности системы. Стандарт ISO/IEC 15288 «Системная инженерия - Процессы жизненного цикла систем»[24]

Стандарт ISO/IEC 15288 «Системная инженерия - Процессы жизненного цикла систем» официально введен в действие в Российской Федерации с 1.01.06 г. (ГОСТ Р ИСО/МЭК 15288). Требования, изложенные в стандарте, направлены на создание интегрированной среды, единой структуры для совершенствования связей и кооперации между хозяйствующими сторонами. Например, он обеспечивает процессы приобретения (закупки) и поставки системы, включая оценку и совершенствование процессов. Существуют отличия от терминологии, которая «на слуху». ГОСТ Р ИСО/МЭК 15288 классифицирует процессы жизненного цикла систем в составе 4 групп следующим образом: процессы предприятия, процессы соглашения, процессы проекта, технические процессы.

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

ется появление в ближайшем будущем еще 2-х гармонизированных международных стандартов, связанных с управлением услугами: ISO/IEC 20000-1:2005 «Управление услугами. Часть 1. Общие положения и словарь; ISO/IEC 20000-2:2005 «Управление услугами. Часть 2. Практическое руководство».

Для деятельности логистических операторов, любых организаций, предоставляющих услуги, эти международные стандарты будут являться не только полезными, но и стратегически необходимыми. Методология комплексного моделирования бизнес-процессов «КОМПАС»[25]

Главным недостатком рассмотренных выше средств и методов моделирования процессов является то, что они позволяют лишь формализовать описание бизнес-процессов, но не дают возможности для системного формирования функциональных структур и оптимизации бизнес- процессов. Следует также заметить, что внедрение ИТ на отдельном предприятии и создание новой интегрированной информационной среды над уровнем предприятия связаны с различными проблемами и задачами. Поэтому с учетом всех положительных аспектов концепций ARIS, IDEF, UML и SCOR необходима разработка специальной методологии комплексного моделирования процессов при проектировании ЦП.

Методология комплексного моделирования бизнес-процессов «КОМПАС» разработана с целью создания общей логики распознавания и анализа бизнес-процессов сложных производственнологистических систем и обеспечивает получение комплексных моделей этих систем с требуемой степенью детализации.

Суть методологии «КОМПАС» состоит в формировании комплексной модели цепи поставок в виде взаимосвязанных составных частей. Функциональная, организационная и информационная модели составляют базовую модель (БМ), которая для конкретных целей анализа

может быть дополнена другими моделями (регламентная, контроллинга, критериальная) [228,2301.

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

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

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

Триада, образующая базовую модель, является фундаментом построения интегрированной модели цепи поставок. Она позволяет перей-

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

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

Рис. 10.8. Структура и логика построения комплексной модели цепи поставок

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

рактеристики процессов: функции, исполнителей, информационные потоки, регламенты, затраты и критерии эффективности.

Анализ и описание процессов и функциональных структур с помощью рассмотренных выше шести моделей позволяет в полной мере отразить все характеристики процессов: функции, исполнителей, информационные потоки, регламенты, затраты и критерии эффективности. На рис. 10.9. представлена общая схема комплексной модели процесса.

Рис. 10.9. Общая схема комплексной модели процесса
alt="" /> Моделирование цепей поставок начинается с определения общих функций логистики и производства, совокупность которых и назовем функциональной моделью цепи поставок на макроуровне (рис. 10.10).

Рис. 10.11. Организационная модель цепи поставок на макроуровне

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

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

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

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

В заключении рассмотрим два примера. На рис. 10.13 приведен пример карты описания бизнес-процесса «Управление отгрузкой и дистрибьюцией».

Рис. 10.13. Пример карты описания бизнес-процесса «Управление отгрузкой и дистрибьюцией»

На рис. 10.14 приведен 1фимер реинжинирнга бизнес-процесса цепи поставок «Выполнение заказа клиента»

^Полу«Г \ : ^товара              \

/>

Приобретение

материалов

Поставщик

Рис. 10.14. Пример реиижеииринга бизнес-процесса цепи поставок «Выполнение заказа клиента»