信息化建设和数字化建设

数据报表建设在早年信息化建设中作为一种最有效的建设方案，被大量使用，因为这种建设方案实施简单，目标明确，无论客户还是自己公司人员都可以迅速掌握，了解其重点。这种建设方案最常见的建设思路就是以最终报表为出发点，然后反推出信息化系统表单，然后交由客户确认即可。例如：已知某公司常年提交的数据报表有xx检查报表、xx核对报表、xx信息填报表，那么建设信息化系统的时候，我们直接以这些报表为基础，设计填报表单，然后确认这种表单填报的流程。通常这种公司并不会有很复杂的跨部门、夸职务审批流程，一般公司内部都是由某个工作人员填报表格后，直接发送给收集表格数据的信息收集人员，然后信息收集人员拿到后，整理统计、归档，再由这些信息收集人员负责定时、定期向领导保送报表数据。

因此这种信息化建设方案就是把这个表单做到系统上，然后给原填报人员分配一个账号登录，在表单填报完成后，以前的接收数据的工作人员变为审核员，如果系统延伸一下，就是审核完成后，数据汇总直接形成所需要的汇报表格，由此完成线下业务到线上业务的转换。

由上面设计方案的流程可以看出来，这种建设方案实施主体、实施目标、以及数据内容都很容易确认，这也就意味着客户、销售、开发、实施都有很清晰的范围，可以极大的降低沟通成本。所以在做客户方案建设的过程中，很多公司都会以此方式建设系统，宣传为由系统完成线下到线上的转变过程。

这种建设和实施方案在公司建立信息化初期，实现信息化从无到有的过程中，是很常用的方案，因为这种方案对公司原有的业务和流程无侵入性，就只是将表格转换为系统而言，相对来说各节点的操作人员也更容易接受这种形式。

但是这种建设方案的短板也极其明显，这种信息化仅仅实现了信息收集，这些信息收集中，甚至部分系统连基本的信息结构化都不会做，直接用原公司内部的原始信息载体，如：Word、Excel等。在整个系统建设过程中并不会对业务流程做出任何的改进，对公司标准化建设帮助微乎其微。前些年宣传的无纸化办公，甚至带动起来一波全民OA的热潮，很多也就是基于这种建设模式。

在公司内部工作由线下变为线上后，部分想实现信息化的公司会发现似乎公司管理并未有任何的变化，期待中的信息化推动流程改进、推送管理监督并未实现。生产、制造、维修等业务活动没有丝毫体现，最终汇报依然是以前能看到Word或是Excel，甚至这Excel或是Word都还是由以前的人上传到系统中的，可能唯一改善的就是，如果某天突然想看一下去年的汇报材料，可以不用翻自己电脑去找当时提交的内容（或是直接再让下属送一份过来---不过再次报送材料有被修改的可能，因为可能下属的电脑中早没了去年的内容，给的这份是昨天刚编好的）。

在管理者意识到这个问题后，就会出现两个方向的考虑，一种会直接认定为信息化就是只是花钱，但是毫无实效的东西，这种意识在早年信息化过程中普遍存在，他们会以自己公司的XX系统（一般都是OA）为例，说自己公司所谓信息化是花了多少钱，养了一个信息部，还不如多招几个修电脑的更有效益。另外一种，在拿到数据报送结果的时候，开始对数据的报送追根溯源，他认为信息化应该体现在每个数据的来源上，这样就推动信息化过程来到第二个建设阶段，基于业务流程建设。

在多个项目实践中，我司针对设备采集场景，对单向通讯盒子（以下简称为单向盒子）依据场景和需求定制和优化，在硬件设计上我们要求便捷接入，同时需要小尺寸，以不影响被采集设备的使用， 软件上我们采用多种对接方式，尤其是你针对数据传输场景，我们提供接口传输方式，便于系统接入获取数据。同时我们针对特定场景，如数据传输传输的需求，提供优先级传输的功能，以保障业务的实时性。

无论从事什么样行业的公司，必然有自己的业务流程，（我这里说的就是必然），基于业务流程的信息化建设，其本质就是让信息化贯穿公司的整个业务。我们就以很常见很小的业务个体来举例。每个小区楼下开的超市或是菜店。他们业务简单可以概括为：进货、销售、结算。简单业务直接就可以一眼看出来他们信息化中最简单需求：进销存。在早期没有信息化的时候，这套进销存的业务流程依赖于进货单、销售单、库存单这三种单据的纸质记录，因此在我小的时候，大一点的百货大楼这种商店，每周五下午都要提前关门，因为要做库存盘点，然后每年年前基本要提前一周就开始做盘点工作。现在基本上所有的超市都有进销存系统来支撑业务（别杠说大部分没有，那个POS机就是）。进货，扫码录入系统，销售，扫码出库；然后每天关门的时候，点一下看看今日销售额，扫一眼看看明细，然后如觉得有异常的，就再去货架上看一眼，就算是盘点、盘库。这个流程就是标准的业务流程信息化系统。

如果我们再基于这个流程继续想，进货的时候，可以选择线上配送，也可以选择自己秘不外宣的进货商（这个就是多年来小超市活下去、差异化的主要能力），这样，就可以扩展出好几个信息化系统：线上配送系统、供应商管理；如果小超市做大了，有能力议价了，那么可以和比亚迪一样，供应商想在店里卖东西，需要接受账期，供应商先送货过来我卖，卖出去给你结账，卖不出去你把东西拉回去，并且卖出去的钱也不可能卖出去就给你，得等到我半年或是一年的账期统一结算。这时候，就明显需要多个系统：商管系统、账期管理系统、财贸管理系统等等。

在这个过程中，就完整展现了在业务流程推动下，各个业务系统的需求是如何并创造出来。在明白业务需求的诞生后，我们来看看信息化建设的方案。

在信息化建设完成从无到有的阶段后，基于业务流程的信息化建设，成为各个行业信息化建设的核心能力。这种建设方案需要在需求调研阶段，关注于业务流程的梳理以及流程节点的确认，这是作为建设的基本依据，因此在信息化建设中，建设方案内容应该偏重于业务流程的描述，业务流程节点的衔接等等。我们还是以上面简单进销存案例进行分析。在整个过程中，三个节点是一定需要确认的：进货、销售、库存盘点。如果我们只管控这三个节点，那么这个系统就是那个POS机系统。但是我们如果拆解做进一步细化方案，可以分解如下：

• 进货：进货的方式可以分为：先货后款，先款后货、现款支付，这三种标准的名字被称为：赊销/账期交易、预付款交易、货到付款/款到发货；那么如果需要管理进货，这三种交易方式是肯定需要考虑的（不要说楼下小超市没有赊销/账期交易，这样就是后面说到的，在做基于业务流程信息化建设方案中，需要注意的业务流程调研问题）。那么每一种流程都有自己信息录入，以及流程（楼下小店当然不会有流程），如：赊销/账期交易 中，至少要录入一个对方联系方式，对方放在店里的是什么货物，数量多少，定价多少，结算方式、是否有押金等等，这些信息至少保证到约定账期的时候，如何支付。

• 销售：销售是整个业务中的核心环节，对于大规模的销售，需要包括：客户询价和报价、销售订单创建、库存占用/调配、出库与发货、财务结算、退货与售后这些基本节点。对于这些小超市，业务内容并没有那么复杂，基本上就是：客户询价和报价： ”老板，这个雪糕多少钱？“，”5块！“，“现在雪糕真贵”；库存占用：“算了，就拿这个雪糕吧”；销售订单创建：“滴，五块”；出库与发货：“这雪糕貌似不好吃啊”；财务结算：“到账，五元整”。在这个流程中POS机完成了大部分销售流程，但是，标准业务流程中必须要考虑还有其他流程：“小胖，你又跑来拿可乐喝，你爸给我说别让你喝可乐了”，“老板，今天我考得好，我爸说让我喝一瓶”，“真的？”，“真的！”，“那你拿去吧”，“谢谢叔叔，回头我爸给你钱啊”，“去吧去吧”；因此，赊账这个流程必然也需要在系统建设的过程中考虑；除此之外，销售中对于临期产品、滞销产品进行促销打折，也应属于销售业务。

• 库存：前面的我们说到，小超市的库存盘点一般会在每日关门前进行盘库和核对，但是在系统中，不可能设计为必须每日，或是只能每日进行一次库存盘点，每隔一段时间，一月或是年底必然需要对店里所有的商品进行查看，清理过期食品、对临期产品、滞销产品制定销售策略（打折）；对丢失或缺失的货物进行财务核销；对所有长期滞销、容易过期的产品进行统计，制定进货时的库存方案等。

基于上面的业务场景，我们将简单的进货、销售、库存三个模块就已经拆分出来多个模块，并且每一个模块都又出现新的业务流程。因此业务流程建设在现在信息化建设中依然是复杂的建设方案。这种建设方案要求调研人员对于行业的业务流程熟练，对于公司的业务情况了解，可以依据公司的公司制度、流程文件、规范说明等多种文件中，总结业务流程，设计业务方案；同时在和各业务人员交流、调研的过程中，需要关注他们的实际执行流程，这里额外需要注意的就是，实际执行节点经常性会和公司流程文件、制度规范不符，这时候需要沟通执行和制度冲突的原因，记录后，依据自身行业经验，对执行流程做出建议性方案，在需求会议上提交，提醒公司管理人员注意，并要求他们给出明确的确定方案。在理想情况下，这样可以将公司业务流程梳理完整，可以支撑公司在系统中完成业务流程。但是实际上，这里忽略了几个很重要的变量因素：

1.  潜规则、隐含流程

所有的公司运行必然尤其潜规则、隐含流程，这些流程多半是为适应公司某种流程，而出现的暂时性应对被长久执行的原因，甚至这些流程会作为很多老员工的经验进行传递。这些隐含流程就像是一个业务流程中的子流程，当执行到那个节点的时候才能被触发，公司的业务人员会在业务沟通的过程中记不起、或是不愿意提及，因此很难通过需求人员的调研或是沟通就能获知；但是这种隐含流程作为系统上线后的一个频繁触发的条件，成为系统运行后的一个个地雷。这种在早期信息化程度差的公司尤为常见和频繁。

早年在我们某个MES系统建设过程中，当时客户公司多年来一直采用多年前采购的一套ERP产品中的某一个生产模块进行管理，由于厂内生产多半以订单的标准件为主，所以他们业务多半是基于订单然后转换为生产工单，依据工单生产。在标准化生产流程设计中，最担心的就是非标件，或是定制件的生产，因为标准件和非标件完全是两个逻辑，两套流程。因此在调研的过程中，我们格外注意有没有非标件流程的生产。我们查看厂内ERP的生产模块订单，和生产部门的每个小组都进行了沟通，并都确认厂内就没生成过非标件，而且老板确认也没有非标件订单。依据厂内标准件流程设计方案提交后，系统上线三个月平稳运行，然后我们最担心的事情就出现。在这公司内，因为有段时间公司想要尝试转型，和部分BD客户合作，做非标准件加工。但是因为一直没有非标件经验，因此成立了一个研发中心，更神奇的就是，这个公司研发中心都不挂在公司的基本组织架构上，而是公司抽调个生产小组的几个技术能力较好的员工，和高校合作，因此研发中心在这所学校中挂牌。不知道是因为学校进展太慢，还是因为长久以来没有推动，因此厂内基本都默认没有这个部门。但是，高校那边因为某技术开始落地，受到国内多家企业关注，各个公司开始下单从这家公司尝试定制样品。更神奇的是，这家厂居然还有一份非标件生产工艺和指导手册，虽然是好几年前的，但是流程和规范倒是什么都不缺。我的个天啊，当时听到这个消息真的是天都要塌了。整个系统生产都已经构造在标准件生产的基础上，如果要拆出来非标件，意味着在客户询单部分就需要加入客制化的属性，并且在各小组加工参数、制程等都可能来自于客户，而非标准件，这种改动设计一定程度上比再重新建设系统都复杂。后续当然是大家重新调研，重新商讨流程，开发加班，硬生生在原系统的基础上新建流程，而且因为这个新建流程的原因，以前系统的架构设计被改动太多，标准件加工的流程都受到了极大影响，出现各种系统错误，整个系统半年多的时间才再次稳定。

潜规则、隐含流程这是我们在调研中要关注的重点之一，但是在实际的调研中，却无法通过手段来完全避免，我们在实际调研过程中，通过会参与到主流程的跟踪中，就是会跟着现场一步步观察和确认主流程的执行，然后和调研、记录的主流程进行比对，看是否出现预期或是记录之外的流程，最主要的是一定要参与到现场的执行过程中，调研中不能只依赖于主管部门的信息，因为主管部门的信息通常来自于他所认为、希望的流程，很多情况下，主管部门人员并不参与到实际的执行过程中，他们沟通和确认均带有明显的主观性。有时间我会这样比喻，主管部门一直以为大家下班都是走工厂大门，实际上现场人员都在下班后，推开厂房的安全门出去了。

2. 业务覆盖流程的缺失

业务覆盖流程的缺失基本是信息化系统上线执行后必然会出现的情况。因为一个系统在调研期间，不可能调研就覆盖所有的流程，所有的分支，而且由于调研人员、设计人员的水平和能力，会陷入到“客户以为你懂，你也以为自己懂，大家都以为对方懂”的情景，也许一句话的业务中，就包含了多种流程分支和流程例外，然而在建设方案，设计方案中是不可能体现，设计人员根本就意识不到缺失流程。然后问题就会集中爆发在系统上线初期，业务人员发现无流程可用，管理部门人员发现无流程可选，然后一致开始认为系统在给大家工作添堵。

这种情况是项目中无可避免的，在多个项目建设实施后，我意识到此问题的解决方案还需要多方的配合。

• 在需求调研阶段，我们依靠于需求调研人员的经验和对业务的敏感度，他需要能把握住被调研人员讲述内容的关键点以及关键信息，对有歧义，有异议的部分可以敏感觉察到，并沟通，记录和管理部门确认，这个没有规范或是资料可以学习，全依赖于调研人员的能力，所以经常我们需要的是行业专家、多年行业从业者去做需求调研，以此减少关键信息的遗漏；

• 在设计阶段，设计人员需要对业务精通的需求调研人员的业务理解，并使用多种沟通工具，如概念图、思维导图、流程图、白板工具、大纲笔记等，确认业务流程的理解相同，减少信息丢失，这里有个注意点就是设计人员在做设计的时候，对于底层无法更改扩展的设计，一定要和需求人员反复确认，确保每个字，每句话大家理解的都是相同的，如上面第一个例子中，设计人员和需求人员需要反复确认厂内确定不进行非标件的生产；

• 在设计人员和开发人员沟通的时候，需要有架构人员的参与，因为架构人员需要在业务实现和流程变更中，选取一个架构平衡点，这个点需要不过分增加工作量的同时，给业务扩展留有更多的空间，这里也有个很重要的点，就是对于架构设计中不能更改的设计部分，也需要和设计人员反复确认。这个点在很多公司容易被忽略，因为经常设计人员并不了解开发，在他概念里认为开发就是代码，代码什么事情做不了，将自行车改成火箭那只是加四个喷射器，然后给里面灌燃料即可；然后在开发那边看来，这就是要他把自行车拆成零件后，再重新融成铁水重铸。因此经常会有段子说，设计人员说开发只有两个改不了，就是：这也改不了，那也改不了。我们在这个过程中引入架构的原因，就是在这个阶段就和设计人员确认架构设计的不可变更部分。如：“自行车你以后要改电动自行车可以，改摩托车，除了不稳定和性能差，也能给你瞎搞出来，甚至汽车也可以，只要你不怕开着开着散架了；但是飞机和火箭是真的不行，加开发人员也不行，这是两个东西。”确定好范围和边界，这样会促使设计人员和需求人员确认主流程的正确性，保障后期流程更新或是修改都在可控范围之内。

业务覆盖流的缺失是无法避免的，我们所需要的就是如何将业务流程覆盖的变更控制在可以掌控的范围内，不要引起系统的连锁崩溃。在上面第一点的例子中，由于非标品的加入，就引起了整个系统的连锁崩溃。

3. 业务基础数据的缺失

业务基础数据作为建设系统的时候，首先需要收集的信息，很容易被多数人项目建设人员所忽略。因为大家普遍认为在项目建设的时候，基础数据的内容公司、企业会依据项目需要，按项目提供的模板整理即可，因为多半时候更多是纯工作量工作，大家都不愿意投入太多的精力在这部分上。但是我们在多次实施信息化建设的过程中，当系统建设完成后，发现基础数据经常会成为影响项目正常运行一个重要因素。因为项目建设人员会默认为企业基础数据会依据要求满足于信息化要求，基础数据是标准、且可靠的。但是实际情况来看，企业人员在整理基础数据的过程中，对于这些数据的使用并不会有直观认识，同时也因为是耗费工作量的事情，不出彩，大部分人员都抱着随意的态度，所以基本所有的基础数据在系统上线运行初期都不会满足于系统需求，甚至很多时候，基础数据在系统上线想当长的一个时间内，都是影响系统稳定，影响业务流转的重要因素。

早期我们从事财务软件的开发，在财务软件实施的过程中，最重要的一个实施准备前准备就是公司财务期初数据。财务期初数据经常需要和财务部门，主管部门反复商量，确定数据收集方案和迁移方案，并且会针对性的做一次数据尝试整理工作，以确认数据符合我们要求。后来我们在做其他项目实施的时候，在设计方案完成后，在开发尚未上线系统之前，通常会开始撰写基础数据收集、迁移数据方案，要求客户依据依据要求提供基础数据，以及尝试对历史系统数据进行迁移。多次经验表明，历史数据的迁移和期初数据的导入不能等到系统上线前期，因为这个历史数据迁移过程必然会导致系统崩溃，这么多此项目实施，我可以说必然，也就是没有一次在执行过程系统不整体性崩溃。

目前在基于流程进行信息化建设的过程中，我们依据多次建设、实施经验，针对性的改进流程，并在不同的执行阶段加入check list确认，在很多项目建设过程中行之有效。

在很多行业，行业多年来都已经有自己的行业准则和规范，如财会行业就是典型的规范制度性行业，因此这种行业的信息化建设会基于此行业的规范性制度的制定，这里依据规范和制度进行制定并非是信息化系统一样，而是他们的建设内容和实现目标，基本都会遵循于这个行业的准则，在整个系统调研和设计的过程中，规范性准则是指导建设方案的核心，因此这种行业的需求调研人员、设计人员通常会以业务专家的头衔，代表他们熟练把握行业规范。

这类系统在需求调研的过程中，由于基本准则已经是明确的，所以在沟通的过程中，和客户确认如何围绕准则规范，实现客户的业务内容就是就是重点。目前市场中对于有确定规范的行业基本都是以确定性产品的方式进行提供，如财会行业的用友、金算盘、管家婆等，税务行业的税友、金蝶等；大家虽然都是实现了财务准则、税法等规范，但是系统设计千差万别。相同的规范，不同系统实现的主要原因就是每个公司，不同的行业专家对于制度的理解有着极大的区别，同时在实现系统的时候，系统侧重点也不一样。我早年在做资产管理系统的时候，一般将资产分为固定资产、流动资产、无形资产等类型，每种类型的资产在做折旧和成本分析的时候，参考当时市面上的多家系统，结果发现每家公司的产品都有着不同的处理方案，后面我们实在处理不了，干脆把各种折旧方法，如：直线法折旧法、加速折旧法、减余价值法等多种方法全做了，让用户自己选这个资产的折旧方法，我们笑称想咋折旧咋折旧法，结果后来遇到一个客户提出来，可以将某些资产通过变更会计科目，实现一次性扣除，人家直接不折旧了，玩法那叫一个溜。

基于规范制度的信息化建设，整体方案的流程基本是明确的，大家一般会在流程的业务运行中做系统的自我创新，但是正是由于我前面说的，由于这类系统基本上都被各个公司做成产品的模式进行销售，导致流程中业务的定制性很小，再加上产品实施的思路和定制化项目的实施思路不一样，产品实施人员在普遍对于产品的掌控很弱，所以在对应于客户的很多需求就无法满足，这在一定程度上由于规范的限制，但是在现在各个公司差异化明显的情况下，更多的是因为实施人员的限制。多年以来，接触过的这类系统最好的代表是SAP。我从刚毕业就进入公司学习ABAP开发几个月，当时觉得这软件白瞎卖这么贵，但是这么多年各个公司观察下来，基本上真心认为SAP是在规范性和用户自主业务实现达到一个极好平衡的产品，做这类产品，我始终认为SAP是目前设计的最优解方案。包括SAP在做咨询，实施落地的时候，整个方案配合系统，真是标准实施的典范。但是这里还是不得不说，在多个项目中，SAP外部实施顾问通常都有着莫名的骄傲，他们能擅长的就是觉得客户的都是不对的，我的方案无懈可击，如果有问题，那就是你的问题。这种现象我曾和多个公司IT的负责SAP对接的人沟通过，大家都有同样的感受。另外一个，SAP整体操作风格和ABAP这种语言都有着反人类的感觉，当年我一直以为是个人感觉，自己水平太菜的原因，后来和一些长期从事ABAP开发人员聊天，他们说大家都有同样的感受，后面发现，这不是人家的系统原因，也不是我们的原因，是因为SAP整个系统就体现的是德国人思维方式，这思维方式，全球难觅。

来源：浮生华年