24.08.2004, 09:42 | #21 |
Участник
|
Ахапка будет работать с 500ми пользователями легко при условии, что у вас будут профессиональные программисты, профессиональные администраторы и инженеры сервера БД. Одно только портит впечатление - закрытие склада.
|
|
24.08.2004, 12:05 | #22 |
Аксакал в отставке
|
Ну не только закрытие склада. Скажем проведение накладных по закупкам и заказам тоже будет не очень быстро делаться.
__________________
Девочка, никогда не произноси слова только за то, что они такие длинные и красивые; говори только то, что знаешь. (Л.Кэрролл "Алиса в стране чудес"). |
|
24.08.2004, 12:14 | #23 |
Участник
|
Цитата:
Изначально опубликовано Тимур
Ну не только закрытие склада. Скажем проведение накладных по закупкам и заказам тоже будет не очень быстро делаться.
__________________
|
|
24.08.2004, 12:36 | #24 |
Участник
|
По моему, недостаточно информации чтобы делать какие либо выводы.
Закрытие склада? Но никто не говорил, что работа будет в рамках одной компании. Может склады будут поделены между большим количеством компаний и будут преспокойно быстренько закрываться. Расчет себестоимости? Но может себестоимость будет зажата финансовыми аналитиками так, что никаких задержек с её расчетом не будет .... |
|
24.08.2004, 13:01 | #25 |
Moderator
|
Valery - у нас как раз был случай зажатия мгновенной себестоимости финансвыми аналитиками. Разносили журнал списаний в котором было тысяч 5-7 строк с серийными номерами в финансовой аналитике. Как показал натурный эксперимент - рассчет мгновенной себестоимости занимал процентов 50 от общего времени разноски. Которое было не приемлимым совсем.
Так что рассчет себестоимости списания на больших объемах - это как раз серьезная проблема, которую так просто не обойти. Кстати - мне кажется что слухи о тормознутости закрытия склада сильно преувеличены Во первых после того как в 3.0SP2 сделали многопользовательское закрытие склада - производительность закрытия растет почти линейно с увеличением числа рабочих станций закрывающих склад. Во вторых - как показали эксперименты - после 20-30 итераций,которые даже при большом объеме движений проходят на 2-5 часов, обычно остаются только те номенклатуры, по которым в данных есть какая-то кривизна. Ну например - сторнировали журнал перемещений (особенно - если несколько раз), а маркировку проводок не расставили. Или просто сторнировали складские движения без маркировки или установки лота возврата. Ну или наконец списали что-то до того как оно пришло. (Кстати это и без галочки отрицательный склад может быть). В общем - методика такая - ставишь закрывать склад, потом после 20-30 итераций прерываешь и смотришь какие номенклатуры в списке закрытия остались. Откатываешь закрытие, разбираешься с этими номенклатурами (сторнируешь, добиваешься отсутствия отрицательных остатков, маркировки проставляешь и т.д). Потом снова закрываешь. Еще помогает методика - поставить сначала коррекцию пропускной способности в маленькое число (в 5 копеек скажем), а после того как прошло какое-то разумное число итераций - поставить туда с соседней рабочей станции рубль или 5. При этом та номенклатура, по которой данные нормальные, закроется с точностью в 5 копеек, а та по которые данные кривые (и она в 20-30-40 итераций не закрылась) закроется с погрешностью 5 рублей. В некоторых случаях это выгоднее чем долгое разбирательство и наведение порядка в данных. Так что если пытатся с каждым закрытием склада осознанно разбираться, а не просто сидеть и ждать когда оно до миллионной итерации дойдет - то все не так уж плохо выглядит. |
|
16.10.2004, 12:23 | #26 |
Участник
|
Добрый день, SergKuz.
Меня зовут Попов Александр. Я директор компании AVASystems. Найти людей в нашей необъятной, которые реально эксплуатировали проект подобный тому, который нужен вам практически не возможно, т.к. случай это очень редкий. А вот команда специалистов моей компании делала такой проект и мы его реально сами поднимали. Мы были первыми в стране кто поставил Oracle в таких масштабах на Linux. Мы были первыми кто перешел на Oracle 8.1.7. Я говорю о компании МВ. Все это было в 2000-2001 годах. Нагрузки на сервер были колоссальными, до 1500 транзакций в секунду. Сервер стоял Compaq Proliant 8500 на 4-х процессорах с 4 Гбт . Количество одновременно работающих пользователей доходило до 650. Теперь мы занимаемся собственным бизнесом и продаем решение, разработанное на базе того, которое мы внедрили в МВ. Решение абсолютно не требовательно в железу по сравнению с аналогами. Ну вот пример: у одного из наших заказчиков 50 пользователей работали на сервере, который был обычным компом, работали и ничего не замечали. Сейчас проводим консалтинговый проект у одного из заказчиков, у которого те же 50 пользователей работают на 4-х процессорном сервере и все стоит "колом". Если эта информация Вас заинтересовала, мы готовы к вам подъехать и обсудить все более детально. |
|
16.10.2004, 12:38 | #27 |
Модератор
|
Добрый день, Александр!
А происходит ли у Вас резервирование товара? А сколько длиться закрытие склада? Можно ли указать точность закрытия? При проведении заказа рассчитывается ли у вас мгновенная средняя себестоимость? Или списывается "как есть", по какой-то фиксированной величине? Реализована ли логистика, сколько складов поддерживается? Учитываются ли накладные расходы при межскладском перемещении? Какие модули / контуры автоматизированный? На чем писали? Расскажите поподробнее, пожалуйста - очень интересно! Можно в разделе "Рынок ERP", это более подходящее место для рекламы. С Уважением, Георгий. |
|
16.10.2004, 13:08 | #28 |
Участник
|
Добрый день!
Клиента писали на delphi , сервер на Oracle. Краткое описание функционала можно посмотреть на сайте www.avasystems.ru Конечно все это поддерживается, а как Вы думаете, если мы автоматизировали МВ, в которой работало около 1500 человек, 9 региональных представительств, около 50 складов. Причем продавец Москвы мог зарезервировать товар на складе в Ростове, остатки которго он видел в он-лайне. На сайте МВ есть статьи о системе и чего она им позволяет. В таких масштабах это, наверное, был первый проект в нашей стране. Себестоимость учитывается по средней, но есть и FIFO. Но в интерфейсе FIFO не используется ни где, просто мы сделали движок, чтобы если понадобится можно было FIFO заюзать быстро. С точки зрения количественных ограничений складов, сотрудников, уровней вложенности папок в центральном классификаторе и прочих не понятных мне ограничений в системе нет. Когда мы разрабатывали нашу систему задача стояла так - написать конструктор lego. Теперь в системе можно создавать новые формы, наследуя их, добавлять поля, менять sql-запросы, категоризировать любые объекты, менять названия элементов управления, менять отчеты. И есть еще момент: почти все можно делать из интерфейса, так чтобы не привязывать нас к себе в процессе эксплуатации продукта. Даже новая весрия системы ставиться одной кнопкой и у пользователей обновляется автоматом. Вся эта процедура занимает около 20 мин. Ну тут можно до бесконечности рассказывать. Могу все показать пальцем, прямо на ноутбуке. |
|
16.10.2004, 13:16 | #29 |
Модератор
|
На чем писали "Lego"? T-SQL + C#?
Я не против самописок, даже считаю, что иногда это - единственно приемлемое решение. Но было бы хорошо, если бы Вы по возможности максимально полно описали бы Вашу систему. К сожалению, "есть все" - это не достаточное описание. Так что ждем пресс-релиза с презентацией в PPT! С Уважением, Георгий. |
|
16.10.2004, 13:26 | #30 |
Участник
|
Описание на след неделе мы выложим на сайт там будет download.
А что касается "самописок", то не хоте ли Вы сказать, что Аксапту писали роботы и она совсем не самописка. Такая же самописка, только брэндовая. А учитывая, что каждый центр внедрения сам Аксапту дописывает и переписывает, то теперь сказать что такое Аксапта вообще сложновато. У каждого она своя.... Отсюда вывод. |
|
16.10.2004, 13:39 | #31 |
Модератор
|
Да, вынужден с Вами согласиться. Но! Прогаммирование в Axapta стандартизированно, и, если придерживаться её идеологии и Best Practise, то, по идее, внешний код должен гармонично дополнить уже имеющийся. К сожалению, в этой области пока нет готовых "коробочных" решений: поставил - настроил - все работает. Напильник, к сожалению, все еще пока под рукой .
Так вот, стандартизация была введена специально, что бы на место одного прогаммиста мог придти другой и без проблем разобраться в чужом коде. Это гарантирует независимось поддержки платформы от разработчиков, которые могут покидать проект / меняться и т.п. В этом, кстати, и большой минус самописных систем - тяжелой поддержке разработчиками клиента стороннего кода. Но, как бы там ни было, появление новой системы мы не можем не приветствовать. С Уважением, Георгий. |
|
16.10.2004, 13:53 | #32 |
Участник
|
Да, я с Вами согласен по поводу стандартов. Но тут ведь вопрос, насколько эти стандарты поддерживаются разработчиками...
Я не знаком со стандартами разработки Аксапты. Но если под стандатами имеется ввиду правила наименования обектов и общие подходы к разработке кода, так это вообще правила хорошего тона в разработке и это должно быть в любом продукте. Но ради интереса я поговорю со своими знакомыми, которые внедряют Аксапту, насколько гладко проходит смена разработчика, как-то сомнительно, что там все гладко... Да и не надо забывать, что компании автоматизируют не программы а люди. И если ламмерам-внедренцам дать хороший продукт, автоматизация закончится плачевно, чего, кстати, у нас в стране хоть отбавляй... Сколько у нас успешных внедрений на Аксапте? Да и что называть успешным внедрением. Тут и там слышу об успешном завершением проекта по внедрению Аксапты, а на самом деле там все может не так гладко, как заявляется. Вот все САПовцы, например, заявляют о внедрении в Эльдорадо с гордостью, а там ведь полный провал на самом деле. продолжать можно до бесконечности. Спасибо, кстати, за теплый прием. А то как-то на форуме в основном сплошная агрессия... |
|
16.10.2004, 14:15 | #33 |
Участник
|
Цитата:
Изначально опубликовано Popov76
А учитывая, что каждый центр внедрения сам Аксапту дописывает и переписывает, то теперь сказать что такое Аксапта вообще сложновато. У каждого она своя.... Отсюда вывод. Аксапта - она одна. Та что на официальном дистрибутиве. Все остальное модифицированная Аксапта. |
|
16.10.2004, 14:16 | #34 |
Участник
|
А эта Аксапта, которая одна, она у кого-нибудь работает?
Сомневаюсь. |
|
16.10.2004, 14:41 | #35 |
Участник
|
Работала. У нас.
Сейчас, после нашего переезда, надо бы снова запустить ее. |
|
17.10.2004, 10:58 | #36 |
Участник
|
Цитата:
Изначально опубликовано mazzy
Работала. У нас. Сейчас, после нашего переезда, надо бы снова запустить ее. |
|
17.10.2004, 17:31 | #37 |
Участник
|
Возращаясь к первоначальной теме: обеспечить приемлимую производительность Axapta на 500 конкурентных пользователях можно. Решение здесь обычное - трехзвенная архитектура с 3 - 6 серверами приложений.
В случае, если в Axapta будет задействован полный цикл движения товаров (закупки, склад, продажи) + финансы на одном сервере баз данных, предварительно необходимо (по-возможности) просчитать скорость роста БД и возможности ее обработки в дальнейшем. В данном случае онечно не обойтись без дорогих аппаратных решений, в первую очередь основанных на SAN (storage area network). Так же здесь необходимо очень тщательно подойти к качеству программных доработок стандартной версии да и вообще к качеству проектирования, т.к. неудачные технические решения могут фатально повлиять на производительность и рост базы данных, что иногда на мелких инсталяциях не так заметно. ИМХО, в данном случае без создания работающей системы качества в областях проектирования развития системы, программных разработок, администрирования (в т.ч. аппаратных решений) проект внедрения заявленной мощности является весьма рисковым с точки зрения достижения изначально поставленных целей автоматизации. |
|
17.10.2004, 19:53 | #38 |
Ехидна
|
ИМХО, абсолютно точно быть уверенным, что система выдержит пиковые нагрузки (а 500 юзеров для Аксапты, даже вкупе с Ораклом - безусловно нагрузка выше среднего) можно только тогда, когда система проработает несколько лет, выдержит хотя бы один переход с версии на версию (у Майкрософта это, как правило, самое травматичное событие, с любым их продуктом) и рост базы в несколько раз. При этом, неплохо бы упомянуть, во что конкретно обошлась поддержка системы за все это время: в деньгах, человеко-часах как со стороны Исполнителя, так и со стороны Клиента (последних, увы, обычно бывает во много раз больше). Иными словами, не оказалась ли система "золотой"?
Мой совет SergKuz и всем, кто планирует использовать Аксапту с числом пользователей больше 100: НЕ ВЕРЬТЕ ни одному слову рекламы! Попытайтесь осмыслить: а) А надо ли вообще вам столько юзеров? б) Если да, надо - можно ли разбить их всех на независимые группы, и внедрять не одну, а две, три... десять... Аксапт? Может быть, такой вариант будет лучше управляем? в) Если-таки внедрять хочется непременно "одну Аксапту" - позаботьтесь о приобретении оборудования, с запасом как миниум 100% к желательной (не минимальной!) конфигурации, заявляемой разработчиком. Плюс, задублируйте все, что только можно - выход из строя даже одного компонента может очень дорого обойтись вам. Кластерируйте, одним словом! Также очень надеюсь, что господа продавцы когда-нибудь научатся давать ПРАВДИВУЮ и ТОЧНУЮ информацию, о том, что конкретно они сделали. А не просто рекламу себя любимых...
__________________
Strictly IMHO and nothing personal. Сугубо мое персональное мнение, безотносительно к личности оппонента. |
|
|
|