Автор статьи: Александр Цыбизов, руководитель департамента автоматизации продаж и клиентского сервиса компании "Константа".
Как вы считаете, реализовать проект автоматизации сбытовых процессов на предприятии, где каждый день отгружается 200-300 заказов – также сложно, как если на кону 2-3 тысячи заказов? Казалось бы, если взять одинаковое ПО, то какая разница, сколько через него будет проводиться операций? Однако это только на первый взгляд. В реальности и процессы, и система, и подход к ее внедрению, и результат проекта, очень разные.
Не то, чтобы крупные предприятия как-то иначе продают, нет. Процессы похожие или одинаковые. Но есть несколько существенных отличий, без учета которых проект с большой долей вероятности зайдет в тупик. А даже если он и завершится, то результат будет настолько стыдным, что всей проектной команде будет мучительно больно за напрасно прожитые годы.
Сегодня разберемся, на что нужно обратить внимание, чтобы попасть в категорию тех, кто получил от проекта то, что хотел, (а не то, что получилось).
Какие они – предприятия «высшей лиги»?
Прежде чем перейти к особенностям автоматизации торговли у предприятий «высшей лиги», давайте разберемся, кто в нее вообще входит.
Мы выделяем несколько критериев, на которые можно ориентироваться:
- количество торговых SKU – от 1500
- объем документооборота:
- количество заказов – от 2000
- количество реализаций – от 2500
- количество заданий на перевозку – от 200
3. организационные параметры торговой деятельности:
- количество каналов продаж – от 10
- количество специалистов клиентского сервиса – от 20
- количество специалистов выписки – от 40
- количество одновременно работающих пользователей системы – от 300
Чем характерны проекты автоматизации торговли на таких предприятиях?
1. Бизнесовые особенности: многовариантность сценариев исполнения бизнес-процессов.
В средних и малых предприятия, как правило, есть базовый стержневой сценарий для каждого функционального раздела ИТ-системы. Этого достаточно. У крупных же предприятий может быть до десятка вариантов «закоулков» протекания каждого процесса. Не учесть их – невозможно. Учитывать и закладывать во внедряемую систему каждый сценарий – либо избыточно, либо даже вредно (часто новые сценарии появляются в разрез правил/целей, как разовая/временная мера, которая приживается и становится постоянной). И для того, чтобы правильно отсечь лишние варианты процессов – нужны особые методологические и коммуникационные компетенции, чтобы договориться о правильных решениях с бизнес-заказчиками.
2. Разветвленность интеграционного ландшафта.
В торговых проектах «высшей лиги» интеграционный ландшафт – это далеко не только выгрузка в бухгалтерский учет. Как правило, это большое количество соседних программных продуктов, систем, модулей (причем на разных платформах), с которыми торговая система взаимодействует. Причем интеграционные потоки можно поделить на 2 группы: это функциональные интеграции – максимально оперативные обмены, происходящие внутри исполняемого бизнес-процесса (например, система маршрутизации рейсов). И смежные интеграции – это как правило асинхронные (посмертные) выгрузки данных в соседние системы (это как раз выгрузка в бухучет или кубы). Для организации обменов в сложном интеграционном ландшафте требуется специализированные компетенции и инструменты по промышленным обменам данных.
3. Технологические требования: быстродействие, отказоустойчивость системы на тех объемах данных, с которыми приходится работать. Сбытовые процессы любого предприятия самые «близкие к деньгам». Именно поэтому важна скорость и своевременность выполнения операций, оформления документов. Для этого к системе управления торговлей с одной предъявляются жесткие требования по доступности, минимизации технологических перерывов. А с другой стороны – по всем критичным для бизнеса операциям система должна «летать».
4. Особенности организации процесса внедрения системы (управления проектом).
Во-первых, когда организация коммуникаций выходит на корпоративный уровень, велика вероятность появления политического подтекста в поведении ключевых участников команды. И понимание расклада сил: коалиционных групп и их интересов, явных и латентных сторонников и противников проекта – становится уже не факультативной, а гигиенической задачей в управлении проектом, чтобы управляемо двигать решения и работы по проекту вперед, а не попадать в управленческие ловушки или тратить время (силы, деньги) на «переобувания» в принимаемых проектных решениях.
Во-вторых, в корпоративных проектах практически гарантирована высокая конкуренция за время ключевых функциональных руководителей для обсуждения и принятия проектных решений: как правило такие специалисты кроме своей основной работы задействованы в еще нескольких проектах изменений и, к сожалению, не всегда готовы/могут найти нужное количество времени.
5. Высокий уровень архитектурного и методологического качества системы.
Требование к качеству системы – вопрос из категории очевидно-неочевидного. С одной стороны очевидно – что всем нужны качественные системы (и не нужны некачественные). С другой стороны – что такое качество система и его обеспечить – вопрос точно неочевидный. При этом довольно часто в проектах корпоративного масштаба и продолжительности к моменту их завершения в системе накапливается такой объем технического долга (функциональные, методологические, архитектурные противоречия и «заплатки»), что по завершению проекта возникает жгучее желание перевнедрить только что внедренную систему.
Чтобы поддерживать качество системы на желаемом уровне на протяжении всего проекта, необходимы компетенции, процессы и инструменты для методологического и архитектурного контроля принимаемых решений.
И как со всем этим справиться?
На вебинаре совместно с ИТ директором «КОМОС ГРУПП» расскажем о проекте внедрения «1С: Управление торговлей 8», как ключевого звена портфеля проектов цифровой трансформации холдинга.
Запись вебинара можно найти в телеграм-канале: https://t.me/digital4food
· Как это – интегрировать систему в ИТ ландшафт, часть элементов которого еще не существует даже на уровне требований?
· С чем пришлось столкнуться при автоматизации 13 функциональных областей в рамках одного проекта?
· Как обеспечить целостную производительность системы на 4500 заказов в сутки и перспективой на рост еще до запуска?
· А главное: какие инструменты и технологии помогли нам со всем этим справиться?