Comments 46
Что мне всегда нравилось в ERP в Европе, что там особо никто не парится документами строгой отчетности и прочей бумажной волокитой. Приезжает машина, водитель дает планшет, ты расписываешься, что получил 5 коробок непонятно чего. Дальше тебе в конце месяца выставляют инвойс на все содержимое коробок за месяц. Это конечно все значительно проще, чем в СНГ. Правда потом бывало, что привезли одно, а инвойс на немного другое, но это уже другая история.
Спасибо за статью. А можете вкратце рассказать, как вы дорабатываете «облачное решение»? Допустим там есть стандартные модули с функционалам каким-то. Дальше доделываются плагины или как? Например, надо добавить на форму Purchase Order какую-то колонку или поле (и в базу тоже). Как это происходит, и как потом это все поддерживается при обновлении базового продукта Dynamics?
Спасибо за статью. А можете вкратце рассказать, как вы дорабатываете «облачное решение»? Допустим там есть стандартные модули с функционалам каким-то. Дальше доделываются плагины или как? Например, надо добавить на форму Purchase Order какую-то колонку или поле (и в базу тоже). Как это происходит, и как потом это все поддерживается при обновлении базового продукта Dynamics?
В новой версии Dynamics 365 Microsoft полностью изменил идеологию разработки и кастомизации приложения — теперь все делается через расширения (extensions). При этом расширения доступны далеко не для всех стандартных алгоритмов, что, с одной стороны, добавляет головной боли разработчику, а, с другой стороны, мотивирует подумать над внедряемым процессом и попытаться изменить процесс, а не систему.
Цели вендора тоже понятны — сделать приложения клиентов всегда актуальными с минимальными трудозатратами. Ведь не секрет, что для классической ERP обновление версии зачастую равнозначно новому внедрению.
Цели вендора тоже понятны — сделать приложения клиентов всегда актуальными с минимальными трудозатратами. Ведь не секрет, что для классической ERP обновление версии зачастую равнозначно новому внедрению.
Спасибо за ответ. А можно где-то почитать в онлайне про этот механизм?
И можете все-таки по моему примеру: как расширить форму заказа на закупку или продажу. Например, хочется добавить какую-то волшебный параметр, а затем пересчитывать цены в заказе на основе параметра. Как это в общих чертах делается?
И можете все-таки по моему примеру: как расширить форму заказа на закупку или продажу. Например, хочется добавить какую-то волшебный параметр, а затем пересчитывать цены в заказе на основе параметра. Как это в общих чертах делается?
Конечно, можно. Вот домашняя страница про расширения.
Если вкратце, то для таблицы заказов на покупку нужно создать расширение, добавить в него новое поле (параметр). Дальше все зависит от задачи. Если это отдельная кнопка по пересчету цен, то можно создать свой класс с логикой расчета, для вызова класса создать MenuItem, для формы также сделать Extension, в который положить новый MenuItem. Если есть необходимость вклиниться с новым параметром в существующую логику расчета, то нужно смотреть возможность расширения этих стандартных классов. Можно также сделать делегаты на события, в которые включить нужную логику расчета цен, например, при изменении нашего нового параметра запустить логику расчета цен.
Если вкратце, то для таблицы заказов на покупку нужно создать расширение, добавить в него новое поле (параметр). Дальше все зависит от задачи. Если это отдельная кнопка по пересчету цен, то можно создать свой класс с логикой расчета, для вызова класса создать MenuItem, для формы также сделать Extension, в который положить новый MenuItem. Если есть необходимость вклиниться с новым параметром в существующую логику расчета, то нужно смотреть возможность расширения этих стандартных классов. Можно также сделать делегаты на события, в которые включить нужную логику расчета цен, например, при изменении нашего нового параметра запустить логику расчета цен.
А как вы оценивали плановые трудозатраты? Ведь найти место куда можно вклиниться часто сопоставимо с тем, что нужно сделать. Сразу умножали на 2? :)
Не очень понимаю, в чем сложность. Взял форму и добавил. В ней посмотрел DataSource и туда добавил поле. Другое дело, что если не сделали «точку входа», чтобы вклиниться в расчет или события, то или нельзя сделать, или по старинке — overlayering, как я понял.
Примерно так и делали. Это связано ещё с новой схемой программирования и переноса кастомизаций моделями, хоть модели и были в предыдущих версиях. Например, сначала мы делали разные модели для разных блоков функциональности. Потом пришли к выводу, что проще не множить зависимости между библиотеками (dll), и весь свой код иметь и деплоить одной моделью
И еще маленький вопрос:
А почему нельзя было просто запустить это все на российской инфраструктуре? Пинг до Германии где-то 50мс, разве этого недостаточно?
Кроме сроков был еще вопрос бюджета: разворачивать и обслуживать в Германии собственную ИТ-инфраструктуру и покупать корпоративные программные лицензии слишком дорого в пересчете на одного пользователя.
А почему нельзя было просто запустить это все на российской инфраструктуре? Пинг до Германии где-то 50мс, разве этого недостаточно?
Тут акцент все-таки больше не на инфраструктуру в Германии, а на инфраструктуру как таковую. Даже в России нужно было выделять серверные мощности под виртуальные сервера. Если выделять отдельное железо, то есть риск не утилизировать его полностью. Если использовать виртуализацию на текущем — все равно рано или поздно нужно будет расширяться. Посчитали наши объемы (по сути нагрузку на систему), отправили этот чеклист вендору и получили 7 виртуальных машин только под продакшн. Кроме этого еще приближенный к продуктивному environment для пользовательского тестирования, и чуть более сжатый вариант под сборку приложения. И это все без учета DRP. С учетом небольшого количества пользователей, всего 20 лицензий, вариант с облачным решением подошел идеально.
Извините, но 7 виртуальных машин под 20 пользователей? А можно поинтересоваться какие характеристики этих виртуальных машин?
Облачная версия Dynamics — это чистый SaaS, у клиента нет доступа к продуктивной среде совсем. Даже средств посмотреть сайзинг виртуальных машин нету. Этим управляет вендор на основе показателей производительности и заявленных требований клиента.
Тут нету прямой зависимости между пользователями и нагрузкой. 20 пользователей может нагенерировать достаточно данных для фоновой обработки, как в нашем случае. Если чуть более конкретно, то сайзинг окружения считается, исходя из запускаемых процессов (какая функциональность будет использоваться) и из количества номенклатур, поставщиков, клиентов, количества складских транзакций, количества финансовых транзакций, наличия интеграций и т.д. Это все указывается в опросном шаблоне перед выходом в продакшн.
Если говорить конкретно про 7 наших виртуальных машин, то их роли такие — БД, 4 сервера приложений, 2 сервера отчетности.
Могу ответить про сайзинг виртуальных машин, которые мы используем для разработчиков — это OneVM DevBox в Azure Standard E8 v3 (8 vcpus, 64 GiB memory)
Тут нету прямой зависимости между пользователями и нагрузкой. 20 пользователей может нагенерировать достаточно данных для фоновой обработки, как в нашем случае. Если чуть более конкретно, то сайзинг окружения считается, исходя из запускаемых процессов (какая функциональность будет использоваться) и из количества номенклатур, поставщиков, клиентов, количества складских транзакций, количества финансовых транзакций, наличия интеграций и т.д. Это все указывается в опросном шаблоне перед выходом в продакшн.
Если говорить конкретно про 7 наших виртуальных машин, то их роли такие — БД, 4 сервера приложений, 2 сервера отчетности.
Могу ответить про сайзинг виртуальных машин, которые мы используем для разработчиков — это OneVM DevBox в Azure Standard E8 v3 (8 vcpus, 64 GiB memory)
Извините, но не очень понял. У вас было два варианта размещения Dynamics: либо в их облаке с неизвестной инфраструктурой, либо on-premise на своей инфраструктуре. Как я понимаю, вы заполняете опросник, а они говорят какие виртуальные машины в вашей инфраструктуре требуются в продакшене. Они вам сказали, что нужно 7 машин, но не указали каких именно?
Прошу прощения, если не совсем точно объяснил. История с чеклистом для клауда работает так, что он не возвращается назад к клиенту, на основании него MS принимает решение, какого масштаба нужна инфраструктура под клиента в облаке, и ее готовит. В итоге мы просто получили по факту тот набор серверов, который я описал.
В случае решения клиента запускать D365 on-premise, насколько я понимаю, этот чек-лист подгружается в утилиту hardware estimator на портале LCS, и клиент получает рекомендации по сайзингу, но решение остаётся окончательно за ним. Кстати, я могу попробовать прогнать наш чек-лист через эту утилиту и поделиться результатом.
Спасибо за ответ.
То есть эти 7 виртуальных машин — это именно в облаке? А цены на эти 7 виртуальных серверов одинаковые? Или там просто цены за пользователя и эти 7 машин — это просто справочная информация?
Было бы очень интересно.
История с чеклистом для клауда работает так, что он не возвращается назад к клиенту, на основании него MS принимает решение, какого масштаба нужна инфраструктура под клиента в облаке, и ее готовит
То есть эти 7 виртуальных машин — это именно в облаке? А цены на эти 7 виртуальных серверов одинаковые? Или там просто цены за пользователя и эти 7 машин — это просто справочная информация?
Кстати, я могу попробовать прогнать наш чек-лист через эту утилиту и поделиться результатом.
Было бы очень интересно.
Цены только за пользователей.
А результатами оценки сайзинга поделюсь в ближайшее время.
Вы знаете, обыскал весь LCS портал и не увидел для проектов Dynamics 365 on-premise утилиты Infrastrucure estimator. Оставили только Subscription estimator, куда загружается опросник для клаудных версий.
А Infrastructure estimator вижу только для предыдущей версии AX2012 — это не очень интересно.
Похоже, что для on-premise решений придется руководствоваться только этим гайдом.
А Infrastructure estimator вижу только для предыдущей версии AX2012 — это не очень интересно.
Похоже, что для on-premise решений придется руководствоваться только этим гайдом.
у вас есть какой-то мониторинг по утилизации виртуальных машин? насколько эффективно они используются и нет ли смысла переити на более слабую или наоборот, более мощную виртуалку?
MS странные люди, для полного цикла надо минимум 22 сервера. Так к ним еще и добавляется головная боль по обновлению всего этого. Сразу возникает желание работать в облаке. И вот тут в Европе получается фэйл — закон о персональных данных в каждой стране имеет какие-то свои особенности и работать в облаке не представляется возможным. Вы упомянули что вы вторыми в России внедрили 365, как? Без персональных данных? Или у MS появились сервера в России?
Как я понял вторыми, кто использует в России, но для автоматизации дочки в Германии. Наверное, поэтому больше никто в России 365 не использует, так как есть проблема с персональными данными, если использовать для российских процессов.
Кстати, MS обещал плагин по работы с персональными данными, если еще не выпустил. Суть плагина состоит в том, чтобы настроенные данные, которые компания считает персональными, сначала складывать на российские сервера, и только потом сохранять в облако Azure. К сожалению, в России датацентров у MS действительно нет.
Законодательство РФ (а именно ФЗ-152) накладывает ограничение на обработку персональных данных, предписывая осуществлять сбор и актуализацию (в понятиях Роскомнадзора) таких данных на серверах, расположенных на территории РФ, а хранение — допускается на территории стран, присоединившихся к конвенции «о ПдН». В нашей реализации (Lamoda) сбор и актуализация ПдН осуществляется в on-premise информационных системах и БД, сервера которых расположены на территории РФ. В 365 используется «копии» этих данных.
UFO just landed and posted this here
«В Европе приняты трудовые законы, поэтому внедрение и разборки с законами выполняли российские специалисты».
Классически, по-менеджерски завуалированная издёвка над людьми, которые вкалывали по 12 часов при зарплате явно несравнимой с европейской.
Классически, по-менеджерски завуалированная издёвка над людьми, которые вкалывали по 12 часов при зарплате явно несравнимой с европейской.
Отличная статья
Особенно комментарий о преимуществах облачного решения.
Всего 7 VM на 20 пользователей? Счастливчики.
А как вам локальная инфраструктура на 200 юзеров и вынесенный в облако WebShop? Даже сказать страшно Сколько VM.
Особенно комментарий о преимуществах облачного решения.
Всего 7 VM на 20 пользователей? Счастливчики.
А как вам локальная инфраструктура на 200 юзеров и вынесенный в облако WebShop? Даже сказать страшно Сколько VM.
Здание на фото, кстати, – это Rocket Internet Tower, инкубатор стартапов. Оттуда, например, происходит и немецкий аналог Lamoda – Zalando
есть трудности с интеграцией с немецким банком
Можете немного подробнее рассказать в чем трудности? Это проблема конкретного банка или европейских банков в целом? Или проблема не а банке а исключительно в сроках?
Трудности с интеграцией связаны прежде всего с ограничениями стандартного функционала по генерации файлов для интернет-банка по международным и местным платежам, который не позволяет, например, объединять в одну платежку несколько платежей (за несколько инвойсов) с одинаковыми реквизитами, при этом корректно указывая в назначении платежа весь список исходных документов, за которые идет оплата.
Также была чисто техническая проблема с кодировкой создаваемых файлов — D365 генерит их в UFT-8, а интернет банк ожидает только ANSI.
И ещё есть заморочка с факторингом: либо мы не научились его "готовить", либо в немецкой локализации нет этого функционала.
«Российских клиентов, использующих облачное решение этой системы, почти нет (если быть точнее — мы стали вторыми), но для наших целей оно подходило лучше всего.»
Есть же компания Норбит, которая как раз внедряет решения от MS. Или они не к облаку делают?
Есть же компания Норбит, которая как раз внедряет решения от MS. Или они не к облаку делают?
А как делали тестирование?
И как планируете иметь дело с ежемесячными обновлениями данной системы?
И как планируете иметь дело с ежемесячными обновлениями данной системы?
Тестирование на текущий момент делаем вручную.
Обновления регулярно накатываем, и пока процесс нравится. Пользуемся вариантом с объединением package'а обновления с моделью собственных разработок, и единым пакетом деплоим. Тестируем обновленное приложение в SAT environment, затем выкатываем в прод.
Большие ожидания связаны с недавно анонсированной утилитой автоматических регрессионных тестов.
Обновления регулярно накатываем, и пока процесс нравится. Пользуемся вариантом с объединением package'а обновления с моделью собственных разработок, и единым пакетом деплоим. Тестируем обновленное приложение в SAT environment, затем выкатываем в прод.
Большие ожидания связаны с недавно анонсированной утилитой автоматических регрессионных тестов.
Sign up to leave a comment.
Технологии, аутсорс и менталитет: как мы внедряли Microsoft Dynamics 365 в немецком офисе Lamoda