Процессы: что это такое и зачем?

 

Цель лекции:

Что такое процессы и какую проблему решает процессный подход

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

Что касается разработчиков стандарта ИСО 9000:2000, то они постарались и сделали все, чтобы нам – практикам от менеджмента качества - жизнь медом не казалась. Хотя, с другой стороны, я их тоже могу понять: надо дать определение на уровне абстракции, соответствующем таковому стандарта ИСО 9001. И они дали.

Попробуем разобраться в задумке.

Итак, процесс – это «совокупность взаимосвязанных и взаимодействующих видов деятельности». Наши переводчики перевели activities как виды деятельности. Если это не случайно и имеет глубокий смысл, то какой? Философский словарь говорит: «ВИД (лат. species) — в логическом смысле понятие, которое образуется посредством выделения общих признаков в индивидуальных понятиях и само имеет общие признаки с др. видовыми понятиями…». Т.е. вид деятельности – это не какая-то конкретная деятельность (например, забивание взятого в ящике гвоздя в стену в комнате, чтобы повесить недавно подаренную картину), имеющая конкретный же результат, а «понятие, образованное выделением общих признаков». Исходя из этого, получается, что процесс, состоящий из «видов деятельности» – это не реальная деятельность, апредставление реальной деятельности, причем представление путем обобщения. Говоря иными словами, процесс – это модель реальной деятельности.

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

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

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

Скажем, 50 лет назад о процессном управлении еще не говорили. У того же Янга в его книге «Системное управление организацией» упоминаются процессы, но несколько в ином смысле, и идеи процессного управления там еще не просматриваются. И в книге А. Фейгенбаума «Контроль качества продукции», вышедшей на русском языке в1986 году, мы еще не встретим упоминания о процессах в известном нам смысле. Но с другой стороны, в предисловии научного редактора к русскому изданию 1997 года известной книги Хаммера и Чампи «Реинжениринг корпорации. Манифест революции в бизнесе» указано, что «Тему реинжениринга специалисты по менеджменту начали разрабатывать уже во второй половине 80-х годов, однако прорыв в исследованиях этого феномена принято ассоциировать со статьей М. Хаммера «Реинжениринг традиционных методов работы: не автоматизируйте их, а отвергайте», опубликованной в четвертом номере «Harvard Business Review» за 1990 г». Стало быть, возникновение идеи процессного подхода к управлению можно отнести к 80-м годам прошлого века.

В это время современный менеджмент качества, т.е. управление качеством продукции с целью удовлетворения ожиданий и требований потребителя, уже становился на ноги, но его применение было связано с появлением одной проблемы: затраты увеличивались и рентабельность падала. Выражаясь языком ИСО 9000:2000, мы бы сказали, что снижалась эффективность. Загляните в тот же «Контроль качества продукции» Фейгенбаума и увидите, что он рассказывает о том, как обеспечить качество и остаться рентабельным. Или взять ту же знаковую книгу Т. Питерса и Р. Уотермена «В поисках эффективного управления», вышедшую в 80-х годах ХХ века. Вот оно – направление поисков и вот ответ: процессный подход.

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

Пример.

Меня зовут Андрей, у меня небольшая фирма по сборке компьютеров. Три человека: один (Антон) собирает, один (Алексей) устанавливает программы, третий (Аркадий) тестирует готовый компьютер и проверяет, все ли ПО установлено. Перед каждым сотрудником поставлена цель: максимальная производительность. Но, откровенно говоря, я уже замучался: вроде, парни стараются вовсю, а мы толком не успеваем ничего, сроки поставок срываются, хотя весь офис забит собранными компами, готовыми для установки программ и тестирования. Я уже подумываю о том, не взять ли в аренду пустующую соседнюю квартиру, чтобы организовать там склад. Мы договорились, что за перевыполнение задания каждый получает бонус и так получается, что этот бонус постоянно выше у Антона, а Алексей с Аркадием получают меньше, хотя сил тратят больше. Я чувствую, назревает конфликт. Д и мне, откровенно говоря, бонусы-то платить особо не с чего: мы ведь компьютеров-то больше не продаем, дополнительных денег не появляется. Странная какая-то ситуация складывается: все стараются, о клиентах заботимся: вот ввели новую услугу – сборка по заказу, а доход не увеличивается, а если уж совсем начистоту, то дела-то все хуже идут.

В чем проблема Андрея? Почему при таком напряжении всех сил результат (и эффективность) оказываются не на высоте?

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

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

А теперь небольшое отступление.

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

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

Продолжение примера.

Андрей провел у себя реорганизацию: он всех ребят объединил в одну бригаду, которую возглавил Антон. Цель у бригады одна: постоянный рост дохода. Бонус выплачивается всей бригаде от процента роста.

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

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

Итак, с точки зрения системного подхода процессное управление – это смена точки зрения на состав элементов системы: вместо представления «система = совокупность подразделений», мы используем представление «система = совокупность процессов».

Но если вы решили, что мы ловко обошли все «мины-ловушки», расставленные разработчиками ИСО 9001, и можно уже кричать «ура!», то не торопитесь, ибо нас ждет известный пункт 7.5.2, из которого следует, что процесс для разработчиков стандарта – это совсем не модель, а самая что ни на есть реальная деятельность, которую необходимо «валидировать» (т.е. подтверждать способность… и далее по тексту). Откуда я взял, что в этом пункте речь идет именно о деятельности, а не о представленииэтой деятельности? Да потому, что там черным по белому написано: «…процессы…, результаты которых…». Вы у представлений (моделей) результаты когда-нибудь видели?

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

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

Они могут быть установлены по следующим соображениям.

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

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

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

Таким образом, на текущий момент мы можем констатировать, что

1) процессный подход – это средство повышения эффективности деятельности за счет устранения локальной оптимизации,

2) процессный подход – это изменение объектов управления,

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

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

Построение процессных систем

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

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

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

Начнем с того, что зададимся вопросом: а для чего, для решения каких задач нам могут потребоваться модели процессов?

На мой взгляд, таких задач всего две:

1) регламентирование деятельности и

2) анализ деятельности.

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

И теперь уже совсем нетрудно догадаться, что вторая задача связана с построением модели As Is. И в самом деле: если мы хотим провести анализ деятельности, то нам надо эту деятельность каким-то образом описать, отобразить так, как она реально выполняется.

Небольшое отступление. Очень часто можно встретить следующую рекомендуемую последовательность действий (взято из материалов Betec, выложенных Романом 17марта под заголовком «Бизнес-процессы и оргструктура»):

Весьма, согласитесь, типичный план, но у меня к создателям подобных планов есть один вопрос: на соответствие чему они собираются на этапе 2 анализировать модель «как есть»? Если результатом этого анализа не является установление того, что «не так», то, значит, я не понимаю целей этого анализа. А если эти цели я все же понимаю правильно, то установление того, что «не так» возможно только при сравнении. А сравнение должно быть с тем, как «должно быть». Но, простите, с чем мы будем сравнивать на этапе 2, если построение модели «как надо» у нас запланировано только на этапе 3?

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

А теперь вернемся к нашим баранам, то бишь задачам моделирования As Is и To Be. Поговорим о технологии решения этих задач, ведь традиционно считается, что она и в том, и в другом случае одинакова. И это ошибка! Причем ошибка дорогостоящая!

Попробуем разобраться.

Начнем с построения модели To Be, т.е. решения задачи регламентирования. С чего обычно начинают построение любых моделей? Идут к тем, кто выполняет деятельность, которую необходимо смоделировать, спрашивают, как она выполняется и на основе этих интервью пытаются построить модель. Вопрос: подходит ли такой способ для создания модели, которая должна служить нормой, эталоном? Сомневаюсь. И вот почему. Что должна отражать модель To Be? Как деятельность должна выполняться. Что будет отражать модель, которую мы построим на основе опросов? Как деятельность выполняется. Выходит, что если мы такой модели присвоим статус To Be, то тем самым сделаем законом (нормой) текущий способ выполнения этой деятельности. А где гарантия, что он может таковым являться? Это во-первых. Во-вторых, мы в полном праве использовать понятие «качество процесса» как степень соответствия его заданным требованиям. И если есть нормативное (эталонное) построение процесса, то качество реального процесса будет определяться тем, насколько близко он выполняется к эталонному. А если образцовый (нормативный, эталонный) процесс построен на основе опроса и отражает реальную практику? Тогда мы всегда будем иметь 100%-ное качество! Почему? Да потому, что когда мы начнем строить модель «как есть», то технология будет той же – опрос, соответственно и результат будет тот же. Совпадение гарантировано вне зависимости от того, как процесс выполняется и достигает ли он тех целей, для которых задумывался. Здорово? По-моему, не очень…

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

Итак, все та же модель To Be. Суть ее в том, чтобы представить деятельность так, она должна выполняться, т.е. некое конечное целевое состояние. По сути, это требования к построению процесса. А кто выставляет такого рода требования? Руководитель. А с технической точки зрения – специалист в этой области. А кто у нас специалист в этой области, кто может сказать, как должны быть построены процессы, необходимые системе менеджмента качества? Правильно – менеджер качества. Что для него является при этом путеводной нитью? Правильно, все те знания по построению систем менеджмента вообще и конкретной (например, по модели той же ИСО9001), в частности. Именно менеджера качества учили (учили? :-) ), как правильно строить СМК, как должны быть выстроены процессы (элементы системы) и именно в этом знании его ценность для организации. Специалисты других профилей там уже есть.

Таким образом, менеджер качества сам, никого не спрашивая, разрабатывает нормативную модель To Be, основываясь на общесистемных требованиях и требованиях выбранной организацией модели менеджмента качества. Ведь никого, скажем, не удивляет, что главбух выстраивает в организации процессы бухучета и ни с кем при этом не советуется. Попробуйте-ка ему предложить свою точку зрения на то, как эти процессы должны выглядеть… Реакцию, думаю, нетрудно представить. Так вот, процессы СМК – это точно такая же единоличная епархия менеджера качества! Ему эта епархия дана в управление и он здесь полновластный хозяин, он устанавливает законы деятельности в рамках СМК.

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

И вот здесь мы пойдем туда, где эта деятельность выполняется и начнем спрашивать, как она выполняется и строить модель As Is. А дальше, как уже все догадались, будет анализ этой модели, сравнение ее с моделью To Be. А у меня вопрос: какое условие необходимо выполнить, чтобы анализ был успешен? Ответ: модели To Be и As Is должны быть сравнимыми, т.е. принципиально допускать такое сравнение. Как это сделать? А вот это тема для домашнего размышления :-)

А кстати, навскидку, когда нам могут понадобиться модели As Is и анализ, о котором идет речь? Тут большой загадки, действительно, нет: конечно, при внутреннем аудите СМК. Если на нашей модели To Be обозначена деятельность, а на практике (в модели As Is) ее нет, то вот вам и несоответствие. Например, по нашей модели процессов СМК владелец процесса должен анализировать и оценивать результативность процесса, а в жизни этого нет – управление происходит исключительно «по событию».

И вот какое интересное следствие образуется. Модель To Be – она, по сути, «вечная», ее изменение может потребоваться, если менеджер качества ошибся при составлении, или руководство иную модель менеджмента качества выбрало, или еще что-то в том же духе. А вот «время жизни» модели As Is гораздо короче: провели анализ, внесли изменения в практику и модель в архив (или на помойку) – утеряла актуальность. Вот, кстати, тот риск, который постоянно проявляется в проектах по моделированию процессов и сводит усилия команд на нет: пока они составляли свою модель на основе опросов, деятельность-то уже поменялась и надо все пересматривать. Помните, как у Успенского: «Вымоет мама зеленого сына, Смотрит - а он не зеленый, а синий. Синего мама еще не купала. И начинается дело сначала…». Вот в такие игры с осьминожками и превращаются проекты по моделированию процессов. И все потому, что выбрана неверная технология решения задачи.

Похоже, что пора подводить итоги, а то лекция плавно перерастет в книгу.

Резюме: