SIPOC: как описать границы процесса перед улучшением

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

Цыба Елена

Ведущий эксперт по финансам, ACCA, IPFM, CIMA, руководитель консалтингового агентства. Преподаватель курса «Управление эффективностью операций (CIMA P1)»

Что такое SIPOC

Аббревиатура означает Suppliers, Inputs, Process, Outputs, Customers: поставщики, входы, процесс, выходы и клиенты. ASQ рекомендует SIPOC для высокоуровневого описания текущего процесса до построения подробной блок-схемы; к пяти основным блокам при необходимости добавляют ограничения и измерения.

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

Когда карта действительно нужна

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

Если задача — разобрать конкретное исключение со всеми переходами, нужна детальная карта потока. Если требуется распределить ответственность, добавляют RACI. SIPOC предшествует этим инструментам, но не заменяет их.

Сначала начало и конец процесса

Запишите два наблюдаемых события. Начало должно находиться внутри управляемой области и запускать работу. Конец — означать, что обещанный результат создан и передан клиенту. Например:

Фразы «клиент захотел услугу» и «клиент доволен» слишком широки для операционной карты. Первая плохо наблюдается, вторая зависит от процессов за пределами обработки заявки. Граница должна быть достаточно узкой, чтобы пять–семь шагов описывали поток, но достаточно широкой, чтобы видеть сквозной результат.

В каком порядке заполнять

1. Process. Запишите 5–7 глагольных шагов от начала до конца.
2. Outputs. Определите результаты каждого процесса в целом, а не все внутренние файлы.
3. Customers. Укажите тех, кто использует выход и предъявляет требования.
4. Inputs. Перечислите то, без чего процесс не может дать корректный выход.
5. Suppliers. Свяжите каждый вход с источником.
6. Requirements and Measures. Добавьте критичные требования и несколько показателей.

Начинать с процесса удобно: он задаёт границу и не позволяет превратить Suppliers в полный список контрагентов организации.

Как написать правильные шаги Process

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

Если один блок требует перечислить десять развилок, зафиксируйте его как укрупнённый шаг и пометьте для отдельного картирования. Например, «проверить допустимость условий» может позже получить собственную блок-схему.

Выходы и клиенты

Выход — результат, который покидает границу процесса. «Заполненная карточка» может быть промежуточным объектом, а реальным выходом — подтверждённая заявка с назначенным владельцем и сроком. Для каждого выхода укажите клиента и его измеримое требование.

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

Входы и поставщики

Входом считается не только документ. Это данные, разрешение, мощность системы, компетенция, справочник или материальный объект, необходимый для выхода. Избегайте слов «информация» и «ресурсы» без уточнения.

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

Заполненный SIPOC: обработка входящей заявки

Пример синтетический и не описывает действующую организацию. Он показывает, как одна страница удерживает границу процесса.

Требования, ограничения и метрики

К карте добавляют только показатели, которые помогают оценить выход и границу:

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

Допустим, из 80 заявок 52 комплектны сразу: 65%. Ещё 20 потребовали одно уточнение, восемь — два и более. Карта подсказывает вопрос: какие входы нестабильны и от каких поставщиков. Она не доказывает, что виноват автор заявки: причина может быть в неясной форме, устаревшем каталоге или противоречивых требованиях.

Как провести 60-минутную сессию

1. 0–10 минут: согласовать цель карты, начало и конец.
2. 10–20: написать пять–семь шагов as-is без обсуждения решений.
3. 20–30: определить выходы, клиентов и требования.
4. 30–40: связать входы и поставщиков.
5. 40–50: добавить два–четыре показателя и ограничения.
6. 50–60: отметить расхождения, владельцев проверки и следующий инструмент.

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

Не смешивайте as-is и to-be

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

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

SIPOC, блок-схема и оргструктура

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

Типичные ошибки

• в Process двадцать шагов и все развилки — карта перестаёт быть обзорной;
• поставщики перечислены без связи с входами;
• выходом названо действие «обработать», а не передаваемый результат;
• клиентом автоматически считают только внешнего покупателя;
• на одной карте смешаны текущее и желаемое состояние;
• метрики взяты из доступного отчёта, но не связаны с требованиями к выходу;
• после сессии не назначен владелец проверки спорных фактов.

Когда карта готова

Новый участник должен суметь за несколько минут объяснить: что запускает процесс, чем он заканчивается, какие пять–семь действий создают выход, кому он нужен, какие входы критичны и откуда они поступают. Все спорные места либо подтверждены, либо записаны как вопросы с владельцем и сроком. После этого переходите к детальной карте узкого места, измерению или PDCA-тесту.

Как проверить карту после сессии

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

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

Реестр открытых вопросов

Что делать после SIPOC

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

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

Карточка версии SIPOC

На карте укажите название процесса, цель построения, начало, конец, дату, участников и владельца. Рядом запишите, какие три случая использованы для проверки и какие вопросы остались открытыми.

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

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

Практика вместо теории

От обзорной карты — к управлению сквозной эффективностью

Связать карту границ с ресурсами, показателями и управленческими решениями помогает курс «Управление эффективностью операций (CIMA P1)». Преподаватель — Цыба Елена; итоговый документ — удостоверение о повышении квалификации.

Смотреть программу

Вопросы и ответы

• Сколько шагов должно быть в SIPOC?

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

• Кто считается клиентом внутреннего процесса?

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

• Нужно ли начинать заполнение с Suppliers?

  Не обязательно. Практически удобно начать с границы и Process, затем определить Outputs и Customers, после этого Inputs и Suppliers. Такой порядок удерживает карту от лишних объектов.

• Можно ли на одном SIPOC показать будущий процесс?

  Можно создать отдельную to-be версию, но не смешивать её с as-is. Иначе предполагаемое решение будет выглядеть как установленный факт, а разрыв между состояниями потеряется.

По теме