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

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

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

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

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

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

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

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

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

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

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. Просто потому, что они наиболее развиты и популярны. Инструменты проверены на практике, синтаксис в них развит и стандартизирован. Это снижает вероятность ошибок или отсутствия нужного инструмента. Кроме того, в случае создания исполняемых нотаций, т.е. при автоматизации процессов, намного легче будет найти разработчика, который также работает с этими инструментами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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