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

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

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

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

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

Второй вопрос: как определить, где бизнес-процесс начинается и где заканчивается? И это, наверное, самый сложный вопрос в процессной методологии!

Ответ зависит от целей и стратегии компании, от экспертизы аналитика, от договоренности внутри проектной команды. А еще — большое влияние оказывает то, какие KPI мы хотим измерить, когда внесем изменения в процесс.

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

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

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

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

А еще — создайте глоссарий со всеми терминами и аббревиатурами, которые планируете использовать. Это еще один важный шаг к тому, чтобы понимать друг друга в команде.

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

Заниматься моделированием процессов можно где угодно — хоть в Excel. Но намного удобнее делать это в понятных нотациях в профессиональном ПО. Это будет более наглядно, поможет учитывать людей, различные ИТ-системы, артефакты и взаимосвязи процесса. А еще — легче автоматизировать и анализировать процессы потом.

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

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

😊 А когда сотрудники чувствуют, что процесс стал проще и эффективнее, и они действительно довольны результатом, — для меня это, пожалуй, главный результат внедрения проекта по оптимизации процессов!

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

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

Рассматриваем максимально длинную логическую цепочку шагов. Прослеживаем процесс как можно дальше в его начале и в конце.

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

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

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

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