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

Предисловие

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

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

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

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

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

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

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

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

(обратно)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

_{Рис. 1.1.1. Обзор основных уровней зрелости по модели СММI}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• наличие и активное использование для мониторинга, анализа, улучшения и стимулирования системы показателей (метрик) по бизнес-процессам; используется система BI^[8]/BPM;

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

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

• автоматизация наиболее важных сквозных процессов в BPMS^[9].

_{Рис. 1.2.1. Структурная схема процесса}

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

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

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

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

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

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

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

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

• храниться;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

_{Рис. 1.2.2. Границы процессов}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• персонал;

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

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

• прочее.

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

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

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

Содержание спецификаций зависит от типа входа или выхода процесса. Ниже приводится несколько примеров структуры спецификаций^[14].

_{Таблица 1.2.1. Структура спецификации для готового продукта}

_{Таблица 1.2.2. Структура спецификации на производственные помещения}

_{Таблица 1.2.3. Структура спецификации на человеческие ресурсы (персонал)}

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.3. Потребители и поставщики процесса}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

_{Рис. 1.2.4. Декомпозиция процесса}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• подключение клиента и т. д.^[25]

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

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

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

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

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

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

_{Рис. 1.2.5. Экземпляры процесса}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак, я представил необходимые определения. Осталось дать определение процессного подхода^[30].

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

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

Главная цель управления процессами – успешное развитие организации путем совершенствования процессов. Процессное управление позволяет обеспечить:

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

• рост объемов продаж, увеличение прибыли;

• постоянное повышение эффективности деятельности организации;

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

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

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

• возможность тиражирования стандартных процессов;

• возможность успешно развиваться и долго сохранять лидерство на рынке.

Основой для совершенствования процессов является цикл PDCA.

Цикл PDCA (Plan-Do-Check-Act) – цикл непрерывного улучшения процессов Шухарта – Деминга

Более подробно цикл PDCA рассмотрен в главе 6.

1.3. Обоснование эффективности процессного подхода^[31]

1.3.1. Стабильность и воспроизводимость процесса

Основная задача данного пункта – показать, что структурированный и управляемый процесс всегда эффективнее хаотичной и плохо управляемой деятельности. Как ни странно, некоторым руководителям это утверждение не кажется очевидным. Когда речь заходит о необходимости описания и наладки процессов, они заявляют: «Мы и так нормально работаем. Зачем нам еще заниматься какими-то процессами, что-то описывать, анализировать?!» Рассмотрим схему, представленную на рис. 1.3.1.

_{Рис. 1.3.1. Стабильный и воспроизводимый процесс (в широком смысле)}

На рис. 1.3.1 представлен график изменения значений одного из показателей, характеризующих результат процесса. Видно, что за все время измерения этого показателя его значения не выходили за верхнюю и нижнюю границы. Если мы можем обоснованно (то есть при помощи определенной методики) предсказать, что значение показателя не выйдет за указанные границы в течение разумного времени, то это означает, что процесс является стабильным (по рассматриваемому показателю). Какое время считать разумным? Если период наблюдения составил один квартал, то разумным временем формирования прогноза можно считать, например, месяц. Безусловно, при наличии возможности лучше выполнить соответствующие расчеты, построить контрольные карты Шухарта и определить, находится ли процесс в состоянии статистической управляемости (см. [6]). Но поскольку многим руководителям этот метод кажется слишком сложным, введем для себя следующие определения.

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

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

Также на рис. 1.3.1 показано распределение значений показателя по данным, полученным за все время наблюдений^[33].

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

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

На рис. 1.3.2 представлены распределение значений показателя (то же, что и на рис. 1.3.1) и функция потерь Генити Тагути. Тагути показал, что в ближайшей окрестности номинального значения показателя вид функции потерь представляет собой параболу^[34]. Функция потерь показывает величину потерь ресурсов различного вида, которые возникают в организации при отклонении значений показателя процесса от номинального.

_{Рис. 1.3.2. Потери для центрированного и смещенного процессов}^[35]

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

Таким образом, можно сделать простой вывод:

Потери ресурсов для стабильного и воспроизводимого процесса будут всегда меньше потерь в случае нестабильного и невоспроизводимого процесса.

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

1.3.2. Вариации процесса

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

Каковы причины вариаций? Профессор Э. Деминг (см. [4]) выделял две группы причин: общие и особые. С моей точки зрения, общие причины можно также назвать системными. Рассмотрим каждую из двух групп причин.

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

На рис. 1.3.3 показано, что? происходит с процессом с течением времени.

_{Рис. 1.3.3. Влияние общих и особых причин}

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

Можно сделать вывод, что:

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

1.3.3. Экономическая целесообразность регламентации процесса

Рассмотрим следующую ситуацию. Представим, что мы потратили определенное время и ресурсы на приведение процесса к стабильному состоянию. Определим некоторые значения:

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

?_опт. – величина ресурсов (затраты), израсходованных на эту деятельность (опт. – от слова оптимизация).

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

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

?_{опт. пр.} – величина ресурсов, израсходованных на операционную деятельность по оптимизированному, стабильному и воспроизводимому процессу за время T.

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

?_{не опт. пр.} – величина ресурсов, израсходованных на операционную деятельность по неоптимизированному процессу за время T.

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

?_{опт. пр.} < ?_{не опт. пр.} (1)

Запишем также следующее неравенство:

?_опт. + ?_{опт. пр.} < ?_{не опт. пр.} (2)

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

Ситуация 1. Стабильная внешняя среда.

Данная идеальная ситуация характеризуется тем, что:

• система общих причин, воздействующих на процесс, не изменяется в течение неограниченного времени;

• воздействие возникающих особых причин не является чрезмерным^[36]; система управления обеспечивает устранение особых причин и поддержание процесса в стабильном и воспроизводимом состоянии.

Очевидно, что в такой идеальной ситуации через некоторое время неравенство (2) всегда будет справедливо. В рассматриваемом случае ? << T.

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

Ситуация 2. Медленные изменения внешней среды.

Ситуация 2 характеризуется тем, что:

• система общих причин, воздействующих на процесс, медленно меняется со временем. При этом система управления успевает адаптировать процесс к изменяющимся условиям без существенных, скачкообразных изменений^[37]. Привлечение дополнительных ресурсов не требуется;

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

В такой ситуации неравенство (2) также будет справедливо с некоторого момента времени. Хотя этот момент может наступить позже, чем в ситуации 1. В данном случае ? < T. Величина T характеризует временной интервал работы процесса до момента идентифицируемого изменения внешней среды.

Ситуация 3. Резкие изменения внешней среды.

Ситуация 3 характеризуется тем, что:

• система общих причин, воздействующих на процесс, со временем резко и непредсказуемо меняется^[38]; система управления не успевает адаптировать процесс к изменяющимся условиям; требуется привлечение дополнительных ресурсов для стабилизации процесса;

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

Для данной ситуации ? ~ T, то есть интервал времени, после которого происходят резкие, существенные изменения внешних условий, сопоставим со временем, потраченным на оптимизацию системы управления. В рассматриваемой ситуации неравенство (2) может оказаться несправедливым. Если в такой ситуации затягивать проект внедрения процессного подхода, то эффект никогда не будет получен (? > T).

Анализ трех рассмотренных ситуаций позволяет сформулировать следующие четыре предположения:

1. Для организаций, ведущих деятельность в условиях стабильной внешней среды, внедрение процессного подхода всегда приводит к росту эффективности.

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

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

4. Для организаций, работающих в весьма нестабильных внешних условиях^[39] (? >> T), внедрение процессного подхода может не принести ожидаемого эффекта. В данной ситуации деятельность организации возможна только благодаря наличию культуры героев и расходованию дополнительных ресурсов.

1.3.4. Структурированный процесс или самоорганизация?

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

_{Рис. 1.3.4. Структурирование и самоорганизация деятельности}

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

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

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

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

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

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

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

Чтобы путем самоорганизации можно было получить результат, необходимо наличие:

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

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

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

• мотивации у сотрудников решить поставленные руководством задачи.

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

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

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

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

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

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

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

• возможность тиражирования процесса;

• возможность масштабирования процесса.

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

• сеть магазинов;

• сеть филиалов;

• сеть представительств;

• группу производственных предприятий одного типа;

• прочее.

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

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

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

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

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

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

Подводя итоги, можно сделать следующие выводы:

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

2. При внедрении процессного подхода в организации обязательно должны появиться структурированные процессы^[40], обеспечивающие гибкость и адаптивность самой системы процессов к изменяющимся условиям внешней среды. Иными словами, должны совершенствоваться не только процессы управления, но и процессы выполнения деятельности.

1.4. Концепция внедрения процессного подхода

1.4.1. Общее описание концепции «Совершенствование процессов»

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

С моей точки зрения, внедрение процессного подхода в организации означает, что:

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

• создана и постоянно совершенствуется система показателей (метрик) для управления процессами; целевые значения для ряда показателей^[41] устанавливаются в рамках системы стратегического управления;

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

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

• руководители всех уровней непрерывно совершенствуют свои процессы;

• создана и активно используется система регламентации процессов, исполнение регламентов контролируется; электронный репозиторий процессов и база НМД поддерживаются в актуальном состоянии;

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

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

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

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

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

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

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

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

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

1.4.2. Процессный подход на уровне организации в целом

На рис. 1.4.1 показаны три уровня. Изменения, возникающие при внедрении процессного подхода на уровне организации в целом, представлены в табл. 1.4.1.

_{Таблица 1.4.1. Элементы системы процессного управления на уровне организации в целом}

^{* Приводится описание только тех элементов, которые должны появиться при внедрении процессного подхода. Полное описание процесса стратегического управления выходи за рамки содержания книги.}

_{Таблица 1.4.1 (окончание)}

^{* В отличие от существующей практики, акцент при оперативном управлении делается на процессы.}

^{** Может рассматриваться как часть системы стратегического управления.}

^{*** НМД – нормативно-методическая документация.}

1.4.3. Обеспечение организационного развития при внедрении процессного подхода

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

_{Рис. 1.4.1. Требования в рамках концепции «Совершенствование процессов»}

_{Таблица 1.4.2. Элементы системы процессного управления на уровне системы организационного развития}

^{* На рис. 1.4.1 «Управление НМД» и «Поддержка репозитория» обведены пунктирной линией, что указывает на тесную связь данных элементов в системе.}

^{** Репозиторий создается при помощи специализированной среды моделирования процессов. Информация о процессах, как правило, хранится в промышленной базе данных.}

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

1.4.4. Управление процессами на уровне владельцев процессов

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

_{Таблица 1.4.3. Элементы системы процессного управления на уровне владельцев процессов}

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

• анализ процесса (в том числе при помощи статистических методов);

• описание процесса в определенной нотации (утвержденной в виде стандарта организации);

• разработка регламентирующих документов;

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

• управление проектами;

• прочее.

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

1.4.5. Краткое описание работы системы, построенной по концепции «Совершенствование процессов»

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

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

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

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

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

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

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

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

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

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

Владельцы процессов вовлечены в деятельность по непрерывному совершенствованию процессов на основе цикла PDCA. Они анализируют процессы, выявляют потери, разрабатывают и реализуют проекты (мероприятия) по совершенствованию процессов. Лучшая практика выполнения работы закрепляется в нормативно-методических документах, которые становятся основной базой для совершенствования деятельности по процессу.

Активно ведется работа по обучению сотрудников лучшим методам работы, вовлечению в деятельность по непрерывному совершенствованию процессов.

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

Руководство компании постоянно проводит мониторинг работы всех элементов системы (рис. 1.4.1) на всех уровнях управления. Деятельность владельцев процессов по управлению процессами находится под контролем. Руководство поддерживает владельцев процессов, помогает им осваивать методы процессного подхода, вовлекает их в деятельность по совершенствованию процессов.

1.4.6. Важность выделения ресурсов на организационное развитие

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

• подразделение по организационному развитию (отдел развития, центр активного развития, управление стандартизацией процессов и качеством и т. п.);

• регламентированные процессы по обеспечению организационного развития.

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

1.4.7. Разработка собственной концепции внедрения процессного подхода

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

1.4.8. Концепция «Формализация процессов»

Внедрение процессного подхода, основанное на принципе непрерывного совершенствования, – сложная задача. Ее решение требует от руководителей лидерства и самоотдачи на протяжении нескольких лет. Опыт показывает, что собственники и руководители некоторых российских компаний^[42] не видят целесообразности в построении системы процессного подхода, основанной на непрерывном совершенствовании. Они считают достаточным разработку и использование системы нормативно-методических документов, регламентирующих процессы. Требования к системе процессного управления при такой постановке задачи (концепция «Формализация процессов») представлены на рис. 1.4.2.

_{Рис. 1.4.2. Требования в рамках концепции «Формализация процессов»}

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

В результате внедрения процессного подхода по концепции «Формализация процессов» в компании:

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

• исполнение требований НМД по процессам контролируется;

• репозиторий процессов и база НМД поддерживаются в актуальном состоянии;

• можно тиражировать процессы (в другие подразделения, сеть, филиалы и т. п.);

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

• можно автоматизировать процессы;

• прочее.

Все это положительные результаты. Однако при использовании такой концепции внедрения сложно или невозможно:

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

• обоснованно и последовательно совершенствовать базу регламентирующих документов;

• обеспечивать поддержание процессов в стабильном и воспроизводимом состоянии^[43];

• создавать корпоративную культуру, ориентированную на управление процессами и развитие.

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

1.4.9. Краткое описание работы системы, построенной по концепции «Формализация процессов»

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

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

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

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

Цель внедрения процессного подхода по концепции «Формализация процессов» – создание и поддержание в порядке системы нормативно-методических документов по процессам, организация управления процессами на основе формализованной системы показателей, ориентированной на достижение стратегических целей компании. Цикл PDCA в организации не работает. Персонал в деятельность по улучшению процессов не вовлекается. Сотрудники просто работают по регламентам^[44]. Процессы контролируются при помощи системы показателей. Развитие осуществляет подразделение организационного развития точечно. Для крупных внутренних проектов (например, по автоматизации процессов) привлекаются внешние специализированные организации.

1.5. Принципы процессного подхода

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

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

Ориентация на удовлетворение потребителей

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

Системный подход

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

Выделение и управление сквозными процессами

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

Четкие границы

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

Измеримость процессов

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

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

Поддержание стабильности и воспроизводимости процессов

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

Непрерывное совершенствование

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

1.6. Проект внедрения процессного подхода

1.6.1. Общее описание этапов проекта

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

Проект внедрения процессного подхода состоит из следующих этапов:

1. Принятие решений.

2. Подготовка.

3. Разработка процессной архитектуры организации.

4. Разработка системы показателей для управления процессами.

5. Организация управления процессами.

6. Описание и регламентация процессов.

7. Запуск цикла PDCA.

График Ганта проекта внедрения процессного подхода показан на рис. 1.6.1.

_{Рис. 1.6.1. График Ганта проекта внедрения процессного подхода}

1.6.2. Принятие решений

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

• основные определения процессного похода;

• цели внедрения процессного подхода;

• принципы процессного управления;

• концепцию внедрения процессного подхода в организации;

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

Называть этот документ можно по разному, например «Концепция внедрения процессного подхода в организации “Х”».

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

1.6.3. Подготовка

На основе утвержденной «Концепции внедрения процессного подхода» на этапе подготовки выполняются следующие работы:

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

• подбор людей, в первую очередь руководителя проекта;

• разработка основных методических документов по проекту;

• разработка плана выполнения проекта (или устава проекта);

• обучение персонала на различных уровнях;

• издание приказа о начале проекта.

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

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

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

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

• положение о рабочей группе;

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

• стандарт описания процессов (соглашение о моделировании);

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

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

• процедура управления внутренними нормативно-методическими документами;

• план (устав) проекта;

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

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

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

• снижающих риск неудачного выполнения проекта.

В качестве примера приведу структуру документа «Методика управления процессами организации».

1. Область применения документа

2. Термины и определения

3. Нормативные ссылки

4. Общее описание процессного управления

4.1. Цели процессного управления

4.2. Принципы процессного управления

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

5. Методика разработки/корректировки системы процессов

5.1. Разработка системы процессов

5.1.1. Формирование системы процессов

5.1.2. Построение модели процессов на верхнем уровне

5.1.3. Структурирование деятельности подразделений

5.1.4. Выделение сквозных (межфункциональных) процессов

5.1.5. Определение необходимых уровней детализации процессов

5.1.6. Определение границ процессов

5.1.7. Определение участников процессов

5.1.8. Определение зон ответственности и назначение владельцев процессов

5.1.9. Кодирование процессов

5.2. Корректировка системы процессов компании

5.3. Ведение справочника процессов компании

6. Методика построения и использования системы показателей

6.1. Определение ви2дения будущего бизнеса

6.2. Построение стратегической карты и ССП^[46], подразделений

6.3. Построение системы отчетов по показателям

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

7. Методика регламентации деятельности

7.1. Подход к регламентации деятельности компании

7.2. Регламентация процессов верхнего уровня

7.3. Регламентация процессов операционного уровня

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

7.5. Регламентация деятельности сотрудников

7.6. Согласование регламентирующих документов

7.7. Утверждение регламентирующих документов

7.8. Размещение в базе НМД

7.9. Актуализация

8. Методика управления процессами

8.1. Оперативное управление процессами

8.1.1. Планирование процессов

8.1.2. Мониторинг процесса

8.1.3. Разработка и выполнение корректирующих действий

8.1.4. Совершенствование процесса на основе цикла PDCA

8.1.5. Стандартизация процессов

8.1.6. Формирование отчетности по процессу

8.2. Выполнение цикла PDCA на уровне компании

8.3. Организация и проведение внутреннего аудита процессов

8.4. Развитие компетенций сотрудников и делегирование полномочий

9. Приложения

9.1. Приложение 1. Шаблон матрицы процессов подразделения/компании

9.2. Приложение 2. Нотация для описания цепочек создания ценности компании «Финэксперт. ру»

9.3. Приложение 3. Шаблон ви2дения будущего бизнеса компании

9.4. Приложение 4. Шаблон сбалансированной системы показателей компании

9.5. Приложение 5. Шаблон стратегической карты компании

9.6. Приложение 6. Шаблон управленческого отчета по сбалансированной системе показателей компании

9.7. Приложение 7. Шаблон регламента процесса верхнего уровня

9.8. Приложение 8. Шаблон операционной карты (инструкции)

9.9. Приложение 9. Шаблон положения о подразделении

9.10. Приложение 10. Шаблон должностной инструкции

9.11. Приложение 11. Форма плана/отчета по процессу

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

Обучение персонала – важнейшая задача подготовительного этапа. Полезно проводить обучение на трех уровнях:

• собственники и руководители организации;

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

• руководители среднего звена и специалисты.

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

1.6.4. Разработка процессной архитектуры организации

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

1. Порядковый номер в таблице.

2. Наименование процесса.

3. Руководитель, ответственный за выполнение процесса (владелец процесса).

4. Участники процесса (перечень подразделений или должностей).

5. Входы процесса.

6. Выходы процесса.

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

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

Разработка процессной архитектуры (системы процессов) позволяет:

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

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

• получить основу для разработки показателей (метрик) для управления процессами^[47];

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

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

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

• прочее.

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

1.6.5. Разработка системы показателей

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

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

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

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

• ориентация системы показателей на повышение операционной эффективности^[48] процессов и удовлетворенности внутренних и внешних клиентов;

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

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

Этап разработки показателей заканчивается утверждением:

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

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

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

1.6.6. Организация управления процессами

Этап организации управления процессами – ключевой с точки зрения внедрения процессного подхода по концепции «Совершенствование процессов».

Организация управления процессами означает, что владельцы процессов:

• планируют выполнение своих процессов с использованием установленных показателей (метрик);

• оперативно проводят мониторинг хода и результатов выполнения процессов;

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

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

• разрабатывают и реализуют проекты по совершенствованию процессов.

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

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

1.6.7. Описание и регламентация процессов

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

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

• внедрена процедура управления нормативно-методической документации; НМД организации поддерживается в актуальном состоянии;

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

• владельцы процессов освоили инструмент описания и регламентации процессов;

• владельцы процессов осуществляют периодический контроль исполнения требований НМД по своим процессам;

• владельцы процессов используют НМД в качестве инструмента для совершенствования процессов и обучения персонала;

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

1.6.8. Запуск цикла PDCA

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

• собственники и руководители организации были вовлечены в этот цикл:

– постоянно анализировали результативность и эффективность выполняемых проектов по совершенствованию процессов;

– выделяли необходимые ресурсы для выполнения проектов по совершенствованию процессов;

– анализировали достижение целей по совершенствованию процессов, периодически корректировали эти цели (с учетом корректировки стратегии, требований клиентов и т. д.);

– поддерживали и развивали систему организационного развития (анализ эффективности, планирование развития, выделение ресурсов);

– организовывали постоянное обучение персонала;

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

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

– анализировали свои процессы;

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

– развивали свой персонал, вовлекали его в деятельность по совершенствованию процессов.

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

1.7. Автоматизация процессного управления

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

Набор программных продуктов^[49], необходимых для комплексного управления процессами, показан в табл. 1.7.1.

_{Рис. 1.7.1. Автоматизация процессного управления: комплекс программных продуктов}

_{Таблица 1.7.1. Комплекс программных продуктов для управления процессами}

^{** В данном случае рассматривается только часть возможностей такой системы.}

^{*** Сейчас ПО такого типа принято называть Business Performance Management.}

^{**** Здесь – Business Process Management System.}

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

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

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

Для организации управления процессами необходимо обеспечить возможность планирования процессов по ряду показателей и последующего их мониторинга с использованием оперативной фактической информации. Конечно, формировать планы и отчеты по показателям процессов можно вручную в файлах MS Excel. Но гораздо эффективнее делать это при помощи специализированного программного обеспечения. Программные продукты для формирования планов, сбора и представления фактической информации в виде удобных аналитических отчетов получили название систем управления эффективностью (Business Performance Management System). Порядок их работы можно кратко описать так: при выполнении процессов возникают первичные фактические данные, которые фиксируются различными прикладными системами (учетные системы, производственные системы, системы ERP и т. д.). Система управления эффективностью получает эти данные, хранит их в специализированной базе данных и предоставляет для руководителей удобный доступ к ним при помощи информационных панелей управления, формирует необходимые отчеты. Таким образом, руководители получают плановую и фактическую информацию, необходимую для оперативного управления процессами.

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

1.8. Список литературы

1. Хаммер М., Чампи Д. Реинжиниринг корпорации. Манифест революции в бизнесе. – М.: Манн, Иванов и Фербер, 2007.

2. Jeston J., Nelis J. Management by Process: A Practical Road-map to Sustainable Business Process Management. – Burlington, USA: Elsevier Ltd., 2008.

3. Всеобщее управление качеством / О. П. Глудкин [и др.]. – М.: Лаборатория базовых знаний, 2001.

4. Деминг Э. Выход из кризиса. Новая парадигма управления людьми, системами и процессами. – М.: Альпина Бизнес Букс, 2009.

5. ГОСТ Р ИСО 9001–2008. Системы менеджмента качества. Требования.

6. Уилер Д., Чамберс Д. Статистическое управление процессами. Оптимизация бизнеса с использованием контрольных карт Шухарта. – М.: Альпина Бизнес Букс, 2009.

Глава 2
Сквозные процессы в организации

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

2.1. Организация как система

Любая организация – это сложная социальная система. В разные времена авторы исследований рассматривали ее под различными углами зрения. В результате сформировалось несколько моделей организации, например [1]:

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

• Организация – машина (А. Файоль, Л. Урвик). Выделение функциональных звеньев, планирование, координация, контроль.

• Организация – община (Э. Мэйо, Ф. Ротлисбергер). «Неформальная» структура организации, социально-психологическая «организация в организации».

• Организация – система (Дж. Марч, Г. Саймон). Техническая подсистема, административная, неформальная, экономическая и т. п.

• Организация – организм (Ари де Гиус). Внутренние органы, характер, болезни и т. п.

• Организация – бюрократическая структура (М. Вебер). Бюрократическая концепция социума, рационализация поведения человека, стандартизация деятельности.

• Организация – политическая система (М. Крозье). Классовая концепция устройства. Групповые интересы.

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

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

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

Пример. Нефтяная компания. Часть I

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

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

• рекомендуемые расходные материалы;

• графики и состав работ по техническому обслуживанию;

• режимы работы;

• требования к компетенции персонала, занимающегося эксплуатацией.

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

Пример. Нефтяная компания. Часть II

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

Пример. Логистический комплекс. Набор персонала

Рядом с крупным городом был построен новый складской комплекс категории «А». На стадии запуска комплекса генеральный директор поставил задачу перед директором по персоналу: набрать в течение месяца значительное количество сотрудников – грузчиков, водителей штабелеров, кладовщиков. Предполагалось, что в ближайшее время компания начнет обслуживание двух крупных клиентов, для каждого из которых потребуется большое количество палетомест^[51] на складе. Директор по персоналу предпринял отчаянные попытки набрать нужное количество персонала, использовал все свои связи, дневал и ночевал в офисе. К назначенному сроку персонал был набран, но клиенты на склад «не заехали». Дело в том, что процессы, необходимые для их обслуживания, не были своевременно отлажены. Эксперты со стороны клиентов провели анализ состояния дел, оценили риски возникновения проблем и не рекомендовали руководителям своих компаний пользоваться услугами данного склада до устранения выявленных несоответствий. Но персонал склада уже был набран и регулярно получал зарплату. Такая ситуация продолжалась несколько месяцев. Иными словами, решение генерального директора, принятое без согласования с другими менеджерами и без понимания реального состояния системы (степени ее готовности к работе и соответствия требованиям клиентов), привело к значительным потерям.

Пример. Гипермаркет

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

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

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

Пример. Завод по производству ЛДСП

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

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

2.2. Синергия

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

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

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

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

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

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

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

• возможность налаживания коммуникаций между субъектами;

• единая система измерений:

– ценности;

– цели и показатели;

– операционные определения;

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

• наличие мотивации у сотрудников.

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

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

Пример. Административные барьеры

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

Пример. Технические барьеры

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

Третье необходимое условие синергии – наличие единой системы целей и показателей для оценки результатов выполнения процессов (в том числе так называемых операционных определений^[52]). Если у сотрудников подразделений разное понимание ценности, создаваемой процессом для клиента, целей и показателей оценки их достижения (или они вообще отсутствуют), то получить эффект синергии при совместной работе сложно.

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

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

Подводя итоги, можно сформулировать следующие тезисы:

• организация – это сложная система, основу которой составляют люди;

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

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

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

2.3. Сквозные процессы

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

Пример. Выпуск газеты-меню

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

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

• несоответствующий дизайн обложки и фотографий;

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

• низкое качество полиграфии;

• прочее.

Указанные проблемы могут быть вызваны следующими причинами:

• сотрудники не понимают свою роль в процессе подготовки газеты-меню;

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

• взаимодействие между сотрудниками носит хаотический характер;

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

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

Конечно, схема процесса, представленная на рис. 2.3.1, далека от идеала. Но главное, что она позволяет:

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

• обсудить его;

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

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

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

• контролировать выполнение процесса в установленные сроки.

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

_{Рис. 2.3.1. Процесс разработки меню}

_{Рис. 2.3.2. Фрагмент процесса обработки заказа клиента}

Пример. Обработка заказа клиента

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

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

Пример. Отправка оборудования клиенту

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

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

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

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

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

• есть повреждения оборудования при упаковке;

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

• прочее.

При сборке оборудования у заказчика возникают следующие проблемы:

• задержки с началом сборки (неготовность заказчика или задержка приезда монтажной бригады);

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

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

• ошибки в спецификации (неточности в документах);

• потеря необходимых документов;

• недостаточная компетенция сборщиков монтажной бригады;

• отсутствие необходимых инструментов (забыли взять);

• нехватка смазочных материалов;

• прочее.

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

_{Рис. 2.3.3. Отправка оборудования клиенту}

Так чем же полезно компании выделение сквозных процессов? Приведу только некоторые важные аспекты:

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

• сотрудники начинают «видеть процессы целиком» и понимают свою роль в удовлетворении потребностей клиентов;

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

• повышаются результативность, эффективность и качество процессов;

• организация как система изменяется (становится более эффективной).

2.4. Критерии выделения сквозных процессов

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

Процесс можно считать сквозным (межфункциональным), если:

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

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

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

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

• существует возможность значительного улучшения деятельности (усиления эффектов синергии) за счет оптимизации межфункционального взаимодействия в рамках процесса^[53].

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

2.4.1. Определение границ сквозного процесса

На рис. 2.4.1 схематично показаны различные варианты выделения сквозных процессов в организации. Например, взаимодействие начальника и его подчиненного в рамках одного структурного подразделения не следует рассматривать как сквозной процесс. То же можно сказать про взаимодействие нескольких сотрудников одного подразделения. Безусловно, при описании такого процесса можно использовать схему типа sweem line («плавательный бассейн»)^[54], но этот процесс не будет сквозным. Наоборот, взаимодействие сотрудников различных отделов может рассматриваться в качестве сквозного процесса. При этом он может быть описан на уровне взаимодействия как отделов (уровень процессов отделов), так и отдельных сотрудников (уровень операций сотрудников).

_{Рис. 2.4.1. Границы сквозных процессов}

Отмечу, что любой процесс (в том числе сквозной) определяется его границами. Но выбор границ – это субъективное решение руководителей, участвующих в их определении и согласовании. На рис. 2.4.2 показан пример, когда в зависимости от определения границ получается либо два процесса, выполняемых внутри различных подразделений, либо один сквозной процесс. Называть какое-то одно решение, представленное на рис. 2.4.2, единственно верным некорректно. Оба имеют право на существование. При выборе второго варианта в процессе участвуют сотрудники двух различных подразделений, то есть он может рассматриваться как сквозной. Но можно ограничиться и вариантом 1. Как принять правильное решение? Практика показывает, что для достижения эффективного межфункционального взаимодействия (получения эффектов синергии) зачастую недостаточно структурировать деятельность внутри подразделений и согласовать входы/выходы^[55]. Необходимо, чтобы кто-то из руководителей видел сквозной процесс целиком и отвечал за его оптимизацию с точки зрения получения конечного результата. Стыковка процессов структурных подразделений по входам/выходам полезна, но не в полной мере обеспечивает получение конечного результата.

_{Рис. 2.4.2. Варианты определения границ процесса}

2.4.2. На каком уровне целесообразно выделять сквозные процессы?

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

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

_{Рис. 2.4.3. Цепочка создания ценности}

На рис. 2.4.3 процесс показан на уровне бизнеса (даже нескольких бизнесов), а не подразделений и отдельных сотрудников. Назовем мы такой процесс сквозным или нет – суть вопроса от этого не изменится. Объект слишком сложный, чтобы можно было описать и проанализировать все важные взаимодействия на уровне сотрудников, работающих в рассматриваемых компаниях. Вряд ли в такой сложной системе можно определить процесс, в котором участвуют сотрудники из всех этих организаций (представляете, сколько метров будет занимать графическая схема такого процесса?!). Однако определение сквозного процесса на уровне операций сотрудников нескольких организаций в определенной части ЦСЦ вполне возможно (рис. 2.4.4). Выделение и оптимизация такого сквозного процесса может обеспечить усиление синергетических эффектов на уровне цепочки создания ценности.

_{Рис. 2.4.4. Сквозной процесс на межорганизационном уровне}

Рассмотрим еще один пример – на рис. 2.4.5. В филиале или СБЕ^[56] компании директор управляет тремя основными процессами: закупкой сырья, производством и сбытом товара. Нужно ли рассматривать процесс, представленный на рис. 2.4.5, как сквозной? Безусловно, нет.

_{Рис. 2.4.5. Процесс филиала}

Показанные на рисунке процессы фактически представляют собой почти всю деятельность данной организации. После выделения сквозного процесса «Закупка – Производство – Сбыт» что-либо проанализировать и потом изменить сложно^[57]. Придется декомпозировать процессы и переходить на операционный уровень. Уровень рассмотрения, представленный на рис. 2.4.5, слишком высок с точки зрения анализа и принятия конкретных решений по улучшению взаимодействия сотрудников различных подразделений^[58]. Но если мы рассмотрим, например, операционную деятельность по формированию и согласованию заявки на обеспечение сырьем, то сквозной процесс выделить легко (см. нижнюю часть рис. 2.4.5). Так же можно определить и другие сквозные процессы.

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

На более высоком уровне деятельность компании можно и нужно рассматривать в виде нескольких групп взаимодействующих процессов операционного уровня^[59].

2.4.3. Возможность управления сквозным процессом

Представим себе, что мы выделили сквозной процесс, в котором участвуют шесть крупных структурных подразделений одной организации и два подразделения – другой. Всего в процессе участвуют около 150 сотрудников, находящихся на разных должностях и уровнях управления. Сможет ли таким сложным процессом управлять один человек? Иными словами, можно ли подобрать владельца процесса для такого сложного объекта управления? Да, безусловно, но этому сотруднику потребуется:

• разделить такой сквозной процесс на несколько частей^[60] (например, пять-шесть);

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

Что может произойти при попытке организовать управление столь сложным сквозным процессом? Наряду с уже существующей в организации иерархической структурой управления появится еще одна – структура для управления сквозными процессами. Они будут конфликтовать между собой из-за ресурсов. Потребуется затратить существенные средства и время на решение этой проблемы^[61], например переходя на матричную схему управления. Но стоит ли этим заниматься? В конце главы 2 я даю развернутый ответ на этот вопрос и предлагаю двухуровневую систему управления сквозными процессами.

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

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

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

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

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

2.4.4. Важность результата сквозного процесса

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

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

• достижения целей организации;

• системной оптимизации ее деятельности;

• улучшения коммуникаций между структурными подразделениями;

• усиления синергетических эффектов, возникающих на межфункциональном уровне.

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

2.4.5. Сколько сквозных процессов должно быть в организации?

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

Целесообразно выделять столько сквозных процессов, сколько нужно для обеспечения эффективного межфункционального взаимодействия структурных подразделений организации^[62] и усиления синергетических эффектов.

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

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

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

• эти проблемы приводят к потерям ресурсов (материальных, финансовых и т. д.);

• эффективность деятельности организации в целом снижается;

• поставленные собственниками цели достигаются лишь частично;

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

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

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

• прочее.

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

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

2.5. Типовой перечень сквозных процессов

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

_{Таблица 2.5.1. Примеры сквозных процессов, объединенных в группы по условным категориям}

^{* Может быть также показан в разделе «Производственные процессы».}

^{** Часть процессов этой группы можно было бы отнести к производственным процессам. В данную группу они выделены потому, что в них участвует потребитель продукции/услуг организации.}

_{Таблица 2.5.1 (окончание)}

^{* Может также рассматриваться в качестве проекта.}

^{** ЗИП – запасные части и принадлежности.}

Пример. Сквозные процессы в ретейле

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

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

• Формирование ассортиментной матрицы (управление жизненным циклом товара).

• Ввод данных о товаре в систему.

• Заказ товара у поставщика.

• Оперативное управление платежами.

• Заключение договоров с поставщиками товара.

• Планирование прихода товара на РЦ^[63].

• Доставка товара с РЦ в магазины (в том числе формирование отгрузочных документов по магазинам – по данным фактического подбора товара на складе).

• Заказ товара магазинами.

• Прием товара в магазине.

• Продажа товара на кассе.

• Переоценка товара в магазинах и на складе в связи с изменением цены в приходах товара.

• Инвентаризация магазинов.

• Управление планограммами и выкладкой товаров.

• Возврат товара из магазинов.

• Формирование списков на возврат товара поставщику, включая остатки такого товара на складе.

• Резервирование товара на складе (в ячейках) под внутренние и внешние заказы.

• Перескладировки товара (изменение зон или ячеек хранения) для оптимизации наполнения склада.

• Внутрискладские перемещения товара по участкам хранения/обработки, включая процесс подбора товара по заказам.

• Управление ценами.

• Бюджетирование.

2.6. Сквозные процессы в системе процессов компании

Как показывать сквозные процессы в системе процессов компании?^[64] Для ответа на этот вопрос рассмотрим несколько примеров.

Пример. Сквозные процессы в области продаж

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

_{Таблица 2.6.1. Состав процессов активных продаж}

^{** ОП – отдел продаж.}

^{*** CRM (Customer Relationship Management) – управление взаимоотношениями с клиентами.}

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

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

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

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

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

Рассмотрим другой пример, представленный в таблице ниже.

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

Торгово-производственная компания. В категории процессов «Инженерно-техническое обеспечение» определена группа процессов «Обслуживание механического оборудования». Курсивом в табл. 2.6.2 выделен сквозной процесс.

_{Таблица 2.6.2. Процессы категории «Инженерно-техническое обеспечение»}

Как видим, бо?льшая часть процессов выполняется силами сотрудников отдела главного механика. Да, в этих процессах участвует несколько сотрудников. Безусловно, такие процессы удобно описывать и анализировать в виде диаграмм sweem line. Но сквозной процесс в данном примере только один – «Закупка ЗИП и инструмента для ремонта механического оборудования».

Пример. Сквозные процессы в лаборатории

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

_{Таблица 2.6.3. Группа процессов «Входной контроль сырья»}

^{* ЦЛ – центральная лаборатория.}

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

Другой процесс – «Формирование заключений по партиям сырья» – также важен, но формально называть его сквозным некорректно.

2.7. Сквозные процессы и проекты

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

Если есть сомнения в правильности идентификации объекта управления (процесс или проект?), используйте следующие критерии. Деятельность можно рассматривать в качестве сквозного процесса (а не проекта), когда:

• основная цель деятельности не меняется;

• деятельность регулярно повторяется;

• деятельность выполняется по неизменной технологии;

• состав участников остается практически неизменным.

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

Деятельность лучше называть проектом, когда:

• ее цель может существенно меняться от случая к случаю;

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

• имеет четкое ограничение во времени;

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

• состав участников меняется.

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

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

2.8. Подходы к управлению сквозными процессами

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

2.8.1. Способ 1 «Ничего не менять»

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

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

2.8.2. Способ 2 «Организация группы вокруг процесса»

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

_{Рис. 2.8.1. Организация группы вокруг процесса}

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

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

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

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

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

2.8.3. Способ 3 «Матричное управление»

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

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

_{Рис. 2.8.2. Матричное управление процессами}

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

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

2.8.4. Способ 4 «Куратор со стороны высшего руководства»

В работах некоторых «классиков» менеджмента качества можно найти следующие рекомендации:

• выделять небольшое количество сквозных процессов;

• назначать кураторами этих процессов топ-менеджеров компании.

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

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

_{Рис. 2.8.3. Куратор со стороны высшего руководства}

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

2.8.5. Способ 5 «Мониторинг владельцем процесса и куратор свыше»

Более практичен способ управления сквозными процессами, представленный на рис. 2.8.4. Вышестоящими руководителями назначается владелец процесса^[68]. Он может, кстати, быть начальником одного из подразделений, участвующих в процессе.

_{Рис. 2.8.4. Мониторинг владельцем процесса и куратор свыше}

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

В случае возникновения отклонений при выполнении процесса его владелец:

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

• либо информирует куратора процесса.

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

В рамках данного подхода владелец процесса имеет следующие полномочия:

• управлять ресурсами, находящимися в рамках его подразделения, а также дополнительно выделенными ему для реализации сквозного процесса^[69];

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

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

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

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

Этот метод управления сквозным процессом наиболее прост и практичен.

2.8.6. Способ 6 «Управление через регламенты»

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

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

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

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

• операционных или технологических картах;

• инструкциях для персонала;

• прочем.

Наиболее важные из разработанных регламентов обсуждаются на уровне топ-менеджеров, утверждаются и вводятся в действие. Последующий контроль исполнения регламентирующих документов возлагается на начальников соответствующих структурных подразделений^[70] и службу внутреннего аудита.

_{Рис. 2.8.5. Управление сквозными процессами через регламенты}

2.9. Управление сквозными процессами в масштабах компании

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

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

2.9.1. Локальные сквозные процессы?!

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

_{Рис. 2.9.1. Локальный сквозной процесс}

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

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

Замечу, что при описании процессов нередко складывается следующая ситуация. Бизнес-аналитик описывает процесс. По ходу работы появляется большое количество шагов (операций). Листа А4 явно не хватает. Аналитик увеличивает размер листа до А3. Но через некоторое время и этого мало. В чем причины? Они заключаются в:

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

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

• нечетком структурировании процессов компании в виде иерархического справочника (отсутствие системы процессов).

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

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

2.9.2. Группы сквозных процессов

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

_{Рис. 2.9.2. Группа сквозных процессов}

Пример. Торговая компания

В группу процессов под названием «Реализация товара» компании входят следующие:

• получение заявок клиентов на отгрузку продукции;

• обработка заявки клиента;

• формирование графика доставки товара клиентам;

• обработка отложенных («ждущих») заявок;

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

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

• прочее.

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

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

Пример. Торгово-производственная компания

В крупной торгово-производственной компании в группу процессов «Разработка нового продукта/измененного текущего продукта» входят следующие процессы:

• разработка и утверждение вариантов рецептуры на продукт;

• изготовление пробных образцов;

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

• декларирование продукта;

• разработка и регистрация технических условий;

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

• прочее.

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

Акцентирую внимание на следующих моментах:

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

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

Практическое использование указанного подхода потребует как минимум:

• корректно определить границы и участников локальных сквозных процессов;

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

• обеспечить управление и оптимизацию локальных сквозных процессов;

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

2.9.3. Как организовать управление сквозными процессами и группами процессов

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

_{Рис. 2.9.3. Двухуровневая схема управления сквозными процессами}

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

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

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

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

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

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

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

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

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

В книге «Быстрее, лучше, дешевле. Девять методов реинжиниринга бизнес-процессов» [6] он пишет о «3,5 метра сквозного процесса». Эта была схема, которую разработала его группа в рамках одного из проектов реинжиниринга. Далее Хаммер отмечает, что таким объектом сложно управлять. Целесообразно вести речь о группе процессов, взаимодействующих между собой. В книге приводится много любопытных примеров оптимизации группы процессов, которая стала возможной за счет работы владельцев процессов при активной поддержке топ-менеджеров и собственников компании.

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

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

• Работу по описанию и анализу выполняют только бизнес-аналитики и некоторые сотрудники подразделений. При этом топ-менеджеры:

– относятся к процессной работе формально;

– уделяют ей слишком мало времени;

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

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

2.9.4. Выбор метода управления сквозными процессами

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

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

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

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

• критерии выделения сквозных процессов;

• количество выделенных сквозных процессов и групп процессов;

• важность групп процессов для достижения целей компании;

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

• наличие опыта по управлению проектами.

2.10. Владелец процесса: ответственность и полномочия

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

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

• часть (доля) деятельности сквозного процесса, которая приходится на конкретное подразделение (руководитель этого подразделения – кандидат на роль владельца процесса);

• заинтересованность руководителя в повышении эффективности (оптимизации) сквозного процесса;

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

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

• коммуникабельность руководителя;

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

• прочее.

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

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

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

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

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

Дж. Харрингтон в книге «Совершенство управления процессами» [5] приводит следующие вопросы, на которые нужно ответить, подбирая владельца процесса:

• У кого из менеджеров наибольшее количество подчиненных занято в данном процессе?

• Кто из них расходует больше всего рабочего времени на этот процесс?

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

• Чья репутация укрепится сильнее всего при условии надлежащего управления процессом?

• Кто из них получит наибольшие выгоды от надлежащего функционирования процесса?

• Кто обладает наибольшими возможностями для внесения изменений в процесс?

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

• видеть последствия для данного процесса изменений бизнес-целей организации;

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

• утверждать и реализовывать план внедрения изменений в процесс;

• контролировать эффективность и результативность процесса.

Еще одним важным обстоятельством при выборе собственника процесса являются личные качества кандидатов. Владелец процесса должен:

• вызывать всеобщее доверие к себе;

• уметь увлекать за собой других работников;

• быть опытным переговорщиком;

• охотно принимать необходимость перемен;

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

• быть дальновидным;

• не бояться рисковать;

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

• не бояться того, что его будут оценивать по достигнутым результатам».

Рассмотрим также обязанности и полномочия руководителя (владельца) процесса согласно Хаммеру. Владелец процесса (у Хаммера [6] объект управления руководителя процесса – группа сквозных процессов):

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

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

• определяет и отслеживает показатели эффективности процесса;

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

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

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

• определяет, какие изменения и в каком порядке необходимо внести в процесс, решает все связанные с этим вопросы;

• устанавливает и оценивает показатели исправной работы процесса^[71];

• сравнивает показатели эффективности процесса с показателями эффективности в других компаниях;

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

• разрешает все проблемы, связанные с выполнением процесса.

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

Приведем еще обязанности и полномочия начальника отдела. По мнению Хаммера, начальник отдела:

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

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

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

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

Что касается высшего руководства компании, то, по мнению Хаммера, оно:

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

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

• обеспечивает ему со своей стороны полную поддержку;

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

• четко определяет границы ответственности и полномочий между руководителями процессов и начальниками отделов;

• дает руководителю процесса реальную власть и средства для проведения своих решений в жизнь.

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

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

2.11. Список литературы

1. Пригожин А. И. Методы развития организаций. – М.: МЦФЭР, 2003.

2. Деминг Э. Выход из кризиса. Новая парадигма управления людьми, системами и процессами. – М.: Альпина Бизнес Букс, Альпина Паблишер, 2009.

3. Хаммер М., Чампи Д. Реинжиниринг корпорации. Манифест революции в бизнесе. – М.: Манн, Иванов и Фербер, 2007.

4. Конти Т. Самооценка в организациях. – М.: Стандарты и качество, 2000.

5. Харрингтон Дж. Совершенство управления процессами. – М.: Стандарты и качество, 2007.

6. Хаммер М., Хершман Л. Быстрее, лучше, дешевле. Девять методов реинжиниринга бизнес-процессов. – М.: Альпина Паблишер, 2012.

Глава 3
Разработка системы процессов организации

3.1. Определение системы процессов организации

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

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

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

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

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

Система процессов может быть описана в файле MS Excel или в виде специального справочника в инструментальном средстве моделирования процессов^[72].

Пример. Система процессов торгово-производственной компании представлена в виде графической схемы на рис. 3.1.1. Эта компания занимается производством и реализацией промышленной продукции.

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

1. Процессная категория (1-й уровень).

1.1. Процессная группа (2-й уровень).

1.1.1. Процесс (3-й уровень).

1.1.1.1. Операционный процесс (4-й уровень).

1.1.1.1.1. Операция (5-й уровень).

1.1.1.1.1.1. Транзакция (6-й уровень).

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

_{Таблица 3.1.1. Определения уровней деятельности в системе процессов организации}

_{Рис. 3.1.1. Пример представления системы процессов организации в виде графической схемы}

Система процессов может строиться сразу в виде иерархического справочника процессов. Другой возможный вариант – описание модели деятельности компании на верхнем уровне в некоторой нотации с последующим представлением в виде иерархического справочника. Если речь идет о построении системы процессов для действующей организации, то, с моей точки зрения, полезно разрабатывать систему процессов сразу в виде справочника, не формируя графическую модель верхнего уровня. Форма справочника более понятна большинству руководителей. Далеко не все топ-менеджеры могут воспринимать сложные графические модели структурного типа (например, в нотации IDEF0^[73]).

После того как система процессов в виде иерархического справочника построена, при необходимости могут быть созданы модели деятельности в виде графических схем. На уровнях 1–3 целесообразно использовать структурные типы моделей (например, IDEF0). С уровня 4 (для небольших компаний – с уровня 3), как правило, описание выполняют при помощи схем в формате Work Flow. Удобный способ их визуального представления – кросс-функциональные схемы, содержащие дорожки. На каждой дорожке указываются операции, выполняемые подразделениями/сотрудниками/бизнес-ролями. Пример: «начальник отдела продаж» – сотрудник, «инициатор договора» – бизнес-роль. Подробно методики описания графических схем в формате Work Flow рассмотрены в главе 4.

Пример. Аналогия с техническим устройством

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

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

Так и в компании. При создании модели верхнего уровня объединение потоков и агрегирование операций процессов остается на совести бизнес-аналитика. Сделать это можно по-разному. Если при создании электронных приборов действуют хотя бы некоторые стандарты, то при создании системы процессов организации таких стандартов фактически нет^[74]. Есть только нотации для создания графических схем и некоторое ви?дение типовой структуры категорий процессов на верхнем уровне («Продажи», «Производство», «Закупка»…). Но что получится в результате моделирования, очень зависит от компетенции и опыта бизнес-аналитика.

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

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

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

Пример. Согласно требованиям стандарта IDEF0 на схеме не может быть более 8 объектов деятельности (подпроцессов). Но в реальности часто требуется показывать большее число подпроцессов. Что делать в случае, если на схеме IDEF0 показано 12 подпроцессов? Создавать 3 отдельные модели по 5 + 4 + 3 подпроцесса в каждой? Агрегировать 12 подпроцессов на 3 подпроцесса («основные», «вспомогательные», «управленческие») с последующей декомпозицией? Однозначного ответа нет.

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

Для описания системы процессов организации можно использовать MS Excel (мне известны примеры крупных компаний, которые поддерживают репозиторий процессов в этой программе).

Форма представления системы процессов в MS Excel показана на рис. 3.1.2. Каждая процессная категория находится на отдельном листе файла.

_{Рис. 3.1.2. Представление системы процессов в виде таблицы MS Excel}

Пример. Модель процессов APQC

Обращаю внимание читателя на созданный американской компанией APQC (American Productivity and Quality Center) «Общий классификатор процессов для различных отраслей» (Cross Industry Process Classification Framework^[75]). Он постоянно корректируется, дополняется новыми процессами. Структура процессов в классификаторе APQC включает 12 категорий, каждая из которых описана на отдельном листе в файле MS Excel. Этот справочник интересен как пример создания сложной системы процессов современной организации. Недостаток справочника – его сложность и всеохватность, из-за которой его трудно применять для внедрения процессного подхода в конкретной компании.

При формировании дерева процессов и описании его в виде таблицы (рис. 3.1.2) возникает вопрос – как правильно показывать входы/выходы для процессов? Для нижнего уровня (четвертого и, возможно, третьего) ответ очень прост: следует описывать конкретные документы (бумажные, электронные) и материальные потоки. Но что делать при описании входов/выходов для процессов верхнего уровня (первый-второй, иногда^[76] третий)? Существует как минимум три основных варианта:

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

2. Не показывать входы/выходы на тех уровнях процессов, где нужно делать агрегирование (то есть там, где невозможно или слишком сложно показывать потоки реальных документов/материалов).

3. Дублировать описание входов/выходов в виде списка, повторяя все входы/выходы, определенные для процессов нижних уровней.

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

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

Пример. Справочник процессов в среде бизнес-моделирования

При выполнении проекта была разработана система процессов в файле MS Excel. Для последующего моделирования процессов использовалась среда Business Studio. При помощи разработки и использования так называемого пакета импорта процессное дерево было импортировано в базу Business Studio, что исключило необходимость повторного ручного ввода информации о структуре процессов.

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

3.2. Цели разработки системы процессов организации

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

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

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

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

• создать уникальную процессную модель «ХХХ», которая бы за счет наличия четких связей с моделями APQC, CBM (Component Business Model), SAP, DocsVision, СМК (система менеджмента качества) и реестром нормативных документов компании обеспечивала возможность:

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

– системно осуществлять описание и регламентацию бизнес-процессов компании с использованием системы Business Studio 3.6;

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

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

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

Пример. Небольшая компания, но при этом лидер рынка в своем сегменте. Построение архитектуры процессов дало в руки ее руководителей и специалистов инструмент, который позволил системно выполнять описание и анализ бизнес-процессов для создания модели «как должно быть» и определения требований к автоматизации процессов при переходе на 1С-8.

Построение системы процессов организации означает упорядочение ее деятельности в виде процессов. Древовидная структура процессов и согласованные границы позволяют четко определить зоны ответственности руководителей на всех уровнях управления, исключить зоны безответственности и зоны размытой ответственности (пересечения ответственности). Четкое определение зон ответственности руководителей позволяет организовать оперативное управление процессами, не дожидаясь их подробного описания и регламентации. Сказанное иллюстрирует рис. 3.2.1. В ситуации 1 процессы не выделены и не управляются. В ситуации 2 процессы выделены, границы процессов четко определены, руководители приступили к организации управления процессами на основе системы показателей. В ситуации 3 процессы регламентированы, оперативно управляются и совершенствуются на основе цикла PDCA.

_{Рис. 3.2.1. Упорядочение деятельности организации в виде процессов}

Управление процессами означает, что для каждого из них разработаны и используются показатели. Если не создать систему процессов, то не к чему будет привязывать эти показатели (не будет идентифицированных объектов управления)^[77]. Если система процессов будет построена некорректно (например, состав и границы выделенных процессов окажутся неадекватны реальной деятельности^[78]), то организация управления такими «процессами» – бессмысленное занятие. Поэтому корректно построенная система процессов – это основа для успешного внедрения процессного подхода.

В целом система процессов организации обеспечивает достижение следующих целей:

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

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

• четкое определение зон ответственности руководителей, исключение зон безответственности, зон дублирования ответственности;

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

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

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

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

• прочее.

3.3. Различные подходы к построению системы процессов организации

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

• структурный подход;

• продуктовый подход;

• подход «блюдо спагетти»;

• CBM IBM (Component Business Model компании IBM);

• методика построения системы процессов на основе анализа модели цепочек создания ценности (ЦСЦ);

• смешанные подходы.

Рассмотрим каждый из указанных подходов подробнее.

3.3.1. Структурный подход к построению системы процессов компании

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

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

Отмечу, что 40–80 % операционных процессов (в зависимости от специфики конкретного подразделения и степени проектной ориентированности организации в целом) не являются сквозными. Иными словами, их нецелесообразно определять как сквозные, так как они полностью выполняются внутри соответствующих подразделений. Вышеизложенное иллюстрирует рис. 3.3.1.

_{Рис. 3.3.1. Процессы структурного подразделения}

На рис. 3.3.1 процессы 1–4 условно можно назвать структурными или сегментированными. Они выполняются целиком в одном подразделении. Это видно по составу участников. Только процесс 5 – сквозной, поскольку в нем участвуют сотрудники нескольких структурных подразделений. Такие сквозные (кросс-функциональные) процессы интегрируют деятельность подразделения в деятельность организации в целом. Если разделить процесс 5 на несколько частей, каждая из которых выполняется в отдельном подразделении, и показать на схеме процессов этого подразделения только ту часть, которую выполняют его сотрудники, то это и будет сегментированный подход. При структурном (сегментированном) подходе сквозные процессы не выделяются, то есть информация о них теряется. В этом состоит главный минус сегментированного подхода.

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

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

Приведем пример фрагмента системы процессов для иллюстрации структурного подхода (табл. 3.3.1).

_{Таблица 3.3.1. Фрагмент системы процессов из категории «Управление технологией и качеством продукции»}

В таблице приведен пример структуры процессов из группы «Контроль соблюдения технологии производства». Стоит обратить внимание на процессы «Участие в обработке претензий по готовой продукции» и «Участие в обработке претензий по сырью». Что это за объекты? Насколько они ценны для компании? Увы, они не имеют самостоятельной ценности. Это всего лишь части сквозных процессов «Обработка претензий потребителей по готовой продукции» и «Претензионная работа по сырью и материалам» соответственно.

Может возникнуть вопрос: по каким принципам выделяются процессы внутри структурного подразделения? Как правило, принимают во внимание следующие моменты:

• количество процессов составляет не более 10–12;

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

• процессы должны быть сопоставимы по масштабу;

• технология создания продуктов/услуг.

3.3.2. Продуктовый подход к построению системы процессов

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

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

1. Основные процессы.

1.1. Обслуживание физических лиц.

1.1.1. Расчетно-кассовое обслуживание физических лиц.

1.1.1.1. Текущие счета физических лиц.

1.1.1.1.1. Открытие текущего счета для физического лица.

1.1.1.1.2. Прием взносов на счет.

1.1.1.1.3. Проведение выплат со счета.

1.1.1.1.4. Взимание комиссии со счета.

1.1.1.1.5. Оформление доверенности на распоряжение счетом.

1.1.1.1.6. Оформление доверенности на распоряжение счетом.

1.1.1.2. Расчетное обслуживание.

1.1.1.3. Кассовое обслуживание.

1.1.1.4. Валютный контроль и валютные операции.

1.1.1.5. Денежные переводы по системам.

1.1.2. Вклады.

1.1.3. Кредитование физических лиц.

1.1.4. Банковские карты для физических лиц.

1.1.5. Индивидуальные банковские ячейки (сейфы) для физических лиц.

1.1.6. …

1.2. Обслуживание юридических лиц.

1.3. Работа на финансовых и межбанковских рынках.

2. Вспомогательные процессы…

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

• большое количество уровней иерархии справочника процессов (реальные операции процессов появляются только на шестом уровне иерархии!);

• не выделяются сквозные процессы;

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

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

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

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

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

Приведу еще один фрагмент из рассматриваемой модели банка:

1. Управленческие процессы

1.1. Управление финансами.

1.2. Управление персоналом.

1.3. Управление маркетингом

1.3.1. …

1.3.2. …

1.3.3. …

1.3.4. Управление продуктами.

1.3.4.1. Разработка и внедрение продуктов и услуг.

1.3.4.1.1. …

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

Пример. Процессы создания новых продуктов торгово-производственной компании

В крупной торгово-производственной компании в рамках категории «Развитие продукции и услуг» выделена процессная группа «Разработка новых и изменение текущих продуктов»:

3. Разработка новых и изменение текущих продуктов.

3.1. Управление разработкой новых и изменением текущих продуктов.

3.2. Поиск и отбор идей по новым продуктам.

3.3. Управление портфелем проектов по новым продуктам/изменениям текущих продуктов.

3.4. Управление проектом по разработке нового продукта/изменению текущего продукта.

3.5. Выполнение исследований по новому продукту/изменениям текущего продукта.

3.6. Проработка идеи нового продукта/изменения текущего продукта.

3.7. Разработка нового продукта/измененного текущего продукта.

3.8. Подготовка производства продукта.

3.9. Запуск производства продукта.

3.10. Вывод продукта на рынок.

3.11. Управление нормативно-технологической документацией.

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

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

3.3.3. Система процессов компании как «блюдо спагетти»

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

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

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

• наличие нескольких файлов с фрагментарным описанием сквозных процессов разного масштаба и важности;

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

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

• графические схемы процессов чрезмерно сложные (количество операций превышает двадцать – тридцать);

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

• операции разных процессов частично дублируют друг друга.

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

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

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

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

3.3.4. Система процессов компании по методу CBM IBM

Подход CBM (Component Business Model) компании IBM довольно интересен (табл. 3.3.2). Этот метод пока мало распространен в России, но некоторые крупные компании уже используют его для построения процессной модели бизнеса.

_{Таблица 3.3.2. Построение системы процессов компании на основе метода CBM}

Для построения системы процессов компании в рамках модели CBM нужно:

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

• для каждой компетенции и для каждого уровня управления определить так называемые компоненты;

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

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

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

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

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

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

3.3.5. Построение системы процессов на основе анализа цепочек создания ценности

Наша команда консультантов^[79] в настоящее время использует метод анализа бизнеса компаний на основе цепочек создания ценности (ЦСЦ).

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

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

При построении системы процессов с использованием схем ЦСЦ в рамках нашего подхода:

• определяются и группируются основные продукты/услуги компании;

• для каждой группы продуктов/услуг разрабатывается схема ЦСЦ (обычно один-два листа формата А4);

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

• выполняется анализ всех разработанных эскизных схем ЦСЦ; определяются процессные категории и группы для системы процессов компании;

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

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

• выполняется анализ полученного иерархического справочника процессов;

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

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

• выполняется согласование системы процессов компании.

На рис. 3.3.2 показаны примеры схемы ЦСЦ для части бизнеса торговой компании – «Реализация товара в розницу». Схема выполнена в MS Visio с применением специальной нотации, разработанной и используемой нашей группой консультантов. Фактически на схеме представлены группы процессов и основные связи между ними.

_{Рис. 3.3.2. Пример схемы ЦСЦ}

_{Схема цепочки ценности «Реализация в розницу»}

_{От отгрузки со склада производителей до клиента}

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

• является полной (то есть охватывает весь бизнес компании);

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

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

• на операционном уровне модель содержит информацию о сквозных (кросс-функциональных) процессах.

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

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

3.3.6. Выбор методики построения системы процессов

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

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

• оптимизация модели бизнеса;

• совершенствование организационной структуры;

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

• управление бизнес-процессами;

• автоматизация бизнес-процессов.

3.4. Методика построения системы процессов организации на основе анализа цепочек создания ценности

3.4.1. Методика построения

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

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

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

• терпеливо отбирать и складывать нужные элементы между собой.

В случае потери общей картинки задача по собиранию пазла существенно усложняется.

Переводя эту аналогию на язык бизнес-моделирования, можно сказать, что:

• общая картинка – это системное понимание процессов бизнеса на верхнем уровне (например, при помощи схем ЦСЦ), и

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

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

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

Рекомендую создавать эту модель, используя принципы определения и построения схем ЦСЦ. Формируемая модель является структурной. Ее назначение – системно показать процессы компании на верхнем уровне и основные, наиболее важные связи между ними.

Рис. 3.4.1. Алгоритм построения системы процессов организации

Для создания структурной модели можно использовать любую понятную и удобную бизнес-аналитикам нотацию (в том числе IDEF0). Главное, чтобы методика применения нотации соответствовала поставленной задаче. Для создания структурной модели можно использовать MS Visio как наиболее доступный инструмент. В крайнем случае модель рисуют на бумаге.

Шаг 2 – это анализ деятельности структурных подразделений, выявление и структурирование процессов, которые в них выполняются. Информация о процессах подразделений представляется в табличной форме (в MS Excel).

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

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

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

• ответственный за выполнение процесса руководитель;

• участники;

• входы (не заполнены);

• выходы (не заполнены).

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

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

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

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

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

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

Обычно для разработки адекватной бизнесу системы процессов нужно не менее трех-четырех итераций. Для компании среднего размера (численностью 1000–1500 человек, 100–150 лиц руководящего состава) такая работа занимает около 1,5–2 месяцев.

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

3.4.2. Использование отраслевых решений и материалов других компаний

На практике при построении системы процессов используются:

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

• опыт экспертов по выделению и описанию процессов в аналогичных компаниях;

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

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

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

3.4.3. «Процессы» или «процессные группы»?

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

Пример. Регламентация процессов верхнего уровня

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

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

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

• непосредственно в системе процессов;

• в должностных инструкциях руководителей.

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

3.4.4. Выявление сквозных процессов на основе анализа схем ЦСЦ

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

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

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

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

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

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

3.5. Разработка модели процессов на верхнем уровне

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

Используя полученную информацию, бизнес-аналитики формируют процессную модель деятельности организации на верхнем уровне (модель процессов на верхнем уровне). Для этого можно использовать любую подходящую методику построения структурных моделей верхнего уровня (ЦСЦ, IDEF0, ARIS VAD и т. д.). Важны не применяемые условные обозначения, а принципы, используемые при построении модели. Кроме того, при построении модели ЦСЦ полезно описывать не только основные, создающие ценность процессы (группы процессов, деятельность), но и управляющие, обеспечивающие.

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

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

Пример. Рассмотрим схему процессов верхнего уровня телекоммуникационной компании, представленную на рис. 3.5.1. На рисунке показана схема цепочки создания ценности^[80] по одной из основных ее услуг.

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

1. «Продавать услуги».

2. «Настраивать сервисы для клиента».

3. «Осуществлять текущее обслуживание клиентов».

4. «Управлять трафиком».

5. «Обеспечивать каналами связи».

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

_{Рис. 3.5.1. Пример схемы процессов верхнего уровня (схема цепочки создания ценности)}

^{* Серой заливкой показаны процессы, выполняемые внешними контрагентами данной организации.}

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

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

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

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

_{Рис. 3.5.2. Использование модели процессов верхнего уровня для построения системы процессов}

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

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

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

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

• процессы могут быть перегруппированы (для получения более адекватного решения);

• некоторые процессы могут быть сгруппированы (то есть изменен уровень);

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

• прочее.

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

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

3.6. Определение процессов подразделений

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

_{Рис. 3.6.1. Алгоритм определения процессов структурного подразделения}

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

На шаге 2 все выявленные входы/выходы нужно сгруппировать так, чтобы получилось не более шести – восьми (максимум десять – двенадцать) групп. Основной критерий для группировки – принадлежность документов (и других ресурсов) к конкретному продукту/услуге, в создании которого участвует подразделение. Адекватная группировка входов/выходов позволяет предположить состав его процессов.

На шаге 3, используя информацию о группах входов/выходов и предположения о структуре процессов, формируем структурную схему процессов. Пример такой схемы представлен на рис. 3.6.2. Цель формирования схемы – выявить возможные процессы подразделения, определить связи между ними, согласовать полученную структуру.

_{Рис. 3.6.2. Структурная схема процессов подразделения}

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

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

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

На шаге 4 для каждого выделенного процесса подразделения определяются входящие в него операции (подпроцессы^[81]). Общее количество операций для каждого процесса не должно превышать 8–12.

На шаге 5 заполняется матрица процессов подразделения, которая включает:

• перечень процессов и операций (то есть два уровня процессного представления);

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

• информацию об ответственности за выполнение процессов и операций (в форме матрицы ответственности).

Возможная форма матрицы процессов подразделения показана в табл. 3.6.1.

На шаге 5 осуществляют анализ, уточнение (по входам/выходам) и согласование матрицы процессов подразделения. Акцент здесь делается на согласовании ви?дения процессов подразделения его руководителем и специалистами. Согласование входов/выходов процессов на межфункциональном уровне может производиться позже, на стадии формирования, анализа и согласования системы процессов организации в целом.

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

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

_{Таблица 3.6.1. Процессы отдела по работе с клиентами (фрагмент)}

3.7. Согласование границ процессов

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

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

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

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

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

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

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

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

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

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

• при необходимости корректируют формы документов (разрабатывают новые формы);

• проводят совещания с поставщиками/потребителями (внутренними и внешними) и согласуют соответствующие формы;

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

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

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

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

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

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

3.8. Список литературы

1. Хаммер М., Хершман Л. Быстрее, лучше, дешевле. Девять методов реинжиниринга бизнес-процессов. – М.: Альпина Паблишер, 2012.

2. Репин В. В. Бизнес-процессы компании: построение, анализ, регламентация. М.: Стандарты и качество, 2007.

3. Харрингтон Дж. Совершенство управления процессами. – М.: Стандарты и качество, 2007.

4. Бьёрн А. Бизнес-процессы. Инструменты совершенствования. – М.: Стандарты и качество, 2003.

5. Де Гиус А. Живая компания. Рост, научение и долгожительство в деловой среде. – СПб.: Стокгольмская школа экономики в Санкт-Петербурге, 2004.

Глава 4
Описание бизнес-процессов организации

4.1. Цели описания бизнес-процессов организации

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

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

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

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

_{Таблица 4.1.1. Возможные ситуации с описанием процессов}

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

Сформулируем цели описания процессов для организаций разного размера.

Небольшая организация (10–100 человек)

Возможные цели описания процессов (моделирования) в небольшой организации:

1. Четкое определение зон ответственности руководителей по ключевым направлениям деятельности.

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

3. Анализ и улучшение деятельности.

4. Подготовка к автоматизации деятельности, в том числе процессов.

5. Первые шаги по созданию культуры процессного управления у сотрудников (обучение процессному ви?дению).

Средняя организация (100–1000 человек)

Возможные цели описания процессов (моделирования) в организации среднего размера:

1. Четкое определение зон ответственности руководителей на всех уровнях управления.

2. Оптимизация взаимодействия структурных подразделений за счет стыковки процессов по входам/выходам.

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

4. Тиражирование стандартов деятельности (например, в филиалы).

5. Обучение сотрудников.

6. Автоматизация процессов.

7. Анализ и улучшение деятельности.

8. Развитие культуры процессного управления у сотрудников.

Крупная организация (> 1000 человек)

Возможные цели описания процессов (моделирования) в крупной организации:

1. Четкое определение зон ответственности руководителей на всех уровнях.

2. Оптимизация взаимодействия структурных подразделений за счет стыковки процессов по входам/выходам.

3. Создание системы процессов организации. Системное описание процессов в формализованном виде на нескольких уровнях (создание так называемой объектной модели организации). Централизованное хранение (в промышленной базе данных) и актуализация моделей процессов.

4. Автоматизация создания регламентирующих документов (при помощи выгрузки из среды моделирования на основе стандартных шаблонов). Формирование нормативно-методических документов: регламенты выполнения процессов, инструкции по выполнению процессов, положения о подразделениях, должностные инструкции. Формирование других отчетов: штатное расписание, карточки должности, карта грейдов^[82], цели и показатели для управления процессами и т. д.

5. Описание и регламентация процессов управления на всех уровнях.

6. Анализ возможных изменений (реализация сценариев «что если?») в модели организации: 1) создание нового подразделения с передачей ему операций процессов других подразделений; 2) ликвидация подразделения с передачей его процессов другим подразделениям.

7. Тиражирование стандартов деятельности (например, в филиалы).

8. Выполнение внутреннего аудита.

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

10. Обучение сотрудников.

11. Автоматизация процессов.

12. Анализ и улучшение деятельности.

13. Управление знаниями о деятельности организации.

14. Вовлечение руководителей и сотрудников подразделений в работу по описанию и стандартизации деятельности организации.

15. Развитие культуры процессного управления у сотрудников.

4.2. Что нужно для успешного описания процессов в масштабах организации?

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

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

4.2.1. Формулировка целей описания процессов

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

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

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

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

• разработка регламентирующих документов;

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

• прочее.

В 2011 году компания BPTrends провела исследования в области моделирования бизнес-процессов. Респондентами стали представители почти 16 000 зарегистрированных участников сообщества BPTrends и посетители соответствующего сайта (Северная Америка – 36 %, Европа – 32 % и т. д.). Поскольку деятельность BPTrends охватывает весь диапазон вопросов, составляющих часть понятия «бизнес-процесс», к исследованию были привлечены управленцы и практики, заинтересованные в комплексном подходе к процессному управлению.

BPTrends: «Моделирование процессов – актуальный метод, используемый практиками в сфере процессного управления, чтобы получать, систематизировать и передавать информацию о бизнес-процессах. Модели процессов могут быть изображены на рабочей доске, бумаге или представлены в цифровой форме в различных видах программного обеспечения для их моделирования. Они могут быть как абстракциями, определяющими фазы деятельности, так и детализированными изображениями осуществленных шагов и принятых решений в ходе конкретной операции. Например, менеджер может нарисовать на листе бумаги три прямоугольника для представления трех фаз, через которые обычно проходит его организация в ходе аудита. Специалист по программному обеспечению может изобразить множество прямоугольников со стрелками и ромбами для точного отражения решений, которые требовались для одобрения нового кредитного счета. И то и другое можно назвать моделями процесса, поэтому в рамках этого исследования термин “моделирование процесса” использовался очень широко для возможности рассмотрения всех видов моделирования…»

В исследовании BPTrends приводится интересная диаграмма, представленная на рис. 4.2.1. По сути, на ней показаны цели моделирования (описания) бизнес-процессов.

_{Рис. 4.2.1. Как вы используете моделирование бизнес-процессов?}

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

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

4.2.2. Нотация моделирования процессов

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

При выборе нотации полезно обратить внимание на следующее. Если описание процессов делается для создания регламентирующих документов, то схемы процессов должны быть просты и интуитивно понятны сотрудникам организации, информативны при минимальном наборе используемых графических символов. Нет смысла усложнять графическое представление – полезную информацию вполне можно вывести в нормативно-методические документы в виде таблиц и текста. Выбранная нотация должна быть понятна большинству сотрудников без специального обучения и длительного освоения. Конечно, можно заставить людей описывать процессы в любых нотациях (например, в UML^[83]) при помощи совершенно разных средств моделирования, но затраты на внедрение таких нотаций/систем обычно значительны. Чрезмерно сложная нотация и средство моделирования сделают методы процессного управления доступными для узкого круга профессионалов из отдела организационного развития или IT-отдела, а преимущества процессного подхода не будут реализованы в полной мере.

Замечу, что если предполагается описывать процессы исключительно в целях последующей автоматизации, то лучше всего использовать нотацию BPMN^[84] 2.0.

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

• в нотации представлен минимально необходимый набор графических элементов для описания процессов типа Work Flow (поток работ);

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

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

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

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

4.2.3. Репозиторий и среда моделирования процессов

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

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

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

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

• внесение изменений в регламентирующие документы требует ручной работы;

• доступ сотрудников к информации по процессам затруднен;

• информация, формализованная в схемах и описаниях процессов, быстро устаревает.

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

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

А если в вашей компании полный порядок, означает ли это, что:

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

• все схемы процессов хранятся в специализированной базе данных;

• выполняется описание процессов в специализированной системе с последующей автоматической генерацией (выгрузкой) регламентирующих документов в MS Word или MS Excel;

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

• обеспечен легкий и быстрый доступ сотрудников к информации по процессам (например, через внутренний портал)?

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

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

Безусловно, репозиторий бизнес-процессов полезен – это база знаний о деятельности компании. Если она будет полной и актуальной, то обеспечит возможность:

• быстро актуализировать модели бизнес-процессов;

• с минимальными трудозатратами формировать регламентирующие документы:

– регламенты выполнения бизнес-процессов;

– регламенты управления бизнес-процессами;

– технологические инструкции;

– положения о подразделениях;

– должностные инструкции сотрудников;

– прочее;

• быстрый и легкий доступ к информации по процессам через интерфейс;

• возможность использовать накопленные знания для автоматизации;

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

• прочее.

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

Создание электронного репозитория бизнес-процессов – это инвестиция в будущее компании. Почему? Судите сами: внедряя репозиторий, вы:

• выполняете описание, анализ и улучшаете бизнес-процессы организации;

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

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

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

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

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

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

• простота и интуитивная понятность интерфейса;

• легкость моделирования бизнес-процессов;

• хранение информации о деятельности компании в базе данных (например, в СУБД MS SQL Server);

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

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

• работа в многопользовательском режиме.

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

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

Описанная ситуация годится для любого бизнес-процесса независимо от объекта деятельности.

Говоря о практическом использовании репозитория, следует отметить, что:

• для поддержания репозитория требуются квалифицированные специалисты;

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

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

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

Важно знать основные возможности среды моделирования процессов, которую предполагается использовать для создания репозитория. Современные программные продукты, предназначенные для описания процессов, как правило, хранят информацию в промышленной базе данных (например, в СУБД MS SQL-Server). Эти системы позволяют создавать сложные, иерархические справочники процессов, подразделений и должностей, документов. С системой могут одновременно работать несколько пользователей. Информация о внесенных изменениях сохраняется.

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

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

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

В исследовании BPTrends приводится любопытная диаграмма (см. рис. 4.2.2) по свойствам среды моделирования процессов, наиболее важных для пользователей.

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

_{Рис. 4.2.2. Какие три свойства средств моделирования процессов вы считаете самыми важными?}

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

Обратите внимание, что только 10 % опрошенных считают важной способность легко переходить от модели к коду программного обеспечения. Для остальных важнее оказались другие требования. Например, 36 % указали на «Способность создавать простые модели процессов», а 56 % – на «Способность сохранять модели и данные о процессах в репозитории». Эти факты говорят о том, что компаниям, которые используют моделирование процессов для анализа, оптимизации и документирования (регламентации), нужны:

• простая, но стандартная нотация моделирования;

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

4.2.4. Методики описания процессов

Чтобы успешно выполнить проект по созданию системы работы по описанию процессов, нужны нормативно-методические документы (методики, стандарты), среди которых:

• стандарт описания бизнес-процессов («Соглашение о моделировании бизнес-процессов»);

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

• инструкция по администрированию среды моделирования;

• прочее.

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

4.2.5. Наличие необходимых специалистов

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

• разрабатывать и изменять систему процессов организации;

• согласовывать процессы по входам/выходам;

• проводить интервью, получать и структурировать информацию по процессам;

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

• настраивать среду моделирования, в том числе формировать шаблоны отчетов для выгрузки регламентирующих документов;

• управлять изменениями объектной модели организации;

• обучать сотрудников организации принципам и методам описания процессов;

• прочее.

Разработка и внедрение в организации системы описания процессов – довольно сложный и длительный (3–6 месяцев) проект, для успешного выполнения которого руководители организации должны выделить адекватные человеческие и финансовые ресурсы.

Пример. В торгово-производственной компании среднего размера приняли решение описывать бизнес-процессы. После проведения формального тендера приобрели среду моделирования процессов. Одному из сотрудников организации было поручено ее использовать. На методическое обеспечение, обучение персонала, настройку системы (справочники, отчеты) денег не выделили. В результате уполномоченный сотрудник в течение нескольких месяцев пытался описывать процессы на свой страх и риск. Полученные модели оказались весьма сомнительного качества. Кроме того, попытка документировать процессы окончилась неудачей, поскольку: а) заранее не были продуманы требования к информации, которую следовало использовать в описаниях процессов; б) у сотрудника, работающего со средой моделирования, не хватило квалификации для настройки необходимых шаблонов отчетов.

4.3. Объектная модель организации

В этом параграфе мы обсудим вопрос создания так называемой объектной модели организации.

Моделирование организации предполагает определение и подробное описание таких объектов, как:

• процессы;

• владельцы/исполнители процессов (подразделения, должности, бизнес-роли);

• ресурсы: документы, файлы, ТМЦ65;

• инициирующие и завершающие события;

• термины;

• цели и показатели деятельности;

• физические лица, занимающие соответствующие должности;

• прочее.

Каждый из этих объектов обладает рядом атрибутов. Например, для него могут быть определены название, тип, текстовое описание, требования к срокам.

По ходу моделирования объекты контактируют между собой, и эти связи также могут иметь определенный тип и соответствующие атрибуты.

В результате моделирования появляется объектная модель организации^[85] – упорядоченная совокупность объектов, связанных между собой определенными способами.

Четкая структура этой модели и наличие связей позволяют в дальнейшем получать любые регламентирующие документы (регламенты, инструкции, положения) и необходимые отчеты.

Объектная модель реализуется только в виде соответствующей базы данных. Ее структуру, разработанную для решения задач бизнес-моделирования, можно называть метамоделью^[86] организации.

На рис. 4.3.1 показано, как в результате деятельности по моделированию с использованием метамодели получается комплексная объектная модель организации.

_{Рис. 4.3.1. Связь объектной модели и метамодели организации}

Метамодель организации, по сути, – это совокупность связанных таблиц СУБД (системы управления базы данных), и она может расширяться по мере необходимости. Например, для такого класса объектов, как должность, можно дополнительно определить следующие атрибуты:

• наименование должности;

• номер грейда;

• лицо, назначающее сотрудника на данную должность;

• лицо, осуществляющее представление на данную должность;

• показатели оценки эффективности;

• прочее.

Для успешного внедрения системы описания процессов нужны квалифицированные специалисты, способные грамотного осуществлять изменения (доработки) в метамодели организации.

Замечу, что далеко не в каждой среде моделирования есть средства управления метамоделью. Но, как показывает практика, эта возможность очень ценна и востребована при практическом описании процессов организации.

4.4. Архитектура типовой среды моделирования процессов

Сейчас на рынке представлено множество программных продуктов для моделирования деятельности организации. Эти продукты относятся к так называемым средствам Business Process Architecture или Enterprise Architecture, то есть программным инструментам, предназначенным для проектирования бизнес-процессов и бизнес-архитектуры компании. Руководителям и специалистам, внедряющим процессный подход, важно понимать общую архитектуру систем такого класса.

Рассмотрим архитектуру типовой среды моделирования процессов, представленную на рис. 4.4.1. Такая среда, как правило, имеет модульную структуру, которая определяется соответствующими сервисами. В конкретных системах сервисы могут объединяться в рамках единых программных решений, а также существовать и использоваться по отдельности в виде модулей.

_{Рис. 4.4.1. Архитектура типовой среды моделирования процессов}

Информация о деятельности организации (справочники процессов, подразделений, документов, схемы процессов) хранится в промышленной базе данных, например MS SQL Server. Есть отдельный сервис, который используется для администрирования: создания/изменения/архивирования баз данных, создания новых пользователей, назначения прав доступа и т. д.

Сервис управления метамоделью – важнейший инструмент бизнес-моделирования. Он позволяет расширять метамодель, предлагаемую поставщиком системы, и создавать новые списки, перечисления, атрибуты для существующих классов объектов. В некоторых системах предусмотрена возможность определять новые классы объектов и связей между ними. Фактически в такой системе доступно спроектировать любую нотацию, которая может потребоваться в организации.

Возможность расширения метамодели важна для полного и адекватного моделирования, решения практических задач, возникающих у разных групп пользователей внутри организации.

Основной сервис среды моделирования – сервис описания^[87], где можно:

• создавать различные справочники:

– процессов;

– подразделений;

– должностей;

– документов;

– терминов;

– прочее;

• формировать схемы:

– процессов;

– организационных структур;

– прочее^[88];

• описывать объекты модели:

– заполнять текстовые поля (например, указывать название процесса, его начало, завершение, требования к срокам);

– формировать списки (например, указывать должностных лиц, которые согласуют требования к выполнению процесса);

– выбирать нужные типы (например, указывать тип подразделения: «департамент» или «отдел»);

– задавать количественные параметры (например, номер грейда, количество ставок на должности или среднее время выполнения процесса);

– прочее;

• формировать отчеты:

– выгружать регламентирующие документы (регламенты процессов, инструкции по выполнению процессов, положения о подразделениях, должностные инструкции);

– выгружать другие специализированные отчеты (например, отчет по движению документов – где создается, кем согласуется, кем утверждается и т. п.);

• осуществлять анализ и изменение объектной модели:

– создавать/корректировать/удалять процессы, подразделения, документы;

– переназначать исполнителей процессов;

– выявлять процессы без назначенных исполнителей;

– выявлять документы, которые никто не использует;

– прочее.

Как правило, основные пользователи сервиса описания процессов – квалифицированные бизнес-аналитики, которые проводят интервью, структурируют информацию и заносят ее в систему в виде различных моделей. В некоторых случаях руководство организации принимает решение вовлекать в работу сотрудников подразделений, которые также используют часть функциональных возможностей в рамках своих полномочий.

При выборе системы руководителям компаний стоит уделить серьезное внимание анализу функциональных возможностей и удобства использования модуля описания процессов. Этот аспект важнее, чем выбор той или иной нотации моделирования. Рекомендуется попробовать все интересующие системы, описав в них один-два пилотных процесса.

Для управления командной работой служит сервис администрирования, в рамках которого:

• выполняются настройки интерфейса системы;

• выполняются настройки ряда справочников;

• создаются/редактируются группы пользователей системы;

• определяются права для групп пользователей и отдельных пользователей;

• выполняются настройки, необходимые для отслеживания изменений в системе;

• прочее.

Сервис формирования отчетов служит для разработки шаблонов различных отчетов (генератор отчетов). При помощи определенного функционала (в системах это может быть реализовано по-разному) квалифицированный пользователь проектирует запрос к базе данных и определяет формат вывода информации в документ MS Word или MS Excel. При построении отчета его тестируют на реальной или специально подготовленной для этого объектной модели. Готовые отчеты доступны конечным пользователям системы. Из системы можно выгружать готовые к согласованию и утверждению нормативно-методические документы (регламенты, положения, инструкции) и другие нужные в практической работе документы.

При выборе системы руководитель должен выполнить анализ сервиса формирования отчетов. Лучше выбирать такую систему, генератор отчетов которой легко освоит не только программист (специалист по запросам к СУБД и написанию кода), но и обычный бизнес-аналитик.

Очень полезен сервис выгрузки моделей в HTML-формат. Он используется для размещения моделей процессов на интранет– или интернет-сервере организации. Все сотрудники (имеющие соответствующие права) могут оперативно просматривать данные на этом сервере, то есть вся регламентирующая информация по процессам становится доступной рядовому персоналу.

Анализ процессов выполняется на сервисе анализа. Как правило, он дает возможность проводить имитационное моделирование процессов, анализировать затраты и т. д.

Современная среда моделирования бизнес-процессов – это сложный пакет программных продуктов, для успешного внедрения которого организации нужны сотрудники с нужной компетенцией и опытом.

4.5. Структурные модели процессов организации

В этом параграфе мы рассмотрим особенности использования структурных моделей при описании процессов организации.

Под структурной будем понимать модель, включающую в себя упорядоченный по определенному принципу набор процессов (групп процессов) с указанием основных связей между ними.

Основное назначение структурной модели – показать, как устроен бизнес организации, раскрыть информацию об основных группах процессов и их взаимосвязях. Структурная модель не показывает последовательность выполнения процессов во времени.

Структурные модели можно использовать локально (не в системе процессов организации) для схематичного описания состава процессов, декомпозированных на следующий уровень. Например, такая структурная схема может быть представлена в регламенте двухуровневого процесса.

Для формирования структурных моделей используются соответствующие нотации: IDEF0, ARIS Value Added Chain, Value Stream Map (информационные потоки) компании Toyota, модель цепочек создания ценности и др. Информация о них содержится во многих публикациях, поэтому в своей книге я не стану касаться этого вопроса.

Структурные модели процессов, как правило, применяются для:

• описания, анализа бизнес-модели организации и определения возможных направлений ее реорганизации;

• разработки системы бизнес-процессов организации по принципу «сверху вниз»;

• системного описания процессов, которые необходимо автоматизировать (например, в ERP-системе);

• описания состава процессов, декомпозированных на следующий уровень (несистемное, фрагментарное использование).

Рассмотрим деятельность торговой компании (розничная торговля продуктами питания). На рис. 4.5.1 показан пример структурной модели процессов, выполненной без использования специализированной нотации на основе анализа цепочек создания ценности, осуществляемых компанией.

_{Рис. 4.5.1. Пример структурной модели торговой компании}^[89]

На рис. 4.5.1 видно, что в модели выделено семь групп процессов. Цель ее построения – демонстрация возможного варианта определения и группировки процессов торговой компании. Такая модель может быть представлена руководителям верхнего уровня для согласования. В дальнейшем модель используется при построении системы процессов организации.

На рис. 4.5.2 та же модель, что и на рис. 4.5.1, только выполненная в стандарте IDEF0.

Анализируя рис. 4.5.2, отмечу, что многочисленные стрелки, которые обычно представлены на схемах IDEF0, не так уж важны руководителям бизнеса для понимания и использования модели. Менеджеры крупной торговой компании, проработавшие в бизнесе много лет, хорошо представляют себе основные результаты работы каждого структурного подразделения (ассортиментная матрица, план продаж и закупок и т. п.). Поэтому загромождение структурной схемы стрелками скорее развлечение, а не деятельность бизнес-аналитика, полезная для управления. Нужно стремиться минимизировать количество стрелок, сохраняя при этом информативность схемы.

_{Рис. 4.5.2. Пример структурной модели процессов торговой компании^[90]. Стандарт IDEF0}

Однако в случае проектирования компании с нуля проработка основных связей на структурной схеме очень полезна. Но такие случаи на практике встречаются редко.

Вопрос пользы структурных моделей для решения задач бизнес-моделирования спорный. С моей точки зрения, построение сложной, многоуровневой системы процессов организации в одной модели IDEF0 (или в другой нотации) излишне. Если соблюдать все формальные правила, то в такой модели может получиться семь-восемь уровней декомпозиции. Реальную же ценность для последующего описания и регламентации имеют один-два нижних уровня, где выполняются конкретные операции и осуществляется реальный документооборот. Именно на этих уровнях процессы можно описать в формате Work Flow и при помощи этих описаний сформировать регламенты работы сотрудников («регламент процесса», «инструкция по выполнению процесса» и т. п.). Вопрос в том, как разработать адекватный реальному бизнесу иерархический справочник процессов^[91]. Если можно обойтись без сложной (понятной только бизнес-аналитику) структурной модели процессов, то и не нужно ее создавать.

Примечание. В крупной, давно работающей компании построение сложной структурной модели может не принести ожидаемого результата. Дело в том, что топ-менеджмент вряд ли решится перекраивать весь бизнес по модели в IDEF0. А с точки зрения регламентации на операционном уровне все верхние уровни (3–5-й) в модели IDEF0 бесполезны.

Другое дело, если нужно спроектировать новый бизнес. Эта работа выполняется по принципу «сверху вниз», так как действующих процессов и самой компании пока нет. Анализ структуры и связей процессов на верхнем и среднем уровнях полезен для принятия решений о структуре будущей организации и закреплении групп процессов за подразделениями.

Итак, структурная модель процессов нужна:

• бизнес-аналитикам для понимания деятельности организации и создания адекватной системы процессов (в первую очередь для корректного перехода к процессам уровня Work Flow – регламентируемым или автоматически исполняемым в BPMS процессам);

• руководителям организации для:

– уточнения зон ответственности, целей и задач их деятельности;

– анализа и совершенствования архитектуры бизнеса;

• руководителям и бизнес-аналитикам при проектировании нового бизнеса.

Замечу, что среди руководителей компаний желающие работать со структурной графической моделью процессов верхнего уровня встречаются редко. Поэтому многоуровневая структурная модель (например, в IDEF0) – удел узкого круга бизнес-аналитиков. В лучшем случае руководители используют диаграмму первого уровня, которую размещают на стенде с нормативно-методической документацией.

4.6. Модели процессов на операционном уровне

В этом параграфе мы рассмотрим модели процессов на операционном уровне. Они отображают последовательность выполнения операций процесса (подпроцессов) во времени. Их обычно называют «модели Work Flow»^[92].

Сейчас существует множество нотаций типа Work Flow, при помощи которых можно описывать процессы операционного уровня. Рассмотрим основу формирования моделей и некоторые важные аспекты их применения.

4.6.1. Нотации типа Work Flow

На рис. 4.6.1 показаны основные элементы, которые используются практически во всех современных нотациях Work Flow. Можно выделить пять основных:

1. События.

2. Операторы логики (по-другому их называют: блоки решения, ветвления/развилки, шлюзы/гейтвеи^[93]).

3. Операции процесса.

4. Стрелки типа «Связь предшествования».

5. Стрелки типа «Поток объектов».

События служат для определения границ процесса. Они могут указывать на его начало и завершение. Кроме того, возможны промежуточные события, возникающие по ходу выполнения процесса. Примеры именования событий: «Поступила заявка клиента на отгрузку продукции», «Утвержден план проекта», «Подписана накладная», «8.00 понедельника» и т. п. Как видно на рис. 4.6.1, в различных нотациях события показаны при помощи разных условных обозначений. Особняком стоит BPMN 2.0^[94] (см., например, [9]). В рамках этой нотации внутри графического элемента «Событие» могут присутствовать различные маркеры: таймер, сообщение, триггер и т. д.

_{Рис. 4.6.1. Основные элементы нотации Work Flow}

Операторы логики служат для описания ситуаций, связанных с ветвлением процесса. Оно может произойти по разным причинам (например, принятие решения, проверка условия). Операторы логики бывают трех типов^[95]: логическое «И», логическое исключающее «ИЛИ», логическое неисключающее «ИЛИ».

На рис. 4.6.2 приведен пример использования операторов логики при построении схемы типа Work Flow (графические обозначения операторов логики на схеме условные).

_{Рис. 4.6.2. Использование операторов логики}

При использовании логического оператора «И» (ситуация 1) после операции 1 выполняются операция 2 и операция 3.

При использовании логического оператора исключающее «ИЛИ» (ситуация 2) после операции 1 выполняется одна из двух операций – 2 или 3.

При использовании логического оператора неисключающее «ИЛИ» (ситуация 3) после операции 1 выполняется операция 2, либо операция 3, либо операции 2 и 3.

Условные обозначения для операций процесса (задач, действий, функций) выглядят практически одинаково во всех нотациях типа Work Flow.

Важный элемент схемы Work Flow – связи. Они представлены при помощи стрелок определенного вида. Первый тип – стрелки «Связь предшествования». Без них построение модели типа Work Flow невозможно. Стрелка «Связь предшествования», связывающая две операции, показывает, что вторая операция начинает выполняться только после завершения первой. Можно сказать, что стрелки «Связь предшествования» демонстрируют развертку процесса во времени.

Стрелки «Поток объектов» используются на схемах типа Work Flow для описания потоков документов и информации^[96].

За счет использования событий, операторов логики и стрелок «Связь предшествования» на схеме Work Flow можно показать сложную логику выполнения процесса во времени.

В следующих разделах рассмотрим наиболее известные нотации моделирования.

4.6.2. Простая блок-схема

Нотация «Простая блок-схема» реализована в MS Visio. На рис. 4.6.3 показаны элементы этой нотации и фрагмент соответствующей схемы. В полном объеме нотация применяется редко.

_{Рис. 4.6.3. Нотация «Простая блок-схема» в MS Visio}

Вообще в MS Visio представлено несколько сложных нотаций типа «Блок-схема». Видимо, поэтому они не нашли широкого применения, хотя и были включены в набор нотаций, поставляемых с системой.

Нотация «Простая блок-схема» в самом доступном и часто используемом варианте содержит всего несколько элементов:

• процесс;

• решение;

• ручная операция (реже);

• документ;

• данные;

• стрелка (для отображения связей между объектами схемы).

При помощи этой нотации можно показать потоки данных, если необходимо описывать процессы для автоматизации.

Рассмотрим некоторые особенности применения простой блок-схемы, в частности применение стрелок. Сотрудники компании, формирующие схемы при помощи простой блок-схемы, придерживаются двух подходов:

• не именуют стрелки вообще;

• стараются присваивать стрелкам, связывающим элементы схемы, простые и понятные названия.

На рис. 4.6.4 показан пример применения простой блок-схемы в одной из компаний. Применены все пять типов элементов. Тем не менее схема выглядит вполне читаемой и понятной пользователю – сотруднику компании.

_{Рис. 4.6.4. Пример схемы в нотации «Простая блок-схема»}

Нотация «Простая блок-схема» часто подвергается в организациях различным вариациям:

• изменяется смысл элемента «Решение» (его используют в качестве операции процесса);

• по-разному используют стрелки связей (именуют или не именуют и т. п.);

• по-разному используют стрелки связей в сочетании с объектом «Документ»;

• прочее.

Интересно, что нотация «Простая блок-схема» в том или ином виде часто используется специалистами по менеджменту качества при описании процессов СМК, так как она самая простая из известных.

Преимущества простой блок-схемы (с сокращенным до минимума количеством элементов):

• простота формирования графических схем процессов;

• интуитивная понятность схем сотрудникам (даже без специального обучения);

• минимальная потребность в обучении сотрудников;

• наличие доступных инструментов для описания процессов (MS Visio, MS Word).

Однако, как это часто бывает на практике, если нотация используется без утвержденного внутреннего стандарта и специализированного средства моделирования, компания получает множество нестандартно оформленных схем, которые содержатся в различных файлах. Поддерживать такой массив информации в связном состоянии и отслеживать изменения сложно. Требуется большой объем ручного труда бизнес-аналитиков. Поэтому, выбирая нотацию «Простая блок-схема», необходимо заранее разработать:

• внутренний стандарт использования этой нотации;

• внутренний стандарт формирования, хранения и актуализации файлов со схемами процессов.

Масштабное использование в компании нотации «Простая блок-схема» без современного средства моделирования неэффективно.

4.6.3. Нотация ARIS eEPC

^[97]

Нотация eEPC является частью общей методологии ARIS, в рамках которой организация рассматривается с четырех позиций: организационной, функциональной, структуры данных и бизнес-процессов. При этом каждая из позиций разделяется на три подуровня: описание требований, описание спецификации, описание внедрения. Для описания бизнес-процессов предлагается использовать около 80 типов моделей, каждая из которых принадлежит тому или иному аспекту.

ARIS eEPC – одна из первых нотаций, получившей широкую известность на российском рынке. Она относится к нотациям Work Flow. Особенности нотации – наличие элементов типа «Событие» и операторов логики «И», неисключающее «ИЛИ», исключающее «ИЛИ».

В качестве примера рассмотрим процесс, представленный на рис. 4.6.5, который начинается с события «Поступил заказ клиента». Оно инициирует операцию «Выполнить учет заказа в системе», которую проводит менеджер отдела сбыта. Для работы он использует систему учета заказов. Результат операции отображается событием «Учет заказа выполнен». После этого менеджер по сбыту осуществляет операцию «Выполнить анализ на соответствие номенклатуре». Ее результат – два альтернативных события: «Заказ соответствует номенклатуре» и «Заказ не соответствует номенклатуре». Процесс ветвится. Для отображения ветвления процесса используется символ логического исключающего «ИЛИ».

_{Рис. 4.6.5. Схема процесса в нотации ARIS eEPC}

^{* ПЭО – планово-экономический отдел.}

Операция «Уведомить клиента о невозможности выполнения заказа» может выполняться в двух случаях: если заказ не соответствует номенклатуре или если производство невозможно. Для отображения на схеме процесса этих вариантов используется символ логического «ИЛИ».

Нотация ARIS eEPC содержит большое количество графических элементов. Поэтому при выполнении проектов создаются так называемые методические фильтры (в рамках соглашений по моделированию), которые ограничивают количество типов элементов, доступных пользователям при создании схем процессов. (В некоторых средствах моделирования нотация ARIS eEPC сразу реализована с минимально необходимым набором элементов.) Однако даже в этом случае неопытные пользователи создают схемы такой сложности, в которых трудно разобраться. К ним нужен подробный комментарий (либо наличие аналитика, способного объяснить схему).

Почему возникает такой эффект? Это результат описания множества возникающих при выполнении процесса ветвлений при помощи формальных логических операторов. Делать это приходится по строгим правилам. В результате появляется формально правильная, но громоздкая, плохо воспринимаемая схема. Впрочем, это проблема почти всех нотаций Work Flow. Для специалиста, который занимается моделированием постоянно, выбор ARIS eEPC в качестве инструмента описания вполне адекватен.

Следует отметить, что типичная схема в ARIS eEPC:

• не годится для автоматизации в системе класса BPM (Business Process Management) (нужно применять дополнительный транслятор, переводящий ее в нотацию BPMN, с последующей ручной доработкой);

• сложна для восприятия рядовыми сотрудниками (их нужно учить правилам использования логических операторов и корректному чтению схем, которые их содержат).

Итак, нотация ARIS eEPC не предназначена для описания автоматически исполняемых процессов и неудобна для восприятия из-за своей сложности. Моделирование в ARIS eEPC не дает значительных преимуществ ни для автоматизации, ни для регламентации. Это классическая, формально правильная, но неудобная для восприятия нотация.

Несмотря на перечисленные проблемы, применение нотации ARIS eEPC и соответствующего средства моделирования, безусловно, позволяет создать в организации качественную, комплексную процессную модель. Многие крупные и средние российские компании используют ARIS eEPC для описания и регламентации бизнес-процессов. Могу предположить, что в этих компаниях постепенно произойдет переход от нотации ARIS eEPC к более сложной, но и более выразительной (с точки зрения задач бизнес-моделирования) нотации BPMN 2.0.

4.6.4. Нотация BPMN

BPMN – система условных обозначений (нотация) и модель для описания и подготовки к автоматизации бизнес-процессов.

Разработана она компанией Business Process Management Initiative и поддерживается Object Management Group после слияния организаций в 2005 году. Предыдущая версия BPMN – 1.2, последняя версия – 2.0^[98].

Нотация BPMN появилась относительно недавно. Она ориентирована на описание так называемых исполняемых процессов, то есть процессов, которые поддерживаются системами автоматизации операционных процессов – BPM.

Рассмотрим пример. В торговой компании есть отдел продаж, деятельность которого заключается в получении и обработке заявок клиентов, выставлении счетов и т. п. Структура процессов отдела следующая:

• получение заявок клиентов;

• обработка заявки и выставление счета (процесс выполняется по одинаковой процедуре несколькими менеджерами отдела);

• формирование графика доставки;

• обработка ждущих (отложенных) заявок;

• контроль остатков, рассылка информационных писем клиентам;

• изменение статуса товара в базе;

• обработка отказов.

На рис. 4.6.6 показан процесс «Обработка заявки и выставление счета клиенту», описанный в нотации BPMN. Схема рис. 4.6.6 содержит три объекта типа Gateway, восемь – типа Event и четыре операции (действия, задачи). Как видим, процесс совсем несложный, но количество условных обозначений, нужных для его описания, значительно.

_{Рис. 4.6.6. Фрагмент модели процесса в нотации BPMN 2.0}

К нотации BPMN специалисты относятся по-разному. Для профессионалов, описывающих процессы с целью автоматизации, она весьма удобна. Более того, сейчас BPMN, очевидно, нет альтернативы. Но для руководителей и сотрудников организации, не обладающих компетенциями в области бизнес-моделирования, эта нотация слишком сложна. Применение BPMN в масштабах компании требует значительных затрат на обучение сотрудников, создание у них навыков моделирования. Это сложнее, чем при использовании более простой и понятной нотации. Поэтому выбирать BPMN можно в случае, если:

• руководители готовы тратить деньги на обучение и развитие культуры бизнес-моделирования в организации;

• руководители сами готовы активно осваивать нотацию BPMN;

• предполагается активно использовать схемы процессов в BPMN для автоматизации операционных процессов.

К сожалению, сейчас на русском языке нет книг по использованию нотации BPMN. Есть только статьи, презентации, материалы вебинаров. Специалисты, заинтересованные в ее изучении, вынуждены обращаться к англоязычным источникам. Надеюсь, что в ближайшей перспективе ситуация изменится к лучшему.

4.6.5. Нотация «Процедура» среды моделирования Business Studio

Сейчас одним из распространенных инструментов бизнес-моделирования стала среда Business Studio^[99]. В этой системе реализованы четыре нотации: IDEF0, «Процесс», «Процедура», eEPC.

Нотация IDEF0 используется для построения моделей верхнего уровня, а «Процедура» и eEPC – для создания моделей типа Work Flow.

Рассмотрим подробнее нотацию «Процедура» (см. рис. 4.6.7), так как она наиболее проста и удобна для описания бизнес-процессов организации. Основные элементы нотации – это:

• операция («Действие» в терминологии Business Studio);

• событие;

• блок «Решение»;

• стрелка типа «Связь предшествования»;

• стрелка типа «Поток объектов»;

• междиаграммная ссылка (МДС);

• сноска (текстовый комментарий);

• дорожки.

_{Рис. 4.6.7. Схема процесса в нотации «Процедура» среды моделирования Business Studio}

Ниже привожу рекомендации по использованию нотации «Процедура» в организации.

Размеры используемых шрифтов, визуальный вид объектов, цветовое кодирование могут быть реализованы в типовых настройках Business Studio. Как правило, данные настройки делаются один раз и не должны в последующем изменяться пользователями.

Дорожки на схеме процесса предназначены для отображения операций, выполняемых одним сотрудником, находящимся на соответствующей должности, либо одним сотрудником, играющим в процессе соответствующую роль. Рекомендуется использовать вертикальное представление дорожек. Можно выбирать их горизонтальное расположение, если так принято в организации.

Схема процесса располагается на листе формата А4. Какие-либо изменения размера листа, как правило, не допускаются. Это ограничение дает возможность документировать схемы процессов в привычном формате (включать в регламентирующие документы компании). Отмечу, что это важное требование и им не стоит пренебрегать.

Рекомендуемое количество операций на одном листе – от 3 до 12. Если операций более 15, необходимо либо агрегировать их, либо попытаться разбить процесс на несколько подпроцессов.

В рамке автоматически указывается название процесса. Использовать номер процесса в рамке нежелательно. Дело в том, что в справочнике процессов удобно применять автоматическую нумерацию. Если в него вносятся новые процессы, то нумерация меняется. При этом в графических схемах, которые уже включены в регламентирующие документы компании, остается старый номер процесса. Это неудобно. Именно поэтому не рекомендуется указывать номер процесса на его графической схеме.

Надписи на стрелках могут располагаться как горизонтально, так и вертикально для обеспечения визуальной наглядности.

Операции процесса должны быть связаны между собой стрелками типа «Связь предшествования». Если после выполнения операции необходимо поставить блок «Решение», то связи операций с этим блоком также отображаются при помощи стрелок «Связь предшествования».

Если между двумя операциями на схеме представлен блок «Решение», то для моделирования передачи информации/документов из одной операции в другую используют стрелки типа «Поток объектов».

В случае перехода на один уровень вверх относительно схемы подпроцесса, разработанной в нотации «Процедура», дорожки на схеме устанавливаются по должности или роли владельца подпроцесса.

На рис. 4.6.8 представлены варианты именования операции процесса в формате «глагол + существительное». Также показаны ошибки, часто допускаемые при именовании операций.

_{Рис. 4.6.8. Именование операций процесса}

Стрелки типа «Связь предшествования» показывают последовательность выполнения операций процесса во времени. Каждая именованная стрелка в Business Studio – объект базы и хранится в справочнике стрелок. К именованным стрелкам типа «Связь предшествования» можно привязывать объекты из справочника «Объекты деятельности» (например, бумажные или электронные документы). К неименованным стрелкам привязать объекты невозможно. На рис. 4.6.9 показаны правильные и неправильные варианты применения стрелок на схеме процесса. Стрелки должны быть привязаны к операциям. Наличие стрелок, не привязанных к операциям (либо междиаграммным ссылкам), не допускается. Стрелки необходимо именовать. Нельзя использовать короткие, абстрактные названия: «да», «договор», «поступило письмо», «информация». Они должны быть подробные, конкретные и отражать контекст того процесса, в рамках которого создаются.

_{Рис. 4.6.9. Использование стрелок типа «Связь предшествования»}

Стрелки типа «Связь предшествования» желательно именовать, указывая:

• название документа в именительном падеже;

• описание результата выполнения операции в терминах события.

Стрелки типа «Поток объектов» показывают движение объектов между операциями процесса. Под объектами понимаются любые объекты из справочника «Объекты деятельности системы Business Studio». В первую очередь это бумажные/электронные документы и информация. Стрелки «Поток объектов» используются там, где невозможно (нецелесообразно) использовать стрелки «Связь предшествования», например:

• при использовании блока «Решение»;

• при описании межпроцессного взаимодействия при помощи информационного потока с использованием междиаграммных ссылок.

Каждая именованная стрелка – объект базы и хранится в справочнике стрелок. К именованным стрелкам можно привязывать объекты из справочника «Объекты деятельности» (например, бумажные или электронные документы). К неименованным стрелкам привязать объекты невозможно.

На рис. 4.6.10 показаны правильные и неправильные варианты применения стрелок на схеме процесса.

_{Рис. 4.6.10. Использование стрелок типа «Поток объектов»}

Стрелки должны быть привязаны к операциям. Наличие стрелок, не привязанных к операциям (либо междиаграммным ссылкам), на схеме процесса не допускается.

Стрелки необходимо обязательно именовать, но нельзя использовать короткие, абстрактные названия типа «Договор», «Письмо», «Информация». Они должны быть подробными, конкретными и содержать наименование или отражать суть тех документов/информации, которые используются в рамках моделируемого процесса.

Стрелки типа «Поток объектов» можно именовать, указывая название документа (формулировку информационного потока) в именительном падеже.

Объекты типа «Событие» используются на схеме процесса для отображения событий. События бывают инициирующими процесс (одно или более), промежуточными (одно или более), завершающими процесс (одно или более).

Промежуточные события можно использовать, когда временна?я последовательность выполнения операций процесса прерывается на неопределенное время.

Если по ходу моделирования возникает промежуточное событие, то рекомендуется разделить процесс на несколько подпроцессов.

На рис. 4.6.11 показаны правильные и неправильные варианты применения на схеме объектов типа «Событие».

_{Рис. 4.6.11. Использование событий}

Блок «Решение» используется на схемах процессов в качестве логического оператора (gateway). Обратите внимание, что «Решение» в Business Studio обладает всеми атрибутами класса «Процесс», но не может быть декомпозировано на следующий уровень.

Блок «Решение» именуется при помощи существительного. Примеры:

• «Проверка принятого решения»;

• «Проверка применимости условий типового предложения»;

• «Сравнение величины запрашиваемой скидки с возможной»;

• «Определение соответствия классификатору…».

На рис. 4.6.12 показаны правильные и неправильные варианты применения на схеме процесса блока «Решение».

_{Рис. 4.6.12. Использование блока «Решение»}

Блок «Решение» необходимо использовать на схеме процесса при возникновении ситуации, требующей применения оператора исключающего логического «ИЛИ» (рис. 4.6.12, ситуация 1). В случае применения блока «Решение» необходимо дополнительно использовать стрелку «Поток объектов» для описания информационного потока между операциями процесса (если он существует). Ситуация 2 некорректна в части именования блока «Решение» и стрелок. Ситуация 3 некорректна, так как требовалось применение блока «Решение».

Для упрощения графической схемы в Business Studio^[100] блок «Решение» не используется при возникновении ситуации, требующей применения оператора исключающего логического «ИЛИ» при объединении двух веток процесса (ситуация 4), а также оператора «И» (ситуация 5).

Для моделирования межпроцессного взаимодействия в Business Studio используют междиаграммные ссылки.

К ним могут быть привязаны как стрелки типа «Поток объектов», так и стрелки «Связь предшествования».

На рис. 4.6.13 показаны правильные и неправильные варианты применения на схеме процесса междиаграммных ссылок.

_{Рис. 4.6.13. Использование междиаграммных ссылок}

Если по смыслу модели нужно указать, что процессы обмениваются информацией/документами, то к междиаграммной ссылке привязывается стрелка типа «Поток объектов». Если следует указать, что процессы выполняются последовательно, то к междиаграммной ссылке привязывается стрелка типа «Связь предшествования».

Создавая междиаграммную ссылку, важно помнить, что соответствующая ссылка и стрелка появятся на той схеме процесса, на которую указывает ссылка.

Взаимодействие между процессами в рамках одной процессной ветки может быть показано при помощи механизма миграции стрелок с одного уровня модели на другой. Поясню. На схеме верхнего уровня один процесс связан с другим некоторым информационным потоком. При декомпозиции этих процессов на уровень вниз на схеме первого появится исходящая стрелка, а на схеме второго – входящая. В данном случае междиаграммная ссылка не используется. Однако если процессы находятся в разных процессных ветках, то использование междиаграммных ссылок при моделировании целесообразно и удобно.

Схема процесса в нотации «Процедура» при кажущейся простоте весьма информативна и удобна для описания. Можно сформулировать следующие преимущества этой нотации (в случае ее использования в Business Studio):

• представлен минимально необходимый набор графических элементов для описания процессов типа Work Flow (поток работ);

• быстрота создания графических схем для целей регламентации;

• возможность повышения информативности схем процессов за счет гибкого использования событий и именованных стрелок (одновременно с возможностью привязки документов к стрелкам и последующей выгрузки информации в регламентирующие документы);

• схемы процессов просты и понятны всем сотрудникам даже без специального обучения;

• простота в обучении (нет необходимости привлекать дорогостоящих специалистов со стороны – обучение можно проводить силами сотрудников отдела организационного развития);

• схемы процессов являются кросс-функциональными, что удобно для описания сквозных процессов компании;

• можно выгружать и редактировать схемы в MS Visio (при необходимости).

Среда моделирования Business Studio позволяет быстро создавать процессную модель компании. Информацию о процессах можно выгружать из системы в виде регламентирующих документов в требуемом формате.

В этом параграфе я привел описание требований к стандартному использованию нотации «Процедура» Business Studio. Но при создании корпоративного стандарта описания процессов вы можете разработать свои правила применения этой нотации. Хочу подчеркнуть, что не бывает идеальных нотаций и стандартов их применения. Важно сделать свой, понятный всем внутренний стандарт описания, опробовать его на практике, а затем использовать в текущей деятельности.

4.7. Информативность графических схем процессов

Одна из важнейших целей формирования графических схем процессов – их последующее использование в регламентирующих документах организации. По этим схемам, как правило, работают сотрудники, не обученные сложным нотациям, не имеющие навыков системного анализа. Для них очень важны простота и наглядность схем. Сложные, запутанные схемы, содержащие массу условных обозначений, плохо воспринимаются, и это затрудняет их практическое использование. Поэтому очень важен корректный выбор и использование нотации описания процессов. По каким критериям следует выбирать, как сравнивать разные нотации между собой? Рассмотрим следующие популярные нотации и попытаемся ответить на эти вопросы:

• «Простая блок-схема» (с отображением движения документов, с использованием блока «решение»);

• «Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»);

• «Процедура» системы Business Studio (один из возможных вариантов представления);

• ARIS eEPC.

В качестве тестового примера я выбрал простой и понятный процесс. Результаты его описания представлены на рис. 4.7.1–4.7.5.

_{Рис. 4.7.1. Схема процесса в нотации «Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение»)}

_{Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день}

На рис. 4.7.1 последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов – при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых зависит последующий ход процесса. Такой подход к использованию ромбиков – весьма распространенное явление. Но вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если вдуматься, то ценность (смысл) рисования этих ромбиков не очевидна. Что это за объекты – операции процесса, события? Вроде бы ни то ни другое. Это, скорее, операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе ромбик был бы полноценной операцией сравнения условий. Но на схеме процесса нужно показывать реальные объекты – процессы, выполняемые людьми, документы, информационные системы. Задумайтесь, корректно ли показывать ромбики отдельно от операции процесса на схеме? Вместо этого можно:

• описать логику принятия решения в виде последовательности операций на схеме рассматриваемого процесса;

• описать логику в виде схемы шагов соответствующего подпроцесса, переходя на уровень ниже;

• описать логику текстом (в текстовых атрибутах операции) и в последующем вывести в регламент выполнения процесса.

Сформулируем плюсы и минусы рассмотренного (рис. 4.7.1) способа использования ромбиков.

Простая блок-схема в MS Visio (с движением документов, с использованием блока «Решение»)

Плюс

1. Наглядное отображение логики выбора тех или иных выходов процесса.

2. Акцентирование внимания исполнителя на точке принятия решения/ветвление процесса в зависимости от условий

3. Схема процесса перегружена информацией.

Минус

1. Вынос логики принятия решения за пределы операции процесса (некорректно с точки зрения формальной декомпозиции процессов).

2. Неудобства при документировании процесса (приходится дублировать ромбики текстом при формировании текстового описания операции).

3. Ромбики часто используются слишком формально, без реальной необходимости

На рис. 4.7.2 приведен пример того же процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на рис. 4.7.1. Схема на рис. 4.7.2 выглядит гораздо проще: от графических элементов не рябит в глазах, а с точки зрения информативности она понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению, то, комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании. (Еще раз замечу: не вся информация о процессе должна быть представлена на его графической схеме. При работе с объектной моделью значительная часть сведений хранится в виде атрибутов объектов в базе данных.)

_{Рис. 4.7.2. Схема процесса в нотации «Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение»)}

_{Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день}

Плюсы и минусы графического изображения процесса в форме, представленной на рис. 4.7.2, показаны ниже.

Простая блок-схема в MS Visio (без движения документов, без использования блока «Решение»)

Плюс

1. Простота и наглядность для исполнителя.

2. На лист можно поместить больше информации, чем в случае формата, использованного на рис. 4.7.1

Минус

1. Логика принятия решений скрыта внутри операций процесса.

2. Графическую схему целесообразно сопровождать таблицей с текстовым описанием операций процесса

Применение схем в таком же формате, как представленный на рис. 4.7.2, удобно как для разработчиков (бизнес-аналитиков), так и для сотрудников.

На рис. 4.7.3 показана схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки «Решение»^[101] использованы нестандартным образом – не как графический элемент для отображения ветвления (оператор логики, развилка, гейтвей), а как полноценная операция процесса, связанная с принятием решений. Использование ромбика (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты ромбика можно внести любую текстовую информацию: описание, начало, завершение, требование к срокам и т. п.

_{Рис. 4.7.3. Процедура системы Business Studio (вариант с нестандартным использованием блоков «Решение»)}

_{Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день}

Вторая особенность схемы процесса на рис. 4.7.3 – применение стрелок. Для отображения последовательности операций полезно использовать стрелку с одним наконечником – стрелку «Связь предшествования». Для отображения движения документов применяют стрелку с двумя наконечниками. Но именно в Business Studio можно пользоваться только одним типом стрелок – стрелками «Связь предшествования», а к именованным стрелкам привязывать необходимое количество документов, которые определены в справочнике объектов деятельности. Такой подход позволяет сократить количество графических элементов на схеме процесса и при этом вывести в регламент процесса необходимую информацию о входящих и исходящих документах.

Таким образом, не загромождая схему лишними элементами, мы можем полностью описать процесс и выгрузить в регламент всю необходимую информацию.

Тот факт, что название стрелки в Business Studio не зависит от документов, которые к ней привязаны, позволяет именовать стрелки понятным и удобным для сотрудников образом. Например, к стрелке предшествования «Подготовлен комплект отчетов» можно привязать комплект конкретных документов. Название стрелки в этом случае указывает исполнителю на событие, завершившее предыдущую операцию, – «Сформировать отчет по инкассации за день». (Замечу, что в методологии компании СТУ^[102] стрелка после операции процесса – это сущность, а не событие. После блока «Решение» можно показывать его возможные результаты.)

Плюсы и минусы графического представления процесса на рис. 4.7.3 показаны ниже.

Процедура системы Business Studio (вариант с нестандартным использованием блоков «Решение»)

Плюс

1. Простота представления.

2. Акцентирование внимания исполнителя на операции, связанной с принятием решения/ветвлением процесса.

3. На листе формата А4 может располагаться большой объем информации (возможны разночтения)

Минус

1. Блок «Решение» не декомпозируется.

2. Неоднозначность в именовании стрелок

Обратите внимание, что в Business Studio нотация «Процедура» может использоваться по-разному.

На рис. 4.7.4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Замечу, что в схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий. Человек, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или без помощи квалифицированного бизнес-аналитика.

_{Рис. 4.7.4. Схема процесса в нотации ARIS eEPC (сформирована в Business Studio)}

_{OR – неисключающее логическое «ИЛИ»; XOR – исключающее логическое «ИЛИ».}

Замечу, что схема процесса в нотации ARIS eEPC занимает намного больше места, чем схемы на предыдущих рисунках. Трудоемкость ее формирования также гораздо выше.

Схема процесса в нотации ARIS eEPC (построена в Business Studio)

Плюс

1. При формировании схемы выдерживается строгая, формальная логика процесса.

2. Четко определены все события, возникающие по ходу процесса

Минус

1. Сложность восприятия.

2. Трудоемкость формирования схемы.

3. У сотрудников должны быть специальные навыки и опыт интерпретации подобных схем.

4. Информационная избыточность.

5. Занимает слишком много места, что неудобно для документирования

На рис. 4.7.5 изображен тот же процесс в нотации BPMN. Как видим, этот рисунок похож на рис. 4.7.1: в нотации BPMN задачи изображаются прямоугольниками, развилки – ромбами, данные – пиктограммой, похожей на документ. Потоки управления – сплошные линии, потоки данных – пунктирные.

_{Рис. 4.7.5. Схема процесса в нотации BPMN 2.0}

Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: лишь один вид развилок из пяти имеющихся и один вид задач из восьми. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но и несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, это более строгая нотация: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована и на то, что ее будут читать люди, и на непосредственное исполнение специальным программным обеспечением – движком BPM-системы. В то же время, как показывает данный пример, при использовании ограниченного подмножества BPMN оказывается не сложнее привычной блок-схемы.

При описании процессов на операционном уровне нужно стремиться к простоте и понятности схем для сотрудников. Использование сложных нотаций приводит к:

• трудностям при интерпретации схем рядовыми сотрудниками;

• невозможности (сложности) организации работ по описанию процессов силами сотрудников подразделений, не прошедших специальное обучение;

• значительному увеличению трудозатрат бизнес-аналитиков на формирование схем;

• дополнительным сложностям при документировании схем (например, большой объем).

Нотация моделирования должна соответствовать уровню процессной культуры организации. Если сотрудники компании делают первые шаги в области описания процессов, то желательно выбрать простую, наглядную и удобную нотацию.

4.8. Формирование регламентирующих документов на основе описания процессов

После того как процессы описаны в среде моделирования (говоря шире – создана объектная модель организации), можно и нужно использовать эту информацию для регламентации деятельности.

В этом параграфе приведен пример использования среды моделирования Business Studio для формирования регламентирующих документов. Рассматриваются процессы управления транспортным отделом одной из российских компаний (методика определения процессов управления представлена в главе 6). С технической точки зрения точно так же можно описывать любые процессы и другие объекты регламентации (подразделения, должности).

На рис. 4.8.1 показана структура процессов управления транспортным отделом (ТО) крупной торговой компании, разработанная в рамках проекта, в котором я в свое время принимал участие.

_{Рис. 4.8.1. Структура процессов управления транспортным отделом}

Представлен процесс управления транспортным отделом (ТО) торговой компании «Оптима» (г. Ижевск). Описание процессов выполнено в среде моделирования Business Studio. На рисунке слева видно дерево процессов, в котором процессы управления структурированы по соответствующим контурам.

Для описания объекта модели «Управление ТО» и контуров управления использована нотация «Процесс». Это наиболее простая нотация в Business Studio, но в рамках предложенной задачи ее использование вполне адекватно.

Для описания процессов внутри контуров управления использована нотация «Процедура». На рис. 4.8.1 показана кросс-функциональная схема процесса «Корректировка потребности в автотранспорте на месяц/квартал». В рамках данной модели все процессы управления описаны в виде подобных схем.

Для каждого процесса управления и для каждой операции процесса были заполнены текстовые атрибуты:

• содержание деятельности;

• начало процесса;

• результат процесса.

Этих атрибутов на первых порах вполне достаточно, но можно использовать и другие (в том числе создавать новые, необходимые бизнес-аналитику).

Для выгрузки описания процессов управления из Business Studio был разработан специальный отчет, который включает информацию о процессах на трех уровнях:

1. описание контура управления;

2. описание процесса в контуре управления;

3. описание операций процесса (в табличной форме) и схему процесса.

На рис. 4.8.2 показана работа мастера отчетов среды моделирования Business Studio. При помощи системы так называемых привязок была сформирована необходимая структура отчета. Затем создали и отредактировали шаблон отчета – регламент процесса управления на трех уровнях. После этого готовый отчет был сохранен в папке пользовательских отчетов среды моделирования Business Studio и запущен на выполнение для объекта «Управление ТО» (рис. 4.8.3).

_{Рис. 4.8.2. Мастер отчетов Business Studio. Разработка регламента управления на трех уровнях}

_{Рис. 4.8.3. Запуск отчета для объекта «Управление ТО»}

Отчет, запущенный для объекта модели «Управление ТО», сгенерировал документ в MS Word и вывел всю информацию о контурах и процессах управления в нужном формате. Автоматически было получено содержание документа (рис. 4.8.4).

_{Рис. 4.8.4. Содержание регламента процесса управления, полученное автоматически в результате запуска отчета в среде моделирования Business Studio}

_{Рис. 4.8.5. Вывод информации о процессе управления в табличной и графической форме}

На рис. 4.8.5 показан формат вывода информации для каждого процесса управления. Он включает в себя таблицу и графическую схему процесса, размещенную на листе формата А4. Видно, что описание операций процесса выводится в виде таблицы, содержащей следующие столбцы:

• номер операции;

• наименование операции;

• исполнитель;

• инициирующие события;

• входящие документы;

• описание операции;

• завершающие события;

• исходящие документы.

Графическая схема процесса представлена в кросс-функциональном виде. Объем регламента процесса управления составил для процесса «Управления ТО» около 70 страниц в MS Word, что совсем немного для такого значительного количества процессов.

Отмечу, что среда моделирования Business Studio позволяет формировать и выгружать практически любые отчеты, нужные для регламентации деятельности организации, в том числе:

• регламенты выполнения процессов;

• положения о подразделениях;

• должностные инструкции (на должности и роли).

4.9. Особенности создания корректных схем процессов

В этом параграфе мы остановимся на особенностях создания корректных схем бизнес-процессов. Неопытные бизнес-аналитики или сотрудники подразделений, привлеченные к работе по описанию процессов, подчас рисуют никуда не годные схемы. Как этого избежать? Конечно, только после получения специалистом нужной квалификации и опыта качество графических схем становится более или менее приемлемым. Но есть несколько аспектов, учет которых позволит даже неопытным в этом деле сотрудникам разрабатывать схемы приемлемого качества. Рассмотрим их.

4.9.1. Корректное определение границ процесса

Для успешного описания процесса прежде всего необходимо корректно определить его границы. Если пренебречь этим простым правилом, то в результате описания получается совершенно не то, чего ожидали (рис. 4.9.1). При внимательном изучении содержания схемы и сравнении ее с названием оказывается, что для описания выбрали один объект (судя по названию), а рисовали совершенно другой. Почему так вышло? Не были четко определены границы процесса, и по ходу формирования схемы процесс пошел совершенно не так, как надо.

Напомню, что границы целесообразно определять по входам/выходам (то есть движению информационных и материальных ресурсов) и событиям (инициирующим и завершающим).

_{Рис. 4.9.1. Выход за границы процессов}

4.9.2. Привязка к системе процессов

В предыдущем случае мы говорили о том, что процесс «ушел не туда». Еще одна из причин такой ситуации – отсутствие системного ви?дения бизнес-процессов организации. Если иерархического справочника процессов нет, то при попытке описать какой-то процесс, скорее всего, возникнет ситуация захвата областей из других процессов и т. п. Затем последуют малопродуктивные споры, как провести границы. Поскольку переделка схем требует времени, появляется искушение согласовать кривые границы процессов и т. д. (рис. 4.9.2).

_{Рис. 4.9.2. Конфликты на границах процессов}

4.9.3. Декомпозиция – слишком длинные процессы

Неопытные бизнес-аналитики часто рисуют слишком длинные схемы процессов. Так бывает, если начать задавать вопросы сотруднику и одновременно пытаться формировать схему. Лучше сначала выслушать описание деятельности, делая пометки в блокноте. Затем обдумать ситуацию, структурировать это описание и снова сделать пометки в блокноте, выделяя процессы и предварительно определяя состав их операций. Только после этого можно приступать к формированию графических схем. Кстати, велика вероятность, что при структурировании полученной информации будет целесообразно выделить и описать не один, а несколько процессов.

Если схема процесса все-таки получилась слишком длинной (более 12–15 операций), следует внимательно ее проанализировать.

Возможно, что:

• на схеме представлено несколько процессов, а не один;

• операции процесса неоднородны (по длительности выполнения, требуемым ресурсам и т. п.);

• в процессе появилась «грыжа» (см. ниже);

• прочее.

В любом случае схему процесса стоит переделать. Исключения составляют ситуации, когда схемы специально рисуют на бумаге формата А3, чтобы детально отразить все шаги и взаимодействия. Но увлекаться увеличением формата листов для схем процессов не стоит. А3 – это максимально допустимый размер. Рисовать и печатать схемы процессов на А2 или А1 категорически не рекомендуется (рис. 4.9.3).

_{Рис. 4.9.3. Чрезмерно длинные процессы}

4.9.4. Процесс в процессе, или «Процессная грыжа»

«Процессная грыжа» (рис. 4.9.4) часто появляется у неопытных бизнес-аналитиков и специалистов, не обладающих навыками системного мышления. Ситуация заключается в том, что внутри схемы процесса представлено описание деятельности, которая выполняется другим подразделением, в другое время и т. п. Но сотруднику кажется, что без этого описания схема будет неполной. Понятие «процессный интерфейс» (ссылка на другой процесс) или возможность взаимодействия процессов при помощи данных при этом совершенно упускаются из виду. Например, сотрудник описывает процесс работы с клиентом, в рамках которого нужно выяснить его платежеспособность. Для отработки запроса служит специальный процесс, выполняемый бухгалтерией, финансовым отделом и службой безопасности. Проверка платежеспособности может потребоваться еще в десятках ситуаций. Но сотрудник упорно рисует все эти действия на своей схеме, которая становится просто огромной.

_{Рис. 4.9.4. «Процессная грыжа»}

Можно предложить следующие решения проблемы:

• разделить процесс на несколько частей и описать их в виде отдельных моделей, увязав между собой;

• вместо подробного описания поместить на схему ссылку на процесс, описанный в другой части системы процессов организации.

В первом случае возникает вопрос, как быть со сквозными процессами. Ответ прост. Сквозной процесс, как и любой другой, можно декомпозировать на несколько процессов. Каждый из этих подпроцессов, в свою очередь, может быть описан в виде кросс-функциональной схемы (см. главу 2). Важно только корректно установить связи между ними (информационные потоки, события).

4.9.5. Примитивизация – рисование процесса по «хвостам»

Одна из распространенных ошибок неопытного бизнес-аналитика – попытка описать бизнес-процесс, последовательно характеризуя операции по работе с документом (рис. 4.9.5). Если цель работы – создать маршрут движения документа, то это нормально. Если же надо описать именно бизнес-процесс, то такой подход приводит к ошибкам. Ведь кроме операций по работе с документом в процессе существует еще множество важных действий: получение информации, ее анализ, различные согласования, принятие решений. Бизнес-аналитик должен видеть картину целиком, а не только маршрут движения одного документа.

_{Рис. 4.9.5. Схема документооборота вместо схемы процесса}

4.9.6. Однородность процесса

Однородность процесса – один из тех важных аспектов, на которые стоит обращать внимание при описании. Все определенные в рамках процесса операции должны по возможности соответствовать друг другу по длительности, трудоемкости, количеству потребляемых ресурсов. Так, некорректно отображать на схеме одного процесса две операции, одна из которых заключается лишь в передаче документа исполнителям, а вторая означает работу целого отдела по формированию пакета документов в течение двух недель. В данном случае неоднородность возникает по таким параметрам, как исполнители, состав работ, время их выполнения.

Если при описании процесса выявлена неоднородность, это красноречиво указывает на необходимость его реструктурирования: какие-то операции следует агрегировать (укрупнить), а другие, наоборот, детализировать. В любом случае неоднородность описания говорит о недостаточной проработке как самой схемы, так и всей системы процессов организации (рис. 4.9.6).

_{Рис. 4.9.6. Различный масштаб процессов}

4.9.7. Связи между процессами, оборванные входы/выходы

Бизнес-аналитик должен ясно осознавать, что между процессами всегда существует взаимодействие. На схеме его можно показать через обмен данных. Это означает, что из процесса выходят и, наоборот, в процесс входят документы (в бумажном или электронном виде). При этом очень важно понимать, что эти документы не берутся из воздуха, а появляются в каком-то одном процессе, используются другим процессом, передаются третьему и т. д. Если бизнес-аналитик рисует на схеме процесса документы, не отдавая себе отчета в том, откуда они берутся, не уточняя их название и содержание, то схема будет мало соответствовать реальности.

На схеме процесса не допускаются оборванные входы и выходы (рис. 4.9.7). Всегда должны стоять ссылки на соответствующие процессы поставщиков и потребителей информации/документов.

_{Рис. 4.9.7. Оборванные входы/выходы процессов}

4.9.8. Нарушение нотации моделирования

Нарушение нотации моделирования создает проблемы – схема становится нечитаемой, возникают неоднозначные моменты в ее интерпретации и т. д. Если в организации установлен стандарт моделирования бизнес-процессов, то обязательно нужно его придерживаться. Чем сложнее выбранная нотация, тем больше вероятность, что неопытный бизнес-аналитик нарисует схему, содержащую множество ошибок (рис. 4.9.8).

Опыт показывает, что сотрудники склонны упрощать любую нотацию до примитивного уровня (это можно назвать профанацией моделирования процессов). К сожалению, при этом качество схем оказывается никуда не годным. В таких компаниях руководство утверждает: «Мы пытались рисовать графические схемы, но что-то у нас они не получились. Мы решили описывать все текстом». Так появляются довольно увлекательные управленческие «новеллы» и «романы» в регламентирующем стиле.

_{Рис. 4.9.8. Чрезмерно сложные схемы процессов}

4.9.9. Проверка на здравый смысл

Даже самому опытному бизнес-аналитику полезно оценить полученную схему процесса с точки зрения здравого смысла (рис. 4.9.9). Это означает, что нужно, например, проверить процесс на физическую реализуемость: мы показываем, что сотрудник делает то-то и то-то, а он в это время давно уже занят чем-то другим и т. п.

Целесообразно обратить внимание на:

• ненужное повторение операций;

• перегрузку исполнителей;

• контрольные операции, от которых можно отказаться;

• возможность параллельного выполнения операций;

• возможность упрощения алгоритма выполнения процесса;

• неоправданное усложнение (лишние, устаревшие операции);

• узкие места различного характера;

• недостаточное обеспечение ресурсами;

• прочее.

_{Рис. 4.9.9. Проверка на здравый смысл}

4.10. Рекомендации по внедрению среды моделирования процессов

Внедрение среды моделирования процессов в масштабах организации – важный и сложный проект. Для его успешного выполнения нужно разработать план, адекватный задаче. Предлагаю один из возможных вариантов такого плана^[103].

Для крупной компании внедрение среды моделирования – серьезный проект, который может состоять из трех этапов^[104]:

1. Выбор и тестирование среды моделирования.

2. Опытная эксплуатация среды моделирования.

3. Внедрение среды моделирования в масштабах компании.

Этап 1. Выбор и тестирование среды моделирования:

• определение потребностей внутренних пользователей;

• определение и согласование целей и задач проекта;

• анализ сред моделирования, представленных на рынке (по документации), и выбор системы для тестирования;

• установка пробной версии среды моделирования (два-три рабочих места);

• создание пилотной модели организации:

– описание двух-трех процессов на двух уровнях;

– описание фрагмента организационной структуры;

– описание некоторых документов, терминов, ТМЦ;

– формирование пилотных отчетов (регламентов выполнения бизнес-процессов);

• тестирование среды моделирования на основе пилотной модели:

– тестирование функциональных возможностей системы;

– тестирование выгрузки отчетов (регламентирующих документов);

– тестирование управления изменениями;

• анализ результатов тестирования среды моделирования на пилотной модели, принятие решения о выборе системы;

• определение конфигурации системы, необходимой для решения задач организации;

• принятие решения и закупка среды моделирования;

• установка системы (три-пять конкурентных лицензий);

• обучение группы специалистов работе со средой моделирования (включая прохождение теста и получение официальных сертификатов);

• разработка детального плана опытной эксплуатации среды моделирования.

Этап 2. Опытная эксплуатация среды моделирования:

• администрирование системы:

– создание групп пользователей и определение прав доступа;

– настройка функционала контроля внесения изменений в систему;

• анализ и внесение необходимых изменений в метамодель:

– анализ требований внутренних потребителей по выгрузке отчетов из среды моделирования (регламенты, положения, прочие отчеты);

– анализ возможностей метамодели с точки зрения хранения информации, необходимой для выгрузки отчетов;

– определение и внесение необходимых дополнений в метамодель (структуру данных);

– определение требований по использованию метамодели при моделировании организации;

• ввод в систему необходимых справочников:

– иерархический справочник процессов организации (возможно, путем импорта системы процессов организации из файла MS Excel);

– иерархический справочник подразделений и должностей;

– справочник бумажных и электронных документов (уровня компании);

– справочник терминов;

– прочее.

• разработка и тестирование необходимых шаблонов регламентирующих документов и других отчетов;

• разработка решений по интеграции с другими системами («экспорт – импорт»);

• разработка стандарта моделирования (нормативный документ, регламентирующий использование функционала системы и метамодели при описании процессов, подразделений, документов и т. п.);

• разработка и тестирование регламента управления изменениями (нормативный документ, регламентирующий взаимодействие сотрудников и порядок внесения изменений в объектную модель организации);

• анализ эффективности функционирования среды моделирования; внесение необходимых изменений в регламенты работы с системой.

Этап 3. Внедрение среды моделирования в масштабах компании:

• определение количества необходимых лицензий;

• закупка и установка среды моделирования в структурных подразделениях организации;

• обучение руководителей и специалистов подразделений использованию системы (соглашение по моделированию, регламент управления изменениями и т. д.);

• разработка плана описания процессов организации;

• описание приоритетных процессов организации силами специалистов подразделений; выгрузка регламентирующих документов;

• анализ эффективности эксплуатации среды моделирования, внесение необходимых изменений в регламенты работы с системой.

В стандарте по моделированию сформулированы требования по использованию системы при описании процессов, подразделений, документов и т. п. Это подробная инструкция, в соответствии с требованиями которой сотрудники организации обязаны работать со средой моделирования: заносить информацию в соответствующие атрибуты объектов модели, формировать графические схемы и т. д. Документ может иметь такую структуру (на примере стандарта, разработанного для использования среды Business Studio):

1. Общие положения

1.1. Назначение и область действия

1.2. Используемые сокращения

1.3. Термины и определения

1.4. Нормативные ссылки

2. Ведение справочников в Business Studio

2.1. Справочник «Процессы»

2.2. Справочник «Субъекты»

2.3. Справочник «Объекты деятельности»

2.4. Справочник «Управление»

3. Описание процессов в Business Studio

3.1. Элементы нотации «Процедура» Business Studio

3.2. Описание операций процесса

3.3. Использование стрелок типа «Связь предшествования»

3.4. Использование стрелок типа «Поток документов»

3.5. Использование событий

3.6. Использование блока «Решение»

3.7. Использование междиаграммных ссылок

3.8. Использование сносок

4. Схемы организационной структуры в Business Studio

4.1. Используемые графические элементы

5. Заполнение атрибутов объектов модели

5.1. Заполнение атрибутов процесса

5.2. Заполнение атрибутов операции процесса

5.3. Заполнение атрибутов стрелок

5.4. Заполнение атрибутов субъекта деятельности

5.5. Заполнение атрибутов объекта деятельности

5.6. Заполнение атрибутов целей и показателей

6. Приложения

6.1. Пример схемы процесса в нотации «Процедура» Business Studio

Регламент управления изменениями – это инструкция по внесению существенных изменений в систему, в том числе изменение модели организационной структуры, изменение справочника процессов на верхнем и среднем уровне, массовое переназначение ответственности за выполнение процессов. Подобные действия могут выполнять только квалифицированные бизнес-аналитики, имеющие соответствующие полномочия. Регламент может выглядеть примерно так:

1. Общие положения

1.1. Назначение

1.2. Термины, определения и сокращения

2. Общее описание процесса управления изменениями

3. Типы изменений и распределение ролей и ответственности за управление изменениями

4. Изменения справочников

4.1. Организационная структура

4.2. Процессы

4.3. Объекты деятельности (документы, ТМЦ, программные продукты)

4.4. Цели и показатели

4.5. Прочее

5. Изменение схем процессов

6. Изменение шаблонов отчетов

7. Изменение метамодели

8. Архивирование и восстановление объектной модели

9. Изменение прав доступа

10. Изменение версии системы (переход на новые версии)

11. Изменение решений по интеграции с другими системами

В заключение приведу пример графика проекта по созданию репозитория бизнес-процессов организации на платформе среды моделирования Business Studio (рис. 4.10.1).

_{Рис. 4.10.1. График Ганта создания репозитория бизнес-процессов на платформе среды моделирования Business Studio}

После покупки и установки системы Business Studio следует обучить рабочую группу. Несколько специалистов из нее образуют потом центр компетенции по использованию репозитория бизнес-процессов. Остальные будут совмещать текущую деятельность в подразделениях с моделированием, анализом и регламентацией бизнес-процессов. Они станут агентами влияния процессной методологии в структурных подразделениях компании.

Для эффективного использования системы нужно разработать архитектуру (систему) бизнес-процессов компании. Удобно это делать в MS Excel, но можно и сразу в системе. Далее полученная архитектура процессов переносится в Business Studio – создается иерархический справочник процессов. Этот справочник – основа для накопления знаний о процессах в рамках электронного репозитория.

Затем рабочая группа описывает несколько пилотных процессов. Это делается для того, чтобы в полной мере освоить возможности инструмента и сформулировать предварительные требования к стандарту моделирования и шаблонам регламентирующих документов.

Чтобы выгрузить из репозитория информацию о процессах в необходимой форме (регламенты, инструкции, положения и т. п.), нужно определить требования к этим документам. При проектировании шаблонов отчетов увязываются между собой требования к документам и возможности системы. Например, если мы хотим видеть в документе какой-то атрибут бизнес-процесса, надо понимать, какую информацию и как следует заносить в репозиторий. Создание шаблонов для выгрузки сложных регламентирующих документов может потребовать изменений объектной модели Business Studio. Это легко делается при помощи специального инструмента Meta Edit, входящего в комплект поставки системы (в версии Enterprise).

Когда станет понятно, как моделировать процессы и какая информация должна заноситься в атрибуты объектов модели, разрабатывается стандарт моделирования (соглашение по моделированию).

Кроме этого документа полезно создать стандарт (инструкцию) по администрированию репозитория и стандарт по внесению изменений в модель организации.

После разработки и согласования стандартов проводится обучение руководителей и специалистов подразделений компании работе с электронным репозиторием бизнес-процессов на платформе Business Studio.

4.11. Список литературы

1. Репин В. В. Бизнес-процессы компании: построение, анализ, регламентация. – М.: Стандарты и качество, 2007.

2. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: Стандарты и качество, 2004.

3. Руководство пользователя Business Studio (2012).

4. Руководство технического специалиста Business Studio (2012).

5. Создание пользовательских отчетов Business Studio. Методика (2012).

6. Маклаков С. В. Моделирование бизнес-процессов с AIIFusion Process Modeler. – М.: Диалог-МИФИ, 2008.

7. Черемных С. В., Семенов И. О., Ручкин В. С. Структурный анализ систем: IDEF-технологии. – М.: Финансы и статистика, 2001.

8. Моделирование бизнеса. Методология ARIS. Практическое руководство / М. Каменнова [и др]. – М.: Серебряные нити, 2001.

9. Silver B. BPMN Method and Style: A levels-based methodology for BPM process modeling and improvement using BPMN 2.0. – Cody-Cassidy, 2009.

Глава 5
Регламентация бизнес-процессов организации

В этой главе рассмотрим вопросы, связанные с разработкой, внедрением и контролем исполнения регламентирующих документов по бизнес-процессам. Регламентация процессов – один из важных элементов системы процессного управления. Некорректное, формально-бюрократическое и неэффективное использование регламентирующих документов может существенно дискредитировать процессный подход в глазах руководителей и специалистов компании. В главе 5 содержится информация, которая должна помочь руководителям выстроить эффективно действующую систему регламентации.

5.1. Культура регламентации в российских компаниях

Крупные и средние российские компании обладают значительными ресурсами, часть которых может быть использована для построения эффективной системы регламентации. Однако этого не происходит. Почему? Поделюсь некоторыми соображениями на этот счет:

• регламентация деятельности имеет низкий приоритет с точки зрения топ-менеджеров (что вполне понятно, их интересует рост продаж, прибыль, капитализация);

• отсутствует культура работы по стандартам (корпоративная культура – вообще больной вопрос);

• устаревание нормативной базы при неадекватной и несвоевременной ее актуализации;

• в системе стимулирования нет элемента, направленного на создание у персонала мотивации исполнять регламенты;

• отсутствие нормирования труда в привязке к регламентам (невозможность исполнения стандартов из-за ресурсных ограничений);

• «исотизированные» (слишком общие) регламенты;

• регламентация процессов производства в ущерб регламентации процессов управления/развития (то есть регламентация в отдельно взятом подразделении).

5.1.1. Низкий приоритет регламентации с точки зрения топ-менеджеров

Глядя со стороны на работу топ-менеджеров компаний, можно сделать вывод, что регламентация деятельности интересует их в третью и даже в четвертую очередь (а в ряде случаев вообще не интересует). Правильная расстановка руководящего персонала и система материального стимулирования – и дело сделано! Топ-менеджеров интересует рост продаж, прибыль, капитализация, годовые бонусы и т. п. Было бы неправильно обвинять их в нежелании детально вникать в вопросы регламентации отдельных операционных процессов. Но именно в их власти создать систему работы, при которой регламентация действительно повышает эффективность. Однако ситуация чаще всего такова, что для решения этой задачи у топ-менеджеров просто не хватает времени. Задача строительства системы, спущенная на средний и нижний уровень, решается бесконечно и неэффективно.

5.1.2. Отсутствие культуры работы по стандартам

Вопрос культуры организации весьма непрост. У меня нет возможности подробно обсуждать его в этой книге. Замечу только, что культура работы по стандартам (регламентам) зависит от общей культуры компании. К сожалению, на многих российских предприятиях корпоративная культура не мотивирует сотрудников исполнять стандарты, в том числе потому, что их формально (и неформально) поощряют за совершенно другое. Стоит ли менять корпоративную культуру? Только в том случае, если топ-менеджмент принимает процессный подход как новую философию управления и реализует ее на практике личным примером.

5.1.3. Устаревание нормативной базы при неадекватной и несвоевременной ее актуализации

База внутренних нормативно-методических документов (НМД) крупной компании может включать сотни (если не тысячи) регламентов, положений, инструкций. Как правило, ситуация такова, что их не успевают актуализировать или делают это формально, для галочки. В результате от 30 до 80 % всех документов устаревают – безнадежно отстают от реальной деятельности. Руководители и сотрудники это понимают и относятся к регламентирующей документации соответственно – не исполняют ее. Причины неадекватной и несвоевременной актуализации документов:

• методически неправильно организованная работа (к актуализации не привлекают руководителей, непосредственно отвечающих за исполнение регламентирующих документов);

• недостаточная квалификация сотрудников, привлекаемых для ее выполнения;

• недостаток ресурсов;

• прочее.

Часто задачу актуализации регламентов поручают одному подразделению (или даже одному сотруднику!). Причем, как правило, у него и без этого много работы. В результате человек не справляется с поставленной задачей.

5.1.4. Система стимулирования

В крупных компаниях есть СПП, КПЭ^[105] и другие системы показателей, часть которых используется для материального стимулирования сотрудников. Чаще всего они ориентированы на достижения показателей результативности (план/факт), реже – на эффективность. Совсем редко в рамках системы стимулирования предусмотрены элементы, мотивирующие персонал на исполнение регламентирующих документов. Почему? Выдвину некоторые предположения:

• у руководства нет объективной информации об исполнении стандартов деятельности;

• регламенты слабо связаны с нормативами (см. ниже);

• требование по исполнению стандартов имеет низкий приоритет перед исполнением плана (то есть важен только план, а нарушать стандарты работы допускается).

Первая причина, вероятно, наиболее существенна. Если мы знаем, что регламенты устарели, неполны и не соответствуют реальности, то имеем ли мы право наказывать персонал за их неисполнение? Поэтому предложения некоторых консультантов ввести жесткие меры мотивации (30 %-ное лишение премии за неисполнение стандартов) не могут быть популярными. Кроме того, такое нововведение в рамках общей репрессивной системы менеджмента только усугубит ситуацию. При этом подразделение, проводящее аудиты нормативных документов, станет врагом всех сотрудников, а идея совершенствования на базе стандартов будет похоронена.

5.1.5. Отсутствие нормирования труда в привязке к регламентам

Какую информацию должен содержать регламент выполнения процесса? Есть несколько точек зрения на этот вопрос. Как минимум в него включают:

• паспорт документа (назначение, область действия и т. п.);

• краткое текстовое описание;

• графическую схему (довольно часто, впрочем, обходятся без нее);

• подробное пошаговое описание операций процесса (часто в виде таблицы).

Гораздо реже в регламент вносят описание ресурсов (количество требуемых сотрудников, оборудование и т. п.).

Крайне редко регламенты процессов построены с учетом реальной трудоемкости соответствующих операций и загрузки сотрудников, выполненной с учетом нормативов.

Пример. Выполняется описание процессов отдела. На выходе получается два десятка графических схем и несколько регламентов. Выходит, если следовать регламентам, каждый сотрудник должен участвовать в нескольких процессах. Но его рабочий день ограничен. Какие операции он успеет выполнить? Если не успеет, то на какой срок может отложить работу? Без нормирования на эти вопросы ответить почти невозможно. При последующем внедрении полученного комплекта документов возникнет ситуация, когда сотрудники не успеют выполнить ключевые требования из-за нехватки времени. Они могут использовать этот аргумент, чтобы объяснить неэффективность своей работы. В любом случае проверить это сложно.

Описание процессов при условии тщательно проработанных нормативов откроет реальную картину загрузки персонала и может указать на необходимость увеличения (или, наоборот, сокращения) штата. Этот вывод не порадует руководство, которое хотело бы обеспечить выполнение регламентов силами имеющегося персонала.

Для выполнения нормирования нужны квалифицированные специалисты, время на замеры и т. п. Для работников, стоящих за станком, без этого не обойтись, а как насчет фронт– или бэк-офиса? Часто задачи и/или ограничения бизнеса приводят к невозможности следовать нормативам. Вероятно, это одна из важных причин появления неработающих регламентов.

Приведу цитату с сайта Национального союза кадровиков:

«…Регламентация труда является основным средством организации трудовых процессов, с помощью которого обеспечивается достижение результатов, поставленных перед коллективом. Регламентация означает установление и строгое соблюдение определенных правил, нормативов и стандартов, в соответствии с которыми осуществляется деятельность персонала. Регламентация трудовой деятельности работников неразрывно связана с нормированием труда – процессом исследования, проектирования и установления необходимых затрат и результатов труда, а также оптимальных соотношений между численностью работников различных категорий и групп. Нормы труда в конечном счете устанавливаются в соответствии с достигнутым уровнем техники, технологии, организации производства и труда^[106]».

Итак, регламентация деятельности без нормирования вызывает вопросы.

Но и нормирование без проработки бизнес-процесса может иметь негативные последствия.

Пример. На складе есть норматив – тариф оплаты за разгрузку конкретного объема товара. Два грузчика, надрываясь, разгружают товар, чтобы побольше заработать. В это время еще два человека курят в сторонке. Сделать работу вместе в два раза быстрее и качественнее никто из них не стремится – это приведет к сокращению зарплаты.

5.1.6. «Исотизированные» (слишком общие) регламенты

Сами по себе стандарты ИСО на систему менеджмента качества (СМК) – довольно ценные методические документы. Однако их практическая реализация не дает ожидаемого эффекта. Об этом много писали и продолжают писать. Мне хотелось бы обратить внимание читателя на тот факт, что часто регламенты, написанные в рамках СМК, выглядят слишком общими. Когда их читаешь, вроде все правильно, но что конкретно надо делать, непонятно. Для таких регламентирующих документов (формально правильных, но чересчур общих) я подобрал термин «исотизированные». Это не обязательно регламенты СМК. В организациях хватает слишком общих документов. Какова ценность регламентов, неизвестно когда, как и кем исполняемых? Можно иметь сто стандартов верхнего уровня, но ни одного внутреннего операционного регламента, полезного при конкретном выполнении работы.

5.1.7. Регламентация процессов производства при отсутствии регламентации процессов управления/развития

В ряде компаний регламентация процессов производства достигает 90–100 %, то есть регламентирована почти вся деятельность. Внешние требования (ограничения) предопределяют наличие регламентов. Чем жестче проверки внешних контролирующих органов, тем работоспособнее эти документы. Однако они устаревают, могут плохо актуализироваться и т. д.

Хочу обратить внимание читателя и на другой аспект.

Пример. В производственной компании процессы производства регламентированы на 100 %, процессы складского хранения – на 80 %. Но степень регламентации процессов управления и развития близка к 0 %. Например, такие процессы, как «Планирование рекламой кампании» или «Принятие решения об инициации проекта разработки нового вида продукции», не регламентированы и выполняются «по понятиям». Это означает, что ключевые решения по распределению бюджета принимают без достаточного обоснования, подчас интуитивно.

Отсутствие регламентации процессов маркетинга, сбыта, развития ведет к потерям. Исключение составляют процессы управления финансами (в том числе бюджетирование), которые, как правило, достаточно формализованы.

Особенно подчеркну отсутствие регламентов управления, выполняемых руководством. На верхнем уровне, кроме нескольких общих положений, схемы организационной структуры и должностных инструкций руководителей, может не быть вообще ничего. Деятельность по принятию решений не регламентирована. Каждый раз решения принимаются по разным алгоритмам, они непрозрачны. Такая ситуация, как правило, не радует собственников бизнеса.

5.1.8. Отсутствие системы работы с регламентами

Зачастую в крупных и средних компаниях отсутствует система стандартизации (регламентации) деятельности. Иными словами, нет системного решения задач регламентации. Присутствуют фрагментарные элементы, неэффективно интегрированные между собой. Отсутствие системности проявляется, например, в следующем:

• эффективность работы по утвержденным регламентам никто не проверяет;

• регламенты вводят в действие, но не контролируют, своевременно не актуализируют;

• регламенты вводят в действие, но персонал с ними не знакомят и не обучают;

• одновременно существуют и используются различные версии нормативных документов;

• регламенты согласовывают, но не утверждают (работа впустую);

• аудиты проводят, проблемы выявляют, но реальную деятельность и соответствующие регламенты не изменяют;

• для работы по утвержденным регламентам не хватает ресурсов, но никого это не волнует;

• прочее.

Подробно система стандартизации бизнес-процессов описана в параграфе 5.4.

5.2. Минусы регламентации бизнес-процессов

Регламентация бизнес-процессов не всегда абсолютно и безусловно нужна организации. Точно так же как витамины полезны живому организму лишь до известной степени. В разделах 5.2–5.3 рассмотрим плюсы и минусы регламентации. Их выявление и обсуждение должно помочь уяснить положительные возможности и свести к минимуму риски построения системы регламентирующих документов в масштабах компании.

Рассмотрим минусы регламентации. Как правило, к их числу относят:

• значительные затраты на регламентацию;

• снижение творчества, инициативы сотрудников;

• разрушение сложившейся команды руководителей и специалистов;

• снижение гибкости в принятии решений, осуществлении изменений и как следствие – уход клиентов;

• дополнительную нагрузку на персонал, снижение производительности;

• увеличение сроков выполнения процессов из-за необходимости соблюдения регламентов;

• появление слишком сложных, забюрократизированных регламентов, что приведет к снижению удовлетворенности клиентов;

• возможность так называемой итальянской забастовки (см. пункт 5.2.8);

• возможную утечку информации о стандартах в другие организации;

• прочее.

Любой из этих минусов – риск неэффективного внедрения системы регламентации (стандартизации) бизнес-процессов. Рассмотрим последовательно каждый минус.

5.2.1. Значительные затраты на регламентацию

Да, затраты на регламентацию могут быть заметными. Но их существенно превышают потери от плохо налаженного взаимодействия и отсутствия четкого порядка выполнения ключевых процессов.

Наличие нужных методик и проработанного плана внедрения системы регламентации, привлечение квалифицированных экспертов, активное вовлечение руководителей и специалистов в проект дают возможность эффективнее использовать средства, выделяемые на регламентацию.

5.2.2. Снижение творчества, инициативы сотрудников

Творчество и инициатива нужны не всегда и не везде. Многие процессы должны выполняться только по установленному стандарту. Здесь любая инициатива может обернуться потерями (или более серьезными проблемами). Да, работа будет выполнена, но ее эффективность окажется низкой. Творчество и инициативу, очевидно, надо приветствовать в области анализа и разработки предложений по совершенствованию деятельности: изменению технологии, применению новых методов и инструментов и т. п. Поэтому, устанавливая систему жесткого контроля исполнения стандартов, нужно одновременно создавать и использовать систему подачи, анализа, обсуждения и внедрения предложений по улучшению процессов (элементы цикла PDCA Э. Деминга).

Проверьте, сколько предложений по улучшению работы поступило за прошлый год от руководителей отделов и специалистов, сколько из них было одобрено и внедрено. Тогда можно будет оценить реальную степень творчества и инициативности персонала. Если же предложений не было вовсе, как может повлиять регламентация на такое отсутствие творчества? Она не способна навредить реальной инициативности, но радикально снижает возможность покрывать разгильдяйство аргументацией о необходимости творчества в повседневной деятельности сотрудников. Не надо путать героев, личным трудовым подвигом устраняющих проблемы на производстве, и реальное творчество и развитие.

Проблема творчества и развития, скорее, заключается в другом. Если руководители, устанавливающие регламенты, консервативны и не готовы менять модель деятельности организации с нужной скоростью, то тормозить развитие будут именно они, а не те, кто работает по стандартам. Безынициативный сотрудник нанесет организации гораздо меньше вреда, чем топ-менеджер, настойчиво транслирующий в регламентную базу свои устаревшие взгляды на модель ведения бизнеса.

5.2.3. Разрушение сложившейся команды руководителей и специалистов

«Регламентация приведет к формализации отношений между участниками процессов. Начнут разрушаться существующие неформальные, устоявшиеся отношения в коллективе. Возникнут взаимные обвинения и обиды. В результате это негативно скажется на работе» – примерно такие аргументы обычно высказывают, когда говорят о разрушении команды.

Если команда есть, то она играет по определенным правилам. При отсутствии регламентации правила игры не формализованы и могут трактоваться по-разному. Нет гарантии, что они соответствуют целям собственников и топ-менеджеров организации. Грамотная регламентация может повысить эффективность командной работы за счет того, что правила становятся однозначными, доступными и понятными всем ее участникам. Они не могут быть произвольно изменены отдельными участниками команды, наделенными бо?льшими полномочиями или имеющими значительный авторитет. Однако при разработке регламентов нужно быть внимательным, чтобы исключить чрезмерное усложнение механизмов взаимодействия между сотрудниками.

Если же команды менеджеров в компании нет, то регламентация тем более не может навредить. Нужно думать о механизмах создания и поддержания возможностей для командной работы, если такой подход устраивает собственников и менеджеров организации.

5.2.4. Снижение гибкости в принятии решений, осуществлении изменений и как следствие – уход клиентов

Своевременно принятое, грамотное управленческое решение – это здорово! Но на практике неподготовленные, несогласованные, нигде не зафиксированные управленческие решения приводят к проблемам различного масштаба. Например, клиент просит нестандартную скидку. Коммерческий директор гибко и неформально идет ему навстречу. В итоге компания теряет деньги, а у собственников возникают сомнения в искренности этого коммерческого директора. Но если коммерческий директор по формальным критериям откажет и потеряет контракт с крупным клиентом, собственники также будут недовольны и т. п. Как же гибкость связана с регламентацией? В 90 % ситуаций регламент – очень полезный инструмент. Он дает возможность принимать обоснованные (по определенной методике) управленческие решения, фиксировать их и в последующем оценивать эффективность. Остальные 10 % ситуаций должны быть четко обозначены (без детальной регламентации действий сотрудника). При их наступлении управление сразу делегируется на вышестоящий уровень. Таким образом, гибкость не станет синонимом безответственности, а руководители будут четко знать пределы своих полномочий.

5.2.5. Дополнительная нагрузка на персонал, снижение производительности

Предполагается, что сотрудники компании потратят часть своего времени на написание регламентов, что снизит производительность труда. Кроме того, по ходу деятельности придется периодически обращаться к регламентам, проверяя соответствие выполняемой работы установленным требованиям.

Первый аргумент: создание и актуализация регламентов действительно занимают немало времени. Только не рядовых сотрудников, а руководителей. Но для них работа по стандартизации – одна из важнейших составляющих деятельности по управлению. Они получают за это зарплату. Руководитель обязан организовать свой рабочий день так, чтобы хватило времени на регламенты. Во многом дефицит времени связан с неупорядоченностью управляемой деятельности, когда правила игры не определены (например, полномочия не делегированы), а сотрудники постоянно отвлекают руководителя, обращаясь с мелкими проблемами.

Что касается второго аргумента, то он во многом надуманный. Если действительно сотрудники начнут периодически сверяться с регламентами, то менеджеры должны радоваться этому. Значит, в культуре организации появился новый, важный элемент – работа по стандартам. В реальности, к сожалению, часто наблюдается обратная картина: регламенты не работают.

5.2.6. Увеличение сроков выполнения процессов из-за необходимости соблюдения регламентов

Этот аргумент аналогичен предыдущему. Предполагается, что после регламентации процессы станет сложнее и дольше выполнять. Если раньше можно было быстро и гибко делать работу, достигая нужного результата, то после регламентации придется действовать по стандарту.

Кроме того, в данном случае не учитываются проблемы и потери, которые всегда сопровождают «быструю и гибкую работу». Вообще нужно внимательно оценивать ситуацию с процессами, анализировать степень влияния внешних условий. Если внешняя среда нестабильна и оказывает слишком возмущающее воздействие на процесс, то его нельзя жестко регламентировать. Даже если регламенты актуализируются быстро, можно не успеть внести все необходимые изменения. В этой ситуации могут возникнуть проблемы. Поэтому для некоторых групп процессов в определенных видах бизнеса жесткая регламентация неприемлема.

5.2.7. Появление слишком сложных, забюрократизированных регламентов

Такой риск действительно есть. Он связан с несколькими факторами:

• слишком формальной постановкой задачи регламентации и формальной, поверхностной оценкой полученных результатов руководителями;

• недостаточным методическим обеспечением проекта;

• плохим управлением проектом;

• неэффективным и забюрократизированным процессом согласования документов;

• отсутствием заинтересованности и готовности последовательно заниматься внедрением системы регламентации у первых лиц организации;

• отсутствием специалистов нужной квалификации;

• слишком сжатыми сроками;

• недостаточным бюджетом проекта;

• прочее.

Если регламенты пишут плохо подготовленные специалисты по недостаточно проработанной методике, используя неудобные формы, тратя на это в два-три раза меньше времени, чем положено, то они вполне могу оказаться не соответствующими поставленным целям, сложными, противоречивыми и неудобными в работе.

5.2.8. Возможность так называемой итальянской забастовки

Некоторые специалисты предполагают возможность так называемой итальянской забастовки, когда сотрудники организации преднамеренно работают в строгом соответствии с регламентами. Предполагают также, что эта система регламентов чрезмерно сложна, запутанна, противоречива, как и сами регламенты. В результате процессы выполняются слишком долго, клиенты недовольны, прибыль снижается и т. п.

Такая ситуация может сложиться в крупной организации (например, государственной) после проведения ряда проверок и показательного увольнения нескольких руководителей. В этом случае система^[107] начинает работу по формальным регламентам. Временно перестают действовать привычные и выгодные определенным субъектам обходные пути, ускоряющие формальный ход процесса. Поскольку регламентов много и они подчас взаимно противоречивы, проблемы решаются очень долго.

В коммерческой организации условия для возникновения итальянской забастовки создаются реже. В небольшой и средней компании вероятность ее возникновения ниже, чем в крупной или очень крупной.

Если собственники и топ-менеджмент постоянно занимаются анализом эффективности системы регламентации и предпринимают шаги по ее улучшению, то предпосылки для возникновения итальянской забастовки, скорее всего, не возникнут.

5.2.9. Возможная утечка информации о стандартах работы в другие организации

Утечка информации (передача комплекта регламентирующих документов в другую организацию) вполне возможна. Если речь идет о регламентах процессов или должностных инструкциях, ущерб от такой утечки не будет значительным. Другое дело, если передаются чертежи, технологические документы, рецептуры, управленческая отчетность и т. п. Что касается нормативно-методических документов, то эффективно использовать их в другой компании невозможно, так как организации имеют разные:

• организационную структуру и численность персонала;

• квалификацию и опыт сотрудников;

• критерии и алгоритмы принятия управленческих решений;

• культуру организации;

• прочее.

Чтобы скопировать бизнес компании, одного только комплекта нормативно-методических документов недостаточно. (Как нельзя, например, стать спортсменом за один день, просто повторяя систему тренировок чемпиона.)

Сейчас существуют системы информационной безопасности, одна из задач которых – предотвращать утечку информации.

Говоря о минусах регламентации, хочу отметить один интересный момент. Когда специалисты организации начинают формулировать и анализировать эти минусы, они обращают внимание не на проблемы, связанные с системой регламентации, а на риск внедрить ее не так, как хотелось бы. Это нормально. Более того, такой взгляд поможет руководителям оценить риски проекта и управлять им эффективнее.

5.3. Плюсы регламентации бизнес-процессов

Мы рассмотрели некоторые возможные минусы регламентации. Обратимся теперь к плюсам. К ним можно отнести:

На стадии внедрения системы регламентации:

• формализацию деятельности, обеспечение единого понимания требований сотрудниками;

• согласование взаимодействия структурных подразделений организации;

• выявление и устранение зон безответственности, пересечения ответственности;

• формирование предпосылок для делегирования полномочий и повышения эффективности управления;

• поиск и внедрение изменений, повышающих эффективность процессов.

На стадии эксплуатации системы регламентации:

• прозрачность бизнеса (для собственников и инвесторов);

• повышение эффективности управления (за счет возможности объективного контроля требований к деятельности сотрудников);

• снижение рисков, связанных с уходом руководителей и специалистов;

• повышение эффективности процессов подбора и обучения персонала;

• создание возможностей для аудита бизнес-процессов и запуска системы непрерывного совершенствования (цикла PDCA);

• создание предпосылок для последующей эффективной автоматизации бизнес-процессов;

• обеспечение возможности развития бизнеса (тиражирование опыта – открытие филиалов в регионах и т. п.).

5.3.1. Формализация деятельности, обеспечение единого понимания требований сотрудниками

По ходу регламентации процесса устанавливаются общие для всех (или некоторых) сотрудников требования к выполнению работы. Субъективные мнения и взгляды на порядок выполнения процесса заменяются формализованными и объективно контролируемыми требованиями. Сотрудникам становится комфортнее работать: они знают, что и когда от них может потребовать руководитель. У них есть информация, как в соответствии с требованиями организации выполнять работу.

5.3.2. Согласование взаимодействия структурных подразделений организации

При разработке регламентов приходится уточнять формы документов, сроки и условия их передачи между структурными подразделениями. Кроме того, приходится согласовывать требования с руководителями этих подразделений. В результате можно добиться лучшего взаимопонимания на межфункциональном уровне и согласовать взаимодействие, тем самым повышая его эффективность.

5.3.3. Выявление и устранение зон безответственности, пересечения ответственности

Описание процесса и последующая регламентация – отличные инструменты выявления и устранения зон безответственности или пересечения ответственности. Формализуя деятельность и назначая ответственных, можно определить те операции, контроль которых не осуществляется или осуществляется недостаточно.

5.3.4. Формирование предпосылок для делегирования полномочий и повышения эффективности управления

Когда последовательность операций процесса формализована и представлена в виде схемы, исполнителю понятно, что? нужно делать. Описание наиболее часто возникающих отклонений и порядка действий сотрудников в этих случаях – основа для делегирования полномочий. Руководство определяет, в каких ситуациях сотрудник должен самостоятельно действовать по утвержденной процедуре, а в каких сразу сообщить руководителю о критических отклонениях в процессе. Если деятельность не формализована, то делегирование полномочий затруднено или связано со значительными рисками.

5.3.5. Поиск и внедрение изменений, повышающих эффективность процессов

Регламентация не возможна без описания процесса. По ходу описания, как правило, выявляются определенные проблемы. Анализ их причин, разработка и выполнение мероприятий по их устранению повышают эффективность процессов. Иными словами, задача выполнить регламентацию неизбежно влечет за собой ту или иную реорганизацию процессов.

На стадии эксплуатации система регламентации процессов дает организации следующие плюсы.

5.3.6. Прозрачность бизнеса

Наличие системы процессов и базы актуальных регламентирующих документов по ним делает деятельность организации прозрачной для собственников и топ-менеджеров. Они имеют представление о том, чем именно занимается каждое структурное подразделение, с кем взаимодействует, за что конкретно отвечают руководители. Такая ситуация комфортна для руководителей, готовых работать в команде для достижения стратегических целей организации. Для менеджеров, преследующих исключительно личные цели, прозрачная ситуация некомфортна и вынуждает их покидать организацию.

5.3.7. Повышение эффективности управления

Регламентирующие документы по процессу дают возможность руководителю выполнять объективный контроль исполнения требований. Он может осуществляться:

• ежедневно – выборочный визуальный контроль соблюдения сотрудниками требований нормативно-методических документов по процессам;

• еженедельно – анализ показателей по процессам, контроль наличия и правильности заполнения документации по процессу, анализ результатов деятельности за неделю;

• ежеквартально (раз в полгода) – участие в аудите исполнения требований регламентирующей документации по процессу (проводят внутренние аудиторы организации);

• прочее.

5.3.8. Снижение рисков, связанных с уходом руководителей и специалистов

Во многих компаниях технология выполнения процессов хранится в головах сотрудников – на бумаге она не зафиксирована. Процессы выполняются, их результаты вполне приемлемы с точки зрения руководителей. Но существует риск, что при уходе из организации руководителей или ключевых специалистов процессы перестанут стабильно работать, возникнут проблемы с клиентами, возрастут затраты и т. п. Поэтому наличие комплекта актуальных нормативно-методических документов по процессам существенно снижает риск.

5.3.9. Повышение эффективности процессов подбора и обучения персонала

Один из полезных результатов регламентации процессов – возможность получать полное описание деятельности сотрудников. Например, в должностной инструкции можно указывать, в каких именно процессах участвует сотрудник, что делает, требования к срокам и т. п. Эту информацию можно представить в виде приложения к должностной инструкции (регламент работы сотрудника). Специалисты службы по управлению персоналом будут использовать такие документы для более эффективного подбора и последующего обучения персонала.

5.3.10. Создание возможностей для аудита бизнес-процессов и запуска системы непрерывного совершенствования (цикла PDCA)

Один из способов обеспечить актуальность и исполнение требований регламентирующих документов – внутренний аудит. Если регламентов нет либо они устарели, то смысл и возможность его проведения теряется. Напротив, регулярно проводимые аудиты помогают руководителям и сотрудникам эффективнее использовать регламенты, изменить отношение к работе по стандартам.

Наличие системы регламентации процессов (исполнение – контроль – актуализация/улучшение нормативно-методических документов) – один из факторов успешного внедрения цикла непрерывного совершенствования PDCA.

5.3.11. Создание предпосылок для последующей эффективной автоматизации бизнес-процессов

Если регламенты процессов постоянно контролируют и актуализируют, то их можно использовать при постановке задачи автоматизации. Нет ничего плохого в том, что графические схемы процессов в этих регламентах могут быть описаны простейшими средствами. Главное, что они структурированы и выполняются. Сотрудники понимают, что такое процессы, как они регламентируются и контролируются. Так гораздо проще перейти к использованию более сложных инструментов описания процессов с целью автоматизации, в частности начать использовать стандарт BPMN.

5.3.12. Обеспечение возможности развития бизнеса

Наличие актуальной регламентной базы облегчает тиражирование бизнеса при создании дочерних компаний, открытии новых филиалов в регионах. Конечно, одних регламентов мало, но это серьезное подспорье для руководителей, перед которыми поставлена задача создать новый филиал и т. п.

5.4. Система стандартизации бизнес-процессов

В компании среднего размера директор издал приказ, содержащий следующую фразу: «Рабочей группе в срок такой-то разработать порядок описания, регламентации и хранения бизнес-процессов». Регламенты предполагалось хранить как товар – на полке! К сожалению, в этой организации так и получилось: были разработаны десятки схем бизнес-процессов, затем с использованием утомительного ручного труда на базе этих схем подготовили и согласовали регламенты, а потом… сдали в архив на хранение. Как-то раз одного из начальников отдела этой компании спросили, как обстоят дела с процессным подходом. На что он ответил: «Его внедрили еще три года назад», – сделал кислую мину и сослался на комплект регламентов, который пылится на полках. Понятно, что разработанные регламенты фактически не работали.

Как добиться того, чтобы регламенты выполнения бизнес-процессов активно использовались и сотрудники работали по стандартам? Достаточно ли, например, заказать внешних консультантов, которые за несколько месяцев опишут бизнес-процессы и разработают соответствующие регламенты? Что получит в результате директор компании? Вероятнее всего, это будет толстая кипа бумаг, которые вряд ли начнут работать. Дело даже не в том, что регламенты могут оказаться плохими. Проблема в отсутствии системы, которая обеспечила бы не только разработку стандартов по бизнес-процессам, но и обучение персонала, контроль исполнения, своевременную актуализацию документов. Такую систему нельзя создать за один день, но ее можно целенаправленно строить в течение некоторого времени (один-два года).

5.4.1. Определение системы стандартизации бизнес-процессов

Сформулируем определение системы стандартизации (ее можно также называть системой регламентации) бизнес-процессов:

Комплекс процессов, методов, инструментов и элементов организационной структуры, обеспечивающий разработку, ввод в действие, контроль исполнения, поддержание в актуальном состоянии и своевременную отмену нормативно-методических документов компании.

Конечно, нормативно-методические документы бывают разные. Но основная их группа предназначена для регламентации деятельности, то есть бизнес-процессов.

Пример. Некоторые симптомы отсутствия порядка с регламентами на практике выглядят так:

• У вас в компании постоянный бардак при заказе или приемке товара, пересортица, другие ошибки, несоблюдение сроков и т. п.

• В разных кафе сети из одних и тех же продуктов, по одной и той же рецептуре получаются разные блюда – клиенты недоумевают (сравнивая ситуацию с незабвенным «Макдоналдсом»).

• Вы закупили дорогое импортное оборудование, но никто в организации не понимает, когда и как надо выполнять техническое обслуживание (ТО), и делают замену запчастей и ТО на глаз. Результат – поломки и простой дорогого импортного оборудования, купленного на кредитные деньги.

На рис. 5.4.1 представлены важнейшие элементы системы стандартизации бизнес-процессов.

Рассмотрим каждый их этих элементов, начиная с методов.

_{Рис. 5.4.1. Элементы системы стандартизации процессов}

^{ЖЦ НМД – жизненный цикл нормативно-методических документов организации.}

5.4.2. Методы системы

Среди документов (в рамках системы стандартизации) центральное место занимает методика моделирования (стандарт описания) процессов. Она включает в себя описание подходов к созданию моделей (описаний) процессов организации. Поскольку сейчас широко распространены и доступны сре?ды моделирования бизнес-процессов, такая методика должна учитывать возможности и ограничения выбранного программного продукта (MS Visio, Business Studio, Casewise, ARIS и др.)^[108]. В практике бизнес-моделирования документ, содержащий требования по использованию программного продукта, часто называют «соглашение по моделированию».

Второй важнейший документ – методика управления изменениями модели организации. В нем вы найдете требования, которые нужно исполнять при внесении изменений в модель организации. Например, нужно частично изменить (дополнить) структуру бизнес-процессов, переназначить исполнителей процессов в случае изменения организационной структуры и т. п.

Следующий документ – процедура (методика) управления нормативно-методическими документами (НМД) внутреннего происхождения. Он устанавливает все необходимые требования по управлению жизненным циклом нормативных документов (регламентов, стандартов по бизнес-процессам и т. д.), в том числе:

• порядок разработки и согласования НМД;

• порядок ввода НМД в действие (в том числе кодирование НМД);

• порядок выдачи копий НМД сотрудникам;

• порядок актуализации НМД;

• порядок отмены действия НМД;

• прочее.

Если в организации отсутствует процедура управления НМД, то зачастую база документов находится в хаотичном состоянии, возникает путаница с версиями, документы теряются.

Документированные методы контроля исполнения требований стандартов по бизнес-процессам нужны для того, чтобы руководители и сотрудники службы внутреннего аудита могли быстро и эффективно контролировать исполнение требований, сформулированных в регламентах по бизнес-процессам. Одно из возможных решений – описание методов контроля в тексте самих регламентов. В этом случае проверяющий открывает соответствующий раздел и следует инструкции по выполнению контроля. Суть состоит в том, что мы определяем контрольные точки (где есть смысл проверять исполнение требований) внутри процесса.

Процедура внутреннего аудита содержит требования по его организации и проведению. В том числе в ней указано, когда и каким образом сотрудники отдела внутреннего аудита должны контролировать исполнение требований стандартов.

Полезно так же методически проработать организационную систему стимулирования по созданию у сотрудников мотивации исполнять требования регламентов по бизнес-процессам.

Еще один элемент – методические материалы по обучению сотрудников. Они могут быть универсальными или создаваться на базе конкретных регламентов.

5.4.3. Инструменты системы

Для создания системы стандартизации бизнес-процессов можно использовать различные программные инструменты. В первую очередь речь идет о среде бизнес-моделирования (Business Process Architecture или Enterprise Architecture), при помощи которой можно описывать:

• бизнес-процессы;

• подразделения и должности;

• документы и информацию;

• прочее.

Очень значима в современной среде моделирования возможность формировать регламентирующие документы: регламенты выполнения процессов (инструкции по выполнению бизнес-процессов), положения о подразделениях, должностные инструкции и т. д. Благодаря этому в среде моделирования хранится существенная часть информации о деятельности компании. Фактически она является ядром системы стандартизации процессов. Но если ее использовать изолированно, без остальных элементов, представленных на рис. 5.4.1, эффект будет незначительным.

Пример. Описание бизнес-процессов (ситуация, которая, надеюсь, будет становиться все менее типичной): руководители компании собрались и решили внедрять процессный подход. В итоге все свелось к покупке программного обеспечения. Наняли аналитика «ценою подешевле». Потом он в темной дальней комнате три месяца рисовал модели процессов. Получилось два тома по 100 страниц каждый. Генеральный директор три дня подержал у себя на столе этот отчет, потом отдал заму, тот – своему заму и т. д. Через два месяца всем стало ясно, что материал никуда не годится. Аналитика уволили, а у генерального директора появился устойчивый негативный рефлекс на словосочетание «процессный поход». Безусловно, к реальному процессному управлению ситуация не имеет никакого отношения.

Многие компании, использующие среду бизнес-моделирования, размещают полученные модели процессов на интранет-сервере (внутреннем веб-портале). У сотрудников появляется возможность просматривать схемы процессов, переходя по гиперссылкам с уровня на уровень и от процесса к процессу. Такая возможность весьма удобна для быстрого поиска нужной регламентирующей информации и понимания бизнес-процессов организации в целом.

Выгруженные из среды бизнес-моделирования проекты нормативных документов необходимо провести через процедуру согласования, утверждения и ввода в действие. Оригиналы этих документов нужно хранить. В этом деле должен быть порядок. Можно, конечно, хранить документы в виде файлов на сервере или в специально разработанном для этого электронном архиве компании. Но эффективнее использовать современную систему электронного документооборота. Тем более что в нее можно экспортировать документы прямо из среды моделирования.

5.4.4. Процессы системы

Лучшие методики и программные продукты бесполезны, если не отлажены реальные процессы, которые их используют. Поэтому при внедрении системы стандартизации процессов наряду с разработкой методик и настройкой инструментов нужно запускать и отлаживать соответствующие бизнес-процессы:

• управление системой стандартизации процессов;

• описание процессов;

• регламентация процессов;

• контроль исполнения процессов;

• управление изменениями;

• управление жизненным циклом НМД;

• внутренний аудит;

• обучение персонала (в части ввода в действие новых регламентов по процессам);

• стимулирование персонала (в части создания культуры работы по стандартам);

• прочее.

В зависимости от подхода принимать участие в данных процессах могут сотрудники различных подразделений, в том числе отдела организационного развития, менеджмента качества, внутреннего аудита и т. п. Руководители и специалисты подразделений – это обязательные участники процессов описания и регламентации.

5.4.5. Персонал, необходимый для работы системы

Управление системой стандартизации может осуществлять руководитель отдела организационного развития. В зависимости от размера компании численность его сотрудников варьируется: один-два человека – для малой, три-пять – для средней и шесть-девять – для крупной организации. Не стоит думать, что именно они должны выполнять всю работу по стандартизации. Для создания культуры работы по стандартам необходимо привлекать к работе по описанию, анализу, оптимизации и стандартизации бизнес-процессов руководителей и специалистов линейных подразделений.

5.4.6. Развитие системы

По ходу создания системы стандартизации процессов некоторые ее элементы могут быть созданы и действовать, но оставаться при этом не закрепленными в документах. В этом нет большой беды. Главное, чтобы нужные элементы присутствовали в системе. При необходимости их в любой момент можно задокументировать (то есть закрепить в стандартах).

Система стандартизации бизнес-процессов создает и поддерживает в организации культуру работы по стандартам, что повышает эффективность и получение лучших коммерческих результатов.

5.5. Объекты регламентации и структура нормативно-методических документов организации

Рассмотрим объекты регламентации в компании. Удобно структурировать НМД по типам объектов, а именно по элементам структуры и процессам.

5.5.1. Структурные НМД

К структурным элементам можно отнести:

• подразделения (департаменты, службы, отделы, группы, команды и т. п.);

• должности и роли;

• оборудование;

• прочее.

Наглядные примеры структурных документов – положение о подразделении и должностная инструкция сотрудника.

Компании нужны и структурные, и процессные документы – при регламентации деятельности невозможно обойтись какой-то одной из этих групп.

5.5.2. Процессные НМД

Процессные документы предназначены для регламентации бизнес-процессов различного уровня и масштаба. Примеры процессных документов – инструкция по выполнению процесса, регламент выполнения процесса, документированная процедура и т. п.

Рассмотрим структуру процессных документов небольшой организации (например, торговой компании, ресторана или небольшого производства), представленную на рис. 5.5.1.

_{Рис. 5.5.1. Структура НМД по процессам для небольшой компании}

В этой компании на верхнем уровне определено 12 процессов. Затем каждый процесс декомпозировали на 8–10 подпроцессов – процессов второго уровня. В свою очередь эти процессы были описаны в виде кросс-функциональных схем формата А4 (такой формат удобен при создании регламентирующих документов). Документ, содержащий эту схему и текстовое описание соответствующих операций, на рис. 5.5.1 назван «Регламентом (инструкцией) выполнения процесса». Форма документа может варьироваться в зависимости от задач.

Дорожки на кросс-функциональных схемах соответствуют определенным должностям в организации. Поэтому для каждой должности можно определить, в каких процессах участвует занимающий ее сотрудник, то есть составить регламент его работы. В нем в виде таблицы представлены операции из всех процессов, в которых занят этот человек. Группируются операции по различным параметрам, например по частотности: выполняется ежедневно, еженедельно и т. п.

На рис. 5.5.2 структура регламентирующей документации представлена в более полном виде. Условно показаны три уровня: 1) уровень компании в целом; 2) уровень процессов и подразделений; 3) операционный уровень (процессы типа Work Flow).

На первом уровне следует обратить внимание на процесс управления компанией. Это целая группа процессов, их участники – топ-менеджеры и специалисты, которые непосредственно с ними взаимодействуют (аналитики, маркетологи, советники). В небольшой организации для генерального директора можно разработать и утвердить регламент управления компанией. Для средних и крупных организаций такой документ слишком сложен – лучше разрабатывать комплект взаимосвязанных регламентов для важнейших аспектов управления, в том числе:

• разработки, утверждения и контроля исполнения стратегии;

• разработки и утверждения бизнес-плана;

• разработки, утверждения и контроля исполнения плана инвестиционного проекта;

• формирования операционного плана компании на период (месяц, квартал);

• бюджетирования;

• ценообразования;

• прочее.

Некоторые документы, регламентирующие управление компанией в целом, представлены на рис. 5.5.2.

_{Рис. 5.5.2. Структура НМД компании}

Рассмотрим «Уровень процессов и подразделений» на рис. 5.5.2. На нем возникает практическая необходимость описывать и регламентировать процессы, выполняемые как внутри структурных подразделений, так и на межфункциональном уровне.

Процессы можно регламентировать на нескольких уровнях детализации.

5.5.3. Одноуровневый регламент выполнения процесса

Рассмотрим так называемый одноуровневый регламент выполнения процесса. Объект регламентации для этого документа:

Процесс 1:

1. операция 1.1;

2. операция 1.2;

3. …

n. операция 1.n.

Уровень, на котором рассматривается процесс 1, – относительный, а не абсолютный, то есть одноуровневый регламент может содержать описание процессных групп в рамках одной категории, процессов в рамках процессной группы, операции в рамках процесса (этот вариант используется чаще всего).

Для каждой операции нужно указать исполнителя, текстовое описание, входы/выходы, требования к срокам и другую необходимую информацию (в одной или нескольких таблицах). Нужно включить в документ графическую схему, отображающую все указанные операции. Полученный документ можно называть «Регламент процесса на одном уровне (одноуровневый регламент)» или «Инструкция по выполнению процесса».

Шаблон одноуровневого регламента представлен в приложении 2.

Предложенный шаблон одноуровневого регламента весьма прост, но имеет некоторые особенности.

В частности, в разделе 5 есть информация о целях и показателях, которые должны использоваться для управления процессом. Отмечу, что плановые и фактические значения показателей в регламенте не указываются. Они должны включаться в соответствующие плановые и отчетные документы по процессу.

В разделе 6 содержится информация о так называемых методах контроля. Строго говоря, контроль исполнения требований регламента предполагает выполнение некоторых процессов. Но для упрощения системы и сокращения числа регламентирующих документов в данном случае процессы контроля детально (в виде схем, подробных инструкций) не прописываются. Дается их краткое описание (в таблице). Такое решение, как, впрочем, и любое другое имеет свои преимущества и недостатки. К преимуществам, с моей точки зрения, можно отнести то, что владелец процесса, его руководитель, внутренний аудитор имеют информацию о том, где и как нужно проверять исполнение требований регламента. Информация о методах контроля представлена именно в том документе, который и нужно проверять.

Методы контроля следует привязывать к наиболее важным этапам процесса. Возможны методы контроля, предполагающие анализ результатов выполнения процесса в целом и т. п.

Еще раз подчеркну, что, описывая процесс и разрабатывая его регламент, мы определяем:

• цели и показатели контроля результативности и эффективности процесса;

• методы контроля исполнения требований.

При необходимости шаблон регламента процесса можно дополнить нужными разделами.

5.5.4. Двухуровневый регламент выполнения процесса

Объект регламентации двухуровневого регламента – это:

Процесс 1.

Процесс 1.1:

1. операция 1.1.1.;

2. операция 1.1.2;

3. …

n. операция 1.1.n.

Процесс 1.2:

1. операция 1.2.1;

2. операция 1.2.2;

3. …

n. операция 1.2.n.

Процесс 1.m:

1. операция 1.m.1;

2. операция 1.m.2;

3. …

n. операция 1.m.n.

Описание операций может быть представлено в виде таблиц. Для каждого процесса на уровне х. х (процесс 1.2) приводят схему процесса. Для процесса в целом также представляют общую графическую схему. Документ на этот процесс можно называть «Регламент процесса на двух уровнях (двухуровневый регламент)».

Можно разработать и трехуровневый^[109], и даже четырехуровневый регламент. Но эти документы будут слишком объемными и сложными для использования.

Возникает вопрос: нужно ли делать одно– и двухуровневые регламенты для одной и той же деятельности? Все зависит от ситуации. Если регламентная база отсутствует (или находится в запущенном состоянии), то для начала разрабатывается система процессов (иерархический справочник процессов компании). Описание начинают с операционного (по сути, нижнего) уровня. При этом получаются одноуровневые регламенты, которые нужно своевременно утверждать и вводить в действие. Представим себе, что в течение некоторого времени многие процессы были описаны на уровне операций в виде одноуровневых регламентов. В данной ситуации вместо десятка одноуровневых сто?ит разработать и ввести в действие один двухуровневый регламент. Также удобно сформировать двухуровневый регламент для сквозного процесса, содержащего несколько подпроцессов.

5.5.5. Положение о подразделении и должностная инструкция

Кроме регламентов процессов, полезно разрабатывать положения о подразделениях. При внедрении процессного управления эти положения можно создать, выявляя те процессы, в которых участвует соответствующее подразделение.

На уровне сотрудников (рис. 5.5.2) показаны инструкции по выполнению процессов (операционные карты). Это могут быть документы типа одноуровневого регламента или более детальные формы процессного представления деятельности. Например, в операционной карте на одном-двух листах показаны все действия, выполняемые отдельным сотрудником в рамках процесса более высокого уровня.

Обязательные документы на этом уровне – должностные инструкции, в приложения к которым могут включаться все операции, выполняемые соответствующей должностью в процессах организации.

Шаблоны положения о подразделении и должностной инструкции – в приложениях 3 и 4. Данные шаблоны нормативных документов построены таким образом, что могут быть полностью выгружены из среды моделирования бизнес-процессов Business Studio.

5.6. Процедура разработки и согласования НМД

Рассмотрим процедуру разработки, согласования, утверждения и ввода в действие НМД компании. Содержание этой процедуры зависит от следующих факторов:

• размера организации (по численности сотрудников, сложности организационной структуры);

• подхода к регламентации процессов (упрощенный, стандартный, сложный);

• наличия ресурсов, выделяемых на управление жизненным циклом НМД (персонал, инфраструктура);

• наличия системы электронного документооборота;

• прочее.

Далее рассмотрим процедуру, которая используется в небольших и средних по величине организациях. Использование системы электронного документооборота в данном случае не предполагается^[110].

Титульный лист процедуры не приводится. Оглавление опущено. Комментарии к тексту приводятся курсивом.

ПРОЦЕДУРА УПРАВЛЕНИЯ НМД

ВНУТРЕННЕГО ПРОИСХОЖДЕНИЯ

5.6.1. Термины и определения

В процедуре используются следующие термины и определения (табл. 5.6.1):

_{Таблица 5.6.1. Термины и определения}

Список терминов может быть расширен и переработан с учетом специфики конкретной компании.

5.6.2. Нормативные ссылки

При разработке этой процедуры использовались следующие документы внешнего происхождения (табл. 5.6.2):

_{Таблица 5.6.2. Документы внешнего происхождения}

Список внешних НМД приводится в качестве примера.

При разработке этой документированной процедуры использовались следующие документы внутреннего происхождения (табл. 5.6.3):

_{Таблица 5.6.3. Документы внутреннего происхождения}

Могут приводиться ссылки на НМД компании и внешние нормативные документы, которые были использованы при разработке процедуры.

5.6.3. Структура НМД

Структура НМД, используемая в организации, представлена в табл. 5.6.4.

_{Таблица 5.6.4. Структура НМД организации}

Основными факторами, определяющими необходимость разработки/пересмотра (актуализации) НМД, могут быть:

• усовершенствование системы процессов организации;

• изменение структуры организации, перераспределение ответственности руководителей организации;

• изменение технологии работы;

• выявленное отсутствие необходимого нормативно-методического документа;

• усовершенствование системы НМД организации;

• результаты внутреннего или внешнего аудита системы процессов организации;

• указания руководителей, утверждающих документы;

• другие факторы, определяющие необходимость разработки/пересмотра (актуализации) документации по результатам текущей деятельности организации.

Это поясняющий текст, его можно убрать из реальной процедуры.

5.6.4. Инициация разработки НМД

Порядок инициации разработки НМД представлен на рис. 5.6.1. Инициаторами разработки НМД могут быть руководители организации до уровня отделов. При возникновении потребности в НМД инициатор разработки готовит обоснование необходимости его разработки в виде служебной записки и передает ее генеральному директору (ГД).

_{Рис. 5.6.1. Инициация разработки НМД}

Кто может являться инициатором разработки НМД? Это зависит от размера организации и сложности структуры НМД. Как правило, инициатором разработки должен быть руководитель структурного подразделения или ведущий специалист.

ГД проверяет обоснованность заявки. Если заявка недостаточно обоснованна, то ГД уведомляет об этом инициатора в устной форме. Если необходимо совещание по обсуждению целесообразности разработки НМД, то ГД организует его.

Замечу: если в компании внедрена система электронного документооборота, то практически все действия, указанные в настоящей процедуре, могут быть автоматизированы. Для этого используют типовые маршруты и соответствующие задания исполнителям.

При необходимости ГД проводит совещание по обсуждению целесообразности разработки НМД. В совещании принимают участие инициатор разработки и согласующие руководители. По итогам совещания ГД принимает решение о целесообразности разработки НМД. Если это нецелесообразно, то ГД уведомляет инициатора разработки в устной форме (или по системе электронного документооборота)^[111].

Если разработка НМД полезна, ГД визирует служебную записку на разработку НМД и передает ее помощнику ГД.

Разработка нормативно-методического документа типа «регламент» стоит дорого. Расчеты показывают, что одноуровневый регламент обходится в сумму от 20–30 до 50–60 тыс. рублей в зависимости от сложности описываемого процесса. При расчете принимались во внимание зарплата бизнес-аналитика, стоимость его рабочего места (инфраструктура), затраты на обеспечение связью и поддержание программных продуктов, стоимость рабочего времени сотрудников, которые были вовлечены в разработку и согласование документа.

Помощник ГД готовит проект распоряжения о разработке НМД и передает ГД.

Помощник ГД в данном случае отвечает за документооборот в организации. В более крупной компании это может быть специализированное подразделение (канцелярия, архив и т. п.).

ГД подписывает распоряжение о разработке/пересмотре НМД и передает своему помощнику.

Помощник ГД регистрирует распоряжение, ставит его на контроль и передает копию распоряжения ответственному разработчику (ОР). ОР получает копию распоряжения и приступает к разработке НМД.

Ответственный разработчик документа – это руководитель подразделения или ведущий специалист, который в соответствии с распоряжением обязан разработать нормативный документ за отведенное время. Хотя ответственному разработчику может помогать квалифицированный бизнес-аналитик, ответственность за разработку, контроль исполнения и последующую актуализацию документа целиком возлагается на ответственного разработчика. То есть ответственными разработчиками целесообразно назначать руководителей подразделений, которые потом будут оперативно контролировать исполнение требований соответствующих нормативных документов.

5.6.5. Разработка и презентация первой версии НМД

Ответственный разработчик готовит первую версию НМД и отправляет ее в электронном виде согласующим руководителям и помощнику ГД (рис. 5.6.2).

_{Рис. 5.6.2. Разработка и презентация первой версии НМД}

Помощник ГД помещает эту версию НМД в электронный архив. Название файла должно содержать название документа (допускаются незначительные сокращения), статус (проект), дату и номер версии.

Согласующие руководители и инициатор разработки НМД рассматривают проект НМД в течение двух рабочих дней.

Ответственный разработчик организует и проводит презентацию проекта НМД для согласующих руководителей и инициатора разработки.

Презентация нужна, если документ новый и сложный. Для новых версий уже существующих документов и/или при незначительных изменениях ее можно не проводить. На презентации рассматривается структура документа и раскрываются основные моменты его содержания. Затем проходит обсуждение проекта документа. Во время презентации согласующие руководители получают интересующую их информацию по документу, задают вопросы и т. п. В результате им проще формулировать замечания к документу, которые должны быть представлены ОР.

Согласующие руководители и инициатор разработки готовят и представляют ОР замечания по проекту НМД в течение трех рабочих дней после проведения презентации. ОР взаимодействует с согласующими руководителями и инициатором разработки в рабочем порядке (устно, по e-mail).

Эта работа может проводиться при помощи системы электронного документооборота, или BPMS.

Ответственный разработчик получает замечания, формирует сводку замечаний.

Ответственный разработчик формирует вторую версию проекта НМД и вносит в нее необходимые изменения, предоставляет ее помощнику ГД, проверяет необходимость проведения совещания по согласованию проекта НМД. Совещание проводится в случае, если замечания по НМД противоречат друг другу и не могут быть учтены одновременно.

Помощник ГД помещает вторую версию НМД в электронный архив.

5.6.6. Согласование проекта НМД

При необходимости ОР организует и проводит совещание по согласованию проекта НМД (рис. 5.6.3). Согласующие руководители и инициатор разработки принимают в нем участие.

_{Рис. 5.6.3. Согласование проекта НМД}

Согласование версии НМД всегда вызывает вопросы. Чем больше согласующих лиц, тем дольше и сложнее проходит этот этап.

Пример. Двадцать шесть версий проекта НМД

В крупной известной компании в рамках одного из проектов нужно было подготовить несколько десятков регламентирующих документов. Каждый документ представлял собой регламент объемом от 12 до 30 и более страниц.

Как правило, в список согласующих лиц включались шесть-восемь руководителей подразделений, один-два специалиста по организационному развитию и начальник отдела организационного развития.

Формальной процедуры согласования проектов документов в компании не было. Все делалось «на коленке» – файлы отправлялись через Outlook с сопроводительным письмом в произвольной форме. Затем разработчикам приходилось буквально отлавливать менеджеров на их рабочих местах. Большинство из них явно проявляло бурную активность: кучи документов, перегородки, облепленные желтыми и красными стикерами, постоянные звонки и электронные письма. Приходилось ловить момент, когда менеджер не говорит по телефону и не отправляет e-mail, и вежливо напоминать про такой-то документ и необходимость его согласования. Ответ, как правило, был один: «Приходите завтра, а лучше через неделю. А кстати, разве Иванов (Петров, Сидоров…) не может его посмотреть и согласовать?»

У специалистов по организационному развитию была своя «фишка». Получат документ на согласование, пробегут глазами пару страниц, сделают замечания и отправят разработчику. В следующей версии читаются уже третья-пятая страницы и т. д. Когда появляется четвертая или пятая версия, специалист забывает, какие изменения внес на первой или второй странице, и делает новые правки и замечания и т. д.

Впечатляющий итог таких согласований – от 26 до 40 версий документов – наверняка не предел для этой компании!

Пример. «Оптимизация» процесса на основе обобщения лучшего опыта

Крупная компания имела несколько филиалов в разных городах. Руководство приняло решение стандартизировать деятельность всех филиалов. Для этого был выбран ряд процессов, в том числе процесс управления договорами.

Специально созданная рабочая группа проанализировала этот процесс в трех филиалах и выявила лучшие практики работы. Каждый филиал имел свои положительные и отрицательные особенности. По итогам был разработан проект регламента управления договорами, который объединял все лучшие наработки. Приступили к согласованию документа.

В процессе согласования со стороны менеджмента филиалов возникали критические замечания. Разработчикам многое пришлось убирать. После двенадцати итераций документ стал весьма формальным, зато устраивал всех.

Однако кто-то из руководителей филиалов пролоббировал следующее решение головного офиса: каждый филиал имеет право адаптировать общий регламент к своим конкретным условиям. В результате регламенты были откорректированы настолько, что новыми остались лишь две вещи: структура документа и его обложка.

Формализованная процедура согласования НМД, четкие требования по формулировке замечаний, учету замечаний и т. п. необходимы, чтобы снизить бесконечное количество согласований, существующее в современных компаниях.

В рассматриваемой нами процедуре управления НМД должно быть три, максимум четыре итерации документа.

По итогам совещания ОР готовит протокол. Если на совещании не удается прийти к общему мнению по формулировке спорных пунктов документа, протокол передается ГД. В протоколе обязательно указывают пункты, по которым не удалось достичь соглашения.

ГД принимает решение по редакции спорных пунктов и передает его ОР (в электронном виде).

Не стоит чересчур нагружать ГД такого рода проблемами. Однако рассматриваемая процедура предназначается для небольшой и средней компании. Если организация крупная и/или документов много, лучше рассмотреть возможность согласования и утверждения НМД различными должностными лицами, например по направлениям деятельности.

ОР вносит изменения в проект НМД и передает третью версию проекта НМД помощнику ГД.

Помощник ГД помещает ее в электронный архив.

После формирования третьей версии НМД (или второй, если совещание по согласованию НМД не требуется) ОР проверяет потребность в тестировании. Если оно необходимо, то ОР приступает к его организации. Если в тестировании нет надобности, то ОР уведомляет помощника ГД, который приступает к вводу НМД в действие.

5.6.7. Тестирование проекта НМД

Ответственный разработчик готовит план тестирования проекта НМД и передает его ГД (см. рис. 5.6.4).

_{Рис. 5.6.4. Тестирование проекта НМД}

ГД утверждает план тестирования НМД.

ОР осуществляет тестирование проекта НМД. В нем принимают участие согласующие руководители и инициатор разработки НМД. Цель тестирования – выявление недостатков в проекте НМД и определение необходимых корректировок.

Тестирование можно также назвать пробной эксплуатацией на пилотном процессе. Пробная эксплуатация нужна, чтобы проверить адекватность требований регламента. Если в регламенте содержатся некорректные, сложно выполнимые или противоречивые требования, это может выявить именно тестирование. Его результаты используют для доводки регламента до рабочего состояния. Безусловно, не все проекты НМД требуют тестирования, например, новые версии уже существующих документов, включающие незначительные изменения.

По итогам тестирования ОР формирует третью или четвертую версию проекта НМД и предоставляет ее помощнику ГД, согласующим руководителям и инициатору разработки НМД.

Помощник ГД помещает третью/четвертую версию НМД в электронный архив.

Согласующие руководители и инициатор разработки НМД согласуют изменения в проекте НГД по результатам тестирования (по электронной почте).

При необходимости ОР вносит изменения в проект НМД и передает его помощнику ГД на проверку соответствия требованиям по оформлению документа.

5.6.8. Ввод НМД в действие

Помощник ГД выполняет контроль НМД на соответствие стандартам (требованиям по оформлению) (см. рис. 5.6.5). Если есть замечания, проект НМД возвращается ОР на доработку.

_{Рис. 5.6.5. Ввод НМД в действие}

Это, можно сказать, последняя вычитка проекта НМД. Помощник ГД как лицо, ответственное за жизненный цикл проекта в компании, на этом этапе проверяет документ на соответствие требованиям по оформлению.

Если в организации используется среда бизнес-моделирования, то код и другие данные регламента заносятся в карточку соответствующего процесса (подразделения, должности для положений или должностных инструкций).

Помощник ГД присваивает НМД код в соответствии с требованиями настоящей процедуры.

Помощник ГД готовит проект приказа ГД о вводе НМД в действие и передает его ГД.

ГД подписывает приказ о вводе НМД в действие.

Помощник ГД регистрирует приказ, заполняет паспорт документа, распечатывает НМД и ставит на титульном листе штамп «Контрольный экземпляр».

Штамп может быть любого цвета. Важно, чтобы бумажный оригинал документа отличался от обычных распечаток. Также важно обеспечить хранение оригиналов НМД в соответствующих папках в архиве.

Помощник ГД собирает подписи на оригинале НМД: подпись ГД «Утверждаю» на титульном листе и подписи согласующих руководителей.

Если в компании используется система электронного документооборота, то на новый НМД заводится регистрационно-контрольная карточка, содержание которой учитывает тип НМД. Проект документа загружается в базу системы (или помещается в защищенное файловое хранилище). Если в системе реализован механизм ЭЦП^[112], то ГД может утвердить документ прямо в электронной форме (тип ЭЦП «утверждает»), а соответствующий руководитель – согласовать его (тип ЭЦП «согласует»).

Помощник ГД уведомляет сотрудников организации по e-mail о вводе НМД в действие. Если нужно, он собирает подписи сотрудников на НМД (например, на должностной инструкции).

Помощник ГД сканирует титульный лист НМД с подписью ГД, лист с подписями согласующих лиц и лист с подписями других сотрудников (если имеется)^[113]. Осуществляет регистрацию НМД в электронном журнале учета. Помещает НМД в архив в электронной форме. Выкладывает на сервер организации файл НМД в режиме «Только чтение». Помещает контрольный экземпляр НМД в бумажной форме в архив организации. Вносит НМД в график периодического контроля и актуализации.

5.6.9. Хранение и выдача учтенных копий НМД

При необходимости в использовании бумажной копии действующего НМД сотрудник организации направляет помощнику ГД запрос по электронной почте.

Помощник ГД распечатывает НМД на желтой бумаге и уведомляет сотрудника о готовности документа.

Почему именно на желтой, ведь это не пресса? Дело в том, что столы сотрудников подчас завалены разными документами, в том числе нормативными. Чтобы официально зарегистрированные копии НМД бросались в глаза, их надо каким-то образом маркировать. Например, распечатать на желтой бумаге или поставить штамп «Копия» красного цвета.

Когда сотрудник организации приходит забрать копию НМД, помощник ГД фиксирует факт передачи бумажной копии в электронном журнале выдачи учтенных копий.

Бумажная копия НМД выдается только после учета в журнале (рис. 5.6.6).

Сотрудник использует бумажную копию НМД до тех пор, пока не получит по электронной почте уведомление об отмене/пересмотре НМД. При получении такого уведомления сотрудник обязан в течение трех рабочих дней уничтожить бумажную копию НМД. Если при проведении внутреннего аудита выявится факт использования неучтенных копий НМД или копий НМД, которые отменены/пересмотрены, сотрудник организации лишается премии или других бонусов по решению ГД.

_{Рис. 5.6.6. Выдача учтенных копий НМД}

Лучше сразу прописать штрафные санкции по отношению к сотруднику, допустившему наличие устаревших версий НМД на своем рабочем месте и/или жестком диске персонального компьютера. Это, например, может быть лишение месячной или квартальной премии в размере от 25 %.

Все НМД организации хранятся:

• в электронном архиве на сервере организации;

• в бумажном виде на белой бумаге с красной печатью «Контрольный экземпляр» в архиве организации.

Бумажные оригиналы НМД хранятся в архиве организации в нумерованных папках. Для каждой формируется лист «Содержание».

Также должна быть установлена номенклатура дел – систематизированный перечень заголовков дел, заводимых в организации, с указанием сроков их хранения, оформленный в установленном порядке. Иными словами, номенклатура дел – это список пронумерованных папок^[114], в которых хранятся документы. На обложку (корешок) заносят наименование структурного подразделения, название дела, его индекс, календарный год и срок хранения. На внутренней стороне обложки помещается опись документов, содержащихся в деле. Более подробное описание работы с номенклатурой дел организации и подразделений выходит за рамки моей книги.

Ответственность за ведение электронного и бумажного архива НМД несет помощник ГД.

Все НМД организации контролируемы. Это означает, что их выпуск, распределение, использование, изменение, хранение и уничтожение копий предыдущих версий проверяют ГД, его помощник и внутренние аудиторы.

Возможно, такое требование покажется слишком жестким, но по-другому работать с НМД невозможно. Если четко не отслеживать жизненный цикл по каждому НМД, через некоторое время в организации возникнет бумажный хаос.

Руководители компании могут иметь на своих рабочих местах папки документов, в которых находятся бумажные копии НМД. Каждая папка должна иметь идентификаторы принадлежности к структурному подразделению и лист с перечнем хранящихся в ней НМД («Содержание»)^[115]. При замене НМД лист с перечнем нужно также заменить на новый, содержащий актуальную информацию. Папки документов нумеруются. Список папок с обязательным указанием ответственного находится у помощника ГД. Это контролируемый документ. Папки документов хранятся у ответственных лиц, контролирующих их содержание. Ответственные за папки назначаются распоряжением директора. Наличие бумажных копий НМД разрешено, но не поощряется.

Хранение электронных копий НМД на компьютерах сотрудников организации запрещено. При необходимости персонал пользуется электронными версиями, размещенными на сервере компании. Документы просматриваются в режиме «Только чтение» без возможности копирования на компьютер сотрудника.

Безусловно, жизнь вносит свои коррективы. В компании может не быть сервера, доступного для всех сотрудников, связь может оказаться некачественной, сотрудники могут находиться в командировке и т. п. Эти факторы стоит принимать во внимание при разработке процедуры управления НМД в конкретной организации.

НМД могут быть переданы за пределы организации только с разрешения ГД. При передаче копии на нее ставится синий штамп «Для информации» (то есть документ не контролируется).

Вопрос защиты информации – это отдельная и сложная тема. Сейчас есть специализированные программные продукты, которые комплексно решают вопрос информационной безопасности в компании.

Отмененный/пересмотренный НМД (с синей печатью «Отменен/Пересмотрен» на титульном листе) может храниться в архиве организации для информационных и методических целей отдельно от действующих документов. В электронном виде отмененные/пересмотренные НМД лежат на сервере компании в отдельном каталоге. Их хранение в электронном виде на компьютерах сотрудников запрещено.

Проекты НМД хранятся в отдельном каталоге на сервере организации.

Не реже раза в месяц помощник ГД осуществляет резервное копирование электронной базы НМД:

• в отдельную область жесткого диска сервера компании;

• на DVD и т. п. (зависит от решения IT-директора или менеджера).

5.6.10. Контроль исполнения НМД

Контроль и актуализация НМД проводится со следующей периодичностью (табл. 5.6.5).

_{Таблица 5.6.5. Периодичность контроля и актуализации НМД}

Состав работ по контролю/актуализации НМД представлен на рис. 5.6.7. За две недели до планового срока контроля (аудита исполнения требований НМД) помощник ГД уведомляет ОР, внутреннего аудитора, руководителей подразделений, которые обязаны контролировать исполнение требований НМД. Помощник ГД назначает дату контроля НМД.

_{Рис. 5.6.7. Контроль исполнения НМД}

Раздел по осуществлению контроля исполнения требований НМД лучше всего рассматривать и корректировать исходя из наличия ресурса сотрудников, которые могут проводить внутренний аудит в компании.

Требования по контролю НМД могут быть представлены не в рассматриваемой процедуре, а в процедуре выполнения внутренних аудитов организации.

Указанные выше лица готовятся к аудиту исполнения требований НМД.

Внутренний аудитор проводит аудит исполнения требований НМД. В нем участвуют ответственный разработчик НМД и руководители подразделений.

Дополнительно к контролю исполнения требований НМД при проведении аудита внутренний аудитор обязан выявлять случаи нарушения процедуры:

• использование сотрудниками бумажных копий НМД, распечатанных на бумаге любого цвета, кроме желтого;

• использование сотрудниками бумажных копий устаревших версий НМД;

• использование сотрудниками электронных копий НМД, размещенных на их рабочих компьютерах.

В данном случае внутренний аудитор осуществляет аудит соответствия. Но одновременно он может выполнять аудит эффективности процесса. Важно не только контролировать формальное исполнение требований стандартов, но и выявлять причины снижения результативности деятельности.

Внутренний аудитор готовит отчет по результатам аудита. В отчете указываются выявленные нарушения и их причины (обязательно), приводятся рекомендации по корректировке (актуализации) НМД. Отчет по аудиту передается ГД.

ГД рассматривает отчет по результатам аудита и принимает решение оставить НМД без изменений, пересмотреть или отменить НМД. О своем решении ГД уведомляет ОР, внутреннего аудитора и руководителя подразделения.

ГД в одном приказе отменяет действие устаревшей версии НМД и вводит в действие новую версию. Помощник ГД выполняет процесс отмены НМД и необходимые действия по вводу новой версии НМД.

5.6.11. Отмена НМД

Помощник ГД получает от шефа информацию об отмене НМД и готовит соответствующий проект приказа (рис. 5.6.8).

_{Рис. 5.6.8. Отмена действия НМД}

ГД утверждает проект приказа об отмене НМД. В приказе об отмене устаревшей версии может содержаться информация о вводе в действие новой версии НМД.

Помощник ГД регистрирует приказ ГД об отмене НМД. Ставит на контрольный экземпляр НМД синюю печать «Отменен/Пересмотрен». Перемещает документ в архив отмененных НМД.

Помощник ГД удаляет отмененный НМД с сервера организации из общего доступа, сохраняя его в электронном архиве организации в папке «Отмененные НМД». Он уведомляет персонал по e-mail об отмене НМД.

Каждый сотрудник организации, использующий бумажную копию НМД, обязан уничтожить ее в течение трех дней с момента уведомления об отмене/пересмотре НМД.

5.6.12. Кодирование НМД

Код НМД организации состоит из комбинации букв и цифр и имеет следующий вид:

АААА-00-00-00

где АААА – буквы и цифры, определяющие вид документа. Возможные комбинации этой части кода показаны в табл. 5.6.6.

_{Таблица 5.6.6. Коды документов}

РПУ1, РП2 – один из возможных вариантов представления информации о форме регламентирующего документа. Так, РПУ1 означает одноуровневый регламент процесса управления^[116], РП2 – двухуровневый регламент и т. п.

АААА-00-00-00 – первая пара цифр обозначает номер подразделения организации, за которым закреплен НМД. Таблица кодов подразделений формируется в соответствии со структурой организации, как показано в табл. 5.6.7.

_{Таблица 5.6.7. Коды подразделений организации}

АААА-00-00-00 – вторая пара цифр определяет порядковый номер документа данного типа в базе НМД организации.

АААА-00-00-00 – третья пара цифр определяет номер версии НМД.

5.7. Оценка качества НМД

Оценка НМД специалистами (например, внутренними аудиторами) весьма субъективна. Чтобы снизить степень этой субъективности, полезно формализовать оценку документов при помощи определенных инструментов: таблиц оценки, шкал и т. п.

Ниже приводится пример таблицы, позволяющей формализовать субъективную оценку качества разработки регламентирующего документа.

Таблица анализа НМД

Наименование НМД _______________________________________

^{* См. главу 1.}

Выводы по результатам анализа регламента:

1. _______________________________________

2. _______________________________________

5.8. Разработка графика регламентации

Деятельность по регламентации ресурсоемка. Поэтому ею нужно квалифицированно управлять. Один из важнейших инструментов при этом – график регламентации. По каждому НМД этот график может содержать следующую информацию:

• наименование бизнес-процесса (подразделения, должности);

• тип НМД;

• номер и дата распоряжения о разработке НМД;

• плановая дата готовности НМД к утверждению;

• должность и ФИО ответственного разработчика;

• состав рабочей группы по НМД (должности и ФИО);

• список согласующих лиц (должности и ФИО);

• стадия разработки НМД (см. ниже);

• номер и дата приказа о вводе НМД в действие (для утвержденных НМД);

• проблемы (риски) при разработке НМД;

• ожидаемая дата готовности НМД к утверждению;

• прочее.

В табл. 5.8.1 представлена одна из возможных форм графика разработки НМД и примеры ее заполнения.

_{Табл. 5.8.1. График разработки НМД}^[117]

График разработки НМД ведется в MS Excel (или в другой удобной для этих целей программе).

В графике отображается текущий статус разработки документа (разработка первой версии, презентация, разработка второй версии, тестирование, разработка третьей версии, утверждение и ввод в действие). Для утвержденных и введенных в действие документов в столбце «Стадия разработки» делается запись «Действует».

Форма графика может быть изменена. Например, дополнена некоторыми столбцами (дата утверждения НМД и т. д.).

5.9. Контроль исполнения требований НМД

Рассмотрим вопрос контроля исполнения требований НМД. Можно выделить шесть основных возможностей (направлений) такого контроля:

1. Самоконтроль.

2. Контроль непосредственным руководителем.

3. Контроль по показателям.

4. Внутренний аудит.

5. Жесткая автоматизация.

6. Контроль, интегрированный в процесс.

5.9.1. Самоконтроль

Самоконтроль предполагает, что исполнитель самостоятельно отслеживает выполнение требований нормативного документа. Чтобы он это делал, необходимо несколько условий:

• знание стандарта и умение им пользоваться (быстро находить нужные требования в зависимости от ситуации);

• внутренняя мотивация выполнять требования стандарта;

• инструменты самоконтроля;

• ресурс времени.

Исполнитель должен хорошо знать стандарт/набор стандартов, по которым он действует. Кроме того, ему необходимо уметь быстро находить нужную информацию в документе, читать графические схемы бизнес-процессов и т. д. Сами стандарты должны быть доступны исполнителю в бумажной, а лучше в электронной форме (если это возможно и рационально).

Внутренняя мотивация исполнителя делать работу правильно (по стандарту) – следствие ряда факторов, таких как действующая система материального стимулирования, корпоративная культура организации, наличие руководителя-лидера, осознание рисков (в том числе лично для себя), возникающих от неправильно выполненной работы.

К полезным инструментам самоконтроля можно отнести контрольные листки, чек-листы, таймшиты, журналы и т. д. В этих документах исполнитель периодически отмечает факт и/или результат выполнения наиболее важных операций процесса. Кроме того, инструментом самоконтроля могут служить отчеты, заполняемые исполнителем в конце рабочего дня/смены.

Отмечу, что исполнителю нужен ресурс рабочего времени для осуществления самоконтроля – то есть при выполнении процессов на эту работу должно отводиться пусть незначительное, но вполне конкретное время.

5.9.2. Контроль непосредственным руководителем

Руководитель может и должен проверять соблюдение требований НМД по процессам, проводя:

• непосредственный визуальный контроль работы исполнителей;

• аудит соблюдения требований на основе анализа документальных подтверждений выполненной работы.

Периодически руководитель может визуально наблюдать за работой сотрудников, проверяя, соблюдают ли они стандарты. Нет сомнений, что он сам при этом должен знать эти стандарты лучше всех. Поэтому в первую очередь следует проверять знания и навыки самого руководителя. Это возможно, например, при проведении очередной аттестации (если они бывают в компании).

Кроме визуального контроля руководитель может проводить аудит исполнения требований стандартов сотрудниками. При этом он проверяет:

• наличие документов, подтверждающих выполнение стандартов (рабочие документы, журналы и т. п.);

• формальное содержание документов (соответствие шаблонам, наличие необходимых данных и т. п.);

• содержательный анализ документов (проверка на профанацию);

• результативность и эффективность выполнения работы (если соответствующие показатели можно рассчитать).

Аудит должен проводиться в соответствии с планом работы подразделения. Его результаты следует фиксировать, чтобы их всегда можно было проверить.

5.9.3. Контроль по показателям

Контроль исполнения требований стандартов по бизнес-процессам на основе показателей возможен, когда:

• процесс стабильно выполняется;

• для процесса подобраны адекватные показатели (метрики);

• фактическая информация для расчета показателей по процессам достоверна и оперативна;

• накоплена статистика измерений показателей за определенный период (для возможности определения нормальных границ хода процесса);

• действует система мониторинга хода и результатов процесса по указанным показателям.

При соблюдении этих условий можно по отклонениям показателей судить об исполнении требований стандартов/регламентов или об отсутствии отклонений от устоявшейся практики работы (если регламенты не документированы). Если стандарты выполнения работы перестают выполняться (возникают нарушения), то этот факт сразу находит отражение в значении показателей. Проводить мониторинг динамики изменения значений показателей может как непосредственный, так и вышестоящий руководитель. Если в компании внедрена система управления эффективностью (Business Performance Management), то ряд наиболее важных показателей доступен для мониторинга руководителям нескольких уровней на их индивидуальных панелях управления.

5.9.4. Внутренний аудит

Один из традиционных способов контроля исполнения стандартов по процессам – внутренний аудит. Как правило, для его проведения создается специализированное подразделение, в состав которого входят квалифицированные специалисты.

Деятельность по аудиту регламентируется стандартом проведения внутренних аудитов. Они выполняются по годовому/квартальному плану. Руководителей подразделений, в которых будет проводиться аудит, предупреждают заранее.

Аудит может проводиться при помощи:

• анализа рабочей документации по процессу;

• визуального наблюдения за сотрудниками, выполняющими процесс;

• проведения интервью при помощи перечня контрольных вопросов;

• анализа причин снижения результативности и эффективности процессов (при помощи различных методик).

По итогам аудита формируется отчет, предоставляемый руководителю подразделения, в котором проводился аудит, и кому-то из заместителей гендиректора (этот руководитель – куратор соответствующих процессов).

Важно подчеркнуть, что к результатам аудита относятся не только перечень выявленных недостатков в работе и нарушений требований стандартов по процессу, но и анализ причин отклонений и подробные рекомендации по улучшению процесса, в том числе путем совершенствования соответствующих регламентов – то есть аудит следует в первую очередь рассматривать как инструмент развития.

5.9.5. Жесткая автоматизация процесса

Если часть работ (или весь процесс) зашита в автоматизированную систему при помощи некоторого программного продукта, сотрудник вынужден четко следовать заранее спроектированному сценарию. Этот сценарий может изменяться в соответствии с некоторыми правилами, но и они установлены заранее.

В большинстве случаев можно не сомневаться, что процесс будет выполнен с соответствии с установленным стандартом. Однако и автоматизация не гарантирует абсолютную точность. Сотрудники иногда ошибаются при вводе данных или вводят заведомо некорректные данные. Они могут выполнять работу дольше, чем положено, и т. п.

Поэтому сейчас активно развивается целый класс систем, предназначенных для автоматизации операционных процессов. Это так называемые системы Business Process Management (BPMS). Некоторые горячие сторонники полагают, что процессный подход возможен только при внедрении указанных средств автоматизации. На мой взгляд, это слишком узкий подход к использованию процессных принципов организации деятельности, хотя внедрение BPMS в определенных случаях полезно для компании. Хорошая BPM-система позволит сотрудникам самим описывать свою деятельность и быстро перенастраивать процессы. Но BPMS – это техническое средство, инструмент. Эффективность его применения зависит от квалификации специалистов. Внедряя BPM-систему, нужно одновременно налаживать коммуникации и разрушать межфункциональные барьеры, обучать менеджеров управлять процессами и вовлекать персонал в деятельность по улучшению процессов. Тогда компания сможет получить значительный эффект от автоматизации.

5.10. Подходы к регламентации: оптимизация или директива?

В этом параграфе рассмотрим два принципиально разных подхода к регламентации процессов. Первый подход можно условно назвать «регламентация, основанная на результатах оптимизации», а второй – «директивная регламентация».

5.10.1. Регламентация, основанная на результатах оптимизации

Рассмотрим подход к регламентации процессов, основанный на их оптимизации.

Руководитель подразделения (возможно, он же является и владельцем процесса) получает от вышестоящего руководства цели и показатели для управления процессом. Они служат ему ориентиром при оптимизации процесса. Чтобы приступить к ней, руководитель создает команду по процессу. В нее входят сотрудники – участники рассматриваемого процесса, а также представители процессов-поставщиков и процессов-потребителей. Существуют различные способы организации командной работы.

Когда команда сформирована, руководитель ставит перед ней цели по оптимизации процесса. Команда выполняет его тщательный анализ. Этот этап может занять от двух недель до полутора месяцев. Чем сложнее и значимее процесс, тем больше времени потребуется. По ходу анализа выявляются проблемы, связанные с выполнением процесса, и устанавливаются их причины. Когда причины установлены, переходят к разработке мероприятий по улучшению. После согласования предложений по совершенствованию процесса и выделения необходимых ресурсов команда совместно с сотрудниками компании приступает к реализации мероприятий. При этом осуществляются изменения и выполняется многократное повторение процесса для закрепления у персонала навыков по новым/измененным методам работы.

После выполнения мероприятий команда проверяет, достигнуты ли цели по совершенствованию процесса. Если да, то может потребоваться закрепление наработок на практике, а эффективного метода работы – в регламенте. Тогда команда разрабатывает/корректирует регламент выполнения бизнес-процесса (возможно, комплект регламентирующих документов). После утверждения регламента его требования доводят до остальных сотрудников и обучают их новым методам работы.

Цели, границы, проблемы, процессы и масштабы соответствующих изменений могут быть разными. Поэтому состав и длительность работы команд существенно варьируются от случая к случаю.

Возможно, над оптимизацией процессов будут работать специальное подразделение (отдел развития, центр инноваций, служба качества, отдел по бизнес-процессам и т. п.) или привлеченный внешний консультант. Общее одно – регламентация осуществляется после оптимизации бизнес-процесса, когда сотрудники обучены и выполняют работу в соответствии с установленными требованиями.

При данном подходе оптимизация бизнес-процессов требует времени, ресурсов и приложения определенных усилий руководителями.

5.10.2. Директивная регламентация

Рассмотрим подход, условно названный «директивная регламентация». Он состоит в следующем. Ставится цель по реорганизации процесса. Это может сделать как вышестоящий начальник, так и сам руководитель. Затем разрабатывается регламент процесса. Делать этот может:

• сам руководитель;

• сотрудник подразделения, назначенный руководителем;

• межфункциональная рабочая группа;

• специализированное структурное подразделение (например, отдел развития);

• внешний консультант;

• прочее.

При разработке учитывается ви?дение руководителей и специалистов того, как правильно должен выполняться процесс. Ви?дение это обычно субъективное и не всегда подтверждается практикой. Но поскольку времени и ресурсов для его проверки путем выполнения нескольких циклов процесса нет, эти соображения принимаются и включаются в регламент как требования к процессу. Вся надежда руководителей при таком подходе возлагается на последующую серию согласований текста регламента на межфункциональном уровне. Считается, что чем больше руководителей и грамотных специалистов согласует регламент, тем лучше. Бесконечные согласования приведут к тому, что регламент устроит всех, а для его практического выполнения не придется значительно менять существующие методы работы (или это будут поверхностные изменения).

Когда межфункциональное согласование не требуется, руководитель может внедрить регламент волевым решением и попытаться заставить сотрудников его выполнять. Если у него хватит сил и времени для жесткого контроля исполнения требований, то регламент будет внедрен. Если нет, то изменения останутся на бумаге.

Рассматриваемый подход имеет ряд недостатков. Главный из них в том, что можно работать с бумагой, а не с реальным процессом. Для описания процесса на бумаге нужно гораздо меньше усилий, чем для его реальной оптимизации. В итоге в компании растет гора бумажных регламентов (как нередко бывает при внедрении СМК), а процессы остаются почти неизменными и недостаточно эффективными.

Мы рассмотрели два диаметрально противоположных подхода к созданию регламентов выполнения процессов. Подводя итоги, еще раз подчеркну, что:

• если требования к процессам не закреплены документально (отсутствуют регламенты, стандарты и т. п.), то совершенствовать процессы трудно или вообще невозможно;

• если руководитель не проверяет требования, установленные в документах, то регламенты не работают (выполняемые процессы частично или полностью не соответствуют требованиям регламента);

• если руководитель формально разрабатывает и административно вводит в действие регламенты, то чаще всего они не работают;

• если регламентации предшествуют оптимизация бизнес-процессов и обучение сотрудников, а исполнение требований регламентов потом оперативно контролируется руководителем, то улучшение процессов возможно.

Итак, чтобы регламенты процессов действительно работали, руководители всех уровней обязаны повседневно контролировать исполнение их требований и организовывать командную работу по оптимизации и последующей стандартизации процессов. В компании должна быть создана система совершенствования процессов, в которой регламенты являются только одной, но достаточно важной частью.

5.11. Список литературы

1. Репин В. В. Бизнес-процессы компании: построение, анализ, регламентация. – М.: Стандарты и качество, 2007.

2. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: Стандарты и качество, 2004.

3. Елиферов В. Г., Репин В. В. Бизнес-процессы. Регламентация и управление. – М.: Инфра-М, 2009.

4. Николаева С. А., Шебек С. В. Корпоративные стандарты: от концепции до инструкции. – М.: Книжный мир, 2002.

5. Харрингтон Дж. Совершенство управления процессами. – М.: Стандарты и качество, 2007.

Глава 6
Управление бизнес-процессами

Глава 6 посвящена практическим вопросам управления бизнес-процессами компании. Рассматриваются подходы к определению процессов управления, разработке показателей для управления процессами и некоторые другие вопросы.

6.1. Процессы управления

6.1.1. Процессы управления в системе процессов компании

С практической точки зрения важен вопрос определения и описания процессов управления. В качестве примера рассмотрим модель APQC, версия 5^[118]. Содержит ли она процессы управления? В определенном смысле – да. Перечислю некоторые процессы, содержащие термин «управлять»:

1.3. Управлять стратегическими инициативами…

2.1. Управлять портфелем продуктов/услуг…

2.1.5. Управлять жизненным циклом продуктов/услуг…

3.5. Разрабатывать планы по продажам и управлять ими…

3.5.3. Управлять продажами…

4.1.2. Управлять спросом на продукты/услуги…

4.1.4.2. Управлять запасами незавершенного производства…

Процессы, содержащие термин «управлять», появляются в модели APQC без всякой системы, то есть в какой-то части модели они есть, где-то их нет, где-то использованы другие слова («разрабатывать», «развивать», «согласовывать» и т. п.). Обратим внимание, что модель APQC не привязана к какой-либо организационной структуре. Итак, APQC может содержать следующие процессы управления:

Вариант 1. Процессы управления объектами управления (стратегия, планы продаж, продукты и услуги, запасы и т. п.).

Вариант 2. Процессы управления процессами (управление процессами продаж, оперативное управление производством, управление процессами технического обслуживания).

Вариант 3. Процессы управления структурными подразделениями (управление отделом продаж).

На мой взгляд, модель AQPC содержит процессы управления объектами (вариант 1), причем они описаны весьма произвольно.

Как же описать процессы управления в системе процессов компании? Какие это процессы? Если модель была построена по процессному принципу (например, на основе ЦСЦ – цепочек создания ценности), то как отобразить в ней процессы управления структурными подразделениями? Это лишь некоторые вопросы, возникающие при попытке структурирования процессов управления организации.

На основе опыта построения системы процессов компаний было выбрано следующее методическое решение:

• включать в модель в качестве первой категории^[119] системы процессов категорию «Управление компанией»;

• определять и показывать процессы управления процессами в виде отдельной процессной группы для каждой категории процессов;

• процессы управления структурными подразделениями (административное управление) определять и включать в отдельную от общей системы процессов модель (структура этой модели может соответствовать организационной структуре компании).

В качестве пояснения приведу следующий пример (табл. 6.1.1):

_{Таблица 6.1.1. Пример процессной категории «Инженерно-техническое обеспечение»}^[120]

Обратите внимание на процессную группу 8.1 – «Управление процессами инженерно-технического обеспечения». Бо?льшая часть процессов управления в ней сводится к планированию процессов обслуживания механического и энергетического оборудования, инфраструктуры предприятия. Явно не хватает контроля, анализа и оперативного управления. Но это реальный пример, он отражает фактическую ситуацию в компании.

Другой пример – процессная группа «Управление процессами продаж» – представлен в табл. 6.1.2.

_{Таблица 6.1.2. Пример процессной категории «Продажи»}

В табл. 6.1.2 есть категория 4.1 – «Управление процессами продаж». Фактически в ней представлены процессы планирования, мониторинга и анализа, которые выполняет руководитель, отвечающий за продажи в целом. Это процессы управления процессами или процессы управления подразделениями? Скорее первое.

6.1.2. Определение процессов управления на основе временны?х контуров

Теперь рассмотрим подход, позволяющий структурировать процессы управления в разрезе временны?х контуров.

Отвлечемся ненадолго от классификации процессов и подумаем: а какую деятельность выполняет руководитель? Предлагаю типовой список, сформированный на основе временны?х контуров управления:

• Ежедневный (даже ежечасный) контур управления – управление оперативной деятельностью:

– личное выполнение ряда действий (операций) в операционных процессах (как правило, для руководителей среднего и нижнего уровня);

– оперативный контроль так называемых экземпляров процесса (если используется система Work Flow или BPMS);

– мониторинг и контроль операционных процессов (визуальный, по документам, по оперативным показателям); принятие оперативных управленческих решений (координация работы исполнителей, разрешение конфликтных ситуаций и т. д.).

• Еженедельный контур управления:

– анализ деятельности за неделю;

– анализ деятельности за неделю по отдельным сотрудникам и принятие решений по материальному стимулированию;

– планирование работы на неделю (определение целей и задач, определение требуемых ресурсов, координация работы сотрудников);

– выборочный контроль соответствия входящих и исходящих ресурсов по операционным процессам;

– контроль состояния оборудования и среды^[121];

– управление проектами (планирование, контроль, координация и т. д.);

– согласование закупок ТМЦ для нужд подразделения (визирование счетов);

– …

• Ежемесячный контур управления:

– анализ деятельности за месяц и подготовка отчета;

– формирование плана на следующий месяц (квартал);

– закрытие табелей за месяц;

– разработка графика ТО^[122] на месяц;

– …

• Ежеквартальный контур управления:

– анализ деятельности за квартал и подготовка отчета;

– уточнение плана и бюджета подразделения на следующий квартал;

– заключение договоров на поставку ТМЦ;

– …

• Ежегодный контур управления:

– анализ деятельности за год и подготовка отчета;

– формирование плана и бюджета отдела на следующий год;

– формирование графика отпусков сотрудников;

– формирование графика обучения сотрудников;

– …

В данном примере присутствуют как процессы управления процессами, так и процессы управления подразделениями. Полезно структурировать деятельность каждого руководителя компании подобным образом, выполнить анализ и понять, насколько эффективно он занимается управлением. Однако сложно включать такие списки процессов управления в общую систему процессов компании. Дело в том, что система процессов не совпадает (и не должна совпадать!) со схемой организационной структуры компании. Поэтому для описания процессов управления под конкретных руководителей желательно создавать отдельную модель.

Приведу несколько примеров структур процессов управления для руководителей, находящихся на различных должностях.

Пример. Структура процессов управления начальника отдела продаж (ОП)

Ежедневный контур управления:

• проведение ежедневных совещаний:

• проверка интенсивности работы сотрудников за предыдущий день;

• проведение совещаний с сотрудниками по итогам встречи с клиентом;

• подготовка отчета по проведенным встречам;

• выборочная проверка и согласование коммерческих предложений по сделкам;

• подготовка личного отчета по работе за день;

• анализ продаж за неделю, формирование и согласование отчета:

• подготовка и проведение совещания ОП;

• определение целевых сегментов.

Ежемесячный контур управления:

• анализ продаж за месяц, формирование и согласование отчета;

• корректировка плана посещения выставок и семинаров на месяц;

• аудит соблюдения стандартов сотрудниками ОП;

• подготовка ежемесячного бюджета ОП;

• подготовка и проведение совещания ОП.

Ежегодный контур управления:

• анализ результатов работы отдела за год;

• проведение собрания по результатам года;

• подготовка годового бюджета ОП;

• формирование графика отпусков сотрудников ОП;

• формирование плана выставок на год (участие, посещение);

• подготовка предложений по корректировке системы оплаты и стимулирования труда ОП.

В этом примере отражены в основном административные процессы, то есть процессы управления подразделением. В меньшей степени – процессы управления процессами.

Пример. Структура процессов управления начальника транспортного отдела (ТО)

Ежедневный контур управления:

• анализ доставок за предыдущий день;

• анализ отчетов диспетчеров, контроль дисциплины;

• учет и контроль пробега автомобилей;

• учет и контроль норм выработки;

• планирование внутренних доставок.

Еженедельный контур управления:

• контроль состояния автотранспорта;

• анализ деятельности ТО за неделю;

• планирование внешних доставок.

Ежемесячный контур управления:

• корректировка потребности в автотранспорте на квартал/месяц;

• анализ работы водителей и экспедиторов за месяц;

• закрытие табелей по сотрудникам ТО;

• формирование отчетности и анализ деятельности ТО за отчетный период;

• анализ, разработка/корректировка графиков доставки.

Ежеквартальный контур управления:

• корректировка потребности в автотранспорте на квартал/месяц;

• заключение договоров на услуги;

• приобретение/замена автомобилей;

• корректировка системы оплаты водителей и экспедиторов;

• анализ, разработка предложений и корректировка графиков доставки по дистрибуции;

• формирование отчетности и анализ деятельности ТО за квартал.

Ежегодный контур управления:

• планирование потребности в автотранспорте на год;

• формирование бюджета ТО на год;

• формирование графика отпусков сотрудников ТО на год;

• формирование графика ТО и ремонта автотранспорта на год;

• формирование отчетности и анализ деятельности ТО за год.

В этом примере встречаются как процессы управления процессами, так и процессы управления подразделениями.

Пример. Структура процессов управления вице-президента компании по функциональному направлению

Ежедневный контур управления:

• рассмотрение текущих проблем и принятие оперативных управленческих решений в пределах своих полномочий^[123];

• формирование поручений сотрудникам управления;

• выполнение срочных поручений вышестоящих руководителей компании.

Еженедельный контур управления:

• проведение еженедельной планерки с директорами департаментов управления (по пятницам с 12.30 до 13.30);

• согласование и предоставление отчета управления на планерку функционального блока;

• анализ еженедельных отчетов сотрудников по приоритетным проектам.

Ежемесячный контур управления:

• получение и анализ отчетов по работе сотрудников за месяц;

• планирование выделения ресурсов на следующий месяц (например, планирование командировок сотрудников);

• контроль выполнения планов и достижения КПЭ^[124] сотрудниками управления;

• проведение секторной группы по функциональному направлению (15-е число месяца).

Ежеквартальный контур управления:

• корректировка плана по выделению ресурсов на следующий квартал;

• согласование и утверждение планов сотрудников управления на квартал;

• контроль исполнения планов сотрудников за предыдущий квартал;

• контроль достижения сотрудниками управлении запланированных КПЭ;

• согласование/корректировка плана проведения аудитов;

• участие в экспертной группе.

Ежегодный контур управления:

• формирование личного плана работы и КПЭ на год;

• разработка и утверждение плана проведения аудитов функциональных подразделений в регионах на год;

• согласование и утверждение планов сотрудников управления на год;

• согласование и утверждение КПЭ сотрудников на год;

• контроль исполнения планов сотрудников за прошедший год;

• оценка и утверждение фактически достигнутых сотрудниками КПЭ;

• формирование плана разработки (пересмотра/актуализации) нормативно-методических документов, регламентирующих процессы управления;

• формирование плана управления на год с выделением ресурсов.

Этот пример в основном содержит процессы управления подразделением.

Пример. Структура процессов управления директора по производству

Ежедневный контур управления:

• анализ отчета по производству за сутки, принятие оперативных решений;

• проведение оперативного совещания с ИТР^[125] департамента производства;

• обход производственных участков;

• контроль расстановки производственного персонала;

• согласование/реализация решений по несоответствующим материалам (в рамках своей компетенции).

Еженедельный контур управления:

• подготовка к еженедельному совещанию у президента;

• согласование плана производства и графика загрузки оборудования на следующую неделю;

• анализ отчета по человеческим ресурсам, формирование заявки на человеческие ресурсы;

• анализ и согласование отчета по производству за неделю;

• согласование заявок на закупку ТМЦ.

Ежемесячный контур управления:

• анализ и согласование предварительного плана производства на месяц;

• согласование плана производства на месяц;

• формирование отчета по КПЭ производства за месяц;

• согласование графика ТО, ремонта и уборки оборудования на месяц;

• согласование графика платежей на месяц;

• анализ и согласование ежемесячного отчета по производству;

• согласование табеля по ИТР департамента производства (два раза в месяц);

• согласование табелей по сменам (два раза в месяц);

• согласование заявок на закупку ТМЦ.

Ежеквартальный контур управления:

• согласование плана производства на квартал по месяцам;

• анализ и согласование отчета по производству за квартал;

• формирование потребности в ТМЦ на следующий квартал.

Ежегодный контур управления:

• анализ и согласование плана производства на год;

• анализ и согласование бюджета департамента производства на год;

• анализ и согласование отчета по производству за год;

• формирование отчета об исполнении бюджета производства за год;

• согласование плана капитального ремонта и модернизации оборудования;

• согласование графика отпусков ИТР департамента производства;

• разработка и расчет КПЭ производства на год;

• разработка и расчет показателей СМК (системы менеджмента качества) для производства на год;

• формирование отчета по СМК в части производства за год.

Пример. Структура процессов управления заведующего кафе

Ежедневный контур управления:

• ежедневный утренний обход кафе;

• анализ деятельности кафе за предыдущие сутки;

• контроль соблюдения стандартов обслуживания в торговом зале, на кухне и в баре.

Еженедельный контур управления:

• проведение еженедельной планерки с администраторами, барменами, заведующим производством и сотрудниками кухни;

• контроль заявки на столовую и барную посуду и столовые приборы, составленную в понедельник администратором дневной смены;

• работа с жалобами.

Ежемесячный контур управления:

• подготовка и согласование плана работы кафе на месяц;

• анализ работы кафе и подготовка отчета о работе кафе за месяц;

• рассмотрение и утверждение графиков работы сотрудников кафе;

• осуществление поощрений и наказаний сотрудников кафе;

• заключение договоров с поставщиками алкогольной продукции, контроль деятельности поставщиков алкогольной продукции;

• организация и выполнение обучения персонала на рабочих местах;

• проведение аттестации персонала кафе;

• выполнение контроля наличия необходимой разрешительной документации и лицензий.

Как видно из приведенных примеров, существенная часть работы руководителя связана с планированием ресурсов (человеческих в том числе), организацией работ, контролем, расчетом зарплаты сотрудников, формированием отчетов руководству. Деятельность по непосредственному управлению операционными процессами также занимает долю времени руководителя. Замечу, что структурное подразделение выполняет и/или участвует в нескольких операционных процессах, имея при этом одного руководителя – начальника подразделения.

Чем ниже по иерархической лестнице находится руководитель, тем меньше у него процессов управления подразделением и тем больше процессов управления операционными процессами. На верхнем уровне руководства (директор, замдиректора, начальник департамента) доля работы руководителя, связанная с управлением операционными процессами, минимальна. На нижнем уровне управления (начальник отдела, руководитель сектора, группы, участка и т. п.) доля работы по управлению операционными процессами выше. Но она никогда не достигает 100 %. Случаи назначения руководителей нижнего уровня исключительно на управление операционными процессами встречаются очень редко (несмотря на рекомендации премудрых западных книжек по менеджменту). Чаще им приходится совмещать административное управление подразделением и управление операционными процессами.

Если мы определили процессы в рамках границ структурного подразделения, то вполне можем описать процессы управления в разрезе контуров (как было показано выше). Если же мы выделяем сквозные бизнес-процессы и назначаем их владельцев (с разной степенью полномочий), то описывать процессы управления этими сквозными бизнес-процессами лучше отдельно (то есть вне контуров управления структурным подразделением). (О назначении владельцев сквозных процессов я рассказал в главе 2.)

Вообще для компании наиболее важны, как правило, именно сквозные процессы. Процессы управления ими могут быть делегированы сотрудникам организации, занимающим должности заместителей начальников отделов, ведущих специалистов, специалистов. Таким образом, структурное управление деятельностью (работа руководителя) легко описать при помощи контуров, а чисто процессное управление – продумать при описании соответствующего сквозного процесса. Очевидно, что контуры управления могут применяться также для структурирования процессов управления сквозным процессом.

6.2. Чем вы управляете: бизнес-процессами или схемами процессов?

Когда в компании ведется работа по структурированию и описанию бизнес-процессов, часто возникает следующая ситуация. Процесс определен, его схема описана и согласована, но реализуют его совершенно разные сотрудники. Более того, они могут находиться в разных подразделениях. В этом случае мы имеем дело с типовыми процессами, или, другими словами, типовыми процедурами деятельности. С точки зрения описания и хранения моделей в соответствующей среде моделирования этот факт никаких проблем не вызывает, но с точки зрения реального управления не все так гладко.

Для простоты рассмотрим разницу между управлением схемами процессов и собственно бизнес-процессами на примере из практики.

Директор одной торговой компании решил, что нужно навести порядок в бизнесе – сделать его прозрачным, понять, наконец, кто из сотрудников чем должен заниматься. Надоело мириться с непрозрачностью, спонтанностью, а также «героизмом» тех, кто просто должен трудиться так, как того требует руководство. В первую очередь за счет описания и регламентации процессов директору хотелось улучшить коммерческий результат.

Был инициирован проект по описанию и регламентации, в рамках которого предполагалось за короткий срок (два-три месяца) определить и закрепить в стандартах наиболее важные процессы работы компании.

Описание начали с коммерческой службы, структура которой представлена на рис. 6.2.1. Эту службу возглавляет коммерческий директор (КД), у которого в подчинении несколько отделов, в том числе отдел продаж (ОП) и его начальник (НОП). У начальника отдела продаж в подчинении несколько менеджеров по продажам.

_{Рис. 6.2.1. Структура и процессы}

Все менеджеры по продажам ОП выполняют одинаковую работу:

• звонят потенциальным клиентам, чтобы договориться о встрече;

• проводят переговоры, предлагая услуги компании;

• формируют и отправляют клиентам коммерческие предложения;

• заключают договоры на оказание услуг (на рис. 6.2.1 этот процесс не показан);

• прочее.

По факту заключения договора клиент передается в другой отдел коммерческой службы для последующего сопровождения сделок.

Рабочая группа, которая включала бизнес-аналитиков и специалистов, разработала структуру процессов ОП, которая была согласована с генеральным (ГД) и коммерческим директорами. Она включала:

«Список 1^[126]

1. Бизнес-процесс управления ОП, в том числе:

1.1. Анализ продаж ОП за неделю.

1.2. Корректировка плана стимулирования продаж.

1.3. Проведение еженедельной планерки.

1.4. …

2. Бизнес-процесс выполнения звонков (холодных, целевых).

3. Бизнес-процесс проведения переговоров.

4. Бизнес-процесс подготовки коммерческих предложений.

5. Бизнес-процесс подготовки и заключения договора.

6. Прочее».

Исполнителем процесса управления являлся НОП. Исполнителями остальных процессов – менеджеры ОП.

В соответствии с лучшими практиками были разработаны кросс-функциональные схемы бизнес-процессов, как показано на рис. 6.2.2. По ходу разработки схемы процессов обсуждались командой менеджеров и специалистов, не раз корректировались. В результате полученные схемы бизнес-процессов отражали ви?дение генерального директора того, как должна выполняться работа менеджерами по продажам (рис. 6.2.2).

_{Рис. 6.2.2. Схемы процессов}

Отмечу, что эти схемы были разработаны в кросс-функциональном формате (диаграммы swim line – «дорожки плавательного бассейна»). Несмотря на то что процессы просты, в них принимают участие различные специалисты отделов коммерческой службы и других подразделений (например, в процессе «Подготовка коммерческих предложений»). Это межфункциональные (сквозные) процессы.

Затем сформировали регламенты в MS Word, содержавшие схемы бизнес-процессов, таблицы с описанием операций, приложения с формами используемых документов. Одним словом, были разработаны и утверждены стандарты работы компании в области продаж.

Оценивая проделанную работу, руководитель пришел к выводу, что все сделано корректно и с учетом лучших практик моделирования и регламентации бизнес-процессов. Однако ему все-таки казалось, что чего-то не хватает.

Руководитель размышлял примерно так: при выполнении работы менеджер ОП должен следовать утвержденным стандартам – выполнять последовательность шагов, представленных в схеме бизнес-процесса. Но в документе изображена идеальная схема. На практике менеджер делает примерно 40–50 звонков в неделю. При этом в 60 % случаев он соблюдает требования стандарта (но это предположение еще нуждается в аудите), в 30 % отклоняется от них из-за особенностей клиента, а в 10 % случаев вообще говорит что хочет. С точки зрения бизнеса имеет значение число звонков, которое сделал менеджер за неделю, а еще интереснее – какое количество из них завершились переговорами с клиентом. Кроме того, много переговоров – это хорошо, но немаловажен их результат – объем заключенных сделок, общая выручка и маржа по сделкам. Иными словами, для управления были бы полезны следующие показатели по каждому менеджеру ОП (за неделю, месяц):

• количество встреч/количество звонков, %;

• количество контрактов/количество звонков, %;

• количество контрактов/количество переговоров, %;

• маржа от сделок/количество звонков;

• маржа от сделок/количество переговоров;

• выручка;

• маржа от сделок/зарплата менеджера и т. п.

Полезно рассмотреть показатели не только каждого менеджера, но и ОП в целом. Таким образом, реальные объекты управления – это деятельность и каждого менеджера, и всего отдела. Важно оценивать и анализировать результативность и эффективность работы каждого сотрудника в отдельности. Потом можно принимать управленческие решения – менять менеджеров, систему мотивации, стандарты работы (те самые схемы бизнес-процессов), оборудование (телефоны, компьютеры), программное обеспечение и т. п. С точки зрения отдела в целом можно изменить процессы управления, механизмы коммуникаций, мотивацию, планограмму посадки менеджеров в помещении, закрыть доступ на развлекательные сайты (типа www.anekdot.ru и т. п.) или изъять из офиса чайник и холодильник. В общем, можно и нужно управлять массой факторов, а не только схемами бизнес-процессов.

Немного подумав, руководитель набросал измененный перечень процессов:

«Список 2

1. Бизнес-процесс продаж ОП в целом.

1.1. Бизнес-процесс управления ОП, в том числе:

1.1.1. Анализ продаж ОП за неделю.

1.1.2. Корректировка плана стимулирования продаж.

1.1.3. Проведение еженедельной планерки.

1.1.4. …

2. Бизнес-процесс продаж ОП в целом, в том числе:

2.1. Бизнес-процесс выполнения звонков ОП в целом, включая подпроцессы:

2.1.1. Бизнес-процесс выполнения звонков менеджером ОП (ФИО 1).

2.1.2. Бизнес-процесс выполнения звонков менеджером ОП (ФИО 2).

2.1.3. Бизнес-процесс выполнения звонков менеджером ОП (ФИО 3).

2.1.4. Бизнес-процесс выполнения звонков менеджером ОП (ФИО 4).

2.1.5. …

2.2. Бизнес-процесс выполнения переговоров ОП в целом, включая подпроцессы:

2.2.1. Бизнес-процесс выполнения переговоров менеджером ОП (ФИО 1).

2.2.2. Бизнес-процесс выполнения переговоров менеджером ОП (ФИО 2).

2.2.3. Бизнес-процесс выполнения переговоров менеджером ОП (ФИО 3).

2.2.4. Бизнес-процесс выполнения переговоров менеджером ОП (ФИО 4).

2.2.5. …

2.3. Бизнес-процесс подготовки коммерческих предложений ОП в целом, включая подпроцессы:

2.3.1. Бизнес-процесс подготовки коммерческих предложений менеджером ОП (ФИО 1).

2.3.2. Бизнес-процесс подготовки коммерческих предложений менеджером ОП (ФИО 2).

2.3.3. Бизнес-процесс подготовки коммерческих предложений менеджером ОП (ФИО 3).

2.3.4. Бизнес-процесс подготовки коммерческих предложений менеджером ОП (ФИО 4).

2.3.5. …

2.4. Бизнес-процесс подготовки и заключения договоров ОП в целом, включая подпроцессы:

2.4.1. Бизнес-процесс подготовки и заключения договоров менеджером ОП (ФИО 1).

2.4.2. Бизнес-процесс подготовки и заключения договоров менеджером ОП (ФИО 2).

2.4.3. Бизнес-процесс подготовки и заключения договоров менеджером ОП (ФИО 3).

2.4.4. Бизнес-процесс подготовки и заключения договоров менеджером ОП (ФИО 4).

2.4.5. …»

«Как-то уж слишком сложно получилось, – подумал генеральный директор, – индивидуальные бизнес-процессы для каждого менеджера, потом для группы менеджеров, потом для отдела ОП в целом, а еще управление нужно прописывать…»

После некоторых размышлений он пришел к выводу, что нужно все-таки оставить список процессов № 1, при этом четко понимая, что он включает не реально выполняемые бизнес-процессы, а иерархический справочник схем бизнес-процессов – стандартов выполнения работы сотрудниками компании. Также стало понятно, что надо фиксировать исходные данные и рассчитывать показатели по бизнес-процессам как на уровне менеджеров ОП, так и для отдела в целом. Была разработана система показателей с соответствующей аналитикой. Эта система использовалась для анализа деятельности ОП и принятия решений по ее совершенствованию. В том числе одним из направлений стала работа по изменению схем бизнес-процессов.

Если бы в данной компании была внедрена система BPM^[127], то ситуация выглядела бы иначе. Список № 1 содержал бы типовые схемы бизнес-процессов (стандарты выполнения работы). Допустим, что часть из них была бы автоматизирована в BPMS. Тогда исполняемые в системе экземпляры процессов, по сути, представляли бы собой процессы из списка № 2. В рамках системы BPM возможно получить информацию о том, кто из сотрудников сколько экземпляров процессов выполнил. Эта информация могла бы использоваться для управления.

При отсутствии системы, фиксирующей практически всю информацию о выполнении каждого экземпляра процесса, стоит организовать ручной сбор сведений (журналы, файлы с отчетами). Часть данных можно собрать в рамках системы CRM, в которую менеджеры ОП должны заносить результаты выполнения соответствующих экземпляров процессов.

По итогам рассмотрения данного примера можно сделать следующие выводы:

• регламентация процессов (в том числе за счет разработки кросс-функциональных схем) не равнозначна управлению процессами;

• для управления процессами требуются показатели;

• аналитика, по которой нужно собирать информацию для управления по показателям, может быть значительно шире, чем объект описания стандарта;

• сами стандарты (регламентирующие документы) по процессам – это объекты управления со стороны руководителя подразделения (процесса).

6.3. Объекты управления в рамках процесса

На рис. 6.3.1 представлена развернутая модель управления деятельностью (процессом). Ее основное назначение – акцентировать внимание читателя на объектах, которыми может и должен управлять руководитель в рамках управления процессом. Поскольку наше определение процесса достаточно широкое (см. главу 1), управление всеми объектами, представленными на рис. 6.3.1, можно назвать процессным управлением. Некоторые специалисты, рассматривая определение процесса в узком смысле, подразумевают под процессным управлением деятельность по контролю и координации экземпляров процесса в рамках автоматизируемых (или уже автоматизированных) операционных цепочек. Такой взгляд кажется мне слишком ограниченным. Реальное управление процессами требует более широкого, комплексного взгляда. Тем более что в компаниях^[128] наблюдается следующая картина:

• 50–60 % операционных процессов выполняется без использования каких-либо прикладных систем^[129] (ERP, CRM, автоматизация бухучета) – применяют обычные офисные приложения (например, Word, Excel);

• 30–40 % выполняется с использованием прикладных систем (в первую очередь учетных, например 1С);

• только 5–10 % операционных процессов компании целесообразно автоматизировать при помощи продуктов класса BPM.

_{Рис. 6.3.1. Расширенная схема управления процессом}

Последовательно рассмотрим объекты управления, представленные на рис. 6.3.1.

В первую очередь руководитель управляет операционной деятельностью, в том числе выполняет:

• мониторинг текущей деятельности (если внедрена система BPM, то выполняется мониторинг экземпляров процессов в системе) – контроль исполнения стандартов работы и достижения плановых показателей, проверка результатов выполнения работы, контроль ключевых показателей процесса/продукта/услуги и т. д.;

• координацию работы сотрудников (например, переназначение задач/заданий, оперативные совещания);

• перераспределение ресурсов;

• оперативный анализ и разрешение конфликтных ситуаций;

• прочее.

По ходу оперативной работы руководитель, как правило, не меняет сами стандарты работы (регламенты процессов, инструкции, положения), то есть объект управления в данном случае – исполняемые экземпляры операционных процессов (не имеет значения, автоматизированы они или нет).

При выполнении оперативного управления процессами руководитель может использовать различные инструменты, в том числе:

• модуль мониторинга и анализа процессов в системе BPMS;

• панели управления, реализованные в системе класса Business Performance Management (или просто таблицы и графики в MS Excel);

• системы контроля поставленных задач;

• системы управления проектами;

• прочие программные продукты.

Замечу, что никакие программные продукты не заменят квалификацию и опыт управления.

Второй важнейший, с моей точки зрения, объект управления – сами стандарты выполнения работы. Руководитель анализирует результаты работы за определенный период (неделя, месяц, квартал), определяет необходимые изменения, вносит изменения в стандарты (в том числе в схемы процессов), согласует измененные стандарты в соответствии с утвержденной процедурой управления нормативной документацией компании.

Следующий объект управления – ресурсы, необходимые для выполнения процесса. В первую очередь к их числу относится персонал. Когда руководитель отдает распоряжение сотруднику выполнить работу в рамках процесса – это оперативное управление процессом. Если руководитель анализирует эффективность работы сотрудника и принимает решение о его замене (повышении квалификации, аттестации и т. п.) – это также управление процессом.

К ресурсам также относятся: оборудование, среда, измерительные инструменты, компьютеры и программное обеспечение – это объекты управления в рамках процесса. Ведь всем ясно, что на неисправном оборудовании или с нестабильно работающим программным обеспечением эффективно работать сложно.

Еще один объект управления – входящие (преобразуемые) ресурсы. Руководитель анализирует их соответствие задачам процесса. Если на вход подаются бракованные (несоответствующие) материалы, достигнуть требуемого результата процесса невозможно.

Итак, лучше всего рассматривать управление процессом комплексно, с учетом всех аспектов. Выбранную модель стоит иметь в виду, проводя анализ, оптимизацию и последующую автоматизацию процессов управления.

6.4. Разработка показателей для управления процессом

Для оперативного управления процессами нужна система показателей. Для определения показателей рассмотрим общую схему (рис. 6.4.1), показывающую различные потоки информации, которые получает руководитель.

_{Рис. 6.4.1. Оперативное управление процессами}

В первую очередь руководитель получает оперативную информацию о выполнении самого процесса и его результатах. Для аналитических целей можно выделять две категории: показатели процесса и показатели продукта/услуги. Однако зачастую эти показатели очень близки по смыслу. Поэтому с практической точки зрения важно создать единую систему показателей для управления процессом – без искусственного дробления показателей на процессные и продуктовые.

Третий поток, который получает руководитель, – это информация об удовлетворенности клиентов процесса, причем как внешних, так и внутренних.

Еще один поток – информация, поступающая от вышестоящего руководителя или из органа управления.

Итак, руководителю (владельцу процесса) требуются показатели о нескольких объектах управления: процессе, продукте/услуге, клиенте и в некотором смысле о вышестоящем руководителе.

Владелец процесса может разработать различные показатели, но они обязательно должны включать следующие четыре категории (см. рис. 6.4.2):

1. Результат выполнения процесса.

2. Затраты ресурсов на выполнение процесса.

3. Время выполнения процесса.

4. Количество дефектов (несоответствий) в продуктах/услугах, полученных в результате выполнения процесса.

_{Рис. 6.4.2. Показатели для управления процессом}

Учет этих четырех категорий при разработке обеспечивает сбалансированность системы показателей. На практике это означает, например, что при сокращении затрат на выполнение процесса или времени его выполнения уровень несоответствий готовой продукции не будет повышаться (как минимум он будет находиться под управлением). Можно много говорить об односторонней псевдооптимизации процессов, когда при росте одного из показателей существенно ухудшаются значения других, например:

• снижение затрат – увеличение длительности;

• снижение затрат – увеличение количества дефектов;

• сокращение времени выполнения – увеличение количества дефектов и т. п.

Есть еще две категории, важные для управления процессом: 1) результативность процесса; 2) эффективность процесса.

Дело в том, что независимо от наличия у компании четко сформулированной стратегии измерять результативность и эффективность ее процессов необходимо. Для этого можно использовать следующие определения:

Под результативностью понимается отношение полученного фактического результата деятельности к планируемому.

Эффективность определяется как отношение полученного фактического результата деятельности к использованным для его достижения ресурсам.

В табл. 6.4.1 показаны различные возможные отношения четырех категорий: результата процесса, затрат, времени и дефектов.

_{Таблица 6.4.1. Показатели результативности и эффективности}

В табл. 6.4.2 и 6.4.3 – примеры показателей. В столбце «Тип» буква «Р» означает, что соответствующий показатель относится к категории «Результативность», а буква «Э» – к категории «Эффективность».

_{Таблица 6.4.2. Показатели процесса «Управление развитием розничной сети»}

_{Таблица 6.4.3. Показатели процесса «Закупка товара»}

Отмечу, что распределение всех показателей по категориям «Результативность» и «Эффективность» не самоцель. С практической точки зрения важно, чтобы процесс находился под контролем с точки зрения как результативности, так и эффективности.

К сожалению, эффективность процесса измеряется и становится целью управления гораздо реже, чем результативность. В некоторых компаниях при управлении процессами эффективность вообще не измеряется или измеряется несистемно, то есть нет необъективной информации о состоянии процесса. В результате потери, возникающие при выполнении процесса, не устраняются. Низкая эффективность компенсируется за счет цены на продукты/услуги. В итоге от этого страдает внешний потребитель.

Для каждого показателя, который предполагается использовать для мониторинга и управления процессом, нужно собрать и систематизировать информацию, которая позволит его идентифицировать и рассчитать. В нее входят:

• наименование и код показателя в системе показателей компании;

• категория показателя;

• перечень должностных лиц и организаций, получающих показатель в составе планов (отчетов);

• должность сотрудника, ответственного за достижение целевого значения показателя;

• должность сотрудника, ответственного за расчет показателя;

• периодичность расчета и отчетный период;

• определение показателя;

• единица измерения показателя;

• методика расчета показателя;

• перечень документов, содержащих информацию, необходимую для расчета показателя;

• перечень плановых (отчетных) форм, включающих показатель.

Наименование и код показателя в системе показателей компании

У каждого показателя должны быть четкое наименование и код, однозначно идентифицирующий его в системе показателей компании. Желательно определиться с принципами идентификации заранее, до построения системы показателей для процессов. Для идентификации следует разработать и утвердить систему кодирования показателей. Возможны различные варианты кодирования. Руководство компании может выбрать наиболее удобный способ.

Категория показателя

Категории показателей используются в различных целях. Например, показатели можно классифицировать так:

• финансовые;

• рыночные;

• по процессам;

• по персоналу;

• по инновациям.

В этом случае их можно привязать к так называемым перспективам, которые используются в методике BSC. Замечу, что иметь определения категорий показателей необязательно.

Перечень должностных лиц, получающих показатель в составе планов (отчетов)

Для каждого показателя определяют круг должностных лиц компании, которые будут получать его значение – плановое и/или фактическое – в составе планов и/или отчетов. Критерий включения показателя в документ – принятие решений на его основе. Если руководитель получает значение показателя в отчете, но никогда не принимает с его помощью управленческих решений, то стоит проанализировать, нужен ли ему такой показатель.

Должность сотрудника, ответственного за достижение целевого значения показателя

Ряд показателей в системе показателей компании служит для измерения достижения какой-либо цели. Некоторые показатели могут использоваться для мониторинга и анализа процессов.

Целевые (нормативные) значения показателей должны устанавливаться в соответствующих плановых документах организации. Для каждого показателя следует определить должностное лицо, отвечающее за достижение его целевого значения. Предполагается, что этот сотрудник, по сути, владелец процесса с определенным набором полномочий.

Должность сотрудника, ответственного за расчет показателя

На практике часто встречается ситуация, когда руководитель, отвечающий за достижение целевого значения показателя, по объективным причинам не может рассчитать этот показатель. Например, руководитель управляет производственными процессами на основании данных производственного учета, но у него нет нужной информации для оценки эффективности процессов с использованием расчета затрат. Эти данные может дать только финансовая служба (или бухгалтерия). В этом случае необходимо назначать отдельное должностное лицо, ответственное только за расчет значения показателя, но не за достижение его целевого значения. В ряде случаев сотрудник, рассчитывающий показатель, может одновременно являться и ответственным за достижение его целевого значения.

Периодичность расчета и отчетный период

Каждый показатель должен рассчитываться с определенной периодичностью и включаться в соответствующие отчетные формы, например ежемесячно или ежеквартально.

Кроме периодичности расчета, для каждого показателя целесообразно указывать отчетный период, например: «Ежемесячно до 2-го числа месяца, следующего за отчетным».

Определение показателя

Определение показателя означает краткую формулировку, дающую четкое и полное понятие о показателе. Как правило, определение показателя должно давать возможность разработать конкретную формулу для его расчета.

На практике попытки четко определить показатель часто приводят к тому, что его название и смысл корректируются.

Для корректной формулировки определения показателя необходимо участие руководителей и специалистов, связанных с выполнением соответствующего процесса.

Единица измерения показателя

Недопустима ситуация, когда один и тот же показатель в разных документах измеряется с помощью различных единиц, например: килограммы и тонны, метры кубические и тонны, количество и рубли, проценты и доли и т. п. Важно, чтобы для каждого показателя была принята одна единица измерения и она использовалась во всех документах, которые включают плановые или фактические значения показателя.

Методика (формула) расчета показателя

Методика расчета показателя может быть определена с разной степенью детализации. Как минимум она должна содержать формулу расчета показателя. Другие используемые в ней показатели, значения которых нужны для расчета, должны быть четко определены. Вообще любые источники данных для расчета показателя следует четко определить, а доступность и корректность исходных данных заранее проверить.

Перечень документов, содержащих информацию, которая необходима для расчета показателя

Информация для расчета показателя может содержаться в нескольких документах (бумажных или электронных), а также в электронных базах данных. Все эти источники должны быть определены и проверены. Сведения о них следует зафиксировать, они должны стать частью информации о соответствующем показателе.

Перечень плановых (отчетных) форм, включающих показатель

Каждый показатель включается в одну или несколько плановых и отчетных форм. Необходимо выявить эти документы и указать в соответствующем разделе при описании показателя.

Отмечу, что сейчас на рынке представлена целая линейка программ, помогающих структурировать показатели в виде иерархического справочника, вводить плановые и фактические значения, получать различного рода отчеты. В некоторых программах, относящихся к классу BPM^[130], можно разрабатывать панели управления и т. п.

Если в компании используется среда моделирования бизнес-процессов (например, Business Studio), то ее можно использовать для:

• ведения иерархического справочника целей и показателей;

• хранения полной информации о показателе (ответственный, определение, формула расчета и т. д.);

• установления связей целей и показателей с процессами, должностями и бизнес-ролями;

• планирования показателей и формирования отчетных форм;

• формирования отчетов по показателям процессов;

• прочее.

На рис. 6.4.3 показан фрагмент справочника целей и показателей в Business Studio, а на рис. 6.4.4 – несложная панель управления, которую можно использовать для мониторинга изменения значений показателей по бизнес-процессам.

_{Рис. 6.4.3. Справочник целей и показателей в Business Studio}

_{Рис. 6.4.4. Панель управления показателями в Business Studio}

6.5. Оперативное управление процессом

6.5.1. Планирование процессов

Оперативное управление осуществляется на всех уровнях иерархии менеджмента компании. Различие состоит только в масштабе управляемой деятельности.

Планированием процессов занимаются их владельцы (руководители структурных подразделений, их заместители, ведущие специалисты), используя при этом:

• фактическую информацию за предыдущие периоды;

• целевые значения показателей процессов;

• выявленные причины отклонений от нормального хода процессов;

• прочую информацию.

Процедура формирования плана по процессу представлена на рис. 6.5.1.

_{Рис. 6.5.1. Формирование плана по процессу}

На шаге 1 руководитель (владелец процесса) получает планы от руководителей нижестоящего уровня (владельцев подпроцессов) и анализирует эти планы. Он рассматривает предлагаемые снизу корректирующие мероприятия, а также действия по совершенствованию процессов (в рамках цикла PDCA)^[131].

Формы планов по процессам, состав показателей по процессам и периодичность планирования устанавливаются в соответствующих нормативно-методических документах по процессам. План может содержать следующие разделы:

1. Операционные планы и показатели по процессу

Раздел для представления существующих показателей и планов по операционной деятельности

1.1. Операционные показатели по процессу

Раздел для описания операционных плановых показателей

1.2. Операционные планы по процессу

Раздел для описания операционных планов по процессу

2. Показатели улучшения процесса (цикл PDCA, в том числе показатели из системы BSC^[132])

Раздел для описания плановых показателей, установленных в рамках выполнения цикла PDCA и в рамках системы BSC

3. Мероприятия (проекты) по улучшению процессов (цикл PDCA, инициативы в системе BSC)

Раздел для описания мероприятий (проектов), которые выполняются в рамках выполнения цикла PDCA, и для описания инициатив (проектов) в рамках системы BSC

4. Корректирующие мероприятия (для устранения причин отклонений от нормального хода процесса)

Раздел для описания корректирующих мероприятий (проектов), которые необходимо выполнить для устранения причин отклонений от нормального хода процессов

На шаге 2 руководитель определяет приоритетность мероприятий с точки зрения:

• установленных целей компании;

• требований внутренних и внешних потребителей;

• наличия необходимых ресурсов.

После согласования состава мероприятий по подпроцессам и определения требуемых ресурсов руководитель приступает в разработке/корректировке плана по процессу (процессам) своего уровня (шаг 3). Он формирует:

• операционные планы по процессу (процессам);

• планы цикла PDCA и инициативы BSC;

• планы корректирующих мероприятий.

В плане по процессу должны быть указаны как мероприятия (проекты) рассматриваемого уровня управления, так и мероприятия, взятые из планов по подпроцессам (в случае если они требуют существенных ресурсов либо могут значительно повлиять на результативность, эффективность и качество процессов). Разработанный план передается вышестоящему руководителю.

На шаге 4 руководитель вышестоящего уровня рассматривает и согласует план по процессу (процессам).

На шаге 5 руководитель утверждает планы по подпроцессам и доводит их до нижестоящих руководителей (владельцев процессов).

Выше приведены некоторые методические рекомендации по организации оперативного планирования процессов. В конкретной компании допустимы свои порядок планирования и формы документов. Также для планирования процессов могут использоваться различные программные продукты.

6.5.2. Мониторинг процесса

Мониторинг процесса^[133] осуществляется владельцем процесса по ряду показателей:

• установленных в отчетности вышестоящим руководителем;

• установленных владельцем процесса, необходимых ему для осуществления мониторинга.

Мониторинг процесса проводится с заданной периодичностью (ежечасно, ежедневно, еженедельно, ежемесячно, ежеквартально). Его задача состоит в том, чтобы определить, находится ли процесс в нормальном состоянии, то есть в состоянии статистической управляемости.

Если выполнить анализ процесса с точки зрения статистической управляемости невозможно, то нормальные границы определяют по другим соображениям.

_{Рис. 6.5.2. Пример анализа процесса по одному из показателей}

На рис. 6.5.2 нормальное состояние процесса соответствует значениям показателей, попадающих в зеленую зону. Когда значение показателей находится в этой зоне, его владелец не должен хвататься за каждое отклонение и анализировать его причину. Но когда процесс приближается к желтой зоне – границе допуска (например, наблюдается явный тренд увеличения значения показателя), владельцу процесса следует выполнить анализ причин отклонений и соответствующие корректирующие действия.

Ширину зеленой зоны лучше всего определять опытным путем. Например, она может составлять 1/2 ширины желтой зоны. А ее ширина, в свою очередь, может определяться более однозначно:

• требованиями внешнего потребителя (границы допусков, значения каких-либо параметров и т. п.);

• нормативами компании;

• требованиями вышестоящего руководства;

• требованиями государственных стандартов и других внешних нормативных документов.

Если значения показателя оказались в красной зоне, это чрезвычайная ситуация. Владельцу процесса нужно срочно предпринимать меры по коррекции процесса и устранению последствий попадания показателя в красную зону (например, отбор бракованных изделий из партии). При значительных отклонениях возможна полная остановка процесса до выяснения и устранения причин.

Последовательность шагов по мониторингу процесса представлена на рис. 6.5.3.

_{Рис. 6.5.3. Мониторинг хода процесса}

На шаге 1 владелец процесса контролирует получение фактической информации по процессу. Данные могут собираться:

• вручную (например, путем занесения в различные журналы, контрольные формы или файлы);

• автоматически фиксироваться различными системами.

Часть информации о процессе его владелец может собирать и фиксировать лично. За сбор другой части данных отвечают его подчиненные либо соответствующие информационные системы.

На шаге 2 на основе фактической информации о ходе и результатах процесса владелец либо его сотрудники формируют таблицы, графики, контрольные карты по выбранным показателям. Для решения этой задачи могут использоваться различные программные продукты – от MS Excel до систем BPM^[134] или специализированных программных продуктов для статистической обработки данных.

На основе анализа данных владелец процесса идентифицирует отклонения от нормального хода процесса. Выявленные отклонения фиксируются в журнале учета отклонений (это может быть электронный файл или база данных).

Может возникнуть вопрос, зачем все это нужно? Чтобы руководители регулярно занимались мониторингом и анализом управляемых ими процессов, необходимо создание определенной управленческий культуры, ориентированной на решение этой задачи. Если просто написать и утвердить процедуру выполнения корректирующих действий (как это часто бывает при формальном внедрении СМК), рекомендующую руководителям «что-то там» анализировать и корректировать, то мало кто будет ее применять. На первых порах важно именно привить культуру работы с процессами. При решении этой задачи основная ответственность ложится на руководителей верхнего и среднего уровня. Они должны постоянно проверять, выполняют ли их подчиненные регулярный мониторинг процессов, анализируют ли отклонения и т. п. Причем они должны делать это не формально, а вникая в суть выполненного анализа и предлагаемых корректирующих мероприятий. В противном случае работа владельцев по анализу и корректировке процессов рискует оказаться профанацией. Поэтому формы (база данных), в которых фиксируются результаты проделанной работы по мониторингу и анализа причин отклонений, очень важны. Они помогают руководителю вышестоящего уровня контролировать процессы управления, выполняемые владельцами процессов. Также важна грамотно построенная система стимулирования, мотивирующая руководителей заниматься совершенствованием своих бизнес-процессов.

На шаге 3 владелец процесса выявляет и анализирует причины отклонений.

При необходимости на шаге 4 он собирает дополнительную, более подробную информацию по процессу. Затем анализ причин отклонений повторяется.

По итогам мониторинга и анализа причин отклонений владелец процесса:

• приступает к анализу необходимости корректирующих действий;

• принимает оперативные решения по изменению процесса (например, организация людей и ресурсов, привлечение дополнительных ресурсов).

6.5.3. Разработка и выполнение корректирующих действий

Владелец процесса выполняет корректирующие действия следующим образом (рис. 6.5.4).

_{Рис. 6.5.4. Выполнение корректирующих действий}

На шаге 1 он рассчитывает возможные потери, связанные с возникновением особой причины, повлекшей за собой отклонение от нормального хода процесса.

Шаг 2 – это определение возможных корректирующих мероприятий и расчет затрат на них.

На шаге 3 владелец процесса сравнивает сумму возможных потерь с объемом потенциальных затрат на выполнение корректирующих мероприятий. В случае если потери существенно ниже затрат, корректирующие действия выполнять не стоит. При этом владелец процесса фиксирует результаты анализа в журнале корректирующих действий (шаг 4а).

Если прогнозируемые потери выше затрат, то владелец процесса формирует план выполнения корректирующего мероприятия, уточняет требования по ресурсам, определяет, достаточно ли их в его распоряжении. Если нет, то владелец процесса согласует план с вышестоящим руководителем и получает от него необходимые ресурсы (шаг 5а). Вышестоящий руководитель может не согласовать план. В этом случае владелец процесса корректирует его и предоставляет на повторное рассмотрение либо отказывается от реализации корректирующего мероприятия.

На шаге 5 владелец процесса выполняет корректирующее мероприятие (лично управляет выполнением или контролирует его).

Проверка корректирующего мероприятия (устранены ли причины отклонений) происходит на шаге 6. Если причины устранены, владелец процессов фиксирует результаты в журнале (базе данных) – шаг 7. На этом цикл корректирующих действий завершается. Если причины не устранены, то владелец процесса разрабатывает новые корректирующие мероприятия либо (по согласованию с руководителем вышестоящего уровня) он отказывается от дальнейших попыток устранить причины отклонений.

6.5.4. Совершенствование процесса на основе цикла PDCA

Владелец процесса выполняет цикл непрерывного совершенствования процесса (цикл PDCA) следующим образом (рис. 6.5.5).

_{Рис. 6.5.5. Цикл непрерывного совершенствования процесса}

Шаг 1 – он получает целевые показатели по улучшению процесса (процессов) от вышестоящего руководителя (как правило, в рамках цикла планирования). Кроме того, владелец процесса анализирует факторы, воздействующие на процесс, выбирает из них приоритетные, анализирует причины отклонений (в том числе используя статистическую информацию о процессе).

На шаге 2 разрабатываются возможные мероприятия по улучшению процесса, формируется план мероприятий, уточняются требования по ресурсам, определяется достаточность ресурсов. Если их мало, то владелец процесса согласует план с вышестоящим руководителем и получает от него необходимые ресурсы (шаг 3а). Вышестоящий руководитель может не согласовать план. В этом случае владелец процесса корректирует план и предоставляет его на рассмотрение повторно.

На шаге 3 владелец процесса выполняет мероприятия по его совершенствованию.

Шаг 4 – это проверка, достигнуто ли улучшение процесса по заданным целевым показателям. Если да, то цикл завершается. Если улучшение не достигнуто (или достигнуто частично), владелец процесса разрабатывает новые мероприятия по совершенствованию. Цикл повторяется.

6.6. Список литературы

1. Репин В. В. Бизнес-процессы компании: построение, анализ, регламентация. – М.: Стандарты и качество, 2007.

2. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: Стандарты и качество, 2004.

3. Елиферов В. Г., Репин В. В. Бизнес-процессы. Регламентация и управление. – М.: Инфра-М, 2009.

4. Харрингтон Дж. Совершенство управления процессами. – М.: Стандарты и качество, 2007.

5. Деминг Э. Выход из кризиса. Новая парадигма управления людьми, системами и процессами. – М.: Альпина Бизнес Букс, Альпина Паблишер, 2009.

6. Уилер Д., Чамберс Д. Статистическое управление процессами. Оптимизация бизнеса с использованием контрольных карт Шухарта. – М.: Альпина Бизнес Букс, 2009.

7. Эккерсон У. Панели индикаторов как инструмент управления: ключевые показатели эффективности; мониторинг деятельности; оценка результатов. – М.: Альпина Бизнес Букс, 2007.

8. Уолш К. Ключевые показатели менеджмента. Как анализировать, сравнивать и контролировать данные, определяющие стоимость компании. – М.: Дело, 2001.

9. Каплан Р., Нортон Д. Награда за блестящую реализацию стратегии. – М.: Олимп-Бизнес, 2010.

Заключение

Итак, вы ознакомились с материалом книги. Надеюсь, что представленная информация оказалась полезной для практики внедрения процессного подхода. Затронуть все аспекты в одной работе невозможно^[135]. Эта книга – не исчерпывающее руководство на все случаи жизни. Важно, чтобы после ее прочтения вы поняли, над чем стоит серьезно задуматься, что необходимо проработать при внедрении процессного управления. Возможно, какие-то аспекты предметной области были раскрыты недостаточно подробно, какие-то узкие темы не рассматривались вовсе, что-то показалось спорным. Но я старался осветить наиболее важные проблемы, которые возникают на практике.

Прежде всего к ним относится отсутствие концепции внедрения процессного управления у собственников и руководителей компаний. Они стремятся что-то менять, слышали о технологиях, но как подойти к решению задачи – не знают. Материалы главы 1 дают ответы на эти вопросы.

Второй, исключительно важный, на мой взгляд, момент – это определение и управление сквозными процессами (глава 2). На этот счет существует много разных мнений, подчас не совсем адекватных. Надеюсь, что мне удалось предложить простой и понятный подход к работе со сквозными процессами компании. Убежден, что значительный экономический эффект может быть получен только в случае определения, анализа и оптимизации группы сквозных (межфункциональных) процессов.

Третий практически важный вопрос – построение системы бизнес-процессов компании. В книге предложен метод построения процессного дерева организации на основе анализа цепочек создания ценности. Надеюсь, что приведенный в главе 3 материал поможет вам системно построить работу с бизнес-процессами.

Четвертая группа вопросов, над которыми стоит задуматься читателю, – это создание системы работы по описанию процессов. Ни нотация, ни инструмент описания по отдельности не являются решающими факторами успеха. Нотаций много. Они разные. Инструменты тоже разные. Важно, чтобы нотация и инструмент не оказались факторами, препятствующими работе по описанию процессов, а само описание – уделом избранных бизнес-аналитиков. Я считаю, что предельно простое и понятное описание процессов должно стать рабочим инструментом руководителей и специалистов любого подразделения организации (а не только отдела развития или IT-службы).

В главе 5 предлагаются определение и структура системы стандартизации бизнес-процессов. Это попытка системного взгляда на вопросы работы с регламентирующими документами организации. Надеюсь, что материал будет иметь практическую ценность при создании регламентной базы вашей компании.

Еще один важный момент, который стоит отметить, – это процессы управления. К сожалению, в книгах и статьях о них говорится очень мало. Но описание и отладка процессов управления – важнейшая задача при внедрении процессного управления.

Надеюсь, что книга помогла сложить из разрозненных кусочков целостную картину методов и инструментов процессного управления. Теперь вы знаете, что нужно для внедрения процессного подхода, и сможете глубже изучить наиболее значимые его аспекты.

В заключение хочу еще раз обратить внимание собственников и руководителей на тот факт, что компания – это сложная социальная система. Успех проекта внедрения процессного подхода в первую очередь зависит от лидерства руководителей, развития управленческой команды, вовлечения персонала. Современные информационные технологии управления важны, но на первом месте – люди, творчески работающие над совершенствованием процессов.

Приложение 1
Система процессов APQC

В приложении представлен авторский перевод системы процессов организации APQC. Эта система процессов полезна как для освоения подходов к построению процессного дерева, так и для анализа и совершенствования системы процессов организации.

Система включает в себя 12 категорий процессов:

1. Развивать ви?дение и стратегию.

2. Развивать продукты/услуги и управлять ими.

3. Выполнять маркетинг и продавать продукты/услуги.

4. Поставлять продукты и оказывать услуги.

5. Управлять обслуживанием потребителей.

6. Развивать человеческий капитал (персонал) и управлять им.

7. Управлять информационными технологиями (IT).

8. Управлять финансовыми ресурсами.

9. Приобретать, возводить недвижимость и управлять ею.

10. Управлять охраной окружающей среды, здоровьем и безопасностью жизнедеятельности (EHS).

11. Управлять внешними связями.

12. Управлять знаниями, улучшениями и изменениями.

1. Развивать ви?дение и стратегию

1.1. Определять концепцию бизнеса и видение на долгосрочную перспективу

1.1.1. Оценивать внешнее окружение

1.1.1.1. Анализировать и оценивать конкуренцию

1.1.1.2. Выявлять экономические тренды

1.1.1.3. Выявлять политические и правовые факторы

1.1.1.4. Оценивать инновации в области новых технологий

1.1.1.5. Анализировать демографические характеристики

1.1.1.6. Выявлять социальные и культурные изменения

1.1.1.7. Выявлять экологические проблемы

1.1.2. Проводить мониторинг рынка и определять потребности и предпочтения потребителей

1.1.2.1. Проводить качественные/количественные оценки

1.1.2.2. Получать информацию о потребностях потребителей и оценивать ее

1.1.3. Осуществлять внутренний анализ

1.1.3.1. Анализировать показатели деятельности организации

1.1.3.2. Определять направления изменения существующих процессов

1.1.3.3. Анализировать системы и технологии

1.1.3.4. Анализировать финансовое состояние организации

1.1.3.5. Определять ключевые компетенции организации

1.1.4. Устанавливать стратегическое видение

1.1.4.1. Согласовывать интересы собственников на основе стратегического видения

1.1.4.2. Доводить стратегическое видение до собственников

1.2. Развивать стратегию бизнеса

1.2.1. Развивать общую миссию

1.2.1.1. Определять текущее состояние бизнеса

1.2.1.2. Формулировать миссию

1.2.1.3. Обсуждать миссию

1.2.2. Оценивать возможности достижения стратегических целей

1.2.2.1. Определять возможности достижения стратегических целей

1.2.2.2. Анализировать и оценивать влияние каждой возможности

1.2.2.3. Разрабатывать устойчивую стратегию

1.2.2.4. Разрабатывать стратегию поддержки и партнерства на мировом уровне

1.2.2.5. Разрабатывать стратегию минимизации и управления рисками

1.2.2.6. Разрабатывать стратегию бережливого производства/непрерывных улучшений

1.2.3. Выбирать стратегию бизнеса на долгосрочную перспективу

1.2.4. Координировать и упорядочивать функциональные и процессные стратегии

1.2.5. Создавать организационный дизайн (структура, управление, отчетность и др.)

1.2.5.1. Оценивать ширину и глубину организационной структуры

1.2.5.2. Осуществлять картирование бизнес-ролей и выполнять анализ создания ценности

1.2.5.3. Совершенствовать схемы процедур выполнения работы для исключения ручного труда

1.2.5.4. Проводить семинары по организационному перепроектированию

1.2.5.5. Проектировать взаимодействия между организационными единицами

1.2.5.6. Совершенствовать схемы распределения ответственности и выполнения работы для ключевых процессов

1.2.5.7. Оценивать возможность внедрения различных альтернатив

1.2.5.8. Изменять организацию

1.2.6. Разрабатывать и устанавливать цели организации

1.2.7. Определять стратегии для бизнес-единицы

1.3. Управлять стратегическими инициативами

1.3.1. Развивать стратегические инициативы

1.3.2. Оценивать стратегические инициативы

1.3.3. Выбирать стратегические инициативы

1.3.4. Устанавливать показатели управления (метрики) на верхнем уровне

2. Развивать продукты/услуги и управлять ими

2.1. Управлять портфелем продуктов/услуг

2.1.1. Оценивать эффективность существующих продуктов/услуг на фоне рыночных возможностей

2.1.2. Определять требования по развитию продуктов /услуг

2.1.2.1. Выявлять возможные улучшения существующих продуктов/услуг

2.1.2.2. Выявлять потенциально новые продукты/услуги

2.1.3. Выполнять исследования новых направлений

2.1.3.1. Выявлять новые технологии

2.1.3.2. Развивать новые технологии

2.1.3.3. Оценивать возможность интеграции новых передовых технологий в концепции продуктов/услуг

2.1.4. Подтверждать соответствие концепций продуктов/услуг стратегии бизнеса

2.1.4.1. Планировать и совершенствовать цели в области цены и качества

2.1.4.2. Ранжировать и выбирать концепции новых продуктов/услуг

2.1.4.3. Устанавливать цели по срокам развития

2.1.4.4. Планировать изменения в предложении продуктов/услуг

2.1.5. Управлять жизненным циклом продуктов/услуг

2.1.5.1. Вводить новые продукты/услуги

2.1.5.2. Избавляться от устаревшей продукции/услуг

2.1.5.3. Определять и совершенствовать показатели эффективности

2.1.6. Управлять информацией по продуктам/услугам

2.2. Развивать продукты/услуги

2.2.1. Проектировать, создавать и оценивать продукты/услуги

2.2.1.1. Выделять ресурсы для проекта создания продукта/услуги

2.2.1.2. Подготавливать возможности на уровне бизнеса и осуществлять техническое обеспечение

2.2.1.3. Разрабатывать проектную документацию по продуктам и услугам

2.2.1.4. Управлять проектной документацией

2.2.1.5. Проверять выполнение обязательных и рекомендательных внешних требований (законов, правил, стандартов)

2.2.1.6. Разрабатывать прототипы

2.2.1.7. Устранять проблемы качества и надежности

2.2.1.8. Выполнять внутреннее тестирование продуктов/услуг и оценивать их пригодность

2.2.1.9. Определять показатели эффективности проектирования и разработки

2.2.1.10. Налаживать сотрудничество при проектировании с поставщиками и производителями

2.2.2. Тестировать рынок для вывода новых или переработанных продуктов/услуг

2.2.2.1. Подготавливать подробный анализ рынка

2.2.2.2. Проводить опросы и интервьюировать потребителей

2.2.2.3. Определять окончательные характеристики продуктов/услуг и условия их применения

2.2.2.4. Завершать оформление технических требований

2.2.2.5. Определять требования к изменениям процессов поставки и производства

2.2.3. Осуществлять подготовку к производству

2.2.3.1. Разрабатывать и тестировать процессы производства и поставки продуктов и/или услуг

2.2.3.2. Проектировать и обеспечивать поставку необходимых материалов и оборудования

2.2.3.3. Внедрять и валидировать методологию или процесс производства

3. Выполнять маркетинг и продавать продукты/услуги

3.1. Анализировать возможности рынка и потребителей

3.1.1. Выполнять анализ информации о рынке и потребителях

3.1.1.1. Проводить исследования рынка и потребителей

3.1.1.2. Выявлять сегменты рынка

3.1.1.3. Анализировать рыночные и отраслевые тренды

3.1.1.4. Анализировать конкурирующие организации, конкурирующие/замещающие продукты

3.1.1.5. Оценивать существующие продукты/бренды

3.1.1.6. Оценивать внутренние и внешние условия бизнеса

3.1.2. Оценивать и приоритезировать рыночные возможности

3.1.2.1. Количественно оценивать рыночные возможности

3.1.2.2. Определять целевые сегменты

3.1.2.3. Приоритезировать рыночные возможности в соответствии с потенциальными возможностями и общей стратегией бизнеса

3.1.2.4. Валидировать возможности

3.2. Развивать рыночную стратегию

3.2.1. Определять предложение по цене и ценности для потребителя

3.2.1.1. Определять цену и позиционирование

3.2.1.2. Разрабатывать предложение ценности, включая позиционирование бренда для целевых сегментов

3.2.1.3. Проверять соответствие предложения ценности целевым сегментам

3.2.1.4. Разрабатывать новую систему продвижения бренда

3.2.2. Согласовывать стратегию ценообразования с предложением ценности

3.2.2.1. Устанавливать нормативы при ценообразовании продуктов/услуг

3.2.2.2. Утверждать стратегии/политику ценообразования

3.2.3. Определять стратегию по каналам сбыта и управлять ею

3.2.3.1. Оценивать параметры каналов сбыта и партнеров

3.2.3.2. Определять каналы сбыта в соответствии с целевыми сегментами

3.2.3.3. Выбирать каналы сбыта для целевых сегментов

3.3. Развивать стратегию продаж

3.3.1. Разрабатывать прогноз продаж

3.3.1.1. Собирать информацию по существующим и прошлым заказам

3.3.1.2. Анализировать тренды и структуру продаж

3.3.1.3. Формировать прогноз продаж

3.3.1.4. Анализировать прошедшие и планируемые мероприятия по продвижению и события

3.3.2. Развивать связи между торговыми партнерами/альянсами

3.3.2.1. Выявлять возможности вступления в альянсы

3.3.2.2. Разрабатывать программы по вступлению в альянсы и методы выбора и управления взаимосвязями

3.3.2.3. Выбирать альянсы

3.3.2.4. Развивать стратегии управления партнерами/альянсами

3.3.2.5. Устанавливать цели управления партнерами/альянсами

3.3.3. Устанавливать общие бюджеты продаж

3.3.3.1. Рассчитывать доход с продукта

3.3.3.2. Определять переменные затраты

3.3.3.3. Определять накладные расходы и постоянные затраты

3.3.3.4. Рассчитывать чистую прибыль

3.3.3.5. Создавать бюджет

3.3.4. Устанавливать цели и показатели для продаж

3.3.5. Устанавливать показатели оценки потребителей

3.4. Разрабатывать маркетинговые планы и управлять ими

3.4.1. Устанавливать цели, показатели и целевые значения показателей для продуктов в разрезе каналов сбыта/сегментов

3.4.2. Устанавливать маркетинговые бюджеты

3.4.2.1. Подтверждать соответствие плана маркетинга бизнес-стратегии

3.4.2.2. Определять затраты на маркетинг

3.4.2.3. Определять маркетинговый бюджет

3.4.3. Развивать и управлять рекламой через СМИ

3.4.3.1. Определять цели в области СМИ

3.4.3.2. Разрабатывать рекламные сообщения

3.4.3.3. Определять целевую аудиторию

3.4.3.4. Привлекать подрядчика в области СМИ

3.4.3.5. Развивать и осуществлять рекламную деятельность

3.4.3.6. Развивать и осуществлять другие маркетинговые кампании/программы

3.4.3.7. Оценивать эффективность маркетингового плана для бренда/продукта

3.4.4. Развивать систему ценообразования и управлять ею

3.4.4.1. Определять систему ценообразования на основе прогноза продаж в натуральном и стоимостном выражении

3.4.4.2. Осуществлять планирование цен

3.4.4.3. Оценивать эффективность системы ценообразования

3.4.4.4. Совершенствовать систему ценообразования по мере необходимости

3.4.5. Развивать деятельность по стимулированию продаж и управлять ею

3.4.5.1. Определять концепции стимулирования продаж

3.4.5.2. Разрабатывать план стимулирования продаж и тестировать его

3.4.5.3. Осуществлять деятельность по стимулированию продаж

3.4.5.4. Оценивать показатели эффективности деятельности по стимулированию продаж

3.4.5.5. Совершенствовать показатели эффективности деятельности по стимулированию продаж

3.4.5.6. Использовать накопленный опыт для будущей/планируемой деятельности по стимулированию потребителей

3.4.6. Отслеживать показатели управления потребителем

3.4.6.1. Определять значения лояльности потребителей и длительность деловых связей

3.4.6.2. Анализировать тенденцию изменения выручки по потребителям

3.4.6.3. Анализировать коэффициенты притока/оттока потребителей

3.4.6.4. Анализировать показатели оценки потребителей

3.4.6.5. Пересматривать стратегии, цели и планы показателей по потребителям

3.4.7. Развивать и управлять стратегией в области упаковки

3.4.7.1. Планировать стратегию в области упаковки

3.4.7.2. Тестировать возможности в области упаковки

3.4.7.3. Осуществлять стратегию в области упаковки

3.4.7.4. Совершенствовать упаковку

3.5. Разрабатывать планы по продажам и управлять ими

3.5.1. Создавать лидеров

3.5.1.1. Выявлять потенциальных потребителей

3.5.1.2. Выявлять лидеров

3.5.2. Управлять потребителями и состоянием расчетов

3.5.2.1. Разрабатывать план по продажам и состоянию расчетов

3.5.2.2. Управлять взаимоотношениями с потребителями

3.5.3. Управлять продажами

3.5.3.1. Осуществлять коммуникации по продажам

3.5.3.2. Осуществлять предпродажную деятельность

3.5.3.3. Закрывать сделки

3.5.3.4. Учитывать результаты процесса продаж

3.5.4. Управлять заказами

3.5.4.1. Принимать и проверять заказы на поставку

3.5.4.2. Собирать и хранить информацию по взаиморасчетам с потребителями

3.5.4.3. Определять годность продукта

3.5.4.4. Определять процесс исполнения заказа

3.5.4.5. Вводить заказы в систему и выявлять/осуществлять деятельность по перекрестным продажам/перепродажам

3.5.4.6. Обрабатывать невыполненные и обновленные заказы

3.5.4.7. Обрабатывать запросы по заказу, включая транзакции после выполнения заказа

3.5.5. Управлять менеджерами по продажам

3.5.5.1. Определять расстановку кадров

3.5.5.2. Устанавливать план стимулирования менеджеров по продажам

3.5.6. Управлять торговыми партнерами/альянсами

3.5.6.1. Проводить тренинги по продажам и продуктам для торговых партнеров/альянсов

3.5.6.2. Развивать прогноз сбыта за счет партнеров/альянсов

3.5.6.3. Договариваться с партнерами/альянсами о комиссионных вознаграждениях

3.5.6.4. Оценивать итоги партнерства/альянсов.

4. Поставлять продукты и оказывать услуги

4.1. Планировать и приобретать необходимые ресурсы (планирование цепочки поставок)

4.1.1. Развивать производственную стратегию и стратегию обеспечения материальными ресурсами

4.1.1.1. Определять производственные цели

4.1.1.2. Определять политику в области трудовых и материальных ресурсов

4.1.1.3. Определять политики в области аутсорсинга

4.1.1.4. Определять политику в области капитальных вложений в производство

4.1.1.5. Определять производственные мощности

4.1.1.6. Определять ограничения в области организации производства и поставок

4.1.1.7. Определять производственный процесс

4.1.1.8. Определять размещение производственного оборудования и инфраструктуры

4.1.2. Управлять спросом на продукты/услуги

4.1.2.1. Разрабатывать прогнозы по основным направлениям

4.1.2.2. Сотрудничать с потребителями

4.1.2.3. Разрабатывать согласованный общий прогноз

4.1.2.4. Определять возможности поставки

4.1.2.5. Проводить мониторинг деятельности с учетом прогноза и пересматривать его

4.1.2.6. Оценивать и пересматривать метод прогнозирования

4.1.2.7. Измерять точность прогноза

4.1.3. Разрабатывать план потребности в материальных ресурсах

4.1.3.1. Создавать план производства без учета запасов материалов

4.1.3.2. Сотрудничать с поставщиками и заключать договоры с производителями

4.1.3.3. Выявлять наиболее важные материалы и мощности поставщиков по их поставке

4.1.3.4. Проводить мониторинг спецификаций на материалы

4.1.3.5. Разрабатывать план производства с учетом запасов и поставок

4.1.3.6. Определять производственный баланс

4.1.4. Создавать и управлять графиком производства

4.1.4.1. Разрабатывать план на уровне участка (подразделения)

4.1.4.2. Управлять запасами незавершенного производства

4.1.4.3. Сотрудничать с поставщиками

4.1.4.4. Разрабатывать и исполнять график работы участка (подразделения)

4.1.5. Планировать требования по дистрибуции

4.1.5.1. Определять возможности поставки

4.1.5.2. Хранить первичную информацию

4.1.5.3. Определять требования к складу готовой продукции в пункте назначения

4.1.5.4. Рассчитывать (определять) требования в пункте назначения

4.1.5.5. Рассчитывать консолидацию товаров при отгрузке

4.1.5.6. Управлять совместным планированием возобновления запасов

4.1.5.7. Управлять требованиями для партнеров

4.1.5.8. Рассчитывать план отправки товаров в место назначения

4.1.5.9. Управлять получением плана отправки

4.1.5.10. Рассчитывать планы по разгрузке/погрузке в месте назначения

4.1.5.11. Управлять планом разгрузки/погрузки для партнеров

4.1.5.12. Управлять затратами на поставку

4.1.5.13. Управлять использованием производственных мощностей

4.1.6. Устанавливать ограничения при планировании дистрибуции

4.1.6.1. Устанавливать ограничения по структуре центра дистрибуции

4.1.6.2. Устанавливать ограничения по управлению запасами

4.1.6.3. Устанавливать ограничения по транспортировке

4.1.7. Пересматривать политики в области дистрибуции

4.1.7.1. Пересматривать сеть дистрибуции

4.1.7.2. Устанавливать важнейшие связи

4.1.7.3. Устанавливать политики в области гибкого развертывания

4.1.8. Оценивать эффективность планирования дистрибуции

4.1.8.1. Устанавливать подходящие показатели (метрики) эффективности

4.1.8.2. Устанавливать периодичность мониторинга

4.1.8.3. Рассчитывать показатели эффективности

4.1.8.4. Выявлять тренды изменения эффективности

4.1.8.5. Анализировать отставания по эффективности на основе бенчмаркинга

4.1.8.6. Составлять необходимые отчеты

4.1.8.7. Разрабатывать план по улучшению эффективности

4.1.9. Разрабатывать стандарты и процедуры в области качества

4.1.9.1. Устанавливать цели в области качества

4.1.9.2. Разрабатывать процедуры контроля стандартов

4.1.9.3. Распространять спецификации в области качества

4.2. Обеспечивать материальными ресурсами и услугами

4.2.1. Развивать стратегии снабжения

4.2.1.1. Разрабатывать план снабжения

4.2.1.2. Выявлять требования по закупкам

4.2.1.3. Развивать стратегию управления запасами

4.2.1.4. Приводить в соответствие потребности и возможности по поставкам

4.2.1.5. Анализировать структуру расходов компании

4.2.1.6. Искать возможности повышения эффективности и ценности

4.2.1.7. Сотрудничать с поставщиками для выявления возможностей поставок

4.2.2. Отбирать поставщиков и заключать/поддерживать договорные отношения

4.2.2.1. Отбирать поставщиков

4.2.2.2. Сертифицировать и валидировать поставщиков

4.2.2.3. Вести переговоры по заключению договоров

4.2.2.4. Управлять договорами

4.2.3. Заказывать материалы и услуги

4.2.3.1. Обрабатывать/пересматривать заявки

4.2.3.2. Акцептовать заявки

4.2.3.3. Запрашивать/отслеживать квоты поставщиков

4.2.3.4. Создавать/распределять заказы на поставку

4.2.3.5. Обрабатывать заказы и удовлетворять запросы

4.2.3.6. Учитывать приход товара

4.2.3.7. Обрабатывать/изучать исключительные ситуации

4.2.4. Оценивать и развивать поставщиков

4.2.4.1. Проводить мониторинг информации о поставщике и управлять ею

4.2.4.2. Обрабатывать/анализировать информацию об эффективности снабжения и деятельности поставщика

4.2.4.3. Поддерживать процессы производства и хранения.

4.2.4.4. Осуществлять мониторинг качества поставленных продуктов

4.3. Создавать/производить/поставлять продукт

4.3.1. Составлять календарный график производства

4.3.1.1. Разрабатывать план по объему производства

4.3.1.2. Разрабатывать подробный календарный график

4.3.1.3. Составлять график заказов на продукцию и определять партии

4.3.1.4. Выпускать график заказов и производства партий

4.3.2. Производить продукт

4.3.2.1. Управлять запасами сырья

4.3.2.2. Исполнять детальный график производства на линиях

4.3.2.3. Переделывать дефектные изделия

4.3.2.4. Оценивать эффективность производства

4.3.3. Планировать график и осуществлять обслуживание оборудования

4.3.3.1. Определять процесс планового технического обслуживания

4.3.3.2. Определять процесс внепланового обслуживания оборудования

4.3.3.3. Осуществлять техническое обслуживание и ремонт

4.3.3.4. Калибровать контрольно-измерительное оборудование

4.3.3.5. Отчитываться о результатах технического обслуживания

4.3.4. Осуществлять контроль качества

4.3.4.1. Осуществлять контроль с помощью стандартной процедуры

4.3.4.2. Записывать (фиксировать) результаты контроля

4.3.5. Обеспечивать производственный учет и отслеживаемость серий

4.3.5.1. Устанавливать систему нумерации серий

4.3.5.2. Определять возможность использования серий

4.4. Предоставлять услуги потребителю

4.4.1. Обеспечивать особые требования для отдельных потребителей

4.4.1.1. Обрабатывать требования потребителей

4.4.1.2. Создавать профиль пользователя

4.4.1.3. Формировать заказ на выполнение услуг

4.4.2. Выявлять и планировать ресурсы, необходимые для обеспечения выполнения требований по сервису

4.4.2.1. Создавать план потребности и график по использованию ресурсов

4.4.2.2. Создавать график исполнения заказов на услугу

4.4.2.3. Разрабатывать заказ на выполнение услуги

4.4.3. Оказывать услуги особым заказчикам

4.4.3.1. Организовывать график выполнения ежедневных заказов на услугу

4.4.3.2. Доставлять ресурсы

4.4.3.3. Управлять результатом оказания услуги

4.4.4. Комплексно валидировать услугу на стадии завершения

4.4.5. Гарантировать качество услуг

4.4.5.1. Выявлять завершенные заказы для получения обратной связи

4.4.5.2. Выявлять незавершенные заказы и некачественно оказанные услуги

4.4.5.3. Получать обратную связь от заказчиков по предоставленным услугам

4.4.5.4. Обрабатывать отклики заказчика на предоставленные услуги

4.5. Управлять логистикой и складским хранением

4.5.1. Определять стратегию в области логистики

4.5.1.1. Переводить требования по оказанию услуг потребителю в требования по логистике

4.5.1.2. Проектировать логистическую сеть

4.5.1.3. Уведомлять о потребностях в привлечении сторонних ресурсов

4.5.1.4. Развивать и поддерживать политику оказания услуг

4.5.1.5. Оптимизировать графики и затраты на транспортировку

4.5.1.6. Определять ключевые показатели эффективности

4.5.2. Планировать поток поступающих материалов

4.5.2.1. Планировать приемку поступающих материалов

4.5.2.2. Управлять потоком поступающих материалов

4.5.2.3. Проводить мониторинг эффективности поставок материалов

4.5.2.4. Управлять потоком возвращенных продуктов

4.5.3. Осуществлять складские операции

4.5.3.1. Отслеживать операции по хранению

4.5.3.2. Получать, проверять и хранить данные о поставках материалов

4.5.3.3. Отслеживать наличие продукта

4.5.3.4. Отбирать, упаковывать и отгружать продукт для доставки

4.5.3.5. Отслеживать соблюдение стандартов при хранении

4.5.3.6. Отслеживать эффективность хранения и отгрузки, выполняемых другими компаниями

4.5.3.7. Управлять запасами готовой продукции

4.5.4. Производить транспортировку отгружаемых материалов

4.5.4.1. Планировать, транспортировать и доставлять отгружаемый продукт

4.5.4.2. Отслеживать эффективность перевозчиков

4.5.4.3. Управлять транспортным парком

4.5.4.4. Обрабатывать и аудировать счета и документацию перевозчиков

4.5.5. Управлять возвратами; управлять логистикой по возвратам

4.5.5.1. Разрешать возвраты и обрабатывать возвращенный товар

4.5.5.2. Осуществлять логистику по возвратам

4.5.5.3. Осуществлять деятельность по утилизации

4.5.5.4. Осуществлять и управлять претензионной работой

4.5.5.5. Управлять ремонтом/восстановлением и возвратом потребителям/на склад

5. Управлять обслуживанием потребителей

5.1. Развивать стратегию заботы о потребителях/обслуживания потребителей

5.1.1. Развивать сегментацию/приоритезацию обслуживания потребителей (например, ценовые сегменты)

5.1.1.1. Проводить анализ существующих потребителей

5.1.1.2. Анализировать обратную связь с целью выяснения нужд потребителей

5.1.2. Определять принципы и процедуры обслуживания потребителей

5.1.3. Устанавливать уровни обслуживания для потребителей

5.2. Планировать деятельность по обслуживанию потребителей и управлять ею

5.2.1. Планировать деятельность обслуживающего персонала и управлять им

5.2.1.1. Прогнозировать количество контактов при обслуживании потребителей

5.2.1.2. Составлять график работы обслуживающего персонала

5.2.1.3. Отслеживать привлечение обслуживающего персонала

5.2.1.4. Проводить мониторинг и оценивать качество взаимодействия с потребителями вместе с представителями по обслуживанию

5.2.2. Управлять требованиями/запросами в области обслуживания потребителей

5.2.2.1. Получать требования/запросы потребителей

5.2.2.2. Распределять требования/запросы потребителей

5.2.2.3. Отвечать на требования/запросы потребителей

5.2.3. Управлять жалобами потребителей

5.2.3.1. Получать жалобы потребителей

5.2.3.2. Распределять жалобы потребителей

5.2.3.3. Реагировать на жалобы (принимать решения по жалобам) потребителей

5.2.3.4. Отвечать на жалобы потребителей

5.3. Измерять и оценивать деятельность по обслуживанию потребителей

5.3.1. Измерять удовлетворенность потребителей путем обработки их требований/запросов

5.3.1.1. Собирать и получать послепродажные отклики потребителей на продукты и услуги

5.3.1.2. Получать послепродажные отклики потребителей на эффективность рекламы

5.3.1.3. Анализировать информацию по удовлетворенности продуктами и услугами и выявлять возможности улучшений

5.3.1.4. Предоставлять отклики потребителей на продукты/услуги руководству по производству продукта

5.3.2. Измерять удовлетворенность потребителей путем обработки и разрешения их жалоб

5.3.2.1. Получать отклики потребителей на обработку и разрешение их жалоб

5.3.2.2. Анализировать информацию по жалобам потребителей и выявлять возможности улучшений

5.3.3. Измерять удовлетворенность потребителей продуктами/услугами

5.3.3.1. Собирать и получать послепродажные отклики потребителей на продукты/услуги

5.3.3.2. Получать послепродажные отклики потребителей на эффективность рекламы

5.3.3.3. Анализировать информацию по удовлетворенности продуктами/услугами и выявлять возможности улучшений

5.3.3.4. Предоставлять отклики потребителей на продукты/услуги руководству по производству продукта

6. Развивать человеческий капитал (персонал) и управлять им

6.1. Развивать HR-планирование, политики и стратегии и управлять ими

6.1.1. Развивать HR-стратегию

6.1.1.1. Выявлять стратегические потребности в области HR

6.1.1.2. Определять бизнес-роли и ответственность персонала

6.1.1.3. Устанавливать затраты на персонал

6.1.1.4. Устанавливать показатели оценки персонала

6.1.1.5. Информировать персонал об HR-стратегии

6.1.2. Разрабатывать и реализовывать планы в области HR

6.1.2.1. Собирать квалификационные требования в соответствии с корпоративной стратегией и рыночной средой

6.1.2.2. Планировать требования по обеспечению персоналом подразделений/компании в целом

6.1.2.3. Развивать систему оплаты труда

6.1.2.4. Развивать план по наставничеству

6.1.2.5. Развивать план диверсификации персонала

6.1.2.6. Развивать другие программы в области HR

6.1.2.7. Развивать HR-политики

6.1.2.8. Управлять HR-политиками

6.1.2.9. Планировать льготы для персонала

6.1.2.10. Развивать стратегию для HR-систем/технологий/программного обеспечения

6.1.2.11. Развивать модели HR-стратегии

6.1.3. Осуществлять мониторинг и корректировать планы

6.1.3.1. Измерять достижение целей

6.1.3.2. Измерять вклад в стратегию бизнеса

6.1.3.3. Уведомлять собственников о корректировках планов

6.1.3.4. Определять добавленную ценность от управления HR

6.1.3.5. Анализировать и пересматривать HR-планы

6.2. Искать, принимать и отбирать сотрудников

6.2.1. Создавать и развивать требования к сотрудникам

6.2.1.1. Согласовывать штатное расписание с планом по численности сотрудников и стратегиями бизнес-единицы/потребностями в ресурсах

6.2.1.2. Развивать и открывать новые вакансии

6.2.1.3. Совершенствовать должностные инструкции

6.2.1.4. Размещать вакансии

6.2.1.5. Управлять размещением вакансий на внутреннем/внешнем сайте

6.2.1.6. Менять/обновлять вакансии

6.2.1.7. Уведомлять об изменениях по вакансиям руководителя по HR

6.2.1.8. Управлять сроком размещения вакансии

6.2.2. Искать/принимать кандидатов

6.2.2.1. Определять методы поиска

6.2.2.2. Осуществлять деятельность/проводить мероприятия по поиску

6.2.2.3. Управлять контрагентами, осуществляющими поиск

6.2.3. Проводить встречи и отбирать кандидатов

6.2.3.1. Выявлять и применять инструменты отбора кандидатов

6.2.3.2. Интервьюировать кандидатов

6.2.3.3. Тестировать кандидатов

6.2.3.4. Выбирать и отклонять кандидатов

6.2.4. Управлять проверкой соответствия кандидатов перед назначением на должность

6.2.4.1. Подбирать информацию о кандидате

6.2.4.2. Осуществлять предварительную проверку перед наймом

6.2.4.3. Рекомендовать/не рекомендовать кандидата

6.2.5. Управлять новым/повторным наймом

6.2.5.1. Разрабатывать и делать предложение о сотрудничестве

6.2.5.2. Вести переговоры на основе предложения

6.2.5.3. Принимать кандидата

6.2.6. Отслеживать кандидатов

6.2.6.1. Создавать учетную карточку претендента

6.2.6.2. Управлять/отслеживать информацию о претенденте

6.2.6.3. Архивировать и хранить учетные карточки претендентов, не принятых на работу

6.3. Развивать и консультировать сотрудников

6.3.1. Управлять ориентированием сотрудников

6.3.1.1. Создавать/поддерживать программы адаптации для новых сотрудников

6.3.1.2. Представлять новых сотрудников руководителям

6.3.1.3. Вводить в курс дела

6.3.1.4. Оценивать эффективность системы адаптации сотрудников

6.3.2. Управлять эффективностью персонала

6.3.2.1. Определять цели по эффективности

6.3.2.2. Анализировать, оценивать и управлять эффективностью персонала

6.3.2.3. Оценивать и корректировать программу по повышению эффективности

6.3.3. Управлять коммуникациями с персоналом

6.3.3.1. Управлять охраной здоровья и охраной труда

6.3.3.2. Управлять трудовыми отношениями

6.3.3.3. Управлять заключением коллективного трудового договора

6.3.3.4. Управлять деятельность в области трудовых союзов

6.3.4. Управлять развитием сотрудников

6.3.4.1. Развивать планы по управлению компетенциями

6.3.4.2. Определять нормативы по развитию персонала

6.3.4.3. Развивать карьерные планы сотрудников

6.3.4.4. Управлять развитием навыков сотрудников

6.3.5. Развивать и обучать сотрудников

6.3.5.1. Согласовывать требования по развитию сотрудников и организации

6.3.5.2. Развивать компетенции

6.3.5.3. Определять потребности в обучении путем анализа необходимых и имеющихся навыков

6.3.5.4. Разрабатывать, организовывать и управлять программами обучения для сотрудников и руководства

6.4. Премировать и удерживать сотрудников

6.4.1. Развивать программы премирования, признания и мотивации сотрудников и управлять ими

6.4.1.1. Развивать план и структуру заработной платы/компенсаций

6.4.1.2. Развивать план денежного вознаграждения, льгот и компенсаций (соцпакет)

6.4.1.3. Выполнять сравнительный анализ льгот, компенсаций и денежного вознаграждения

6.4.1.4. Выявлять требования по компенсациям, основываясь на политике выплат, финансовой и кадровой политике

6.4.1.5. Управлять выплатой компенсаций и премий сотрудникам

6.4.1.6. Премировать и мотивировать сотрудников

6.4.2. Обеспечивать льготы и компенсации и управлять ими

6.4.2.1. Разрабатывать программу льгот и компенсаций для сотрудников

6.4.2.2. Управлять регистрацией льгот и компенсаций

6.4.2.3. Обрабатывать претензии

6.4.2.4. Согласовывать льготы и компенсации между собой

6.4.3. Управлять поддержкой и удержанием сотрудников

6.4.3.1. Разрабатывать программы для обеспечения баланса между работой и частной жизнью сотрудников

6.4.3.2. Разрабатывать системы поддержки семьи

6.4.3.3. Пересматривать показатели удержания и мотивации сотрудников

6.4.3.4. Пересматривать план выплаты компенсаций

6.4.4. Управлять фондом заработной платы

6.5. Производить перемещения и увольнять сотрудников

6.5.1. Управлять процессом повышения и понижения в должности

6.5.2. Управлять аттестацией сотрудников

6.5.3. Управлять процессом увольнения

6.5.4. Управлять отпусками

6.5.5. Осуществлять трудоустройство уволенных сотрудников

6.5.6. Управлять перемещением персонала

6.5.7. Перемещать сотрудников и управлять назначениями на должность

6.5.8. Управлять сокращением и увольнением персонала

6.5.9. Управлять иностранными специалистами

6.5.10. Управлять процессом перемещения сотрудников

6.6. Управлять информацией о сотрудниках

6.6.1. Управлять процессами отчетности (подачи сведений)

6.6.2. Управлять процессом запроса информации о сотрудниках

6.6.3. Поддерживать данные о сотрудниках и управлять ими

6.6.4. Управлять программным обеспечением в области управления персоналом (HRIS)

6.6.5. Совершенствовать показатели оценки сотрудников и управлять ими

6.6.6. Управлять посещаемостью

6.6.7. Управлять коммуникацией сотрудников

6.6.7.1. Развивать план коммуникации с сотрудниками

6.6.7.2. Управлять/собирать предложения сотрудников и проводить исследования среди персонала

6.6.7.3. Управлять жалобами сотрудников

6.6.7.4. Делать коммуникации публичными

7. Управлять информационными технологиями (IT)

7.1. Управлять бизнесом в сфере информационных технологий

7.1.1. Развивать IT-стратегию компании

7.1.1.1. Формировать стратегическую информацию

7.1.1.2. Выявлять IT-потребности компании на долгосрочную перспективу вместе с собственниками (учредителями)

7.1.1.3. Определять стратегические стандарты, направления и принципы развития

7.1.1.4. Определять и утверждать стандарты IT-архитектуры и развития информационных технологий

7.1.1.5. Определять стратегических поставщиков IT

7.1.1.6. Утверждать структуру и процессы управления информационными технологиями

7.1.1.7. Создавать стратегический план для поддержки бизнес-целей

7.1.2. Определять корпоративную архитектуру

7.1.2.1. Утверждать определение корпоративной архитектуры

7.1.2.2. Верифицировать методику поддержки корпоративной архитектуры

7.1.2.3. Поддерживать соответствие корпоративной архитектуры

7.1.2.4. Выполнять функции центра обмена информацией в сфере IT-инноваций и изучения информационных технологий

7.1.2.5. Управлять корпоративной архитектурой

7.1.3. Управлять IT-портфелем

7.1.3.1. Утверждать IT-портфель

7.1.3.2. Анализировать и оценивать ценность IT-портфеля для компании

7.1.3.3. Обеспечивать ресурсами в соответствии со стратегическими приоритетами

7.1.4. Выполнять исследования в области IT и инноваций

7.1.4.1. Исследовать технологии для инноваций IT-сервисов/решений

7.1.4.2. Переходить на реально работающие технологии в области IT-сервисов/решений

7.1.5. Осуществлять управление финансами с помощью информационных технологий

7.1.5.1. Развивать и поддерживать IT-сервисы/решения для обеспечения прозрачности затрат

7.1.5.2. Устанавливать и поддерживать процессы учета

7.1.5.3. Управлять бюджетами проектов на основе контрольных точек

7.1.6. Оценивать ценность и эффективность IT для бизнеса и доводить эту информацию до сотрудников

7.1.6.1. Утверждать ключевые показатели эффективности и проводить их мониторинг

7.1.6.2. Оценивать эффективность IT-плана

7.1.6.3. Информировать о ценности информационных технологий

7.1.7. Осуществлять управление персоналом в области IT

7.1.7.1. Развивать IT-руководство и персонал

7.1.7.2. Управлять эффективностью работы IT-персонала

7.1.8. Управлять поставщиками IT-услуг и IT-договорами

7.1.8.1. Развивать стратегии осуществления доставок в области IT

7.1.8.2. Вести переговоры с поставщиками

7.1.8.3. Утверждать и поддерживать взаимосвязи с поставщиками

7.1.8.4. Оценивать эффективность поставщиков

7.1.8.5. Оценивать эффективность договоров

7.2. Развивать взаимосвязи с потребителями информационных технологий и управлять ими

7.2.1. Развивать стратегию IT-сервисов/решений

7.2.1.1. Изучать IT-сервисы/решения для приведения их в соответствие с требованиями бизнеса и пользователей

7.2.1.2. Переводить требования бизнеса и пользователей в требования к IT-сервисам/решениям

7.2.1.3. Определять стратегические инициативы в сфере IT-сервисов/решений

7.2.1.4. Согласовывать стратегии с внутренними собственниками (учредителями) для обеспечения соответствия

7.2.1.5. Оценивать и выбирать стратегические инициативы в сфере IT-сервисов/решений

7.2.2. Развивать и управлять уровнем IT-сервисов

7.2.2.1. Создавать и поддерживать каталог IT-сервисов/решений

7.2.2.2. Устанавливать и поддерживать соглашения об уровнях IT-сервиса

7.2.2.3. Оценивать и отчитываться по результатам выполнения уровней сервиса

7.2.2.4. Обсуждать возможности повышения уровней IT-сервиса

7.2.3. Осуществлять управление спросом на IT-сервисы

7.2.3.1. Анализировать потребление и использование IT-сервисов/решений

7.2.3.2. Развивать и осуществлять мотивационные программы, повышающие эффективность потребления

7.2.3.3. Развивать прогноз для IT-сервисов/решений в количественном и стоимостном выражении

7.2.4. Управлять удовлетворенностью потребителей информационных технологий

7.2.4.1. Собирать данные по удовлетворенности потребителей и анализировать их

7.2.4.2. Оценивать и обсуждать модели удовлетворенности потребителей

7.2.4.3. Инициировать улучшения на основе анализа моделей удовлетворенности потребителей

7.2.5. Выполнять маркетинг IT-сервисов/решений

7.2.5.1. Развивать маркетинговую стратегию в сфере IT-сервисов/решений

7.2.5.2. Развивать стратегию работы с потребителями информационных технологий и управлять ею

7.2.5.3. Управлять рекламными кампаниями в сфере IT-сервисов/решений

7.2.5.4. Обрабатывать и отслеживать заказы в сфере IT-сервисов/решений

7.3. Управлять устойчивостью бизнеса и рисками

7.3.1. Развивать устойчивость бизнеса и управлять ею

7.3.1.1. Развивать стратегию устойчивости бизнеса

7.3.1.2. Осуществлять непрерывное операционное планирование

7.3.1.3. Непрерывно тестировать бизнес-операции

7.3.1.4. Непрерывно поддерживать бизнес-операции

7.3.2. Развивать соблюдение нормативов и управлять им

7.3.2.1. Развивать стратегию соблюдения нормативов

7.3.2.2. Устанавливать систему контроля соблюдения нормативов

7.3.2.3. Управлять соблюдением нормативов при выполнении корректирующих действий

7.3.3. Осуществлять управление совокупным риском

7.3.3.1. Развивать стратегию и подход к управлению совокупным риском

7.3.3.2. Управлять совокупным риском

7.3.4. Развивать и осуществлять систему контроля безопасности, конфиденциальности и защиты информации

7.3.4.1. Утверждать стратегии и уровни информационной безопасности, конфиденциальности и защиты информации

7.3.4.2. Тестировать, оценивать и осуществлять систему контроля информационной безопасности, конфиденциальности и защиты информации

7.4. Управлять корпоративной информацией

7.4.1. Развивать стратегии управления информацией и контентом

7.4.1.1. Анализировать потребности управления информацией и контентом и роль IT-сервисов в осуществлении бизнес-стратегии

7.4.1.2. Оценивать последствия применения новых технологий в управлении информацией и контентом

7.4.1.3. Выявлять и приоритезировать действия по управлению информацией и контентом

7.4.2. Определять архитектуру корпоративной информации

7.4.2.1. Определять структуру информации, групповую структуру, логические взаимосвязи и ограничения, таксономию и возможные отклонения

7.4.2.2. Определять требования доступа к информации

7.4.2.3. Устанавливать депозитарное хранение данных

7.4.2.4. Управлять изменениями архитектуры хранения данных

7.4.3. Управлять источниками информации

7.4.3.1. Определять стандарты и политики в области корпоративной информации/данных

7.4.3.2. Развивать и осуществлять управление данными и контентом

7.4.4. Осуществлять управление корпоративными данными и контентом

7.4.4.1. Определять источники и места хранения контента

7.4.4.2. Управлять техническими интерфейсами для пользователей контента

7.4.4.3. Управлять сохранением, проверкой и удалением корпоративной информации

7.5. Развивать и поддерживать IT-решения

7.5.1. Развивать стратегию развития информационных технологий

7.5.1.1. Утверждать стратегию поставок для развития информационных технологий

7.5.1.2. Определять стандарты в области процессов, методологии и инструментов развития

7.5.1.3. Выбирать методологии и инструменты развития

7.5.2. Осуществлять планирование жизненного цикла IT-сервисов/решений

7.5.2.1. Планировать развитие новых требований

7.5.2.2. Планировать расширения выполняемых функций

7.5.2.3. Развивать план жизненного цикла для IT-сервисов/ решений

7.5.3. Развивать и поддерживать архитектуру IT-сервисов/решений

7.5.3.1. Создавать архитектуру IT-сервисов/решений

7.5.3.2. Пересматривать архитектуру IT-сервисов/решений

7.5.3.3. Прекращать действие устаревшей архитектуры IT-сервисов/решений

7.5.4. Создавать IT-сервисы/решения

7.5.4.1. Анализировать подтвержденные требования

7.5.4.2. Разрабатывать IT-сервисы/решения

7.5.4.3. Получать/развивать компоненты IT-сервисов/решений

7.5.4.4. Готовить ресурсы для создания IT-сервисов/решений

7.5.4.5. Тестировать IT-сервисы/решения

7.5.4.6. Подтверждать одобрение потребителей

7.5.5. Поддерживать IT-сервисы/решения

7.5.5.1. Анализировать требования к обслуживанию/улучшениям и выполнять оценку несоответствий

7.5.5.2. Разрабатывать изменения для существующих IT-сервисов/решений

7.5.5.3. Получать/развивать измененные компоненты IT-сервисов/решений

7.5.5.4. Тестировать изменения IT-сервисов/решений

7.5.5.5. Прекращать использование IT-сервисов/решений

7.6. Развертывать (использовать) IT-решения

7.6.1. Развивать стратегию развертывания информационных технологий

7.6.1.1. Утверждать политики изменения IT-сервисов/решений

7.6.1.2. Определять стандарты в области процессов, методик и инструментов развертывания

7.6.1.3. Выбирать методологии и инструменты развертывания

7.6.2. Планировать и осуществлять изменения

7.6.2.1. Планировать развертывание изменений

7.6.2.2. Доводить изменения до собственников (учредителей)

7.6.2.3. Управлять графиком изменений

7.6.2.4. Обучать пользователей, которых коснулись изменения

7.6.2.5. Распространять и инсталлировать изменение

7.6.2.6. Верифицировать (подтверждать) изменение

7.6.3. Планировать версии и управлять ими

7.6.3.1. Анализировать и координировать разработку и приемку версии

7.6.3.2. Планировать вывод версии

7.6.3.3. Распространять и инсталлировать версию

7.6.3.4. Верифицировать (проверять) версию

7.7. Поставлять и поддерживать IT-сервисы

7.7.1. Развивать стратегию поставки IT-сервисов/решений

7.7.1.1. Утверждать стратегию закупки в области информационных технологий

7.7.1.2. Определять стандарты в области процессов, методики и инструменты поставки

7.7.1.3. Выбирать методологии и инструменты поставки.

7.7.2. Развивать стратегию IT-поддержки

7.7.2.1. Утверждать стратегию поставки для IT-поддержки

7.7.2.2. Определять услуги IT-поддержки

7.7.3. Управлять ресурсами информационной инфраструктуры

7.7.3.1. Управлять IT-обеспечением и ресурсами

7.7.3.2. Управлять возможностями IT-ресурсов

7.7.4. Управлять операциями информационной инфраструктуры

7.7.4.1. Поставлять IT-сервисы/решения

7.7.4.2. Оказывать услуги по поддержке IT-операций

7.7.5. Поддерживать IT-услуги и решения

7.7.5.1. Управлять доступностью системы

7.7.5.2. Управлять возможностями

7.7.5.3. Управлять резервными средствами/средствами восстановления

7.7.5.4. Управлять эффективностью и возможностями

7.7.5.5. Управлять инцидентами (ошибками)

7.7.5.6. Управлять проблемами

7.7.5.7. Управлять запросами

7.8. Управлять знаниями в области информационных технологий

7.8.1. Развивать стратегию управления знаниями в сфере информационных технологий

7.8.1.1. Анализировать потребности в знаниях в сфере информационных технологий

7.8.1.2. Анализировать существующий поток знаний в области информационных технологий

7.8.1.3. Координировать стратегию и роли с корпоративной функцией управления знаниями

7.8.1.4. Планировать действия и приоритеты в управлении знаниями в области информационных технологий

7.8.2. Управлять картой знаний в области информационных технологий

7.8.2.1. Определять элементы знаний, логические взаимосвязи и ограничения и действующие правила

7.8.2.2. Выявлять источники и хранилища (архивы) знаний в области информационных технологий

7.8.2.3. Выявлять возможности обмена знаниями в области информационных технологий

7.8.2.4. Определять процессы и подходы в сфере IT-знаний

7.8.3. Управлять жизненным циклом знаний в области информационных технологий

7.8.3.1. Собирать элементы знаний из источников знаний в сфере информационных технологий

7.8.3.2. Оценивать, создавать и кодифицировать элементы знаний

7.8.3.3. Использовать (развертывать) кодифицированные знания в области информационных технологий

7.8.3.4. Обновлять и удалять знания в области информационных технологий

7.8.3.5. Оценивать и улучшать стратегии и процессы управления знаниями в области информационных технологий

8. Управлять финансовыми ресурсами

8.1. Осуществлять управленческий учет и планирование

8.1.1. Осуществлять планирование/бюджетирование/прогнозирование

8.1.1.1. Развивать и поддерживать политики/процедуры бюджетирования

8.1.1.2. Подготавливать периодические бюджеты и планы

8.1.1.3. Подготавливать периодические финансовые прогнозы

8.1.2. Учитывать и контролировать затраты

8.1.2.1. Учитывать запасы

8.1.2.2. Анализировать себестоимость продукции

8.1.2.3. Калькулировать себестоимость

8.1.2.4. Проводить анализ отклонений

8.1.2.5. Предоставлять отчет о рентабельности

8.1.3. Осуществлять управление затратами

8.1.3.1. Определять ключевые носители затрат

8.1.3.2. Оценивать (измерять) носителей затрат

8.1.3.3. Определять критические операции

8.1.3.4. Управлять развертыванием и использованием полезных свойств

8.1.4. Оценивать финансовые показатели и управлять ими

8.1.4.1. Оценивать доходность клиента и рентабельность продукта

8.1.4.2. Оценивать новые продукты

8.1.4.3. Определять затраты по жизненному циклу

8.1.4.4. Оптимизировать соответствие клиентов и ассортимента продукции

8.1.4.5. Отслеживать эффективность по новым клиентам/продуктам

8.1.4.6. Определять показатели эффективности на основе метода ABC^[136]

8.1.4.7. Управлять постоянными улучшениями в области затрат

8.2. Осуществлять учет доходов

8.2.1. Осуществлять кредитование потребителей

8.2.1.1. Устанавливать кредитные политики

8.2.1.2. Анализировать/подтверждать новые заявления на открытие счетов

8.2.1.3. Проверять существующие счета

8.2.1.4. Составлять отчеты по кредитам/взысканию долгов

8.2.1.5. Восстанавливать или закрывать счета в соответствии с кредитными политиками

8.2.2. Выставлять счета потребителям

8.2.2.1. Поддерживать данные по клиентам/продуктам

8.2.2.2. Формировать платежную информацию по потребителям

8.2.2.3. Пересылать платежную информацию потребителям

8.2.2.4. Уведомлять потребителей о задолженности

8.2.2.5. Обслуживать финансовые запросы потребителей

8.2.3. Управлять дебиторской задолженностью (ДЗ)

8.2.3.1. Утверждать политики по ДЗ

8.2.3.2. Получать/фиксировать платежи потребителей

8.2.3.3. Принимать оплату чеками

8.2.3.4. Подготавливать отчеты о ДЗ

8.2.3.5. Вести учет изменения ДЗ

8.2.4. Управлять возвратом ДЗ

8.2.4.1. Устанавливать политики работы с должниками

8.2.4.2. Анализировать балансы по должникам

8.2.4.3. Вести переписку/переговоры с должниками

8.2.4.4. Обсуждать возможности решения проблемы должников

8.2.4.5. Обрабатывать/списывать задолженность

8.2.5. Управлять корректировками/вычетами и обрабатывать их

8.2.5.1. Утверждать политики/процедуры корректировок

8.2.5.2. Анализировать корректировки

8.2.5.3. Вести переписку/переговоры с клиентом

8.2.5.4. Обсуждать решение проблемы с внутренними участниками

8.2.5.5. Подготавливать корректирующие счета

8.2.5.6. Обрабатывать связанные данные

8.3. Выполнять учет и формировать отчетность

8.3.1. Управлять политиками/процедурами

8.3.1.1. Обсуждать соглашения об уровне сервиса

8.3.1.2. Устанавливать учетные политики

8.3.1.3. Устанавливать и вводить лимиты одобрения по кредитам

8.3.1.4. Утверждать общие финансовые системы

8.3.2. Вести учет

8.3.2.1. Поддерживать план счетов

8.3.2.2. Обрабатывать проводки в журнале

8.3.2.3. Обрабатывать отчисления

8.3.2.4. Вносить корректировки по окончании периода (например, денежные поступления, конверсия валюты)

8.3.2.5. Согласовывать трансфертные транзакции

8.3.2.6. Выверять счета в главной книге

8.3.2.7. Выполнять консолидацию

8.3.2.8. Подготавливать предварительный (проверочный) баланс

8.3.2.9. Подготавливать управленческую корректировку распределения затрат и осведомлять о ней

8.3.3. Осуществлять учет основных средств

8.3.3.1. Утверждать политики/процедуры учета основных средств

8.3.3.2. Поддерживать информацию в карточках основных средств

8.3.3.3. Проводить операции по учету изменения основных средств

8.3.3.4. Обрабатывать и фиксировать данные корректировки, уточнения, переоценки основных средств

8.3.3.5. Рассчитывать и фиксировать амортизационные отчисления

8.3.3.6. Учитывать затраты на поддержку и ремонт основных средств

8.3.3.7. Проверять правильность ведения учета основных средств

8.3.3.8. Контролировать наличие основных средств, включая инвентаризацию

8.3.3.9. Предоставлять данные по основным средствам для налоговой, статистической и прочей отчетности

8.3.4. Осуществлять финансовую отчетность

8.3.4.1. Подготавливать финансовые отчеты по бизнес-единице

8.3.4.2. Подготавливать консолидированные финансовые отчеты

8.3.4.3. Создавать управленческие отчеты по бизнес-единице

8.3.4.4. Создавать консолидированные отчеты для управления затратами

8.3.4.5. Подготавливать отчеты для совета директоров

8.3.4.6. Формировать ежеквартальные/ежегодные отчеты для акционеров (учредителей)

8.3.4.7. Формировать обязательную отчетность

8.4. Управлять ведением отчетности по проектам в части основных средств

8.4.1. Осуществлять планирование и одобрение проекта капитальных вложений

8.4.1.1. Развивать политики/процедуры в области капитальных вложений

8.4.1.2. Разрабатывать и утверждать планы и бюджеты капитальных вложений

8.4.1.3. Анализировать и утверждать проекты капитальных вложений и приобретения основных средств

8.4.1.4. Контролировать экономическую обоснованность при одобрении проекта

8.4.2. Вести учет по проектам капитальных вложений

8.4.2.1. Создавать аналитику счетов для проектного учета

8.4.2.2. Фиксировать транзакции, связанные с выполнением проекта

8.4.2.3. Проводить мониторинг проектов капитальных вложений и расходования бюджета

8.4.2.4. Закрывать/капитализировать проекты

8.4.2.5. Оценивать возврат инвестиций по выполненным проектам капитальных вложений

8.5. Управлять выплатой заработной платы

8.5.1. Управлять табелями рабочего времени

8.5.1.1. Утверждать политики/процедуры

8.5.1.2. Собирать и записывать данные по времени, отработанном сотрудниками

8.5.1.3. Анализировать и предоставлять отчеты по оплачиваемым и неоплачиваемым отпускам

8.5.1.4. Проводить мониторинг основного времени работы, переработок и сверхурочных

8.5.1.5. Анализировать и предоставлять отчеты по эффективности использования рабочего времени сотрудниками

8.5.2. Управлять выплатами

8.5.2.1. Вводить количество отработанных сотрудником часов в систему выплаты заработной платы

8.5.2.2. Поддерживать информацию по заработной плате сотрудников и управлять ею

8.5.2.3. Поддерживать применяемые вычеты и управлять ими

8.5.2.4. Проводить мониторинг изменения в налоговом статусе сотрудников

8.5.2.5. Проводить и распределять платежи

8.5.2.6. Обрабатывать и распределять оформленные вручную чеки

8.5.2.7. Обрабатывать корректировки по окончании периода

8.5.2.8. Отвечать на запросы сотрудников по выплатам

8.5.3. Начислять налоги на заработную плату

8.5.3.1. Подсчитывать и выплачивать налоги на заработную плату

8.5.3.2. Создавать и передавать сотрудникам ежегодные налоговые отчеты

8.5.3.3. Заполнять обязательные налоговые формы по заработной плате

8.6. Управлять кредиторской задолженностью (КЗ) и возмещением расходов

8.6.1. Управлять кредиторской задолженностью

8.6.1.1. Осуществлять сверки задолженности

8.6.1.2. Поддерживать электронную торговлю и управлять ею

8.6.1.3. Аудировать состояние КЗ

8.6.1.4. Акцептовать платежи

8.6.1.5. Проводить финансовые начисления и аннулирование

8.6.1.6. Начислять налоги

8.6.1.7. Анализировать/разрешать несоответствия (отклонения)

8.6.1.8. Осуществлять платежи

8.6.1.9. Отвечать на запросы по КЗ

8.6.1.10. Архивировать данные по КЗ

8.6.1.11. Корректировать данные по КЗ

8.6.2. Управлять возмещением расходов

8.6.2.1. Утверждать политики по возмещению расходов и лимиты КЗ и уведомлять контрагентов

8.6.2.2. Собирать данные о налогах и формировать отчеты

8.6.2.3. Акцептовать платежи по возмещению расходов и авансовые платежи

8.6.2.4. Управлять платежами по возмещению расходов и авансовыми платежами

8.6.2.5. Управлять личными счетами

8.7. Управлять казначейскими операциями

8.7.1. Управлять казначейскими политиками/процедурами

8.7.1.1. Утверждать область действия казначейских операций и ответственность за них

8.7.1.2. Утверждать и публиковать политики в области казначейства

8.7.1.3. Развивать казначейские процедуры

8.7.1.4. Осуществлять мониторинг казначейских процедур

8.7.1.5. Аудировать казначейские процедуры

8.7.1.6. Пересматривать казначейские процедуры

8.7.1.7. Развивать и подтверждать систему внутреннего контроля казначейства

8.7.1.8. Определять системные требования к безопасности

8.7.2. Управлять денежными средствами

8.7.2.1. Управлять денежными средствами и обеспечивать соответствие

8.7.2.2. Управлять эквивалентами денежных средств

8.7.2.3. Обрабатывать платежи системой электронных платежей (EFTs) и контролировать систему

8.7.2.4. Формировать прогноз движения денежных средств

8.7.2.5. Управлять движением денежных средств

8.7.2.6. Учитывать операции по движению денежных средств и формировать отчеты

8.7.2.7. Управлять взаимодействием с банками

8.7.2.8. Анализировать, обсуждать, принимать решения и подтверждать комиссионные за проведение банковских операций

8.7.3. Выполнять учет операций, осуществляемых внутренним подразделением банковского типа

8.7.3.1. Управлять учетом операций для дочерних компаний

8.7.3.2. Управлять операциями внутреннего кредитования

8.7.3.3. Управлять централизованными исходящими платежами, осуществляемыми от имени дочерних компаний

8.7.3.4. Управлять централизованными входящими платежами, осуществляемыми от имени дочерних компаний

8.7.3.5. Управлять внутренними платежами и внутрисетевыми транзакциями

8.7.3.6. Высчитывать процентный доход и комиссионные сборы по внутренним банковским операциям

8.7.3.7. Предоставлять выписки со счетов внутренних банковских операций

8.7.4. Управлять долгосрочными обязательствами и инвестициями

8.7.4.1. Управлять взаимосвязями с финансовыми агентами

8.7.4.2. Управлять ликвидностью

8.7.4.3. Управлять рисками по выпуску ценных бумаг

8.7.4.4. Осуществлять транзакции по долгосрочным обязательствам и инвестициям

8.7.4.5. Обрабатывать и контролировать операции с иностранной валютой

8.7.4.6. Формировать отчетность по долгосрочным обязательствам и инвестициям

8.7.5. Управлять финансовыми рисками

8.7.5.1. Управлять процентным риском

8.7.5.2. Управлять валютным риском

8.7.5.3. Управлять внешними рисками

8.7.5.4. Развивать и выполнять операции хеджирования

8.7.5.5. Оценивать и уточнять позиции по хеджированию

8.7.5.6. Создавать операции и отчеты по учету хеджирования

8.7.5.7. Осуществлять мониторинг кредита

8.8. Управлять системами внутреннего контроля

8.8.1. Утверждать системы, политики/процедуры внутреннего контроля

8.8.1.1. Создавать комитет по аудиту при совете директоров

8.8.1.2. Определять этический кодекс компании и распространять информацию о нем

8.8.1.3. Устанавливать роли и ответственность в рамках системы внутреннего контроля

8.8.1.4. Определять цели и риски по бизнес-процессам

8.8.1.5. Определять рискоустойчивость предприятия и его подразделений

8.8.2. Управлять системой контроля и осуществлять мониторинг ее соответствия политикам/процедурам системы внутреннего контроля

8.8.2.1. Разрабатывать и осуществлять контролирующую деятельность

8.8.2.2. Осуществлять мониторинг эффективности контроля

8.8.2.3. Исправлять недостатки системы контроля

8.8.2.4. Создавать подразделение по обеспечению нормативно-правового соответствия

8.8.2.5. Управлять подразделением по обеспечению нормативно-правового соответствия

8.8.2.6. Внедрять и поддерживать технологии и инструменты контроля

8.8.3. Предоставлять отчет о соответствии системы внутреннего контроля

8.8.3.1. Подготавливать отчет для внешних аудиторов

8.8.3.2. Подготавливать отчет для регламентирующих органов, акционеров, держателей долговых обязательств, фондовой биржи и т. д.

8.8.3.3. Подготавливать отчет для третьей стороны (например, бизнес-партнеров)

8.8.3.4. Подготавливать отчет для внутреннего руководства

8.9. Управлять налогами

8.9.1. Развивать налоговую стратегию и план

8.9.1.1. Развивать иностранную, национальную, государственную и внутреннюю налоговую стратегию

8.9.1.2. Консолидировать и оптимизировать совокупный налоговый план

8.9.1.3. Обеспечивать хранение информации по налогам

8.9.2. Начислять налоги

8.9.2.1. Осуществлять налоговое планирование/стратегию

8.9.2.2. Оформлять возвраты

8.9.2.3. Оформлять иностранные налоги

8.9.2.4. Подсчитывать отсроченные (отложенные) налоги

8.9.2.5. Отчитываться за начисление налогов

8.9.2.6. Осуществлять мониторинг выполнения требований налогового законодательства

8.9.2.7. Рассматривать запросы по налогам

8.10. Управлять международными фондами/консолидацией

8.10.1. Осуществлять мониторинг внутренних ставок

8.10.2. Управлять транзакциями

8.10.3. Осуществлять мониторинг риска потенциальных убытков при изменении валютного курса/ставок хеджирования

8.10.4. Предоставлять отчет о результатах

9. Приобретать, возводить недвижимость и управлять ею

9.1. Проектировать и строить/приобретать непроизводственные активы

9.1.1. Развивать стратегию и долгосрочное видение в области недвижимости

9.1.1.1. Подтверждать соответствие требований к недвижимости бизнес-стратегии компании

9.1.1.2. Оценивать внешнюю среду

9.1.1.3. Принимать решение по покупке или возведению недвижимости

9.1.2. Развивать, застраивать и изменять земельные участки

9.1.3. Планировать инфраструктуру

9.1.3.1. Проектировать инфраструктуру

9.1.3.2. Анализировать бюджет

9.1.3.3. Выбирать недвижимость

9.1.3.4. Вести переговоры по параметрам инфраструктуры

9.1.3.5. Управлять строительством и усовершенствованием

9.1.4. Обеспечивать площадкой и активами

9.1.4.1. Приобретать площадку и активы

9.1.4.2. Изменять соответствие/форму/функцию площадки и активов

9.2. Поддерживать непроизводственные активы

9.2.1. Перемещать людей и имущество

9.2.1.1. Перемещать людей

9.2.1.2. Перемещать материалы и инструменты

9.2.2. Восстанавливать площадку и активы

9.2.3. Обеспечивать плановое обслуживание и ремонт площадки и активов

9.2.4. Управлять безопасностью

9.2.5. Управлять операциями с инфраструктурой

9.3. Получать, устанавливать и планировать поддержку производственных активов

9.3.1. Развивать стратегии непрерывной поддержки производственных активов

9.3.1.1. Анализировать состояние активов и прогнозировать потребности в техническом обслуживании

9.3.1.2. Развивать подход по интеграции предупреждающих действий в производственный план

9.3.2. Получать и устанавливать оборудование

9.3.2.1. Разрабатывать технические решения для производственного процесса

9.3.2.2. Покупать оборудование

9.3.2.3. Устанавливать оборудование и вводить его в эксплуатацию

9.4. Ликвидировать производственные и непроизводственные фонды

9.4.1. Развивать стратегию выхода

9.4.2. Осуществлять продажи

9.4.3. Закрывать объект

9.5. Управлять физическим риском

10. Управлять охраной окружающей среды, здоровьем и безопасностью жизнедеятельности (EHS)

10.1. Определять результаты EHS

10.1.1. Оценивать воздействие продуктов, услуг и процессов на окружающую среду

10.1.2. Проводить проверки по EHS

10.2. Развивать и осуществлять программу EHS

10.2.1. Выявлять нормативные требования и требования заинтересованных лиц (стейкхолдеров)

10.2.2. Оценивать будущие риски и возможности

10.2.3. Разрабатывать политику в области EHS

10.2.4. Фиксировать и управлять мероприятиями в области EHS

10.3. Тренировать и обучать сотрудников

10.3.1. Доводить проблемы EHS до сведения учредителей и решать их

10.4. Осуществлять мониторинг и управлять программой EHS

10.4.1. Управлять затратами и выгодами по программе EHS

10.4.2. Измерять эффективность программы EHS и формировать отчетность

10.4.2.1. Развертывать программу ликвидации чрезвычайных ситуаций

10.4.2.2. Развертывать программу, направленную на предотвращение загрязнения окружающей среды

10.4.3. Обеспечивать сотрудников поддержкой в части EHS

10.5. Гарантировать соответствие нормативным документам

10.5.1. Осуществлять мониторинг соответствия

10.5.2. Выполнять аудит соответствия

10.5.3. Обеспечивать соответствие требованиям стейкхолдеров

10.6. Управлять восстановительными мерами

10.6.1. Разрабатывать планы восстановительных работ

10.6.2. Связываться и советоваться с экспертами

10.6.3. Выявлять/передавать в пользование ресурсы

10.6.4. Изучать правовые аспекты

10.6.5. Изучать причины возникшего ущерба

10.6.6. Улучшать или разрабатывать политику по восстановлению

11. Управлять внешними связями

11.1. Выстраивать отношения с инвесторами

11.1.1. Планировать, выстраивать и управлять отношениями с кредиторами

11.1.2. Планировать, выстраивать и управлять отношениями с консультантами, аналитиками

11.1.3. Коммуницировать с акционерами (учредителями)

11.2. Управлять связями с правительственными структурами и внутриотраслевыми связями

11.2.1. Управлять связями с правительственными структурами

11.2.2. Управлять связями с околоправительственными структурами

11.2.3. Управлять отношениями с торговыми или отраслевыми группами

11.2.4. Управлять лоббированием

11.3. Управлять коммуникацией с советом директоров

11.3.1. Предоставлять отчет о результатах

11.3.2. Предоставлять отчет о результатах аудита

11.4. Управлять правовыми и этическими вопросами

11.4.1. Разрабатывать политики в области этики.

11.4.2. Управлять политиками в области корпоративной этики

11.4.3. Разрабатывать и осуществлять превентивные правовые программы

11.4.4. Гарантировать обеспечение соблюдения правовых и этических норм

11.4.4.1. Планировать и инициировать программу, обеспечивающую соблюдение законодательных, нормативных и этических норм

11.4.4.2. Осуществлять программу, обеспечивающую соблюдение законодательных, нормативных и этических норм

11.4.5. Управлять внешним консультированием

11.4.5.1. Оценивать проблему и определять требования

11.4.5.2. Приглашать внешних консультантов при необходимости

11.4.5.3. Принимать стратегию/бюджет

11.4.5.4. Принимать результаты работы и управлять ситуацией и выполненной работой (проводить их мониторинг)

11.4.5.5. Перечислять платежи компаниям, оказывающим юридические услуги

11.4.5.6. Отслеживать правовую деятельность/результаты правовой деятельности

11.4.6. Защищать интеллектуальную собственность

11.4.6.1. Управлять авторскими правами и патентами

11.4.6.2. Поддерживать права и ограничения интеллектуальной собственности

11.4.6.3. Управлять условиями лицензирования

11.4.6.4. Управлять возможностями выбора

11.4.7. Разрешать споры и судебные процессы

11.4.8. Обеспечивать юридические консультации

11.4.9. Обсуждать и оформлять соглашения/контракты

11.5. Управлять программой по связям с общественностью

11.5.1. Управлять связями с местным населением

11.5.2. Управлять связями со СМИ

11.5.3. Способствовать политической стабильности

11.5.4. Создавать пресс-релизы

11.5.5. Выпускать пресс-релизы

12. Управлять знаниями, улучшениями и изменениями

12.1. Разрабатывать и управлять стратегией повышения организационной эффективности

12.1.1. Создавать модель системы показателей компании

12.1.1.1. Устанавливать показатели эффективности

12.1.1.2. Устанавливать периодичность контроля эффективности

12.1.1.3. Устанавливать целевые значения показателей эффективности

12.1.2. Измерять производительность процессов

12.1.3. Измерять экономическую эффективность

12.1.4. Измерять эффективность персонала

12.1.5. Измерять продолжительность циклов

12.2. Осуществлять бенчмаркинг эффективности

12.2.1. Проводить оценки эффективности

12.2.2. Развивать возможности бенчмаркинга

12.2.3. Осуществлять процесс бенчмаркинга

12.2.3.1. Составлять и обновлять перечень процессов и организаций для проведения бенчмаркинга

12.2.3.2. Утверждать контрольные показатели

12.2.3.3. Измерять эффективность по контрольным показателям

12.2.4. Проводить бенчмаркинг среди конкурирующих компаний

12.2.4.1. Составлять и обновлять перечень процессов и организаций для проведения бенчмаркинга

12.2.4.2. Утверждать контрольные показатели

12.2.4.3. Измерять эффективность по контрольным показателям

12.2.5. Осуществлять сравнительный анализ для понимания потребности в изменениях и масштаба изменений

12.2.6. Утверждать потребность в изменениях

12.3. Развивать возможности управления знаниями в масштабе предприятия

12.3.1. Развивать стратегию управления знаниями

12.3.1.1. Развивать модель управления

12.3.1.2. Утверждать основную группу по управлению знаниями

12.3.1.3. Определять роли и ответственность основной группы в противовес операционным единицам

12.3.1.4. Развивать схемы финансирования

12.3.1.5. Выявлять связи с ключевыми инициативами

12.3.1.6. Развивать основные методологии управления знаниями

12.3.1.7. Оценивать потребности в информационных технологиях и использовать IT-функцию

12.3.1.8. Развивать планы по обучению и коммуникациям

12.3.1.9. Развивать подходы к управлению изменениями

12.3.1.10. Развивать стратегические показатели и индикаторы

12.3.2. Оценивать возможности управления знаниями

12.3.2.1. Оценивать сроки исполнения существующих инициатив в области управления знаниями

12.3.2.2. Оценивать существующие подходы к управлению знаниями

12.3.2.3. Выявлять пробелы (несоответствия) и потребности

12.3.2.4. Улучшать/изменять существующие подходы к управлению знаниями

12.3.2.5. Развивать новые подходы к управлению знаниями

12.3.2.6. Осуществлять новые подходы к управлению знаниями

12.3.3. Выявлять и планировать проекты в области управления знаниями

12.3.3.1. Выявлять стратегические возможности применения подхода(ов) к управлению знаниями

12.3.3.2. Выявлять требования и цели управления знаниями

12.3.3.3. Оценивать культурный уровень и готовность к данному подходу к управлению знаниями

12.3.3.4. Выявлять подходящие методологии управления знаниями

12.3.3.5. Создавать бизнес-кейсы и получать финансирование

12.3.3.6. Развивать систему показателей и индикаторов проекта

12.3.4. Разрабатывать и запускать проекты в области управления знаниями

12.3.4.1. Разрабатывать процесс передачи, получения и использования знаний

12.3.4.2. Определять роли и ресурсы

12.3.4.3. Выявлять особые требования к информационным технологиям

12.3.4.4. Создавать планы по обучению и коммуникациям

12.3.4.5. Развивать планы по управлению изменениями

12.3.4.6. Развивать подходы к признанию и вознаграждению

12.3.4.7. Разрабатывать и планировать запуск проекта по управлению знаниями

12.3.4.8. Развертывать проект по управлению знаниями

12.3.5. Управлять жизненным циклом проекта по управлению знаниями

12.3.5.1. Оценивать соответствие бизнес-целям

12.3.5.2. Оценивать влияние управления знаниями (стратегии и проектов) на показатели и результаты (выходы)

12.3.5.3. Продвигать и поддерживать деятельность и вовлеченность

12.3.5.4. Корректировать и обновлять стратегию и подходы к управлению знаниями

12.4. Управлять изменениями

12.4.1. Планировать изменения

12.4.1.1. Выбирать методологию улучшения процессов

12.4.1.2. Оценивать готовность к изменениям

12.4.1.3. Определять заинтересованные стороны (стейкхолдеров)

12.4.1.4. Вовлекать/выявлять ответственных

12.4.1.5. Формировать команду разработчиков

12.4.1.6. Определять область проекта

12.4.1.7. Анализировать текущее состояние

12.4.1.8. Определять будущее состояние

12.4.1.9. Проводить анализ рисков

12.4.1.10. Оценивать вопросы культурного уровня

12.4.1.11. Утверждать ответственность за управление изменениями

12.4.1.12. Выявлять препятствия на пути к изменениям

12.4.1.13. Определять факторы, способствующие изменениям

12.4.1.14. Выявлять ресурсы и развивать систему показателей

12.4.2. Проектировать изменения

12.4.2.1. Оценивать связь с другими инициативами

12.4.2.2. Развивать планы по управлению изменениями

12.4.2.3. Развивать план обучения

12.4.2.4. Развивать коммуникационный план

12.4.2.5. Развивать план по вознаграждениям/мотивациям

12.4.2.6. Устанавливать метрики (показатели)

12.4.2.7. Утверждать/разъяснять новые роли

12.4.2.8. Выявлять бюджет/роли

12.4.3. Внедрять изменения

12.4.3.1. Создавать заинтересованность в улучшениях/изменениях

12.4.3.2. Осуществлять реинжиниринг бизнес-процессов и систем

12.4.3.3. Поддерживать переход к новым ролям или стратегию выхода для должностных лиц

12.4.3.4. Проводить мониторинг изменений

12.4.4. Поддерживать улучшения

12.4.4.1. Проводить мониторинг эффективности улучшенных процессов

12.4.4.2. Извлекать уроки из осуществления процессов изменения и многократно использовать этот опыт

12.4.4.3. Проводить корректирующие действия по мере необходимости

Приложение 2
Шаблон «Регламент процесса»

Приложение 3
Шаблон «Положение о подразделении»

Приложение 4
Шаблон «Должностная инструкция»

Об авторе

Владимир Владимирович Репин – кандидат технических наук, доцент, исполнительный директор и партнер ООО «BPM Консалтинг Групп» (www.bpm3.ru). Область профессиональных интересов:

• оптимизация систем управления;

• внедрение процессного подхода к управлению на российских предприятиях;

• внедрение среды описания и регламентации бизнес-процессов Business Studio;

• проведение семинаров-тренингов для руководителей и специалистов предприятий;

• управление информационным порталом по тематике процессного управления www.FineXpert.ru.

Владимир Репин участвовал в консультационных проектах более чем на 70 предприятиях России. Провел свыше 120 семинаров-тренингов для руководителей и специалистов компаний по вопросам внедрения процессного подхода к управлению, моделирования и регламентации бизнес-процессов, управления финансами.

Автор книг: В. В. Репин. Бизнес-процессы компании: построение, анализ, регламентация (М.: РИА «Стандарты и качество», 2007); В. Г. Елиферов, В. В. Репин. Бизнес-процессы: регламентация и управление (М.: Инфра-М, 2004); В. В. Репин, В. Г. Елиферов. Процессный подход к управлению. Моделирование бизнес-процессов (М.: РИА «Стандарты и качество», 2004); В. В. Репин. Технологии управления финансами предприятия (М.: Издательский дом «АТКАРА», 2000).

Примечания

1

Репозиторий – см. определение на с. 219.

(обратно)

2

Например, «Методика управления процессами организации» – базовый методический документ, содержащий описание терминов и определений процессного управления, принципы, концепцию внедрения и необходимые методы работы с процессами.

(обратно)

3

Рассматриваемый подход описан в «Исследовании в области моделирования бизнес-процессов» за 2011 год компании BPTrends, перевод которого размещен на сайте 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

В настоящее время в некоторых компаниях используется понятие «процессирование». «Процессирование» – новомодный термин, означающий описание, регламентацию и управление процессами; мне он не нравится. Многие термины приходят к нам с Запада. Но лучше обходиться своими формулировками, и русский язык для этого достаточно богат.

(обратно)

31

В данном параграфе сделана попытка обосновать эффективность процессного подхода без детального рассмотрения методов статистического управления процессами.

(обратно)

32

Обычно стабильность процесса определяют на основе понятия статистической управляемости.

(обратно)

33

Форма распределения показана условно, но это распределение в любом случае не является нормальным.

(обратно)

34

Реальная функция потерь не обязательно должна выглядеть как парабола. Кроме того, для нее существует некоторое максимальное значение потерь, ограничивающее эту функция сверху.

(обратно)

35

График построен на основе примера, приведенного в главе 7 книги [6].

(обратно)

36

Пример чрезмерного влияния особой причины – взрыв газовой магистрали, который привел к выгоранию всего предприятия.

(обратно)

37

Например, совершенствование производственного процесса без полной замены оборудования.

(обратно)

38

По сути, часть общих причин становится особыми причинами.

(обратно)

39

Например, в ситуации войны.

(обратно)

40

И, соответственно, подразделения и сотрудники.

(обратно)

41

До определенного уровня декомпозиции процессов.

(обратно)

42

По моему опыту, их доля составляет 70–80 % от числа организаций, использующих какие-либо методы процессного подхода.

(обратно)

43

Что обеспечивает снижение потерь.

(обратно)

44

Само по себе это уже является большим достижение менеджмента организации.

(обратно)

45

Такие сотрудники могут участвовать в проекте, но только в качестве стажеров.

(обратно)

46

ССП – система сбалансированных показателей.

(обратно)

47

Очевидно, что при отсутствии системы процессов такая работа не может быть выполнена.

(обратно)

48

Независимо от того, формализована стратегия организации или нет.

(обратно)

49

Платформа, интегрирующая различные виды программного обеспечения, на рис. 1.7.1 не показана.

(обратно)

50

В отличие от сложных технических систем.

(обратно)

51

Палетоместо – единица складского хранения.

(обратно)

52

Рассмотрены в главе 1.

(обратно)

53

Такой сквозной процесс выделять целесообразно.

(обратно)

54

Схема процесса, на которой операции, выполняемые каждым его участником, показаны в отдельном столбце.

(обратно)

55

Хотя само по себе согласование входов/выходов – важнейшая задача при внедрении процессного управления.

(обратно)

56

СБЕ – стратегическая бизнес-единица.

(обратно)

57

Для целей полного анализа бизнеса нужно построить схемы ЦСЦ.

(обратно)

58

Если каждый процесс выполняет только один сотрудник (малая компания), то процесс, представленный на рис. 2.4.5, можно считать сквозным.

(обратно)

59

В главе 3 подробно описана методика построения архитектуры бизнес-процессов компании.

(обратно)

60

Каждая из этих частей также может представлять собой сквозной процесс.

(обратно)

61

Многие западные консультанты рекомендуют такой подход. Однако на практике он не работает.

(обратно)

62

То есть выделение и управление сквозными процессами рассматривается мной в качестве инструмента налаживания межфукнционального взаимодействия для решения задач бизнеса, получения синергетических эффектов и достижения высокой операционной эффективности.

(обратно)

63

РЦ – распределительный центр.

(обратно)

64

Вопросы разработки архитектуры или системы бизнес-процессов компании подробно изложены в главе 3.

(обратно)

65

Формализованный язык описания процесса, метод описания процесса.

(обратно)

66

Скорее, приведет к стрессу у выполняющих процесс сотрудников.

(обратно)

67

В одной из зарубежных книг автор предложил при внедрении процессного подхода создавать институт владельцев процессов и «процессных стюардов».

(обратно)

68

В результате коллегиального решения.

(обратно)

69

Наиболее сложная форма выделения ресурсов – матричная схема организации. Но, как я уже упоминал, она не рекомендуется для управления сквозными процессами, выделенными в обычной линейно-функциональной организации.

(обратно)

70

Каждый отвечает за исполнение требований регламентов по сквозному процессу в части операций, выполняемых его подразделением.

(обратно)

71

Очевидно, неточный перевод. Скорее, имелись в виду «показатели нормального хода процесса». Другими словами, допустимый диапазон отклонений значений показателей.

(обратно)

72

Например, в системе Business Studio.

(обратно)

73

IDEF0 (Function Modeling) – методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Прим. ред.

(обратно)

74

Есть некоторые отраслевые стандарты на системы процессов (например, eTOM – enhanced Telecom Operations Map – многоуровневая модель бизнес-процессов телекоммуникационной компании; является базой для анализа и проектирования бизнес-процессов в отрасли связи) и типовые перечни процессов (например, модель APQC), но общепризнанного комплексного стандарта проектирования системы процессов организации пока не существует. При применении некоторых существующих общих методических подходов (например, матрицы Захмана) количество разных моделей организации соответствует числу аналитиков, участвовавших в работе.

(обратно)

75

Авторский перевод справочника версии 2010 года на русский язык представлен в приложении 1.

(обратно)

76

В зависимости от сложности модели и общего количества уровней процессного дерева.

(обратно)

77

Процессы есть во всех организациях. Но далеко не в каждой из них процессы определены в качестве объектов управления.

(обратно)

78

Например, такая ситуация может сложиться при формальном внедрении системы менеджмента качества в соответствии с требованиями стандарта ИСО 9000–2008.

(обратно)

79

См. сайт www.bpm3.ru.

(обратно)

80

Схема выполнена в нотации, разработанной компанией ФИНЭКСПЕРТ.РУ в период с 2007 по 2008 год.

(обратно)

81

В зависимости от уровня структурного подразделения.

(обратно)

82

Документ показывает количество должностей в каждом подразделении, номер грейда для каждой должности, количество сотрудников на должности.

(обратно)

83

Unify Modeling Language – унифицированный язык моделирования.

(обратно)

84

Business Process Modeling Notation – нотация и модель бизнес-процессов.

(обратно)

85

В некоторых западных подходах модель такого типа называют Enterprise Architecture.

(обратно)

86

В среде моделирования Business Studio используется следующее определение: метаданные – описательная информация о структуре и смысле данных.

(обратно)

87

Условное название модуля.

(обратно)

88

Зависит от функциональных возможностей конкретной среды моделирования.

(обратно)

89

Один из возможных вариантов представления.

(обратно)

90

Модель учебная. Подразделения – исполнители процессов не показаны. Обратные связи тоже.

(обратно)

91

Этот вопрос подробно обсуждался в главе 3.

(обратно)

92

Work flow – «поток работ» (англ.).

(обратно)

93

Gateway – «ворота, шлюз» (англ.).

(обратно)

94

Business Process Model and Notation.

(обратно)

95

За исключением BPMN.

(обратно)

96

При необходимости их можно использовать для описания потоков материальных объектов.

(обратно)

97

ARIS – «архитектура интегрированных информационных систем». ARIS eEPC (Extended Event-driven Process Chain) – «расширенная модель цепочки процесса, управляемого событиями» (нотация для описания бизнес-процессов).

(обратно)

98

Появилась в 2012 году.

(обратно)

99

На начало 2011 года данная система использовалась более чем в 1000 компаний в России и странах СНГ.

(обратно)

100

В других нотациях это не так.

(обратно)

101

В Business Studio ромбик обладает почти всеми атрибутами полноценного процесса, но не может быть декомпозирован. Это нужно иметь в виду при описании процессов в этой системе. В параграфе 4.6 я как раз не рекомендую использовать «Решение» как полноценную операцию.

(обратно)

102

СТУ – «Современные технологии управления» (г. Самара) – разработчик Business Studio.

(обратно)

103

План внедрения в организации среднего или крупного размера.

(обратно)

104

Для небольших компаний план проекта может быть существенно переработан.

(обратно)

105

ССП – система сбалансированных показателей, КПЭ – ключевые показатели эффективности.

(обратно)

106

То есть требуемых бизнес-процессов.

(обратно)

107

В данном примере в систему входят как сотрудники организации, так и внешние лица, которые пользуются их услугами.

(обратно)

108

Эта тема обсуждалась в главе 4.

(обратно)

109

Пример разработки такого регламента при помощи среды моделирования Business Studio приводится в главе 4.

(обратно)

110

В случае применения системы электронного документооборота рассматриваемая процедура должна быть переработана с учетом возможностей этого программного обеспечения.

(обратно)

111

Автоматизация этих процессов возможна также в системах класса Business Process Management.

(обратно)

112

ЭЦП – электронная цифровая подпись.

(обратно)

113

Если НМД действует в системе электронного документооборота с ЭЦП, то это (и последующие действия) делать не нужно.

(обратно)

114

Понятие «номенклатура дел» может быть также в системе электронного документооборота.

(обратно)

115

Здесь речь идет, по сути, о номенклатуре дел подразделения.

(обратно)

116

Регламенты управления разрабатываются для стандартизации деятельности руководителей.

(обратно)

117

ФИО изменены.

(обратно)

118

Об этой модели говорилось в главе 3. Перевод модели на русский язык представлен в приложении 1.

(обратно)

119

Про процессные категории и группы см. главу 3.

(обратно)

120

* ППР – планово-предупредительный ремонт.

** ОГМ – отдел главного механика.

*** ОГЭ – отдел главного энергетика.

(обратно)

121

Температура, влажность, освещенность и т. п.

(обратно)

122

ТО – техническое обслуживание.

(обратно)

123

Такая формулировка нечетко определяет процесс, но была оставлена руководителем.

(обратно)

124

КПЭ – ключевой показатель эффективности.

(обратно)

125

ИТР – инженерно-технический работник.

(обратно)

126

Список процессов управления приводится в виде небольшого фрагмента.

(обратно)

127

BPM – Business Process Management.

(обратно)

128

В зависимости от отрасли и размера компании соотношение может меняться. В данном случае представлено мое личное мнение, сформированное на основе опыта выполнения консалтинговых проектов.

(обратно)

129

Эта величина на первый взгляд может показаться странной, но в компаниях действительно множество важных для бизнеса операционных процессов, которые выполняются при поддержке только офисных приложений. Пропорция зависит от вида бизнеса и других факторов.

(обратно)

130

Business Performance Management.

(обратно)

131

Корректирующие мероприятия – действия, направленные на приведение процесса в нормальное состояние. Улучшения в рамках цикла PDCA – целенаправленный поиск и реализация мероприятий, изменяющих процесс в соответствии с установленными целями.

(обратно)

132

BSC (Balanced Score Card) – система сбалансированных показателей компании.

(обратно)

133

Для осуществления мониторинга процессов рекомендуется использовать систему класса BPM (Business Performance Management).

(обратно)

134

В данном контексте – Business Performance Management.

(обратно)

135

Поэтому я рекомендую также новое издание книги В. В. Репина и В. Г. Елиферова «Процессный подход к управлению. Моделирование бизнес-процессов» (М.: Манн, Иванов и Фербер, 2013).

(обратно)

136

Метод ABC (ABC-анализ) позволяет классифицировать ресурсы компании по степени их важности; один из методов рационализации, может применяться в сфере деятельности любой организации. Прим. ред.

(обратно)

Оглавление

Предисловие

Глава 1 Процессный подход: концепция внедрения в организации

  1.1. Зрелость компании в области процессного управления

  1.2. Термины и определения процессного подхода

    1.2.1. Структурная схема процесса

    1.2.2. Границы процесса

    1.2.3. Спецификации на входы и выходы процесса

    1.2.4. Контроль входов/выходов процесса

    1.2.5. Технология выполнения процесса

    1.2.6. Окружение процесса

    1.2.7. Классификация процессов

    1.2.8. Показатели для управления процессом

    1.2.9. Определение процессного подхода

  1.3. Обоснование эффективности процессного подхода[31]

    1.3.1. Стабильность и воспроизводимость процесса

    1.3.2. Вариации процесса

    1.3.3. Экономическая целесообразность регламентации процесса

    1.3.4. Структурированный процесс или самоорганизация?

  1.4. Концепция внедрения процессного подхода

    1.4.1. Общее описание концепции «Совершенствование процессов»

    1.4.2. Процессный подход на уровне организации в целом

    1.4.3. Обеспечение организационного развития при внедрении процессного подхода

    1.4.4. Управление процессами на уровне владельцев процессов

    1.4.5. Краткое описание работы системы, построенной по концепции «Совершенствование процессов»

    1.4.6. Важность выделения ресурсов на организационное развитие

    1.4.7. Разработка собственной концепции внедрения процессного подхода

    1.4.8. Концепция «Формализация процессов»

    1.4.9. Краткое описание работы системы, построенной по концепции «Формализация процессов»

  1.5. Принципы процессного подхода

  1.6. Проект внедрения процессного подхода

    1.6.1. Общее описание этапов проекта

    1.6.2. Принятие решений

    1.6.3. Подготовка

    1.6.4. Разработка процессной архитектуры организации

    1.6.5. Разработка системы показателей

    1.6.6. Организация управления процессами

    1.6.7. Описание и регламентация процессов

    1.6.8. Запуск цикла PDCA

  1.7. Автоматизация процессного управления

  1.8. Список литературы

Глава 2 Сквозные процессы в организации

  2.1. Организация как система

  2.2. Синергия

  2.3. Сквозные процессы

  2.4. Критерии выделения сквозных процессов

    2.4.1. Определение границ сквозного процесса

    2.4.2. На каком уровне целесообразно выделять сквозные процессы?

    2.4.3. Возможность управления сквозным процессом

    2.4.4. Важность результата сквозного процесса

    2.4.5. Сколько сквозных процессов должно быть в организации?

  2.5. Типовой перечень сквозных процессов

  2.6. Сквозные процессы в системе процессов компании

  2.7. Сквозные процессы и проекты

  2.8. Подходы к управлению сквозными процессами

    2.8.1. Способ 1 «Ничего не менять»

    2.8.2. Способ 2 «Организация группы вокруг процесса»

    2.8.3. Способ 3 «Матричное управление»

    2.8.4. Способ 4 «Куратор со стороны высшего руководства»

    2.8.5. Способ 5 «Мониторинг владельцем процесса и куратор свыше»

    2.8.6. Способ 6 «Управление через регламенты»

  2.9. Управление сквозными процессами в масштабах компании

    2.9.1. Локальные сквозные процессы?!

    2.9.2. Группы сквозных процессов

    2.9.3. Как организовать управление сквозными процессами и группами процессов

    2.9.4. Выбор метода управления сквозными процессами

  2.10. Владелец процесса: ответственность и полномочия

  2.11. Список литературы

Глава 3 Разработка системы процессов организации

  3.1. Определение системы процессов организации

  3.2. Цели разработки системы процессов организации

  3.3. Различные подходы к построению системы процессов организации

    3.3.1. Структурный подход к построению системы процессов компании

    3.3.2. Продуктовый подход к построению системы процессов

    3.3.3. Система процессов компании как «блюдо спагетти»

    3.3.4. Система процессов компании по методу CBM IBM

    3.3.5. Построение системы процессов на основе анализа цепочек создания ценности

    3.3.6. Выбор методики построения системы процессов

  3.4. Методика построения системы процессов организации на основе анализа цепочек создания ценности

    3.4.1. Методика построения

    3.4.2. Использование отраслевых решений и материалов других компаний

    3.4.3. «Процессы» или «процессные группы»?

    3.4.4. Выявление сквозных процессов на основе анализа схем ЦСЦ

  3.5. Разработка модели процессов на верхнем уровне

  3.6. Определение процессов подразделений

  3.7. Согласование границ процессов

  3.8. Список литературы

Глава 4 Описание бизнес-процессов организации

  4.1. Цели описания бизнес-процессов организации

  4.2. Что нужно для успешного описания процессов в масштабах организации?

    4.2.1. Формулировка целей описания процессов

    4.2.2. Нотация моделирования процессов

    4.2.3. Репозиторий и среда моделирования процессов

    4.2.4. Методики описания процессов

    4.2.5. Наличие необходимых специалистов

  4.3. Объектная модель организации

  4.4. Архитектура типовой среды моделирования процессов

  4.5. Структурные модели процессов организации

  4.6. Модели процессов на операционном уровне

    4.6.1. Нотации типа Work Flow

    4.6.2. Простая блок-схема

    4.6.3. Нотация ARIS eEPC

    4.6.4. Нотация BPMN

    4.6.5. Нотация «Процедура» среды моделирования Business Studio

  4.7. Информативность графических схем процессов

  4.8. Формирование регламентирующих документов на основе описания процессов

  4.9. Особенности создания корректных схем процессов

    4.9.1. Корректное определение границ процесса

    4.9.2. Привязка к системе процессов

    4.9.3. Декомпозиция – слишком длинные процессы

    4.9.4. Процесс в процессе, или «Процессная грыжа»

    4.9.5. Примитивизация – рисование процесса по «хвостам»

    4.9.6. Однородность процесса

    4.9.7. Связи между процессами, оборванные входы/выходы

    4.9.8. Нарушение нотации моделирования

    4.9.9. Проверка на здравый смысл

  4.10. Рекомендации по внедрению среды моделирования процессов

  4.11. Список литературы

Глава 5 Регламентация бизнес-процессов организации

  5.1. Культура регламентации в российских компаниях

    5.1.1. Низкий приоритет регламентации с точки зрения топ-менеджеров

    5.1.2. Отсутствие культуры работы по стандартам

    5.1.3. Устаревание нормативной базы при неадекватной и несвоевременной ее актуализации

    5.1.4. Система стимулирования

    5.1.5. Отсутствие нормирования труда в привязке к регламентам

    5.1.6. «Исотизированные» (слишком общие) регламенты

    5.1.7. Регламентация процессов производства при отсутствии регламентации процессов управления/развития

    5.1.8. Отсутствие системы работы с регламентами

  5.2. Минусы регламентации бизнес-процессов

    5.2.1. Значительные затраты на регламентацию

    5.2.2. Снижение творчества, инициативы сотрудников

    5.2.3. Разрушение сложившейся команды руководителей и специалистов

    5.2.4. Снижение гибкости в принятии решений, осуществлении изменений и как следствие – уход клиентов

    5.2.5. Дополнительная нагрузка на персонал, снижение производительности

    5.2.6. Увеличение сроков выполнения процессов из-за необходимости соблюдения регламентов

    5.2.7. Появление слишком сложных, забюрократизированных регламентов

    5.2.8. Возможность так называемой итальянской забастовки

    5.2.9. Возможная утечка информации о стандартах работы в другие организации

  5.3. Плюсы регламентации бизнес-процессов

    5.3.1. Формализация деятельности, обеспечение единого понимания требований сотрудниками

    5.3.2. Согласование взаимодействия структурных подразделений организации

    5.3.3. Выявление и устранение зон безответственности, пересечения ответственности

    5.3.4. Формирование предпосылок для делегирования полномочий и повышения эффективности управления

    5.3.5. Поиск и внедрение изменений, повышающих эффективность процессов

    5.3.6. Прозрачность бизнеса

    5.3.7. Повышение эффективности управления

    5.3.8. Снижение рисков, связанных с уходом руководителей и специалистов

    5.3.9. Повышение эффективности процессов подбора и обучения персонала

    5.3.10. Создание возможностей для аудита бизнес-процессов и запуска системы непрерывного совершенствования (цикла PDCA)

    5.3.11. Создание предпосылок для последующей эффективной автоматизации бизнес-процессов

    5.3.12. Обеспечение возможности развития бизнеса

  5.4. Система стандартизации бизнес-процессов

    5.4.1. Определение системы стандартизации бизнес-процессов

    5.4.2. Методы системы

    5.4.3. Инструменты системы

    5.4.4. Процессы системы

    5.4.5. Персонал, необходимый для работы системы

    5.4.6. Развитие системы

  5.5. Объекты регламентации и структура нормативно-методических документов организации

    5.5.1. Структурные НМД

    5.5.2. Процессные НМД

    5.5.3. Одноуровневый регламент выполнения процесса

    5.5.4. Двухуровневый регламент выполнения процесса

    5.5.5. Положение о подразделении и должностная инструкция

  5.6. Процедура разработки и согласования НМД

    5.6.1. Термины и определения

    5.6.2. Нормативные ссылки

    5.6.3. Структура НМД

    5.6.4. Инициация разработки НМД

    5.6.5. Разработка и презентация первой версии НМД

    5.6.6. Согласование проекта НМД

    5.6.7. Тестирование проекта НМД

    5.6.8. Ввод НМД в действие

    5.6.9. Хранение и выдача учтенных копий НМД

    5.6.10. Контроль исполнения НМД

    5.6.11. Отмена НМД

    5.6.12. Кодирование НМД

  5.7. Оценка качества НМД

  5.8. Разработка графика регламентации

  5.9. Контроль исполнения требований НМД

    5.9.1. Самоконтроль

    5.9.2. Контроль непосредственным руководителем

    5.9.3. Контроль по показателям

    5.9.4. Внутренний аудит

    5.9.5. Жесткая автоматизация процесса

  5.10. Подходы к регламентации: оптимизация или директива?

    5.10.1. Регламентация, основанная на результатах оптимизации

    5.10.2. Директивная регламентация

  5.11. Список литературы

Глава 6 Управление бизнес-процессами

  6.1. Процессы управления

    6.1.1. Процессы управления в системе процессов компании

    6.1.2. Определение процессов управления на основе временны?х контуров

  6.2. Чем вы управляете: бизнес-процессами или схемами процессов?

  6.3. Объекты управления в рамках процесса

  6.4. Разработка показателей для управления процессом

  6.5. Оперативное управление процессом

    6.5.1. Планирование процессов

    6.5.2. Мониторинг процесса

    6.5.3. Разработка и выполнение корректирующих действий

    6.5.4. Совершенствование процесса на основе цикла PDCA

  6.6. Список литературы

Заключение

Приложение 1 Система процессов APQC

  1. Развивать ви?дение и стратегию

  2. Развивать продукты/услуги и управлять ими

  3. Выполнять маркетинг и продавать продукты/услуги

  4. Поставлять продукты и оказывать услуги

  5. Управлять обслуживанием потребителей

  6. Развивать человеческий капитал (персонал) и управлять им

  7. Управлять информационными технологиями (IT)

  8. Управлять финансовыми ресурсами

  9. Приобретать, возводить недвижимость и управлять ею

  10. Управлять охраной окружающей среды, здоровьем и безопасностью жизнедеятельности (EHS)

  11. Управлять внешними связями

  12. Управлять знаниями, улучшениями и изменениями

Приложение 2 Шаблон «Регламент процесса»

Приложение 3 Шаблон «Положение о подразделении»

Приложение 4 Шаблон «Должностная инструкция»

Об авторе