Моделирование бизнес процессов транспортно логистической компании

Моделирование бизнес-процесса организации перевозок транспортно-логистической компанией

Моделирование
бизнес-процесса организации перевозок транспортно-логистической компанией

Введение

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

Объектно-ориентированная методология (ООМ) создания автоматизированных
систем состоит из следующих частей:

·              объектно-ориентированный анализ (OOA),

·              объектно-ориентированное проектирование (OOD),

·              объектно-ориентированное программирование (OOР).

ООА — методология анализа сущностей реального мира на основе понятий
класса и объекта, составляющих словарь предметной области, для понимания и
объяснения того, как они (сущности) взаимодействуют между собой.

ООD — методология проектирования, соединяющая в себе процесс объектной
декомпозиции, опирающийся на выделение классов и объектов, и приемы
представления моделей, отражающих логическую (структура классов и объектов) и
физическую (архитектура моделей и процессов) структуру системы.Р -совокупность
идей и понятий, определяющая стиль написания программ, в которой основными
концепциями являются понятия объектов и классов.

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

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

Основные понятия объектно-ориентированного проектирования: объект, класс,
атрибут, операция, полиморфизм, наследование, компонент, связь.

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

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

Атрибут — поименованное свойство класса, определяющее диапазон допустимых
значений, которые могут принимать экземпляры данного свойства. Атрибуты могут
быть скрыты от других классов, это определяет видимость атрибута: рublic
(общий, открытый); private (закрытый, секретный); protected (защищенный).

Определенное воздействие одного объекта на другой с целью вызвать
соответствующую реакцию называется операцией или посылкой сообщения. Операция —
это реализация услуги, которую можно запросить у любого объекта данного класса.
Операции реализуют связанное с классом поведение, его обязанности. Описание
операции включает четыре части: имя; список параметров; тип возвращаемого
значения; видимость.

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

Компонент — это относительно независимая и замещаемая часть системы,
выполняющая четко определенную функцию в контексте заданной архитектуры. Виды
компонентов: компонент исходного кода; компонент времени выполнения; исполняемый
компонент.

Между элементами объектной модели существуют различные виды связей:

·        ассоциация — это семантическая связь между классами;

·        агрегация — более сильный тип связи между целым и его
частями;

·        зависимость — связь между двумя элементами модели, при
которой изменения в спецификации одного элемента могут повлечь за собой
изменения в другом элементе;

·        обобщение — связь «тип — подтип».

Метод объектно-ориентированного проектирования основывается на:

·        модели построения системы как совокупности объектов
абстрактного типа данных;

·        модульной структуре программ;

·        нисходящем проектировании, используемом при выделении
объектов.

В объектно-ориентированном проектировании выделяют следующие
фундаментальные понятия:

Инкапсуляция.

Концепция сокрытия в как бы «капсуле» всей информации об
объекте, то есть объединение в некое целое данных и процедур (методов) их
обработки. Единицей инкапсуляции в OOD является объект, в котором содержатся и
данные состояния объекта и сообщения, которые объект может обрабатывать. Т.е.
Инкапсуляция означает сочетание структур данных с методами их обработки в
абстрактных типах данных — классах объектов.

Наследование.

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

Полиморфизм.

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

Для различных методик объектно-ориентированного проектирования характерны
следующие черты:

·        объект описывается как модель некоторой сущности реального
мира;

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

Выделено четыре этапа объектно-ориентированного проектирования:

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

·        разработка структуры классов, описывающей связь между
классами и объектами;

·        разработка диаграмм объектов, показывающих взаимосвязи с
другими объектами;

·        разработка внутренней структуры программного продукта.

История развития языка UML берет начало с октября 1994 года, когда Гради
Буч и Джеймс Румбах из Rational Software Corporation начали работу по
унификации методов Booch и ОМТ. Хотя сами по себе эти методы были достаточно
популярны, совместная работа была направлена на изучение всех известных
объектно-ориентированных методов с целью объединения их достоинств. При этом Г.
Буч и Дж. Румбах сосредоточили усилия на полной унификации результатов своей
работы. Проект так называемого унифицированного метода (Unified Method) версии
0.8 был подготовлен и опубликован в октябре 1995 года. Осенью того же года к ним
присоединился А. Джекобсон, главный технолог из компании Objectory AB (Швеция),
с целью интеграции своего метода OOSE с двумя предыдущими.

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

Начиная работу по унификации своих методов, Г. Буч, Дж. Румбах и А.
Джекобсон сформулировали следующие требования к языку моделирования. Он должен:

·              Позволять моделировать не только программное обеспечение, но
и более широкие классы систем и бизнес-приложений, с использованием
объектно-ориентированных понятий.

·              Явным образом обеспечивать взаимосвязь между базовыми
понятиями для моделей концептуального и физического уровней.

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

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

Разработка системы обозначений или нотации для ООАП оказалась непохожей
на разработку нового языка программирования. Во-первых, необходимо было решить
две проблемы:

.        Должна ли данная нотация включать в себя спецификацию требований?

.        Следует ли расширять данную нотацию до уровня языка визуального
программирования?

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

Усилия Г. Буча, Дж. Румбаха и А. Джекобсона привели к появлению первых
документов, содержащих описание собственно языка UML, эти документы послужили
своеобразным катализатором для широкого обсуждения языка UML различными
категориями специалистов. Первые отзывы и реакция на язык UML указывали на
необходимость его дополнения отдельными понятиями и конструкциями.

В это же время стало ясно, что некоторые компании и организации видят в
языке UML линию стратегических интересов для своего бизнеса. Компания Rational
Software вместе с несколькими организациями, изъявившими желание выделить ресурсы
для разработки строгого определения версии 1.0 языка UML, учредила консорциум
партнеров UML, в который первоначально вошли такие компании, как Digital
Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI
Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys. Эти компании
обеспечили поддержку последующей работы по более точному и строгому определению
нотации, что привело к появлению версии 1.0 языка UML. В январе 1997 года был
опубликован документ с описанием языка UML 1.0, как начальный вариант ответа на
запрос предложений RTP. Эта версия языка моделирования была достаточно хорошо
определена, обеспечивала требуемую выразительность и мощность и предполагала
решение широкого класса задач.

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

Из более чем 800 компаний и организаций, входящих в настоящее время в
состав консорциума OMG, особую роль продолжает играть Rational Software
Corporation, которая стояла у истоков разработки языка UML. Эта компания
разработала и выпустила в продажу одно из первых инструментальных CASE-средств
Rational Rose 98, в котором был реализован язык UML.

В январе 1997 года целый ряд других компаний, среди которых были IBM,
ObjecTime, Platinum Technology и некоторые другие, представили на рассмотрение
OMG свои собственные ответы на запрос предложений RFP. В дальнейшем эти
компании присоединились к партнерам UML, предлагая включить в язык UML некоторые
свои идеи. В результате совместной работы с партнерами UML была предложена
пересмотренная версия 1.1 языка UML. Основное внимание при разработке языка UML
1.1 было уделено достижению большей ясности семантики языка по сравнению с UML
1.0, а также учету предложений новых партнеров. Эта версия языка была
представлена на рассмотрение OMG и была одобрена и принята в качестве стандарта
OMG в ноябре 1997 года.

В настоящее время все вопросы дальнейшей разработки языка UML
сконцентрированы в рамках консорциума OMG. Соответствующая группа специалистов
обеспечивает публикацию материалов, содержащих описание последующих версий
языка UML и запросов предложений RFP по его стандартизации. Очередной этап
развития данного языка закончился в марте 1999 года, когда консорциумом OMG
было опубликовано описание языка UML 1.3.

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

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

Унифицированный язык моделирования UML стал основой для целого спектра
различных средств поддержки разработки программного обеспечения — CASE-средств
(Computer-Aided Software Engineering).

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

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

К появлению CASE-технологии способствовали и такие факторы, как:

·              подготовка аналитиков и программистов, восприимчивых к
концепциям модульного и структурного программирования;

·              широкое внедрение и постоянный рост производительности
компьютеров, позволившие использовать эффективные графические средства и
автоматизировать большинство этапов проектирования;

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

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

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

Все современные CASE-средства можно классифицировать по типам и
категориям. Классификация по типам отражает функциональную ориентацию
CASE-средств на те или иные процессы жизненного цикла. Помимо этого
CASE-средства можно классифицировать по категориям, применяемым методологиям и
моделям систем и БД; степени интегрированности с СУБД; доступным платформам.

·              широкое разнообразие качества и возможностей CASE-средств;

·              относительно небольшое время использования CASE-средств в
различных организациях и недостаток опыта их применения;

·              широкое разнообразие в практике внедрения различных
организаций;

·              отсутствие детальных метрик и данных для уже выполненных и
текущих проектов;

·              широкий диапазон предметных областей проектов;

·              различная степень интеграции CASE-средств в различных
проектах.

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

Но все же грамотное, продуманное и обоснованное использование
CASE-технологии способно принести следующие выгоды:

·              высокий уровень технологической поддержки процессов разработки
и сопровождения ПО;

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

·              приемлемый уровень отдачи от инвестиций в CASE-средства.

Среди всех фирм-производителей CASE-средств именно компания IBM Rational
Software Corp. (до августа 2003 года — Rational Software Corp.) одна из первых
осознала стратегическую перспективность развития объектно-ориентированных
технологий анализа и проектирования программных систем. Эта компания выступила
инициатором унификации языка визуального моделирования в рамках консорциума
OMG, что, в конечном итоге, привело к появлению первых версий языка UML. И эта
же компания первой разработала инструментальное объектно-ориентированное
CASE-средство, в котором был реализован язык UML как базовая нотация
визуального моделирования.Rose — CASE-средство фирмы Rational Software
Corporation (США) — предназначено для автоматизации этапов анализа и
проектирования ПО, а также для генерации кодов на различных языках и выпуска
проектной документации.Rational Rose — популярное средство визуального
моделирования, которое считается стандартом де-факто среди средств визуального
проектирования приложений. Этот продукт входит в состав пакета IBM Rational
Suite и предназначен для моделирования программных систем с использованием
широкого круга инструментальных средств и платформ. Инструментальное средство
IBM Rational Rose расширяет возможности моделирования программных систем,
выходящих за рамки платформы J2EE и инструментальных средств моделирования в
составе IBM Rational Professional Bundle.

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

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

Достоинства продукта Rational Rose

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

·        удобная навигация между элементами модели при помощи
«инспектора проекта»;

·        хранение результатов проектирования в виде единой модели;

·        поддержка работы над проектом группы разработчиков;

·        данное CASE средство может быть применено для создания
разнообразного объектно-ориентированного программного обеспечения, в первую
очередь для платформы Windows, а так же на языке Java;

·        на всех этапах разработки применяется язык UML, и проект
программного средства представляет собой единую модель;

·        возможность конфигурирования системы с помощью модулей
расширения;

·        в наибольшей степени подходит для разработки крупных
информационных систем, так как реализует большую часть функций ARIS и
ERwin/BPwin. И т.д.

Недостатки продукта Rational Rose

·        слабо реализована поддержка проектирования ПО для других
операционных систем, почти все стандартные рабочие среды ориентированны на
построение Windows-приложений, единственным способом написания приложения для
не-Windows операционной системы является использование языка Java, производительность
которого, пока, оставляет желать лучшего.

·        сложность самого языка UML также накладывает определенные
ограничения на привлечение к работам над проектами непрофессионалов,

·        нельзя показать и удалить неиспользуемые объекты в отличие от
BPWin;

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

·        не поддерживает функционально-стоимостной анализ;

·        нет возможности отобразить потоки данных между объектами или
процессами.

В результате разработки проекта с помощью CASE-средства Rational Rose
формируются следующие документы:

·        диаграммы классов;

·        диаграммы состояний;

·        диаграммы сценариев;

·        диаграммы модулей;

·        диаграммы процессов;

·        спецификации классов, объектов, атрибутов и операций

·        заготовки текстов программ;

·        модель разрабатываемой программной системы.

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

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

1.
Описание предметной области

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

1.      разработка оптимальной транспортно-технологической схемы
перевозки;

.        организация перевозки.

Разработкой транспортно-технологической схемы перевозки занимается
логистический отдел. Этот процесс включает в себя:

·        выбор вида и типа транспортного средства;

·        выбор вида транспортировки;

·        выбор маршрута.

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

·        прием и обработку заявок на перевозку;

·        заключение договоров с клиентами;

·        проведение необходимых бухгалтерских операций;

·        экспедирование перевозки;

·        таможенное оформление.

В данном курсовом проекте рассматривается этап организации перевозок.

2.
Моделирование проектируемой системы

 

.1
Диаграмма вариантов использования

Диаграмма вариантов использования (use case diagram) — диаграмма, на
которой изображаются отношения между актерами и вариантами использования.

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

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

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

Выделен 1 основной вариант использования — «организация перевозки». После
обращения компании-клиента в нашу фирму начинается процесс организации
перевозки. Сначала заключается договор на перевозку, а также оформляется заявка
на перевозку. После чего получается ТЛС. Для начала транспортировки груза
необходимо произвести расчет за перевозку с компанией-перевозчиком, затем
происходит транспортировка груза с экспедиционными услугами, которые
подразумевают под собой прохождение таможни и сбор всех необходимых документов
на пути следования. По окончании перевозки необходимо выставить счет клиенту и
принять оплату.

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

автоматизированный объектный ориентированный логистический

Рисунок 1 — Диаграмма вариантов использования

2.2
Диаграмма классов

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

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

На рисунке 2 представлена диаграмма классов.

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

Рисунок 2 — Диаграмма классов

2.3
Диаграмма последовательности

Является моделью, описывающей поведение взаимодействующих групп объектов.
Охватывает поведение только одного варианта использования.

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

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

2.4 Диаграмма кооперации

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

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

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

На рисунке 4 представлена диаграмма кооперации, которая формируется из
диаграммы последовательности.

2.5
Диаграмма состояний

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

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

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

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

2.6 Диаграмма деятельности

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

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

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

На рис. 6 представлена диаграмма деятельности менеджера. Менеджер
составляет договор на перевозку, а затем отдает его на проверку директору.
После чего договор либо подлежит исправлению и правится менеждером, либо
подлежит подписанию и в этом случае менеджер подписывает договор с клиентом,
затем отдает договор директору для подписания. После этого происходит
оформление заявки на перевозку, а так же дается указание логистическому отделу
на разработку ТЛС. После происходит получение ТЛС и передача ее и заявки
экспедитору.

Заключение

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

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

Список
литературы

1. Конспект лекций ПИС.

2.      Электронный самоучитель Rational Rose 98/2000, Леоненков.

Введение

Ключевая роль
организационно-управленческой функции в современных организациях и компаниях в
большинстве случаев отводится моделированию бизнес-процессов [1] (Nagibina, Mylnikova, 2013). Бизнес-процессы не только
структурируют и регламентируют действия всех завязанных в них контрагентов, но
и очерчивают границы коллаборационных процессов; определяют трудоемкость
выполняемых операций и действий; распределяют зоны ответственности на исполнителя
и владельца того или иного бизнес-процесса или этапа в графической
декомпозиции. В настоящее время весьма актуальным становится вопрос о развитии
бизнес-моделирования, в том числе и в логистической сфере. Эффективное
партнерство бизнес-моделирования и логистической сферы позволяет завоевать
компании, имеющей какое-либо отношение к области логистики, лидирующие позиции на
рынке [2] (Drobot,
Vartanova, 2019).

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

Объектом в проведенном
исследовании выступает транспортно-экспедиционная компания (далее – ТЭК), а предметом
исследования является логистическая инфраструктура ТЭК.

Научная новизна данной публикации
и авторский вклад в работу заключаются в следующем:

— разработка методологии
функционального моделирования логистического бизнес-процесса на примере ТЭК (в
частности, проработка основных блоков типового бизнес-процесса);

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

— оптимизация предлагаемого бизнес-процесса
с учетом введенного тайм-менеджмента включением ответственных лиц и исполнителей
по каждой операции и/или функции;

— разработка типового бизнес-процесса
ТЭК по работе с клиентами, направленного на доставку груза из пункта
отправления до места назначения.

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

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

В современной
отечественной научно-исследовательской литературе тема, представленная авторами
работы, весьма актуальна и значима, труды ученых носят в основном теоретический
характер [3] (Egorov,
Polivanov, 2020).
Стоит отметить лишь ряд исследователей, которые представили схемы
бизнес-процессов по улучшению логистической инфраструктуры. Н.Б. Завьялова и М.
Сухова при помощи нотации IDEF0 изучили шесть этапов обобщенного вида смешанных
перевозок [4] (Zavyalova,
Sukhova, 2012). Ю.М.
Винтер предложил три типовые формулы по расчету показателей оценки процессов
логистики [5] (Vinter,
Monakhov, 2017).
В.М. Литвиненко приводит в публикации единый цикл управления бизнес-процессами,
где стратегия, финансы, маркетинг, персонал, активы, экология и т.д. выступают
основными элементами [6] (Litvinenko, 2018). М.В. Ботнарюк и М.И. Классовская изучили систему управления,
учитывающую цифровую трансформацию деловой логистической среды [7] (Botnaryuk, Klassovskaya, 2020). А.А. Хачатурян, Н.А. Солдатенко и
др. раскрыли графическую нотацию ЕРС, предназначенную для формализации и
описания бизнес-процесса по проектированию и производству авиационных
двигателей АО «Редуктор-ПМ» [8] (Khachaturyan, 2021). Полемический обзор показал, что разработкой
предварительного плана и типового бизнес-процесса по доставке товара ТЭК в
российском научном сообществе занимались относительно трансцендентально,
конкретных методологических основ не проводилось, что послужило основой для
проведения данной научно-исследовательской работы.

Моделирование
бизнес-процесса деятельности ТЭК по доставке товаров клиентам

Подготовительный этап по разработке графической модели
любого бизнес-процесса должен начинаться с анализа нормативно-правовых основ
деятельности предметно-объектного состава исследования. Кроме того, необходимо
составить детальную схему информационных потоков для обеспечения безопасности
выполняемых функций и обязанностей [9] (Melnikova, Mylnikova, Moskvitina, Nagibina, 2021). Операции в области
транспортно-экспедиционных услуг регламентируются следующими
нормативно-правовыми актами:

— ФЗ-87 от 30.06.2003 г. (редакция
от 18.03.2020 г.), рассказывающий о сущности транспортно-экспедиционной
деятельности в целом;

— Постановление Правительства РФ от
08.09.2006 г. № 554, направленное на утверждение правил осуществления транспортно-экспедиционной
деятельности;

— ГК РФ (вторая часть) от 26.01.1996 г.
№ 14-ФЗ (редакция от 27.12.2019 г., изменения от 28.04.2020 г.) статья
801, раскрывающая основные пункты договора транспортной экспедиции;

— ФЗ-184 от 27.12.2002 г.,
повествующий о техническом регулировании;

— ФЗ-259 от 08.11.2007 г. (редакция
от 24.02.2021 г.), представленный в формате устава автомобильного
транспорта и городского наземного электрического транспорта [10].

Узкоспециализированная
(частная, конкретная [11] (Chabanova, Kudrin, Bartova, 2021)) цель разрабатываемого бизнес-процесса – доставить товар
клиента ТЭК из пункта отправления в место назначения.

Для перехода к основной
части – моделированию бизнес-процесса по доставке товара клиентам ТЭК –
необходимо выделить основные блоки типовой модели графической композиции (рис. 1),
которые далее (на рис. 2) будут представлены в желтых многоугольниках.
Именно для адаптации рассматриваемой нотации ЕРС к графическому моделированию в
системе IDEF0 – основные блоки будут являться структурирующими и записаны как
А1, А2,…, Аn с последующей фокусировкой на составные операции и функции [12] (Belova, 2018).

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

Заключительным этапом в данной научной работе выступает смоделированный
бизнес-процесс по доставке товара клиенту ТЭК в нотации Event-Driven Process
Chain (далее – ЕРС), что наглядно представлено на рисунке 2.

Рисунок 1. Структура бизнес-процесса ТЭК по
доставке товара из пункта отправления до места назначения

Источник: составлено авторами.

Рисунок 2. Моделирование бизнес-процесса
деятельности ТЭК по доставке товара клиентам

Источник: составлено авторами.

Заключение

В эпоху XXI века в России очень остро встает
вопрос об эффективной логистической инфраструктуре как экспедиционных компаний
в частности, так и смарт-городов в целом [13] (Yakupova, Mylnikova, Nagibina, 2019). Оптимизировать и структурировать
все логистические функции можно при помощи такого инструмента, как
бизнес-моделирование, который наряду с транспортно-логистической
инфраструктурой на сегодняшний день является актуальным для изучения мировым
научным сообществом [14].

В процессе работы над публикацией
авторами выявлено, что основными детерминантами и причинами нерационального использования
временного ресурса ТЭК, а впоследствии и возникновения определенных потерь,
являются следующие факторы:

— неструктурированный способ
консьюмеризма с клиентами;

— неэффективно выстроенные деловые и
информационные каналы связи между внутренними и внешними контрагентами;

— несоответствующий способ приема
товаров.

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

Итак, предложенный авторами
настоящей публикации типовой бизнес-процесс может оказаться весьма
востребованным как управляющими ТЭК, так и клиентами, которые планируют воспользоваться
услугами логистических компаний по доставке товаров, а также тем, кто хочет «попробовать
себя» в данном направлении бизнеса [15] (Indan, 2019).

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

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

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

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

Этапы описания бизнес-процессов:

1.
Определение целей описания.

2.
Описание окружения, определение входов
и выходов бизнес-процесса, построение
IDEF0-диаграмм.

3.
Описание функциональной структуры
(действия процесса), построение
IDEF3-диаграмм.

4.
Описание потоков (материальных,
информационных, финансовых) процесса,
построение DFD-диаграмм.

5.
Построение организационной структуры
процесса (отделы, участники, ответственные).

Моделирование бизнес-процессов организации включает два этапа структурное и детальное:

1.
Структурное моделирование бизнес-процессов
организации может выполняться в нотации
IDEF0 с использованием инструментария
BPwin или на языке UML с использованием
инструментария Rational Rose. Детальное
моделирование выполняется на языке
UML.

На этапе структурного моделирования в модели должны быть отражены:

—
существующая организационная структура;

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

—
структуру бизнес-процессов, отражающую
их иерархию от более общих групп к
частным бизнес-процессам;

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

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

Детальная модель бизнес-процесса должна включать:

—
набор прецедентов отражающих возможные
варианты выполнения бизнес-процессов
«как есть»;

—
диаграммы действий, детально описывающие
последовательность выполнения
бизнес-процессов;

—
диаграммы взаимодействия, отражающие
схемы документооборота.

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

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

–
теоретическая
база; – описание шагов, необходимых
для получения заданного результата;

–
рекомендации
по использованию как отдельно, так и в
составе группы методик.

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

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

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

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

Реинжиниринг
бизнес-процессов
(англ. Business process reengineering) — это фундаментальное
переосмысление и радикальное
перепроектирование бизнес-процессов
для достижения максимальной эффективности
производственно-хозяйственной и
финансово-экономической деятельности,
оформленное соответствующими
организационно-распорядительными и
нормативными документами. Бизнес-инжиниринг
состоит из моделирования бизнес-процессов
(разработка модели «как есть», её
анализ, разработка модели «как надо»)
и разработки и реализации плана перехода
к состоянию «как надо».

Решения
по моделированию бизнес-процессов
обычно принимается по причинам:

Моделирование
бизнес-процессов затрагивает многие
аспекты деятельности компании:

—
изменение организационной структуры;
— оптимизацию функций подразделений и
сотрудников; — перераспределение прав
и обязанностей руководителей; — изменение
внутренних нормативных документов и
технологии проведения операций; — новые
требования к автоматизации выполняемых
процессов и т. д.

История
развития методологий моделирования
бизнес-процессов

Основные
типы методологий моделирования и анализа
бизнес-процессов

Основу
многих современных методологий
моделирования бизнес-процессов составили
методология SADT
(Structured
Analysis
and
Design
Technique
– метод структурного анализа и
проектирования), семейство стандартов
IDEF
(Icam
DEFinition,
где Icam
— это Integrated
Computer-Aided
Manufacturing)
и алгоритмические языки.

Основные
типы методологий моделирования и анализа
бизнес-процессов:

1.
Моделирование бизнес-процессов (Business
Process Modeling).
Наиболее широко используемая методология
описания бизнес-процессов – стандарт
IDEF0.
Модели в нотации IDEF0 предназначены для
высокоуровневого описания бизнеса
компании в функциональном
аспекте.

2.
Описание потоков работ (Work
Flow Modeling).
Стандарт IDEF3
предназначен для описания рабочих
процессов
и близок к алгоритмическим методам
построения блок-схем.

3.
Описание потоков данных (Data
Flow Modeling).
Нотация DFD
(Data Flow
Diagramming),
позволяет отразить последовательность
работ, выполняемых по ходу процесса, и
потоки
информации,
циркулирующие между этими работами.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

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

1) Бизнес процесс: «Выполнение автотранспортных перевозок»;

2) Бизнес процесс: «Выполнение складских операций».

В свою очередь, бизнес процесс «Выполнение автотранспортных перевозок» включает в себя работы по доставке на предприятие закупленных ТМЦ и выполнение доставки готовой продукции клиентам предприятия.

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

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

Проблемы типичной системы управления логистикой

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

1) Не оптимальная загрузка автотранспорта;

2) Простои транспортных средств;

3) Дефицит складских площадей;

4) Дефицит автомобилей для выполнения перевозок;

5) Замораживание оборотных средств предприятия в запасах;

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

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

Бизнес процессы эталонной системы управления логистикой

Эталонная система управления логистикой предприятия содержит следующие бизнес процессы:

1. «Моделирование логистической системы предприятия»;

2. «Определение правил пополнения запасов и норм»;

3. «Контроль остатков запасов ТМЦ на складах»;

4. «Оперативное планирование логистических операций»;

5. «Диспетчеризация логистических операций»;

6. «Мониторинг и контроль системы управления логистикой».

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

Бизнес процесс «Моделирование логистической системы предприятия».

В рамках этого бизнес процесса необходимо выполнять следующие виды работ:

1) Прогнозирование направлений и будущих объемов автотранспортных перевозок;

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

3) Составление перечня ТМЦ, подлежащих транспортировке и хранению на складах;

4) Определение требований к транспортировке ТМЦ. Например:

5) Определение наиболее оптимальных способов доставки грузов;

6) Определение требований к транспортным средствам, а именно:

7) Определение требований к складам:

Подготовка детального описания бизнес процессов автотранспортных перевозок и складских операций. О том, как выполнить описание бизнес процессов Вы можете прочитать в нашей статье «Описание бизнес-процессов. Алгоритм»

9) Расчет себестоимости логистических операций;

10) Расчет показателей эффективности использования техники и оборудования.

В качестве такого показателя можно использовать показатель «Общая эффективность использования техники и оборудования» или ОЕЕ (от англ. overall equipment effectiveness).

11) Выполнение сравнительного анализа стоимости выполнения логистических операций силами Компании и силами подрядчиков и выбор наиболее эффективного способа выполнения логистических операций.

Бизнес-процесс «Установка правил пополнения запасов и норм».

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

Указанные проблемы возникают потому, что закупщики перед закупкой не проводят контроль остатков ТМЦ на складе и не анализируют то, как часто закупаемые ТМЦ используются в деятельности предприятия.

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

Каким образом провести категоризацию запасов?

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

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

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

С применением данных показателей, все запасы предприятия можно разделить на три категории:

1. Запасы категории А;

2. Запасы категории B;

3. Запасы категории C;

К категории А относятся запасы, процент стоимости которых составляет 70% в общей стоимости запасов, закупаемых предприятием, и которые составляют 20 – 25 % от общего количества номенклатурных позиций, используемых предприятием в своей деятельности.

К категории B относятся запасы, процент стоимости которых составляет 20 – 25 % в общей стоимости запасов, закупаемых предприятием, и которые составляют 20 – 25 % от общего количества номенклатурных позиций, используемых предприятием в своей деятельности.

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

После проведения категоризации запасов к каждой категории необходимо применить правила пополнения.

Существуют 3 правила пополнения запасов.

Первое правило: Пополнение запасов по потребности.

При применении этого правила пополнение запасов необходимых номенклатур осуществляется только при возникновении потребности в ТМЦ, и только в том количестве, которое необходимо.

Целью применения данного правила является минимизация запасов. Правило пополнения запасов по потребности применяется для приоритетных, самых дорогих номенклатур категории А.

Второе правило: Пополнение запасов по статистической точке заказа.

При применении этого правила пополнение запасов необходимых номенклатур осуществляется только тогда, когда уровень запасов достигает определенного уровня в натуральном измерении.

Цель применения данного правила — поддержание определенного уровня запасов на складе.

Правило применяется при относительно стабильном и прогнозируемом спросе на определенную номенклатуру и используется для номенклатурных позиций категории А (в некоторых случаях) и В (чаще всего).

Третье правило: Пополнение по календарной точке заказа.

Суть правила заключается в осуществлении дозаказа ТМЦ до максимального уровня необходимых номенклатур с установленной периодичностью.

Цель применения данного правила — поддержание уровня запасов при минимальном контроле.

Потребность в номенклатурных позициях определяется на основе проверки имеющихся запасов на определенную дату. Правило применяется для пополнения относительно недорогих номенклатур категории В (в некоторых случаях) и категории С.

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

В зависимости от типа запаса это может быть:

Для ТМЦ, которые закупаются разово или потребляются время от времени, устанавливается норматив пролеживания на складе.

Для ТМЦ, пополнение запасов которых, осуществляется периодически, по календарной точке заказа, необходимо определить периодичность мониторинга уровня запасов.

Бизнес процесс «Оперативное планирование логистических операций».

Для устранения проблем дефицита складских мощностей и автотранспортных средств на предприятии необходимо внедрить процесс «Оперативное планирование логистических операций».

В рамках бизнес процесса «Оперативное планирование логистических операций» необходимо выполнять следующие виды работ:

1) сбор и консолидация информации о потребности структурных подразделений предприятия в автотранспортных перевозках и складских операциях;

2) проверка достаточности ресурсов для обеспечения потребности;

3) формирование оперативных планов выполнения логистических операций на период до 3 месяцев.

Бизнес процесс «Диспетчеризация логистических операций»

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

Бизнес-процесс «Мониторинг и контроль системы управления логистикой»

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

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

Например, необходимо контролировать маршруты движения автотранспортных средств, расход топлива, и соответствие порядка выполнения складских операций утвержденным инструкциям.

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

Надеемся, что приведенная в статье информация поможет Вам построить эффективную систему управления логистикой на вашем предприятии.

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

На рисунке 1 представлена диаграмма вариантов использования бизнес-процесса организации перевозок.На сегодняшний день рынок насыщен транспортно-логистическими компаниями.После обращения компании-клиента в нашу фирму начинается процесс организации перевозки.Разработкой транспортно-технологической схемы перевозки занимается логистический отдел.В данном курсовом проекте рассматривается этап организации перевозок.Среди всех фирм-производителей CASE-средств именно компания IBM Rational Software Corp.Инструмент полностью поддерживает компонентно-ориентированный процесс создания ИС.Выделен 1 основной вариант использования — «организация перевозки».На рисунке 3 представлена диаграмма последовательности действий организации перевозки.Затем оформляется заявка на перевозку путем взаимодействия компании-клиента с менеджером.

Скачать Моделирование бизнес-процесса организации перевозок транспортно-логистической компанией

Скачать документ

(Если ссылка на скачивание файла не доступна — дайте нам знать об этом в комментариях либо через форму обратной связи)

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

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

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

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

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

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

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

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

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

Проанализируем модельные, функциональные, технологические характеристики CASE-систем.

CASE-средство Rational Rose

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

Достоинства продукта Rational Rose:

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

• удобная навигация между элементами модели при помощи «инспектора проекта»;

• хранение результатов проектирования в виде единой модели;

• поддержка работы над проектом группы разработчиков;

• данное CASE средство может быть применено для создания разнообразного объектно-ориентированного программного обеспечения, в первую очередь для платформы Windows, а так же на языке Java;

• на всех этапах разработки применяется язык UML, и проект программного средства представляет собой единую модель;

• возможность конфигурирования системы с помощью модулей расширения;

• в наибольшей степени подходит для разработки крупных информационных систем, так как реализует большую часть функций ARIS и ERwin/BPwin. и т.д.

Rational Rose — популярное средство визуального моделирования, которое считается стандартом де-факто среди средств визуального проектирования приложений. Этот продукт входит в состав пакета IBM Rational Suite и предназначен для моделирования программных систем с использованием широкого круга инструментальных средств и платформ.

CASE-средство ARIS

ARIS — рассматривает предприятие как совокупность четырех взглядов (views):

• взгляд на организационную структуру

• взгляд на структуру функций

• взгляд на структуру данных;

• взгляд на структуру процессов.

ARIS позволяет составлять диаграмму целей, связывая процессы через цели с миссией компании. В результате после построения бизнес-модели получается комплексное видение компании: Цели — Процессы — Оргструктура — Данные — Продукты/услуги в виде отдельных, но связанных через объекты диаграмм. Это означает, что при изменении названия должности на одной диаграмме сразу корректируются названия во всех процессах, где она присутствует, и в оргструктуре.

При этом каждый из данных взглядов разделяется еще на три подуровня:

• описание требований;

• описание спецификации;

• описание внедрения.

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

CASE-средство Business Studio

Business Studio разработана специально для максимально легкого создания бизнес-архитектуры. Помимо этого, она обеспечивает решение смежных задач, необходимых для обеспечения непрерывного развития компании. Таким образом, Business Studio поддерживает полный цикл создания эффективной системы управления компанией – «Проектирование — Внедрение – Контроль – Анализ», позволяя решать следующие задачи:

• формализация стратегии и контроль ее достижения

• моделирование и оптимизация бизнес-процессов

• проектирование организационной структуры и штатного расписания

• регламентация деятельности: разработка регламентов и распространение их среди сотрудников

• внедрение системы менеджмента качества в соответствии со стандартом ISO

• формирование Технических заданий и поддержка внедрения информационных систем.

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

На основании приведенных сравнений было выбрано программное средство Business Studio, ключевые преимущества которой, принципиально отличаются от других аналогичных программных продуктов:

• Простота, удобство и высокая скорость освоения специалистами.

• Использование самых популярных нотаций моделирования бизнес-процессов, понятных сотрудникам без дополнительной подготовки: IDEF0, Процесс (Basic Flowchart)/

• Интегрированность: в одном инструменте собраны все востребованные бизнесом методики и технологии.

• Формирование на выходе конкретизированных регламентирующих документов, не требующих дополнительной доработки.

• Business Studio Portal, предоставляющий сотрудникам необходимую для работы информацию и вовлекающий их в процесс улучшения компании.

• Мощный Мастер отчетов, позволяющий формировать отчеты с использованием всех возможностей форматирования Microsoft Word и поддерживающий сложные выборки данных.

Абдулгалимова Анжелика Гамлетовна, Джабраилова Лейла Мусаевна

1. Магистрант, Дагестанский государственный университет
2. к.ф-м.н., доц. Дагестанский государственный университет

Abdulgalimova Anzhelika Gamletovna, Dzhabrailova Leila Musaevna,

1. Graduate students, Dagestan State University
2. candidate of physico-mathematical Sciences, associate Professor. Dagestan state University

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

Abstract: The article deals with various business process modeling of transportation, which are used in logistics systems, models and their characteristics, advantages and disadvantages. The influence of logistics systems on transport is also considered.

Ключевые слова: бизнес-процесс, модель, моделирование, ARIS, транспорт, логистика, логистические системы, транспортные системы, перевозки.

Keywords: business process, model, transport, logistics, logistics systems, transport systems, traffic.

---

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

Возникает вопрос: «Что же должен выполнить современный руководитель, чтобы улучшить деятельность предприятия? Во-первых, необходимо понять, что ни один руководитель не хочет потерять способность самостоятельно принимать решения, касающиеся  вопросов улучшения деятельности предприятия. Поэтому необязательно современному руководству иметь «гениев», а лучше использовать различные технологии и приемы, методы и модели улучшения бизнес-процессов.[1]. Именно поэтому, необходимо иметь адекватную, соответствующая реальному времени информацию и создавать нужного рода модели бизнес-процессов. Что касается транспортного предприятия, необходимо смоделировать бизнес-процессы, позволяющие провести всесторонний и всеобщий анализ всего предприятия, его структур и подразделений, взглянуть и оценить модель бизнес-процессов со всех точек зрения, и увидеть то, что не видят  сотрудники и вышестоящее руководство.

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

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

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

Если говорить о логистическом моделировании, необходимо отметить, что оно основывается на полных или частичных системах и процессах. В этом случае, особенно важно рассмотреть модели на принципах логистики. Основные  модели логистического моделирования представлены на рисунке 1. [2].

Рисунок 1. Модели логистического моделирования с помощью ПП ARIS

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

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

1. выбор способа транспортировки;
2. выбор вида транспорта;
3. выбор перевозчика;
4. определение маршрутных схем и условий перевозки;
5. выбор организаций, обеспечивающих ход процесса транспортировки. [3].

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

Рассмотрим следующий пример. Рассчитаем рейтинг для трех перевозчиков по пяти критериям, которые указаны в графе 1 (таб. 1). Ранг каждого критерия указан в графе 2, а соответственно в графах 3, 5 и 7 приведены оценки степени удовлетворения критериям каждого из перевозчиков. Рассмотрена следующая шкала оценок: 1 – хорошо, 2 – удовлетворительно, 3 – плохо. [3].

Таблица 1.

Расчет рейтинга перевозчиков методом экспертных оценок

Критерий	Перевозчики
Ранг	Оценка	Рейтинг	Оценка	Рейтинг	Оценка	Рейтинг
1	2	3	4	5	6	6	8
Скорость	1	1	1,00	2	2,00	3	3,00
Надежность	2	4	1,50	1	0,50	2	1,00
Стоимость	3	2	0,67	1	0,33	2	0,67
Грузоподъемность	4	1	0,25	2	0,50	1	0,25
Доступность	5	23	0,40	3	0,60	1	0,20

Необходимо использовать следующую формулу для расчета рейтинга перевозчиков:

Где, R_i – рейтинг i-го перевозчика;  b_ij – оценка степени удовлетворения i-го перевозчика j-му критерию; r_j – ранг j-го критерия.

Рассматривая  таблицу 1 можно сказать, что рейтинг первого перевозчика оценивается как самый высокий, а рейтинг третьего перевозчика как самый низкий. Тем не менее, значение рейтинги у первых двух перевозчиков равны, в то время как третий перевозчик немного позади них. Таким образом, третий будет исключен из списка, а первый и второй перевозчики с приблизительно равными рейтингами войдут в целевую группу.[3].

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

Библиографический список

1. Тельнов, Ю.Ф. Инжиниринг бизнес-процессов и проектирование корпоративных экономических информационных систем / Инжиниринг деловых и информационных процессов: сб. науч. тр. – М.: МЭСИ, 2009. – С. 14-21.
2. Тельнов, Ю.Ф. Интеллектуальные изд системы тр информационные системы в экономике: yu науч процессов учеб .пособие. 3-изд. / Ю. Ф. brodetsky математические mesi Тельнов – М.: СИНТЕГ, 2011. –306 с.
3. Бродецкий, Г. Л. works processes processes Экономико -математические методы и lecture economics modeling модели в логистике: Потоки in reengineering потоки событий и системы обслуживания / Г. Л. studies reengineering информационных Бродецкий . – М.: Изд. центр «лекция logistics науч Академия », 2009. – 272 с.;
4. Толуев Ю.И. Моделирование service of service логистических процессов: традиции и модели telnov reengineering инновации Лекция 1: Задачи и информационные works systems методы моделирования логистических and тр house систем 2012;