Автоматизация клиентского сервиса. Кому? Зачем?

Сегодня поговорим о клиентском сервисе у производителей продуктов питания.

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

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

«ИТакСойдет» и его последствия

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

// Пример. В старой системе не получалось загружать и обрабатывать 1,5 тысячи заказов одновременно (долго проводились, была большая нагрузка на людей для обработки этой информации). Как следствие, реализации в системе корректировались прямо в процессе отгрузок. За счет такой «заглушки» была решена проблема нагрузки на систему, но зато напрочь терялась аудируемость цепочки поставок. Во и получается, что при попытке автоматизировать процессы приемки и обработки заказов, люди перетаскивают вот такие «лучшие практики» из старой системы в новую. Хотя объективно это не несет в себе никакой пользы.

Данный пример показывает, что для успешного перевода процессов работы с заказами из одной системы в другую требуется хорошо проработать модель процессов и требований к их настройке в ИТ-системе: описать особенности и функции процессов, исполнителей и связки их взаимодействий по времени и последовательности. Все понимают, что проект смены платформы будет стоить денег. Соответственно, логично, чтобы они были конвертированы в реальные улучшения, а не стали оплатой замены «шила на мыло».

Гигиенический уровень организации клиентского сервиса на разных этапах развития бизнеса

Чтобы определить достаточный уровень требований к системе клиентского сервиса, разделим предприятия на несколько категорий в зависимости от текущего объема обработки заказов:

• До 200 заказов в день

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

• 200-600 заказов в день

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

• Более 600 заказов в день

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

Механика конвейера обработки заказов как отраслевой стандарт

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

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

Чтобы понять, что именно мы автоматизируем, разберем процесс работы с заказами пошагово – от фиксации их в ИТ-системе до отгрузок и обработки документов отгрузок.

На картинке выше приведен перечень блоков с разбивкой на базовые (должны присутствовать в стандартной системе клиентского сервиса у любого современного производителя продуктов питания) и на дополнительные, позволяющие реализовать в системе ту часть функций, которая может стать причиной повышенной конкурентоспособности предприятия, но которая чаще всего остается за бортом автоматизации – в Excel. А такой инструментарий на больших объемах клиентских заказов ни к чему хорошему не приводит. Рассмотрим каждый блок в отдельности.

1. Ценообразование (соглашения, скидки, базовые и зависимые прайс-листы, запланированные трейд-маркетинговые мероприятия)

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

2. Формирование заявки на производство (на выработку, упаковку и маркировку готовой продукции) и подтверждение ее исполнимости

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

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

3. Прогнозирование остатка на момент отгрузки принятых заказов и корректировка на доступный объем

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

4. Формирование планов отгрузок

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

5. Формирование рейсов

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

6. Сборка заказов и подготовка к отгрузке

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

7. Отгрузка и формирование накладных

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

8. Формирование возвратов

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

9. Работа с бумажными документами отгрузки

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

10. Претензии и возвраты

В ежедневной деятельности предприятия неизбежны моменты, когда по результатам отгрузки какой-то объем товара может быть возвращен. Для этого в системе должна быть возможность фиксации возврата товара от покупателя «в день отгрузки». Но также бывают ситуации, когда клиент может формировать претензии уже после отгрузок. Такие запросы должны фиксироваться в системе, отдельно обрабатываться и по каждой такой ситуации принимается решение – оформлять возврат или нет.

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

Наличие корректно учтенных данных по уровням производственного, складского, логистического и клиентского сервисов позволяют закрывать 2 важные задачи:

• Аудит клиентского сервиса

При общении с сетями не редки ситуации, когда по внутренним данным предприятия уровень клиентского сервиса составляет 97%, а вот по данным сетей может быть значительно ниже (например, 80%). Система позволяет аудировать и грамотно оценивать уровень сервиса + может быть серьезным подспорьем в переговорах с сетями.

• Единство данных внутри предприятия

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

Проблемы клиентского сервиса при смене платформы ИТ-системы

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

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

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

Как сохранить уровень клиентского сервиса при смене платформы IT-системы?

На этот вопрос эксперты отрасли ответят 29 апреля на вебинаре, посвященном автоматизации клиентского сервиса для производителей продуктов питания.

Поговорим о том:

• Как и что менять в клиентском сервисе при смене платформы IT-системы?
• На каких платформах лучше всего решать задачу? Типовое флагманское или отраслевое решение выбрать?
• Какие ошибки чаще всего допускаются в рамках проектов автоматизации?

Узнать подробности о программе и зарегистрироваться вы можете на сайте https://standart1c.ru/eventerp.

До встречи ON-line!