上期，陈总介绍了信息系统架构过程中由于缺少架构导致的几个痛点，本期一手干货继续分享陈总的《信息化系统是要建成“菜场”还是“大厦”? 》演讲实录的第三部分：如何解决信息系统架构的痛点。

信息系统架构的理念和方法

1、紧扣核心业务

IT的规划架构必须支撑核心业务，必须以业务的战略蓝图为基础，业务有三年、五年规划，根据核心业务来规划信息化系统核心应用。

2、先做减法后做加法，分布实施

一个浅显的道理，IT上系统是管理的改进，是管理的提升。在做信息化的过程中，业务部门提需求的时候，经常会要求一步到位，一下子上一个完美的系统，但是，实际上行不通。

在上系统之前，管理水平是不高的，有可能管理水平还相当低，假如IT一步到位做好系统了，业务部门一步到位用起来了，那么你的管理水平就很高了，这是违背常理的，本来水平很低，通过上一个系统，一下子就很高水平，这是不可能的，仅仅通过一个系统，管理水平是不可能突飞猛进的。

所以我们绝大部分企业，做任何系统一定是先做减法，后做加法，分步实施，但是很多企业特别容易犯这种错误。要求一步到位，不管是有意还是无意，实际是给自己挖坑。当然，也有企业能做到一步到位，比如西门子，西门子的新公司实施SAP，从顾问进场到上线，只要一个月时间，常规实施SAP一般都要7个月，但西门子能做到一个月上线，原因是西门子的规范化、标准化做得非常到位，管理水平也已经相当高了，才能做到，全世界没几家公司能做这点，所以绝大部分企业还是必须先做减法后做加法。

3、平台化

很多企业现在还是用原码开发，一行行代码堆的方式，这个方法确实值得商榷。

(图源：陈红)

平台的优点非常多，第一个好处是开发周期短，我们的CRM系统是比较复杂的，有三四十个模块，如上图，包括PC端和手机端，在平台上开发，3个月就全部完成，然后测试，很快上线。

第二个好处就是Bug少，稳定性高，由于是平台，成熟的系统，代码量又少。第三个好处是工作交接比较方便，新人接手很快，短期人手不够，可以请一个顾问过来，很快就能上手，极大地减少了对人的依赖。前面所提到的医药公司CIO非常头疼，如果他们有好的架构，选择了平台，就不用这么麻烦。

4、快速扩展能力

第四就是快速扩展能力，支撑新需求新业务，如果架构做得好，平台化，集成化，快速拓展能力自然就有。

5、适合的才是最好

最后一个是适合才是最好的，这个不多讲，IT内部人士，大家都了解，前面的CRM案例，实际上就是犯了选型的错误，一味的追求高大上，忽视自身情况和实用性。

推进的误区

1、信息化只能领先管理水平半步

在信息化的过程中，最理想的状态就是信息化领先管理半步。信息化系统上线后，管理水平自然就提升半步，然后信息化系统优化改进，再领先半步，如此一步一个脚印往前走，拉动管理的改进和管理的提升。

2、不能一味追求完美，缺乏可操作性

业务部门提需求往往希望一步到位，这对他来说是合理的，但是作为IT来说，要合理的引导他们，系统一定是分步实施，分步上线，否则即使提供了一步到位的系统，业务部门也不可能一下子全功能使用。除非管理水平已经很高，一步到位才有可能，但是大部分企业的管理水平没有那个高度，还这样操作，导致的结果只能是失败。

3、购买不等于上线

实际上购买是万里长征第一步，真正有价值的还是实施过程，但实施过程是艰难的。

4、不能完全响应业务需求乱打补丁

前面提到的那家定制企业案例，就是完全响应业务的需求，补丁乱打，造成了系统的Bug太多。我们公司前期也是，我们的业务主要是零售，以前工程很少，这两年工程快速发展，今年会更多。工程的量上来之后，为了便于管理，系统对工程单的管理也要精细化，工程部门提了一个要求，一个订单分批发货，但我们现有的ERP逻辑是一个订单、一次下单，一次入库、一次发货，不能拆单。

但工程不一样，一个订单几百套、几千套柜子，覆盖很多栋楼，一栋楼建好，先发一批货过去安装，甚至一个单元好了，先把这一单元的货发过去，工程这个需求是合理的。但是假如我们ERP更改拆单逻辑，一方面，一旦改不好，就会造成系统的不稳定，二来工作量也很大。所以ERP的底层逻辑更改，相当于对ERP动了一个中大型手术，付出的代价会非常大。

怎么解决问题呢?我们找业务部门研讨解决方案，系统不改底层逻辑，是否有办法满足业务需求?最后我们找到一个非常好的方案，即业务拆订单下单，例如一个订单一千套，按照楼号或者单元，分拆下单。由于工程单大，每个月就几个订单，所以一个订单即使拆成5个、10个单子，增加的工作量也不大。然后增加一个查询功能，把同一客户同一楼盘的订单集中查询，便于业务部门跟踪同一合同的订单，这样不改底层逻辑，也能满足业务需求。

另外一个需求是MES系统增加设备的首检的功能，我们所有的设备99%都是自动化设备，都是数控机床，都要首检，确认加工精度是否符合要求，否则一旦加工精度有问题，全天加工的板件都要返工或报废，所以首检是必须要做的。质量部门和工艺部门跟我们讲了需求，用系统确保首检，我听完了之后，跟他们讲，这个功能没有必要上系统，这个属于SOP的内容，上系统并不能解决问题，假如工人愿意做，自然会按照SOP完成，如果他不愿意做，实际首检没做，系统点几下就行，系统也不能发现没做，就是说这是假需求、伪需求，这种需求在系统中更不能乱打补丁，跟业务部门交流的时候，解释清楚让大家理解就可以了。所以不管是整体架构还是在某个应用的运维上，都需要有架构思维。

5、线下流程原样搬到线上

这个大家都了解，信息化就是流程再造的过程，不多解释。

6、系统选型不能崇洋媚外

一二十年前，国内和国外很多系统是有明显的差距，但是近几年除了ERP外，绝大部分系统，国内和国外系统差距不大，其实ERP的差距也缩小了。前面提到的选择国外CRM那家公司带点崇洋媚外，总认为国际上的大公司、大品牌、大系统好用，最后却失败了。

实际上我们在选择的时候，很多系统国内的比外国的更价廉物美，而且服务也好，不像国外的大公司那么傲气，更新的节奏也快，更符合国情。

7、核心系统不能完全依赖外部顾问

最后一个也是比较重要的，就是核心系统，不能完全依靠外部顾问，内部团队一定要有把控能力，因为对于核心的应用，核心的系统，一定支撑的是核心业务，核心业务有优化，有改进，有新需求，响应必须快，依靠外部顾问，不是总能做到。而且对业务的理解外部顾问肯定不如我们自己人，一定是我们自己对自己的业务更理解、吃的更透，所以新的需求来了，他对需求的理解，以及解决方案的设计，一定更合理更实用。

架构的重点

1、应用的架构

分两个层面：一是总体应用规划，有哪些应用，哪一些是核心应用，什么时候实施什么样的应用，二是应用项目实施的过程中，项目本身也需要架构，项目的运维过程也要有架构。

2、主数据规划

主数据必须唯一，这样才能使所有的系统做成集成的，否则就是一个菜场。要实现主数据唯一，不一定非要上MDM系统，也不一定要有数据中台也能做到。钱多有钱多的方法，钱少有钱少的方法，但不花钱肯定不行。

3、平台的规划

举个例子，我们公司HR要做360度评测，HR把需求给我们IT，我们的一位小伙子花了半天时间就开发完成，PC端和手机端都非常好用，测评题目能随便定义，评测对象指定范围，比如经理级，上下级等可以随便定义，不但如此，连经销商都能用。这个就是有好平台的结果，主数据在前期都准备充分，比较完善，开发平台也比较成熟，所以在平台上做这么一个小应用就非常快，而且实用。

当然，应用网络的规划跟需求相关，什么样的可用性需求做什么样级别软件硬件的规划，包括上云不上云都应该在这个里面，数据安全是非常重要的。企业规模小的时候，可能感觉不明显，但是到了一定的规模之后，特别的敏感，而且是不能出问题的，数据安全一旦出问题，都是大问题。还有组织规划、制度保障等也都是问题。

综上，企业信息系统的架构要服务于企业自身核心业务，从实用性出发，从自身管理水平出发，循序渐进，分步实施，才能解决痛点，达到企业需求，建成宏伟的信息化大厦。