即使在俄罗斯，将远程分支机构的会计系统及其与父级结构的集成相结合也是一项艰巨的任务。 而且，当客户在国外时，整个项目会使在地方税法方面缺乏专业知识和心态冲突复杂化。 我的名字叫Stanislav Gotz，我是Lamoda ERP系统开发部门的负责人，在这篇文章中，我将向您介绍这种经验-有关在我们德国分支机构中实施ERP系统的经验。
我们的德国子公司购买商品并将其出售给俄罗斯法人。 其中使用的Tsenit系统仅允许在财务数据级别保存记录：谁，谁，欠多少钱，何时进行购买或出售等。 使用Tsenit工具无法进行货物和物流任务的核算；要解决这些问题，必须使用其他工具，这会对整个系统的速度和可靠性产生负面影响。 结果，数据分散在多个数据库中。
此外，德国法人实体必须提交报告，缴纳税款并通过审核-使用现有的会计系统解决此类问题并不容易。
要了解为什么在Tsenit中进行此财务交易并回答税务机关或审计师的简单问题，我不得不在Excel中手动铲除大量数据并与物流部门联系。
在某个时候，决定将会计和财务与物流结合到一个分支ERP系统的框架中的一个电路中。 作为主要软件，选择了Microsoft Dynamics 365-以前的Dynamics AX，或更容易的是Axapta。 几乎没有俄罗斯客户在使用该系统的云解决方案（更确切地说，我们成为第二个），但这最适合我们的目的。
美好未来的时间，预算和信念
我们有严格的时间限制：在一个会计年度的中期启动这样的系统需要传输整个历史数据集，这是一项不可能的任务，因为在旧系统中，实际上不存在商品核算并将其保存在电子表格中。 但是在报告期初，仅转移余额就足够了。 因此，有必要启动2019年1月1日或将其推迟一年。 与贸易和仓库物流相关的流程并不是特别复杂，在我们看来，截止日期不会有问题。
除了截止日期外，还有一个预算问题：在德国部署和维护自己的IT基础架构以及购买公司软件许可证对于每个用户来说太昂贵了。
由于不超过20个人参与德国业务流程，因此我们选择了Dynamics 365云解决方案，对于小型远程分支机构而言，SaaS方案是最佳选择，它使您能够获得所有必要的软件和开发环境，并在与提供商签订合同后立即开始实施。
Microsoft Dynamics 365许可策略非常简单，并且假定每月一个用户许可的价格固定，同时可以增加或减少用户数量。 这是选择该特定软件产品的另一个论点。
陷阱
主要问题在于技术层面之外：我们不了解欧洲法律在此类系统中保存记录的所有要求。 Microsoft Dynamics 365涵盖了大量的业务流程。 发布了所谓的本地化软件包，使您可以根据特定国家/地区的法律法规灵活地定制解决方案。 如果开发团队长期研究俄语版本，那么我们再也不会碰到德国版本了。 由您自己的团队设置这样的解决方案将是一项艰巨的任务。
德国管理层担心，由于缺乏当地税收和会计方面的经验和知识，俄罗斯方面无法应付这项任务。 结果，我们选择了中间立场并吸引了外部咨询。 本来可以弥补与欧洲法律要求相关的空白，提供对以前财务系统迁移的审核，分析业务流程的描述，对其进行优化，并使将来的解决方案能够最大程度地使用标准功能。 如果有必要，计划将其完成，从而逐步使俄罗斯团队投入发展。
开始实施和数据传输
默认情况下，我们有权使用以下三种环境：BUILD（用于将不同开发人员创建的代码组装到一个应用程序中）； SAT（标准接受测试）用于进行用户接受测试； PROD进行操作。 此外，还为Azure中的每个开发人员部署了开发箱虚拟机。 整个基础架构是通过单个门户- 生命周期服务进行管理和监视的，并且自定义过程的一个特点是，任何改进都只能通过SAT进入PROD环境。
由于选择了Microsoft Dynamics 365作为新系统，因此使用包装盒中提供的数据包相对容易实现数据传输。 Dynamics 365与Microsoft产品（包括Excel）有着密切的关系：对于用户而言，它看起来像是通过
ODATA连接到Dynamics 365服务的电子表格。 使用Excel扩展，用户可以将数据直接发布到系统。 德方准备了模板，并注意其中的必填列。 用户填写了这些模板，然后顾问控制了导入过程。
除其他外，顾问从旧的会计系统中转移了有关供应商和客户的信息，以及总分类帐帐户上的余额。 直接传输所有商品数据需要大量时间和精力，我们试图以更有效的方式解决此问题。 实施了将德国分公司的新会计系统与主要商品所在的俄罗斯主要系统进行的集成。 到年底，我们在德国没有实体收支平衡，因此，有必要从旧系统中仅转移进一步分配货物所需的背景信息。 因此，可以省去所有关于货物的历史数据的传输，从而节省了时间。
半外包：连接俄罗斯团队
自2018年6月开始实施以来，我们预计将在新年假期之前解决所有问题，但除了此类项目中的自然语言问题外，沟通困难也出现了。 长期以来，德国顾问都对查询做出了回应。 员工连续六小时不能休息。 完成工作后，他必须有至少11个小时的空闲时间。 当专家与另一个客户打交道时，他不会被问到任何事情。 这种正式的方法影响了时间。 在某个时候，承包商在新的一年中提议只启动财务会计，这在旧系统中已经起作用。 这不适合我们。 自2013年以来，我们一直在Lamoda中独立实施Axapta，并在2016年将所有会计完全从1C转移到了它。 俄罗斯的流程要复杂得多，因此我们知道该项目可以按时完成。
我们决定吸引俄罗斯团队，从德国同事那里吸取所有系统功能的定制和开发。 实际上，我们只向外部承包商提供咨询，任务设置和功能设计。 他们告诉我们需要做什么，我们做了，然后他们测试并接受了结果。 实施的速度有所提高，但是很快就需要对工作流的这种组织进行修改：这名德国财务顾问休假了三个星期。 对于项目而言，这个截止日期变得至关重要，我们的主要任务与财务，税收等紧密相关。 我也必须承担这一部分的责任，因此，我们的专家认为欧洲的税收法规并不比外部法规差很多。
加上不断有一些非标准的任务。 由于主要的俄罗斯团队沉浸在开发中，他们能够相对快速地解决它们。 此外，最初在考虑到我们公司所使用的所有系统和流程的知识的基础上开发了解决方案。
这些任务之一是将新的云环境与现有的俄罗斯ERP系统集成。 它已经实现了与购买者的工作相关的功能，并且我们不想复制代码以免使其支持复杂化。 结果，在俄罗斯ERP中创建了从国外供应商购买商品的订单，然后将其转移到德国云中。
在实施过程中，俄罗斯团队为我们掌握了全新的开发方法和新工具。 我们曾经将自己的IDE用于Axapta，但在这里我们切换到了Visual Studio和Azure DevOps。 在项目实施期间，软件版本发生了变化，我们的专家知道云环境并行开发的所有乐趣-从技术上来说，这非常有趣。
SureStep与敏捷：启动问题
来自德国的同事根据Microsoft SureStep方法进行工作。 这是一种不灵活的方法，更接近经典的“瀑布”。 它在每个阶段都涉及所有内容的文档编制，功能和技术设计的准备，对协议的发布进行严格测试，在某些建模系统中记录过程等。 要求提供此类文档的同事在发布前一个月与我们联系。 到那时，新的ERP系统已经或多或少地发挥了作用。 假设在六个月内启动它，我们选择了更灵活的开发方法：每日站立，任务讨论和每周发布。 对于文档，我们在Azure DevOps中使用了工作项，它们还反映了项目的进度并确认了测试结果。
由于该系统处于多云状态，因此由Microsoft做出最终决定是否正式发布该产品，与之进行的所有联系均由我们的承包商进行。 反过来，从SureStep方法学的角度来看，他们还没有准备好发送没有所有必要文档的应用程序。 结果，该项目的及时启动受到了威胁。
我们决定自行与供应商联系，并获得批准进入生产，然后我们平静地，系统地改进了系统的功能。 德国专家帮助我们将设置从测试环境转移到食品杂货店。 此后，如果我们有任何意见，他们将设置会计并纠正缺点。
战斗测试
由于我们自己团队的及时参与，我们设法按期完成了任务并按原计划于2019年1月1日启动了该系统。
新的会计系统将财务部分和物流结合在一起，我们已经通过了德国的季度报告。 在此之前，我们设法进行了所谓的 该月结束时没有重大损失。 在启动此类系统时，不可避免地会出现延迟，但是在一月份，我们晚了三天，而在二月份，只有一晚。 当我们从系统手动收集数据时，现在俄罗斯开发团队正在致力于报告的自动化。 这些问题主要与人为因素有关：员工难以为其执行新的程序，并且肯定会出现一些粗糙现象。
现在，我们可以清楚地看到各个仓库编号级别（SKU）上的货物以及欧洲中间仓库中的余额数据。 结束许多任务是不可能的：与一家德国银行的整合存在困难，并且由于及时解决内部团队的资源不足而存在一些小问题-最初假设承包商将关闭这条战线。 基本上，所有这些都归结为缺乏适当的自动化水平，并且最终用户的手工工作量有所增加。 现在，我们正在逐步利用团队力量并在俄罗斯分公司的新合作伙伴的帮助下缩小差距。
我们的开发人员为该项目工作的好处还在于，在实施阶段立即进行了改进，以改善系统的功能。
俄罗斯团队已开发出针对买卖订单的自动税务确定功能。 默认情况下，系统要求会计师在处理发票和过帐交易记录时手动设置税制。 在这种情况下，无论货物是直接从供应商那里运到俄罗斯还是货物在欧洲进行了整合，都必须考虑到装运国，供应商的注册国，提货人（收件人或供应商），将货物发送到俄罗斯联邦（德国或俄罗斯法人）。 每次交付会计都没有所有这些细微之处。 我们使系统中的过程完全自动化，以便负责的物流提供者引入必要的初始参数。 此外，系统根据创建的设置本身确定税收方案和必要的会计分录。 所有数据都会自动合并到德国和纳税申报单所需的统计报告中。 因此，可以更好地在专家之间分配职责，从而提高了工作速度和可靠性。
总结
最初，我们希望大部分工作都落在承包商身上，因此，所有关键要素都是我们自己开发的。 通常，ERP的启动需要1年的时间，但是我们成功地在项目启动后的6个月内启动，而积极的开发仅持续了3个月。
结果，我们获得了独特的体验，我们决定分享。 与了解当地情况的外国承包商进行合作是切实可行的，但您不应指望它们会带来奇迹。 如果您有
自己的强大团队 ，则应该仅将咨询，任务设置以及测试外包。
这还不是我们故事的结局。 俄罗斯引入了统一的商品标记国家制度，这是一个新的挑战。 立法者将其发布日期推迟到2020年，但是从7月开始，我们希望在通过海关之前在每双鞋子上标上唯一的条形码。 另外，总是存在与优化性能有关的任务。 好吧，还有许多其他想法和计划。 在实施这些技术时，我们现在将更多地依靠我们自己的优势，为此，我们首先必须稍微“发胖”。