05.02.2004, 10:00 | #1 |
----------------
|
Переход с Ax2.5(sp0) на Ax3.0(sp2)
Есть желание перейти с Аx2.5 без SP на Ax3.0 SP2.
Возникает вопрос как это лучше сделать своими силами? 1. Напрямик: 2.5 -> 3.0 sp2 Путь понятен - 480ч работы (как минимум). 2. Через SP5: 2.5 -> 2.5sp5 -> 3.0sp2 Можно ли считать 2.5 -> 2.5sp5 приближение к конечной цели? На сколько функциональность, структура данных и внутренняя структура (набор классов и методов) Ax2.5sp5 близок к Ax3.0? |
|
05.02.2004, 12:22 | #2 |
Участник
|
Имхо, нет смысла перелопачивать всё по 2 раза. Лучше потратить освободившееся время на изучение отличий 3-й версии и более плотное тестирование.
(мы переходили с 2.5 sp5 на 3.0) |
|
05.02.2004, 17:07 | #3 |
Участник
|
Перенести все модификации (выкинув лишние - уверен они есть за долгое время использования)
Модификации изменить до совместимости с ах30 (особенно разноску по ГК) Отсавит 25 в покое, тк нам не было корреспонденции и переносить проводки бесполезно Перенести все справочники и остатки (возможно на дату - для исторических отчетов) Работать в новой системе. |
|
05.02.2004, 17:27 | #4 |
Шаман форума
|
Цитата:
Изначально опубликовано BOAL
Отсавит 25 в покое, тк нам не было корреспонденции и переносить проводки бесполезно Как не было? Может, по-другому устроен был механизм, но корреспонденция-то была! |
|
06.02.2004, 15:42 | #5 |
Участник
|
Перейти без потери данных это большой геморой стоимостью 80-200 тысяч зеленых американских рублей. Причем даже эти деньги не гарантируют перенесение всех данных и функциональности. Слишком уж много кто умеет съесть денги и ни чего не гарантировать.
При этом хорошо бы иметь более-менее точное описание используемой функциональности. Сделанных модификаций. Причем интересует не только код - его можно получить выгрузив юзр и др слои. Представляет интерес какие модификации используются а какие нет, а какие используются не но не очень эффективно. Это позволит экономить деньги. Например я бы порекомендовал отказаться от модификаций, автоматизирующий рабоут менеджеров и секретарей. Если они не справляются дешевле будет увеличить их штат. Но лучше всего убедить руководство перейти на чистую базу. Стоимость работы будет соответствовать обычному внедрению системы. Вообщем это в любом случае это крупный проект который сильно встряхнет фирму и несомненно потребует крупных организационных, кадровых и прочих решений. |
|
06.02.2004, 21:03 | #6 |
Участник
|
Не надо переходить на 3.0. - сырая она еще, склад, например не дружит со сводным планированием и куча еще всего.
Я уже перевел клиента - теперь приходится искать работу, но самое обидное - это клиент. Был лояльный клиент, у которого работал весь производственный контур и финансы со складом. А теперь... :-(( |
|
07.02.2004, 01:16 | #7 |
Участник
|
Цитата:
Изначально опубликовано xan
...сырая она еще, склад, например не дружит со сводным планированием... А что ж вы не проверили это ДО того, как апгрейдить? |
|
07.02.2004, 14:43 | #8 |
Member
|
Цитата:
Изначально опубликовано mazzy
...А что ж вы не проверили это ДО того, как апгрейдить?... Да и не дело это проводить полномасштабное тестирование продукта вдоль и впоперек перед каждым внедрением. Можно создать макет, проверить концепцию — это да, обязательно. Но многие мелочи, как правило, вылазят только при реальной работе. Идея. Может еще страховую компанию к процессу внедрения привлечь? И пусть они потом с кем-то судятся и кому-то возмещают убытки. У них юристов и экспертов должно быть много. xan, а в чем были ваши проблемы с интеграцией склада и сводного планирования в Аксапте? Если что-то серьезное, то предупредите, чтобы остальные не наступили на те же грабли.
__________________
С уважением, glibs® |
|
07.02.2004, 14:50 | #9 |
Member
|
Тьфу, еще не проснулся.
PS. Цитата:
Изначально опубликовано glibs
...Идея... Цитата:
Изначально опубликовано glibs
...то предупредите, чтобы остальные не наступили на те же грабли...
__________________
С уважением, glibs® |
|
08.02.2004, 02:30 | #10 |
Участник
|
А экономическое обоснование под эту идею сделали? Просчитали, какие возможности хотите задействовать, под какие задачи и какой это даст эффект? Чья это вообще идея и чем она обоснована? Вариантов вижу несколько:
1. меняется команда проекта, и новички не хотят разбираться со старым хламом 2. "перетаскивает" внедренческая фирма, которая вела проект (о возможных причинах промолчу) 3. возникло желание перейти к использованию стандартного функционала и перестать зависеть от команды разработчиков 4. реально востребован какой-то новый функционал. но такого нет. Думаю, переходить чаще чем раз в три-четыре года на новые версии - не рационально. Переход на новые версии должен быть связан с желанием "сделать многое по другому и при этом воспользоваться новыми возможностями развитой системы". Оптимально, если при этом проводятся процедуры оптимизации рабочего процесса. Переход с версии на версию желательно делать в начале года, отработав механизм переноса остатков, сальдо и всех процедур в системе, а так же отработав механизм запросов к старой базе в удобном для пользователей виде. Время подготовки и тестирования - минимально 3 месяца, если люди знающие сидят. Это все- только мои оценки, разумеется.
__________________
"...жизнь проходит, пока мы строим планы на жизнь..." с уважением, ESys. |
|
08.02.2004, 12:11 | #11 |
Участник
|
Цитата:
Изначально опубликовано glibs
Но многие мелочи, как правило, вылазят только при реальной работе. Не согласен по форме в данном конкретном случае. Во-первых, не считаю сводное планирование и склад без производства мелочью. Во-вторых, ведь явно писали во всех документах "what's new", что в Аксапте 3.0 перефигарили систему безопасности, переделали конфигурационные ключи и перетасовали зависимость между модулями. Поэтому не проверять взаимодействие модулей ПЕРЕД апгрейдом - некий авантюризм Хотя вполне понимаю, что бывают ситуации когда ПРИХОДИТСЯ действовать по такому сценарию... Но ПОСЛЕ как выбран авантюрный сценарий жаловаться на жизнь?... |
|
08.02.2004, 12:51 | #12 |
Участник
|
Пояснение:
есть "все" лицензии на производство и сводное планирование. Сейчас подводим итоги января - количество глюков поражает, лучше бы не переходили. Но... новые возможности сводного планирования периодически радуют.... |
|
08.02.2004, 14:36 | #13 |
Member
|
Цитата:
Изначально опубликовано mazzy
...Не согласен по форме в данном конкретном случае... Цитата:
Изначально опубликовано mazzy
...Поэтому не проверять взаимодействие модулей ПЕРЕД апгрейдом - некий авантюризм ... Но ПОСЛЕ как выбран авантюрный сценарий жаловаться на жизнь?...
__________________
С уважением, glibs® |
|
08.02.2004, 16:08 | #14 |
Участник
|
Цитата:
Изначально опубликовано glibs
Я воздержусь от комментариев по данному конкретному случаю. Как минимум до тех пор, пока у меня не будет достаточного количества информации о том, что произошло. xan, извините, если сказал лишнего. |
|
08.02.2004, 17:43 | #15 |
Участник
|
Вспоминается далекое прошлое и переход с Axapta 2.5 sp3 на Axapta 2.5 sp4.
Ввиду того что российское подразделение MBS (а тогда Navision) выпускает "высокоинтегрируемые" и "легкопереносимые" версии пришлепок, процесс перехода затянулся почти на полгода. В течении этого полгодия стало понятно, что "новые возможности" SP4 - сны Анны Павловны. В общем то я бы 7 раз отмерил, а потом бы 1 раз резал
__________________
|
|
08.02.2004, 23:24 | #16 |
Member
|
Цитата:
Изначально опубликовано glibs
...©, все дела... http://www.axforum.info/forums/showt...6841#post26841 Очень жаль. Идея классная. Прошу прощения за неумышленный плагиат. Не успеваю все читать.
__________________
С уважением, glibs® |
|