Текущее время: Пн, июл 07 2025, 15:10

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 23 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: SAP в роли бэк-офиса на магазине - благо или наказание?
СообщениеДобавлено: Чт, фев 07 2008, 08:40 
Ассистент
Ассистент

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт, фев 07 2008, 09:35 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Ср, окт 03 2007, 11:41
Сообщения: 160
ПРедложение первое-- развернуть такую ветку в логистике (MM, LO, SD) ну и в IS-Retail


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт, фев 07 2008, 10:28 
Ассистент
Ассистент

Зарегистрирован:
Пт, июл 14 2006, 04:29
Сообщения: 26
Уважаемый BAE, Выы наверно не вникли в тему.

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт, фев 07 2008, 10:50 
Младший специалист
Младший специалист

Зарегистрирован:
Вт, авг 22 2006, 13:37
Сообщения: 54
Пол: Мужской
Вопрос - была ил фронтофисная система настолько закрыта, что невозможно было наладить онлайновое взаимодействие?


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт, фев 07 2008, 11:18 
Гуру-эксперт
Гуру-эксперт
Аватара пользователя

Зарегистрирован:
Ср, ноя 03 2004, 14:51
Сообщения: 1912
Откуда: КраснАдар
Пол: Мужской
Я не специалист в области ретейла. Просто выскажу свое мнение со стороны.
Мне кажется, что в ретейле, при использовании пакетного интерфейса обмена данных, всегда будут проблемы с определением остатков по складу и проводкам фин.документов. Целесообразнее бы было отказаться от использования локального ПОМ вообще и заменить и фронт-офис на SAP. Только в этом случае все операции будут проходить в рантайме и оперативная отчетность будет достоверной.

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт, фев 07 2008, 11:20 
Гуру-эксперт
Гуру-эксперт
Аватара пользователя

Зарегистрирован:
Ср, ноя 03 2004, 14:51
Сообщения: 1912
Откуда: КраснАдар
Пол: Мужской
Свяжу темы http://sapboard.ru/forum/viewtopic.php?t=33990


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт, фев 07 2008, 11:33 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Ср, окт 03 2007, 11:41
Сообщения: 160
Как вариант можно было сделать "кнопку" для загрузки/выгрузки.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт, фев 07 2008, 11:43 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Вт, май 17 2005, 13:35
Сообщения: 4871
Откуда: Москва
Пол: Мужской
Я думаю, обсуждение лучше все-таки вести в одном форуме.
Так что темы будут слиты и перемещены на форум по отраслевым решениям.

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

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

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

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

_________________
Удача - результат нашего желания (© А. Нортон)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт, фев 07 2008, 21:04 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Вт, май 17 2005, 13:35
Сообщения: 4871
Откуда: Москва
Пол: Мужской
Хм, прочитал статью. Похоже с примером баланса функций между системами по приемке товара я попал в точку :)
Согласен с утверждением
Цитата:
недостатки обусловлены именно особенностями концептуальной модели и не могут быть полностью устранены

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

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

Вот эту проблему и надо решать в первую очередь :)

_________________
Удача - результат нашего желания (© А. Нортон)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт, фев 07 2008, 21:14 
Гуру-эксперт
Гуру-эксперт
Аватара пользователя

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Чт, фев 07 2008, 22:05 
Гуру-модератор
Гуру-модератор
Аватара пользователя

Зарегистрирован:
Вт, май 17 2005, 13:35
Сообщения: 4871
Откуда: Москва
Пол: Мужской
Интересно, конечно, какую сторону представляет автор первоначального поста и сайтика на Народе. Но, боюсь, он нам не признается ;)

_________________
Удача - результат нашего желания (© А. Нортон)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, фев 08 2008, 04:09 
Ассистент
Ассистент

Зарегистрирован:
Пт, июл 14 2006, 04:29
Сообщения: 26
Цитата:
Если есть возможность вносить изменения в ПОМ магазина, то почему бы не сделать rfc-вызов нужного ФМ (возможно самописного) в бэк-офисе SAP сразу же после проведения кассовой операции?

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

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

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

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Из своего личного опыта...
СообщениеДобавлено: Пт, фев 08 2008, 10:42 
Старший специалист
Старший специалист
Аватара пользователя

Зарегистрирован:
Сб, окт 16 2004, 11:27
Сообщения: 348
Откуда: Москау
Пол: Мужской
Из своего личного опыта на Retail-проекте...

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

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

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

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

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

_________________
Тот, у кого хватит храбрости и терпения всю жизнь вглядываться во мрак, первым увидит в нём проблеск света


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, фев 08 2008, 10:54 
Старший специалист
Старший специалист
Аватара пользователя

Зарегистрирован:
Сб, окт 16 2004, 11:27
Сообщения: 348
Откуда: Москау
Пол: Мужской
Кстати, еще идея с того же проекта, которая оказалась рабочей...

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

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

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

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

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

_________________
Тот, у кого хватит храбрости и терпения всю жизнь вглядываться во мрак, первым увидит в нём проблеск света


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, фев 08 2008, 11:39 
Ассистент
Ассистент

Зарегистрирован:
Пт, июл 14 2006, 04:29
Сообщения: 26
Цитата:
Все движения товара в магазине (приемка, внутреннее перемещение, отгрузка, кроме продаж) выполняются в интерфейсе SAP. В момент проводки документа товара в расширении аккурат перед обновлением таблиц в SAP выполняется вызов посредством RFC в магазинную систему, в которой выполняется транзакция изменения запасов. Если она неудачная, то в SAP проводка документа товара откатывается

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

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

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 23 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB