Процессный подход — что сделать, чтобы он стал реальностью в организации

Показательный пример: EFQM (Европейский фонд управления качеством) пересматривая в 2009 году Модель идеальной организации, немного изменил название концепции, которая касается процессного подхода. Раньше она называлась «Управление процессами», теперь — «Управление через процессы». В комментариях к этому изменению говорится, что старое название создавало впечатление, что процессы — это просто один из многих объектов управления в организации. Новое название подчеркивает, что процессы — это способ управления любой деятельностью в организации и что нет деятельности, которая не управлялась бы этим способом.

Конечно, в большинстве организаций, которые сертифицировали систему управления качеством по стандарту ISO 9001, выполнены шаги по внедрению процессного подхода: определены процессы, назначены их владельцы, разработаны их документированные описания и показатели их мониторинга. Но часто эти шаги выполняются формально и процессы не становятся чем-то реальным в жизни организации, не используются как действенный инструмент для управления ею. В сущности, реальное внедрение процессного подхода (которое часто требует «небольшой революции» в подходах к управлению организацией) заменяется разработкой набора документов, которые описывают порядок выполнения разных работ в организации. Насколько смешались эти понятия видно даже из терминологии, которая часто используется в отечественных организациях, когда словом «процесс» называют соответствующий документ. И действительно, во многих случаях этот документ является единственным, что объединяет деятельность разных подразделений в какую-то целостность (процесс). Можно сказать, что в таких организациях процесс — это деятельность, описанная в одном документе (описании процесса); достаточно аннулировать такие документы и от процессного подхода в организации не останется и следа. Но неужели действительно процессный подход сводится к набору документов и почему тогда ему уделяется такое большое внимание? Конечно, это не так, и процессный подход означает что-то большее.

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

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

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

Процессы: что это такое и для чего они нужны

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

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

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

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

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

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

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

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

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

Исходя из параллелей с управлением через структурные подразделения, можно сказать, что внедрение процессного подхода означает создание:

• Новой структуры организации;
• Новой системы распределения ответственности и полномочий;
• Новой роли руководителей;
• Новых типов управленческих решений.

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

Проектирование структуры процессов

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

Правилом, очевидным для оргструктуры (и для любой иерархической структуры) является то, что первый руководитель организации должен лично руководить любыми структурными подразделениями, которые подчинены непосредственно ему: определять цели их работы, согласовывать пути достижения этих целей, при необходимости — помогать в их достижении, анализировать полученные результаты. Если даже небольшой отдел непосредственно подчиняется генеральному директору организации, он должен взять управление этими отделом на себя. Если же он не готов регулярно это делать, то должен подчинить отдел одному из своих заместителей. Аналогия этого правила для процессной структуры понятна — процессы первого уровня, это те виды деятельности, которыми первый руководитель готов руководить непосредственно. Один из немедленных выводов из этого: этих процессов должно быть столько, чтобы у первого руководителя хватало времени и возможностей для регулярного управления ими (встречаются системы, состоящие из 40-50 процессов, не понятно, может ли первый руководитель хотя бы пересчитать их). А главный вывод — структура процессов должна отображать видение работы организации первым руководителем, ведь — должна разрабатываться и пересматриваться только при его непосредственном участим. Если это правило не будет выполнено (наиболее распространенный вариант — когда структура процессов копирует структуру стандарта ISO 9001), организация получит не настоящее процессное управление (собственно, процессами никто управлять не будет), а только набор документов, описывающих ее деятельность. Позиция высшего руководства — одна из главных причин того, что структуры процессов могут отличаться даже в подобных организациях. Например, деятельность относительно взаимодействия с потребителями может быть представлена в процессной схеме множеством вариантов, например:

• Единый процесс «Взаимодействие с потребителями» (включает продажи, рекламу, продвижение продукции, маркетинговые исследования, работу с рекламациями и т.п.);
• Три отдельных процесса «Продажи», «Реклама», «Маркетинговые исследования»;
• Два процесса «Маркетинговые исследования» и «Привлечение потребителей» (включает рекламу и продажи);
• Два процесса «Продажи» и «Маркетинг» (включает маркетинговые исследования и рекламу);
• Деятельность по продажам и заключению договоров может быть объединена в единый процесс с выполнением договоров;
• В процесс «Продажи» может быть включена деятельность по доставке продукции потребителям.

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

Банальным вопросом для оргструктуры является то, что она должна охватывать весь персонал — каждый сотрудник должен относиться к определенному структурному подразделению. Сложно вообразить ситуацию, когда из 100 сотрудников 50 распределили по структурным подразделениям, а другим сказали, что они работают в организации, но ни к одному подразделению не принадлежат. Но для структуры процессов такая ситуация является нормальной — особенно когда ее построение вызвано лишь требованиями определенного системного стандарта. В этом случае можно ожидать, что структура процессов не будет охватывать деятельность, которая не регламентируется этим стандартом. В частности, при разработке системы управления качеством по стандарту ISO 9001, как правило, структура процессов не охватывает финансовый менеджмент, стратегическое управление, вопрос мотивации персонала, и т.п. Едва ли такую ситуацию можно назвать полноценным внедрением процессного подхода. Речь не идет о том, что все виды деятельности, которые выполняются в организации, должны быть детально описаны в документации системы. Может быть достаточным выделить соответствующие процессы, определить их связь с сопредельными процессами и назначить их владельцев. На первом этапе сам процесс может не описываться и представлять собой «черный ящик». Решение о необходимости его дальнейшего описания и детализации может принимать его владелец.

Не менее очевидным вопросом для оргструктуры является то, что разные подразделения не должны пересекаться между собой: один и тот же сотрудник не может одновременно работать в разных подразделениях или вообще «повиснуть» где-то в промежутке между ними (речь не идет о совмещении должностей — в этом случае четко определено, какую именно работу по которой из должностей выполняет сотрудник в определенный момент). Для процессов такая ситуация есть довольно распространенной. Особенно часто она возникает когда процессный подход внедряются исключительно под определенный стандарт. Тогда и возникают странные процессы типа «Управление документацией», которые пересекаются со всеми другими процессами. При этом, сотрудники организации не могут ответить на вопрос: разработка конструкторской документации — это часть процесса «Проектирование» или «Управление документацией», разработка прайс-писем — это «Сбыт» или «Управление документацией»? Чаще всего ответ звучит нечетко «С одной стороны... , с другой стороны...». Но с процессами так быть не может, границы между ними должны быть четкими и однозначными. Повторимся, если речь идет только о разработке документов, без реального внедрения процессного подхода — подобные сечения, когда требования к определенной деятельности описаны сразу в нескольких документах, являются нежелательными, но не критическими. Если же внедрять процессы по-настоящему, то это приводит к конфликту полномочий между владельцами разных процессов.

В целом, проектируя структуру процессов, следует понимать, что речь идет о распределении ответственности за работу организации. Рассмотрим такое влияние на примере деятельности по закупкам (сырья, оборудования, услуг, и т.п.). Существует два основные варианта для отражения этой деятельности в структуре процессов. Первый вариант — это разработка общего процесса «Закупки», который охватывает все категории закупок в организации (владельцем такого процесса может быть руководитель службы закупок). Второй — это включение соответствующей деятельности в профильные процессы: закупки оборудования и услуг по его обслуживанию — к процессу «Управление оборудованием», закупки учебных услуг — к процессу «Управление персоналом», и т.п. Конечно, во втором варианте может остаться отдельный процесс закупок, но он будет ограничен закупками сырья и комплектующих (но и этот процесс иногда можно объединить с процессом производства). Важно, что этот выбор существенно влияет на организацию работ по закупке, на распределение ответственности между службой закупки и профильными подразделениями (службой главного инженера, службой по работе с персоналом, и т.п.). Но кто из них отвечает за конечный результат — за то, чтобы своевременно были получены продукция и услуги надлежащего качества и в нужном количестве? Если будет выбрана первая альтернатива — общий процесс закупок, это означает, что ответственность несет служба закупок. Профильные подразделения должны лишь выполнить ее требования, например, — подать свои заявки на закупку в установленной ею форме в установленное ею время. Если они эти требования выполнили, а при закупке возникли проблемы — это ответственность службы (в частности, это может быть ответственность за неверно разработанные формы заявок). Во второй альтернативе — это ответственность профильных подразделений. Каждый из них самостоятельно определяет удобную для себя схему закупки, при этом для разных категорий закупки эти схемы могут отличаться. В рамках своих процессов они могут предусматривать привлечение службы закупки для использования ее опыта и компетенции, но формы такого привлечения определяют они и ответственность за конечный результат несут также они.

Еще одним моментом, на который желательно обращать внимание, проектируя структуру процессов, является определение сквозных процессов (в англоязычной литературе: end-to-end processes). В первую очередь это касается процессов жизненного цикла продукции или услуг, но тот же принцип может быть применен к другим категориям процессов. Основная идея: процесс должен заканчиваться конечным результатом, который несет определенную законченную ценность для потребителей: внешних или внутренних (но для процессов жизненного цикла продукции, желательно — внешних). Возможно, в большей степени это касается процесса приема и выполнения заказов со стороны потребителей — следует попробовать спроектировать его как целостный процесс: от момента когда потребитель обратился к организации, до момента когда его заказ полностью выполнен и он подтвердил это. На практике, довольно часто предприятия разбивают такой сквозной процесс на несколько меньших процессов (как правило, таких, что связаны с разными структурными подразделениями или регламентируются разными разделами стандарта). Например, деятельность по проектированию и внедрению в производство нового вида продукции может быть представлена в виде процессов «Разработка конструкторской документации», «Разработка технологической документации», «Подготовка к запуску в производство»; деятельность со стратегического планирования: «Анализ со стороны руководства», «Разработка политики и целей», «Разработка планов» и «Бюджетирование». Это приводит к повторению ситуации, известная по традиционному управлению через структурные подразделения: когда общий конечный результат не достигается, хотя каждый из определенных процессов выполняется согласно своей методике и достигает своих целей. Конечно, все приведенные примеры «ограниченных» процессов могут иметь место в системе управления, но может быть более целесообразным определить их как процессы второго уровня — составные части сквозных процессов.

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

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

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

• Процессы жизненного цикла продукции или услуг (деятельность, которая создает ценность с точки зрения потребителей);

• Процессы обеспечения ресурсами (превращают запросы или прогнозы относительно потребности в ресурсах в соответствующие ресурсы).

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

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

Владельцы процессов и их полномочия

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

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

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

Могут рассматриваться варианты предоставления владельцу процесса дополнительных полномочий, в первую очередь, связанных с его участием в оперативном контроле над выполнением. Например, могут рассматриваться такие полномочия:

• Возможность оперативного сбора информации о ходе процесса, контроля над его выполнением;

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

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

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

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

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

Примером реального внедрения процессного подхода является одна из французских страховых компаний, которую в свое время посетил автор. При том, что эта компания имела все возможные сертификаты на системы менеджмента, в ней не было службы качества или другого подобного подразделения. На вопрос, а как же они организовали приведение своей деятельности в соответствие со стандартами ISO 14001, OHSAS 18001 и других, ответ был простой: в ежегодных целях для каждого из владельцев процессов было записано — привести свой процесс в соответствие с требованиями определенного стандарта; кроме того, была создана проектная группа из представителей наиболее задействованных процессов, для координации деятельности. Со всем остальным владельцы процессов чудесно справились сами, работы для отдельного подразделения просто не осталось. Этот пример, конечно, не означает, что службы качества во всех организациях должны распускаться через определенное время после внедрения процессного подхода. Но им придется серьезно подумать над своими функциями после того как владельцы процессов научатся самостоятельно руководить ими. Один из возможных вариантов — сконцентрироваться на инициировании и внедрении прорывных изменений в системе управления.

Мониторинг и анализ процессов

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

Кроме того, поскольку правильно определенный процесс является целостным и завершенным, определить для него полезные показатели мониторинга, которые дают реальную информацию, может быть значительно легче, чем для отдельных структурных подразделений. Особенно это касается структурных подразделений, которые не выполняют завершенных функций, не создают самостоятельных продуктов, а только помогают другим подразделениям в выполнении их работы (классические примеры — юридическое подразделение, подразделение по охране труда, подразделение по управлению качеством). Для них может быть особенно сложно найти показатели, которые характеризуют именно их работу и не зависят существенно от других подразделений. Если возникли проблемы с выбором характерных показателей относительно мониторинга для определенного процесса, это может свидетельствовать о том, что сам процесс определен не очень удачно (например, тяжело вообразить действенный показатель для процесса «Управление документацией» и это может свидетельствовать только о том, что управление документацией на самом деле процессом не является). Вообще , сравнивая мониторинг процессов и структурных подразделений, можно сказать, что руководству, ориентированному на достижение результата, значительно интереснее может быть насколько эффективно выполняется маркетинговая деятельность (а об этом свидетельствует мониторинг соответствующего процесса), а не то, насколько эффективно работают сотрудники отдела маркетинга (об этом говорят результаты мониторинга подразделения).

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

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

Определение порядка выполнения процессов

Без большого риска ошибиться, можно сказать, что первой ассоциацией, которая возникает у отечественного специалиста при слове «процесс» является документ, который описывает порядок выполнения определенной работы — документированное описание процесса. Во многих случаях даже сами эти понятия смешиваются и внедрение процессного подхода сводится к написанию набора таких документов. Это, конечно, очень упрощенный взгляд, но для каждого процесса такие описания действительно должны быть (не обязательно детальные) и их разработка является одной из главных задач владельца процесса. Предоставление детальных рекомендаций относительно организации не является задачей этой статьи; здесь будет только проанализирована цель разработки этих документов и их место в общей системе управления.

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

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

• Проанализировать, обеспечивает ли выполнение всех этих положений то, что заказы потребителей будут стабильно выполняться на протяжении определенного срока;

• Определить, какие изменения должны быть внесены в эти положения, чтобы гарантировать сокращение срока выполнения заказов на 20%.

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

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

Часто приходится сталкиваться с другим аргументом со стороны организаций: у нас уже есть разработанные раньше документы (положение, инструкции, приказы), которые определяют порядок выполнения основных работ: что же нового может дать нам процессный подход? Во- первых, такая совокупность документов, если она разрабатывалась за пределами проектирования структуры процессов, редко когда является целостной и согласованной. Как правило, эти документы могут содержать дублирование и противоречия; в то же время отдельные направления работы организации могут быть не охвачены ими. Ведь какой есть наиболее распространенная схема разработки таких документов: столкнувшись с определенными проблемами в своей деятельности, организация решает разработать документ, который регламентирует порядок выполнения соответствующих работ. Одно из привлеченных подразделений разрабатывает соответствующую инструкцию — по поручению руководства или по собственной инициативе. Через некоторое время возникает проблема в сопредельной области и для ее решения разрабатывается еще один документ — на этот раз под названием «положение». Если его разрабатывает то же подразделение, которое разрабатывало предыдущую инструкцию — можно надеяться, что они будут согласованы, если другое — шансов на это немного. Я лично сталкивался с ситуацией, когда на предприятии порядок приемки закупленной продукции был описан в трех документах, разработанных тремя разными подразделениями: инструкции о порядке закупки, инструкции относительно ведения складского хозяйства, инструкции о порядке контроля ОТК. Надо ли говорить, что описания приемки закупленной продукции в этих инструкциях были абсолютно разными? Понадобилось полдня работы, чтобы понять, что речь идет об одной и той же деятельности, а потом неделя, чтобы определить порядок работы, который удовлетворял бы все привлеченные подразделения. При желании, каждая организация может вообразить ситуацию: перед сотрудником поставлена новая для него задача и он попросил предоставить ему полный перечень действующих документов, которые он должен учесть в своей деятельности. Есть ли уверенность в том, что удастся выполнить его пожелание? Тот же вопрос можно сформулировать в более острой форме: принято решение о разработке нового документа, который будет регламентировать выполнение определенного вида работ, и нужно знать перечень действующих документов, которые должны быть учтены при разработке нового. При наличии действенного процессного подхода действия в этой ситуации должны быть стандартными: любой новый документ определяет порядок работы в рамках определенного процесса. Соответственно, нужно учесть документированное описание этого процесса, по необходимости — документированные описания сопредельных процессов (потребителей и поставщиков), а также документы, детализирующие порядок их выполнения (описания подпроцессов, ссылки на которые должны быть включены в документированные описания процессов). Кроме того, могут существовать отдельные общесистемные документы, которые определяют корпоративные требования, обязанности для всех процессов (например, требования относительно единой системы документооборота); но их число, как правило, невелико. Главным остается принцип: структура процессов, а соответственно — и структура документов, должны быть спроектированы, а не создаваться спонтанно: не может существовать «самой по себе» инструкция, связь которой с процессами непонятна.

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

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

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

Последнее замечание

Завершить статью хочется таким замечанием. Часто в литературе говорят о построении в организации системы управления качеством по стандарту ISO 9001. Такой подход кажется не совсем эффективным, ведь он означает, что существует «система управления качеством», отдельная от общей системы управления. Также можно называть эту работу усовершенствованием системы управления организации на основе стандарта ISO 9001. Это название более точное, но оно тоже не кажется совершенным, поскольку привязывает работу к требованиям стандарта, а не к нуждам самой организации. Возможно, более эффективным позиционированием соответствующей работы может быть именно внедрение процессного подхода к управлению организацией. Такое позиционирование может побуждать сотрудников к тому, чтобы действительно глубоко пересмотреть и усовершенствовать базовые подходы к своей деятельности, а не просто сосредоточиться на успешном прохождении сертификационного аудита. А если организации удалось ввести процессный подход по-настоящему, то можно сказать, что 90% соответствия требованиям стандарта ISO 9001 уже достигнуто. А то, что осталось — это, скорее всего, локальные вопросы, которые могут быть разрешимы владельцами процессов.

Об авторе:

Тарас Петрович Калита — Сертифицированный аудитор по качеству Немецкого общества по качеству (DGQ) и Европейской организации качества (EOQ). Сертификат ISTO (International Standart Testing Organisation) с отличием. Старший эксперт Европейской награды качества, член правления Украинской ассоциации качества. Сертифицированный менеджер по окружающей среде EOQ. Член Международной гильдии профессионалов качества.