Технологии, аутсорс и менталитет: как мы внедряли Microsoft Dynamics 365 в немецком офисе Lamoda

    Объединение учетных систем удаленного филиала и их интеграция с головной структурой — задача достаточно непростая даже в пределах России. А когда заказчик находится за рубежом, весь проект может усложнить отсутствие экспертизы в местном налоговом законодательстве и конфликт менталитетов. Меня зовут Станислав Гоц, я руковожу отделом разработки ERP-систем Lamoda и в этом посте расскажу вам как раз о таком опыте — о внедрении ERP-системы в нашем немецком филиале.

    image

    Наш филиал в Германии закупает товары и продает их российскому юридическому лицу. Использовавшаяся в нем система Tsenit позволяла вести учет только на уровне финансовых данных: кто, кому и сколько должен денег, когда прошла покупка или продажа и т.д. Учет товара и логистические задачи средствами Tsenit было выполнять невозможно, для решения этих задач приходилось использовать дополнительные инструменты, что отрицательно влияло на скорость и надежность всей системы. Данные в результате были разбросаны по нескольким базам.

    К тому же немецкое юрлицо должно сдавать отчетность, платить налоги и проходить аудиторские проверки — а с существовавшими системами учета решать подобные задачи было непросто.



    Чтобы понять, почему в Tsenit были сделаны те или иные финансовые проводки, и ответить на простые вопросы налоговых служб или аудиторов, приходилось вручную лопатить огромные объемы данных в Excel и обращаться в отдел логистики. 



    В какой-то момент было решено объединить бухгалтерию и финансы с логистикой в единый контур в рамках одной ERP-системы филиала. В качестве основного программного обеспечения была выбрана Microsoft Dynamics 365 — бывшая Dynamics AX, или еще проще — Axapta. Российских клиентов, использующих облачное решение этой системы, почти нет (если быть точнее — мы стали вторыми), но для наших целей оно подходило лучше всего.

    Сроки, бюджет и вера в светлое будущее


    У нас были жесткие ограничения по срокам: запуск подобной системы в середине финансового года требует переноса всего набора исторических данных, что стало бы неподъемной задачей, ведь в старой системе товарный учет фактически отсутствовал и велся в электронных таблицах. Зато в начале отчетного периода достаточно перенести только балансы. Таким образом, запуск необходимо было произвести либо 1 января 2019 года, либо отложить его еще на год. Связанные с торговлей и складской логистикой процессы не особенно сложные, и нам казалось, что проблем со сроками не возникнет.

    Кроме сроков был еще вопрос бюджета: разворачивать и обслуживать в Германии собственную ИТ-инфраструктуру и покупать корпоративные программные лицензии слишком дорого в пересчете на одного пользователя. 

    Поскольку в немецких бизнес-процессах участвует не более 20 человек, мы остановились на облачном решении Dynamics 365. Для небольших удаленных филиалов схема SaaS оптимальна, она позволяет получить все необходимое ПО и среды разработки, чтобы начать внедрение сразу после подписания договора с провайдером. 

    Политика лицензирования Microsoft Dynamics 365 предельно проста и предполагает фиксированную стоимость за одну пользовательскую лицензию в месяц, при этом количество пользователей можно увеличивать или уменьшать. Это стало еще одним аргументом за выбор именно этого программного продукта.

    Подводные камни


    Главная проблема лежала вне технической плоскости: мы не знали всех требований европейского законодательства к ведению учета в подобных системах. Microsoft Dynamics 365 охватывает огромное количество бизнес-процессов; выпускаются так называемые пакеты локализации, которые позволяют гибко настраивать решение под специфику законодательства конкретной страны. Если российскую версию команда разработки давно изучила, то с версией для Германии мы никогда не сталкивались.  Настройка такого решения силами собственной команды стала бы трудновыполнимой задачей.



    image

    У немецкого менеджмента были опасения, что российская сторона не справится с поставленной задачей из-за отсутствия опыта и знаний в локальном налоговом и бухгалтерском учете. В итоге выбрали золотую середину и привлекли внешний консалтинг. Он должен был закрыть связанные с европейскими законодательными требованиями пробелы, обеспечить аудит миграции из предыдущей финансовой системы, проанализировать описания бизнес-процессов, оптимизировать их и подогнать под будущее решение с максимальным использованием стандартной функциональности. При необходимости доделок их планировалось выполнить, постепенно погружая российскую команду в разработку.

    Начало внедрения и перенос данных


    По-умолчанию мы получили права на три среды: BUILD — для сборки созданного разными разработчиками кода в одно приложение, SAT (Standard Acceptance Testing) — для проведения приемочного пользовательского тестирования, а также PROD — для эксплуатации. Помимо этого для каждого разработчика в Azure развернуты виртуальные машины dev-box. Вся инфраструктура управляется и мониторится через единый портал — Lifecycle services, а особенность процесса кастомизации заключается в том, что любые доработки попадают в среду PROD только через SAT.

    Благодаря тому, что в качестве новой системы был выбран Microsoft Dynamics 365, перенос данных удалось осуществить сравнительно несложно, с помощью доступных из коробки Data packages. В Dynamics 365 есть тесная связь с продуктами Microsoft, в том числе и с Excel: для пользователя это выглядело как электронная таблица с подключением к сервисам Dynamics 365 через ODATA. С помощью расширения Excel пользователи публиковали данные напрямую в систему. Немецкая сторона готовила шаблоны, отмечая в них обязательные для заполнения столбцы. Пользователи эти шаблоны заполняли, а консультанты контролировали процесс импорта. 

    Среди прочего из старой системы учета консалтеры перенесли информацию о поставщиках и клиентах, а также балансы по счетам главной книги. Прямой перенос всех данных по товарам потребовал бы значительного времени и усилий, и мы постарались решить эту задачу более эффективным способом. Была реализована интеграция новой системы учета немецкого филиала с основной российской системой, в которой находятся мастер-данные по товарам. Физических остатков в Германии на конец года у нас не было, и в итоге потребовалось перенести из старой системы только справочную информацию, необходимую для дальнейшего товародвижения. Таким образом удалось обойтись без переноса всех исторических данных по товарам, что сохранило время. 

    Полуаутсорсинг: подключение российской команды


    Начав внедрение в июне 2018 года, мы рассчитывали решить все задачи до новогодних праздников, но помимо естественных в таких проектах языковых проблем появились трудности с коммуникацией. Консалтеры из Германии долго отвечали на запросы. Работник не может работать без перерыва более 6 часов подряд. После окончания работы он должен иметь минимум 11 часов свободного от работы времени. А когда специалист занимается другим клиентом, его нельзя ни о чем спрашивать. Такой формальный подход повлиял на сроки. В какой-то момент подрядчик предложил к новому году запустить только финансовый учет, который и так работал в старой системе. Нас это не устроило. С 2013 года мы самостоятельно внедряем Axapta в Lamoda, а в 2016 году полностью перевели на нее весь бухгалтерский учет из 1С. Процессы в России куда более сложные, поэтому мы знали: проект можно завершить в установленные сроки. 



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

    Плюс постоянно возникали какие-то нестандартные задачи. Благодаря глубокому погружению основной российской команды в разработку, решить их удавалось сравнительно быстро. Кроме того, решения изначально разрабатывались с учётом знаний о всех системах и процессах, используемых в нашей компании.

    Одна из таких задач — интеграция нового облачного окружения с существующей российской ERP-системой. В ней уже была реализована связанная с работой закупщиков функциональность, и мы не хотели дублировать код, чтобы не усложнять его поддержку. В итоге заказы на покупку товаров у иностранных поставщиков создаются в российской ERP и потом переносятся в немецкое облако. 

    В процессе внедрения российская команда освоила полностью новый для нас подход к разработке и новый инструментарий. Раньше мы использовали собственную IDE для Axapta, но здесь перешли на Visual Studio и Azure DevOps. Во время реализации проекта менялись версии ПО, а наши специалисты познали все прелести параллельной разработки для облачных сред — в техническом плане это было весьма интересно. 

    SureStep vs Agile: проблемы запуска


    Коллеги из Германии работали по методологии Microsoft SureStep. Это негибкий подход, который ближе к классическому «водопаду». Он предполагает на каждом этапе документирование всего, подготовку функциональных и технических дизайнов, тщательное тестирование с выпуском протоколов, запись процессов в какую-нибудь систему моделирования и т.д. С запросом на такую документацию коллеги обратились к нам за месяц до запуска. Новая ERP-система к тому моменту уже более-менее функционировала. Предполагая запустить ее за полгода, мы выбрали более гибкие методики разработки: ежедневные стендапы, обсуждение задач и еженедельные релизы. Для ведения документации использовали Work items в Azure DevOps, там же отражали ход проекта и подтверждали результаты тестирования.

    Поскольку система облачная, финальное решение о ее выходе в продакшен принимала компания Microsoft, все контакты с которой осуществляли наши подрядчики. Они, в свою очередь, оказались не готовы посылать заявку без всей необходимой с точки зрения методологии SureStep документации. В итоге своевременный запуск проекта оказался под угрозой.

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

    Испытание в бою


    Благодаря своевременному привлечению собственной команды нам удалось уложиться в сроки и запустить систему 1 января 2019 года, как и планировалось изначально. 

    Новая учетная система объединила финансовую часть и логистику, мы уже сдали через нее квартальную отчетность в Германии. Перед этим нам удалось провести т.н. закрытие месяца без значительного ущерба по срокам. При запуске такого класса систем задержки неизбежны, но в январе мы опоздали на три дня, а в феврале — всего на один. Данные из системы пока собираем вручную, сейчас российская команда разработки занимается автоматизацией отчетности. Проблемы в основном связаны с человеческим фактором: сотрудникам сложно выполнять новые для них процедуры, и какие-то шероховатости обязательно вылезают. 

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



    Бонусом того, что над проектом работали наши разработчики, стало ещё и то, что сразу на этапе внедрения были выполнены доработки, улучшающие функциональность системы. 

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

    Итоги


    Изначально мы рассчитывали на то, что большая часть работ ляжет на подрядчика, а в результате все ключевые блоки сделали силами собственной разработки. Обычно запуск ERP занимает от 1 года, нам же удалось запуститься за 6 месяцев с момента инициации проекта, из которых активная разработка длилась всего в 3 месяца.

    В итоге мы получили уникальный опыт, которым и решили поделиться. Сотрудничество со знающими местные условия иностранными подрядчиками имеет практический смысл, но ждать от них чудес не стоит. Если у вас имеется собственная сильная команда, на аутсорсинг стоит выносить только консалтинг и постановку задач, а также тестирование. 



    Это не конец нашей истории. Новый вызов связан с внедрением в России единой национальной системы маркировки товаров. Законодатели перенесли сроки ее запуска на 2020 год, но мы хотим уже с июля маркировать каждую пару обуви уникальным штрих-кодом до прохождения товаром таможни. Помимо этого всегда есть связанные с оптимизацией производительности задачи. Ну и прочих идей и планов у нас предостаточно. При их реализации мы теперь будем больше полагаться на свои силы, для чего сначала придется немного «растолстеть».
    Lamoda
    105,34
    Russian Fashion Tech
    Поделиться публикацией

    Комментарии 46

      0
      Что мне всегда нравилось в ERP в Европе, что там особо никто не парится документами строгой отчетности и прочей бумажной волокитой. Приезжает машина, водитель дает планшет, ты расписываешься, что получил 5 коробок непонятно чего. Дальше тебе в конце месяца выставляют инвойс на все содержимое коробок за месяц. Это конечно все значительно проще, чем в СНГ. Правда потом бывало, что привезли одно, а инвойс на немного другое, но это уже другая история.

      Спасибо за статью. А можете вкратце рассказать, как вы дорабатываете «облачное решение»? Допустим там есть стандартные модули с функционалам каким-то. Дальше доделываются плагины или как? Например, надо добавить на форму Purchase Order какую-то колонку или поле (и в базу тоже). Как это происходит, и как потом это все поддерживается при обновлении базового продукта Dynamics?
        0
        В новой версии Dynamics 365 Microsoft полностью изменил идеологию разработки и кастомизации приложения — теперь все делается через расширения (extensions). При этом расширения доступны далеко не для всех стандартных алгоритмов, что, с одной стороны, добавляет головной боли разработчику, а, с другой стороны, мотивирует подумать над внедряемым процессом и попытаться изменить процесс, а не систему.
        Цели вендора тоже понятны — сделать приложения клиентов всегда актуальными с минимальными трудозатратами. Ведь не секрет, что для классической ERP обновление версии зачастую равнозначно новому внедрению.
          0
          Спасибо за ответ. А можно где-то почитать в онлайне про этот механизм?
          И можете все-таки по моему примеру: как расширить форму заказа на закупку или продажу. Например, хочется добавить какую-то волшебный параметр, а затем пересчитывать цены в заказе на основе параметра. Как это в общих чертах делается?
            0
            Конечно, можно. Вот домашняя страница про расширения.
            Если вкратце, то для таблицы заказов на покупку нужно создать расширение, добавить в него новое поле (параметр). Дальше все зависит от задачи. Если это отдельная кнопка по пересчету цен, то можно создать свой класс с логикой расчета, для вызова класса создать MenuItem, для формы также сделать Extension, в который положить новый MenuItem. Если есть необходимость вклиниться с новым параметром в существующую логику расчета, то нужно смотреть возможность расширения этих стандартных классов. Можно также сделать делегаты на события, в которые включить нужную логику расчета цен, например, при изменении нашего нового параметра запустить логику расчета цен.
              0
              А как вы оценивали плановые трудозатраты? Ведь найти место куда можно вклиниться часто сопоставимо с тем, что нужно сделать. Сразу умножали на 2? :)
                0
                Не очень понимаю, в чем сложность. Взял форму и добавил. В ней посмотрел DataSource и туда добавил поле. Другое дело, что если не сделали «точку входа», чтобы вклиниться в расчет или события, то или нельзя сделать, или по старинке — overlayering, как я понял.
                  0

                  Overlaying больше не работает

                  0

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

          0
          И еще маленький вопрос:
          Кроме сроков был еще вопрос бюджета: разворачивать и обслуживать в Германии собственную ИТ-инфраструктуру и покупать корпоративные программные лицензии слишком дорого в пересчете на одного пользователя.

          А почему нельзя было просто запустить это все на российской инфраструктуре? Пинг до Германии где-то 50мс, разве этого недостаточно?
            0
            Тут акцент все-таки больше не на инфраструктуру в Германии, а на инфраструктуру как таковую. Даже в России нужно было выделять серверные мощности под виртуальные сервера. Если выделять отдельное железо, то есть риск не утилизировать его полностью. Если использовать виртуализацию на текущем — все равно рано или поздно нужно будет расширяться. Посчитали наши объемы (по сути нагрузку на систему), отправили этот чеклист вендору и получили 7 виртуальных машин только под продакшн. Кроме этого еще приближенный к продуктивному environment для пользовательского тестирования, и чуть более сжатый вариант под сборку приложения. И это все без учета DRP. С учетом небольшого количества пользователей, всего 20 лицензий, вариант с облачным решением подошел идеально.
              0
              Извините, но 7 виртуальных машин под 20 пользователей? А можно поинтересоваться какие характеристики этих виртуальных машин?
                0
                Облачная версия Dynamics — это чистый SaaS, у клиента нет доступа к продуктивной среде совсем. Даже средств посмотреть сайзинг виртуальных машин нету. Этим управляет вендор на основе показателей производительности и заявленных требований клиента.
                Тут нету прямой зависимости между пользователями и нагрузкой. 20 пользователей может нагенерировать достаточно данных для фоновой обработки, как в нашем случае. Если чуть более конкретно, то сайзинг окружения считается, исходя из запускаемых процессов (какая функциональность будет использоваться) и из количества номенклатур, поставщиков, клиентов, количества складских транзакций, количества финансовых транзакций, наличия интеграций и т.д. Это все указывается в опросном шаблоне перед выходом в продакшн.
                Если говорить конкретно про 7 наших виртуальных машин, то их роли такие — БД, 4 сервера приложений, 2 сервера отчетности.
                Могу ответить про сайзинг виртуальных машин, которые мы используем для разработчиков — это OneVM DevBox в Azure Standard E8 v3 (8 vcpus, 64 GiB memory)
                  0
                  Извините, но не очень понял. У вас было два варианта размещения Dynamics: либо в их облаке с неизвестной инфраструктурой, либо on-premise на своей инфраструктуре. Как я понимаю, вы заполняете опросник, а они говорят какие виртуальные машины в вашей инфраструктуре требуются в продакшене. Они вам сказали, что нужно 7 машин, но не указали каких именно?
                    0

                    Прошу прощения, если не совсем точно объяснил. История с чеклистом для клауда работает так, что он не возвращается назад к клиенту, на основании него MS принимает решение, какого масштаба нужна инфраструктура под клиента в облаке, и ее готовит. В итоге мы просто получили по факту тот набор серверов, который я описал.
                    В случае решения клиента запускать D365 on-premise, насколько я понимаю, этот чек-лист подгружается в утилиту hardware estimator на портале LCS, и клиент получает рекомендации по сайзингу, но решение остаётся окончательно за ним. Кстати, я могу попробовать прогнать наш чек-лист через эту утилиту и поделиться результатом.

                      0
                      Спасибо за ответ.
                      История с чеклистом для клауда работает так, что он не возвращается назад к клиенту, на основании него MS принимает решение, какого масштаба нужна инфраструктура под клиента в облаке, и ее готовит

                      То есть эти 7 виртуальных машин — это именно в облаке? А цены на эти 7 виртуальных серверов одинаковые? Или там просто цены за пользователя и эти 7 машин — это просто справочная информация?

                      Кстати, я могу попробовать прогнать наш чек-лист через эту утилиту и поделиться результатом.

                      Было бы очень интересно.
                        0

                        Цены только за пользователей.
                        А результатами оценки сайзинга поделюсь в ближайшее время.

                          0
                          Вы знаете, обыскал весь LCS портал и не увидел для проектов Dynamics 365 on-premise утилиты Infrastrucure estimator. Оставили только Subscription estimator, куда загружается опросник для клаудных версий.
                          А Infrastructure estimator вижу только для предыдущей версии AX2012 — это не очень интересно.
                          Похоже, что для on-premise решений придется руководствоваться только этим гайдом.
                        0
                        у вас есть какой-то мониторинг по утилизации виртуальных машин? насколько эффективно они используются и нет ли смысла переити на более слабую или наоборот, более мощную виртуалку?
                          0
                          Мониторинг есть. А Вы про какие виртуалки спрашиваете: DevBoxes или продуктивную среду?
                            0
                            больше интересует прод.
                              0
                              Как я уже упоминал, мы не можем управлять сайзингом продуктивной среды, даже если видим неполную утилизацию. Стоимость этих виртуальных машин «включена» в стоимость клиентских лицензий, поэтому смысла менять сайзинг нет.
                                0
                                ясно, спасибо
                  0
                  MS странные люди, для полного цикла надо минимум 22 сервера. Так к ним еще и добавляется головная боль по обновлению всего этого. Сразу возникает желание работать в облаке. И вот тут в Европе получается фэйл — закон о персональных данных в каждой стране имеет какие-то свои особенности и работать в облаке не представляется возможным. Вы упомянули что вы вторыми в России внедрили 365, как? Без персональных данных? Или у MS появились сервера в России?
                    0
                    Как я понял вторыми, кто использует в России, но для автоматизации дочки в Германии. Наверное, поэтому больше никто в России 365 не использует, так как есть проблема с персональными данными, если использовать для российских процессов.
                      +1
                      Кстати, MS обещал плагин по работы с персональными данными, если еще не выпустил. Суть плагина состоит в том, чтобы настроенные данные, которые компания считает персональными, сначала складывать на российские сервера, и только потом сохранять в облако Azure. К сожалению, в России датацентров у MS действительно нет.
                        0
                        Пристально не следил за законодательством РФ в области персональных данных, но разве там смысл не в том, чтобы не хранить их за границей вообще? В чем тогда смысл, если они будут и там и там? Ведь чем больше мест хранения, тем больше вероятность утечки их.
                          0
                          Смысл их хранить в России и в первую очередь в России, чтобы всегда можно было произвести кхмм… «контролируемую утечку в компетентные органы».
                      +1
                      Законодательство РФ (а именно ФЗ-152) накладывает ограничение на обработку персональных данных, предписывая осуществлять сбор и актуализацию (в понятиях Роскомнадзора) таких данных на серверах, расположенных на территории РФ, а хранение — допускается на территории стран, присоединившихся к конвенции «о ПдН». В нашей реализации (Lamoda) сбор и актуализация ПдН осуществляется в on-premise информационных системах и БД, сервера которых расположены на территории РФ. В 365 используется «копии» этих данных.
                        0
                        Вижу что вы написали, но судя по тому, что «вторые в России внедрили в Германии» — как-то слабо верится то, что это именно так.
                          0
                          В 365 для Германии (то, о чем рассказывается в статье) нет вообще персональных данных граждан РФ. Там — соответствие GDPR.
                • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    «В Европе приняты трудовые законы, поэтому внедрение и разборки с законами выполняли российские специалисты».
                    Классически, по-менеджерски завуалированная издёвка над людьми, которые вкалывали по 12 часов при зарплате явно несравнимой с европейской.
                      0
                      Не так уж она и несравнима, если вычесть налоги. Я думаю никто в России с плетью над ними не стоял. При желании всегда можно сменить компанию, если заставляют работать в нерабочее время.
                      0
                      Отличная статья
                      Особенно комментарий о преимуществах облачного решения.
                      Всего 7 VM на 20 пользователей? Счастливчики.

                      А как вам локальная инфраструктура на 200 юзеров и вынесенный в облако WebShop? Даже сказать страшно Сколько VM.

                        0

                        Здание на фото, кстати, – это Rocket Internet Tower, инкубатор стартапов. Оттуда, например, происходит и немецкий аналог Lamoda – Zalando

                          0
                          Так Rocket и наша alma mater тоже. Фото из окон немецкого офиса Lamoda.
                          0
                          есть трудности с интеграцией с немецким банком

                          Можете немного подробнее рассказать в чем трудности? Это проблема конкретного банка или европейских банков в целом? Или проблема не а банке а исключительно в сроках?
                            0

                            Трудности с интеграцией связаны прежде всего с ограничениями стандартного функционала по генерации файлов для интернет-банка по международным и местным платежам, который не позволяет, например, объединять в одну платежку несколько платежей (за несколько инвойсов) с одинаковыми реквизитами, при этом корректно указывая в назначении платежа весь список исходных документов, за которые идет оплата.
                            Также была чисто техническая проблема с кодировкой создаваемых файлов — D365 генерит их в UFT-8, а интернет банк ожидает только ANSI.
                            И ещё есть заморочка с факторингом: либо мы не научились его "готовить", либо в немецкой локализации нет этого функционала.

                              0
                              Интересно. А как решаются такие технические проблемы (я про кодировку, например)? Вы обращаетесь к вендору, или сами дописываете какие-то дополнительные обработки?
                                0
                                Если в целом, то проблемы решаем самостоятельно доработками. Именно эту пока еще не решили.
                            0
                            «Российских клиентов, использующих облачное решение этой системы, почти нет (если быть точнее — мы стали вторыми), но для наших целей оно подходило лучше всего.»

                            Есть же компания Норбит, которая как раз внедряет решения от MS. Или они не к облаку делают?
                              +1

                              Норбит — далеко не единственная консалтинговая компания — партнёр Microsoft, занимающаяся внедрением ERP Microsoft. Но именно клаудную версию D365 мы запустили вторыми.

                                0
                                Не только. Есть также региональный Pkey-online. Очень сильное заявление про вторых, учитывая, что работают они с 2012.
                                  0
                                  Вы имеете в виду заявление про то, что мы второй клиент, запустивший клауд, из российских клиентов? Я консультировался в Microsoft, прежде чем публиковать это. А с 2012 мы действительно продолжаем работать, это не секрет.
                              0
                              А как делали тестирование?
                              И как планируете иметь дело с ежемесячными обновлениями данной системы?
                                0
                                Тестирование на текущий момент делаем вручную.
                                Обновления регулярно накатываем, и пока процесс нравится. Пользуемся вариантом с объединением package'а обновления с моделью собственных разработок, и единым пакетом деплоим. Тестируем обновленное приложение в SAT environment, затем выкатываем в прод.
                                Большие ожидания связаны с недавно анонсированной утилитой автоматических регрессионных тестов.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое