Формализация бизнес-процессов как HR-инструмент. Что даёт формализация бизнес-процессов

Многие бизнесмены придерживаются мнения о том, что если бизнес более-менее успешен, то достаточно сохранять всё в существующем виде. Однако если перефразировать этот тезис, то получится, что менять что-либо мы будем, только когда появятся проблемы. Чтобы не доводить ситуацию до их возникновения, полезно заниматься оптимизацией работы компании в постоянном режиме. Причём эксперты советуют обращать особое внимание на бизнес-процессы.

Бизнес-процессом называется вся последовательность действий, приводящих к конкретному результату. Например, к производству готовой единицы продукции или продаже товара.

Опыт показывает, что пока в компании мало сотрудников, владелец может всё держать под личным контролем, хотя и это не всегда удаётся. Однако для крупных предприятий отладка каждого бизнес-процесса обязательна, иначе снизится и КПД, и доходность от деятельности.

Суть формализации бизнес-процессов

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

Если этого не сделать, неизбежны следующие проблемы:

Не всегда понятно, какой сотрудник за что отвечает.
Часто неочевидно, кто отвечает за конкретную задачу.
Решение каждой задачи задерживается, так как отсутствует чёткий алгоритм.
Задачи (документы, клиенты, заявки) совершают большой «путь» по компании, пока будут решены, при этом задействуются избыточные для данного случая сотрудники.

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

При этом в ряде случаев руководитель даже не знает, к кому из сотрудников он должен обратиться по очередному вопросу, а это ещё больше усложняет ситуацию.

Задачи формализации бизнес-процессов

Формализация бизнес-процессов может быть выполнена разными методами, например, с помощью систем BPM, либо «вручную». Однако она всегда предполагает выстраивание чёткого алгоритма:

Закупка сырья.
Доставка сырья на склад.
Хранение на складе.
Отправка в цех.
Производство продукции.
Отправка продукции на склад.
Доставка продукции клиенту после покупки.

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

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

Должна быть выстроена чёткая схема для бизнес-процесса.
Каждый сотрудник должен понимать, на каком участке схемы требуются его усилия, где начинается и где заканчивается его ответственность; от кого он получает задачи и куда должен их передать после обработки.
Руководитель должен иметь возможность проконтролировать, где находится задача на данный момент времени (на каком этапе и у какого сотрудника).

Формализация бизнес-процессов путём автоматизации

Начать с того, что формализация бизнес-процессов не предполагает обязательной автоматизации с помощью BPMS, она может быть выполнена и вручную. Самый простой путь – написание регламентов для каждого сотрудника. Благодаря этому удаётся успешно решить часть задач, а именно задачи 1 и 2 приведённого выше списка (составление схемы и понимание каждым сотрудником его роли).

Однако формализация бизнес-процессов «на бумаге» почти не позволяет контролировать соблюдение регламента: выполняют ли его сотрудники или находят «обходные пути» на уровне договоренности друг с другом. Роль человеческого фактора и пространство для злоупотреблений персонала остаются очень большими.

Если же формализация бизнес-процессов проводится с помощью систем BPM, то появляются дополнительные весьма важные возможности:

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

Последняя возможность особенно важна, потому что она помогает, в том числе:

Узнать, кто из сотрудников работает эффективно, а кто не очень.
Увидеть реальный объём всей работы, выполненной каждым работником. Может, кто-то лишь делает вид, что чем-то занят?
Избавиться от риска самых разнообразных злоупотреблений персонала.

Формализация бизнес-процессов крайне полезна для любого предприятия. Даже если в настоящее время у вас нет серьёзных проблем, полезно уже сейчас начать бороться с хаотичностью в работе компании, чтобы уменьшить разные потери и затраты, повысить КПД и эффективность всех сотрудников и бизнеса в целом.

Эффективно управлять бизнесом без ясного и однозначного понимания всеми сотрудниками бизнес-процессов компании - невозможно!

Согласно определению бизнес-процесс - это цепь логически связанных, повторяющихся действий, цель которых - производство продукции/ оказание услуг (конкретных измеримых результатов) для удовлетворения потребностей внутренних или внешних клиентов. При этом предприятие использует как внешние (сырье, источники энергии, информация), так и внутренние ресурсы (труд работников, технологии, оборудование). Совокупность всех бизнес-процессов представляет собой модель бизнеса .

Для того чтобы своевременно обеспечить «на выходе» необходимое количество продукции/ услуг требуемого качества, каждый сотрудник должен знать свои обязанности, причем его роль (рамки полномочий и ответственности) должна однозначно пониматься всеми участниками процесса. Иначе невозможно эффективно контролировать деятельность работников и точно оценивать вклад каждого в достижение конечного результата.

В период проведения изменений в компании для адаптации к новым рыночным условиям описание (формализация) и усовершенствование ключевых бизнес-процессов становится особенно важной задачей. Какое же отношение к оптимизации бизнес-процессов имеет менеджер по персоналу?

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

Необходимость формализации бизнес-процессов возникает и при проведении оценки уровня вовлеченности работников компании (или отдельного подразделения). Специалисты по управлению персоналом выявили: один из основных источников неудовлетворенности работой в компании - неэффективная организация труда . Например, не разграничены зоны ответственности, сотрудники выполняют ненужные действия, нарушают технологическую последовательность операций и т. п. В данном случае причина неудовлетворенности работников - управленческие ошибки , а именно: неправильно спроектированные рабочие процессы, которые могут снижать производительность труда, создавать в подразделении конфликтные ситуации, приводить к увольнению ключевых сотрудников, ухудшать удовлетворенность клиентов. Неправильно спроектированные процессы чреваты и такими «побочными эффектами», как недостаток или избыток персонала на различных участках, дублирование одних функций и недостаточное внимание к другим (что также сказывается на результатах - ритмичности работы, производительности труда и качестве продукции/услуг).

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

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

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

Поскольку объем работы подразделения резко увеличился, а значит, выросла загрузка консультантов, мы начали искать самый простой, быстрый и наименее затратный метод улучшения бизнес-процессов. Так мы пришли к использованию метода быстрого анализа решения , или методики FAST 2 . В состав команды FAST вошли руководитель службы поддержки, менеджеры по персоналу и руководитель подразделения, куда входит служба поддержки. Команда определила план действий, приведенный в таблице 1 .

Табл. 1. План действий по методике FAST

№ п/п	Описание	Ответственный
	Формулирование целей службы поддержки	Руководитель подразделения Руководитель службы
	Анализ имеющейся документации, информации	Менеджер по персоналу
	Составление списка бизнес-процессов службы Определение процессов для FAST	Руководитель службы Менеджер по персоналу
	Разработка блок-схем бизнес-процессов	Менеджер по персоналу
	Определение плана мероприятий для реализации процессов	Руководитель службы Менеджер по персоналу
	Презентация руководству компании Утверждение предложенных улучшений	Руководитель службы Менеджер по персоналу
	Описание и документирование процессов	Менеджер по персоналу
	Информирование сотрудников подразделения о новых процессах	Руководитель службы Менеджер по персоналу
	Информирование сотрудников смежных подразделений об изменениях	Руководитель службы Менеджер по персоналу
	Обновление квалификационных требований к работникам службы поддержки Проведение оценки исполнения (performance appraisal )	Руководитель службы Менеджер по персоналу
	Контроль соблюдения процессов работниками	Руководитель службы
	Обеспечение процесса постоянного улучшения	Руководитель подразделения

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

Далее мы проанализировали действовавшее на тот момент «Положение о службе поддержки», в котором были описаны утвержденная структура подразделения, должностные обязанности и компетенции консультантов по поддержке. Анализ показал, что:

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

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

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

Фактическое отклонение по срокам выполнения работ в соответствии с типами поддержки и приоритетами задач.
Количество оплачиваемых часов (для консультантов по поддержке).
Показатели удовлетворенности клиентов.

После этого составили список всех бизнес-процессов службы поддержки клиентов и определили те из них, работа над формализацией которых должна быть проведена в первую очередь. Для каждого процесса были идентифицированы ключевые участники ; зоны ответственности каждого из них; взаимосвязи сотрудников службы поддержки с другими подразделениями (например, проектным офисом, менеджером по работе с клиентами, финансовым отделом).

Затем мы приступили к разработке первоначальной версии блок-схем 4 этих процессов. Проанализировав первые наработки, внесли в них корректировки, в том числе - в отношении участников процессов и зон их ответственности. Например, было принято решение об аннулировании позиции Helpline Representative (помощника-консультанта) - часть этих обязанностей передали младшим консультантам. В итоге, на основании проделанного анализа блок-схем бизнес-процессов, а также анализа фактической работы сотрудников службы была изменена ее структура - с учетом специфики матричных структур, характерных для проектных организаций (рис. 1 ).

Рис. 1. Изменение организационной структуры подразделения

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

В результате нами были предложены изменения процесса реализации заявок (рис. 2 ) и процесса взаимодействия с другими подразделениями (рис. 3 ).

Рис. 2. Пример процесса реализации заявок
()

Рис. 3. Пример процесса взаимодействия с другими подразделениями
(представлен в сокращенном виде )

После этого провели презентацию результатов работы команды FAST для руководителей компании и подразделения (заказчика). Все наши рекомендации получили одобрение руководства. После внесения небольших корректировок (они были сделаны в ходе обсуждения вопроса на уровне топ-менеджеров) руководитель службы поддержки провела презентацию для своих подчиненных. С этого момента служба поддержки продолжила свою работу в рамках обновленного регламента.

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

организационная структура отдела;
блок-схемы процессов с их пошаговым описанием;
квалификационные требования (профили должности, табл. 2 );
стандартные планы обучения для каждого грейда (табл. 3 ).

Табл. 2. Квалификационные требования к сотрудникам отдела поддержки
(представлена в сокращенном виде )

Вес навыка для должности:		Грейд 1	Грейд 2	Грейд 3	Грейд 4
Профессиональные навыки и знания
	Знания предметной области
	Описание тест-кейсов
	Описание тестового сценария
	Умение написать техническую спецификацию
	Проведение тренингов для заказчиков
	Знание и использование проектной методологии
Общие навыки
	Коммуникационные навыки
	Навыки работы в команде
	Управление временем
	Ориентация на заказчика
Потенциал
	Способность к обучению
	Проактивность
	Инновационность
Сертификаты
	221 NAV C/SIDE Introduction
	225 NAV Financials


	226 NAV Installation & Configuration
Количество сертификатов

Табл. 3. Стандартный план обучения сотрудника службы поддержки

План обучения сотрудника для подтверждения грейда 2
Описание	Приоритет	Форма обучения	Сроки

Модель SIPOC используется в шести сигмах и управлении качеством для определения границ проекта, обзора процессов «с высоты». В силу нашей детализации задач, эта модель отлично сработала и на более «низких высотах». К некоторым выводам о «высоте» обзора процесса я еще вернусь ниже.

Эта модель может служить поставщиком материала для формализации бизнес-процессов в общепринятых нотациях. Во многих случаях эта модель может полностью описывать процессы компании, если придерживаться методики, в этом случае модель может ложиться в основу ТЗ по доработкам или внедрению типовых конфигураций 1С.

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

Прежде чем начать

Суть идеи формализации процесса по методу SIPOC заключается в том, что мы:

Особое внимание уделяем «масштабу» процесса или, как я еще это называю «высоте точки обзора».
«Разматываем» процесс, как клубок, начиная от потребителей конечного результата процесса, заканчивая его инициатором. Не наоборот!
Особое внимание уделяем «стыкам» этапов процесса.
Особое внимание уделяем читабельности карты процесса.

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

Что такое SIPOC

Итак, SIPOC - это акроним от английских слов Supplier (поставщик), Input (вход), Process (процесс), Output (выход), Customer (заказчик) . Эта модель позволяет описывать процессы с точки зрения последовательности действий, движения информации/товаров/услуг между этапами процесса, а так же взаимоотношений, возникающих в результате процесса между различными участниками. Модель позволяет проследить бизнес-логику процесса, с высоким, но управляемым уровнем абстракции.

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

(S) ООО «Рога и копыта» -> (I) Требования к информационной системе -> (P) Формализация требований -> (O) Техническое задание -> (C) 1С:Франчайзи

Читаем слева направо: Заказчик озвучивает требования к информационной системе, которые формализуются, в результате чего появляется техническое задание для 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 совсем не удобный инструмент. Если ветвлений много, то это означает, что либо выбран не тот «масштаб», либо необходимо использовать другие инструменты.

С одной стороны я понимаю, что у SIPOC есть свои плюсы и минусы. С другой стороны, опыт автоматизации различных процессов показывает, что самые правильные, устойчивые и рабочие процессы на одном уровне (если процессы разноуровневые, то они рисуются на разных картах) практически всегда линейные и стремятся в идеале к чек-листу. Сложные процессы либо были нарисованы консалтинговой компанией «в стол», либо являются плодом фантазии на тему «как может быть». Редко, но встречается, что процесс действительно сложный и по-другому действительно нельзя. Как только мы встречаем сложные процессы, то мы заранее ставим вопрос о том, что, скорее всего, процесс выстроен не оптимально или описан некорректно. Чаще всего это встречается, когда кто-то захотел на одном листке бумаги, пусть и очень большого формата описать сразу все.

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

Есть разные уровни управления и соответствующие им разные уровни масштаба.

На этой карте мы не видим солдат, технику, отряды. «Высота» обзора не позволяет. Если брать в качестве аналогов оперативное управление: ветвления, циклы и пр., то мы эти винтики с такого расстояния не увидим. По сути, им здесь и не место, эта карта – инструмент стратегического и тактического планирования. Оперативное управление требует применение иных средств визуализации.

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

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

Теперь, после того, как мы рассмотрели саму методику описания процессов, необходимо научиться ее рисовать.

Прежде всего, мы должны определить уровень детализации. Как я уже написал выше, мы определяем уровень детализации верным тогда, когда выделяется линейный процесс. «Высота» обзора при этом должна быть не ниже уровня операций, необходимых учету. Т.е. описывать процесс до уровня «исполнитель взял ручку и начал писать» не имеет смысла, т.к. эта информация никак не отражается на учете.

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

Если процесс мы читаем слева направо сверху вниз, то рисовать процесс мы начинаем справа налево снизу вверх! То есть:

Costumer: Мы сначала определяем, кто будет потребителем результатов процесса. Это могут быть другие подразделения, конкретные должности, возможно внешние контрагенты.

Process: Потом мы описываем сам процесс, как последовательность действий и ответственного за исполнение этого этапа.

Input: Описываем, что необходимо для выполнения этого этапа и требования к этому.

Supplier: Описываем, кто будет поставлять процессу необходимые компоненты.

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

Теперь, если вспомните, чуть выше я писал о стыках этапов процессов. Пришел их черед. Как правило, на обследовании (это свойственно вообще этапу обследования) вскрываются различные нюансы. Вдруг выясняется, что для выполнения этапа процесса необходим был какой-то документ, но оказывается, что его никогда не было и этап процесса выполнялся до этого без учета этого документа. Более того, т.к. документа никогда не было, то не понятно, кто должен его поставлять для этапа процесса. Или выясняется, что на каком-то этапе выдается «выход» (output), который оказывается никому не нужен, т.е. когда мы просматриваем процесс позднее и видим «потребителей» (costumers), которые потребляют «выходы» (outputs) и нигде потом больше не участвуют, то вполне возможно, что что-то делается зря. Это не всегда так, например, выходом может быть печатная форма, которая позднее уходит в бухгалтерию, а в рамках автоматизации бухгалтерский учет не присутствует. Для описания процесса такой «выход» будет лишним, но в рамках ограничений процесса это допустимо. В любом случае проверить никогда не будет лишним.

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

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

Неявные бонусы

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

Сами карты SIPOC легко читаемы и легко воспринимаются ЛПР. Это позволяет создавать «продающие» обследования. Часто встречали на средних и крупных проектах, что ЛПР, не умел читать нотации серии IDEFх. В этом случае мы переводили их на более понятный уровень, если это было возможно, т.к. иногда был откровенный бред. Если мы работаем с ИТ-отделом, то дальнейшее описания в проектных документах мы согласуем с ними, если они не высказываются «против», то мы продолжаем придерживаться нотации SIPOC. Но бывает, что требуют другие нотации, как правило, IDEF0 и/или IDEF1, это бывает очень редко. Пока, что весомого аргумента в пользу этих нотаций, кроме того, что это привычный стандарт, а SIPOC они в глаза не видели, я не услышал. За исключением проекта, где требовалось автоматизировать процесс маршрутизации клиента по отделам в зависимости от того, что он закупает, в каком объеме и пр., там было очень много ветвлений. Фактически это автоматизация сложного оперативного управления, картам SIPOC там не место.

Еще одним бонусом, является навык определения «высоты» обзора процессов. Часто общаясь с руководителями различных структур, уже в разговоре по косвенным признакам становится понятно, что «высота» обзора процессов выбрана не верно. И только из-за этого в компании управление находится на практически нулевом уровне. Я в этом случае перехожу к, в некотором роде, консалтингу. Помогаю разобраться с высотой обзора и с этапами процессов. Как правило, это позволяет получить более плотный контакт для дальнейшего общения и повысить уровень доверия, как к эксперту. Не смотря на длинное описание, все это может происходить в рамках одного бизнес-ланча.

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

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

Прежде чем начать

Суть идеи формализации процесса по методу SIPOC заключается в том, что мы:

Особое внимание уделяем «масштабу» процесса или, как я еще это называю «высоте точки обзора».
«Разматываем» процесс, как клубок, начиная от потребителей конечного результата процесса, заканчивая его инициатором. Не наоборот!
Особое внимание уделяем «стыкам» этапов процесса.
Особое внимание уделяем читабельности карты процесса.

Что такое SIPOC

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

Визуально отображаем:

Теперь разберем, что это вообще такое и для чего нужно.

S - Supplier (поставщик) . В нашем примере это некоторая организация. В этой роли может быть любой элемент процесса, который дает на вход процесса какую-то информацию, документы, материалы, продукцию, товары, услуги и пр. В общем, это поставщик всего чего угодно, того, что обязательно участвует в процессе.

I - Input (вход) . В нашем примере это требования к информационной системе. Эти требования могут быть в виде электронного письма, описаны устно на переговорах или запротоколированы в предыдущих интервью. Здесь описывается все, что необходимо для процесса. К этому описанию применяются требования (requirements), поэтому акроним SIPOC можно увидеть в некоторых источниках, как SIRPORC. Эти требования, как видно из акронима применяются как к входу, так и к выходу.

P - Process (процесс) . Здесь мы описываем процесс, который будет происходить. В нашем примере это формализация требований. Как правило, в этом блоке описывается, кто отвечает за процесс, возможно, его роль. Описывается сам процесс производства того, что будет на выходе. Рисую изображение только для того, чтобы было визуальное представление процесса.

O - Output (выход) . Здесь мы описываем то, что должно было получиться из предыдущего этапа. В нашем примере это техническое задание. К техническому заданию как к «выходу» из процесса предъявляются свои требования, которые формулируются заказчиком (customer"ом). Например, 1С:Франчайзи имеет стандарт оформления технического задания. Требование «техническое задание должно соответствовать стандарту» описывается нами в приложении. Но, чтобы закрепить визуально, дорисуем:

С - Customer (заказчик) . В нашем примере это 1С:Франчайзи, которое получает техническое задание в результате проведенной формализации требований.

Тонкости

То же самое касается и «исходящих» объектов и заказчиков:

У нас уровень детализации находится эмпирическим путем индивидуально с каждым заказчиком.

А как же цикличные процессы? А как же параллельные процессы? А как же ветвления?

Отвечу на все вопросы по порядку.

Есть разные уровни управления и соответствующие им разные уровни масштаба.

На этой карте мы не видим солдат, технику, отряды. «Высота» обзора не позволяет. Если брать в качестве аналогов оперативное управление: ветвления, циклы и пр., то мы эти винтики с такого расстояния не увидим. По сути, им здесь и не место, эта карта - инструмент стратегического и тактического планирования. Оперативное управление требует применение иных средств визуализации.

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

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

Теперь, после того, как мы рассмотрели саму методику описания процессов, необходимо научиться ее рисовать.

Input: Описываем, что необходимо для выполнения этого этапа и требования к этому.

Supplier: Описываем, кто будет поставлять процессу необходимые компоненты.

Не явные бонусы

Пока готовил этот материал, решил поискать, что же есть в рунете на эту тему, довольно не много. Но это позволит вам расширить представление по этой теме:

в яндекс.картинках лежит куча примеров карт SIPOC

6 сигм, бережливое производство…

… и пожалуй все.

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

П.С. Как я уже писал, я решил вести рассылку. В данный момент рассылка находится в спящем режиме. В рассылке еще не много, но уже и не мало подписчиков. Сейчас уже 143 человека и еще 9 не подтвердили подписку (проверяйте папку «Спам», иногда письмо подтверждения попадает туда). Это всего за 15 дней существования рассылки, что меня сильно вдохновляет. В ближайшее время я буду проводить небольшой бесплатный онлайн тренинг. Я не профессиональный тренер и это скорее хобби, но думаю, что он будет интересен вольным стрелкам и руководителям организаций, занимающихся автоматизацией на базе 1с. В данный момент готовятся все технические элементы тренинга. Если вам понравился этот материал, то подписаться на рассылку можно . Я и дальше планирую публиковаться на ИС, в рассылку попадут материалы, которые не подходят ИС по формату (например, как тут провести тренинг я так и не придумал).

Когда компания маленькая и все всех знают (примерно до 30 человек) никакие формализованные бизнес-процессы, по идее, не нужны. Когда компания большая, географически раздёлённая или же задачи стоят нетривиальные, количество бардака начинает стремительно увеличиваться. С этим надо бороться. Например, мы решили внедрять бизнес-процессы в тот момент, когда перестали узнавать в лицо некоторых собственных сотрудников.

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

Пример постановки процесса из 1900-х

Рабочие на заводе Форда собирают детали на конвейере. Рабочий получает 5 баксов в день и собирает 30 единиц продукции. Генри Форд в течение часа смотрит на рабочего и понимает, что тот делает много лишних действий. Он пробует сам собрать деталь по новой схеме, и понимает, что, по идее, это можно делать быстрее, но нужно чуть изменить конвейер, подвинуть оборудование, и, главное, научить рабочего совершать другие движения. Через «не хочу» он обучает этого человека делать как надо - и, вуаля! - он всё ещё продолжает получать 5 баксов в день, но производит уже 42 единицы продукции.

Привычно? Нет. Интуитивно-понятно? Нет. Выгодно? Да, если затраты на переобустройство и переобучение рабочих меньше, чем предполагаемая прибыль.

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

Хронология борьбы с бардаком

Мы прошли вот такие стадии:

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

Нужны ли процессы, если команда из 10 человек?

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

Пример 1: простой, но знакомый до боли - фича от клиента.

Встреча клиента и менеджера для постановки задачи.
Согласование критериев приёмки задания.
Руководитель отдела составляет техзадание разработчику.
Техзадание или контрольные точки согласовываются с клиентом.
Ведётся разработка.
Руководитель отдела проводит приёмку.
Менеджер проводит сдачу проекта клиенту.

Если вы разработчик, при таком процессе это означает следующие вещи:

Никто кроме вашего руководителя не может ставить вам задачи (даже гендиректор).
Вы никогда не работаете без чёткого техзадания.
Вы не видите клиента. Вы даже не видите менеджера, если уж совсем хочется.
Внезапно передумавший клиент с новой идеей в последний день разработки - это проблема менеджера.
Вы отвечаете за косяки только перед своим руководителем (а он - перед клиентом).
Вы работаете не на «усталость», а на результат. То есть если разработка была закончена за час, это не значит, что вы получите меньше, чем если бы она была сделана за месяц.

Всё просто, логично и понятно, но вызывает издержки, связанные с необходимостью соблюдения протокола.

Пример 2, теперь из практики Мосигры
Вводная: есть безумный офис на 50 человек и чётко структурированные розничные магазины. Предположим, продавцу в рознице нужна новая полка взамен только что сломавшейся. Вот что он делает в старой схеме:

Обращается к старшему точки и сообщает о проблеме.
Старший точки обращается к региональному координатору и сообщает о проблеме.
Координатор стучит к руководителю отдела АХО и сообщает о проблеме.
Руководитель отдела АХО ставит задачу разнорабочему.
Разнорабочий утверждает бюджет у своего руководителя на новую полку.
Финансовому директору на стол ложится счёт под подпись.
Наступает следующий день.
Рабочий наконец-то ставит новую полку.

Если в процессе что-то прервётся, полка приедет только после того, как продавец скажет о ней ещё раз старшему и вся схема будет пройдена заново. Понятно, что описано достаточно утрированно и в реале всё проще, но 10-15% процессов без чёткой схемы всё равно могут дать сбой, например, если руководитель заболел.

Теперь та же ситуация выглядит так:

Продавец обращается в АХО и сообщает о проблеме.
Сотрудник АХО принимает решение о целесообразности использования средств.
Рабочий ставит новую полку.

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

Если АХО выставляет счёт, который выходит за план их отдела, генерится алерт для руководства, где есть две кнопки: «дать люлей» и «разрешить». При желании можно нажать обе. Суть механики: путь короче и быстрее, но полный контроль при этом сохраняется. Никаких лишних действий.

Метрики

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

Работу закупщика оценивать уже сложнее: но построение бизнес-процесса даёт возможность понимать, что именно дальше стало с товаром, как именно оно стало и насколько эффективно.

Косяки

Всё вышеописанное было бы просто теорией, если бы не встраивалось в систему управления и учёта (в нашем случае – в 1С). Теперь, например, если кто-то звонит в магазин и заказывает товар, которого нет в наличии прямо сейчас, эта информация либо сразу доносится до закупщика, либо складывается в сборщик косяков. В итоге руководитель отдела закупок чётко видит проблему и имеет возможность принять меры.

Когда десантируются сектоиды

Говорят, у военных есть инструкции на все случаи жизни: даже если прилетит НЛО с плазменными танками, у них есть точный план действий на этот случай. Так и с процессами: в идеале они есть на все случаи жизни сотрудника. Когда у сотрудника нет плана на непредвиденный случай, происходит два события:

Он обращается к тому, кто отвечает за этот вопрос (скорее всего, не отвлекая своего руководителя).
Если ситуация повторяется, создаётся процесс-правило для обработки таких случаев.

Как это всё внедряется в компанию

Сначала аналитик разговаривает с руководителем и понимает задачу. Бывает так, что процессы внедряются для галочки, чтобы потом выгоднее продать бизнес иностранцем, бывает, что для понтов, а бывает - что для дела. Последний случай наиболее интересный и сложный.
Выставляется счёт, вызывающий оху когнитивный диссонанс. В этот момент нужно договариваться на такие условия, что оплата производится при повышении конкретных показателей. Грубо говоря, стали получать на 20% больше прибыли в результате внедрения - платите.
Затем аналитик обходит всю компанию и задаёт много-много вопросов о том, как оно работает.
Потом каждому сотруднику приходит анкета с просьбой указать свои выполняемые задачи (заполняется полчаса).
Аналитик напряжённо думает и составляет блок-схему взаимодействия, из которой растут процессы и оргсхема компании.
Компания реорганизовывается под новые процессы.
Сотрудникам доносится суть изменений. Если сотрудники в возрасте, они понимают туго, но делают сразу. Если молодые - понимают отлично, но изменяются медленно.
Корректируются баги. Структура меняется по мере изменения компании и её процессов.

Сроки

У нас процесс занял около месяца на сбор данных при аналитике (работающем по программе «Луноход-1») и аналитике в штате, ещё месяц ушел на сбор и проверку анкет, ещё через кучу времени появилась оргсхема и процессы, потом всё это было внедрено. В общей сложности на всё ушло примерно полгода.

Зачем ещё нужно внедрять такие штуки

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

Резюме: плюсы и минусы

Плюсы:

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

Минусы:

Процедура занимает много времени и требует много средств: например, начинать её в сезонный пик продаж - не лучшая идея.
Консультант - не волшебник. Он не решает проблемы, а предлагает типовые решения (которые есть и в книгах) и помогает дотачивать их под компанию. Эти типовые решения внедряются при непосредственном участии руководства.
Придётся много и сильно работать самим как по построению процессов, так и по внедрению.
В конечном итоге это дорого для компании, поэтому нужно очень чётко понимать, что конкретно всё это даст.

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

UPD . В личку напомнили, что для построения бизнес-процессов нужно сформулировать стратегические цели и даже миссию (в хорошем смысле этого слова). Да, иначе будет непонятно, что делать, куда делать и как делать: нужна своеобразная ДНК или modus operandi компании.