ЭММ в проектных решениях
по управлению производством и логистикой
Интервью с Левоном Антоняном,
научным руководителем проекта "Технология ADD Cerebrum"
О целях, задачах и опыте применения экономико-математических методов в управлении производством и логистикой мы беседуем с Левоном Владимировичем Антоняном – руководителем этого направления, кандидатом физико-математических наук.
– Левон Владимирович, а что такое ЭММ? Что стоит за этой аббревиатурой?
– Экономико-математическое моделирование (ЭММ) понимается как применение математических методов в моделировании, анализе, прогнозировании и оптимизации различных экономических процессов: производственных, управленческих, торгово-распределительных, транспортно-логистических и т.д.
– А если на примере?
– На примере? Пожалуйста. Если – немного утрируем – Вы из выручки от реализации Вашей продукции вычтете затраты – даже на листе бумаги! – и посчитаете таким образом прибыль, то это уже будет простейшая экономико-математическая модель! А вообще – если серьезно – это может быть расчет бюджета или производственного плана-графика, оптимизация размещения производственных объектов или складского хозяйства....
– А что можно сказать по истории вопроса?
– Ну, элементарные экономические расчеты, конечно, уходят корнями в глубокую древность. А серьезные математические методы пришли в экономику примерно в 60-х годах прошлого (20-го) века – когда экономика усложнилась до такой степени, что принятие эффективных управленческих решений на основе лишь опыта и интуиции стало практически невозможным. Хотя, разумеется, сами эти методы появились существенно раньше: так, например, методы исследования операций (линейное и динамическое программирование, теория массового обслуживания, теория игр и другие), ныне активно используемые в управлении производством, логистикой, маркетингом и другими экономическими процессами, широко применялись еще в ходе второй мировой войны при планировании боевых действий.
– А что вообще дает применение математических методов в экономике, в управлении производством, в консалтинге?
– Ну, во-первых, поскольку ЭММ, так или иначе, имеет дело с информацией: анализирует и перерабатывает ее (порождая новую информацию), то применение ЭММ ведет к упорядочиванию информационно-аналитического обеспечения компании – формулируются и проводятся в жизнь определенные требования к составу информации, способам ее хранения и анализа.
Во-вторых, разработка средств поддержки принятия решений (являющаяся одной из целей ЭММ) ведет к повышению качества и оперативности принимаемых управленческих решений.
Еще один результат применения ЭММ – повышение точности, оперативности и глубины экономических расчетов при одновременном снижении их трудоемкости.
Наконец, применение математического аппарата и вычислительной техники позволяет решать производственно-экономических задачи повышенной сложности, не решаемые без применения этих средств.
Наконец, применение математического аппарата и вычислительной техники позволяет решать производственно-экономических задачи повышенной сложности, не решаемые без применения этих средств.
– А в чем смысл выделения ЭММ в отдельное направление деятельности консалтинговой компании?
– Вопрос вполне логичный, поскольку в консалтинговой компании, являющейся, кроме всего прочего, коммерческой структурой, разработка экономико-математических моделей, конечно же, не может быть самоцелью.
Однако можно с уверенностью утверждать, что большинству консультантов так или иначе приходится в ходе своей работы заниматься построением разного рода моделей – прежде всего, с использованием популярного и достаточно хорошо знакомого им инструмента «Microsoft Excel». В силу вполне объективных причин это нередко приводит к распылению и дублированию усилий, а разрабатываемые модели оказываются ориентированными на частные, локальные задачи.
Смысл выделения ЭММ в отдельное направление деятельности заключается как раз в преодолении этих недостатков, в повышении качества разрабатываемых моделей до уровня тиражируемых (а в каких-то случаях – и коммерческих) продуктов, допускающих, как минимум, их многократное применение внутри компании.
При этом консультанты не освобождаются от необходимости разрабатывать свои собственные модели, но они получают в свое распоряжение набор специализированных модулей, которые легко встраиваются в разрабатываемые модели и позволяют решать разнообразные типовые задачи.
– Получается, что возглавляемая Вами группа ЭММ занималась ранее, главным образом, разработкой средств автоматизации работы консультантов?
– Я бы так не сказал. Мы непосредственно участвовали и во внешних (коммерческих) проектах компании, причем формы такого участия были весьма разнообразными.
В простейшем случае предлагаемые нашим заказчикам проектные решения могли включать лишь результаты наших расчетов: то есть мы обеспечивали экономическое обоснование разрабатываемых решений, но используемые при этом модели и инструменты заказчику не предоставляли.
Другом вариант мог предусматривать передачу разрабатываемых моделей и инструментов в самостоятельное пользование заказчикам, причем как в рамках отдельных проектов по разработке соответствующих инструментов, так и в рамках более широких проектов по оптимизации бизнес-процессов.
Наконец, могло предполагаться внедрение разрабатываемых моделей и инструментов на предприятиях заказчиков, то есть их адаптация к условиям заказчика, обучение персонала, пробная эксплуатация, возможная интеграция с корпоративными информационными системами и другими имеющимися у заказчиков программными продуктами и т.д.
Но пришло время, и мы стали перепрофилироваться из консалтинговой компании в софтверную, перешли к разработке собственных информационных систем…
– Но давайте, с Вашего позволения, еще ненадолго задержимся в «консалтинговом прошлом» компании. Могли бы Вы поподробнее остановиться на интеграции ваших тогдашних экономико-математических моделей с программными средствами заказчиков? Вы сказали, что наиболее часто используемой средой разработки ваших продуктов являлся тогда Excel...
– Ну, сначала скажу пару слов о самом «консалтинговом прошлом». Вообще-то, с нашим переходом в сферу информационных технологий консалтинг на самом деле никуда не делся. Ведь разработке и внедрению информационной системы должно предшествовать описание и перепроектирование подлежащих автоматизации бизнес-процессов, подготовка регламентов и так далее, то есть, чисто консалтинговая работа. Так что, консалтинг остался, но стал играть подчинённую роль. Впрочем, это отдельная тема…
Теперь – что касается среды разработки моделей. Да, действительно, мы часто использовали (и используем до сих пор!) именно Excel в качестве средства разработки наших моделей. Но, во-первых, мы не разделяем широко распространенного скептического отношения к Excel’у: модели, разрабатываемые на базе этого поистине «народного» инструмента, как правило, наиболее просты в освоении, и даже их самостоятельная адаптация к меняющимся условиям может для более или менее квалифицированных пользователей Excel’а оказаться вполне посильной задачей. К тому же, на местах (например, в цехах предприятий) использование иных программных средств может оказаться затруднительным – хотя бы в силу ресурсных ограничений (это могут быть и устаревшие компьютеры, и отсутствие локальной сети, и низкая квалификация пользователей).
Да, мы понимаем, что для работы с большими массивами данных Excel плохо приспособлен, поэтому для хранения данных мы еще и в консалтинговую пору при необходимости использовали специализированные инструменты управления базами данных (такие, как Microsoft Access или Microsoft SQL Server), а у заказчика роль источника информации могла играть, в частности, база данных его корпоративной информационной системы.
Кроме того, в каких-то случаях вычислительные процедуры, реализованные в среде Excel, не обеспечивают необходимого быстродействия – и тогда мы реализуем их другими средствами (например, на языке программирования FORTRAN), причем помещаем их в отдельные динамически загружаемые библиотеки (DLL), откуда – вот что здесь чрезвычайно важно! – они могут быть вызваны не только из Excel’а, но и, к примеру, из той же корпоративной информационной системы заказчика. Вот вам и интеграция! А что же в этой ситуации остается за Excel’ом? Фактически – только интерфейс пользователя (при разработке которого вся мощь Excel’а (обширный набор встроенных функций, красивые графики, богатые возможности форматирования таблиц...) оказывается в нашем распоряжении. Но и интерфейс пользователя можно при желании перенести на платформу заказчика, чем мы теперь успешно и занимаемся. Однако технология «прототипирования» разрабатываемых решений с использованием Excel’а оказалась настолько удачной, что мы используем ее и сейчас на начальных этапах разработки информационных систем.
Конечно, когда разрабатывается чисто учетная система с математикой на уровне арифметики начальной школы, то особого смысла делать Excel’овский прототип может вообще не быть. Но мы обычно беремся за проекты, требующие разработки сложнейших алгоритмов, и тогда неизменно начинаем с прототипов.
Прототип обычно состоит из двух частей: математического «ядра» в виде библиотеки DLL, в которой и «зашиты» требуемые алгоритмы, и Excel’ной части с таблицами для ввода исходных данных, передаваемых в «ядро», и для отображения возвращаемых из «ядра» результатов расчетов. В самой Excel’ной части, как правило, никаких содержательных расчётов не производится, но она непременно содержит макрос (программную процедуру на встроенном в Microsoft Office языке программирования «Visual Basic for Applications» (VBA)), который считывает исходные данные (попутно проверяя их корректность), передает их в «ядро», получает из него результаты расчетов и размещает их в надлежащих местах. На самом деле львиную долю времени на этапе прототипирования занимает разработка «ядра», а Excel’ная часть делается сравнительно быстро и параллельно с «ядром».
Прототип обычно состоит из двух частей: математического «ядра» в виде библиотеки DLL, в которой и «зашиты» требуемые алгоритмы, и Excel’ной части с таблицами для ввода исходных данных, передаваемых в «ядро», и для отображения возвращаемых из «ядра» результатов расчетов. В самой Excel’ной части, как правило, никаких содержательных расчётов не производится, но она непременно содержит макрос (программную процедуру на встроенном в Microsoft Office языке программирования «Visual Basic for Applications» (VBA)), который считывает исходные данные (попутно проверяя их корректность), передает их в «ядро», получает из него результаты расчетов и размещает их в надлежащих местах. На самом деле львиную долю времени на этапе прототипирования занимает разработка «ядра», а Excel’ная часть делается сравнительно быстро и параллельно с «ядром».
Тем не менее, может возникнуть вопрос: а зачем вообще нужна эта Excel’ная часть, если в конечном итоге «ядро» всё равно будет интегрироваться с разрабатываемой (или даже уже существующей) системой? А дело в том, что Excel’ная часть прототипа включает в себя макет структуры данных, которую программистам остается лишь реализовать в разрабатываемой системе, а прототип в целом представляет собой полнофункциональный (во всяком случае, в «алгоритмическом» плане) макет всей системы, который можно показывать заказчикам, согласовывать с ними и «доводить до ума» параллельно с другими работами.
Это страхует от неожиданностей при сдаче уже готовой системы, когда зачастую вдруг выясняется, что заказчики ждали чего-то совсем другого. Но нередко мы делаем прототип даже ещё до заключения договора на проект, за свой счёт – чтобы было что показать заказчику, было чем его заинтересовать, чтобы у заказчика появилась уверенность в том, что мы в состоянии решить поставленную задачу.
– А сколько примерно времени уходит на разработку подобного прототипа?
– Что-то показать заказчику удаётся обычно уже примерно через месяц – что-то ещё совсем сырое, но уже работающее! И обычно уже с красивым графическим отображением планов перевозок в виде диаграмм Гантта, с возможностью варьирования исходных данных, «проигрывания» различных сценариев… Кстати, диаграммы Гантта очень облегчают и нам, разработчикам, тестирование и отладку алгоритма: порой, чтобы понять, что что-то не так, достаточно одного взгляда на график…
Очень важно также и то, что прототип позволяет тестировать «интеллектуальное ядро» не на «игрушечных», а на настоящих, реальных данных большой размерности, потому что, как показывает наш опыт, в алгоритмах подобной сложности некоторые ошибки проявляются только на больших размерностях, когда реализуются различные редкие сочетания исходных данных. Да и больших размерностей разрабатываемый алгоритм может вообще «не потянуть» – и это тоже не должно потом стать неприятным сюрпризом…
– Да, понятно… Но не могли бы Вы привести конкретные примеры ваших разработок, причём, начиная с «консалтингового прошлого» – именно экономико-математических моделей, то есть, каких-то, может быть, сценарных расчётов, инструментов поддержки принятия решений?
– Да, пожалуйста. Вот, например, уже довольно много лет назад нам довелось заниматься оценкой перспектив развития перегрузочной деятельности на одной крупной железнодорожной станции. Прежде всего, нужно было понять, что будет, если в ситуации «как есть» существенно вырастут грузопотоки: какие и где возникнут «узкие места», появятся очереди и т.д. Кроме того, надо было оценить несколько заданных сценариев развития станции, предусматривавших строительство новых путей, контейнерных площадок (причём в разных возможных местах), обновление парка маневровых локомотивов и т.д.
И мы тогда довольно быстро поняли две вещи. Во-первых, что хотя в проекте речь шла о сценариях развития только лишь перегрузочной деятельности, вычленить её из работы станции в целом было практически невозможно. И, во вторых, что посчитать потребность станции в тех же маневровых локомотивах или, допустим, пропускную способность какого-нибудь пути (в «узком месте») чисто арифметически, основываясь на нормах времени выполнения соответствующих операций, фондах времени работы тех же локомотивов и т.д., хотя и можно было, но достоверность результатов таких расчётов была бы под большим сомнением.
Потому что такие расчёты никак не учитывают, в частности, простоев, возникающих хотя бы из-за неравномерности прибытия поездов. Кроме того, аналитическими методами никак не получается считать длины очередей (например, скоплений порожних вагонов). Поэтому мы решили сделать имитационную модель работы станции – благо, собственный инструментарий для такого моделирования у нас имелся – и уже на этой модели «прокрутить» заданные сценарии. При этом сама модель заказчику не передавалась (только результаты расчётов и выводы).
У нас был также интересный опыт разработки различных методик – и тоже с моделями в Excel’е! Например, была такая методика тарификации централизованной доставки материально-технических ресурсов для нужд крупных территориально распределенных компаний на основе статистики перевозок и затрат на них за истекшие периоды. Другой пример: методика оптимизации объемов многономенклатурных закупок материально-технических ресурсов с дифференцированными тарифами на доставку и ценовыми скидками.
Третий (совсем другой) пример: методика анализа продаж и оптимизации ассортимента для розничных сетей. Во всех этих случаях Excel’ная модель с самого начала позволяла заказчику проверить, как методика будет работать на реальных данных. Но тогда наработанные материалы передавались программистам заказчиков. А теперь…
– А теперь давайте уже окончательно перенесёмся в прекрасное настоящее?
– Да, давайте. В один и в самом деле прекрасный момент мы решили, что в век цифровизации и искусственного интеллекта пора бы и нам попробовать себя на этом поприще – благо, опыта и наработок для этого вполне хватало.
И тогда мы начали разрабатывать два семейства программных продуктов: «Интеллектуальный планировщик производства» и «Интеллектуальный логистический планировщик», базирующихся на двух совершенно различных подходах.
В первом случае вопрос стоит так: какую продукцию и в каких объёмах целесообразно запланировать к производству на заданный плановый период (год, квартал, месяц, неделю, сутки, смену) при имеющихся ограничениях по входящему сырью и его складским запасам, материалам и комплектующим, производственным мощностям и персоналу, спросу на готовую продукцию и её складским остаткам. Это в общем виде.
А конкретно ещё несколько лет назад мы взялись за автоматизацию планирования производства на птицеперерабатывающих комбинатах. На комбинат поступает поток живой птицы, а на выходе получаются различные виды продукции: тушка, грудка, филе грудки, окорочка и т.д. в различных упаковках: в лотках, в пакетах, в коробах и т.д. в различных термических состояниях: в охлажденном или в замороженном виде. И это ещё не все «измерения»: есть ещё сорта, калибры, бренды… Но главная трудность – в том, что это такое вот «разборочное» производство, и всякий раз встает вопрос, на каком уровне этой «разборки» целесообразно остановиться.
Скажем, проще всего, продавать целую тушку, но на неё, во-первых, в таких объемах может просто не быть спроса, а, во-вторых, может не хватать мощностей линий по упаковке этой самой тушки. А выгоднее всего может быть продавать филе грудки, но тогда надо будет понимать, что делать с окорочками и с крыльями, на которые может не быть спроса. Разделывать те же окорочка на бёдра и голени? Но там возникают свои варианты и проблемы… Кстати, если на какую-то продукцию ситуативно нет спроса, то её можно заморозить и отправить на склад, но тут может вплыть проблема нехватки морозильных мощностей…
– И что же со всем с этим делать?
– Хороший вопрос… Для начала нам следовало определиться с целеполаганием. Вот я говорил, что здесь требуется понять, что и в каких объемах целесообразно производить. А в каком смысле «целесообразно»? И здесь наиболее разумным критерием оказалась максимизация маржинальной прибыли. Правда, каша система позволяет пользователю выбирать критерий оптимизации по своему усмотрению, но в это давайте пока углубляться не будем и остановимся на «марже».
То есть, мы стремимся распланировать производство таким образом, чтобы максимизировать разницу между выручкой от реализации готовой продукции (включая ту, которая будет произведена «на склад») и переменными затратами – на входящее сырьё (живую птицу), энергию, персонал, пищевые добавки, упаковочные материалы и т.д.
Причём, подчеркну, что речь идёт о максимизации суммарной маржи по всей номенклатуре производимой продукции, причём с соблюдением всех имеющихся ограничений, о которых мы уже говорили. В частности, вся входящая птица должна быть полностью переработана (и это очень жёсткое ограничение!), ну, и куда девать готовую продукцию, тоже понимать надо. Хотя здесь в крайних случаях прибегают к аренде дополнительных складов, если их не хватает, но это касается только замороженной продукции: «охлаждёнка» складированию вообще не подлежит!
– А куда девать клиентов, заказы которых невозможно выполнить?
– Это тоже очень важный вопрос. Особенно потому, что в то время как спрос на готовую продукцию из мяса птицы динамично меняется (даже в зависимости от погодных условий – не говоря уже о «гримасах» рынка!), потоки входящего сырья (то есть, живой птицы), напротив, крайне инерционны, хотя и при этом тоже не вполне предсказуемы!
Здесь схема получилась такая. Мы ввели приоритеты заказов на готовую продукцию – например, «высокий», присваиваемый тем заказам, которые обязательно должны быть выполнены в срок и в полном объеме, «средний» – тем, которые желательно выполнить, и «низкий» – тем, которые могут выполняться по мере возможности и целесообразности.
И по результатам работы процедуры планирования система сообщает, что, допустим, удалось запланировать в срок и в полном объеме выполнение заявок только высокого и среднего уровней (соответственно, низкого – частично). Либо ещё перед запуском планирования пользователь сам указывает, что он заинтересован в полном выполнении, например, только заявок высокого уровня, и тогда система в обязательном порядке запланирует только их.
– А какими методами решалась данная задача в целом?
– Здесь мы воспользовались нашей оригинальной ресурсно-операционной методологией моделирования бизнес-процессов, сводящей данную задачу к задаче линейного программирования. В результате «ядро» системы оказалось абсолютно универсальным: в нём реализован симплекс-метод решения задачи линейного программирования, адаптированный к ресурсно-операционному подходу.
Но сама моделируемая предметная область (птицеперерабока) оказалась настолько «многомерной» и сложной, что нам пришлось, по сути, проделать целую научно-исследовательскую работу, чтобы «дойти» от этой предметной области до симплекс-метода. Нужно было добиться того, чтобы при любых изменениях исходных данных модель птицекомбината автоматически пересчитывалась. Например, при остановках или запусках каких-то линий, при изменениях их производительностей… Но самый интересный случай – это изменение ассортимента готовой продукции, появление новых номенклатурных позиций, новых артикулов.
И нам удалось добиться того, чтобы и в этом случае вносить изменения в модель «руками» не приходилось: она перестраивается сама! Это происходит примерно так же, как новый (открываемый учёными) химический элемент находит свою клеточку в таблице Менделеева. Только таблица Менделеева двумерна (ведь положение каждого элемента в ней определяется номерами строки и столбца), а наша таблица готовой продукции, по сути, десятимерна, поскольку каждая номенклатурная позиция определяется именно 10-ю признаками (аналитическими кодами), которые я уже упоминал: это вид продукции, сорт, калибр, вид упаковки, термический статус и другие.
Эти признаки полностью определяют технологию производства каждого продукта – например, вид продукции указывает на то, что тушка выходит непосредственно из убоя, а, допустим, грудка или крыло – из разделки первого уровня, что замороженная продукция должна пройти заморозку, а охлаждённая – не должна и т.д. Всё это позволило автоматизировать динамическую генерацию модели…
– Да, очень интересно… Но время нашей беседы плавно подходит к концу, поэтому не могли бы Вы сказать пару слов и о логистических планировщиках?
– Да, это не менее интересная тема! Здесь постановка задача в общем виде – примерно такая. Есть заданный перечень заявок на перевозку грузов или людей. Но при этом жёсткой связи между пунктами отправки и назначения может не быть.
Например, есть заявки на вывоз урожая сахарной свёклы с полей и есть заявки сахарных заводов на завоз той же свёклы, но с каких-то полей свёкла может везтись, например, на два разных завода. Аналогично с людьми: человек может сесть в автобус в одном из нескольких пунктов посадки (в пределах шаговой доступности от своего местожительства) и поехать на работу на одно из нескольких предприятий (в его услугах нуждающихся).
Есть также парк транспортных средств разной грузоподъёмности и вместимости, которые в начальный момент находятся в разных местах в разном статусе (могут быть порожними или гружёными) и имеют разные «окна готовности». Например, задано, что конкретная машина может стартовать из начального пункта A не ранее 10:00, закончить работу не позднее 20:00 (причём, возможно, в каком-то конкретном пункте B), но работать при этом не более 8-ми часов (например, с 10:00 до 18:00 или 12:00 до 20:00). Кроме того, могут быть разные другие ограничения. Например, определяющие возможность перевозки конкретными ТС конкретных видов грузов (или пассажиров), а также посещения конкретными ТС конкретных объектов, в том числе, в соответствии с какими-нибудь правилами биобезопасности. Может быть или не быть возможность перевозки одним рейсом ТС сразу нескольких разных видов грузов, в том числе, ТС могут быть многосекционными. Ну, и так далее…
А требуется здесь составить план перевозок, оптимальный по какому-то критерию. Целевой функцией может быть та же маржинальная прибыль, но в ней может также учитываться недовывоз и недопоставки (грузов или людей), непроизводительные простои ТС и т.д.
– И здесь тоже применялся волшебный симплекс-метод?
– Нет, конечно. Симплекс-метод эффективно применим лишь к задачам с непрерывными (вещественными) переменными. Что имеется в виду? То, что если, допустим, из убоя вышло 1000 тонн тушки, то мы теоретически можем любую часть этого количества продать как тушку, а оставшуюся часть пустить в разделку. Например, это может быть 234,5 тонн тушки и 766,5 тонн разделки.
А в логистической задаче мы должны решить, кто, куда и в какой последовательности поедет. А это уже дискретная задача, комбинаторика. Причём комбинаторика большой размерности. Очень большой! Где могут быть десятки пунктов разгрузки и разгрузки, сотни машин и рейсов, тысячи пассажиров… Здесь не только симплекс-метод, здесь вообще никакие аналитически методы работать не будут! Здесь требуются эвристические подходы!
– А в чём разница между аналитическими и эвристическими методами? Что, вообще, такое «эвристические методы»?
– К аналитическим относятся такие методы, которые имеют строгое логическое обоснование и гарантируют получение результата за предсказуемое число шагов и, главное, за разумное время. Делай «раз», делай «два», делай «три»! Вот как симплекс-метод. Но к комбинаторным задачам симплекс-метод хотя и в каких-то случаях применим, но с целочисленными переменными (из-за дискретности задачи). А при тех размерностях, о которых мы сейчас говорим, время решения задачи линейного программирования с целочисленными переменными может даже на сверхсовременном суперкомпьютере составить годы или даже тысячелетия. Есть, конечно, и полный перебор вариантов, но с ещё более пессимистичным прогнозом возможного времени счёта. Поэтому нужны принципиально иные подходы.
Для начала нужно отказаться от совершенно безнадёжной идеи отыскания абсолютно лучшего, идеального решения. Тем более что на практике этого обычно и не требуется. Требуется приемлемое решение, позволяющее решить стоящую задачу (в нашем случае – перевезти грузы) разумной ценой. И не беда, если это приемлемое решение окажется хуже наилучшего на какие-нибудь 3-4 процента. Вот в такой постановке за подобные задачи уже можно браться! Нужно придумать какую-то разумную стратегию поиска решения – и в путь!
Причём, желательно, чтобы алгоритм поиска решения был адаптивным, то есть предусматривал корректировки в зависимости от уже полученных в ходе поиска результатов: варьирование каких-то управляющих параметров и даже самих методов поиска, если они не дают эффекта. Как правило, эвристические методы работают именно так: пользовать выделяет на поиск решения определённое время (секунду, 10 секунд, минуту, час...), и в течение этого времени алгоритм находит решение (или сразу несколько решений), которое (или которые) затем пытается улучшить, а по истечении выделенного времени выдаёт наилучшее из всех найденных решений.
Подобных эвристических методов довольно много: это и генетические алгоритмы, и алгоритмы муравьиной колонии и даже нейронные сети… Но мы остановили свой выбор на методе направленного поиска с запретами (исключениями), развили его, успешно применили к нескольким различным задачам и рассказали об этом подходе и нашем опыте его практического применения в статье, которая может быть интересна самому широкому кругу читателей.
– Но не могли бы в завершение нашей беседы хотя бы кратко описать этот метод?
– Да, без этого наша беседа, пожалуй, осталась бы неполной… Ну, давайте я кратко опишу принципы работы поиска с запретами на примере задачи построения плана перевозок.
Алгоритм стартует «с нуля», то есть с пустого плана перевозок (когда никто ещё никуда не едет) и на каждом шаге разворачивающегося процесса построения плана добавляет в него (пока это возможно) по одному рейсу. Причём, всякий раз выбирая самый выгодный (по целевой функции) рейс (из всех возможных вариантов ТС, видов груза, пунктов загрузки и разгрузки и т.д.).
На первом шаге это будет, скорее всего, самый продолжительный рейс, с самой большой загрузкой. На втором шаге по тому же принципу добавится второй рейс, причём это может быть рейс как того же, так и другого ТС – как получится. И так далее – пока будет сохраняться возможность добавления новых и новых рейсов.
Разумная стратегия – как Вам кажется?
– Да вроде бы вполне разумная…
– Вроде бы, да не всё так просто! Вот мы включили в план длинный, выгодный рейс ТС, но может оказаться, что больше это ТС уже никуда послать не удастся (просто времени его работы на следующий рейс может не хватить) и что вместо этого длинного рейса именно этому ТС надо было бы назначить два коротких рейса. А если бы никаких других ТС вообще не было, то получилось бы, что в такой элементарной ситуации наша «разумная» стратегия уже дала сбой. Но на самом деле это нет так. Потому что мы нашу стратегию описали не до конца.
Вот если бы она предусматривала только добавления рейсов в план, пока они возможны, а в случае невозможности добавлений алгоритм завершал бы свою работу, то такая стратегия, действительно, была бы ущербной. Но алгоритм поиска с запретами в ситуации невозможности добавления дополнительных рейсов предусматривает продолжение работы (если выделенное время ещё не истекло). Первым делом он должен будет запомнить построенный к этому моменту план перевозок как первое допустимое (и «рекордное») решение рассматриваемой задачи.
Первое, но, скорее всего, не последнее, поскольку алгоритм продолжит поиск более эффективных решений. Для этого ему придётся удалить из плана один из рейсов, причём удалить надо будет самый невыгодный из рейсов – чтобы в результате снижение целевой функции было как можно меньшим. А на следующем шаге алгоритм попытается вместо удалённого добавить в план какой-то другой рейс, причём именно другой, поскольку правило запретов не позволит ему добавить только что удалённый (это станет возможным только через определённое число шагов, называемых в данной концепции длиной списка запретов).
Если такие другие рейсы найдутся, то самый выгодный из них будет включён в план, а иначе придётся удалять ещё один рейс. И этот итерационный процесс может продолжаться сколь угодно долго (пока время не закончится), и на каждом шаге этого процесса достигнутое значение целевой функции сопоставляется с прежним рекордом, и если оно оказывается больше, то текущий план перевозок запоминается как наилучший на замену запомненного ранее.
Примерно так… В таком виде эта стратегия хотя и выглядит вполне разумной, но ничего не гарантирует. Но при этом загадочным образом работает! То есть позволяет находить те самые приемлемые решения, в нашем случае – вполне эффективные планы перевозок…
– И на основе этого подхода вы смогли сделать универсальный планировщик перевозок – с несколькими видами грузов, с разными по грузоподъёмности и вместимости транспортными ТС, со всеми этими ограничениями биобезопасности?
– Нет, по этому пути мы не пошли. Хотя, в принципе, это было возможно, но очень трудоёмко. Особенно отладка такого «монстра» потребовала бы больших усилий и времени. А время обычно не ждёт… Но дело не только во времени.
Во-первых, понимание того, как это должно быть устроено, приходит не сразу. А, кроме того, универсальный планировщик неизбежно проиграет в эффективности специализированному. За универсальность всегда приходится платить! А мы хотим, чтобы наши планировщики работали в оперативном режиме: несколько секунд – и план перевозок из трёх сотен рейсов готов!
Вот по этим причинам мы и решили делать отдельные планировщики под конкретные задачи. Начали с… планировщика производства стеклотарной продукции! Да, это вообще не логистика, а производство, но там та же комбинаторика и тот же поиск с запретами. При этом там был ещё и ряд специфических (именно для той отрасли) сложностей, для преодоления которых пришлось разработать целую технологию (специальный алгоритм контроля ограничений) за рамками собственно поиска с запретами.
Потом был планировщик перевозок комбикормов. Именно вокруг этой задачи построена наша статья, ознакомиться с которой я уже рекомендовал. Там – свои сложности: многосекционность кормовозов и обусловленная ею многовариантность загрузки ТС и необходимость в отдельном алгоритме её оптимизации.
А ещё и почти полное отсутствие запасов готовой продукции на комбикормовых заводах, из-за чего в планировщике перевозок комбикормов приходится учитывать динамику их производства и, наряду с вариантами немедленной, но неполной (из-за отсутствия кормов) загрузки и отправки ТС, оценивать варианты отложенной (но более полной) загрузки... Представляете себе?
– С трудом…
Но это ещё так, навскидку…
Потом был планировщик перевозки животных на убой – со своей спецификой.
И, наконец, мы разработали планировщик вывоза урожая с полей. Вот он, как раз, наиболее универсален. Там много всего: много видов грузов, различающихся по грузоподъёмности и другим параметрам транспортных средств, много пунктов загрузки и разгрузки и т.д. Причём, одно и то же ТС может, к примеру, привезти с поля на сахарный завод свёклу, а затем вывезти с завода на то же или на другое поле дефекат (отходы переработки свёклы).
И, наконец, мы разработали планировщик вывоза урожая с полей. Вот он, как раз, наиболее универсален. Там много всего: много видов грузов, различающихся по грузоподъёмности и другим параметрам транспортных средств, много пунктов загрузки и разгрузки и т.д. Причём, одно и то же ТС может, к примеру, привезти с поля на сахарный завод свёклу, а затем вывезти с завода на то же или на другое поле дефекат (отходы переработки свёклы).
На очереди – планировщик пассажирских перевозок…
В общем, рассказывать обо всём об этом можно бесконечно…
– Намёк понят… Действительно, время нашего интервью уже давно вышло. Спасибо за очень интересную, познавательную беседу!
– Спасибо за внимание и за содержательные вопросы!
– Намёк понят… Действительно, время нашего интервью уже давно вышло. Спасибо за очень интересную, познавательную беседу!
– Спасибо за внимание и за содержательные вопросы!
Закажите экономико-цифровой аудит для обоснованного решения о цифровизации
Наша команда с 2000 года занимается повышением эффективности предприятий в области оптимизации производства, логистики и цепочек поставок.
Мы выполняли проекты оптимизации процессов с Иркутской нефтяной компанией, ТНК-ВР, ТНК, Юганснефтегаз.
Нам доверяют лидеры отраслей: Норникель, Магнитогорский металлургический комбинат, КАМАЗ, Росэнергоатом, Казахмыс, Казцинк, Северсталь и многие другие. Отзывы это подтверждают.
Мы работаем по методике проведения экономико-цифрового аудита. Она проста и предназначена для выявления потерь, таких как:
1. простои производственных ресурсов,
2. необоснованные запасы,
3. различные браки и сбои,
4. повышенные затраты на разных этапах бизнес-процессов вашего предприятия.
Оформим реестр потерь и точек роста, выделим те, которые устраняются автоматизацией.
Потери не связанные с автоматизацией пойдут бонусом.
Очень важно правильно провести расчеты и представить полученную информацию руководству предприятия для принятия решения.
Наши выводы основаны на фактах: фотофакты, анализ статистики и замеров покажут реальные потери и возможности роста. Экономические эффекты в цифрах в пересчете на год. Наглядно показана окупаемость и за счет чего.
Мы привязываем наше вознаграждение к получению экономических эффектов.
Закажите экономико-цифровой аудит со скидкой 20%, с вами свяжется эксперт для обсуждения сроков и деталей
© ООО "АДД КОНСАЛТИНГ", 2018 — 2023
Все права защищены.
Технологии искусственного интеллекта для логистики и производства.
8 (495) 772-5555
Пн-Пт: 9:00 - 21:00Почтовый адрес:
119620, Москва, а\я №8
Адрес:
119620, Москва, а\я №8
Адрес:
м. Румянцево
Москва, Бизнес-центр Румянцево
Москва, Бизнес-центр Румянцево
