Принципы построения модели логистической системы
Логист при выполнении своей работы вольно или невольно оперирует не с самой логистической системой, а с её моделью, на модели проверяется и верность предложенных решений, и только после проверки и получения удовлетворительного результата на модели логистической системы, осуществляются необходимые управляющие воздействия непосредственно на функционирующую систему.
При построении модели логистической системы необходимо учитывать, что каждая логистическая система является открытой. Степень открытости системы определяется степенью заинтересованности источника ресурсов и получателя готового продукта в согласовании взаимных интересов. Простейшая принципиальная модель (схема) логистической системы представлена на рисунке 3.
Данная схема может быть дополнена источниками управляющих и регулирующих воздействий, а также сигналами обратной связи и авторегулирующими сигналами.
Чёрный ящик логистической системы является основным исполнительным органом и, в свою очередь, так же может быть представлен в виде совокупности вложенных в него логистических систем взаимодействующих друг с другом. Образно «логистическую систему» можно представить в виде матрёшки или автомобиля с его подсистемами: система управления; топливная система, двигатель, движитель, тормозная система и т.д.
Такое наглядное и схематичное построение логистической системы позволяет:
· Получить наглядный и удобный инструмент для создания и исследования модели взаимодействия субъектов и объектов в рамках рассматриваемой системы;
· Сэкономить время, силы и средства, а так же добиться максимально значимого совокупного, для взаимодействующих субъектов, результата.
Как же начать практически строить и изучать схемы логистических систем?
Наиболее удобным и легко понимаемым является метод построения систем с использованием графического языка UML – универсального языка моделирования (Unified Modeling Language).
Основы UML (Unified Modeling Language)
Для того, чтобы построенная Вами модель логистической системы, да и всякая другая модель, легко читалась и понималась другими специалистами она должна строиться с использованием универсальных символов, графических элементов и спецификаций[7]. Приведём их в таблице 1.
Таблица 1
Виды диаграмм в UML
В UML используется целый набор диаграмм, предназначенных для представления характеристик системы с различных точек зрения. Ни одна из диаграмм не может дать целостного и исчерпывающего представления о системе, и только их совокупность может дать целостное представление о «Слоне» (см. рис. 4)
Только целостный взгляд на систему может способствовать пониманию того, чем является «Слон».
Диаграмма прецендентов
Диаграммы прецедентов могут иметь два вида:
1. Диаграмма прецедентов с исходящим воздействием;
2. Диаграмма прецедентов с входящим воздействием.
Диаграмма прецедентов описывает возможные действия “actor”ов (действующих лиц) в рамках моделируемой системы или возможные ответы системы в адрес взаимодействующих с ней “actor”ов.
То есть, для каждого “actor”а, действующего внутри системы или из вне взаимодействующего с системой необходимо представить весь спектр возможных сигналов, запросов, ответов и взаимодействий.
Наглядно диаграммы прецедентов приведены в таблице 2.
Таблица 2
Виды диаграмм прецедентов
Диаграмма классов
Диаграммы классов используются для анализа предметной области разрабатываемых систем и составления словаря описываемых систем.
Диаграммы классов визуально представляют из себя «структурные схемы» в которых стрелки наследования направлены вверх от конкретных объектов ко всё более формализованным сущностям.
Диаграммы классов могут использоваться для формализации объектов и субъектов модели системы с указанием их свойств и возможных вариантов действий. Это особенно необходимо в случае разработки аппаратно-программного обеспечения логистической деятельности и документирования разрабатываемой модели.
Класс, подкласс и конкретный экземпляр класса, обладающий набором уникальных характеристик, на диаграммах обозначаются одинаково в виде прямоугольника разделённого на секции (так как показано выше). В верхней секции отображается название класса (объекта) в нижних его характеристики (наименования и типы данных) и возможные действия с данным классом (объектом).
Диаграмма классов представлена на рисунке 5.
Диаграмма объектов
Диаграмма объектов показывает совокупность объектов системы и их взаимодействие между собой в определённый конкретный момент времени. Это своеобразный моментальный снимок состояния системы. Таким образом, диаграмма объектов показывает статическое состояние системы в определённый момент времени. В связи с тем, что любые системы, в том числе и логистические, редко находятся в статике это ограничивает применение диаграммы объектов.
Пример диаграммы объектов приведён на рисунке 6.
Диаграмма объектов, приведённая на рисунке наглядно показывает какие объекты, а именно: Склад сырья, Отдел закупок, менеджер отдела закупок Иванов В.С. и Финансовый директор компании принимают решение относительно судьбы очередного заказа.
Диаграмма последовательностей
Диаграмма последовательностей отображает взаимодействие объектов системы в динамике.
Взаимодействие объектов может иметь физический и информационный характер, в любом случае принимаемое взаимодействие каким-то образом изменяет состояние получателя. В случае если состояние объекта, принимающего взаимодействие, не изменилось, то и взаимодействия не наблюдалось.
Область применения диаграммы последовательностей находится в сфере написания и анализа сценариев взаимодействия объектов системы, так же в диаграмме последовательностей можно найти обратные сигналы (обратные взаимодействия) направляемые от принимающего объекта к первичному (передающему) объекту.
На диаграмме последовательностей может отображаться не только порядок передаваемых объектами воздействий, но и «время жизни» этих воздействий. В некоторых случаях это может оказаться важной информацией.
Приведём диаграмму последовательностей действий при исполнении заказа покупателя на поставку продукции (см. рис. 7).
Итак, как Вы уже догадались, приведена диаграмма последовательностей бизнес процесса «Обработка и исполнение заказа покупателя с условием последующей оплаты».
И хотя впереди есть ещё необходимость разобрать другие диаграммы составляемые при моделировании логистической системы, представляется что можно сделать паузу и вернуться к ранее изложенному материалу, но уже с целью составления уже изученных диаграмм и разбору представленной в них информации.
Маленькое, но важное ЗАМЕЧАНИЕ:
Обычно изучаемые системы настолько сложны, что детализировать их в одной диаграмме любого вида невозможно, особенно это касается диаграмм объектов и диаграмм последовательностей, поэтому диаграммы системы составляются в порядке вложения подсистем друг в друга, вплоть до достижения уровня, на котором дальнейшее выделение подсистем уже не представляется возможным (подсистема представлена элементарными взаимодействующими объектами).
Первая попытка оптимизации интересов участников логистической системы
Выявим участников логистического взаимодействия при исполнении заказа покупателя на поставку продукции. Определим основные интересы участников данной системы, а так же определим их основные интересы, в том числе и противоречащие интересам самой системы, выработаем предложения по согласованию интересов участников системы с целью максимизации совокупного полезного эффекта.
Система состоит из двух участников. На самом деле участников данной системы должно быть намного больше, но налоговой службой, различными фондами и прочими участниками на данном этапе можно пренебречь.
Самому общему представлению о данной системе соответствовал бы рисунок 8.
Эта самая общая схема позволяет определить основных действующих лиц (“actor”ов) моделируемой системы:
1. Внешняя неконтролируемая или слабо контролируемая часть системы – «Заказчик»;
2. Собственно система с вложенными подсистемами – «Производитель»
Основной интерес «Заказчика» – максимизация чистого получаемого дохода. Этот интерес реализуется в другой логистической системе, аналогичной этой, но при условии, что данный заказчик поменяет свою роль и станет продавцом. В рассматриваемой логистической системе интерес «Заказчика» реализуется при минимизации закупочной цены на товары (продукцию) указанной в спецификации к заказу.
Основной интерес «Производителя» – так же максимизация чистого получаемого дохода, но по своему отношению к цене на продукцию, входящую в спецификацию к заказу, цена реализации должна быть максимизирована.
Противоречие в интересах может быть проиллюстрировано рисунком 9.
Но это крайне упрощённый подход. Грамотный экономист должен указать, что важен не разовый максимальный доход или максимизация дохода от продажи единицы товара, а важно добиться максимизации долговременного дохода при реализации максимального количества товара, пусть и не по самой высокой цене. Эта «аксиома» экономики доказана ещё отцами основателями: Джон Локк (XVII век); Джеймс Стюарт (XVIII век); Адам Смит (XVIII век); Альфред Маршалл (XIX век).
Графическое представление «Закона спроса и предложения» разработал Альфред Маршал. Все мы видели эти знаменитые кривые (см. рис. 10).
Нас интересуют не столько сами кривые, а прямоугольные области, обозначенные буквами. Эти прямоугольные области соответствуют денежным суммам:
A-B-C-G – сумма дохода от реализации товара продавцом третьим лицам;
G-E-H-D – сумма дохода от реализации продукции производителем продавцу;
F-C-D-G – сумма затрат производителя на производство товара;
A-B-H-E – чистый доход продавца товара;
E-H-C-F – чистый доход производителя продукции.
Однако это идеальная модель, не учитывающая множественность участников рынка, вернее все производители и все продавцы объединены каждый в свою категорию. Кроме того, между продавцами и конечным потребителем поставлен знак равенства.
Более точная модель для локального рынка предполагает наличие единственного производителя (“actor” – производитель) в показанной модели (см. рис. 8) и множества покупателей. Предполагается, что все покупатели имеют одинаковые побудительные мотивы и их поведение стандартно.
В таком случае в модель должно быть введено ещё одно действующее лицо – «Коллективный конечный потребитель». Уточнённая модель представлена на рисунке 11.
В этой модели производитель лишён возможности продавать свою продукцию конечному потребителю напрямую, а «Продавец», он же «Заказчик» вынужден балансировать между конечным спросом со стороны «Потребителя» товара и возможностями (желаниями) «Производителя» по изготовлению продукции.
В данном случае, модель логистической системы лучше представить в табличном виде. (см. таблицу 3)
Таблица 3
Наиболее важные переменные параметры логистической системы выделены жирным обрамлением рамок.
Производитель товара может работать при условии, что его прибыль имеет положительные значения, а это означает то, что производить не будет производить товар при конечной цене реализации равной 0 рублей и 60 рублей.
Продавец товара достигает максимума прибыли при конечной цене реализации товара равной 40 рублям. Эта же цена максимизирует прибыль производителя при договорной цене равной 13,2 рубля за единицу товара (условие «Рентабельность равна 30% от затрат на производство единицы продукции).
В таких условиях могут существовать все участники логистической системы, но согласованы ли их интересы? Очевидно, что нет.
При производстве 40 единиц товара производитель получает прибыль в размере 82 рубля, в то время как продавец этого же количества товара получает прибыль равную 1072 рубля. Полная гармония должна наступить в том случае, когда прибыль производителя товара и прибыль продавца товара будут равны.
В таблице 4 представлены гармонизированные данные по взаимодействию участников логистической системы.
Таблица 4
Как видно из таблицы:
1. Покупатель принимает предложенную цену (40 рублей) за единицу товара;
2. Продавец не может продавать товар дешевле 3 рублей за единицу;
3. Продавая товар по конечной цене реализации равной 40 рублям продавец должен закупать 40 единиц товара, а производитель изготавливать эти 40 единиц товара;
4. Цена реализации продукции производителем равна 25,11 рубля;
5. Прибыль продавца при этом составит 595,60 рублей, а прибыль производителя будет равна 594,4 рубля, что обеспечивает равенство их интересов.
В рассматриваемой логистической системе «Заказчик – Производитель» Заказчик будет являться «Центром прибыли», а Производитель, соответственно – «Центром затрат». В соответствии с коммерческой логикой, любое пожелание Центра прибыли должно быть исполнено, если его исполнение приводит к увеличению оптимизированного совокупного дохода системы, то есть дополнительный доход, получаемый Производителем от Заказчика должен превышать дополнительные затраты производителя, связанные с исполнением пожеланий «Заказчика» и получением этого дополнительного дохода.
Можно рекомендовать разработчикам логистической системы, кроме экономических ограничителей на базе соотношения ΔПрибыли/ΔЗатрат (соотношение должно быть больше единицы), разработать и критерии «Ограничители» не относящиеся к коммерческой области, например: юридические ограничители, моральные ограничители, репутационные ограничители и т.д.
В связи с ограниченностью времени на анализ состояния системы и принятие экономически обоснованного решения аналитики, разрабатывающие проекты решений и лица, принимающие решения должны пользоваться специальными автоматизированными программными средствами. Диаграммы, разрабатываемые на языке UML, в этом случае, будут абсолютно необходимы для составления технического задания на разрабатываемую модель логистической системы, для проектирования системы и составления рабочей документации по разрабатываемой системе, написания программного кода и его отладки.
Основы UML (Unified Modeling Language) ПРОДОЛЖЕНИЕ
В предыдущем материале были рассмотрены правила составления трех видов диаграмм из языка UML:
· Диаграмма классов;
· Диаграмма объектов;
· Диаграмма последовательностей.
Вернёмся к рассмотрению других диаграмм UML.
Диаграммы взаимодействия (диаграммы кооперации)
Диаграммы взаимодействия очень схожи с ранее рассмотренными диаграммами последовательностей, так как показывают потоки сообщений между объектами системы и является удобным средством моделирования системы. При проектировании логистической системы можно пользоваться как диаграммами последовательностей, так и диаграммами взаимодействия, по выбору разработчика.
Объекты на диаграммах взаимодействия обозначаются стандартно – прямоугольниками с написанными и подчёркнутыми именами (подчёркивание обозначает конкретный индивидуализированный объект).
Взаимодействия между объектами обозначаются линиями (лучами). Над ними обозначаются названия и порядковый номер. Продолжительность взаимодействия (срок жизни) в данной диаграмме не обозначается.
Мы уже говорили, что диаграммы последовательностей и диаграммы взаимодействия выполняют одну и ту же роль: Показывают порядок взаимодействия объектов в системе. Для наглядности покажем эти диаграммы рядом, а какой вид диаграмм предпочтёте использовать лично Вы, решать Вам.
Созданная нами диаграмма последовательностей отражала взаимодействие «Заказчика» и объектов логистической системы по обработке принятого заказа и отгрузке товаров покупателю на условиях последующей оплаты.
Диаграмма последовательностей приведена на рисунке 7, но мы приведём её для удобства читателей ещё раз.
А теперь спроектируем диаграмму взаимодействия (рисунок 12)
Как уже было сказано – эти диаграммы равнозначны, но я предпочитаю диаграмму последовательностей, для меня она более понятна и информативна. Диаграммы состояний
Любой объект системы в разное время может находиться в различных состояниях. Например, в начальный момент времени объект не взаимодействует ни с одним из прочих объектов системы и является пассивным. В следующий момент времени он меняет своё состояние на ожидание взаимодействия, потом получает управляющий сигнал, после чего выполняет какое-либо конкретное действие, далее отправляет отчёт, и снова переходит в состояние покоя. В данном примере объёкт последовательно сменяет пять состояний, характеризующих его деятельность.
Диаграмма состояний определяет условия и возможности объекта по переходу из одного возможного для него состояния в другое в результате реакции на внешнее событие.
Диаграмма состояний составляется для каждого конкретного объекта системы.
