Как мы сделали сложно, чтобы стало просто (кейс про автоматизацию процесса согласования договоров с клиентами в отделе продаж). Часть 1. Аналитика

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

Люди любят, когда все просто и понятно, чтобы можно было легко, в 2-3 клика, получить задуманный эффект. Мы потратили около года на создание удобного процесса согласования договоров в Битрикс24. Позже принципы и инструменты из него стали основой для нашего тиражного решения.

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

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

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

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

1. Чтобы запустить согласование, менеджер по продажам писал письмо с копией на всех участников согласования. Все отвечали по мере своей загруженности. Поэтому к руководителю отдела или к другим участникам, которые могли повлиять на условия, зачастую договор попадал уже после согласования с бухгалтером и/или юристом. Кто-то из них вносил правки в условия отгрузки или оплаты и договор начинали пересогласовывать.

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

Перед началом работы у нас были 3 схемы процесса, составленные руководителями отделов продаж и убеждение клиентов, что у них 4 типа договоров, от которых зависит маршрут согласования.

1. типовой по форме компании,

2. типовой с корректировками,

3. спецификация,

4. по форме клиента.

На встрече по этим схемам я задала мои любимые вопросы: «Всегда ли…?» и «Что проверяет…?», «В каких случаях…?» и «А как сейчас…?»

На примере самой первой схемы получился следующий набор вопросов:

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

Моя задача на этом этапе вытащить обратно в область сознания весь этот процесс и выявить, что же там происходит.

Если представить первую схему в виде бизнес-процесса в Битрикс24, то это будет практически линейный процесс, всего с двумя остановками. Причем на каждой из остановок у согласующего будет всего 2 варианта: согласовать или отклонить. У РОПа не будет возможности подключить юриста или бухгалтера, поэтому важно понимать, происходит ли такое хотя бы иногда. Оказалось, что да, в некоторых случаях бывает.

Ок, значит, расшиваем варианты выбора в этой точке: согласовать, отклонить, привлечь юриста и/или бухгалтера (по этому пункту ставлю себе пометку, что решение еще не окончательное).

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

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

Поэтому снова корректирую варианты возможных выборов РОПа и получается вот такой список:

1) согласовать,

2) отправить на доработку секретарю,

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

Бывают ли ситуации, когда РОП совсем отклоняет договор? Формально, да, бывает.

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

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

Но если всё так просто, может быть мы можем автоматизировать согласование? Какие критерии договора проверяет РОП, как понимает, что с ним что-то не так?

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

Следующей задачей было прояснить шаг согласования с директором. По схеме он является обязательным и блокирующим. Снова представляю, что я уже собрала этот бизнес-процесс в Битрикс24: все договоры после прохождения шага с РОПом попадают к директору и не идут дальше, пока он не одобрит. А в день заключается в среднем 5-6 таких договоров. Директор все просматривает и лично принимает решения? Сомнительно…

Начинаю уточнять: «А как сейчас вы поступаете с такими договорами: каждый показываете директору, и по договору не ведутся другие работы, пока он не скажет своё веское слово?»

Быстро выясняем, что нет, конечно, зачем отвлекать директора по таким пустяковым вопросам.

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

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

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

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

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

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

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

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

1. Доп. согласования не требуются, договор идет сразу на подпись.

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

3. Нужно согласование суммы с руководителем компании. Во внутреннем регламенте есть пороговое значение, и все документы на сумму выше этого значения обязательно согласовываются с директором компании. Также РОП выбирает этот маршрут в каких-то сложных случаях, когда не готов согласовать сумму договора под свою ответственность.

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

Вот теперь я могла описать в ТЗ итоговую версию шага согласования с РОПом, в которой были прописаны информационные поля для принятия решения, выделены поля для текста задания и уведомлений, а также поля для заданий бизнес-процесса.

Вот как это всё выглядит сейчас:

Главное в задании — списочное поле «Согласовать» с пятью вариантами действий (решили всё же оставить РОПу возможность Отклонить, её используют, когда надо удалить ошибочное согласование).

РОП выбирает один из маршрутов и, в зависимости от своего выбора, заполняет дополнительные поля. Если выбрал создание задачи для согласования, то указывает, кого из сотрудников надо добавить в эту задачу для корректировки текста и согласования условий: юриста, бухгалтера, директора и т.д.

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

Своё обоснование, комментарии и мнения по договору вписывает в поле Комментарий.

В итоге, мы выявили общие шаги для согласований всех типов документов, объединили 4 схемы в одну и зафиксировали порядок шагов.

Также составили перечень особых случаев и ответвлений маршрута.

Таких дополнительных веток оказалось всего три:

1. Если сумма договора превышает пороговую, требовалось согласование договора с руководителем компании.

2. При согласовании спецификации параллельно с подписанием документов запускается дополнительная цепочка задач для бухгалтерии и руководителей.

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

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

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

Есть два основных варианта, как организовать работу с правками:

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

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

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

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

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

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

Ключевым параметром для этапа обмена оригиналами оказалась очерёдность отправки документов: мы первые отправляем оригиналы или клиент.

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

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

Если первым оригинал должен прислать клиент, то сначала создаётся пустое Входящее в статусе ожидания, а после получения оригинала создаётся Исходящее с номером и задача для секретаря.

В итоге, эта часть процесса с регистрацией входящей и исходящей корреспонденции прижилась в компании и стала использоваться для всей корреспонденции.

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

Продолжение следует...

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