Автоматизация торговли для тех, кому за… 2000 заказов в сутки

Материал подготовлен совместно с партнером комьюнити Digital4food, компанией Константа.

Как вы считаете, реализовать проект автоматизации сбытовых процессов на предприятии, где каждый день отгружается 200-300 заказов – также сложно, как если на кону 2-3 тысячи заказов? Казалось бы, если взять одинаковое ПО, то какая разница, сколько через него будет проводиться операций? Однако это только на первый взгляд. В реальности и процессы, и система, и подход к ее внедрению, и результат проекта, очень разные.

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

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

Какие они – предприятия «высшей лиги»?

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

• количество торговых SKU – от 1500
• объем документооборота:
  • количество заказов – от 2000
  • количество реализаций – от 2500
  • количество заданий на перевозку – от 200
• организационные параметры торговой деятельности: 
  • количество каналов продаж – от 10
  • количество специалистов клиентского сервиса – от 20
  • количество специалистов выписки – от 40
  • количество одновременно работающих пользователей системы – от 300

Чем характерны проекты автоматизации торговли на таких предприятиях?

1. Бизнесовые особенности: многовариантность сценариев исполнения бизнес-процессов. 

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

2. Разветвленность интеграционного ландшафта.

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

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

4. Особенности организации процесса внедрения системы (управления проектом).

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

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

5. Высокий уровень архитектурного и методологического качества системы.

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

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

И как со всем этим справиться?

19 декабря приглашаем вас на вебинар «Как управлять БОЛЬШИМИ проектами? Кейс автоматизации «КОМОС ГРУПП» на 100 000 человеко-часов».

На вебинаре совместно с ИТ директором «КОМОС ГРУПП» расскажем о проекте внедрения «1С: Управление торговлей 8», как ключевого звена портфеля проектов цифровой трансформации холдинга.

• Как это – интегрировать систему в ИТ ландшафт, часть элементов которого еще не существует даже на уровне требований? 
• С чем пришлось столкнуться при автоматизации 13 функциональных областей в рамках одного проекта? 
• Как обеспечить целостную производительность системы на 4500 заказов в сутки и перспективой на рост еще до запуска? 
• А главное: какие инструменты и технологии помогли нам со всем этим справиться?

Регистрируйтесь по ссылке и до встречи онлайн!