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

[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 - какие процессы ложатся на стандарт, какие требуют изменений. Может какие-то бизнес-процессы пересмотреть в угоду экономии на модицикациях.
Нацелиться на час Х. Морально быть готовым, что еще несколько месяцев система будет "утрясаться".
Ну и вести документацию.

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