instructor

Рамиль Кинзябулатов

2022-09-12

Что такое бизнес-процесс и описание бизнес-процесса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Технологический процесс и бизнес-процесс

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

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

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

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

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

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

Я не единожды читал информацию о том, что нотации бизнес-процессов (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 (специальные сноски) и т.д. Этим нередко «грешат» любители создавать собственные конструкции вместо использования готовых нотаций. Где-то у них названия не помещаются, где-то им кажется, что длинное название в теле бизнес-процесса будет неудобным. В результате либо приходится искать в сносках, о ком именно идет речь, либо создатели таких бизнес-процессов просто забывают указать кого-то из участников.
  • Понятное потребителю описание. Самое главное – ваш потребитель, тот, кто будет читать эту нотацию, должен быстро и, в идеале, даже без ваших пояснений понимать описание бизнес-процесс.

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

 Нередко даже в профессиональной среде путают два понятия — декомпозиция и подпроцесс. На самом деле, это далеко не одно и то же. И важно понимать разницу между этими двумя терминами.

Декомпозиция или подпроцесс?

Декомпозиция

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

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

 Пример декомпозиции сущности А: 

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

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

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

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

Подпроцесс

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

Подпроцесс А внутри процесса:

Подпроцесс А внутри процесса

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

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

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

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

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

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

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

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

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

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

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

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

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

Мифы и заблуждения о бизнес процессах

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

Миф 1. Бизнес-процессы бывают сквозными

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

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

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

Миф 2. Бизнес-процессы всегда должны нести ценность

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

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

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

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

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

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

Миф 3. Всегда при анализе нужно иметь As Is (Как есть)

Об этом часто пишут в учебниках, в том числе зарубежных. Там описывается последовательность действий: сначала нужно получить As Is (Как есть), потом перейти к To Be (Как должно быть). В таком подходе нет ничего плохого, но только в том случае, если вы приходите в компанию, где уже есть какое-то свое «как есть». Т.е. в учебниках описывают ситуацию, когда бизнес-консультант приходит в компанию, где уже есть какая-то система, люди работают по определенным принципам. Ему надо разобраться, что происходит, после чего он сможет предложить что-то лучшее.

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

Потому достаточно часто нет никакой необходимости составлять нотации «As Is». Если нет единой системы, какой смысл анализировать, что происходит? Вы это поймете и так, на этапе интервью с сотрудниками. Системы нет. Люди это прекрасно понимают. Им не надо пояснять, что у них все работает неправильно и бессистемно. Скорей всего, вас именно по этой причине и позвали. А раз не существует того, что стоит анализировать, можно и нужно сразу продумывать, как это должно работать. И предлагать вариант — «Как должно быть».

Миф 4. Всегда нужно знать процесс на уровне сотрудников

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

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

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

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

Миф 5. Основные и вспомогательные процессы — важное отличие

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

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

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

Миф 6. Бизнес-процесс — это только для бизнеса

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

 

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

Самое популярное определение дают на сайте businessstudio.ru:

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

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

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

Почему я не рекомендую пользоваться этим понятием

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

О вычислении владельца

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

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

Как обычно предлагают вычислять владельца бизнес-процесса:

  • По наибольшим затратам;
  • По наличию полномочий;
  • По наибольшему преобразованию;
  • По соответствию цели.

В качестве красивых слов этот перечень можно использовать. Но на практике оказывается, что они не имеют смысла. 

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

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

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

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

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

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

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

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

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

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

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

Ошибочность понятия владелец бизнес-процесса

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

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

Зачем придумали владельца бизнес-процесса

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

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

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

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

Трудоемкость и цена описания бизнес-процесса

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

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

Есть два подхода к формированию стоимости описания бизнес-процесса:

— Подсчет потраченного времени;

— Создание пакетов услуг.

Считаем трудозатраты: плюсы и минусы

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

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

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

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

Пакеты услуг: профессиональные решения

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

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

Какой подход выбрать?

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

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

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

Ответственность бизнес-консультанта

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

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

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

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

Результат для бизнеса зависит от нескольких факторов, и далеко не всегда они связаны с вашей работой.

Кто занимается внедрением?

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

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

Консультант в штате или приглашенный специалист

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

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

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

А если мы понесем убытки?

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

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

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

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

Консультант – это советчик

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

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

Ответственность заказчика

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

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

Частые ошибки заказчиков:

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

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

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

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

От переговоров к результату

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

Результат также обсуждается заранее. Это может быть:

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

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

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

Должен ли знать консультант процессы на уровне людей непосредственно работающих с этими процессами

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

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

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

Из собственного опыта

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

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

На самом деле, консультанту во всем этом разбираться не нужно.

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

Не пытайтесь стать сотрудником

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

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

А как же тогда адаптировать?

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

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

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

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

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

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

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

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