Моделирование бизнес-процессов с помощью BPMN20.02.2017 01:08

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Усовершенствование процессов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Новый клиент.

• Изменение тарифного плана.

• Работа с обращениями.

• Передача проекта между менеджерами.

• Перевод разработчика в отдел ТП.

• Снятие клиента с поддержки.

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

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

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

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

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

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

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

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

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

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

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

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

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

Полный текст статьи читайте на CMS Magazine