|
21.03.2017, 15:01 | #1 |
Moderator
|
Ты не совсем правильно вопрос ставишь. Заметное число клиентов не сможет внедрить систему, в которой запрещена ЗАМЕНА стандартной логики тем или иным методом. Как в этом случае TCO посчитать ? Сформулируем конкретный пример: в DAX2012 внедрили с overlayering. Чистая TCO за 5 лет - X. В D365FO внедрить не смогли в принципе (просто остановили проект после прототипирования). Как сравнимые TCO посчитать ?
|
|
|
За это сообщение автора поблагодарили: EVGL (1). |
21.03.2017, 15:17 | #2 |
Участник
|
Цитата:
Я бы сформулировал так: ЕСЛИ, из-за запрета замены стандартной логики, ТСО вырастет настолько, что станет неприемлемым для клиента (либо у клиента столько денег нет, либо на рынке есть конкурирующий продукт с существенно меньшим TCO), ТО клиент просто не станет внедрять систему. в этом случае достаточно констатации, что TCO будет неподъемной для целевой аудитории или существенно выше, чем у конкурентов. Цитата:
нет владения - нет доходов от продажи у вендора. нету ручек - нет конфетки. https://www.youtube.com/watch?v=7KyZJ3xrreA TCO - не единственный показатель ))) |
|
21.03.2017, 15:26 | #3 |
Moderator
|
Цитата:
Сообщение от mazzy
Почему? Они тупые? (С)
Я бы сформулировал так: ЕСЛИ, из-за запрета замены стандартной логики, ТСО вырастет настолько, что станет неприемлемым для клиента (либо у клиента столько денег нет, либо на рынке есть конкурирующий продукт с существенно меньшим TCO), ТО клиент просто не станет внедрять систему. Поэтом и дорабатывают так много... |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
21.03.2017, 16:48 | #4 |
Banned
|
Большинству типичных клиентов AX - TCO это прежде всего вопрос нахождения надежного Партнера которому можно доверять. Затем возможности самой системы.
И только после этого - стоимость. Это только вендор думает что TCO на первом месте. Причем всегда большой бизнес - нетипичен и нестандартен, он хочет свою разработку. Если через метаданные мы сможем заменять вызов любого класса или метода - это и просто, и эффективно. В Java и PHP это делается через конфигурационные файлы *.xml на уровне конкретных фрэймворков. По сути AX/D365FO тот самый фрэймворк и есть и с учетом того что уже есть через метаданные это действительно проще. Но это не избавляет от (функциональных) конфликтов при обновлениях и раз так то проще использовать слои. Все что нужно вендору - это разные режимы и настройки продукта относительно обновлений и overlayering которые определяет сам клиент/партнер. Последний раз редактировалось ax_mct; 21.03.2017 в 16:51. |
|
|
|