А вообще в SAP много таких вещей, про которые AX пока только мечтать может

[ImpCons]

Цитата:

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

...
Какой смысл сравнивать SAP и голую DAX от MS?
...

Есть и решения для процессного производства (c множественным выходом) и нормальный ТОиР (хватит пользоваться НЕПРАВИЛЬНОЙ для русского языка саповской аббревиатурой ТОРО), и более функциональные, чем у SAP, решения, по бюджетированию и пр.
...

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

Заметьте, я рассказывал про процессное производство, планово предупредительные ремонты (ТОиРО) в Oracle JD Edwards EO и там это все есть, именно в стандартной поставке а не в партнерских решениях. А Oracle JD Edwards EO именно в той же ценовой нише что и Аксапта, а системы рассчитана на примерно один и тот же сегмент рынка.

Мое мнение - все эти байки про преимущество партнерских решений перед стандартным функционалом это уловки сейлзов. Было бы стандартное решение, те же сейлзы взахлеб начали бы петь какая система функциональная!

[ImpCons]

Цитата:

Сообщение от Maxim Gorbunov

Увы, да. Через XI интегрировались финансовая система с HRM и Payroll'ом, а также с биллингом. Только поддержкой XI занимались три консультанта. В отдел IT кроме них входило 4 basis-консультанта, 10 программеров, примерно 5 функциональных консультантов (сейчас уже просто не помню, сколько их точно было) и бессчетное количество всяких разных проджект-менеджеров. Внедрение при этом было далеко не самое большое, установлены были только финансы, payroll и HRM, а биллинг постоянно находился в состоянии планирования. Для сравнения: один из моих клиентов сейчас использует AX 4.0 для фин. учета, логистики и ритейла (в зачаточном состоянии, правда) в более чем 20 территориально удаленных подразделениях (это не считая точек продаж). Все это добро успешно поддерживается силами одного четырех функциональных консультантов и пары программистов. Как говорится, почувствуйте разницу.

Так для чего был XI на проекте? Для интеграции между SAP-овскими модулями или все таки для интеграцией между биллингом и SAP-ом? Финансовой системой вы называете модуль Финансы в SAP-е или систему третей стороны? Биллинг тоже Саповский был?

Насчет сколько человек и куда может входить это уже дело вменяемости руководства. Почему так мало базисников, всего 4-ре? Нужно их было 15-ть в отдел набрать. Давайте не будет сравнивать теплое с мягким. Каждый проект это своя особая история.

Я могу Вам рассказать про один мой проект в котором у клиента остается пол базисника (он же еще и системный админ в компании) и 1 специалист SAP (наполовину консультант, наполовину разработчик) при полных внедренных финансах + казначейство + бюджетирование. Так что теперь из сравнения Вашего и моего проекта сделаем вывод, что для поддержания САПа гораздо меньше специалистов требуется чем для Аксапты?

Цитата:

Сообщение от Maxim Gorbunov

Пожалуй соглашусь, но с одним "но": средний опыт программиста подразумевает его специализацию в одном (!) модуле. Это, конечно, мое субъективное мнение, но через 1 год работы программист не будет в состоянии писать отчеты для любого модуля SAP. Да, за год накопятся здания по архитектуре какого-то отдельного раздела, но изучение других модулей займет сравнимое время, в силу отсутствия четкой однотипной структуры.

Я говорил про опыт специалистов не сколько по конкретному модулю сколько по инструментарию разработки и мое субъективное мнение, что разработчик, писавший под финансы 1 год, именно столько и будет тратить, сколько я писал ранее, когда ему дадут задачу по логостике или производству, по финансам он будет писать в 2 раза быстрее. Потому как для знания функциональности модуля, есть консультант который напишет ТЗ для разработчика на языке именно таблиц и полей, а не на языке БП.

[George Nordic]

Цитата:

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

А Oracle JD Edwards EO именно в той же ценовой нише что и Аксапта и расчитана на примерно тот же сегмент рынка.

Дешевле. Это я ответствнно заявляю.

Но! надо понимать, что у Dynamics AX уже 2 преднастроенных набора, к которым можно добирать ту или иную функциональность и конкурентные пользователи. У Oracle для среднего бизнеса - 2 модели ценообразования - компонентная (именные пользователи) и CAS (наборы функиональности для всех пользователей)

Но, имхо, это уже оффтоп в данной ветке.

По теме могу только поддержать ImpCons - в стандарте у SAP и Oracle больше функциональности, которую можно внедрить, настроив.

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

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

[Maxim Gorbunov]

ImpCons,

В чем отличие решений SAP, которые SAP приобререл у "третьей строны" и интегрировал в свое решение, от партнерских решений для AX, которые Microsoft лицензировал и продает по общему прайс-листу с базовым продуктом? А тот же самый Process Industries от FullScope вполне себе реализует процессное производство в AX.

[fed]

Цитата:

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

Мое мнение - все эти байки про преимущество партнерских решений перед стандартным функционалом это уловки сейлзов. Было бы стандартное решение, те же сейлзы взахлеб начали бы петь какая система функциональная!

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

[ImpCons]

Цитата:

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

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

Вариант 1
Продукция: "Производство из нефти"
Продукция: Бензин
Сырьё: Нефть Количество = Норма потребления (можно указать в литрах, можно в % от Объёма готового изделия)
Продукция: Мазут
Сырьё: Нефть Количество = Норма потребления (можно указать в литрах, можно в % от Объёма готового изделия)

Вариант 2
Продукция: Бензин
Сырьё Нефть Количество = Норма потребления (можно указать в литрах, можно в % от Объёма готового изделия)
Продукция Мазут
Сырьё Нефть Количество = Норма потребления (можно указать в литрах, можно в % от Объёма готового изделия)

Себестоимость по сырью = количество потреблённого сырья*на себестоимость.

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

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

В общем реализация процессного производства Вашим методом понятна.
Не понял как Вы решите проблему когда в зависимости от объема используемого сырья вы получите разные BOM-ы.

Конкретный пример:

используя 1000 л нефти
600 л бензина АИ 93
300 л мазута
2 кг графитовой смазки

используя 3000 л нефти
1900 л бензина АИ 93
9500 л мазута
7 кг графитовой смазки

используя 10 000 л нефти
7000 л бензина АИ 93
4000 л мазута
25 кг графитовой смазки

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

Будете заводить для данного примера 3 полуфабриката в варианте 1 или 3 продукции в варианте 2:
1. бензин АИ93, при производстве 1000 л нефти
2. бензин АИ93, при производстве 3000 л нефти
3. бензин АИ93, при производстве 10000 л нефти
???

А если подобных процессов 20 ?

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

[Maxim Gorbunov]

Цитата:

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

Так для чего был XI на проекте? Для интеграции между SAP-овскими модулями или все таки для интеграцией между биллингом и SAP-ом? Финансовой системой вы называете модуль Финансы в SAP-е или систему третей стороны? Биллинг тоже Саповский был?

Да, все системы были на SAP. То есть, XI использовался для интеграции разных систем, работающих на SAP.

Цитата:

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

Насчет сколько человек и куда может входить это уже дело вменяемости руководства. Почему так мало базисников, всего 4-ре? Нужно их было 15-ть в отдел набрать. Давайте не будет сравнивать теплое с мягким. Каждый проект это своя особая история.

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

Цитата:

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

Я говорил про опыт специалистов не сколько по конкретному модулю сколько по инструментарию разработки и мое субъективное мнение, что разработчик, писавший под финансы 1 год, именно столько и будет тратить, сколько я писал ранее, когда ему дадут задачу по логостике или производству, по финансам он будет писать в 2 раза быстрее.

Не готов согласиться. Единообразная структура модулей отсутствует. Например, для расширения в Финансах используется OpenFI. В других модулях - BTI (который есть развитие OpenFI, так что разница не очень большая). Наиболее перспективным при этом считается расширение с помощью BADI. А если учесть, что в каждом модуле есть свои customer-exits, то очевидно, что парой дней тут не обойтись Для того, чтобы начать программировать в HRM, мне пришлось разобраться с целым зоопарком различных структур данных и классов. В FI я ничего не писал, так что, возможно, я здесь ошибаюсь, но беглый взгляд подсказывает, что все то, что я узнал, работая с HRM, в FI мне не очень-то пригодится

Цитата:

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

Потому как для знания функциональности модуля, есть консультант который напишет ТЗ для разработчика на языке именно таблиц и полей, а не на языке БП.

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

[ImpCons]

Цитата:

Сообщение от Maxim Gorbunov

ImpCons,

В чем отличие решений SAP, которые SAP приобререл у "третьей строны" и интегрировал в свое решение, от партнерских решений для AX, которые Microsoft лицензировал и продает по общему прайс-листу с базовым продуктом? А тот же самый Process Industries от FullScope вполне себе реализует процессное производство в AX.

Думаю в том, что у SAP-а гораздо больше ресурсов для доработки и интеграции купленного продукта в свою платформу, чем у того же партнера для разработки партнерского решения. Кроме того появляется поддержка купленного, доработанного и интегрированного решения от вендора а нет от партнера - а это все таки гораздо надежнее.

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

[Aleck]

Цитата:

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

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

Для тех кто в танке, повторю:

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

SAP - сам пишет и отраслевые решения и максимально закапывается в специализированные модули, не зазывает партнеров писать решения, а предлагает им только внедрять. На попытки писать смотрит неодобрительно.
Oracle идет дальше и на попытки писать бьет по рукам.

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

Сравнивать надо сравнимое, исходя из разницы подходов в случае с MS надо учитывает и партнерские решения, а не голую систему от MS.

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

[Aleck]

Цитата:

Сообщение от George Nordic

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

А как же Fullscope Process Industries? Или он на Oracle?))))

[mazzy]

Цитата:

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

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

Я в танке.
А какие это решения?

[George Nordic]

Цитата:

Сообщение от Maxim Gorbunov

В чем отличие решений SAP, которые SAP приобререл у "третьей строны" и интегрировал в свое решение, от партнерских решений для AX, которые Microsoft лицензировал и продает по общему прайс-листу с базовым продуктом? А тот же самый Process Industries от FullScope вполне себе реализует процессное производство в AX.

Поддержка осуществляется вендором, а не сторонней компанией. Это ключевое различие.

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

[George Nordic]

Цитата:

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

А как же Fullscope Process Industries? Или он на Oracle?))))

Вау! Когда это Fullscope стал частью DAX? Что-то я пропустил.

Маячок: сравниваем стандартный функционал. Иначе скатимся к 1С. Поверьте, там конфигураций - намного больше.

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

[Aleck]

Цитата:

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

Я в танке.
А какие это решения?

Partnersource да ChannelBuilder тебе в помощь.
ChannelBuilder выдает 1000 партнерских решений для DAX - большинство Certified.
Таблетки от лени у меня нет, не занимаюсь наркотиками )))

[Maxim Gorbunov]

ИМХО, партнерское решение партнерскому решению рознь Те, что продаются по тому же прайс-листу, что и сама система, вполне надежны, имеют серьезную клиентскую базу, и поддерживаются не намного хуже, чем сама система (благо, планку здесь Microsoft не самую выскокую задал )

[ppson]

Цитата:

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

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

Ну MS наплодил тоже кучу систем, которые с разной степенью интегрируются с её ERP решениями - Microsoft Dynamics SL, Microsoft CRM и т.д.

[Aleck]

Цитата:

Сообщение от George Nordic

Вау! Когда это Fullscope стал частью DAX? Что-то я пропустил.

Маячок: сравниваем стандартный функционал. Иначе скатимся к 1С. Поверьте, там конфигураций - намного больше.

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

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

[ImpCons]

Цитата:

Сообщение от Maxim Gorbunov

Да, все системы были на SAP. То есть, XI использовался для интеграции разных систем, работающих на SAP.

Не буду спорить опыта в HR и Payrol и тем более биллинге у меня нет, так что как проводится интеграция их с SAP финансы не скажу - вполне возможно что и не тревиально. Но и задачу Вы совсем не тревиальную описываете, гораздо тревиальней задачу Вы описали по проекту Аксапты : фин. учет, логистика и ритейл (в зачаточном состоянии, правда). В таком варианте могу компетентно заявить для SAP-а XI будет точно не нужен, как и 4 базисника и 10 программистов.

Цитата:

Сообщение от Maxim Gorbunov

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

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

Цитата:

Сообщение от Maxim Gorbunov

Не готов согласиться. Единообразная структура модулей отсутствует. Например, для расширения в Финансах используется OpenFI. В других модулях - BTI (который есть развитие OpenFI, так что разница не очень большая). Наиболее перспективным при этом считается расширение с помощью BADI. А если учесть, что в каждом модуле есть свои customer-exits, то очевидно, что парой дней тут не обойтись Для того, чтобы начать программировать в HRM, мне пришлось разобраться с целым зоопарком различных структур данных и классов. В FI я ничего не писал, так что, возможно, я здесь ошибаюсь, но беглый взгляд подсказывает, что все то, что я узнал, работая с HRM, в FI мне не очень-то пригодится

Ну вот и перечислили, то что и должен знать средний разработчик от 1 года опыта :
BADI, OpenFi, замещения и проверки - но пишите вы совсем не про отчеты . Причем тут функциональность?
Освоить первый раз инструмент в модуле согласен может до 3 недель уйти но зато все последующие пойдут по срокам которые написал все таки я .
Если что, то для разработки средних отчетов, о которых мы говорили, эти знания не нужны - вот если данные для них не подготовлены тогда другое дело.

Цитата:

Сообщение от Maxim Gorbunov

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

Средний консультант, тоже от года опыта, должен уметь писать такие ТЗ, иначе он не консультант а галочковтыкатель .

[Aleck]

Цитата:

Сообщение от George Nordic

Поддержка осуществляется вендором, а не сторонней компанией. Это ключевое различие.

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

Это каких это клиентов по DAX MS поддерживает напрямую?
Все ЧЕРЕЗ ПАРТНЕРОВ по внедрению, а партнерам выгоднее получать поддержку от небольшого разработчика - гораздо оперативнее и гибче, чем неповоротливый огромный вендор.
Георгий, ты точно в MS работал? Или числился, параллельно SAP и Oracle изучая и готовясь к развитию карьеры?

[George Nordic]

Цитата:

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

SAP - сам пишет и отраслевые решения и максимально закапывается в специализированные модули, не зазывает партнеров писать решения, а предлагает им только внедрять. На попытки писать смотрит неодобрительно.

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

Цитата:

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

Oracle идет дальше и на попытки писать бьет по рукам.

Опять не так. Наоборот, развитие партнерский решений очень даже приветствуется. Есть даже программа для партнеров специальная - "ACCELERATE". Аналог - RCT для DAX. Т.е. разработка вертикального решения, типовая настройка + быстрая настройка приложения в зависимости от парамеров.

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