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

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

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

Бизнес процессы – это не только про бизнес

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

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

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

— государственных учреждений, в том числе, медицинских, центров выдачи документов и т. д.

— благотворительных организаций любого профиля;

— общественных организаций и т. д.

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

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

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

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

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

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

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

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

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

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

Процессная модель как пошаговая инструкция

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

И здесь процессный подход становится оптимальным решением:

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

Рассмотрим в качестве примера фрагмент процесса продаж:

1. Прием звонка от покупателя;
2. Сохранение звонка (запроса);
3. Создание задачи «обработка запроса» на основе запроса от покупателя;
4. Автоматическое создание Сделки на основе обработанного запроса.

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

Теперь начинается анализ каждого этапа:

1. Прием звонка. Его нужно автоматически зафиксировать. в CRM-системе и сохранить запись. При выборе программного обеспечения рассматриваем, какие CRM-системы работают с этой телефонией. Все программные решения, которые не могут быть интегрированы с телефонией, более не рассматриваются.Выбор сужается до перечня тех, что удовлетворяют реализации этого этапа.
2. Сохранение звонка. Нужно ли вам хранить записи телефонных разговоров? Предоставляет ли телефония эту возможность? Определяем варианты реализации решения. Добавляем с техническое задание для специалиста, который будет настраивать CRM-систему требование: сохранение события – «звонок от клиента» с обязательной ссылкой на запись разговора.
3. Создание задачи. Прорабатываем детали. Как назначается ответственное лицо – автоматически или руководителем? Нужно ли отправлять уведомление о созданной автоматически задаче руководителю? Какие сведения необходимо получить от покупателя на этапе обработки запроса? Как определить, что задача выполнена, и можно открывать сделку? В некоторых случаях этот этап требует 1-2 действий, например, уточнения наличия товара и повторного звонка клиенту. В других случаях создается «подпроцесс», т.е. этап детализируется подробно. И прописывается перечень требований по автоматизации к каждому из действий.
4. Создание Сделки. Аналогично: после каких выполненных условий Сделка будет создаваться автоматически? Какие данные (информационные поля) должны быть в документе Сделка? Ответы на вопросы позволяют еще больше детализировать требования к выбору и настройке CRM. Конечно же если возможно оптимизация тех или иных действий, то оптимизируем.

И так, этап за этапом, вы продумываете подробно. В результате вы получаете четкое и однозначное решение – как это должно работать и что для этого нужно.

Т.е. в процессе разработки процессной модели и ее детализации вы получаете всю необходимую информацию:

1. Что именно необходимо выполнить, чтобы прийти к нужному результату.
2. Какие ресурсы вам нужны: компьютерные мощности, другое оборудование (телефоны, сканеры, IP-телефония, кассовые аппараты и т.д.). В том числе, в этот список входят люди – на каких этапах и каким образом будут действовать сотрудники. И какая квалификация исполнителя  в каждом случае нужна.
3. Какие требования к программной системе для вас важны. Готовый список требований поможет из перечня «возможно подходящих» быстро выбрать одну или несколько, которые действительно подходят. И далее уже определяться на основе цены, предпочтений сотрудников или каких-то дополнительных пожеланий.
4. Каким образом программная система (или системы) должны быть настроены. Т.е. вы сможете быстро и четко описать техническому специалисту, какие документы и справочники необходимы, какие в них должны быть поля для заполнения, какие задачи в какой последовательности должны формироваться и т.д.

Таким образом, процессная модель, по сути, становится основой для всех дальнейших решений.

Процессный подход при составлении плана работы

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

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

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

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

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

Процессное моделирование для взаимодействия с заказчиком

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

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

Нередко для подобных целей используют другие варианты:

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

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

Как это происходит:

1. Постановка задачи. Заказчик сообщает о проблеме и о том, что он хотел бы получить.
2. В BPMN создается графическая процессная нотация, которая проходит согласование. На этом этапе заказчик понимает, что он получит, и согласен с выбранным решением, исполнитель – что именно нужно сделать.
3. На основе согласованного решения выполняется выбор программного обеспечения (с учетом иерархии систем, о которой я уже писал в прошлых статьях).
4. Формируется план выполнения работ.
5. Выполняется внедрение.
6. Заказчик на основе согласованной процессной модели оценивает результат.

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

Два уровня: графика и текст

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

Потому я сочетаю всегда два уровня:

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

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

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

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

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

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

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

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

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

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

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

Использовать осторожно

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

• Моделирование бизнеса. Основные подходы
• Знакомство с нотацией IDEF0 и пример использования
• Краткое описание BPMN с примером
• Что такое BPMS
• Использование GAP-анализа для выявления и согласования задач по проекту

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

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

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

Как создается описание бизнес процесса

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

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

Немного о терминах используемых в данной статье

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

Таблица соотвествия сущностей и компетенцийСущность/КомпетенцияЗнание процессаБизнес моделированиеПринятие решенияСотрудник* Бизнес аналитик * Руководитель *

Зачем нужен приглашенный бизнес-аналитик?

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

1. Знание бизнес-анализа и умение работать с нотациями.
2. Информация о работе определенного процесса.
3. Требования по оптимизации: к какому результату стремится руководство компании.

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

Примеры

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

Пример 1. Автоматизация интернет-магазина

Очень распространенная ситуация – оптимизация работы интернет-магазина. Изначально на обработке заказов работало несколько человек:

• Операторы, которые вручную переносили заказы, полученные с сайта, в систему учета.
• Складской работник, занимавшийся непосредственно отгрузкой заказов.

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

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

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

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

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

Пример 2. Автоматизация такси

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

1. Заказ такси – автоматически, через сайт или приложение без участия диспетчера.
2. Доставка клиента до места назначения
3. Оплата – автоматически, с банковской карты или интернет-денег после поездки на основе GPS-данных.

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

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

Основные причины ошибок и проблем

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

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

Также, руководитель бизнеса в большинстве случаев не является экспертом в тех или иных процессах, проходящих в компании. Он может быть прекрасным организатором, но – не врачом. Или знатоком моды и стиля, но – не швеей и т.д. К сожалению, в процессе работы по оптимизации бизнес-процессов обычно основной целью является не столько улучшение работы (как это должно быть), а в первую очередь – сокращение расходов. Руководство компании, обратившейся к специалисту по оптимизации бизнес-процессов, стремится снизить издержки. А это практически всегда означает – сократить штатную единицу. Обычно это звучит как "Уменьшение человеческого фактора". Примеров подобных выше можно приводить еще много, все их объединяет несколько важных факторов, которые и приводят к печальным результатам:

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

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

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

Простое решение проблемы: цените людей

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

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

Будьте осторожнее с технологиями

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

Бизнес моделирование и IT-сфера

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

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

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

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

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

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

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. Поговорить с сотрудниками
4. Выявить наиболее важные задачи бизнес процессе
5. сделать первый вариант бизнес процесса
6. Выявить начало и конец процесса, начало должно быть только одно, финалов много.
7. Составить список задач с условиями
8. Обсудить детали с руководством и с ключевыми сотрудниками
9. представить финальный вариант
10. Подготовить текстовое описание бизнес процесса

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

1. Описать цель описания бизнес процесса

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

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

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

Примеры подобных задач: «Оптимизация процесса бизнес-контроля» или «Реинжиниринг процесса планирования».

Т.е. первый этап – это четкое понимание, а еще лучше, сразу краткое текстовое описание того, зачем вы вообще выполняете эту работу.

2. Поговорить с руководством отделов, которые работают в бизнес процессе

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

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

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

3. Поговорить с сотрудниками

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

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

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

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

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

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

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

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

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

5. Выявить начало и конец процесса

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

Помните: финалов у бизнес-процесса может быть несколько, начало – всегда одно. В принципе в пункте 2 вы уже описали финалы, но важно понимать что на данном этапе вы пишете конкретно где и сколько будет финалов.

6. Составить список задач с условиями

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

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

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

7. Сделать первый вариант бизнес процесса

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

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

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

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

8. Обсудить детали с руководством и с ключевыми сотрудниками

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

9. Представить финальный вариант

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

После согласований вы создаете финальный вариант графической нотации.

10. Подготовить текстовое описание бизнес процесса

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

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

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

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

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

Вопросы и ответы

Какое количество элементов должно быть в описании бизнес-процесса?

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

Лично я считаю, что 40-50 элементов в бизнес-процессе – это допустимый максимум. Это тот объем, который люди могут воспринять. Если необходима на каком-то этапе большая детализация, создавайте отдельные подпроцессы. Здесь главное, чтобы прочесть правильно нотацию смогли и вы, и ваши заказчики. Иначе проблем, недовольства и переделок не избежать.

Как описывать задачи текстом и делать текстовые пояснения в нотации?

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

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

В финальном варианте и документе описания уже стоит применять грамотную терминологию и приложить словарь терминов (глоссарий).

В какой нотации лучше описывать бизнес-процесс?

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

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

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

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

Цели моделирования

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

Первая цель моделирования – наглядно и однозначно поставить задачу или пояснить решение. Графика – всегда нагляднее слов. В случае использования нотаций разночтений практически не возникает.

Графика против текста

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

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

Преимущества такого подхода:

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

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

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

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

Какие бывают нотации

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

1. функциональным;
2. процессным;
3. ментальным.

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

Ментальный подход удобен для наглядной демонстрации идеи. Он не скован строгими рамками и правилами, не имеет какого-то языка моделирования. По сути, это просто графические наброски, которые помогут наглядно увидеть «слабые места» и нюансы решения. Для других видов моделирования созданы специальные языки – IDEF0, IDEF3, BPMN, UML, ARIS и многие другие.

Нередко мне задают вопрос, почему я не использую отечественные разработки. Дело в том, что в России графическое моделирование практически не развивалось. Существует две системы – сетевой график и «дракон». Но, к сожалению, они не столь популярны и не так хорошо документированы, как IDEF0 или BPM.

Выбор языка моделирования

Язык графических нотаций выбирают с точки зрения выбранного подхода и особенностей применения. Например, UML используют для работы с базами данных и алгоритмизации компьютерных информационных систем. Графические элементы этого языка отражают преимущественно объекты и управляющие элементы для взаимодействия с базами данных, а потому этот специализированный язык будет удобен разработчиками в этой сфере деятельности, но описать с его помощью производственный процесс не получится. Для описания последовательности действий при выполнении каких-то работ оптимально подойдет IDEF3 или BPMN.

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

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

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

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

В каком порядке моделировать

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

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

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

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

И последний этап – текстовые пояснения. Любая графическая модель, как я уже писал, ограничена определенными рамками и несколько абстрактна. Обойти эти рамки и донести суть модели поможет текст, где будут описаны все подробности каждого действия.

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

Насколько важно знать сферу деятельности при моделировании

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

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

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

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

Подведем итоги

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

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

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

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

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

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

Для понимания работы компании в целом вы используете функциональную модель в 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». Если нет единой системы, какой смысл анализировать, что происходит? Вы это поймете и так, на этапе интервью с сотрудниками. Системы нет. Люди это прекрасно понимают. Им не надо пояснять, что у них все работает неправильно и бессистемно. Скорей всего, вас именно по этой причине и позвали. А раз не существует того, что стоит анализировать, можно и нужно сразу продумывать, как это должно работать. И предлагать вариант — «Как должно быть».

Подробнее об As is вы можете почитать в статье Описание бизнес-процессов Как есть (AS IS) и Как должно быть (TO BE)

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Правильные «неправильные» диаграммы и почему так важно помнить о цели

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

Проблематика

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

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

Пример диаграммы управления снабжением

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

Цель

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

Я провел ABC-анализ продаж и анализ оборачиваемости склада. В результате я выяснил, что оборачиваемость склада составляла порядка 5-6 месяцев. Это очень долго. По сути, получается, что даже без постоянных закупок товара на складе хватило бы на полгода месяцев продаж.

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

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

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

Для просмотра полного изображения перейдите по ссылке

Описание

В то время я еще не работал с BPMN, это было более 12 лет назад. Описание я выполнил на основе собственного опыта и знаний, полученных из тематической литературы. Эту диаграмму вместе с текстовым описанием мы раздали сотрудникам, отвечающим за работу со снабжением.

После обсуждения было реализовано:

1. Оргструктура. Из описания понятно, что должен быть отдел закупок. Он был создан, а в самом отделе были выделены две роли – «операторы» и «менеджеры этажа». Так это тогда называлось. В компании было два «этажа» - по грузовым и легковым автомобилям.
2. Доработки в учетной системе. В соответствии с этой диаграммой была доработана учетная система. Программисты получили задание, выполнили нужные доработки. В системе была реализована возможность работать в соответствии с бизнес-процессом.
3. Обучение. По этой же диаграмме было проведено обучение сотрудников.

В результате удалось уменьшить количество остатков, в первую очередь, избавились от неликвидных остатков. Например, было выявлено, что на складе лежит долгое время 3 двигателя для грузовых автомобилей. В результате наведения порядка они были проданы со скидкой, и компания высвободила деньги. Оборачиваемость товара снизилась с 5-6 месяцев до 2-3 месяцев. Т.е. цель составления диаграммы была достигнута: разобрались в причинах и высвободили средства.

Критика

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

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

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

Что касается эстетики самой диаграммы, о ней можно спорить вечно. Эстетика – не более, чем дело вкуса. Лично я не вижу смысла обсуждать всерьез этот параметр.

Выводы

На основе описанных примеров и их критики можно сделать следующие выводы:

1. Всегда соотносите свои инструменты и результаты работы с целями, которых вы хотели достичь. Если у вас нет четко поставленной цели, то, в принципе, сама ваша работа не нужна. Это будет бесцельная работа, т.е. «мартышкин труд».
2. Если при помощи выбранных инструментов вы достигли нужного результата, можно считать, что вы все сделали как надо. Как говорится, победителей не судят. И любые ошибки с формальной точки зрения оказываются не так важны, главное – результат. Конечно, изучать свои ошибки необходимо, формальная сторона также важна для вашего собственного развития. Но упираться в только формальную сторону – не стоит. Результат намного важнее.
3. Диаграммы создаются для того, чтобы передать их другим лицам, т.е. их можно считать формой передачи информации. И если получатель информации все правильно понял, значит, диаграмма выполнила свою функцию. Например, если вы работаете сами, и диаграмму создаете также для себя, все ошибки с формальной точки зрения не имеют значения, главное, что вы понимаете, что и зачем нарисовали. Если диаграмма передается руководителю, программисту, другим сотрудникам, важно, чтобы она читалась и понималась однозначно. Правила нотаций в этом очень сильно помогают, но далеко не всегда есть необходимость ограничиваться одной из нотаций.
4. Форма диаграммы – важна, помогает лучшему пониманию. Содержание – еще важнее. Но самое главное – это цель. Если у вас есть четко поставленная цель и понимание, как прийти к результату, никакие ошибки в форме, а часто и ошибки в содержании, вам не помешают. Главное, не как вы описываете достижение цели, а владеете ли вы нужными для ее реализации инструментами, и хватит ли у вас энергии довести работу до успешного результата.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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