500 пользователей - какая система?

[LCh]

Ахапка будет работать с 500ми пользователями легко при условии, что у вас будут профессиональные программисты, профессиональные администраторы и инженеры сервера БД. Одно только портит впечатление - закрытие склада.

[Тимур]

Ну не только закрытие склада. Скажем проведение накладных по закупкам и заказам тоже будет не очень быстро делаться.

[ppson]

Цитата:

Изначально опубликовано Тимур
Ну не только закрытие склада. Скажем проведение накладных по закупкам и заказам тоже будет не очень быстро делаться.

Особенно по заказам из за расчета мгновенной средней.

[Valery]

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

[fed]

Valery - у нас как раз был случай зажатия мгновенной себестоимости финансвыми аналитиками. Разносили журнал списаний в котором было тысяч 5-7 строк с серийными номерами в финансовой аналитике. Как показал натурный эксперимент - рассчет мгновенной себестоимости занимал процентов 50 от общего времени разноски. Которое было не приемлимым совсем.
Так что рассчет себестоимости списания на больших объемах - это как раз серьезная проблема, которую так просто не обойти.

Кстати - мне кажется что слухи о тормознутости закрытия склада сильно преувеличены

Во первых после того как в 3.0SP2 сделали многопользовательское закрытие склада - производительность закрытия растет почти линейно с увеличением числа рабочих станций закрывающих склад.
Во вторых - как показали эксперименты - после 20-30 итераций,которые даже при большом объеме движений проходят на 2-5 часов, обычно остаются только те номенклатуры, по которым в данных есть какая-то кривизна. Ну например - сторнировали журнал перемещений (особенно - если несколько раз), а маркировку проводок не расставили. Или просто сторнировали складские движения без маркировки или установки лота возврата. Ну или наконец списали что-то до того как оно пришло. (Кстати это и без галочки отрицательный склад может быть).
В общем - методика такая - ставишь закрывать склад, потом после 20-30 итераций прерываешь и смотришь какие номенклатуры в списке закрытия остались. Откатываешь закрытие, разбираешься с этими номенклатурами (сторнируешь, добиваешься отсутствия отрицательных остатков, маркировки проставляешь и т.д). Потом снова закрываешь.
Еще помогает методика - поставить сначала коррекцию пропускной способности в маленькое число (в 5 копеек скажем), а после того как прошло какое-то разумное число итераций - поставить туда с соседней рабочей станции рубль или 5.
При этом та номенклатура, по которой данные нормальные, закроется с точностью в 5 копеек, а та по которые данные кривые (и она в 20-30-40 итераций не закрылась) закроется с погрешностью 5 рублей. В некоторых случаях это выгоднее чем долгое разбирательство и наведение порядка в данных.
Так что если пытатся с каждым закрытием склада осознанно разбираться, а не просто сидеть и ждать когда оно до миллионной итерации дойдет - то все не так уж плохо выглядит.

[Popov76]

Добрый день, SergKuz.
Меня зовут Попов Александр. Я директор компании AVASystems.
Найти людей в нашей необъятной, которые реально эксплуатировали проект подобный тому, который нужен вам практически не возможно, т.к. случай это очень редкий.
А вот команда специалистов моей компании делала такой проект и мы его реально сами поднимали. Мы были первыми в стране кто поставил Oracle в таких масштабах на Linux. Мы были первыми кто перешел на Oracle 8.1.7. Я говорю о компании МВ. Все это было в 2000-2001 годах. Нагрузки на сервер были колоссальными, до 1500 транзакций в секунду. Сервер стоял Compaq Proliant 8500 на 4-х процессорах с 4 Гбт . Количество одновременно работающих пользователей доходило до 650. Теперь мы занимаемся собственным бизнесом и продаем решение, разработанное на базе того, которое мы внедрили в МВ. Решение абсолютно не требовательно в железу по сравнению с аналогами. Ну вот пример: у одного из наших заказчиков 50 пользователей работали на сервере, который был обычным компом, работали и ничего не замечали. Сейчас проводим консалтинговый проект у одного из заказчиков, у которого те же 50 пользователей работают на 4-х процессорном сервере и все стоит "колом". Если эта информация Вас заинтересовала, мы готовы к вам подъехать и обсудить все более детально.

[George Nordic]

Добрый день, Александр!

А происходит ли у Вас резервирование товара?
А сколько длиться закрытие склада? Можно ли указать точность закрытия? При проведении заказа рассчитывается ли у вас мгновенная средняя себестоимость? Или списывается "как есть", по какой-то фиксированной величине? Реализована ли логистика, сколько складов поддерживается? Учитываются ли накладные расходы при межскладском перемещении? Какие модули / контуры автоматизированный? На чем писали?

Расскажите поподробнее, пожалуйста - очень интересно! Можно в разделе "Рынок ERP", это более подходящее место для рекламы.

С Уважением,
Георгий.

[Popov76]

Добрый день!
Клиента писали на delphi , сервер на Oracle.
Краткое описание функционала можно посмотреть на сайте www.avasystems.ru
Конечно все это поддерживается, а как Вы думаете, если мы автоматизировали МВ, в которой работало около 1500 человек, 9 региональных представительств, около 50 складов. Причем продавец Москвы мог зарезервировать товар на складе в Ростове, остатки которго он видел в он-лайне. На сайте МВ есть статьи о системе и чего она им позволяет. В таких масштабах это, наверное, был первый проект в нашей стране.
Себестоимость учитывается по средней, но есть и FIFO. Но в интерфейсе FIFO не используется ни где, просто мы сделали движок, чтобы если понадобится можно было FIFO заюзать быстро. С точки зрения количественных ограничений складов, сотрудников, уровней вложенности папок в центральном классификаторе и прочих не понятных мне ограничений в системе нет. Когда мы разрабатывали нашу систему задача стояла так - написать конструктор lego. Теперь в системе можно создавать новые формы, наследуя их, добавлять поля, менять sql-запросы, категоризировать любые объекты, менять названия элементов управления, менять отчеты. И есть еще момент: почти все можно делать из интерфейса, так чтобы не привязывать нас к себе в процессе эксплуатации продукта. Даже новая весрия системы ставиться одной кнопкой и у пользователей обновляется автоматом. Вся эта процедура занимает около 20 мин. Ну тут можно до бесконечности рассказывать. Могу все показать пальцем, прямо на ноутбуке.

[George Nordic]

На чем писали "Lego"? T-SQL + C#?

Я не против самописок, даже считаю, что иногда это - единственно приемлемое решение. Но было бы хорошо, если бы Вы по возможности максимально полно описали бы Вашу систему. К сожалению, "есть все" - это не достаточное описание. Так что ждем пресс-релиза с презентацией в PPT!

С Уважением,
Георгий.

[Popov76]

Описание на след неделе мы выложим на сайт там будет download.
А что касается "самописок", то не хоте ли Вы сказать, что Аксапту писали роботы и она совсем не самописка. Такая же самописка, только брэндовая. А учитывая, что каждый центр внедрения сам Аксапту дописывает и переписывает, то теперь сказать что такое Аксапта вообще сложновато. У каждого она своя.... Отсюда вывод.

[George Nordic]

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

Но, как бы там ни было, появление новой системы мы не можем не приветствовать.

С Уважением,
Георгий.

[Popov76]

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

[mazzy]

Цитата:

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

...что вы ошиблись в выкладках.

Аксапта - она одна. Та что на официальном дистрибутиве.
Все остальное модифицированная Аксапта.

[Popov76]

А эта Аксапта, которая одна, она у кого-нибудь работает?
Сомневаюсь.

[mazzy]

Работала. У нас.
Сейчас, после нашего переезда, надо бы снова запустить ее.

[domandr]

Цитата:

Изначально опубликовано mazzy
Работала. У нас.
Сейчас, после нашего переезда, надо бы снова запустить ее.

Верится с трудом! Чтобы, которая с компакта и сразу заработала. Ну-ну.

[Serge Kotov]

Возращаясь к первоначальной теме: обеспечить приемлимую производительность Axapta на 500 конкурентных пользователях можно. Решение здесь обычное - трехзвенная архитектура с 3 - 6 серверами приложений.

В случае, если в Axapta будет задействован полный цикл движения товаров (закупки, склад, продажи) + финансы на одном сервере баз данных, предварительно необходимо (по-возможности) просчитать скорость роста БД и возможности ее обработки в дальнейшем. В данном случае онечно не обойтись без дорогих аппаратных решений, в первую очередь основанных на SAN (storage area network).

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

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

[AKIS-Falcon]

ИМХО, абсолютно точно быть уверенным, что система выдержит пиковые нагрузки (а 500 юзеров для Аксапты, даже вкупе с Ораклом - безусловно нагрузка выше среднего) можно только тогда, когда система проработает несколько лет, выдержит хотя бы один переход с версии на версию (у Майкрософта это, как правило, самое травматичное событие, с любым их продуктом) и рост базы в несколько раз. При этом, неплохо бы упомянуть, во что конкретно обошлась поддержка системы за все это время: в деньгах, человеко-часах как со стороны Исполнителя, так и со стороны Клиента (последних, увы, обычно бывает во много раз больше). Иными словами, не оказалась ли система "золотой"?

Мой совет SergKuz и всем, кто планирует использовать Аксапту с числом пользователей больше 100: НЕ ВЕРЬТЕ ни одному слову рекламы!
Попытайтесь осмыслить:
а) А надо ли вообще вам столько юзеров?
б) Если да, надо - можно ли разбить их всех на независимые группы, и внедрять не одну, а две, три... десять... Аксапт? Может быть, такой вариант будет лучше управляем?
в) Если-таки внедрять хочется непременно "одну Аксапту" - позаботьтесь о приобретении оборудования, с запасом как миниум 100% к желательной (не минимальной!) конфигурации, заявляемой разработчиком. Плюс, задублируйте все, что только можно - выход из строя даже одного компонента может очень дорого обойтись вам. Кластерируйте, одним словом!

Также очень надеюсь, что господа продавцы когда-нибудь научатся давать ПРАВДИВУЮ и ТОЧНУЮ информацию, о том, что конкретно они сделали. А не просто рекламу себя любимых...