Разработка системы поддержки принятия решений в транспортной логистике: Структура и содержание курсовой работы

Введение, которое определяет контекст и актуальность курсовой работы

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

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

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

Данная курсовая работа посвящена решению именно этой проблемы.

Цель работы: разработка концептуальной модели системы поддержки принятия решений (СППР) для автоматизации и оптимизации процессов в транспортной логистике на предприятии малого или среднего бизнеса.

Для достижения поставленной цели необходимо решить следующие задачи:

1. Проанализировать теоретические основы СППР: их определение, классификацию, архитектуру и роль в логистике.
2. Изучить предметную область, проанализировав существующие бизнес-процессы управления грузоперевозками и выявив их недостатки.
3. Сформулировать детальные функциональные и нефункциональные требования к разрабатываемой системе.
4. Спроектировать архитектуру СППР, включая модель базы данных, ключевые алгоритмы обработки информации и пользовательский интерфейс.
5. Продемонстрировать работоспособность предложенного решения на практическом примере и описать методику его тестирования.

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

Глава 1. Теоретические основы, раскрывающие суть СППР в логистике

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

Определение и сущность СППР

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

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

Классификация и виды СППР

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

• Ориентированные на данные (Data-Driven): Предоставляют доступ к большим объемам внутренних и внешних данных, позволяя выполнять запросы и формировать отчеты.
• Ориентированные на модели (Model-Driven): Используют математические, статистические или финансовые модели для анализа ситуаций и поиска оптимальных решений.
• Ориентированные на знания (Knowledge-Driven): Содержат базу знаний и правила вывода для предоставления экспертных рекомендаций.
• Интеллектуальные СППР: Отдельная важная категория, которая активно развивается в последние годы. Такие системы классифицируются как интеллектуальные, если они основаны на методах искусственного интеллекта (ИИ), включая машинное обучение, нейронные сети и мультиагентные системы. Они способны не просто обрабатывать данные, а выявлять скрытые закономерности и самообучаться.

Архитектура и компоненты

Классическая архитектура СППР включает три основных компонента:

1. Подсистема данных: Это хранилище, которое содержит базу данных (БД) и базу знаний (БЗ). БД агрегирует структурированные данные из различных источников (внутренних и внешних), а БЗ — неструктурированную информацию, правила и эвристики.
2. Подсистема моделей: Ядро системы, включающее в себя библиотеку математических, статистических и оптимизационных моделей. Именно здесь происходит анализ данных, имитация сценариев «что если» и прогнозирование исходов.
3. Пользовательский интерфейс: Средство взаимодействия пользователя с системой. Качественный интерфейс должен быть интуитивно понятным, наглядным и позволять легко манипулировать данными и моделями.

Роль СППР в логистике

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

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

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

Анализ существующих решений

На рынке существует ряд готовых IT-решений для управления транспортной логистикой, от модулей в крупных ERP-системах (SAP, Oracle) до специализированных TMS (Transportation Management System). Их сильные стороны — надежность и широкий функционал. Однако у них есть и слабые стороны, особенно для малого и среднего бизнеса: высокая стоимость внедрения и поддержки, избыточность функций и низкая гибкость для адаптации под уникальные бизнес-процессы. Именно поэтому разработка собственной, кастомизированной СППР может быть более эффективным решением, когда готовые продукты не полностью удовлетворяют потребности компании.

Глава 2. Аналитическая часть, где мы исследуем предметную область

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

Описание объекта автоматизации

В качестве объекта автоматизации рассмотрим гипотетическое предприятие ООО «Транс-Логистик» — небольшую транспортную компанию, оперирующую на рынке региональных грузоперевозок.

• Автопарк: 15 автомобилей различной грузоподъемности (от 1.5 до 20 тонн).
• Штат: 3 логиста, 15 водителей, директор, бухгалтер.
• Основные услуги: Доставка сборных и генеральных грузов по городу и области.
• Документооборот: Ведется преимущественно в бумажном виде и с использованием электронных таблиц (Excel).

Анализ существующих бизнес-процессов («As Is»)

Рассмотрим текущий процесс обработки заказа на перевозку шаг за шагом:

1. Получение заявки: Логист принимает заявку от клиента по телефону или электронной почте. Информация (адрес, контакты, параметры груза) вручную вносится в журнал и таблицу Excel.
2. Подбор транспорта: Логист, основываясь на своем опыте и данных в таблице, подбирает свободный автомобиль подходящей грузоподъемности.
3. Построение маршрута: Маршрут прокладывается с помощью общедоступных онлайн-карт. Оптимизация нескольких точек доставки в одном рейсе происходит интуитивно.
4. Оформление документов: Выписываются путевой лист и товарно-транспортная накладная.
5. Контроль выполнения: Логист поддерживает связь с водителем по мобильному телефону для уточнения статуса и местоположения. Информация о выполнении заказа фиксируется по факту возвращения водителя.
6. Архивация: Бумажные документы подшиваются в архив, данные в Excel-файле сохраняются.

Выявление проблем и узких мест

Анализ текущего процесса «как есть» позволяет выявить ряд критических недостатков:

• Неоптимальное использование транспорта: Из-за отсутствия единой системы обзора и автоматического подбора часто возникают ситуации, когда для небольшого груза назначается крупнотоннажный автомобиль или, наоборот, транспорт простаивает. Это ведет к росту порожнего пробега и снижению рентабельности.
• Человеческий фактор: Ручной ввод данных в Excel и бумажные журналы неизбежно приводит к ошибкам, опечаткам и потере информации.
• Отсутствие прозрачности: У директора и самого логиста нет возможности в реальном времени видеть картину загрузки автопарка и статус выполнения всех текущих заказов.
• Низкая скорость реакции: Обработка каждой заявки требует значительного времени на рутинные операции, что замедляет работу и снижает качество клиентского сервиса.

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

Формулировка требований к СППР

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

Функциональные требования:

1. Система должна обеспечивать ведение единой базы данных клиентов, водителей и транспортных средств.
2. Должен быть реализован модуль создания и обработки заявок на перевозку с фиксацией всех необходимых параметров (груз, адреса, время).
3. Система должна автоматически подбирать оптимальное транспортное средство для заявки с учетом его грузоподъемности, доступности и местоположения.
4. Система должна автоматически строить оптимальный маршрут для рейса, включая возможность объезда нескольких точек.
5. Должна быть реализована возможность отслеживания статуса выполнения заявки в реальном времени.
6. Система должна генерировать стандартные отчеты (например, по выполненным рейсам, по пробегу, по рентабельности).

Нефункциональные требования:

• Интерфейс системы должен быть интуитивно понятным и не требовать длительного обучения.
• Система должна обеспечивать безопасное хранение данных и разграничение прав доступа для разных ролей (логист, директор).
• Время отклика системы на основные операции не должно превышать 2-3 секунд.

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

Глава 2. Проектная часть, в которой рождается архитектура системы

Этот раздел является ядром курсовой работы, где теоретические знания и результаты анализа преобразуются в конкретный технический проект. Мы представим высокоуровневую архитектуру будущей СППР, спроектируем ее ключевые компоненты: базу данных, подсистему обработки данных и пользовательский интерфейс.

Общая архитектура решения

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

• Серверная часть (Backend): Отвечает за всю бизнес-логику, обработку данных и взаимодействие с базой данных.
• База данных (БД): Централизованное хранилище всей информации о заявках, клиентах, транспорте и маршрутах.
• Клиентская часть (Frontend): Веб-интерфейс, с которым работают пользователи (логисты, руководители).
• Интеграционный модуль с ГИС: Модуль для взаимодействия с геоинформационными сервисами (например, Яндекс.Карты или Google Maps) для построения маршрутов и отображения транспорта на карте.

Проектирование базы данных

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

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

Ключевые таблицы:

1. Clients (Клиенты):
   • `id` (первичный ключ)
   • `name` (наименование компании)
   • `contact_person` (контактное лицо)
   • `phone`, `email`
2. Vehicles (Транспортные средства):
   • `id` (первичный ключ)
   • `model` (модель)
   • `license_plate` (гос. номер)
   • `capacity_kg` (грузоподъемность в кг)
   • `status` (статус: свободен, в рейсе, на ремонте)
3. Drivers (Водители):
   • `id` (первичный ключ)
   • `full_name` (ФИО)
   • `phone` (телефон)
   • `vehicle_id` (внешний ключ к таблице Vehicles)
4. Orders (Заявки):
   • `id` (первичный ключ)
   • `client_id` (внешний ключ к Clients)
   • `address_from`, `address_to` (адреса)
   • `cargo_description` (описание груза)
   • `cargo_weight_kg` (вес груза)
   • `status` (статус: новая, в работе, выполнена, отменена)
   • `assigned_vehicle_id` (назначенный транспорт)

Проектирование подсистемы обработки данных

Эта подсистема содержит «мозг» нашего решения — ключевые алгоритмы.

• Алгоритм подбора транспортного средства: При поступлении новой заявки система будет выполнять SQL-запрос к таблице `Vehicles`. Запрос будет отбирать все транспортные средства со статусом «свободен», у которых `capacity_kg` больше или равно `cargo_weight_kg` из заявки. Для выбора оптимального варианта будет использоваться критерий минимальной избыточной грузоподъемности, чтобы не гонять полупустой крупнотоннажный транспорт.
• Алгоритм оптимизации маршрута: После назначения транспорта система обращается к внешнему ГИС-сервису через API. В сервис передаются координаты точек загрузки и выгрузки. Для решения задачи коммивояжера (если точек несколько) могут быть применены эвристические методы, например, муравьиный алгоритм или более простые, такие как алгоритм ближайшего соседа. Результатом работы является оптимальная последовательность точек и рассчитанный километраж.

Проектирование пользовательского интерфейса (UI)

Интерфейс — это лицо системы. Он должен быть функциональным и удобным (UX). Разработаем макеты нескольких ключевых экранов.

Экран 1: Дэшборд логиста.

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

Экран 2: Форма создания/редактирования заявки.

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

Экран 3: Карточка рейса.

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

Спроектировав систему на бумаге, мы должны доказать ее работоспособность. Следующий шаг — продемонстрировать, как она работает на практике, на конкретном примере.

Глава 3. Практическая реализация и как провести ее тестирование

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

Выбор средств реализации

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

• Backend: Python с фреймворком Django или Flask. Этот выбор обусловлен скоростью разработки, большим количеством готовых библиотек и отличной поддержкой работы с API.
• Frontend: JavaScript с фреймворком React или Vue.js. Позволяет создавать современные, быстрые и интерактивные пользовательские интерфейсы.
• База данных: PostgreSQL. Надежная, бесплатная и мощная СУБД с поддержкой сложных запросов и геоданных.
• ГИС-интеграция: API Яндекс.Карт. Предоставляет качественные карты для РФ и СНГ, а также и��струменты для геокодирования и построения маршрутов.

Контрольный пример (сквозной сценарий)

Продемонстрируем работу системы на конкретном примере. Задача: принять, обработать и выполнить заявку на перевозку 10 тонн оборудования из пункта А (склад) в пункт Б (строительный объект).

1. Шаг 1: Создание заявки. Логист заходит в систему, нажимает «Создать заявку». В открывшейся форме он выбирает клиента из выпадающего списка, вводит адреса «А» и «Б», указывает в параметрах груза «Оборудование, 10 000 кг». (Здесь в курсовой работе приводится скриншот заполненной формы).
2. Шаг 2: Автоматический подбор транспорта. После сохранения заявки система анализирует автопарк. Допустим, есть два свободных автомобиля: «Газель» (1500 кг) и «КамАЗ» (12000 кг). Система отфильтровывает «Газель» как неподходящую по грузоподъемности и предлагает логисту назначить «КамАЗ». Логист подтверждает выбор.
3. Шаг 3: Построение маршрута. Система автоматически передает координаты пунктов А и Б в API Яндекс.Карт и получает оптимальный маршрут с учетом текущей дорожной обстановки. Маршрут отображается на карте в карточке рейса. (Приводится скриншот с картой и проложенным маршрутом).
4. Шаг 4: Выполнение и мониторинг. Водителю поступает уведомление о новом рейсе (в более продвинутой версии — через мобильное приложение). Логист на своем дэшборде видит, что статус автомобиля изменился на «В рейсе», и может отслеживать его движение по карте.
5. Шаг 5: Завершение рейса. По прибытии в пункт Б и выгрузке, водитель сообщает об этом логисту. Логист меняет статус заявки на «Выполнена». Вся информация о рейсе (километраж, время, исполнитель) сохраняется в архиве для последующего анализа и отчетности.

Тестирование системы

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

План тестирования:

Вид тестирования	Объект тестирования	Методика
Модульное тестирование	Отдельные функции: алгоритм подбора транспорта, функция расчета расстояния.	Написание автоматических тестов (unit-тестов), которые проверяют работу функций на заранее подготовленных наборах данных.
Интеграционное тестирование	Взаимодействие модулей: Frontend ↔ Backend, Backend ↔ БД, Backend ↔ ГИС API.	Проверка сквозного сценария (аналогичного контрольному примеру) на тестовом стенде. Проверка корректности передачи данных между компонентами.
Юзабилити-тестирование	Пользовательский интерфейс.	Привлечение потенциального пользователя (логиста), которому дается задание (например, создать 5 заявок) без предварительного обучения. Фиксируются все возникшие трудности и непонятные моменты.

Результаты тестирования

По итогам тестирования формируется отчет. Например: «В ходе модульного тестирования выявлена ошибка в алгоритме подбора транспорта при весе груза, точно равном грузоподъемности. Ошибка исправлена. Интеграционное тестирование показало стабильную работу системы. По результатам юзабилити-тестирования было решено сделать кнопку ‘Сохранить’ более заметной».

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

Заключение, которое подводит итоги и оформляет работу

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

Написание заключения

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

1. Напоминание о цели: Начать следует с повторения цели, поставленной во введении. Например: «Целью данной курсовой работы являлась разработка модели системы поддержки принятия решений для автоматизации транспортной логистики».
2. Перечисление результатов по задачам: Кратко перечислить, что было сделано для решения каждой задачи. «В ходе работы был проведен анализ теоретических основ СППР, что позволило определить их архитектуру и классификацию. Были исследованы бизнес-процессы гипотетической логистической компании, на основе чего выявлены ключевые проблемы и сформулированы требования к автоматизации. В проектной части была разработана архитектура информационной системы, спроектирована база данных и пользовательский интерфейс. Наконец, в практической части была продемонстрирована работоспособность системы на контрольном примере и описана методика ее тестирования».
3. Главный вывод: Сформулировать основной вывод о достижении поставленной цели. «Таким образом, цель курсовой работы достигнута: разработана и обоснована концептуальная модель СППР, способная решить основные проблемы ручного управления грузоперевозками в малом бизнесе».
4. Практическая значимость: Указать, в чем польза разработанного решения. «Практическая значимость работы заключается в том, что предложенная модель может быть использована в качестве основы для создания реального программного продукта, внедрение которого позволит повысить эффективность использования транспорта, снизить операционные издержки и минимизировать ошибки, связанные с человеческим фактором».
5. Направления для дальнейшего развития: Обозначить, как можно улучшить и развить проект в будущем. Например:
   • Разработка мобильного приложения для водителей с функциями навигации и обновления статусов.
   • Интеграция с бухгалтерскими системами (например, 1С) для автоматического выставления счетов.
   • Добавление модуля предиктивной аналитики для прогнозирования спроса на перевозки.

Оформление списка литературы

Список литературы должен быть оформлен строго по ГОСТу. Все источники нумеруются и располагаются в алфавитном порядке.

Пример оформления книги:
Иванов, И. И. Логистика и управление цепями поставок : учебник / И. И. Иванов. – Москва : ИНФРА-М, 2023. – 350 с.

Пример оформления статьи из журнала:
Петров, П. П. Применение СППР в транспортных задачах / П. П. Петров // Вестник транспорта. – 2022. – № 4. – С. 25-31.

Пример оформления электронного ресурса:
Системы управления транспортом (TMS): что это, функции, преимущества [Электронный ресурс]. – Режим доступа: https://example.com/tms-guide (дата обращения: 20.08.2025).

Оформление приложений

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

• Листинги программного кода ключевых модулей.
• Полная схема базы данных (ER-диаграмма).
• Подробные результаты тестирования в виде таблиц.
• Большие диаграммы бизнес-процессов (BPMN).

Финальная вычитка и проверка

Перед сдачей работы необходимо провести самопроверку по следующему чек-листу:

1. Содержание: Все разделы (введение, главы, заключение, список литературы, приложения) на месте и соответствуют плану.
2. Орфография и пунктуация: Текст проверен на наличие ошибок.
3. Форматирование: Шрифт, интервалы, отступы, заголовки соответствуют методическим указаниям вашего вуза.
4. Нумерация: Страницы, рисунки, таблицы, формулы пронумерованы сквозным образом и корректно.
5. Ссылки: Все ссылки на источники в тексте соответствуют позициям в списке литературы.

Список использованных источников, который соответствует академическим требованиям

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

1. Аникин, Б. А. Логистика и управление цепями поставок. Теория и практика : учебник / под ред. Б. А. Аникина, Т. А. Родкиной. – Москва : Проспект, 2022. – 328 с.
2. Балдин, К. В. Информационные системы в экономике : учебник / К. В. Балдин, В. Б. Уткин. – 8-е изд. – Москва : Дашков и К°, 2021. – 394 с.
3. Гаджинский, А. М. Логистика : учебник / А. М. Гаджинский. – 24-е изд. – Москва : Дашков и К°, 2023. – 426 с.
4. Ларионов, В. Г. Методы и модели поддержки принятия решений в логистике / В. Г. Ларионов // Логистика сегодня. – 2024. – № 1. – С. 45-52.
5. Что такое TMS-система и как она помогает бизнесу [Электронный ресурс]. – Режим доступа: https://some-logistics-portal.com/articles/what-is-tms (дата обращения: 18.08.2025).

Список использованной литературы

1. Баронов В.В. Информационные технологии и управление предприятием / В.В. Баронов, Г.Н. Кальянов, Ю.Н. Попов, И.Н. Титовский. — М.: АйТи, 2009. — 328 с.
2. Гаврилова Т.А. Базы данных интеллектуальных систем / Т.А. Гаврилова, В.Ф. Хорошевский. — СПб: Питер, 2000. — 384 с. О размещении заказов для государственных и муниципальных нужд : федер. закон 94-ФЗ.
3. Дидковский В.М. Организационное и экономическое обеспечение подготовки и проведения подрядных торгов / В. М. Дидковский // Экономика строительства. – 2003. – № 8. – С. 3–11.
4. Дидковский В.М. Оценка коммерческих предложений участников подрядных торгов / В. М. Дидковский // Экономика строительства. – 2005. – № 5. – С. 17–27.
5. Иванец В. К. Опыт корпоративных конкурсных торгов / В. К. Иванец, А. И. Резник, Н. И. Жильченко // Экономика строительства. – 2003. – № 9. – С. 17–28.
6. Ириков В.А., Тренев B.H. Распределенные системы принятия решений. — M.: Наука, 1999.
7. Организация и проведение подрядных торгов в строительстве : науч. и учеб.-метод. справ. пособие / А. Н. Асаул [и др.]. – СПб. : Гуманиcтика, 2004. – 240 с.
8. Практика проведения конкурсов для строительства объектов электроэнергетики / В. В. Кумин [и др.] // Экономика строительства. – 2003. – № 9. – С. 2–16.
9. Трахтенгерц Э.А. Субъективность в компьютерной поддержке управленческих решений. — M.: СИНТЕГ, 2002
10. Уайт О. У. Управление производством и материальными запасами в век ЭВМ. — М.: Прогресс. 1978. – 302 с.
11. Семененко А.И. Логистика. Основы теории / А.И. Семененко, В.И. Сергеев. — СПб: Союз, 2003. — 544 с.