Бизнес-процессы. Моделирование, внедрение, управление читать онлайн - Владимир Репин

Бизнес-процессы. Моделирование, внедрение, управление

Владимир Владимирович Репин

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

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

Владимир Репин

Бизнес-процессы. Моделирование, внедрение, управление

Предисловие

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

Глава 1 посвящена общей концепции внедрения процессного подхода, разъяснению основных терминов и определений. В ней приводится обоснование эффективности внедрения процессного подхода, рассматриваются типовой план проекта внедрения и необходимые для этого методики и инструменты.

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

Глава 3 раскрывает подход к построению системы бизнес-процессов. В ней читатель узна?ет о наиболее популярных методах, найдет практические рекомендации по построению системы процессов компании и примеры.

Глава 4 посвящена вопросам описания процессов на операционном уровне. Обсуждаются часто используемые методики моделирования, вопросы создания электронного репозитория[1 - Репозиторий – см. определение на с. 219.] компании. Приводятся примеры схем бизнес-процессов в формате Work Flow.

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

Глава 6 посвящена определению процессов управления и разработке показателей для управления процессами. Приводятся примеры показателей. Обсуждаются вопросы мониторинга процессов и выполнения корректирующих действий, совершенствования процессов на основе цикла PDCA.

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

Глава 1

Процессный подход: концепция внедрения в организации

1.1. Зрелость компании в области процессного управления

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

• бизнес-процесс (процесс);

• архитектура процессов;

• владелец процесса;

• описание процесса;

• регламентация процесса;

• стабильность процесса;

• улучшение процесса;

• автоматизация процесса и т. д.

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

Вместе с президентом они прошлись по офису и заглянули в одну из комнат. Президент спросил у сотрудника: «А скажи-ка нам, что такое процесс?» Тот подскочил и четко выпалил: «То, что имеет вход и выход!»

Еще пример. Сотрудники одной из компаний на вопрос, внедрен ли у них процессный подход, ответили: «Да, конечно. Еще три года назад мы описали процессы и распечатали регламенты. С тех пор они хранятся вон в том шкафу…»

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

В главе 1 приводятся необходимые термины и определения, а затем обсуждается концепция внедрения процессного управления. Руководители организаций могут использовать материалы этой главы для уточнения собственного ви?дения целей и задач внедрения процессного подхода, концепции внедрения, для разработки основных методических документов в области процессного управления[2 - Например, «Методика управления процессами организации» – базовый методический документ, содержащий описание терминов и определений процессного управления, принципы, концепцию внедрения и необходимые методы работы с процессами.].

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

Перед тем как приступить к освоению методов процессного управления, оцените уровень зрелости своей организации. Для этого есть несколько способов, и я приведу пример одной из возможных моделей[3 - Рассматриваемый подход описан в «Исследовании в области моделирования бизнес-процессов» за 2011 год компании BPTrends, перевод которого размещен на сайте www.FineXpert.ru (http://www.finexpert.ru/)]. Концепция уровней зрелости процесса (Process Maturity Levels) была создана в Институте программной инженерии (Software Engineering Institute, SEI) при Университете Карнеги – Меллона в 1990-е гг. В ее основу положена работа Уотса Хамфри. Впервые разработанная для поддержки анализа зрелости процесса программирования (CMM), последняя версия, интегрированная модель технологической зрелости (Capability Maturity Model Integrated, CMMI), была обобщена для любого из широкого спектра процессов в различных организациях

(рис. 1.1.1).

Приведу краткое описание каждого из уровней, указанных на рис. 1.1.1.

Уровень 1. Процессы не определены

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

Уровень 2. Определены некоторые процессы

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

Уровень 3. Определено большинство процессов

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

Уровень 4. Процессы находятся под управлением

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

Пример. Компания, в которой давно внедрена система бизнес-моделирования, создан и используется репозиторий бизнес-процессов, контролируется исполнение регламентов по процессам, внедрена система управления эффективностью BPM[4 - BPM (Business Performance Management) – управление эффективностью деятельности (бизнеса).] для оперативного мониторинга и управления процессами, относится к уровню 4. В такой компании (а это, скорее всего, крупный, устойчивый бизнес) есть необходимое количество штатных специалистов, профессионально владеющих методами моделирования бизнес-процессов, разработкой и анализом KPI[5 - KPI (Key Performance Indicators) – ключевые показатели эффективности.] и т. п. Эти специалисты могут осваивать и внедрять сложные методики и инструменты в области управления бизнес-процессами.

Уровень 5. Процессы непрерывно совершенствуются

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

На каком уровне зрелости находятся российские компании?

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

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

• наличие и поддержание в актуальном состоянии архитектуры (системы) бизнес-процессов компании (система BPA[6 - BPA (Business Process Architecture) – система для разработки архитектуры бизнес-процессов компании.]);

• действующая система стандартизации (регламентации) деятельности (в первую очередь процессов); использование системы класса ECM[7 - ECM (Enterprise Content Management) – управление корпоративной информацией.] для поддержки жизненного цикла нормативно-методических документов (регламентов, положений, инструкций);

• наличие и активное использование для мониторинга, анализа, улучшения и стимулирования системы показателей (метрик) по бизнес-процессам; используется система BI[8 - BI (Business Intelligence) – бизнес-анализ, бизнес-аналитика. Под этим понятием чаще всего подразумевают программное обеспечение, созданное для помощи менеджеру в анализе информации о своей компании и ее окружении.]/BPM;

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

• наличие центра компетенции (департамента /отдела) по организационному развитию с представителями в каждом департаменте (функциональное подчинение);

• автоматизация наиболее важных сквозных процессов в BPMS[9 - BPMS (Business Process Management System) – тип программного обеспечения для поддержки выполнения операционных процессов.].

1.2. Термины и определения процессного подхода

1.2.1. Структурная схема процесса

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

Процесс включает в себя деятельность по преобразованию ресурсов и деятельность по управлению. Сформулируем определение:

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

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

Под ресурсом понимается материальный или информационный объект, необходимый для выполнения процесса.

С точки зрения состояния ресурсы могут:

• храниться;

• перемещаться;

• находиться в состоянии обработки.

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

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

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

На рис. 1.2.1 показано, что с точки зрения процесса ресурсы могут быть преобразуемыми, преобразованными, обеспечивающими и ресурсами

по управлению. Приведу необходимые определения.

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

Преобразованный ресурс – тот, к которому добавлена определенная ценность при выполнении процесса.

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

Ресурс по управлению – необходимый для управления процессом.

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

Выход процесса – преобразованный при выполнении процесса ресурс.

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

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

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

• выделяться процессу на постоянной основе.

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

Трансформируются ли обеспечивающие ресурсы при выполнении процесса? С точки зрения рассматриваемой модели – нет. В реальной жизни обеспечивающие ресурсы меняются:

• сотрудники приобретают опыт работы, стареют и т. п.;

• оборудование изнашивается;

• программное обеспечение морально устаревает.

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

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

Вернемся к рис. 1.2.1. Деятельность по управлению процессом, представленная на схеме, включает улучшение процесса и регулирование процесса (оперативное управление).

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

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

Они являются выходами деятельности по управлению процессом.

Говоря об управлении процессом, определим понятие «владелец процесса».

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

Подход, при котором для каждого выделенного процесса назначается владелец процесса, появился давно[10 - См. работу М. Хаммера и Д. Чампи [1].]. Сейчас существует множество различных взглядов на то, что собой представляет владелец процесса и чем он должен заниматься. Однако чем больше консультанты по управлению рассуждают об этом, тем меньше ясности для практиков – руководителей, которые должны внедрять институт владельцев процессов в компании.

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

В целом владелец процесса – это руководитель, способный как минимум:

• проводить мониторинг хода процесса;

• анализировать факторы, влияющие на процесс и приводящие к вариациям;

• разрабатывать предложения по улучшению процесса и организовывать их обсуждения и согласования;

• координировать (или управлять) внутренние проекты совершенствования процесса.

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

1.2.2. Границы процесса

Понятие границ процесса является важнейшим при внедрении процессного подхода. Подчеркну, что установление границ осуществляется субъективно – путем достижения договоренности между несколькими сторонами (поставщиками и потребителями). Для обсуждения границ процесса нужно сформулировать несколько определений.

Границы процесса – событие (совокупность событий), инициирующее и завершающее процесс.

Событие – наступление определенной ситуации (времени, перехода ответственности за ресурсы).

Инициирующее событие – событие, при наступлении которого начинается процесс.

Завершающее событие – событие, которым завершается процесс.

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

первого процесса это событие завершает процесс, с точки зрения владельца второго процесса – инициирует его. Одно и то же событие может быть сформулировано по-разному при описании границ двух рассматриваемых процессов. Первый владелец скажет, что ресурс «А» передан, а второй – что ресурс «А» получен. Чтобы при описании процессов было удобнее увязывать их в единую систему, лучше определять одно событие и давать ему примерно такую формулировку: «Ресурс “А” передан из процесса 1 в процесс 2»[11 - Если названия процессов длинные, то такая форма наименования события не совсем удобна. Но в то же время длинная формулировка полнее характеризует реальное событие.]. В любом случае формулировки событий должны быть обязательно согласованы между владельцами процессов при регламентации границ.

Приведем примеры формулировки событий, связанных с движением материальных ресурсов:

• «Товар помещен в зону хранения»;

• «Продукция упакована и передана покупателю»;

• «Оборудование установлено».

Примеры формулировки событий, связанных с передачей информации:

• «Поступил заказ клиента»;

• «Факс отправлен»;

• «Руководитель дал отмашку».

Последний пример приведен в шутку. С практической точки зрения такая формулировка события недопустима. Лучше сформулировать так: «Поступило распоряжение руководителя приступить к выполнению работы» (желательно в письменной форме или хотя бы по e-mail).

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

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

Еще пример: рассмотрим отправку какого-либо документа по корпоративной электронной сети. Факт отправки документа сотрудником можно описать событием «Документ отправлен по e-mail». Однако сотрудник, которому отправлен данный документ, может его получить не сразу или вообще не получить (сбой сети, случайное удаление и т. п.). Значит, инициировать процесс второго сотрудника будет событие «Получен документ по e-mail». Очевидно, что это два разных события. В данном случае можно:

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

• рассматривать передачу документа по электронной сети в качестве самостоятельного, но автоматически выполняемого процесса, имеющего своего владельца и т. п.[12 - Этот вариант использовать не рекомендуется.]

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

Итак, для четкого определения границ процесса необходимо:

• определить, какие ресурсы движутся внутрь и вовне процесса (входы и выходы);

• определить инициирующие и завершающие события;

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

1.2.3. Спецификации на входы и выходы процесса

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

Спецификации могут детально описывать требования, которым должны удовлетворять:

• документация;

• сырье, вспомогательные и упаковочные материалы;

• полуфабрикаты;

• готовые изделия;

• производственные и офисные помещения, инфраструктура;

• персонал;

• оборудование;

• программное обеспечение;

• прочее.

В спецификации необходимо фиксировать все требования, предъявляемые к объекту конкретным процессом (табл. 1.2.1–1.2.3).

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

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

Содержание спецификаций зависит от типа входа или выхода процесса. Ниже приводится несколько примеров структуры спецификаций[14 - * Это только примеры. В случае практического применения разрабатывается структура спецификаций, необходимая для процессов конкретной компании.** ТУ – технические условия.*** Можно дать ссылки на методики верификации и валидации продукта либо привести сами методики.].

1.2.4. Контроль входов/выходов процесса

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

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

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

Важным понятием, которое стоит использовать при работе с границами процессов, является «операционное определение» (см. [4])[15 - В данном случае я предлагаю свое определение. В книге Э. Деминга четкая формулировка операционного определения отсутствует, хотя этому вопросу посвящена целая глава. Он предлагает «облечь понятие в определенную форму, ясную всем». Кстати, Э. Деминг приводит такой пример некорректного операционного определения: «Отливки должны быть приемлемо чистыми». Очевидно, что при наличии такого определения у процесса-потребителя всегда будут претензии к процессу-поставщику.].

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

Пример. Образец некорректного операционного определения – формулировка понятия «предельно допустимая концентрация» (ПДК). Официально она звучит так: «Максимальное количество вредного вещества в единице объема или массы, которое при ежедневном воздействии в течение неограниченного времени не вызывает каких-либо болезненных изменений в организме человека… В Российской Федерации устанавливается законодательно для каждого вредного вещества». Видел ли кто-нибудь человека, живущего неограниченное время? В любом организме постоянно происходят изменения, в том числе болезненные, которые вызваны сотней различных причин. Можно ли назвать такое определение ПДК четким и однозначным? Вероятно, нет.

Типичная ситуация: руководитель ставит сотруднику задачу, а потом проверяет ее исполнение, при этом выражая свое неудовольствие. Сотрудник не может понять, в чем дело, ведь он выполнил работу в срок и качественно. Но, как оказалось, у руководителя и сотрудника разные представления о приемлемости требуемого результата. Если бы с самого начала существовали четко сформулированные критерии приемки/проверки, конфликта бы не было. Такая ситуация в первую очередь выявляет недостаточную компетентность руководителя.

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

«Для оценки качества уборочных работ принимается пятибалльная система. Высшей оценкой качества уборочных работ является “пять” баллов при отсутствии замечаний по текущей и генеральной уборке к санитарному состоянию проверенных номеров. Снижение оценки производится по “Шкале оценки уборочных работ” (приложение № …) при наличии замечаний по текущей и генеральной уборке к санитарному состоянию проверенных номеров…»

Замечания, сформулированные в шкале оценки, по сути, и являются операционными определениями[16 - Некорректные, на мой взгляд, операционные определения выделены далее курсивом.] результата работы горничных. Каковы же эти определения?

«…Замечания, выявленные при генеральной уборке:

1. Грязные: окна, двери, стены, ковролин, полы, радиаторы отопления, все виды обшивки, светильники, зеркала, картины, холодильник, телефон, телевизор, радиоприемник.

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

3. Грязные или рваные тюль, портьеры, покрывала, постельные принадлежности.

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

5. Пыль на мягкой мебели.

6. Отсутствие папки с информационными материалами.

7. Перестановка мебели без указания администрации.

8. Неукомплектованность инвентарем в номере более одного предмета.

9. Техническая неисправность оборудования (мебели, сантехоборудования, электроприборов, телевизора, телефона, кондиционера, замков и т. д.) при отсутствии заявки на ремонт в журнале.

…Одно из вышеперечисленных замечаний оценивается в 1 балл…»

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

Как определить несоответствия? Это возможно, когда:

• есть документально зафиксированные требования по расстановке предметов (планограммы и т. п.) и они нарушены – предметы переставлены[17 - Мне не нравится, когда горничная переставляет предметы как полагается и при этом нарушает комфортную для клиента расстановку, которую он создал сам.];

• возникает «бинарная» ситуация: либо занавеска порвана, либо нет;

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

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

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

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

• физических параметров ресурсов (требований ТУ, формы, веса, цвета, упаковки);

• информационных параметров[18 - Термины «параметр» и «показатель» используются в данной книге в качестве синонимов.] (формы, структуры и содержания документа, параметров достоверности и точности информации);

• временны?х и пространственных параметров[19 - То есть должны быть четко определены события.] (времени передачи, места передачи);

• экономических параметров (затрат, себестоимости, доли наценки, цены и т. п.).

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

• показатели оценки результатов процесса (изделия, документа);

• методики измерения этих показателей;

• оборудование для измерения показателей;

• условия измерения (среда, место, время).

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

Говоря о контроле выходов процесса, следует упомянуть о таких понятиях, как верификация и валидация. В стандартах ИСО 9000 на систему менеджмента качества приводятся следующие определения этих терминов (см. пп. 3.8.4 и 3.8.5 в [5]):

«3.8.4

Верификация (verification) —

подтверждение (посредством предоставления объективных свидетельств (3.8.1)) того, что установленные требования (3.1.2) были выполнены.

Примечание 1. Термин “верифицировано” используется для обозначения соответствующего статуса.

Примечание 2. Деятельность по подтверждению может включать такие виды деятельности, как:

• осуществление альтернативных расчетов,

• сравнение технических условий (3.7.3), относящихся к новому проекту, с аналогичной документацией по апробированному проекту,

• проведение испытаний (3.8.3) и демонстраций, и

• анализ документов до их выпуска.

3.8.5

Валидация (validation) —

подтверждение (посредством представления объективных свидетельств (3.8.1)) того, что требования (3.1.2), относящиеся к конкретному предполагаемому использованию или применению, были выполнены.

Примечание 1. Термин “валидировано” используется для обозначения соответствующего статуса.

Примечание 2. Условия применения для конкретного применения могут быть реальными или смоделированными».

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

Пример. Был подготовлен проект бизнес-плана. Его проверили на соответствие требованиям корпоративного шаблона. Структура документа соответствовала установленным в компании требованиям, то есть проект был верифицирован. Однако анализ бизнес-плана независимым экспертом показал, что ряд прогнозов ошибочен, часть расчетов была выполнена некорректно и т. д. По такому бизнес-плану невозможно было бы работать. Таким образом, при проведении валидации выяснилось, что бизнес-план не соответствует требованиям организации.

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

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

1.2.5. Технология выполнения процесса

Вспомним структурную схему процесса (рис. 1.2.1). Можно утверждать, что деятельность в рамках процесса в определенной своей части выполняется по технологии, то есть не хаотично, бессистемно. А что такое технология? В Википедии[20 - Интернет-энциклопедия.] приводятся следующие определения:

«1. Техноло?гия (от греч. tеchne – ‘искусство, мастерство, умение’ и греч. logos – ‘изучение’) – совокупность методов и инструментов для достижения желаемого результата; метод преобразования данного в необходимое; способ производства.

2. Технология – в узком смысле – способ преобразования вещества, энергии, информации в процессе изготовления продукции, обработки и переработки материалов, сборки готовых изделий, контроля качества, управления.

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

4. Технологией, или технологическим процессом, часто называют также сами операции добычи, транспортировки и переработки, которые являются основой производственного процесса».

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

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

«технология».

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

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

1.2.6. Окружение процесса

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

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

Внутренний потребитель – потребитель, находящийся внутри организации.

Внешний потребитель – потребитель, находящийся вне организации.

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

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

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

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

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

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

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

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

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

1.2.7. Классификация процессов

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

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

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

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

Процесс управления – процесс, поставляющий на вход других процессов ресурсы по управлению.

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

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

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

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

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

Ценность – значение, представляемое продуктом/услугой для удовлетворения той или иной потребности субъекта, производящего оценку.

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

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

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

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

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

Сквозной (межфункциональный) процесс – тот, в котором участвует несколько структурных подразделений организации.

Тот факт, что сквозной процесс проходит через несколько различных структурных подразделений, скорее

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

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

При описании процессов на разных уровнях управления возникает вопрос, как называть процесс каждого уровня. Некоторые консультанты употребляют множество терминов: «макропроцесс», «бизнес-процесс», «процесс», «процедура», «функция», «операция», «работа», «активность» и т. п. Термин «бизнес-процесс» интерпретируют по-разному. Одни считают, что бизнес-процесс проходит через всю организацию и приносит прибыль[22 - Это когда-то вычитали в западных изданиях и начали бездумно тиражировать в России.]. Другие выделяют бизнес-процессы на всех уровнях. Чаще всего такие классификации оказываются непрактичными и запутывают сотрудников. В книге термины «процесс» и «бизнес-процесс» будут рассматриваться в качестве синонимов.

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

Декомпозиция процесса – разделение его на составляющие части.

Подпроцесс – процесс следующего уровня декомпозиции.

Замечу, что деятельность можно называть «подпроцессом» только в контексте рассмотрения процесса вышестоящего уровня.

На рис. 1.2.4 показано, как осуществляется декомпозиция процесса. При декомпозиции желательно разбивать его на несколько подпроцессов – от 2 до 10. Можно выделять даже 12 подпроцессов, если в противном случае приходится вводить дополнительные формальные уровни иерархии. Дело в том, что реальная жизнь всегда сложнее, чем любая теория или методика. На практике бывает удобно показывать при декомпозиции 10–12 подпроцессов. Это в основном касается описания процессов на среднем и нижнем уровнях.

Процессы самого верхнего уровня можно называть «процессными категориями». Регламентировать процесс верхнего уровня (процессную категорию) одним нормативно-методическим документом нецелесообразно, поскольку полученный документ будет формальным, громоздким и неудобным для практического использования[23 - Так же ошибочно приравнивать деятельность крупного структурного подразделения процессу и разрабатывать регламент выполнения такого «процесса». Целесообразно выделять реальные процессы внутри подразделения (может быть, некоторые при этом будут сквозными) и разрабатывать регламенты для этих процессов. Для описания деятельности подразделения можно разработать положение о подразделении, в котором указать перечень выполняемых процессов и ответственных за них.]. Важно корректно разработать систему процессов на нескольких уровнях, а регламентацию процессов следует начинать разумно (с третьего, иногда – с четвертого уровня)[24 - Это не означает, что не нужны документы верхнего уровня – положения о подразделениях. Речь идет только о процессах.].

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

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

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

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

Процедура – алгоритм выполнения некоторой части или процесса в целом.

Понятие процедуры вводится для решения следующих задач:

• описания обезличенных процессов, которые могут использоваться в различных подразделениях организации разными сотрудниками (примеры: «процедура управления документооборотом», «процедура управления договорами», «процедура оформления заявки» и т. п.);

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

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

Характерный пример обезличенных процессов – процедуры, разрабатываемые при внедрении системы менеджмента качества.

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

Пример. В организации есть call-центр. Множество операторов постоянно находятся на связи – принимают входящие звонки, обзванивают клиентов и т. п. Каждый оператор обязан выполнять работу по установленным процедурам. Их разработано несколько: процедура приема входящих звонков, процедура отправки факсов и т. д.

С точки зрения директора в деятельности call-центра можно выделить несколько процессов, например:

• обслуживание входящих звонков;

• обслуживание исходящих звонков;

• администрирование рабочих групп call-центра;

• подключение клиента и т. д.[25 - Взяты некоторые процессы из опыта работы реального call-центра.]

Рассмотрим процесс обслуживания входящих звонков. С точки зрения директора call-центра важно, чтобы все входящие звонки были качественно обработаны при минимальном количестве операторов. Для процесса «Обслуживание входящих звонков»

определены:

• технология выполнения (описана в соответствующих процедурах);

• требования к обеспечивающим ресурсам (необходимое оборудование, каналы связи, операторы с требуемыми навыками);

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

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

Рассмотрим рис. 1.2.5. На нем представлена деятельность подразделения, внутри которого выделено шесть операций[26 - Показана линейная последовательность операций. В реальности схема может быть гораздо сложнее, содержать циклы и т. д.]. Часть деятельности структурирована в виде процесса «А», который включает операции 1, 2, 3, 4 (другой процесс – «Б» включает операции 5 и 6). Операции процесса «А» выполняются последовательно, то есть работа переходит от одного сотрудника к другому. Допустим, что в начале рабочего дня процесс «А» начал осуществляться и к определенному времени операции 1 и 2 были выполнены, а операция 3 – только запущена (флажок напротив операции 3). В это время на вход операции 1 поступил ресурс, требующий обработки, то есть процесс «А» запускается еще раз (флажок напротив операции 1). Как описать такую ситуацию при помощи определений? Для этого вводится понятие «экземпляр процесса».

Экземпляр процесса – деятельность по выполнению совокупности операций процесса, обеспечивающая получение единичного результата процесса[27 - Некоторые операции из их общей совокупности при выполнении экземпляра процесса могут быть выполнены несколько раз (циклы, возвраты, доработки и т. п.).].

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

Оперировать понятием «экземпляр процесса» целесообразно только на уровне операционных процессов. Для более высокого уровня это понятие практически неприменимо.

Использование понятия «экземпляр процесса» является важным при автоматизации операционных процессов при помощи систем Work Flow, BPMS.

Обсудив некоторые подходы к классификации процессов, я введу такое важное понятие, как архитектура (система процессов) организации.

Архитектура (система процессов) – совокупность всех взаимосвязанных и взаимодействующих процессов организации.

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

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

• процессы различных уровней (три – пять уровней в зависимости от размеров организации);

• участники процессов;

• владельцы процессов;

• границы процессов (по входам/выходам и событиям).

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

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

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

Моделирование (описание) процессов – отражение в виде модели субъективного ви?дения реально существующих в организации процессов.

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

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

1.2.8. Показатели для управления процессом

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

Показатель – количественный или качественный параметр, характеризующий объект управления.

Как правило, для каждого показателя определяют:

• наименование и код в системе показателей организации;

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

• должность лица, ответственного за достижение целевого значения показателя;

• должность лица, ответственного за расчет показателя;

• периодичность расчета показателя и отчетный период;

• текстовое описание;

• единицу измерения;

• методику расчета;

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

• перечень плановых (отчетных) форм, включающих показатель.

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

Показатель процесса – показатель, характеризующий процесс как объект управления.

Показатель выхода (продукта) процесса – показатель, характеризующий выход (продукт) процесса как объект управления.

Показатель удовлетворенности потребителя процесса – показатель, характеризующий степень удовлетворенности потребителя процесса выходом (продуктом) процесса.

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

Пример. Организация продает автозапчасти. За прошлый месяц было реализовано 200 амортизаторов для определенной модели автомашин. Объем продаж амортизаторов является показателем процесса. Какой же показатель в данном случае может характеризовать продукт? Например, доля амортизаторов (из числа реализованных за месяц), которые вышли из строя в течение трех месяцев с момента продажи[29 - Конечно, такой показатель рассчитать непросто. Но поставить такую задачу все-таки можно.].

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

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

Качество результата процесса – степень соответствия результатов процесса требованиям и ожиданиям потребителей.

С точки зрения практики важны еще два определения:

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

Эффективность процесса – отношение между достигнутым результатом и использованными ресурсами.

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

Более подробно разработка и использование показателей описываются в главе 6.

1.2.9. Определение процессного подхода

Итак, я представил необходимые определения. Осталось дать определение процессного подхода[30 - В настоящее время в некоторых компаниях используется понятие «процессирование». «Процессирование» – новомодный термин, означающий описание, регламентацию и управление процессами; мне он не нравится. Многие термины приходят к нам с Запада. Но лучше обходиться своими формулировками, и русский язык для этого достаточно богат.].

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

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию (http://www.litres.ru/vladimir-repin/biznes-processy-modelirovanie-vnedrenie-upravlenie/?lfrom=931425718) на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

notes

Примечания

1

Репозиторий – см. определение на с. 219.

2

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

3

Рассматриваемый подход описан в «Исследовании в области моделирования бизнес-процессов» за 2011 год компании BPTrends, перевод которого размещен на сайте www.FineXpert.ru (http://www.finexpert.ru/)

4

BPM (Business Performance Management) – управление эффективностью деятельности (бизнеса).

5

KPI (Key Performance Indicators) – ключевые показатели эффективности.

6

BPA (Business Process Architecture) – система для разработки архитектуры бизнес-процессов компании.

7

ECM (Enterprise Content Management) – управление корпоративной информацией.

8

BI (Business Intelligence) – бизнес-анализ, бизнес-аналитика. Под этим понятием чаще всего подразумевают программное обеспечение, созданное для помощи менеджеру в анализе информации о своей компании и ее окружении.

9

BPMS (Business Process Management System) – тип программного обеспечения для поддержки выполнения операционных процессов.

10

См. работу М. Хаммера и Д. Чампи [1].

11

Если названия процессов длинные, то такая форма наименования события не совсем удобна. Но в то же время длинная формулировка полнее характеризует реальное событие.

12

Этот вариант использовать не рекомендуется.

13

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

14

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

** ТУ – технические условия.

*** Можно дать ссылки на методики верификации и валидации продукта либо привести сами методики.

15

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

16

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

17

Мне не нравится, когда горничная переставляет предметы как полагается и при этом нарушает комфортную для клиента расстановку, которую он создал сам.

18

Термины «параметр» и «показатель» используются в данной книге в качестве синонимов.

19

То есть должны быть четко определены события.

20

Интернет-энциклопедия.

21

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

22

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

23

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

24

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

25

Взяты некоторые процессы из опыта работы реального call-центра.

26

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

27

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

28

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

29

Конечно, такой показатель рассчитать непросто. Но поставить такую задачу все-таки можно.

30

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