Объединение учетных систем удаленного филиала и их интеграция с головной структурой — задача достаточно непростая даже в пределах России. А когда заказчик находится за рубежом, весь проект может усложнить отсутствие экспертизы в местном налоговом законодательстве и конфликт менталитетов. Меня зовут Станислав Гоц, я руковожу отделом разработки ERP-систем Lamoda и в этом посте расскажу вам как раз о таком опыте — о внедрении ERP-системы в нашем немецком филиале.
Наш филиал в Германии закупает товары и продает их российскому юридическому лицу. Использовавшаяся в нем система Tsenit позволяла вести учет только на уровне финансовых данных: кто, кому и сколько должен денег, когда прошла покупка или продажа и т.д. Учет товара и логистические задачи средствами Tsenit было выполнять невозможно, для решения этих задач приходилось использовать дополнительные инструменты, что отрицательно влияло на скорость и надежность всей системы. Данные в результате были разбросаны по нескольким базам.
К тому же немецкое юрлицо должно сдавать отчетность, платить налоги и проходить аудиторские проверки — а с существовавшими системами учета решать подобные задачи было непросто.
Чтобы понять, почему в Tsenit были сделаны те или иные финансовые проводки, и ответить на простые вопросы налоговых служб или аудиторов, приходилось вручную лопатить огромные объемы данных в Excel и обращаться в отдел логистики.
В какой-то момент было решено объединить бухгалтерию и финансы с логистикой в единый контур в рамках одной ERP-системы филиала. В качестве основного программного обеспечения была выбрана Microsoft Dynamics 365 — бывшая Dynamics AX, или еще проще — Axapta. Российских клиентов, использующих облачное решение этой системы, почти нет (если быть точнее — мы стали вторыми), но для наших целей оно подходило лучше всего.
Сроки, бюджет и вера в светлое будущее
У нас были жесткие ограничения по срокам: запуск подобной системы в середине финансового года требует переноса всего набора исторических данных, что стало бы неподъемной задачей, ведь в старой системе товарный учет фактически отсутствовал и велся в электронных таблицах. Зато в начале отчетного периода достаточно перенести только балансы. Таким образом, запуск необходимо было произвести либо 1 января 2019 года, либо отложить его еще на год. Связанные с торговлей и складской логистикой процессы не особенно сложные, и нам казалось, что проблем со сроками не возникнет.
Кроме сроков был еще вопрос бюджета: разворачивать и обслуживать в Германии собственную ИТ-инфраструктуру и покупать корпоративные программные лицензии слишком дорого в пересчете на одного пользователя.
Поскольку в немецких бизнес-процессах участвует не более 20 человек, мы остановились на облачном решении Dynamics 365. Для небольших удаленных филиалов схема SaaS оптимальна, она позволяет получить все необходимое ПО и среды разработки, чтобы начать внедрение сразу после подписания договора с провайдером.
Политика лицензирования Microsoft Dynamics 365 предельно проста и предполагает фиксированную стоимость за одну пользовательскую лицензию в месяц, при этом количество пользователей можно увеличивать или уменьшать. Это стало еще одним аргументом за выбор именно этого программного продукта.
Подводные камни
Главная проблема лежала вне технической плоскости: мы не знали всех требований европейского законодательства к ведению учета в подобных системах. Microsoft Dynamics 365 охватывает огромное количество бизнес-процессов; выпускаются так называемые пакеты локализации, которые позволяют гибко настраивать решение под специфику законодательства конкретной страны. Если российскую версию команда разработки давно изучила, то с версией для Германии мы никогда не сталкивались. Настройка такого решения силами собственной команды стала бы трудновыполнимой задачей.
У немецкого менеджмента были опасения, что российская сторона не справится с поставленной задачей из-за отсутствия опыта и знаний в локальном налоговом и бухгалтерском учете. В итоге выбрали золотую середину и привлекли внешний консалтинг. Он должен был закрыть связанные с европейскими законодательными требованиями пробелы, обеспечить аудит миграции из предыдущей финансовой системы, проанализировать описания бизнес-процессов, оптимизировать их и подогнать под будущее решение с максимальным использованием стандартной функциональности. При необходимости доделок их планировалось выполнить, постепенно погружая российскую команду в разработку.
Начало внедрения и перенос данных
По-умолчанию мы получили права на три среды: 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 год, но мы хотим уже с июля маркировать каждую пару обуви уникальным штрих-кодом до прохождения товаром таможни. Помимо этого всегда есть связанные с оптимизацией производительности задачи. Ну и прочих идей и планов у нас предостаточно. При их реализации мы теперь будем больше полагаться на свои силы, для чего сначала придется немного «растолстеть».
Автор: sgots
