Введение: проблема страуса
В данной статье я хочу затронуть вопросы, которые вроде бы очевидны. Они лежат на поверхности. Но когда сотрудники занимаются регламентаций процессов, почему-то про них совершенно забывают. Последствия – неработающие регламенты и, что хуже, разочарование в методах процессного управления в целом.
Представим себе распространенную ситуацию – по заданию руководства нужно разработать регламент некоторого процесса. В лучшем случае, исполнители сначала выполняют описание данного процесса при помощи графической схемы. В идеале, процесс входит в архитектуру процессов компании. Тогда для него легче определить контекст – входы и выходы, инициирующие и завершающие события. Если модель процессов компании не создана, определить границы процесса будет сложнее. Но это возможно.
Итак, разработана и согласована графическая модель – алгоритм выполнения процесса исполнителями. Предположим, что качество модели высокое, т.е. она отражает нюансы реально выполняемого процесса со степенью подробности, достаточной понимания и исполнения компетентными сотрудниками.
Далее на основе этой графической схемы формируется регламент. Кто-то выгружает проект регламента автоматически (например, при использовании Business Studio). Кто-то создает регламент «ручной сборки», копи-пастом помещая схемы из MS Visio в файл MS Word и добавляя текстовое описание операций процесса.
Регламент готов. Он проходит ряд согласований, доработок и, наконец, утверждается руководителем…
После внедрения выясняется, что:
• алгоритм выполнения процесса постоянно нарушается;
• нормативное время выполнения процесса и фактическое время его выполнения отличаются в десяти раз.
Видя такую ситуацию, руководители закрывают на это глаза (прячут голову в песок).
Проблемы процесса
Почему реальный процесс не работает в соответствии с требованиями регламента? Для ответа на этот вопрос, нужно определиться с тем, какие именно требования регламента должны быть выполнены. Давайте обсудим следующие требования:
• алгоритм процесса;
• нормативное время выполнения отдельных операций и процесса в целом.
Допустим, для нас критически важно, чтобы процесс выполнялся в полном соответствии с установленным алгоритмом. Затем мы и рисовали графическую схему.
Важно ли для нас соблюдение нормативного времени выполнения? Да, конечно. Но вот тут мы должны вспомнить, что процесс – это не сферический конь в вакууме (абстрактный алгоритм работы). Он должен быть интегрирован в систему процессов компании. Достаточно ли просто увязать процессы по входам и выходам для обеспечения такой интеграции? Нет, не достаточно! Процессы выполняются в разное время. Они должны быть синхронизированы между собой. Это влияет на возможность выполнения процесса в отведенное нормативное время. Что еще?
Проектируя графическую схему, мы забыли о следующих ключевых характеристиках реально выполняемого процесса:
• нагрузка на процесс;
• производительность процесса;
• доступный ресурс исполнителей (оборудования и проч.);
• стоимость результатов процесса.
Что такое нагрузка на процесс? Это количество событий, инициирующих выполнение процесса (запуск экземпляров процесса) в единицу времени. Например, количество заявок на выставление счетов и т.п. Замечу, что нагрузка на процесс может быть неравномерной. Например, в среднем, в день поступает 100 заявок, но пик приходится на вторую половину дня.
Расчетная производительность процесса – возможность процесса пропускать через себя ресурсы для получения заданного количества результатов в единицу времени. Производительность процесса определяется как алгоритмом (логикой), так и наличием необходимых ресурсов: человеческого ресурса (исполнители), оборудования (техническая исправность), расходных материалов (упаковка и т.п.), ИТ-систем (работающая система учета).
Расчетная производительность процесса может не соответствовать фактической нагрузке на процесс. Например, у нас есть ограничения по количеству сотрудников, которые могут заниматься обработкой заявок одновременно. Или узким местом является какой-то агрегат.
Допустим, нагрузка на процесс не соответствует его расчетной производительности. При этом будем считать, что исполнители процесса сильно замотивированы на получение результата. Какие возможны ситуации? Первая – алгоритм процесса не будет выполняться. Сотрудники будут нарушать требования (пропускать нужные операции, выполнять их не по технологии и т.п.), но при этом успеют обработать все заявки.
Замечу, что такую ситуацию порождают сами менеджеры, проектируя неэффективные процессы, перегружая людей и устанавливая жесткую мотивацию от результата. Естественно, возникают риски и потери. В крайних случаях они могут приводить к большим проблемам.
Вторая ситуация – процесс продолжает выполняться по установленному алгоритму. В этом случае, из-за несоответствия нагрузки и производительности возникнет очередь на входе. Если длинна очереди станет критичной для клиентов, то они могут поискать других поставщиков. Если клиенты внутренние, то им придется ждать. Но это повлияет на эффективность компании в целом.
Проблемы системы
Доступный ресурс исполнителей. Проблема в том, что исполнители (если только мы не рассматриваем примитивные ручные операции на конвейере) участвуют в нескольких процессах компании.
Когда мы проектируем конкретную графическую схему, то подразумеваем,
что исполнители будут выполнять только этот процесс. Но
это предположение некорректно. Сотрудники будут участвовать так же в других процессах, тем самым лишая рассматриваемый процесс ресурса, снижая его производительность и создавая очередь на входе.
Еще хуже то, что исполнители будут сами расставлять приоритеты - какую операцию какого процесса им выполнять сейчас, а какую – потом. Хаоса добавит оперативное вмешательство руководителя – разовые задачи с максимальным приоритетом, которые останавливают выполняемые по регламенту процессы на неопределенное время.
В результате нормативное время выполнения процесса (который выполняют исполнители, задействованные в других процессах), как правило, оказывается рассчитанным неадекватно. Это нормативное время никогда не будет достигнуто! Как быть?
Заняться синхронизацией, определением тактовой частоты и приоретизаций процессов, причем с использованием принципов ТОС или TPS (система Тойоты).
Синхронизация процессов – когда, какие именно процессы запускаются и как влияют друг на друга.
Тактовая частота – периодичность, с которой исполнители будут переключаться с процесса на процесс. Например, раз в 2 часа я трачу 30 минут на выполнение Процесса А, 45 минут - на выполнение Процесса Б, 30 минут – на выполнение Процесса С, 15 минут – на разовые поручения руководителя.
Приоретизация. Сотрудник должен знать и понимать, с какого процесса нужно начинать работу в первую очередь. Руководители должны определить и установить приоритеты выполнения. Например, с 9-00 до 11-00 исполнитель должен заниматься только этим процессом, потом с определенной тактовой частотой переключаться между процессами и т.п.
Как это сложно, наверное, подумал уже читатель. Да сложно! Но кто говорил, что создание эффективной системы управления - это легко?
Процесс и процедура
Всё не так уж и страшно. Есть процессы, общие для всей компании. Их можно условно назвать процедурами (не путать с нотаций «Процедура» в Business Studio). Например, процедура заключается в том, что нужно искренне улыбнуться и вежливо поздороваться с клиентом (большинство сотрудников, работающих с клиентами недопустимо угрюмы и неприветливы). Можно написать общий алгоритм процесса и зафиксировать его в регламенте. Нужно ли определять нагрузку, производительность и ресурсы для такой процедуры? Теоретически, если все будут улыбаться и здороваться определенное время, то времени на выполнение других процессов останется меньше и т.п. Но такие расчеты в масштабах всей компании в настоящее время невозможны или бессмысленны (слишком сложная система с нелинейными связами).
Другое дело, когда мы занимаемся разработкой и оптимизацией реального процесса. Такой процесс выполняется в конкретных подразделениях конкретными исполнителями. Для него весьма актуальными будут расчеты нагрузки, производительности, ресурсов, синхронизация, тактовая частота, стоимость результата и проч.
В следующей таблице я показал, какие аспекты нужно учитывать при инжиниринге процесса и процедуры.
Таблица.
Выводы
Итак, регламент не равен реальному процессу. Процессное управление – не разработка формальных регламентов. Что нужно делать при проектировании процесса? Можно предложить следующие шаги для обсуждения:
1. Понять, что мы описываем: процесс или процедуру? Если процесс, то:
2. Описать процесс «как есть» (графическая схема).
3. Определить целевую нагрузку на процесс и его фактическую производительность, выявить узкие места и ограничения.
4. Выполнить анализ выполнения процесса:
4.1. понять, в каких еще процессах участвуют исполнители;
4.2. определить существующий порядок приоретизации работ и фактическую тактовую частоту;
5. Определить целевые приоритеты выполнения и тактовую частоту процесса;
6. Синхронизовать процесс с другими процессами в системе;
7. Изменить алгоритм процесса (модель «как должно быть»), обеспечить необходимыми ресурсами с учетом синхронизации, приоритетов и тактовой частоты.
Шаги 5-7 придется выполнять итерационно.
8. Провести валидацию процесса (т.е. проверить, что процесс в реальной ситуации выдает нужные нам характеристики).
9. Разработать и внедрить регламент процесса.
В.В. Репин,
к.т.н., доцент, тренер, консультант по управлению.
Апрель 2016 г.
