接上一篇信息化建设。 因为这一篇太长了，所以改了名字，也分为多个系列来分享。同样，内容很长，大家量力阅读。
数字化建设是在信息化建设的基础上更近一步。前面提到过，信息化建设是规范性流程、规范业务。数字化建设就是在将运行在信息化上的流程、业务使用数据进行填充，这里数据填充目的不只是细化信息化过程中的数据内容，而且期望于这种细化的数据能带来业务、流程的变革。在以前，如果说数据能带来业务的变革，可能要解释明白是一件很难的事情，但是互联网、大数据的发展，让越来越多的人认识到，大量数据的积累，就可以带来业务的更新和变革。
在信息化建设，因为多年来信息化项目实施经验和信息化普及的原因，基本上大部分客户都已经对信息化有着很明确的目标预期，所以落实到建设方案中很容易判断出方案是否满足建设目标，但是数字化建设过程中，因为数字化普及或是实施并没有形成全面的影响力，很多企业其实在数字化建设过程中对建设内容并没有清晰的实施效果概念，因此大部分客户数字化建设趋向于两种方式来确定建设内容。
同行业参观与调研，这是目前较为普遍的做法。当我们对于一个事情没有把握或是思路的时候，去看看别人怎么做的，学习别人的经验是一个很好的方法。在这个过程中，我们可以做到扬长避短。在同行业学习调研的过程中，一定要学习对方项目建设的思路和方法，而不要直接使用对方的建设路线，更不要直接照抄对方的建设方案。因为这里有个很容易陷入的误区：行业相同，大家产品基本相同，作业方式也基本相似，所以可以使用对方建设路线和建设方案，只需要做少许的改动即可。其实每家企业经营方式、管理方式、业务流程都有着明显的不同。就算是同一个行业，同一个方向，同一个产品，相同生产设备，都会因为管理层的不同，管理方式的差异，从而出现业务差异性。不要说不同公司之间由于管理产生的差异，就同一家公司，可能会因为管理层变动，甚至管理层决策的公司方向变动， 从而导致数字化建设方案的差异。 这里以我们曾服务过的某个企业举例子来说。我们曾在稀有金行业某采矿企业做数字化建设交流，当时公司任职的是公司创始人的接班人，由于是年轻人，所以在数字化方案上较为激进。通过他们管理层参观相关同行公司的数字化建设，他们依据对方公司的数字化建设的效果，提出了对此次数字化建设目标和希望。我们依据现场业务调研结果和管理层的管理方向，做出了一期目标规划。由于公司管理层想要实现全面数字化，所以同期他们还和多家厂商一起，整个规划中包含了ERP、MES、业财一体化、SCADA、WMS、费控等多个系统。当时公司内部先启动了业财一体化、费控、ERP项目建设，计划几个月后，MES、SCADA、WMS等业务系统开始启动。然而，就在这时候出现了问题。由于新管理层变革动作过大，公司内部保守派的阻力开始越来越大，终于到了不可调和的地步。老董事长重新上任，将接班人职位下放。随之而来的，就是新管理层主导的所有数字化改革项目全部暂停，重新依据原业务流程进行设计，整个数字化建设基本是回退到前期的信息化方案中去做。 当然，上面案例较为极端，我只是用这个极端的案例说明，即使是所有的外部环境、生产资料全部不变的情况下，数字化设建设方案可能也会因为管理层的方向就产生极大的变化，因此同行业参观和调研的内容，可以作为企业数字化实施的一个参考，或是数字化实施的效果的一个考量，可以通过同行业的数字化实施效果，来确定自己企业的数字化实施目标和落地规划，千万不要说：“我们也要xx企业的效果”，都有企业真金白银的投入打样做了一个示范，如果只是从中学会了一个样板间，并没有规避建设方案的缺点，发扬优点，那岂不是自己亏大了。其实在一定程度上我能理解大部分公司会更喜欢复刻同行项目的原因，因为重新设计自己的方案，一方面意味着对项目未来落地全貌没有把握，如果优于参观项目那还好，但是落地后一旦明显不如参观项目，对于承担项目建设任务人员都需要承担相应责任，这时候趋于保守才正确的选择；另一方面，即使方案更符合本企业内部的管理方式，但是这就意味着推动和落地的时候，可能遇到同行业项目中没遇到的问题，一旦自身能力、建设厂商能力不足以支撑解决，那么这些问题到时候连个参考方案都没有，可能会引起项目建设风险，这种担忧也会进一步导致客户倾向于选择复制已有方案。 这里我想要说的是：对于各人的考量和选择都没有严格意义上的好坏之分，虽然我个人倾向于依据企业自身量身设计方案，但是企业的担忧是正常表现，依据路线复制的确是相对稳妥的推进策略，也可能更符合部分客户所希望的：“先解决有无的问题”。但是数字化建设因为是需要大量侵入公司业务中，和公司业务进行深度融合，生硬的建设方案会在项目建设完成后，和自己公司的业务格格不入而受到业务人员的抵制，数字化建设的效果也会大打折扣。在这里我比较推荐的建议就是：在参观过程中，多和行业交流方案、实施的经验和困难，还有建设厂商的能力评价，对于能力评价较好的建设厂商，可以优先考虑使用，因为选择这种建设厂商在有行业建设经验的同时，也避免了选择到建设供应商能力支撑不足的问题。
区别于同行业已经建设的项目，数字化行业产品是近几年发展最快，也是大部分是企业最后落地项目的时候，经常采用的方法。数字化行业产品在一定程度上可以说是得益于近几年硬件发展，他们通常使用通用硬件方案解决业务中的共性问题。我在以前《信息化、数字化思考（五）》中推崇的最佳实践就是解决方案实践，但是这里需要明确的是，解决方案实践是指实践指南，或是实践方案，并不是指落地产品。因为很多客户、企业可能并不能分清楚解决方案和行业产品的区别，对于两者区别，可以简单的用这两个方法来区分。 1、解决方案在做建设方案的时候，更多的是在讲：企业调研中，业务有什么问题；目前流程是什么；通过和公司管理和业务人员的交流，期望建设的系统方向是什么；我们的方案计划如何解决这些问题；方案最终能到达到的目标是什么； 2、行业产品在建设方案中，更多的是在讲：我们的产品有什么；企业可以怎么使用我的产品来解决什么样的问题；企业通过我们的产品能达到什么样的效果；我们的产品能帮助客户实现什么样的目标； 从上面两点可以看出来明显区别，建设方案是以企业为中心进行设计，说的是我们怎么能去解决企业的业务、管理中的问题，实现企业最终的目标；而行业产品的建设方案一定是以产品为核心，他们的产品能帮助企业去做什么，最后产品帮助客户实现目标。造成这两种的建设方案差异的主要原因就是一个是需要量身为企业定做，一个是产品已经确认，企业只要评估适用不适用即可。再简单来理解，就是可以理解为：解决方案是：你想吃什么，我来做什么；行业产品是：我做什么，你吃什么（就是早几年流行的Omakase）； 我这里需要申明一点，解决方案建设和行业产品建设并没有严格意义上的优秀、差劲之分，因为所有的建设方案一定是要基于行业、企业的内部管理、业务、还有最重要的：建设资金 来选择的。一般来说，解决方案一般采用的是定制化方式，项目周期长，实施难度大，人员素质普遍要高于行业产品，正因为这样，解决方案会面临项目和方案严重不符、预期和落地项目不符的情况。我们经常会在客户那边听到说“你们这些人几百万开发的系统，还不如我外面花几万块钱买个xx系统好用”这样的话，其实这就是在用行业产品的思维去看解决方案。所实话，在一定程度上我个人是比较反感这种说法的，因为按现今流行的话来说，我认为这其实就是一种“既要又要”的心态。客户既想要解决方案的适配性，又想要行业产品的通用性和易用性，而且还和行业产品来比价格；‘在实际项目设计和实施中，适配性和通用性两者在绝大部分时候都是相悖的，这可是比“五彩斑斓的黑”更离谱的两个极端。当然一定程度上也不能说客户的这种心态，因为我出去买东西的时候，我是”既要又要还要“，比客户还离谱。当然，我这里只是做基本的区分，并不能针对市场上的每一种方案形态。因为肯定会有人和我杠说：“我们的产品就是既有产品通用性、易用性，还可以根据客户业务做适配性，最主要的是还便宜”，听上去简直是“既要又要还要“的完美解决。对于这种我只能笑笑，如果说这话的人是销售，我会夸他“本职工作做的真不错，他们老板招聘了一个不错的员工”，在通用性和适配性上能做到结合的，我只推崇一个产品：SAP，但是他为了解决这两个问题，可以说基本没有“易用性”，而且大家也都知道，SAP和“价格便宜”这四个字就不沾边。 在解决方案和行业产品上我们讨论的够多了，我们回到数字化行业产品的建设方案讨论中。数字化行业产品个人认为多数企业需要花更多精力在本公司需求调研和产品调研上。在规范性好的行业，如我前面在《信息化、数字化思考（三）- 电力行业》提到的电力行业，国网在“六统一”，“九统一”中，对规范性做了严格的约束，因此电力行业的数字化产品有很明显的业务适配性，当然也正是由于规范性，电网行业的数字化产品种类繁多，很多产品都只做一个特定业务的一小部分，这种其实也是数字化产品最合适的建设形态。但是在绝大部分想要实施数字化的企业，企业自身可能信息化都实现的一团乱麻，要规范性基本不可能，没有规范性，那么意味着行业产品在建设中，可能会和企业自身业务毫无关系，亦或是和建设期望的目标大相径庭。为了解决这个问题，我提出这个说法，数字化行业产品实现数字化建设一定要注意先做好本公司需求调研和行业产品调研。
建设方案在数字话建设中是极其重要的地位。在客户确认数字化项目的范围后，即可以将数字化项目立项，这时候可以进行招投标，选择合适的供应商进入企业做数字化建设。首先，必然是各个供应商需要进入公司调研，然后依据调研结果确定数字化建设方案，这里我就将自己做数字化建设方案的流程和一些经验进行分享。
在华为等大厂的数字化方案中，他们提出的数字化建设路径经常会包含数字化蓝图的规划，数字化蓝图就包含对于整个企业、公司，数字化最终形态架构，这种是形态架构会将整个企业全部形成一体化的数字形态，这里面会包含研发、制造、销售、交付、合作伙伴等多方面，例如：华为数字化架构蓝图中提出客户联接、一线作战平台、能力数字化、数字化运营四部分，但是由于我服务的很多公司并没有这样规模，我也没有能力对整个公司做出全面数字化蓝图，所以一般我们整体方案中并不会做数字化蓝图，而是将自己部分作为数字化转型或是数字化建设的一个业务的特定解决方案。
数字化目标是我在做企业数字化的时候，必然会涉及的一部分内容。我前面说过，数字化建设相比于信息化建设，难点在于信息化建设经常是没有案例和行业性参考。这是因为每个公司其生产过程的特殊性，经常会具有其特殊的生产流程，而这个生产流程中使用的工艺、产线、设备的区别，必然带来数字化建设方案的差别；也导致在复杂的大型厂区数字化建设过程中，客户在一定程度上很难知道或错误理解数字化建设的所能达到的目标和效果。因此提出明确形象的数字化建设目标，可以让客户明确此次建设的落地预期目标，在稳定客户预期目标的同时，也让可以对比自己的预期，如果和预期目标偏差明显，可以即是提出来做修正。例如上面我提到的领导预期目标是数字资产系统，但是在落地的最终目标形态WMS，这就是明显的数字化目标偏差。所以我们在数字化建设的时候，数字化目标不要过于口号化、抽象化和追求高端化。当然我不是在完全的反对这种形式，口号化，抽象化、高端化的目标在启动初期，可以起到易于接受、激励士气的作用，便于项目的推进；但是如果目标只有这三个特征，而没有实际内容，很容易引起客户的想象。我能理解在一定程度上，建设目标就是要抽象化和高端化，因为这是我们在从客户那里争取订单、打动客户的一个重要是手段，甚至有些时候，我们就是要依靠并不明确、抽象化、高端化的目标让客户产生想象，客户的想象空间就是我们的议价空间，但是实际上很多时候，建设方案的目标拔高了客户的预期，然后项目实施后的落地使得客户产生极大的落差，因此就很容易出现对建设项目不满的情况，这也是前面方案不管实施死活的典型表现。如何在合理建设客户预期和让客户愿意为这个预期买单之间做一个平衡，也是数字化建设目标需要考虑的一个重要方面。讲直白点就是：如何让客户知道你要做的是什么东西，又同时让客户觉的你做的这种东西值得花这个价格，这是建设目标也要考虑的内容。 为企业确立一个合理的数字化建设目标，可以为客户建立比较明确的数字化概念，也利于日后进行数字化实施的时候，得到客户的支持。
在数字化建设中，建设方案的重要性突显。优秀的建设方案需要厂商在做数字化调研，以及制定做数字化实施路线中，必须要知道清楚的客户生产的相关业务细节（这也是和信息化不同的地方，信息化关注的是流程和流程中的节点）以及生产流程，设计的方案需要能利用设备实现和推送业务细节中业务数据的流动，最终将这些业务数据流动在信息化的流程框架中，成为信息化流程框架的一部分，从而实现信息化基础上的数字化转型和升级。在这个过程中，业务细节的理解和信息化流程的融合成为关键，因为这两点决定数字化建设的内容和方向。 在方案建设中，我始终认为应该一个企业一个方案，依据企业的业务特点量身定做方案。当然，这并非是在说数字化建设中没有通用的建设方案模式可以使用，实际上我们在做每家企业的建设方案时候，基本的调研流程已经是基本标准化，并且我们还为此设计了一系列的调研表格、需求调研报告模板、设备调研模板等一系列调研工具包，这个工具包就是在长期多个项目中，依据自身系统架构特点，技术路线进行制定的，以方便我们在调研完成后，对企业业务、流程、设备、数据等做多方面的评估，这些评估一方面会会成为撰写客户建设方案的基本材料内容，另一方面，也会成为后期做设计方案、系统研发设计的基本资料。 有细心的读者可能会看到我们在做初期建设方案调研的时候，就已经将后期研发、实施中需要面对的系统架构、技术路线相关因素考虑进去了。这也算是我们公司在做建设方案的时候，长期积累出的一种特定实践方式。在标准的软件工程、项目管理规范中，是要求需求调研、建设方案阶段不能将架构、开发前置，因为这种前置内容一方面会影响到调研的准确性，调研的时候可能会潜意识的往已有系统功能上靠，可能导致调研理解偏差；其次，架构设计和开发前置会导致开发资源极大的浪费，因为建设方案是最不稳定的方案，可能在一次次的调研中不断的推翻，重新修改，进而导致架构、开发等相关内容也反复变更；我也承认的确多次实践表明，的确很容易产生研发资源的浪费，例如在某企业SCADA系统的设计中，我们的技术路线设计在建设方案的变更中，反复变更了六个版本，光是技术路线的设计方案就有五万多字，这还不包括部分技术路线需要调研和前期验证。但是这个带来了一个很明显的好处，我们交付的产品通常和建设方案中的目标相差并不大，我们的最终落地系统更能贴合公司业务需求，同时提供的部分业务改进功能也明显的对公司业务有实质性的提升，这样带来的好处就是我们的系统在现场更容易推进，更容易被客户所接受。在早几年很流行一种设计方案，《精益创业》中提到的使用最小原型的方法去验证产品。在看完这本书后，我曾去考虑书中提到的最小化验证的思路运用到项目建设中，即在每次的调研结束之后，会让技术参与进来，商讨调研中遇到的相关业务形态设计技术路线，形成一个业务形态和技术的一个最小验证闭环。这里可能是信息化项目和数字化项目之间一个比较明显的区别：信息化项目的技术路线在绝大部分项目中都不需要做改进或是变化，因此我们可以看到有很多信息化产品甚至还有的2000年左右的技术路线和技术方案，这种做法在信息化项目中是没有任何问题的，因为信息化项目主要是做业务流程的；但是在数字化项目建设过程中，这种技术方案如果出现在定制化建设项目中，是不能想象的（注意： 我这里说是定制化建设项目，因为在数字化产品中，技术方案经常也不需要有太多的变化和更新），因为数字化项目在建设过程中会和大量的设备进行通讯，而通讯的情况多种多样的。我们经常看到各种宣传数字化系统的，上来就在宣传自己系统的通讯协议，自己的系统可以接入各种设备，完成工厂数字化，实际上依据我多个项目的经验，客户现场的业务设备是极其繁杂的，没有什么通讯协议是可以统一，因为甚至很多设备都没有通讯协议，对于这类设备我见过太多厂商直接就是一句轻飘飘的“需要设备改造”就把难题扔还给了客户；数字化系统建设中，数据的规约和数据采集本身也是建设方案中极其重要的一个方面，数字化建设，如果都没有基本的数据采集了，还谈什么数字化建设。我们也是在多个项目中建立了一系列的完整的数据采集方案，包括从没有通讯能力的工控软件上采集数据，从没有数据通讯的设备上采集数据等待，以此才能支撑我们多个数字化项目的建设。也正式因为以上这些原因，经过多次实践，我们在整体的磨合过程中即提出了目前的技术前置的数字化建设实践方案。我不能说这个方案适用于其他公司和团队，因为我们本身也是在逐步的磨合和实践中，使用部分沟通交流手段才形成这种体系，但是在我们公司的多个项目实施实践过程中，效果显著。 在上一节中，我曾提到客户在做数字化项目范围的时候，要避免被部分数字化产品厂商忽悠，当时这种说法是站在客户角度来讲述。在我们建设厂商给客户做数字化建设的时候，同样就是要避免因为客户被数字化产品厂商洗脑，从而将我们建设数字化系统的方向带入深渊。 在某客户做数字化建设方案中，我们对各业务部门做需求调研时，某业务部门主管提出的需求：对现场的生产设备能耗、状态、故障、车间环境等进行检测。由于此客户是典型的柔性生产的产线类型，单纯的监测设备数据有意义，但是在实际业务中并没有业务实际使用价值。设备能耗的监测更属于无意义监测。我当时反应是是客户需要做绿色工厂示范，以及后期可能会对厂区做能源改造。因为设备能耗、状态数据监测的出发点常见于这些场景。但是在仔细沟通了解之后，他们根本没有这种规划，甚至提出此需求的业务主管并不知道这种使用场景。经过进一步沟通后才知道，他会有这些想法的原因是前期他们在进行数字化厂商调研的时候，某专注于电力行业的厂商给他们设计了这样的建设方案，方案中包括设备终检加装电能表，配电箱改造，电能质量监控等一系列方案。到此就恍然大悟，这的确是电力行业最标准的建设方案，但是只要对此客户业务进行调研，对车间的实际业务生产情况进行调研，对一线员工进行沟通就可以确定这种方案在此客户的实际生产中并无实际业务价值。后期，在我们和相关业务管理部门沟通和建议后，重新给此客户设计的方案，其中内容包括：
接上一篇《数字化建设一》。
在前面我们说了数字化项目的项目立项和项目建设方案两个阶段的相关内容，这一篇我们来说项目具体落地的方案：项目设计方案。数字化项目设计方案是用来承接于建设方案，将建设方案的预期目标转变为可以落地开发、实施的具体系统功能和模块，它对上承接建设方案，对下承接技术方案，所以设计方案是沟通业务和技术桥梁。在普遍的项目中，因为技术方案基本针对于开发人员，不会移交给客户，所以设计方案是客户能够看到的最接近于最终项目落地和实施的描述文档。 我们在上一篇中也说过，数字化项目的最终目标是两个：1：积累业务数据；2：积累的业务数据产生变革；我们的建设方案中从多个点来解析如何组织建设方案，用于给本文中设计方案的组织好提供指导和参考。设计方案基本已经是和客户交流沟通的最后一个指导性内容，因此此方案可以直接以系统最终目标出发，以建设方案中的客户需求和调研内容为支撑，进行项目设计；我这里也直接以建设目标进行分章节进行讨论。
数字化建设的直接目标一定是积累数据，这里数据包含各种基础数据，业务流转数据等等。在前面的思考中我说过，想要越精确和准时的掌控流程，就需要越精确的细粒度数据作为支撑，但是越细粒度的数据收集，在信息化的建设中就会导致信息化使用人员工作量成倍的增加。因此在信息化设计过程中，需要平衡好数据收集和流程管控的之间的关系，这样也就是我们在信息化建设过程中，所谓的信息化节点的设置。当我们需要管控到这个业务的某个点的时候，就在这里设置一个业务的节点，这个节点可以是一个表单，也可以是一个审批，或者可以是一个数据确认和查看。这些的设置都说明这个节点是此信息化业务中需要关注和管控的东西。 在数字化建设过程中，就是需要将这些管控节点细化，在信息化的管控节点中加入更多小的数字化管控节点，以丰富监控节点的数据。在数字化建设之后，监控节点数量一般都会成倍的增加，这里有个很重要的原则：数字化建设后，监控节点，流程数据会成十倍、百倍的增加，但是需要保障操作人员工作量不变，甚至应该让操作人员花在填写监控节点信息的时间成倍的降低。这里也是在体现我经常会反复强调，我认为数字化就应该建立在信息化基础上的原因。我们这里以一个简单的公司业务进行举例说明。 假设A公司是从事冷链运输行业，公司有条业务线南京到上海，为了统计公司运输司机的工作量，所以公司早期的办法就是，南京出发前，司机领了一个运输单，交给验货员，验货员查验货品之后，填写运输物品及其出发时间，然后运输司机签字确认；到达上海之后，接货的验货员验收货物，填写接收货物明细，到达时间，然后再把单子给司机签字确认。这样就完成了一个线下的南京到上海的运输业务。每月月底会计会核算每个司机的运输次数，以此来确认司机的薪资和奖金。 某天，A公司老板由于业务量持续攀升，原管理流程出错的几率大大提升， 同时客户满意度也随着业务的扩展下滑严重，很多投诉都已经打电话到他这里进行抱怨。鉴于整体管控难度的增加，以及为了后续业务的发展和扩张，因此打算将业务进行信息化，设计信息系统以便于进行流程管控，减少投诉率，提高客户满意度。经过软件公司的设计，这个业务实现信息化后的流程如下，这里以南京到上海的物流线路进行举例：运输司机从南京出发的时候，检验员选择运输车次上车查验货品并拍照，然后提交查验通过；此趟运输司机在手机端看到检验员的查验单，点击“开始出发”，即完成确认工作。当到达上海后，运输司机在手机端确认到达目的地，这时候上海的查验员收到“到达目的地，请求检验单”，上车查验接收货物，并拍照，然后确认收货。 在这个流程中我们就可以看到信息化的实现中有四个管控节点：出发前检验、司机确认出发、司机确认到达、到达检验。通过这四个节点，老板可以随时了解到某车次今天运输人员是哪个司机，也可以知道某一天运送了多少趟车，同时还能知道此刻有多少趟车正在路上运输；在收到客户投诉后，他可以让客服人员直接通过查询系统，即可知道这趟车目前所处的状态，并且可以通过司机或是检验员的信息，可以知道这个趟运输出现哪些问题，这样可以针对性的进行回答和安抚；另外此系统的数据可以直接和CRM进行对接，这样即可实现客户满意度的回访和调查，以提高整个业务过程中的客户满意度。这样简单的一个信息化业务流程设计后，整个运输业务可以运转的很好，司机、检验员分工名明确，各司其职；公司的管理层也可以及时了解到具体数据情况，及时对运输线路进行调整、优化。 但是运行一段时间后，随着客户要求的逐步提高，以及公司管理的细化，管理层想要做进一步流程优化，如：
我在《信息化、数字化思考（五）》曾说过，当数据在足够准确和普遍的时候，就可以通过数据推算出工艺、流程，然后可以针对性的对工艺、流程进行改进。并且在所有的精益化管理教学中，数据记录、数据的分析是整个精益化管理过程最最基本，也是最最重要的部分，所以在精益管理相关课程、资料、书籍中，都会提到使用各种统计表格来进行统计，并且还为特定的场景去设计独特的表格以方便使用。
例如，做工厂能源分析所使用的分析表：
这些所有的数据收集，就是是上一节中所提到数据采集和数据积累。在积累到足够的数据之后，我们就可以从数据的角度开考虑流程优化和改进。优化和改进最主要的出发点就是需要了解公司业务，以及公司管理需求。从管理需求和业务出发，将不必要的步骤省掉或是优化掉，将重复的步骤进行合并，最后得到一个优化流程，然后和公司管理和业务就优化流程进行沟通和讨论，确认其合理性。在这个优化流程上，再思考优化流程中节点可以采用的提高效率的技术手段，这样就可以从整个流程节点方面直接提高生产效率。
当然，以上是理想情况，由于以上的的设计过程中，需要IT人员、业务人员、管理人员三方全部参与，同时需要三方就整个流程进行沟通和交流，而在实际生产过程中，管理人员只精通整个业务流程，业务操作人员只精通某节点内流程，而IT人员只精通技术手段，而需要有人能够将会三方的所有信息进行综合，然后做出分析。这就需要这个人既可以和这三方人员进行沟通，能听明白三方人员的交流内容，而且还能够依据三方人员的沟通内容做出总结和概况，并抽取关键信息后，重新思考这个流程；思考完流程之后，提出优化流程方案，优化流程方案通过后，再和技术人员确认技术实现手段以提高效率。这就要求这个人必然是精通于业务的需求调研人员，同时需要有技术技能，而且最后还需要有一定的高度能进行流程总结，由于这种人员太少，因此在实际的执行过程中，这种流程优化多半是在数据采集和数据积累完成后，一个节点、一个节点的优化和更新。这就是最常用流程优化手段：监控节点流程优化。
对于整个流程把控是一个难度极高的事情，但是对一个重要的监控节点内的流程把控是一件容易的事情，甚至可能只愿意基础操作业务人员参与即可完成，对流程中的某一个监控节点进行调研和数据分析，看此节点中内容是否可以省略，或是此节点是否可以合并到上一个监控节点或是下一个监控节点。这样我们就可以只针对流程中的每一个节点单独进行思考和调研，在不影响整体流程模式的情况下，完成一个业务流程的流程优化。
这里提到两种依据数据进行流程优化的方案，但是实际上在数字化初期建设过程中，有一种行之有效的方法可以直接提高生产效率：减少"浪费"。（注意：我这里浪费打引号。我早年曾在生物企业工作，看到生物企业的Gene合成业务，从最开始的三天，业务流程被压缩到最后可以在6个小时内完成。这种优化方式简单，易于操作，只是个人认为在现阶段的国内，会背离方案的初衷。）在所有的业务流转过程中，都必然会产生“浪费”，材料浪费、时间浪费等等。只要利用足够的数据，就可以分析出可能的“异常点”，如：消耗原料异常点、工作量异常点、操作异常点等等，然后针对这些异常点进行分析，提出解决方案即可。我们在工厂生产过程中熟知的“5S检查”，中间的整理、整顿、清扫等检查就是在用规范性的制度约束，来减少生产过程中物料存取、搬运，以及生产过程中对原料的浪费。在数字化改造后的数据的支撑下，对于特定的节点可以直接进行现场分析，实行最基本的5S方案，或许就能达到很好的目的。这里额外说一句，在很多IE或是生产制造咨询顾问在厂内做生产改进的时候，其实整体原理也是这种方案。他们是基于多个项目锻炼经验，使用眼睛进行人工的数据采集（有些复杂的流程也会借助于表格记录），然后和自己经验所认知的经验标准进行比对，从而察觉出异常点，然后对异常点进行针对性分析，从而改进流程。
这种方案本来是一种简单易行而是利于推广的方案，但是我对这种方案有顾虑的主要原因是这种方法的另一面，压缩工序时长。流水线的好处除了将工序标准化可以带来产品质量的提升以及工人熟练度提高后带来的生产效率的提升外，还有一个最为重要的核心：节拍。流水线可以通过不断的提高节拍，以此将整条流水线上所有的劳动力全部压榨干净。同样的道理，这种数字化方案也可以。除了前面提到减少对工序时间的浪费，一个最简单的方式就是直接压缩工序时长即可。（整个逻辑就可以参考美团对外卖员的算法剥削）不断地通过压缩较长工序的工序时间（压缩办法包括但不限于：超时考核、超量考核），最后可以得到一个工序极限时间，然后以这个工序极限时间作为考核标准时间即可，相比前面两种流程改进方法，这种方法见效快，对实施人员的专业技能要求低、而且方案实施容易，效果明显。
上面谈了三种流程改进的方式，我们继续以第一点中那个A运输公司例子来说明。
在上面数据采集的流程方案设计中，我们并未改变整体业务流程，仅仅是对四个关键节点的部分操作从数字化角度进行优化，采用这种数据采集和数据积累方案后，运输流程的可以优化的业务内容如下：
1、运输物安全保障。全程温度监控，保障物品不会因为异常情况，如：保温箱破损泄露、门没关严等导致冷链运输的食品等变质。
2、运输路径规划。依据长期积累的运输路线数据以及互联网中的道路数据，可以预测某一时刻的运输线路拥堵等情况，提前进行路径规划；
3、全程监控，异常情况及时处理。如车辆抛锚，可以及时派出车辆接应处理；
4、加强对司机的约束。在保温箱中加入定位、温湿度等防止运输物品在途中被替换，或是司机自行并更行驶路径导致货物受损；
5、增强客户信任感。将路径数据、实时定位数据实时共享，客户可以及时了解货物位置，提前做好准备工作，并且增加信任感；
可以看到，通过数字化的改进，在不增加人员工作量的情况下，即可将运输的业务流程实现业务细化以及全面监控，同时对运输路径、运输途中的异常情况、以及给客户的交付体验等流程都有明显的流程优化。
当然，这些仅仅是基于我们上一步依据公司业务信息化业务流程，做数字化改造后，能够产生的业务流程优化，其实我们可以以运输业务为核心再进一步进行流程优化，例如在这个业务中，目前存在的两个人为主控节点：出发前检验 和 到达检验 工作，这两个查验工作做进一步优化。
1、建立公司货物接收和装车体系。对所有送到公司需要运输的货物，由货物接收处进行接收，接收完成后，建立货物接收档案，然后生成电子标签，将电子标签贴在包装箱外侧；然后将货物编号放到指定局域；
2、建立运输计划：在每次运输前，需要依据货物特性，如：特殊要求（4小时速达、货物很大，需要大吨位的卡车等），还有车辆状态：在运输途中、返回途中、空闲等，分配运输车辆，指定装车时间和运输时间，制定运输计划；
3、在运输前，装车的时候，装车货物由指定区域送出，经过检测门，装至运输车上，这个过程中，货物在经过检测门后，自动校验车辆和货物档案目的地是否匹配，防止货物运输错误，同时将货物状态更新为“已装车”；
4、装车结束后，系统上显示本次车辆装车货物数量；这批货物是否装车完成；当装车人员确认无误后；即可完成装车；
5、装车完成后，司机使用手持扫描设备，依据系统发送的装车信息进行核对，确认无误后，开车运输；
6、到目的地后，接收人员手持扫描设备，依据系统发送的装车信息进行核对，确认无误后，接收货物；
在这个过程中，可以看到我们将整个过程拆解为六个步骤，甚至开始涉及公司货物接收体系的业务更改；在这个流程优化的过程中，将货物接收和原本的检验工作合二为一，然后由司机作为一个确认工作，整个过程不依赖于检验人员，也不将检验人员作为一个把控节点存在，而是通过接收节点、数字档案节点、装车检测节点三个节点，节点层层确认，同时责任分摊，在降低所有人员工作量的同时，细化了三个管控节点，同时由于将货物接收体系进行规范化，后期可以进一步对货物接受体系做数字化管控，从而无缝对接原运输流程，从而逐步实现全公司的数字化。
我们依据A公司的运输数字化平台设计方案再来回顾一下数字化建设中设计方案的过程： 1、数据采集和数据积累。我们通过A公司的业务模式可以知道，运输是此公司的核心业务，所以所有的设计必须要围绕这个核心业务进行展开，这也是我在《数字化建设一》中不断在强调的，所有数字化建设一定要围绕客户的核心业务展开设计。在这个设计过程中，因为原信息化业务流程在整个公司业务行进中，已经形成了完整的业务指导方案，而且这个流程在本质上就是贴合于运输业务的，所以我们无需变更或是修改这个信息化流程，只是将管控节点进行细化即可。所以重点就是将运输过程中这个无管控的“管理真空”阶段，进行全过程细粒度管理，围绕这个阶段，设计了GPS定位、全程温湿度监控、门禁监控三个数据管理方向，这三个数据管理方向会将运输节点的监控精度直接提升到30S的数据采样周期。 2、流程优化和改进 通过这个数据采集设计，直接就可以使用数据设计出客户需要解决的业务问题：行驶路径、货物损耗比、客户实时监控。在解决客户业务问题的同时，我们同时考虑做部分业务流程优化动作：如运输安全、运输路径规划、异常情况监控等流程，这些流程在解决企业目前问题的同时，为异常情况的做更多的业务设计，这些设计就类似于数字化项目设计过程中的状态监控；另外，我们后续提出了公司层面整体性流程优化方案：通过引入电子标签，将货物运输的核验环节和货物接收环节进行融合，通过流程节点的拆分，实现更细粒度的节点管控，提升了企业整体的规范性。 以前流程由于四个管控节点的存在，每个管控节点需要人为执行，并且完全依赖于人为执行，在这个过程中，任何一个管控节点都可能因为人为因素产生不稳定，或是流程中断，从而影响到这个业务流程的管控，因此在这个阶段的管理执行职能依靠于管理行政命令，这也就是我在《信息化、数字化思考（五）》中提到的，信息化的执行基本依赖于公司上层的推动，如果上层推动遇阻，信息化是无法顺利为业务服务；而经过数字化改造后的方案，相较于以前的流程，以在整个数字化改造过程中，我们将所有流程拆解为类似于流水线的方式，大家只需要配合设备做好工作即可，如：货物装车需要过检测门、装车后需要扫描仪走一遍，这部分工作仅需要各执行单元配合即可，不需要做系统培训，也不需要他们掌握系统操作方式，从而降低系统推广执行难度。（我在《信息化、数字化思考（五）》也说到，所有的设计方案都需要兼顾执行人员的感受，这是系统能顺利推行的一个重要条件）；在整个改进流程中，我们设立了运输计划职位，这个职位需要做系统培训，选择合适的管理人员担任即可。上面改进流程能提供的数据优化方向远不止上面提到的这些，例如运输计划节点的加入，可以通过这个节点可以直接做全局的运输资源配置，仅仅这一个方向，就可以产生多个优化方案。 这个设计方案的过程其实就和我们的现在开车的行驶轨迹一样，虽然我们在行驶过程中的数据是间隔时间采样的，类似于流程一个节点一个节点的执行，单个数据并不能体现出来行驶的路程，但是当数据足够多的时候，就会形成一条直观，有意义的轨迹，而这条轨迹，就相当于一个业务。可以这样说，行驶过程中的定位数据，组成了行驶轨迹的业务。通过行驶轨迹这个业务，我们就可以将每个节点进一步做优化、改进，而整个优化评估，直接看轨迹的路径和时间即可。
本文我们讨论了数字化建设中，设计方案的设计流程。在前几篇中，有部分读者提到其中内容只有整体框架，想要看具体点的内容，这一篇算是很具体的设计方案的设计流程了，下一篇，我们会分享一下数字化项目的开发和实施，欢迎各位持续关注。
接上一篇《数字化建设（二）- 设计方案》
针对上一篇中有同行留言说，需要满足多样性和扩展需求，这种让我想起早年我在生物公司做的一个项目，当年那个项目由于大量的需求变动和业务的多样和特殊性，导致整个系统无比复杂，这么多年来我一直在想那个典型的制造业业务场景，看是否有更好的设计，架构方案。 需求调研，方案设计方面的应对措施我这里不展开来说，因为我上一篇《数字化建设（二）- 设计方案》已经提到了核心的主要部分，可以作为参考。因此这里我们只讨论实施的技术部分。 我一直在数字化建设中提到需要对客户针对性，有业务针对性的进行项目建设和实施，其实对于这个行业的从业人员都知道，个性化、定制化的项目实施会导致工作量和研发费用成倍的增加，并且定制化项目风险高，无论是客户的风险，还是开发团队的实施风险都很高，一旦项目在实施过程中把握不好，对部分重要的业务定制化需求拒绝会导致整个项目都出现客户不认可的风险；而如果对客户需求过分满足，则很容易出现软件项目中需求失控的情况，而且很多时候，需求失控可能都不是更为致命的，如果需求遭遇框架不满足、业务定制需求过多后，技术实现混乱导致无法把握整个系统，从而导致系统在一次次的需求累积之下如累卵之危；以上种种表现，在实际开发实现和实施过程中，由于是研发人员在整个项目中的弱势，而被忽略和掩盖，经常最后通过客户关系，商务关系等来解决，由此也仅仅是不断的在将一次次问题忽视，并没有作为一个项目问题来解决。 针对业务多样性、客户需求定制化化这个问题，我们换一种方式来进行思考，如果你是一家大集成商，你负责一个企业的全面信息化，数字化建设，你要采用何种手段，既要保障业务，又要保证扩展和个性化？目前经过多年我多种技术方案的更新和尝试来看，我的答案是云平台技术方案是目前解决以上问题最适合的技术方案。得益于近几年软件技术的发展，云计算，云平台的方案已经作为一种门槛并不是遥不可及的方案，已经可以较为容易的落入到中小型企业的信息化、数字化建设实践中，我们可以利用云计算，云平台的弹性、伸缩的特性，配合微服务的方式来完成多服务，多样化的需求。在工业化项目中推行和使用云平台技术方案，是我目前最为推荐的技术实现方案。 我们回到前面提出来的思考，如果作为集成商需要在企业内部实施数字化，可以参考的开发和实施基本的框架流程如下:
做数字化转型，必然需要和很多硬件设备进行通讯，要和设备通讯，和厂家的沟通就比不可少。几年来从事数字化、自动化系统建设，遇到过几百家各式的设备厂商，就我个人经验来看，遇到硬件设备厂商不懂交流（这里不懂交流是委婉说法，说直白点就是傻X）的支持人员概率极大，基本上大一点的项目，需要接入多个厂商设备，总能遇到奇葩的技术支持人员。这些人的共同表现是：但凡你要问设备相关问题，需要设备通讯资料，他们会感觉自己有了权利，回复或是交流那必须体现高高在上的权利感。 我们曾遇到一个产品支持，沟通过程如下： 问：你们这产品怎么样？ 答：必须的啊，我们都是和格力大金合作的， 你看我们这产品..... 问：为啥我们按接口文档开发的接口通讯没有数据？ 答：不可能啊，我们都是和格力大金合作的， 你看我们这产品..... 问：要不你给我一份你们通讯示例吧 答：大金、格力我们合作他们都没要过，你看我们这产品.... 后面实在没办法了，问技术，技术支持的Flash感觉只有两句话的空间，问他A的情况，他说看看B的配置；看完B的配置后，他说再看看C的配置，看完C的配置，他说没问题啊，我们东西是好的，你要干啥来着？我重复一遍出现了A这种情况，他然后说，那你看看B的配置..... 这种情况经常出现，并且不只有在小厂商，行业性的国际性品牌都经常遇到这种不会沟通的支持。 对于这种情况，依据我的经验，建议就是直接投诉。就这么直接处理效果最好。一般如果技术支持人员装死，我在催几次后，都是直接打总部电话投诉。 曾经有一次对于某行业国际企业，我甚至写英文邮件去总部投诉，因为这家打400电话，来回跳转都是这个技术售后支持，说这个是本区域售后，反正一句话换不了。技术售后支持问他要资料，但凡给回一句话，那就是那天心情好。那次真被这厂商气的不轻，我现在还记得当时邮件内容大概：“我是贵公司公司客户，据我了解贵公司秉承着客户至上的服务理念，但是我作为贵公司客户，却得不到基础的售后支持，我对售后支持的工作态度极为失望，贵公司作为国际性的公司，在员工培训和客户支持上这样的管理失职让我对贵公司的产品质量也有所怀疑，我希望贵公司能提供基础的支持服务以完成对客户的承诺，在此表示感谢。” 在英文投诉邮件发出的第二天，立刻就得到中国区的自称为负责人的电话，立刻表示会安排人员和我对接，有问题可以和他直接沟通。 当然投诉不一定总是有效，曾有甲方使用某公司产品，我们在反复沟通无果后，只好依据他们提供的软件去反向解析协议，这个过程导致通讯部分至少增加了两周的工作量。自此以后，我记住这个品牌，但凡和客户提到这个品牌，或是行业客户在设备采购时候征询我的意见，我都是直接告诉他们XX品牌不要购买，否则售后有问题，或是后续二次开发没支持。虽然不知道这对客户有多少影响，但是我一直相信在这个市场上，就应该不是劣币驱逐良币，要让好的品牌活的更好，我们这些从业者不去推动，不去影响，以后市场上就只能是一对垃圾企业市场上狂舞，反过来我们再抱怨市场上都是垃圾企业的时候，就要想想是不是自己的纵容和无底线才导致这样的市场。
我们做为其中一个或是几个系统研发，必然需要和部分其他厂商进行合作，尤其在整个是数字化建设的过程中，数字化建设的规模很庞大，通常有数十个厂商同时合作完成，每个厂商因为开发水平、厂商能力等差异，会出现各种的沟通、实施、联调问题，这也就是就是促使我提出系统三个独立原则中，控制独立原则的根本原因。厂商合作的情况无法避免，我们应该尽可能让自身系统受其他外来因素的影响降到最低，才能保障自身系统的稳定性。
客户现场基本上是我们进行数字化项目建设过程中，花费时间最多，工作量最大的事情了。基本上每个数字化项目都需要反复和客户现场进行核实，和客户沟通现场整改方案，沟通完成后，还要不断的对客户现场进行检查和调试。这个过程中可能会遇到各种问题，而且很多问题可能都并非是技术问题，或是业务问题。我们曾遇到过客户现场配合的人员在安装采集设备，然后和我们进行沟通说系统通讯没有效果。我们到现场后，由于采集设备是客户自行购买，我们也是第一次见到，我反复询问采集设备是否安装是否正确，是否按厂商指导进行安装，现场人员都确认说没问题。找了很久，我不觉得自己的通讯硬件部分有问题，反复测试都是正常，我又重新开始怀疑采集设备是否安装正确。终于，我注意到此采集设备在侧面是闭合处有二极管灯，这个灯不亮，我立刻意识到可能采集设备并未通电，然后重新询问现场人员是否通电，这时候才发现此采集设备为卡扣式，通电是需要将整个设备完全推入底座才可以通电，在我将整个采集设备完全推入后，发现侧面灯亮起，再测试，果然一切正常。从这件事情以后，我学到的最主要的一个原则就是：“别相信客户说的任何一句话”。自此以后，我整个工具箱中必然有电笔、线钳等工具，但凡客户说设备不正常，不管客户如何保证，我第一件事都是先拿电笔看一下设备是否通电，然后拆下来线，自己重新制作线头插入设备，重新看一下是否正常； 客户现场一定要和工程人员进行现场沟通和确认，甚至需要拿粉笔，直接给施工人员画出来位置，然后再三确认施工人员已经理解我所说的意思，最后再让施工人员重复一遍我说的话。因为只有这样，才能确保沟通施工的东西，能尽量保证在三次之内达到我想要的效果。我们曾在某次数字化项目中，需要监控整个建筑的能耗、环境温度、同时需要对天气等也进行监测，因此我们在建筑物的楼顶设立电能采集柜，将采集设备、通讯设备、传感器等放入其中，以满足项目需求。于是给施工人员说，就楼顶，你找个宽敞合适的地方，把这个柜子安在上面，电力线从顶楼配电室接入即可。施工人员说没问题，然后我们就回去继续系统建设，三天后，说施工完成了，让我去现场看一下。到了现场，差点崩溃。配电室在中间，正常应该靠着配电室周围，立个电能采集柜即可，但是施工人员可能觉得空空荡荡的地方立个电能柜不合适，于是将配电柜放到了顶楼空调外机集中的那一堆管道中间。我也不知道他们为了把那个柜子搬过去废了多大的劲，反正我走过去要翻过三个空调管道，还一不小心踩扁另一个管道。那中间集中了空调外机，20°的天气，那边能有至少30°，我的环境采集能准确就见鬼了，出风口正对着柜子在吹的起劲，我感觉我那个采集柜每天采集出来的天气数据都是在我家火焰山的天气；同时为了把柜子放在那边，他们硬生生的把电线从围着墙转个圈，我也不知道这电线在夏天能晒几天不风化，我只希望风化的时候别刚好搭到空调管道上，要不我担心会随机送走一个用空调的。不用说，全部拆了整改，现场叫施工的负责人过来，告诉他就把箱子安到我站的地方，告诉他电线沿着已有线槽走，不要再单独自己拉，就这样来来回回两三次，总算整体施工现场正常。 好了，就到这里吧，信息化，数字化建设的最后一部分内容分享完成，整个内容总计三万五千多字，虽然还有很多需要补充和完善的地方，但是整体我想要表达和分享的内容都已经全部讲述，整个过程中内容全都是基于我自身项目建设的经验进行讲述，所以很多很多读者说想要我分享XX行业的数字化建设经验的时候，我很可能并未参与过，因此并不能针对那个行业进行分析。但是整体数字化建设的脉络是一样，业务的部分还是需要各位读者自己去挖掘和理解，这样才能实现企业真正数字化的实现。以后我也会更多分享些数字化的案例分析，希望各位能保持关注。
