Моделирование бизнес процессов задачи менеджера

BPMN (Business Process Model and Notation) называют условные обозначения, которые используются для создания схемы бизнес-процессов.

Моделирование бизнес-процессов необходимо компании по многим причинам:

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

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

После прохождения программы слушатели смогут:

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

Продолжительность: 16 ак. часов

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

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

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

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

Моделирование бизнес-процессов осуществляется в двух направлениях.

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

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

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

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

Моделирование бизнес-процессов происходит посредством поэтапного определения и формализации:

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

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

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

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

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

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

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

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

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

При моделировании бизнес-процессов следует придерживаться основных принципов:

• • «разделяй и властвуй» (лат. Divide et impera) – моделирование должно начинаться с базовой модели, которая описывает верхний уровень исследуемой предметной области, и детализироваться до необходимого уровня сложности;
• • «закон экономии» (лат. Lex parsimoniae) – процесс декомпозиции и детализации модели должен руководствоваться принципом разумной достаточности для целей моделирования (принцип бритвы Оккама);
• • принцип системного подхода – моделируемая предметная область должна быть рассмотрена как система взаимосвязанных и взаимодействующих процессов;
• • принцип целостности требует обеспечения целостности описания бизнес-процессов, включающего название, раскрывающее его сущность; описание реализуемой последовательности функций/процессов; определение участников процесса, используемых ресурсов и информации;
• • принцип соизмеримости моделей – на одном уровне детализации должны размещаться подмодели, равные по степени обобщения описываемой информации и соизмеримости по сложности, составу и значимости;
• • принцип эргономичности – на каждом виртуальном или реальном листе графического описания должно содержаться такое число объектов, чтобы модель могла быть легко прочитана и проанализирована.

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

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

Примерами методов (нотаций) структурного анализа являются:

• • SADT (Structured Analysis
• • моделирование бизнес-процессов и блоков 1DEF3;
• • кросс-функциональная блок-схема (Cross Functional Flowchart);
• • метод Ericsson-Penker, основанный на расширенном варианте универсального языка моделирования UML (Unified Modeling Language).

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

К основным современным методам (нотациям) событийного подхода относятся:

• • цепочки функций процесса, управляемого событиями, ЕРС (Event-driven Process Chain);
• • нотация и модель бизнес-процессов BPMN (Business Process Model and Notation).

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

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

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

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

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

• [1]Оптимизация (бизнес-процесса) – реализация изменений в структуре бизнес-процесса или характеристиках его элементов, которые влекут достижение экстремума (минимума или максимума) целевой функции, характеризующей выполнение бизнес-процесса.
• [2]Нотация (от лат. notatio – записывание, обозначение) – это синтаксис (система условных обозначений и правила их сочетания) и семантика (правила толкования моделей и их элементов), используемые для визуального представления бизнес-процессов.
• [3]Декомпозиция – процесс представления системы в виде совокупности составляющих ее элементов, расположенных на более низком уровне иерархической структуры.

Источник: studme.org

Моделирование бизнес процессов задачи менеджера

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

BPM (Business Process Management) — управление бизнес-процессами, систематический подход для создания, представления, документирования и контроля автоматизированных и не автоматизированных процессов, направленных на реализацию целей и бизнес-стратегии компании.

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

Что означает end-to-end процессы? В действительности это не более чем процесс от начала до его завершения.

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

Для графического представления бизнес-процессов используется BPMN.

BPMN (Business Process Model and Notation) — метод иллюстрации бизнес-процессов в форме различных диаграмм, схем и графиков логических последовательностей.

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

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

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

Артефакты. Для отображения дополнительной информации о процессе используют артефакты. Артефакты не влияют на процесс напрямую. Любой артефакт может быть связан с любым объектом потока.

Больше не нужно искать и обзванивать каждое диджитал-агентство
Создайте конкурс на workspace.ru – получите предложения от участников CMS Magazine по цене и срокам. Это бесплатно и займет 5 минут. В каталоге 15 617 диджитал-агентств, готовых вам помочь – выберите и сэкономьте до 30%.
Создать конкурс →

Рассмотрим пример иллюстрации простейшего бизнес-процесса:

На схеме представлен процесс смены тарифного плана для клиента технической поддержки.

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

В представленной схеме можно выделить несколько основных элементов.

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

В примере мы можем различить следующие задачи: «Подготовить дополнительное соглашение» и «Сменить тарифный план в системе ТП».

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

В текущей задаче исходным событием является желание клиента сменить свой тарифный план — «Клиент сообщает о необходимости сменить тарифный план»

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

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

Где используются BMP на практике?

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

Наша компания выделяет следующие направления использования BPM:

1. Моделирование (документирование) существующих процессов.
2. Усовершенствование процессов.

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

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

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

Опыт использования BPMN нашей компанией

Причины внедрения BPMN

Основные причины, повлиявшие на принятие решения о внедрении BPMN:

1. Отсутствие четкого регламента взаимодействия и разграничения области ответственности сотрудников.
2. Проблема обучения новых сотрудников.

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

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

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

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

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

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

Бизнес-процессы технической поддержки

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

• Новый клиент.
• Изменение тарифного плана.
• Работа с обращениями.
• Передача проекта между менеджерами.
• Перевод разработчика в отдел ТП.
• Снятие клиента с поддержки.

Эти процессы сформировались из значимых систематически выполняемых задач отдела.

Среди процессов технической поддержки выделяется основной и наиболее сложный процесс «Работа с обращениями». В процессе участвуют клиент, менеджер, а также все необходимые специалисты (в основном, дизайнеры и Frontend и Backend-разработчики).

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

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

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

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

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

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

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

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

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

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

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

Ищете исполнителя для реализации проекта?

Проведите конкурс среди участников CMS Magazine

Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.

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