从一个ERP系统迁移到另一个

通常，公司向新的ERP系统过渡并不会停止购买和完成的财务费用，而是需要从旧系统迁移。 他们有成百上千的用户，他们在一个程序中执行其业务流程，因此需要将他们全部转移到另一个程序中，而业务不会因此停下来。

近年来，我们已经走了几十次，而且我们已经开发出了最轻松的方法来做到这一点。

难点

野牛以他的存在向您的村庄表示敬意的那一天，对您而言，成为生活中最重要的事情。 但是对我来说是星期二。
-街头霸王贝森

客户的许多特别令人印象深刻的员工第一次处于恐慌状态，因此过渡过程通常很复杂，因为对于他们而言，这很可能是他们职业生涯中的第一次迁移。 对我们来说，这是一个普通事件，通常，它是根据同一场景发生的。

当任何人将一种产品交换为另一种产品时，他注意到的第一件事是他被带走了，还没有意识到他收到了什么。 因此，通常的第一反应是：“你在我这里溜了什么胡话-照原样做。” 在实践中，我们遇到一种情况，一个用户抱怨他对新操作不满意，该新操作是在旧系统中通过表单之间的五个转换完成的。 但是他完美地做到了自动化，以至于对于一个人来说，起初确实比做两个新的但更简单的动作要快。

另一个困难是，在过渡期间，客户喜欢将业务流程更改为他们的愿景。 应当谨慎对待这一点，因为可以保证当前的“原样”流程能够正常工作。 通常，嵌入到产品中的流程也可以正常工作，因为它们被其他客户使用。 但是从理论上讲，新发明可能看起来很漂亮，但在实践中，它们会遇到麻烦，因此整个过程可能会停滞不前。

情境

实际上，从一个系统迁移到另一个系统有两种主要方案：

瞬间

确定过渡到新系统的日期。 开发所有功能都是为了从旧系统中卸载数据并将其加载到新系统中。 在第X天，迁移从晚上开始，到早上，所有具有所有业务流程的用户将开始以新方式在新系统中工作。

纸上的一切都是美丽的。 但实际上至少有四类问题：

1. 培训 。 通常，在过渡时，许多训练有素的用户完全忘记了他们所教的内容。 他们开始戳戳一切，结果他们以“无所作为”停止工作。 目前可以在第一线支持人员的帮助下解决此问题。 但是，在转职的第一天会有如此多的请求，以至于无法利用可用的员工数量来满足他们的要求。 或者，您需要有一种方法可以在传输过程中快速扩展其数量，这也很难做到。
2. 改进和错误 。 通常，新的ERP系统会带来新的业务流程（否则为什么要更改它）。 显然，在实施之前就将它们以某种方式赶走了，但是在真正的“战斗检查”时，通常会产生大量的细微差别，因此通常无法执行流程。 因此，具有紧迫优先级的这种改进的数量再次像滚雪球一样增长，并且对物理上将无法关闭这种数量的请求的程序员资源提出了迫切的需求。
3. 数据 。 通常，旧系统的开发人员并不热衷于帮助上传数据（对他们来说，这通常是失去客户的不幸事件），如果他们帮助，那么上传的质量将有很多不足之处。 通常，在新系统运行的第一天就会发现不一致之处。 结果，需要考虑到操作期间已更改的情况，更正卸载，并以某种方式重新加载数据。
4. 表现 。 在测试过程中，要在系统上重现完全“真实”的负载并非易事。 如果产品的基本功能通常已经过测试并显示正常的性能参数，则在某些情况下，对客户端的“个人”改进可以“坐下”服务器。 反过来，这也需要程序员资源进行优化。

当所有这四个问题同时发生在转换的第一天或一周时，那么就无法避免业务损失。 因此，这种方案仅在小型项目上有效。 例如，当用户数少于一百并且过程不是关键时。

显然，您可以在过渡之前立即花更多的资源来培训和测试系统，这样就可以减少问题。 但是在生活中，客户的员工通常会“无袖”地提及这些流程，而依赖于“也许”。 或他们只是错误地认为，期望某个过程将能够在某个环境中赚钱，但实际上，细微差别似乎会削减一切。

渐进的

通过这种方法，可以将系统水平 （按过程）或垂直 （按用户）划分为多个部分，然后依次介绍这些部分。 这使您可以及时散布所有上述问题，并在它们收到较少功率的情况下加以解决。

由于我们专门从事零售行业，因此我将进一步描述基于开放和免费的lsFusion平台的ERP迁移过程，该平台用于商店的零售链。 但是我们将相同的原则应用于其他领域的客户。

资料读取

通常，对于支持旧系统的公司而言，更换程序并失去客户的消息是很大的打击。 有些陷入不适当的状态，并立即停止支持以威胁客户。 自然，这永远不会奏效，也永远不会推翻决定。 但是，很少有人会支持那些支持旧系统的人，即他们提供存储过渡所需的所有数据的表。

首先，您需要确定必要的信息存储在哪个DBMS中以及如何访问它。 在过去的几年中，我们不得不处理以下与旧系统兼容的DBMS：

• 访问权限 由于平台是用Java编写的，因此有可能挖掘出一个古老的库，该库知道如何连接到mdb（尽管仅供阅读）。 它的工作非常特别，因为尽管使用了过滤器，但它可以读取整个表，但是足够了。 我们很幸运，客户的IT服务非常了解数据库结构，并告诉我们存储的内容和位置。
• MS SQL 旧系统是Axapta 2000s。 我们设置了对测试系统的访问权限，并在其中启动了GUI和SQL Profiler。 然后，我们轮流进入目录，并查看Axapta生成的请求。 从他们那里很容易理解这些信息的确切存储位置。
• 视觉Foxpro 这很简单，因为从我们的旧系统开始过渡了，获取信息并不难。 唯一的困难是找到一个不能与DBASE表一起使用但与Visual Foxpro格式一起使用的Java库。
• 甲骨文 从supermag盒装程序过渡。 我们根据类似于Axapta方案的方案进行工作：GUI和SQL Developer中的查询以获取最新查询。 那里的基本结构和接口肯定比Axapta中的简单得多，因此没有大的问题。
• 进度/ OpenEdge 。 从盒装的Gestori程序过渡。 鉴于DBMS一点也不受欢迎，因此我们没有找到任何分析器。 但是，文本文件中存在转储。 这样就可以简单地进入测试服务器的GUI并搜索文本文件以搜索屏幕上可见的数据。 幸运的是，在此DBMS的官方网站上，有机会下载JDBC驱动程序，并对SQL数据库进行查询。 那是技术问题。

由于采用了这些方法，因此我不必再求助于旧系统的开发人员，因为这通常可以为合作节省大量资金，因此大大节省了客户的支出。

主数据

这一切都始于导入主数据。 特别是对于零售贸易，首先要实现商品组，商品，承包商和商店的目录的导入。 通过逐步过渡，可以采用两种方法导入主数据：

• 一次性导入数据，然后再次输入新旧系统。
• 从旧系统到新系统的连续增量数据更新。

在某些情况下，会使用第一种方法，但这种方法过于耗时，并且极易受到人为因素的影响而出现错误的可能性。 因此，我们始终仅使用第二个选项。

理想情况下，旧系统可以累积更改并以某种方式传达需要重新导入的信息。 但是通常没有人会更改或修改旧系统中的任何内容。 因此，我们使用的唯一工作方案如下：

1. 对旧系统的目录有一个请求，该目录从中读取所有数据。
2. 将读取的数据与新系统中的电流进行比较，并检测到更改。
3. 更改将在单个事务中写入新系统。

平台上用于导入产品目录的代码如下所示：

它的工作方式如下：

• READ会考虑整个目录以及内存中的代码和名称
• IMPORT会将所有数据写入本地属性（即数据库中的临时表）
• 第一个周期将创建新数据库中尚未存在的所有商品（按产品代码搜索）。 尽管已在其中写入FOR ，但它会编译为对数据库的一个查询，该查询仅适用于临时表。
• 第二个周期将更新所有产品（包括新创建的产品）的字段。 在这种情况下，仅更改的值将被写入临时表。
• 第三个操作DELETE检测到新数据库中的所有商品，但未检测到读取数据中的所有商品，并将删除它们。
• APPLY将启动事务，并根据先前命令生成的临时表将所有更改写入数据库。

实际上，启动时的此操作将完全同步旧目录和新目录。 它不存储任何增量信息，因此即使先前的交换因错误而完成，也可以随时重新启动。

由于所有操作都无需任何迭代即可编译到SQL查询中，因此所有操作都可以相当快速，安全地完成。 通常，交换100-200,000条记录的商品目录需要花费几分钟。 同时，由于PostgreSQL已版本化，因此此时不会阻止用户工作。
同样，供应商的价格，分类矩阵，订单计划和其他工作所需的信息也始终保持同步。 但是，这里可能会出现一个问题，即旧系统中的域逻辑与新域逻辑不一致。 例如，在我们的系统中，我们具有矩阵版本的历史记录以及矩阵内部产品级别的概念。 如果在旧系统中，当前的商店分类是作为商店和商品的布尔值平放存储的，那么将为每个商店创建一个矩阵，且每个矩阵只有一个级别。

大多数情况下，我们使该操作每小时将所有目录与旧系统同步一次，同时为用户提供了手动启动交换的机会。

过程

在零售业中，我们通常在商店之间垂直划分翻译过程，同时在商店过程和办公室过程中同时划分翻译过程。

第一步是选择将开始向新系统转移的商店。 以传入文档的形式从旧系统中导入当前余额和存储价格，并带有相应的数量和价格：


在商店开始前几周，已连接从POS系统导入的实施。 这是必要的，以便在工作的第一天就有用于形成订单的历史数据。

通常，自己生产的过程要比主要过程晚一些。 在这种情况下，将有关原材料移动和从那里进口成品的文件卸载到旧系统中。

在转移当天，导入从晚上开始，然后将客户支持人员和我们的第一条支持热线发送到商店。 它们可以帮助用户开始使用新系统，而无需进行预培训。 在这种情况下，通常会在一段时间内，由于人们输入错误，旧系统中的文档更改无法关闭，因此他们需要能够更正错误。 几周后，将残余物重新导入，然后已经禁止旧系统的更改。

在第一家商店中识别并解决了上述所有问题之后，大约两周后，又转移了2-3家商店。 再次发现并修复问题。 然后，根据客户的客户支持服务的资源，非常快速地翻译所有其他内容。 一直以来，主数据继续输入到旧系统中，因此存储可以在旧系统上运行。

然后，当所有存储转移后，要么逐渐关闭要么全部关闭从旧系统的导入，用户开始将主数据输入新系统。

来自旧系统和新系统的摘要信息可以通过记帐或BI系统获取，在这两个系统中同时上传。 您可以在其中获得该间隔的摘要报告，其中包括旧系统和新系统中的时间。

结论

尽管从一个系统过渡到另一个系统表面上看起来很复杂，走了几十遍，但您了解到，使用调试方案，实际上并不是那么可怕。 由于大多数客户的雇员都相当保守，并且至少有一点机会要求按“原样”做事，因此出现了更多问题。 在这里，非常重要的一点是，客户要有足够的权限，可以比较旧的和新的流程，确定哪个流程最优化并能够“破坏”员工。 或者，如果结果相反，则按照“原样”方案修改流程。