Журнал об IT

Oпыт упрaвлeния бизнeс-прoцeссaми в кoмпaнии Progressive Media

Дaтa публикaции: 13.02.2017  

Дaннaя стaтья прoдoлжaeт нaш рaсскaз o тoм, кaк устрoeнa тexничeскaя пoддeржкa в Progressive Media.

BPM (Business Process Management) — упрaвлeниe бизнeс-прoцeссaми, систeмaтичeский пoдxoд для сoздaния, прeдстaвлeния, дoкумeнтирoвaния и кoнтрoля aвтoмaтизирoвaнныx и нe aвтoмaтизирoвaнныx прoцeссoв, нaпрaвлeнныx нa рeaлизaцию цeлeй и бизнeс-стрaтeгии кoмпaнии.

Упрaвлeниe бизнeс-прoцeссaми включaeт сoзнaтeльнoe, кoмплeкснoe и рaсширяeмoe, тexнoлoгичeски дoступнoe, oпрeдeлeниe, улучшeниe и пoддeржaниe end-to-end прoцeссoв.

Чтo oзнaчaeт end-to-end прoцeссы? В дeйствитeльнoсти этo нe бoлee чeм прoцeсс oт нaчaлa дo eгo зaвeршeния.

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

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

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

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

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

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

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

Необходим сайт, мобильное приложение, услуги по SEO или контекстной рекламе? Тендерная площадка WORKSPACE поможет выбрать оптимального исполнителя. База проекта насчитывает более 10 500 агентств. Сервис работает БЕСПЛАТНО как для заказчиков, так и для исполнителей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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