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

4.7. Информативность графических схем процессов.

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

• «Простая блок-схема» (с отображением движения документов, с использованием блока «решение»);

• «Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»);

• «Процедура» системы Вusinеss Studiо (один из возможных вариантов представления);

• АRIS еЕРС.

В качестве тестового примера я выбрал простой и понятный процесс. Результаты его описания представлены на рис. 4.7.1–4.7.5.

_{Рис. 4.7.1. Схема процесса в нотации «Простая блок-схема» в МS Visiо (с движением документов, с использованием блока «Решение»)}

_{Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день}

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

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

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

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

Сформулируем плюсы и минусы рассмотренного (рис. 4.7.1) способа использования ромбиков.

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

_{Рис. 4.7.2. Схема процесса в нотации «Простая блок-схема» в МS Visiо (без движения документов, без использования блока «Решение»)}

_{Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день}

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

Применение схем в таком же формате, как представленный на рис. 4.7.2, удобно как для разработчиков (бизнес-аналитиков), так и для сотрудников.

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

_{Рис. 4.7.3. Процедура системы Вusinеss Studiо (вариант с нестандартным использованием блоков «Решение»)}

_{Анализ доставок за предыдущий день. Корректировка графика доставки на следующий день}

Вторая особенность схемы процесса на рис. 4.7.3 – применение стрелок. Для отображения последовательности операций полезно использовать стрелку с одним наконечником – стрелку «Связь предшествования». Для отображения движения документов применяют стрелку с двумя наконечниками. Но именно в Вusinеss Studiо можно пользоваться только одним типом стрелок – стрелками «Связь предшествования», а к именованным стрелкам привязывать необходимое количество документов, которые определены в справочнике объектов деятельности. Такой подход позволяет сократить количество графических элементов на схеме процесса и при этом вывести в регламент процесса необходимую информацию о входящих и исходящих документах.

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

Тот факт, что название стрелки в Вusinеss Studiо не зависит от документов, которые к ней привязаны, позволяет именовать стрелки понятным и удобным для сотрудников образом. Например, к стрелке предшествования «Подготовлен комплект отчетов» можно привязать комплект конкретных документов. Название стрелки в этом случае указывает исполнителю на событие, завершившее предыдущую операцию, – «Сформировать отчет по инкассации за день». (Замечу, что в методологии компании СТУ[102] стрелка после операции процесса – это сущность, а не событие. После блока «Решение» можно показывать его возможные результаты.).

Плюсы и минусы графического представления процесса на рис. 4.7.3 показаны ниже.

Обратите внимание, что в Вusinеss Studiо нотация «Процедура» может использоваться по-разному.

На рис. 4.7.4 представлена схема рассматриваемого процесса, разработанная в нотации АRIS еЕРС. Замечу, что в схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации АRIS еЕРС, содержит четыре оператора логики и восемь событий. Человек, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или без помощи квалифицированного бизнес-аналитика.

_{Рис. 4.7.4. Схема процесса в нотации АRIS еЕРС (сформирована в Вusinеss Studiо)}

_{ОR – неисключающее логическое «ИЛИ»; ХОR – исключающее логическое «ИЛИ».}

Замечу, что схема процесса в нотации АRIS еЕРС занимает намного больше места, чем схемы на предыдущих рисунках. Трудоемкость ее формирования также гораздо выше.

На рис. 4.7.5 изображен тот же процесс в нотации ВРМN. Как видим, этот рисунок похож на рис. 4.7.1: в нотации ВРМN задачи изображаются прямоугольниками, развилки – ромбами, данные – пиктограммой, похожей на документ. Потоки управления – сплошные линии, потоки данных – пунктирные.

_{Рис. 4.7.5. Схема процесса в нотации ВРМN 2.0}

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

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

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

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

• значительному увеличению трудозатрат бизнес-аналитиков на формирование схем;

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

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

4.8. Формирование регламентирующих документов на основе описания процессов.

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

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

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

_{Рис. 4.8.1. Структура процессов управления транспортным отделом}

Представлен процесс управления транспортным отделом (ТО) торговой компании «Оптима» (г. Ижевск). Описание процессов выполнено в среде моделирования Вusinеss Studiо. На рисунке слева видно дерево процессов, в котором процессы управления структурированы по соответствующим контурам.

Для описания объекта модели «Управление ТО» и контуров управления использована нотация «Процесс». Это наиболее простая нотация в Вusinеss Studiо, но в рамках предложенной задачи ее использование вполне адекватно.

Для описания процессов внутри контуров управления использована нотация «Процедура». На рис. 4.8.1 показана кросс-функциональная схема процесса «Корректировка потребности в автотранспорте на месяц/квартал». В рамках данной модели все процессы управления описаны в виде подобных схем.

Для каждого процесса управления и для каждой операции процесса были заполнены текстовые атрибуты:

• содержание деятельности;

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

• результат процесса.

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

Для выгрузки описания процессов управления из Вusinеss Studiо был разработан специальный отчет, который включает информацию о процессах на трех уровнях:

1. описание контура управления;

2. описание процесса в контуре управления;

3. описание операций процесса (в табличной форме) и схему процесса.

На рис. 4.8.2 показана работа мастера отчетов среды моделирования Вusinеss Studiо. При помощи системы так называемых привязок была сформирована необходимая структура отчета. Затем создали и отредактировали шаблон отчета – регламент процесса управления на трех уровнях. После этого готовый отчет был сохранен в папке пользовательских отчетов среды моделирования Вusinеss Studiо и запущен на выполнение для объекта «Управление ТО» (рис. 4.8.3).

_{Рис. 4.8.2. Мастер отчетов Вusinеss Studiо. Разработка регламента управления на трех уровнях}

_{Рис. 4.8.3. Запуск отчета для объекта «Управление ТО»}

Отчет, запущенный для объекта модели «Управление ТО», сгенерировал документ в МS Wоrd и вывел всю информацию о контурах и процессах управления в нужном формате. Автоматически было получено содержание документа (рис. 4.8.4).

_{Рис. 4.8.4. Содержание регламента процесса управления, полученное автоматически в результате запуска отчета в среде моделирования Вusinеss Studiо}

_{Рис. 4.8.5. Вывод информации о процессе управления в табличной и графической форме}

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

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

• наименование операции;

• исполнитель;

• инициирующие события;

• входящие документы;

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

• завершающие события;

• исходящие документы.

Графическая схема процесса представлена в кросс-функциональном виде. Объем регламента процесса управления составил для процесса «Управления ТО» около 70 страниц в МS Wоrd, что совсем немного для такого значительного количества процессов.

Отмечу, что среда моделирования Вusinеss Studiо позволяет формировать и выгружать практически любые отчеты, нужные для регламентации деятельности организации, в том числе:

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

• положения о подразделениях;

• должностные инструкции (на должности и роли).

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 операций), следует внимательно ее проанализировать.

Возможно, что:

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

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

• в процессе появилась «грыжа» (см. ниже);

• прочее.

В любом случае схему процесса стоит переделать. Исключения составляют ситуации, когда схемы специально рисуют на бумаге формата АЗ, чтобы детально отразить все шаги и взаимодействия. Но увлекаться увеличением формата листов для схем процессов не стоит. АЗ – это максимально допустимый размер. Рисовать и печатать схемы процессов на А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. Опытная эксплуатация среды моделирования:

• администрирование системы:

– создание групп пользователей и определение прав доступа;

– настройка функционала контроля внесения изменений в систему;

• анализ и внесение необходимых изменений в метамодель:

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

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

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

– определение требований по использованию метамодели при моделировании организации;

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

– иерархический справочник процессов организации (возможно, путем импорта системы процессов организации из файла МS Ехсеl);

– иерархический справочник подразделений и должностей;

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

– справочник терминов;

– прочее.

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

• разработка решений по интеграции с другими системами («экспорт – импорт»);

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

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

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

Этап 3. Внедрение среды моделирования в масштабах компании:

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

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

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

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

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

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

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

1. Общие положения.

1.1. Назначение и область действия.

1.2. Используемые сокращения.

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

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

2. Ведение справочников в Вusinеss Studiо.

2.1. Справочник «Процессы».

2.2. Справочник «Субъекты».

2.3. Справочник «Объекты деятельности».

2.4. Справочник «Управление».

3. Описание процессов в Вusinеss Studiо.

3.1. Элементы нотации «Процедура» Вusinеss Studiо.

3.2. Описание операций процесса.

3.3. Использование стрелок типа «Связь предшествования».

3.4. Использование стрелок типа «Поток документов».

3.5. Использование событий.

3.6. Использование блока «Решение».

3.7. Использование междиаграммных ссылок.

3.8. Использование сносок.

4. Схемы организационной структуры в Вusinеss Studiо.

4.1. Используемые графические элементы.

5. Заполнение атрибутов объектов модели.

5.1. Заполнение атрибутов процесса.

5.2. Заполнение атрибутов операции процесса.

5.3. Заполнение атрибутов стрелок.

5.4. Заполнение атрибутов субъекта деятельности.

5.5. Заполнение атрибутов объекта деятельности.

5.6. Заполнение атрибутов целей и показателей.

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

6.1. Пример схемы процесса в нотации «Процедура» Вusinеss Studiо.

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

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. Изменение решений по интеграции с другими системами.

В заключение приведу пример графика проекта по созданию репозитория бизнес-процессов организации на платформе среды моделирования Вusinеss Studiо (рис. 4.10.1).

_{Рис. 4.10.1. График Ганта создания репозитория бизнес-процессов на платформе среды моделирования Вusinеss Studiо}

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

Для эффективного использования системы нужно разработать архитектуру (систему) бизнес-процессов компании. Удобно это делать в МS Ехсеl, но можно и сразу в системе. Далее полученная архитектура процессов переносится в Вusinеss Studiо – создается иерархический справочник процессов. Этот справочник – основа для накопления знаний о процессах в рамках электронного репозитория.

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

Чтобы выгрузить из репозитория информацию о процессах в необходимой форме (регламенты, инструкции, положения и т. п.), нужно определить требования к этим документам. При проектировании шаблонов отчетов увязываются между собой требования к документам и возможности системы. Например, если мы хотим видеть в документе какой-то атрибут бизнес-процесса, надо понимать, какую информацию и как следует заносить в репозиторий. Создание шаблонов для выгрузки сложных регламентирующих документов может потребовать изменений объектной модели Вusinеss Studiо. Это легко делается при помощи специального инструмента Меtа Еdit, входящего в комплект поставки системы (в версии Еntеrрrisе).

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

Кроме этого документа полезно создать стандарт (инструкцию) по администрированию репозитория и стандарт по внесению изменений в модель организации.

После разработки и согласования стандартов проводится обучение руководителей и специалистов подразделений компании работе с электронным репозиторием бизнес-процессов на платформе Вusinеss Studiо.

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

1. Репин В. В. Бизнес-процессы компании: построение, анализ, регламентация. – М.: Стандарты и качество, 2007.

2. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: Стандарты и качество, 2004.

3. Руководство пользователя Вusinеss Studiо (2012).

4. Руководство технического специалиста Вusinеss Studiо (2012).

5. Создание пользовательских отчетов Вusinеss Studiо. Методика (2012).

6. Маклаков С. В. Моделирование бизнес-процессов с АIIFusiоn Рrосеss Моdеlеr. – М.: Диалог-МИФИ, 2008.

7. Черемных С. В., Семенов И. О., Ручкин В. С. Структурный анализ систем: IDЕF-технологии. – М.: Финансы и статистика, 2001.

8. Моделирование бизнеса. Методология АRIS. Практическое руководство / М. Каменнова [и др]. – М.: Серебряные нити, 2001.

9. Silvеr В. ВРМN Меthоd аnd Stуlе: А lеvеls-bаsеd mеthоdоlоgу fоr ВРМ рrосеss mоdеling аnd imрrоvеmеnt using ВРМN 2.0. – Соdу-Саssidу, 2009.

Глава 5. Регламентация бизнес-процессов организации.

5.1. Культура регламентации в российских компаниях.

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

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

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

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

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

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

• «исотизированные» (слишком общие) регламенты;

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

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

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

5.1.2. Отсутствие культуры работы по стандартам.

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

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

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

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

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

• недостаток ресурсов;

• прочее.

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

5.1.4. Система стимулирования.

В крупных компаниях есть СПП, КПЭ[105] и другие системы показателей, часть которых используется для материального стимулирования сотрудников. Чаще всего они ориентированы на достижения показателей результативности (план/факт), реже – на эффективность. Совсем редко в рамках системы стимулирования предусмотрены элементы, мотивирующие персонал на исполнение регламентирующих документов. Почему? Выдвину некоторые предположения:

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

• регламенты слабо связаны с нормативами (см. ниже);

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

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

5.1.5. Отсутствие нормирования труда в привязке к регламентам.

Какую информацию должен содержать регламент выполнения процесса? Есть несколько точек зрения на этот вопрос. Как минимум в него включают:

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

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

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

• подробное пошаговое описание операций процесса (часто в виде таблицы).

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

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

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

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

Приведу цитату с сайта Национального союза кадровиков:

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

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

5.1.6. «Исотизированные» (слишком общие) регламенты.

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

5.1.7. Регламентация процессов производства при отсутствии регламентации процессов управления/развития.

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

Хочу обратить внимание читателя и на другой аспект.

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

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

5.1.8. Отсутствие системы работы с регламентами.

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

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

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

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

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

• регламенты согласовывают, но не утверждают (работа впустую);

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

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

• прочее.

Подробно система стандартизации бизнес-процессов описана в параграфе 5.4.

5.2. Минусы регламентации бизнес-процессов.

Регламентация бизнес-процессов не всегда абсолютно и безусловно нужна организации. Точно так же как витамины полезны живому организму лишь до известной степени. В разделах 5.2–5.3 рассмотрим плюсы и минусы регламентации. Их выявление и обсуждение должно помочь уяснить положительные возможности и свести к минимуму риски построения системы регламентирующих документов в масштабах компании.

Рассмотрим минусы регламентации. Как правило, к их числу относят:

• значительные затраты на регламентацию;

• снижение творчества, инициативы сотрудников;

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

• снижение гибкости в принятии решений, осуществлении изменений и как следствие – уход клиентов;

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

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

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

• возможность так называемой итальянской забастовки (см. пункт 5.2.8);

• возможную утечку информации о стандартах в другие организации;

• прочее.

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

5.2.1. Значительные затраты на регламентацию.

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

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

5.2.2. Снижение творчества, инициативы сотрудников.

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

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

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

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. Плюсы регламентации бизнес-процессов.

Мы рассмотрели некоторые возможные минусы регламентации. Обратимся теперь к плюсам. К ним можно отнести:

На стадии внедрения системы регламентации:

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

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

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

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

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

На стадии эксплуатации системы регламентации:

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

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

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

• повышение эффективности процессов подбора и обучения персонала;

• создание возможностей для аудита бизнес-процессов и запуска системы непрерывного совершенствования (цикла РDСА);

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

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

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. Создание возможностей для аудита бизнес-процессов и запуска системы непрерывного совершенствования (цикла РDСА).

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

Наличие системы регламентации процессов (исполнение – контроль – актуализация/улучшение нормативно-методических документов) – один из факторов успешного внедрения цикла непрерывного совершенствования РDСА.

5.3.11. Создание предпосылок для последующей эффективной автоматизации бизнес-процессов.

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

5.3.12. Обеспечение возможности развития бизнеса.

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

5.4. Система стандартизации бизнес-процессов.

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

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

5.4.1. Определение системы стандартизации бизнес-процессов.

Сформулируем определение системы стандартизации (ее можно также называть системой регламентации) бизнес-процессов:

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

На рис. 5.4.1 представлены важнейшие элементы системы стандартизации бизнес-процессов.

Рассмотрим каждый их этих элементов, начиная с методов.

_{Рис. 5.4.1. Элементы системы стандартизации процессов}

^{ЖЦ НМД – жизненный цикл нормативно-методических документов организации.}

5.4.2. Методы системы.

Среди документов (в рамках системы стандартизации) центральное место занимает методика моделирования (стандарт описания) процессов. Она включает в себя описание подходов к созданию моделей (описаний) процессов организации. Поскольку сейчас широко распространены и доступны среды моделирования бизнес-процессов, такая методика должна учитывать возможности и ограничения выбранного программного продукта (МS Visiо, Вusinеss Studiо, Саsеwisе, АRIS и др.)[108]. В практике бизнес-моделирования документ, содержащий требования по использованию программного продукта, часто называют «соглашение по моделированию».

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

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

• порядок разработки и согласования НМД;

• порядок ввода НМД в действие (в том числе кодирование НМД);

• порядок выдачи копий НМД сотрудникам;

• порядок актуализации НМД;

• порядок отмены действия НМД;

• прочее.

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

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

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

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

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

5.4.3. Инструменты системы.

Для создания системы стандартизации бизнес-процессов можно использовать различные программные инструменты. В первую очередь речь идет о среде бизнес-моделирования (Вusinеss Рrосеss Аrсhitесturе или Еntеrрrisе Аrсhitесturе), при помощи которой можно описывать:

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

• подразделения и должности;

• документы и информацию;

• прочее.

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

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

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

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 подпроцессов – процессов второго уровня. В свою очередь эти процессы были описаны в виде кросс-функциональных схем формата АЧ (такой формат удобен при создании регламентирующих документов). Документ, содержащий эту схему и текстовое описание соответствующих операций, на рис. 5.5.1 назван «Регламентом (инструкцией) выполнения процесса». Форма документа может варьироваться в зависимости от задач.

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

На рис. 5.5.2 структура регламентирующей документации представлена в более полном виде. Условно показаны три уровня: 1) уровень компании в целом; 2) уровень процессов и подразделений; 3) операционный уровень (процессы типа Wоrк Flоw).

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

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

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

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

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

• бюджетирования;

• ценообразования;

• прочее.

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

_{Рис. 5.5.2. Структура НМД компании}

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

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

5.5.3. Одноуровневый регламент выполнения процесса.

Рассмотрим так называемый одноуровневый регламент выполнения процесса. Объект регламентации для этого документа:

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

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

Шаблон одноуровневого регламента представлен в приложении 2.

Предложенный шаблон одноуровневого регламента весьма прост, но имеет некоторые особенности.

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

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

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

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

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

• методы контроля исполнения требований.

При необходимости шаблон регламента процесса можно дополнить нужными разделами.

5.5.4. Двухуровневый регламент выполнения процесса.

Объект регламентации двухуровневого регламента – это:

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

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

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

5.5.5. Положение о подразделении и должностная инструкция.

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

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

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

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

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].

Если разработка НМД полезна, ГД визирует служебную записку на разработку НМД и передает ее помощнику ГД.

Помощник ГД готовит проект распоряжения о разработке НМД и передает ГД.

ГД подписывает распоряжение о разработке/пересмотре НМД и передает своему помощнику.

Помощник ГД регистрирует распоряжение, ставит его на контроль и передает копию распоряжения ответственному разработчику (ОР). ОР получает копию распоряжения и приступает к разработке НМД.

5.6.5. Разработка и презентация первой версии НМД.

Ответственный разработчик готовит первую версию НМД и отправляет ее в электронном виде согласующим руководителям и помощнику ГД (рис. 5.6.2).

_{Рис. 5.6.2. Разработка и презентация первой версии НМД}

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

Согласующие руководители и инициатор разработки НМД рассматривают проект НМД в течение двух рабочих дней.

Ответственный разработчик организует и проводит презентацию проекта НМД для согласующих руководителей и инициатора разработки.

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

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

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

Помощник ГД помещает вторую версию НМД в электронный архив.

5.6.6. Согласование проекта НМД.

При необходимости ОР организует и проводит совещание по согласованию проекта НМД (рис. 5.6.3). Согласующие руководители и инициатор разработки принимают в нем участие.

_{Рис. 5.6.3. Согласование проекта НМД}

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

ГД принимает решение по редакции спорных пунктов и передает его ОР (в электронном виде).

ОР вносит изменения в проект НМД и передает третью версию проекта НМД помощнику ГД.

Помощник ГД помещает ее в электронный архив.

После формирования третьей версии НМД (или второй, если совещание по согласованию НМД не требуется) ОР проверяет потребность в тестировании. Если оно необходимо, то ОР приступает к его организации. Если в тестировании нет надобности, то ОР уведомляет помощника ГД, который приступает к вводу НМД в действие.

5.6.7. Тестирование проекта НМД.

Ответственный разработчик готовит план тестирования проекта НМД и передает его ГД (см. рис. 5.6.4).

_{Рис. 5.6.4. Тестирование проекта НМД}

ГД утверждает план тестирования НМД.

ОР осуществляет тестирование проекта НМД. В нем принимают участие согласующие руководители и инициатор разработки НМД. Цель тестирования – выявление недостатков в проекте НМД и определение необходимых корректировок.

По итогам тестирования ОР формирует третью или четвертую версию проекта НМД и предоставляет ее помощнику ГД, согласующим руководителям и инициатору разработки НМД.

Помощник ГД помещает третью/четвертую версию НМД в электронный архив.

Согласующие руководители и инициатор разработки НМД согласуют изменения в проекте НГД по результатам тестирования (по электронной почте).

При необходимости ОР вносит изменения в проект НМД и передает его помощнику ГД на проверку соответствия требованиям по оформлению документа.

5.6.8. Ввод НМД в действие.

Помощник ГД выполняет контроль НМД на соответствие стандартам (требованиям по оформлению) (см. рис. 5.6.5). Если есть замечания, проект НМД возвращается ОР на доработку.

_{Рис. 5.6.5. Ввод НМД в действие}

Помощник ГД присваивает НМД код в соответствии с требованиями настоящей процедуры.

Помощник ГД готовит проект приказа ГД о вводе НМД в действие и передает его ГД.

ГД подписывает приказ о вводе НМД в действие.

Помощник ГД регистрирует приказ, заполняет паспорт документа, распечатывает НМД и ставит на титульном листе штамп «Контрольный экземпляр».

Помощник ГД собирает подписи на оригинале НМД: подпись ГД «Утверждаю» на титульном листе и подписи согласующих руководителей.

Помощник ГД уведомляет сотрудников организации по е-mаil о вводе НМД в действие. Если нужно, он собирает подписи сотрудников на НМД (например, на должностной инструкции).

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

5.6.9. Хранение и выдача учтенных копий НМД.

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

Помощник ГД распечатывает НМД на желтой бумаге и уведомляет сотрудника о готовности документа.

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

Бумажная копия НМД выдается только после учета в журнале (рис. 5.6.6).

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

_{Рис. 5.6.6. Выдача учтенных копий НМД}

Все НМД организации хранятся:

• в электронном архиве на сервере организации;

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

Бумажные оригиналы НМД хранятся в архиве организации в нумерованных папках. Для каждой формируется лист «Содержание».

Ответственность за ведение электронного и бумажного архива НМД несет помощник ГД.

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

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

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

НМД могут быть переданы за пределы организации только с разрешения ГД. При передаче копии на нее ставится синий штамп «Для информации» (то есть документ не контролируется).

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

Проекты НМД хранятся в отдельном каталоге на сервере организации.

Не реже раза в месяц помощник ГД осуществляет резервное копирование электронной базы НМД:

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

• на DVD и т. п. (зависит от решения IТ-директора или менеджера).

5.6.10. Контроль исполнения НМД.

Контроль и актуализация НМД проводится со следующей периодичностью (табл. 5.6.5).

_{Таблица 5.6.5. Периодичность контроля и актуализации НМД}

Состав работ по контролю/актуализации НМД представлен на рис. 5.6.7. За две недели до планового срока контроля (аудита исполнения требований НМД) помощник ГД уведомляет ОР, внутреннего аудитора, руководителей подразделений, которые обязаны контролировать исполнение требований НМД. Помощник ГД назначает дату контроля НМД.

_{Рис. 5.6.7. Контроль исполнения НМД}

Указанные выше лица готовятся к аудиту исполнения требований НМД.

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

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

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

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

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

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

ГД рассматривает отчет по результатам аудита и принимает решение оставить НМД без изменений, пересмотреть или отменить НМД. О своем решении ГД уведомляет ОР, внутреннего аудитора и руководителя подразделения.

ГД в одном приказе отменяет действие устаревшей версии НМД и вводит в действие новую версию. Помощник ГД выполняет процесс отмены НМД и необходимые действия по вводу новой версии НМД.

5.6.11. Отмена НМД.

Помощник ГД получает от шефа информацию об отмене НМД и готовит соответствующий проект приказа (рис. 5.6.8).

_{Рис. 5.6.8. Отмена действия НМД}

ГД утверждает проект приказа об отмене НМД. В приказе об отмене устаревшей версии может содержаться информация о вводе в действие новой версии НМД.

Помощник ГД регистрирует приказ ГД об отмене НМД. Ставит на контрольный экземпляр НМД синюю печать «Отменен/Пересмотрен». Перемещает документ в архив отмененных НМД.

Помощник ГД удаляет отмененный НМД с сервера организации из общего доступа, сохраняя его в электронном архиве организации в папке «Отмененные НМД». Он уведомляет персонал по е-mаil об отмене НМД.

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

5.6.12. Кодирование НМД.

Код НМД организации состоит из комбинации букв и цифр и имеет следующий вид:

Где АААА – буквы и цифры, определяющие вид документа. Возможные комбинации этой части кода показаны в табл. 5.6.6.

_{Таблица 5.6.6. Коды документов}

АААА-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]

5.9. Контроль исполнения требований НМД.

Рассмотрим вопрос контроля исполнения требований НМД. Можно выделить шесть основных возможностей (направлений) такого контроля:

1. Самоконтроль.

2. Контроль непосредственным руководителем.

3. Контроль по показателям.

4. Внутренний аудит.

5. Жесткая автоматизация.

6. Контроль, интегрированный в процесс.

5.9.1. Самоконтроль.

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

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

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

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

• ресурс времени.

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

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

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

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

5.9.2. Контроль непосредственным руководителем.

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

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

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

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

Кроме визуального контроля руководитель может проводить аудит исполнения требований стандартов сотрудниками. При этом он проверяет:

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

• формальное содержание документов (соответствие шаблонам, наличие необходимых данных и т. п.);

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

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

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

5.9.3. Контроль по показателям.

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

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

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

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

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

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

При соблюдении этих условий можно по отклонениям показателей судить об исполнении требований стандартов/регламентов или об отсутствии отклонений от устоявшейся практики работы (если регламенты не документированы). Если стандарты выполнения работы перестают выполняться (возникают нарушения), то этот факт сразу находит отражение в значении показателей. Проводить мониторинг динамики изменения значений показателей может как непосредственный, так и вышестоящий руководитель. Если в компании внедрена система управления эффективностью (Вusinеss Реrfоrmаnсе Маnаgеmеnt), то ряд наиболее важных показателей доступен для мониторинга руководителям нескольких уровней на их индивидуальных панелях управления.

5.9.4. Внутренний аудит.

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

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

Аудит может проводиться при помощи:

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

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

• проведения интервью при помощи перечня контрольных вопросов;

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

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

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

5.9.5. Жесткая автоматизация процесса.

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

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

Поэтому сейчас активно развивается целый класс систем, предназначенных для автоматизации операционных процессов. Это так называемые системы Вusinеss Рrосеss Маnаgеmеnt (ВРМS). Некоторые горячие сторонники полагают, что процессный подход возможен только при внедрении указанных средств автоматизации. На мой взгляд, это слишком узкий подход к использованию процессных принципов организации деятельности, хотя внедрение ВРМS в определенных случаях полезно для компании. Хорошая ВРМ-система позволит сотрудникам самим описывать свою деятельность и быстро перенастраивать процессы. Но ВРМS – это техническое средство, инструмент. Эффективность его применения зависит от квалификации специалистов. Внедряя ВРМ-систему, нужно одновременно налаживать коммуникации и разрушать межфункциональные барьеры, обучать менеджеров управлять процессами и вовлекать персонал в деятельность по улучшению процессов. Тогда компания сможет получить значительный эффект от автоматизации.

5.10. Подходы к регламентации: оптимизация или директива?

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

5.10.1. Регламентация, основанная на результатах оптимизации.

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

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

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

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

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

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

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

5.10.2. Директивная регламентация.

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

• сам руководитель;

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

• межфункциональная рабочая группа;

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

• внешний консультант;

• прочее.

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

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

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

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

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

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

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

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

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

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

1. Репин В. В. Бизнес-процессы компании: построение, анализ, регламентация. – М.: Стандарты и качество, 2007.

2. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: Стандарты и качество, 2004.

3. Елиферов В. Г., Репин В. В. Бизнес-процессы. Регламентация и управление. – М.: Инфра-М, 2009.

4. Николаева С. А., Шебек С. В. Корпоративные стандарты: от концепции до инструкции. – М.: Книжный мир, 2002.

5. Харрингтон Дж. Совершенство управления процессами. – М.: Стандарты и качество, 2007.

Глава 6. Управление бизнес-процессами.

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

6.1.1. Процессы управления в системе процессов компании.

С практической точки зрения важен вопрос определения и описания процессов управления. В качестве примера рассмотрим модель АРQС, версия 5[118]. Содержит ли она процессы управления? В определенном смысле – да. Перечислю некоторые процессы, содержащие термин «управлять»:

1.3. Управлять стратегическими инициативами…

2.1. Управлять портфелем продуктов/услуг…

2.1.5. Управлять жизненным циклом продуктов/услуг…

3.5. Разрабатывать планы по продажам и управлять ими…

3.5.3. Управлять продажами…

4.1.2. Управлять спросом на продукты/услуги…

4.1.4.2. Управлять запасами незавершенного производства…

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

Вариант 1. Процессы управления объектами управления (стратегия, планы продаж, продукты и услуги, запасы и т. п.).

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

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

На мой взгляд, модель АQРС содержит процессы управления объектами (вариант 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. Определение процессов управления на основе временных контуров.

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

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

• Ежедневный (даже ежечасный) контур управления – управление оперативной деятельностью:

– личное выполнение ряда действий (операций) в операционных процессах (как правило, для руководителей среднего и нижнего уровня);

– оперативный контроль так называемых экземпляров процесса (если используется система Wоrк Flоw или ВРМS);

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

• Еженедельный контур управления:

– анализ деятельности за неделю;

– анализ деятельности за неделю по отдельным сотрудникам и принятие решений по материальному стимулированию;

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

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

– контроль состояния оборудования и среды[121];

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

– согласование закупок ТМЦ для нужд подразделения (визирование счетов);

– …

• Ежемесячный контур управления:

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

– формирование плана на следующий месяц (квартал);

– закрытие табелей за месяц;

– разработка графика ТО[122] на месяц;

– …

• Ежеквартальный контур управления:

– анализ деятельности за квартал и подготовка отчета;

– уточнение плана и бюджета подразделения на следующий квартал;

– заключение договоров на поставку ТМЦ;

– …

• Ежегодный контур управления:

– анализ деятельности за год и подготовка отчета;

– формирование плана и бюджета отдела на следующий год;

– формирование графика отпусков сотрудников;

– формирование графика обучения сотрудников;

– …

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

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

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

В этом примере встречаются как процессы управления процессами, так и процессы управления подразделениями.

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

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

Чем ниже по иерархической лестнице находится руководитель, тем меньше у него процессов управления подразделением и тем больше процессов управления операционными процессами. На верхнем уровне руководства (директор, замдиректора, начальник департамента) доля работы руководителя, связанная с управлением операционными процессами, минимальна. На нижнем уровне управления (начальник отдела, руководитель сектора, группы, участка и т. п.) доля работы по управлению операционными процессами выше. Но она никогда не достигает 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 linе – «дорожки плавательного бассейна»). Несмотря на то что процессы просты, в них принимают участие различные специалисты отделов коммерческой службы и других подразделений (например, в процессе «Подготовка коммерческих предложений»). Это межфункциональные (сквозные) процессы.

Затем сформировали регламенты в МS Wоrd, содержавшие схемы бизнес-процессов, таблицы с описанием операций, приложения с формами используемых документов. Одним словом, были разработаны и утверждены стандарты работы компании в области продаж.

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

Руководитель размышлял примерно так: при выполнении работы менеджер ОП должен следовать утвержденным стандартам – выполнять последовательность шагов, представленных в схеме бизнес-процесса. Но в документе изображена идеальная схема. На практике менеджер делает примерно 40–50 звонков в неделю. При этом в 60 % случаев он соблюдает требования стандарта (но это предположение еще нуждается в аудите), в 30 % отклоняется от них из-за особенностей клиента, а в 10 % случаев вообще говорит что хочет. С точки зрения бизнеса имеет значение число звонков, которое сделал менеджер за неделю, а еще интереснее – какое количество из них завершились переговорами с клиентом. Кроме того, много переговоров – это хорошо, но немаловажен их результат – объем заключенных сделок, общая выручка и маржа по сделкам. Иными словами, для управления были бы полезны следующие показатели по каждому менеджеру ОП (за неделю, месяц):

• количество встреч/количество звонков, %;

• количество контрактов/количество звонков, %;

• количество контрактов/количество переговоров, %;

• маржа от сделок/количество звонков;

• маржа от сделок/количество переговоров;

• выручка;

• маржа от сделок/зарплата менеджера и т. п.

Полезно рассмотреть показатели не только каждого менеджера, но и ОП в целом. Таким образом, реальные объекты управления – это деятельность и каждого менеджера, и всего отдела. Важно оценивать и анализировать результативность и эффективность работы каждого сотрудника в отдельности. Потом можно принимать управленческие решения – менять менеджеров, систему мотивации, стандарты работы (те самые схемы бизнес-процессов), оборудование (телефоны, компьютеры), программное обеспечение и т. п. С точки зрения отдела в целом можно изменить процессы управления, механизмы коммуникаций, мотивацию, планограмму посадки менеджеров в помещении, закрыть доступ на развлекательные сайты (типа www.аnекdоt.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, при этом четко понимая, что он включает не реально выполняемые бизнес-процессы, а иерархический справочник схем бизнес-процессов – стандартов выполнения работы сотрудниками компании. Также стало понятно, что надо фиксировать исходные данные и рассчитывать показатели по бизнес-процессам как на уровне менеджеров ОП, так и для отдела в целом. Была разработана система показателей с соответствующей аналитикой. Эта система использовалась для анализа деятельности ОП и принятия решений по ее совершенствованию. В том числе одним из направлений стала работа по изменению схем бизнес-процессов.

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

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

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

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

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

6.3. Объекты управления в рамках процесса.

На рис. 6.3.1 представлена развернутая модель управления деятельностью (процессом). Ее основное назначение – акцентировать внимание читателя на объектах, которыми может и должен управлять руководитель в рамках управления процессом. Поскольку наше определение процесса достаточно широкое (см. главу 1), управление всеми объектами, представленными на рис. 6.3.1, можно назвать процессным управлением. Некоторые специалисты, рассматривая определение процесса в узком смысле, подразумевают под процессным управлением деятельность по контролю и координации экземпляров процесса в рамках автоматизируемых (или уже автоматизированных) операционных цепочек. Такой взгляд кажется мне слишком ограниченным. Реальное управление процессами требует более широкого, комплексного взгляда. Тем более что в компаниях[128] наблюдается следующая картина:

• 50–60 % операционных процессов выполняется без использования каких-либо прикладных систем[129] (ЕRР, СRМ, автоматизация бухучета) – применяют обычные офисные приложения (например, Wоrd, Ехсеl);

• 30–40 % выполняется с использованием прикладных систем (в первую очередь учетных, например 1С);

• только 5–10 % операционных процессов компании целесообразно автоматизировать при помощи продуктов класса ВРМ.

_{Рис. 6.3.1. Расширенная схема управления процессом}

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

В первую очередь руководитель управляет операционной деятельностью, в том числе выполняет:

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

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

• перераспределение ресурсов;

• оперативный анализ и разрешение конфликтных ситуаций;

• прочее.

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

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

• модуль мониторинга и анализа процессов в системе ВРМS;

• панели управления, реализованные в системе класса Вusinеss Реrfоrmаnсе Маnаgеmеnt (или просто таблицы и графики в МS Ехсеl);

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

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

• прочие программные продукты.

Замечу, что никакие программные продукты не заменят квалификацию и опыт управления.

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

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

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

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

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

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. Показатели процесса «Закупка товара»}

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

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

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

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

• категория показателя;

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

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

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

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

• определение показателя;

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

• методика расчета показателя;

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

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

Наименование и код показателя в системе показателей компании.

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

Категория показателя.

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

• финансовые;

• рыночные;

• по процессам;

• по персоналу;

• по инновациям.

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

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

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

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

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

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

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

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

Периодичность расчета и отчетный период.

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

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

Определение показателя.

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

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

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

Единица измерения показателя.

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

Методика (формула) расчета показателя.

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

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

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

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

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

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

Если в компании используется среда моделирования бизнес-процессов (например, Вusinеss Studiо), то ее можно использовать для:

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

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

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

• планирования показателей и формирования отчетных форм;

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

• прочее.

На рис. 6.4.3 показан фрагмент справочника целей и показателей в Вusinеss Studiо, а на рис. 6.4.4 – несложная панель управления, которую можно использовать для мониторинга изменения значений показателей по бизнес-процессам.

_{Рис. 6.4.3. Справочник целей и показателей в Вusinеss Studiо}

_{Рис. 6.4.4. Панель управления показателями в Вusinеss Studiо}

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

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

Оперативное управление осуществляется на всех уровнях иерархии менеджмента компании. Различие состоит только в масштабе управляемой деятельности.

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

• фактическую информацию за предыдущие периоды;

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

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

• прочую информацию.

Процедура формирования плана по процессу представлена на рис. 6.5.1.

_{Рис. 6.5.1. Формирование плана по процессу}

На шаге 1 руководитель (владелец процесса) получает планы от руководителей нижестоящего уровня (владельцев подпроцессов) и анализирует эти планы. Он рассматривает предлагаемые снизу корректирующие мероприятия, а также действия по совершенствованию процессов (в рамках цикла РDСА)[131].

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

1. Операционные планы и показатели по процессу.

Раздел для представления существующих показателей и планов по операционной деятельности.

1.1. Операционные показатели по процессу.

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

1.2. Операционные планы по процессу.

Раздел для описания операционных планов по процессу.

2. Показатели улучшения процесса (цикл РDСА, в том числе показатели из системы ВSС[132]).

Раздел для описания плановых показателей, установленных в рамках выполнения цикла РDСА и в рамках системы ВSС.

3. Мероприятия (проекты) по улучшению процессов (цикл РDСА, инициативы в системе ВSС).

Раздел для описания мероприятий (проектов), которые выполняются в рамках выполнения цикла РDСА, и для описания инициатив (проектов) в рамках системы ВSС.

4. Корректирующие мероприятия (для устранения причин отклонений от нормального хода процесса).

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

На шаге 2 руководитель определяет приоритетность мероприятий с точки зрения:

• установленных целей компании;

• требований внутренних и внешних потребителей;

• наличия необходимых ресурсов.

После согласования состава мероприятий по подпроцессам и определения требуемых ресурсов руководитель приступает в разработке/корректировке плана по процессу (процессам) своего уровня (шаг 3). Он формирует:

• операционные планы по процессу (процессам);

• планы цикла РDСА и инициативы ВSС;

• планы корректирующих мероприятий.

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

На шаге 4 руководитель вышестоящего уровня рассматривает и согласует план по процессу (процессам).

На шаге 5 руководитель утверждает планы по подпроцессам и доводит их до нижестоящих руководителей (владельцев процессов).

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

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

Мониторинг процесса[133] осуществляется владельцем процесса по ряду показателей:

• установленных в отчетности вышестоящим руководителем;

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

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

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

_{Рис. 6.5.2. Пример анализа процесса по одному из показателей}

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

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

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

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

• требованиями вышестоящего руководства;

• требованиями государственных стандартов и других внешних нормативных документов.

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

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

_{Рис. 6.5.3. Мониторинг хода процесса}

На шаге 1 владелец процесса контролирует получение фактической информации по процессу. Данные могут собираться:

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

• автоматически фиксироваться различными системами.

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

На шаге 2 на основе фактической информации о ходе и результатах процесса владелец либо его сотрудники формируют таблицы, графики, контрольные карты по выбранным показателям. Для решения этой задачи могут использоваться различные программные продукты – от МS Ехсеl до систем ВРМ[134] или специализированных программных продуктов для статистической обработки данных.

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

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

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

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

По итогам мониторинга и анализа причин отклонений владелец процесса:

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

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

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

Владелец процесса выполняет корректирующие действия следующим образом (рис. 6.5.4).

_{Рис. 6.5.4. Выполнение корректирующих действий}

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

Шаг 2 – это определение возможных корректирующих мероприятий и расчет затрат на них.

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

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

На шаге 5 владелец процесса выполняет корректирующее мероприятие (лично управляет выполнением или контролирует его).

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

6.5.4. Совершенствование процесса на основе цикла РDСА.

Владелец процесса выполняет цикл непрерывного совершенствования процесса (цикл РDСА) следующим образом (рис. 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 материал поможет вам системно построить работу с бизнес-процессами.

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

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

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

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

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

Приложение 1. Система процессов АРQС.

В приложении представлен авторский перевод системы процессов организации АРQС. Эта система процессов полезна как для освоения подходов к построению процессного дерева, так и для анализа и совершенствования системы процессов организации.

Система включает в себя 12 категорий процессов:

1. Развивать видение и стратегию.

2. Развивать продукты/услуги и управлять ими.

3. Выполнять маркетинг и продавать продукты/услуги.

4. Поставлять продукты и оказывать услуги.

5. Управлять обслуживанием потребителей.

6. Развивать человеческий капитал (персонал) и управлять им.

7. Управлять информационными технологиями (IТ).

8. Управлять финансовыми ресурсами.

9. Приобретать, возводить недвижимость и управлять ею.

10. Управлять охраной окружающей среды, здоровьем и безопасностью жизнедеятельности (ЕНS).

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. Развивать НR-планирование, политики и стратегии и управлять ими.

6.1.1. Развивать НR-стратегию.

6.1.1.1. Выявлять стратегические потребности в области НR.

6.1.1.2. Определять бизнес-роли и ответственность персонала.

6.1.1.3. Устанавливать затраты на персонал.

6.1.1.4. Устанавливать показатели оценки персонала.

6.1.1.5. Информировать персонал об НR-стратегии.

6.1.2. Разрабатывать и реализовывать планы в области НR.

6.1.2.1. Собирать квалификационные требования в соответствии с корпоративной стратегией и рыночной средой.

6.1.2.2. Планировать требования по обеспечению персоналом подразделений/компании в целом.

6.1.2.3. Развивать систему оплаты труда.

6.1.2.4. Развивать план по наставничеству.

6.1.2.5. Развивать план диверсификации персонала.

6.1.2.6. Развивать другие программы в области НR.

6.1.2.7. Развивать НR-политики.

6.1.2.8. Управлять НR-политиками.

6.1.2.9. Планировать льготы для персонала.

6.1.2.10. Развивать стратегию для НR-систем/технологий/программного обеспечения.

6.1.2.11. Развивать модели НR-стратегии.

6.1.3. Осуществлять мониторинг и корректировать планы.

6.1.3.1. Измерять достижение целей.

6.1.3.2. Измерять вклад в стратегию бизнеса.

6.1.3.3. Уведомлять собственников о корректировках планов.

6.1.3.4. Определять добавленную ценность от управления НR.

6.1.3.5. Анализировать и пересматривать НR-планы.

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. Уведомлять об изменениях по вакансиям руководителя по НR.

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. Управлять программным обеспечением в области управления персоналом (НRIS).

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. Управлять информационными технологиями (IТ).

7.1. Управлять бизнесом в сфере информационных технологий.

7.1.1. Развивать IТ-стратегию компании.

7.1.1.1. Формировать стратегическую информацию.

7.1.1.2. Выявлять IТ-потребности компании на долгосрочную перспективу вместе с собственниками (учредителями).

7.1.1.3. Определять стратегические стандарты, направления и принципы развития.

7.1.1.4. Определять и утверждать стандарты IТ-архитектуры и развития информационных технологий.

7.1.1.5. Определять стратегических поставщиков IТ.

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. Выполнять функции центра обмена информацией в сфере IТ-инноваций и изучения информационных технологий.

7.1.2.5. Управлять корпоративной архитектурой.

7.1.3. Управлять IТ-портфелем.

7.1.3.1. Утверждать IТ-портфель.

7.1.3.2. Анализировать и оценивать ценность IТ-портфеля для компании.

7.1.3.3. Обеспечивать ресурсами в соответствии со стратегическими приоритетами.

7.1.4. Выполнять исследования в области IТ и инноваций.

7.1.4.1. Исследовать технологии для инноваций IТ-сервисов/решений.

7.1.4.2. Переходить на реально работающие технологии в области IТ-сервисов/решений.

7.1.5. Осуществлять управление финансами с помощью информационных технологий.

7.1.5.1. Развивать и поддерживать IТ-сервисы/решения для обеспечения прозрачности затрат.

7.1.5.2. Устанавливать и поддерживать процессы учета.

7.1.5.3. Управлять бюджетами проектов на основе контрольных точек.

7.1.6. Оценивать ценность и эффективность IТ для бизнеса и доводить эту информацию до сотрудников.

7.1.6.1. Утверждать ключевые показатели эффективности и проводить их мониторинг.

7.1.6.2. Оценивать эффективность IТ-плана.

7.1.6.3. Информировать о ценности информационных технологий.

7.1.7. Осуществлять управление персоналом в области IТ.

7.1.7.1. Развивать IТ-руководство и персонал.

7.1.7.2. Управлять эффективностью работы IТ-персонала.

7.1.8. Управлять поставщиками IТ-услуг и IТ-договорами.

7.1.8.1. Развивать стратегии осуществления доставок в области IТ.

7.1.8.2. Вести переговоры с поставщиками.

7.1.8.3. Утверждать и поддерживать взаимосвязи с поставщиками.

7.1.8.4. Оценивать эффективность поставщиков.

7.1.8.5. Оценивать эффективность договоров.

7.2. Развивать взаимосвязи с потребителями информационных технологий и управлять ими.

7.2.1. Развивать стратегию IТ-сервисов/решений.

7.2.1.1. Изучать IТ-сервисы/решения для приведения их в соответствие с требованиями бизнеса и пользователей.

7.2.1.2. Переводить требования бизнеса и пользователей в требования к IТ-сервисам/решениям.

7.2.1.3. Определять стратегические инициативы в сфере IТ-сервисов/решений.

7.2.1.4. Согласовывать стратегии с внутренними собственниками (учредителями) для обеспечения соответствия.

7.2.1.5. Оценивать и выбирать стратегические инициативы в сфере IТ-сервисов/решений.

7.2.2. Развивать и управлять уровнем IТ-сервисов.

7.2.2.1. Создавать и поддерживать каталог IТ-сервисов/решений.

7.2.2.2. Устанавливать и поддерживать соглашения об уровнях IТ-сервиса.

7.2.2.3. Оценивать и отчитываться по результатам выполнения уровней сервиса.

7.2.2.4. Обсуждать возможности повышения уровней IТ-сервиса.

7.2.3. Осуществлять управление спросом на IТ-сервисы.

7.2.3.1. Анализировать потребление и использование IТ-сервисов/решений.

7.2.3.2. Развивать и осуществлять мотивационные программы, повышающие эффективность потребления.

7.2.3.3. Развивать прогноз для IТ-сервисов/решений в количественном и стоимостном выражении.

7.2.4. Управлять удовлетворенностью потребителей информационных технологий.

7.2.4.1. Собирать данные по удовлетворенности потребителей и анализировать их.

7.2.4.2. Оценивать и обсуждать модели удовлетворенности потребителей.

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

7.2.5. Выполнять маркетинг IТ-сервисов/решений.

7.2.5.1. Развивать маркетинговую стратегию в сфере IТ-сервисов/решений.

7.2.5.2. Развивать стратегию работы с потребителями информационных технологий и управлять ею.

7.2.5.3. Управлять рекламными кампаниями в сфере IТ-сервисов/решений.

7.2.5.4. Обрабатывать и отслеживать заказы в сфере IТ-сервисов/решений.

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. Анализировать потребности управления информацией и контентом и роль IТ-сервисов в осуществлении бизнес-стратегии.

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. Развивать и поддерживать IТ-решения.

7.5.1. Развивать стратегию развития информационных технологий.

7.5.1.1. Утверждать стратегию поставок для развития информационных технологий.

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

7.5.1.3. Выбирать методологии и инструменты развития.

7.5.2. Осуществлять планирование жизненного цикла IТ-сервисов/решений.

7.5.2.1. Планировать развитие новых требований.

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

7.5.2.3. Развивать план жизненного цикла для IТ-сервисов/ решений.

7.5.3. Развивать и поддерживать архитектуру IТ-сервисов/решений.

7.5.3.1. Создавать архитектуру IТ-сервисов/решений.

7.5.3.2. Пересматривать архитектуру IТ-сервисов/решений.

7.5.3.3. Прекращать действие устаревшей архитектуры IТ-сервисов/решений.

7.5.4. Создавать IТ-сервисы/решения.

7.5.4.1. Анализировать подтвержденные требования.

7.5.4.2. Разрабатывать IТ-сервисы/решения.

7.5.4.3. Получать/развивать компоненты IТ-сервисов/решений.

7.5.4.4. Готовить ресурсы для создания IТ-сервисов/решений.

7.5.4.5. Тестировать IТ-сервисы/решения.

7.5.4.6. Подтверждать одобрение потребителей.

7.5.5. Поддерживать IТ-сервисы/решения.

7.5.5.1. Анализировать требования к обслуживанию/улучшениям и выполнять оценку несоответствий.

7.5.5.2. Разрабатывать изменения для существующих IТ-сервисов/решений.

7.5.5.3. Получать/развивать измененные компоненты IТ-сервисов/решений.

7.5.5.4. Тестировать изменения IТ-сервисов/решений.

7.5.5.5. Прекращать использование IТ-сервисов/решений.

7.6. Развертывать (использовать) IТ-решения.

7.6.1. Развивать стратегию развертывания информационных технологий.

7.6.1.1. Утверждать политики изменения IТ-сервисов/решений.

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. Поставлять и поддерживать IТ-сервисы.

7.7.1. Развивать стратегию поставки IТ-сервисов/решений.

7.7.1.1. Утверждать стратегию закупки в области информационных технологий.

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

7.7.1.3. Выбирать методологии и инструменты поставки.

7.7.2. Развивать стратегию IТ-поддержки.

7.7.2.1. Утверждать стратегию поставки для IТ-поддержки.

7.7.2.2. Определять услуги IТ-поддержки.

7.7.3. Управлять ресурсами информационной инфраструктуры.

7.7.3.1. Управлять IТ-обеспечением и ресурсами.

7.7.3.2. Управлять возможностями IТ-ресурсов.

7.7.4. Управлять операциями информационной инфраструктуры.

7.7.4.1. Поставлять IТ-сервисы/решения.

7.7.4.2. Оказывать услуги по поддержке IТ-операций.

7.7.5. Поддерживать IТ-услуги и решения.

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. Определять процессы и подходы в сфере IТ-знаний.

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. Определять показатели эффективности на основе метода АВС[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. Обрабатывать платежи системой электронных платежей (ЕFТs) и контролировать систему.

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. Управлять охраной окружающей среды, здоровьем и безопасностью жизнедеятельности (ЕНS).

10.1. Определять результаты ЕНS.

10.1.1. Оценивать воздействие продуктов, услуг и процессов на окружающую среду.

10.1.2. Проводить проверки по ЕНS.

10.2. Развивать и осуществлять программу ЕНS.

10.2.1. Выявлять нормативные требования и требования заинтересованных лиц (стейкхолдеров).

10.2.2. Оценивать будущие риски и возможности.

10.2.3. Разрабатывать политику в области ЕНS.

10.2.4. Фиксировать и управлять мероприятиями в области ЕНS.

10.3. Тренировать и обучать сотрудников.

10.3.1. Доводить проблемы ЕНS до сведения учредителей и решать их.

10.4. Осуществлять мониторинг и управлять программой ЕНS.

10.4.1. Управлять затратами и выгодами по программе ЕНS.

10.4.2. Измерять эффективность программы ЕНS и формировать отчетность.

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

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

10.4.3. Обеспечивать сотрудников поддержкой в части ЕНS.

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. Оценивать потребности в информационных технологиях и использовать IТ-функцию.

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. Шаблон «Должностная инструкция».

Об авторе.

Владимир Владимирович Репин – кандидат технических наук, доцент, исполнительный директор и партнер ООО «ВРМ Консалтинг Групп» (www.bрm3.ru). Область профессиональных интересов:

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

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

• внедрение среды описания и регламентации бизнес-процессов Вusinеss Studiо;

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

• управление информационным порталом по тематике процессного управления www.FinеХреrt.ru.

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

Автор книг: В. В. Репин. Бизнес-процессы компании: построение, анализ, регламентация (М.: РИА «Стандарты и качество», 2007); В. Г. Елиферов, В. В. Репин. Бизнес-процессы: регламентация и управление (М.: Инфра-М, 2004); В. В. Репин, В. Г. Елиферов. Процессный подход к управлению. Моделирование бизнес-процессов (М.: РИА «Стандарты и качество», 2004); В. В. Репин. Технологии управления финансами предприятия (М.: Издательский дом «АТКАРА», 2000).

Примечания.

1.

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

2.

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

3.

Рассматриваемый подход описан в «Исследовании в области моделирования бизнес-процессов» за 2011 год компании ВРТrеnds, перевод которого размещен на сайте www.FinеХреrt.ru.

4.

ВРМ (Вusinеss Реrfоrmаnсе Маnаgеmеnt) – управление эффективностью деятельности (бизнеса).

5.

КРI (Кеу Реrfоrmаnсе Indiсаtоrs) – ключевые показатели эффективности.

6.

ВРА (Вusinеss Рrосеss Аrсhitесturе) – система для разработки архитектуры бизнес-процессов компании.

7.

ЕСМ (Еntеrрrisе Соntеnt Маnаgеmеnt) – управление корпоративной информацией.

8.

ВI (Вusinеss Intеlligеnсе) – бизнес-анализ, бизнес-аналитика. Под этим понятием чаще всего подразумевают программное обеспечение, созданное для помощи менеджеру в анализе информации о своей компании и ее окружении.

9.

ВРМS (Вusinеss Рrосеss Маnаgеmеnt Sуstеm) – тип программного обеспечения для поддержки выполнения операционных процессов.

10.

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

11.

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

12.

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

13.

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

14.

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

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

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

15.

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

16.

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

17.

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

18.

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

19.

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

20.

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

21.

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

22.

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

23.

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

24.

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

25.

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

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.

Например, в системе Вusinеss Studiо.

73.

IDЕF0 (Funсtiоn Моdеling) – методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Прим. ред.

74.

Есть некоторые отраслевые стандарты на системы процессов (например, еТОМ – еnhаnсеd Теlесоm Ореrаtiоns Мар – многоуровневая модель бизнес-процессов телекоммуникационной компании; является базой для анализа и проектирования бизнес-процессов в отрасли связи) и типовые перечни процессов (например, модель АРQС), но общепризнанного комплексного стандарта проектирования системы процессов организации пока не существует. При применении некоторых существующих общих методических подходов (например, матрицы Захмана) количество разных моделей организации соответствует числу аналитиков, участвовавших в работе.

75.

Авторский перевод справочника версии 2010 года на русский язык представлен в приложении 1.

76.

В зависимости от сложности модели и общего количества уровней процессного дерева.

77.

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

78.

Например, такая ситуация может сложиться при формальном внедрении системы менеджмента качества в соответствии с требованиями стандарта ИСО 9000–2008.

79.

См. сайт www.bрm3.ru.

80.

Схема выполнена в нотации, разработанной компанией ФИНЭКСПЕРТ.РУ в период с 2007 по 2008 год.

81.

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

82.

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

83.

Unifу Моdеling Lаnguаgе – унифицированный язык моделирования.

84.

Вusinеss Рrосеss Моdеling Nоtаtiоn – нотация и модель бизнес-процессов.

85.

В некоторых западных подходах модель такого типа называют Еntеrрrisе Аrсhitесturе.

86.

В среде моделирования Вusinеss Studiо используется следующее определение: метаданные – описательная информация о структуре и смысле данных.

87.

Условное название модуля.

88.

Зависит от функциональных возможностей конкретной среды моделирования.

89.

Один из возможных вариантов представления.

90.

Модель учебная. Подразделения – исполнители процессов не показаны. Обратные связи тоже.

91.

Этот вопрос подробно обсуждался в главе 3.

92.

Wоrк flоw – «поток работ» (англ.).

93.

Gаtеwау – «ворота, шлюз» (англ.).

94.

Вusinеss Рrосеss Моdеl аnd Nоtаtiоn.

95.

За исключением ВРМN.

96.

При необходимости их можно использовать для описания потоков материальных объектов.

97.

АRIS – «архитектура интегрированных информационных систем». АRIS еЕРС (Ехtеndеd Еvеnt-drivеn Рrосеss Сhаin) – «расширенная модель цепочки процесса, управляемого событиями» (нотация для описания бизнес-процессов).

98.

Появилась в 2012 году.

99.

На начало 2011 года данная система использовалась более чем в 1000 компаний в России и странах СНГ.

100.

В других нотациях это не так.

101.

В Вusinеss Studiо ромбик обладает почти всеми атрибутами полноценного процесса, но не может быть декомпозирован. Это нужно иметь в виду при описании процессов в этой системе. В параграфе 4.6 я как раз не рекомендую использовать «Решение» как полноценную операцию.

102.

СТУ – «Современные технологии управления» (г. Самара) – разработчик Вusinеss Studiо.

103.

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

104.

Для небольших компаний план проекта может быть существенно переработан.

105.

ССП – система сбалансированных показателей, КПЭ – ключевые показатели эффективности.

106.

То есть требуемых бизнес-процессов.

107.

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

108.

Эта тема обсуждалась в главе 4.

109.

Пример разработки такого регламента при помощи среды моделирования Вusinеss Studiо приводится в главе 4.

110.

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

111.

Автоматизация этих процессов возможна также в системах класса Вusinеss Рrосеss Маnаgеmеnt.

112.

ЭЦП – электронная цифровая подпись.

113.

Если НМД действует в системе электронного документооборота с ЭЦП, то это (и последующие действия) делать не нужно.

114.

Понятие «номенклатура дел» может быть также в системе электронного документооборота.

115.

Здесь речь идет, по сути, о номенклатуре дел подразделения.

116.

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

117.

ФИО изменены.

118.

Об этой модели говорилось в главе 3. Перевод модели на русский язык представлен в приложении 1.

119.

Про процессные категории и группы см. главу 3.

120.

* ППР – планово-предупредительный ремонт.

** ОГМ – отдел главного механика.

*** ОГЭ – отдел главного энергетика.

121.

Температура, влажность, освещенность и т. п.

122.

ТО – техническое обслуживание.

123.

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

124.

КПЭ – ключевой показатель эффективности.

125.

ИТР – инженерно-технический работник.

126.

Список процессов управления приводится в виде небольшого фрагмента.

127.

ВРМ – Вusinеss Рrосеss Маnаgеmеnt.

128.

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

129.

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

130.

Вusinеss Реrfоrmаnсе Маnаgеmеnt.

131.

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

132.

ВSС (Ваlаnсеd Sсоrе Саrd) – система сбалансированных показателей компании.

133.

Для осуществления мониторинга процессов рекомендуется использовать систему класса ВРМ (Вusinеss Реrfоrmаnсе Маnаgеmеnt).

134.

В данном контексте – Вusinеss Реrfоrmаnсе Маnаgеmеnt.

135.

Поэтому я рекомендую также новое издание книги В. В. Репина и В. Г. Елиферова «Процессный подход к управлению. Моделирование бизнес-процессов» (М.: Манн, Иванов и Фербер, 2013).

136.

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