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

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

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

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

Рис. 1. Системный оператор.

1. НАСТОЯЩЕЕ.

1.1 Исследуемая система: бизнес-процессы.

Система бизнес процессов, особое внимание сквозным бизнес-процессам (затрагивающим работу 2 и более отделов или групп). Гибкость процессов.

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

1.2. Надсистема.

Стратегический менеджмент, система сбалансированных показателей. Горизонтальное взаимодействие сотрудников. Бережливое производство, система менеджмента качества. Рынок, конкуренция. Частая смена обстановки, динамика среды. Изменения законодательства.

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

1.3. Подсистемы.

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

2. ПРОШЛОЕ 30-е гг. 20 века.

2.1. Система.

Человек на рабочем месте, инструкции руководителей (именно «инструкции»).

Одной из самых известных методологий описания организаций как организационно-технических систем, стала методология структурного анализа и проектирования систем SADT (Structured Analysis and Design Technique) . Она была разработана американцем Дугласом Россом (D. Ross) в 1973 г. Особенно широкое применение получило одно из подмножеств SADT — методология функционального моделирования IDEF0 (Integration Definition For Function Modeling). Инициатором ее разработки и дальнейшей стандартизации было Министерство обороны США. Методология IDEF0 успешно применялась в военных, коммерческих организациях для решения широкого спектра задач (от разработки программного обеспечения для оборонных систем до разработки систем материально-технического снабжения и управления финансами). Наличие возможностей и опыт применения IDEF0 в различных предметных сферах, наряду с растущей компьютерной поддержкой, сделало ее еще более доступной в использовании. Это, в свою очередь, также привело к широкому использованию IDEF0 как методологии для описания бизнес-процессов организаций. Во многом популярность методологии функционального моделирования IDEF0 обусловлена простотой нотации, основными элементами которой являются функциональный блок и стрелка.

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

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

3.2. Надсистема.

3.3. Подсистемы.

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

4. БУДУЩЕЕ.

4.1. Система.

Гибкие карты бизнес-процесса, интегрированные в CRM-системы и системы более высокого уровня (ERP-системы).

4.2. Надсистема.

Саморазвивающийся бизнес (компания), дальнейшее развитие LEAN , CRM-система, ERP-системы с интеграцией , .

4.3. Подсистемы.

Мгновенный доступ к самообновляющейся информации. Гибкая система бизнес процессов (модель), управление ответственностью, управление персоналом, регламентация процессов, автоматическая отчетность по показателям, гибкое управление эффективностью процессов. Автоматизация, роботизация, система развития компетенций, knowledge management .

Шаг 2.

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

Основные моменты, на которые необходимо обратить внимание при описании бизнес-процессов (результат применения системного оператора):

1. Что потеряли из прошлого (а это интересно и эффективно)?
2. Что изменится в перспективе? Что можно оставить без изменений, а в каких аспектах нужно заложить фундамент уже сейчас?
3. На что седует обратить внимание при разаработке алгоритма описания бизнес-процессов?

При анализе системы описания бизнес-процессов с помощью системного оператора мы увидели следующее:

1. Подсистемы: Быстрый доступ к информации. Система бизнес процессов (модель), управление ответственностью, управление персоналом, регламентация процессов, отчетность персонала, автоматизация процессов, управление эффективностью процессов. Мы видим, что бизнес-процессы должны иметь возможность быстро извлекаться из информационной среды, иметь высокую гибкость, иметь реперные точки, которые покажут, что изменится в надсистеме при изменении бизнес-процесса на уровне конкретной должности.
2. Стратегический менеджмент, система сбалансированных показателей. Бережливое производство, система менеджмента качества. Рынок, конкуренция… Относительная стабильность, постепенная, плавная смена обстановки (существенное отличие от НС «Настоящее» ).Действующее законодательство. При проектировании бизнес-процессов должна быть разработана система показателей: KPI (ключевые показатели эффективности) и управленческие индикаторы, по которым мы отслеживаем эффективность достижения KPI. Будущее показывает нам, что бизнес-процессы должны быть включены с систему управления знаниями, то есть должна быть разработана система показателей, завязанная на модель компетенций. Предусмотреть здесь отсутствие разрыва! Автоматическому сбору статистики по показателям следует уделить особое внимание, развивать культуру работы с цифрами, постепенно подготавливая систему управления к применению методов машинного обучения в будущем.

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

1. Учесть, что чувство времени у людей хоть и развилось со времен А.К. Гастева, но все же далеко от идеала, поэтому бизнес-процессы должны быть автоматизированы в CRM-системе с функцией автоматического уведомления, но в любом случае, перед тем как готовить ТЗ для CRM, куда в конечном итоге попадет описание БП, создается бумажный документ. Важно учесть, что пытаться все подряд регламентировать глупо, а в небольших компаниях такое внимание к администрированию чревато потерей бизнеса. Поэтому перед регламентацией процессов следует определить положение компании на S-кривой (удобнее всего по И. Адизесу) и исходя из этого назначить «масштаб» регламентации, то есть определить степень детализации процесса. Также важно определить степень свободы принятия решения сотрудника в изменении бизнес-процессов с целью повышения их эффективности. Как было указано выше, предусмотреть возможность оперативного изменения процесса, но с простановкой маркеров, какие из смежных процессов будут невольно затронуты. Следует предусмотреть разграничение прав доступа по изменению процессов.

1. Изучение успеха IDEF0 показывает нам, что для представления бизнес-процессов необходимо стараться максимально уходить от текстовых инструкций в пользу графики — инфографики, рисунки с короткими пояснениями. Если необходимо более подробное разъяснение, его можно дать в качестве примечания к соответствующему пункту инфограммы. Такие инструкции воспринимаются и запоминаются гораздо лучше, но здесь есть и подводные камни. Хорошая инфографика — лучший вариант с точки зрения восприятия инструкции пользователем, но у нее есть огромный минус в том, что рисовать схемы очень дорого и долго по времени. Не все сотрудники могут этим заниматься. Сегодня указанная проблема решена. В 2016 - 2017 годах происходит настоящий бум по интеграции графического отображения бизнес-процессов в CRM-системах согласно рекомендациям IDEF0. Отсюда понятно, что стоит обратить внимание на CRM-системы, обладающие именно такими возможностями и использовать их. При этом важно учесть мониторинг по показателям, указанным выше, разграничение прав доступа, сигнализацию по реперным точкам при внесении изменений.

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

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

1. При описании БП следует учесть взаимодействие между подразделениями. Именно на стыке отделов происходит наибольший дефект коммуникаций, искажение информации и различного рода сбои. Рекомендации - см. выше. Дополнительно: при определении профиля личности место не рассматривать изолировано, а посмотреть в связке с подразделениями и владельцами процессов, с которыми бизнес-процессы переплетены наиболее тесно. Задачу решать на уровне мест, в свойства материала не уходить (см. рекомендации по схематизации)!

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

Шаг 3.

Когда мы брались за эту задачу, то уже тогда понимали, что одни и те же рекомендации не могут применяться для компаний на разных этапах своего развития. Поэтому на данном шаге мы решили посмотреть, как меняется найденная нами концепция решения в зависимости от ее положения компании на S-кривой . Наилучшим образом этапы развития компании описывает S-образная кривая в концепции И. Адизеса (рис. 2):

Рис. 2. Стадии развития компании по И. Адизесу.

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

• Цели деятельности;
• Системное описание бизнес-процессов (функциональной бизнес-модели бизнеса);
• Организационная структура предприятия;
• Должностные инструкции сотрудников;
• Системы управленческой отчетности;
• Регламенты деятельности (стандартизации);
• Процедуры управления стандартами;
• Механизмы контроля исполнения стандартов на предприятии.

Теперь мы можем описать требования к БП на каждом этапе развития компании в соответствии с выбранными критериями.

1. ухаживание:

Цели: во главе стоит идея и интуиция. Бизнеса как такового еще нет, но есть огромное желание реализоваться.

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

Организационная структура: отсутствует.

Должностные инструкции: отсутствуют, все рабочие отношения строятся на словах. Должностные обязанности не прописаны.

Отчетность: отсутствует. Руководитель не нуждается в отчетности, так как сам “полностью в теме”, а также отсутствует наработанная статистика. Работа в компании не организована должным образом, чтобы учитывать результаты для формирования отчетности.

Регламенты: отсутствуют.

Управление стандартами: отсутствуют.

Отсутствуют.

2. младенчество:

Цели: начинает зарождаться целеполагание, но оно строится не по методике SMART (SMART - это аббревиатура методики целеполагания и постановки задач. Расшифровка S.M.A.R.T.: Specific (цель должна быть конкретна), Measurable (измерима), Achievable (достижима), Relevant (быть релевантной, т.е. соответствовать деятельности и потребностям предприятия, уместной), Timed (определена во времени).

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

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

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

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

Отчетность: отсутствует. Руководитель по-прежнему не нуждается в отчетности, так как сам полностью “в теме”, а также отсутствует наработанная статистика. Работа в компании не организована должным образом, чтобы учитывать результаты для формирования отчетности.

Регламенты: бизнес-процессы меняются со скоростью мысли, осуществляются бесконтрольно.Формализация бизнес-процессов невозможна.

Управление стандартами: отсутствует.

Контроль исполнения стандартов: отсутствует.

3. Давай-давай:

Цели: цели становятся более конкретными с приходом опыта, побед и ошибок. Становятся видны перспективы развития и накапливается статистика.

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

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

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

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

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

Регламенты: руководители начинают ощущать потребность в создании регламентов деятельности и приступают создавать мини-инструкции, например, как правильно принять заявку клиента, упаковать продукт или построить разговор с клиентом (скрипты переговоров). Инструкции создаются интуитивно, носят характер затыкания “дырок” в работе (локальная стандартизация). Методика регламентации отсутствует.

Управление стандартами: регламенты не проходят в компании процедуры согласования и утверждения, спускаются “сверху” персоналу. Часто воспринимаются сотрудниками как дополнительная нагрузка и вызывают негодования по поводу того, что зачем это все нужно и так “все работают на все 100% и, не покладая рук”. Руководитель проводит стихийные обучения по мере выявления “косяков”. Считает, что сотрудники и так все должны сами знать и понимать самостоятельно.

Контроль исполнения стандартов: отсутствует.

4. юность:

Цели: цели на предприятии определяются в терминах SMART.

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

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

Должностные инструкции: существующие и/или не соответствующие должностные инструкции заменяют новыми, которые созданы самостоятельно в соответствие с бизнес-процессами предприятия.

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

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

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

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

Контроль исполнения стандартов: с увеличение количества регламентов возникает потребность в регулярном контроле их исполнения (аудите).

5. Расцвет:

Цели: цели на предприятии определяются в терминах SMART с применением системы сбалансированных показателей (финансы, маркетинг, процессы, развитие персонала).

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

Возникает необходимость проведения аналогичной работы с постоянными поставщиками/подрядчиками.

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

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

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

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

Регламентация деятельности становится корпоративной культурой.

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

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

Контроль исполнения стандартов: контроль исполнения начинает проводится в форме аудита в масштабе всей компании. Процесс контроля регламентирован.

6. Стабильность:

Цели: цели на предприятии определены в терминах SMART с применением системы сбалансированных показателей, создана система показателей эффективности деятельности компании. Цели и показатели каскадированы до каждой должности.

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

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

Должностные инструкции: корректируются и улучшаются с целью повышения качества работы персонала.

Отчетность: регулярно корректируется и дополняется создающими ценность показателями и аналитикой.

Регламенты: методиками стандартизации владеют все руководители предприятия и самостоятельно применяют инструменты в своей работе. Бизнес автоматизирован. Оптимизация процессов ведется в системе автоматизации. Самообучающаяся организация.

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

Контроль исполнения стандартов: ведется регулярное проведение аудитов.

7. Аристократия:

Цели: цели перестают пересматриваться и актуализироваться.

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

Организационная структура: не актуализируется. Все привыкли к существующему положению дел.

Должностные инструкции: перестают корректироваться с целью повышения качества работы персонала.

Отчетность: не корректируется и не дополняется создающими ценность показателями и аналитикой.

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

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

Контроль исполнения стандартов: качество проведения аудитов не контролируется.

8. охота на ведьм:

Цели: цели устарели, не актуальны.

Бизнес-процессы: потеря актуальности.

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

Должностные инструкции: перестают быть актуальными.

Отчетность: перестает быть актуальной.

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

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

Контроль исполнения стандартов: аудиты отменены.

9. Бюрократия:

Цели: цели устарели, не актуальны.

Бизнес-процессы: полная потеря актуальности и структуры бизнес-процессов.

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

Должностные инструкции: устарели, либо создаются без ориентации на бизнес-модель.

Отчетность: потеря актуальности, бесконтрольное сокращение объема отчетной информации. Уход работы “в тень”.

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

Управление стандартами: рабочие группы по стандартизации не проводятся, согласование регламентов затягивается на неопределенные сроки.

Контроль исполнения стандартов: отсутствует.

Шаг 4.

Это инструментальный шаг (берите и делайте).

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

При этом учтите следующее:

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

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

1. Определить положение компании на S-кривой;
2. Исходя из п.1, сформулировать цели описания БП, поставить акценты;
3. Сформулировать название процесса;
4. Провести работу над видением и целью БП;
5. Определить границы процесса (начало и конец);
6. Определить входы (ресурс) и выходы (результат) процесса в целом;
7. Назначить владельца процесса;
8. Определить состав и последовательность выполнения работ (создать цикл );
9. Определить действия , границы, входы и выходы каждого этапа;
10. Определить сроки каждого этапа;
11. Определить ответственных за каждый этап;
12. Оформить процесс документально (подготовить Стандарт).

Для удобства использования полученной концепции результат сведем в матрицу.

Таблица 1. Рекомендации по описанию бизнес-процесса в зависимости от положения компании на S-образной кривой (что должно входить в состав описания БП на различных этапах развития компании):

Сокращения:

Бизнес-процессы (БП)

Организационная структура (Орг.)

Должностные инструкции (ДИ)

Отчетность (Отч.)

Регламенты (Р)

Управление стандартами (Упр. ст.)

Контроль исполнения стандартов (КИС)

Таблица 2. Рекомендации по описанию бизнес-процесса в зависимости от положения компании на S-образной кривой (кто должен прописывать БП):

Сокращения:

“-” отсутствует;

К — команда;

Ко — консультант (эксперт).

Литература:

1. Как преодолеть кризисы менеджмента. Диагностика и решение управленческих проблем / Ицхак Калдерон Адизес — М.: Манн, Иванов и Фербер, 2014.
2. Найти идею: Ведение в ТРИЗ - теорию решения изобретательских задач / Генрих Альтшуллер - 3-е изд. - М.: Альпина Паблишерз, 2010.

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

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 — можно описать подробно все бизнес-процессы компании.

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