В статье Владимира Репина рассматриваются проблемы создания регламентов, а именно: учет нагрузки на процесс, анализ производительности, синхронизация операций, приоретизация работ и тактовая частота. Учет данных факторов позволяет создавать эффективно работающие процессы и использовать соответствующие регламенты.
В данной статье я хочу затронуть вопросы, которые вроде бы очевидны. Они лежат на поверхности. Но когда сотрудники занимаются регламентаций процессов,
Представим себе распространенную ситуацию — по заданию руководства нужно разработать регламент некоторого процесса. В лучшем случае, исполнители сначала выполняют описание данного процесса при помощи графической схемы. В идеале, процесс входит в архитектуру процессов компании. Тогда для него легче определить контекст — входы и выходы, инициирующие и завершающие события. Если модель процессов компании не создана, определить границы процесса будет сложнее. Но это возможно.
Итак, разработана и согласована графическая модель — алгоритм выполнения процесса исполнителями. Предположим, что качество модели высокое,
Далее на основе этой графической схемы формируется регламент.
Регламент готов. Он проходит ряд согласований, доработок и, наконец, утверждается руководителем…
После внедрения выясняется, что:
Видя такую ситуацию, руководители закрывают на это глаза (прячут голову в песок).
Почему реальный процесс не работает в соответствии с требованиями регламента? Для ответа на этот вопрос, нужно определиться с тем, какие именно требования регламента должны быть выполнены. Давайте обсудим следующие требования:
Допустим, для нас критически важно, чтобы процесс выполнялся в полном соответствии с установленным алгоритмом. Затем мы и рисовали графическую схему.
Важно ли для нас соблюдение нормативного времени выполнения? Да, конечно. Но вот тут мы должны вспомнить, что процесс — это не сферический конь в вакууме (абстрактный алгоритм работы). Он должен быть интегрирован в систему процессов компании. Достаточно ли просто увязать процессы по входам и выходам для обеспечения такой интеграции? Нет, не достаточно! Процессы выполняются в разное время. Они должны быть синхронизированы между собой. Это влияет на возможность выполнения процесса в отведенное нормативное время. Что еще?
Проектируя графическую схему, мы забыли о следующих ключевых характеристиках реально выполняемого процесса:
Что такое нагрузка на процесс? Это количество событий, инициирующих выполнение процесса (запуск экземпляров процесса) в единицу времени. Например, количество заявок на выставление счетов
Расчетная производительность процесса — возможность процесса пропускать через себя ресурсы для получения заданного количества результатов в единицу времени. Производительность процесса определяется как алгоритмом (логикой), так и наличием необходимых ресурсов: человеческого ресурса (исполнители), оборудования (техническая исправность), расходных материалов (упаковка
Расчетная производительность процесса может не соответствовать фактической нагрузке на процесс. Например, у нас есть ограничения по количеству сотрудников, которые могут заниматься обработкой заявок одновременно. Или узким местом является
Допустим, нагрузка на процесс не соответствует его расчетной производительности. При этом будем считать, что исполнители процесса сильно замотивированы на получение результата. Какие возможны ситуации? Первая — алгоритм процесса не будет выполняться. Сотрудники будут нарушать требования (пропускать нужные операции, выполнять их не по технологии
Замечу, что такую ситуацию порождают сами менеджеры, проектируя неэффективные процессы, перегружая людей и устанавливая жесткую мотивацию от результата. Естественно, возникают риски и потери. В крайних случаях они могут приводить к большим проблемам.
Вторая ситуация — процесс продолжает выполняться по установленному алгоритму. В этом случае,
Доступный ресурс исполнителей. Проблема в том, что исполнители (если только мы не рассматриваем примитивные ручные операции на конвейере) участвуют в нескольких процессах компании.
Когда мы проектируем конкретную графическую схему, то подразумеваем, что исполнители будут выполнять только этот процесс. Но это предположение некорректно. Сотрудники будут участвовать так же в других процессах, тем самым лишая рассматриваемый процесс ресурса, снижая его производительность и создавая очередь на входе.
Еще хуже то, что исполнители будут сами расставлять приоритеты — какую операцию какого процесса им выполнять сейчас, а какую — потом. Хаоса добавит оперативное вмешательство руководителя — разовые задачи с максимальным приоритетом, которые останавливают выполняемые по регламенту процессы на неопределенное время.
В результате нормативное время выполнения процесса (который выполняют исполнители, задействованные в других процессах), как правило, оказывается рассчитанным неадекватно. Это нормативное время никогда не будет достигнуто! Как быть?
Заняться синхронизацией, определением тактовой частоты и приоретизаций процессов, причем с использованием принципов ТОС или TPS (система Тойоты).
Синхронизация процессов — когда, какие именно процессы запускаются и как влияют друг на друга.
Тактовая частота — периодичность, с которой исполнители будут переключаться с процесса на процесс. Например, раз в 2 часа я трачу 30 минут на выполнение Процесса, А, 45 минут — на выполнение Процесса Б, 30 минут — на выполнение Процесса С, 15 минут — на разовые поручения руководителя.
Приоретизация. Сотрудник должен знать и понимать, с какого процесса нужно начинать работу в первую очередь. Руководители должны определить и установить приоритеты выполнения. Например, с 9–00 до 11–00 исполнитель должен заниматься только этим процессом, потом с определенной тактовой частотой переключаться между процессами
Как это сложно, наверное, подумал уже читатель. Да сложно! Но кто говорил, что создание эффективной системы управления — это легко?
Всё не так уж и страшно. Есть процессы, общие для всей компании. Их можно условно назвать процедурами (не путать с нотаций «Процедура» в Business Studio). Например, процедура заключается в том, что нужно искренне улыбнуться и вежливо поздороваться с клиентом (большинство сотрудников, работающих с клиентами недопустимо угрюмы и неприветливы). Можно написать общий алгоритм процесса и зафиксировать его в регламенте. Нужно ли определять нагрузку, производительность и ресурсы для такой процедуры? Теоретически, если все будут улыбаться и здороваться определенное время, то времени на выполнение других процессов останется меньше
Другое дело, когда мы занимаемся разработкой и оптимизацией реального процесса. Такой процесс выполняется в конкретных подразделениях конкретными исполнителями. Для него весьма актуальными будут расчеты нагрузки, производительности, ресурсов, синхронизация, тактовая частота, стоимость результата и проч.
В следующей таблице я показал, какие аспекты нужно учитывать при инжиниринге процесса и процедуры.
№ | Характеристика для анализа и описания | Регламентация общей процедуры | Регламентация реального процесса |
---|---|---|---|
1 | Графическая схема | + | + |
2 | Нормативное время выполнения операций и процесса в целом | + | + |
3 | Нагрузка на процесс | - | + |
4 | Производительность процесса | - | + |
5 | Требования к ресурсам (персонал, оборудование, расходные материалы, |
- | + |
6 | Приоритеты и тактовая частота | - | + |
7 | Синхронизация с другими процессами | - | + |
Итак, регламент не равен реальному процессу. Процессное управление — не разработка формальных регламентов. Что нужно делать при проектировании процесса? Можно предложить следующие шаги для обсуждения:
Опубликовано по материалам:
http://finexpert.ru/view/reglament_ili_protsess/905
Апрель 2016 г.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
* Поля, обязательные для заполнения.
Введите поисковый запрос: