Yandex.Метрика

OMS: система управления заказами

Внедрение проекта OMS: мой опыт внедрения.

В данной статье я расскажу о своем опыте внедрения системы OMS (Order Management System или Система Управления Заказами). Рассмотрим преимущества, недостатки, подключение дополнительных модулей и требования для расширения до полноценного проекта VMI (Vendor Managed Inventory или Запасы Управляемые поставщиком).

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

Важно! Очень часто некоторые люди путают две системы: OMS и CRM (Customer Relationship Management). Важно понимать, что OMS — это система управления заказами, и предназначена она в первую очередь для создания, обработки и управления заказами, и именно об этом будет идти речь. CRM-система предназначена для управления взаимоотношениями с клиентами: в ней ведется учет клиентской базы, хранятся личные данные клиентов и история взаимодействия с ними, а также содержится различная информация о задачах, сделках и заказах.

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

Проект OMS: введение.

Чаще всего, промышленные предприятия и поставщики, работая с крупными федеральными сетями, получают заказы через EDI-сервисы (системы электронного обмена данными): заказ формируется в электронном виде и поступает в базу данных поставщика. Помимо этого, формируется ряд различных электронных документов: накладные, акты, счета, уведомления и так далее. Это очень удобно, быстро и практично.

Но помимо работы с федеральными сетями, поставщики работают и с дистрибьюторами. И проблема заключается в том, что большая часть дистрибьюторов к EDI-сервисам не подключена (потому что для дистрибьюторов это невыгодно). Поэтому, чаще всего заказы подаются через менеджеров посредством электронной почты: либо в письме просто сообщается, на какие номенклатуры необходимо сформировать заказ, либо заполняется бланк с номенклатурами и с соответствующими объемами для того или иного дистрибьютора и так же отправляется по почте. Кто-то умудряется формировать заказ по телефону или через мессенджеры. Это вполне нормальная практика, в этом нет ничего плохого, но при такой механике формирования заказов возникает ряд проблем:

  • Банально, но заказ может затеряться в почте. Такое, хоть и не часто, но бывает. Последствия могут быть крайне неприятными, особенно если дистрибьютор сравнительно недавно стал сотрудничать с поставщиком и еще не может быть полностью уверен в его надежности: возможно резкое снижение заказываемых объемов или даже полная замена ассортимента на ассортимент конкурента.
  • Если менеджер высылает заказ в бланке: позиции в бланке могут быть неактуальными. Замена одной позиции на другую, вывод из ассортимента, появление новых позиций, смена количества вложений в одной упаковке той или иной номенклатуры: если хоть что-то в бланке не учтено — бланк уже неактуальный. При загрузке заказа в систему, могут возникнуть ошибки. Придется уведомлять об этом менеджера, менеджеру придется перезаполнять новый бланк, заказ придется принимать заново, а это всё — двойная работа.
  • Большие временные затраты на ручное формирование заказа, его обработку и корректировки. Нужно открыть АКТУАЛЬНЫЙ бланк, заполнить данные по заказу, ввести дату доставки клиенту, зайти на почту и отправить этот бланк. Заказ необходимо принять, проверить на корректность данных, проверить актуальность бланка, загрузить заказ в систему, уведомить менеджера о принятии и так далее. На это все нужно время. Если заказ необходимо скорректировать — повторяем алгоритм, снова тратим драгоценное время.
  • Невозможность добавления различных модулей типа рекомендованного заказа или установки принудительных ограничений при формировании заказов.

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

Проект OMS: готовое решение или собственная разработка?

Система, которая упрощает и автоматизирует процесс приема и обработки заказа называется OMS — Order Management System или система управления заказами. В интернете по ней предлагается множество готовых решений, но нужно понимать, что у каждого предприятия свои особенности, и вряд ли они все учтены в каком-либо готовом решении. Я считаю, что принимать решение о внедрении стороннего софта нужно опираясь на две составляющие: бюджет, выделяемый на внедрение системы и наличие квалифицированного штата программистов в Вашей компании.

Что касается моего опыта работы, в первом случае, хоть у нас и были квалифицированные программисты, был также и огромный бюджет: мы не просто потратили средства на приобретение готового решения и его настройку, мы заключили договор со сторонней организацией, которая под нашим контролем создавала новое программное обеспечение, основываясь на нашем техзадании и наших требованиях. Была разработана веб-версия OMS системы, написанная на языке PHP, с большим набором скриптов и различных модулей и подключенная к нескольким базам данным. Быстро, качественно, и с интуитивно-понятным интерфейсом, со множеством функций. Однако, были и минусы: дороговизна разработки и появление некой «зависимости» от сторонних программистов (в случае чего, все доработки делают только через них).

Во втором случае разработку системы OMS мы поручили своим программистам. Бюджет был ограничен, но в то же время хотелось сделать систему максимально удобной и многофункциональной.  Хорошо это или плохо, но веб-версия OMS-системы была разработана на базе платформы 1С 8.3. Да, вероятно это самое простое решение, но нужно понимать, что функционал 1С для разработки такой системы может быть сильно ограничен (не в обиду тем, кто программирует на 1С), поэтому с реализацией некоторых модулей могут возникнуть проблемы (они и возникали). Из плюсов стоит отметить минимальные затраты, отличную синхронизацию с основной базой данных компании и более-менее понятный интерфейс для тех, кто хоть немного работал в 1С. Из минусов: длительность разработки и некоторая ограниченность в функционале, дизайне и модулях.

На длительность внедрения повлияли следующие факторы:

  • Занятость сотрудников отдела программирования: помимо работы над проектом, была еще и оперативная работа.
  • Опять же, ограниченность в функционале 1С. Приходилось как-то «изворачиваться», чтобы тот или иной модуль работал корректно.
  • Ошибки OMS-системы после публикации веб-версии 1С (в веб-версии не работала часть кода, которая работала в обычном клиенте 1С, поэтому пришлось кое-что переделывать).

В итоге, внедрение прошло успешно, все нужные функции все-таки были реализованы. На изображении ниже — «Основное рабочее место» системы OMS для принятия и подтверждения заказов:

OMS, Система Управления Заказами: Рабочее место

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

Покупать готовый продукт или разрабатывать свою систему — целиком и полностью Ваше решение. Но рекомендую подойти к этому максимально ответственно: оцените временные и финансовые затраты, риски, проведите SWOT-анализ и после этого примите правильное решение.

Проект OMS: разработка и особенности внедрения.

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

Функционал системы OMS можно разделить на 3 части:

  1. Основной функционал. Прием, корректировка, обработка заказов и самый простой набор элементов интерфейса. Это тот минимум, с которым уже можно пользоваться системой. Замена ручной работы на автоматизированную уже есть.
  2. Дополнительный функционал. Различные модули, доработки, функции и элементы интерфейса, облегчающие работу как для менеджеров, так и для специалистов из клиентского сервиса. Без всего этого работать можно, но с ним намного удобнее. Чаще всего, это внедрение какой-либо распространенной функции, либо функции «по требованию»: в моем случае, это были требования либо вышестоящего руководства (им хотелось именно так и никак иначе), либо требование тестовой группы (из будущих пользователей системы для тестирования были отобраны несколько человек).
  3. Потенциал. Все, что еще можно внедрить в систему, но по какой-либо причине, либо отложено на потом, либо вообще не рассматривалось к внедрению.

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

Дополнительный функционал и особенности проекта:

  1. Разделение ролей пользователей. Роль «Менеджер» подразумевает создание заказа на определенного контрагента и отслеживание его статуса (видны только свои заказы). Роль «Клиентский сервис» — подтверждение или отмена заказа того или иного менеджера (видны заказы всех менеджеров).
  2. Функция рекомендованного заказа. Внедрена в точности, как я ее и описывал в своей статье. Система Управления Заказами подключена к базе данных, в которой хранятся вторичные данные дистрибьютора: остатки на складах и вторичные продажи. При формировании заказа, торговый представитель может включить отображение объемов рекомендованного заказа и автоматически их подставить.
  3. Система уведомлений. Менеджерам и сотрудникам клиентского сервиса приходят уведомлении о поступлении заказа в систему, о корректировках, принятии и отмене заказа.
  4. Удобное управление корректировками и отмена заказа. Для того, чтобы скорректировать заказ, можно просто дважды щелкнуть по нему. Он откроется в новом окне, где можно сразу же скорректировать уже заказанные объемы на необходимые (при условии, что не превышен допустимый срок корректировки). Также, добавлена подсветка скорректированных значений.
  5. Загрузка и заполнение объемов прошлого заказа или среднее значение объемов нескольких прошлых заказов (опционально, стандартное значение — 5, можно увеличить до 10). Помимо этого — подсветка позиций прошлого заказа: очень полезно, особенно если ассортимент очень большой и время поиска нужной номенклатуры необходимо свести к минимуму.
  6. Документ «Диспо-схема», содержащий информацию о плановом дне неделе подачи заказа на того или иного контрагента, а также соответствующий день отгрузки и доставки. Если менеджер подает заказ и день подачи заказа совпадает с днем подачи заказа в документе «Диспо-схема» — дата отгрузки и доставки заказа рассчитывается и подставляется автоматически.
  7. Синхронизация с основной БД компании: всегда актуальные номенклатуры, контрагенты и их свойства, отображение статуса формирования маршрута и комплектации, моментальная миграция заказа из OMS-системы БД компании, отображение статуса контрагента (находится ли контрагент в ПДЗ или нет).
  8. Ограничения при формировании заказа: ограниченное количество корректировок, запрет на поздние корректировки и так далее.
  9. Отслеживание статуса заказа: принят, скорректирован, отклонен, укомплектован.
  10. И другие узкоспециализированные функции, которые актуальны только для моего предприятия.

Примерная схема работы системы OMS в моем представлении со всеми дополнительным функционалом выглядит так:

OMS, система управления заказами: схема работы

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

Проект OMS: потенциал и расширение до полноценного проекта VMI.

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

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

Другая функция — подключение инструментов BI-аналитики для построения отчетности с элементами визуализации. Например, можно подключить такое программное обеспечение, как Power BI или Qlikview. Благодаря ему, можно строить различные многоуровневые сложные графики, диаграммы, гистограммы, которые будут отображать динамику продаж и статистику. Отслеживая всё это, можно проводить расширенную аналитику и находить слабые места в продажах и быстро на них реагировать.

Также, в OMS можно добавить следующие мелочи:

  • Отслеживание остатков на складах, чтобы менеджер видел, какая продукция в дефиците в момент формирования заказа. Но тут довольно спорная ситуация, менеджер данную функцию может обратить в свою пользу: в попытках выполнить свой план продаж не перегружая склады дистрибьютора, он будет заказывать большие (правильнее сказать «невыполнимые») объемы дефицитной продукции. Здесь все будет зависеть от политики той или иной компании.
  • Отслеживание цен на ту или иную продукцию.
  • Модуль прогнозирования, основанный на вторичных продажах.
  • Печать документов, договоров, бланков.
  • Проверка корректности ввода данных (округлять согласно количеству штук в одной упаковке).
  • Адаптация веб-интерфейса для мобильных устройств.
  • Отслеживание маршрутов.

Если все функции объединить в одной системе и добавить функцию автозаказа (заказ на дистрибьютора формируется автоматически в зависимости от потребности, без участия менеджера), то данную систему уже можно будет считать полноценной системой VMI (Vendor Managed Inventory или Запасы Управляемые Поставщиком). И в таком случае, дистрибьютор целиком и полностью перекладывает всю ответственность по управлению запасами на своих складах на поставщика. В полноценной VMI системе есть свои преимущества и недостатки, но о них мы поговорим в отдельной статье.

Проект OMS: возможные проблемы при внедрении.

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

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

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

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

Проект OMS: заключение.

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

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

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

6 комментариев

  1. Ольга 15.01.2020
  2. Владимир 15.01.2020
  3. Андрей 07.04.2020
    • HeinzBr 07.04.2020
  4. Jamesbailt 29.04.2020

Оставить комментарий