Проблемы работы ERP в многофилиальной и территориально разнесённой компании СНГ.

[SlavaK]

У нас в компании следующая ситуация:

Я работаю в торговой компании, имеющей подразделения в 18 городах Казахстана, занимающиеся оптовой/мелкооптовой/розничной торговлей. Вся информация по работе каждого подразделения должна стекаться ежедневно в Центральный офис компании. Обеспечить постоянную связь с каждым регионом в теории можно, но на практике не хотелось бы, т.к. при обрыве канала связи, не хотелось бы останавливать работу филиала, т.к. клиент подразделения в регионе не должен ждать пока связь наладят с Центральным офисом, а записывать на бумажке/в экселе, а потом перебивать в систему не вариант. А при работе с розничной торговлей вообще не приемлимо. Не представляю ситуацию, что супермаркет останавливает свою работу, только из-за того что прервалась связь с Центральным офисом, который находится в другом городе.

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

Решено купить ERP-систему, но встаёт обратная проблема: Большинство ведущих ERP-систем удовлетворяют наши функциональные потребности, но не могут нормально реплицировать данные, т.е. не могут "разрулить" ситуацию когда каждое подразделение нашей компании работает со своей БД, а скажем один/несколько раз в день проходит репликация, которая доставляет данные на Центральный сервер, а оттуда доставляется остальным подразделениям в части касающейся их информации.

Если я ошибаюсь - большая просьба, Вопрос №1 укажите ERP-систему или решение для какой-либо ERP-системы, которое смогло бы решить наши потребности в репликации.

Что касается этой проблемы в Axapta:

1. Прочитал на сайте Mazzy http://consulting.mazzy.ru/erp/ :
>Не стоит покупать Microsoft Business Axapta: Если у вас отсутствует постоянный канал и вы хотите реплицировать ВСЕ данные между территориально распределенными подразделениями. Т.е. Если постоянный канал отсутствует, то придется применять изощренные методы решения данной проблемы. Главное, значительно усложняется администрирование системы. Да, работа удаленных подразделений без постоянного канала связи возможна, но такое решение вряд ли можно назвать эффективным.

2. Прочитал в данном форуме трейд :
http://www.axforum.info/forums/post7743
Обращался к scof за более подробной информацией он пока не ответил

Из всего этого в Вопрос №2: Как вы считаете целесообразно ли прикручивать к Axapte самописную репликацию? Или стоит поискать другую ERP-систему?
Насколько возможны/критичны при варианте прикручивания репликации к Axapt-е следуюшие проблемы:
a) потеря сопровождения от парнёра-внедренца - из-за изменения структуры таблиц. Или структуру таблиц менять не придётся? Мы когда реализовывали в своей автоматизированной системе репликацию на Oracle, добавляли уникальное поле для отслеживания записи и поле для разрешения конфликтов между серверами - аналогичное как MS SQL-ной репликации.
б) Работа Axapt-ы не нарушится при добавлении полей для репликации если их придётся всё таки добавлять.
в) Очень тяжело будет накатывать новые изменения и исправления в Axapt-у с сохранением изменений внесённых в Базовую версию, касающихся репликации.

Заранее благодарен за ответ.

[komar]

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

[SlavaK]

Кomar, спасибо за ответ, но как всегда возникли дополнительные вопросы:

Цитата:

Изначально опубликовано komar
При работе с розничной торговлей при обрыве связи может работать специальное ритейловое ПО, которое может обмениваться данными с основной системой, например, раз в день.

Интересно, а почему нельзя тогда применять ритейловое ПО не только для розничной торговли, но и для мелкооптовой/оптовой торговли? Или функционал у ритейлового ПО сильно обрезан? Может быть у Вас есть ссылки где можно почитать про технические и функциональные возможности Axapta ретейл?

Цитата:

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

Ну так и мы очень сильно сомневаемся в этом решении, но пока других вариантов в Axapta не видим. Другое дело если бы 3-ёх звенка Axapt-ы ещё позволяла бы сохранять на клиенте часть данных, а при появлении связи выкидывала бы их на сервер Центральной БД, как в Midas, но насколько я понял в Axapt-е такая функция не реализована?

Цитата:

Изначально опубликовано komar
Добавление полей - это не проблема,

Уточните, пожалуйста - при добавлении нами поля в таблицу Axapt-ы все механизмы Базовой Конфигурации, которые работают с этой таблицей, будут так же безошибочно отрабатывать?

Цитата:

Изначально опубликовано komar
проблема в определении того, каким образом будут решаться проблемы, связанные с изменением одних и тех же данных в разных инсталляциях, т.е. каким образом будут разрешаться подобные конфликты.
Односторонняя репликация "филиал - клиент" однозначно может быть реализована.
Поскольку процедуры разрешения конфликтов у Вас, судя по всему , отработаны на сторой системе, можно построить и "двухстороннее" решение.
Такие вещи писались различными партнерами неоднократно.

Да в принципе на старой системе механизм разрешения конфликтов продуман с учётом приоритета сервера/филиала/пользователя и т.п. Для каждой таблицы можно поставить свой вид приоритета и метод реализации разрешения конфликта update. Но я думаю что прикручивание к конфигурации партнёра-внедренца ещё и нашей репликации - это самый крайний случай, т.к. в этом случае нам придётся изучать не только структуру всех таблиц, но и возможно бизнес процессы проводки в таблицы (для того чтобы грамотно навесить правила приоритетов на каждую таблицу). И соответствено время написания репликации/разрешения конфликтов может затянутся на длительное время. Не могли бы вы дать названия фирм внедренцев, реализовавших хотя бы односторонюю репликаци и если есть то предприятия на которых такая репликация успешна внедрена?

Цитата:

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

В связи с этим вопрос, а при покупки лицензии на модуль исходники модуля предоставляются? Т.е. есть возможность сотрудникам предприятия, на котором проходит внедрение, самим исправить код Базовой конфигурации, перекомпилить и затем использовать его?

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

А может быть ещё лучше найти ERP-систему в которой возможность репликации уже реализована, наравне с удовлетворяющем нас функционалом.

[komar]

Цитата:

Изначально опубликовано SlavaK
Интересно, а почему нельзя тогда применять ритейловое ПО не только для розничной торговли, но и для мелкооптовой/оптовой торговли? Или функционал у ритейлового ПО сильно обрезан? Может быть у Вас есть ссылки где можно почитать про технические и функциональные возможности Axapta ретейл?

Наверное, можно. Акзапта ритейл живет на www.axaptaretail.ru , Навижновский ритейл живет на сайтах Импакт-Софт и IBS.

Цитата:

Изначально опубликовано SlavaK
Ну так и мы очень сильно сомневаемся в этом решении, но пока других вариантов в Axapta не видим. Другое дело если бы 3-ёх звенка Axapt-ы ещё позволяла бы сохранять на клиенте часть данных, а при появлении связи выкидывала бы их на сервер Центральной БД, как в Midas, но насколько я понял в Axapt-е такая функция не реализована?

Да, такого нет. Базы либо разные, либо одна. Но предлагаю все-таки сопоставить затраты на поддержку репликации и на установку каналов связи.

Цитата:

Изначально опубликовано SlavaK

Уточните, пожалуйста - при добавлении нами поля в таблицу Axapt-ы все механизмы Базовой Конфигурации, которые работают с этой таблицей, будут так же безошибочно отрабатывать?

Да, будут.

Цитата:

Изначально опубликовано SlavaK

Да в принципе на старой системе механизм разрешения конфликтов продуман с учётом приоритета сервера/филиала/пользователя и т.п. Для каждой таблицы можно поставить свой вид приоритета и метод реализации разрешения конфликта update. Но я думаю что прикручивание к конфигурации партнёра-внедренца ещё и нашей репликации - это самый крайний случай, т.к. в этом случае нам придётся изучать не только структуру всех таблиц, но и возможно бизнес процессы проводки в таблицы (для того чтобы грамотно навесить правила приоритетов на каждую таблицу). И соответствено время написания репликации/разрешения конфликтов может затянутся на длительное время. Не могли бы вы дать названия фирм внедренцев, реализовавших хотя бы односторонюю репликаци и если есть то предприятия на которых такая репликация успешна внедрена?

Ваш механизм, возможно, прикручивать придется. Не в плане техническом, а в плане постановки.
Мне известны следующие решения, использовавшие репликационные схемы на Акзапте или Навижн (если моя информация неверна, пусть меня поправят) -
Корус консалтинг на OSKO, IBS на Deloitte&Touche. Уверен, есть и другие, но мне далеко не все известно.

Цитата:

Изначально опубликовано SlavaK

В связи с этим вопрос, а при покупки лицензии на модуль исходники модуля предоставляются? Т.е. есть возможность сотрудникам предприятия, на котором проходит внедрение, самим исправить код Базовой конфигурации, перекомпилить и затем использовать его?

За лицензию на исходники нужно башлять отдельные деньги. Что-то около 8 тыс. долларов. За эту сумму получаете исходники всей бизнес-логики на Х++

[SlavaK]

To Komar: Спасибо большое за подробный ответ.

Единственно я не совсем понял насчёт трёхзвенки - на мой вопрос:

--------------------------------------------------------------------------------
Изначально опубликовано SlavaK
Другое дело если бы 3-ёх звенка Axapt-ы ещё позволяла бы сохранять на клиенте часть данных, а при появлении связи выкидывала бы их на сервер Центральной БД, как в Midas, но насколько я понял в Axapt-е такая функция не реализована?
--------------------------------------------------------------------------------

Вы пишите:

Цитата:

Изначально опубликовано komar
Да, такого нет. Базы либо разные, либо одна.

Я имел ввиду 3-ёх звенку, которой на клиенте не надо иметь другую базу, а достаточно иметь буфферные файлы (обычные тестовые или бинарные) в которых хранятся данные, которые не могут уйти когда нет связи, а при появлении связи данные ушли бы на Центральный Сервер. Имено так в Midas реализована работа с файлами client data set (расширение .cds). Тоже самое и со справочниками из БД Центрального сервера в начале связи они скидываются на клиентскую машину, а все изменения по ним потом при появлении связи накатываются на БД Центрального сервера. Вот я и спрашивал может быть я не имею достаточной информации - а такого рода 3-ёх звенка и организована на Axapta ?

[Lazy_Tiger]

Про Мидас. Нету в Аксапте такого. Вы либо работаете напрямую с базой используя AOS, Citrix, WEB, WAP или еще какого нить клиента, либо у вас несколько баз и вы их реплицируете.

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

Дешевле сделать между офисами канал в 256-512кбит. В 21 веке то, когда космические корабли чего то там бороздят

[SlavaK]

Ну централизованный справочник товара - помоему это очень круто
Как могут работать оптовые торговые базы через Центральный офис, когда в номенклатура товара от 1000 до 20000 товаров?
Оформяется к примеру счёт фактура поставщику - в которой несколько новых товаров, причём поставщик местный - т.е. такого товара в Центральном офисе точно ещё не заводили. Нужно отправить запрос в ЦО и ждать пока там эти товары заведут и пока они по репликации прийдут?
Если такая система с централизованной справочной системой ещё и приемлима для работы с номенклатурой производимых товаров, то для работы с номенклатурой покупаемой продукции и для работы с номенклатурой товарно материальных ценностей (ТМЦ), учитываемых в строительстве или ремонте в подразделениях компании, явно не приемлима.
Решать репликацию в общем виде с разрешением конфликтов - нам тоже не очень бы и хотелось, но если не найдём уже готового решения, то боюсь придётся.

[Lazy_Tiger]

про приход товара которого нет в справочнике. Внимание - вопрос:

А на основании чего собственно поставщик приволок вам этот товар?

Hint: может быть сначала была типа закупка (заказ товара поставщику, согласование цен и кол-ва)? А если была, товар уже в справочнике и давно реплицировался куда попало и, кстати, 10.000-20.000 номенклатуры это не много

P.S. Я типа в торговой компании внедряю, у вас пока очень простые вопросы
P.P.S. сильно рекомендую посмотреть на Axapta retail. СЕРЬЕЗНО

[SlavaK]

Цитата:

А на основании чего собственно поставщик приволок вам этот товар?

Hint: может быть сначала была типа закупка (заказ товара поставщику, согласование цен и кол-ва)? А если была, товар уже в справочнике и давно реплицировался куда попало

Хорошо, вполне возможно что был сначала и заказ товара поставщику, хотя вполне могла быть и закупка без заказа (торговый менеджер договорился и купил товар без заказа), НО заказ товара поставщику не обязательно должен проходить через Центральный Офис, заказ товара, согласование цены и количества чаще проводить само региональное подразделение, соответственно и характеристики нового товара знает лучше региональное подразделение, само собой что именно в региональном подразделении должны заводить товар, т.к. уже перед оформлением самого заказа товара поставщику товар уже должен быть заведён в справочник. Или Вы предлагаете заводить все заказы товара в ЦО или вообще в другой системе?

Цитата:

сильно рекомендую посмотреть на Axapta retail. СЕРЬЕЗНО

Посмотрел по ссылкам по Axapta retail, которые рекомендовал Komar, но пока не нашёл как технически там решена проблема с передачей данных и синхронизацией справочников. Может у кого есть подобная техническая информация или ссылки на неё. Буду очень благодарен.

Да и почему то позиционируют Ахапту ритейл как для предприятий розничной торговли, нас же интересует не только розничная торговля, но и торговля оптом: по договорам, под консигнацию, вот и хотелось бы точно знать сможет ли Ахапта ритейл обеспечить нужный нам функционал.

[ARahmanov]

Возможно что в заблуждение вводит именно название продукта )
Многие организации использующие отраслевое решение AxaptaRetail имеют разные каналы сбыта : Опт, розница, дистрибуция а также производственные участки

[Торгаш]

А я от своих партнеров по бизнесу, внимательно смотревших это решение для своей сетки, слышал что axaptaretail это не более чем файловый стык AXAPTA и кристалловского кассового сервера. Т.е. это жесткая привязка к кассам и услугам этой компании из СПб. Оно вам надо? Нас, например, наши ПОСы и так устраивают.
Из описания с их сайта вывода о реализуемости "распределенных БД в AXAPTA" я сделать не могу. Может я не туда смотрел? Покажите.

[Lazy_Tiger]

Цитата:

Изначально опубликовано Торгаш
А я от своих партнеров по бизнесу, внимательно смотревших это решение для своей сетки, слышал что axaptaretail это не более чем файловый стык AXAPTA и кристалловского кассового сервера. Т.е. это жесткая привязка к кассам и услугам этой компании из СПб. Оно вам надо?

Не правда, вот у нас например псевдоПОС-терминалы стоят.

Цитата:

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

ДАВИТЬ! ОДНОЗНАЧНО! Мы бардак автоматизируем или порядок наводим?

Цитата:

... характеристики нового товара знает лучше региональное подразделение

Безусловно, пусть заведет его в основной базе, заодно будут проведены проверки на его уникальность, правильность заполнения полей, выполнение правил наименования и т.д. И оно реплицируется куда попало. Или у вас ассортиментную политику определяет филиал?

[ARahmanov]

Хм, вообще то в Axapta Retail нет привязки к конкретной кассовой системе, и на практике реализована стыковка с тремя разными конфигурациями торгового оборудования магазинов.

А что касается "просто стыковки" в случае заинтересованности могу предоставить "краткую справку по функциональности"

[Alex_K]

To ARahmanov: А по типам касс/кассовых модулей можно подробнее? И про готовые стыки с весами...

[SlavaK]

Цитата:

Изначально опубликовано Lazy_Tiger

Не правда, вот у нас например псевдоПОС-терминалы стоят.

Недавно со своим знакомым спорил насчёт автоматизации розницы в ERP-системе или в отечественной системе. Одним из самых больших аргументов в пользу отечественной системы (не буду называть какой - могут поставщики обидется) цена - за ПО на один объект розничной торговли из 5 терминалов и 6 весов продают за 15'000$ с установкой настройкой и обучением. Думаю, что подобное решение на Axapta Retail на порядок дороже.

Да и страно одна из крупных компаний внедренцев, занимающаяся и Axapta и Navision, тоже отговаривала от реализации розницы на Axapta, аргументируя тем что Navision более приспособлена к рознице. А прикручивание розницы на отечественной системе или на Navision-е ко всей остальной ERP-системе на Axapta по моему равнозначно одинаково - вариант не лучший.

Цитата:

Изначально опубликовано Lazy_Tiger

ДАВИТЬ! ОДНОЗНАЧНО! Мы бардак автоматизируем или порядок наводим?

Для автоматизации торговли я согласен - можно потребовать закупку у поставщиков только через заказы, НО есть исключения из правил - менеджер по закупкам поехал к поставщику, какой-то номенклатуры продукции, которая указанна в заказе не оказалась, но есть товар сходный, который можно купить вместо отсутсвующего, так что ему возвращаться и исправлять заказ? Или с Вашей точки зрения такой ситуации быть не должно?

Для учёта ТМЦ и ОС так ещё хуже ситуация - в вашем подразделении сломался конвеер по подаче продукции на складе - срочно отправили снабженца покупать запчасти по ремонту. Он купил и привёз - теперь что нельзя оформлять покупку без заявки? Или ТМЦ и ОС в Axapt-е уже не ведём?

Цитата:

Изначально опубликовано Lazy_Tiger

Безусловно, пусть заведет его в основной базе, заодно будут проведены проверки на его уникальность, правильность заполнения полей, выполнение правил наименования и т.д. И оно реплицируется куда попало. Или у вас ассортиментную политику определяет филиал?

Я понимаю когда закупки в большей степени централизованы для всех подразделений компании - то может быть это ещё и приемлимо, но если в любом из региональных подразделений могут покупать и определять что покупать самостоятельно от Центра, а постоянного выделенного канала до Центрального офиса нет, то тут и встаёт вопрос как это сделать не на центральном сервере БД, а у себя - в региональном подразделении. Вопрос встаёт в синхронизации справочников - да это больная тема, но ещё не понятно что сложнее реализовать постоянное соединение - там где его нет или вообще не может быть, или выправить ошибки заведение справочной информации, которые будут появлятся после синхронизации справочников.

Может разница подходов к проблеме у нас из-за разницы в условиях? :-)

[Lazy_Tiger]

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

[Alex_K]

Цитата:

Изначально опубликовано SlavaK


Для автоматизации торговли я согласен - можно потребовать закупку у поставщиков только через заказы, НО есть исключения из правил - менеджер по закупкам поехал к поставщику, какой-то номенклатуры продукции, которая указанна в заказе не оказалась, но есть товар сходный, который можно купить вместо отсутсвующего, так что ему возвращаться и исправлять заказ? Или с Вашей точки зрения такой ситуации быть не должно?

Знаю довольно крупную сеть супермаркетов, где ситуация обстоит (или обстояла) именно так. Товар, отсутствующий в справочнике номенклатуры, в природе не существует...

[Lazy_Tiger]

Цитата:

Изначально опубликовано Alex_K


Знаю довольно крупную сеть супермаркетов, где ситуация обстоит (или обстояла) именно так. Товар, отсутствующий в справочнике номенклатуры, в природе не существует...

а иначе попытки свести концы с концами, хоть как то упорядочить закупки и элементарно навести порядок в справочнике номенклатуры (а не называть один и тот же товар в разных магазинах по разному) на мой взгляд просто НЕВОЗМОЖНО.

И не нада утрировать - если этот товар нада закупить, будет принято решение, он появится в справочнике и будет закуплен

[KMV]

2SlavaK

Прошло уже полгода, после этого обсуждения.
Можно узнать, к каким выводам пришли.
Я так понимаю, вы еще в поисках были.