AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Функционал
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 29.08.2010, 19:13   #21  
Evgeniy2020 is offline
Evgeniy2020
Участник
 
309 / 68 (3) ++++
Регистрация: 10.04.2007
Адрес: Москва, САО, СЗАО
Хорошо, начнем анализ на примерах.

Начальные условия
в некоторой компании А разивается Аксапта с 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 для этого перехода и чтобы не переплачивать?

Последний раз редактировалось Evgeniy2020; 29.08.2010 в 19:40.
За это сообщение автора поблагодарили: dn (1).
Старый 29.08.2010, 23:45   #22  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Как говорится - выполним работы быстро, качественно, недорого - выберите любые 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 - какие процессы ложатся на стандарт, какие требуют изменений. Может какие-то бизнес-процессы пересмотреть в угоду экономии на модицикациях.
Нацелиться на час Х. Морально быть готовым, что еще несколько месяцев система будет "утрясаться".
Ну и вести документацию.

Если бы документация велась бы изначально - то ее бы анализ (без анализа кода) однозначно бы ответил на Ваши вопросы - что переносить, а что не переносить.
Самое главное - нужно убедить руководство - что нужно провести инвентаризацию функционала, и что в результате этой инвентаризации - обязательно что-то отвалится. И тот самый занятой пользователь, у которого не было времени с Вами пообщаться - не сможет работать в системе.
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: mazzy (5), AlGol (1), dn (2), Dudnik Anton (1), Lemming (7), lev (6), Evgeniy2020 (1), _scorp_ (2).
Старый 30.08.2010, 00:03   #23  
Evgeniy2020 is offline
Evgeniy2020
Участник
 
309 / 68 (3) ++++
Регистрация: 10.04.2007
Адрес: Москва, САО, СЗАО
Спасибо главный вывод актуальная и правильная документация это залог успеха во всем.

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

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

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

Последний раз редактировалось Evgeniy2020; 30.08.2010 в 00:15.
Старый 30.08.2010, 00:36   #24  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от 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 (5).
Старый 30.08.2010, 00:52   #25  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от 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 для этого перехода и чтобы не переплачивать?
"Не бывает серебряных пуль", как писал Брукс в то время, когда я только пошел в школу. Переход на новую версию системы, причем через версию, - это нудная и кропотливая работа. Тут нет каких-то волшебных инструментов или легких путей решения проблемы - во всяком случае, при условии, что ваше руководство считает деньги, а вы - дорожите своим местом.
Старый 30.08.2010, 07:24   #26  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
согласен с 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 - отвечает за разноску журнала платежей поставщику.

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

Нажмите на изображение для увеличения
Название: 1.PNG
Просмотров: 268
Размер:	79.1 Кб
ID:	6115

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

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

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

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

Цитата:
Сообщение от Evgeniy2020 Посмотреть сообщение
каков эффективный workflow для этого перехода и чтобы не переплачивать?
постоянно вести документацию и описания во время проекта.
если документация не велась, то придется перелопачивать хотя бы один раз.

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

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



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

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

основная проблема: онтология содержит огромное количество чисто технических аспектов, которые неинтересны для принятия решений, но их приходится включать чтобы получить правильную онтологию. Причем эти технические аспекты появляются как при автоматическом построении онтологий, так и при ручном. Здесь уже приводились примеры - метод округления сумм, диалоги, системные окна, процедуры печати, процедуры контроля окон и т.п.
__________________
полезное на axForum, github, vk, coub.
За это сообщение автора поблагодарили: dn (2), sukhanchik (6).
Старый 30.08.2010, 09:42   #28  
Михаил Андреев is offline
Михаил Андреев
Участник
Компания АМАНД
Лучший по профессии 2009
 
1,284 / 239 (10) ++++++
Регистрация: 09.11.2001
Адрес: Химки, Московская область
Цитата:
Сообщение от gl00mie Посмотреть сообщение
. По большому счету, в вашей ситуации вам предстоит перевнедрение. Если нанятный вами консалтинг не хочет до вас это донести или не хочет на это подписываться - найдите другой, более адекватный и, извините, профессиональный (в плане профессиональной честности - не впаривать клиенту то, что ему на самом деле не нужно).
Обеими руками поддерживаю. А весь огромный пласт программных модификаций рассматривать не более чем как черновики для новых модификаций в новой системе. И "инвентаризацию" модификаций не всегда имеет смысл проводить - может оказаться, что половина её просто не используется.

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

Цитата:
Сообщение от gl00mie Посмотреть сообщение
Непонятно, о чем вопрос. Эффективный путь перехода с учетом дальнейшего развития вендором системы - максимально использовать стандартный функционал. Это звучит банально, но это так. Вопрос лишь в том, есть ли у людей, участвующих в вашем проекте, выстраданное понимание этого факта на уровне ощущений или же для них это - пустой звук, как для кого-то - теория относительности: ну да, вроде слышали, вроде никто не опроверг пока, ага..."Не бывает серебряных пуль", как писал Брукс в то время, когда я только пошел в школу. Переход на новую версию системы, причем через версию, - это нудная и кропотливая работа. Тут нет каких-то волшебных инструментов или легких путей решения проблемы - во всяком случае, при условии, что ваше руководство считает деньги, а вы - дорожите своим местом.
Обеими руками "ЗА"!
__________________
Михаил Андреев
https://www.amand.ru
Старый 30.08.2010, 10:27   #29  
lev is offline
lev
Ищущий знания...
Аватар для lev
Oracle
MCBMSS
Axapta Retail User
 
1,723 / 491 (20) +++++++
Регистрация: 18.01.2005
Адрес: Москва
попробую вставить свои пять копеек

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

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

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

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

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

Последний раз редактировалось lev; 30.08.2010 в 10:29.
Старый 30.08.2010, 11:31   #30  
Evgeniy2020 is offline
Evgeniy2020
Участник
 
309 / 68 (3) ++++
Регистрация: 10.04.2007
Адрес: Москва, САО, СЗАО
Решил пока не отвечать на вопросы, так как лучше представить материал в сжатом виде.

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

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

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

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

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

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

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

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

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

to be continue (в перерывах между работой буду дописывать дальше)
Старый 30.08.2010, 11:42   #31  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от Evgeniy2020 Посмотреть сообщение
Бизнес аналитик приходит к Системе и говорит
"я купец у тебя товар. а ну как Система покажи мне что у тебя есть."

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

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

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

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

Последний раз редактировалось sukhanchik; 30.08.2010 в 11:48.
Старый 30.08.2010, 12:15   #32  
Evgeniy2020 is offline
Evgeniy2020
Участник
 
309 / 68 (3) ++++
Регистрация: 10.04.2007
Адрес: Москва, САО, СЗАО
Так придется немного побороться с консерватизмом.

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

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

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

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

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

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

у нас есть замечательный инструмент также Task recorder
надо будет посмотреть как он сохраняет данные.
я видел на презентации как он прекрасно как бы генерит документацию в формате doc для конечных пользователей (инструкцию мануал, с последовательностью действий)
но это не относится к представлению бизнес аналитика.
Старый 30.08.2010, 12:19   #33  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Evgeniy2020 Посмотреть сообщение
Картинка (метафора)

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

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

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

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

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

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

Но сказать она ничего не может. Она - не волшебное зеркало.
__________________
полезное на axForum, github, vk, coub.
Старый 30.08.2010, 12:21   #34  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Evgeniy2020 Посмотреть сообщение
Нет, в метаформе подразумевается Железка, а не человек.
Общение Бизнес аналитика с Системой происходит напрямую,
без участия других лиц. В этом и суть нового представления АОТ для бизнес аналитика.
Ясно.

Большая Мечта о Красной Кнопке.
__________________
полезное на axForum, github, vk, coub.
Старый 30.08.2010, 12:36   #35  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Внизу поста есть ссылка "Цитировать сообщение" - будет получаться красивая цитата.

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

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

Цитата:
Сообщение от Evgeniy2020 Посмотреть сообщение
Конутры функциональной карты задаются человеком.
и вся программная начинка делится на распознанную кучу и не распознанную кучу. когда программер добавляет модификации они попадают в не распознанное.
А как ТЕХНИЧЕСКИ Вы это себе представляете в АХ?
Цитата:
Сообщение от Evgeniy2020 Посмотреть сообщение
у нас есть замечательный инструмент также Task recorder
надо будет посмотреть как он сохраняет данные.
я видел на презентации как он прекрасно как бы генерит документацию в формате doc для конечных пользователей (инструкцию мануал, с последовательностью действий)
но это не относится к представлению бизнес аналитика.
Он генерит лишь описание последовательности действий, которое и сохраняет - не более того. И он непригоден для разработчика.
__________________
Возможно сделать все. Вопрос времени
Старый 30.08.2010, 12:53   #36  
dn is offline
dn
Участник
Самостоятельные клиенты AX
 
486 / 159 (6) ++++++
Регистрация: 26.03.2003
Адрес: Москва
Цитата:
Сообщение от Evgeniy2020 Посмотреть сообщение
Общение Бизнес аналитика с Системой происходит напрямую, без участия других лиц. В этом и суть нового представления АОТ для бизнес аналитика.
Как я понял основная цель - исключить роль "системного архитектора", частично возложив её на бизнес аналитика, частично на разрабатываемый "искусственный интелект". Идея может быть и красивая, но попробуйте оценить затраты на её воплощение в жизнь. Не дешевле ли будет взять человека на эту роль, или на худой конец научить бизнес аналитика самому разбираться в аксапте?
Старый 30.08.2010, 12:57   #37  
Михаил Андреев is offline
Михаил Андреев
Участник
Компания АМАНД
Лучший по профессии 2009
 
1,284 / 239 (10) ++++++
Регистрация: 09.11.2001
Адрес: Химки, Московская область
Цитата:
Сообщение от Evgeniy2020 Посмотреть сообщение
Картинка (метафора)

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

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

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

Знакомый и совершенно неконструктивный подход. Всё равно что попросить шахматиста показать все этюды. Правил мало, учатся быстро, а вариантов реализации мало не покажется. Так и с системой. Есть функциональность, но вариантов реализации столько, что описать их в рамках одной некой "функциональной карты" просто нереально. Да, есть "заточенные" бизнес процессы. Но, во-первых, они не у всех востребованы (у вас есть комплектация паллет на складе? а автоматический расчёт потребностей в момент заказа изделия конфигуратором через портал?), во-вторых, очень гибкие даже в рамках одной и той же функциональности. Можно некую абстрактную "функциональную карту" нарисовать. Но это будет пример, не более.
__________________
Михаил Андреев
https://www.amand.ru
Старый 30.08.2010, 13:00   #38  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Михаил Андреев Посмотреть сообщение
Можно некую абстрактную "функциональную карту" нарисовать.
Ну, теоретически - можно.
Если учесть конфигурационные ключи и права доступа.
Но трудозатраты на "нарисовать" универсальную рисовалку будут офигительными. Согласен.
__________________
полезное на axForum, github, vk, coub.
Старый 30.08.2010, 13:07   #39  
Evgeniy2020 is offline
Evgeniy2020
Участник
 
309 / 68 (3) ++++
Регистрация: 10.04.2007
Адрес: Москва, САО, СЗАО
Купца в виде собственника пока что добавлять не будем,
так как маркетинг и управленческий учет, отдачу и оборачиваемость активов
все это не в этом потоке.

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

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

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

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

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

Цитата:
А как ТЕХНИЧЕСКИ Вы это себе представляете в АХ?
Да вы правы лучше один раз УВИДЕТЬ чем сто раз УСЛЫШАТЬ.

думаю на чем бы можно было бы рисовать удобно, возможно буду рисовать в фотошопе или в корел драв.
Старый 30.08.2010, 13:12   #40  
Михаил Андреев is offline
Михаил Андреев
Участник
Компания АМАНД
Лучший по профессии 2009
 
1,284 / 239 (10) ++++++
Регистрация: 09.11.2001
Адрес: Химки, Московская область
Цитата:
Сообщение от mazzy Посмотреть сообщение
Ну, теоретически - можно.
Если учесть конфигурационные ключи и права доступа.
Но трудозатраты на "нарисовать" универсальную рисовалку будут офигительными. Согласен.
"Да ни вопрос! Любой каприз за Ваши деньги". Мы люди привычные и более идиотские требования видали

Главное, чего не хочет понять топикстартер, - что эта "функциональная схема" будет похожа на его предприятие меньше, чем одежда на модели с подиума на нём самом. И отношение к жизни именно такое же - красивая картинка, для обучения пойдёт, наверное, но не дальше.
__________________
Михаил Андреев
https://www.amand.ru
Теги
диаграмма классов, модель данных, crm2011

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Запрет синхронизации объекта АОТ egorych DAX: Администрирование 3 30.09.2009 12:42
ALEG: Что нам стоит бизнес построить.Нарисуем бизнес план и будем жить Blog bot DAX Blogs 0 19.01.2007 16:00
ALEG: Фишка недели: Бизнес Оповещения или сказ о том, как ИТ менеджер улучшал продуктивность бизнеса Blog bot DAX Blogs 10 16.01.2007 14:06
Методология внедрения от данных, а не от бизнес - модели Recoilme DAX: Прочие вопросы 26 26.08.2004 19:07
Бизнес-процессы склада в Аксапта Sirius DAX: Функционал 6 02.03.2004 18:52
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 12:09.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.