SAP в магазинах розничной сети.
Анализ причин неудачного завершения проекта.

 

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

Крупная розничная компания по продаже бытовой техники имеет следующую архитектуру:

§        В розничных магазинах в качестве фронт-офиса и бэк-офиса используется программа собственного производства "ПОМ" (программное обеспечение магазина), которая покрывает все процессы, происходящие в рамках магазина. 

§        В ЦР установлена ERP система SAP, которая покрывает процессы, происходящие в рамках ЦР.

§        В ЦР установлена центральная БД ПОМ, в которую стекаются данные об операциях всех магазинов за один день. Эти данные затем агрегируются и передаются в SAP. Из SAP в центральную БД ПОМ выгружаются данные о выписке товара на магазин (т.е. плановые поступления товара), которые передаются в локальную БД ПОМ каждого магазина.  Используется пакетный способ передачи информации. Данные передаются один раз в сутки, ночью.

Такая схема передачи информации, т.е. двойной интерфейс, ( локальный ПОМ ↔ центральный ПОМ ↔ SAP ) имеет ряд недостатков, таких как низкая оперативность передачи информации, искажение электронных документов, ошибки интерфейса и т.п. Исходная схема взаимодействия представлена в приложении № 1.

Для устранения подобных недостатков был инициирован проект по переносу ряда бизнес-процессов магазинной части в SAP. В результате для реализации была выбрана концептуальная модель, см. приложение № 2. В соответствии с новой концепцией, ПОМ стал выполнять только роль фронт-офиса, а SAP – роль бэк-офиса магазина. Необходимо отметить, что реинжиниринга процессов не было, т.е. в SAP реализовали те же процессы, что были ранее в ПОМ. Эксперимент проводился на двух магазинах.

Проект был реализован, но потерпел неудачу после 10 дней функционирования. Причины остановки проекта следующие:

1.     Если рассмотреть технологический процесс движения товара от ЦР до потребителя, то становится видно, что при перемещении товара из ЦР в магазин новая схема обеспечивает оперативность, целостность и непротиворечивость информации. Но товар быстрее от этого ехать не стал. Т.о. магазин оперативно получает информацию в SAP о том, что на него выписан товар, но все равно ждет некоторое количество времени, пока товар приедет. Только после этого информация о выписке становится востребованной. Но для того, что бы продать товар, необходимо обновить остатки во фронт-офисе. А между SAP и фронт-офисом  налажена пакетная передача данных каждые полчаса. Следовательно, после регистрации прихода товара в SAP магазин вынужден ждать еще полчаса, чтобы начать торговлю товаром.
Т.о. мы видим, что при перемещении товара из ЦР в магазин оперативность поступления информации была достигнута, но при дальнейших физических операциях с товаром в магазине оперативность сопровождения информацией была утеряна.

2.     В связи с тем, что на состояние учетных остатков в SAP могут влиять приходы/расходы в SAP, продажи/возвраты во фронт-офисе, то для обеспечения достоверной информацией об остатках необходимо обеспечить полное и корректное поступление информации из фронт-офиса. А т.к. пакетная передача информации осуществляется раз в полчаса, то для контроля закачки необходим постоянный мониторинг. В случае зависания хотя бы одного IDOC'а, уже нельзя говорить о достоверности остатков в любой системе.  При прежней  схеме, закачка осуществлялась один раз в сутки и не требовала непрерывного мониторинга. Т.о. становится очевидным, что в случае тиражирования новой схемы на всю розничную сеть потребуется увеличение человеческих ресурсов для мониторинга интерфейса и обеспечение оперативного реагирования при возникновении неполадок.

3.     Т.к. при разработке проекта была низкая степень взаимодействия между проектной группой и функциональными специалистами заказчика,  то некоторая часть бизнес-процессов не попала в зону покрытия SAP и не могла уже быть обеспечена фронт-офисом. Но эти проблемы имели не критичное значение и могли быть решены в ближайшей перспективе.

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

Сайт управляется системой uCoz