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

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

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

[sukhanchik]

Цитата:

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

Я и предлагаю акутальность репозитария модиф и ведение документации возложить на Аксапту 2009.

А вот это уже неправильный вывод. Т.е. конечно возложить можно все. А сможет ли сама система? Для этого ли она предназначена?
Пример. MS Word - замечательная программа - в ней можно писать различные тексты (к примеру документацию ту же). А может в ней можно и учет вести? Там же все отчеты можно нарисовать? Ну допилим немного макросами? Надеюсь, не возникает мысли что MS Word может вполне заменить Аксапту?

Цитата:

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

AX 2009 прекрасная система, которая сможет самостоятельно вести репозитарий и легко представлять данные о модифах.

Вот он - изначальный постулат, на основе которого делается следующие выводы
Вывод 1:

Цитата:

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

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

Вывод 2:

Цитата:

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

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

Выводы верные при условии, что верен постулат.
А кто сказал что он верен? Visual C# (С++, Delphi, VBA, и т.д.) - прекрасные языки программирования, на которых можно написать замечательную систему учета модиф. А какова цена этого вопроса?

Некоторые консалтинговые компании ведут учет модификаций в АХ (знаю по собственному опыту). Но система изначально - слабо предназначена для этого. MS Word со своим умением вести учет изменений документов, сравнения версий документов - уже дает 100 очков вперед перед АХ. А есть еще замечательная такая штука, как Sharepoint (которую опять-таки надо настраивать - приводить в вид, удобный для использования).

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

Мой вывод базируется на том, что в свое время (пару лет назад) - один мой знакомый таким образом нашел приемлемую для себя систему багтрекинга. Конечно не идеальную, зато бесплатную и русскую. У него были свои требования к системе (которые сформировались поначалу на основе работы с MS Excel) но где-то процентов на 95 его система удовлетворяла. Он ее немного расширил (добавил пару полей, сделал пяток отчетов) и внедрил в использование. С АХ эта система вообще не знакома и никаким образом не связана.

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

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

[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
Проектирование данных

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

Цитата:

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

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

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

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

Цитата:

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

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

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

[lev]

попробую вставить свои пять копеек

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

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

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

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

Как я понял в Вашей компании стоит вопрос о переходе с Ax 3.0 на Ax2009. тогда наверно вам будет интересно послушать Алексея Еременко, материал выложен здесь

[Evgeniy2020]

Решил пока не отвечать на вопросы, так как лучше представить материал в сжатом виде.

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

Картинка (метафора)

Действующие лица:
Купец бизнес аналитик.
Система располагающая товаром (набором функций).

Купец располагает картой бизнес процессов.
Бизнес аналитик приходит к Системе и говорит
"я купец у тебя товар. а ну как Система покажи мне что у тебя есть."

Система демонстрирует функциональную карту.
это то чем она располагает в данный момент времени.

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

раньше на стенах я видел портреты Ленина, текущих президентов,
теперь я часто вижу на стене висящую Функциональную карту AX 2009
(уже в нескольких компаниях, респект разработчикам этой карты).

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

это как приходят к системе а ну ка покажи все что есть.
система ракскрывает пальто и у нее вывешена полная функциональная карта всего то что есть.
На первом уровне именно похожая на функциональную карту AX 2009 в виде плакатика. но напротив областей (контуров) есть плюсики кликая на которые мы
переходим ко второму уровню.

to be continue (в перерывах между работой буду дописывать дальше)

[sukhanchik]

Цитата:

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

Бизнес аналитик приходит к Системе и говорит
"я купец у тебя товар. а ну как Система покажи мне что у тебя есть."

Система демонстрирует функциональную карту.
это то чем она располагает в данный момент времени.

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

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

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

Какая ни была бы супер система на складе - она не в состоянии вести учет за живого человека. Так и при учете модификаций.

[Evgeniy2020]

Так придется немного побороться с консерватизмом.

"Только не нужно забывать, что в Вашей метафоре под Системой должен подразумеваться человек, а не железка."

Нет, в метаформе подразумевается Железка, а не человек.
Общение Бизнес аналитика с Системой происходит напрямую,
без участия других лиц. В этом и суть нового представления АОТ для бизнес аналитика.

Другое дело что в подготовке функциональной карты учавствует человек.
В настоящий момент система не может сформировать новый уровень представления совсем самостоятельно. Поэтому ей немного будет помагать человек но с минимальными усилиями.

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

У нас есть слои, которые позволят ответить на первый вопрос
Стандарт, Кастомизация расширение, функционал с нуля
(аналитику не надо будет видеть слова gls usr и т.д.)
вторая вещь это кросс-референс.
третья вещь это Id сущностей.

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

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

[mazzy]

Цитата:

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

Картинка (метафора)

Действующие лица:
Купец бизнес аналитик.
Система располагающая товаром (набором функций).

Купец располагает картой бизнес процессов.
Бизнес аналитик приходит к Системе и говорит
"я купец у тебя товар. а ну как Система покажи мне что у тебя есть."

Система демонстрирует функциональную карту.
это то чем она располагает в данный момент времени.

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

Направильная метафора.
Правильная такая:

Действующие лица:
Купец директор/собственник
Рабочий Балда - бизнес аналитик.
Система располагающая товаром (набором функций), на которой работает Рабочий Балда.

Купец спрашивает у Рабочего Балды - а это могешь? А "за два щелка тебе по лбу" могешь?
Балда (Бизнес-аналитик) идет к Системе и готовит ответ (или как Левша запирается и творит)
Главное: Система - ничего сказать не может. Она бессловесна. Она - инструмент.
Система - это мелкоскоп левши. Система - веревка, при помощи которой Балда заставил чертей платить оброк. Система - плуг.

Но сказать она ничего не может. Она - не волшебное зеркало.

[mazzy]

Цитата:

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

Нет, в метаформе подразумевается Железка, а не человек.
Общение Бизнес аналитика с Системой происходит напрямую,
без участия других лиц. В этом и суть нового представления АОТ для бизнес аналитика.

Ясно.

Большая Мечта о Красной Кнопке.

[sukhanchik]

Внизу поста есть ссылка "Цитировать сообщение" - будет получаться красивая цитата.

Цитата:

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

Нет, в метаформе подразумевается Железка, а не человек.
Общение Бизнес аналитика с Системой происходит напрямую,
без участия других лиц. В этом и суть нового представления АОТ для бизнес аналитика.

Я ни в коем случае не хочу убедить Вас - что это неправильно - да, в идеале хорошо, когда все умеет система. Но... много ли у нас мест, когда ведется учет САМ? Электронный кладовщик?
Т.е. я конечно приветствую Ваше желание создать систему искусственного интеллекта.... но в рамках "решения проблемы за разумные деньги" - это невыполнимое желание.

Цитата:

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

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

У нас есть слои, которые позволят ответить на первый вопрос
Стандарт, Кастомизация расширение, функционал с нуля
(аналитику не надо будет видеть слова gls usr и т.д.)
вторая вещь это кросс-референс.
третья вещь это Id сущностей.

Вы путаете инструменты и организационные действия. Слои могут помочь только при прописанном регламенте. Количество слоев ограничено. У Вас каждая запятая в коде будет переноситься между слоями в коде после того как она была вставлена разработчиком? Нет? Как тогда помогут слои, если вся разработка будет вестись в одном слое?
Перекрестные ссылки могут помочь программисту, но не бизнес-аналитику.
Id сущностей - это все равно что "У нас же есть полки на складе - почему там не налажен учет?"

Цитата:

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

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

А как ТЕХНИЧЕСКИ Вы это себе представляете в АХ?

Цитата:

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

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

Он генерит лишь описание последовательности действий, которое и сохраняет - не более того. И он непригоден для разработчика.

[dn]

Цитата:

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

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

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

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

Цитата:

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

Картинка (метафора)

Действующие лица:
Купец бизнес аналитик.
Система располагающая товаром (набором функций).

Купец располагает картой бизнес процессов.
Бизнес аналитик приходит к Системе и говорит
"я купец у тебя товар. а ну как Система покажи мне что у тебя есть."

Система демонстрирует функциональную карту.
это то чем она располагает в данный момент времени.

Что она "демонстрирует"?

Знакомый и совершенно неконструктивный подход. Всё равно что попросить шахматиста показать все этюды. Правил мало, учатся быстро, а вариантов реализации мало не покажется. Так и с системой. Есть функциональность, но вариантов реализации столько, что описать их в рамках одной некой "функциональной карты" просто нереально. Да, есть "заточенные" бизнес процессы. Но, во-первых, они не у всех востребованы (у вас есть комплектация паллет на складе? а автоматический расчёт потребностей в момент заказа изделия конфигуратором через портал?), во-вторых, очень гибкие даже в рамках одной и той же функциональности. Можно некую абстрактную "функциональную карту" нарисовать. Но это будет пример, не более.

[mazzy]

Цитата:

Сообщение от Михаил Андреев

Можно некую абстрактную "функциональную карту" нарисовать.

Ну, теоретически - можно.
Если учесть конфигурационные ключи и права доступа.
Но трудозатраты на "нарисовать" универсальную рисовалку будут офигительными. Согласен.

[Evgeniy2020]

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

Цитата:

Система - веревка, при помощи которой Балда заставил чертей платить оброк. Система - плуг. Но сказать она ничего не может. Она - не волшебное зеркало.

Зеркало в терминах программинга это механизм рефлексии.

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

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

Цитата:

Я ни в коем случае не хочу убедить Вас - что это неправильно - да, в идеале хорошо, когда все умеет система. Но... много ли у нас мест, когда ведется учет САМ? Электронный кладовщик?

учет САМ по себе тут не ведется. и мы пока что тему ВЕДЕНИЕ УЧЕТА тоже рассматривать не будем в этой ветке.

будем рассматривать лишь отображение учета на функциональной карте,
но уже это более подробно на втором уровне (вложенном)

Цитата:

А как ТЕХНИЧЕСКИ Вы это себе представляете в АХ?

Да вы правы лучше один раз УВИДЕТЬ чем сто раз УСЛЫШАТЬ.

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

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

Цитата:

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

Ну, теоретически - можно.
Если учесть конфигурационные ключи и права доступа.
Но трудозатраты на "нарисовать" универсальную рисовалку будут офигительными. Согласен.

"Да ни вопрос! Любой каприз за Ваши деньги". Мы люди привычные и более идиотские требования видали

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