随着数字化转型成为热议话题，我们在各种场合都能听到关于它的讨论。然而，关于数字化转型的探讨往往聚焦于政策、概念和价值等宏观层面，而忽略了实践中的具体问题。本文旨在从自身实践角度出发，总结和探讨企业在数字化过程中遇到的问题。

经历过几个大型项目的实施和建设，但是因为时间原因并没有进行过整体复盘，本文即是对自己经历的复盘，也可以通过复盘梳理在系统实施中遇到的问题和自身的得失。这里要说明下，ERP并不代表数字化，这两者之间不能划等号。但是ERP系统是企业数字化建设中重要的组成部分，是企业数字化过程中的重要工具，所以这即是实施系统过程中的总结，也是针对企业数字化实践过程中的总结。

因为ERP系统搭建或信息化建设是一个很庞大的项目，所以为了方便理解，本文会按照系统建设的步骤来划分章节。

什么是ERP?

• ERP的全称是企业资源计划，是一种思想理念；ERP系统是企业资源管理系统，是实现ERP理念的实体；但在日常语境下erp和erp系统并不需要进行区分，做到看资料、读文章而不疑惑即可。
• ERP系统是从MRP（物料需求计划）演化而来的，最初是服务于生产制造企业的，随着信息技术的不断发展，erp系统逐渐应用在更多的行业与领域。因为历史原因，进销存系统是在ERP系统之前就被公司使用的系统，所以有时我们会将ERP系统称为进销存系统，但是我们作为产品要清楚的知道，进销存系统并不能指代ERP。
• ERP系统就是对企业经营中三流（物流、资金流、信息流）的集成管理的系统，包含企业经营过程中的各个方面；包括但不限于：采购管理、物料管理、车间管理、库存管理、人力资源管理、财务管理等。

一、计划阶段

1.1 为什么要做

当企业人员越来越多、业务越来越多的时候，管理层是不能够清晰知道员工实际情况的，只能通过业务负责人提供的报表来了解企业经营状态。而且汇报层级越长，信息在传达过程就越容易失真，如同供应链中的“牛鞭效应”。因为需求信息无法有效无误的传递，导致信息在传递过程中逐渐失真。这也导致管理层制定的规则并不能合理的覆盖到所有人，也不能根据执行情况及时对规则做调整。

对于一些岗位如销售、维修技师等，因为他们的工作就需要直接于客户接触，且公司制度也不能完全涉及到每个方面，所以就有机会通过岗位特点获取不当利益的，而且越是信息不透明越是方便通过信息差获取不当利益。

所以公司就需要借助企业数字化的方式，磨平管理过程中遇到的阻碍，而erp是企业数字化的重要工具，所以就会有自建系统或购买系统的理由，希望能够通过系统实现降本增效、提高公司管理层对公司的掌控力（也包括通过数字化这个理由对人员精简及权利回收）。

1.2 希望实现的目标

无论是购买系统还是自研系统，系统本身肯定不是目的，而是希望通过系统达到的某个可量化的目标。注意，这个目标一定是企业数字化后希望达成的目标，而且这个目标是可以量化的。例如希望系统上线后可以提升多少效率、节省多少人力时间、相比旧系统提升了多少效率等。

因为传统企业并不能够真正了解企业数字化的价值，对系统的唯一认知就是可以在电脑、手机上实时看到业务数据。这就导致企业在评估软件价值、财务汇报的时候，只看到了公司对其的持续投入。

而且在传统企业眼中，销售部门是用来挣钱的，而产研部门一直是个销金窟，并不能带来直接经济价值也就算了，还不能通过简单的成本控制或者人力的增加获得改善。长期的投入就会导致产研部门会受到非议，对于股份制公司来说，产研部门的长期投入直接影响到了年底分红，所以就会导致软件实施过程中部门之间配合效率下降、配合意愿降低。

因此这个目标一定是公司内部的共识，如果是产研部门内部制定而没有业务人员的参与，就导致这个目标成了产研部门的一厢情愿了。例如实现销售人员收款交付流程的效率提升，那么实现这个目标就需要优化整个交付流程，而销售人员极有可能可以通过原来的流程获取到原本不属于自己的东西，这可以是权利也可以是利益。

只要影响到了业务人员的蛋糕，那么就很难将系统推进下去。

所以在建设之初，我们就需要制定一个目标，这个目标既可以引领软件实现的方向，也可以通过目标来体现软件带来的价值，另外也可以通过大家的共识免除在推动系统过程中的不必要麻烦。

1.3 从何处入手

在数字化转型的旅程中，企业面临着两种主要的路径选择：一是从小处着手，逐步推进；二是全面布局，一次成型。

首先，从小处着手的方式，选择那些独立性强、与其他业务耦合度低、且重复劳动密集的业务线或功能开始，如客服系统、数据分析模块或OA系统。这种方式具有以下优点：

• 实现难度低：由于这些功能与其他业务没有直接关联，因此在实施过程中不会引发跨部门的沟通与协作难题，系统的上线过程也更加迅速。
• 成本可控：初期投入较小，企业可以根据自身的财务状况逐步增加投入，避免了一次性大规模投入带来的资金压力。
• 风险小：小功能通常较为简单，开发和实施的难度相对较低，即便遇到问题也易于调整和优化。
• 见效快：通过率先实现一些关键的小功能，企业能够迅速看到数字化转型带来的效果，增强进一步推进数字化的信心。

然而，这种方式也有其不足之处：

• 整体规划不足：由于前期侧重于小规模功能的实现，可能会导致缺乏整体规划，在后续迭代中因基础架构不足而需进行重构。
• 系统整合难度大：随着小功能的不断增加，系统之间的整合和协调难度也会随之加大，可能引发信息孤岛和流程不畅的问题。

其次，另一种方式是搭建一整套系统，这种策略具有以下优势：

• 整体规划清晰：在构建整套系统之前，会进行全面的需求分析和规划，确保系统能够满足企业的整体业务需求。
• 系统整合度高：整套系统内部各个模块之间紧密集成，信息流通顺畅，避免了信息孤岛和流程不畅的问题。
• 用户体验一致：整套系统通常采用统一的设计规范和界面风格，使得用户体验更加一致和友好。
• 扩展性强：由于具有整体规划，整套系统在后续扩展和升级时更加灵活和方便。

当然，这种方法同样伴随着一定的挑战：

• 初期投入大：构建整套系统需要较大的初期投入，包括硬件、软件、人力等方面的成本。
• 实施周期长：整套系统的搭建和实施过程较为复杂，需要较长的时间来完成。
• 风险较高：由于整套系统涉及多个模块和复杂的业务流程，因此风险也相对较高，一旦某个环节出现问题，可能会影响整个系统的正常运行。

所以，企业在做数字化时没有固定的路径，需要根据自身的实际情况和发展阶段，选择适合自己的方式。

1.4 自研前的调研准备

在做之前我们需要全面了解公司内部的部门划分和公司管理风格，因为“系统只是工具”。系统是不能弥补管理上的缺失的，很多传统企业管理者认为只要上线了系统，就能让公司焕然一新变成了拥有数字化能力的公司，这实际是并没有理解企业数字化或者只是把本应不属于产研部门的工作强行加到了产研部门身上。

技术的先进性并不能弥补管理上的缺失，如果现有管理就不规范，系统就无法开发，系统是稳定的管理方式的体现，系统是在满足现有标准流程的基础之上去分析现有状况的，这样才能发挥出系统的价值。

通过系统来重新梳理规范时，也容易出现一厢情愿的情况，因为公司高层长时间的脱离一线，导致对一线的工作情况并不了解，虽然有规范，但一线人员往往并不能百分百的按照标准执行，而标准是否严格执行也不会体现到短期营收上去，而高层只能通过营收数字来分析指导工作，接着就导致了信息不对称,就算下达强硬的措施也只能造成阴奉阳违。

在不能够真正了解一线的情况下，部门主管在指导功能流程时还会提出自己的想法，希望通过系统再次将流程标准化。这就会导致流程与业务的不匹配，造成开发出来的流程与实际业务差距很大，而自研之前就应该需要充分的了解公司的实际情况，而不是为了标准而标准、为了规范而规范，使用才是第一步。

另外我们也需要知道当前已经使用了哪些系统，以及系统是通过什么逻辑诠释业务的。举个例子：退货是订单中很常见的业务，常规的做法是当用户发起退货操作的时候，根据订单生成仓储系统的退货入库单，当仓管入库后，再根据退货入库单生成财务单据。当时公司当时使用的金蝶系统是在原有的销售出库单上推式生成新的采购入库单，直接在原有的采购入库单上进行修改。

通过这个例子，我们就能够很直观的感受到业务的实际流程和系统诠释后的流程。有系统和没有系统这是两回事，我们可以理解公司所有业务都有一个最优的流程和方案，如果之前已经有系统诠释了公司的业务，那么势必会影响到我们自身对于业务的理解，也影响到业务人员对于系统的操作习惯。

二、调研阶段

2.1 线下需求调研

做大型系统或系统关联多岗位时，可以根据业务线为突破口。采用头脑风暴的形式，每接触一个岗位就将该岗位的所有职责都记录下来，在记录职责时不需要关心哪些内容可以做到系统上，因为记录职责的目的是为了让我们更了解业务人员所需要做的事情。

业务线这三个字每个人理解是不同的，甚至在业务领导那就没有业务线的概念，但是他们清楚的知道自己的职责以及部门职责，这种方式的好处就是可以避免因只关注业务线而产生遗漏。在记录职责的时候也尽量精简，“动词+名词+部分解释”就足够记录每个岗位要做的事情了（见下图）。

而且在调研时，哪怕语音和视频会议沟通的再清楚，也都需要线下面对面调研。调研时一定要去线下，语音或者视频会议沟通的再清楚，都不如线下沟通。

比如有次去线下调研 ，维修车间和前台有一墙之隔，技师经常来回跑，我就问为啥不弄一个对讲机？业务说之前弄过，但是因为门店旁边有很多饭店，用对讲机的时候经常遇到串频道的情况。这边刚问车修好了没，结果那边传过来：5号桌的菜已经好了。如果不是线下调研，这种情况我相信产品永远无法获取到，只是沉浸在自己的逻辑世界里。

2.2 业务建模

调研结束后，我们可以将调研结果通过岗位职责脑图、用例图、业务流程图来体现。如果业务线的流程过长且涉及多个部门，那么可以根据领域驱动设计的理论，通过拆分领域的方式将一个大的业务线拆分成多个子业务，针对每一个子业务单独分析。这里需要注意，这些子业务可能并不是真实存在的，而是根据对业务的了解和对产品架构的理解人为划分的。

以整车的维修为例，可以根据职责相似度和业务场景可以将其拆分为：服务顾问接待客户、维修技师维修车辆、仓管员出库配件、客户付款这四个子业务（可见下图的服务顾问接待客户的业务）。

1）业务用例图

2）业务流程图

在“服务顾问接待客户”业务中，我们需要详细了解到每一个步骤是如何完成的，如果有纸质单据，纸质单据是什么格式；如果需要做电子单据，那么电子单据的签字是否能够用电子签名完成；进店的客户是不是车主，不是车主怎么处理；客户以什么形式进行付款，是否使用了积分、券等一些列细节问题。

通过上述问题，我们就应该可以知道拆分成子业务的好处了。它能够更深刻的理解业务中的每一个环节，在功能设计的时候也可以更清晰的认知到功能谁在用，使用者的场景和痛点。

我们当然可以将一整条业务线全都体现出来，这样能体现出业务的流向和了解业务整体，但是这样会导致信息太多，让我们忽略掉一些细节。如果想要了解整个业务流程，可以单独绘制一张独立且完整的业务流程图。

2.3 调研结果需达成共识

相比于上述的调研产出，最最重要的就是调研结果能否达成共识。

再重复一遍，调研产出固然重要，但更重要的是调研结果能否达成共识。

每一次产出都应向业务人员确认，并且需要获得各业务部门领导及部分基层人员的认可。一线人员通常更接近实际工作环境，对具体操作过程中的问题有着更深入的理解；而管理层则更多地关注整体战略规划和流程优化，其视角更为宏观。因此，我们不仅需要管理层的确认，还需要与一线人员共同探讨流程的可行性。

如果不进行充分的确认，很容易因为沟通不到位而产生返工的情况，让产品夹在中间无法顺利推进工作。

三、设计研发阶段

3.1 系统建模

复杂系统的在实现之初，都是从很简单的功能开始的。但是随着功能的增加、代码数量增加、结构的变更的原因，逐步变得复杂且不可控。所以我们需要借助“理念”“工具”的力量来避免系统走向混乱。

领域驱动设计（简称DDD）就是应对复杂系统很有效的方法，DDD的核心目的就是利用各种方法、技巧和工具提炼出问题本质的领域模型，将大系统拆分为子模块，通过这种方式降低“单体架构”因功能变多、需求变多、数据变多而产生了过多的复杂性。并且为了避免系统的过度设计、设计不足，为系统留下的技术债，我们需要重视调研和产品规划。

系统建模的关注点在于划分系统与外界的职责，系统能做什么、外界的反馈是什么。软件系统就如同现实世界的映射，通过系统建模将现实世界中出现的实体映射到软件中。在线下调研时，我们已经得知了企业所有岗位、每个岗位所作的工作、拆分了业务线，那么下一步就需要根据现实世界去分析系统。

1）功能用例图

系统用例图可以在业务用例图的基础上进行修改。我采用的方法是在业务用例图上将可以通过系统完成的工作标红。这样既能节省重新画图的时间，也能清晰地界定业务和系统的边界，明确哪些工作由系统完成，哪些不由系统处理。如果系统在某个环节出现问题，可以通过用例分析出是系统的问题还是使用者的问题。

2）实体关系图

实体关系图（ER图或ERD图）是将业务需求转化为系统设计过程中的重要工具。它可以帮助产品经理将业务流程转化为具体的数据结构，让我们能够更好地理解各数据实体之间的逻辑关系。并且实体关系图还能为团队成员提供了一种共同的语言和框架，让产品和技术在相同的语境下沟通。

虽然产品经理并不需要会写代码，但是我们仍然需要了解系统的数据结构，这种理解可以为后续的系统规划、业务逻辑的实现以及数据分析奠定基础。

3.2 需求文档产出

上一步我们已经清晰的知道系统需要完成哪些工作，下一步就需要产出原型和需求文档了，在产出原型和文档时需要注意以下几点。

1）名词命名要统一

例如业务这个词，我们可以理解成“业务人员”，也可以理解成“业务流程”。因为有这种情况的产生，所以我们就需要统一命名规范，需要统一命名的不止是软件中的常用字段，也包括业务人员常用的名词，避免使用同义词或者类似的表达方式，导致理解上的混淆。

我们可以制定一套明确的命名规范，在整个团队中推广使用，命名规范里包括名词、名词含义。

2）保障输入信息的正确性

业务人员在使用系统的时候，经常会填错信息，甚至会出现单据已经提交财务且财务已经审核通过了，此时业务人员要求回退单据，如果出现这种情况，我们如何处理？这就要求系统拥有纠错机制机制、防呆机制、逆向流程，确保员工录入信息的正确性。

在设计功能时，我们需要考虑到无论业务操作到了那一步，我们都可以帮助业务人员将错误信息改正。但是我们要注意，所有的数据改正都是建立在现实世界中的，我们不能去处理现实世界中根本不存在的错误。

通过实际例子，我们应该能更好的理解为什么要保证数据的正确性：

• 服务顾问创建单据，已经将单据指派给主修人了，发现车辆VIN填错了，，此时如何处理？

这种错误我们可以设置VIN的格式，如果与VIN的格式不符，那么就无法提交；如果格式填写正确但内容错误，这种情况就可以将单据撤销回创建的状态进行车辆信息的修改；如果状态已经无法回退了，那么就可以通过修改功能，将新的信息覆盖旧的信息，并保留旧的数据以作记录。

• 服务顾问创建单据后，客户因为紧急事情需要离店，此时如何处理？

前面我们说了，系统是现实世界的映射，我们可以根据业务实际的情况来解决软件搭建的难题。如果车辆还没有进入维修（创建状态），那么我们可以作废单据；如果车辆已经在维修了，但是还并没有拆解车，我们可以通过单据回退的方式，将单据回退至创建状态再进行作废单据。如果车辆已经拆解了某些配件，我们就无法进行处理了，这并不是系统不支持而是实际业务场景不支持。

3）避免过度设计

B端产品在设计时需要重视“易用性”，要尽力避免过度设计，组件库有的样式就直接沿用组件库的样式就好了，没必要绞尽脑汁去实现一个不一样的交互和展示形式。因为实际用户可能学历不高、不太会用电脑、年龄较大等等，这些因素都影响原型的实现。

在设计B端产品时，应高度重视“易用性”，尽量避免过度设计。组件库可以提供的样式，可以直接沿用，没必要绞尽脑汁去实现一个不一样的交互和展示形式，毕竟产品的价值不在于交互的新颖、设计的创新。而且考虑到实际用户可能学历不高、不熟悉电脑操作或年龄较大，我们还需要将页面设计的“丑”一些，例如：加粗的文字、明显的按钮。

常用的组件库包括：Ant Design、Vant、Element。

4）不要过于迷信技术

科学技术是第一生产力，但不能狭隘的就认为新技术就是好的。要辩证的去看待技术，不能陷入到产研团队的自嗨。在某些特定情境下，技术的应用并非取决于其先进与否，而是受制于更为基本的因素——人力成本。

例如，RFID技术作为一种高效的数据采集手段，能够提升供应链管理的效率，但并不代表有仓储业务的企业就会去用RFID。并非因为技术有缺陷，而是用人力比用这些新技术更省钱。

以小仓库（50㎡）为例，无论是否应用RFID，总归是需要一个仓管员来负责的，而且RFID的标签不是凭空出现在物料上的，还需要花费时间将标签贴到物料上，应用新技术除了多花钱之外没有节省任何时间，只不过是将出库的时间花费在了贴标签上。

3.3 业务负责人及一线人员确认

产出原型、需求文档之后，先不要着急去开发，而是需要与业务人员进行确认。因为软件毕竟是员工使用的，所以我们就需要不断的去和员工进行沟通，向他们询问对于系统设计的建议与合理性。与调研结果的确认类似，即需要与一线人员确认也需要与对应管理层确认。

以上面的流程为例，我们可以向部门负责人（售前部门领导）去确认流程的合理性。如果流程是合理的，可以让领导去根据区域、门店、经营等情况，推荐几个一线业务人员，再向他们确认功能流程和页面交互。与一线业务人员确认的时候需要注意，最好不要和业务领导一块确认，免得因为领导在场而不敢主动发言，提不出自己的意见。

3.4 需求评审

如果部门领导以及一线员工都认为没有问题之后，我们就需要进入到需求评审阶段了。

需求评审的核心就是PRD文档，所以一份好的PRD文档非常重要。什么是好的PRD文档呢？那就是结构清晰。结合前面的业务建模、系统建模，我们就可以将其结合到PRD文档中。

通过业务建模让团队对业务有个清晰的认识，再通过系统建模让同事知道系统逻辑是什么样的，再去根据系统建模去讲解对应的原型页面。这样就可以让我们的团队从业务到系统都有了一个全面的认知，统一认知之后，就能保障技术同学能够在了解业务的基础之上去提问，避免技术同学频繁去反驳产品方案的合理性，导致整个会议都是在与技术同学的争执中度过。

在需求评审时需要注意，我们一定要做好会议纪要。就像上面提到的，需求评审不可避免的会与技术产生争执，有时会议上争论很激烈，但是争论来争论去，就会越来越远离会议目的的，成了为了争论而争论。所以为了避免这种情况的产生，如果遇到会议上不能立刻产生解决方案的问题，那就先做记录等会后解决。

有争执先记录，等第二次需求评审就可以直接针对上次的遗留问题做评审。

3.5 测试验收

在需求评审通过并完成开发工作后，接下来的关键步骤是测试验收。这一阶段确保软件满足功能需求，同时也能在实际使用场景下满足业务使用。

测试验时要注意下面三点:

• 压力测试：我们可以根据企业员工数量，来调节和确定压力测试的强度。毕竟对于一家100人的企业和一家10000人的企业，压力测试的重点和规模会有明显的区别。特别是导入导出功能需要重点测试，因为一般月底会做总结会议，经常需要导出数据进行数据分析。
• 兼容性测试：完成压力测试后，紧接着进行兼容性测试。这一测试就是验证软件在不同操作系统、浏览器以及设备上的表现。在兼容性测试前，可以先统计企业内使用设备的情况，假如企业统一使用edge浏览器（微软原生浏览器），那么也就没必要去测试国产的各种乱七八糟的浏览器了。
• 用户体验测试：在确保了软件的基本功能和技术稳定性后，接下来的重点是用户体验测试。通过收集用户反馈和观察他们的实际操作行为，我们可以深入了解软件的优缺点，并根据结果进行必要的调整和优化，提升整体的用户体验。我们可以邀请需求评审时那些同事（调研产出确认、需求确认的业务同事），毕竟和他们沟通过原型和流程，他们已经对我们的系统有了基本的了解。由他们主导用户体验的优劣，也免除了重新介绍系统的时间。

四、实施准备阶段

4.1 内部认同的实施计划

你可能会想，实施计划不就是简单地规定一个时间，让企业开始使用新系统吗？然而，事情远没有那么简单。对于大多数业务人员来说，这套ERP系统是一个全新的工具，他们甚至可能从未见过。在这种情况下，我们如何确保每个员工都能熟练地使用这套系统呢？即使系统的功能设计得再简单，仍然会面临企业历史数据的处理、财务对账等一系列复杂问题。

因此，在制定实施计划时，我们必须将这些潜在的问题都考虑在内，并根据实际情况出具详细的实施记录。

首先，由于财务的特殊性，我们只能选择在每个月的1号进行数据和系统的切换，以确保财务数据的准确性和连续性。其次，考虑到行业的实际情况，我们需要选择一个业务相对不忙的时段进行切换。以汽车零售行业为例，由于年底是冲销量、完成厂家任务的关键时期，我们尽量避免在10月、11月、12月和1月进行切换，以免对业务造成不必要的干扰。

并且在制定实施计划时，我们也要留出足够的时间来做培训，培训时尽量能够在线下完成，虽然视频培训可以覆盖广泛的受众，但在实际操作中，员工可能会遇到各种预料之外的问题。

在后续的软件试用期间，也需要制定试用的计划。例如试用的第一周的目的是让员工熟悉软件，第二周要通过系统录入至少实际业务10%的数据，第三周要通过系统录入实际业务50%的数据，通过目标制定的方式，方便我们能够把控软件实施的实际情况。

通过考虑上面的这些问题，就可以制定出一个让各方比较满意的实施计划，这个计划可能不那么完美，但它是我们与业务同事和管理层达成的共识，而且也可以根据后续推进情况不断优化（如下图）。

4.2 实施准备工作

• 内部时间节点的通知：在ERP项目启动之初，就需要设立明确的时间表和关键里程碑。这些时间节点包括但不限于系统上线日期、培训安排等。为了确保信息的透明度和一致性，企业需要通过内部公告或邮件等方式及时通知所有相关人员，避免信息不同步。
• 数据准确性的保证：数据质量是ERP实施成功的关键因素，在系统切换之前，需要对原始数据进行全面的审计，避免因为原始数据错误而影响到ERP的运行。并且还可以设定一个特定的时间节点作为数据的“冻结”点，比如在切换前的一周内进行大盘点，以此确保所有数据都是最新的且准确无误。
• 外包业务的考虑：企业在运营过程中可能会涉及外包业务，在ERP系统实施过程中，需要考虑如何将外包流程整合进来，或者是兼容外包业务。

4.3 产研的部门定位及团队建设

在实际推进过程中管理层好像是条件反射，只要是系统问题就会推给产研部分，导致产研同学总是处理那些低价值的问题，例如物料价格错了需要修改、采购怎么做、A地区和B地区的售价不一样需要调整等等问题。

所以产研部门需要明确自己的角色和责任，避免成为业务流程问题的唯一解决者，需要明确哪些责任属于产研部门，哪些应由业务部门承担。例如，某些数据的系统配置应由对应部门的领导负责，单据错误后应该由直属部门领导来修改。ERP项目的实施一旦启动，就不可能随意停下来，所以产研部门需要在实施前就开始招聘一些人，确保有足够的人力资源来应对可能出现的各种问题。

4.4 实施过程中紧急问题的处理

越是接近实施阶段，技术和测试同学发现的问题往往越不会那么简单，此时对于已经存在的逻辑和功能，在没有完全理解前因后果（即100%了解）的情况下，不要轻易进行改动。这是因为之前的做法必定有其合理的缘由，随意改动可能会引入新的问题或破坏原有的平衡，就好像代码中有bug所以系统才能正常运行。

如果确实需要进行修改，就必须遵循正规的需求评审等流程，这样做可以确保所有相关的利益方都了解改动的意图及其可能带来的影响，同时也能够避免在紧急处理过程中产生新的bug。

五、实施阶段

5.1 实施前期

在实施的前期，是工作最近紧张的时刻，前期的一系列工作就看实施的是否顺利了，下面是实施前期需要注意的事情。

• 浏览器的缓存问题：在ERP系统部署过程中，浏览器缓存可能会导致显示错误或功能异常。为了避免这类问题，可以通过硬性更新的方式来清除缓存，确保用户看到的是最新的系统状态，或者在页面上加一个按钮，方便用户清除缓存更新系统。
• 销售收款的合规性问题：对于非标品或非固定价格的商品，销售过程中可能存在较多不透明的地方。所以在ERP系统设计时，需要特别注意销售收款的合规性，尽量保证所有交易都符合要求（只能说尽量，因为只要牵扯交易，就必然会有不合规的地方，公司可能就靠这些不合规的地方盈利）。
• 产品研发部门的人力安排：在ERP实施过程中，产品研发部门的人力安排需要合理规划，避免出现一部分人员非常忙碌而其他同事却无事可做的情况。这可以通过灵活调配资源、优化任务分配来实现。
• 正规流程处理数据错误：如果业务人员做错了数据，不能直接删除数据或修改数据库，而应遵循正规流程进行处理，不能因为客户着急而去走特殊渠道修改数据。
• 每日问题记录：在ERP实施过程中，每天都需要记录遇到的问题及其解决方案，这不仅有助于解决当前问题，也为后续可能出现的类似问题提供了参考。
• 信息同步：在ERP实施过程中，各部门之间的协作能力和信息同步是很重要的，可以每周末进行一个同步会议，沟通本周遇到的问题，如果是业务问题，可以直接交由对应业务领导去解决，避免产研部门直接指挥一线业务人员。

5.2 实施后期

ERP系统的实施并非以业务使用或财务顺利做账为终点，而应以月末做账的成功作为最终目标。这是因为月末做账涉及到大量的数据整合和处理，只有当这个环节顺利完成，才能说明ERP系统真正融入了企业的日常运作。

我们需要确保所有的财务报表都能够准确无误地生成。这意味着不仅要验证数据本身的准确性，还要确认报表逻辑的合理性。例如，在月末结账时，系统应该能够顺利处理所有相关的财务记录，并生成符合会计准则的报表。

财务数据的准确性对于ERP系统至关重要。任何错误的数据输入都可能导致严重的后果。在ERP实施后期，需要重点检查财务模块的数据输入流程，确保每一笔交易都能够被正确记录。此外，还应建立一套完整的数据校验规则，比如设置自动对账程序来发现并纠正潜在的错误。

除了财务数据的准确，管理人员往往在月末需要各类业务数据去做分析，方便他们去做月度汇报，我们可以为特定角色设定定制化的数据推送机制。例如，可以为高层管理者设定自动报告功能，定期向他们的邮箱发送销售分析、库存水平等重要指标，帮助他们掌握业务动态。

六、收尾工作

再完成ERP实施之后，恐怕到了部门最严峻的时候了，集团需要计算投资回报率。

集团投资了一大笔钱来做系统，当系统建设完成之后总会去做投资回报率或者上线后的收益，但计算的结果肯定不会让产研团队舒服，因为ROI只是一个财务指标，而ERP系统不只是从手工单据到电子单据的转变，更是企业管理、业务流程、组织架构的变革，并不是ROI不重要，而是ROI不应该作为唯一的决策依据。

作为产研部门，我们需要从企业数字化的角度去评估系统的价值，包括流程优化、员工生产力提升、打破信息壁垒、数据决策等。我们可以通过项目复盘去回顾整个ERP项目，我们的初衷有没有坚守、设立的目标有没有实现、当前ERP的价值有没有体现。如果实现了，那么具体产生了多少的效益，信息化建设的下一个目标是什么；如果没有实现，是因为什么原因导致的，后续需要怎么做才能满足目标。

这些东西都可以作为复盘会议的总结，而这些总结又可以汇报给集团领导，避免高层只看到了ROI数据而否定了整个项目的价值。

七、结尾

自建ERP系统是一个非常复杂且充满挑战的过程，但这也只是企业数字化建设的一小部分。企业数字化不只是做个系统，用上什么新技术这么简单，它是对企业管理、业务流程的一次变革，在这个过程中，知道为什么做比知道怎么做更重要，因为ERP的价值不仅仅体现在直接的财务回报上，更重要的是它为企业带来的长远发展潜能。

本文旨在从自身实践角度出发，总结和探讨企业在数字化过程中遇到的问题，因为需要兼顾系统建设的各个方面，某些地方写的比较笼统也有一些不足，希望大家能够谅解，也希望能给你带来一些思考。