Бизнес процесс примеры готовые. Описание бизнес процессов

И, тем не менее, ум человеческий тщетно пытался постигнуть ее в течение более чем 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% действий не несут никакой ценности.

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

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

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

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

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

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

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

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

1. Текстовый: «Отдел продаж составляет договор и согласует его с юридическим отделом».

2. Табличный.

3. Графический.

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

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

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

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

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

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

ОПИСАНИЕ ОКРУЖЕНИЯ БИЗНЕС-ПРОЦЕССА

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

Пример 1

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

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

Пример 2

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

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

КЛАССИФИКАЦИЯ ВХОДОВ И ВЫХОДОВ БИЗНЕС-ПРОЦЕССОВ

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

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

Характеристики первичных и вторичных входов и выходов бизнес-процесса

Элемент	Определение и характеристики
Первичный выход	· Основной результат, ради которого существует бизнес-процесс. · Определяется целью, назначением бизнес-процесса.
Вторичный выход	· Побочный продукт бизнес-процесса, который может быть востребован вторичными клиентами. · Не является основной целью бизнес-процесса.
Первичный вход	Поток объектов, инициирующий «запуск» бизнес-процесса, например заказ клиента, план закупок и т.д.
Вторичный вход	Потоки объектов, обеспечивающие нормальное протекание бизнес-процесса, например стандарты, правила, механизмы выполнения действий, оборудование и пр.

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

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

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

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

КЛАССИЧЕСКАЯ МЕТОДОЛОГИЯ ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ

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

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

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

Согласно классическому подходу стандарт DFD, который расшифровывается как Data Flow Diagram, представляет собой диаграмму потоков данных, которая используется для описания бизнес-процессов верхнего уровня. В свою очередь стандарт WFD расшифровывается как Work Flow Diagram и представляет собой диаграмму потоков работ, которая используется для описания бизнес-процессов нижнего уровня. У диаграммы потоков работ имеется и другое название — диаграмма алгоритмов. Давайте рассмотрим два этих стандарта, составляющих классическую методологию описания бизнес-процессов.

ПОСТРОЕНИЕ ДИАГРАММ ПОТОКОВ ДАННЫХ - DFD

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

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

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

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

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

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

Правило 1. Названия работы нужно формулировать согласно следующей формуле:

Название работы = Действие + Объект, над которым действие осуществляется.

Например, если эта работа представляет собой действие по продаже продукции, то ее нужно назвать «Продажа продукции», а еще лучше конкретизировать, что это за продукция. В данном случае «продажа» — это действие, а «продукция» — объект, над которым действие по продаже производится.

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

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

Название потока = Объект, предоставляющий поток + Статус объекта.

Например, если речь идет о продукции, которую отгрузили клиенту, то данный поток нужно сформулировать следующим образом: «Продукция отгруженная» или «Продукция, отгруженная клиенту». В данном случае «продукция» — это объект, представляющий поток, а «отгруженная клиенту» — статус объекта.

ПОСТРОЕНИЕ СЕТИ БИЗНЕС-ПРОЦЕССОВ

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

Другое наглядное представление бизнес-процессов компании — сеть процессов, которая представляет DFD-схему, построенную на основе бизнес-процессов, составляющих дерево.

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

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

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

ДЕКОМПОЗИЦИЯ БИЗНЕС-ПРОЦЕССА

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

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

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

В случае необходимости работы на схеме процесса второго уровня могут быть декомпозированы на схемы бизнес-процессов третьего уровня и т.д. Декомпозиция бизнес-процесса должна продолжаться до тех пор, пока не будут достигнуты цели его описания. В данном случае удобно использовать понятия «вложенный процесс» или «подпроцесс». На рис. 7 процессная схема работы 3 является вложенным процессом или подпроцессом процесса верхнего уровня. Аналогичным образом процессные схемы работ 3.1 и 3.4 являются вложенными процессами или подпроцессами процесса второго уровня.

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

ПОСТРОЕНИЕ ДИАГРАММЫ ПОТОКОВ РАБОТ - WFD

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

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

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

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

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

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

Итак, с помощью двух классических схем — DFD и WFD — можно описать подробно все бизнес-процессы компании.

С.М. Ковалев, генеральный директор компании «БИТЕК», В.М. Ковалев, ведущий консультант компании «БИТЕК»

Инструкция

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

Описать бизнес-процесс можно несколькими способами. Наиболее популярный из них - графический, с помощью , выполненных в различных нотациях (нотация - набор символов для обозначения чего-либо).
Самые распространенные виды нотаций для описания бизнес-процессов - это IDEF0, BPMN, EPC (ARIS) и др.
В качестве примера остановимся на диаграмме, выполненной в нотации BPMN (Business Process Modelling Notation) с помощью CASE-средства PowerDesigner (Рис.1). Главными элементами на диаграмме являются:
1. «Процесс» (функция) - скругленный по углам прямоугольник;
2. «Переход» - стрелка, соединяющая процессы;
3. «Решение» - ромб, содержащий вопрос, на который можно ответить только «Да» или «Нет»;
4. Условия - текстовые выражения, при которых осуществляется переход от функции к другой. Условия всегда заключаются в квадратные скобки. Иногда полезно разбить вашу на «Дорожки» - вертикальные или горизонтальные секции, обозначающие подразделения предприятия или сотрудников, ответственных за выполнение определенной функции. В таком случае этой функции должен находиться в пределах своей секции. Кроме перечисленных элементов, может содержать также перечень данных, которые являются входными или выходными для процесса, а также ссылки на правила или регламент, согласно которым выполняется та или иная функция. Пример описания бизнес-процесса «Контроль производства изделия» показан на рис.1. Нетрудно заметить, что эта диаграмма очень похожа на блок-схему алгоритма решения задачи.

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

Полезный совет

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

Источники:

• М.Рыбаков. Оптимизация бизнес-процессов.
• как составить бизнес процесс

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

Инструкция

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

Показав суть изменения, обычно переходят к описанию процесса как последовательности «состояний» С этой целью обычно все время наблюдения с

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

Общая информация

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

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

Функциональный подход

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

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

Процессный подход

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

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

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

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

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

Порядок разработки

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

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

Чему следует уделить внимание?

Следует сконцентрироваться на следующих разделах:

1. Стандартные формы.
2. Карта.
3. Маршруты.
4. Матрицы.
5. Блок-схемы.
6. Описание стыков.
7. Вспомогательные описания.
8. Документирование.
9. Развернутое описание.
10. Определение индикаторов и показателей.
11. Регламент выполнения.

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

О картах замолвим слово

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

Также можно проследить и то, проходит ли и как информация между разными подразделениями компании. Для получения наилучшего эффекта следует поставить несколько вопросов. Кто совершает эту операцию? Зачем её необходимо выполнять? Что она собой представляет? Когда нужно проводить операцию? Где она осуществляется? При улучшении осуществляемых процессов следует ёще поинтересоваться, можно ли её совершенствовать.

Матрицы

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

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

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

Почему хорошая формализация бизнес-процесса важна?

1. Она позволяет сделать наши мысли предметом широкого обсуждения.
2. Она дает возможность донести новые правила работы до тех сотрудников, которые будут их выполнять.
3. Формализованные бизнес-процессы легче изменять и модернизировать.
4. Формализация бизнес-процессов является хорошей основой для последующей автоматизации бизнеса в компании: создания/настройки различных информационных систем и стандартных пакетов автоматизации.

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

Пример бизнес-процесса

В качестве примера я взял крупный магазин по торговле мебелью и его бизнес-процесс "Покупка клиентом товара". На рис. 9.1 представлена диаграмма этого бизнес-процесса в нотации BPMN , с комментариями по нотации.

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

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

1. "Оформление заказа". Сначала клиент оформляет заказ. Предполагается, что перед этим он определился в главном - что ему нужно. Например, кухонный гарнитур. Тогда в отделе по торговле кухонной мебелью он, вместе с одним из менеджеров этого отдела, составляет дизайн-проект для своей покупки (в соответствии с размерами его кухни и своими пожеланиями), уточняет параметры своего заказа и точно определяется с комплектующими и материалами.
2. "Получение товаров". Клиент идет на склад и сам выбирает все составные части своего заказа, имея точный перечень того, что ему нужно. При этом ему помогают работники склада.
3. "Оплата товаров и оформление доставки". Клиент вместе со своими выбранными товарами (он везет их на тележке) следует к кассе и оплачивает то, что он выбрал. Далее, с оплаченными товарами, он переходит в отдел доставки, где оформляет и оплачивает доставку своей мебели, а также ее сборку (если ему это нужно); после этого он уезжает домой.
4. "Доставка". Оплаченные товары клиенту доставляют в течение трех дней.
5. "Сборка". После этого, если клиент оформил сборку, то к нему приезжает мастер-сборщик и собирает доставленную мебель.

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

Декомпозиция бизнес-процессов

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