Модуль 2. Архитектура SCOR: уровни модели и процессы
Цель модуля
Детально разобраться в четырехуровневой структуре SCOR, ее логике, процессных группах и том, как эти уровни трансформируются в структуру данных, архитектуру BI и операционные показатели. Показать, как именно адаптировать SCOR под конкретную компанию с учетом роли данных, систем и организационных процессов.
Общая архитектура SCOR: зачем уровни и в чем их смысл
SCOR-модель формализует цепочку поставок как иерархию процессов с разным уровнем детализации. Это ключ к адаптации под бизнес любой отрасли. Модель состоит из четырех уровней:
- Уровень 1 — базовые домены процессов: Plan, Source, Make, Deliver, Return. Эти домены позволяют описать операционную модель компании на самом верхнем уровне.
- Уровень 2 — категории процессов, задающие архитектуру конкретных сценариев. Например, Deliver может быть разбит на Deliver Stocked Product, Deliver Make-to-Order Product и т.д.
- Уровень 3 — шаги процессов, описанные в виде задач, ролей, входов, выходов и используемых систем.
- Уровень 4 — конкретные операционные процедуры, стандарты, чек-листы, которые компания определяет самостоятельно.
Модель работает как схема трансформации от стратегии к операционным данным.
Планирование (Plan): как декомпозировать и привязать к данным
Процесс Plan охватывает все уровни планирования:
- стратегическое: планы продаж, мощностей, локаций, инвестиции,
- тактическое: S&OP, сбалансированные планы спроса и поставок,
- операционное: недельные и дневные графики закупок, производства и дистрибуции.
В SCOR Plan разбивается на Plan Supply Chain, Plan Make, Plan Deliver и т.д.
Пример декомпозиции:
- Уровень 1: Plan
- Уровень 2: Plan Supply Chain
- Уровень 3: Balance Supply and Demand
- Уровень 4: Weekly balancing run in IBP tool
Работа с данными
Чтобы построить аналитику по Plan, нужны таблицы:
- факт продаж и прогноз (по клиенту, SKU, неделе),
- история исполнения плана (насколько прогноз точен),
- планы производства и закупок.
BI и DWH должны обеспечивать:
- сравнение плана и факта по дням, неделям, SKU,
- расчеты точности прогноза: например, MAPE = ABS(Actual - Forecast) / Actual.
Ошибки:
- нет связи между источниками прогноза (Excel) и фактами (ERP),
- разные классификаторы товаров и клиентов.
Следствие: нельзя правильно рассчитать точность плана и скорректировать модель.
Снабжение (Source): как разложить процессы и контролировать их
Процесс Source описывает выбор поставщиков, управление заказами на закупку, доставку и приемку материалов.
Пример SCOR-декомпозиции:
- Уровень 1: Source
- Уровень 2: Source Stocked Product
- Уровень 3: Issue Purchase Order, Receive Product, Verify Product
- Уровень 4: Процедура приемки в 1С с использованием акта о расхождениях
BI и DWH могут включать:
- витрину заказов на закупку,
- витрину приемки и качества,
- таблицу по срокам исполнения заказов.
Пример метрики:
- Supplier On Time In Full (SOTIF) = Число заказов, полученных вовремя и без расхождений / Общее число заказов.
Ошибка:
- в ERP не хранится дата плановой поставки — только дата заказа. Тогда нельзя рассчитать вовремя ли поставлено.
Вывод: архитектура данных должна предусматривать хранение всех дат, этапов движения заказа и статусов.
Производство (Make): цифровая модель производственных процессов
Процесс Make описывает как производится продукция: какие рецептуры, линии, смены, оборудование, контроль качества, выпуск.
Пример декомпозиции:
- Уровень 1: Make
- Уровень 2: Make-to-Order
- Уровень 3: Schedule Production, Execute Production, Quality Check
- Уровень 4: Процедура запуска смены и записи в MES
BI и DWH:
- загрузка MES-данных по событиям,
- хранение нормативов по производственным циклам,
- расчет OEE (общая эффективность оборудования): OEE = Доступность * Производительность * Качество.
Ошибка:
- MES не интегрирован с ERP и BI — данные по качеству теряются,
- OEE считается вручную — нет достоверности.
Рекомендация: включить Make в цепочку данных с полной связкой: заказ → производственный график → выпуск → проверка качества → отгрузка.
Доставка (Deliver): от склада до клиента
Процесс Deliver — один из самых богатых с точки зрения аналитики. Он включает:
- управление заказами клиента,
- формирование заказов к отгрузке,
- сборку, упаковку,
- транспортировку и доставку.
Пример SCOR-декомпозиции:
- Уровень 1: Deliver
- Уровень 2: Deliver Stocked Product
- Уровень 3: Manage Customer Order, Pick, Pack, Ship
- Уровень 4: Операции в WMS и TMS-системах
BI и DWH:
- данные из WMS: движение по складу, ошибки сборки,
- данные из TMS: маршруты, задержки, отказы доставки,
- заказы клиентов (ERP/CRM),
- контрольный отчет по Perfect Order (доставлено вовремя, в нужном количестве, без повреждений и ошибок).
Метрика:
- Delivery SLA = Число заказов, доставленных вовремя / Общее число заказов.
Ошибка:
- нет интеграции с TMS → невозможно рассчитать реальную длительность логистического цикла.
Рекомендация: включать в DWH по Deliver минимум три уровня данных — заказы, перемещения, доставка.
Возвраты (Return): управление обратным потоком
Return — часто забываемая часть цепочки, но именно она определяет устойчивость и гибкость компании.
SCOR описывает:
- возвраты от клиента (damage, отказ),
- возвраты поставщику,
- возвраты из производства.
Пример декомпозиции:
- Уровень 1: Return
- Уровень 2: Return Defective Product
- Уровень 3: Authorize Return, Receive Returned Product, Dispose or Repair
- Уровень 4: Процедура возврата с формированием акта и возвратной поставки
BI и DWH:
- таблицы возвратов по клиентам и поставщикам,
- доля возвратов от объема продаж,
- классификация причин возврата.
Пример формулы:
- Return Rate = Количество возвращенной продукции / Проданная продукция.
Ошибка:
- в ERP нет стандартного процесса возврата, всё делается вручную → BI не видит возвраты корректно.
Решение: стандартизировать процесс возврата и включить его в SCOR Deliver → Return.
Выводы и рекомендации
- SCOR-модель позволяет формализовать структуру цепочки поставок и построить её цифровой двойник.
- Каждый домен SCOR можно декомпозировать в процессы, задачи, источники данных, витрины и BI-дашборды.
- Ошибки часто происходят из-за отсутствия данных (дат, статусов, связей) или из-за ручного ввода.
- Чтобы внедрить SCOR корректно, нужно создать единый слой интеграции данных, поддерживающий все процессы и KPI.
- BI и DWH должны не просто визуализировать SCOR, а работать как операционная платформа управления цепочкой поставок.
