Моделирование Бизнес-процессов. От Идеи к Результату

Рамиль Кинзябулатов
Моделирование бизнес-
процессов. От идеи
к результату
Издательские решения
По лицензии Ridero
2019
УДК 33
ББК 65
К41
Шрифты предоставлены компанией «ПараТайп»
Кинзябулатов Рамиль
К41 Моделирование бизнес-процессов. От идеи
к результату / Рамиль Кинзябулатов. — [б. м.] : Издательские
решения, 2019. — 164 с.
ISBN 978-5-0050-3659-9
Автор рассказывает простым и понятным языком, что такое моделирование

бизнес-процессов, какие методы моделирования существуют и где они применя-
ются. Вы узнаете, зачем нужны описания бизнес-процессов, как оптимизировать
работу компании с помощью нотаций, как происходит сотрудничество бизнес-
консультанта с заказчиками. Увидите примеры бизнес-процессов и описаний
к ним.
УДК 33
ББК 65
0+ В соответствии с ФЗ от 29.12.2010 №436-ФЗ
ISBN 978-5-0050-3659-9 © Рамиль Кинзябулатов, 2019

ВВЕДЕНИЕ
Для того, чтобы правильно автоматизировать и оптимизи-
ровать работу любого бизнеса, необходимо, в первую очередь,
понимать, как именно он работает. Для этого применяют два
подхода — функциональный и процессный. Первый применяют
преимущественно для разработки стратегических решений,
а второй, процессный, как раз и направлен на то, чтобы опти-
мизировать работу подразделения или компании в целом
с точки зрения взаимодействия сотрудников, отделов и IT-си-
стем.
Как только вы столкнетесь с процессным подходом, вам по-
требуются навыки моделирования бизнес-процессов.
Я работаю бизнес-консультантом уже более 15 лет. Мои ос-
новные направления деятельности — моделирование бизнес-
процессов и их регламентация. Когда я только начал развивать
это направление в своей деятельности, самым сложным было
представление услуги. Здесь было два одинаково сложных во-
проса — как продать услугу, о которой клиент практически ни-
чего не знает, и как ее потом сдать. Причем, нередко решение
второго вопроса оказывалось даже сложнее, чем представле-
ние самой услуги.
Если вы обращаетесь к врачу с переломом, результат его ра-
боты заранее очевиден, скорее всего это будет гипс. Также, если
вы заказываете архитектурный проект дома, финал сотрудниче-
ства также ясен и однозначен. При работе с информационными
системами, например, с Zoho или 1С или в любой другой систе-
мой организации труда, все не настолько однозначно. Как опре-
делить, в какой момент задача выполнена и сотрудничество за-
вершено? Заказчики склонны годами обращаться за бесплатной
помощью по результату законченного проекте и консультациями
в полной уверенности, что так и надо.
3
РАМИЛЬ КИНЗЯБУЛАТОВ
После долгих поисков метода работы по проекту я в конеч-

ном итоге я пришел к тому, что наиболее близкой мне является
методология IDEF и BPMN. Когда я начал изучать эти инструмен-
ты IDEF уже существовала многие годы, а BPMN только набира-
ла популярность. За 15 лет я глубоко изучил эти инструменты,
и теперь решил поделиться своими знаниями с читателями.
Я расскажу, как на практике пользоваться BPMN, когда
и почему нужно пользоваться этим инструментом. Поговорим
об истории вопроса. Отдельно я расскажу о распространенных
заблуждениях, с которыми сам не единожды сталкивался
на практике. И обсудим очень важную тему — что не нужно де-
лать, т.е. поговорим о тех ошибках и «граблях», на которые на-
ступают практически все, кто начинает заниматься моделирова-
нием бизнес-процессов, и которых можно избежать, если знать
о них заранее.
В этой книге я постараюсь охватить максимум полезной ин-
формации, начиная от основ методологии и того, что такое BPM,
и заканчивая тем, как работать с нотациями на практике при мо-
делировании информационных систем и при организации рабо-
ты трудовых коллективов.
Если говорить о BPM, как о конкурентном преимуществе,
здесь самое главное — скорость внедрения новых технологий
и принципов работы. В своих публикациях я не раз повторял,
что бизнес-консультант в современных условиях — это обяза-
тельно IT-специалист, т.е. специалист по внедрению информаци-
онных систем. Сейчас невозможно себе представить работу ор-
ганизации без использования IT-систем, это просто анахронизм.
Даже если руководитель бизнеса не считает нужным рабо-
тать с компьютером, что сегодня в наших реалиях еще иногда
встречается, сама организация все равно использует различные
IT-системы. Иначе бизнес просто неконкурентоспособен.
На практике я понял, что скорость внедрения — очень важ-
на, в первую очередь, для меня, как для бизнес-консультанта.
Если над каждым проектом работать месяцами, это будет штуч-
ный товар, который вы каждый раз создаете, по сути, с нуля. По-
4
МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ. ОТ ИДЕИ К РЕЗУЛЬТАТУ
началу я и сам так работал. Но потом понял, что на самом деле,

внедрение IT-системы возможно успешно реализовать за 2—
3 недели. Причем, мы выполняли такую работу для сравнитель-
но крупных компаний, в которых работает более 100 человек.
Само собой, это выгодно мне, как бизнес-консультанту, привле-
ченным IT-специалистам. Но это также выгодно бизнесу.
И здесь BPMN оказалась тем самым инструментом, который
помогает закрывать проекты быстро и одновременно качествен-
но. Как это реализовать на практике, читайте в книге.
Кроме всего прочего, хотя я работаю на бизнес, в силу того я
знаю что нотации бизнес процессов и процессный подход ис-
пользуют также и в государственных учреждениях. Ведь пред-
приятия на которых работают ради прибыли собственника
и предприятия которые работают в интересах государства, с точ-
ки зрения организации труда ничем не отличаются.
В этой книге я рассматривал бизнес-процессы с точки зре-
ния их практической пользы. Как и любой инструмент, их нет
смысла изучать отдельно от контекста. А потому здесь вы найде-
те не только материалы, касающиеся непосредственно модели-
рования бизнес-процессов, но и много полезной информации
о бизнес-анализе в целом, об отличиях разных подходов, поста-
раюсь привести примеры их использования.
Я надеюсь, что в результате вдумчивого изучения этой книги
вы поймете, что такое бизнес-процессы, научитесь их применять
на практике. И полученные знания принесут вам реальную прак-
тическую пользу.
Я также надеюсь, что эти материалы помогут не только моим
коллегам, но и руководителям организаций. Вы сможете понять,
что именно вам предлагают, разберетесь, какие требования сто-
ит выдвигать к приглашенным специалистам, какие результаты
можно и нужно ожидать. Кроме того, я всегда повторяю, что од-
нозначное понимание сторонами терминологии — важнейший
элемент успешного сотрудничества. В сфере IT, как и в бизнес-
моделировании с этим вопросом также часто возникают пробле-
мы. Книга написана простым языком, понятным широкой ауди-
5
тории. А потому может стать прекрасным помощником в реше-

нии описанных выше проблем.
6
МОДЕЛИРОВАНИЕ БИЗНЕСА.
ОСНОВНЫЕ ПОДХОДЫ
В этом главе я хочу поговорить об основных принципах мо-
делирования бизнеса, о тех подходах, которые применяются
в этой сфере, и на основе которых создаются языки моделиро-
вания и нотации. И вот есть два типа описания модели предпри-
ятия — графический (схемы), и текстовый.
С одной стороны, применение схем для наглядности при
описании моделей бизнеса в ни у кого не вызывает вопросов.
Это действительно очень удобно. С другой стороны, многие биз-
несмены и даже мои коллеги недоумевают, зачем нужны специ-
альные нотации и правила для разработки бизнес-процессов,
ведь можно в любом графическом редакторе (visio) или при по-
мощи других удобных инструментов просто нарисовать интуи-
тивно понятную схему. О том, почему так важна стандартизация,
а также о том, в каком случае применяется тот или иной подход,
я и хочу поговорить.
ОСНОВНЫЕ ПОДХОДЫ
Сегодня существует множество различных инструментов для

разработки бизнес-моделей, они используют различные языки
моделирования, как стандартные, так и какие-то собственные
разработки. Но все их можно объединить по принципу работы
в три основных подхода:
— Функциональный;
— Процессный;
— Ментальный (с применением ментальных карт).
На самом деле, конечно, существуют и другие подходы, их
7
Пример функционального моделирования в формате IDEF0
много так же, как и языков моделирования. Но они большей

частью являются гибридными решениями, объединяющих пере-
численные подходы. Кроме того, именно процессная и функци-
ональная модели уже стали стандартами, по крайней мере,
на западе. И у нас они получают все большее распростране-
ние. Об этих основных направлениях я и хочу поговорить по-
дробнее.
Функциональное моделирование
Функциональное моделирование рассматривает деятель-
ность в организации через призму функций (лат. functio — со-
вершение, исполнение). В функциональной модели функция
не имеет временной последовательности, а только точку ввода
и точку вывода.
Функциональное моделирование помогает рассматривать
бизнес-модель с точки зрения результативности, т.е. при моде-
лировании мы исходим из того, что имеем на вводе, и того, что
желаем получить на выводе.
Например, компания разрабатывает CRM-систему для свое-
го бизнеса. В случае применения функционального подхода
к моделированию уже сама выбранная среда для работы под-
сказывает, с чего начинать. Точка ввода — «вводящий интерес
8
Пример процессного моделирования в формате BPMN
клиента или лид», точка вывода — желаемый результат: «покуп-

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

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

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

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

— Нет строгих рамок и ограничений при создании схемы;
— Ментальная карта в большинстве случаев интуитивно понятна;
— Создавать такие схемы просто.
Минусом подхода является отсутствие устоявшегося подхода

и стандартизированной методологии. Если в нотациях функцио-
нальных и процессных имеется некоторая вариативность,
но все же она ограничена строгими рамками языков моделиро-
вания, то ментальные карты создаются в произвольной форме.
И даже специализированные программы для их создания также
почти не ограничивают человека в процессе моделирования. Т.е.
какие-то правила могут вводиться в рамках определенного про-
граммного продукта, но стандарта не существует. В результате
для понимания модели и заложенных в ней идей требуется при-
сутствие и комментарии ее разработчика (аналитика).
МЕТОДОЛОГИЯ И ЯЗЫКИ БИЗНЕС-

МОДЕЛИРОВАНИЯ
Очень часто даже в профессиональной литературе возника-

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

в конкретном случае оптимальным. В общем, разницу между по-
нятием «программирование» и «программированием в рамках
определенного языка», я думаю, большинство понимают даже
без таких пояснений.
ОТЛИЧИЕ ЯЗЫКОВ РАЗРАБОТКИ БИЗНЕС-

МОДЕЛЕЙ ОТ ЯЗЫКОВ ПРОЕКТИРОВАНИЯ
СИСТЕМ
Существует целое семейство языков проектирования систем,

которые внешне схожи с языками бизнес-моделирования, на-
пример, это Ares Studios, целое семейство языков UML и другие,
которые используются для проектирования IT-систем. Основное
различие этих языков от языков разработки бизнес-процессов
лежит в их предназначении.
Если языки проектирования IT-систем рассматривают биз-
нес-процессы с точки зрения возможности их автоматизации,
воплощении в IT-системах, то языки бизнес-моделирования рас-
сматривают последовательность действий именно с точки зре-
ния бизнеса, включая работу как IT-систем, так и сотрудников,
движения товаров и т. д.
Соответственно, в языках проектирования систем нет эле-
ментов, которые помогут полноценно описать действия подраз-
делений, сотрудников, взаимодействие между ними, работу
с поставщиками, общение с клиентами и так далее. Инструмен-
ты этой группы языков помогут именно автоматизировать про-
цессы бизнеса, которые поддаются автоматизации. А все
остальное будет оставлено «за кадром», например, как некие
«функции» без расшифровки.
В то же время языки разработки бизнес-процессов охваты-
вают максимально именно работу бизнеса как такового, а вот те
или иные нюансы автоматизации и алгоритмизации систем
в них описать далеко не всегда возможно с достаточной степе-
нью детализации.
13
ПРЕИМУЩЕСТВА РАЗРАБОТКИ МОДЕЛЕЙ

БИЗНЕСА
И все же, зачем применять языки бизнес-моделирования,

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

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

будут «подсказывать» перечень возможных и необходимых дей-
ствий. А в случае создания исполняемых моделей или неисполняе-
мых, но в строгих рамках правил, всегда можно проверить работу
бизнес-модели в исполняемой среде и провести отладку, как при
программировании.
ПРИМЕНЕНИЕ МОДЕЛЕЙ БИЗНЕСА

НА ПРАКТИКЕ
Лично я считаю, что бизнес-моделирование стоит применять

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

в процессе взаимодействия с клиентами. Проекты у меня часто
бывают сложными, и обычного текста или устной речи бывает
недостаточно для понимания, в то время как использование на-
глядных бизнес-моделей снижает затраты времени клиента
на чтение и понимание моих предложений, и практически ис-
ключает проблемы взаимопонимания в этом вопросе.
И если несколько лет назад я еще сталкивался с недоумени-
ем со стороны клиентов, то сейчас вариант описания «на сло-
вах» без наглядных и удобных схем практикуется крайне редко.
А в случае автоматизации какого-либо этапа работы или созда-
ния автоматизированной системы управления бизнесом на ос-
нове проектно-ориентированного подхода качественная бизнес-
модель, выполненная в том или ином языке моделирования, ста-
нет готовым руководством для технических специалистов.
Удобство, универсальность, простота восприятия — это те
причины, по которым от словесных описаний в бизнес-сфере
все больше переходят к бизнес-моделированию. А применение
готовых языков позволяет работать с моделями быстро, избегать
ошибок, и также без проблем вносить любые изменения.
15
ЧТО ТАКОЕ БИЗНЕС-ПРОЦЕСС
И ОПИСАНИЕ БИЗНЕС-ПРОЦЕССА
О бизнес-процессах говорят много и часто преимуществен-
но в связи с автоматизацией бизнеса. Использую этот термин
и я, в том числе, в своих публикациях, посвященных CRM-систе-
мам, ERP, работе с BPMN-нотациями, IDEF0 и описанию других
инструментов, которые могут понадобиться в работе бизнес-
консультанта и внедрении систем автоматизации. При этом в Ру-
нете понятное и развернутое определение термина «бизнес-
процесс» я до сих пор не нашел.
Многие авторы используют его «по умолчанию», как термин
«интуитивно понятный» без расшифровки, либо вообще вносят
дополнительную путаницу использованием альтернативной тер-
минологии, например, пишут вместо бизнес-процесса «бизнес
сущность» и т. д.
В этой главе я решил поговорить о том, что такое бизнес-
процесс, рассказать об истории появления этого понятия
и о том, где его можно и нужно применять.
ОПРЕДЕЛЕНИЕ БИЗНЕС-ПРОЦЕССА
Итак, в чем же разница между бизнес-процессом и функций

или даже просто обычным процессом? В чем разница между
этими терминами? Я пришел к следующему выводу:
Бизнес-процесс — это логическая последовательность действий че-
ловека (или нескольких человек) в коллективе. Цель описания бизнес-
процесса — анализ и регламентация тех или иных действий в кол-
лективе.
Почему я делаю особый упор на людях и коллективе:
16
— Бизнес-процесс всегда происходит с участием человека. Если

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

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

структуре или компании? Потому что понятие бизнес-процесса
может быть использовано, в том числе, для некоммерческой ор-
ганизации. Это может быть благотворительность, выезд скорой
помощи к пациенту или даже организация званого ужина без
каких-либо продаж и получения прибыли. При этом также мож-
но описывать бизнес-процесс, так как у нас есть люди, которые
выполняют какие-то действия для получения определенного ре-
зультата.
ОПИСАНИЕ БИЗНЕС ПРОЦЕССА
Также важно дать определение описанию бизнес процесса:

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

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

ли вы описываете «то, что есть», все равно допускаются некото-
рые неточности, «сглаживаются» углы, какие-то действия упуска-
ются для простоты восприятия. А если описывается «то, что
должно быть», то здесь на основе существующего создается
нечто новое. При этом бизнес-аналитик все же ограничен стро-
гими рамками — правил, синтаксиса, логических ограничений.
Лично я сравниваю создание нового бизнес-процесса с ба-
лансированием на тонкой нити гармоничного сочетания творче-
ства, искусства и строгой математики.
При этом нужно понимать, что ни один бизнес-процесс
не может быть совершенным и на 100% соответствовать реаль-
ности. Всегда есть место каким-то упрощениям и допущениям,
где-то при реализации даже самого строгого регламента свои
коррективы вносит человеческий фактор.
Кроме того, как известно, в любой новой сущности всегда
заложена возможность дальнейшего совершенствования. И со-
здание бизнес-процессов также подтверждает этот философ-
ский тезис. Как бы вы ни старались описать бизнес-процесс иде-
ально, все равно в нем найдется что-то такое, что также можно
улучшить либо сейчас, либо — в будущем.
И здесь очень важно с одной стороны, вовремя остано-
виться самому, ведь обновленные бизнес-процессы будут реа-
лизовывать реальные люди, которые привыкли работать
«по старинке», и нужно учитывать их косность мышления и сте-
пень обучаемости. Также и автоматизация, которая обычно
входит в модернизацию бизнес-процессов, требует определен-
ных вложений. И здесь нужно исходить из реальных возмож-
ностей заказчика.
Все это бизнес-консультант должен четко понимать сам,
знать, где и на каком уровне допущений он упростил описание
бизнес-процесса, а где решил отложить на будущее какие-то ре-
шения по объективным причинам (финансы, человеческий фак-
тор). И все это нужно уметь просто и понятно объяснить руково-
дителю бизнеса.
18
ТЕХНОЛОГИЧЕСКИЙ ПРОЦЕСС И БИЗНЕС-

ПРОЦЕСС
Главное отличие бизнес-процесса от технологического за-

ключается в том, что в технологическом процессе на выходе
предполагается один вполне определенный результат. Напри-
мер, если речь идет о производстве, то на выходе должна полу-
читься продукция с определенными параметрами.
Конечно, даже в технологическом процессе существует ве-
роятность получения брака, но не один из закономерных вари-
антов, а последствия нарушения технологического процесса.
В то время как в бизнес-процессе результат «на выходе» может
отличаться в зависимости от выполнения тех или иных условий
в «теле» бизнес-процесса, который выполнялся без нарушений
и сбоев.
Для наглядности описание технологического процесса мо-
жет выглядеть таким образом:
— Берем заготовку A;
— Соединяем ее с заготовкой B;
— Обрабатываем под параметры C;
— Получаем деталь.
Все однозначно и никаких условных «вилок» не предусмат-

ривается.
В бизнес-процессе вполне нормальной считается следующая
ситуация:
— Получаем вводные данные A:
— Если данные соответствуют условию B, переходим на последова-
тельность действий C;
— Если данные соответствуют условию D, выполняем действия E.
— Полученный результат передается на выход.
Т.е. уже в алгоритме процесса предусмотрены возможные

условия и разные действия, зависящие от исходных или проме-
жуточных данных.
19
ИСТОРИЯ ПОЯВЛЕНИЯ ТЕРМИНА
Я не единожды читал информацию о том, что нотации биз-

нес-процессов (IDEF0) появилось чуть ли ни в середине XIX ве-
ка. Более реалистичные авторы пишут о периоде Второй Миро-
вой войны. Но и они ошибаются.
Например, когда я написал статью об IDEF0, некоторые чи-
татели в качестве примеров нотаций приводили примеры каких-
то инструкций из министерств и ведомств времен Первой Миро-
вой или даже раньше, а в качестве графического отображения
обсуждались схемы и наглядные изображения военных дей-
ствий. Но все это не является описанием бизнес-процесса. Все
вышеперечисленное можно назвать методиками, наглядной де-
монстрацией, инструкциями, но нельзя назвать нотациями.
Нотации — понятие современное, причем, нотациями назы-
вается нечто устоявшееся, стандартизированное, т.е. набор ко-
манд и обозначений, которыми пользуется много людей,
а не одна или две организации. Можно придумать свой особый
язык для описания бизнес-процессов или, например, програм-
мирования. Но пока он не получит «обкатку» в массовом ис-
пользовании, не будут выявлены и устранены противоречия,
неоднозначные трактовки, другие недочеты, пока он не станет
устоявшимся и привычным для людей стандартом, называть его
нотацией нельзя. Подробнее о нотациях я планирую написать
позже. А сейчас вернемся к вопросу появления термина «биз-
нес-процесс».
На самом деле описание бизнес-процессов и нотации BPMN
появились в 70-е годы XX века, когда повсеместно начали ис-
пользоваться информационные системы. И сам термин, и нота-
ции понадобились изначально именно для разработки инфор-
мационный систем.
Дело в том, что после начала применения информационных
систем сложность организации работы людей в организациях
увеличилась во много раз. Кроме того, машины не понимают аб-
стракции, им требуется строгий алгоритм и определенный поря-
20
док введения и обработки информации. Если до начала автома-

тизации, когда информация переходила непосредственно от че-
ловека к человеку, проблема взаимопонимания находилась
на уровне человеческих коммуникаций, то теперь появилась
необходимость ее строго регламентировать.
В результате понадобилось создавать описания работы
не только людей в организации, но также их взаимодействия
с информационными системами. И здесь стало недостаточно
текстовых нотаций (инструкций), где все описания были в сво-
бодной текстовой форме, они оказались не актуальны и неудоб-
ны. Появилась потребность в стандартизации, по сути, в созда-
нии особого языка команд и однозначной последовательности
действий. Причем, в отличие от машинных языков, эти нотации
должны были стать одинаково удобными для перевода в ма-
шинный код, и для восприятия человека.
Первые методологически проработанные нотации бизнес-
процессов (а я буду говорить именно о методологически прора-
ботанных нотациях, например, IDEF3***) появились у военных
в США. Причина очевидна — уже тогда военные в США пользо-
вались автоматизацией с использованием удаленных соедине-
ний, т.е. той самой системой, которая позже стала Интернетом.
И при таком уровне применения информационных систем по-
требность в нотациях бизнес-процессов была особенно актуаль-
ной.
***По теме методологически проработанных нотаций хочу также
сказать пару слов. Почему я привел в качестве примера IDEF3: я еще
не видел более проработанной методологически системы описания
бизнес-процессов. Даже BPMN 2.0 все еще развивается и дорабатыва-
ется. А если вы почитаете англоязычное описание IDEF3 (перевода
на русский я пока не видел), то также сумеете оценить по достоин-
ству глубину его проработки.
Очень быстро методология и нотации завоевали огромную

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

нес, т.е. получить более высокую производительность при тех же
затратах.
Особенно заинтересовала бизнес возможность оптимиза-
ции. Как известно, чтобы что-то улучшить, нужно четко пони-
мать, что вы имеете, и что из этого вы желаете изменить.
И графические нотации наглядно показывали обе ситуации —
отправная точка и желаемый результат, а также наиболее про-
блемные области. На основе этих данных выбрать оптималь-
ный путь решения и смоделировать оптимальный вариант мо-
дернизации оказалось намного проще, чем без столь удобных
инструментов.
Именно тогда появились понятия бизнес-процессов и нота-
ций бизнес-процессов, два неразрывно связанных понятия.
Очень важно понимать, что не существует, например, от-
дельного «бизнес-процесса продажи». Есть процесс продажи,
который станет бизнес-процессом, если его описать при помо-
щи нотации. Т.е. без описания в нотации бизнес-процесса вы
занимаетесь продажами, это никто не оспаривает. Но пока нет
определенного незыблемого и однозначного описания ваши
продажи — явление, в чем-то, стихийное. А бизнес-процессом
они станут только после их описания в рамках нотации и реа-
лизации этого описания на практике.
Продажи — это самый простой и наглядный пример. Каждый
из нас в роли покупателя, а многие, и в роли продавца знакомы
с этим процессом. И все мы знаем, что даже один и тот же чело-
век в разных ситуациях (для разных товаров, разных покупате-
лей, в разную погоду и вообще, в зависимости от настроения)
будет продавать несколько по-разному. Но если описать и четко
регламентировать определенный бизнес-процесс, то независи-
мо от того, «с какой ноги встал утром продавец», процесс прода-
жи будет определенным образом стандартизирован, ограничен
определенными рамками, и, в результате, более стабилен.
22
ЗАЧЕМ МОДЕЛИРОВАТЬ (ОПИСЫВАТЬ) БИЗНЕС-

ПРОЦЕССЫ
Как я уже не единожды писал, я работаю преимущественно

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

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

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

подразделений: бухгалтерия, кадры, отдел продаж, склад, до-
ставка, производство и т. д. Над всем этим стоит один человек —
руководитель бизнеса. Он физически не может на экспертном
уровне понимать все виды процессов в бизнесе. Именно потому
и нанимают различных специалистов. Но ему необходимо эф-
фективно всем этим управлять, а в определенных случаях — мо-
23
дернизировать.
И здесь на помощь приходят бизнес-процессы. При этом
определенные виды человеческой деятельности в рамках ком-
пании описываются графическими нотациями и представляются
в том виде, который помогает руководству понять, как именно
происходит работа на каждом из этапов, и что здесь можно
улучшить. При этом руководителю компании не обязательно об-
ладать высокой квалификацией специалиста того или иного
профиля.
Конечно, на этом уровне не обойтись без некоторых инфор-
мационных потерь. Невозможно описать графической нотацией
все нюансы и подробности работы каждого сотрудника. Но эти
информационные потери оказываются несущественными для
понимания процессов в общем и принятия решения.
РАСПРОСТРАНЕННЫЕ МИФЫ И ЗАБЛУЖДЕНИЯ
Не «изобретайте велосипед»! Не нужно придумывать свои нотации.
Нередко люди вместо того, чтобы изучить особенности су-

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

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

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

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

сать подробнее тот или иной процесс. И я это также считал сво-
им недочетом.
На самом деле, исходя из всего выше описанного, модели-
рование бизнес-процесса — это некоторое допущение, процесс
творческий. С другой стороны, я в свое время не знал даже, что
ответить на просьбы описать еще «это» и «вон то». Но со време-
нем я понял, что бизнес-моделирование — это не просто творче-
ство, но некий диалектический процесс. И уже само создание
бизнес-процесса всегда будет нести в себе собственное отрица-
ние. Здесь действительно стоит подходить к вопросу с философ-
ской точки зрения. И создавая бизнес-процесс, нужно помнить,
что мы не можем охватить все и сразу, а потому он всегда будет
несовершенен. Но при этом мы уже закладываем в него то, что
будем совершенствовать в будущем. Стоит к этому подходить
просто как к факту.
Ваш бизнес-процесс должен решать поставленную задачу,
отвечать на тот вопрос, который рассматривается в рамках про-
екта. Все остальное — вопрос будущего возможного сотрудниче-
ства. Именно так и стоит пояснять заказчикам, почему вы не де-
тализируете какие-то процессы или не рисуете еще какой-то
бизнес-процесс, связанный с обсуждаемым.
26
БИЗНЕС ПРОЦЕССЫ — ЭТО
НЕ ТОЛЬКО ПРО БИЗНЕС
Я не устаю повторять, что применение бизнес-процессов
не ограничивается бизнес-сферой. На самом деле, слово «биз-
нес» здесь — не более, чем устоявшаяся терминология. Успешно
применять бизнес-процессы можно практически в любой сфере
деятельности, где используется коллективный труд. Об этом я го-
ворил в главе «Что такое бизнес процесс», повторяю этот тезис
и в других публикациях. Но этот момент я считаю настолько
важным, что выделил в отдельную небольшую главу.
Бизнес-процессы можно применять в любой сфере, где вам
требуется автоматизация и, что еще важнее, регламентация дея-
тельности. Если вы понимаете, что на каких-то этапах вы и ваш
коллектив работаете недостаточно эффективно, хотите улучшить
показатели, без регламентации не обойтись. И здесь на помощь
приходит моделирование бизнес-процессов.
Вы можете применять бизнес-процессы для улучшения ра-
боты и автоматизации:
— государственных учреждений, в том числе, медицинских, центров
выдачи документов и т. д.
— благотворительных организаций любого профиля;
— общественных организаций и т. д.
Бизнес-процессы можно и нужно применять везде, где тре-

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

так сложилось.
В английском языке под словом «бизнес» подразумевается
не только коммерческая деятельность. В данном случае стоило
перевести его как «дело» или даже «труд». И тогда термин зву-
чал бы намного точнее — «трудовые процессы», т.е. любая дея-
тельность, которую можно описать процессами, независимо
от того, будет ли она в итоге приносить прибыль. Но сложилось
уже так, как сложилось. А потому приходится повторять, бизнес-
процессы — это не только про бизнес. Используйте их везде, где
увидите смысл. Не бойтесь терминов и не ограничивайте себя
жесткими рамками.
28
ДЕКОМПОЗИЦИЯ ИЛИ
ПОДПРОЦЕСС?
Нередко даже в профессиональной среде путают два поня-
тия — декомпозиция и подпроцесс. На самом деле, это далеко
не одно и то же. И важно понимать разницу между этими двумя
терминами.
ДЕКОМПОЗИЦИЯ
Декомпозиция — это разложение задачи на более простые

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

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

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

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

не перегружать диаграмму на высоком уровне подробностями,
что облегчает ее восприятие. С другой, при работе с подпроцес-
сами система BPMN поможет вам избежать ошибок, так как вы
работаете внутри нотации, а не с отдельной диаграммой. Важно
понимать что подпроцесс используется для исполняемых про-
цессов, для неисполняемых процессов я не рекомендую исполь-
зовать. Лучше используйте декомпозицию, так как подпроцесс
сложнее к восприятию.
31
РАЗБИРАЕМСЯ С ПОНЯТИЕМ BPM.
ЧТО ТАКОЕ УПРАВЛЕНИЕ БИЗНЕС
ПРОЦЕССАМИ
В современных условиях бизнес активно применяет про-
цессный подход к организации работы. Но до сих пор существу-
ет проблема понимания — что такое управление бизнес-процес-
сами и как правильно использовать BPM.
Определение по версии EABPM (Европейская ассоциация
BPM) этого термина звучит следующим образом:
Управление бизнес-процессами (BPM) представляет собой систем-
ный подход для отражения, проектирования, выполнения, докумен-
тирования, измерения, мониторинга и контроля как автоматизиро-
ванных, так и неавтоматизированных процессов, для достижения
целей и бизнес-стратегий компании. BPM охватывает осознанное,
всеобъемлющее и все более технологичное определение, совершен-
ствование, инновации и поддержание сквозных процессов. Благодаря
этому системному и сознательному управлению процессами компа-
нии добиваются лучших результатов быстрее и гибче.
Я считаю, что это определение вносит больше путаницы, чем

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

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

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

и значительная часть подобных инструкций пылились на полках,
зачастую, никем, кроме создателя, не прочитанные. А опыт
и требования передавались от опытного сотрудника новичку.
А что делать, если появляется необходимость быстро изме-
нить работу целой организации? А если еще при этом внедряет-
ся автоматизация? Ответом на эти запросы и стало появле-
ние BPM.
ОБ УПРАВЛЕНИИ БИЗНЕС-ПРОЦЕССАМИ
ПРОСТЫМИ СЛОВАМИ
Управление бизнес-процессами заключается в том, что вы

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

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

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

уметь описывать по-отдельности, после чего объединять в об-
щую систему.
Необходимо исходить из понимания: процессный подход —
это управление целым через управление частями.
И чтобы исключить путаницу в терминологии, поясню:
— BPM (Business Process Management) — это методология. т.е. набор
основных принципов и подходов к построению нотаций и самой ор-
ганизации работы при помощи бизнес-процессов.
— BPMN (Business Process Model and Notation) — нотация (язык),

в которой строятся нотации, в том числе, исполняемые.
— BPMS (Business Process Management System) — IT система испол-

нения, построенная по определенным правилам, заданных в мето-
дологии.
Если проводить аналогию с наукой, то BPM — это прежде

всего подход, своего рода мировоззрение. BPMN — это методы
и алгоритмы решения конкретных задач. Например, доказа-
тельства для теорем или набор методов для создания проекта
обеспечения электричеством объекта (производства, много-
квартирного дома). А, в свою очередь, BPMS- это уже готовые
прикладные решения, которые можно «включить» и они уже
будут работать. Для математики это — готовые решения задач,
имеющих практическое значение. Для физики — непосред-
ственное реализации той самой электропроводки и подключе-
ние объектов. Для сферы айти — готовый программный код.
ИСПОЛНЯЕМЫЕ И НЕИСПОЛНЯЕМЫЕ БИЗНЕС

ПРОЦЕССЫ
Нотации бизнес-процессов могут быть исполняемые и неис-

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

нотаций. При этом пользуемся правилами написания BPMS. Для
того, чтобы создать нотацию неисполняемую, в принципе, мож-
но воспользоваться даже листом ватмана и карандашом. Глав-
ное, четко соблюдать все правила.
Для исполняемой нотации требуется определенная IT-сре-
да — BPMS. При этом даже неисполняемые я рекомендую вы-
полнять в BPMN, так как здесь сама среда помогает выявлять
возможные ошибки, противоречия, что повышает грамотность
и точность описания бизнес-процесса.
ОПИСАНИЕ РАБОТЫ С BPM
Для лучшего понимания того, что такое BPM (управление

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

ных. На этом этапе аналитик получает описание бизнес-процесса
«как есть».
— Изучение полученного бизнес-процесса с точки зрения слабых

мест и возможности оптимизации.
— На основе готовой оптимизированной (по мере необходимости)

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

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

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

ных системах. И новый этап внедрения в эксплуатацию.
ЖИЗНЕННЫЙ ЦИКЛ ПРОЦЕССА В BPM
Как видно из описанной выше последовательности, каждый

бизнес-процесс проходит определенный цикл от создания
до внедрения. Далее какой-то период времени он работает «как
есть». После чего практика показывает определенные недостат-
ки и недочеты, аналитик изучает отчетность и со своей стороны
находит какие-то «слабые места». Процесс подвергается модер-
низации.
Этот цикл может повторяться бесконечное число раз. Любой
бизнес, любая организация — не застывший монолит, а развива-
ющийся организм в постоянно изменяющемся окружении. Меня-
ются особенности законодательства, приходят и уходят с рынка
конкуренты, появляются новые инструменты автоматизации
и т. д.
Главное правило: при оптимизации процесса нужно уметь
вовремя остановиться. И здесь необходимо четко анализиро-
вать — трудоемкость (стоимость) изменений и повышение эф-
фективности (выгоды) в результате.
ПЛЮСЫ И МИНУСЫ BPM
К числу преимуществ использования BPM относятся:

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

ности процессов в компании и увидеть их слабые места.
— Нотации прекрасно подходят в качестве инструкции исполнителю,

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

процесса будет стандартизирован и соответствовать ожидаемому.
Это позволит снизить влияние человеческого фактора на уровень
сервиса или выполнения любых других видов работы.
— Методология BPM — прекрасно проработана и стандартизирована

благодаря BPMN. При этом инструменты (нотации BPMN) интуитивно
понятны даже для людей, не изучавших управление бизнес-процес-
сами вообще. С другой стороны, наличие стандартов и правил поз-
воляет избегать ошибок при разработке и создавать в системе BPMS
исполняемые нотации (готовые элементы автоматизации бизнеса).
Минусы BPM, как это часто бывает, находятся там же, где
и преимущества:
— Высокая степень детализации процессов мешает восприятию ра-
боты бизнеса для стратегического планирования.
— На людях, которые разрабатывают процессную модель, лежит

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

ровкам «изнутри». Исполнитель получает четкую последователь-
ность действий и уже не может проявить инициативу. В результате,
любую ошибку исполнители будут повторять из раза в раз, пока она
не будет исправлена в самом бизнес-процессе.
38
КАКИМ КОМПАНИЯМ ПОДХОДИТ BPM
Процессный подход идеально подойдет государственным

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

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

а также описание нотаций BPMS. О них я писал в этой статье,
и подробно — в предыдущих статьях. Кроме того, не так давно
появились новые понятия — DMN и CMMN. На них я сейчас по-
дробно останавливаться не буду. Постараюсь описать новые
понятия и их особенности в будущих публикациях.
Зачем нужно в построении нотаций столько сложностей и разные
подходы?
Управление бизнес-процессами и сама методология BPM

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

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

автоматизации (в IT сфере есть свои инструменты), а для орга-
низации работы компании или любого коллектива. Здесь могут
учитываться участки работы с применением автоматизирован-
ных систем. А могут рассматриваться исключительно процессы
в коллективе, причем, любом — от строительных бригад или
производства до творческих коллективов в театре или филармо-
нии. Главное, четко описать — как происходит интересующий
вас процесс, а также, как вы его хотите изменить.
40
ЧТО ТАКОЕ BPMS
В прошлой главе мы разобрались в общем с методологией
BPM, пришло время заняться изучением инструментов, в рамках
которых реализуется эта методология. Понятие BPMS-системы
традиционно вызывает множество вопросов. Зачем они нужны?
Как они работают? В чем их принципиальное отличие от других
вариантов автоматизации бизнеса?
Когда я впервые столкнулся с BPMS, у меня также возникли
все перечисленные выше вопросы. Я далеко не сразу понял, за-
чем нужен новый инструмент, почему нельзя реализовать все
необходимые для успешной работы бизнес-процессы в уже име-
ющихся системах учета или CRM, и в чем принципиальное отли-
чие BPMS от других вариантов автоматизации бизнес-процес-
сов. Во всех этих нюансах мы сейчас и будем разбираться.
ЧТО ТАКОЕ BPMS?
BPMS — еще одна аббревиатура из разряда ERP, CRM, кото-

рая не имеет четкого определения. Хотя определений достаточ-
но много: и зарубежных, и российских. Кроме того, компании,
которые выпускают собственные BPM-системы, также дают свои,
особые определения, что вносит дополнительную путаницу.
К тому же нередко BPMS объединяют с другими системами (на-
пример, BPMS+CRM, BPMS+ERP) и тогда разработчики дают
определение BPM-системы, исходя уже из этого контекста.
Для того, чтобы разобраться, что такое на самом деле BPMS,
и в чем заключаются их особенности, напомню еще раз, что та-
кое BPM.
BPM (англ. Business Process Management, управление бизнес-процесса-
ми) — концепция процессного управления организацией, рассматри-
41
вающая бизнес-процессы как особые ресурсы предприятия, непре-

рывно адаптируемые к постоянным изменениям, и полагающаяся
на такие принципы, как понятность и видимость бизнес-процессов
в организации за счёт моделирования бизнес-процессов с использо-
ванием формальных нотаций, использования программного обеспе-
чения моделирования, симуляции, мониторинга и анализа бизнес-
процессов, возможность динамического перестроения моделей биз-
нес-процессов силами участников и средствами программных си-
стем. © Википедия.
BPMS (англ. Business Process Management System) — это

в первую очередь программное обеспечение для поддержки
концепции BPM в компании. BPMS-системы нужны для того, что-
бы реализовывать в программной среде концепцию BPM.
BPMS рассматривает работу компании как набор процессов,
а не как набор функций. Объектом BPM-системы является не ра-
бота отдела продаж или закупок, а процесс продажи, процесс
поддержки клиентов, процесс управления снабжением
и т. д. И уже исходя из этого понимания, строится работа по ре-
инжинирингу бизнес-процессов в BPMS.
BPM-cистема направлена, главным образом, на совершен-
ствование работы компании, на более прибыльную деятельность
предприятия путем оптимизации и контроля бизнес-процессов.
РАБОТА ПОЛЬЗОВАТЕЛЕЙ В BPMS И ДРУГИХ

СИСТЕМАХ
Для лучшего понимания сути BPMS, нужно понять, как обык-

новенные системы (ERP-системы, CRM) подходят к работе поль-
зователей. Например, пользователю необходимо составить за-
каз клиента. Каковы его действия?
Пользователь может заполнять документ произвольно, если
не запрограммирована последовательность его работы:
Может сначала открыть форму заказа, подобрать товары,
указать цены, потом определить клиента.
Может сначала создать клиента, потом — его заказ.
Одним словом, в действиях пользователя есть вариатив-
42
ность, т.е. сотрудник, исходя из ситуации, может выбирать соб-

ственные варианты действия.
BPM-система рассматривает пользователя как еще один
кирпичик в системе. Человек должен четко знать, в каком про-
цессе он работает и что он должен делать.
Сотрудники в BPM-системе рассматриваются не с точки зре-
ния результата процесса, а с точки зрения выполнения действия.
Вариативность действия пользователя здесь исключается. Со-
трудник делает только то, что запрограммировано в системе, ни
больше, ни меньше.
СПОСОБЫ РЕАЛИЗАЦИИ БИЗНЕС-ПРОЦЕССОВ
BPMS — это один из способов реализации бизнес-процесса.

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

— «Бумажный» подход;
— Автоматизированный подход (с применением других систем);
— Процессный подход в системе BPMS.
Для примера возьмем бизнес-процесс согласования счета

на оплату, так как он достаточно простой и наглядный.
В моей практике был такой случай: клиент мне оплатил пол-
ностью счет, хотя на тот момент должен были внести только
часть оплаты в размере 50%. Почему это произошло?
Потому что у них в компании не было процедуры согласова-
ния счета. Узнали мы с директором компании об этом совершен-
но случайно. Я узнал, что в их компании на этапе согласования
счета происходят периодические сбои, а директор с удивлением
обнаружил, что он оплатил не 50% счета, как планировал, а сра-
зу 100%.
Почему так случилось? Все просто. Сработал, так называе-
мый, «испорченный телефон». Специалист принес с бухгалтерию
43
счет к оплате с фразой «Надо оплатить 50% от суммы». Бухгал-

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

нии?
Сотрудник получает счет, передает его в бухгалтерию;
Бухгалтерия вписывает счет в платежную ведомость, согласовы-
вает ее с руководителем;
Если руководитель одобряет и подписывает запрос, бухгалтерия
оплачивает счет.
Чем плох этот подход? Здесь размыты границы перехода
зон ответственности между этапами. В случае недоразумения
и не своевременной оплаты или неоплаты счета сотрудники пе-
рекладывают вину друг на друга, и невозможно в итоге найти
ответственных.
Автоматизированный подход
Как правило, компании стараются контролировать тот или

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

ные этапы согласования.
Как это выглядело:

1. В системе назначаются ответственные лица за согласование рас-
ходов;
2. На основании какого-либо документа (заказа поставщику, поступ-
ления товаров или другого документа) создается документ Заявка
на расходование денежных средств в статусе Не согласовано;
3. Если ответственный согласовал заявку и поменял статус на Согла-
совано, то счет направлялся в бухгалтерию;
4. Если ставился статус Отклонено, значит, заявка уходила обратно
к лицу, инициировавшему процесс.
В этой компании ответственным за согласование расходов

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

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

мента:
— деньги (сколько мы должны выплатить);
— получатель (кому мы должны выплатить);
— назначение (за что выплачиваем).
45
А, значит, заполняя лишнюю информацию, сотрудник теряет

время, и процесс согласования затягивается.
К тому же, такая реализации согласования в учетной систе-
ме достаточно примитивна и не предполагает вариативности
(например, разделение зон ответственности в зависимости
от суммы документа или статьи расходов).
В BPM-системе, все-таки, важен сам процесс согласования,
а не отражение информации для будущей отчетности
и т. п. Здесь просто есть люди, которым нужно, исходя из контек-
ста информации, быстро исполнить процесс.
Итак, основные отличия ведения бизнес-процессов в BPMS
от учетной системы:
1. В BPMS важно именно то, что делается. Здесь важна не учетная
информация, не отчетность, а необходимость быстро принять реше-
ние, чтобы бизнес-процесс продвинулся дальше. С учетной системой
так не получится, здесь мы должны указывать, какие документы
за счет каких создаются и т. п. — это неудобно. Здесь нет четкого
контекста.
2. Простота логики и разработки. Если мы ведем бизнес-процесс
в учетной системе, то должны учитывать большое количество логи-
ческих связей: как проводятся документы, транзакции, на что это
влияет, какие дополнительные лицензии надо покупать и т. п. — хотя,
казалось бы, ответственному за согласование лицу это не нужно.
Но в учетной системе мы обязательно должны привязываться к объ-
ектам конфигурации либо дорабатывать их, что не очень правильно.
Вот как раз для этого и были созданы BPM-системы, в кото-

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

процесс на последовательные этапы.
В нашем примере их будет три:
46
1. Создание заявки на согласование счета;

2. Проверка заявки;
3. Результат заявки:
— если одобрено — распечатка заявки,
— если не одобрено — сообщить об этом поставщику
Далее проектируем условия, при каких событиях или атри-

бутах происходят те или иные действия (например, можно отра-
зить зависимость ответственного от суммы счета, если на пред-
приятии разные суммы согласовывают разные сотрудники; или
отправка оповещений на том или ином этапе работы).
В системе каждый пользователь работает под своим логи-
ном и паролем и видит только свою форму и свое место в биз-
нес-процессе. В нашем примере за создание заявки ответстве-
нен сотрудник, а за проверку и согласование — руководитель,
и каждый из них видит только свои формы, свои задачи и может
выполнять только свои действия.
Соответственно, если сотрудник, создавший заявку, нажал
перехода на следующий этап, то с него ответственность снима-
ется и переходит к руководителю, который должен проверить
заявку. Этим мы добиваемся разделения и контроля зон ответ-
ственности.
На этом примере наглядно видно, что, в BPM-системах все зави-
сит от контекста. Все взаимодействия форм направлены на то,
чтобы пользователь видел только то, что нужно и только то, что
ему необходимо на конкретном этапе, исходя из контекста про-
цесса.
Если другие системы направлены на то, чтобы операция бы-
ла выполнена, то в BPMS мы сконцентрированы на действиях.
BPM-систему можно сравнить с японской техникой стрельбы
из лука Юми. В школах стрельбы из юми проповедуют следую-
щий подход: если вы хотите попасть, не нужно концентриро-
ваться на цели, нужно делать правильно каждое действие сей-
час. Т.е. здесь используется принцип, который применяют в уже
упомянутой мною японской стрельбе из лука Юми: сосредоточь-
тесь на каждом действии, на каждом этапе, качественно выпол-
47
няйте каждое действие. И тогда вы обязательно придете к цели!

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

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

нес-процесса и люди, знакомые с этой нотацией, сразу поймут
модель бизнес-процесса, написанную в этом формате.
Я надеюсь, что сумел внести ясность в вопрос, что такое
BPM-система и зачем она нужна путем сравнения процессного
подхода с другими вариантами работы. В следующих главах я
покажу, как применять процессный подход в процессе автома-
тизации бизнеса и внедрении программного обеспечения.
49
ИСПОЛЬЗОВАНИЕ ПРОЦЕССНОГО
ПОДХОДА. РАЗРАБОТКА ПО
По роду своей деятельности я постоянно сталкиваюсь с про-
ектной работой. И на старте любого проекта возникает трудная
задача грамотного планирования. Почему это так важно? Хоро-
ший план — это практически половина успеха. Без планирова-
ния практически невозможно выстроить работу четко, слаженно,
добиться поставленных целей и уложиться в оговоренные сроки.
Особенно это важно, если речь идет о командной работе.
В принципе, о важности планирования написано очень
много. И я здесь не буду повторять всем известные истины. Все
просто: если вы знаете, куда вам нужно прийти и сумеете про-
ложить верный маршрут, вы достигните цели. Если нет — увы,
никто не сможет заранее угадать, куда вы в итоге придете.
«ПОДВОДНЫЕ КАМНИ» ПЛАНИРОВАНИЯ

В СФЕРЕ IT
Любой план достижения цели должен учитывать такие фак-

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

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

не сталкивались со строительством, вы видели много домов,
в том числе, в процессе стройки. Результат — материален, как
и внешние факторы. Потому выбор решения и составление пла-
на редко вызывают сложности.
При работе с компьютерными информационными системами
вы сталкиваетесь с проблемой отсутствия материальных факто-
ров и результата. Здесь не получится, как, например, при выбо-
ре фундамента для дома, опираться на однозначные исходные
данные и законы физики. Кроме того, внедрение каждого про-
граммного продукта — это уникальный проект.
Каждый коллектив, как и каждый человек, по-своему уни-
кальны. И них всегда есть свои, особые потребности и пожела-
ния. Разработку и внедрение программного обеспечения для
того и заказывают, чтобы получить решение «под себя», когда
существующих типовых программ оказывается недостаточно.
При планировании проекта в сфере IT необходимо:
— Изучить особенности и потребности заказчика;
— Четко понять поставленную задачу и учесть пожелания;
— Согласовать с заказчиком выбранные решения.
И только после этого можно переходить к составлению пла-

на действий. При этом заказчиком может выступать любой чело-
век, коммерческая или некоммерческая организация. Главное,
что всегда есть тот, кто заказывает проект и будет им в будущем
пользоваться.
Практика показывает, что как раз подготовительная работа
с заказчиком часто вызывает сложности. И здесь на помощь мо-
жет прийти подход, основанный на определении:
Компьютерная информационная система — это идея, выраженная
посредством языка программирования.
51
ИДЕЯ И ВЫБОР ПРОГРАММНЫХ ПРОДУКТОВ
Первое и наиболее очевидное, что нужно понимать: чтобы

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

ния идеи проекта очень полезными оказываются, так называе-
мые, BPM схемы. Иначе говоря, графические нотации описания
бизнес-процессов.
Для описания бизнеса или выполнения какой-либо задачи
могут применяться два подхода — процессный и функциональ-
ный. Об их отличиях и особенностях я мы с вами говорили в гла-
ве «Моделирование бизнеса. Основные подходы».
При поиске решения (формулировке самой идеи) многие
предпочитают функциональный вариант моделирования. Он по-
могает для себя понять суть задачи и необходимые для ее реше-
ния инструменты. А для эффективного решения поставленной
задачи и составления плана работ, как показывает мой личный
опыт, оптимально подходит процессное моделирование.
Как это делают:
— Создается графическая нотация (описание) бизнес процесса. Я ре-
комендую использовать формат BPMN 2 как наиболее продвинутый
и проработанный инструмент, применение которого снижает вероят-
ность ошибок и неоднозначных решений.
— Идею, выраженную в виде BPMN нотации, обсуждают с заинтере-

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

либо принимают решение о написании программного продукта с ну-
ля.
52
— Составляется план работ с учетом выбранных инструментов, ре-

шений, подробно разработанной идеи (BPMN нотации).
КАК СОЗДАЕТСЯ BPMN МОДЕЛЬ
Для успешного составления BPMN нотации человек должен

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

граммирования. Это необходимо, чтобы ставить корректные и реа-
листичные требования к программным системам.
— Иметь навыки работы с графическими нотациями. Этот формат,

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

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

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

и взаимодействия подразделений. Здесь важно понимать: гра-
фическая модель помогает увидеть многие «шероховатости»,
ненужное дублирование функций и т. д. И, конечно, при форму-
лировании идеи в виде нотации, можно и нужно обсудить эти
недостатки рабочего процесса и продумать, как их оптимизиро-
вать.
ВЫБОР ПРОГРАММНОГО ПРОДУКТА
У вас уже есть согласованная и детализированная идея, во-

площенная в виде графической нотации. Что очень важно —
нотация прошла все обсуждения, руководство компании подпи-
сало окончательный вариант. Можно с уверенностью в достиг-
нутом взаимопонимании приступать к выбору или созданию
программного продукта.
В наше время для коммерческих и некоммерческих органи-
заций крайне редко приходится писать программные решения
«с нуля». Это дорого и долго. Тем более, что для большинства
идей существуют готовые (типовые) решения, которые достаточ-
но настроить и/или немного доработать.
И здесь очень важно из всех подходящих по тематике
и функциональности программных систем нужно выбрать ту,
идея которой максимально соответствует идее заказчика.
Например, идея звучит так: «нужна автоматизация работы
отдела продаж».
— Этап 1. Для реализации лучше всего подходит CRM-система. Эти
программные решения разрабатываются специально для отделов
продаж.
— Этап 2. Из всех существующих CRM нужно выбрать те, функцио-

нал которых максимально подходит под выбранный алгоритм рабо-
ты (реализацию идею).
— Этап 3. Выбор из составленного списка подходящих CRM заклю-

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

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

являются неотъемлемой частью процесса. И если они не примут
выбранное решение, то программный продукт при всех его до-
стоинствах с точки зрения разработчиков, окажется неподходя-
щим для реализации идеи.
Более того, описание бизнес-процесса (воплощения идеи) —
это, прежде всего, описание деятельности людей. Идеи относят-
ся к человеческой деятельности. Автоматизация здесь только
вспомогательный фактор. А потому любое описание бизнес-про-
цессов — это, прежде всего, описание работы людей. И только
потом — техническая часть вопроса.
К сожалению, я на практике встречался с ошибочным подхо-
дом, когда BPMN нотация полностью посвящена технической ча-
сти и, по сути, является альтернативным вариантом написания
алгоритма для программистов. В этом случае люди и их взаимо-
действие с программными решениями оказываются «за кад-
ром». И при внедрении решения на практике часто возникают
накладки и недоразумения. В результате идея реализуется дол-
го, сложно. Или оказывается провальной. Просто потому, что при
ее описании забыли о важнейшем факторе — действиях людей.
55
ЧТО ТАКОЕ НОТАЦИИ БИЗНЕС
ПРОЦЕССОВ
Сегодня мне даже сложно представить, что я когда-то
не пользовался нотациями. Я применяю их практически всюду:
при изучении организации работы компании, при выборе
и внедрении программных систем, в начале работы над новым
проектом. Даже при написании статей я периодически сначала
создаю нотацию, а потом на ее основе пишу текст. Также было
и с этой книгой, по крайней мере, при работе с основной струк-
турой и написании некоторых глав.
Но при встрече с новым клиентом мне очень часто приходит-
ся пояснять, что такое нотации и зачем они нужны. Практически
всегда поначалу графическая нотация вызывает некоторое недо-
умение, потом, в процессе обсуждение, приходит понимание
и принятие преимуществ такого подхода. В этой главе я решил
подвести своеобразный итог этих многочисленных обсуждений,
и собрать все «за», «против» и «почему» воедино. Я надеюсь, что
после изучения этого материала у вас не возникнет вопросов, по-
чему нужно пользоваться нотациями, и какие из них подходят
для ваших целей.
ЦЕЛИ МОДЕЛИРОВАНИЯ
При взаимодействии заказчика с исполнителем важнейшая

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

чески не возникает.
ГРАФИКА ПРОТИВ ТЕКСТА
На начальном этапе сотрудничества у меня нередко клиенты

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

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

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

ния: от и до.
Можно возразить, что текст дает больше возможностей, ведь

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

из 200 или 300 страниц. Честно говоря, я с трудом представляю,
как можно в голове «связать» такой объем информации. А ведь
это не художественная литература, здесь каждая страница со-
держит огромное количество технической информации. А ведь
ее нужно не просто изучить и понять, но еще и обсудить, а ино-
гда и «защитить» идею. Графическая нотация в этом случае явно
выигрывает.
Но есть у графики и недостатки. Здесь нет возможности по-
дробно и развернуто описать все нюансы решения. Часть про-
цессов придется оставлять без детализации, от описания дру-
гих — отказываться, так они «уводят» в сторону от основного
процесса.
КАКИЕ БЫВАЮТ НОТАЦИИ
Подробно о видах нотаций я написал в главе «Моделирова-

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

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

зданы специальные языки — IDEF0, IDEF3, BPMN, UML, ARIS
и многие другие.
Нередко мне задают вопрос, почему я не использую отече-
ственные разработки. Дело в том, что в России графическое мо-
делирование практически не развивалось. Существует две си-
стемы — сетевой график и «дракон». Но, к сожалению, они
не столь популярны и не так хорошо документированы, как
IDEF0 или BPM.
ВЫБОР ЯЗЫКА МОДЕЛИРОВАНИЯ
Язык графических нотаций выбирают с точки зрения вы-

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

Впрочем, я лично рекомендую придерживаться IDEF00,
IDEF03, BPMN. Просто потому, что они наиболее развиты и попу-
лярны. Инструменты проверены на практике, синтаксис в них
развит и стандартизирован. Это снижает вероятность ошибок
или отсутствия нужного инструмента. Кроме того, в случае со-
здания исполняемых нотаций, т.е. при автоматизации процессов,
намного легче будет найти разработчика, который также работа-
ет с этими инструментами.
В любом случае, нотацию нужно выбирать под задачу,
а не наоборот.
В КАКОМ ПОРЯДКЕ МОДЕЛИРОВАТЬ
Для начала вспомним бессмертную истину — «нельзя объять

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

дель, после чего демонстрируете ее тем людям, у которых брали
интервью. В результате обсуждения и уточнений модель коррек-
тируется. Этот этап завершается только тогда, когда все обсуж-
дения пройдены, а сама модель утверждена заказчиком.
И последний этап — текстовые пояснения. Любая графиче-
ская модель, как я уже писал, ограничена определенными рам-
ками и несколько абстрактна. Обойти эти рамки и донести суть
модели поможет текст, где будут описаны все подробности каж-
дого действия.
Например, в графической нотации присутствует элемент
«заказ поставщику». Большей детализации графика не позволя-
ет. В текстовом пояснении нужно подробно перечислить все по-
ля этого заказа, другие дополнительные данные, которые будут
присутствовать в документе. Такой документ-сопровождение
может называться отчетом, пояснительной запиской или т. д.
НАСКОЛЬКО ВАЖНО ЗНАТЬ СФЕРУ

ДЕЯТЕЛЬНОСТИ ПРИ МОДЕЛИРОВАНИИ
Этот вопрос я слышу очень часто. И суть его заключается

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

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

шение для достижения взаимопонимания между заказчиком
и подрядчиком. В процессе моделирования принимают участие
сотрудники и другие заинтересованные лица. При этом форма
подачи информации позволяет в сжатые сроки даже неподго-
товленному человеку понять, что именно вы предлагаете и ка-
кие важные особенности вы могли пропустить.
Результат — однозначно утвержденная нотация, прочитать
которую неправильно практически невозможно, а также тексто-
вое описание того, что не помещается в рамки графики. После
утверждения такого документа вероятность в итоге услышать «я
это представлял себе иначе» от заказчика или «я не так вас по-
нял» от исполнителя стремится к нулю. А потому изучайте моде-
лирование, оно того стоит.
62
IDEF0. ЗНАКОМСТВО С НОТАЦИЕЙ
И ПРИМЕР ИСПОЛЬЗОВАНИЯ
Одна картинка стоит тысячи слов
Народная мудрость
Зачастую в работе бизнес-консультанта возникает необходи-

мость не просто изучить и решить определенную проблему,
но выявить ее местонахождение в общей модели работы компа-
нии. Мало понимать, что определенное подразделение работает
неправильно, важно понимать, каким образом оно взаимодей-
ствует с другими. Иначе невозможно выявить все существующие
проблемы и выбрать оптимальный метод решения поставленной
задачи. А для этого требуется изучить работу компании и соста-
вить ее функциональную модель.
Конечно, в теории функциональная модель работы компа-
нии должна быть у руководителя, причем, не важно, идет речь
об организации работы склада или IT системе (от лида до заяв-
ки). Но в реальности практически никогда ее не оказывается,
а потому в процессе изучения и поиска решения поставленной
клиентом задачи приходится создавать функциональную модель
работы компании или определенного процесса (функции) само-
стоятельно.
НЕСКОЛЬКО СЛОВ О ПРЕИМУЩЕСТВАХ

ГРАФИКИ
Как известно, функциональные модели IDEF0 — это всегда

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

утверждения о необходимости функциональной модели работы
компании, очень многие подумали, что это все необязательно,
можно и на словах пояснить как работает та или иная функция
в компании. Вот об этом я и хочу поговорить. И для начала сде-
лаем небольшой экскурс в историю.
Вернемся в далекий 1877 год, в период Русско-Турецкой
войны. Именно тогда полиграфист Сытин впервые применил
графику при описании военных действий. Сейчас для нас все
это привычно, при описании любого сражения у каждого перед
глазами возникают карты со стрелками, которые наглядно пока-
зывают ход сражения. А в те времена военные действия описы-
вались словами. Для каждого боя — много-много слов. И понять
в итоге, что же происходит, было очень сложно. А потому идея
Сытина была поистине революционной — он начал печатать ли-
тографические копии карт с обозначением укреплений и распо-
ложений воинских частей. Назывались эти карты «Для читателей
газет. Пособие».
Идея оказалась настолько актуальной, что первый же тираж
«Пособий» разошелся мгновенно. И потом такие приложения
были очень востребованы. Причина очевидна. Графика помога-
ла понять то, что при помощи одних слов разобрать было прак-
тически невозможно.
Аналогичный пример беспомощности словесных описаний я
могу привести также из своей практики. Один из моих заказчи-
ков очень просил взяться за внедрение ERM-системы для его
компании. На вопрос, есть ли у них какое-то техническое зада-
ние, я получил ответ: «Да, есть. Но в нем 400 страниц». При этом
клиент очень жаловался, что мои коллеги, к которым он обра-
щался ранее, либо отказывались от проекта вообще, либо назы-
вали явно завышенные цены.
После того, как я увидел, что в техническом задании дей-
ствительно 400 страниц, и состоит оно исключительно из тексто-
вого описания, я понял причины поведения разработчиков. Про-
читать такой объем текста, вникнуть в него, разобраться во всех
64
нюансах только для того, чтобы понять задачу и назвать цену —

это и правда очень сложно. Этому клиенту я предложил альтер-
нативный вариант — описать все, что можно, графически в виде
нотаций. Показал ему примеры моделирования. В итоге они сей-
час переосмысливают свои пожелания и оформление техниче-
ского задания.
Знаю я также много других примеров, когда графическое
моделирование бизнес-процессов помогало в работе как моим
коллегам, бизнес-консультантам и разработчикам, так и самим
бизнесменам
ПОЧЕМУ ЭТО ВАЖНО ДЛЯ РАБОТЫ

КОНСУЛЬТАНТА
Моя работа всегда связана с внесением изменений в суще-

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

не предоставить объем, а максимально быстро и полно донести
суть. Большие объемы текста требуют времени, которого у биз-
несменов чаще всего очень мало. А графика позволяет сокра-
тить объем моего предложения и наглядно, в понятной форме
показать решение.
В результате мои предложения значительно сократились,
в них появилась графика, а решения о начале сотрудничества
стали приниматься быстрее. Именно по этой причине я исполь-
зую наглядные модели. Как известно, одна картинка стоит тыся-
чи слов. И в случае описания бизнес-процессов и вариантов мо-
дернизации работы бизнеса — это действительно так. И здесь
очень хорошо подходят нотации IDEF0. Но для начала, давайте
разберемся с основными понятиями, что такое нотации, зачем
они нужны, что такое IDEF0, в чем особенности и преимущества
этого метода
ЧТО ТАКОЕ НОТАЦИЯ ОПИСАНИЯ БИЗНЕС-

ПРОЦЕССОВ
Нотацией называется формат описания бизнес-процесса,

представляющий собой совокупность графических объектов, ис-
пользуемых при моделировании, а также правил моделирова-
ния. По сути, нотации — это особый графический язык, который
позволяет описывать работу компании, наглядно демонстриро-
вать взаимодействие между различными подразделениями, т.е.
описывать бизнес-процессы. Нотации могут применяться для
процессного или функционального моделирования. В общем,
нотации можно назвать языком программирования при бизнес-
анализе
66
ЧТО ТАКОЕ IDEF0?
IDEF0 — методология функционального моделирования (англ.

function modeling) и графическая нотация, предназначенная для
формализации и описания бизнес-процессов. Отличительной осо-
бенностью IDEF0 является ее акцент на соподчиненность объектов.
В IDEF0 рассматриваются логические отношения между работами,
а не их временна́я последовательность (поток работ). (с) Википедия
Стандарт IDEF0 был разработан в 1981 году в США департа-

ментом Военно-воздушных сил для автоматизации промышлен-
ных предприятий. В процессе разработки программного обеспе-
чения разработчики столкнулись с необходимостью разработки
новых методов анализа бизнес-процессов. В результате появи-
лась методология функционального моделирования IDEF0, в ко-
торой для анализа применяются специальные нотации IDEF0.
ФУНКЦИОНАЛЬНАЯ МОДЕЛЬ КОМПАНИИ
Функциональная модель IDEF0 представляет собой набор

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

вводящими и выводящими, так как по-английски они называют-
ся Input и Output соответственно. Но особенности перевода
и привычные названия выглядят уже так, как сложилось.
И все же для правильного понимания терминов важно пом-
нить их значение в данном случае. Это подтверждается еще
и тем, что данная нотация создана прежде всего для разработки
ПО, и термины переводить правильнее в этой точки зрения.
Стрелки подписываются при помощи имен существительных
(опыт, план, правила), а блоки — при помощи глаголов, т.е. в них
описываются действия, которые производятся (создать товар, за-
ключить договор, произвести отгрузку).
IDEF0 — это очень простой и одновременно наглядный
язык описания бизнес-процессов. С помощью этого стандарта
возможна передача информации между разработчиками, кон-
сультантами и пользователями. Стандарт очень тщательно раз-
рабатывался, он удобен для проектирования, универсален. Для
работы с ним существует множество инструментов, например,
VISIO, BPWIN, ERWIN, Bussines studio и т. д.
Кроме того, использование для создания бизнес-моделей
IDEF0 — это не только удобно, это еще и правильно. Этот ин-
струмент был разработан для бизнес-аналитики, он прошел дли-
тельную и тщательную отладку и шлифовку. А потому при помо-
щи IDEF0 создать функциональную модель без ошибок намного
проще, чем без применения этого стандарта.
Как известно, забивать гвозди лучше всего молотком. Конеч-
но, вы можете для этого применять и другие инструменты,
но молоток — наиболее функционален и с его помощью проще
всего забить гвоздь аккуратно и точно. Так и с применением
IDEF0 — этот инструмент был создан для функционального мо-
делирования, и с его помощью вы намного быстрее и точнее
сможете получить нужный результат.
68
Диаграмма первого уровня
ПРИМЕР СОЗДАНИЯ ФУНКЦИОНАЛЬНОЙ

МОДЕЛИ IDEF0
Для того чтобы понять, как работать с функциональным мо-

делированием, я приведу пример процесса написания статьи.
Основной блок — «Написать статью».
Входящие стрелки — «Опыт», «Информация из сторонних
источников».
Это те вводные, которые необходимы для начала работы.
Управляющие для написания статьи — это «План публика-
ции», «Требования издателя», «Правила русского языка». А в ро-
ли «Механизмов» выступают автор, копирайтер, корректор
и программное обеспечение.
В данном случае автор создает аудиоматериал, в котором
собирает все мысли и идеи, которые должны быть отражены
69
в статье.
Копирайтер — это человек, который создает на основе этого
материала, руководствуясь требованиями издателя, планом пуб-
ликации и правилами русского языка, готовый текст статьи.
Корректор проверяет материал на ошибки.
Программное обеспечение — это те инструменты, которые
используют в работе все участники процесса.
Таким образом, я задал основные параметры процесса, его
вход, выход, а также все необходимое для успешного проведе-
ния процесса. Но это — только основные рамки процесса. Так
описывается общая схема работы компании в целом.
На самом деле, процесс создания статьи, как и любой биз-
нес-процесс можно и нужно детализировать. Для этого я деком-
позирую общий блок «написать статью» на связанные между со-
бой элементы.
В нашем случае работа делится на 4 основных этапа:
1. Подготовить аудио.
2. Подготовить текст
3. Подготовить текст к публикации
4. Разместить статью в издании.
На схеме наглядно видно, на каком этапе какие управляю-

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

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

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

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

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

как для выполнения необходимо что-то получить на входе (заказ,
поставленную задачу), а после обработки на выходе необходимо пе-
редать готовый продукт. Входящие стрелки всегда слева, исходя-
щие — справа.
73
3. Сверху — управляющие элементы, снизу — механизмы, необходи-

мые для выполнения процесса.
4. Если на одном листе (экране) располагается несколько блоков,

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

пересечение стрелок было сведено к необходимому минимуму.
Стандарт IDEF0 включает в себя также общепринятые обо-

значения, правила, требования к блокам диаграмм, имеет соб-
ственную семантику. Подробно ознакомиться с ними можно
в документе «Методология функционального моделирования
IDEF0»
ТИПИЧНЫЕ ОШИБКИ
Функциональное моделирование выполняют при помощи

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

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

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

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

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

называют именами существительными, блоки — глаголами. Так
принято в стандарте IDEF0, и такой подход помогает избежать
путаницы и ошибок. Чаще всего ошибки допускают при назва-
нии блоков. Например, вместо «Создать статью» пишут «Созда-
ние статьи». Блоки в данном подходе — это действия, а потому
они должны быть всегда глаголами.
ВЫГОДЫ ИСПОЛЬЗОВАНИЯ IDEF0
Самая первая выгода очевидна — это наглядность. Вы сами

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

Дисциплина и отсутствие ошибок. Стандарт IDEF0 предпола-
гает строгие рамки и правила. Такой подход дисциплинирует,
а привычка действовать в рамках стандарта помогает избежать
ошибок по невнимательности. Любые нарушения стандарта ста-
новятся сразу заметны.
В ЧЕМ ТРУДНОСТЬ ПРИМЕНЕНИЯ IDEF0
Важно понимать, что только в самых простых случаях два

бизнес-аналитика создадут для описания работы компании аб-
солютно одинаковые функциональные модели.
Любая модель — это отражение опыта аналитика, глубины
понимания работы бизнеса, который он стремится описать, а та-
кже, в некотором роде, его личная точка зрения на этот бизнес.
Т.е. человек разрабатывает бизнес-модель с точки зрения руко-
водителя, как будто этим руководителем является именно он.
При этом я считаю, что бизнес-аналитик — это не совсем
профессия, бизнес-аналитикой занимается каждый руководи-
тель бизнеса или разработчик каких-то систем, который анали-
зирует бизнес и стремится выстроить наиболее эффективную
систему. Именно для этих людей и для этих целей предназначен
инструмент IDEF0.
А потому очень важно при составлении функциональной
бизнес модели «как есть» постоянно советоваться с руководите-
лем компании, чтобы не совершить ошибки, которая повлечет
за собой автоматически ошибки на этапах декомпозиции. Также
на последующих этапах могут потребоваться дополнительные
согласования с руководителями структурных подразделений
и сотрудниками.
Только если ваша функциональная модель «как есть» будет
действительно отражать реальное положение вещей, можно
вносить какие-то изменения и предложения. А для достижения
качественных результатов в такой работе требуется, прежде все-
го, практический опыт и знание особенностей того или иного ви-
77
да бизнеса.
78
ЧТО ТАКОЕ BPMN: ИЗУЧАЕМ
НОТАЦИЮ
В этой главе я предлагаю разобраться «с нуля» — что такое
BPMN? В чем особенности и преимущества этой нотации и поче-
му она появилась и оказалась столь востребованной, по край-
ней мере, за рубежом. Да и у нас в стране ей все больше и боль-
ше интересуются.
Также я хочу сразу обратить ваше внимание на то, что здесь
я буду говорить именно о нотации BPMN, т.е. о языке моделиро-
вания бизнес-процессов. Я, конечно, постараюсь максимально
просто описать основы BPMN так, чтобы они были понятны даже
новичкам. Но также важно понимать, что здесь я буду говорить
именно о языке, а не о методологии.
Методология моделирования бизнес-процессов — это поня-
тие очень обширное, по сути, это та самая база, знания которой
нужны для практического применения языков моделирования
бизнес-процессов. Почему я делаю на этом акцент? Многие лю-
ди (и я в свое время также) считают, что достаточно выучить
язык бизнес-моделирования, и вы сумеете выстраивать бизнес-
процессы.
Для понимания причин появления BPMN и всех нюансов мо-
делирования при помощи этой системы нотаций, понадобится
также знание основных проблем, которые решает BPMN, что для
работы использовали до появления BPMN, и с какими сложно-
стями сталкивались. Ведь появление новых систем и нотаций
невозможно без понимания определенной проблематики. И я
считаю, что этот аспект очень важен для понимания сути вопро-
са, что же такое на самом деле BPMN.
Лично я познакомился впервые с BPMN около десяти лет на-
зад, когда начал изучать систему Bizagi Modeler. Заинтересовал-
79
ся я этой системой по причине того, что давно уже понимал всю

важность моделирования. До этого я лично пользовался IDEF0
и IDEF3, но там я сталкивался с определенными ограничениями.
Дело в том, что IDEF0 несколько ограничен по числу возможно-
стей. А IDEF3 мне лично показался излишне строгим и «сухим»,
в нем было сложно моделировать многие виды бизнес-процес-
сов с участием программных продуктов.
В то время Bizagi был относительно простым модулем, в ко-
тором присутствовал удобный редактор для моделирования (ри-
сования) бизнес процессов, но еще не было никаких инструмен-
тов для исполнения бизнес-процессов. Но даже тогда строгие
правила BPMN, принятые в системе Bizagi, помогали избегать
значительного числа ошибок, столь частых при обычном «рисо-
вании» бизнес-процессов в графических редакторах или на бу-
маге.
В поисках оптимального решения для себя я изучал ARIS,
инструменты 1С для бизнес-моделирования, различные системы
моделирования бизнес-процессов, которые были придуманы
различными бизнес-консультантами, как российскими, так и за-
рубежными. И, конечно же, познакомился с нотацией BPMN.
При первом знакомстве BPMN мне во многом понравился,
идея была очень хорошей, а вот исполнение на тот момент с мо-
ей точки зрения еще было «сырым». И полноценно пользоваться
BPMN я начал только через несколько лет после знакомства, ко-
гда задачи, которые я стал решать, усложнились настолько, что
IDEF0 применять полноценно никак не получалось. И оказалось,
что нотация развивалась, и теперь я активно пользуюсь BPMN
в своей работе.
BPM: ОСНОВНЫЕ ПОНЯТИЯ
Для того чтобы разобраться, что такое BPMN, нужно пони-

мать, что часть этой аббревиатуры «BPM» имеет две расшифров-
ки — Business Process Modeling и Business Process Management.
В первом случае — это непосредственно моделирование бизнес
80
процесса, а во втором — управление бизнес-процессами, т.е. об-

щая система, частью которой и является Business Process
Modeling.
При этом моделирование бизнес-процессов является осно-
вой и основной целью. При помощи моделирования мы можем
описать любой бизнес процесс, а исполняться они могут в самых
разных системах управления.
Есть и еще одно понятие, о котором стоит сразу упомя-
нуть — BPMN Modeler. Этот термин описывает те самые системы
управления, в которых производится моделирование, а также
исполнение бизнес-процессов.
Можно сказать, что BPMN является частью двух важнейших
составляющих:
— BPMN Modeler (Business Process Modeling) — это та среда, где вы
занимаетесь непосредственно моделированием. Самостоятельно или
в команде.
— BPMS (Business Process Modeling System) — это инструменты для

исполнения созданных вами моделей. Это может быть Bizagi,
Comundo, ELMA и пр.
Также необходимо отметить что есть BPMS которые уже

включают в себя BPMN Modeler.
ЯЗЫК ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ
Когда впервые сталкиваешься с моделированием бизнес-

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

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

нес-процессов и структуры языка моделирования, я хочу немно-
го рассказать об истории появления нотации BPMN. Разработка
системы моделирования бизнес-процессов и спецификаций для
нее (языка моделирования) ведется относительно давно.
82
Первая версия BPMN 1.0 была выпущена в мае 2004 года

компанией Business Process Management Initiative. Эта версия
обладала ограниченными возможностями и была, так сказать,
«пробным вариантом», который нуждался в многочисленных до-
работках.
Следующая версия BPMN 1.1 выходит в январе 2008, и здесь
разработкой и поддержкой занималась уже Object Management
Group, организация, появившаяся в результате слияния BPMI
с другой компанией-разработчиком программного обеспечения.
Еще один релиз появляется всего через год, версия BPMN
1.2 выходит в свет в январе 2009. Разработчик OMG остается
прежним. Команда, которая занимается продуктом, после слия-
ния практически не меняется.
В январе 2011 года компания OMG выпускает версию BPMN
2.0, а в декабре 2013 выходит последний на данный момент ре-
лиз — BPMN 2.0.2. Именно эта версия предлагается всем поль-
зователям и сегодня, так как система получилась стабильной,
возможности моделирования в ней очень широкие, а язык мо-
делирования (набор обозначений) по большей части понятен
всем бизнес-пользователям — как бизнесменам, бизнес-кон-
сультантам, так и техническим специалистам.
Из истории можно сделать вывод что период изменений
в этом языке миновал, и можно спокойно изучать и использо-
вать его на практике.
Сегодня BPMN — это один из наиболее распространенных
методов описания бизнес-процессов, которые сегодня уже «по-
нимают» как бизнес-пользователи, так и программные продук-
ты, предназначенные для работы с бизнес-моделями. Т.е. этот
язык описания является стандартным также и для создания ис-
полняемых алгоритмов в сфере управления бизнесом.
Я особенно хочу подчеркнуть этот момент, так как и сам
столкнулся поначалу с непониманием, зачем те или иные вещи
усложнять? Ведь для описания бизнес-процессов, например, при
GAP-анализе (анализ разрывов) или для представления заказчи-
ку бизнес-модели в какой-то упрощенной форме, всего много-
83
образия элементов BPMN вам не нужно. Но когда начинается

автоматизация, когда бизнес-модель становится не просто удоб-
ной схемой, а может экспортироваться в другие программные
продукты в качестве исполняемых данных, все становится
на свои места. Последняя версия BPMN действительно стабиль-
на и все требования к языку обоснованы.
ИЗ ЧЕГО СОСТОИТ НОТАЦИЯ BPMN?
И здесь я хочу сделать небольшое отступление. Дело в том,

что перевод терминов и понятий с английского языка на рус-
ский — занятие сложное. Найти наиболее точное слово обычно
может специалист, но переводом занимается совсем другой че-
ловек, часто вообще не имеющий понятия о сути тех понятий,
которые он переводит. В результате появляется множество
неточностей, понятия усложняются, возникает путаница.
Здесь я буду оперировать теми понятиями и терминами,
которые использую сам на практике. И они не всегда будут
совпадать с теми словами, которые вы встречали в Википедии
или каких-то переведенных руководствах. Причина заключает-
ся именно в том, что я, как специалист, в некоторых случаях
нашел для себя более точный перевод английского термина.
И применение слова, которое выбрал для себя я, помогает по-
нять суть процесса намного быстрее.
Конечно, я буду пояснять всю терминологию по мере необ-
ходимости. А потому думаю, что проблем с пониманием и тер-
минами не возникнет. Но все же обратить внимание на этот мо-
мент я считаю правильным.
Язык описания бизнес-процессов опирается на следующие
базовые объекты:
— Event — Событие;
— Activity — Действия;
— Gateway — Шлюзы или Развилки;
— Flow — Поток.
— Date — Данные;
84
— Artefact — Артефакты;
— Swimline — «плавательные дорожки»;
— Pool (Пул) — набор.
Здесь я не буду рассказывать обо всех существующих эле-

ментах BPMN, их на самом деле очень много. И при необходи-
мости вы всегда можете воспользоваться документацией
по BPMN, где подробно описаны все существующие элементы.
Я же остановлюсь только на базовых элементах, без кото-
рых не обходится ни одна бизнес-модель. Для первого знаком-
ства с BPMN и понимания основных принципов работы нотаций
этого достаточно.
EVENT (Событие)
Event — это то событие, которое произошло в описании про-
цесса или хореографии (о ней я расскажу отдельно). Эти собы-
тия могут быть начальными, конечными или промежуточными.
Например, опишем процесс получения заказа от клиента
по телефону:
— Событие Старт — это входящий звонок от клиента.
— Событие Финиш — это отправка готового расходного документа
на печать.
Конечными могут быть самые разные события. Здесь и за-

пись перечня потребностей клиента, и сохранение документа
85
заказа, и создание на его основе расходной накладной, налого-

вой и т. д.
ACTIVITY (Действия)
Activity — это те действия (задачи), которые должны быть
выполнены на определенном этапе бизнес-процесса. Их при мо-
делировании обычно обозначают в виде прямоугольников, в ко-
торые вписывают суть действия.
Действия могут быть элементарными, т.е. неделимыми на ка-
кие-то более простые действия, так и не элементарными, т.е. та-
кими, которые при детализации делятся на последовательность
определенных более простых действий.
Обычно действия делят следующим образом:
— Процесс — крупное действие, которое требует дальнейшей дета-
лизации при моделировании.
— Задача — элементарное действие, которое уже не может быть
дальше детализировано.
GATEWAY (Шлюз, развилка)

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

шения о покупке — «да или нет». При положительном решении
необходимо оформить покупку, при отрицательном — выяснить
возможные причины отказа, провести работу с «отказом» и т. д.
FLOW (Поток) И MESSAGE FLOWS (Поток сообщений)

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

же Message Flows могут связывать два отдельных пула в диа-
грамме.
Message Flows Association — еще один вид линий, в отличие
от сообщений, которые являются пунктирными линиями, этот ва-
риант отображается в виде последовательности не отрезков,
а точек. Необходима для того, чтобы показывать артефакты
(о них — ниже).
POOL (Пул)
Пул — это объект, описывающий какой-то один процесс
на диаграмме. Он может быть не изображен на диаграмме,
но он всегда есть. На одной диаграмме может быть несколько
Пулов. Пул можно развернуть для просмотра деталей.
Пул может также содержать, так называемые, «дорожки».
Они нужны для того, чтобы указать участников процессов, кото-
рые скрыты в пуле. Например, в процессе работы с клиентами
участвует менеджер по продажам, руководитель отдела продаж,
возможно, бухгалтер или кассир.
DATE OBJECT (Данные, объекты данных)

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

Для менеджера это будет результат действий, а для склада, ко-
торый получает заказ — началом действия (сбор товаров и от-
грузка).
MESSAGE (Сообщение)
Этот элемент необходим, чтобы показать коммуникацию
между двумя участниками процесса. Это может быть Email, со-
общения внутри системы совместной работы, переписка в ка-
ком-либо из мессенджеров, которыми пользуются участники
процесса, коммуникации на сайте компании, sms-сообщения
и т. д.
89
ARTEFACT (Артефакты)
Под артефактами в BPMN понимают объекты, не являющие-

ся действиями и не связанные с действиями напрямую. Это мо-
гут быть любые документы, данные, информация, которая
не влияет напрямую на исполнение процесса.
Выделяют два вида артефактов:
— Object Group (Группа объектов)
— Text Annotation (Текстовая аннотация)
Object Group (Группа объектов) — это еще одна возможность

объединить под общим символом несколько элементов, чтобы
сэкономить место на диаграмме и повысить простоту ее воспри-
ятия. Здесь собираются различные активности под одним общим
названием. Группу объектов также всегда можно рассмотреть
детально. Группа выглядит как прямоугольник с закругленными
углами, выполненный штриховой линией с точками.
Text Annotation (текстовые аннотации) применяют для раз-
личных уточнений к диаграмме. Это могут быть комментарии,
пояснения, другая информация, которая повысит читабельность
диаграммы. Аннотации — это незакрытый прямоугольник, вы-
полненный сплошной линией, от которого к объекту аннотации
ведет линия, состоящая из точек.
ИСПОЛНЯЕМЫЕ И НЕИСПОЛНЯЕМЫЕ БИЗНЕС-

ПРОЦЕССЫ
В бизнес-моделировании процессы можно условно разде-

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

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

Исполняемый вариант требует глубоких знаний BPMN, а так-
же внимательного отношения к каждой детали, так как вы,
по сути, создаете программу (алгоритм) для компьютера, просто
используете для этого не текстовый язык, а графические нота-
ции. Это дело — для опытных специалистов.
ПОДХОДИТ ЛИ BPMN ДЛЯ МАЛОГО

И СРЕДНЕГО БИЗНЕСА?
Нотации BPMN можно и даже нужно использовать при рабо-

те с малым и средним бизнесом. Возможно, что вы не будете ре-
ализовать бизнес-модель на уровне программного обеспечения,
так как это всегда — дополнительные затраты, и в условиях ма-
лого бизнеса нет необходимости в подобных инструментах кон-
троля и анализа работы.
Но, тем не менее, на уровне неисполняемых бизнес-процес-
сов я очень активно используют именно BPMN. Дело в том, что
при всей сложности вхождения (т.е. изучения и умения работать
с нотациями), уровень понимания BPMN — низкий, т.е. для чте-
ния нотаций не требуется вообще никаких особых знаний и на-
выков. Графические нотации понимаются интуитивно. И я еще
не встретил ни одного человека, для которого бы прочесть нота-
цию было бы сложно. Эта нотация создавалась специально для
того, чтобы найти общий язык между аналитиком и обычными
бизнесменами (управленцами).
В результате, как я и писал выше, при помощи BPMN вы эко-
номите свое время и время заказчика (руководителя) и добивае-
тесь максимально высокого уровня взаимопонимания. Нотации
не позволяют «двойного прочтения», а потому очень помогают
в работе.
92
МИНУСЫ И ВАЖНЫЕ ОСОБЕННОСТИ BPMN
О том, насколько удобна BPMN, я сказал уже много. Но для

выбора любого инструмента важно также понимать и возмож-
ные минусы. О них я сейчас и расскажу:
— Система имеет значительное количество понятий и терминов, их
нужно знать и применять грамотно.
— Высокий уровень вхождения. Как и любой инструмент с широки-
ми возможностями требует большего времени на изучение, по срав-
нению с другими нотациями (IDEF0, IDEF3).
— Необходимо знание бизнес-анализа. В BPMN модели — это
не просто картинки или схемы, которые вы можете нарисовать в лю-
бом графическом редакторе. Здесь очень важна грамотная структура
и четкая последовательность.
ПРИМЕР ПРАКТИЧЕСКОГО ПРИМЕНЕНИЯ BPMN
Конечно же, без примера описание моделирования бизнес-

процессов было бы неполным и не до конца понятным. Я решил
в качестве примера взять процесс обеспечения заказов покупа-
телей, так как этот этап работы присутствует практически в лю-
бом направлении бизнеса, а потому реализация этого процесса
на практике будет понятна без дополнительных пояснений ши-
рокому кругу читателей.
Результатом этого процесса должно быть обеспечение поку-
пателя необходимыми ему наименованиями товара.
Данный бизнес-процесс выполняется следующим образом:
— Менеджер по продажам получает информацию о потребностях
клиента (заказ).
— В системе CRM создается документ Заказ покупателя.
— Если нужные товары есть в наличие, то менеджер создает расход-
ный документ в программе учета. Если товара нет в наличии, мене-
джер делает запрос в отдел закупки.
— Отдел закупки оформляет запрос поставщикам на получение то-
вара.
На этом мы будем считать бизнес-процесс завершенным, так
93
Модель процесса «Резервирование товара»
как покупатель сейчас или после поступлений товаров от по-

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

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

са? В наглядной форме вы можете показать своим бизнес-
клиентам каким образом функционирует или должна функци-
онировать связь между отделами продаж и закупки с целью
максимального удовлетворения потребностей покупателей. Та-
кже при помощи этого бизнес-процесса техническим специа-
листам будет намного проще создавать и настраивать про-
граммное обеспечение для автоматизации работы компании,
так как на диаграмме наглядно видно, какие процессы в ка-
кой последовательности должны происходить, какая информа-
ция поступает на каком этапе, а также из каких источников,
какие из пользователей должны иметь доступ к тем или иным
процессам и документам.
При необходимости этот бизнес-процесс может быть детали-
зирован, что также помогает увидеть, что и как работает (долж-
но работать) для получения результата.
КАК РАЗРАБАТЫВАТЬ ДИАГРАММЫ BPMN

НА ПРАКТИКЕ?
Здесь я хочу поделиться некоторыми советами о том, с чего

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

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

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

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

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

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

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

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

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

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

моделирования вам нужен, не стоит бояться BPMN. Выучить
нотацию очень просто, а для чтения таких диаграмм вашим
коллегам и клиентам даже минимальные знания не понадобят-
ся, моделирование очень наглядно и готовые диаграммы по-
нятны интуитивно. Попробуйте, у вас также обязательно все
получится.
97
КАК ОПИСАТЬ БИЗНЕС-ПРОЦЕСС
Существует два диаметрально противоположных подхода
к началу описания бизнес-процесса. Некоторые учебники реко-
мендуют сначала описать все текстом, пошагово, и только потом
переходить к графике. Другие советуют сразу моделировать гра-
фическую нотацию, а потом описывать ее текстом по мере необ-
ходимости.
Я считаю, что начинать с текста — это путь в никуда. Потому
что вы таким образом получаете на первом этапе много тексто-
вой информации, в которой даже самому можно запутаться.
Кстати, это происходит не так редко, как может показаться. Тем
более, ваши заказчики будут долго и с трудом разбираться, что
вы им хотите донести.
Другое дело — графическая нотация, где наглядно видно,
какое действие выполняется на каждом этапе, где находится
«условная вилка» и т. д. В этом случае любые ошибки и недоче-
ты становятся очень заметны.
Я рекомендую такую последовательность действий:
1. Цель описания бизнес процесса
2. Цели бизнес процесса
3. Поговорить с руководством в отделах которые работают в бизнес
процессе
4. Поговорить с сотрудниками
5. Выявить наиболее важные задачи бизнес процессе
6. Сделать первый вариант бизнес процесса
7. Выявить начало и конец процесса, начало должно быть только од-
но, финалов много.
8. Составить список задач с условиями
9. Обсудить детали с руководством и с ключевыми сотрудниками
10. представить финальный вариант
11. Подготовить текстовое описание бизнес процесса
Такой подход экономит время и вам, и заказчику. И что еще
98
важнее, гарантирует взаимопонимание. Но давайте разберемся

шаг за шагом, с чего начинать и как действовать.
1. ОПИСАТЬ ЦЕЛЬ ОПИСАНИЯ БИЗНЕС

ПРОЦЕССА
Цель описания бизнес процесса ни в коем случае не надо

путать с целью самого бизнес-процесса. Это разные этапы ра-
боты.
Цель описания бизнес-процесса — это задача, которая стоит
перед вами. Например, это может быть автоматизация процесса
продажи, автоматизация приема заявки, процесса управления
снабжением и т. д.
Также целью описания может быть не автоматизация, а ре-
инжиниринг или, говоря проще, оптимизация бизнес-процесса.
В этом случае вам сначала понадобиться сделать описание «как
есть», и только потом его оптимизировать.
Примеры подобных задач: «Оптимизация процесса бизнес-
контроля» или «Реинжиниринг процесса планирования».
Т.е. первый этап — это четкое понимание, а еще лучше, сра-
зу краткое текстовое описание того, зачем вы вообще выполняе-
те эту работу.
2. ОПИСАТЬ ЦЕЛИ БИЗНЕС ПРОЦЕССА
Теперь необходимо четко обозначить цели самого бизнес-

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

жет иметь два очевидных финала:
— Сделка завершена успешно.
— Сделка проиграна (клиент отказался от сотрудничества).
Оба эти финала должны быть запланированы заранее. При-

чем, в случае проигранной сделки, обязательно нужно заранее
определить, в каких случаях может возникнуть такой вариант
выхода из бизнес-процесса, ведь заказчик может отказаться
от сделки на разных этапах и по разным причинам. Здесь очень
важно определить оптимальные варианты выхода из сделки.
Почему так важно четко определить цели бизнес процесса?
Очень важно в любом процессе на выходе получить максимум
информации о том, как он проходил, где и на каком этапе за-
вершился, где и по каким причинам он сорвался, или, наоборот,
что сделали, чтобы процесс прошел успешно.
3. ПОГОВОРИТЬ С РУКОВОДСТВОМ ОТДЕЛОВ,

КОТОРЫЕ РАБОТАЮТ В БИЗНЕС ПРОЦЕССЕ
Теперь, когда поставлены все необходимые цели, пришло

время обсудить нюансы работы с руководителями отделов, кото-
рые будут учувствовать в бизнес-процессе.
Важно понимать, что где бы и с кем вы ни работали, вы все-
гда будете сталкиваться с определенной иерархией внутри орга-
низации. Скорей всего, первый этап переговоров у вас будет
происходить на уровне руководства. Но дальше вам необходим
контакт с подразделениями, которые задействованы в бизнес-
процессе. Нужно выявить тех сотрудников, которые будут учув-
ствовать в нем непосредственно. Для этого вам понадобится об-
щение с руководителями этих подразделений.
Важно понимать что иногда вам не нужно будет говорить
с каждым с кем запланировано, кто нибудь из руководства мо-
жет вам рассказать и за себя и за других людей. Соблюдайте ме-
ру, не будьте роботом.
100
4. ПОГОВОРИТЬ С СОТРУДНИКАМИ
Далее, уже с согласия и, возможно, при участии этих руково-

дителей, имеет смысл пообщаться с лучшими сотрудниками. Я
их называю обычно «звезды». Это те люди, которые в текущих
условиях выполняют свою работу наиболее эффективно. Инфор-
мация от них поможет вам понять, как составить бизнес-процесс
наилучшим образом.
Список звезд вы должны получить от руководства отделов,
это может быть один или несколько человек.
5. ВЫЯВИТЬ НАИБОЛЕЕ ВАЖНЫЕ ЗАДАЧИ

В БИЗНЕС-ПРОЦЕССЕ
На основе собранных интервью сотрудников и руководства

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

на самом деле важно, в каждой организации и в каждой ситуа-
ции индивидуально. Вы — специалист, и вы должны уметь вы-
являть то, что действительно требуется для моделирования
бизнес-процесса. При этом вы будете исходить из контекста,
из поставленной задачи, из ресурса финансового и временного
и т. д.
Очень важно понимать что на самом деле вы всегда сможете
добавить что то, даже если вы убрали это ранее. Ведь при об-
суждении вам скорее всего укажут на вашу недоработку тот кого
вы до этого интрвьюировали.
6. ВЫЯВИТЬ НАЧАЛО И КОНЕЦ ПРОЦЕССА
Вы уже определяли цели процесса, теперь, после общения

с сотрудниками компании-заказчика, их можно и даже нужно
уточнить. Кроме того, на этом этапе нужно четко обозначить на-
чало процесса, с учетом всех входящих данных.
Помните: финалов у бизнес-процесса может быть несколько,
начало — всегда одно. В принципе в пункте 2 вы уже описали
финалы, но важно понимать что на данном этапе вы пишете
конкретно где и сколько будет финалов.
7. СОСТАВИТЬ СПИСОК ЗАДАЧ С УСЛОВИЯМИ
Определите основные задачи, которые должны быть реше-

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

симости от условия. Обычно условия могут быть «или» или «и».
В зависимости от нотации количество видов развилок может
варьироваться.
8. СДЕЛАТЬ ПЕРВЫЙ ВАРИАНТ БИЗНЕС

ПРОЦЕССА
Пришло время заняться созданием самого бизнес-процесса.

Я обычно называю первый вариант черновым, но, тем не менее,
показываю заказчикам. Именно в качестве черновика.
Необходимо уметь донести до своих клиентов, что это такое
и зачем вы им показываете «черновик». Они должны понимать,
что вы — специалист в своем деле, но не в особенностях работы
их бизнеса. И только совместная работа над бизнес-процессом
поможет добиться наилучшего результата. Потому вы составляе-
те «черновой» вариант бизнес-процесса, а они его изучают, ско-
рей всего, на уровне руководителей тех самых подразделений,
которые будут по этой схеме работать. И вносят свои пожелания
и уточнения.
На своем опыте я также понял, что оптимальное решение —
разослать черновой вариант бизнес-процесса заранее всем за-
интересованным лицам, например, за 1—2 дня до дня встречи
или онлайн-конференции. Графические нотации читаются про-
сто, они понятны интуитивно даже не специалистам, особенно,
если составлены грамотно. Нужно стараться делать ваши нота-
ции как можно более понятными. Впрочем, при необходимости
вы можете составить краткое пояснение для каких-то сложных
или особо важных этапов.
Дайте людям время на изучение бизнес-процесса. Пусть они
составят свои вопросы и уточнения заранее. Конечно, никто
не гарантирует, что они найдут время и прочитают нотацию за-
ранее. Но все же старайтесь сделать так, чтобы заинтересован-
ные люди успели ознакомиться с вашим «черновиком», и, что
еще важнее, смогли понять, что именно вы предлагаете.
103
9. ОБСУДИТЬ ДЕТАЛИ С РУКОВОДСТВОМ

И С КЛЮЧЕВЫМИ СОТРУДНИКАМИ
Далее следует этап обсуждения. Здесь важно, с одной сторо-

ны, внимательно прислушиваться к мнению руководителей под-
разделений и самих сотрудников, учитывать нюансы, которые
вы могли не совсем верно понять при первом интервью. Но так-
же помните, что эксперт в этом случае — вы. Именно вы знаете,
как лучше. А потому везде, где сотрудники компании будут стре-
миться вернуть процесс на «привычные рельсы», а они будут это
делать с высокой вероятностью, проявляйте твердость. Они хо-
рошо знают «как есть», а вы — «как должно быть».
10. ПРЕДСТАВИТЬ ФИНАЛЬНЫЙ ВАРИАНТ
Черновых вариантов может быть более одного, особенно,

если бизнес-процесс сложный и специфический. Но в любом
случае, этот процесс согласования не может продолжаться бес-
конечно. Лучше всего, если заказчик будет понимать заранее,
что вы готовы дорабатывать 1,2 или 3 раза. Но не более. Тогда
и обсуждение будет максимально конструктивным.
После согласований вы создаете финальный вариант графи-
ческой нотации.
11. ПОДГОТОВИТЬ ТЕКСТОВОЕ ОПИСАНИЕ

БИЗНЕС ПРОЦЕССА
Текстовое описание бизнес-процесса следует готовить после

всех согласований. Подробно описывать имеет смысл только
финальный вариант. Здесь уже вы готовите текстовое описание
как документ, прилагаете к нему план работ и т. д. На основании
графической нотации и этого описания вы в дальнейшем будете
работать.
104
ПРАВИЛА ОПИСАНИЯ БИЗНЕС-ПРОЦЕССА
Выше я много сказал о творческом подходе, о возможностях

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

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

статочность, т.е. описывать все необходимые этапы и действия,
при этом быть максимально лаконичным для простоты восприя-
тия. Лично я вывел для себя «правило 15 минут» — если за этот
период времени я могу объяснить руководству компании пред-
ставленный бизнес-процесс, значит, его можно показывать за-
казчику. Получается быстрее — прекрасно, требует больше вре-
мени и слов — надо подумать, что можно сократить и упростить.
Я когда-то лично видел графическое описание бизнес-про-
цесса, выполненное на листе 2 метров длиной (и соответствую-
щей шириной). Его даже просто рассмотреть и понять, куда ве-
дет какая стрелка крайне сложно. А как его пояснять заказчику,
я лично не представляю.
Помните, что человек воспринимает зрительно определен-
ный объем информации, ограниченный, в том числе, определен-
ным размером листа или экрана (это связано с особенностями
105
зрения), а также числом элементов (возможности мозга также

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

ретать собственные обозначения и правила. Используйте нота-
ции, которыми пользуются во всем мире. Я видел в книгах неко-
торых отечественных авторов попытки создания собственной
системы обозначений. И, честно говоря, так и не понял, зачем
они усложняют жизнь и себе, и своим читателям. Здесь как
с языком — вы можете придумать свой особый язык, но пони-
мать его никто, кроме вас, не будет. А если он окажется похож
на существующие, то может еще и путаница появиться. Либо вас
сочтут безграмотным, так как вы не по правилам известных язы-
ков используете пунктуацию, склоняете слова и т. д. Так и с но-
тациями — есть уже устоявшиеся, известные людям и, что также
немаловажно, интуитивно понятные нотации. Они потому и ста-
ли популярны, что в процессе их создания и доработок постоян-
но тестировались на простоту, однозначность и удобство. Если
вы будете использовать готовые нотации, вас будут понимать,
воспринимать, как эксперта, да и сами правила нотаций убере-
гут вас от логических ошибок. Я лично рекомендую IDEF3
и BPMN 2.
— Все участники бизнес-процесса должны быть учтены

и прямо указаны. И делать это необходимо без использования
сносок с нумерациями, комментариях в объектах Swimm line
(специальные сноски) и т. д. Этим нередко «грешат» любители
создавать собственные конструкции вместо использования гото-
106
вых нотаций. Где-то у них названия не помещаются, где-то им

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

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

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

цесса?
Важно понимать, что чем больше элементов в бизнес-про-

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

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

IDEF3. Подробно я о них здесь не буду говорить, но основное
отличие заключается в том, что в IDEF3 вы можете декомпози-
ровать элементы, а в BPMN такая возможность отсутствует.
С другой стороны, в BPMN вы можете создать около 40—50 эле-
ментов, т.е. подробно описать большой процесс. В IDEF3 допу-
стимое число элементов меньше. Потому здесь не выйдет изоб-
разить большой бизнес-процесс, зато можно часть процессов
представить «черными ящиками», после чего декомпозировать
их в подпроцессы.
108
ОПИСАНИЕ БИЗНЕС ПРОЦЕССОВ.
ИСПОЛЬЗОВАТЬ ОСТОРОЖНО
Сегодня общим местом стал тот факт, что бизнес-процессный
подход к организации работы считается современным, иннова-
ционным решением, которое в случае внедрения помогает по-
высить качество работы и увеличить прибыль предприятия. Я
и сам вам об этом постоянно повторяю в разных главах.
Но сейчас я решил поговорить о недостатках внедрения
процессного подхода, о том, какой негативный эффект может
получить компания и ее сотрудники в случае реализации этого
подхода неправильным образом.
Казалось бы, для работы был нанят специалист — бизнес-
консультант, или бизнес аналитик, он знает свое дело. Можно
расслабиться, специалисты все сделают «как надо». Но на самом
деле все не так просто, как может показаться на первый взгляд.
А в случае ошибочных решений проблемы ждут именно клиента
и его сотрудников.
КАК СОЗДАЕТСЯ ОПИСАНИЕ БИЗНЕС ПРОЦЕССА
Чаще всего над созданием описания бизнес процесса рабо-

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

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

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

тельность колонок и строк не имеет значения):
ЗАЧЕМ НУЖЕН ПРИГЛАШЕННЫЙ БИЗНЕС-

АНАЛИТИК?
Бизнес-моделирование необходимо для того, чтобы полу-

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

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

МАГАЗИНА
Далее я на примере покажу, как неправильных исходные

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

рах исчезла, так как заказ автоматически передается в учетную
112
Бизнес-процесс продажи до оптимизации
систему, где также без участия человека создаются все необхо-

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

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

Количество заказов, обрабатываемых в день, теперь ограни-
чивается только возможностями складского работника. Человек
видит постоянную «очередь заказов». Ее же наблюдает и его на-
чальство, и привычно выражает недовольство.
Даже если нет негатива «сверху», человек и сам видит по-
стоянный «завал», работать приходится больше, чем раньше.
Конечно, частично это компенсирует повышение зарплаты.
Но все равно из-за повышенной нагрузки копится усталость,
в том числе, психологическая. Человек — не машина, он не мо-
жет идеально работать изо дня в день без перерывов. У каж-
дого человека есть определенный максимум — сколько заказов
он способен обработать за смену.
В итоге, складские работники начинают увольняться один
за другим. Возникает текучка, приводящая к дополнительным
проблемам, задержкам в отправке заказов, ошибкам, связанным
с работой неопытных и усталых сотрудников. Вместо ожидаемой
оптимизации работы компания несет убытки и репутационные
потери.
А все потому, что, увлекшись красивой «упрощенной» нота-
цией, аналитик и руководитель компании не предусмотрели ка-
кие-то механизмы регулирования скорости работы, не учли, на-
сколько возрастает нагрузка, т.е. восприняли сотрудников не как
реальных людей, а как абстрактные «бизнес-процессы».
ОСНОВНЫЕ ПРИЧИНЫ ОШИБОК И ПРОБЛЕМ
Необходимо понимать, что в процессе создания нотации лю-

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

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

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

выглядит идеально, на том или ином этапе начинает давать
сбои.
Еще один важный фактор, который объединяет описанные
выше примеры:
При составлении нотации и внедрении процессного подхода
аналитик и руководитель компании не учли, что организация
обязательно состоит из людей. Как только из процесса исключа-
ются люди, он перестает быть бизнес-процессом, становится
процессом технологическим. А для этого типа процессов суще-
ствуют собственные правила описания, требования безопасно-
сти и т. д. Описывать их как бизнес-процессы недопустимо.
ПРОСТОЕ РЕШЕНИЕ ПРОБЛЕМЫ: ЦЕНИТЕ

ЛЮДЕЙ
Самый простой и очевидный выход — берегите сотрудников

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

рый не перегружается и успевает хорошо отдыхать, намного
лучше работает. Он результативнее, реже совершает ошибки, го-
тов творчески подходить к работе, делать больше и лучше.
Впрочем, это вам подтвердит любой опытный руководитель.
Если вынудить человека работать 8 часов подряд без переры-
вов, то работоспособность его значительно падает. Вынуждать
сотрудников работать «на износ» не только негуманно, но и,
в большинстве случаев, не выгодно. Люди будут увольняться ли-
бо, в определенных случаях, вы будете вынуждены их уволь-
нять, так как они начинают выполнять работу очень плохо, как
говорят о таких сотрудниках, «выгорают». Придется тратить вре-
мя и силы на поиск нового человека, его обучение, и так из раза
в раз. Постоянные лояльные компании сотрудники принесут
много больше пользы и стоить будут меньше, чем регулярно ме-
няющиеся кадры.
БУДЬТЕ ОСТОРОЖНЕЕ С ТЕХНОЛОГИЯМИ
В самом начале статьи я указал на основную ошибку — из-

лишнее доверие к современным технологиям, в число которых
входит также и бизнес-моделирование, в сочетании к стремле-
нию упростить все, что только можно, приводит к накоплению
ошибок.
Вникайте в детали, особенно, если вы планируете на каком-
то участке заменить человека программой. Убедитесь, что это
не приведет к потере контроля или естественной регулировки
нагрузки смежных подразделений. Не стоит «слепо» доверять
современным программным и технологическим решениям про-
сто потому, что мы живем в век массовой автоматизации.
118
БИЗНЕС МОДЕЛИРОВАНИЕ И IT-СФЕРА
В конце я хотел бы сказать несколько слов о том, как биз-

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

выше печальным образом. Причем, как видите из примеров,
негативные факторы могут одинаково повлиять и на небольшой
бизнес (пример интернет-магазина), так и на крупную компанию
(пример крупного сервиса такси). Необходимо понимать, что это
просто еще один пример разделения труда для большей эффек-
тивности в решении задачи.
120
ЗАБЛУЖДЕНИЯ И МИФЫ
О БИЗНЕС ПРОЦЕССАХ
В процессе изучения бизнес-процессов, общения с коллега-
ми и заказчиками, я слышал много мифов и ошибочных сужде-
ний по этому вопросу. Некоторые из них настолько распростра-
нены, что я решил поделиться ими с читателями.
Миф 1. Бизнес-процессы бывают сквозными
Этот термин я встречал даже в некоторых книгах, претенду-

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

либо по другим причинам.
Миф 2. Бизнес-процессы всегда должны нести ценность
Ничего подобного. Возьмем для примера бизнес-процесс

одобрения счета на оплату. На одной из конференций спикер
подробно показывал подобный процесс, который состоял
из 71 действия, и сообщал, что только 17 из них несут в себе
ценность. У меня это вызвало недоумение.
Я предлагаю подумать и вам. Вот какую ценность несет сам
по себе процесс согласования счета на оплату? И вообще, что
такое «ценность»? Какое значение несет в себе это слово? Если
под ценностью подразумевается получение прибыли, то этот
процесс точно ее не приносит и даже не гарантирует. Если речь
идет о снижении числа действий, то также это будет неверным
подходом.
Важно не снизить количество действий, а создать процесс,
при котором они будут правильными, т.е. последовательность
будет четкой, понятной, и приводить к нужному результату.
В данном случае результатом можно считать контроль добросо-
вестности сотрудников, т.е. бизнес-процесс согласования счета
позволяет избежать потерь, но сам по себе он не приносит при-
были.
Более того, если для достижения цели, в данном случае, кон-
троля правильности оформления документов и добросовестно-
сти сотрудников, требуется выполнить 71 действие, значит, они
все необходимы. И выделять какие-то из них, как несущие в се-
бе ценность, бессмысленно.
Если на самом деле, можно без потери качества сократить
число действий, например, до 50, это не значит, что часть из них
не несет ценности. Скорее, это значит, что специалист при со-
ставлении бизнес-процесса сделал ошибку. А если этих дей-
ствий действительно нужно 50, то далее сокращать их недопу-
стимо, независимо от того, какие из них вам покажутся более
122
или менее ценными. Если вы из правильно смоделированной

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

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

Подробнее об об As Is читайте в соответствующей главе этой
книги.
Миф 4. Всегда нужно знать процесс на уровне сотрудников
Это заблуждение массово встречается в бизнес-среде, т.е.

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

личие
Я и сам не использую классификацию бизнес-процессов

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

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

На самом деле, бизнес-процессы можно использовать в самых
разных сферах. Впрочем, это вопрос настолько важный, о нем
так часто приходится говорить, что я его решил выделить в от-
дельную главу. Обязательно ознакомьтесь с ней, если разделяете
это ошибочное мнение.
125
ОПИСАНИЕ БИЗНЕС-ПРОЦЕССОВ
КАК ЕСТЬ (AS IS) И КАК ДОЛЖНО
БЫТЬ (TO BE)
Когда я сам изучал моделирование бизнес-процессов при
реинжиниринге, то во всех учебниках встречал два понятия —
AS IS и TO BE. И все авторы писали, что сначала необходимо со-
ставить нотацию AS IS (буквальный перевод — «как есть), т.е. как
система работает в настоящее время, и только потом приступать
к процессу модернизации, т.е. создавать нотацию TO BE (Как
должно быть).
Проще говоря, сначала следует изучить, как работает пред-
приятие или отдел сейчас, сделать описание бизнес процесса,
и только потом, на основе нотации AS IS, начинать оптимиза-
цию. Но все эти теории хороши, когда есть что описывать
по схеме «Как есть». В реальности ситуация чаще всего иная.
ОПИСЫВАТЬ НЕЧЕГО
Если в компании не проводилась ранее оптимизация биз-

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

лист или коммерческое предложение и успокоится на этом. Дру-
гой сначала позвонит, все уточнит. Третий будет добиваться лич-
ной встречи даже там, где без нее можно прекрасно обойтись.
Перед ними стоит задача — обработать лиды и сделать план
продаж. Возможно, есть даже перечень рекомендаций, как это
лучше делать. Но единой системы нет. И люди начинают нару-
шать последовательность действий, поступать на свое усмотре-
ние и т. д.
Даже при наличии должностных инструкций в реальности
они чаще всего пылятся всеми забытые, а сотрудники работают,
кто как привык. В итоге, мы видим, что системы AS IS, т.е. «как
есть», не существует. Нет какой-то единой системы, по которой
на самом деле люди работают. И описывать, на самом деле,
нечего.
Вы, конечно, можете, попытаться составить модель AS IS
на основе инструкций. Но она не будет отражать реальность,
ведь их массово нарушают. Можете опросить сотрудников,
но любая из моделей будет отражать работу только части людей
либо что-то «усредненное», что вообще не будет иметь отноше-
ния к реальности, т.к. все работают похоже, но — не так.
ОПИСЫВАТЬ НЕЗАЧЕМ
Еще один важный аспект, с которым я столкнулся на практи-

ке. О том, что в компании что-то делают неправильно, все и так
давно догадываются. Иначе бы вас, как специалиста, не пригла-
сили. И от вас не ждут описания существующих проблем, они
часто и так понятны. От вас ждут решения — как надо работать.
Чаще всего клиенты ожидают, что бизнес-консультант при-
дет, осмотрится, опросит людей, после чего выдаст рекоменда-
ции, как надо делать, чтобы решить существующие проблемы.
Т.е. людям не нужны нотации «Как есть». Им сразу хочется уви-
деть «Как должно быть».
127
ЗАЧЕМ СОЗДАЮТ НОТАЦИИ AS IS?
Создавать нотации AS IS для себя вы можете, это даже мо-

жет быть удобно и полезно. В конце концов, графика помогает
упорядочить мысли, разобраться точнее лично для себя, что
и как происходит. Но в рекомендованной последовательности
действий указывается обязательный этап предоставления этой
нотации клиенту.
Бизнес-консультанту такой подход выгоден с финансовой
точки зрения. Больший объем работы повышает ее стоимость.
Но нужно ли это заказчику? Он и сам знает, что компания как-то
работает, потому что бизнес приносит прибыль и т. д. Вас он на-
нимает не для того, чтобы за их деньги вы им поясняли, какую
схему работы они сами организовали. Им хочется увидеть
от эксперта результат, т.е. схему, которая будет работать лучше.
Возникает резонный вопрос. А как без описания того, что
есть, вы сможете выдать рекомендации, что нужно изменить?
Но ведь вы — специалист, эксперт в своей сфере деятельности,
вас потому и позвали, что верят, вы разберетесь и сумеете вы-
дать правильный результат.
Конечно, вы будете вести свои записи. Вполне возможно,
что вы даже оформите их в виде нотации, как это и описывают
в учебниках. Вы можете использовать эти записи для уточнения
каких-то моментов в работе компании. Но этот этап нужен вам,
а не заказчику.
Потому не имеет смысла тратить силы и время на составле-
ние полноценной нотации AS IS с сопроводительной документа-
цией, включать этот этап в план работ и т. д. Если ваш клиент
не ждет от вас этого этапа в обязательном порядке, что иногда
случается в крупном бизнесе или в случаях, когда заказчики то-
же читали те самые учебники, предоставляйте сразу решение —
TO BE. Вы должны быть на стороне клиента, и давать ему то, что
реально нужно. Это подход продуктивности.
128
ДОЛЖЕН ЛИ ЗНАТЬ КОНСУЛЬТАНТ
ПРОЦЕССЫ НА УРОВНЕ ЛЮДЕЙ
НЕПОСРЕДСТВЕННО
РАБОТАЮЩИХ С ЭТИМИ
ПРОЦЕССАМИ
В качестве бизнес-консультанта я помогал автоматизировать
работу компаний, работающих в самых разных сферах. И здесь
постоянно возникает вопрос, насколько глубоко бизнес-консуль-
тант должен понимать сферу деятельности, которую он автома-
тизирует?
Очень распространено мнение, что без знания бухгалтер-
ского учета невозможно создать бизнес-процессы для работы
бухгалтерии или финансового отдела. Также многие руководите-
ли бизнеса считают, что для оптимизации работы их отдела про-
даж бизнес-консультант должен глубоко изучить особенности
товара или услуги.
Но практика показывает, что все совсем не так. Допустим,
для взаимопонимания с бухгалтерами желательно понимать хо-
тя бы основы бухучета. Просто иначе вы говорите «на разных
языках». Но и здесь достаточно основ. Все остальное бухгалтера
расскажут сами. В большинстве других случаях даже этого
не нужно.
ИЗ СОБСТВЕННОГО ОПЫТА
Лично я автоматизировать компанию по производству обо-

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

Больше скажу, у меня есть опыт в автоматизации медицин-
ских услуг, но это не сделало меня ни врачом, ни фармацевтом.
Есть в числе успешных проектов оптимизация работы туристи-
ческой компании, в том числе, в разрезе сопровождения детей
в места отдыха. Но я бы не рискнул взять на себя ответствен-
ность за группу детей и сейчас.
На самом деле, консультанту во всем этом разбираться
не нужно.
Заказчики часто спрашивают, а как ты сможешь автоматизи-
ровать то, в чем не разбираешься? Но ведь я — не сотрудник, я
не буду работать с этими технологиями, заниматься бухгалтер-
ской отчетностью или сопровождать детей. Этим будут и дальше
заниматься сотрудники, которые знают свое дело.
НЕ ПЫТАЙТЕСЬ СТАТЬ СОТРУДНИКОМ
Консультанту нет необходимости глубоко изучать сферу дея-

тельности каждой компании. Для этого в штате уже есть специа-
листы. Консультант нужен для того, чтобы понимать, что такое
бизнес-процессы, и как с ними правильно работать.
На самом деле, излишне глубокое изучение технических
особенностей и нюансов деятельности для бизнес-консультанта
даже вредно. Консультант работает не с одним сотрудником
и его сферой деятельности, он должен работать в рамках группы
людей, автоматизировать работу этой группы, а не деятельность
каждого специалиста в отдельности.
А КАК ЖЕ ТОГДА АВТОМАТИЗИРОВАТЬ?
Ответ на этот важный вопрос вы должны уметь давать еще

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

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

поможете ее составить. Далее вы включите этапы «сбор инфор-
мации у клиента» и «отправку формы на производство» в биз-
нес-процесс. А что означает каждый из параметров, вам знать
нет никакой нужды.
Потому вы не должны быть сотрудником, вы должны оста-
ваться консультантом и смотреть на процесс в целом.
132
ОТВЕТСТВЕННОСТЬ БИЗНЕС-
КОНСУЛЬТАНТА
Вопросы ответственности бизнес-консультанта за результат
внедрения описанного им процесса возникают часто, причем,
задают их еще на этапе предварительных переговоров. Если
вы — опытный специалист с уже сложившейся репутацией
и большим количеством успешных кейсов, скорей всего, вам бу-
дут доверять. Но даже я, с учетом всего своего опыта, регулярно
сталкиваюсь с настороженностью и фразами типа «А если это
будет работать плохо, что тогда?». Менее опытные специалисты
слышат вопросы, касающиеся ответственности за результат, по-
стоянно. Потому я решил посвятить этой теме отдельную главу.
Результат работы бизнес-консультанта заключается не толь-
ко в построении нотации и получении прибыли за проделанную
работу. Для ваших заказчиков результат — это повышение эф-
фективности работы компании после внедрения предложенных
вами решений.
Бизнес-процессы могут быть построены грамотно или нет.
В последнем случае результат, конечно, будет печальным. Каче-
ство проработки и умение применять свои знания на практи-
ке — ваша зона ответственности.
Если ваши решения будут неудачными, степень погружения
в нюансы работы компании недостаточными, вы очень быстро
понесете репутационные потери, а это критически важный фак-
тор в сфере услуг, в том числе, и в работе бизнес-консультанта.
Это должны понимать и вы, и ваши клиенты.
Результат для бизнеса зависит от нескольких факторов,
и далеко не всегда они связаны с вашей работой.
133
КТО ЗАНИМАЕТСЯ ВНЕДРЕНИЕМ?
Сотрудничество с бизнес-консультантами строится двумя

разными способами. Это может быть целый комплекс услуг, при
котором вы предлагаете решение и выполняете весь спектр ра-
бот по внедрению, включая обучение сотрудников и тестовый
период эксплуатации. При таком варианте сотрудничество за-
вершается, когда бизнес уже на практике работает по-новому,
и заказчик видит результат.
Но если вы приглашены на роль эксперта-консультанта,
а ваши идеи реализуют другие люди, ваша ответственность за-
канчивается на этапе согласования нотации и предоставления
пакета документов, состоящих из графической нотации и тексто-
вого описания к ней.
КОНСУЛЬТАНТ В ШТАТЕ ИЛИ ПРИГЛАШЕННЫЙ

СПЕЦИАЛИСТ
Некоторые компании предпочитают заниматься описанием

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

ков. Он видит ситуацию «со стороны», т.е. не имеет каких-то сво-
их привычек, предпочтений или инструментов, от которых
не хочется отказываться, чтобы не переучиваться. Кроме того,
этот человек выполнит работу и уйдет. Потому скорее не побоит-
ся собрать на себя негатив, который всегда вызывают реформы,
его не волнуют возможные конфликты в будущем и т. д. Потому
приглашенный специалист всегда приносит больше пользы.
А ЕСЛИ МЫ ПОНЕСЕМ В РЕЗУЛЬТАТЕ УБЫТКИ?
Это очень популярный вопрос на этапе переговоров. Все по-

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

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

но вопрос с возможными убытками закрывается раз и навсегда:
«Если мы совместно будем нести убытки, то нужно обговорить
и совместное получение прибыли».
135
КОНСУЛЬТАНТ — ЭТО СОВЕТЧИК
Вы — приглашенный специалист, который может предло-

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

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

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

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

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

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

том и заказчиком зависит очень многое. И если заказчик дей-
ствительно хочет получить работоспособную оптимизированную
модель, но будет помогать в сборе информации, изучать «чер-
новики» нотации, разбираться во всех нюансах. Помните, что
после того, как вы примете работу, поздно будет говорить «вы
меня не поняли» или «я тут что-то не так понял». Помогайте спе-
циалисту, чтобы он смог помочь вам.
137
ОТ ПЕРЕГОВОРОВ К РЕЗУЛЬТАТУ
Итак, подведем итоги. На этапе переговоров вы должны

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

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

обозначить момент завершения сотрудничества и, конечно, ка-
чественно выполнить свою работу. Тогда проблем и разногласий
не возникает.
138
ТРУДОЕМКОСТЬ И ЦЕНА
ОПИСАНИЯ БИЗНЕС-ПРОЦЕССА
Очень часто мне задают вопрос, как правильно оценить ре-
зультаты работы по описанию бизнес-процесса. Причем, чаще
всего, проблема ценообразования волнует консультантов. По-
нятно, что в нашем мире бесплатно никто не будет работать.
Но нередко попытки определить, сколько будет стоить описание
бизнес-процесса в том или ином случае, ставят начинающих
консультантов в тупик.
В принципе, это проблема знакома практически всем, кто
продает услуги. Ценообразование в продажах товаров подчи-
няется определенным правилам, там все четко и однозначно —
себестоимость плюс торговая наценка, которая позволит оку-
пить затраты и получить прибыль. Стоимость вашей работы
складывается из других составляющих. Это и потраченное вре-
мя на выполнение заказа, и ваши знания, опыт, вложения в са-
мообразование. Потому даже на одну и ту же услугу у разных
специалистов цены могут отличаться в разы.
Есть два подхода к формированию стоимости описания биз-
нес-процесса:
— Подсчет потраченного времени;
— Создание пакетов услуг.
СЧИТАЕМ ТРУДОЗАТРАТЫ: ПЛЮСЫ И МИНУСЫ
Первый вариант чаще всего используют начинающие специ-

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

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

ками, применять какие-то ранее созданные шаблоны и т. д. В резуль-
тате работа будет выполнена намного быстрее, но ведь не оцени-
вать ее дешевле, чем долгий труд новичка? Да, частично разницу
компенсирует повышение стоимости часа работы, при оценке можно
не учитывать то, что в реальности будут применяться готовые реше-
ния. Но все же, многим профессионалам такой вариант не нравится.
ПАКЕТЫ УСЛУГ: ПРОФЕССИОНАЛЬНЫЕ

РЕШЕНИЯ
Вы, как потребитель, скорей всего, много раз видели подоб-

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

и т. д.
КАКОЙ ПОДХОД ВЫБРАТЬ?
Я считаю, что начинающим специалистам больше подходит

вариант с подсчетом трудозатрат, т.е. потраченного времени.
Этот метод ценообразования проще, при необходимости вы без
проблем сможете обосновать заказчику выставленную сумму.
Кроме того, он дисциплинирует и учит грамотно оценивать свои
силы. Любая ошибка при оценке необходимого времени будет,
как говорится, «бить вас рублем».
Со временем подход стоит пересмотреть. Когда вы накопите
собственную статистику и поймете, по какому признаку вам
удобно делить заказы на тарифы, переходите к пакетам услуг.
В результате вам не придется каждый раз оценивать объем ра-
боты и рассчитывать сумму, а это — заметная экономия вашего
времени. Заказчики будут сразу видеть стоимость работ и ори-
ентировочный результат, что также значительно снижает количе-
ство вопросов из серии «почему так дорого» или «на чем осно-
ваны ваши цены».
Кроме того, разработка готовых пакетов позволяет разме-
стить их на сайте вашей компании или на сторонних сервисах
в «магазинах услуг». О том, насколько эффективен этот метод
привлечения клиентов, думаю, маркетологам, бизнесменам и,
тем более, консультантам рассказывать не имеет смысла.
141
ПРИМЕР ПРОЦЕССНОГО
ПОДХОДА: ПРЕДПРОЕКТНОЕ
ОБСЛЕДОВАНИЕ
ПРОМЫШЛЕННОЙ КОМПАНИИ.
ПРИМЕР BPMN ДИАГРАММЫ
Диаграмма в формате BPMN процесса «Продажа товара»
В прошлых разделах я обещал привести примеры примене-

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

ния программных продуктов).
Сфера деятельности компании: Производство и продажа
промышленного оборудования.
Штат компании: около 50 человек.
СТРУКТУРА КОМПАНИИ
Работой с покупателями занимаются три отдела продаж,

каждый из которых ведет собственное направление, c названия-
ми, принятыми в организации:
— Выс***
— Промы***
— Терм***
Кроме того, в работе с клиентами участвует испытательный

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

которые рассматриваться здесь не будут.
ПОСТАВЛЕННЫЕ ЗАДАЧИ
По результатам обследования работы компании был выяв-

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

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

они должны быть направлены. В остальном бизнес-процесс ра-
боты с клиентами полностью идентичен.
После регистрации в системе все запросы должны быть об-
работаны ответственным лицом, в обязанности которого входит
сортировка и назначение отдела продаж для каждого запроса.
Эту работу необходимо проводить не менее 2 раз в день.
А по возможности — по мере поступления.
РОЛИ СОТРУДНИКОВ В ОТДЕЛЕ ПРОДАЖ
В отделе продаж предусмотрено две основные роли:

— Менеджер по продажам (продавец);
— Руководитель отдела продаж.
Менеджер выполняет основную работу по взаимодействию

с клиентом в обычном режиме, когда нет никаких особых слож-
ностей, потребностей, других отклонений от стандартной схемы
продаж.
Руководитель:
144
— распределяет поступающие обращения,

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

в учетной системе, отслеживается своевременность выполнения
поставленных задач продавцами, проводится выборочный теле-
фонный опрос клиентов о степени их удовлетворенности рабо-
той продавцов. В нестандартных ситуациях или в случае, когда
менеджер явно не справляется с поставленной задачей, руково-
дитель отдела продаж подключается непосредственно к процес-
су продажи, выявляет причины проблемной ситуации и находит
решение.
ВХОДЯЩИЕ КАНАЛЫ
Заявки поступают по следующим каналам:

— телефон;
— email;
— сайт компании.
При этом вся информация с сайта отправляется через email

в автоматическом режиме. А потому по факту в CRM-системе
нужно реализовать два канала: телефон и электронная почта.
Для работы с телефонными звонками наиболее подойдет
система МИКО. Каждый входящий звонок необходимо фиксиро-
вать. И в случае если телефон отсутствует в базе данных, т.е.
звонит новый потенциальный клиент, для звонка автоматически
должен создаваться лид.
Email-письма необходимо загружаться в CRM-систему на ос-
нове одного из шаблонов:
— Переписка в онлайн-чате JivoSite;
— Форма обратной связи сайта;
— Электронные письма от потенциальных клиентов, написанные
вручную.
— При загрузке email-обращения в CRM-систему аналогично прово-
145
дится проверка на соответствие контактного почтового адреса базе

данных. И в случае выявления запроса с неизвестного адреса авто-
матически формируется лид и обращения.
ОПИСАНИЕ БИЗНЕС-ПРОЦЕССОВ
1. Регистрация лида
Лид — это потенциальный клиент, который проявил интерес

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

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

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

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

клиента с учетом текущих возможностей компании и других
нюансов.
В зависимости от особенностей клиента возможны два ва-
рианта сотрудничества:
— Составление и отправка коммерческого предложения, по резуль-
татам рассмотрения которого заключается договор, выставляется
счет. Либо клиент отказывается и получает статус «не годный». В по-
следнем случае руководитель также получает задачу проверить ка-
чество работы продавца.
— Счет на оплату (договор) без этапа согласования.
В Сделке отражаются потребности и запросы клиента, т.е. любые по-
желания, которые обсуждаются и являются объектом переговоров.
После согласования всех вопросов работа переходит в один из двух
вариантов:
147
— Отгрузка со склада. В случае, если все необходимое оборудова-

ние уже имеется на складах компании.
— Заказ на производство. Если часть оборудования необходимо из-
готовить.
Важно учитывать: если список товаров в заказе клиента со-

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

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

— климатич**;
— имит***
Аттестация проводится специальными организациями

и необходима для проверки соответствия оборудования заяв-
ленным параметрам.
Для других видов оборудования этот этап не нужен.
4. Сервис
148
После завершения продажи и пуско-наладочных работ кли-

енту предлагается сервисное обслуживание. А потому Сервис —
обязательная стадия Сделки, при переходе на которую Мене-
джеру формируется задача «Предложить сервис», а в случае по-
лучения согласия — «Заключить контракт на сервисное обслу-
живание».
После проведения переговоров о Сервисном обслуживании,
получении оплаты и всех подтверждающих бухгалтерских доку-
ментов Сделка закрывается.
РЕАЛИЗАЦИЯ БИЗНЕС-ПРОЦЕССА ПРОДАЖИ

В 1С
Для того, чтобы реализовать предложенные решения в про-

граммной системе 1С, потребуются следующие инструменты:
— Справочник «Обращения», в котором должны регистрироваться
входящие запросы потенциальных клиентов. Для существующих
клиентов новые «обращения» (лиды) создаваться не будут. Запрос
от существующего контрагента должен добавляться в историю пере-
писки с клиентом, а уведомление о новом запросе получит мене-
джер, ответственный за работу с этим контрагентом.
— Тип клиента «Лид» в справочнике Контрагентов (дополнительно
к существующим по умолчанию «Партнер» и «Контрагент»).
— Документ «Сделка» с перечнем товаров, количества, сроков и дру-
гой важной информацией. Основные параметры сделки:
— Область применения;
— Тип оборудования (насосы, компрессоры);
— Тип обрабатываемых материалов.
— Печатная форма «Коммерческое предложение» должна формиро-
ваться автоматически на основе указанных в Сделке параметров.
— Заказ покупателя — документ, автоматически создается на основе
согласованного списка товаров в Сделке.
— Заказ на склад, Заказ на производство. Заказ поставщику — фор-
мируются автоматически на основе Заказа покупателя:
— Если товар есть на складе, формируется «Заказ на склад» для ре-
зервирования и последующей отгрузки товаров.
— Если товар необходимо изготовить, формируется «Заказ на произ-
водство».
149
— Если товара нет на складе и предприятие его не изготавливает,

формируется «Заказ поставщику».
— Документы реализации товаров и услуг. Пакет документов для от-
грузки и оплаты готового заказа. Должны быть привязаны к сделке
и формироваться на ее основе.
ЗАДАЧИ И МЕТОДЫ РЕШЕНИЯ ПРИ

АВТОМАТИЗАЦИИ ОТДЕЛА ПРОДАЖ
Действия, которые необходимо выполнить для внедрения

автоматизации продаж:
Переход с текущей версии системы 1С в конфигурацию «1С
Торговля УТ 14» с переносом данных:
— Остатки по товарам на складах;
— Справочники товаров и клиентов;
— Остатки по взаиморасчетам;
— Незакрытые заказы покупателей.
Доработать систему 1С УТ 11.4 согласно описанному выше

перечню решений.
— Подключение модуля «МИКО» для регистрации телефонных звон-
ков в 1С.
— Подключение к системе УТ 11 электронную почту.
— Составить инструкции по работе с системой для руководителя от-
дела продаж и для менеджера.
— Обучение персонала работе с новой системой (проведение тре-
нингов).
— Ввод системы в эксплуатацию.
— Автоматизация работы отдела маркетинга
— На основе контактных данных лидов и клиентов автоматически
формируется база данных email, по которым отдел маркетинга дол-
жен проводить рассылки.
Для этого необходимо создать выгрузку из 1С адресов email

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

дет периодически выполняться по запросу отдела маркетинга.
Кроме того, на основе полученных данных маркетологи
должны иметь возможность поставить перед тем или иным ме-
неджером задачу — Звонок клиенту.
ЗАДАЧИ И МЕТОДЫ РЕШЕНИЯ ДЛЯ ОТДЕЛА

МАРКЕТИНГА
Действия, которые необходимо выполнить для внедрения

автоматизации:
— Написать выгрузку контактных данных клиентов в разрезе вы-
бранных сегментов в файл Excel для последующей загрузки
в MailChimp.
— Написать выгрузку контактных данных клиентов в разрезе вы-
бранных сегментов (компания, контакты, телефоны и т.д.) для после-
дующей комфортной работы маркетологов при планировании теле-
фонного маркетинга.
— Написать инструкцию по работе для маркетологов.
— Провести обучение персонала (тренинг).
— Автоматизация работы склада
Для повышения эффективности работы склада необходимо прове-
сти работу по нескольким направлениям:
— Провести автоматизацию на базе штрих-кодирования.
— Автоматизировать учет по срокам годности: организовать посе-
рийный учет с использованием штрих-кодов. Этот вид учета необхо-
дим для того, чтобы товары, имеющие определенный срок годности.
продавать по мере их поступления. Такой подход поможет значи-
тельно снизить объемы списания просроченных товаров.
— Задачи и методы решения для автоматизации склада
Для выполнения поставленной задачи необходимо:
— Закупить оборудование для штрих-кодирования и сканирования
штрих-кодов;
— Настроить конфигурацию 1С для работы с штрих-кодами с учетом
серий (партий) поступления товаров: первым должны продаваться
остатки из самой старой серии.
— Обучить сотрудников склада.
151
ГЛОССАРИЙ
Лид — это потенциальный клиент. Чаще всего лид выглядит

как входящий запрос или зафиксированный менеджером инте-
рес, который потенциальный клиент проявил к вашей компании.
В CRM лид фиксируется в виде контактных данных человека,
проявившего интерес к вашим продуктам, а также информации
о сути запроса: что именно его заинтересовало, на какие вопро-
сы нужно дать ответ.
Контакт — это информация о человеке, с которым менеджер
ведет переговоры. Его ФИО, важная информация и контактные
данные.
Клиент — это организация или физическое лицо, которое яв-
ляется покупателем (заказчиком) товаров и услуг. Это может
быть организация, предприниматель, физическое лицо (конеч-
ный потребитель). От имени клиента может работать один чело-
век или несколько, это может быть один магазин (склад, офис,
квартира) или разные. Но при этом клиент — один, т.е. есть об-
щее руководство и финансирование.
Сделка (Потенциальная сделка) — это предложение, отправ-
ленное клиенту. В ней фиксируется сумма, обязательства сторон
и другие важные подробности. Обычно сделка создается при от-
правке коммерческого предложения или обсуждении подробно-
стей будущего контракта в устной форме для того, чтобы зафик-
сировать договоренности. После заключения договора и/или
получения оплаты сделка считается состоявшейся.
Стадии (статусы) сделки — это параметр, который отвечает
на вопрос, что именно сейчас происходит в сделке, в какой ста-
дии находятся переговоры, какой этап работы по тому или ино-
му потенциальному заказу ведет в текущее время менеджер.
Стадии сделки необходимы фиксации текущего этапа и плани-
рования последующей работы по этой сделке.
Учетная система 1С — это наиболее популярное в РФ
и других постсоветских странах программное обеспечение для
автоматизации учета различных процессов на предприятии. Су-
152
ществует множество конфигураций 1С, предназначенных для

работы бухгалтерии, кадров, управления производством, тор-
говлей, складом и т. д.
Конфигурация 1С УТ 11 — акутальная версия конфигурации
программного продукта 1С «Управление торговлей».
IP-телефония — это телефонная связь через интернет,
по протоколу IP. Под IP-телефонией подразумевается набор ком-
муникационных протоколов, VoIP оборудования, программного
обеспечения, технологий и методов, обеспечивающих традици-
онные для телефонной связи функции: набор номера, дозвон
и двустороннее голосовое общение, а также видео-общение
по сети Интернет или любым другим IP-сетям.
153
ПОСЛЕСЛОВИЕ
Вот вы и прочли книгу, в которой я постарался поделиться
с вами опытом и знаниями, которые необходимы для описания
бизнес-процессов. Я искренне надеюсь, что сумел максимально
просто и понятно рассказать даже о самых сложных вещах. Я
уверен, что для настоящего понимания нет необходимости пи-
сать сложным академическим языком. Подобных учебников
много, а количество вопросов, в том числе, от студентов, кото-
рые штудировали эти труды, меньше не становится.
Моя цель — описывать все нюансы работы максимально до-
ступно. Так, как я пишу для своих клиентов. А они, можете быть
уверены, никогда не занимались бизнес-моделированием.
И в большинстве практически ничего не знают о процессном
подходе. Надеюсь, что эта книга помогла вам. И пригодится, ко-
гда уже вы будете пояснять сложные вещи своим клиентам.
Что хотелось бы пожелать? Первое, и самое главное. Всегда
доводите дело до конца. Вы будете работать с разными людьми.
Кто-то окажется сложным и конфликтным, где-то возникнут про-
блемы с оплатой или вы сами ошибетесь при оценке сложности
работы. Как говорится, люди есть люди. И сложностей не избе-
жать. Но если вы будете бросать неоконченные проекты, убегать
от проблемных клиентов или результатов собственных ошибок,
профессионалом вам никогда не стать. Вы должны всегда дово-
дить дело до конца. И даже в самых сложных случаях помнить:
это нужно не только клиенту, результат точно также нужен вам.
И дело тут далеко не в деньгах. Вам нужно учиться и развивать-
ся, для этого необходим практический опыт. Нужны успешные
и эффективные решения, чтобы привлекать новых клиентов. По-
тому всегда, без вариантов, доводите дело до конца!
И еще один совет. Не бойтесь своих решений. На самом деле,
моделирование бизнес-процессов — работа творческая. Редко,
154
когда два специалиста предложат одинаковые решения одной

и той же задачи. Каждый из нас думает по-своему, понимает по-
ставленную задачу тоже немного по-своему, делает акценты
на разных нюансах работы и т. д. Одинаковыми могут быть, разве
что, типовые описания самых простых и распространенных про-
цессов. Во всех остальных случаях, вы — творец. Вы имеете пра-
ва на свой взгляд и свой особый подход. Потому не бойтесь ре-
шать сложные задачи, не бойтесь своих, даже самых необычных
решений. Если вы понимаете, что это — правильно и будет рабо-
тать, смело предлагайте заказчику.
Что ж. На этом пришла пора прощаться. Успехов в изучении
бизнес-моделирования и удачной работы!
155
ГЛОССАРИЙ
BPMN (англ. Business Process Model and Notation, нотация
и модель бизнес-процессов) — это система условных обозначе-
ний и их описания в XML для моделирования бизнес-процессов.
Один из языков бизнес-моделирования.
Бизнес аналитик — сущность, представляющая человека или
людей, которые моделируют бизнес процесс и могут в отдель-
ных случаях предоставлять рекомендации по улучшению бизнес
процесса. В большинстве случаев изначально не компетентны
в процессе и не имеют права принятия решения.
Бизнес-процесс — это логическая последовательность дей-
ствий человека (или нескольких человек) в коллективе. Цель
описания бизнес-процесса — анализ и регламентация тех или
иных действий в коллективе.
Бизнес-процесс (процесс) — это последовательность собы-
тий и действий, которые имеют начало и конец. Эту последова-
тельность необходимо выполнить, чтобы получить определен-
ный результат.
Клиент — это Контакт, который из потенциального перешел
в разряд реальных клиентов. В данном конкретном случае кон-
такт становится клиентом после оформления и подтверждения
Записи на услугу
Компьютерная информационная система — это идея, выра-
женная посредством языка программирования.
Контакт — это Лид, который в процессе общения проявил
явную заинтересованность в товарах и услугах компании. Лид
становится Контактом после того, как подтверждается интерес
и начинается процесс переговоров.
Лид — потенциальный клиент, тем или иным образом отреа-
гировавший на маркетинговую коммуникацию. Термином лид
стало принято обозначать потенциального покупателя, контакт
156
с ним, полученный для последующей менеджерской работы

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

моделей бизнеса.
158
ОГЛАВЛЕНИЕ
Введение 3
Моделирование бизнеса. Основные подходы 7
Основные подходы 7
Методология и языки бизнес-моделирования 12
Отличие языков разработки бизнес-моделей от языков
проектирования систем 13
Преимущества разработки моделей бизнеса 14
Применение моделей бизнеса на практике 14
Что такое бизнес-процесс и описание бизнес-процесса 16
Определение бизнес-процесса 16
Описание бизнес процесса 17
Технологический процесс и бизнес-процесс 19
История появления термина 20
Зачем моделировать (описывать) бизнес-процессы 23
Распространенные мифы и заблуждения 24
Бизнес процессы — это не только про бизнес 27
Декомпозиция или подпроцесс? 29
Декомпозиция 29
Подпроцесс 30
Разбираемся с понятием BPM. Что такое управление
бизнес процессами 32
Как появилось BPM 33
Об управлении бизнес-процессами простыми словами 34
Исполняемые и неисполняемые бизнес процессы 35
Описание работы с BPM 36
Жизненный цикл процесса в BPM 37
Плюсы и минусы BPM 37
Каким компаниям подходит BPM 39
Вопросы и ответы 39
Что такое BPMS 41
Что такое BPMS? 41
Работа пользователей в BPMS и других системах 42
Способы реализации бизнес-процессов 43
Использование процессного подхода. Разработка ПО 50
«Подводные камни» планирования в сфере IT 50
Идея и выбор программных продуктов 52
Как создается BPMN модель 53
Выбор программного продукта 54
Что такое нотации бизнес процессов 56
Цели моделирования 56
Графика против текста 57
Какие бывают нотации 58
Выбор языка моделирования 59
В каком порядке моделировать 60
Насколько важно знать сферу деятельности при
моделировании 61
Подведем итоги 62
IDEF0. Знакомство с нотацией и пример использования 63
Несколько слов о преимуществах графики 63
Почему это важно для работы консультанта 65
Что такое нотация описания бизнес-процессов 66
Что такое IDEF0? 67
Функциональная модель компании 67
Пример создания функциональной модели IDEF0 69
Как создавать нотации IDEF0 72
Типичные ошибки 74
Выгоды использования IDEF0 76
В чем трудность применения IDEF0 77
Что такое BPMN: изучаем нотацию 79
BPM: основные понятия 80
Язык описания бизнес-процессов 81
Немного истории BPMN 82
Из чего состоит нотация BPMN? 84
Исполняемые и неисполняемые бизнес-процессы 90
Подходит ли BPMN для малого и среднего бизнеса? 92
Минусы и важные особенности BPMN 93
Пример практического применения BPMN 93
Как разрабатывать диаграммы BPMN на практике? 95
Как описать бизнес-процесс 98
1. Описать цель описания бизнес процесса 99
2. Описать цели бизнес процесса 99
3. Поговорить с руководством отделов, которые работают
в бизнес процессе 100
4. Поговорить с сотрудниками 101
5. Выявить наиболее важные задачи в бизнес-процессе 101
6. Выявить начало и конец процесса 102
7. Составить список задач с условиями 102
8. Сделать первый вариант бизнес процесса 103
9. Обсудить детали с руководством и с ключевыми
сотрудниками 104
10. Представить финальный вариант 104
11. Подготовить текстовое описание бизнес процесса 104
Правила описания бизнес-процесса 105
Вопросы и ответы 107
Описание бизнес процессов. Использовать осторожно 109
Как создается описание бизнес процесса 109
Немного о терминах 110
Зачем нужен приглашенный бизнес-аналитик? 111
Пример. Автоматизация интернет-магазина 112
Основные причины ошибок и проблем 115
Простое решение проблемы: цените людей 117
Будьте осторожнее с технологиями 118
Бизнес моделирование и IT-сфера 119
Заблуждения и мифы о бизнес процессах 121
Описание бизнес-процессов Как есть (AS IS) и Как должно
быть (TO BE) 126
Описывать нечего 126
Описывать незачем 127
Зачем создают нотации AS IS? 128
Должен ли знать консультант процессы на уровне людей
непосредственно работающих с этими процессами 129
Из собственного опыта 129
Не пытайтесь стать сотрудником 130
А как же тогда автоматизировать? 130
Ответственность бизнес-консультанта 133
Кто занимается внедрением? 134
Консультант в штате или приглашенный специалист 134
А если мы понесем в результате убытки? 135
Консультант — это советчик 136
Ответственность заказчика 136
От переговоров к результату 138
Трудоемкость и цена описания бизнес-процесса 139
Считаем трудозатраты: плюсы и минусы 139
Пакеты услуг: профессиональные решения 140
Какой подход выбрать? 141
Пример процессного подхода: предпроектное
обследование промышленной компании. Пример BPMN
диаграммы 142
Структура компании 143
Поставленные задачи 143
Роли сотрудников в отделе продаж 144
Входящие каналы 145
Описание бизнес-процессов 146
Реализация бизнес-процесса продажи в 1С 149
Задачи и методы решения при автоматизации отдела
продаж 150
Задачи и методы решения для отдела маркетинга 151
Глоссарий 152
Послесловие 154
Глоссарий 156
Рамиль Кинзябулатов
Моделирование бизнес-процессов. От идеи

к результату
Создано в интеллектуальной издательской системе Ridero

Язык

Моделирование Бизнес-процессов. От Идеи к Результату

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Моделирование Бизнес-процессов. От Идеи к Результату

Загружено:

Авторское право:

Доступные форматы

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

Шрифты предоставлены компанией «ПараТайп»

Автор рассказывает простым и понятным языком, что такое моделирование

0+ В соответствии с ФЗ от 29.12.2010 №436-ФЗ

ISBN 978-5-0050-3659-9 © Рамиль Кинзябулатов, 2019

После долгих поисков метода работы по проекту я в конеч-

началу я и сам так работал. Но потом понял, что на самом деле,

тории. А потому может стать прекрасным помощником в реше-

Сегодня существует множество различных инструментов для

На самом деле, конечно, существуют и другие подходы, их

Пример функционального моделирования в формате IDEF0

много так же, как и языков моделирования. Но они большей

Пример процессного моделирования в формате BPMN

клиента или лид», точка вывода — желаемый результат: «покуп-

стью согласен, что существует множество языков моделирования

Пример ментальной карты

довательности действий, которые мы можем в дальнейшем пе-

Ментальный подход (ментальные карты)

— Не нужно знать какие-то специальные языки;

Минусом подхода является отсутствие устоявшегося подхода

МЕТОДОЛОГИЯ И ЯЗЫКИ БИЗНЕС-

Очень часто даже в профессиональной литературе возника-

ствами С++ совсем не обязательно, что именно этот язык будет

ОТЛИЧИЕ ЯЗЫКОВ РАЗРАБОТКИ БИЗНЕС-

Существует целое семейство языков проектирования систем,

ПРЕИМУЩЕСТВА РАЗРАБОТКИ МОДЕЛЕЙ

И все же, зачем применять языки бизнес-моделирования,

— Скорость разработки моделей значительно увеличивается. Языки

— Снижается число возможных ошибок. Сами элементы системы уже

ПРИМЕНЕНИЕ МОДЕЛЕЙ БИЗНЕСА

Лично я считаю, что бизнес-моделирование стоит применять

Кроме того, наглядные схемы бизнес-моделей помогают мне

Итак, в чем же разница между бизнес-процессом и функций

Почему я делаю особый упор на людях и коллективе:

— Бизнес-процесс всегда происходит с участием человека. Если

— В бизнес-процессе всегда задействованы несколько людей в яв-

Почему я пишу именно о коллективе, а не о коммерческой

ОПИСАНИЕ БИЗНЕС ПРОЦЕССА

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

И здесь необходимо понимать, что бизнес-процесс без опи-

Описание бизнес-процессов — работа творческая. Даже ес-

ТЕХНОЛОГИЧЕСКИЙ ПРОЦЕСС И БИЗНЕС-

Главное отличие бизнес-процесса от технологического за-

Все однозначно и никаких условных «вилок» не предусмат-

Т.е. уже в алгоритме процесса предусмотрены возможные

ИСТОРИЯ ПОЯВЛЕНИЯ ТЕРМИНА

Я не единожды читал информацию о том, что нотации биз-

док введения и обработки информации. Если до начала автома-

Очень быстро методология и нотации завоевали огромную

С их помощью оказалось возможным оптимизировать биз-

ЗАЧЕМ МОДЕЛИРОВАТЬ (ОПИСЫВАТЬ) БИЗНЕС-

Как я уже не единожды писал, я работаю преимущественно

— Обеспечение наглядности. Как известно, «одна картинка стоит ты-

Сочетание изучения истории появления термина с моим

Представьте себе обычную компанию, состоящую из разных

РАСПРОСТРАНЕННЫЕ МИФЫ И ЗАБЛУЖДЕНИЯ

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

Нередко люди вместо того, чтобы изучить особенности су-

Во многих автоматизированных системах, например, 1С или

О том, что бизнес-процессы должны приносить прибыль, я

Нет. Бизнес — процесс должен быть простым, понятным,

ше. А нередко и клиенты меня просили детализировать и опи-

Бизнес-процессы можно и нужно применять везде, где тре-