Делаем процесс обработки заявок на поставку металлопроката прозрачным и организованным. Кейс "МЕТЧИВ"

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

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

О клиенте: задачи, особенности

К нам обратилась компания "МЕТЧИВ" (далее по тексту Метчив)— поставщик металлопроката различных типов. Она производит изделия из специальных сталей и сплавов, в том числе по индивидуальным чертежам заказчиков. Компания известна не только в России, но и за рубежом. В Метчив обращаются с различными заказами, каждый из которых требует пристального внимания и согласования со стороны специалистов: сотрудники ПЭО (планово-экономического отдела), коммерческий, генеральный директора и другие. Менеджер в зависимости от нескольких критериев (степень сложности детали, итоговое изделие, необходимые технологии) определяет, по какому алгоритму согласовывать сделку (кому направлять).

Задачи клиента

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

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

• сделать процесс согласования сделок прозрачным и организованным; 
• упростить обработку и сделать гибким решение по заявкам; 
• отслеживать движение Сделки в Битрикс24 без необходимости заходить в 1С. 

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

Громоздкий бизнес-процесс

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

Давайте подробнее рассмотрим процесс. Отдел продаж начинает обрабатывать заявку от клиента, как только она поступает. Для начала, сотрудники проверяют контрагента на благонадежность: изучают сведения из ФНС, Росреестра и Арбитражного суда. Затем направляют сделку на согласование:

• с руководителем отдела продаж;
• с руководителем отдела продаж и коммерческим директором;
• с главным технологом и коммерческим директором;
• с генеральным директором.

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

Битрикс24

Итак, менеджер наполняет информацией Сделку в Б24. Есть обязательная информация, без которой заявки рассматриваться точно не будут. Эту информацию менеджер дублирует в форме согласования для следующего сотрудника, который будет рассматривать Сделку. Раньше приходилось подключать смекалку менеджера: в ход шли телефон, смс, письма, служебные записки — все что душе угодно. Однако это было неудобно, ведь:

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

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

Знать клиента — основа успеха

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

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

Дополнительная форма согласования

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

Информация в Формы загружается автоматически после того, как менеджер добавит сведения в Сделку. Процесс работает в обе стороны: если сотрудник заполнил Форму, но не внес информацию в Сделку, то она там все равно появится. Это удобно, ведь не приходится делать лишние шаги. Смысл Формы в том, чтобы как можно быстрее запустить процесс согласования. В этом случае, весь процесс будет перед глазами у менеджера, информация точно не потеряется, а (с учетом других нововведений ↓ ) процесс будет проще.

Третий вариант решения: Запуск пересчета

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

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

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

Давайте посмотрим на один из вариантов согласования сделки. От потенциального заказчика поступает заявка, и менеджер запускает ее на согласование с главным технологом и коммерческим директором. Для начала заявка попадает на «стол» главному технологу, он передает её сотруднику ПЭО, который рассчитывает стоимость по сделке в зависимости от входных данных. После этого сделка возвращается к менеджеру. И вот тут у него появляется варианты:

• Согласовать расчет и отправить коммерческому директору. Тогда сделка проходит через директора и попадает на стадию ТКП или счет (в зависимости от того, что указано в формате ответа в Форме).
• Не согласовать. Менеджер видит, что сделка не рентабельна, или нет возможности её выполнить и отказывает в дальнейшей работе по ней.
• Запустить перерасчет. Такой вариант выбирают, если появились новые данные, они уточнялись или изменились. В данном случае появляется дополнительная форма, где менеджер вносит свои комментарии, прикрепляет документы и запускает процесс согласования снова. Однако это не новый процесс, а зацикленный старый.

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

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

1С

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

Загружаем базу

Заказчик пришел к нам с сильно переработанной платформой 1С, которую предстояло интегрировать с Битрикс24. Без интеграции систем, сотрудникам пришлось бы создавать заявку покупателя (1С) и сделку (Битрикс) отдельно друг от друга, то есть дублировать свои действия, в том числе создавать контрагентов. Например, если сделать в 1С заявку с контрагентом, которого нет в Б24, то нужно создать этого контрагента и на корпортале. Только после этого создавать Сделку с ним в Б24. Лишние шаги в алгоритме. Чтобы убрать их, мы загрузили базу клиентов из 1С в Битрикс24 и интегрировали платформу с корпорталом.

Перед дальнейшей разработкой проекта, мы провели объемную работу по загрузке базы клиентов из 1С в Битрикс24. Мы анализировали все контакты и решали:

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

Интеграция платформ и перенос базы помогли автоматически создавать заявки в 1С с теми контактами, которые есть в Битрикс24 (и наоборот). В случае, если соответствующего контрагента в 1С нет, то он автоматически создается на платформе. 

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

Параллельные статусы в 1С и Битрикс24

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

• на какой стадии сделка и что будет следующим шагом;
• когда заказ завершится и товар будет отгружен.

Без них, процесс производства тяжело отслеживать.

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

Когда в Битрикс24 согласуют сделку, она переходит на стадию Счет (сразу или после стадии ТКП). В это время в 1С появляется Заявка покупателя (далее — ЗП) на основе данной Сделки из Битрикс24. На базе ЗП сотрудник создает Заказ на производство (далее — ЗПр). И вот с этим документом отделы производства и работают. ЗПр — это такой документ, в котором указаны детали заказа покупателя: что необходимо сделать, размеры, материал, количество, а также сроки выполнения заказа. У каждого ЗПр есть статусы:

• подготовлен к производству;
• маршрутный лист создан;
• на корректировке;
• на ознакомлении с коммерческим директором; принят в работу;
• продукция выпущена;
• отгружено и другие.

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

Нашими задачами были:

1. отследить статусы ЗПр;
2. перемещать автоматически Сделку в Битриксе в зависимости от статусов ЗПр.

С одним ЗПр все понятно: меняется его статус — меняется статус у остальных сущностей. Однако, сотрудник может создать как один ЗПр, так и несколько — в зависимости от сложности проекта. Как тогда учесть все статусы в одной Сделке?

В таком случае на базе ЗП делаем Основной Заказ (далее — ОЗ), и уже на его основе сотрудник создает несколько ЗПр. Когда статусы у ЗПр меняются, то меняется статус ОЗ, а от него по цепочке меняется и статусы у ЗП и Сделки.

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

Единый ответственный

Для заказчика важен порядок в делах. Это значит, что сделка и заказ должны быть закреплены за одним сотрудником. Поэтому, кроме статусов заказов в 1С, мы сделали ещё одну разработку: ЗП и ЗПр создавался с тем же ответственным, что и Сделка в Битрикс24.

Битрикс24 пока создает заказ в 1С, смотрит на специальное поле — почта. Главное — найти в 1С сотрудника с такой же электронной почтой, как в Битрикс24. Система ставила его в качестве ответственного за Сделку и Заказ: он отслеживал статус проекта, контролировал процесс. В случае, когда система не находит сотрудника с такой же почтой как в Б24, то автоматически делает текущего пользователя ответственным за Сделку и Заказ.

К чему мы ведем?

Такие доработки, как:

• форма согласования;
• дополнительные поля для дочерних компаний;
• цикличность процесса согласования заявки (третий вариант решения);
• синхронизированный статус заказа и сделки;

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

У Вас похожие задачи или бизнес? Обратитесь к нашим сотрудникам для детальной консультации. Вместе мы подберем оптимальное решение.