Обсуждение стоимости владения D365FO и AX2012

[EVGL]

Цитата:

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

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

Was ich nicht weiß macht mich nicht heiß. Для клиента очевидная только стоимость лицензии, а не полная стоимость владения, как то количество виртуальных машин для внедрения, идущее на десятки, и стоимость людей, это поддерживающих. На лицензию можно получить скидку, если хорошо попросить или постучаться в июне.

А отстутствие или наличие модуля на продажах замечается быстро. Более того, сторонний или самописный модуль против стандартного тоже сильно увеличивает стоимость владения, не так ли? Все хотят стандартизации и best practices забесплатно.

[fed]

Цитата:

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

Was ich nicht weiß macht mich nicht heiß. Для клиента очевидная только стоимость лицензии, а не полная стоимость владения, как то количество виртуальных машин для внедрения, идущее на десятки, и стоимость людей, это поддерживающих. На лицензию можно получить скидку, если хорошо попросить или постучаться в июне.

Когда клиент выбирает ERP систему, он на самом деле интересуется стоимостью проекта внедрения (в целом). Если бы клиент всегда сначала выбирал бы ERP, без учета стоимости внедрения, то выбирали бы всегда ERP-систему Python (ну или GNU C - для экстремалов).
При этом в компреде обычно пишется что-то типа: Дневная ставка - XXXX EUR, ожидаемые трудозатраты - nnn дней плюс-минус 20-25%. Поэтому, даже если проект формально оплачивается по формуле T&M, то там всегда есть предельная величина затрат клиента, за которую выходить достаточно болезненно и для клиента и для партнера. В D365, при прочих равных, трудозатраты на внедрение выросли процентов на 60-70 (как я уже и сказал). Если в компреде эти затраты по честному показать, то велика вероятность что клиент просто выберет SAP. Можно конечно занизить ожидаемую стоимость внедрения, а потом попытаться по ходу задрать на недостающие проценты, но это порочная практика. Во первых - управление подобным проектом превращается в довольно сволочное занятие, потому что ПМ должен все время искать поводы докопаться до клиента и перевести на него стрелки. Во вторых - даже если удалось как-то перевести стрелки на клиента, у него еще должны найтись дополнительные деньги. Поскольку в бюджете такие суммы (типа +- 70%) обычно не закладывают, то поиск денег клиентом занимает какое-то время. В это время партнер либо должен приостановить проект на несколько месяцев и куда-то пристроить простаивающих консов, либо продолжить работу без оплаты, где-то перехватив денег на зарплату консам. Это в общем тоже не повышает привлекательности продукта и для клиента и для партнера. Ну и наконец, даже если проект был успешно внедрен, информация о большом превышении бюджета так или иначе растекается по отрасли. Конечно вряд ли кто-то опубликует пресс-релиз в стиле "Мы успешно внедрили D365 с превышением бюджета на 70%", но в кулуарных разговорах информация все равно утекает.
Так что in a long run, даже если удалось втюхать клиенту систему пользуясь его неосведомленностью, то к хорошим результатам это не приводит.

[AlexeyS]

Цитата:

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

При этом в компреде обычно пишется что-то типа: Дневная ставка - XXXX EUR, ожидаемые трудозатраты - nnn дней плюс-минус 20-25%. Поэтому, даже если проект формально оплачивается по формуле T&M, то там всегда есть предельная величина затрат клиента, за которую выходить достаточно болезненно и для клиента и для партнера. В D365 при прочих равных трудозатраты на внедрение выросли процентов на 60-70 (как я уже и сказал). Если в компреде эти затраты по честному показать, то велика вероятность что клиент просто выберет SAP. Можно конечно занизить ожидаемую стоимость внедрения, а потом попытаться по ходу задрать на недостающие проценты, но это порочная практика
..
Так что in a long run, даже если удалось втюхать клиенту систему пользуясь его неосведомленностью, то к хорошим результатам это не приводит.

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

[fed]

Цитата:

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

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

Я бы сказал что пока партнеры просто закладывались по формуле DAX2012+30%, а по факту получается не 30 процентов, а 60-70. Это я и называю сидеть в overbudget. И как-то я не уверен что новые проекты (с учетом полученного опыта) получится продавать по формуле DAX2012+60%. Плюс пока не понятно как учитывать риски при регулярном обязательном обновлении. Вот допустим при очередном апгрейде (который должен будет устанавливаться по нажатию кнопки, если верить последним обещаниям микрософт) выяснилось что какая-то из старых доработок принципиально несовместима с новой версией. И апгрейд этой доработки будет сводится к ее переписыванию. Допустим что начальная разработка занимала 20 человеко-дней (вместе с тестированием). Как оценить и забюджетировать затраты на подобное переписывание несколько раз в год ? Как оценить и забюджетировать затраты на тестирование всех этих обновлений?

[Captain]

Согласен с fed. Время "шальных" выгод прошло. Если мы в новой архитектуре просим 70% превышения, то зачем мы нужны на рынке? Надо учиться постоянно. Как на новом авто изучать все фишки. От автомата до ...