для чего предназначен метод sipoc выберите один вариант ответа
Методология SIPOC: как улучшить процессы компании?
Методология SIPOC — это инструмент описания бизнес-процессов. Он суммирует входные и выходные данные одного или нескольких процессов и представляется, в большинстве случаев, в табличной форме.
Аббревиатура SIPOC складывается из пяти слов:
Некоторые организации используют противоположную аббревиатуру COPIS, которая ставит клиента на первое место и демонстрирует его ценность для организации.
Методологию SIPOC часто используют для описания и обзора всех бизнес-процессов компании. Такой анализ помогает сотрудникам или руководителю компании выявить потенциальные пробелы в работе: ненужные входы, выходы, которые не ценятся клиентами или этапы процесса, несущие убытки.
В большинстве случаев карты SIPOC применяют:
Чтобы понять, как методология работает, рассмотрим пример простой схемы SIPOC.
Пример схемы SIPOC
Ключевая цель построения SIPOC-схемы – определение всех этапов проекта, начиная с самого начала. Имейте в виду, что основная часть диаграммы – это количественная оценка входов и того, кто их предоставляет.
Разберем на примере схему, показывающую, как входы преобразуются в выходы. Название нашего процесса: настройка ноутбука для нового сотрудника.
Мы привели самый простой пример того, как работает диаграмма SIPOC. Она также может быть многоуровневой: процесс может состоять из большого количества шагов, а заказчиков может быть более десяти. Главная сложность – выделение элементов для входа, а также составление процесса. Его важно разбить на ключевые компоненты и найти для них место в диаграмме.
Далее рассмотрим основные преимущества применения методологии SIPOC в организации.
Преимущества использования методологии
Методология SIPOC представляет собой простой для понимания инструмент. Руководитель компании может использовать данный метод в различных ситуациях. Рассмотрим семь основных преимуществ схем SIPOC:
*методика концептуального проектирования сложных систем
И не самое очевидное преимущество – лояльность клиента. Часто заказчики боятся переплатить либо просто не понимают, за что с них требуют деньги. В этом случае руководители компаний предлагают клиенту самостоятельно заполнить и детализировать процесс. Подобный консалтинг помогает:
Такой подход выгоден и по другим причинам: вы помогаете клиенту, не затрачивая своего времени, а также экономите время и нервы на нецелевых действиях.
Мы тщательно подходим к вопросам ведения клиента и оказанию услуг. Используем только проверенные современные технологии для оптимизации нашего производства! Готовы выполнить задачи любой сложности и внедрить новые технологии для вашей компании. Звоните по телефону +7 (495) 118-39-18 или заполните форму ниже.
SIPOC диаграмма
Что такое SIPOC?
SIPOC — это диаграмма, используемая для идентификации базовых элементов процесса, таких как границы процесса, поставщики процесса, входные данные процесса, шаги или этапы процесса, выходные данные процесса и заказчики. Эта диаграмма используется в основном для определения процессов верхнего уровня. Более того, SIPOC хорошо помогает транслировать требования заказчика в требования к выходным процессам и соответственно определять ключевые переменные выходных процессов (KPOV’s). Диаграмма SIPOC используется также для картирования потока создания ценности.
Слово SIPOC — это аббревиатура пяти слов:
Преимущества SIPOC
Основное преимущество и назначение SIPOC заключается в том. что он дает возможность увидеть бизнес или деятельность в перспективе процессов. Среди прочих преимуществ можно выделить следующие:
Соединяя концы в диаграмме SIPOC, где выход одного процесса будет входом другого процесса — вы сможете с легкостью выстроить огромную сеть бизнес-процессов в масштабах целой компании.
Построение диаграммы
Эти несколько вопросов помогут вам правильно определить “входы” и “поставщиков” процесса:
Для построения диаграммы SIPOC лучше всего использовать обычную блок-диаграмму, где каждый блок будет представлять ключевую деятельность организации или “процесс”. В отличие от более детальной карты процесса, блок-диаграмма обычно изображается в виде простого прямолинейного потока без всяких точек назначения или альтернативных путей. Во избежание слишком большого количества деталей необходимо сократить количество “процессов” — от 4 до 10 блоков.
Модель SIPOC используется в шести сигмах и управлении качеством для определения границ проекта, обзора процессов «с высоты». В силу нашей детализации задач, эта модель отлично сработала и на более «низких высотах». К некоторым выводам о «высоте» обзора процесса я еще вернусь ниже.
Эта модель может служить поставщиком материала для формализации бизнес-процессов в общепринятых нотациях. Во многих случаях эта модель может полностью описывать процессы компании, если придерживаться методики, в этом случае модель может ложиться в основу ТЗ по доработкам или внедрению типовых конфигураций 1С.
У этой модели есть свои плюсы и минусы, поэтому я не настаиваю на всеобщем применении, но думаю, что альтернативный взгляд всегда полезен. В том числе и мне. Пишите, что думаете в комментариях.
Прежде чем начать
Суть идеи формализации процесса по методу SIPOC заключается в том, что мы:
Как это ни странно, но, не смотря на очевидность этих пунктов, практически все карты процессов, которые я встречал в своей жизни, нарушали минимум два пункта из этих четырех. Если эта статья поможет вам осознать эти принципиальные моменты, то я буду считать, что достиг своей цели, не зависимо от того, какой нотацией вы пользуетесь.
Что такое SIPOC
Сразу же наглядный пример описания процесса. На нем можно посмотреть основы.
Читаем слева направо: Заказчик озвучивает требования к информационной системе, которые формализуются, в результате чего появляется техническое задание для 1С:Франчайзи.
Теперь разберем, что это вообще такое и для чего нужно.
S – Supplier (поставщик). В нашем примере это некоторая организация. В этой роли может быть любой элемент процесса, который дает на вход процесса какую-то информацию, документы, материалы, продукцию, товары, услуги и пр. В общем, это поставщик всего чего угодно, того, что обязательно участвует в процессе.
I – Input (вход). В нашем примере это требования к информационной системе. Эти требования могут быть в виде электронного письма, описаны устно на переговорах или запротоколированы в предыдущих интервью. Здесь описывается все, что необходимо для процесса. К этому описанию применяются требования (requirements), поэтому акроним SIPOC можно увидеть в некоторых источниках, как SIRPORC. Эти требования, как видно из акронима применяются как к входу, так и к выходу.
Обычно мы не отображаем требования к входу или к выходу визуально, если этого не требуют условия (в нашей практике такого еще не встречалось, но всякое возможно). Но эти требования мы описываем в приложении к визуальному отображению бизнес-процесса. Продиктовано это возникающим неудобством применения карт SIPOC для последующего использования в проектной документации из-за их возрастающей объемности. Но, чтобы визуально закрепить методику в голове, мы ее нарисуем так:
Требованиями к входящим в процесс объектам могут быть любые условия, которые необходимы для успешного выполнения процесса. Стрелка направлена от процесса к поставщику, потому что именно поставщик должен соблюдать требования. Это может быть измеримое качество или количество материалов, если это производство, или это может быть требование «наличие SMART анализа для целей внедрения информационной системы», если это предпроект и т.п.
P – Process (процесс). Здесь мы описываем процесс, который будет происходить. В нашем примере это формализация требований. Как правило, в этом блоке описывается, кто отвечает за процесс, возможно, его роль. Описывается сам процесс производства того, что будет на выходе. Рисую изображение только для того, чтобы было визуальное представление процесса.
Это описание, мы, как правило, приводим в приложении к визуальному отображению бизнес-процесса. [Не обращайте внимания на диагональные стрелки, я рисую по ходу написания статьи]
O – Output (выход). Здесь мы описываем то, что должно было получиться из предыдущего этапа. В нашем примере это техническое задание. К техническому заданию как к «выходу» из процесса предъявляются свои требования, которые формулируются заказчиком (customer’ом). Например, 1С:Франчайзи имеет стандарт оформления технического задания. Требование «техническое задание должно соответствовать стандарту» описывается нами в приложении. Но, чтобы закрепить визуально, дорисуем:
С – Customer (заказчик). В нашем примере это 1С:Франчайзи, которое получает техническое задание в результате проведенной формализации требований.
Это очень упрощенный пример. Он нужен только для того, чтобы пробежаться по верхам и увидеть картинку в целом.
Тонкости
Это описание процесса с высоты совсем уж «птичьего полета». Естественно, что сам процесс гораздо сложнее. Поэтому сначала начнем с возможностей детализации в рамках процесса.
Если у нас несколько поставщиков «входящих» объектов или несколько самих «входящих» объектов, то их можно отобразить вот так:
То же самое касается и «исходящих» объектов и заказчиков:
Теперь, если представить, что нам потребуется бОльшая детализация процессов, требований, то рисунок будет все менее и менее читаем. Чего мы, кстати, хотим избежать.
У нас уровень детализации находится эмпирическим путем индивидуально с каждым заказчиком.
Для того, чтобы сохранить читабельность процесса, мы начинаем дробить процесс на этапы. Каждый этап является копией модели SIPOC со своими входами и выходами. Например, предпроект можно разбить на два и более этапов, в зависимости от требуемой детализации. Я нарисую первые два.
Если внимательно рассмотреть эти два этапа, то можно заметить, что первые три элемента второго этапа «Консультант-Протоколы-ИТ-директор» дублируют последние три элемента первого этапа. Это стыки этапов процесса. К ним мы еще вернемся в дальнейшем.
А как же цикличные процессы? А как же параллельные процессы? А как же ветвления?
Отвечу на все вопросы по порядку.
Параллельные процессы, если позволяет ситуация, описываются отдельными картами SIPOC. Если взаимоотношения параллельных процессов во времени сложные, то SIPOC используется только для описания процессов, сами взаимоотношения процессов во времени описываются другими инструментами. Это выходит за рамки применения карт SIPOC.
Теперь то, что касается ветвлений. Если процесс содержит ветвления, то картами SIPOC описываются этапы процесса до и после ветвлений. В этом отношении SIPOC совсем не удобный инструмент. Если ветвлений много, то это означает, что либо выбран не тот «масштаб», либо необходимо использовать другие инструменты.
С одной стороны я понимаю, что у SIPOC есть свои плюсы и минусы. С другой стороны, опыт автоматизации различных процессов показывает, что самые правильные, устойчивые и рабочие процессы на одном уровне (если процессы разноуровневые, то они рисуются на разных картах) практически всегда линейные и стремятся в идеале к чек-листу. Сложные процессы либо были нарисованы консалтинговой компанией «в стол», либо являются плодом фантазии на тему «как может быть». Редко, но встречается, что процесс действительно сложный и по-другому действительно нельзя. Как только мы встречаем сложные процессы, то мы заранее ставим вопрос о том, что, скорее всего, процесс выстроен не оптимально или описан некорректно. Чаще всего это встречается, когда кто-то захотел на одном листке бумаги, пусть и очень большого формата описать сразу все.
Это очень похоже на процесс программирования. Мы используем тот уровень детализации в процедурах и функциях, который позволяет нам легко ориентироваться. Представьте, что было бы, если бы в 1с был только один модуль, который отвечает за все, и не было бы процедур и функций, которые повышают уровень абстракции алгоритма.
Есть разные уровни управления и соответствующие им разные уровни масштаба.
На этой карте мы не видим солдат, технику, отряды. «Высота» обзора не позволяет. Если брать в качестве аналогов оперативное управление: ветвления, циклы и пр., то мы эти винтики с такого расстояния не увидим. По сути, им здесь и не место, эта карта – инструмент стратегического и тактического планирования. Оперативное управление требует применение иных средств визуализации.
Нельзя одновременно видеть все и в деталях. Должны быть разные карты для разных точек обзора. Если соблюдать это требование, то практически все процессы, соответствующие детализацией «высоте» обзора, можно описать моделью SIPOC. Из этого я в свое время сделал такой вывод: если процесс описывается методом SIPOC, то «высота» обзора процесса соответствует уровню детализации. Возможно, это покажется спорным утверждением. Надеюсь на то, что если я не прав, то более компетентные товарищи меня поправят в комментариях. Я всегда готов к совершенствованию. Но пока опытным путем не удалось столкнуться с обратным.
Как рисовать карту процесса?
Теперь, после того, как мы рассмотрели саму методику описания процессов, необходимо научиться ее рисовать.
Прежде всего, мы должны определить уровень детализации. Как я уже написал выше, мы определяем уровень детализации верным тогда, когда выделяется линейный процесс. «Высота» обзора при этом должна быть не ниже уровня операций, необходимых учету. Т.е. описывать процесс до уровня «исполнитель взял ручку и начал писать» не имеет смысла, т.к. эта информация никак не отражается на учете.
Когда консультант приходит на интервью, которое посвящено обследованию процесса, он придерживается следующих рекомендаций.
Если процесс мы читаем слева направо сверху вниз, то рисовать процесс мы начинаем справа налево снизу вверх! То есть:
Costumer: Мы сначала определяем, кто будет потребителем результатов процесса. Это могут быть другие подразделения, конкретные должности, возможно внешние контрагенты.
Output: Далее мы определяем, что именно должен получить каждый потребитель результатов процесса и определяем требования к ним. Напомню, что требования мы не рисуем на карте, а описываем приложением к процессу.
Process: Потом мы описываем сам процесс, как последовательность действий и ответственного за исполнение этого этапа.
Input: Описываем, что необходимо для выполнения этого этапа и требования к этому.
Supplier: Описываем, кто будет поставлять процессу необходимые компоненты.
Это мы описали самый нижний, результирующий этап процесса. И дальше мы начинаем разматывать клубок, переместившись на один этап вверх. Так последовательно описываются все этапы.
Теперь, если вспомните, чуть выше я писал о стыках этапов процессов. Пришел их черед. Как правило, на обследовании (это свойственно вообще этапу обследования) вскрываются различные нюансы. Вдруг выясняется, что для выполнения этапа процесса необходим был какой-то документ, но оказывается, что его никогда не было и этап процесса выполнялся до этого без учета этого документа. Более того, т.к. документа никогда не было, то не понятно, кто должен его поставлять для этапа процесса. Или выясняется, что на каком-то этапе выдается «выход» (output), который оказывается никому не нужен, т.е. когда мы просматриваем процесс позднее и видим «потребителей» (costumers), которые потребляют «выходы» (outputs) и нигде потом больше не участвуют, то вполне возможно, что что-то делается зря. Это не всегда так, например, выходом может быть печатная форма, которая позднее уходит в бухгалтерию, а в рамках автоматизации бухгалтерский учет не присутствует. Для описания процесса такой «выход» будет лишним, но в рамках ограничений процесса это допустимо. В любом случае проверить никогда не будет лишним.
Эти стыки иногда приводят к расширениям требований. Например, однажды обследуя процессы клиента, мы задавали вопрос о некоторых стыках. Оказалось, что была потребность выставления сводных актов и счетов-фактур по договору и бухгалтера сводили все вручную. Первоначальных требований по этому контуру не было, но выявив этот момент в процессе обследования именно на этапе анализа стыков и их необходимости, мы выработали концепцию решения, предложили ее руководству заказчика и получили дополнительный бюджет для этого контура.
В результате такого интервьюирования консультант рисует процессы, составляет протоколы обследования процессов, согласовывает и передает их вместе с аудиозаписями интервью своему руководителю для дальнейшего анализа.
Неявные бонусы
Методология SIPOC представляя собой простой инструмент, позволяет получать не совсем явные бонусы. Вы можете, имея навык, использовать этот инструмент в различных ситуациях.
Сами карты SIPOC легко читаемы и легко воспринимаются ЛПР. Это позволяет создавать «продающие» обследования. Часто встречали на средних и крупных проектах, что ЛПР, не умел читать нотации серии IDEFх. В этом случае мы переводили их на более понятный уровень, если это было возможно, т.к. иногда был откровенный бред. Если мы работаем с ИТ-отделом, то дальнейшее описания в проектных документах мы согласуем с ними, если они не высказываются «против», то мы продолжаем придерживаться нотации SIPOC. Но бывает, что требуют другие нотации, как правило, IDEF0 и/или IDEF1, это бывает очень редко. Пока, что весомого аргумента в пользу этих нотаций, кроме того, что это привычный стандарт, а SIPOC они в глаза не видели, я не услышал. За исключением проекта, где требовалось автоматизировать процесс маршрутизации клиента по отделам в зависимости от того, что он закупает, в каком объеме и пр., там было очень много ветвлений. Фактически это автоматизация сложного оперативного управления, картам SIPOC там не место.
Еще одним бонусом, является навык определения «высоты» обзора процессов. Часто общаясь с руководителями различных структур, уже в разговоре по косвенным признакам становится понятно, что «высота» обзора процессов выбрана не верно. И только из-за этого в компании управление находится на практически нулевом уровне. Я в этом случае перехожу к, в некотором роде, консалтингу. Помогаю разобраться с высотой обзора и с этапами процессов. Как правило, это позволяет получить более плотный контакт для дальнейшего общения и повысить уровень доверия, как к эксперту. Не смотря на длинное описание, все это может происходить в рамках одного бизнес-ланча.
Ну и, наверное, последнее, что хотелось бы рассказать. Иногда клиенты либо не имеют средств на обследование, либо просто не понимают за что собственно они платят и как следствие жадничают. В этом случае я им предлагаю вариант, когда они самостоятельно заполняют и детализируют процессы. Получается такой поверхностный консалтинг, который иногда приводит к проектам. Это происходит в переписке, где я им скидываю уже готовые брифы, а они их заполняют. Мы созваниваемся, когда возникают вопросы. Такой подход позволяет не прерывать отношения, поддерживать диалог и при этом не тратить времени, если клиент жадный до денег, находится в ситуации вынужденной экономии или просто не понимает за что платить консультантам. Вкусив горечи консалтингового труда, он либо выдает результат, с которым можно начинать работать, либо соскакивает, квалифицируя себя как нецелевого клиента, либо покупает нормальное обследование. В любом случае, при таком подходе мы остаемся в сильной позиции. В первом случае мы помогли, не затрачивая своего времени, нам это зачтется потом. Во втором случае мы сэкономили кучу времени и нервов на нецелевых действиях. И в третьем мы заработали на обследовании.
В сумме всех факторов: простота метода, легкость в обучении и широкие возможности для консалтинга, это все плюсы, которые заставляют нас применять метод снова и снова. На текущий момент такого сочетания полезности для обследования и повышения качества коммуникации с клиентами я не встречал пока ни в одном методе. Опять же, повторюсь, коллеги, делитесь своими наработками, я с удовольствием учусь.
Модель SIPOC используется в шести сигмах и управлении качеством для определения границ проекта, обзора процессов «с высоты». В силу нашей детализации задач, эта модель отлично сработала и на более «низких высотах». К некоторым выводам о «высоте» обзора процесса я еще вернусь ниже.
Эта модель может служить поставщиком материала для формализации бизнес-процессов в общепринятых нотациях. Во многих случаях эта модель может полностью описывать процессы компании, если придерживаться методики, в этом случае модель может ложиться в основу ТЗ по доработкам или внедрению типовых конфигураций 1С.
У этой модели есть свои плюсы и минусы, поэтому я не настаиваю на всеобщем применении, но думаю, что альтернативный взгляд всегда полезен. В том числе и мне. Пишите, что думаете в комментариях.
Прежде чем начать
Суть идеи формализации процесса по методу SIPOC заключается в том, что мы:
Как это ни странно, но, не смотря на очевидность этих пунктов, практически все карты процессов, которые я встречал в своей жизни, нарушали минимум два пункта из этих четырех. Если эта статья поможет вам осознать эти принципиальные моменты, то я буду считать, что достиг своей цели, не зависимо от того, какой нотацией вы пользуетесь.
Что такое SIPOC
Сразу же наглядный пример описания процесса. На нем можно посмотреть основы.
Читаем слева направо: Заказчик озвучивает требования к информационной системе, которые формализуются, в результате чего появляется техническое задание для 1С:Франчайзи.
Теперь разберем, что это вообще такое и для чего нужно.
S – Supplier (поставщик). В нашем примере это некоторая организация. В этой роли может быть любой элемент процесса, который дает на вход процесса какую-то информацию, документы, материалы, продукцию, товары, услуги и пр. В общем, это поставщик всего чего угодно, того, что обязательно участвует в процессе.
I – Input (вход). В нашем примере это требования к информационной системе. Эти требования могут быть в виде электронного письма, описаны устно на переговорах или запротоколированы в предыдущих интервью. Здесь описывается все, что необходимо для процесса. К этому описанию применяются требования (requirements), поэтому акроним SIPOC можно увидеть в некоторых источниках, как SIRPORC. Эти требования, как видно из акронима применяются как к входу, так и к выходу.
Обычно мы не отображаем требования к входу или к выходу визуально, если этого не требуют условия (в нашей практике такого еще не встречалось, но всякое возможно). Но эти требования мы описываем в приложении к визуальному отображению бизнес-процесса. Продиктовано это возникающим неудобством применения карт SIPOC для последующего использования в проектной документации из-за их возрастающей объемности. Но, чтобы визуально закрепить методику в голове, мы ее нарисуем так:
Требованиями к входящим в процесс объектам могут быть любые условия, которые необходимы для успешного выполнения процесса. Стрелка направлена от процесса к поставщику, потому что именно поставщик должен соблюдать требования. Это может быть измеримое качество или количество материалов, если это производство, или это может быть требование «наличие SMART анализа для целей внедрения информационной системы», если это предпроект и т.п.
P – Process (процесс). Здесь мы описываем процесс, который будет происходить. В нашем примере это формализация требований. Как правило, в этом блоке описывается, кто отвечает за процесс, возможно, его роль. Описывается сам процесс производства того, что будет на выходе. Рисую изображение только для того, чтобы было визуальное представление процесса.
Это описание, мы, как правило, приводим в приложении к визуальному отображению бизнес-процесса. [Не обращайте внимания на диагональные стрелки, я рисую по ходу написания статьи]
O – Output (выход). Здесь мы описываем то, что должно было получиться из предыдущего этапа. В нашем примере это техническое задание. К техническому заданию как к «выходу» из процесса предъявляются свои требования, которые формулируются заказчиком (customer’ом). Например, 1С:Франчайзи имеет стандарт оформления технического задания. Требование «техническое задание должно соответствовать стандарту» описывается нами в приложении. Но, чтобы закрепить визуально, дорисуем:
С – Customer (заказчик). В нашем примере это 1С:Франчайзи, которое получает техническое задание в результате проведенной формализации требований.
Это очень упрощенный пример. Он нужен только для того, чтобы пробежаться по верхам и увидеть картинку в целом.
Тонкости
Это описание процесса с высоты совсем уж «птичьего полета». Естественно, что сам процесс гораздо сложнее. Поэтому сначала начнем с возможностей детализации в рамках процесса.
Если у нас несколько поставщиков «входящих» объектов или несколько самих «входящих» объектов, то их можно отобразить вот так:
То же самое касается и «исходящих» объектов и заказчиков:
Теперь, если представить, что нам потребуется бОльшая детализация процессов, требований, то рисунок будет все менее и менее читаем. Чего мы, кстати, хотим избежать.
У нас уровень детализации находится эмпирическим путем индивидуально с каждым заказчиком.
Для того, чтобы сохранить читабельность процесса, мы начинаем дробить процесс на этапы. Каждый этап является копией модели SIPOC со своими входами и выходами. Например, предпроект можно разбить на два и более этапов, в зависимости от требуемой детализации. Я нарисую первые два.
Если внимательно рассмотреть эти два этапа, то можно заметить, что первые три элемента второго этапа «Консультант-Протоколы-ИТ-директор» дублируют последние три элемента первого этапа. Это стыки этапов процесса. К ним мы еще вернемся в дальнейшем.
А как же цикличные процессы? А как же параллельные процессы? А как же ветвления?
Отвечу на все вопросы по порядку.
Параллельные процессы, если позволяет ситуация, описываются отдельными картами SIPOC. Если взаимоотношения параллельных процессов во времени сложные, то SIPOC используется только для описания процессов, сами взаимоотношения процессов во времени описываются другими инструментами. Это выходит за рамки применения карт SIPOC.
Теперь то, что касается ветвлений. Если процесс содержит ветвления, то картами SIPOC описываются этапы процесса до и после ветвлений. В этом отношении SIPOC совсем не удобный инструмент. Если ветвлений много, то это означает, что либо выбран не тот «масштаб», либо необходимо использовать другие инструменты.
С одной стороны я понимаю, что у SIPOC есть свои плюсы и минусы. С другой стороны, опыт автоматизации различных процессов показывает, что самые правильные, устойчивые и рабочие процессы на одном уровне (если процессы разноуровневые, то они рисуются на разных картах) практически всегда линейные и стремятся в идеале к чек-листу. Сложные процессы либо были нарисованы консалтинговой компанией «в стол», либо являются плодом фантазии на тему «как может быть». Редко, но встречается, что процесс действительно сложный и по-другому действительно нельзя. Как только мы встречаем сложные процессы, то мы заранее ставим вопрос о том, что, скорее всего, процесс выстроен не оптимально или описан некорректно. Чаще всего это встречается, когда кто-то захотел на одном листке бумаги, пусть и очень большого формата описать сразу все.
Это очень похоже на процесс программирования. Мы используем тот уровень детализации в процедурах и функциях, который позволяет нам легко ориентироваться. Представьте, что было бы, если бы в 1с был только один модуль, который отвечает за все, и не было бы процедур и функций, которые повышают уровень абстракции алгоритма.
Есть разные уровни управления и соответствующие им разные уровни масштаба.
На этой карте мы не видим солдат, технику, отряды. «Высота» обзора не позволяет. Если брать в качестве аналогов оперативное управление: ветвления, циклы и пр., то мы эти винтики с такого расстояния не увидим. По сути, им здесь и не место, эта карта – инструмент стратегического и тактического планирования. Оперативное управление требует применение иных средств визуализации.
Нельзя одновременно видеть все и в деталях. Должны быть разные карты для разных точек обзора. Если соблюдать это требование, то практически все процессы, соответствующие детализацией «высоте» обзора, можно описать моделью SIPOC. Из этого я в свое время сделал такой вывод: если процесс описывается методом SIPOC, то «высота» обзора процесса соответствует уровню детализации. Возможно, это покажется спорным утверждением. Надеюсь на то, что если я не прав, то более компетентные товарищи меня поправят в комментариях. Я всегда готов к совершенствованию. Но пока опытным путем не удалось столкнуться с обратным.
Как рисовать карту процесса?
Теперь, после того, как мы рассмотрели саму методику описания процессов, необходимо научиться ее рисовать.
Прежде всего, мы должны определить уровень детализации. Как я уже написал выше, мы определяем уровень детализации верным тогда, когда выделяется линейный процесс. «Высота» обзора при этом должна быть не ниже уровня операций, необходимых учету. Т.е. описывать процесс до уровня «исполнитель взял ручку и начал писать» не имеет смысла, т.к. эта информация никак не отражается на учете.
Когда консультант приходит на интервью, которое посвящено обследованию процесса, он придерживается следующих рекомендаций.
Если процесс мы читаем слева направо сверху вниз, то рисовать процесс мы начинаем справа налево снизу вверх! То есть:
Costumer: Мы сначала определяем, кто будет потребителем результатов процесса. Это могут быть другие подразделения, конкретные должности, возможно внешние контрагенты.
Output: Далее мы определяем, что именно должен получить каждый потребитель результатов процесса и определяем требования к ним. Напомню, что требования мы не рисуем на карте, а описываем приложением к процессу.
Process: Потом мы описываем сам процесс, как последовательность действий и ответственного за исполнение этого этапа.
Input: Описываем, что необходимо для выполнения этого этапа и требования к этому.
Supplier: Описываем, кто будет поставлять процессу необходимые компоненты.
Это мы описали самый нижний, результирующий этап процесса. И дальше мы начинаем разматывать клубок, переместившись на один этап вверх. Так последовательно описываются все этапы.
Теперь, если вспомните, чуть выше я писал о стыках этапов процессов. Пришел их черед. Как правило, на обследовании (это свойственно вообще этапу обследования) вскрываются различные нюансы. Вдруг выясняется, что для выполнения этапа процесса необходим был какой-то документ, но оказывается, что его никогда не было и этап процесса выполнялся до этого без учета этого документа. Более того, т.к. документа никогда не было, то не понятно, кто должен его поставлять для этапа процесса. Или выясняется, что на каком-то этапе выдается «выход» (output), который оказывается никому не нужен, т.е. когда мы просматриваем процесс позднее и видим «потребителей» (costumers), которые потребляют «выходы» (outputs) и нигде потом больше не участвуют, то вполне возможно, что что-то делается зря. Это не всегда так, например, выходом может быть печатная форма, которая позднее уходит в бухгалтерию, а в рамках автоматизации бухгалтерский учет не присутствует. Для описания процесса такой «выход» будет лишним, но в рамках ограничений процесса это допустимо. В любом случае проверить никогда не будет лишним.
Эти стыки иногда приводят к расширениям требований. Например, однажды обследуя процессы клиента, мы задавали вопрос о некоторых стыках. Оказалось, что была потребность выставления сводных актов и счетов-фактур по договору и бухгалтера сводили все вручную. Первоначальных требований по этому контуру не было, но выявив этот момент в процессе обследования именно на этапе анализа стыков и их необходимости, мы выработали концепцию решения, предложили ее руководству заказчика и получили дополнительный бюджет для этого контура.
В результате такого интервьюирования консультант рисует процессы, составляет протоколы обследования процессов, согласовывает и передает их вместе с аудиозаписями интервью своему руководителю для дальнейшего анализа.
Не явные бонусы
Методология SIPOC представляя собой простой инструмент, позволяет получать не совсем явные бонусы. Вы можете, имея навык, использовать этот инструмент в различных ситуациях.
Сами карты SIPOC легко читаемы и легко воспринимаются ЛПР. Это позволяет создавать «продающие» обследования. Часто встречали на средних и крупных проектах, что ЛПР, не умел читать нотации серии IDEFх. В этом случае мы переводили их на более понятный уровень, если это было возможно, т.к. иногда был откровенный бред. Если мы работаем с ИТ-отделом, то дальнейшее описания в проектных документах мы согласуем с ними, если они не высказываются «против», то мы продолжаем придерживаться нотации SIPOC. Но бывает, что требуют другие нотации, как правило, IDEF0 и/или IDEF1, это бывает очень редко. Пока, что весомого аргумента в пользу этих нотаций, кроме того, что это привычный стандарт, а SIPOC они в глаза не видели, я не услышал. За исключением проекта, где требовалось автоматизировать процесс маршрутизации клиента по отделам в зависимости от того, что он закупает, в каком объеме и пр., там было очень много ветвлений. Фактически это автоматизация сложного оперативного управления, картам SIPOC там не место.
Еще одним бонусом, является навык определения «высоты» обзора процессов. Часто общаясь с руководителями различных структур, уже в разговоре по косвенным признакам становится понятно, что «высота» обзора процессов выбрана не верно. И только из-за этого в компании управление находится на практически нулевом уровне. Я в этом случае перехожу к, в некотором роде, консалтингу. Помогаю разобраться с высотой обзора и с этапами процессов. Как правило, это позволяет получить более плотный контакт для дальнейшего общения и повысить уровень доверия, как к эксперту. Не смотря на длинное описание, все это может происходить в рамках одного бизнес-ланча.
Ну и, наверное, последнее, что хотелось бы рассказать. Иногда клиенты либо не имеют средств на обследование, либо просто не понимают за что собственно они платят и как следствие жадничают. В этом случае я им предлагаю вариант, когда они самостоятельно заполняют и детализируют процессы. Получается такой поверхностный консалтинг, который иногда приводит к проектам. Это происходит в переписке, где я им скидываю уже готовые брифы, а они их заполняют. Мы созваниваемся, когда возникают вопросы. Такой подход позволяет не прерывать отношения, поддерживать диалог и при этом не тратить времени, если клиент жадный до денег, находится в ситуации вынужденной экономии или просто не понимает за что платить консультантам. Вкусив горечи консалтингового труда, он либо выдает результат, с которым можно начинать работать, либо соскакивает, квалифицируя себя как нецелевого клиента, либо покупает нормальное обследование. В любом случае, при таком подходе мы остаемся в сильной позиции. В первом случае мы помогли, не затрачивая своего времени, нам это зачтется потом. Во втором случае мы сэкономили кучу времени и нервов на нецелевых действиях. И в третьем мы заработали на обследовании.
В сумме всех факторов: простота метода, легкость в обучении и широкие возможности для консалтинга, это все плюсы, которые заставляют нас применять метод снова и снова. На текущий момент такого сочетания полезности для обследования и повышения качества коммуникации с клиентами я не встречал пока ни в одном методе. Опять же, повторюсь, коллеги, делитесь своими наработками, я с удовольствием учусь.
Что почитать
Пока готовил этот материал, решил поискать, что же есть в рунете на эту тему, довольно не много. Но это позволит вам расширить представление по этой теме:
в яндекс.картинках лежит куча примеров карт SIPOC
6 сигм, бережливое производство…
Во вложении лежит пример кусочка реального технического задания, в который вошла карта небольшого процесса и приложение к ней. Это для наглядности, как мы это используем на реальных проектах.
П.С. Как я уже писал, я решил вести рассылку. В данный момент рассылка находится в спящем режиме. В рассылке еще не много, но уже и не мало подписчиков. Сейчас уже 143 человека и еще 9 не подтвердили подписку (проверяйте папку «Спам», иногда письмо подтверждения попадает туда). Это всего за 15 дней существования рассылки, что меня сильно вдохновляет. В ближайшее время я буду проводить небольшой бесплатный онлайн тренинг. Я не профессиональный тренер и это скорее хобби, но думаю, что он будет интересен вольным стрелкам и руководителям организаций, занимающихся автоматизацией на базе 1с. В данный момент готовятся все технические элементы тренинга. Если вам понравился этот материал, то подписаться на рассылку можно тут. Я и дальше планирую публиковаться на ИС, в рассылку попадут материалы, которые не подходят ИС по формату (например, как тут провести тренинг я так и не придумал).