Ошибки создания бизнес процессов

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

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

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

Проблема №1. А зачем Вам это?!

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

Три главных ошибки при внедрении бизнес-процессов

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

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

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

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

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

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

Типичные ошибки в написании бизнес-процесса.

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

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

Собственник бизнеса в такой ситуации оказывается в самой невыгодном положении: 1) не достигается цель, требуемая бизнесом, 2) оплачивается создание и использование ненужного бизнес-процесса, 3) возможно причинение вреда компании от ненужного бизнес-процесса.

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

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

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

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

Какой должен быть алгоритм принятия решения? Какое образование, ученая степень должна быть у такого сотрудника и где же такого умника взять? Эксперт не может ответить на эти вопросы — никакого алгоритма нет, и обработать даже по алгоритму такое количество вводных человеку не под силу. Да и зачем сотруднику нужны все эти данные, которые он не может переварить, а решение будет приниматься исходя из каких-то субъективных выводов? Ответ эксперта: «Пусть эти данные у него будут на всякий случай».

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

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

Проблема № 2. Пойди туда, не знаю куда

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

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

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

После двухчасового доклада о необходимости внедрения схемы учета партий товара, ее экономической целесообразности я осмелился задать уточняющий вопрос: «Что же такое партия товара»? При этом указал, что действующий Государственный стандарт РФ ГОСТ Р 51303-99 «Торговля. Термины и определения» не дает определения этому понятию, как и нормативные документы по бухучету.

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

Проблема № 3. Снежный ком проблем

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

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

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

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

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

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

Источник: www.retail.ru

Управление бизнесом. Ошибки внедрения бизнес-процессов

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

Основы управления бизнесом

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

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

Условно все бизнес-операции можно разделить на такие категории:

основные;
вспомогательные;
для управления;
для развития.

Нужно учитывать определенные моменты, а именно:

Жизненный цикл компании. Маленькие организации (до 30 сотрудников), где бизнес-процессы максимально простые, целевая аудитория достаточно расплывчатая, характеризуются быстрой реакцией на разные ситуации, им легче приспособиться к изменениям условий. По мере роста требуется управление бизнесом, потому что операции становятся хаотичными, работа организации требует контроля. Система управления призвана объединить действия сотрудников компании в одном направлении.
Регламентация. Прописываются и документируются только те процессы, которые отлажены полностью и повторяются многократно. Что касается процессов, которые постоянно меняются, они подлежат тестированию, после чего делается выбор самых эффективных.
Специфика деятельности компании. Управлять бизнесом можно не на всех предприятиях. К таким относятся проектные, строительные организации, а также предприятия, ведущие производственную деятельность. Эффективным управление будет в тех компаниях, где многократно повторяются действия, к примеру, серийные производства, ритейловые компании и др. Такой механизм — основа бесперебойной работы.

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

простая повторяющаяся;
простая и повторяющая по определенному алгоритму;
сложная неповторяющаяся;
сложная повторяющаяся.

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

Этапы бизнес-процессов

Существует три основных этапа управления бизнесом.

Разделение

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

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

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

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

Разработка

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

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

Совершенствование

В рамках данного этапа проводится:

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

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

Правила эффективного управления

Чтобы данная работа была эффективной, необходимо параллельно проводить мероприятия:

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

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

Как внедряются бизнес-процессы?

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

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

Алгоритм включает последовательные шаги:

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

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

Какие ошибки допускаются?

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

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

Ошибка № 1. Не определены конкретные объекты совершенствования

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

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

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

Ошибка № 2. Отсутствие работы над существующими операциями

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

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

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

Ошибка № 3. Превращение в проект ИТ

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

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

Источник: synergy.ru

Моделирование бизнес-процессов в нотации BPMN начинающими: типовые ошибки

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

Введение

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

Для выполнения этой задачи нужны: эффективная система управления проектом, методология, инструмент (система моделирования) и человеческие ресурсы, адекватные по численности и подготовке. Если инструмент можно легко купить, то с методологией и ресурсами всё не так просто. Качество управления проектом сильно зависит от конкретного руководителя.

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

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

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

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

Исходные данные для анализа

Исходные данные для анализа таковы. В ряде компаний (нефтедобыча, производство, ритейл и проч.) проводилось обучение временных рабочих групп (ВРГ) численностью 25–30 человек. Некоторые участники занимались «описанием» процессов при помощи «диаграмм с ромбиками» (в Business Studio — это нотация «Процедура») или сталкивались с нотацией eEPC. Но большинство специалистов созданием графических схем не занимались.

Обучение проводилось в течение 2 дней на основе методического пособия «Моделирование в нотации BPMN. Пособие для начинающих. Часть I» (, 2018 год). В первый день слушателей последовательно знакомили с основами нотации BPMN. Они выполняли ряд связанных между собой заданий, моделируя процесс в среде Business Studio и двигаясь от простого к сложному.

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

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

Требования и правила моделирования устанавливались в «Соглашении по моделированию» компании.

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

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

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

Типовые ошибки моделирования, допускаемые начинающими

Проблема мышки

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

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

Оборванные

Следующая проблема — это оборванные . У неопытных и довольно безответственных рисовальщиков документы появляются «из воздуха», «зависают» на выходе операций процесса и никуда не попадают. Часто начинающие вообще не показывают на схеме потоки документов/информации.

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

Обсуждая входы/выходы можно отметить два аспекта. Технически на схеме в нотации BPMN в среде Business Studio можно показывать взаимодействие между разными процессами при помощи стрелки типа massage flow, связывая конкретную операцию процесса со свернутым пулом (другой процесс). Для последующей возможности вывода информации о входах/выходах в отчеты к этой стрелке должен быть привязан конкретный документ. Часто неопытные пользователи забывают это делать. Но сама по себе стрелка massage flow без привязанного к ней документа с точки зрения комплексной модели в Business Studio не несет конкретной информации.

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

Бывает обратная ситуация — на модели верхнего уровня входы/выходы есть, а при переходе на уровень вниз на процессы, описанные в нотации BPMN, эти входы/выходы теряются. Иногда на моделях нижнего уровня в нотации BPMN показывают информационные связи с процессами уровня + 2 выше. Как следствие — низкое качество модели компании в целом.

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

На мой взгляд, наличие потока документов на схеме процесса в нотации BPMN в Business Studio необходимо и практически полезно для целей анализа, регламентации и автоматизации.

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

Рис. 1. Оборванные и отсутствующие (фрагмент схемы).

Некорректная логика процесса

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

Рис. 2. Пример логической ошибки (фрагмент схемы процесса). Нет входов/выходов.

Непонимание межпроцессного взаимодействия

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

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

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

отправляют сообщение в другой процесс (свернутый пул на схеме в Business Studio), который не должен запускаться (инициироваться) — с ним просто есть взаимодействие по (причем, чаще всего, опосредованное — через базу данных или компании);
отправляют сообщение в свернутый пул под названием «Все процессы», «Поставщик» или, что хуже всего, «Отдел …» (в Business Studio можно создать свернутый пул из так называемой «Внешней ссылки»);
отправляют сообщение в процесс, который находится в дереве на 2–3 уровня выше описываемого и сформирован в нотации IDEF0 — отправка «на деревню дедушке»;
показав отправку сообщения на схеме описываемого процесса, не открывают другой процесс и не дают себе труд продумать, куда попадает отправленное сообщение и как оно повлияет на выполнение другого процесса.

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

Рис. 3. Некорректное использование событий отправки/получения сообщений Нет входов/выходов.

Использование таймеров

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

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

Рис. 4. Некорректное использование (фрагмент схемы).
Нет входов/выходов.

Описание процесса для одного объекта, которых в реальности множество

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

Процесс в процессе (рекурсия)

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

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

Красота схемы

Здесь все печально. Только 10–15% сотрудников стремятся сделать схемы красивыми. Для остальных это третьестепенная задача. Но некрасивую схему не хочется брать в руки, а тем более анализировать. Визуальная красота схемы — залог ее проработанности, что снижает трудоемкость последующих согласований и внесения изменений.

Накопление опыта и исправление ошибок

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

Хотел бы отметить, что для освоения навыков моделирования процессов на операционном уровне (в нотации BPMN) очень полезно показать сотрудникам имитацию выполнения процесса в Business Studio. Еще лучше, если после этого они сами попробуют запустить на имитацию отрисованный ими процесс, причем сначала пошагово, чтобы почувствовать себя той самой «мышкой» (токеном). Это упражнение дает хорошее понимание сути моделирования процессов Work Flow.

Выводы

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

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

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

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

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

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

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

Источник: www.businessstudio.ru