[gl00mie]

Цитата:

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

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

Давайте разберем по пунктам:

• Для склада такое, может, и прокатит - там бизнес-процессов меньше пары десятков. Это если тупо склад, а не какой-нить 3PL-оператор.
• "Тупо склад" с 15-ю бизнес-процессами - это ведь отнюдь не уровень среднего и крупного бизнеса, куда метит Dynamics AX, потому что там уже бизнес-процессов - под сотню, а то и более. Все их настроить и связать между собой с помощью шаблонов начальных данных? Что-то сомнительно.
• Настроить ERP-систему пригоршней галочек - это, по-моему, утопия. Помнится, у локализаторов была такая затея - сделать некий мастер, который на основе демо-базы как набора шаблонов и каких-то галочек вроде как перельет в пустую базу нужное подмножество настроек, и получится готовая к употреблению система. Однако, идея в итоге заглохла: думается, с разрастанием функционала комбинаторная сложность такой задачи свела на нет все попытки ее автоматизации.

Цитата:

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

Я так понимаю - процесс движется к идее, заложенной в MS Dynamics CRM, MS Office, MS Windows.

По-моему, в перечисленных системах заложены 3 совершенно разные идеи

• MS Windows - это платформа для запуска приложений, которая, во-первых, сама по себе нафиг никому не нужна, во-вторых, она в целом ряде сценариев избыточна, требуя слишком много ресурсов и внимания для обслуживания самой себя (в т.ч. пресловутого накатывания заплаток и связанных с этим перезагрузок). Последние затеи типа Nano Server доказывают, что там не то что дописывать - в пору выкидывать лишнее.
• MS Office - чудесный пакет, который установлен, наверно, практически у всех, но он реализует сравнительно небольшое число совершенно типовых сценариев использования, стабильных и неизменных на протяжении десятилетий и, кроме прочего, не зависящих от местного законодательства или иных особенностей. Максимум, где-то пишут слева направо, а где-то - справа налево. Как по мне, развитие функционала Ms Office остановилось на версии 2010, дальше пошли рюшечки и портирование на другие платформы.
• А вот Dynamics CRM - отдельная тема...

Цитата:

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

Следующим напрашивающимся шагом будет закрытие исходного кода (сейчас делаются все шаги к тому, чтобы простимулировать разработчиков максимально не трогать штатный код) и останутся dll-ки, к которым можно будет писать свои add-оны. Ведь по большому счету никто же не посягает на исходные коды Excel, Word - все ими пользуются и пишут в отдельных случаях макросы (=add-оны).

Контр-пример: Dynamics Enterprise POS поставляется с частично закрытым кодом, и это приносит огромное количество проблем на проектах внедрения, при этом в Modern POS уже открыто все. А мотивы максимально не трогать штатный код могут быть иными: каждый, кто ставил обновления для стандартного приложения Аксапты, видел, как ради копеечного исправления в обновление по зависимостям тянутся тонны других изменений. Накатывать такие исправления неудобно, небезопасно, трудоемко, но логика тут тоже есть: раз имеется зависимость, то изменение одного из компонент "по умолчанию" влияет на все связанные, поэтому изменения должны поставляться общим большим пакетом. Так что и кастомизации, меняющие что-то в штатном коде, должны по зависимостям включать в себя тонны связанного кода. Отсюда - мораль: надо уменьшить число зависимостей и по возможности запретить напрямую менять штатный код, чтобы кастомизации было удобнее, безопаснее и менее трудоемко накатывать.

Цитата:

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

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

По-моему, движение в сторону настройки галочками и невозможности менять стандартное приложение (только лепить что-то сбоку) как раз приведет Dynamics AX в сторону того же SAP с его узкими специалистами по отдельным модулям и их бесчисленным настроечным галочкам. Какая уж там настройка через LCS, да еще и силами самих клиентов!

Цитата:

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

Консалтинг здесь будет зарабатывать видимо "ассортиментом решений Microsoft". Т.е. где-то сваять программку на C#, где-то сделать add-on для Dynamics AX/CRM/..., MS Office - в общем - всем понемножку. Опять-таки - партнеры не будут узконаправленными, а будут работать по всей линейке продуктов MS, что снова хорошо ложится в стратегию MS-а в целом

По-моему, нормально зарабатывать, занимаясь всем понемножку, малореально, потому что если будет небольшое число "специалистов широкого профиля", то они глубоко не будут разбираются ни в чем и вынуждены будут конкурировать со "студентами-недоучками", а если будет толпа узких специалистов, то у них будет эпизодическая, очень неравномерная загрузка. Специалист либо должен быть загружен по 8 часов 5 дней в неделю, либо его услуги будут космически дороги, либо он будет прозябать и уйдет в другие технологии/отрасли. А кроме того, вендор вроде как смотрит на ситуацию иначе: вертикальная специализация, а не горизонтальная "всеядность" и затыкание щелей на стыках различных продуктов. В конце концов, клиентам не нужен "ассортимент решений Microsoft", им нужно решение их проблем в их конкретной отрасли за приемлемые деньги, а уж будет ли решение основано на одном монолитном продукте или целом стеке технологий и каких-то микросервисов - дело десятое.