В данной статье я попытаюсь в доступной форме рассказать, что такое система управления бизнес-процессами (далее СУБП), как она работает, когда не работает, чем отличается от простого набора регламентов-инструкций. Кому-то, возможно, такое описание может показаться излишне упрощенным и не академическим, что ж, сделаем вид, что так и было задумано. Так же обращаю внимание, что описанное ниже – не последовательность шагов по разработке и внедрению СУБП.
СУБП – это инструмент управления предприятием, основанный на процессном подходе и регламентации бизнес-процессов, включающий кроме описательной части методы и инструменты управления и непрерывного совершенствования. Есть другое определение, СУБП – как специальное программное обеспечение. Но мы будем далее рассматривать СУБП именно в разрезе инструмента управления.
Итак, с самого начала. Вы описываете структуру процессов предприятия. Вопрос, как именно это делать, выходит за объемы данной статьи. Я пока предлагаю посмотреть на этот бизнес-инструмент крупным планом.
Структура бизнес-процессов – это модель бизнес-процессов компании, которая отражает связи между процессами и подразделениями (в том числе и через входы/выходы) и иерархию процессов.
Важный момент: описывается деятельность компании, а не ее структура. Да, иногда они могут совпадать, но чаще они все-таки отличаются, так как большинство основных бизнес-процессов цепочки создания ценности являются сквозными, т.е. проходят через несколько подразделений компании.
Бизнес-процесс – это периодически повторяемая, управляемая деятельность, результатом которой является некоторый ресурс, имеющий ценность для конкретного потребителя (клиента). Клиент может быть как внутренний, так и внешний.
Хотя, кажется, что описать структуру процессов компании довольно просто, вы ведь видите это процессы каждый день, вы в них живете, но, когда вы начнете проводить границы процессов, определять типы процессов и т.д., вы поймете, что не все так просто и однозначно. Не стоит пытаться с первого раза описать структуру процессов раз и навсегда. По мере описания регламентов, развития проектов, автоматизации процессов вы будете еще неоднократно, и возможно и кардинально, пересматривать структуру процессов.
Для описания структуры процессов компании я рекомендую использовать два инструмента: графический, который позволяет визуально представить процессы в их иерархической последовательности, и табличный, в виде матрицы процессов, где не только перечисляются процессы, но также указываются их владельцы и исполнители, основные входы и выходы, клиенты и поставщики процессов, со временем можно добавить и показатели процессов.
Для отображения в графическом виде можно воспользоваться как специальными программами и нотациями (ERWin, Buisness Studio – в нотации IDEF0), так и произвольной нотацией блок-схем, в подходящем графической или организационной программе (MS Visio, MindManager).
Перед тем как приступать к разработке регламентов процессов, полностью описывать структуру процессов не обязательно, но все-таки желательно, чтобы более обоснованно сделать выбор первых процессов для регламентирования, а также держать в голове общую картину связей процессов между собой. В крайней случае, можно не делать декомпозиции некоторых ветвей процессов, т.е. не детализировать нижележащую структуру. Например, обозначить ветку «Вспомогательных процессов» без уточнения ее содержания, начать описывать основные процессы цепочки создания ценности, а затем, по мере формирования видения, развернуть и ветвь вспомогательных процессов.
Затем описываются бизнес-процессы компании – разрабатывается регламенты. Регламент – это не просто описание последовательности действий (кстати, она может быть представлена в графическом, табличном и текстовом виде для удобства восприятия различными людьми), регламент также определяет:
- роли исполнителей и зоны ответственности на различных этапах выполнения процесса;
- определяет входы и выходы процесса, не просто перечисляет, а устанавливает стандарты и требования к ним: кто, как, кому, когда, в какой форме, по каким каналам и т.д.;
- показатели процесса, включая методики измерения и контроля, единицы измерения, порядок определения плановых значений и допустимых границ отклонения и т.д.;
- порядок управления процессом и порядок внесения изменений в регламент.
После описания регламента начинается стадия его запуска и внедрения. Происходить это может по следующей схеме:
Описание схемы запуска регламента процесса:
- Разрабатывать регламент – собственно подпроцесс разработки регламента, в котором происходит сбор, анализ, обработка данных о процессе и оформление их в соответствии с шаблоном в регламент управления БП.
- Проводить подготовку к запуску БП – подпроцесс, в рамках которого происходит разработка и установка необходимого программного обеспечения, закупка и запуск дополнительного оборудования, а также разработка учебных материалов и проведение обучения персонала.
- Тестировать выполнение БП – подпроцесс, в рамках которого регламент БП выполняют в рабочем режиме. Устанавливается срок проведения теста. В ходе теста ответственный специалист проводит ежедневные опросы и мониторинг, после чего, при необходимости, вносит корректирующие управленческие решения (по согласованию с владельцем процесса).
- Испытывать БП – подпроцесс, в рамках которого разрабатывается сценарий для испытания работы регламента БП в различных штатных и нештатных режимах, а затем проводятся сами испытания согласно разработанного сценария.
- Проводить «Обкатку» БП – подпроцесс, в рамках которого происходит выполнение БП согласно регламента с чадящим режим дополнительного контроля со стороны ответственного специалиста, а также с предоставлением еженедельных отчетов о выполнении БП от владельца процесса. По факту успешного окончания данного этапа происходит запуск процесса в самостоятельном режиме и под управлением владельца процесса.
Примечания:
- По окончании каждого этапа переходим в зависимости от результата либо к следующему этапу, либо возвращаемся к любому предыдущему и повторяем путь снова.
- Т.к. каждый этап предусматривает в начале разработку плана и определение сроков его проведения, то, если к нему повторно переходят после проведения изменений и доработок, можно регулировать длительность и полноту проведения повторных этапов.
- В качестве ответственного специалиста может выступать руководитель службы процессного управления, директор по развитию, внешний специалист, один из топ-менеджеров компании и т.д.
Очевидно, что описать сразу все процессы – не реально. Да и ни к чему. Выберете один-два процесса для стартовой площадки. Критерии для выбора процесса для первоначального описания (оценивайте по всем или по нескольким критериям, в зависимости от ситуации):
- важность процесса для деятельности компании;
- наличие в процессе «больных» мест;
- относительная простота описания для откатки процедуры и получения опыта;
- наличие заинтересованной группы сторонников и исполнителей во главе с инициативным владельцем процесса;
- показательность процесса для компания, т.е. увеличение его эффективности будет заметно для всей компании – это поможет в вопросе мотивации персонала при описании остальных бизнес-процессов.
Еще один важный момент – это реинжиниринг и/или реорганизация бизнес-процессов. При описании структуры бизнес-процессов и разработке регламентов возможны три варианта относительно изменения бизнес-процессов:
| Вариант | Плюсы | Минусы |
|
|
|
|
|
|
|
|
|
Выбор того или иного варианта зависит от особенностей компании, ее масштаба, этапа ее жизненного и цикла и т.д. Моя практика показала, что чаще всего наши компании выбирают второй вариант, но конечно возможны и другие варианты развития событий.
Продолжение здесь