Описание неудачного проекта в крупной ретейловой конторе
http://sap-in-store.narod.ru/
Была попытка установить САП в магазинах в качестве бэк-офиса. Проект провалился. При анализе причин провала посчиталим, что в целом сама архитектурная модель порочна. Но так ли это?
Действительно ли САП как бэк-офис - неудачный вариант?

ПРедложение первое-- развернуть такую ветку в логистике (MM, LO, SD) ну и в IS-Retail

Уважаемый BAE, Выы наверно не вникли в тему.

В САПе была реализована часть бизнес-процессов бэк-офиса магазина. Естественно, для этого были задействованы модули ММ, IS-Retail. Но проблемы то возникли не в САПе, а на участке передачи информации в систему фронт-офиса магазина. Именно из-за того, что операции в магазине регистрируются в разных системах, то синхронизация информации по остаткам - очень сложный вопрос. Тот метод, что был выбран в этой конторе оказался не совсем удачным.
Если Вы имели в виду реализацию процессов фронт-офиса в среде САП, то это не возможно, т.к. САП не работает с кассовыми аппаратами...

Вопрос - была ил фронтофисная система настолько закрыта, что невозможно было наладить онлайновое взаимодействие?

Я не специалист в области ретейла. Просто выскажу свое мнение со стороны.
Мне кажется, что в ретейле, при использовании пакетного интерфейса обмена данных, всегда будут проблемы с определением остатков по складу и проводкам фин.документов. Целесообразнее бы было отказаться от использования локального ПОМ вообще и заменить и фронт-офис на SAP. Только в этом случае все операции будут проходить в рантайме и оперативная отчетность будет достоверной.

А постановка "Действительно ли САП как бэк-офис - не удачный вариант?" не корректна. Та же ситуация будет с любой системой при использовании указанной архитектуры.

Свяжу темы http://sapboard.ru/forum/viewtopic.php?t=33990

Как вариант можно было сделать "кнопку" для загрузки/выгрузки.

Я думаю, обсуждение лучше все-таки вести в одном форуме.
Так что темы будут слиты и перемещены на форум по отраслевым решениям.

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

1) SAP действительно не умеет общаться с кассовыми аппаратами, да и обычно в магазинах стоят свои магазинные системы, заточенные под бизнес-процессы компании. Поэтому магазинные системы целесообразно оставить.
2) Тут встает вопрос интеграции SAP и ИС магазина. Основные направления:
- Из САП в Ис магазина. Справочники (товары, цены)
- Обратно в САП. Загрузка продаж
- Двухсторонняя интеграция склада магазина с САП (доставка товара в магазин, отгрузка товара из магазина при перемещении в другие объекты сети, инвентаризация, укомплектование-разукомплектование, списание, перемещения внутри склада и т.п.).

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

То есть вопрос в балансе функций между САПом и ИС магазина. И тут нет однозначно правильного ответа - надо смотреть, какая функциональность уже есть в ИС магазина, насколько просто ее адаптировать под требования, возникшие при внедрении САП.

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

Только проблема модели вовсе не в переносе функциональности приемки товара в САП, а в этом:

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

Еще одна мысль вслух. Если есть возможность вносить изменения в ПОМ магазина, то почему бы не сделать rfc-вызов нужного ФМ (возможно самописного) в бэк-офисе SAP сразу же после проведения кассовой операции? Это относительно второй архитектурной схемы.

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

Это хорошее предлодение, однако програмное обеспечение магазина (ПОМ) - это приложение, которому около 10 лет. Это DOSовое приложение и ничего об RFC оно не знает.

Вариант с передачей из САП в ПОМ не остатков, а движений мы так же отрабатывали. Причины отказа от этого варианта следующие:
1) Это был экспериментальный проект и он задумывался как малобюджетный. Реализация схемы синхронизации ОСТАТКОВ и ДВИЖЕНИЙ в распределенных БД значительно увеличило бы объем и сроки проекта.
2) Т.к. технология RFC не поддерживается ПОМ, то придется использовать неагрегированный пакетный способ передачи данных, а это значит:
2.а) опять же непрерывный монитор для контроля прохождения каждого ИДОКа.
2.б) таже самая задержка в 30 минут
2.в) те же проблемы, что при исходной схеме, а именно искажение электронных документов, ошибки интерфейса и т.п. Т.е. то, от чего хотели уйти.
2.г) увеличение трафика, т.к. БД распределенные и передача данных проходит по Интернету. А данные о движениях не агрегированы, т.е. для каждого движения необходимо в ИДОКе заполнять заголовок. Для одного магазина это вреде не существенно, но в масштабе всей сети ...
Именно из-за этих причин мы выбрали схему с передачей только остатков. Причем остатки в течении дня выгружалися исключительно для товаров, по который произошли изменения остатков. А ночью остатки в ПОМ полностью затирались остатками САПа по всем товарам.

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

Если отвлечься от конкретного проекта, а проанализировать саму схему, то получается, что единственно верное решение при интеграции фронт-офиса в виде ИС магазина и бэк-офиса в виде САП - это использование технологии RFC для синхронизации движений и соответственно остатков. Я правильно вас понял? (вопрос к аудитории)[/list]

Из своего личного опыта на Retail-проекте...

Все движения товара в магазине (приемка, внутреннее перемещение, отгрузка, кроме продаж) выполняются в интерфейсе SAP. В момент проводки документа товара в расширении аккурат перед обновлением таблиц в SAP выполняется вызов посредством RFC в магазинную систему, в которой выполняется транзакция изменения запасов. Если она неудачная, то в SAP проводка документа товара откатывается.

Схема оказалась работоспособной.

Правда, отлаживали ее очень долго, около полугода.

Основные причины:
1. Невозможность организации единой транзакции (просто не смогли это сделать);
2. Косяк в ядре SAP при обновлении таблиц - была обнаружено непредсказуемое изменение ключа обновления (VBKEY - кто знает ABAP, тот поймет);
3. Просто программные ошибки.

Разумеется, торговая ИС должна работать не под DOS, а использовать последние коммуникационные возможности.

Кстати, еще идея с того же проекта, которая оказалась рабочей...

Можно нарисовать свою транзакцию, которая работает по схеме:

1. Проводка докуента товара через BAPI
2. RFC-вызов в торговую ИС для обновления запасов
3. Если обновление в торговой ИС не прошло, то сторно документа товара.

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

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

Мы умудрились сделать универсальную морду, в которой поддерживается большинство видов движений MM (для транзакций MB1A, MB1B, MB1C). Да и кладовщикам в магазине с неполным средним образованием (учитывая повышенную текучку таких кадров) приходится меньше данных вводить - согласитесь, основная масса ошибок не технического, а прикладного характера...

Согласен, это действительно хороший вариант. Получается, что две системы работают в режиме он-лайн.


Тоже рабочая схема. Спасибо за совет.
Значит в нашем случае необходимо зайти с другой стороны - сначала заменить ИС магазина на современный софт.