Что такое бизнес процессы: Что такое бизнес-процесс и описание бизнес процесса / Trinion corporate blog / Habr – Что такое бизнес-процессы: основные понятия и определения

процесс — это… Что такое Бизнес-процесс?

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

Описание

Существуют три вида бизнес-процессов:

1. Управляющие — бизнес-процессы, которые управляют функционированием системы. Примером управляющего процесса может служить Корпоративное управление и Стратегический менеджмент.
2. Операционные — бизнес-процессы, которые составляют основной бизнес компании и создают основной поток доходов. Примерами операционных бизнес-процессов являются Снабжение, Производство, Маркетинг и Продажи.
3. Поддерживающие — бизнес-процессы, которые обслуживают основной бизнес. Например, Бухгалтерский учет, Подбор персонала, Техническая поддержка, АХО.

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

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

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

Бизнес-процессы могут подвергаться моделированию с помощью различных методов. Одним из способов является составление модели бизнес-процесса «как есть» (англ. as is). После этого модель бизнес-процесса подвергается критическому анализу или обрабатывается специальным программным обеспечением. В результате строится модель бизнес-процесса «как должно быть» (англ. to be). Некоторые консультанты опускают фазу «как есть» и сразу предлагают модель «как должно быть».

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

workflow.

Операграмма

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

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

См. также

Виды бизнес процессов и их составляющие

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

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

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

Существует 3 вида процессов:

• Основные процессы. Основные процессы направлены на производство товаров и услуг для конечного потребителя, т.е. именно для того, кто в итоге покупает и использует результаты процесса. Основные процессы создают добавочную стоимость. Результат процесса (его продукт) добавляет ценность конечному продукту. К примеру, помимо непосредственно производства, нам необходимо еще “упаковать” жидкость для мыльных пузырей так, чтобы это понравилось клиенту. Упаковка добавляет ценность продукту, а значит, данный процесс является основным.
• Вспомогательные процессы. Этот вид бизнес процессов обеспечивают всю компанию ресурсами и позволяет основным процессам выполнять свою работу. В компании «Мама» такими процессом является подготовка ингредиентов для жидкости.
• Процессы управления. Это все процессы, связанные с вопросами управления ходом процесса, его результатами и организацией в целом. При изготовлении жидкости используется процесс управления по названием «Рецепт». Да, да, определение рецепта, конкретных ингредиентов и их пропорций управляет всем процессом.

Виды бизнес процессов и цепочка ценности

 

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

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

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

Понятие бизнес процесса

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

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

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

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

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

Внутренние поставщики

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

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

Клиент и бизнес процесс

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

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

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

• Количество производимой жидкости в час (или другой промежуток времени)
• Расход сырья на литр жидкости
• Крепость получаемых пузырей
• И т.д.

Показатели делят на 3 вида: показатели процесса, показатели продукта процесса и показатели удовлетворенности клиента. Такое деление необходимо для того, чтобы понимать и не забывать, что и где измерять. Мы еще будем об этом говорить.

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

Подведем небольшой итог:

1. Бизнес процесс – это цепочка действий, которая выполняется в определенном порядке.
2. Бизнес процесс имеет начало и окончание.
3. В основе бизнес процесса лежит цель удовлетворения потребности клиента. Для этого производится продукт, который использует клиент процесса.
4. Если продукт никто не использует – процесс не имеет смысла.
5. Для производства бизнес процесс использует ресурсы, которые получаются от поставщиков бизнес процесса.
6. Владелец бизнес процесса несет всю ответственность за его ход, результаты и удовлетворенность клиента. Владелец должен быть обязательно!
7. Для управления процессом необходимо измерять его показатели.
8. Процесс должен многократно и устойчиво производить продукт с одинаковым качеством.

Вернуться на главную страницу?

Автоматизация бизнеса (бизнес-процессов) простыми словами / Habr

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

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

Чтобы это понять, давайте просто разберем автоматизацию бизнес-процесса на части.

Итак, бизнес-процесс.
Что такое бизнес всем понятно.
А вот к процессу присмотримся внимательнее.

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

Именно наличие этапов (шагов, пунктов) дает нам возможность автоматизировать процесс. Каким образом?

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

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

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

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

Последовательность достаточно проста, если в нее не углубляться и не изощряться.
Учтите только, что потомство будет заводится в рамках семьи.

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

Событие – то, что произошло.

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

Например:

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

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

Соответственно, что у нас есть?

1. Этапы процесса.
2. Событие, после которого процесс переходит на следующий этап.
3. События, которые происходят во время этапа.

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

Процесс состоит их этапов.
У каждого этапа есть начало и конец.
Мы знаем, когда конец каждого этапа (по действию после которого процесс переходит на следующий этап).
Если мы знаем конец одного этапа, то мы знаем, когда происходит начало следующего этапа.
Также мы знаем последовательность действий, которые происходят во время этапа.

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

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

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

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

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

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

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

Таким образом, получается все просто.

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

Для примера опишу часть процесса.

Вы получили согласие на свидание.
Система ставит вам задачу – “пойти на свидание и поцеловать”

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

Я ей указываю, что произошло и дальше она действует сама.

ОТШИЛА — система закрывает этот процесс.
УСПЕШНО ПОЦЕЛОВАЛ – система переводит процесс на этап “отношения” и ставит следующую задачу.
ХОРОШО, НО БЕЗ ПОЦЕЛУЯ – система ставит задачу “назначить свидание”.
НЕ ПОДХОДИТ МНЕ — система закрывает этот процесс.

Краткое описание BPMN с примером / Trinion corporate blog / Habr

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

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

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

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

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

Лично я познакомился впервые с BPMN около восьми лет назад, когда начал изучать систему Bizagi Modeler. Заинтересовался я этой системой по причине того, что давно уже понимал всю важность моделирования. До этого я лично пользовался IDEF0 и IDEF3, но там я сталкивался с определенными ограничениями. Дело в том, что IDEF0 несколько ограничен по числу возможностей. А IDEF3 мне лично показался излишне строгим и «сухим», в нем было сложно моделировать многие виды бизнес-процессов с участием программных продуктов.

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

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

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

BPM: ОСНОВНЫЕ ПОНЯТИЯ

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

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

Есть и еще одно понятие, о котором стоит сразу упомянуть – это «BPMS», т.е. Business Process Modeling System. Этот термин описывает те самые системы управления, в которых производится моделирование, а также исполнение бизнес-процессов.

Можно сказать, что BPMN является частью двух важнейших составляющих:

• BPM (Business Process Modeling) – это та среда, где вы занимаетесь непосредственно моделированием. Самостоятельно или в команде.
• BPMS (Business Process Modeling System) – это инструменты для исполнения созданных вами моделей. Это может быть Bizagi, Comundo,ELMA и пр.
• Итак, основные понятия у нас есть. Подробнее о BPM я планирую поговорить в следующих статьях.

ЯЗЫК ОПИСАНИЯ БИЗНЕС-ПРОЦЕССОВ

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

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

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

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

Например, для моделирования бизнес-процессов вам понадобится знание таких понятий, как «условия», «цикл», «декомпозиция» и т.д.

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

НЕМНОГО ИСТОРИИ BPMN

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

Первая версия 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-анализе (анализ разрывов) или для представления заказчику бизнес-модели в какой-то упрощенной форме, всего многообразия элементов BPMN вам не нужно. Но когда начинается автоматизация, когда бизнес-модель становится не просто удобной схемой, а может экспортироваться в другие программные продукты в качестве исполняемых данных, все становится на свои места. Последняя версия BPMN действительно стабильна и все требования к языку обоснованы.

ИЗ ЧЕГО СОСТОИТ НОТАЦИЯ BPMN?

И здесь я хочу сделать небольшое отступление. Дело в том, что перевод терминов и понятий с английского языка на русский – занятие сложное. Найти наиболее точное слово обычно может специалист, но переводом занимается совсем другой человек, часто вообще не имеющий понятия о сути тех понятий, которые он переводит. В результате появляется множество неточностей, понятия усложняются, возникает путаница. Об особенностях перевода и сложностях применения терминов в сравнении с графикой я уже писал, например, в статье Знакомство с нотацией IDEF0 и пример использования (см. раздел “Несколько слов о преимуществах графики”).

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

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

Язык описания бизнес-процессов опирается на следующие базовые объекты:

• Event – Событие;
• Activity – Действия;
• Gateway – Шлюзы или Развилки;
• Flow – Поток.
• Date – Данные;
• Artefact – Артефакты;
• Swimline – «плавательные дорожки»;
• Pool (Пул) — набор.

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

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

EVENT (СОБЫТИЕ)

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

Например, опишем процесс получения заказа от клиента по телефону:

• Событие Старт – это входящий звонок от клиента.
• Событие Финиш – это отправка готового расходного документа на печать.

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

ACTIVITY (ДЕЙСТВИЯ)

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

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

Обычно действия делят следующим образом:

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

GATEWAY (ШЛЮЗ, РАЗВИЛКА)

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

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

FLOW (ПОТОК) И MESSAGE FLOWS (ПОТОК СООБЩЕНИЙ)

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

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

Message Flows Association – еще один вид линий, в отличие от сообщений, которые являются пунктирными линиями, этот вариант отображается в виде последовательности не отрезков, а точек. Необходима для того, чтобы показывать артефакты (о них – ниже).

POOL (ПУЛ)

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

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

DATE OBJECT (ДАННЫЕ, ОБЪЕКТЫ ДАННЫХ)

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

MESSAGE (СООБЩЕНИЕ)

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

ARTEFACT (АРТЕФАКТЫ)

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

Выделяют два вида артефактов:

• Object Group (Группа объектов)
• Text Annotation (Текстовая аннотация)

Object Group (Группа объектов) – это еще одна возможность объединить под общим символом несколько элементов, чтобы сэкономить место на диаграмме и повысить простоту ее восприятия. Здесь собираются различные активности под одним общим названием. Группу объектов также всегда можно рассмотреть детально. Группа выглядит как прямоугольник с закругленными углами, выполненный штриховой линией с точками.

Text Annotation (текстовые аннотации) применяют для различных уточнений к диаграмме. Это могут быть комментарии, пояснения, другая информация, которая повысит читабельность диаграммы. Аннотации – это незакрытый прямоугольник, выполненный сплошной линией, от которого к объекту аннотации ведет линия, состоящая из точек.

ИСПОЛНЯЕМЫЕ И НЕИСПОЛНЯЕМЫЕ БИЗНЕС-ПРОЦЕССЫ

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

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

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

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

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

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

ПОДХОДИТ ЛИ BPMN ДЛЯ МАЛОГО И СРЕДНЕГО БИЗНЕСА?

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

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

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

МИНУСЫ И ВАЖНЫЕ ОСОБЕННОСТИ BPMN

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

• Система имеет значительное количество понятий и терминов, их нужно знать и применять грамотно.
• Высокий уровень вхождения. Как и любой инструмент с широкими возможностями требует большего времени на изучение, по сравнению с другими нотациями (IDEF0, IDEF3).
• Необходимо знание бизнес-анализа. В BPMN модели — это не просто картинки или схемы, которые вы можете нарисовать в любом графическом редакторе. Здесь очень важна грамотная структура и четкая последовательность.

ПРИМЕР ПРАКТИЧЕСКОГО ПРИМЕНЕНИЯ BPMN

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

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

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

1. Менеджер по продажам получает информацию о потребностях клиента (заказ).
2. В системе CRM создается документ Заказ покупателя.
3. Если нужные товары есть в наличие, то менеджер создает расходный документ в программе учета. Если товара нет в наличии, менеджер делает запрос в отдел закупки.
4. Отдел закупки оформляет запрос поставщикам на получение товара.

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

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

Точкой входа служит получение заказа от покупателя. Точкой выхода – «резервирование товара».

Обратите внимание, что после получения заказа стрелка ведет к этапу-ромбу, т.е. условию:

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

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

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

КАК РАЗРАБАТЫВАТЬ ДИАГРАММЫ BPMN НА ПРАКТИКЕ?

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

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

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

Что еще хотелось бы посоветовать:

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

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

Еще статьи по данной теме:

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

Классификация бизнес-процессов. Понятие и виды бизнес-процессов :: BusinessMan.ru

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

1. Основные — связаны с производством главных продуктов компании (товаров или услуг):

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

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

• управление персоналом;
• управление финансами;
• управление логистикой и т. п.

3. Управляющие – HR, корпоративное управление, управление качеством и т.п.:

• стратегические;
• процессы планирования;
• контролирующие.

В некоторых источниках данную классификацию называют и описывают как структурные бизнес-процессы. Во главе угла – корпоративная структура.

Другие классификации бизнес-процессов

Процессы можно группировать по степени их сложности:

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

Виды бизнес-процессов по принципу иерархии:

• Индивидуальные горизонтальные процессы – действия отдельных сотрудников.
• Межфункциональные горизонтальные процессы – пограничные взаимодействия сотрудников «соседних» отделов.
• Горизонтальные процессы – взаимодействие по горизонтали.
• Вертикальные процессы – взаимодействие по вертикали (чистая иерархия).
• Интегрированные процессы – цепочки действий сотрудников по вертикали и горизонтали одновременно.

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

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

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

Процесс – продвижение, течение, ход событий. Это превращение «входа» в «выход».

Бизнес-процесс – фиксированная на носителе последовательность действий людей в коллективе для анализа, регламентации и оптимизации.

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

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

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

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

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

• управление взаимоотношениями с поставщиками;
• непосредственное производство продукта;
• доставку продукта клиенту;
• риск-менеджмент;
• управление взаимоотношениями с клиентами;
• проектирование новых продуктов.

Вспомогательные бизнес-процессы

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

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

Управляющие процессы

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

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

Управляющие процессы – единственный вид процессов, к которым можно применить типовую структуру. Модель процесса одна и та же, а объекты управления – разные: это может быть управление персоналом, управление финансами, управление планированием и т. д. Что же касается типовой модели управляющих бизнес-процессов, то она следующая:

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

Зачем огород городить, или Суть процессного управления

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

1. Эффективного изучения и постоянного улучшения бизнеса (руководством в том числе).
2. Наглядности, которая поможет детально понять все виды работ людям со стороны.
3. Минимизации офисных «войн» между департаментами, так как можно прописать и согласовать все «стыковые» участки горизонтальных процессов.
4. Четкости, понятности и видимости реальных рабочих процессов для всех сотрудников. С прописанными бизнес-процессами невозможно «пустить пыль в глаза» ни начальству, ни аудиторам, ни коллегам.
5. Снижения зависимости компании от личной компетентности сотрудников, особенно звездных. В стандартизированных процессах нет имен, там есть только названия позиций и приписываемые действия.
6. Для тиражирования процессов в филиалах.

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

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

О типовых процессах

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

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

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

Принципиальные особенности процессного менеджмента

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

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

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

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

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

Как описывать процесс

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

1. Не так сложно, как может показаться.
2. Чрезвычайно увлекательно и интересно.

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

Алгоритм описания бизнес-процессов:

1. Собрать участников процесса.
2. Определить название и цель процесса.
3. Зафиксировать начало и конец процесса – первое и последнее действия.
4. Определить вход и все, что необходимо для входа (материалы, информация, другие ресурсы).
5. Определить выход (все, что должно быть получено в итоге).
6. Назвать этапы бизнес-процессов.
7. Назвать владельца процесса с полномочиями и ответственностью.
8. Точно определить и согласовать (очень важно!) исполнителя каждого этапа.
9. Уточнить сроки выполнения каждой стадии, перечислить все необходимые сопутствующие документы и формы.

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

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

Мифы, ошибки и советы

• Серьезное и распространенное заблуждение – думать, что бизнес-процессы обязательно должны быть прибыльными. Это верно, если процесс связан, например, с прямыми продажами. Нельзя говорить о прибыли в других процессах – формировании кадровой отчетности или промежуточной отгрузки товара. Добавление ценности – не есть получение прибыли.
• Не нужно писать огромные простыни с подробнейшими деталями. На такие «шедевры» даже смотреть страшно, не говоря об изучении или оптимизации. Лаконичность и простота – важнейшие требования к оформлению бизнес-процессов.
• Нельзя путать корпоративные бизнес-процессы и IT процессы, которые не имеют ничего общего друг с другом, кроме названий. Считайте IT процессы просто полными тезками, не более того.
• Нет смысла изобретать свои «авторские» способы изображения процессов. Лучше всего использовать готовые системы, например BPMN2.0 или IDEF3, которые минимизируют ошибки и помогут стандартизировать ваши процессы, чтобы они были понятными самой широкой аудитории пользователей.
• Частая ошибка – описать бизнес-процессы «как есть» и на этом успокоиться. В результате получается «описание ради описания». Исполнители забывают, что создание графических процессов – лишь инструмент для достижения главной цели: улучшений, оптимизаций, снижения затрат, увеличения доходности и т. д. Прописать бизнес-процессы – только начало. Самое интересное начинается позже.
• При анализе и корректировке бизнес-процессов ни в коем случае нельзя игнорировать внешний контекст, особенно в современном быстро меняющемся мире. Контрагенты, конкуренты, кризисы, изменения в налогах – во внешней среде мелочей нет.
• Стереотипы, связанные с японскими «легендами» о бережливом производстве, принципах производства в Тойоте, системе «кайдзен» и т. д. Не имея понятия о сути японского менеджмента качества, консультанты или сами сотрудники стараются подогнать свою новую систему бизнес-процессов под японский трафарет. Чужие трафареты никогда и никому не помогали, особенно это касается японских разработок, которые связаны, прежде всего, с особенностями культуры и менталитета.
• Слишком много внимания уделяется второстепенным деталям: подробное описание процесса заказа корпоративных обедов вряд ли сыграет какую-либо роль в повышении эффективности работы компании. Описывать и оптимизировать нужно все действия во всех отделах, но приоритеты нужно знать и соблюдать.

Как мы внедряли бизнес-процессы и зачем оно вообще надо / Мосигра corporate blog / Habr

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

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

Пример постановки процесса из 1900-х

Рабочие на заводе Форда собирают детали на конвейере. Рабочий получает 5 баксов в день и собирает 30 единиц продукции. Генри Форд в течение часа смотрит на рабочего и понимает, что тот делает много лишних действий. Он пробует сам собрать деталь по новой схеме, и понимает, что, по идее, это можно делать быстрее, но нужно чуть изменить конвейер, подвинуть оборудование, и, главное, научить рабочего совершать другие движения. Через «не хочу» он обучает этого человека делать как надо — и, вуаля! — он всё ещё продолжает получать 5 баксов в день, но производит уже 42 единицы продукции.

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

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

Хронология борьбы с бардаком

Мы прошли вот такие стадии:

1. Нас четыре человека, все всё понимают.
2. Появляется два разных магазина: уже нужны правила приёма почты и правила обязательных ответов на неё.
3. Появляются представительства в городах. Начинается систематический сбор информации для внутренних инструкций, советов и других штук, призванных помочь в разных ситуациях: по сути, позитивный опыт и наследственные коллекции грабель.
4. Усложняются взаимодействия по сайту. Разработчики поднимают трекер и систему тикетов.
5. Нас столько, что одни и те же вопросы задаются больше трёх раз. Заводится закрытый корпоративный блог, чтобы иметь возможность быть в курсе всего, быстро сообщать о проблемах, меняться механиками процессов.
6. Нанимается команда специалистов, которые планируют бизнес-процессы внутри компании, составляют точные инструкции и оргсхему. По сути, идёт процесс описания уже существующих процессов и их оптимизации там, где это нужно.
7. Вся эта радость дотачивается под ситуации.

Нужны ли процессы, если команда из 10 человек?

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

Пример 1: простой, но знакомый до боли — фича от клиента.

1. Встреча клиента и менеджера для постановки задачи.
2. Согласование критериев приёмки задания.
3. Руководитель отдела составляет техзадание разработчику.
4. Техзадание или контрольные точки согласовываются с клиентом.
5. Ведётся разработка.
6. Руководитель отдела проводит приёмку.
7. Менеджер проводит сдачу проекта клиенту.

Если вы разработчик, при таком процессе это означает следующие вещи:

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

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

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

1. Обращается к старшему точки и сообщает о проблеме.
2. Старший точки обращается к региональному координатору и сообщает о проблеме.
3. Координатор стучит к руководителю отдела АХО и сообщает о проблеме.
4. Руководитель отдела АХО ставит задачу разнорабочему.
5. Разнорабочий утверждает бюджет у своего руководителя на новую полку.
6. Финансовому директору на стол ложится счёт под подпись.
7. Наступает следующий день.
8. Рабочий наконец-то ставит новую полку.

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

Теперь та же ситуация выглядит так:

1. Продавец обращается в АХО и сообщает о проблеме.
2. Сотрудник АХО принимает решение о целесообразности использования средств.
3. Рабочий ставит новую полку.

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

Если АХО выставляет счёт, который выходит за план их отдела, генерится алерт для руководства, где есть две кнопки: «дать люлей» и «разрешить». При желании можно нажать обе. Суть механики: путь короче и быстрее, но полный контроль при этом сохраняется. Никаких лишних действий.

Метрики

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

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

Работу закупщика оценивать уже сложнее: но построение бизнес-процесса даёт возможность понимать, что именно дальше стало с товаром, как именно оно стало и насколько эффективно.

Косяки

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

Когда десантируются сектоиды

Говорят, у военных есть инструкции на все случаи жизни: даже если прилетит НЛО с плазменными танками, у них есть точный план действий на этот случай. Так и с процессами: в идеале они есть на все случаи жизни сотрудника. Когда у сотрудника нет плана на непредвиденный случай, происходит два события:

• Он обращается к тому, кто отвечает за этот вопрос (скорее всего, не отвлекая своего руководителя).
• Если ситуация повторяется, создаётся процесс-правило для обработки таких случаев.

Как это всё внедряется в компанию

1. Сначала аналитик разговаривает с руководителем и понимает задачу. Бывает так, что процессы внедряются для галочки, чтобы потом выгоднее продать бизнес иностранцем, бывает, что для понтов, а бывает — что для дела. Последний случай наиболее интересный и сложный.
2. Выставляется счёт, вызывающий оху когнитивный диссонанс. В этот момент нужно договариваться на такие условия, что оплата производится при повышении конкретных показателей. Грубо говоря, стали получать на 20% больше прибыли в результате внедрения — платите.
3. Затем аналитик обходит всю компанию и задаёт много-много вопросов о том, как оно работает.
4. Потом каждому сотруднику приходит анкета с просьбой указать свои выполняемые задачи (заполняется полчаса).
5. Аналитик напряжённо думает и составляет блок-схему взаимодействия, из которой растут процессы и оргсхема компании.
6. Компания реорганизовывается под новые процессы.
7. Сотрудникам доносится суть изменений. Если сотрудники в возрасте, они понимают туго, но делают сразу. Если молодые — понимают отлично, но изменяются медленно.
8. Корректируются баги. Структура меняется по мере изменения компании и её процессов.

Сроки

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

Зачем ещё нужно внедрять такие штуки

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

Резюме: плюсы и минусы

Плюсы:

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

Минусы:

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

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

UPD. В личку напомнили, что для построения бизнес-процессов нужно сформулировать стратегические цели и даже миссию (в хорошем смысле этого слова). Да, иначе будет непонятно, что делать, куда делать и как делать: нужна своеобразная ДНК или modus operandi компании.

Что это такое бизнес-процесс: для чего он нужен

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

Что является бизнес-процессом

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

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

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

Из чего состоит бизнес-процесс

Мы подошли к вопросу: «Из чего состоит бизнес-процесс?». Как уже было сказано ранее, построение самой схемы не сложное. Самое трудное – это сформулировать цели и трезво оценивать свои возможности. Сейчас Вы поймёте, о чём мы говорим. Для моделирования бизнес-процесса есть общепринятая схема.

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

В качестве ресурсов берётся бюджет, выделенный на раскрутку бизнеса, аренда офиса, штат сотрудников, запланированное SEO-продвижение сайта компании и заключённые контракты с поставщиками.

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

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

Бизнес-процесс: с чего начать

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

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

Для чего нужны бизнес-процессы

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

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

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

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

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

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

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

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