АОТ для бизнес аналитиков

[Evgeniy2020]

я все же может и переделал бы последний пост, но увы отредактировать его уже не могу (пункта редактирования уже нет).
нормальная у вас реакция, тут я понимаю за что мне очередной минус, но за то урок на будущее.

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

я считаю хамством оценивать кого то отрицательно без соответствующих аргументов, это просто хамство в дискуссии.

но за что что вы oip поставили свою оценку я понимаю и поэтому вовсе не обижаюсь.
я думаю больше минусов еще будет.

хотя если честно должен быть механизм покоторому автор имеет право удалить свой пост, вдруг он ошибься действительно, и тогда бы вместо моих сообщений стояло бы сообщение "Удалено по просьбе автора"

просто тема это весьма перспективная, если ее удачно реализовать то снизятся ТСО, ТСС, и зависимость от многолетних сотрудников, не актуальных репозитариев с модифами, можно увидеть будет труд транскодеров ДНК (программистов) в другом ракурсе, в будущем позволит переносить изменения бизнес аналитику мышкой (Drag n Drop), в некоторых изменениях вообще не прибегать к помощи транскодеров ДНК (программистов), и в будущем позволят системе эволюционировать в простых изменениях без помощи транскодеров ДНК (программистов).

транскодер ДНК это тот кто кодирует эволюционное изменение (тз со стороны бизнес аналитика, консультанта) в тело ДНК (в АОТ в соответсвующие сущности и ветки элементы ДНК)

по сути стратегия дать эволюцинонерам (операторам эволюции) дать возможность оценивать транскодирование ДНК, видеть как что реализовано только в привычном им в виде. позволит в будущем обойтись без транскодеров система сама будет эффективно транскодироваь предлагаемое изменение в тело своего ДНК (в АОТ)

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


поэтому я за то чтобы если кто то в дискуссии проявит свою субъективность и начнет на ней настаивать без аргументов
просто мол мне нравится это а не нравится то, как в случае с Lemming ом (это вообще как называется ничего ползного не внес, лишь окрасил свою субъективость) тебя Лемминг попросили голосовать что ли?, то штраф в репутацию в 10 кратном размере от поставленной им же оценки.
все равно что то я пока не могу успокоится, когад кто то лезит на основании мол мне это кажется странным или мне это кажется чем то еще
и молча лепит оценки, тут реально у меня слов нет, я думаю надо жестко пресекать.
а вот по поводу oip совсем не обдино да он озвучил свою позицию влепил свою оценку, и я полностью понимаю его.
это нормально.

и еще я считаю что необходимо внести изменения в форум, пока человек в этой ветке не создал поста,
то отрицательно он не имеет право никого оценивать. если он поучавствовал в ветке то он имеет право оценивать отрицательно.

ну конечно можно разрешить мировым специалистам оцениваьт без своего участия. мол на правах личного авторитета в этой области.

[Evgeniy2020]

А теперь после обсуждения тема создавалась как

+Бизнес аналитик -программист

2 Mazzy
в третьем посте вы нарисовали прекрасные картинки только залезли в колокольню программиста и ответив на многие вопросы как программист.
то есть ответили с позиции -Бизнес аналитик +программист
а тема создавалась наоборот +Бизнес аналитик -программист.

перерисуйте ваши скриншоты так чтобы это попало именно в условия
+Бизнес аналитик -программист
то есть хороший бизнес аналитик не знает что такое АОТ и не знает что такое SYS GLS CUS VAR USR

интересно как при данных условиях вы перерисуете скриншоты чтобы ответить на те же самые вопросы (помеченные у вас стрелочками красного цвета)

если бы все было так просто я бы не создавал тему, так как программингом занимался с 2001 года.

[BOAL]

Цитата:

Сообщение от Evgeniy2020

то есть хороший бизнес аналитик не знает что такое АОТ и не знает что такое SYS GLS CUS VAR USR

В терминах АХ - это плохой бизнес аналитик (как консультант внедренца)
либо, ему вообще не нужно НИЧЕГО знать о системе, а только б-п для автоматизации и иметь под рукой того, кто знает, как это в АХ.
Люди, способные в одиночку сделать проект на АХ существуют и им достаточно текущих инструментов (неизменных по сути с АХ 2.5, то есть 10 лет). Это не значит, что лучше и не нужно, это значит, что нужно знать и уметь больше, чтобы быть серьезным спецом. Если нужно знать АОТ, то нужно его знать, кодить при этом самому и не обязательно.

В АХ, в сравнении с другими системами, как раз все очень дружелюбно для НЕпрограммиста, а... системного аналитика или системного архитектора. Бизнес аналитик же - это вообще чел. со стороны заказчика (или от бизнес консалтинга) далекий от особенностей ПО.

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

[Lemming]

Цитата:

Сообщение от Evgeniy2020

2 Lemming
прежде чем лепить минусы )) надо хоть как то аргументировать что конкретно там вы не считаете нужным.
здоровая критика приветствуется а молчаливые оценки полезной нагрузки не несут, лишь говрят о субъективности восприятия.
а оно действительно у всех разное и не надо думать что именно у вас оно самое правильное, хотя бы аргумент привели бы.
Спасибо.

...

и to Lemming попрощу не добавлять оценки отрицательные без комментариев. такие оценки ьез комментариев пользы не несут, только субъективность обнажают.
и вообще лезут всякие леминги в обсуждение прототипов. вообще не пониамаю лезть в обсуждение прототипов и чо там ставить без комента.

попрошу лично Lemming ответить за что он поставил свою оценку в обсуждении прототипа слоя преставления информации АОТ для бизнес аналитиков

Цитата:

Сообщение от Evgeniy2020

первым делом 2 Lemming пошел нах и больше чтоб не учавствовал в обсуждениях прототипов где я автор.

ХОЧУ ПО НАСТОЯЩЕМУ ЗАКРЫТЬ ЭТУ ВЕТКУ. и если есть возможность удалить мои сообщения вообще в этой ветке. ПРОСТО УДАЛИТЬ ЭТУ ВЕТКУ.

Цитата:

Сообщение от Evgeniy2020

я все же может и переделал бы последний пост, но увы отредактировать его уже не могу (пункта редактирования уже нет).
...
я считаю хамством оценивать кого то отрицательно без соответствующих аргументов, это просто хамство в дискуссии.
...
поэтому я за то чтобы если кто то в дискуссии проявит свою субъективность и начнет на ней настаивать без аргументов
просто мол мне нравится это а не нравится то, как в случае с Lemming ом (это вообще как называется ничего ползного не внес, лишь окрасил свою субъективость) тебя Лемминг попросили голосовать что ли?, то штраф в репутацию в 10 кратном размере от поставленной им же оценки.
все равно что то я пока не могу успокоится, когад кто то лезит на основании мол мне это кажется странным или мне это кажется чем то еще
и молча лепит оценки, тут реально у меня слов нет, я думаю надо жестко пресекать.
...
и еще я считаю что необходимо внести изменения в форум, пока человек в этой ветке не создал поста,
то отрицательно он не имеет право никого оценивать. если он поучавствовал в ветке то он имеет право оценивать отрицательно.

ну конечно можно разрешить мировым специалистам оцениваьт без своего участия. мол на правах личного авторитета в этой области.

Богато

Видите ли Evgeniy2020, мне очень сложно конструктивно поучаствовать в этой, созданной вами, ветке по той простой причине, что я не вижу тут поводов для обсуждения. Темы "как бы так сделать, что бы консультанты(аналитики) могли..." более грамотно ориентироваться в системе, в том числе, и постоянно меняющейся системе, если я не ошибаюсь, обсуждались тут неоднократно.

Так же, очень сложно читать ваши сообщения, так как они содержать такое большое кол-во метафор, что порой сложно понять о чем вообще идет речь: 80% АОТ закэшировано в голове, программер посмотрит в АОТ и через время распарсит и выдаст, стандарт уже в ДНК системы, кастомизация расширение ДНК системы, кандидат на включение в ДНК системы или потенциальный генетический мусор, скоро потребуется вместо 500 квтч ч мозга 2 млн квтч мозга, закэширифанный кэш модиф, 6 лет работал на одном месте и закэшировал 80% АОТ, труд транскодеров ДНК (программистов), транскодер ДНК это тот кто кодирует эволюционное изменение, стратегия дать эволюцинонерам (операторам эволюции) дать возможность оценивать транскодирование ДНК. ?

В любом случае, на "АОТ для бизнес аналитиков" я все же планирую взглянуть, надо бы только с метафорами при его реализации не переборщить.

[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 для этого перехода и чтобы не переплачивать?

[sukhanchik]

Как говорится - выполним работы быстро, качественно, недорого - выберите любые 2 пункта.
Давайте разбирать ситуацию.

Цитата:

Сообщение от Evgeniy2020

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

Ошибка руководства компании №1. Отсутствие ведения документации означает, что, экономя на ведении документации - мы автоматически предполагаем что единственная документация - это программный код. Значит бизнес-аналитик / консультант / кто-то еще ДОЛЖЕН разбираться в коде (=быть программистом). Такой специалист дороже неразбирающегося в коде аналитика. Но мы же экономим на документации, значит мы должны осознавать что кроме кода у нас ничего нет. Если руководство это не осознает (не осознавало) - это ошибка руководства. Неважно когда допущенная. Грамотное руководство должно грамотно считать затраты. Если оно считает затраты неграмотно - это неграмотное руководство.

Цитата:

Сообщение от Evgeniy2020

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

Вот и вскрылась цена отказа от ведения документации.

Цитата:

Сообщение от Evgeniy2020

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

Да, но компания сама же отказалась от учета хлама.

Цитата:

Сообщение от Evgeniy2020

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

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

Естественно - кто ж поймет - этот кусок кода был написан с какими целями? То ли кривые руки программиста, то ли остатки былой роскоши, то ли какая недоделка. И кто возьмет на себя ответственность за то, что удалив этот кусок кода - не отвалится какой-то неизвестный бизнес-процесс?

Цитата:

Сообщение от Evgeniy2020

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

Я жирным выделил значимые фразы.
А почему люди часто меняются? Может условия труда неподходящие?
Вот тут ошибка руководства №2 - люди часто меняются + убирание консультанта, как возможно (с т.з. руководства) лишнего звена.
Если люди часто меняются - значит однозначно - проблема в руководстве - которое не может заинтересовать работника в постоянном месте работы.
Убирание должности, непонятной для руководства - чревато тем, что бизнес-аналитик в Вашем случае - обязан стать консультантом. И это он (бизнес-аналитик) должен понимать. А уж консультант обязан знать нутро (АОТ, слои и т.д.) системы.

Цитата:

Сообщение от Evgeniy2020

консалтинг старается минимизировать свои усилия,

Неа. Консалтинг просто не хочет брать на себя работу, которую он не в состоянии сделать. Либо тогда уж проводить бизнес-консалтинг с описанием всех бизнес-процессов но уже за существенно большее время и деньги.

Цитата:

Сообщение от Evgeniy2020

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

руководство хочет = есть деньги на оплату работы. Если невозможно провести работу в связи с отсутствием документации - извольте раскошелиться на полную инвентаризацию бизнес-процессов.

Цитата:

Сообщение от Evgeniy2020

разработка любого документа стоит очень дорого.

Конечно. Проще было тщательно вести документацию.

Цитата:

Сообщение от Evgeniy2020

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

Полный анализ "с нуля". Т.е. описание всех бизнес-процессов, описание того, как они отражаются в системе. Моральная подготовка к тому, что если что-то забыли описать - то это отвалится. Пусть у Вас 60% уже есть. Отлично - значит Вам нужно провести анализ по 40%, все склеить и подходить к внедрению, как будто все делаете с нуля. Посмотреть - что есть в АХ 2009 - какие процессы ложатся на стандарт, какие требуют изменений. Может какие-то бизнес-процессы пересмотреть в угоду экономии на модицикациях.
Нацелиться на час Х. Морально быть готовым, что еще несколько месяцев система будет "утрясаться".
Ну и вести документацию.

Если бы документация велась бы изначально - то ее бы анализ (без анализа кода) однозначно бы ответил на Ваши вопросы - что переносить, а что не переносить.
Самое главное - нужно убедить руководство - что нужно провести инвентаризацию функционала, и что в результате этой инвентаризации - обязательно что-то отвалится. И тот самый занятой пользователь, у которого не было времени с Вами пообщаться - не сможет работать в системе.

[Evgeniy2020]

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

По поводу вопроса А почему люди часто меняются? Может условия труда неподходящие?
отвечу речь идет о смене людей в основном в команде консалтинга, чем обусловлено не знаю,
возможно организовано как pool. в нашей команде более менее стабильно. просто очень мало ресурсов.
а бизнес аналитик не может эффективно учавствовать по причине не знания нового стандарта АХ 2009, да и лишь частично знает что есть модифы в текущем приложении.

я начал ветку как раз на похожую тему. Я и предлагаю акутальность репозитария модиф и ведение документации возложить на Аксапту 2009.
AX 2009 прекрасная система, которая сможет самостоятельно вести репозитарий и легко представлять данные о модифах.
конечно ей потребуется небольшая помощь в этом со стороны человека,
особенно в области разграничения бизнес процессов и иерархии контуров учета, но многое можно взвалить на саму Аксапту.
Пусть прекрасная система и ведет документацию что и как в ней самой представлено и на модифицировано.

отсюда и возникла идея о АОТ для бизнес аналитиков.

[gl00mie]

Цитата:

Сообщение от Evgeniy2020

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

А в некоторых - и того раньше

Цитата:

Сообщение от Evgeniy2020

Никакая документация не ведется. В 2007 ом были документы протоколы изменения системы. но с тех пор их никто не вел и они стали неактуальными. в них что то есть но положится на них проблематично. есть мануалы, в некоторой степени они актуальны, но не для всех участков. имеем текущий проект переходим на AX 2009 SP1 RU5

У вас - классическая ситуаиця на начало проекта внедрения системы автоматизации - любой. В такой ситуации принято поступать однотипно: сперва описывать бизнес-процессы "как есть". Затем вы сможете 1) попытаться наложить это описание на стандартный функционал системы, 2) найти "функциональные разрывы", 3) определить, которые из них, с учетом использования стандартного функционала новой системы, покрываются вашими доработками.

Цитата:

Сообщение от Evgeniy2020

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

Я вам скажу по секрету: с учетом того, насколько стандартное приложение AX 2009 изменилось по сравнению с 3.0, даже перенос "как есть" будет вам стоить очень дорого. По большому счету, в вашей ситуации вам предстоит перевнедрение. Если нанятный вами консалтинг не хочет до вас это донести или не хочет на это подписываться - найдите другой, более адекватный и, извините, профессиональный (в плане профессиональной честности - не впаривать клиенту то, что ему на самом деле не нужно).

Цитата:

Сообщение от Evgeniy2020

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

Непонятно, о чем вопрос. Эффективный путь перехода с учетом дальнейшего развития вендором системы - максимально использовать стандартный функционал. Это звучит банально, но это так. Вопрос лишь в том, есть ли у людей, участвующих в вашем проекте, выстраданное понимание этого факта на уровне ощущений или же для них это - пустой звук, как для кого-то - теория относительности: ну да, вроде слышали, вроде никто не опроверг пока, ага...

Цитата:

Сообщение от Evgeniy2020

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

"Не бывает серебряных пуль", как писал Брукс в то время, когда я только пошел в школу. Переход на новую версию системы, причем через версию, - это нудная и кропотливая работа. Тут нет каких-то волшебных инструментов или легких путей решения проблемы - во всяком случае, при условии, что ваше руководство считает деньги, а вы - дорожите своим местом.

[Михаил Андреев]

Цитата:

Сообщение от gl00mie

. По большому счету, в вашей ситуации вам предстоит перевнедрение. Если нанятный вами консалтинг не хочет до вас это донести или не хочет на это подписываться - найдите другой, более адекватный и, извините, профессиональный (в плане профессиональной честности - не впаривать клиенту то, что ему на самом деле не нужно).

Обеими руками поддерживаю. А весь огромный пласт программных модификаций рассматривать не более чем как черновики для новых модификаций в новой системе. И "инвентаризацию" модификаций не всегда имеет смысл проводить - может оказаться, что половина её просто не используется.

P.S. Лет 15 назад делали "инвентаризацию" программ на Clipper-е - делали новый блок работы с заказами и наткнулись на огромный PRG файл с обработкой строк заказа. Анализ текста ровным счётом ничего не дал - куча текста, цены туда, количество сюда. Убив на это пол-дня (причём, смотрел со своим замом, тоже недешёвым программистом), плюнул и пошёл к директору. Тот даже не смог вспомнить, что это такое. Повесили "кнопку" - чтобы система сразу сообщила нам, кто этой программой пользуется. За неделю никто на эту "кнопку" не нажал.

Цитата:

Сообщение от gl00mie

Непонятно, о чем вопрос. Эффективный путь перехода с учетом дальнейшего развития вендором системы - максимально использовать стандартный функционал. Это звучит банально, но это так. Вопрос лишь в том, есть ли у людей, участвующих в вашем проекте, выстраданное понимание этого факта на уровне ощущений или же для них это - пустой звук, как для кого-то - теория относительности: ну да, вроде слышали, вроде никто не опроверг пока, ага..."Не бывает серебряных пуль", как писал Брукс в то время, когда я только пошел в школу. Переход на новую версию системы, причем через версию, - это нудная и кропотливая работа. Тут нет каких-то волшебных инструментов или легких путей решения проблемы - во всяком случае, при условии, что ваше руководство считает деньги, а вы - дорожите своим местом.

Обеими руками "ЗА"!

[mazzy]

согласен с sukhanchik и gl00mie

и хочу добавить, что ветка плавно скатывается в то, что уже обсуждалось
Cтоит ли программистов огораживать консультантами от пользователей?
Про консультантский подход

Цитата:

Сообщение от Evgeniy2020

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

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

нет инструментов, которые действуют на уровне абстракций для бизнес-аналитиков.
(разве что проекты, но это жалкое подобие левой руки)
поэтому либо писать вручную такие документы, либо таки делать маппинг от кода к асбтракциям (в первый раз тоже вручную и обязательно работая совместно с пользователями). Когда сделаете маппинг, то можно будет воспользоваться существующими инструментами Аксапты.

Цитата:

Сообщение от Evgeniy2020

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

попросили составить документ анализа системы...

А кого попросили, если людей соответствующей квалификации нет?
Наймите правильных людей.

Цитата:

Сообщение от Evgeniy2020

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

1. Узнать у пользователей точки входа (какие меню, какие кнопки нажимают, какие параметры выбирают)
2. Дополнительно выявить точки в автоматически выполняемых периодических заданиях. Скорее всего это Пакеты (batch), но может быть и внутри SQL, а также могут запускаться по шедулеру из самой винды.
3. Настройки узнать в настройках.
4. Используя перекрестные ссылки, начиная от точке входа отследить какой код гарантировано не используется, какой код может использоваться, какой код гарантировано используется.
5. Провести дополнительный анализ для кода, который не используется: перекрестые ссылки могут не поймать некоторые связи, если код написан через хитрую жопу - например, для выражения myTable.(fieldnum) в перекрестных ссылках не будет отображено, что таблица и поле используются
6. (опицонально) провести маппинг объектов AOT в абстракции с нужной степенью детализации (вручную. другого способа нет). Пример грубого маппинга, все объекты семейства LedgerJournalEngine отвечают за разноску журналов. Пример более точного маппинга, класс LedgerJournalEngine_Payment и его потомки отвечают за разноску журнала платежей. Еще пример, LedgerJournalEngine_VendPayment - отвечает за разноску журнала платежей поставщику.

Обратите внимание, что жирным выделены точки входа, которые указали пользователи. Если ваши абстракции будут (более-менее) совпадать с точками входа, то анализ и дальнейшая работа намного облегчится.



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

7. провести анализ
8. принять решение о выкидывании неиспользуемого кода.

Причем легче всего будут даваться решения по самым неважным и нетрудоемким для переноса участкам кода. Например, какие-нибудь копии таблиц, которые делались для каких-нибудь проверок, но так и забыты. Или какие-нибудь копии классов/Job'ов.

А труднее всего будут даваться решения по действительно важным вещам. Здесь уже приводился пример появившейся в ax2009 разноски по складам. Если у вас такая штука уже реализована, то скорее всего, идеология работы не совпадает с тем, что появилось в ax2009. Кроме того, чтобы перейти на штатную в ax2009 скорее всего придется перелопатить кучу кода. Вопрос "оставить вашу разноску или вернуться к стандартной?" чертовски сложен и неоднозначен.

Цитата:

Сообщение от Evgeniy2020

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

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

=================
(опционально)
ваш изначальный вопрос сводится к следующему:
"как построить маппинг из объектов в абстракции и как его отобразить понятном для человека-непрограммиста в виде"

маячок:
маппинг => онтологии, модель онтологий, еще
отображение онтологий => редакторы онтологий



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

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

основная проблема: онтология содержит огромное количество чисто технических аспектов, которые неинтересны для принятия решений, но их приходится включать чтобы получить правильную онтологию. Причем эти технические аспекты появляются как при автоматическом построении онтологий, так и при ручном. Здесь уже приводились примеры - метод округления сумм, диалоги, системные окна, процедуры печати, процедуры контроля окон и т.п.

[mazzy]

см. также
Анализ системы
Reverse engineer (обратная разработка) в Dynanics Ax 4.0
Структура таблиц axapta
Разработка схем работы согласно логике системы
Axapta vs Rational Rose
Проектирование данных

[mazzy]

Цитата:

Сообщение от Evgeniy2020

перерисуйте ваши скриншоты так чтобы это попало именно в условия
+Бизнес аналитик -программист
то есть хороший бизнес аналитик не знает что такое АОТ и не знает что такое SYS GLS CUS VAR USR

интересно как при данных условиях вы перерисуете скриншоты чтобы ответить на те же самые вопросы (помеченные у вас стрелочками красного цвета)

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

помеченные стрелочками возможности - базовые возможности.
с ними - так же.

я бы понял, если бы вы начали говорить о том, что перекрестные ссылки дают ненаглядное представление, что надо истпользовать онтологии, что эти онтологии надо привязывать к правам и конфигурационным ключам, что функция reverse engeeniring работает отвратительно на большом числе таблиц...

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

Кроме того, вы не ответили на вопрос: а почему ваши бизнес-аналитики не опросит ваших же пользователей?
а также не рассказали как вы видите инструменты и какие именно документы вам нужны.
но зато заставляете "перерисовывать"