Лекция 2.5. Интеграция логистики: сквозные цепи поставок, инструменты

Содержание

• Лекция 2.5. Интеграция логистики: сквозные цепи поставок, инструменты
  • Содержание
  • Такт, время цикла и производственный анализ
    • От такта операции к ритму цепи
    • Почему это ведёт к интеграции
  • Проблема фрагментарной логистики
    • Сущность проблемы
    • Признаки фрагментарности
    • Последствия
  • Интегрированная логистика
    • Уровни интеграции
  • Интеграция внутренней и внешней логистики
    • Внутренняя интеграция
    • Внешняя интеграция
  • Стратегии развития и управление интеграцией
    • Стратегии интеграции
    • Управление интеграцией
  • Преимущества интегрированной логистики
    • Экономические преимущества
    • Операционные преимущества
  • Принципы построения сквозных логистических цепей
  • SCOR-модель: эталонная модель цепи поставок
    • Пять базовых процессов SCOR
    • Иерархия метрик SCOR
    • Атрибуты производительности и метрики уровня 1
    • DCOR-модель и конфигурирование цепи поставок
  • EDI-интеграция и сравнение EDI с API
  • Инструменты интеграции API и JSON
    • Роль API в интеграции логистических систем
    • JSON как формат обмена данными
    • Основные типы API в логистике
    • Интеграция через API: примеры использования
    • Облачные платформы для логистической интеграции
    • Схема интеграции через облачный API
    • Безопасность API
    • Ключевые преимущества API-интеграции
  • Синхронизация модулей имитационной модели
    • Модули модели
    • Визуализация сквозного потока
  • Анализ сценариев
    • Типы сценариев
    • Стресс-тестирование
  • Применение на машиностроительном предприятии
  • Связь с лабораторной работой
  • Ключевые выводы по лекции
  • Контрольные вопросы
  • Рекомендуемая литература

Такт, время цикла и производственный анализ

Вспомним основы (лекция 1.4). Полный разбор понятий такта и времени цикла, взаимосвязи цикла и такта, производственного анализа и числовых примеров рассогласования приведён в лекции 1.4, раздел «Такт, время цикла и производственный анализ». Напомним ключевое:

• Такт (takt time) — требуемый интервал выпуска единицы продукции, задаваемый спросом: $Такт = \frac{Доступное\ время}{Потребность\ спроса}$
• Время цикла (cycle time) — фактический интервал между выпуском двух последовательных единиц на операции; определяется возможностями операции и является объектом управления
• Ключевое правило: цикл больше такта — операция становится «узким мест»; цикл меньше такта — операция простаивает
• Производственный анализ — сопоставление фактических циклов всех звеньев с тактом для выявления узких мест, простоев и резервов

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

От такта операции к ритму цепи

В лекции 1.4 рассогласование тактов и циклов разобрано на уровне операций внутри предприятия (таблица типовых потерь, числовой пример с узким местом сборки, способы выравнивания — см. лекцию 1.4, разделы «Как рассогласование тактов и циклов создаёт потери», «Числовой пример» и «Способы выравнивания тактов»). Здесь важен следующий шаг: те же закономерности действуют на уровне всей цепи поставок, где звенья принадлежат разным организациям и согласовать их ритмы административным приказом уже нельзя.

Ключевое отличие: если внутри предприятия узкое место можно «разогнать» перераспределением ресурсов, то в межорганизационной цепи (поставщик электронных компонентов → транспорт → склад → производство → отгрузка заказчику) ритм каждого звена задаётся его собственными интересами и ограничениями. Поставщик гонит партию крупным объёмом ради своей экономии, перевозчик ждёт накопления груза, производство работает по своему графику — в результате «пробка» запасов возникает уже не между цехами, а между юридическими лицами, и ни один участник не видит её целиком. Именно поэтому согласование ритмов цепи требует не балансировки линий, а интеграционных инструментов: общего информационного пространства и совместного планирования.

Почему это ведёт к интеграции

Рассогласование тактов внутри предприятия лечится балансировкой линий (методы — в лекции 1.4), а рассогласование ритмов между звеньями цепи (поставщик → склад → производство → отгрузка) требует согласованного управления всей цепью — то есть интегрированной логистики: EDI, VMI, CPFR и API-обмена данными в реальном времени. Именно эти инструменты мы рассмотрим далее в этой лекции.

Проблема фрагментарной логистики

Сущность проблемы

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

Признаки фрагментарности

• Закупки закупают по графику поставщика, а не производства
• Производство производит по плану, а не по спросу
• Сбыт продаёт без учёта производственных мощностей
• Склад хранит избыточные запасы «на всякий случай»
• Транспорт работает с недогрузом

Последствия

Интегрированная логистика

Интегрированная логистика — объединение и координация функциональных областей и участников логистической цепи для эффективного управления материальными, информационными и финансовыми потоками.

Уровни интеграции

---
config:
  look: handDrawn
  theme: neutral
---
flowchart TD
    A[Уровни интеграции логистики] --> B
    
    subgraph B[Уровень 1: Функциональная интеграция]
        B1[Автоматизация отдельных функций<br>WMS, TMS]
    end
    
    B --> C
    
    subgraph C[Уровень 2: Внутренняя интеграция]
        C1[Интеграция подразделений предприятия<br>ERP-система]
    end
    
    C --> D
    
    subgraph D[Уровень 3: Внешняя интеграция]
        D1[Интеграция с поставщиками и клиентами<br>EDI, порталы]
    end
    
    D --> E
    
    subgraph E[Уровень 4: Стратегическая интеграция]
        E1[Совместное планирование с ключевыми клиентами<br>и поставщиками VMI, CPFR]
    end

Интеграция внутренней и внешней логистики

Внутренняя интеграция

Цель: Координация подразделений предприятия

Инструменты:

• ERP-система (единая база данных)
• Сбалансированная система показателей (BSC)
• Кросс-функциональные команды

Пример:

• Закупки, производство, логистика работают в единой ERP
• Общие KPI для всех подразделений
• Еженедельные совещания по координации

Внешняя интеграция

Цель: Координация с участниками цепи поставок

Инструменты:

• VMI (Vendor Managed Inventory) — поставщик управляет запасами клиента
• CPFR (Collaborative Planning, Forecasting, Replenishment) — совместное планирование
• EDI (Electronic Data Interchange) — электронный обмен данными

Пример:

• Поставщик видит запасы клиента в реальном времени
• Автоматическая генерация заказов при достижении точки заказа
• Совместное прогнозирование спроса

Стратегии развития и управление интеграцией

Стратегии интеграции

Управление интеграцией

Этапы:

1. Анализ текущего состояния
   • Аудит процессов
   • Выявление «информационных островов»
2. Разработка целевой модели
   • Определение уровня интеграции
   • Выбор инструментов
3. Внедрение
   • Поэтапная реализация
   • Обучение персонала
4. Контроль и корректировка
   • Мониторинг KPI
   • Непрерывное улучшение

Преимущества интегрированной логистики

Экономические преимущества

Операционные преимущества

• Сокращение времени выполнения заказа на 30–50%
• Повышение оборачиваемости запасов на 40–60%
• Увеличение OTIF до 95–98%
• Снижение уровня запасов на 20–40%

Принципы построения сквозных логистических цепей

Вспомним основы (лекция 1.8). Четыре ключевых принципа построения сквозной цепи — единство управления, информационная прозрачность, синхронизация процессов и партнёрские отношения — вместе с общей схемой цепи «поставщик → … → клиент» разобраны в лекции 1.8, раздел «Принципы построения сквозной логистической цепи». Здесь мы не повторяем их, а переходим к практической реализации принципов на конкретном машиностроительном предприятии.

Ниже сквозная цепь АО «Ракета» рассмотрена по этапам с указанием информационных потоков, связывающих их в единую систему, — то есть показано, как принципы из лекции 1.8 «приземляются» на реальные бизнес-процессы и ИТ-системы.

Этапы сквозной цепи и их параметры:

---
config:
  look: handDrawn
  theme: neutral
---
flowchart LR
    A[1. Закупки<br>ERP/MRP] --> B[2. Склад<br>обеспечения<br>WMS]
    B --> C[3. Передел 1<br>микросборка<br>MES]
    C --> D[4. Передел 2<br>агрегаты<br>MES]
    D --> E[5. Передел 3<br>сборка и ОТК<br>MES/QMS]
    E --> F[6. Склад ГП<br>WMS]
    F --> G[7. Отгрузка<br>TMS]
    G --> K[Заказчик<br>госконтракт]

    B -.->|остатки| A
    D -.->|статус ограничения| C
    E -.->|паспорта качества| G

    style A fill:#f9f,stroke:#333,stroke-width:2px
    style G fill:#f96,stroke:#333,stroke-width:2px

Ключевые точки интеграции:

1. Закупки ↔ склад — план потребности (MRP) автоматически сверяется с фактическими остатками WMS; заказ поставщику формируется при достижении точки заказа (см. лекцию 1.3).
2. Склад ↔ передел 1 — выдача материалов в производство по производственному заданию; тянущий сигнал ограничения (метод DBR, см. лекцию 1.4).
3. Переделы 1 → 2 → 3 — передача полуфабрикатов с контролем тактов; буфер перед ограничением (передел 2).
4. Передел 3 ↔ склад ГП ↔ отгрузка — приёмка ОТК формирует паспорт качества, без которого отгрузка по государственному контракту невозможна; комплектация заказов синхронизируется с темпами отгрузки.

Сквозной информационный поток: единый идентификатор заказа по государственному контракту проходит через все системы (ERP → WMS → MES → QMS → TMS), обеспечивая прослеживаемость от закупки конкретной партии электронных компонентов до отгрузки готового изделия. Разрыв этого идентификатора — типичный признак фрагментарной логистики.

SCOR-модель: эталонная модель цепи поставок

SCOR (Supply Chain Operations Reference) — эталонная модель процессов цепи поставок, разработанная Советом по цепям поставок (Supply Chain Council). Модель обеспечивает единый язык описания, измерения и совершенствования сквозных процессов — от поставщика поставщика до клиента клиента. В курсе SCOR рассматривается по источнику Крылатков П. П., Прилуцкая М. А. «Управление цепью поставок» (см. раздел «Рекомендуемая литература»).

Пять базовых процессов SCOR

---
config:
  look: handDrawn
  theme: neutral
---
flowchart TD
    P[Plan<br>Планирование] --> S[Source<br>Закупки]
    P --> M[Make<br>Производство]
    P --> D[Deliver<br>Доставка]
    S --> M
    M --> D
    D --> R[Return<br>Возвраты]
    R -.-> S
    R -.-> M

    style P fill:#f9f,stroke:#333,stroke-width:2px
    style R fill:#f96,stroke:#333,stroke-width:2px

Плановый процесс (Plan) координирует все остальные: Source, Make, Deliver; процесс Return (обратная логистика) замыкает цепь, возвращая потоки в Source и Make (подробнее — в лекции 2.4).

Иерархия метрик SCOR

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

Правило декомпозиции: метрика уровня 1 раскладывается на метрики уровня 2 по сегментам цепи, а те — на процессные метрики уровня 3. Например, «надёжность поставок» (уровень 1) → «доля заказов, отгруженных в срок по сегментам» (уровень 2) → «точность комплектации на складе ГП» (уровень 3).

Атрибуты производительности и метрики уровня 1

Каждой цепи соответствуют пять атрибутов производительности; метрики уровня 1 группируются по этим атрибутам:

Расчётный пример (метрика уровня 1 «надёжность»). Perfect Order Fulfillment (POF) — доля заказов, выполненных одновременно: в срок, в полном объёме, без повреждений и с корректными документами:

Пример. По данным отгрузок АО «Ракета» за квартал: всего 40 отгрузок по государственному контракту; в срок — 38; в полном объёме — 39; с корректными документами (паспорт качества, акты приёмки представителем заказчика) — 40; без повреждений — 40. Идеальных (по всем четырём критериям одновременно): 36.

\[POF = \frac{36}{40} \cdot 100\% = 90\%\]

Вывод: надёжность цепи 90% — ниже целевого уровня 95–98% для промышленного предприятия. Декомпозиция показывает, что основные потери — в критериях «в срок» (2 отклонения) и «в полном объёме» (1 отклонение) → целевое улучшение — синхронизация производства с темпами отгрузки (процессы Plan и Deliver).

DCOR-модель и конфигурирование цепи поставок

DCOR (Design Chain Operations Reference) — расширение SCOR для процессов проектирования и разработки новой продукции. Если SCOR описывает цепь поставок существующего продукта, DCOR описывает цепь разработки: управление проектами, портфелем разработок, данными об изделии, интеграцию поставщиков в разработку.

Конфигурирование цепи поставок (по Крылаткову) — процедура приведения структуры и параметров цепи в соответствие с рыночной стратегией. Этапы:

1. Сегментация цепи — выделение сегментов «продукт — рынок» с разными требованиями к сервису.
2. Выбор стратегии для сегмента — «эффективная» цепь (минимум затрат) для стабильного спроса или «отзывчивая» цепь (скорость, гибкость) для изменчивого спроса.
3. Настройка параметров — размещение запасов, уровни сервиса, выбор транспорта, размещение производства и складов.
4. Согласование с SCOR-метриками — установка целевых значений метрик уровней 1–3 для каждого сегмента.

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

EDI-интеграция и сравнение EDI с API

EDI (Electronic Data Interchange) — электронный обмен деловыми документами между информационными системами партнёров по стандартизированным форматам. Исторически первый массовый инструмент внешней интеграции, до сих пор доминирующий в ритейле, транспорте и крупных промышленных цепях поставок.

Стандарты EDI:

Типовые сообщения EDI в логистике:

• ORDERS — заказ поставщику
• DESADV — уведомление об отгрузке (ASN)
• INVOIC — счёт
• IFTSTA / IFTMBF — статус перевозки, подтверждение бронирования
• RECADV — подтверждение получения товара

---
config:
  look: handDrawn
  theme: neutral
---
sequenceDiagram
    participant E as ERP заказчика
    participant P as EDI-провайдер<br>(VAN/AS2)
    participant S as ERP поставщика
    E->>P: ORDERS (заказ на электронные компоненты)
    P->>S: ORDERS (стандартизированный формат)
    S-->>P: DESADV (уведомление об отгрузке)
    P-->>E: DESADV
    S-->>P: INVOIC (счёт)
    P-->>E: INVOIC
    E-->>P: RECADV (подтверждение приёмки)
    P-->>S: RECADV

Сравнение EDI и API — двух поколений интеграции:

Практический вывод: EDI и API не конкурируют, а дополняют друг друга. EDI остаётся стандартом для юридически значимого документооборота и обмена с крупными партнёрами (сети, транспортные операторы, госсектор), а API — для оперативного обмена данными в реальном времени и интеграции внутренних систем. Современная интеграционная архитектура предприятия использует оба инструмента через единый интеграционный шлюз (ESB/iPaaS).

Инструменты интеграции API и JSON

Роль API в интеграции логистических систем

API (Application Programming Interface) — набор протоколов и инструментов для взаимодействия различных программных приложений. В логистике API обеспечивает обмен данными между WMS, TMS, ERP и системами партнёров в реальном времени.

JSON как формат обмена данными

JSON (JavaScript Object Notation) — лёгкий формат обмена данными, читаемый как человеком, так и машиной. Широко используется в API для передачи логистических данных.

Пример JSON-структуры заказа:

{
  "order_id": "ORD-2024-001",
  "customer": {
    "id": "CUST-123",
    "name": "ООО «ТрансЛогистик»",
    "address": "г. Екатеринбург, ул. Логистическая, 1"
  },
  "items": [
    {
      "sku": "PROD-001",
      "name": "Оборудование А",
      "quantity": 50,
      "weight_kg": 250.0
    },
    {
      "sku": "PROD-002",
      "name": "Комплектующие Б",
      "quantity": 200,
      "weight_kg": 100.0
    }
  ],
  "shipping": {
    "method": "rail",
    "carrier": "РЖД",
    "estimated_delivery": "2024-06-15",
    "tracking_number": "RD-123456789"
  },
  "total_weight_kg": 350.0,
  "status": "in_transit"
}

Основные типы API в логистике

Интеграция через API: примеры использования

1. Отслеживание грузов в реальном времени

---
config:
  look: handDrawn
  theme: neutral
---
flowchart LR
    A[ERP-система] -->|GET /shipment/id| B[API трекера]
    B -->|JSON: статус, координаты| A
    C[Клиент] -->|Запрос статуса| D[Веб-портал]
    D -->|GET /tracking/id| B
    B -->|JSON: данные трекинга| D

Пример API-запроса:

GET https://api.logistics.example/v1/shipments/ORD-2024-001
Authorization: Bearer <token>
Content-Type: application/json

Ответ сервера:

{
  "shipment_id": "ORD-2024-001",
  "status": "in_transit",
  "current_location": {
    "lat": 56.8389,
    "lon": 60.6058,
    "city": "Екатеринбург"
  },
  "estimated_delivery": "2024-06-15T14:00:00Z",
  "events": [
    {
      "timestamp": "2024-06-12T08:00:00Z",
      "status": "picked_up",
      "location": "Москва"
    },
    {
      "timestamp": "2024-06-13T12:00:00Z",
      "status": "in_transit",
      "location": "Екатеринбург"
    }
  ]
}

2. Синхронизация запасов между складами

---
config:
  look: handDrawn
  theme: neutral
---
flowchart TD
    A[Склад 1 - WMS] -->|PUT inventory| B[Общий API-шлюз]
    C[Склад 2 - WMS] -->|PUT inventory| B
    D[ERP-система] -->|GET inventory| B
    B -->|JSON: остатки| D
    E[Поставщик] -->|GET forecast| B
    B -->|JSON: прогноз| E

3. Автоматический расчёт стоимости доставки

POST https://api.logistics.example/v1/rates/calculate
Content-Type: application/json

{
  "origin": {
    "city": "Москва",
    "postal_code": "101000"
  },
  "destination": {
    "city": "Екатеринбург",
    "postal_code": "620000"
  },
  "cargo": {
    "weight_kg": 500,
    "volume_m3": 2.5,
    "type": "general"
  },
  "service_type": "express"
}

Ответ:

{
  "rate_id": "RT-2024-456",
  "options": [
    {
      "carrier": "Деловые Линии",
      "service": "standard",
      "price_rub": 45000,
      "transit_days": 3,
      "currency": "RUB"
    },
    {
      "carrier": "ПЭК",
      "service": "express",
      "price_rub": 72000,
      "transit_days": 1,
      "currency": "RUB"
    }
  ]
}

Облачные платформы для логистической интеграции

Схема интеграции через облачный API

---
config:
  look: handDrawn
  theme: neutral
---
flowchart LR
    subgraph Клиенты
        A[ERP]
        B[WMS]
        C[TMS]
    end
    
    subgraph Облачный API-шлюз
        D[API Gateway]
        E[Аутентификация<br>OAuth 2.0 / JWT]
        F[Rate Limiting]
        G[Логирование]
    end
    
    subgraph Микросервисы
        H[Сервис заказов]
        I[Сервис отслеживания]
        J[Сервис расчёта]
        K[Сервис аналитики]
    end
    
    A & B & C --> D
    D --> E --> F --> G
    G --> H & I & J & K
    
    H & I & J & K --> L[(Облачная<br>база данных)]
    
    style D fill:#f96,stroke:#333,stroke-width:3px
    style E fill:#f9f,stroke:#333,stroke-width:2px
    style L fill:#6cf,stroke:#333,stroke-width:2px

Безопасность API

Ключевые преимущества API-интеграции

1. Реальное время — обмен данными без задержек
2. Автоматизация — исключение ручного ввода данных
3. Масштабируемость — лёгкое добавление новых партнёров
4. Гибкость — возможность быстрой замены компонентов системы
5. Прозрачность — полная видимость цепочки поставок

Синхронизация модулей имитационн��й модели

Модули модели

1. Модуль закупок

• Генерация заказов поставщикам
• Контроль сроков поставки

2. Модуль склада материалов

• Приёмка и размещение
• Выдача в производство

3. Модуль производства

• Планирование операций
• Контроль выполнения

4. Модуль склада ГП

• Приёмка готовой продукции
• Комплектация заказов

5. Модуль отгрузки

• Планирование транспорта
• Отгрузка клиентам

Визуализация сквозного потока

---
config:
  look: handDrawn
  theme: neutral
---
flowchart LR
    A[Закупки] --> B[Склад]
    B --> C[Производство]
    C --> D[Склад ГП]
    D --> E[Отгрузка]
    
    A --> F[План]
    B --> G[Приёмка]
    C --> H[Запуск]
    D --> I[Отгрузка]
    E --> J[Доставка]
    
    style F fill:#f9f,stroke:#333,stroke-width:2px
    style G fill:#ccf,stroke:#333,stroke-width:2px
    style H fill:#9f9,stroke:#333,stroke-width:2px
    style I fill:#f96,stroke:#333,stroke-width:2px
    style J fill:#6cf,stroke:#333,stroke-width:2px

Анализ сценариев

Типы сценариев

Стресс-тестирование

Цель: Оценка устойчивости системы к экстремальным сценариям.

Пошаговый алгоритм стресс-тестирования:

1. Выбор сценария — определение типа стресса (рост спроса, срыв поставок, поломка оборудования, логистический кризис)
2. Задание параметров — установка величины отклонения (например, +50% спроса, задержка на 14 дней)
3. Запуск имитационной модели — прогон сквозной цепи через все модули (закупки → склад → производство → отгрузка)
4. Сбор результатов — фиксация показателей: простой, срывы отгрузок, дефицит, дополнительные затраты
5. Анализ уязвимостей — выявление «слабых звеньев» цепи (где система не справляется первой)
6. Выработка рекомендаций — определение мер: увеличение страхового запаса, поиск альтернативных поставщиков, резервирование мощностей

Пример:

• Сценарий: задержка поставки на 14 дней
• Результат: простой производства 5 дней, срыв отгрузок на 10 млн руб.
• Рекомендация: увеличить страховой запас с 7 до 10 дней

Применение на машиностроительном предприятии

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

Особенности интеграции на промышленном предприятии:

Целевая архитектура интеграции АО «Ракета»:

---
config:
  look: handDrawn
  theme: neutral
---
flowchart TD
    subgraph Внутренний контур предприятия
        ERP[1С:ERP<br>планирование, учёт по госконтрактам]
        MES[MES<br>цеховое управление]
        WMS[WMS<br>склады материалов и ГП]
        QMS[QMS<br>качество, приёмка представителем заказчика]
        TMS[TMS<br>транспорт, отгрузка]
    end

    ESB[Интеграционная шина<br>защищённый корпоративный контур]

    SUP[Системы поставщиков электронных компонентов] -->|EDI/API через шлюз| ESB
    GOS[Порталы заказчика<br>ЕИС, отчётность по госконтракту] -->|регламентный обмен| ESB
    ERP <--> ESB
    MES <--> ESB
    WMS <--> ESB
    QMS <--> ESB
    TMS <--> ESB

    style ESB fill:#f96,stroke:#333,stroke-width:3px

Принципы построения интеграции на промышленном предприятии:

1. Единый идентификатор заказа по государственному контракту — сквозной ключ, связывающий закупку партии электронных компонентов, производственные операции, акты приёмки и отгрузочные документы.
2. Раздельный учёт по контрактам — каждая операция в WMS/MES несёт признак контракта; ERP формирует отчётность по себестоимости государственного контракта.
3. Защищённый корпоративный контур — обмен с внешними участниками только через сертифицированные шлюзы; журналирование всех транзакций.
4. Прослеживаемость партий комплектующих — от входного контроля на складе обеспечения до установки в конкретное изделие (требование приёмки).

Связь с лабораторной работой

Материал лекции является теоретической основой лабораторной работы «Проектирование сквозной логистической цепи» (семестр 2, выполняется в Python: SimPy, matplotlib, pandas).

Рекомендации по выполнению: каждый модуль модели SimPy реализуйте как отдельный ресурс с очередью; между модулями задайте буферы (ёмкости накопителей), соответствующие рассчитанным в семестре 1 запасам; в качестве выходных метрик фиксируйте POF (долю идеальных заказов), длительность сквозного цикла и средний уровень запасов — это метрики SCOR уровней 1–2. Результаты экспериментов с вариабельностью поставок сопоставьте с расчётами страховых запасов из лекции 1.3.

Ключевые выводы по лекции

1. Фрагментарная логистика приводит к избыточным запасам, простоям, срывам отгрузок.
2. Интегрированная логистика объединяет участников цепи для управления потоками.
3. Уровни интеграции: функциональный, внутренний, внешний, стратегический.
4. Инструменты внешней интеграции: VMI, CPFR, EDI, API.
5. API и JSON — современные инструменты обмена данными между логистическими системами.
6. Преимущества интеграции: снижение затрат, повышение эффективности, улучшение видимости.
7. Принципы сквозной цепи: единство управления, прозрачность, синхронизация, партнёрство.
8. Такт задаётся спросом, время цикла — возможностями операции; рассогласование тактов и циклов создаёт узкие места, простои и запасы.
9. Производственный анализ выявляет узкие места и резервы через сопоставление циклов всех звеньев с тактом.
10. Облачные платформы (AWS, Azure, GCP, Yandex Cloud) обеспечивают масштабируемую инфраструктуру для логистической интеграции.
11. Анализ сценариев помогает оценить устойчивость системы к сбоям.
12. SCOR-модель описывает цепь через пять процессов (Plan, Source, Make, Deliver, Return) и трёхуровневую иерархию метрик (стратегический, тактический, операционный), связывая стратегию с операциями.
13. Атрибуты производительности SCOR — надёжность, отзывчивость, гибкость, затраты, активы; ключевая метрика уровня 1 — Perfect Order Fulfillment (доля идеальных заказов).
14. DCOR-модель дополняет SCOR процессами разработки новой продукции; конфигурирование цепи связывает её структуру с рыночной стратегией («эффективная» vs «отзывчивая» цепь).
15. EDI и API дополняют друг друга: EDI — юридически значимый документооборот и обмен с крупными партнёрами, API — оперативный обмен в реальном времени и интеграция внутренних систем через единый интеграционный шлюз.
16. Специфика интеграции на промышленном предприятии: защищённый корпоративный контур, импортозамещение ИТ, сквозная прослеживаемость по государственным контрактам, интеграция MES и QMS для приёмки представителем заказчика.

Контрольные вопросы

1. В чём сущность проблемы фрагментарной логистики?
2. Дайте определение интегрированной логистики.
3. Какие уровни интеграции вы знаете?
4. Что такое VMI и CPFR?
5. Что такое API и какова его роль в логистике?

Рекомендуемая литература

Основная:

1. Крылатков П. П., Прилуцкая М. А. Управление цепью поставок: учеб. пособие. — Екатеринбург: Изд-во Урал. ун-та, 2018.

Дополнительная:

1. Пермикин В. Ю. Моделирование транспортных систем: курс лекций. — Екатеринбург: УрГУПС, 2014.

Полный каталог и содержание источников — в обзоре литературы.