|
23.11.2005, 12:34 | #1 |
Участник
|
Цитата:
Сообщение от George Nordic
1) производительность
Нормальная. 2) функциональность. Общирная. 3) техническех требования Минимальны.
__________________
|
|
23.11.2005, 12:40 | #2 |
Dynamics 365 MR
|
Цитата:
Сообщение от ppson
Георгий, Аксапта - идеальная система ?
|
|
23.11.2005, 12:39 | #3 |
Модератор
|
Докажите обратное!
С Уважением, Георгий |
|
23.11.2005, 12:50 | #4 |
Участник
|
Цитата:
Сообщение от George Nordic
Докажите обратное!
1) Производительность Если в 1С была проблема что 20 человек не смогут одновременно провести накладные, то в Аксапте вас ждет "высокопроизводительное" закрытие склада по средней. "По мелочи" набереться куча других замечаний по производительности. 2) Функциональность Средняя. Развитие фукнциональности за последние года два скорее отрицательное чем положительное (если исключить что местный МБС продолжает медленно поддерживать наши бухгалтерские плюшки) 3) Техтребования Не комментирую. 4) и, наконец, удобства. Какие? Эргономические? Микрософт активно добавляет всякие вкусности в интерфейс 4ки.
__________________
|
|
23.11.2005, 13:14 | #5 |
Moderator
|
Цитата:
Сообщение от ppson
1) Производительность
Если в 1С была проблема что 20 человек не смогут одновременно провести накладные, то в Аксапте вас ждет "высокопроизводительное" закрытие склада по средней.
__________________
С уважением, kvan. |
|
23.11.2005, 13:52 | #6 |
Участник
|
Цитата:
Сообщение от kvan
А может сравнивать будем все таки с проведением накладных?
Функционал стандартный. Цитата:
Сообщение от kvan
Не потому ли что для 1С нужно мощное клиентское место а для Axapta в большинстве случаев нет?
Кван, не ловите меня на слове. У меня к этой системе положительное отношение, которое сформировалось на основе сравнения её с другими системами. Дружу с аксаптой уже 4й год, и пока не планирую изменять этой дружбе. Аксапта не идеал, у неё есть очень много достоинств как и проблем. Скорость закрытия склада по средней осталась такой же медленной, книги покупок/продаж формируются очень долго.
__________________
|
|
23.11.2005, 14:07 | #7 |
пофигист
|
Для меня самое неудобное, при дописывание системы, было то что склады (места хранения) находятся в двух таблицах - "inventDim" и "inventLocation". Т.е зная InventLocationID какого-то скалада и ItemID номенклатуры нельзя сразу узнать остаток по этой номеклатуре из таблицы "inventSum", а приходится сначало лезть в таб. inventDim и по InventLocationID узнавать InventDimID этого склада. Для этого нужно писать более сложные запросы, которые дольше работают!!!!!!, добавлять лишние датасорсы на формы и т.д. В 1с помоему этого нет.
Ваще в базе данных там куча таблиц и полей у таблиц, которые нах никому не нужны. Из-за этого все тормозит. И еще ЖУТКО не удобный дизайн отчетов и форм. P.S. А дописывать систему вам придется и много!!!
__________________
Хорошо смеется тот, кто смеется с портвейном. Последний раз редактировалось Guest_UserId; 23.11.2005 в 14:19. |
|
23.11.2005, 13:17 | #8 |
Moderator
|
Цитата:
Сообщение от ppson
3) Техтребования
Не комментирую.
__________________
С уважением, kvan. |
|
23.11.2005, 12:56 | #9 |
Разработчик
|
Не знаю поверите ли мне, но к сожалению, лучше Аксапты сейчас нет системы.
И как не было бы грустно, альтернативы пока нет. Да, это дорогая система, стоимость лицензий может перевалить за 500тыс. Но у MS все дорого. Много недоработок, много ошибок (которые никто не спешит бесплатно устранять), но после доработок и исправления ошибок, и обучения конечных пользователей Аксапту вполне можно использовать (сложные программы не могут иметь интуитивно понятный интерфейс по определению, производительность отчетов и выполнения операций на больших базах становится приемлемой, и количество пользователей перестает влиять на производительность) PS. 1) Лучше разработать собственную систему, но для этого конечные пользователи должны хорошо знать чего они хотят (а сейчас они хотят, чтобы компьютер все делал за них, и как он это будет делать, они считают, что это не их компетенция). 2) Конечно у Аксапты есть существенные проблемы (более важные чем удобство, функциональность, требования к оборудованию, производительность и даже надежность), но о них, как лицо заинтересованное я промолчу. У других систем дела не лучше Последний раз редактировалось perestoronin; 23.11.2005 в 13:33. |
|
23.11.2005, 13:10 | #10 |
Модератор
|
Цитата:
Сообщение от perestoronin
Лучше разработать собственную систему, но для этого конечные пользователи должны хорошо знать чего они хотят.
А в общем случае - нет. Читайте: http://akop.ru/personal/1307?PARENT_RUBR=akop_art_it С Уважением, Георгий P.S. Вы других систем не видели Нету идеальной системы. В Аксапте еще хоть что-то самому поправить можно |
|
23.11.2005, 13:15 | #11 |
Разработчик
|
Не буду хвастаться тем, что я видел, но соглашусь со справедливым замечанием, что кривизну бизнес-логики в Аксапте исправлять легче, чем в других системах, а в некоторых других системах это просто невозможно
PS. По поводу создания своих компиляторов, СУБД и других сложных программых систем, замечу, что наметился переход, даже в MS, от технологии OOD в сторону нового веяния AOD. Поэтому я и сделал заключение о том, что лучше создавать в любом случае свою систему, конечно же если нет готовой , пусть даже и дорогой, т.к. упущенная выгода может оказаться существенно больше нескольких млн.евро. Последний раз редактировалось perestoronin; 23.11.2005 в 13:28. |
|
23.11.2005, 15:20 | #12 |
Участник
|
Цитата:
Сообщение от perestoronin
Не знаю поверите ли мне, но к сожалению, лучше Аксапты сейчас нет системы.
И как не было бы грустно, альтернативы пока нет. Да, это дорогая система, стоимость лицензий может перевалить за 500тыс. Но у MS все дорого. Не согласен насчет цены. Поищите. Тезис дороговизны возникает не в первых раз. Я уже говорил: ВСЕ МОДУЛИ + 100 пользователей = 450тыс. ВСЕ МОДУЛИ еще никем не покупались. Даже во всем мире, насколько я знаю. В среднем, для оценки стоимости хорошо работает формула 2000 * кол-во одновременно работающих пользователей. Подробно здесь http://www.rabota-na-rezultat.ru/erp/prices.html По поводу быстродействия - нормальное. В стандартной Аксапте, пользователи начинают хоть как-то приставать с быстродействием, если их одновременно входит больше 50-70. В сильно переписанной системе быстродействие может быть любым. Опыт повышения быстродействия у заказчиков говорит, что проблема проявляются как раз не с закрытием склада... А с самонаписанным функционалом. Смотрите например на проблемы Guest_UserId в этой ветке... Еще последний пример, http://forum.mazzy.ru/index.php?showtopic=4448&hl= Можно привести еще массу примеров... macklakov, а ты все-таки почитай отчет. Там уже написан ответ на твои возражения. Главный недостаток Аксапты на сегодняшний момент, на мой взгляд, катастрофический недостаток документации и методических материалов. Из-за этого народ тратит кучу сил и времени на разбор стандартного функционала. Из-за этого народ принимает неправильные решения, которые выливаются в низкую производительность, в неудобную работу с Аксаптой. Из-за этого народ неправильно использует стандартный функционал. Нужна дока. Дока нужна прежде всего на стандартные API. Особенно на русские стандартные API. Будет дока - будет больше квалифицированных специалистов, будет больше оптимальных и производительных решений. |
|
23.11.2005, 18:06 | #13 |
NavAx
|
Цитата:
Сообщение от mazzy
macklakov, а ты все-таки почитай отчет. Там уже написан ответ на твои возражения.
Цитата:
Наполнение базы данных производилось путем запуска большого количества сценариев по обработке закупок, заказов, складских журналов и журналов Главной книги
Цитата:
В процедуре генерации данных использовался коэффициент 10 для всех тестируемых модулей: 10000 клиентов (стандартно 1000), 5000 наименований номенклатуры (стандартно 500) и т.д.
Среднее количество обрабатываемых строк в заказе – 10 P.S. Вообще эта статья не заслуживает обсуждения, в данной ветке т.к. это "сферический конь в вакууме"
__________________
Isn't it nice when things just work? |
|
23.11.2005, 22:41 | #14 |
Участник
|
Цитата:
Сообщение от macklakov
... Совершенно не учитывалось взаимодействие различных модулей ...
... Для реальной базы это не объем, т.к. есть тенденция накопления исторических данных, не говоря уже о транзакционных таблицах. А ведь "перегреваются" именно транзакционные таблицы, т.к. они быстро разрастаются, и используются из нескольких модулей одновременно, а иногда и внешними приложениями. P.S. Вообще эта статья не заслуживает обсуждения, в данной ветке т.к. это "сферический конь в вакууме" Тест, о котором идет речь, мне был очень интересен, т.к. компания в которой я тогда работал использовала почти аналогичное оборудование для сервера баз данных и очень сильно кастомизированную в сторону усложения функциональность Axapta. Поэтому проверить возможности стандартной Axapta на схожем оборудовании было очень интересно. Должен признаться, результаты теста меня тогда удивили, потому сильно модифицированная конфигурация и, мягко говоря, немалый объем БД (~160 GB) в условиях промышленной эксплуатации в сущности работали также как стандартная Axapta на 15 GB базе в этом тесте! Разумеется, если нагрузку интерпретировать в ASU и сопоставить с нагрузкой железной части. Иначе говоря, нарастив мощности серверов приложений до тех, которые использовались в тесте и при внезапном росте количества транзакций, мы бы получили результаты одного порядка с тестом. Да, конечно, на нашей системе в реальности было бы трудно получить 50 тыс. строк заказов в час, но порядка 30 тыс. с учетом множества других пользователей, занятых своими задачами, а не вводом заказов - вполне. Можно конечно отмахиваться от тестов, испытаний, исследований и пр. и нежиться в мире собственных представлений, но тогда и неудивительны образцы нелепых рассуждений как, например, не так давно было в ветке про AOS и многопроцессорные машины. |
|
24.11.2005, 12:50 | #15 |
NavAx
|
Цитата:
Сообщение от Serge Kotov
Тесты очень мощная штука если уметь видеть внутренние связи и уметь их интерпретировать на практике
__________________
Isn't it nice when things just work? |
|
23.11.2005, 23:35 | #16 |
Участник
|
Цитата:
Сообщение от macklakov
На всякий случай еще раз перечитал. Не обнаружил ответа.
http://forum.mazzy.ru/index.php?showtopic=3497 Здесь, похоже, идет рубилово за добро. Мы вряд ли сможем поговорить толково и с расстановкой о тестировании в этой ветке. готов ответить там. |
|
24.11.2005, 10:47 | #17 |
Разработчик
|
Цитата:
Сообщение от mazzy
Не согласен насчет цены. Поищите. Тезис дороговизны возникает не в первых раз.
Я уже говорил: ВСЕ МОДУЛИ + 100 пользователей = 450тыс. PS. Во всем мире доход у любых работающих компаний выше, чем у аналогичных в России как минимум в 10 раз. Цитата:
Сообщение от mazzy
По поводу быстродействия - нормальное.
Цитата:
Сообщение от mazzy
Главный недостаток Аксапты на сегодняшний момент, на мой взгляд, катастрофический недостаток документации и методических материалов.
Требуется хотя-бы поверхностное описание логики кода на всем понятном языке (от программиста до директора холдинга). К сожалению графический язык UML и некоторые другие более продвинутые технологии, для этого мало подходят, т.к. требует основательного обучения пользователей и не один день, и не намного нагляднее, чем исходный код, а описание логики на естественном языке, наводит на мысли о разночтении даже Библии разными конфессиями, просто диву даешься, как можно так извратить одни и те же простые слова, наверное нужен какой-то особый, Святой Дух, чтобы описания на естественном языке всеми воспринимались с одинаковым смыслом. Поэтому в софтверной индустрии вопрос о языке, графической нотации, всеми легко читаемым, остается открытым. Последний раз редактировалось perestoronin; 24.11.2005 в 15:23. |
|
24.11.2005, 15:18 | #18 |
Участник
|
Цитата:
Сообщение от perestoronin
Но многие руководители предприятий на далекой периферии с такими ценами не соглашаются, даже имея хороший чистый доход. MS свои продукты в России (Москва - это не вся Россия, а только капля в море) могла бы раз в 10-30 подешевле продавать (только в России) (это был бы еще один большой маркетинговый шаг для захвата всего рынка ПО в России).
....... 1) Население: Москва+Московская область - 20 млн, т.е. ок. 14%. 2) ВВП: не меньше 20% от всей страны (можно уточнить). 3 )Многие компании имеют головной офис в Москве (и внедряют ERP часто там же), тогда как основная деятельность - в других регионах. |
|
24.11.2005, 15:27 | #19 |
Разработчик
|
Цитата:
Сообщение от 2A
Москва - далеко не капля в море.
1) Население: Москва+Московская область - 20 млн, т.е. ок. 14%. тогда как основная деятельность - в других регионах. |
|
23.11.2005, 12:56 | #20 |
Banned
|
Отмечу такой небольшой недостаток: до версии SP4 получить правильную себестоимость производства и закрыть склад было практически нельзя. Даже в версии SP4 надо импортировать ряд хотфиксов. Может быть, теперь багов в расчете себестоимости в стандартной версии не осталось (в восточноевропейской точно есть!), но сомнения гложут.
|
|
Теги |
сравнение систем |
|
|