СергV70Имеем огромную самописную (MS SQL 2005+VFP 8.0) ERP систему, включающую товародвижение и репликацию на складскую БД, сопряженную с бухгалтерским и управленческим учетом на 1С 7.7 (150 пользователей в офисе и 30 на складе + ИС управления сортировочным комплексом)
В некоторых головах возникло желание переписать систему на новой платформе. Рассматриваются Microsoft Dynamics® AX 2009, Microsoft Dynamics NAV® 2009, 1С 8.2 – конфигурация УПП.
Что думает по этому поводу сообщество

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

СергV70Основная цель - снять зависимость от программистов FOX в связи с их дефицитом
В определенной мере цель вполне разумная. Если специалисты в дефиците, то желательно платформу сменить, пока не поздно. Другой вопрос, на что менять. Любая технология имеет свой жизненный срок, а подсаживаться со своей ERP на вечную "соску" денег сторонних внедренцев я бы не советовал. Если бы с их стороны были гарантии качества и сроков выполнения - это был бы другой разговор. Но по срокам только 1Сники что-то гарантируют, а по качеству - вообще никто :)

s_ustinovесли очень хочется переписывать , то используют Java, C++ или в крайнем случае голую платформу 1С. Но если рассматривается вариант переписать на платформе навижина - совет однозначный - не надо .
Пожалуй, поддержу. NAV в общем-то продукт непонятный - там вроде как все есть, но при попытке использования оказывается, что там нет ничего, В стандартных локализациях даже счет на предоплату не выставишь. При этом средства разработки ужасны. Дешевле и быстрее действительно написать с нуля на обычных современных IDE, чем допиливать написанное в NAV.

s_ustinovвообще-то в стандартном функционале навижина есть почти все, что нужно (про счет на предоплату не помню, да и не знаю современных локализаций). а вот средства разработки - очень специфические. и фраза о попытке переписать на навижине систему свидетельствует о полном незнании предмета.
Ну да, номинально есть. Только дописывать приходится вообще всё. Про предоплаты я уже говорил. А еще в стандартной NAV невозможно отследить входящие партии при перемещении товаров. А еще в NAV автообновление аналитических отчетов при учете блокирует финжурнал на длительное время, и черта с два получится активно работать в такой системе. И т.д. А уж чего стоит фирменная фишка NAV заполнять поля документов только в определенном порядке - это вообще жесть, всенародная любовь пользователей обеспечена.
В любом функционале там есть какой-то мерзкий бажок или недоработка, которая не дает им нормально пользоваться. И я как-то подсчитал, что реализовать нужный функционал с нуля действительно нам вышло бы дешевле и быстрее, чем допиливать NAV до кондиции. Вы хотите получить такой же анализ по измерениям? Да ради бога, это всего несколько дополнительных справочников, поля в документах и журнал. Вам нужно планирование? Дык в NAV оно тоже в сыром виде работает вкривь и вкось. Квоты не учитывает, заявки на пополнение по перемещениям отваливаются с ошибками, если нет SKU и т.д. :)

СергV70А что думаете о количестве программеров на поддержке в рассматриваемых вариантах, если сегодня 8 челов, причем не менее 80% времени они тратят на поддержку данных (исправление косяков пользователей, обработка нестандартных запросов, исполнение заданий, не предусмотренных интерфейсом)?
И как с этим вопросом в рассматриваемых системах?

1. Это много
2. Косяки пользователей и нестандартные запросы - это не проблема системы, а проблема организационная
3. Если ничего не менять в консерватории, у вас после внедрения новой ERP будет 8 программеров, которые 80% своего времени будут тратить на исправление косяков пользователей в Аксапте, НАВ или 1С и на обработку в них нестандартных запросов.

Из личного опыта: у нас поток косяков упал примерно в десять раз после того, как я ввел маленькие штрафы за некорректно оформленные документы. В смысле, за раздолбайски оформленные. Например, когда путают номенклатуру товаров (хотя под рукой есть сканер штрих-кодов, и делов всего-то пикнуть по коробке).
А количество нестандартных запросов сошло на ноль после того, как был развернут DWH на SSAS и заинтересованные руководители были обучены пользоваться аналитическими кубами

George NordicЕсли так хочется написать с "нуля" - смотрите в сторону OS. Я не представляю, как вы нормальную логистику будете писать с резервированиями, перебросками и планированием, а так же расчетом с/с и пересчетом (когда новые факты вскроются, или накладные расходы изменятся), и как это будет с финансами интегрированно. Ну и про финансы - отдельная песня.

Я просто хотел уточнить - а что в этом особенно сложного? Таблица партий, таблица применения партий, таблица стоимости, таблица складских операций. Вот необходимый и достаточный движок для логистики и расчета себестоимости. Разработка ядра ERP не требует человеко-лет работы.