Цели моделирования. Средства (инструменты) моделирования (сравнительный анализ). Классификация моделей.

Тема 6. Моделирование логистических бизнес-процессов как способ визуализации координационных механизмов.

1. Цели моделирования. Средства (инструменты) моделирования (сравнительный анализ). Классификация моделей.

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

 

Цели моделирования. Средства (инструменты) моделирования (сравнительный анализ). Классификация моделей.

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

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

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

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

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

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

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

Для принятия решения, модель должна отражать сущность проблемы, давая обоснование, по словам А.Эйнштейна, “…по возможности очень простое, но не проще”. Полное отражение всех реальных зависимостей в модели невозможно или экономически неоправданно.

Как сказал основатель подхода тотального качества Э. Деминг: “Все модели неправильны, но некоторые модели полезны”. Полезными модели становятся тогда, когда при их построении выполняются на практике несколько методических правил.

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

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

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

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

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

Основными средствами и методами моделирования логистических и производственных процессов в настоящее время являются:

· SCOR (Supply Chain Operation Reference-Model),

· ARIS (Architecture of Information Systems),

· UML (Unified Modeling Language),

· IDEF (Integration Definition for Function Modeling).

Они обладают различными возможностями и предназначением.

Разработка концепции ARIS началась в середине 80-х годов в Институте экономической информатики в университете Саарбрюкен (Германия) под руководством профессора А. В. Шеера. С момента опубликования первого издания «Architektur inlegrierter Informationssysteme — ARIS» в 1991 году идея документирования бизнес-процессов с помощью стандартных программных продуктов на основе разработки их моделей вызвала большой интерес у практиков.

Созданная А. В. Шеером методология ARIS, использующая принципы оптимизации организационных изменений в рамках BPR (реинжиниринга бизнес-процессов), сохранения базы знаний организации, использования документации процессов для сертификации по ISO 9000 и определения их затрат, а также применения моделей для внедрения новых ИТ, нашла широкий отклик и поддержку множества предприятий.

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

Архитектура методологии ARIS представляет четыре типа моделей, отражающих различные аспекты исследуемой системы:•

· организационные модели, представляющие структуру системы (иерархию организационных подразделений, должностей и конкретных лиц, многообразие связей между ними и их территориальное размещение);•

· функциональные модели (иерархия целей с совокупностью не* обходимых для их достижения «деревьев» функций);•

· информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы;•

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

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

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

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

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

В настоящий момент к семейству IDEF можно отнести стандарты:•

· IDEF0 (методология функционального моделирования);•

· IDEF1 (методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи);•

· IDEF1X (методология построения реляционных структур и баз данных);•

· IDEF2 (методология динамического моделирования развития систем, построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets)),•

· IDEF3 (методология докуменіирования процессов, происходящих Б системе, которая используется, например, при исследовании технологических процессов на предприятиях);•

· IDEF4 (методология построения объект но-ориеитированных систем);•

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

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

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

· управление (например, технологический план), •

· вход (полуфабрикат); •

· выход (готовый продукт); •

· механизм (цех, рабочий).

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

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

Этим достигается структурная целостность модели IDEF0.

Другим подходом к моделированию логистических и производственных процессов явилась разработка в середине 90-х годов методологии UML (Unified Modeling Language). Основателями данного подхода принято считать Д. Румбаха, И. Якобсона, Г. Буча. Разработка языка UML началась в компании Rational в 1995 году с объединения методов G. Booch и развивавшейся в то время техники ОМТ (Object Modeling Technique). Процесс разработки было решено сделать общедоступным. В1997 году созданная общими усилиями многих компаний спецификация языка была принята группой OMG (рабочей группой по развитию стандартов объектного программирования).

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

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

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

SCOR-модель

Если рассмотренные выше методологии являются общими методами моделирования процессов, то модель SCOR была специально разработана для реализации SCM (управление логистическими цепями). Это было вызвано необходимостью создания методики моделирования SCM и одинакового понимания лежащих в основе этого метода процессов с последующей их оценкой. Создание стандартизированной модели процессов было инициировано Советом по цепям поставок (Supply Chain Council — SCC). SCC является инициативным объединением, которое было создано в 1996 году в США п насчитывает более 800 предприятий-участников. В 2005 году был создан Национальный совет по цепям поставок в Москве, являющийся членом Европейского совета по цепям поставок.

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

Модель SCOR имеет трехуровневую структуру. В модели первого уровня принципиально различаются следующие основные виды деятельности и процессы:•

· планы (все подготовительные виды деятельности но процессу, определение ресурсов, объединение требований служб снабжения, производства и размещения, планирование использования мощностей вплоть до распределения заказов);•

· снабжение (описание процессов приобретения, получения, проверки и предоставления поступающих материалов); •

· производство (все производственные процессы);•

· поставка (определение спроса, управление заказами и процесс сбыта, включая управление складами и транспортом).

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

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

К недостаткам SCOR следует oтнести прежде всего•

· ее ориентированность как объекта моделирования на отдельное предприятие, а не на ЛЦ,•

· ограничение моделирования процессов планирования и организации (отсутствие фаз контроля и изменений),•

· рассмотрение главным образом лишь транспортно-логистиче- ской составляющей ЛЦ (отсутствие процессов конструкторско- технологической подготовки работ и послепроизводственных стадий эксплуатации и сервиса)

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