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

[Evgeniy2020]

после сегоднящнего разгромного митинга, стало понятно что ворочать ERP системами становится труднее и труднее. оин очень масштабными стали.

особенно сложно стало их эволюционировать. переходить от 3.0 к 2009.

родилась бизнес идея.

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

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

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

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

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

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

вообщем пока что бизнес идея
отображать сущности из AOT
голубым цветом (с уровня SYS GLS)
красным (VAR CUS USR)

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

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

[oip]

Цитата:

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

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

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

[mazzy]

Цитата:

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

после сегоднящнего разгромного митинга, стало понятно что ворочать ERP системами становится труднее и труднее. оин очень масштабными стали.

Цитата:

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

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

Ага. Снова вера в некий чудо-инструмент, который все сделает. В пресловутую "красную кнопку".

А что вы называете "понятным бизнес-аналитику видом"?

Цитата:

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

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

Берете объект и смотите в каких слоях он находится. Если есть модификации в вашем слое - значит модифа, если нет вашего слоя - значит стандарт.

Всегда было просто. И сейчас также.

Цитата:

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

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

Отображайте. Старые aod-файлы положите в каталог old.
и сравнивайте со старым.

(специально скриншот снял со старой версии ax3.0 - всегда эти инструменты были)

Цитата:

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

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

диаграмы чего? и документы какие именно?

Цитата:

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

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

Кто закроет? Что вы называете "эккоунт"?
После разгромного митинга вам урезали интернет? Забанили в гугле? Выгоняют с работы?

Цитата:

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

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

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

Цитата:

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

вообщем пока что бизнес идея
отображать сущности из AOT
голубым цветом (с уровня SYS GLS)
красным (VAR CUS USR)

А просто sys, gls, var, cus, usr не устраивает? Текущий слой - выделяется жирным.
Что не устраивает в существующем представлении?

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

так надо работать:


а так переключатель установлен по умолчанию:


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


Обратите также внимание на поля "Автор модификации" и "Дата модификации".
Даю маячок: по этим полям тоже можно включить фильтры и сортировку(!)

Цитата:

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

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

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

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

Цитата:

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

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

Что значит "не используемый"?

Значит ли это "никогда не открываемый"? А если пользователь из любопытства тыкнул и открыл? Тогда он перестает быть "не используемым"?
Значит ли это "выключенный" или "запрещенный правами доступа"?

Правильно ли я понимаю, что вы помните о пакетных заданиях, которые могут выполняться автоматически? (пользователь никогда их не открывает, но они выполняются)

Итак, что такое "не используемый"?

Цитата:

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

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

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

но если вы таки хотите автоматически, то для таблиц есть Журнал трассировки операторов SQL. Включите его. Далее анализируйте стеки.
(снова совершенно сознательно привел скриншот старой версии)


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

а для кода в ax3.0 есть макросы #ProfileBegin, #ProfileEnd. В более старших версиях есть еще и Trace Parser.
Но, если включать их на всем функционале, они точно убьют вашу систему.

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


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

Так что такое "часто используемый"?

Цитата:

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

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

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

Вы сначала расскажите что вас не устраивает в УЖЕ существующих инструментах?
И может расскажете что вам мешает просто и надежно опросить пользователей?

[Vadik]

Цитата:

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

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

Ну допустим есть Tools -> Development tools -> Application objects -> Element usage log
Допустим, выводимая там информация точна. А дальше что? "Бизнес-аналитикам" это явно не поможет

Цитата:

Под жопу таких аналитиков и гнать поганой метлой.

А работать тогда с кем, как сказал горячо любимый премьер?

[gl00mie]

Цитата:

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

Ну допустим есть Tools -> Development tools -> Application objects -> Element usage log. Допустим, выводимая там информация точна.

Это то, что в 2009-й появилось? Но ведь это не статистика никакая - там показывается максимум то, какие объекты вообще использовались за день, а как часто они используются в течение дня, из этих логов не узнать...

[Vadik]

Цитата:

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

Это то, что в 2009-й появилось? Но ведь это не статистика никакая - там показывается максимум то, какие объекты вообще использовались за день, а как часто они используются в течение дня, из этих логов не узнать...

Зачем гадать, если можно запустить отчет? Хинт - это виртуалка, последний раз перезапускалась 8/27

[gl00mie]

Цитата:

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

Зачем гадать, если можно запустить отчет?

А я вовсе не гадаю - я сужу по коду сбора этой "статистики" - см. \Data Dictionary\Tables\SysUtilElementsLog\Methods\persistRegisteredUsagesServer. Т.н. "разы" использования в отчете - это на самом деле количество различных дат, в которые было залогировано использование той или иной формы/отчета, а вовсе не количество раз, которое они открывались.

[Evgeniy2020]

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

так как возможно что то придется нарисовать возможно прототипное.
надо еще на ММАС 2010 сходить успеть пока время есть.

чуть позже объясню и отвечу.


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


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

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

поэтому сейчас я и вижу как программист является тем самым медиумом который в голове закешировал 80% АОТ и когда его спрашивают бизнес аналитики а как это у нас реализовано в системе программист парсит все это в голове и выдает что реализовано за счет кастомизации такой то или написано с нуля (кустарно).

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

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

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

по поводу начальных терминов для концептов

Стандарт (функциональность в SYS GLS)
Кастомизация (функциональность расширенная в слоях VAR CUS USR но изначально присутствующая в SYS GLS)
Кустарщина (функциональность полностью рожденная в слоях VAR CUS USR)

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

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

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

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

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

[gl00mie]

Цитата:

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

ворочать ERP системами становится труднее и труднее. особенно сложно стало переходить от 3.0 к 2009.

Ага...

Цитата:

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

встречал ли кто то средство бизнес моделирования, чтобы видно было кастомизации и стандартный функционал, некую тулзу которая интегрирована с АОТ

Встречали, называется MorphX: показывает названия стандартных элементов приложения обычным шрифтом, а кастомизацированных - полужирным.

Цитата:

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

и может показывать функционал в понятном бизнес аналитику виде? то есть совершенно не программистком виде?

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

Цитата:

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

а то сложно стало отделять мух от котлет и сказать что есть модифа а что есть стандартная функциональнсть.

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

Цитата:

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

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

А на то есть What's new - Application, для 2009-й там каких-то 750+ страниц всего, плюс аналогичный документ для 4-ки, если с 3-ки переходить собираетесь.

Цитата:

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

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

Ну-ну...

Цитата:

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

вообщем пока что бизнес идея отображать сущности из AOT голубым цветом (с уровня SYS GLS) красным (VAR CUS USR)

"Когда у общества нет цветовой дифференциации штанов, то нет цели!" (с) х/ф. А чем не устраивает смотреть на список всех слоев, где присутствует элемент приложения? О, бизнес-идея! Можно собрать отдельные проекты по слоям - тогда не надо будет раскрашивать объекты AOT. Только вот фигня в том, что кастомизация кастомизации - рознь. Где-то методы класса разноски по одному из модулей переписали, а где-то - свойство контрола на форме/отчете поменяли...

Цитата:

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

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

В 2009-й такой механизм появился - см. таблицу SysUtilElementsLog и завязки на нее. Правда, штатный механизм отслеживает лишь формы/отчеты как более-менее самостоятельные элементы приложения, к тому же наиболее трудоемкие в плане переноса кастомизаций на другую версию. Еще более-менее реально отслеживать использование классов-наследников RunBase, в остальном же простого способа собрать статистику нет - надо долго и упорно вертеть перекрестные ссылки плюс анализировать код каким-то очень нетривиальным способом.

Цитата:

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

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

Мне это чем-то напоминает попытки оценить сроки разработки той или иной функциональности по числу строк кода, которые потребуется написать: одна неизвестная подменяется другой, столь же трудно вычислимой. Еще раз: более-менее легко можно собрать статистику по формам/отчетам/наследникам RunBase, не более того. А уж как ее раскрасить - это дело десятое...

Цитата:

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

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

Я вам сразу могу сказать, на что по статистике больше всего "нагрузка": формы SysFormSearch, SysPrintPrinterProgress, SysPrintProgress, Dialog, SysFormSplitter_Y, SysDateLookup, класс NumberSeqCleanup. Легче стало?

Цитата:

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

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

Оставьте вы эти затеи - ерунда это все, ну кроме сбора статистики по объектам указанных типов (если будет особо тяжко переносить какую-нить форму/отчет - заглянете в статистику и удалите за ненадобностью с чистой совестью). Это чем-то похоже на мечты пользователей о том, чтобы у них в системе была одна большая кнопка "Работать": нажал ее - и пошел чай пить с плюшками, ожидая окончания рабочего дня. На эту тему хочется вспомнить статью Джоэла Спольски "Где грязь, там и деньги" (ее можно найти в его книге Джоэл. И снова о программировании):

Цитата:

Когда в юности я работал в хлебопекарне, проклятием для меня было тесто. Оно было липкое, приставало всюду, и его было трудно отчистить. Придя домой, я находил комочки теста у себя в волосах. Каждую смену часа два уходило на то, чтобы отчистить от теста механизмы. В заднем кармане я носил скребок, которым счищал тесто. Иногда большой кусок теста отлетал куда-то в сторону и залеплял все, на что попадал. Тесто снилось мне по ночам в кошмарных снах.
Я работал в производственной зоне. На другом конце пекарни занимались упаковкой и транспортировкой. Там проклятием были крошки. Они забирались всюду. Те, кто там работал, возвращались домой с крошками в волосах. Каждую смену часа два уходило на то, чтобы отчистить от крошек механизмы. В задних карманах они носили маленькие щетки. Не сомневаюсь, что крошки снились им по ночам.
Почти с любой работой, за которую вам платят, свазана неприятная деталь. Если это не тесто или крошки, то, возможно, вы работаете на бритвенной фабрике и приходите домой с мелкими порезами на руках. Или вы работаете в VmWare, и вас посещают ночные кошмары, свзанные с эмуляцией дефектов в сложных видеокартах, необходимых для компьютерных игр. Или вы разрабатываете Windows, и ваши страхи связаны с тем, что из-за какой-нибудь мелкой модификации перестанут работать миллионы программ и аппаратных устройств. Такая уж поганая особенность у вашей работы. К несчастью, на рынке вам платят за решение противных, а не легких проблем. Как говорят йоркширские ребята, «где грязь, там и деньги».

PS. Ну вот, пока писал - уже появилась куча ответов...

[Kabardian]

Да, AX усложняется с каждым годом, книжки становятся все толще и толще, да еще и локализаторы как не в себе фаршуруют систему новыми фичами...

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

[sukhanchik]

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

[George Nordic]

Понаписали-то сколько всего.

Вы путаете:
1. Причину и следствия.
2. Цель, процесс и результат
3. Источник знаний о бизнес-процессе.
и меня сильно запутали.

Итак.
Все дело в том, что нет методологии, о которой столько говорили большевики.

Предпроектное обследование.
Сначала делается анализ текущих бизнес-процессов компании, как есть - AsIs.
Потом владельцев бизнес-процессов спрашивают, а как они хотят их изменить с целью оптимизации бизнес-процессов. Если предполагается внедрение некой системы, идет демонстрация ее базовых возможностей (системы или решения).Анализируется, как внедрение данной системы повлияет на текущие бизнес-процессы, как они могут измениться. проводиться реинжиниринг бизнес процессов, рисуются бизнес-процессы, как они должны быть - ToBe.
Если планируется внедрение системы, то строится предварительный Дизайн решения - что должно быть в системе, если строить ее с учетом процессов, как они будут.
Данные документы фиксируются и подписываются владельцами бизнес-процессов и утверждаются спонсорами (кто будет платить за изменения). Более того, со спонсари утверждаются и Цели Проекта - что должно быть результатом реинжииринга БП или внедрения системы. Спонсоры могут внести изменения в список БП, в сами БП и Цели Проекта. Имея утвержденые Цели проекта и предполагаемые итоговые Бизнес -процессы, можно переходить к следующей стадии.

К сожалению, многие не понимают значимости фазы Анализа и отказываются за нее платить отдельно, или вовсе отказываются от детального предпроектного обследования, что зачастую мешает точной оценке объема проекта и его стоимости.
Проект
Дизайн. На фазе построения дизайна решения проводится анализ как мы можем сделать из того, что есть (AsIs) то, что будет (ToBe). Если предполагается использование системы автоматизации, то проводится Gap-Fit анализ: что уже есть, что нужно настроить, где необходимы доработки. На основании GF-анализа строится предварительный план проекта, в котором фиксируется оценочный обеъем, сроки внедрения и необходимые ресурсы, проект разбивается на этапы, строится архитетура решения. Обычно только на этой стадии можно с достаточной точностью сказать о сроках и объеме проекта. Дизайн решения обсуждается с владельцами БП и спонсорами.

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

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

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

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

Вот примерно так.

Вы же пытается идти от концепции "А что система принципиально может". Это в корне неверно.

С Уважением,
Георгий

[Morpheus]

Готов БЕСПЛАТНО составить документ который отказывается сделать упомянутая Вами консалтинговая компания. В документе будет описание и анализ модификаций, а также аргументированное обоснование какие из них переносить в AX 2009 и какие - нет. А также оценка трудозатрат и дополнительных рисков при upgrade(е). Но есть одно маленькое условие...