Если вы хотите отслеживать эффективность своих сотрудников при работе в Битрикс24, вам поможет наш сервис Пинкит.
Протестируйте сценарии автоматизации в личном кабинете Пинкит, зарегистрировавшись по ссылке: https://lk.pinkit.io/register/
Тарифы на платформу и функционал в тарифной сетке можно посмотреть здесь: https://pinkit.io/
Алексей Окара,
основатель Пинол и продакт-менеджер Пинкит
1 Преамбула |
Порой мы видим многое, но не замечаем главного.
Конфуций.
Но как она работает? Что из себя представляет? Какой бизнес-процесс реализован во внедренном решении? И, главное, как его совершенствовать и изменять? Итак, господа Знатоки… «Черный ящик»!
Что-то входит (поток информации) и выходит (результаты в каком-то виде)?
2 Конфликт интересов |
2.1 Роль и ответственность менеджера проекта |
Роль менеджера проекта (для краткости буду использовать для его обозначения аббревиатуру ПМ – «проектный менеджер») можно описать двумя фразами:
- ПМ отвечает за то, чтобы проект уложился в рамки тройственного ограничения;
- ПМ несет ответственность за проект в целом.
Тройственное ограничение – это «сроки», «стоимость» и «содержание работ» проекта. Говоря о нем – нередко рисуют треугольник, чтобы подчеркнуть взаимосвязь всех его граней. Изменение бюджета неизбежно повлияет на сроки и состав работ; обратное справедливо и для остальных граней.
Иногда внутри треугольника пишут еще одно условие – «удовлетворенность заказчика».
Руководство организации-заказчика автоматизации процессов зачастую не знает или пренебрегает элементарными принципа, позволяющими управлять автоматизированными бизнес-процессами на собственном предприятии после окончания внедрения проекта. Это еще при условии, что проект формально окажется успешным и даже будет запущен в промышленную эксплуатацию.
Итак, ситуация. Пред проектное обследование проводилось «никто не помнит, как?», техническое задание или отсутствует или не даёт необходимой информации об имплементированных бизнес-процесса, ролях и так далее. Я называю такую ситуацию «телега впереди лошади».
Как правило, документация при таких внедрениях бывает, даже если и выполнена, то абсолютно бесполезна, так как не даёт необходимой информации.
Ответственность ПМ я вижу как раз в том, чтобы проект был успешным (не выходил за грани треугольника). Если ПМ заранее осознает провал еще не начавшегося проекта – надо ставить вопрос «ребром». Лучше уволиться, если другое не помогает.
Но, что же делать, если всё уже случилось? Выход есть.
2.2 Что может сделать бизнес-аналитик |
Базовое понимание того, каким должен быть бизнес-процесс, можно выразить так. Бизнес-процесс должен быть:
- описанным;
- оптимизированным;
- выполнимым;
- изменяемым (совершенствуемым).
Понятно, что именно от этого напрямую зависят результаты работы бизнеса. В том числе и финансовые.
Если автоматизированный бизнес-процесс прошит в код программного обеспечения, то ничего сделать уже не получится, это понятно. Придётся проводить революцию.
В данной статье я рассматриваю конкретный проект реинжиниринга бизнес-процессов, имплементированных в систему Битрикс24. Благодаря открытости платформы Битрикс24 имеется возможность изучить бизнес-процесс в визуальном редакторе системы и сделать Техническое Задание, которое не было сделано тогда, когда это было необходимо.
Лошадь поставлю-таки впереди телеги! И бизнес сможет увидеть свои процессы и начать движение вперёд.
3 Реинжиниринг бизнес-процессов Битрикс24 |
В данной статье я не буду описывать всю работу, которая была выполнена. В этом нет необходимости. Но состав этапов работы – полный.
Первое, что необходимо определить, это к каким сущностям в системе построены бизнес-процессы. В нашем примере – это сущность «Сделка» CRM Битрикс24.
На следующем этапе надо определить переменные, а также другие настройки, применённые к имплементированному бизнес-процессу. Из настроек я выбираю переменные в таблицу (Таблица 1). Для того, чтобы беспорядочные наименования переменных более не мешали мне работать, я унифицирую их названия в используемый мной формат (v[Название_Переменной]). На изображении (Рисунок 1) показана настройка переменной для Менеджера по Сделке.
Таблица 1. Переменные бизнес-процесса (фрагмент).
Наименование переменной (смысл) |
Переменная в системе |
Тип данных |
Менеджер по Сделке |
vManager |
Привязка к пользователю |
Город, где производится установка |
vGorod |
Список |
Диспетчер замера |
vDispetcher |
Привязка к пользователю |
Замерщик по сделке |
vZamershchik |
Привязка к пользователю |
Предполагаемая дата-время замера
|
vDataZamera
|
Дата/Время
|
Рисунок 1. Определение переменной.
Теперь в визуальном редакторе открываю схему бизнес-процесса (Рисунок 2) и начинаю её изучать, с самого первого блока. Здесь надо отметить, что уже в процессе проведения аналитики имплементированного бизнес-процесса, можно вносить изменения в него с целью оптимизации, если необходимость таких изменений видна сразу. А можно применить классический подход, сделав сначала аналитику «Как есть» (AsIs), а потом построить «Как должно быть» (ToBe). Что правильнее.
Рисунок 2. Схема бизнес-процесса в визуальном редакторе Битрикс24 (фрагмент).
В данной работе выявляются бизнес-роли пользователей. В отличие от процесса, выстраиваемого мной в нотации BPMN, роли в явном виде в визуальном редакторе Битрикс24 не видны. Потребуется некоторые аналитические усилия, дабы их раскрыть. Можно прибегнуть к содействию владельцев бизнес-процесса, но, по моему опыту, лучше выстроить весь процесс самому, а уж потом общаться с бизнесом в стиле «Здесь вот так? Или нет? А как тогда? Хорошо. Сделаю так.».
Рисунок 3. Схема бизнес-процесса в нотации BPMN (фрагмент).
Во время формирования схемы (Рисунок 3) у меня естественным образом происходит выявление ролей процесса, так как иначе схему и не построить. Необходимо свести роли в таблицу (Таблица 2).
Таблица 2. Роли пользователей в имплементированном бизнес-процессе (фрагмент).
Наименование роли |
Переменная или поле сущности в системе |
Описание основных фунций |
Автор Сделки |
Автор (поле) |
|
Менеджер Сделки |
vManager (переменная) |
|
Диспетчер в городе |
vManager (переменная) |
|
Итак, в результате проведения всех этапов работ, я получаю полное техническое задание на разработку и внедрение бизнес-процесса обработки Сделки для компании, занимающейся производством, дистрибуцией и установкой натяжных потолков.
Следует отметить, что такой бизнес-процесс характерен для большинства компаний, занимающихся позаказным производством и установками (двери, окна, мебель и тому подобное).
После проведения реинжиниринга и получения актуальной документации необходимо самым строгим образом контролировать процесс, который называется «Управление изменениями». Для этого нужно назначить ответственного сотрудника, который будет иметь права на изменения бизнес-процессов в Битрикс24. Это можно сделать во вкладке «Доступ» параметров шаблона бизнес-процесса в системе (Рисунок 4).
Рисунок 4. Настройка прав доступа к изменению бизнес-процесса.
Само по себе управление изменениями – тема отдельной статьи, и довольно обширная. Я же пожелаю Вам успехов в наведении порядка и твердости в недопущении установки телеги впереди лошади.
Если вы хотите отслеживать эффективность своих сотрудников при работе в Битрикс24, вам поможет наш сервис Пинкит.
Протестируйте сценарии автоматизации в личном кабинете Пинкит, зарегистрировавшись по ссылке: https://lk.pinkit.io/register/
Тарифы на платформу и функционал в тарифной сетке можно посмотреть здесь: https://pinkit.io/
Алексей Окара,
основатель Пинол и продакт-менеджер Пинкит
Время работы специалистов Пн.–Пт.: с 9:30 до 18:30; Сб.-Вс.: выходные.
Полина Гальченко
|
Сервис «Пинкит» (
Если Вам нужна помощь в комплексной настройке приложений Пинол, в рамках использования сервиса «Пинкит» ( |
Полина Гальченко
|
Подписывайтесь на наш YouTube-канал (
|
Полина Гальченко
|
Рекомендуем ознакомиться с нашими готовыми кейсами (
|
Елена Хажина
|
Регистрируйтесь по ссылке:
|