Бизнес-процессы, описание бизнес-процессов, разработка бизнес-процессов

Блог о бизнес-процессах и BPMN

Блог о бизнес-процессах, BPMN и других нотациях автоматизации бизнес процессов.

Как построить схему бизнес-процесса: графический пример

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

Общий подход к построению схемы бизнес-процесса

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

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

Какими качествами должна обладать готовая схема?

Качественная и эффективная схема должна отвечать следующим требованиям:

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

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

Зачем нужно строить схему бизнес-процессов?

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

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

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

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

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

Как построить схему самостоятельно?

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

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

Первый этап. Установление границ бизнес-процесса

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

Соответственно, необходимо понимать все тонкости работы организации и всех его процессов.

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

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

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

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

Второй этап. Точки начала, окончания, ключевые блоки

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

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

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

Третий этап. Дополнение недостающими операциями

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

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

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

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

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

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

Четвертый этап. Обозначение роли участников, документации, баз данных

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

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

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

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

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

Читать: Для чего проводится анализ бизнес процессов на предприятии, какие методы и виды оценки эффективности подразделений применяются на практике

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

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

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

Результатом такого управления становится формирование процессной структуры, ориентированной на потребности внутреннего клиента.

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

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

Пятый этап. Проверка полученной модели

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

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

Обзор программ для создания схемы бизнес-процесса

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

ELMA BPM

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

Business Studio

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

Visual Paradigm

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

Bizagi Process Modeler

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

Intalio BPMS

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

ARIS Express

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

Camunda

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

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

AllFusion Process Modeler

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

IBM WebShpere Business Modeler

Программное средство для моделирования, имитации и анализа бизнес-процессов.

Основными характеристиками являются:

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

Fox Manager Бизнес Процессы

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

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

Comindware Business Application Platform

Российская платформа, в которой реализовано моделирование бизнес-процессов и цифровая трансформация предприятия.

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

Практический пример с графической схемой

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

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

На основе обработки информации составим проект процессов компании.

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

Основные производственные процессы предприятия представлены на рисунке.

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

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

Материалы поступают на склад по накладным от различных поставщиков.

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

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

Таким образом, проведенное исследование позволило сделать следующие выводы:

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

Читать: Для чего нужна автоматизация бизнес процессов на предприятии. Как выбрать средство автоматизации и правильно внедрить его в производство

Улучшить работу предприятия можно при учете следующих моментов.

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

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

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

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

Можно чаще документировать толщину шва, чтобы быть уверенными в том, что контроль осуществляется часто.

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

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

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

Бизнес-процессы — основа эффективного управления предприятием

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

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

Преимущества процессного подхода перед функциональным

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

Каждый бизнес-процесс имеет:

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

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

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

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

Внедрение СМК на предприятии в обязательном порядке требует создания и описания бизнес-процессов.

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

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

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

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

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

• Стандартные формы бизнес-процесса
• Карта бизнес-процесса
• Маршруты бизнес-процесса
• Матрицы бизнес-процесса
• Блок-схемы бизнес-процесса
• Описание стыков бизнес-процесса
• Вспомогательные описания бизнес-процесса
• Развернутое описание бизнес-процесса
• Документирование бизнес-процесса
• Определение показателей и индикаторов бизнес-процесса
• Регламент выполнения бизнес-процесса

Рассмотрим подробнее каждый этап.

1.Стандартные формы описания бизнес-процесса

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

2.Карта бизнес-процесса

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

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

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

Рекомендация

При составлении карты бизнес-процесса следует воспользоваться популярной вопросной формулой 5W1H. Коротко, это 5 вопросов W:

• Who?(Кто совершает данную операцию?)
  
• Why? (Почему или зачем выполняется эта операция?)
  
• What? (Что представляет собой эта операция?)
  
• When? (Когда нужно проводить данную операцию?)
  
• Where? (Где производится операция?)
  

и один вопрос H

• How? (Как совершается эта операция? Можно ли сделать это иначе или внести улучшения?).

Если карта получается слишком сложной — это сигнал о том, что в управлении организацией нет должного порядка.

3. Маршруты бизнес-процесса

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

4. Матрицы бизнес-процесса

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

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

5. Составление блок-схемы бизнес-процесса

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

• Сопоставима ли ценность от данного бизнес-процесса с затратами на его проведение?
• Насколько он интегрирован с другими бизнес-процессами?
• Могут ли быть сразу обнаружены ошибки этого бизнес-процесса?
• Что сделано для улучшения и обеспечения качества этого бизнес-процесса?

6. Описание стыков бизнес-процессов

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

Рекомендация

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

Затем составьте аналогичное описание входов.

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

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

8. Развернутое описание бизнес-процессов

Развернутое описание бизнес-процесса может быть в любой удобной для предприятия форме, но должно содержать основные положения:

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

9. Документирование бизнес-процесса

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

10. Определение показателей и индикаторов бизнес-процесса

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

• качество;
• время выполнения;
• количество;
• издержки.

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

Группа индикаторов бизнес-процесса показывает степень достижения цели.

Группа требований включает в себя:

• человеческие ресурсы;
• инфраструктура;
• условия производственной среды.

Группа обеспечения желаемого протекания процесса:

• информация;
• инструкции по выполнению работ;
• время.

Группа рекомендаций:

• финансы;
• логистика;
• поставщики;
• партнеры и т.д.

11. Регламент выполнения бизнес-процесса

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

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

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

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

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

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

Карл Маркс. Капитал. Том 1. Предисловие к первому изданию.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я не единожды читал информацию о том, что нотации бизнес-процессов IDEF0 появилось чуть ли ни в середине XIX века. Более реалистичные авторы пишут о периоде Второй Мировой войны. Но и они ошибаются.

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

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

На самом деле описание бизнес-процессов и нотации BPMN появились в 70-е годы XX века, когда повсеместно начали использоваться информационные системы. И сам термин, и нотации понадобились изначально именно для разработки информационный систем.

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

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

Первые методологически проработанные нотации бизнес-процессов (а я буду говорить именно о методологически проработанных нотациях, например, IDEF3***) появились у военных в США. Причина очевидна – уже тогда военные в США пользовались автоматизацией с использованием удаленных соединений, т.е. той самой системой, которая позже стала Интернетом. И при таком уровне применения информационных систем потребность в нотациях бизнес-процессов была особенно актуальной.

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

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

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

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

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

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

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

Зачем моделировать (описывать) бизнес-процессы

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

Моделирование бизнес-процессов помогает решить сразу две задачи:

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

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

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

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

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

Как описывать бизнес-процессы

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

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

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

Рекомендуемая последовательность действий:

1. Собираем участников процесса (сотрудников);
2. Собираем входящую информацию, необходимую и достаточную для запуска процесса;
3. Собираем используемые системы. Это может быть учетная система,CRM, электронная почта, таблицы Excel и т.д. Все, что реально используется в работе, необходимо зафиксировать.
4. Определяем ожидаемый результат – что будет в конце процесса.
5. Собираем последовательность действий, которые выполняет человек.
6. Вычленяем условия. В зависимости от разных входящих данных и промежуточных результатов действия могут быть разными.
7. Описываем всю собранную информацию в графическом виде в удобной нотации (IDEF3, BPMN 2.0 и т.д.).

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

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

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

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

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

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

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

Не путайте описания бизнес-процессы компании и бизнес-процессы IT систем.

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

Распространенная ошибка: Бизнес-процесс обязательно приносит ценность (прибыль).

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

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

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

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

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

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

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

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

Источник https://bpmn.pro/process/shema-biznes-protsessa

Источник https://www.u-b-s.ru/publikacii/biznes-processy.html

Источник https://habr.com/ru/post/342448/