|
29.08.2010, 16:08 | #1 |
Участник
|
Цитата:
либо, ему вообще не нужно НИЧЕГО знать о системе, а только б-п для автоматизации и иметь под рукой того, кто знает, как это в АХ. Люди, способные в одиночку сделать проект на АХ существуют и им достаточно текущих инструментов (неизменных по сути с АХ 2.5, то есть 10 лет). Это не значит, что лучше и не нужно, это значит, что нужно знать и уметь больше, чтобы быть серьезным спецом. Если нужно знать АОТ, то нужно его знать, кодить при этом самому и не обязательно. В АХ, в сравнении с другими системами, как раз все очень дружелюбно для НЕпрограммиста, а... системного аналитика или системного архитектора. Бизнес аналитик же - это вообще чел. со стороны заказчика (или от бизнес консалтинга) далекий от особенностей ПО. Консультант же без этих глубинных знаний может работать только в команде, сольно он не продуктивен именно из-за непонимания АОТ и инструментария. Последний раз редактировалось BOAL; 29.08.2010 в 16:10. |
|
|
За это сообщение автора поблагодарили: mazzy (2), AlGol (1), sukhanchik (2). |
29.08.2010, 18:21 | #2 |
Участник
|
Цитата:
Сообщение от Evgeniy2020
2 Lemming
прежде чем лепить минусы )) надо хоть как то аргументировать что конкретно там вы не считаете нужным. здоровая критика приветствуется а молчаливые оценки полезной нагрузки не несут, лишь говрят о субъективности восприятия. а оно действительно у всех разное и не надо думать что именно у вас оно самое правильное, хотя бы аргумент привели бы. Спасибо. ... и to Lemming попрощу не добавлять оценки отрицательные без комментариев. такие оценки ьез комментариев пользы не несут, только субъективность обнажают. и вообще лезут всякие леминги в обсуждение прототипов. вообще не пониамаю лезть в обсуждение прототипов и чо там ставить без комента. попрошу лично Lemming ответить за что он поставил свою оценку в обсуждении прототипа слоя преставления информации АОТ для бизнес аналитиков Цитата:
Цитата:
Сообщение от Evgeniy2020
я все же может и переделал бы последний пост, но увы отредактировать его уже не могу (пункта редактирования уже нет).
... я считаю хамством оценивать кого то отрицательно без соответствующих аргументов, это просто хамство в дискуссии. ... поэтому я за то чтобы если кто то в дискуссии проявит свою субъективность и начнет на ней настаивать без аргументов просто мол мне нравится это а не нравится то, как в случае с Lemming ом (это вообще как называется ничего ползного не внес, лишь окрасил свою субъективость) тебя Лемминг попросили голосовать что ли?, то штраф в репутацию в 10 кратном размере от поставленной им же оценки. все равно что то я пока не могу успокоится, когад кто то лезит на основании мол мне это кажется странным или мне это кажется чем то еще и молча лепит оценки, тут реально у меня слов нет, я думаю надо жестко пресекать. ... и еще я считаю что необходимо внести изменения в форум, пока человек в этой ветке не создал поста, то отрицательно он не имеет право никого оценивать. если он поучавствовал в ветке то он имеет право оценивать отрицательно. ну конечно можно разрешить мировым специалистам оцениваьт без своего участия. мол на правах личного авторитета в этой области. Видите ли Evgeniy2020, мне очень сложно конструктивно поучаствовать в этой, созданной вами, ветке по той простой причине, что я не вижу тут поводов для обсуждения. Темы "как бы так сделать, что бы консультанты(аналитики) могли..." более грамотно ориентироваться в системе, в том числе, и постоянно меняющейся системе, если я не ошибаюсь, обсуждались тут неоднократно. Так же, очень сложно читать ваши сообщения, так как они содержать такое большое кол-во метафор, что порой сложно понять о чем вообще идет речь: 80% АОТ закэшировано в голове, программер посмотрит в АОТ и через время распарсит и выдаст, стандарт уже в ДНК системы, кастомизация расширение ДНК системы, кандидат на включение в ДНК системы или потенциальный генетический мусор, скоро потребуется вместо 500 квтч ч мозга 2 млн квтч мозга, закэширифанный кэш модиф, 6 лет работал на одном месте и закэшировал 80% АОТ, труд транскодеров ДНК (программистов), транскодер ДНК это тот кто кодирует эволюционное изменение, стратегия дать эволюцинонерам (операторам эволюции) дать возможность оценивать транскодирование ДНК. ? В любом случае, на "АОТ для бизнес аналитиков" я все же планирую взглянуть, надо бы только с метафорами при его реализации не переборщить. |
|
29.08.2010, 19:13 | #3 |
Участник
|
Хорошо, начнем анализ на примерах.
Начальные условия в некоторой компании А разивается Аксапта с 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 | #4 |
Administrator
|
Как говорится - выполним работы быстро, качественно, недорого - выберите любые 2 пункта.
Давайте разбирать ситуацию. Цитата:
Сообщение от Evgeniy2020
Хорошо, начнем анализ на примерах.
Присутствует свой программист Аксапта с 2006 го. Который локально внутри компании развивает систему и производит критические правки и доработки. Никакая документация этим программистом не ведется. Сам программист не имеет свободного времени. полностью занятый ресурс. Цитата:
Сообщение от 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
а наше руководство хочет чотбы от хлама избавились и перешли на стандартную функциональность АХ 2009 где только возможно
конаслтинг говорит мы можем перенести как есть, а если вы хотите что то поменять вам нужно с новой функциональностью АХ 2009 согласовать с бизнес аналитиками и ключевыми пользователями. Конечно. Проще было тщательно вести документацию. Цитата:
Нацелиться на час Х. Морально быть готовым, что еще несколько месяцев система будет "утрясаться". Ну и вести документацию. Если бы документация велась бы изначально - то ее бы анализ (без анализа кода) однозначно бы ответил на Ваши вопросы - что переносить, а что не переносить. Самое главное - нужно убедить руководство - что нужно провести инвентаризацию функционала, и что в результате этой инвентаризации - обязательно что-то отвалится. И тот самый занятой пользователь, у которого не было времени с Вами пообщаться - не сможет работать в системе.
__________________
Возможно сделать все. Вопрос времени |
|
|
За это сообщение автора поблагодарили: mazzy (5), AlGol (1), dn (2), Dudnik Anton (1), Lemming (7), lev (6), Evgeniy2020 (1), _scorp_ (2). |
30.08.2010, 00:03 | #5 |
Участник
|
Спасибо главный вывод актуальная и правильная документация это залог успеха во всем.
По поводу вопроса А почему люди часто меняются? Может условия труда неподходящие? отвечу речь идет о смене людей в основном в команде консалтинга, чем обусловлено не знаю, возможно организовано как pool. в нашей команде более менее стабильно. просто очень мало ресурсов. а бизнес аналитик не может эффективно учавствовать по причине не знания нового стандарта АХ 2009, да и лишь частично знает что есть модифы в текущем приложении. я начал ветку как раз на похожую тему. Я и предлагаю акутальность репозитария модиф и ведение документации возложить на Аксапту 2009. AX 2009 прекрасная система, которая сможет самостоятельно вести репозитарий и легко представлять данные о модифах. конечно ей потребуется небольшая помощь в этом со стороны человека, особенно в области разграничения бизнес процессов и иерархии контуров учета, но многое можно взвалить на саму Аксапту. Пусть прекрасная система и ведет документацию что и как в ней самой представлено и на модифицировано. отсюда и возникла идея о АОТ для бизнес аналитиков. Последний раз редактировалось Evgeniy2020; 30.08.2010 в 00:15. |
|
30.08.2010, 00:36 | #6 |
Administrator
|
Цитата:
Пример. MS Word - замечательная программа - в ней можно писать различные тексты (к примеру документацию ту же). А может в ней можно и учет вести? Там же все отчеты можно нарисовать? Ну допилим немного макросами? Надеюсь, не возникает мысли что MS Word может вполне заменить Аксапту? Цитата:
Вывод 1: Цитата:
Цитата:
А кто сказал что он верен? Visual C# (С++, Delphi, VBA, и т.д.) - прекрасные языки программирования, на которых можно написать замечательную систему учета модиф. А какова цена этого вопроса? Некоторые консалтинговые компании ведут учет модификаций в АХ (знаю по собственному опыту). Но система изначально - слабо предназначена для этого. MS Word со своим умением вести учет изменений документов, сравнения версий документов - уже дает 100 очков вперед перед АХ. А есть еще замечательная такая штука, как Sharepoint (которую опять-таки надо настраивать - приводить в вид, удобный для использования). Вывод. Никакое техническое решение не решит проблемы организационного порядка. Т.е. никакая система не будет вести учет модиф сама, без роли человека. Если нужна система - начинайте делать все вручную, используя к примеру - MS Word. Вы выработаете для себя правила ведения документации. После этого Вы сможете сформулировать для себя - что Вам нужно от системы учета модификаций. После этого Вы сможете посмотреть на рынок таких систем - и возможно, что при желании можно будет найти даже бесплатную софтинку (а АХ там не будет вообще). Мой вывод базируется на том, что в свое время (пару лет назад) - один мой знакомый таким образом нашел приемлемую для себя систему багтрекинга. Конечно не идеальную, зато бесплатную и русскую. У него были свои требования к системе (которые сформировались поначалу на основе работы с MS Excel) но где-то процентов на 95 его система удовлетворяла. Он ее немного расширил (добавил пару полей, сделал пяток отчетов) и внедрил в использование. С АХ эта система вообще не знакома и никаким образом не связана.
__________________
Возможно сделать все. Вопрос времени |
|
|
За это сообщение автора поблагодарили: gl00mie (5). |
30.08.2010, 14:24 | #7 |
Участник
|
Цитата:
Вот смотрите, что произошло. Ваше руководство несколько лет не выполняла рекомендации по организации разработки и поддержке софта, не использовало проверенную методологию, игнорировало риски, связанные с бизнес системой, или даже не задумывалось о них, исключало из процесса важнейшие звенья. Почему оно это делало? Хотело как хуже? Да нет, вряд ли. Хотели, скорее всего, как лучше. А лучше всего, им казалось, - сэкономить денег на поддержке системы. Им, возможно, показалось, что все эти методики и технологии придумали жадные и хитрые айтишники, чтобы повытягивать с них денег. Сколько людей на этом уже обожглось, никто, наверное, и не поинтерсовался. Теперь же обнаружилось, что в результате принятой ими политики система внезапно перестала быть дешевой и вдруг оказалась очень дорогой в обслуживании. Ведь, согласитесь, какой вариант вы сейчас не выберите, он в любом случае окажется "дорогим". То, что пытался донести sukhanchik - это то, что экономить на методологии очень невыгодно. Вы просто эти затраты смещаете во времени, да при этом еще и умножая их. Методологии для того и разрабатываются, чтобы снизить затраты на эксплуатацию в предопределенной временной перспективе в соответствии с запланированными сроками эксплуатации. Руководство думало, что оно уменьшает стоимость поддержки системы, а на самом деле только увеличивало. Что происходит сейчас. Видимо, предыдущий опыт вам так понравился, что даже и сейчас вы пытаетесь вместо стандартного подхода применить свой - "экономный". Мы не будем нанимать людей, нафига нам всякие консультанты и аналитики, пусть нам сама Аксапта выполнит в нашем проекте роль и системного и бизнес аналитика и разработчика и напишет сама про себя документацию. Утрирую, конечно, но общее впечатление остается именно такое. То, что вы хотите придумать, должно быть уж точно революционно-эффективным, потому что разработка любой новой методологии - дело само по себе чрезвычайно затратное и с не сильно предсказуемыми результатами. Судя по тому, сколь неожиданными для вашего руководства оказались многие более простые в понимании вещи, ничего нет удивительного, если успех новой вашей революционной идеи вызывает у кого-то из форумчан определенную долю скепсиса. |
|
|
За это сообщение автора поблагодарили: mazzy (2), sukhanchik (4). |
30.08.2010, 14:56 | #8 |
Administrator
|
Цитата:
А по факту получается - что для автоматизации чего-то - сначала нужен ручной труд.
__________________
Возможно сделать все. Вопрос времени |
|
30.08.2010, 15:03 | #9 |
Участник
|
2 Coolibin
Цитата:
Что происходит сейчас. Видимо, предыдущий опыт вам так понравился, что даже и сейчас вы пытаетесь вместо стандартного подхода применить свой - "экономный". Мы не будем нанимать людей, нафига нам всякие консультанты и аналитики, пусть нам сама Аксапта выполнит в нашем проекте роль и системного и бизнес аналитика и разработчика и напишет сама про себя документацию. Утрирую, конечно, но общее впечатление остается именно такое.
Совершенно никто так не говорит. вы совершенно поняли меня не так, или же пытается исказить факты по своему. придется несколько развеять все это. 1. Появился Task recorder. Изменилась ли методология? ответ НЕТ. переложили ли мы труд на Аксапту? ответ ДА. мы облегчили этим жизнь? ответ ДА. завтра действительно мы несколько поменяем работу одного из пользователей, мы запустим Task recorder достаточно быстро пробежися по новой последовательности. и СИСТЕМА нам выдаст новую инструкцию. у системы это уйдет 10 секунд и меньше. Пользователь получит безошибочную новую инструкцию. (раннее консультант должен был потратить часа два, делать скриншоты, переделывать инструкцию) это прямой ответ, я еще приведу примеры. надо лишь понимать в каких вопросах мы можем применить СИСТЕМУ, и сделать АВТОМАТИЗАЦИЮ. я думаю вы знакомы с термином АВТОМАТИЗАЦИЯ это облегчение труда с примением технических систем (в данном случае труд переложен на Аксапту) такой подход снижает ТСО, снижает трудоемкость, снижает ручной труд, защищает от человеческих факторов. в моей метафоре присутствует ЧЕЛОВЕК БИЗНЕС АНАЛИТИК, я его никуда не выкидывал, и не сращивал с СИСТЕМОЙ. есть БИЗНЕС АНАЛИТИК есть СИСТЕМА. и консультантов я никуда не выкидывал. их арсенал дополнится уровнем при котором они даже визуально могут видеть труд программиста, и возможно даже смогут ревьюить работу. я переложил функцию протоколирования изменений на систему в момент фиксирования изменений в АОТ, да скорее всего я переложу это на СИСТЕМУ. она будет фиксировать изменения системы. чтобы потом творения программера прикрутить к соотвествующему контуру. и про USAGE COUNTERS я тоже не зря спросил чтобы интервьюирование пользователей то чем они пользуются, переложить на систему, она весьма красиво представит ЧЕМ ПОЛЬЗУЕТСЯ БУХГАЛТЕР ИВАНОВА И.И. система отразит то чем она реально пользуется и покажет чем и чаще чем. Последний раз редактировалось Evgeniy2020; 30.08.2010 в 15:09. |
|
30.08.2010, 00:52 | #10 |
Участник
|
Цитата:
Цитата:
Сообщение от Evgeniy2020
Никакая документация не ведется. В 2007 ом были документы протоколы изменения системы. но с тех пор их никто не вел и они стали неактуальными. в них что то есть но положится на них проблематично. есть мануалы, в некоторой степени они актуальны, но не для всех участков. имеем текущий проект переходим на AX 2009 SP1 RU5
Цитата:
Сообщение от Evgeniy2020
наше руководство хочет чотбы от хлама избавились и перешли на стандартную функциональность АХ 2009 где только возможно. конаслтинг говорит мы можем перенести как есть, а если вы хотите что то поменять вам нужно с новой функциональностью АХ 2009 согласовать с бизнес аналитиками и ключевыми пользователями. разработка любого документа стоит очень дорого.
Цитата:
|
|
30.08.2010, 09:42 | #11 |
Участник
|
Цитата:
Сообщение от gl00mie
. По большому счету, в вашей ситуации вам предстоит перевнедрение. Если нанятный вами консалтинг не хочет до вас это донести или не хочет на это подписываться - найдите другой, более адекватный и, извините, профессиональный (в плане профессиональной честности - не впаривать клиенту то, что ему на самом деле не нужно).
P.S. Лет 15 назад делали "инвентаризацию" программ на Clipper-е - делали новый блок работы с заказами и наткнулись на огромный PRG файл с обработкой строк заказа. Анализ текста ровным счётом ничего не дал - куча текста, цены туда, количество сюда. Убив на это пол-дня (причём, смотрел со своим замом, тоже недешёвым программистом), плюнул и пошёл к директору. Тот даже не смог вспомнить, что это такое. Повесили "кнопку" - чтобы система сразу сообщила нам, кто этой программой пользуется. За неделю никто на эту "кнопку" не нажал. Цитата:
Сообщение от gl00mie
Непонятно, о чем вопрос. Эффективный путь перехода с учетом дальнейшего развития вендором системы - максимально использовать стандартный функционал. Это звучит банально, но это так. Вопрос лишь в том, есть ли у людей, участвующих в вашем проекте, выстраданное понимание этого факта на уровне ощущений или же для них это - пустой звук, как для кого-то - теория относительности: ну да, вроде слышали, вроде никто не опроверг пока, ага..."Не бывает серебряных пуль", как писал Брукс в то время, когда я только пошел в школу. Переход на новую версию системы, причем через версию, - это нудная и кропотливая работа. Тут нет каких-то волшебных инструментов или легких путей решения проблемы - во всяком случае, при условии, что ваше руководство считает деньги, а вы - дорожите своим местом.
|
|
30.08.2010, 10:27 | #12 |
Ищущий знания...
|
попробую вставить свои пять копеек
во первых. На мой взгляд бизнес-аналитик существует для того, чтобы все бизнес процессы компании были регламентированы (описаны) и поддерживались в актуальном состоянии. А так же, он должен знать в какой системе, какой бизнес процесс реализован. Так же бизнес аналитик должен быть всегда на связи с консультантом (консультантами) всех систем, на которых строится бизнес, и знать о всех модификациях, которые вносятся в эти системы (по идее все эти модификации должны быть с его подачи). + не плохо что бы бизнес-аналитик ориентировался в программах (программе), на которых построен бизнес. Т.е. основная мысль такая: "программа должна работать так, как работают бизнес процессы компании, поэтому первый документ, описывающий работу программы, это Описание бизнес процесса(ов)". А за это бизнес-аналитик как раз и несет ответственность. во вторых у бизнес-аналитика должен быть свой "АОТ" документации по бизнесу компании. ему не надо знать, какие объекты в системе изменены, а какие нет. Это технические вопросы, и ему эта информация не к чему. Он должен знать, что программа работает так, как это требует компания. в третьих, если в компании меняются бизнес аналитики, то старые сотрудники, должны передать свой накопленный опыт и документы новым сотрудникам. Если старые бизнес-аналитики просто протирали штаны (поэтому их и меняют), то новому бизнес-аналитику придется в начале своей карьеры проделать огромную работу и регламентировать все бизнес процессы компании. Если новые сотрудник(и) это сделал, то компания наняла правильного человека. Если же нет, и с приходом новых людей все осталось по прежнему, то поменяли шило на мыло. на мой взгляд доработки в системе должны исходить от бизнес-аналитика. Тогда в силу того, что первоисточником является он сам, то он и знает о всех доработках и настройках системы. Как я понял в Вашей компании стоит вопрос о переходе с Ax 3.0 на Ax2009. тогда наверно вам будет интересно послушать Алексея Еременко, материал выложен здесь
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем Последний раз редактировалось lev; 30.08.2010 в 10:29. |
|
30.08.2010, 11:31 | #13 |
Участник
|
Решил пока не отвечать на вопросы, так как лучше представить материал в сжатом виде.
Далее буду уже описывать концептуально дальше. По ходу обсуждения выявляются важные пункты. и вырисовываются требования. четкие требования это основа рождения чего то нового (если не можем эффективно воспользоваться старым или ТСО и ТСС слишком большие). Картинка (метафора) Действующие лица: Купец бизнес аналитик. Система располагающая товаром (набором функций). Купец располагает картой бизнес процессов. Бизнес аналитик приходит к Системе и говорит "я купец у тебя товар. а ну как Система покажи мне что у тебя есть." Система демонстрирует функциональную карту. это то чем она располагает в данный момент времени. купец часто может приходить к системе и интересоваться, в любой момент времени, и система должна ему обеспечить актуальный ответ. раньше на стенах я видел портреты Ленина, текущих президентов, теперь я часто вижу на стене висящую Функциональную карту AX 2009 (уже в нескольких компаниях, респект разработчикам этой карты). Я предлагаю сделать функциональную карту динамической и кликабельной. Кроме того функциональная карта должна показать все что закуплено в стандарте и все что приукрашено творцами кода (создано модификаций, и совсем с нуля). это как приходят к системе а ну ка покажи все что есть. система ракскрывает пальто и у нее вывешена полная функциональная карта всего то что есть. На первом уровне именно похожая на функциональную карту AX 2009 в виде плакатика. но напротив областей (контуров) есть плюсики кликая на которые мы переходим ко второму уровню. to be continue (в перерывах между работой буду дописывать дальше) |
|
30.08.2010, 07:24 | #14 |
Участник
|
согласен с sukhanchik и gl00mie
и хочу добавить, что ветка плавно скатывается в то, что уже обсуждалось Cтоит ли программистов огораживать консультантами от пользователей? Про консультантский подход Цитата:
В аксапте есть создание проекта, который содержит изменения в слоях. но эти инструменты действуют на уровне кода, а не на уровне абстракций. нет инструментов, которые действуют на уровне абстракций для бизнес-аналитиков. (разве что проекты, но это жалкое подобие левой руки) поэтому либо писать вручную такие документы, либо таки делать маппинг от кода к асбтракциям (в первый раз тоже вручную и обязательно работая совместно с пользователями). Когда сделаете маппинг, то можно будет воспользоваться существующими инструментами Аксапты. Цитата:
Сообщение от Evgeniy2020
На текущий момент ни в консалтинговой компании на которой завязан переход, ни в самой компании А нет людей которые СХОДУ могли бы сказать, что является доработкой а что теперь есть в новом стандарте АХ 2009 в качестве аналогов.
попросили составить документ анализа системы... Наймите правильных людей. Цитата:
2. Дополнительно выявить точки в автоматически выполняемых периодических заданиях. Скорее всего это Пакеты (batch), но может быть и внутри SQL, а также могут запускаться по шедулеру из самой винды. 3. Настройки узнать в настройках. 4. Используя перекрестные ссылки, начиная от точке входа отследить какой код гарантировано не используется, какой код может использоваться, какой код гарантировано используется. 5. Провести дополнительный анализ для кода, который не используется: перекрестые ссылки могут не поймать некоторые связи, если код написан через хитрую жопу - например, для выражения myTable.(fieldnum) в перекрестных ссылках не будет отображено, что таблица и поле используются 6. (опицонально) провести маппинг объектов AOT в абстракции с нужной степенью детализации (вручную. другого способа нет). Пример грубого маппинга, все объекты семейства LedgerJournalEngine отвечают за разноску журналов. Пример более точного маппинга, класс LedgerJournalEngine_Payment и его потомки отвечают за разноску журнала платежей. Еще пример, LedgerJournalEngine_VendPayment - отвечает за разноску журнала платежей поставщику. Обратите внимание, что жирным выделены точки входа, которые указали пользователи. Если ваши абстракции будут (более-менее) совпадать с точками входа, то анализ и дальнейшая работа намного облегчится. Также обратите внимание, что объекты могут маппироваться на несколько абстракций. Например, тот же журнал платежей может маппироваться и на графики платежей, и на прогноз движения денежных средств, и на векселя, и на штрафные санкции за просрочку платежа, и на НДС с авансовых платежей, и на счета-фактуры и т.д. Т.е. если начнете делать такой маппинг, то начните с грубого, но готовьтесь постоянно уточнять его, чтобы получить нужную для принятия решений детализацию. 7. провести анализ 8. принять решение о выкидывании неиспользуемого кода. Причем легче всего будут даваться решения по самым неважным и нетрудоемким для переноса участкам кода. Например, какие-нибудь копии таблиц, которые делались для каких-нибудь проверок, но так и забыты. Или какие-нибудь копии классов/Job'ов. А труднее всего будут даваться решения по действительно важным вещам. Здесь уже приводился пример появившейся в ax2009 разноски по складам. Если у вас такая штука уже реализована, то скорее всего, идеология работы не совпадает с тем, что появилось в ax2009. Кроме того, чтобы перейти на штатную в ax2009 скорее всего придется перелопатить кучу кода. Вопрос "оставить вашу разноску или вернуться к стандартной?" чертовски сложен и неоднозначен. Цитата:
если документация не велась, то придется перелопачивать хотя бы один раз. ================= (опционально) ваш изначальный вопрос сводится к следующему: "как построить маппинг из объектов в абстракции и как его отобразить понятном для человека-непрограммиста в виде" маячок: маппинг => онтологии, модель онтологий, еще отображение онтологий => редакторы онтологий но только поверьте человеку, который к этой задаче для Аксапты подступал уже несколько раз: построение полезных для использования онтологий - более трудоемкая задача, нежели задача построения полезного для вас маппинга вручную. поэтому просто опросите пользователей, узнайте точки входа и сделайте анализ, не надеясь на магическую красную кнопку. "серебряной пули нет". основная проблема: онтология содержит огромное количество чисто технических аспектов, которые неинтересны для принятия решений, но их приходится включать чтобы получить правильную онтологию. Причем эти технические аспекты появляются как при автоматическом построении онтологий, так и при ручном. Здесь уже приводились примеры - метод округления сумм, диалоги, системные окна, процедуры печати, процедуры контроля окон и т.п. |
|
|
За это сообщение автора поблагодарили: dn (2), sukhanchik (6). |
Теги |
диаграмма классов, модель данных, crm2011 |
|
|