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

Что такое СУБП и зачем она нужна вашей компании?

Начнем с определения:

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

СУБП – это часть системы управления компанией, как например система управления финансами или система управления персоналом. Наличие СУБП означает, что в организации ведется практическая работа с процессами: оперативное управление, анализ, улучшение, стандартизация и автоматизация.

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

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

В данной серии статей я предлагаю вашему вниманию подробный план внедрения СУБП «C нуля». Этот план вы можете адаптировать с учетом особенностей и конкретной ситуации в вашей организации.

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

План внедрения СУБП

План внедрения СУБП включает следующие этапы:

1. Подготовка к выполнению проекта.
2. Разработка документа «Концепция внедрения СУБП в компании».
3. Разработка Методологии и регламентация процессов СУБП.
4. Разработка Архитектуры бизнес-процессов.
5. Внедрение программного обеспечения СУБП.
6. Разработка системы развития компетенций по процессному управлению.
7. Разработка системы вовлечения персонала в деятельность по улучшению процессов.
8. Выполнение «пилотного» проекта по оптимизации сквозного процесса компании.

На рис. 1 показан ориентировочный график выполнения проекта внедрения СУБП.

Срок внедрения СУБП, то есть построения Системы работы с процессами около 6 месяцев. При желании, можно быстрее. Но есть определенные ограничения, связанные, в первую очередь, с недостатком ресурса времени руководителей и их мотивации выполнить проект. Крайне нежелательно растягивать проект на 1,5-2 года. За это время многие решения потеряют актуальность, результаты обучения будут забыты, регламенты устареют. То есть систему нужно строить достаточно быстро.

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

1. Подготовка к выполнению проекта

Подготовка к выполнению проекта включает следующие группы работ.

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

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

1.3.Поиск и подбор Руководителя Процессного офиса, Главного методолога и бизнес-аналитиков.
В рамках подготовки к проекту необходимо выбрать из своих сотрудников или привлечь со стороны специалистов, от которых во многом зависит успех внедрения СУБП. Необходимо подобрать Руководителя Процессного офиса, Главного методолога и одного-двух бизнес-аналитиков (на первое время).

Для подбора можно использовать проф. стандарт «Специалист по процессному управлению» и соответствующий тест, доступный на сайте ассоциации ABPMP Russian Chapter. Так же можно обратиться к лучшим экспертам в области процессного управления за помощью в подборе и тестировании кандидатов.

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

1.4. Назначение куратора проекта внедрения СУБП по стороны Руководства компании.
Одновременно с п. 1.3. выполняется выбор и назначение куратора проекта со стороны топ-менеджмента компании. Это может быть первый заместитель директора, директор, руководитель крупного департамента, представитель собственника.

1.5. Выполнение бенчмаркинга.
Куратор с сотрудниками Процессного офиса и ключевыми руководителями могут совершить 2-3 бенчмаркинговых поездки для ознакомления с опытом внедрения СУБП и практикой работы с бизнес-процессами в передовых компаниях. Если таких средств нет, то необходимо, как минимум, ознакомиться с опытом других компаний, доступным из открытых источников: сайта www.bpmaward.ru, www.finexpert.ru, www.tadviser.ru и др. Так же можно посетить специализированные конференции для обмена опытом с коллегами.

1.6. Разработка Плана проекта внедрения СУБП.
Процессный офис разрабатывает План внедрения СУБП. Если в компании развита культура проектного управления, то по всем правилам может быть создан Устав проекта.

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

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

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

2. Разработка документа «Концепция внедрения СУБП в компании»

2.1. Формирование Глоссария.
Система терминов в области процессного управления является важнейшим элементом СУБП. Процессный офис разрабатывает Глоссарий, используя общепринятые отраслевые практики, книги специалистов по BPM, доступные системы терминов, рекомендации BPM CBOK, опыт экспертов. Крайне нежелательно использовать сложные, запутанные термины.

По ходу проекта Глоссарий будет дополняться терминами с учетом используемых решений в области автоматизации СУБП.
Глоссарий должен быть доступен всем сотрудникам компании на внутреннем корпоративном web-портале.

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

Руководитель проекта организует согласование видения, целей и принципов СУБП с руководством компании.

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

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

2.4. Определение структуры процессов для управления ЖЦ бизнес-процесса.
Процессный офис прорабатывает структуру процессов СУБП, которые необходимо спроектировать и внедрить для управления всеми значимыми бизнес-процессами в рамках их жизненного цикла.
Жизненный цикл любого процесса (см. рис 2) включает целеполагание, планирование и проектирование, внедрение изменений, выполнение процесса и оперативное управление, анализ.

Например, необходимо включить в структуру процессов СУБП «Процесс описания процессов». Это необходимо для четкой организации работы по проектированию бизнес-процессов с высоким качеством. Если пустить работу на самотек, то будут получены результаты весьма низкого качества, которые нельзя использовать. Данный процесс СУБП будет использоваться в рамках этапа ЖЦ «Проектирование процесса и планирование изменений».

Другой пример – «Разработка Технического задания на автоматизацию процесса» — то есть соответствующий бизнес-процесс и т.п.

В идеальной ситуации должны быть разработана общая модель процессов СУБП. Такая модель наглядно показывает взаимодействие процессов СУБП между собой и с другими процессами организации.

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

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

2.5. Определение методологии СУБП
Многие процессы СУБП должны базироваться на четко определенных методиках, в том числе:

1. Методика проектирования процессов.
2. Методика анализа процессов.
3. Методика автоматизации процессов.
4. Методика внедрения изменений.
5. Методика разработки целей и показателей для управления процессами.
6. Методика оперативного управления процессами.
7. Методика оценки уровня зрелости СУБП и проч.

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

2.6. Определение участников СУБП.
Процессный офис проектирует структуру будущей СУБП в части субъектов. Определяются органы управления и участники СУБП: Процессный комитет, Процессный офис, Процессный Методолог, владельцы процессов, менеджеры процессов, участники временных рабочих групп по проектированию процессов и проч. С учетом определенных процессов СУБП определяются функции, полномочия и ответственность субъектов СУБП. Готовый раздел включается в проект «Концепции».

2.7. Определение архитектуры информационных систем СУБП
В рамках «Концепции» целесообразно описать архитектуру информационных систем, которые будут использоваться в СУБП (см. рис. 3): состав, назначение и основные информационные потоки между ними. Для управления бизнес-процессами в рамках СУБП используются:

1. Среда проектирования и анализа процессов (например, Business Studio, ARIS и др.)
2. Система автоматизации процессов – BPMS (например, Bizagi, Elma и др.).
3. Внутренний web-портал.
4. BI-система.

Возможны различные комбинации систем. Например, модуль BI может быть реализован в рамках единого web-портала компании. Другой пример – использование среды проектирования и портала BPMS без отдельного программного обеспечения для проектирования процессов (Business Studio, ARIS).

Выбор архитектуры информационных систем СУБП определяется многими факторами:
• ИТ-стратегией компании;
• функциональными возможностями уже используемых в компании систем, в т.ч. web-портала;
• наличием средств для приобретения и внедрения ИТ-систем;
• ограничениями в области безопасности и проч.

Тем не менее, в «Концепции» принципиально важно сформулировать, что будут использоваться: обязательно web-портал для управления ЖЦ бизнес-процессов (формируется на основе архитектуры процессов компании), средство проектирования и автоматизации процессов, средство для автоматического формирования регламентирующих документов на основе схем процессов, средство для оперативного управления процессами (может использоваться web-портал компании или доработанный портал BPMS).

2.8. Определение системы оценки зрелости и этапов развития СУБП компании.
В рамках «Концепции» желательно указать, что компания будет регулярно проводить оценку зрелости СУБП по соответствующим разделам.
Целесообразно показать перспективу развития СУБП на как, например, показано на рис. 4.

2.9. Презентация и утверждение Концепции внедрения СУБП.
После того, как проект «Концепции внедрения СУБП в компании» подготовлен, Процессный офис организует презентацию документа для руководства компании. Проводится обсуждение «Концепции» на совещаниях с руководством компании. «Концепция» утверждается и доводится до персонала.

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

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», Советник Директора АО «СО-ЕЭС», руководитель отдела Анализа и методологического обеспечения ПО № 8 ГБУ «Аналитический центр» Департамента экономической политики и развития города Москвы.

Июль 2020 г.

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

Введение

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

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

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

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

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

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

Процесс, как объект управления

На рисунке 1 схематично представлен процесс, как объект управления.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица. Критерии оценки уровня развития процессного управления

Заключение

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

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

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

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

В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»

Ноябрь 2018 г.

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

Введение

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

Контролируете ли Вы исполнение требований вашими подчиненными?

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

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

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

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

Классификация методов оперативного контроля исполнения требований регламентов

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

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

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

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

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

Информация для оперативного контроля исполнения технологии процесса

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

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

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

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

Таблица 1. Информация для контроля исполнения требований технологии выполнения процесса

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

Оперативный контроль при помощи системы Business Studio

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

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

Выводы

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

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

В.В. Репин, к.т.н., доцент, тренер, консультант по управлению.

Сентябрь 2016 г.

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

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

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

5.1….
5.2. Приемка ткани
5.2.1. Разгрузка а/м.
5.2.2. Визуальный контроль и проверка ткани по количеству.
5.2.3. Формирование и подписание акта приемки ткани.
5.2.4. Печать этикеток со штрих кодами.
5.2.5. Приклеивание этикеток (для ткани от поставщиков).
5.2.6. Сканирование этикеток.
5.2.7. Сверка и перемещение в 1С на склад приемки.
5.3. Приемка возврата
5.3.1. Получение информации о возврате.
5.3.2. Доставка возврата со склада клиента (в Москве) или из ТК.
5.3.3. Доставка возврата клиентом (самостоятельно).
5.3.4. Разгрузка а/м.
5.3.5. Проверка правильности оформления документов и наличия ткани.
5.3.6. Перемещение возврата и документов в зону ОТК .
5.4….

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

Теперь давайте обсудим форму этого регламента. Рекомендую использовать следующие разделы.

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

Титульный лист

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

Паспорт регламента

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

Содержание

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

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

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

Общее описание процесса

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

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

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

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

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

Графическая схема процесса

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

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

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

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

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

Действия в случае отклонений

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

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

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

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

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

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

Ресурсы, необходимые для выполнения процесса

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

Контрольные процедуры (методы контроля)

Методы контроля или, другими словами, контрольные процедуры целесообразно продумать на стадии разработки регламента. Для чего они нужны? Это инструмент оперативного (час, день, неделя) контроля со стороны непосредственного руководителя.
В каждом процессе есть места, где у исполнителя есть:

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

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

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

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

Цели и показатели

Формулировка целей процесса является тяжким трудом для многих руководителей. Гораздо проще просто написать, например, что задачей процесса является получение маркетинговой информации или обслуживание оборудования. Но это «ни о чём». Нужно учиться формулировать четкие цели, причем увязанные с общей системой целей организации.
Я считаю раздел «Цели и показатели» обязательным для регламента. Процессом нужно управлять, а без показателей это невозможно делать целенаправленно. Нецеленаправленная деятельность – это хаос, имитация управленческой деятельности. Поэтому цели и показатели нужно включать в регламент обязательно.

Приложения

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

«Редкие звери» или нечасто используемые разделы регламента

Кратко хочу сказать про разделы, которые встречаются в регламенте процесса редко. Например, это раздел «Ответственность исполнителей». Его оформляют в виде таблицы. Как правило, везде одна и та же фраза – «Несет ответственность в соответствии с УК РФ…» или «Устное/письменное замечание руководителя/ Дисциплинарное взыскание». Если вам нечего написать в таком разделе, кроме одной и той же общей фразы, то лучше вообще убрать раздел из регламента.
Кроме «Ответственности исполнителей» в регламенте могут показывать информацию по проведенным аудитам. Это удобно для электронной версии, но неудобно для бумажной.
Иногда в регламентах можно увидеть такие разделы, как «Документирование и архивирование» или «Порядок внесения изменений». Но в них чаще всего пишут общие фразы типа: «Порядок документирования и архивирования в рамках настоящего регламента определен внутренними нормативными документами компании «» и « Настоящий Регламент пересматривается на соответствие в установленные в компании «_» сроки. Порядок пересмотра настоящего регламента определен внутренними нормативными документами компании «___». Зачем включать такие пустые, формальные фразы в регламент?! Не понимаю…

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

Резюме

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

В.В. Репин,
к.т.н., доцент, тренер, консультант.

Июль 2015 г.