Построение бизнес процессов в компании пример. Вячеслав кондратьевпоказываем бизнес-процессы

Типовые структуры бизнес-процессов (Process Frameworks) разработаны Группой компаний «Современные технологии управления» в качестве методической основы для построения моделей бизнес-процессов реальных компаний. Типовые структуры представлены в формате PDF для ознакомления и в формате XML для использования в Business Studio (доступны для загрузки на странице Пакеты для самостоятельной загрузки).

Оказание услуг (PDF)

Проектная деятельность (PDF)

Производство (PDF)

Управляющая компания (PDF)

Уникальная возможность

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

Модели бизнес-процессов, созданные в системе Business Studio

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

Модели опубликованы в формате HTML-публикации , автоматически формируемой Business Studio. HTML-публикация содержит диаграммы бизнес-процессов предприятия, основные регламентные документы (Регламент процесса, Регламент процедуры, Положение о подразделении, Должностная инструкция) и управленческую информацию с возможностью перехода между документами по гиперссылкам.

Внимание!

Шаблоны документов, используемые в бизнес-моделях, являются демонстрационными. Формат, структуру и состав информации выходных документов Business Studio, формируемых при построении бизнес-моделей, можно настраивать под потребности конкретной компании.

Модель производственного предприятия

Характеристика предприятия

Основные направления деятельности:

• Производство и продажа алюминиевого профиля;
• Производство и продажа автокомпонентов.

Численность персонала: 1200 человек.

Описание модели

Модель является локализацией 8-ми процессной нормативной модели бизнес-процессов организации. Цели создания модели — подготовка к автоматизации бизнес-процессов (создание модели «как будет» с учетом применения будущей информационной системы), формирование технического задания на автоматизацию.

Модель включает:

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

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

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

Техническое задание на автоматизацию

Нормативная 8-процессная модель деятельности производственного предприятия

Модель разработана компанией «БКГ» и лично ведущим российским специалистом в области организационного развития компаний Т.Р. Кадыевым. Может применяться как основа для последующей локализации на конкретном предприятии.

Модель включает в себя:

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

Принцип построения бизнес-модели заключается в выделении основных объектов управления бизнес-системы и проектировании процессов управления этими объектами: (бизнес-процессы, стратегия развития).

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

Модель компании, осуществляющей деятельность по проектированию, монтажу и обслуживанию инженерно-технических систем.

Модель включает:

• Модель бизнес-процессов и процедур, включая цели и показатели процессов;
• Организационную структуру компании;
• Финансовую структуру компании;
• Бюджетную структуру компании;
• Раздел СМК, содержащий требования стандартов ИСО 9001:2000 и ИСО/ТУ 16949, Руководство по качеству ;
• Структуру информационной системы и Техническое задание на автоматизацию .

Данная модель содержится в демо-версии системы Business Studio.

Модель производственной деятельности в соответствии со стандартом ИСО 9001:2000

Рост конкуренции между западными и отечественными компаниями за право преобладания на Российском рынке товаров и услуг заставляет последних активнее использовать современные методы управления, в частности, построение системы менеджмента качества (СМК), соответствующей требованиям ИСО 9001:2000 г. Данный стандарт представляет собой набор требований к подсистеме управления качеством выпускаемой продукции или оказания услуг организации. Функционирующая СМК позволяет утверждать, что организация способна выпускать качественную продукцию (оказывать услуги) на регулярной основе, а значит, имеет большие преимущества перед конкурентами. Однако построение СМК дело непростое, зачастую требующее от организации внесения значительных изменений в ее производственно-хозяйственную деятельность, в бизнес-процессы предприятия. Для облегчения понимания требований самого стандарта ИСО 9001:2000 г., а также в качестве примера построения СМК предлагается модель деятельности организации, осуществляющей производство продукции. Модель включает в себе все стандартные процессы, начиная от проектирования и заканчивая сервисным обслуживанием продукции.

Для описания модели организации использовалась нотация функционального моделирования IDEF0. Процессы верхнего уровня модели соответствуют ключевым разделам стандарта ИСО 9001:2000 г., далее они декомпозируются на подпроцессы нижнего уровня уже непосредственно в привязке к производственно-хозяйственной деятельности организации. Таким образом, модель представляет собой совокупность бизнес-процессов организации с интегрированными в них требованиями ИСО 9001:2000 г. При этом существуют ограничения в интерпретации требований стандарта (переложении их на деятельность организации), связанные с тем, что за основу была принята достаточно условная организация, без какой-либо отраслевой специфики. В связи с этим, на практике, такую модель можно использовать как основу для анализа соответствия деятельности предприятия (по зонам ответственности — разделы стандарта) требованиям ИСО 9001:2000, а также как нормативную модель для разработки и внедрения СМК.

И, тем не менее, ум человеческий тщетно пытался постигнуть ее в течение более чем 2 000 лет, между тем как, с другой стороны, ему удался, но крайней мере приблизительно, анализ гораздо более содержательных и сложных форм. Почему так? Потому что развитое тело легче изучать, чем клеточку тела. К тому же при анализе экономических форм нельзя пользоваться ни микроскопом, ни химическими реактивами. То и другое должна заменить сила абстракции.

Карл Маркс. Капитал. Том 1. Предисловие к первому изданию.

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

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

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

Определение бизнес-процесса

Итак, в чем же разница между бизнес-процессом и функций или даже просто обычным процессом? В чем разница между этими терминами? Я пришел к следующему выводу:

Бизнес-процесс – это логическая последовательность действий человека (или нескольких человек) в коллективе. Цель описания бизнес-процесса – анализ и регламентация тех или иных действий в коллективе.

Почему я делаю особый упор на людях и коллективе:

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

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

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

Также важно дать определение описанию бизнес процесса:

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

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

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

Лично я сравниваю создание нового бизнес-процесса с балансированием на тонкой нити гармоничного сочетания творчества, искусства и строгой математики.

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

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

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

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

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

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

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

1. Берем заготовку A;
2. Соединяем ее с заготовкой B;
3. Обрабатываем под параметры C;
4. Получаем деталь.

Все однозначно и никаких условных «вилок» не предусматривается.

В бизнес-процессе вполне нормальной считается следующая ситуация:

1. Получаем вводные данные A:
   • Если данные соответствуют условию B, переходим на последовательность действий C;
   • Если данные соответствуют условию D, выполняем действия E.
2. Полученный результат передается на выход.

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

История появления термина

Я не единожды читал информацию о том, что нотации бизнес-процессов IDEF0 появилось чуть ли ни в середине XIX века. Более реалистичные авторы пишут о периоде Второй Мировой войны. Но и они ошибаются.

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

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

На самом деле описание бизнес-процессов и нотации BPMN появились в 70-е годы XX века, когда повсеместно начали использоваться информационные системы. И сам термин, и нотации понадобились изначально именно для разработки информационный систем.

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

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

Первые методологически проработанные нотации бизнес-процессов (а я буду говорить именно о методологически проработанных нотациях, например, IDEF3***) появились у военных в США. Причина очевидна – уже тогда военные в США пользовались автоматизацией с использованием удаленных соединений, т.е. той самой системой, которая позже стала Интернетом. И при таком уровне применения информационных систем потребность в нотациях бизнес-процессов была особенно актуальной.

***По теме методологически проработанных нотаций хочу также сказать пару слов. Почему я привел в качестве примера IDEF3: я еще не видел более проработанной методологически системы описания бизнес-процессов. Даже BPMN 2.0 все еще развивается и дорабатывается. А если вы почитаете англоязычное описание IDEF3 (перевода на русский я пока не видел), то также сумеете оценить по достоинству глубину его проработки.

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

С их помощью оказалось возможным оптимизировать бизнес, т.е. получить более высокую производительность при тех же затратах.

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

Именно тогда появились понятия бизнес-процессов и нотаций бизнес-процессов, два неразрывно связанных понятия.

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

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

Зачем моделировать (описывать) бизнес-процессы

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

Моделирование бизнес-процессов помогает решить сразу две задачи:

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

И сочетание изучения истории появления термина с моим личным опытом дает следующее определение:

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

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

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

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

Как описывать бизнес-процессы

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

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

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

1. Собираем участников процесса (сотрудников);
2. Собираем входящую информацию, необходимую и достаточную для запуска процесса;
3. Собираем используемые системы. Это может быть учетная система,CRM, электронная почта, таблицы Excel и т.д. Все, что реально используется в работе, необходимо зафиксировать.
4. Определяем ожидаемый результат – что будет в конце процесса.
5. Собираем последовательность действий, которые выполняет человек.
6. Вычленяем условия. В зависимости от разных входящих данных и промежуточных результатов действия могут быть разными.
7. Описываем всю собранную информацию в графическом виде в удобной нотации (IDEF3, BPMN 2.0 и т.д.).

Правила описания бизнес-процесса

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

• Законченность. Бизнес-процесс должен четко отвечать на вопрос, стоящий перед ним. Если мы говорим о процессе продажи определенного товара или услуги, то бизнес-процесс должен полностью описывать действия, необходимые для получения указанного результата, и завершающегося именно таким результатом (с определенными допущениями, о которых я говорил выше).
• Лаконичность. Бизнес-процесс должен сочетать в себе достаточность, т.е. описывать все необходимые этапы и действия, при этом быть максимально лаконичным для простоты восприятия. Лично я вывел для себя «правило 15 минут» - если за этот период времени я могу объяснить руководству компании представленный бизнес-процесс, значит, его можно показывать заказчику. Получается быстрее – прекрасно, требует больше времени и слов – надо подумать, что можно сократить и упростить.
  Я когда-то лично видел графическое описание бизнес-процесса, выполненное на листе 2 метров длиной (и соответствующей шириной). Его даже просто рассмотреть и понять, куда ведет какая стрелка крайне сложно. А как его пояснять заказчику, я лично не представляю.
  Помните, что человек воспринимает зрительно определенный объем информации, ограниченный, в том числе, определенным размером листа или экрана (это связано с особенностями зрения), а также числом элементов (возможности мозга также ограничены). Простой и лаконичный бизнес-процесс заказчик поймет, просто «охватив» схему взглядом. Сложный и перенасыщенный деталями придется изучать не один час просто для того, чтобы понять, что там отображено. Скорей всего, руководитель компании, который не является экспертом в работе отдельных подразделений, а также ограничен по количеству свободного времени, просто не будет изучать столь сложную конструкцию и не поймет сути даже самых выгодных предложений.
• Использование общепризнанных нотаций. Не стоит изобретать собственные обозначения и правила. Используйте нотации, которыми пользуются во всем мире. Я видел в книгах некоторых отечественных авторов попытки создания собственной системы обозначений. И, честно говоря, так и не понял, зачем они усложняют жизнь и себе, и своим читателям. Здесь как с языком – вы можете придумать свой особый язык, но понимать его никто, кроме вас, не будет. А если он окажется похож на существующие, то может еще и путаница появиться. Либо вас сочтут безграмотным, так как вы не по правилам известных языков используете пунктуацию, склоняете слова и т.д. Так и с нотациями – есть уже устоявшиеся, известные людям и, что также немаловажно, интуитивно понятные нотации. Они потому и стали популярны, что в процессе их создания и доработок постоянно тестировались на простоту, однозначность и удобство. Если вы будете использовать готовые нотации, вас будут понимать, воспринимать, как эксперта, да и сами правила нотаций уберегут вас от логических ошибок. Я лично рекомендую IDEF3 и BPMN 2.0.
• Все участники бизнес-процесса должны быть учтены и прямо указаны. И делать это необходимо без использования сносок с нумерациями, комментариях в объектах Swimm line (специальные сноски) и т.д. Этим нередко «грешат» любители создавать собственные конструкции вместо использования готовых нотаций. Где-то у них названия не помещаются, где-то им кажется, что длинное название в теле бизнес-процесса будет неудобным. В результате либо приходится искать в сносках, о ком именно идет речь, либо создатели таких бизнес-процессов просто забывают указать кого-то из участников.
• Понятное потребителю описание. Самое главное – ваш потребитель, тот, кто будет читать эту нотацию, должен быстро и, в идеале, даже без ваших пояснений понимать описание бизнес-процесс.

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

Распространенные мифы и заблуждения

Не «изобретайте велосипед»! Не нужно придумывать свои нотации.

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

Я не рекомендую так поступать. Во-первых, при использовании готовых инструментов вам не потребуется изобретать свои обозначения и стандарты. Все давно придумано до вас. При этом стандартные нотации действительно понятны интуитивно, читаются однозначно, известны многим людям. Во-вторых, в готовых системах (IDEF3, BPMN 2.0 и пр.) имеется проработанная методология и строгие ограничения. Их можно воспринимать как язык программирования и среду для работы с этим языком. Здесь вы просто не сумеете совершить многих ошибок, от этого вас уберегут стандарты синтаксиса и сама среда (ограничения в редакторе, автоматические проверки).

Не путайте описания бизнес-процессы компании и бизнес-процессы IT систем.

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

Распространенная ошибка: Бизнес-процесс обязательно приносит ценность (прибыль).

О том, что бизнес-процессы должны приносить прибыль, я слышал даже от известных спикеров. Более того, видел даже “разбор ошибок” при создании бизнес-процесса, в котором очень много внимания уделяется тому, что 70% действий не несут никакой ценности.

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

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

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

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

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

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

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

Владимир Репин

Генеральный директор ООО «Владимир Репин Менеджмент»

Член ABPMP Russia

Консультант по управлению

Бизнес-тренер

Кандидат технических наук

В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема » в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие. При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов.

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

Введение

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

Сравнение нотаций

Для сравнения были выбраны следующие нотации описания процессов:

1. «Простая блок-схема » (с отображением движения документов, с использованием блока «Решение»);
2. «Простая блока-схема » (без отображения движения документов, без использования блоков «Решение»);
3. «Процедура» системы Business Studio (один из возможных вариантов представления);
4. ARIS eEPC.

В качестве тестового примера был выбран простой и интуитивно понятный процесс. Результаты описания этого процесса представлены на Рис. 1-4.

Рис. 1. Схема процесса в нотации «Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)

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

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

Сформулируем «плюсы» и «минусы» рассмотренного выше (Рис. 1) способа использования «ромбиков».

«Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)

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

Рис. 2. Схема процесса в нотации «Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)

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

«Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)

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

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

Второй особенностью схемы процесса, представленной на Рис. 3, является применение стрелок. Для отображения последовательности операций можно использовать стрелку с одним наконечником — стрелку «предшествования». Для отображения движения документов можно использовать стрелку с двумя наконечниками. Однако в Business Studio можно обойтись использованием только одного типа стрелок — стрелками «предшествования». При этом к именованным стрелкам можно привязывать необходимое количество документов, которые определены в справочнике объектов деятельности.

Такой подход дает возможность:

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

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

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

Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

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

«Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

В случае применения Business Studio, нотация «Процедура» может быть использована несколько по-разному. Автор статьи склоняется к подходу, представленному на Рис. 3.

На Рис. 4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Заметим, что на схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий! Сотрудник, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем, рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или помощи квалифицированного бизнес-аналитика.

Заметим, что схема процесса в нотации ARIS eEPC занимает существенно больше места, чем схемы, представленные на Рис. 1-3. Трудоемкость формирования такой схемы также существенно выше.

Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio)

Схема процесса в нотации ARIS eEPC (построена в Business Studio)

В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.

Описание процесса для целей последующей автоматизации

Интересно рассмотреть приведенный выше пример описания бизнес-процесса в случае, если он представлен в нотации BPMN 2.0. Это нотация предназначена для описания «исполняемых» процессов, т. е. процессов которые поддерживает система BPM.

Своим мнением об использовании BPMN 2.0. делится А. А. Белайчук — Генеральный директор компании «Бизнес-консоль»:

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

Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением — „движком“ BPM-системы.

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

Рис. 5. Схема процесса в нотации BPMN 2.0

Практика жизни

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

Рис. 6. Примеры схемы процесса одной из компаний

При формировании схемы Рис. 6, бизнес-аналитики очевидно, «боролись» за наглядность и максимальную понятность для рядового пользователя. Они стремились свести к минимуму, или вообще отказаться от текстового комментария к схемам процессов. Исполнителям просто печаталась схема формата А3, при чтении которой все сразу становилось понятно: что делать, как, какие документы использовать и т. п.

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

Выводы

Итак, очевидно, что при описании процессов нужно стремиться к простоте и понятности для сотрудников.

Использование сложных, формализованных нотаций при описании процессов приводит к:

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

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

http://finexpert.ru/ — среда общения профессионалов http://bpm3.ru/ — процессы, проекты, эффективность

Ковалев Сергей Михайлович
Ковалев Валерий Михайлович
(Журнал "Консультант директора", № 12, Июнь, 2004 г.)

Семь "золотых" правил описания бизнес-процессов

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

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

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

Правило 1. Составляйте, уточняйте, подтверждайте схемы вместе с "владельцами"/"участниками" бизнес-процессов.

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

Правило 2. Используйте визуальные подходы описания бизнес-процессов, способствующие повышению эффективности работы в группе.

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

Правило 3. Используйте язык, понятный "владельцам"/"участникам" бизнес-процесса.

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

Правило 4. Создавайте схемы деятельности, а не организационных структур.

При описании бизнес-процессов нужно "забыть" про существующую организационную структуру и не использовать ее как средство выделения бизнес-процессов и работ. Бизнес-процессы строятся на основе стратегии, а организационная структура подстраивается под них, но не наоборот. Именно поэтому организационная структура описывается и накладывается на бизнес-процессы в последний момент. Факт того что, она будет не состыковываться с процессами говорит об ее неоптимальности. Если пренебречь этим правилом и в качестве средства выделения бизнес-процессов и работ использовать действующую оргструктуру, то вероятность того, что разработанные описания бизнес-процессов будут искажены в случае неоптимальной организационной структуры достаточно велика.

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

Правило 5. Избегайте излишней детализации бизнес-процессов, особенно на схеме "как есть".

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

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

Правило 6. Избегайте составления схемы бизнес-процесса ради схемы, не ведущей к дальнейшему анализу и действиям.

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

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

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

Правило 7. Не смешивайте понятия "как есть", " как должно быть", "как будет".

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

Личная информация:

Консультировал в области регулярного менеджмента более 70-ти компаний: от 10 до 9.000 человек (включая: холдинги, сети магазинов, фабрики, сервисные компании, строителей, государственных служащих, веб-агентства, интернет-магазины). Ученик Александра Фридмана.

Один из соавторов книги "Социальные технологии Таллиннской школы менеджеров. Опыт успешного использования в бизнесе, менеджменте и частной жизни": http://www.ozon.ru/context/detail/id/140084653/

генеральный директор

«Три пути ведут к знанию: путь размышления - это путь самый благородный, путь подражания - это путь самый легкий и путь опыта - это путь самый горький»

Конфуций

кому: собственникам, топ-менеджерам, руководителям

Управление процессами через регламенты приводит к управлению «рукой через ногу»

Я уже неоднократно рассказывал о пользе регламентов, которые решают такие важные задачи для собственников бизнеса и руководителей, как:

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

И редко встречал руководителя, который не считал бы регламенты полезными. Казалось бы, регламент это панацея от всех бед! Но... Попытки “управлять только по регламентам” зачастую терпят неудачу.

Почему? Сейчас попробую объяснить. Регламент - это описание какой-либо части рабочего процесса (последовательности действий), протекающего в компании: либо процесса целиком, либо нескольких процессов, либо части процесса.

Процесс (синоним “бизнес-процесс”) - это последовательность действий для решения какой-либо типовой задачи (нетиповые задачи относятся к проектам).

Процессами эффективно управлять напрямую, а для их формализации - чертить схемы

Процессы делятся на простые и составные. Составные - содержат в себе несколько простых процессов. Ещё бывают сквозные процессы . Так называют процессы, разные этапы которых проходят через несколько отделов компании. В этом обычно и заключается их сложность.

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

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

Почему регламентов недостаточно

• Далеко не все процессы линейные. Многие имеют множество условий “если…, то…”. Сложно быстро разобраться в “полотенце” текста регламента и понять, как этапы процесса связаны между собой . Например, регламент по подбору сотрудников изобилует подобными развилками почти на каждом этапе. В зависимости от должности соискателя собеседование может проходить удалённо или очно, с привлечением его непосредственного руководителя или без.
• Если процесс проходит через несколько звеньев, возникает проблема “кто ответственен за конечный результат”. В случае сбоев и косяков, сотрудники валят вину друг на друга и на обстоятельства, возникает круговая порука.
• Сотрудники не могут договориться между собой о том, кто выполняет какую работу.
• Из-за низкой наглядности (всё тот же гигантский объём текста регламента) крайне непросто заниматься оптимизацией и развитием процесса .
• Значительны затраты времени сотрудников на чтение, изучение, и понимание общей картины и всех взаимосвязей. Регламент редко описывает процесс целиком. Зачастую процессу, проходящему через несколько отделов, соответствуют разные регламенты.

Введение в управление процессами: в каком виде лучше описать процесс?

Управление процессами - целая наука. Но я буду целенаправленно упрощать многие вещи, чтобы было понятно, как это работает. Если кратко, то суть теории управления процессами в том, что вся деятельность компании может быть разбита на процессы (неожиданно, да?)

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

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

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

Всем этим критериям, по моему мнению, отвечает нотация BPMN (версия 2.0) . Для отрисовки схем рекомендую использовать бесплатную программу Bizagi Modeler .

И ещё раз про упрощение. Начиная рисовать схемы, вам не обязательно соблюдать стандарт на все 100%, это только усложнит внедрение. На начальных этапах главное, чтобы схемы были понятны участникам и однозначно ими трактовались. Привести схемы в соответствие стандарту вы еще успеете.

Итого, схемы процессов решают следующие задачи:

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

Не забудьте задать цели оптимизации и подсчитать, насколько изменятся затрачиваемые ресурсы у новой версии процесса!

Ключевая фишка процессного управления - ответственный за весь процесс

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

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

Ответственный за весь процесс (иногда его называют “владелец процесса”) - это руководитель (или сотрудник), который отвечает за доработки и развитие бизнес-процесса; решение глобальных возникающих коллизий и анализ сбоев; помощь и обучение ответственных за копию процесса.

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

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

За развитие процесса и выполнение всех его копий должен отвечать один человек

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

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

Алгоритм описания и развития бизнес-процесса с помощью схем и регламентов

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

Этап 1. Нарисовать и согласовать схему процесса

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

Пример №1. Схема процесса “Подбор сотрудников” в нотации BPMN

Пример №2. Часть схемы “Подбор сотрудников” в нотации BPMN

Этап 2. Написать регламент выполнения этапов процесса

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

Пример описания в регламенте одного из этапов схемы процесса

Этап 3. Запустить управление процессом

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

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

В дальнейшем перейдите на бизнес-процессы в Битрикс24 или 1С. Вполне возможно, что их будет более чем достаточно для вашей компании.

Этап 4. Развивайте и оптимизируйте процесс с целью роста эффективности и качества

Как я уже упоминал, за развитие процесса должен отвечать его “владелец” (обращаю внимание, что это не из разряда “хочу/не хочу”, а почётная обязанность сотрудника).

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

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

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

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

Заключение, или Почему «всё и сразу» - это путь на кладбище проектов

Про процессы можно рассказывать много, хватит на целую книгу. Но… кладбища мёртвых проектов заполнены попытками внедрить “всё и сразу” и на самом дорогом и/или многофункциональном программном обеспечении. В лучшем случае сотрудники не использовали внедрённые технологии, или системы получались настолько громоздкими, что работать с ними было невозможно. В худшем - сложности при внедрении так и не позволили завершить работу до конца.

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

Читавшие эту статью, также читали

Время «Ч»: Когда внедрение регулярного менеджмента в вашей компании неизбежно, а оттягивание старта лишь принесёт дополнительные убытки

Сайт производителя товаров и оборудования: 10 типовых ошибок, которые препятствуют поиску новых дилеров и оптовиков

← Вернуться