Аксапта как фронт-офисное решение в рознице.

[vc]

Добрый день, уважаемые участники.
Хочу поднять тему, отчасти ранее обсуждаемую на данном форуме, но несколько в ином разрезе.
Для начала немного о себе Региональная ИТ компания, основные направления бизнеса – оптовая и розничная торговля компьютерной и цифровой техникой, позаказное и мелкосерийное производство компьютеров, проектный бизнес (построение сетей передачи данных), сервисные услуги (собственный сервисный центр).
Проекту 1.5 года, Аксапта 3.0 СП3, вертикальное решение Корус Ритейл. MS SQL Server 2000. Около 100 пользователей, автоматизированы все вышеперечисленные направления бизнеса, распределительный центр (адресное хранение не применяется, используются WiFi терминалы сбора данных в режиме онлайн – реализовано через интеграцию Аксапты с ДКЛинк) Внешние силы при внедрении не привлекались.
За время развития проекта, компания тоже не стояла на месте. Сейчас и по масштабам и по структуре сильно отличается от себя самой полутора (даже и более чем двухгодовой, с учетом периода принятия решения и выбора ERP системы) давности.
Ну и теперь собственно к теме ветки:
В том, что касается розницы – не сразу, но было принято и реализовано решение в качестве фронт-офиса использовать ту же Аксапту. Вот некоторые резоны к этому:
• Функциональность фронт офисного решения штатно предлагавшегося в связке с Корус Ритейл нас не устраивала. Скажем, отсутствие контроля остатков при отгрузке товара, естественное в продовольственной рознице, при продаже тех же ноутбуков нам казалось серьезным ограничением.
• Наши розничные магазины, плохо это или хорошо, в значительной мере работают не с розничным покупателем. Объем операций с юридическими лицами в них очень значителен. Мы имеем весь набор требований к обеспечению этих операций, скажем контроль кредитного лимита при отгрузке, возможность заведения карточки клиента в магазине и т.д.
• Формирование индивидуальной спецификации компьютера при работе с покупателем – мы так или иначе выстраиваем производство в Аксапте. Обеспечивать аналогичный функционал во внешней системе – кажется очень дорого по ресурсам.
• В целом вопрос сложности ведения автоматизации в нескольких системах. Вопросы интеграции торгового оборудования, доработки по кассовому учету – все это мне представляется несопоставимым со сложностью реализации единых правил в принципиально разных системах, администрированием системы распределенных приложений, обеспечением их интеграции в условиях постоянных изменений бизнес процессов компании и т.д.
• Единая система, это возможность использования единых бизнес-процессов. Оформление доставки клиенту едино в розничном магазине, оптовом отделе и сервисном центре, как и оформление доставки по межскладскому перемещению. Набор мотивационных показателей для менеджера по приемке в сервисном центре, и кассира в розничном магазине не идентичен, но достаточно схож. Большая разница – реализовывать ли их учет в двух системах, или в одной.

На самом деле этот список можно продолжать и на данном этапе развития компании принятое в свое время решение на мой взгляд доказало свое право на жизнь. Но есть и другие резоны
На момент начала проекта в компании был только один магазин. Собственно сам проект (запускаемый поэтапно) начался как запуск второго магазина, нового для нас на тот момент формата самообслуживания. Доля сотрудников розничных магазинов в штате компании, их доля в оборотах компании, в объеме учитываемых операций – была значительно ниже нынешней. Сейчас у нас три магазина в единой системе – через год это количество удвоится. То есть мы получим небольшую, но вполне реальную розничную сеть, без планов приостановки расширения. Возникает вопрос – где границы применимости нашей модели? Для трех магазинов она представляется оправданной. Для сотен магазинов, скажем 1000 розничных рабочих мест – вероятно нет. А где сейчас, по вашему мнению, пролегает эта грань? Прежде всего – какие на данный момент ваши представления о тех масштабах проектов, в плане количества пользователей, которые характерны/целесообразны для проектов на Аксапте.
Скажем года два назад, из просматриваемых обсуждений я выносил мнение, что 100 пользователей для Аксапты это нагрузка относительно банальная, 200 – типичный крупный проект, а 500 в общем проект выдающийся, требующий экстраординарных программных и аппаратных решений. Изменилась ли, и насколько радикально, по вашему мнению эта ситуация с выходом четверки?
Ну и еще один мотив – выгоды централизованного решения мне представляются значимыми. Но я не знаю (буду рад узнать) ни одного случая где фронт офис на Аксапте как у нас являлся бы неотделимым от бэк офиса. Очевидно, есть резоны, по которым такое решение не является характерным.
Буду рад если вы поделитесь своими соображениями на этот счет.

[twilight]

У вас все три магазина в одной базе Аксапты? А если связь с базой обрывается, то магазин перестает работать?

[vc]

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

[vc]

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

[twilight]

На 3-ке по идее через некоторое время у вас должны RecId закончится. А в 4-ке их гораздо больше, так что есть смысл в переходе.

[Alex_KD]

...или 5ку ждать

[twilight]

У нас у самих есть розничное решение для сети (пара десятков магазинов по продаже продуктов питания), но на Аксапте там только центральный офис и распределительный центр. А для фронт-офиса используется другая система, которая поддерживает распределенные базы. И для отчетности по продажам, помимо отчетов в Аксапте, настроен OLAP на 2005 SQL Server.

[vc]

Цитата:

Сообщение от twilight

У нас у самих есть розничное решение для сети (пара десятков магазинов по продаже продуктов питания), но на Аксапте там только центральный офис и распределительный центр. А для фронт-офиса используется другая система, которая поддерживает распределенные базы. И для отчетности по продажам, помимо отчетов в Аксапте, настроен OLAP на 2005 SQL Server.

Олап у нас конечно настроен тоже. И для продуктовой розницы мы бы наверняка не использовали фронт-офис на Аксапте. Но для дорогостоящей, сложной техники возникают процессы, которые кажется легче и эффективнее решать в единой системе. Вот один пример - в сервисный центр приносят проданный в нашем магазине ноутбук. В сервисном листе (из гарантийного талона или кассового чека) заполняется номер исходной накладной по продаже. В дальнейшем, скажем случае неремонтопригодности - автоматически формируется кредит нота по соответствующей строке накладной. На балансе клиента сформировалось сальдо, которое он сразу может выбрать в том же или другом магазине покупкой этого же или иного товара. Или он может получить деньги обратно. Но не в том случае, если продажа проходила по договору кредита – в таком случае возврат денег по этой схеме невозможен. А как мы узнаем был этот ноутбук продан по кредиту или нет, если его безлично продали в Crystal.Set? Я имею в виду именно именно подобные сюжеты. Их удельный вес в общем объеме операций нашей розницы высок. Трудоемкость их реализации даже в случае с единой системой - выше их веса в общем объеме.

[mazzy]

Цитата:

Сообщение от vc

Возникает вопрос – где границы применимости нашей модели?

1. связь. но вы о ней уже ответили
2. стоимость решения. дело в том, что стоимость пользователей не зависит от используемого ими функционала. Да, это упрощает схему лицензирования. Но если у вас 200-300 продавцов и всего лишь 20-30 остальных пользователей, то платить одинаково за всех становится жалко. Здесь может выручить то, что у вас отраслевое решение (для него возможна индивидуальная схема) и много пользователей (для такого случая можно говорить об индивидуальных условиях)
3. необходимость обеспечить режим 24/7/365. Дело в том, что в Аксапте предусмотрены регламентные процедуры. Самая известная - закрытие склада. Но есть и расчет курсовых, и пересчеты, и проверки целостности, обновления статистики, переиндексации, бэкапы... Во время регламентных процедур люди работать конечно могут. Но скорее всего они будут заблокированы блокировками. В корусе, насколько я помню, что-то делали с закрытием. Поэтому важность этого пункта не так велика. Но это тоже граничное условие.

Цитата:

Сообщение от vc

Для сотен магазинов, скажем 1000 розничных рабочих мест – вероятно нет.

Если однотипные, то почему бы и нет?
А вот если разные с разным ассортиментом и разными правилами, то вполне возможно, что да.

Цитата:

Сообщение от vc

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

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

Цитата:

Сообщение от vc

Изменилась ли, и насколько радикально, по вашему мнению эта ситуация с выходом четверки?

Не. То же самое, вид сбоку.
Улучшения есть. Но и функционала тоже стало больше. Радикальным рост я бы не назвал.
Вот переход на SQL2005, да сильно изменил ситуацию.

Цитата:

Сообщение от vc

Ну и еще один мотив – выгоды централизованного решения мне представляются значимыми. Но я не знаю (буду рад узнать) ни одного случая где фронт офис на Аксапте как у нас являлся бы неотделимым от бэк офиса. Очевидно, есть резоны, по которым такое решение не является характерным.

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

[vc]

Спасибо за разбор, Маззи.

Цитата:

Сообщение от vc

Возникает вопрос – где границы применимости нашей модели? Для трех магазинов она представляется оправданной. Для сотен магазинов, скажем 1000 розничных рабочих мест – вероятно нет.

Цитата:

Сообщение от mazzy

Если однотипные, то почему бы и нет?
А вот если разные с разным ассортиментом и разными правилами, то вполне возможно, что да.

Или я неправильно вас понял, или мои собственные оценки разнятся в данном вопросе. Как раз выделение во внешний фронт-офис однотипных, как можно более несложных по функционалу, рабочих мест, мне бы показалось более приемлимым. Если бы магазин можно достаточно было бы себе представить черным ящиком, внутренняя жизнь которого в течение дня не требует регулировки и регламентации системой. Если бы достаточно взаимодействовать только с его интерфейсами, обмениваясь складскими документами…
Есть у нас и такая схема – с иногородним магазином. Это боль. Не только в плане реализации всех этих интерфейсов, худо бедно это реализовано. Серьезнее то, что при таком подходе, во всяком случае у нас так получается, как раз обеспечить соблюдение правил оказывается сложно. В Аксапте мы на три (было время и на два) магазина могли реализовать поддержку двух разных форматов. И отличия между ними достаточно серьезные – магазин салон с торговлей по образцам, и магазин самообслуживания. Скажем в первом случае прием денег по кассе ведет к созданию складского документа на отгрузку, который затем обрабатывается работником склада и никакой менеджер доступа к складским операциям не имеет. Во втором кассир сам выдает товар, выделенных складских работников нет, и обработка накладной происходит в одной транзакции с разноской кассового журнала при приеме денег.
А в случае с удаленным магазином (не Аксапта) в сущности не удается оказать поддержку никакого формата. Может быть конечно это издержки нашего дефицита ресурсов, но реально сложно то, что сделано в Аксапте повторно реализовывать не в ней.
Моя исходная посылка о 1000 пользователях - это опасения предела масштабируемости. А нагрузка на систему от того, что пользователи выполняют схожие операции сильно снижаться не будет, как я понимаю.

[mazzy]

Цитата:

Сообщение от vc

Или я неправильно вас понял, или мои собственные оценки разнятся в данном вопросе. Как раз выделение во внешний фронт-офис однотипных, как можно более несложных по функционалу, рабочих мест, мне бы показалось более приемлимым.

Скорее, я невнятно сказал.
Согласен с вашими выкладками.

[vc]

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

Цитата:

Сообщение от mazzy

Не. То же самое, вид сбоку.
Улучшения есть. Но и функционала тоже стало больше. Радикальным рост я бы не назвал.
Вот переход на SQL2005, да сильно изменил ситуацию.

В то же время есть тема Почему AX 4.0 стала еще быстрее
Почему AX 4.0 стала еще быстрее
Убедительной мне кажется статья Dynamics AX 4 и IMTS
http://www.ms-dynamics.ru/blog/2007/...s-ax-4-i-imts/

То есть имеются причины, которые вроде бы должны привести к росту производительности – и переработка ядра, и достаточно глубокая переработка базового функционала.
Кроме того, имеются (хоть и немногочисленные) и свидетельства, подтверждающие этот рост. На Аксфоруме:

Цитата:

Сообщение от eugene egorov

Докладываю - новый год стартовали на 4-ке
….
Улучшилась ситуация с блокировками при складских операциях - благотворно сказался измененный способ обновления InventSum и оптимистическая модель блокировок.
….

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

То есть разница в оценках налицо.
Одно возможное объяснение:
Может быть, те проекты, где улучшения незаметны, изначально достаточно сильно оптимизированы. Скажем на сайте Маззи есть совет по борьбе с хинтами в запросах. Если его выполнить на тройке для достаточного количества запросов, то эффекта тотального отказа от хинтов в четверке можно и не заметить. Ну и значительного улучшения ситуации с блокировками может не произойти, если изначально у вас не было блокировок.
То есть предположение состоит в том, что четверка подняла нижнюю планку производительности проекта out of the box. А так как эта нижняя планка кем то достигается (мы скажем получили драматическое снижение производительности системы при росте количества пользователей с 30 до 50, совсем не драматические цифры для Аксапты) а кем то нет - то и замечают это изменение не все.

[twilight]

А все же, про RecId, вас не беспокоит, что они у вас могут закончиться?

[vc]

Цитата:

Сообщение от twilight

А все же, про RecId, вас не беспокоит, что они у вас могут закончиться?

Текущий показатель RecId меньше четырехсот миллионов. Надеюсь, что у нас есть в запасе полтора-два года, пока мы не достигнем 4 (или правильный вариант двух?) миллиардов.

[twilight]

2 года пройдут быстро, значит переходить на 4-ку или 5-ку все равно придется

[vc]

Цитата:

Сообщение от twilight

2 года пройдут быстро, значит переходить на 4-ку или 5-ку все равно придется

Вы правы, но есть и разница: на четверку или на пятерку, сейчас или через два года, один или два раза - сейчас и через два года.