信息化、数字化系统设计原则

前言

在前面我分享的数字化、信息化系统建设经验中，我经常会不断的强调系统建设过程中业务理解的重要性，系统设计一定要遵循企业的业务，围绕着主营业务建设信息化、数字化系统。在本文中，我们来分享信息化、数字化系统建设过程中另外一个需要思考的方面：设计原则。

系统的设计理念

系统设计原则是一个初听来感觉较为“虚”的东西，似乎和我以前所说的各种只做咨询，不讲落地的企业咨询一样，但是在我这几年的系统架构和设计的过程中，我开始不断的在尝试将系统的设计原则作为一个重要考虑方面，我发现系统中以前很多并不明确或是不能区分的部分，在这个设计原则下就变得极为清晰，所以在后期的系统设计中，我在方案设计、系统设计中，都会践行设计原则，以帮助自己去厘清一些难以区分、或是棘手的设计问题。下面我分享一些我个人正在使用的设计原则。 如果在架构和设计一个系统的时候，没有一个建设理念作为系统核心原则进行支撑，这个系统经常就会呈现出一种“各种工具拼盘”的感觉。

1、价值核心

价值核心是一个系统存在的基础。当我们为客户去建设、设计一个系统的时候，一定是需要为他们解决至少一个企业价值相关的问题，如果没有，那就需要编一个，并且编的这个，自己一定要坚持和坚信，同时这个价值核心，一定需要至少能对应上客户至少一个凸显的企业问题。 价值核心就是客户在现在生产 、经营过程中，面对的问题中想要解决的一个问题，并且它愿意为这个问题花钱。和在前几年的互联网黑话中，经常说的“痛点”意思差不多。我这里不用"痛点"这个词的主要原因，一方面是自己对于"痛点"这个词深恶痛绝，因为以前公司领导学会了痛点这个词后，开会最多给我们说的话就是：“你们这个产品、项目解决了客户的什么痛点？”。另一方面，我个人认为"痛点"这个词其实本身带有欺骗、忽悠的成分。我们以前最长用的解决客户痛点的办法就是：给客户用匕首划一刀，然后给客户卖创可贴。因为这时候创可贴是最需要"痛点"。以前我们经常说没有需求就创造需求，换到痛点就是：给客户一刀，让客户有"痛点"。 价值核心的本质是客户存在业务需求场景，同时这个需求是客户愿意为此付费的。例如：对于制造企业，MES、ERP其实必然是它的价值核心，只是可能因为企业的规模、发展阶段等原因，暂时不需要而已。但当客户提出想解决"进、销、存、物料"的时候，这个一定是ERP的价值核心。有这个价值核心之后，我们就是依据这个价值核心去建立ERP系统，首要解决的也是这个价值核心，因为这个是客户项目建设的出发点，如果这个都无法解决，那么其他所有的功能都是无用之功。 我这里一直在强调这个价值核心，也是因为往往这个价值核心是客户所最为关注的重点。围绕这个重点，其他的所有工作才是有意义的，把这个核心服务好，让客户看到效果，才可能让系统受到客户的支持，只要有这个价值核心在，即使后期有部分人员质疑系统的必要性和合理性，价值核心都可以作为回击最有利的武器。我经常会说，很多信息化建设系统在建设后，必然会造成公司内部大部分员工的工作量的增加，而受到抵制，而这时候基于这个系统价值核心就是回击最有利的方式。前几年在某工厂的开发MES系统，从一线车间，到部门主管，对最终上线系统都抱怨颇多，每次去现场沟通的时候，很多生产人员都表示系统极大降低了他们的工作效率。我当时经常会给他们说他们工厂的一个现象：早年他们厂内没有上线MES系统的时候，因为生产进度不透明，所以他们基本都是在工作卡上纸质记录之后，然后在每次生产会议前再翻找出工作卡编制一份是报表，汇总到小组主管，小组主管再汇总到部门，部门最后汇总到生产负责人，因为每次记录可能有保管等原因，经常会生产负责人拿到的数据最后结果是有偏差的，老板有时间会用库房数据反向印证这个生产数据，最后发现这个数据就从来没对过。老板骂生产负责人，生产负责人骂部门经理，部门经理骂小组主管，小组主管骂产线人员，就这样一级一级的再骂回来。我就说：系统上线后，的确工作量增加了，而且系统的确也不好用，但是，你们应该没有再被老板因为数据的事情骂过吧。另外一个，每次交付延期，你们生产是能吵过采购，还是能吵过库房，现在MES系统至少能让你们不背锅了吧。其实这就是MES本身的价值核心：生产流程管控，抓住这一点，有时间也是安抚系统使用人员抵制情绪的一个手段。

2、业务核心

每个系统都有其自己的业务核心，这个业务核心就是自己系统区别于其他系统的功能实现。如：MES系统核心理念：工单、派工、工序；ERP系统核心理念：进、销、存、物料。用系统业务核心去实现系统的价值核心，这才是信息化、数字化项目建设的正常方式。听上去这似乎是一件并不难的事情，但是实际在项目建设、设计过程中，业务核心的偏离是极为常见的事情。例如：

• MES本质是在做工单，但是因为工单涉及到设备，然后客户觉得既然生产设备都在MES系统，那为什么不把所有的设备全部录入到MES系统中，然后设备盘点的时候，就可以直接使用MES中的设备资产库，这种需求，是做还是不做？
• ERP在录入订单的时候，客户信息本身要么从主数据拉取，要么从CRM系统进行拉取，但是客户觉一个客户信息还要去另外一个系统中维护，就很麻烦，而且另外一个系统可能因为不好用，客户也不想去用，而要求ERP实现客户的维护和管理，这些需求如何应对？ 我在《数字化建设（三）- 数字化项目开发和实施》中曾说过，数字化建设的前期，一定要规划出每个系统的建设边界，不要在一个系统中实现过于庞大的业务。这里所说的系统建设边界，就是在指一个系统的业务核心。在信息化建设中，有部分产品依然使用超级单体建设的方案，将所有的功能全部融入其中，在这种建设方式中，其实不存在什么所谓的系统业务核心的概念。但是我在前几篇分享中已经明确指出这种建设方案的弊端，现在建设方案中我们有多种工具、框架和开发手段去实现系统之间的隔离，进而实现业务核心的独立分隔。 那么回到刚才提出的两个问题：
• MES中加入设备资产库，这个需求如何谈？ 这里我们可以先考虑这个问题的出发点，MES中的设备管理模块是为什么业务部门所准备的？其中设备信息数据的来源，信息的维护是什么业务部门在管理和维护？设备盘点这个动作又是哪个部门在进行？其实只要能说明这几点，正常的客户一般就不会再提出这个需求。因为很明显，设备信息数据的来源、设备信息的维护和设备盘点动作都不是同一个部门，也不是同一个业务的下上游。一个部门想要数据，或是想要从其他系统直接获取数据，本质其实就是不想自己对数据来源负责，或是不想对数据进行维护；而他要想做到这两点，一方面就需要能约束数据来源的部门，直白点来说，就是他能管理这个数据来源的维护部门，这样就算这个数据来源的维护部门不愿意做，他也可以凭借其管理职能让他们替它干这些事情；另一方面，这个部门需要确定数据本身可以满足自身的要求（除非这部门混日子，完全无所谓数据质量）。所以只需要从业务角度来说明如上两点的问题，提出这个超越业务核心的需求自然就取消了。很多时候，客户提出这些非核心需求就是一种天马行空想象，看到某系统中有设备数据，就默认系统中有全公司的资产数据，因为他们也只是公司众多业务部门中的一个，他们只是从自己的业务角度来理解系统中的数据，从资产部角度出发，设备数据不就代表了公司内部大多数设备资产么，只要我们从这个角度来看，就能理解他们提出这个需求原因，也就能懂得如何去说服客户。
• 客户信息数据的需求 这个需求其实相对于上一个需求就比较容易拒绝。因为本身如果客户公司已经有主数据平台和CRM系统，可以直接告诉客户公司规定和信息系统规范，同时说明如果系统内自行设置客户数据，他们的订单最终是无法进入财务系统进行核算的。这种类似需求大部分都是客户一时感觉而已，其实只要说明系统之间约束即可。 这里举的两个例子其实较为明显，很容易就能从核心业务分辨出来，实际上在系统的建设和设计过程中，部分业务功能并不是一眼就能分辨出来的，这时候就需要我这里说的，始终依据自己系统建设的业务核心，依据业务核心功能进行需求评估，这样一方面可以避免系统建设过程中因为非核心功能的开发影响开发进度，另一方面也可以避免非核心功能对于系统的侵入性影响。

  功能的设计原则

  不只是系统有设计理念，我们在系统中进行功能设计的时候，也需要有功能的设计原则。因为一个功能的实现方式其实是很多的，例如一个最简单的系统交互请求，我们可以有拉取数据的设计方案，也可以有推送数据的设计方案，那我们如何选择合适的设计方案进行建设，就显得尤为重要。 我们在系统设计的时候，通常会从以下几点基本的设计原则出发：

  1、精益生产原则

  在制造、生产型的企业中，我很推崇的一个理念就是精益生产的理念。在精益生产中，有一个核心理念：持续改进，实现生产过程的持续优化。基于这个理念，我们每次设计功能的时候，都需要考虑几个问题：

  1. 这种设计方案是否能帮助生产减少工作量
  2. 这种设计方案是否能改进生产流程
  3. 这种设计方案是否能提高生产效率 如果这三个问题的答案都为否，则说明这个方案需要继续改进，这种系统设计功能不要妄想说服生产人员使用，因为自己都不知道这种功能设计出来是做什么用的。提出精益生产原则一方面是在设计功能的过程中，能更好的评估功能设计的使用方式、设计流程、以及生产人员的接受度；另一方面也是为了在功能设计完成之后，培训生产人员使用过程中，让生产人员接受和理解，有助于系统在生产执行端的推行。 前几年我们在某工厂实施数字化项目，工厂属于加工制造类型工厂，工厂经常会从各个供应商那边拿到待加工品物料，然后他们需要入库后，等待加工部门加工产品使用。每次各个供应商在提供待加工物料的时候，会随物料的箱内放一张打印纸，纸上标明了此次物料的数量，以及每个物料的相关参数信息，而每个物料和这张纸对应是依靠物料的丝印，所以每次库房人员收到成箱的代加工物料后，入库需要一个人拿纸核对，一个人看物料丝印，对上后，在交货单上打勾，然后将这张交货单纸质保存即可。在数字化项目实施的过程中，我们发现需要将这张交货单内容输入系统，作为基础物料进行管理，这个工作变成了三个人来完成，一个人拿交货单核对，一个人看物料丝印，一个人录入系统；有时间人手不够就两个人，一个人看交货单，一个人看丝印，在核对完后，再用交货单录入系统，而且由于物料每次入厂的时候极多，他们一个月基本上有一周都要做这个事情。因此单纯的依靠人工录入方案必然不可行。我们最初想法是和各个供应商进行系统对接，或是要求供货商提供电子版本，系统导入后简化录入，后来沟通发现各供应商信息化程度低，而工厂本身并没有谈判能力，所以这方案并不可行。因此我们经过重新开发设计后，为库房提供了一套代加工品物料入库套件。 套件由几部分组成：高拍仪、工控机、工业摄像机。使用高拍仪将交货单直接拍照，然后分析OCR识别，识别出交货单上所有的物料，这些物料信息自动录入系统；然后库房人员使用工业相机对所有的待加工物料进行拍照，通过图像识别分析出丝印，然后自动和交货单上信息核对，核对一致后自动入库。由此改进后，入库工作量骤降，系统在推行的过程中就很容易获得认可。

     2、管控优先

     在多种设计方案进行选择，或是制定设计方案的时候，我们会将管控作为优先考虑因素。这里的管控可以是数据管控，流程管控，或是人员管控等多种，无论是哪一种管控，我们在所有的设计方案中一定要优选有管控的设计方案。信息化、数字化系统建设的基本出发点就是流程、数据的规范性，在规范性的前提下，我们才可以谈论其他方面，例如系统易用性、实用性等问题。因此如果一个功能无法避免管控导致的工作量增加、使用繁复等问题，这时候一定要以管控为核心，不可以在功能设计上进行让步。 这也就是在信息化建设过程中，经常会因为管控问题导致使用者、一线人员抱怨的原因。我这里说管控优先的原则，可能部分设计人员会认为在设计的时候，就应该将多种内容全部设计为需要人员进行填报，以此来体现信息内容的管控性。这是对管控优先原则的极大误解，我这里来做一个设计方案举例来说明： 在某工厂的生产过程中，某个工序是对其生产的元件进行压力测试，需要将压力测试结束后，需要将压力测试过程中的压力的变化、元器件的监测数据作为工序的测量数据填入，形成工序的实验结果数据。在早期的厂内信息化的设计方案中，生产人员将压力测试仪连入是厂家提供的软件中，然后再做完实验之后，将测试结果导出，然后对数据在系统中进行提交。 在这个设计过程中我们明显可以看到流程脱节：压力数据是在测试完成后，将结果导出后提交至系统。生产工序和工作内容脱节，而且数据结果手动操作，不符合管理要求。 因此我们基于管控原则，设计流程如下：在生产进行到压力测试工序后，生产人员需要将会压力测试仪连入采集设备，然后开始工序进行测试，测试过程中，采集设备会对压力测试仪进行数据采集，并将数据提交到服务器。当测试完成后，所有数据作为测试结果，提交到MES系统的工序结果中，作为此工序的执行结果。在这个流程设计中，由于是压力测试仪需要接入采集设备，部分生产人员对此觉得并不如以前数据直接导出方便，因此也有过抱怨。但是我们基于管控流程来说，持续的过程监控和管理，并且过程中无人为影响数据，必然是比原本方案要更符合系统管控的要求，因此我们在说明方案的设计原则之后，主管部门对此也十分认可，要求生产人员以此进行工序试验工作。 在这个过程中，由于涉及到设备通讯，因此涉及到SCADA系统，MES系统通过SCADA系统，对压力仪器进行数据采集，采集的数据返回业务系统后，作为业务数据被保存。这种需求一般会出现如下的设计方案： 当业务系统向SCADA系统请求数据的时候，SCADA系统接收到数据请求，将数据请求内容解析后，然后将请求转发给终端设备，终端设备依据请求的内容，将相关的数据进行返回，业务系统获取数据，由此完成一个数据请求闭环。这个请求过程如下图所示：

在这个过程中，SCADA系统承担的角色类似于代理的角色，它负责将业务系统请求数据的动作“翻译”为从设备中读取数据的动作，然后通过设备的协议接口，即可读取到设备的数据，然后将设备数据返回即可。 现在我们来思考一下，这个设计方案有没有问题？ 其实有问题，在我看来这个设计方案就没有遵循管控优先的原则。当业务系统在向 我经常说，生产人员最喜欢的管理方式应该是用Excel，因为想怎么填，就怎么填。主打一个灵活自由，但是哪个企业会希望用这种方式来进行管理。建立信息化、数字化的目的就是为了规范性，如果连管控都不需要了，如何体现规范性。功能设计中管控的设计方式也需要传达给管理部门，因为生产人员因为管控必然会产生抱怨和抵制，从而导致对系统的负面评价，但是主管部门肯定明白管控的必要性，将功能设计中管控设计原则和主管部门进行时沟通，以此来获得他们的支持，是推行系统正常运行的一个重要手段。

3、若无必要，勿增实体

若无必要，勿增实体同时又被称为简单性原则，这是我在系统设计过程中极为喜欢一种设计方式。在代码开发、程序设计中也有这个原则，其实这个原则适用于极多的方面。我以前在《空调集控做个节能测试》中提到一种马斯克策略，其实就是这种简单性原则另一种表现形式。在系统功能设计中，我们也经常会采用这种方案。当我们设计好一个功能，设计好一个表单，或是设计好一个流程之后， 我们通常会再次审视一遍这个功能、表单、流程，然后去思考一个问题：这个是不是必须的，这个字段、流程节点，配置功能能不能去掉？这个功能是否需要客户去做？功能是否需要生产人员去使用？是否需要管理人员去使用？没有他们是不是可以保证业务正常流转？在思考这些的时候，是因为我知道：客户用的更少，才更容易教会他们；系统才更不容易出现bug；客户也不随意发挥出更多的新增需求；同时严格控制功能的使用人群，可以保障我只要说服、教会几个人使用人员即可，而不是我要让所有人都懂得这个功能应该怎么用，让他们来挑战我的功能设计

最后

每个系统都需要遵循一定的设计原则，这些设计原则是需求、设计的时候不至于迷茫的依靠；而且更重要的是，很多时候有了设计原则，才能和客户“讨价还价”的时候，有基本逻辑支撑。