Текущее время: Пн, ноя 03 2025, 11:20

Часовой пояс: 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
Сообщения: 4875
Откуда: Москва
Пол: Мужской
Я думаю, обсуждение лучше все-таки вести в одном форуме.
Так что темы будут слиты и перемещены на форум по отраслевым решениям.

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

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

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

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

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


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

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

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

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

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

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


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

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


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

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

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


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пт, фев 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
Сообщения: 349
Откуда: Москау
Пол: Мужской
Из своего личного опыта на Retail-проекте...

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

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

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

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

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

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


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

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

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

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 часа


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

Сейчас этот форум просматривают: Ahrefs [Bot]


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

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