Схема бизнес процесса заявки

ПланФикс

• Отчеты по расписанию: эффективно управляйте выполнением задач
• Продолжение: ChatGPT ищет душнил и токсичных
• Итоги: апрель 2023
• Как добавить в ПланФикс быстрое создание задач
• Итоги: март 2023
• Перенос найма новых ребят в ПланФикс
• Интерактивное планирование рабочих встреч
• Итоги: февраль 2023
• Итоги: январь 2023
• Оцифровка бизнес-процессов ресторана с помощью ПланФикса

Универсальное согласование или описание бизнес-процессов по-планфиксовски

• Рассказ от первого лица
• автоматические сценарии, документооборот, параллельное согласование, Последовательное согласование, согласование, универсальное согласование
• 4 комментария

Алена Талмазан: Документооборот — это некий скелет, который пронизывает всю структуру компании и непосредственно связан с ее деятельностью. Мы знаем о значимости документооборота, и о том, как порой сложно настроить его должным образом, удовлетворяя большинство запросов организации. Одно из решений предложил партнер и интегратор ПланФикса Андрей Гринюк, который вывел универсальную форму согласования. В сегодняшней заметке он поделится с нами тем, как в ПланФиксе сделать процесс согласования быстрее и эффективнее. Передаю ему слово.

Приём заявки (бизнес процесс) Начальный уровень детализации.

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

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

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

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

А что у нас в ПланФиксе?

Во-первых, есть конфигурация «Последовательное согласование» от команды ПланФикса:

Плюсы:
• Бесплатно, легко и доступно.

Минусы:
• Каждый вид согласования будет занимать один процесс (штука, ограниченная тарифным планом).

Во-вторых, есть системная галочка в задаче «Последовательная задача», которая создана как будто для этого. Можно организовать шаблон дерева задач — вот и решение:

Задачи и бизнес-процессы в 1С

Плюсы:
• Есть справка, статья в блоге, как устроена это галочка и как её использовать.

Минусы:
• Главный минус, что все подзадачи — это отдельные шаблоны задач.

У меня может быть пять процессов согласований и в каждом из них согласовывает директор. По итогу я получу пять отдельных шаблонов задач про одно и тоже «согласование директора», которые нужно отдельно настраивать и изменять при необходимости. А суть то одна и та же (неважно, что именно согласовывает руководитель) — и поведение одно, и форма одна.

Изобретаем очередной велосипед

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

Сформулируем задачу:

1. Мы не хотим на каждый бизнес-процесс согласования использовать отдельный процесс в системе (бережём).
2. Так как мы знаем маршрут, то он должен где-то храниться. А задачи должны быть созданы по этому маршруту и появляться в системе для исполнителей по очереди.
3. Нам хотелось бы анализировать время выполнения этих задач для управленческих решений. Поэтому важно разделять время: сколько задача находилась до тех пор, пока исполнитель её принял в работу, и сколько времени потратил сотрудник на ее выполнение.
4. Нам нужны как последовательные, так и параллельные задачи на согласование, чтобы сократить сроки самой заявки.
5. Нам нужен набор элементарных подзадач (проверить, согласовать, исполнить и т. д.), каждая из которых имеет стандартное поведение.

Давайте мастерить

Изначально в системе кто-то должен создать заявку, которая согласовывается. Поскольку заявки могут быть совершенно разные и иметь разный состав данных, то логично, что заявка — это отдельный шаблон задачи:

Дальше нам нужны подзадачи. Но мы усвоили, что с «последовательными задачами» — не вариант. Как можно ещё создать нужные нам подзадачи? Например, из Аналитики. Отлично.

На ум приходит аналитика с полями «Ответственный», «Тип задачи», «Срок» и «Суть задачи», где «Тип задачи» — это список, который принимает какие-то значения, например, «Согласовать», «Исполнить» и т.д. Назовём Аналитику «Дорожная карта»:

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

Следующее. При создании задач из Аналитики «Дорожная карта» заранее никого уведомлять об этом не нужно, поэтому подзадачи изначально будем создавать в статусе «Черновик».

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

В момент создания подзадач из Аналитики сделать их сразу нужным шаблоном не получится. Но при переводе задачи из статуса «Черновик» в любой активный статус сработает триггер — «Задача создана», и в этот момент мы можем изменить шаблон на нужный, согласно «Типу задачи»:

Теперь осталось решить вопрос, связанный с активацией подзадач, поскольку они все в «Черновиках». Предположим, что у всех подзадач был бы порядковый номер – 1, 2, 3 и т.д., чтобы мы могли активировать сначала первую задачу, потом вторую. Мы как бы шагаем: первый шаг, второй шаг и т.д. Тогда в Аналитику «Дорожная карта» добавим поле «Номер шага», чтобы это значение пробросить в подзадачу в поле задачи «Номер шага».

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

Концепт велосипеда готов.

Вот так могла бы выглядеть «Дорожная карта», например, заявки на оплату:

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

А ещё такую дорожную карту можно автоматически представить в виде графической схемы. Это не BPMN-нотация, но получается вполне наглядно и понятно:

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

Уровень абстракции

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

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

Её элементами являются:

1. Заявка, в которой установлен маршрут.
2. Маршрут — задача, в которой помимо аналитики «Дорожная карта» (последовательность шагов бизнес-процесса), описываются такие вещи как:
3. участники заявки;
4. общее количество шагов в «Дорожной карте» (нам это нужно для успешного выхода);
5. номер шага, на котором заявка должна быть заблокирована от изменений.
6. Шаг (строка в аналитике «Дорожная карта»):
7. Шаг «заключение» требуется, чтобы определённый специалист составил экспертное мнение. Например, юрист оставляет свои комментарии по тексту договора на предмет ошибок и рисков. Все составленные заключения будут показаны в задаче согласования, чтобы их видело руководство.
8. Шаг «согласование». Ключевая задача, от которой будет зависеть успешно или неуспешно выполнена заявка.
9. Шаг «исполнение». SMART-задача, которую можно только выполнить.
10. Шаг «вложенный маршрут», который разворачивается в дополнительную дорожную карту в виде подзадач, и считается выполненным, когда вложенная дорожная карта успешно пройдена.

Главный вход в процесс — это создание заявки и её запуск.

А выходы из процесса бывают следующие:

1. Заявка успешно завершается, если пройдены все шаги по данной дорожной карте.
2. Заявка неуспешно завершается, если в точках согласования сотрудник ее не согласовал.
3. Заявитель может в любой момент отменить заявку, например, если заявка стала неактуальной.

В конце статьи представлен видеоролик, в котором на 03:42 минуте вы увидите, как выглядит процесс согласования заявки на оплату в глазах участников.

Эффект от внедрения

Приведу график внедрения ПланФикса на одном предприятии. Руководство решило попробовать внедрить его в качестве постановки внутренних поручений и контроля их исполнения. И тогда встал вопрос: как замотивировать сотрудников пользоваться системой. Мы предложили регламентировать простые процессы:

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

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

Кто может позволить себе такой велосипед?

Велосипед получился не дешёвый с точки зрения использованных «запчастей». На реализацию у нас ушло:

• Аналитик: 4 шт.
• Процессов: 3 шт.
• Статусов: 5 шт.
• Кнопок: 6 шт.
• Автоматических сценариев: 76 шт (20-32 в процессе), что даёт запас дополнительных автоматик.
• Шаблонов задач: 5 шт.
• Пользовательских полей: 23 шт.

Поэтому, увы, подойдёт только тем организациям, кто пользуется тарифом «Бизнес» или «Корпорация».

Как запустить у себя

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

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

Андрей, приветствую.
Отличная работа. У нас есть похожее по функциональности решение. Прям очень-очень похожее, как будто функциональные требования писал один человек.
Но три отличия.
Во-первых, можно запускать как последовательное, так и параллельное согласование.
Во-вторых, есть автоматика контроля маршрута (чтобы при последовательном согласовании нельзя было ошибиться с шагом. Ни пропустить, ни указать разным сотрудникам одинаковый номер в маршруте).
Ну, и “чуть-чуть” полегче подкапотка:
– 2 шаблона задач;
– 1 процесс со стандартными статусами;
– 12 полей;
– 2 аналитики;
– 2 кнопки;
– 6 (шесть) сценариев;
– 1 вебхук.
))) Войдите, чтобы ответить

Привет, Михаил.
Спасибо, за комментарий.
1) В данном варианте решения тоже можно запускать параллельные шаги.
2) Про контроль последовательных шагов не совсем понятно: как возможно, чтобы кто-то ошибся с шагом?
3) Ну, и про количество “запчастей”, есть много того, что я не описал Войдите, чтобы ответить

Андрей, привет.
Не могу найти твои прямые контакты. Ты помнишь про демонстрацию своего решения на сегодняшнем митапе? Войдите, чтобы ответить

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

Источник: planfix.com

Как описать бизнес-процесс получения новых клиентов

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

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

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

Целевая аудитория: начинающие компании, малый бизнес.

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

Процессы верхнего уровня

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

• Интернет-продвижение (ответственный за процесс – интернет-маркетолог).
• Продвижение (ответственный за процесс – менеджер по продажам).
• Продажа (ответственный за процесс – клиентский менеджер).
• Предоставление услуг (ответственные за процесс – команда компании).
• Сервис клиенту (ответственные за процесс – команда компании).
• Повторная продажа (ответственный за процесс – клиентский менеджер).

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

• Формирование базы клиентов с помощью «Яндекс.Карт».
• Формирование базы клиентов с помощью социальных сетей.
• Формирование базы клиентов с помощью специальных инструментов обработки поисковых запросов.
• Формирование базы клиентов с использованием налоговых баз.
• Формирование базы клиентов с использованием таможенных баз.

Процессы второго уровня: интернет-продвижение

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

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

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

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

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

Процессы второго уровня: продвижение

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

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

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

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

На пятой стадии продвижения менеджер осуществляет разогрев клиента до принятия решения о начале работы. Итогом этого этапа должна быть готовность клиента обсуждать сделку. В системе CRM клиент переводится в категорию «теплые клиенты».

Процессы третьего уровня: пополнение клиентской базы

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

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

Третий шаг: маркетолог форматирует базу клиентов до параметров CRM. В результате список клиентов в Excel должен быть полностью подготовлен для автоматической загрузки в CRM-систему.

В ходе выполнения четвертого шага маркетолог загружает список клиентов в CRM.

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

После завершения этапа пополнения клиентской базы у компании должен появиться материал для последующей работы менеджера по продажам.

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

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

Как получить полный бесплатный доступ к публикации?

1. Авторизоваться или зарегистрироваться на сайте

Источник: www.e-xecutive.ru