1. Есть файл с адресами торговых точек (на самом деле, с координатами GPS)
2. Есть список агентов (N штук)
3. Необходимо поделить город на N непересекающихся областей, границы которых проходят обязательно по дорогам общего пользования (но не по внутриквартальным проездам). При этом в каждой из N областей должно быть примерно одинаковое (+-10%) количество точек.
К транспорту привязку не делали. Область у каждого агента получается компактная. Агент едет до своей вотчины на личном или общественном транспорте, и дальше перемещается по ней на своих двоих.
Думаю, что с небольшими переделками это может сработать и для курьеров.
Лично я за генерацию заданий. Тем более, что минусы относительно легко оптимизируются.
1. Оut-of-order execution. В момент, когда трак запрашивает следующее задание — система просматривает tasklist на заданную глубину, и выбирает такое задание, которое требует минимального холостого пробега трака от последнего зафиксированного местоположения. Плюс некий механизм дедлайна, чтобы задание из «неудобной» ячейки не могло обходиться траком бесконечно.
2. Alternative tasks. Если необходимый товар лежит на нескольких подходящих местах, то создается не одна задача на переноску, а несколько связанных альтернативных задач: «Взять с места А; Взять с места B; Взять с места C». При запросе траком следующей задачи, система выбирает из нескольких альтернатив ту, которую можно исполнить с минимальным пробегом, назначает ее траку, а остальные альтернативы уничтожает.
Основным критерием является минимальная стоимость (!) маршрута доставки. А уже она складывается из: — Затрат на 1 км (ГСМ+износ агрегатов) — Затрат на 1 час (рабочее время водителя) — Вероятных потерь (возвраты из-за недоставки)
Километраж и время — это важно, но вторично. Я лично видел ситуацию, когда оптимальный по времени и пробегу маршрут оказывался на 20% дороже оптимального по цене.
Мы внедряем «Л:Т» ( http://transport.bit-integro.ru ) — там можно не подбирать параметры время/стоимость, а задавать в качестве целевой функции полную стоимость доставки.
Время — это реально важно. Для одной организации время доставки определялось по двухэтажной формуле с учетом: — тоннажа — количества наименований — вида продукции (штуки, упаковки) — планового простоя в очереди на разгрузку — наличия/отстутствия приема денег — к/та индивидуальной вредности клиента — к/та индивидуальной пронырливости экспедитора — признака свой/не свой район для экспедитора
Задача на 10-15 машин и 200-280 точек доставки по городу-миллионнику считается 15-20 минут.
Экономический эффект от внедрения на 10 машин: 300-600 тысяч рублей в год.
Без текста обсуждаемого договора рекомендации давать тяжело. Предполагаю, что текущую ситуацию можно описать следующим образом: — Никто не может точно оценить перечень необходимых работ, сроки и стоимость проекта — У заказчика нет уверенности, что он получит именно то, что хочет — У исполнителя нет уверенности, что заказчик не захочет невозможного — В договоре заказчику предлагается сначала купить софт, потом заплатить за доработки, а потом получить результат.
Я бы рекомендовал сделать следующее:
1. Цену в договоре не прописывать. Использовать формулировку: «вознаграждение исполнителя определяется на основании ежемесячно оформляемых актов выполненных работ». Ориентировочный бюджет проекта, сроки, и базовые требования к результатам записать в приложение к договору (в устав проекта)
2. Там же определить рабочую группу, отвечающую за ведение проекта (со стороны заказчика обязательны предметные специалисты и руководитель в ранге руководителя департамента). Обязать ее проводить рабочие совещения не реже 1 раза в две недели. Эта же группа должна готовить проекты ежемесячных актов выполненных работ.
3. Если проект предусматривает приобретение лицензий — установить следующее: — Либо лицензии оплачиваются в конце проекта — после того как он будет признан успешным — Либо в случае неуспеха проекта исполнитель обязуется выкупить лицензии по их первоначальной стоимости — Либо, в случае неуспеха проекта, исполнитель передает в дополнение к лицензиям полный набор исходных текстов созданного/модифицированного программного продукта, чтобы заказчик мог самостоятельно завершить проект.
В целом, такая стратегия позволяет управлять рисками по ходу исполнения договора, постепенно уточняя и согласовывая требования сторон. С другой стороны, если выяснится, что интересы сторон не могут быть согласованы (а это выяснится в первые 1-2 месяца) — потери в денежном выражении будут не такие большие.
С другой стороны, и исполнитель не может оказаться в ситуации, когда за какую-то первоначальную сумму денег ему бесконечно предлагают доделывать и переделывать программное обеспечение не подписывая акт приемки системы. Текущие расходы на доработки будут оплачены в любом случае на основании ежемесячных актов выполненных работ. А реальную прибыль (деньги за лицензии, и т.д.) он получит только по завершении проекта.
1. Сесть и написать, каким должно быть светлое будущее. То есть, пока не привязываясь к конкретному оборудованию и ПО, накидать идеальный производственный процесс склада. Особенно обращать внимание на то, какие знания и умения вы оставляете у людей, а какие — отделяете от носителей и закладываете в виде алгоритмов в планируемую WMS. В принципе, у каждого поставщика WMS есть своя точка зрения на этот вопрос. По странному совпадению, их светлое будущее проще всего реализуется именно с помощью их WMS-ки. Поэтому я предпочел бы сформировать собственное мнение на этот счет до того, как мне начнут промывать мозги специалисты отделов продаж. Иначе не технология работы склада начнет диктовать алгоритмы работы WMS, а наоборот. :-(
2. Написать объективные требования (текущие и перспективные) к производительности склада (средняя и пиковая скорости приемки, размещения, комплектовки, отгрузки). В дальнейшем, это позволит контролировать интегратора решения по лимитам времени на индивидуальные операции. В моей практике был случай, когда бизнес-процесс склада пошел вразнос только из-за того, что примененная система этикирования продукции давала одну этикетку за 5 секунд, а надо было не более чем за 3.
