SIPOC — таблица из пяти колонок (Suppliers, Inputs, Process, Outputs, Customers), которая фиксирует границы бизнес-процесса на самом верхнем уровне детализации, прежде чем углубляться в конкретные шаги. Это первый инструмент, который берут в руки, когда процесс нужно улучшить, но команда ещё не договорилась, где он вообще начинается и кончается.
Происхождение и исследовательская база
SIPOC вырос из практики Total Quality Management и окончательно оформился как стандартный инструмент внутри методологии Six Sigma, институционализированной компаниями Motorola (с 1986 года) и General Electric в 1990-х. Внутри цикла DMAIC (Define — Measure — Analyze — Improve — Control), на котором строится любой Six Sigma-проект, SIPOC — стандартный инструмент именно фазы Define: прежде чем измерять процесс и искать в нём потери, нужно однозначно зафиксировать, где он начинается и заканчивается, кто его реальный заказчик и какой конкретно результат считается выходом.
Более глубокие корни — в производственной системе Toyota (Toyota Production System) эпохи становления бережливого производства, где идея «внутреннего клиента-поставщика» между последовательными операциями предшествовала формальному оформлению SIPOC как отдельного инструмента.
Ключевые идеи и принципы
Принцип: пять колонок и их точное содержание
Suppliers (Поставщики) — кто предоставляет ресурсы для запуска процесса (не только внешние контрагенты — соседний отдел тоже поставщик).
Inputs (Входы) — что именно поставляется: материалы, данные, документы, разрешения.
Process (Процесс) — сам процесс на верхнем уровне, обычно 4-7 крупных шагов, не пошаговая инструкция.
Outputs (Выходы) — результат процесса, который получает клиент.
Customers (Клиенты) — кто получает результат, включая ВНУТРЕННИХ клиентов (соседний отдел, а не только конечный покупатель).
Принцип: «внутренний клиент-поставщик» — SIPOC не заканчивается на границе компании
Между шагами одного процесса часто есть скрытые внутренние клиенты и поставщики — например, бухгалтерия является клиентом процесса продаж (получает данные для проводки), а отдел технического контроля — клиентом процесса производства. Пропуск таких внутренних участников — источник большинства «слепых зон» при построении диаграммы.
Принцип: заполнять в обратном порядке — P→O→C→I→S, не слева направо
Наиболее методологически ценный практический приём: правильный порядок заполнения таблицы — сначала Process (общие границы и крупные шаги), затем Outputs (что процесс реально производит), затем Customers (кто это получает), и только после этого — Inputs и Suppliers. Если начинать «по алфавиту» — слева направо, с поставщиков — команда почти гарантированно тонет в деталях входов раньше, чем вообще определит, где у процесса начало и конец.
Принцип: связь с Value Stream Mapping — SIPOC даёт границы, VSM детализирует поток внутри них
SIPOC и Value Stream Mapping (VSM) решают разные по масштабу задачи одного и того же процесса: SIPOC — это «вид с высоты птичьего полёта», верхнеуровневая карта, фиксирующая ТОЛЬКО границы процесса и участников на входе/выходе, без единой детали о времени или потерях внутри. VSM — следующий, гораздо более детальный шаг: внутри уже зафиксированных SIPOC-границ VSM разворачивает реальный поток операций с временем такта, запасами и восемью видами потерь (Lean-муда). Практическая последовательность — сначала SIPOC (определить, ЧТО вообще анализируем), потом VSM (понять, КАК это движется и где теряется время) — попытка сразу строить VSM без предварительного SIPOC часто приводит к тому, что команда детализирует не тот процесс или не те его границы, о которых на самом деле договорились заказчик и исполнители.
Принцип: связь с формулой Y = f(X)
В более строгой Six Sigma-нотации выход процесса (Y) формально рассматривается как функция от его входов (X₁, X₂, …, Xₙ) плюс случайная вариация (ε): Y = f(X₁, X₂...Xₙ) + ε. SIPOC — первый шаг к тому, чтобы вообще определить множество этих X и Y, прежде чем переходить к статистическому анализу их связи на последующих фазах DMAIC (Measure/Analyze).
Ограничения, слепые зоны и критика
SIPOC описывает процесс на верхнем уровне и намеренно не умеет отражать ветвления и циклы («если... то...», повторы шагов) — попытка впихнуть в таблицу условную логику обычно превращает её в нечитаемую кашу; для процессов с реальным ветвлением нужна отдельная блок-схема или BPMN-диаграмма, SIPOC для этого не предназначен.
Неверный выбор масштаба детализации — частая методологическая ошибка: если процесс расписан слишком подробно (20+ шагов), SIPOC теряет саму цель верхнеуровневого обзора; если слишком укрупнённо (1-2 шага) — теряет полезность для дальнейшей работы.
SIPOC статичен — фиксирует картину на момент составления, ничего не говорит о времени выполнения, узких местах или частоте сбоев (эту информацию даёт уже VSM или последующие фазы DMAIC).
Диаграмма, составленная кабинетно (одним аналитиком по документам, без участия реальных исполнителей процесса), систематически упускает неформальные внутренние связи — тот самый «внутренний клиент-поставщик», который часто заметен только тем, кто реально работает внутри процесса.
Типовые ошибки
Ошибка 1: заполнение слева направо, начиная с поставщиков
Первым делом пытаются перечислить всех поставщиков и входы, ещё не договорившись, что вообще считается процессом и его границами.
Как избежать: заполнять в порядке P→O→C→I→S — сначала процесс и его крупные шаги, потом выход и клиент, и только в конце — входы и поставщики.
Ошибка 2: игнорирование внутренних участников
В колонки Suppliers/Customers вписывают только внешних контрагентов, пропуская соседние отделы, которые фактически являются внутренними поставщиками и клиентами процесса.
Как избежать: явно задавать вопрос «какой отдел получает результат ДО того, как он дойдёт до внешнего клиента?» на каждом шаге процесса.
Ошибка 3: путаница входов и выходов
Один и тот же артефакт по ошибке помещают то во входы, то в выходы соседнего шага, из-за чего границы шагов процесса перестают быть однозначными.
Как избежать: для каждого элемента явно проверять — это то, ЧТО ПОСТУПАЕТ в процесс, или то, ЧТО ПРОЦЕСС ПРОИЗВОДИТ на выходе конкретного шага.
Ошибка 4: избыточная детализация процесса
Колонка Process расписывается на 15-20 мелких операций вместо 4-7 крупных блоков — диаграмма перестаёт выполнять свою функцию верхнеуровневого обзора.
Как избежать: держать 4-7 шагов как ориентир; более мелкая детализация — задача следующего инструмента (карты процесса, VSM), не SIPOC.
Ошибка 5: попытка отразить ветвления и циклы внутри таблицы
В колонку Process пытаются вписать условную логику («если заявка одобрена — шаг А, если нет — шаг Б») — таблица становится нечитаемой.
Как избежать: для процессов с реальным ветвлением строить отдельную блок-схему или BPMN-диаграмму, SIPOC оставлять линейным верхнеуровневым обзором.
Ошибка 6: диаграмма не проверена с реальными участниками
SIPOC составляется одним аналитиком по документам/регламентам, без валидации с людьми, которые реально выполняют процесс — в результате диаграмма отражает «как должно быть по регламенту», а не «как есть на самом деле».
Как избежать: обязательная сверка готовой диаграммы минимум с одним реальным исполнителем каждого крупного шага, прежде чем считать её финальной.
Главное, что нужно знать
SIPOC — верхнеуровневая карта границ процесса: 4-7 крупных шагов, поставщики/входы, выходы/клиенты — не детальная блок-схема.
Заполнять нужно в обратном порядке: сначала Process→Outputs→Customers, потом Inputs→Suppliers — иначе команда тонет в деталях входов раньше, чем определит границы.
Клиенты и поставщики бывают внутренними (соседний отдел), не только внешними контрагентами.
SIPOC — стандартный инструмент фазы Define цикла DMAIC (Six Sigma), первый шаг перед более детальным Value Stream Mapping.
Не подходит для процессов с реальным ветвлением/циклами — для этого нужна отдельная блок-схема или BPMN.
План внедрения
Неделя 1: определение границ и участников
Собрать группу из 4-6 реальных участников процесса (не только руководителя направления).
Заполнить в порядке P→O→C→I→S: сначала 4-7 крупных шагов процесса, затем выход и клиенты (включая внутренних), затем входы и поставщики.
Явно проверить каждый элемент на путаницу входов/выходов и наличие пропущенных внутренних участников.
Неделя 2: верификация
Сверить готовую диаграмму минимум с одним реальным исполнителем каждого крупного шага процесса.
Убедиться, что в Process нет попыток отразить ветвления/циклы — если они есть, вынести их в отдельную блок-схему/BPMN.
Зафиксировать финальную версию как согласованные границы процесса для дальнейшей работы (VSM, поиск узких мест).
Далее: переход к детализации
Согласованный SIPOC — стартовая точка, не конечный результат: следующий шаг — Value Stream Mapping внутри уже зафиксированных границ, где появляются время такта, запасы и конкретные виды потерь, которые SIPOC намеренно не показывает.
Как реализовать этот план с помощью фрейма «SIPOC-диаграмма» в OrgDevTools
Фрейм SIPOC в OrgDevTools — настоящая пятиколоночная таблица (Поставщики/Входы/Процесс/Выходы/Клиенты), а не набор карточек: каждая строка таблицы — один сквозной элемент процесса, ячейки редактируются прямо в таблице, новая строка добавляется кнопкой «Добавить строку» или клавишей Enter. Над таблицей — переключатель-фильтр, который можно временно сузить до одной конкретной колонки (например, показать только заполненные строки по «Клиентам»), чтобы вычитать одну категорию без отвлечения на остальные четыре.
Вердикт наверху фрейма пересчитывается автоматически: пока не добавлено ни одной строки — подсказка начать с колонки «Процесс» (P), что напрямую реализует принцип «заполнять в обратном порядке» из блока «Ключевые идеи» выше; если часть строк заполнена не по всем 5 колонкам — явное предупреждение, что неполный SIPOC теряет границы процесса; когда все строки заполнены полностью — подтверждение, что границы процесса чётко определены.
На неделе 1 плана внедрения заполняйте строки именно в порядке Процесс → Выходы → Клиенты → Входы → Поставщики, даже если визуально таблица предлагает слева направо — методологически правильный порядок именно такой.
