[Evgeniy2020]

Хорошо, начнем анализ на примерах.

Начальные условия
в некоторой компании А разивается Аксапта с 2006 го года,
уже как 4 года. Аксапта 3.0

Присутствует свой программист Аксапта с 2006 го. Который локально внутри компании развивает систему и производит критические правки и доработки. Никакая документация этим программистом не ведется. Сам программист не имеет свободного времени. полностью занятый ресурс.

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

есть мануалы, в некоторой степени они актуальны, но не для всех участков.
я их взял на вооружение. и в какой то мере опираюсь на них.

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

имеем текущий проект переходим на AX 2009 SP1 RU5

цель проекта отчистить систему от мусора и кустарщины по возможности перейти на стандртную функциональность АХ 2009.

Решили взять слои VAR CUS USR перенести в АХ 2009. получим копию Аксапта 3.0 только на платформе АХ 2009. На текущий момент ни в консалтинговой компании на которой завязан переход, ни в самой компании А нет людей которые СХОДУ могли бы сказать, что является доработкой а что теперь есть в новом стандарте АХ 2009 в качестве аналогов. В итоге тот же хлам который обширно написан на Ах 3.0 переносится на АХ 2009.

И теперь вопрос как действительно и эффективно избавится от хлама, написанного за 4 года и перейти и задействовать новый стандарт АХ 2009 (стандартную функциональность)

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

В компании была принята ранне схема
Бизнес ------> Бизнес аналитик говрит что нужно бизнесу ------> консультант знает что есть пишет тз -----------> разработчик кодирует изменения ---> Аксапта 3
консультанта в настоящий момент времени нет. переложено на консалтинг но сами люди часто меняются.
поэтому осталось
Бизнес -----> Бизнес аналитик -----------> Программист ---> Аксапта 3.0
текущий проект
Аксапта 3.0 ------> Косалтинг консультант и программист + слои VAR CUS USR -----> Ax 2009
консалтинг старается минимизировать свои усилия,
а наше руководство хочет чотбы от хлама избавились и перешли на стандартную функциональность АХ 2009 где только возможно
конаслтинг говорит мы можем перенести как есть, а если вы хотите что то поменять вам нужно с новой функциональностью АХ 2009 согласовать с бизнес аналитиками и ключевыми пользователями.
разработка любого документа стоит очень дорого.

вопрос каков эффективный путь дял перехода на ах 2009 и максимального использования стандартной функциональности,
и избавления от хлама?

каков эффективный workflow для этого перехода и чтобы не переплачивать?