Вот мы и нашли этих 43 AX7 клиентов? Или это не AX7/D365?

[fed]

Цитата:

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

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

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

[trud]

Цитата:

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

"Сделать все на overlay

Ну речь немного не про это. Т.е. сейчас существует 2 типа моделей - вы выбираете этот тип при создании модели экстеншн модель и модель кастомизации.
физически это означает будет ваш код лежать в отдельной папке или подпапки у какой-то модели

если выбрана экстеншн модель - в ней можно создавать только экстеншн, в модели кастомизации можно создавать как экстеншены так и кастомизации

Утверждение 1 - нужно по возможности как можно меньше перекрывать (делать overlay) кода и объектов микрософт - это всегда было так, дает массу преимуществ и т.д. с этим я думаю никто спорить не будет
это можно достигать как кастомизациями, так и там где невозможно экстеншенами

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

автоматом это решение мигрирует на D365, где тоже не будет оверлея - мигрирует оно в модель кастомизации

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

[skuull]

Цитата:

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

В дискуссии trud vs skuull, меня больше всего удивляет, что никто даже не рассматривает вариант "Сделать все на overlay, а если Микрософт будет докапываться - предложить им оплатить дополнительные затраты на использование extensions"

Вариант рассматриваетсяю Но вместе с ним рассматривается вариант что возьмут модель и залочат для оверлея, как случилось с некоторыми Будет и смешно и грустно.

[skuull]

Цитата:

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

В дискуссии trud vs skuull, меня больше всего удивляет, что никто даже не рассматривает вариант "Сделать все на overlay, а если Микрософт будет докапываться - предложить им оплатить дополнительные затраты на использование extensions"

И мне бы хотелось узнать, получилось ли у вас заставить МС оплатить

Цитата:

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

1. Они могут закрыть overlayering как класс (возможно - от балды навставлял точек расширения в стандартные прикладные классы). В этом случае, на первых же проектах, по итогам анализа партнеры начнут сообщать клиентам о том что в новой версии их бизнес-процессы не представляется возможным покрыть; Возможность серьезной доработки отрублена, а стандартной фунции для данного процесса - нету. После этого клиент с большой вероятностью бодро откажется от подписки на D365, спишет затраты на анализ в убытки и пойдет внедрять САП. Действительно - преимущество облачных технологий - можно в любой момент остановить проект, списав в убытки только небольшие понесенные затраты. Ну и партнеры само собой будут тоже плавно мигрировать в САП. Ведь если разработка по факту запрещена, то лучше использовать систему с более богатым базовым функционалом.

Ну и сколько ваших клиентов уже ушло в САП ? И начали ли вы миграцию на него ?

[fed]

Цитата:

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

И мне бы хотелось узнать, получилось ли у вас заставить МС оплатить

Ну у нас на D365 просто не было крупных клиентов. И в целом - понятно что если клиент купил 150 рабочих мест, то шансов продавить Микрософт у него не много. Помнится, EVGL писал что его клиенту микрософт что-то компенсировал - но я могу что-то путать.

Цитата:

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

Ну и сколько ваших клиентов уже ушло в САП ? И начали ли вы миграцию на него ?

Один из старых клиентов, обнаружив что на новую версию ему без радикального перевнедрения и смены бизнес-процессов не мигрировать - сейчас, судя по всему, очень активно думает. Еще один крупный клиент (правда там мы изначально не внедряли, а просто апгрейдили их с DAX4 на DAX2009), начал пробное внедрение D365FO в одном из филиалов. И похоже, что дела там идут так себе. В целом - есть достаточно заметные шансы что они поймут что апгрейд на D365 не возможен и начнут рассматривать другие варианты (хотя тут по разному может случится).
Как ни странно, среди новых клиентов (правда достаточно мелких), интерес к D365 достаточно большой. Но как мне написал один мой старый знакомый (владелец одного партнера в эмиратах): "my reply is wait until customers have been live for a year and then see how many sue"
P.S. Ах да - забыл добавить что мы, конечно, САПовскую практику открывать не планируем. Но моему боссу 67 лет, так что он просто не планирует на срок больше 2-3 лет.

[Logger]

Цитата:

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

Как ни странно, среди новых клиентов (правда достаточно мелких), интерес к D365 достаточно большой.

Спасибо.

А можно уточнить, мелкий клиент, это какой ? По какому критерию для себя ты относишь клиента к мелким ?

[fed]

Цитата:

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

Спасибо.

А можно уточнить, мелкий клиент, это какой ? По какому критерию для себя ты относишь клиента к мелким ?

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

[fed]

Мне как раз просто интересно - а зачем вообще использовать extensions, если они явно повышают трудозатраты на разработку, а трудозатраты на апгрейд, в типичном случае, снижают несильно ? Ну то есть - я могу представить какого-то нишевого ISV, который, например, написал приблуду для печати бар-кодов, интегрировал ее только через extensions и счастлив. Там этот подход вполне жизнеспособен.
Но вот когда я гляжу на типичный внедренческий проект, я понимаю что на одних extensions его в принципе не сделаешь. Более того - есть ощущение что процентов 70 типичных доработок будет уходить в overlay независимо от того, насколько сильно вам хочется использовать extensions. И вот отсюда и вопрос - а стоит ли городить огород с extensions на типичном проекте, если мы точно знаем что апгрейдить и мерджить приложение все равно придется (из за тех самых 70% типичных доработок ушедших в overlay...)?

[trud]

Extension для элементов или extension модели? Это же разные вещи
Extension для элементов позволяет менять меньше системного кода – тот же меню айтем добавить в меню, или в формах можно обойтись без перекрытия. Т.е. цель использования – сократить изменения в коде, чтобы легче фиксы ставить. Это вполне такой рабочий инструмент если использовать без фанатизма
extension модели – это другое. Зачем его используют на проектах я не понимаю, пример использования я видел и это было мягко говоря не очень. На вопрос – а собственно нафига, следовал стандартный ответ – ну мы же AX7, тут надо Extension

[AlexSD]

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

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

[trud]

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

[Logger]

Процитирую то, что мне показалось особенно интересным
https://habrahabr.ru/article/318462/

Цитата:

Вопрос:
— В Windows Server 2016 есть несколько технологий, которые изначально были созданы и использованы в Azure, такие как программный балансировщик нагрузки (Software Load Balancer), распределённый брандмауэр (Datacenter Firewall) и некоторые другие. Как вы представляете себе дальнейший путь (роадмап) развития и миграции технологий из Azure в Windows Server?
— Да, действительно, эти технологии уже себя зарекомендовали. В прошлом, когда мы разрабатывали какую-то штуку — первая версия, поставлявшаяся заказчику, была... первой разработанной версией! Конечно, мы проводили длительные бета-тесты, тестирование на железе, в замкнутых сетях и так далее. Но так или иначе, это была лишь первая версия любого ПО. Сейчас же всё происходит совершенно иначе.

Ответ :
Сейчас мы берём какую-то технологию из Azure, которая уже используется в промышленной среде и в огромных масштабах, и включаем её в операционную систему. Фактически это как если бы мы выпускали сразу четвёртую или пятую версию, потому что они уже обкатаны таким вот образом. Я ожидаю, что эта модель сохранится и в будущем, потому что она доказала свою успешность.

Хотя, одно из связанных с этим затруднений заключается в том, что развитие Azure работает в стиле непрерывного развёртывания (continuous delivery). Поэтому я думаю, что мы постараемся ещё точнее соответствовать этой модели в поставке наших технологий традиционным заказчикам, использующим Windows внутри своих организаций. Потому что — да, прямо сейчас мы просто взяли какие-то технологии и принесли их в Windows Server. Но, понимаете, с тех пор эти технологии продвинулись вперёд ещё дальше. А поэтому я думаю, что в будущем нам будет удобнее доставлять их заказчикам либо отдельно, по мере необходимости и вне традиционного цикла выпуска ОС, либо каким-то другим механизмом. В общем, подход такой — мы продолжим брать технологии из Azure и выпускать либо для Windows, либо для Azure Stack, и мы постараемся делать это таким способом, чтобы успевать за развитием Azure. И, если честно — это некая головоломка, которую нам предстоит решить. Настоящий вызов!

Вот откуда растут ноги у настойчивого желания работать всегда на последней версии. Они хотят, чтобы приложение позволяло безболезненно ставить обновления. Т.е. то что они хотят сделать для винды, SQL и.т.п - они хотят применить и для аксапты. Т.е. все это родилось не у архитекторов аксапты в голове, а на более высоком уровне. И наших просто прогнули.

Я не очень-то верю, что в итоге у них получится.
Думаю, что в итоге откажутся, как тут например:
emeadaxsupport: LCS Crash and Hang Analysis Discontinued
Или как в случае с реализацией наследования табличек в разных релизах 2012-й аксапты. (в 2012 RTM сделали все по науке - нормализовано - в итоге наука победила здравый смысл. Ну а жизнь все расставила по местам - прогнула под более разумные способы.)

Далее интервьюер спрашивает :

Цитата:

Вопрос:
— Почему? Существуют какие-то специфические препятствия, какие-то унаследованные особенности? Или в чём заключается основная сложность?

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

Сейчас мы придумали выпускать то, что называем «текущая ветвь для бизнеса» — Current Branch for Business или CBB. К примеру, вот Nano Server поддерживается именно по этой модели. Это значит, что какое-то время мы будем продолжать обновлять его такими же ежемесячными исправлениями, как и обычный Windows Server. Но в определённый момент, для конкретной версии это прекратится, все новые исправления будут входить уже в новую версию — и поэтому заказчикам потребуется перейти на эту новую версию. Но пока что это касается только Nano Server. Потому что Server Core и Server with Desktop Experience (традиционный вариант установки с графическим интерфейсом) продолжают использовать традиционную модель поддержки — т.е. сначала пять лет основной, и затем ещё пять лет расширенной.

Цитата:

Вопрос:
— Каков подход Microsoft к модели разработке с открытым кодом (Open Source)? Что из текущих продуктов и служб использует Open Source, а что может быть открыто в будущем?
Ответ:
....
Всё очень просто — слушать заказчиков и давать им то, чего они хотят. (Буагага, они бы лучше партнеров послушали ! -примеч. Logger ) В контексте Azure — давайте скажем прямо — мы хотим, чтобы каждое облачное приложение или система работали на Azure. Ну а для людей, использующих Linux, это подразумевает уверенность в том, что Linux будет отлично работать на Azure. Как компания мы вложили очень много средств, а как главный архитектор Windows Server я вложил очень много времени в то, чтобы наш стек виртуализации относился к Linux как «клиенту первого класса». Мы много работали над его производительностью, и — мы особо не говорим об этом — но в некоторых сценариях Linux показывает [в Azure] даже более высокие результаты, чем Windows. И это нормально, мы этого и добивались. И мы идём ещё дальше. Мы собираемся взять наше отличное ПО и сделать так, чтобы заказчики могли запускать его на тех ОС, на которых они сами захотят.

Цитата:

Вопрос:
— Вот вы недавно выпустили Windows Server 2016, а какие изменения произойдут с продуктом в ближайшие годы? Главное, как часто вы планируете обновлять его — раз в 3-4 года, как и раньше?

Ответ:
— Честный ответ заключается в том, что мы не знаем. Будучи гибкой и современной компанией, вы постоянно слушаете своих заказчиков — вследствие чего: (а) вы более прозрачны в собственных действиях, но (б) вы менее предсказуемы. Раз вы слушаете заказчиков и действуете по обстоятельствам — вы не знаете заранее, чего они вам скажут.

Задача, которую мы пытаемся решить, заключается в том, что есть большая группа заказчиков, которые хотят новейшие технологии как можно скорее. Это лучше всего сейчас заметно на примере клиентских ОС, где мы уже выпускаем обновления очень быстро. Но теперь у нас есть нечто аналогичное и для сервера — как я уже говорил, это «текущая ветвь для бизнеса» или CBB — новая версия, которая будет выпускаться с укороченным циклом. Но ведь, кроме того, есть и заказчики, которым это не нужно. Они хотят получить какую-то версию продукта, которую они купят и останутся на ней. Это то, что мы называем «Ветвь длительного обслуживания», Long Term Servicing Branch или LTSB. Вы её покупаете, и у вас есть пять лет стандартной поддержки, а потом ещё пять лет расширенной. Собственно, тут остаются те же правила игры, которые были раньше — на протяжении двадцати лет истории Windows Server.

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

Цитата:

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

Ответ:
— Я бы сказал, что есть вещи тактического порядка, а есть вещи стратегического порядка. Стратегические вещи почти не меняются, тактические же изменяются постоянно. Большая стратегическая перемена, я считаю, связана с переходом в облако или к облачной модели. Кроме того, глубоко убеждён, что в каждой компании, которая существует сегодня, за ближайшие 5-10 лет полностью сменится всё руководство — и генеральный директор, и вице-президенты, и директора. Их сменят люди, которые поймут, как использовать облако и с его помощью трансформировать собственные продукты и услуги.

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

[mazzy]

про локализацию на акс7 - сюда: Что-нибудь известно о локализации Microsoft Dynamics 365 for Operations?
про extensions - Клуб анонимных оверлейщиков

в этой ветке тема:
Вот мы и нашли этих 43 AX7 клиентов? Или это не AX7/D365?

[Vadik]

Перенес часть сообщений в новую ветку

[EVGL]

А вот и новые зловещие цифры: CLASH OF THE TITANS 2016.
За считанные годы Dynamics вылетел из тройки и скатился на 4 место после Infor. Вырос один показатель: время внедрения, до ДВУХ ЛЕТ, превысив среднее время внедрения SAP (sic!) на 25%.

[ax_mct]

Цитата:

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

А вот и новые зловещие цифры: CLASH OF THE TITANS 2016.
За считанные годы Dynamics вылетел из тройки и скатился на 4 место после Infor. Вырос один показатель: время внедрения, до ДВУХ ЛЕТ, превысив среднее время внедрения SAP (sic!) на 25%.

Спасибо. Хоть что-то.
Пишут правда что Aксапта была написана на Java, но это ладно. Вопрос в другом, Dynamics это группа продуктов, там и Solomon и CRM, и GP и Nav. Как при этом считают стоимость внедрения Dynamics и прочую статистику для меня загадка.

А главное не указаны источники информации и/или использованные методики.
Неужели акционеры Microsoft не могут затребовать реальную статистику. Не может это быть коммерческой тайной. Действительно ведь любопытно.

Туман поднялся на такую высоту что его начали называть облаками

P.S. Виноват. Это результат опроса 519 клиентов. Но какого рожна тогда они не дают результата по конкретным продуктам. Dynamics это на 80% CRM, и что его стоит внедрить $1.7 млн???

Цитата:

Clash of the Titans 2016 includes analysis of responses collected via the Panorama
Consulting website from June 2014 to October 2015. The dataset includes 519 respondents who have selected or implemented SAP, Oracle, Microsoft Dynamics or Infor ERP solutions.

[EVGL]

Более развернутый анализ дает, наверное, Gartner, но это стоит денег. Анализ проводится по ERP продуктам, и я рассчитываю на то, что аналитики не сравнивали SAP BW c Dynamics CRM.

[EVGL]

Сорри, старый отчет. Вот новый: http://go.panorama-consulting.com/rs...o4WmkifQ%3D%3D
Похоже, в 2016 году произошел серьезный поворот, и Dynamics получил мощный импульс. Что из этого D356fO, а что - AX2012 R3, понять трудно, хотя Cloud usage = 60% есть толстый намек. Каким образом в одном году disruption был три-четыре недели, а потом всего год спустя стал 1-2 недели, я не понимаю. В D356fO этот эффект немыслим, поскольку любой хотфикс развертывается по 5 часов в боевой версии, поэтому это делают раз в неделю, не чаще. Наверное, база для анализа очень мала.

Длительность проектов осталась в пределах 2 лет, что логично: внедрение по-быстрому "на коленке" прекратилось с выходом AX 2012, и навсегда. Появилось четкое разделение труда на консультантов, инфраструктурщиков, программистов и программистов BI. В D356fO разделение труда, в целом, не поменялось.

[ax_mct]

Цитата:

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

Сорри, старый отчет. Вот новый:

Clash of the Titans 2017 analyzes responses collected from Panorama’s
ERP Benchmark Survey between October 2015 and November 2016.
The dataset includes 470 respondents who have selected or
implemented SAP, Oracle, Microsoft Dynamics or Infor ERP solutions.

По прежнему говоря о Dynamics они говорят сразу обо всех продуктах. То есть совершенный туман.

Цитата:

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

Появилось четкое разделение труда на консультантов, инфраструктурщиков, программистов и программистов BI. В D356fO разделение труда, в целом, не поменялось.

Ага, тока популяция программистов D356fO это овечки Долли.
https://ru.wikipedia.org/wiki/%D0%94...2%D1%86%D0%B0)

[EVGL]

Цитата:

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

The dataset includes 470 respondents who have selected or
implemented SAP, Oracle, Microsoft Dynamics or Infor ERP solutions.

А если расставить жирным выделение вот так:
The dataset includes 470 respondents who have selected or
implemented SAP, Oracle, Microsoft Dynamics or Infor ERP solutions?