数字化建设（三）- 数字化项目开发和实施

定义企业信息化、数字化系统的范围，即：定义出本次需要建设的业务系统，这些业务系统代表了此次的建设目标，建设目标不一定能覆盖整个企业内部所有的业务和细节，但是一定是需要针对某个业务进行规划，对某个业务进行规划之后，后期可以定向扩展实施，逐步推行整个企业全面数字化。这里需要注意的是，不要想用还一个系统去解决所有的业务场景。在早年信息化建设过程中，使用一个系统完成整个公司信息，建立一个无比庞大的信息化应用，是比较常见的开发实现手段；但是这种实现就会出现单体应用过大，系统缓慢，难以解耦，系统升级或是更新业务困难等问题，所以现在后来推出的微服务方案，在一定程度上就是用来解决业务复杂性上升后，带来的系统“膨胀”问题，因此我们在做数字化系统架构的时候，也需要注意不要将一个系统构建的过于庞大，将整个业务分系统、分布构建，在极大降低业务系统开发复杂度的同时，也实现了业务之间的解耦。目前常见的业务系统，如: ERP，PLM，MES，SCADA，WMS，OA等等，可以在其中选择企业内部最为紧急需要改变的业务，进行优先试点建设；同时，还需要注意在设计建设的时候，一定要确定每个系统的边界范围，即每个系统负责的内容是什么，系统与系统直接的边界是什么，注意一定不要在一个系统中越界去实现其他系统的业务功能，这是一个在具体建设过程中极易出现的问题。因为在实际建设过程中，受需求方的影响，会将大量本系统无关的请求加入到一个业务系统的建设中，经常会因为无法拒绝这些业务，导致向其他业务系统进行延伸，延伸带来的问题就是：最终系统建设出来四不像，很多功能在某个业务系统"部分实现"，能用，但是明显看到业务流程的视线存在问题，如果继续实现，则需要研发人员继续投入大量开发工作，如果不投入，新建系统可能会存在重复建设的问题，重复性建设在老板看来，那就是在挥霍他的钱；就算是能说服老板和管理层，建设新的系统需要和当前的业务系统进行业务对接，而重叠的这一部分成为对接和实现最大的障碍，因为这部分已经依据临时业务流程方案运转，要改新的完整业务流程对接，不是废弃这部分功能这么简单，而是需要对已经实现到当前业务系统中的这部分“重复实现”进行切除，这同样是一个很大的开发任务，而且这种开发任务一般会是的当前业务系统变得极其不稳定，由此必然会带来业务部门的抱怨和投诉；最终结果就是实现的这些功能并不能给自己系统带来更高的业务满意度，不但增加工作量，而且后期带来了更多的投诉风险。

数字化建设是个长期的过程，在进行数字化建设的时候，在早期就将基础平台进行规划是一件很有必要的事情。当各个业务系统已经建设完成，再从中抽取建设基础平台，这是不可能办到的事情。数字化建设的两个基础支撑，其中一个就是基础数据集中化，归一化，而要实现这个基础支撑目标，基础平台就是根本。基础平台包含有各个系统所需要的必要性数据，这部分基础必要性数据不只有业务基础数据，还有业务支撑数据，同时还可能有一些系统支撑平台，用于各个系统的集成。目前数字化建设中，常见的基础平台如: 主数据平台，工作流平台，ESB平台等等。这些平台通常具有很高的独立性，所以很多公司都会将这些平台作为基础产品进行销售，因此数字化建设中，可以直接购买成熟的基础平台作为企业数字化的基础支撑，在节省研发资源的同事，也可以节省数字化整体的建设费用。只是要注意购买成熟产品的时候，一定需要数字化建设的团队参与评估和评审，并要求数字化建设团队对基础平台的支撑功能提出接入方案，以保障购买的基础平台在后期多个数字化系统中可以顺利接入。

数字化建设，数据是重中之重。提前对各个系统交换数据的形式、交换数据的内容做出规划和设计，这是数字化建设必须要做的事情。在定义出数据格式、数据交换形式、数据内容之后，这个基础定义一方案可以作为各个系统进行沟通、通讯和数据交换的基础参考，另一方面，定义完善的数据通讯，可以为后期系统进行升级、替换、改造，或是引入其他合作厂商提供基础。可以这样说，完善的数据交换定义，可以帮助企业在自己是在搞不定的时候，还有“请求外援”的计划，即使由于部分建设方向错误，都可以通过将部分系统进行重建的方式，实现建设方向的转向，不至于整个数字化建设全部“扑街”。数据交换的具体内容，需要根据各个企业的业务特点、行业特性以及企业短、中、长期的目标不同而进行制定，其实这也是实现第一点：定义系统范围边界的一种方式。

当所有的准备工作结束，即可选择合适的团队，组建各个系统开发、建设团队，开发建设各个系统。如何管理各个系统开发团队，以及如何把控各个团队开发进度等等内容，我们这里就不再讨论，因为这是一个合格的项目建设和项目开发团队应该具有的基本能力，具体集成方需要注意在建设的过程中，始终要将各个项目进行数据互联、数据互通、业务流转作为首要推进和沟通目标，一定要将企业内部业务推进、数据流转的整体概念传达到各个系统开发团的负责人，保证各个项目开发团队负责人及其清楚自己所承接的企业业务内容，自己系统在整个数字化建设中所处的业务位置，以及自己上下游系统的业务需求和数据需求，确保流程、数据的正确性。我曾在参与某建设项目的过程中发现，部分数字化业务系统直至开发上线完成，都不知道自己所承接的上有业务和数据内容，并且没将其业务传达给具体的业务部门人员。业务部门人员一直也不知道是因为这个系统承接业务出现错误，一直以为是这个数字化建设到他们业务部门就是这样流转，每次还有大量的人工新建、人工录入工作；此业务条线的一线使用人员抱怨数字化极其难用，然而一直没人注意到原本设计的业务流程在其中一个业务条线被一个数字化系统硬生生的给断开。在中、大型的企业内部，业务流转本身就是一件极其复杂的过程，而且流转的路径、流转的方式有成千上万个，一旦某个业务系统在建设过程中将某条重要的业务承接流程断开，其他系统从各自系统出发都无法看到这个情况的发生，甚至总集成方都无法判断出这种情况，但是这个导致的后果就是原本设计的数字化业务流程就会因为这个系统而受到业务部门的挑战，更主要的是，业务部门经常并不能完整表述自己系统在使用过程中的障碍， 因为他们根本无法分辨出这是数字化建设本身的要求，还是某个系统的问题导致，导致他们就会将整个的抱怨和投诉指向整个数字化建设团队。

这是作为集成商进行数字化建设的时候，基本的建设方案和建设框架，其实如果我们内部组建实现完整的信息化，数字化，依然是上面的建设框架，不过在企业内部进行全面数字化建设的时候，为了解决多样性、多业务线等问题，我建议可以做进一步约束性，如使用工业数字底座的能力，在其上建立业务实现。工业数字化底座是近几年来提出的较为流行的解决方案，在企业内部团队研发能力并不强，数字化建设经验不丰富的情况下，我比较推荐推进数字化的工作的主要团队选用符合自己公司的工业数字化底座产品（注意：这里一定是需要熟悉数字化建设的团队去主导，否则买回来的东西会让所有后期参与开发建设团队感到绝望）。在这个过程中，需要特别注意的是，如果是内部组建数字化，使用数字底座一定在设计之初就做好业务切分，因为这种建设方式并不像集成商的模式，系统之间有着天然的隔离，一但内部实现中业务拆分规划不合理，基础平台管理混乱，那必然是一场灾难，而且这个灾难会带偏整个数字化建设方向，这就要求组建者，设计者，架构人员有着清晰的业务能力，抽象概括能力，但是在一定程度上降低了研发能力的要求；因此这种也算是在给内部研发资源不够的企业所指出的一种快速降低起始成本，降低研发能力要求的一种方案。在这里我依然要不厌其烦的再次强调，一定要熟悉数字化的团队来主导，否则上面说的所有流程和方案都不会有任何指导意义。

在内部建设数字化系统的时候，我建议每个系统实行三个独立。这三个独立性是在系统进行架构的时候，就需要做好设计，并且需要注意在开发过程中严格遵守。

业务独立性，就是我们在开发实现的系统的时候，将客户业务的实现部分，作为独立的运行。业务独立性是保障业务流程顺利执行的关键，保障业务独立性，可以确保自身系统中业务的正确性，在出现新的需求变更或是新的业务方向的时候，也可以在不影响其他业务、数据的情况下实现，从而将业务需求变更、业务流程变更的影响降低到最小。虽然无法消除业务多样性和业务的变化，但是我们可以让新业务不至于对原本运行业务产生影响，出现业务需求变更而引入系统“雪崩”的情况。

数据独立有两个含义，其一即在数字化系统中，系统和其他系统交互、或是和设备的数据交换中，接收数据，作为自己系统的数据输入，这部分数据可能是上述系统中的基础数据，也可能是由其他系统推送过来，推动业务流程运行的数据，这部分功能设计需要作为系统独立设计，无论上游系统是否正常，或是上游系统出现升级、换版等，都不至于影响到自身系统的变更。这种独立性问题原本在超级单体的项目中不存在，但是在集成商建设，或是多系统建设的这种方案中，数据独立是建设一个稳定系统必要架构设计；其二：自身系统在设计过程中，数据需要设计出独立通道进行流动，而不要和业务绑定在一起。打个比方来说，数据就想是电线中的电流，一直在电线中流动，它能推动哪个业务进行流转，取决于哪个业务在使用这个数据，使用此数据的业务“打开开关”，数据就想电流一样，驱动这个业务进行动作。这种方案在我们目前的设计中，是一条重要原则，其实现的初衷就是想要将应对于业务变更和调整的多样性，数据独立和业务独立共同配合，实现新增业务，变更业务的影响控制在一个已知的范围内，一方面便于监控和修复新业务模块的问题，另一方面可以实现更高程度的业务解耦合。

控制独立，即：系统中的涉及到的和其他系统的交互中，推送流程运行、或是设备控制等，这部分功能也作为系统独立设计运行。同数据独立类似，下游系统、受控设备本身并非是自身系统可以控制的，设备、下游系统的变更都可能会引起自身业务的变化，例如下游系统对于数据输入需求的变更、下游系统对于业务流转的调整等等，都可能会引起自身业务系统的变化。控制独立可以将这种下游的变化独立在自身系统之外，在方便进行独立开发和实现的同时，可以帮助自身更好评估下游的能力和特性，以便于做出及时、合适的应对方案；对于设备也是如此。

整体的系统开发实现和实施的框架我已经全部介绍完成，下面说一下我在项目开发建设过程中，遇到的部分典型问题是，也算是作为项目开发建设发FAQ进行分享。

做数字化转型，必然需要和很多硬件设备进行通讯，要和设备通讯，和厂家的沟通就比不可少。几年来从事数字化、自动化系统建设，遇到过几百家各式的设备厂商，就我个人经验来看，遇到硬件设备厂商不懂交流的支持人员概率极大，基本上大一点的项目，需要接入多个厂商设备，总能遇到奇葩的技术支持人员。这些人的共同表现是：但凡你要问设备相关问题，需要设备通讯资料，他们会感觉自己有了权利，回复或是交流那必须体现高高在上的权利感。

我们曾遇到一个产品支持，沟通过程如下：

问：你们这产品怎么样？

答：必须的啊，我们都是和格力大金合作的， 你看我们这产品.....

问：为啥我们按接口文档开发的接口通讯没有数据？

答：不可能啊，我们都是和格力大金合作的， 你看我们这产品.....

问：要不你给我一份你们通讯示例吧

答：大金、格力我们合作他们都没要过，你看我们这产品....

后面实在没办法了，问技术，技术支持的Flash感觉只有两句话的空间，问他A的情况，他说看看B的配置；看完B的配置后，他说再看看C的配置，看完C的配置，他说没问题啊，我们东西是好的，你要干啥来着？我重复一遍出现了A这种情况，他然后说，那你看看B的配置.....

这种情况经常出现，并且不只有在小厂商，行业性的国际性品牌都经常遇到这种不会沟通的支持。

对于这种情况，依据我的经验，建议就是直接投诉。就这么直接处理效果最好。一般如果技术支持人员装死，我在催几次后，都是直接打总部电话投诉。

曾经有一次对于某行业国际企业，我甚至写英文邮件去总部投诉，因为这家打400电话，来回跳转都是这个技术售后支持，说这个是本区域售后，反正一句话换不了。技术售后支持问他要资料，但凡给回一句话，那就是那天心情好。那次真被这厂商气的不轻，我现在还记得当时邮件内容大概：“我是贵公司公司客户，据我了解贵公司秉承着客户至上的服务理念，但是我作为贵公司客户，却得不到基础的售后支持，我对售后支持的工作态度极为失望，贵公司作为国际性的公司，在员工培训和客户支持上这样的管理失职让我对贵公司的产品质量也有所怀疑，我希望贵公司能提供基础的支持服务以完成对客户的承诺，在此表示感谢。”

在英文投诉邮件发出的第二天，立刻就得到中国区的自称为负责人的电话，立刻表示会安排人员和我对接，有问题可以和他直接沟通。

当然投诉不一定总是有效，曾有甲方使用某公司产品，我们在反复沟通无果后，只好依据他们提供的软件去反向解析协议，这个过程导致通讯部分至少增加了两周的工作量。自此以后，我记住这个品牌，但凡和客户提到这个品牌，或是行业客户在设备采购时候征询我的意见，我都是直接告诉他们XX品牌不要购买，否则售后有问题，或是后续二次开发没支持。虽然不知道这对客户有多少影响，但是我一直相信在这个市场上，就应该不是劣币驱逐良币，要让好的品牌活的更好，我们这些从业者不去推动，不去影响，以后市场上就只能是一对垃圾企业市场上狂舞，反过来我们再抱怨市场上都是垃圾企业的时候，就要想想是不是自己的纵容和无底线才导致这样的市场。

我们做为其中一个或是几个系统研发，必然需要和部分其他厂商进行合作，尤其在整个是数字化建设的过程中，数字化建设的规模很庞大，通常有数十个厂商同时合作完成，每个厂商因为开发水平、厂商能力等差异，会出现各种的沟通、实施、联调问题，这也就是就是促使我提出系统三个独立原则中，控制独立原则的根本原因。厂商合作的情况无法避免，我们应该尽可能让自身系统受其他外来因素的影响降到最低，才能保障自身系统的稳定性。

客户现场基本上是我们进行数字化项目建设过程中，花费时间最多，工作量最大的事情了。基本上每个数字化项目都需要反复和客户现场进行核实，和客户沟通现场整改方案，沟通完成后，还要不断的对客户现场进行检查和调试。这个过程中可能会遇到各种问题，而且很多问题可能都并非是技术问题，或是业务问题。我们曾遇到过客户现场配合的人员在安装采集设备，然后和我们进行沟通说系统通讯没有效果。我们到现场后，由于采集设备是客户自行购买，我们也是第一次见到，我反复询问采集设备是否安装是否正确，是否按厂商指导进行安装，现场人员都确认说没问题。找了很久，我不觉得自己的通讯硬件部分有问题，反复测试都是正常，我又重新开始怀疑采集设备是否安装正确。终于，我注意到此采集设备在侧面是闭合处有二极管灯，这个灯不亮，我立刻意识到可能采集设备并未通电，然后重新询问现场人员是否通电，这时候才发现此采集设备为卡扣式，通电是需要将整个设备完全推入底座才可以通电，在我将整个采集设备完全推入后，发现侧面灯亮起，再测试，果然一切正常。从这件事情以后，我学到的最主要的一个原则就是：“别相信客户说的任何一句话”。自此以后，我整个工具箱中必然有电笔、线钳等工具，但凡客户说设备不正常，不管客户如何保证，我第一件事都是先拿电笔看一下设备是否通电，然后拆下来线，自己重新制作线头插入设备，重新看一下是否正常；

客户现场一定要和工程人员进行现场沟通和确认，甚至需要拿粉笔，直接给施工人员画出来位置，然后再三确认施工人员已经理解我所说的意思，最后再让施工人员重复一遍我说的话。因为只有这样，才能确保沟通施工的东西，能尽量保证在三次之内达到我想要的效果。我们曾在某次数字化项目中，需要监控整个建筑的能耗、环境温度、同时需要对天气等也进行监测，因此我们在建筑物的楼顶设立电能采集柜，将采集设备、通讯设备、传感器等放入其中，以满足项目需求。于是给施工人员说，就楼顶，你找个宽敞合适的地方，把这个柜子安在上面，电力线从顶楼配电室接入即可。施工人员说没问题，然后我们就回去继续系统建设，三天后，说施工完成了，让我去现场看一下。到了现场，差点崩溃。配电室在中间，正常应该靠着配电室周围，立个电能采集柜即可，但是施工人员可能觉得空空荡荡的地方立个电能柜不合适，于是将配电柜放到了顶楼空调外机集中的那一堆管道中间。我也不知道他们为了把那个柜子搬过去废了多大的劲，反正我走过去要翻过三个空调管道，还一不小心踩扁另一个管道。那中间集中了空调外机，20°的天气，那边能有至少30°，我的环境采集能准确就见鬼了，出风口正对着柜子在吹的起劲，我感觉我那个采集柜每天采集出来的天气数据都是在我家火焰山的天气；同时为了把柜子放在那边，他们硬生生的把电线从围着墙转个圈，我也不知道这电线在夏天能晒几天不风化，我只希望风化的时候别刚好搭到空调管道上，要不我担心会随机送走一个用空调的。不用说，全部拆了整改，现场叫施工的负责人过来，告诉他就把箱子安到我站的地方，告诉他电线沿着已有线槽走，不要再单独自己拉，就这样来来回回两三次，总算整体施工现场正常。

好了，就到这里吧，信息化，数字化建设的最后一部分内容分享完成，整个内容总计三万五千多字，虽然还有很多需要补充和完善的地方，但是整体我想要表达和分享的内容都已经全部讲述，整个过程中内容全都是基于我自身项目建设的经验进行讲述，所以很多很多读者说想要我分享XX行业的数字化建设经验的时候，我很可能并未参与过，因此并不能针对那个行业进行分析。但是整体数字化建设的脉络是一样，业务的部分还是需要各位读者自己去挖掘和理解，这样才能实现企业真正数字化的实现。以后我也会更多分享些数字化的案例分析，希望各位能保持关注。