取消
搜索历史
热搜词
原创
活动
创新2.0
I T
产业
当前位置:首页 >产经•城市 > 产经 > 工业4.0 > 正文
我乐家居CIO陈红:信息化系统是要建成“菜场”还是“大厦”?
来源:ENI经济和信息化网  作者:陈红 2019-05-15 11:11:00
应用网络的规划跟需求相关,什么样的可用性需求做什么样级别软件硬件的规划,包括上云不上云都应该在这个里面。

前面花了一些时间介绍了智能制造,现在来讲今天的主题,今天的主题是信息化架构——《信息化系统是要建成“菜场”还是“大厦”?》。这几年是走访了不少企业,跟很多企业做过交流,跟许多CIO同行也有交流,感觉大部分企业还是比较缺乏架构思维,缺乏规划,走了很多弯路,甚至回头路,不但浪费了人力物力财力,更重要的是浪费了时间,错失了发展的时间窗口。所以今天重点跟大家探讨一下。

\

大家看到这个图,左边是菜场,右边是大厦,菜场一般没有特别专业的设计,而大厦必须有非常专业的设计,在强电、弱电、消防、采光、通风、和安全等方面非常规范,菜场没有大厦那么规范,所以虽然菜场的规模可以扩得很大,也不可能有大厦的高度。我们的信息系统就是要建成大厦,不但有规模,同时有高度。

\

下面我就分四个方面跟大家分享一下:第一个就是缺乏架构的痛点,第二个是架构的理念和方法。第三个就是推进的误区,第三四个就是架构的重点。

\

痛点我总结了四点,说不定还有其他的,我感觉到比较有共性的就是这四点:第一,如果缺乏架构一定会走弯路,我们今天在会前也交流了不少,在这个过程中大家都有体会。第二,就是信息孤岛,这是老生常谈了,但不幸的是,目前这还是一个普遍的问题,很多企业都有。第三,就是人多不一定好办事,有的人说事情搞不定没有关系,加人就可以了,实际上有的时候人多效率反而是低的。最后,如果架构不好,新的业务和业务转型的支持会比较困难。因为现在大家都在转型,互联网+、工业互联网、新零售、和智能制造等。如果架构不好,转型实际上是很困难的。

下面我们逐一分析,既然是架构实战,今天我们都是举一些真实的案例,当然信息都脱敏了,防止对号入座。走弯路和回头路各举了一个例子,第一个快销品公司,这个公司每天有大量的配送,实际上配送对象就是商超和个人,量比较大,有几十万。因此分销系统一定是它的核心系统。分销里面含计划,指挥排产,然后配货、发货、送货。商超和个人家庭还是有差异的,商超主要是补货的逻辑,而个人家庭是变化比较大,个人家庭今天要这个,明天要那个,说不定后天就取消了。信息变动频次如此之高,数据量又大,过程中不容许有差错,不容许有延迟,这是一套比较复杂的系统。非常的不幸,他们不是选一个成熟的平台,而是交给一位朋友,实际上是一位大学教授带了几个研究生开发了一套系统,没有行业经验,也谈不上丰富的开发经验,系统上线后一直问题不断,当公司发展到20亿左右规模时,根本没法跑,问题太多,Bug太多,一般来说信息化系统是企业的引擎、助推器,但在它这儿变成了瓶颈,制约企业的发展,后来花了大的力气更换了一套系统,缺乏规划和架构思维,走了很大的弯路。

正常的情况下,遇到这种分销系统,一般肯定先考虑行业已有的成熟的系统,假如说找不到这种比较成熟的系统,既使开发也要找一个平台开发,不能一行行代码堆着,由于开发团队没有行业经验,甚至开发经验也不够,因此走弯路也就必然了。

第二个案例也是一个销售公司,这个销售公司是一个全国连锁,连锁店有几百家,他们的连锁店规模比较大,都要上千个平方,产品也是家用的消费品,是中低频的消费品,所以消费是靠口碑和服务,CRM一定是他们的核心系统。但是他们的CRM选了国外一个大牌公司的,这个CRM在国内很少有公司使用,他们太看重了这个牌子,合同签了几千万,实施了一年半最后失败了,把老系统拉出来顶上,走了回头路。这就是规划和架构能力严重不足的最典型的一个案例,选型上出了比较大的问题,供应商的名气虽然比较大,规模也比较大,但是它的CRM不行,在国内没有什么案例,敢用这种系统是需要勇气的,再加上自己的把控项目的经验不足,所以这个项目失败了,这个CASE是近几年的事情,发生在2015年,要说十几年前有信息化项目实施失败,可能大家还是认为比较正常的事情,要说最近几年信息化项目搞失败了,而且是这么大的项目,确实少见。规划和架构能力不足,走了回头路。

信息孤岛实际上是一个老生常谈的问题,我举了两个例子也是比较普遍的,一个是某工程设备公司,B2B的业务,公司对IT的重视还是相当不错的,连续3年对IT的投入,都是销售额的1%,一般的公司做不到,这公司的老板比较舍得投入。我们到现场参观,系统做得不少,自动化包括机器人应用很多,监控大屏也高大上。但是他们有一个问题,就是系统挺多,积累了很多的数据,做全面的数据分析很难,很头疼这件事,实际上这就是架构上的问题。假如说三年前重点投入之前,有很好的规划和架构设计,确保主数据唯一,系统都是集成的,就不会出现这个问题。没有规划,系统之间互联互通出了问题,不是集成的系统,形成信息孤岛,跨系统的数据综合分析当然很难。但三年后,要想打通各个系统,做集成,就要花大功夫,要不上一个数据中台,要不上一个MDM系统,不幸的是,很多企业都是这个状况。

第二个案例是一家医药公司,我跟他的CIO交流的时候,他说每年春节之后就头疼,IT有三四十号人员,过年之后都有离职的,离职之后工作交接都是头疼的事,因为他们除了ERP外,有三四十个系统都是自己开发的,而且开发也不是基于平台,更没有中台,都是一行行代码堆起来的系统,IT三四个人一组,每个组维护几个系统,这一行行代码堆起来的系统相互之间不集成,这个就是最典型的菜场式系统。每个系统有新的需求、有变更、有优化,代码就要变更,补丁摞补丁,新人很难完全读懂老代码,修改代码很难考虑周全,容易形成新的Bug,因此系统问题特别多。这就是没有架构思维,系统自然就变成了一个菜场,虽说规模不小,但很难再有发展。

第三个痛点是人多不一定好办事,有两个案例,两个Saas APP,第一个是培训相关的一个SaasAPP,使用对象是门店销售的导购,用户数近十万人,第二个是服务相关的SaasAPP,使用对象是安装工人,用户数30万,第一家培训APP,APP开发人员有20几号人,第二家服务相关的,APP开发人员不到十个。但两个APP虽然行业不一样,但是功能模块数是差不多的,也就是说开发和运维的工作量实际上差不多。说明服务APP的架构明显比培训APP强,从效率上来讲肯定高很多,差不多的工作量一家是20几个人,一家十个人。而且第一家跟我们在交流的时候,为了强调他们重视研发,做事一丝不苟,重视功能的优化,跟我们讲了一个案例,他们的库存管理模块开发做了5遍,我当时听了很无语,说明这个架构师严重失职,简单的一个库存管理要做5遍,对于一个合格的架构师是不可能的。因此,培训APP的开发人员虽然多一倍,但效率反而更低,其主要原因就是架构上的问题。

第二个案例是一个定制行业的企业,用的ERP是国际顶尖的,但他们把ERP搞的太重,定制开发太多了,他们目前的ERP的运维人员是20多个人,说明了这个系统问题非常多,否则需要20多个人来运维吗?同时可想而知,当新业务来时,新需求来时,他们的响应也不会快,因为问题多,所以响应慢是必然的。这种情况也是典型的架构没有做好,人虽然多,但效率低。首先定位就错,把ERP搞的太重,当然这还不是最致命的,定制开发太多,后期的所有的优化、改进也没有架构性的思维,打补丁不慎重,长期以往,补丁摞补丁,引起Bug太多,问题多靠增加人员来弥补,实际上效率更低。

最后一个痛点是难以支撑新业务或者说业务的转型,刚才提到了,很多企业在转型,智能制造和新零售,我举的两个例子都是跟新零售相关。第一个例子是一个企业做新零售O2O系统,现在也说OAO,即Online And Offline,这个系统一般来说都有几个模块,包括引流数据归集、呼叫中心跟进、进店和成交等,线上引流信息来源比较多,有百度搜索引擎的,有官网的,有电商平台的,如天猫、京东等,有朋友圈的,有今日头条的,也有小视频的,系统必须要做到自动归集,之后呼叫中心跟踪进店,直到成交,手机端和PC端都要支持。这种系统,一家企业花了30万购买一套系统,实施3个月上线,但是问题不断,主要问题在哪?就是需求变化比较多,响应太慢。因为每家做新零售都有各自的特色,尤其是O2O,都是摸索前进,一个方向试试不行,再换另一个方向试试,系统也要随之不断调整,供应商的响应肯定是不够的。另外一家企业花了几万块钱,自己开发,一个月上线,用的还很好,这个也是一个架构的问题。第一家企业供应链应用不够成熟,而且,CRM跟供应链系统是不集成的,因此短期内自己无法开发O2O系统。第二家企业CRM和供应链两个系统是成熟的,而且架构好,是集成的,还有他们PC端、手机端的开发,一定是有平台的,所以在应用架构和开发架构很好的基础上,很容易搭建新零售系统。

第二个案例是智慧门店,前两年做智慧门比较风靡,我说的这一家规模很大,在北京北五环的边上,整栋楼3万平方,分3层,一层1万平方,投入也是相当大,跟一家大型的电商公司合作。那个时候我们也在考虑做智慧门店,各大电商公司都想拉我们入伙,其中一家电商公司作为案例推荐,把我们拉到北京去参观这家门店。但有一个问题,实施一年多,开业时系统对接还没有完全做好,我当时去跟IT交流,系统对接很大一部分还在手工,我完全不理解,因为像这种智慧门店跟电商对接,首先就是商品,商品价格、规格、描述这些商品基本信息;第二就是订单的对接,线上订单到线下,线下定单到线上;第三就是供应链,B端的发货和收货,配送及C端的收货;最后一个是结算对接,应该没那么复杂,我觉得用不了一年,要是架构好,一两个月就能对接完成。原来甲方企业系统本身就不集成,他们的供应链、CRM、以及自己的电商系统是相互独立的,所以跟电商公司做对接自然问题就多。

前面讲了缺乏架构的几个痛点,第一个就是走弯路,走回头路。第二个信息孤岛。第三个人多不一定好办事,最后一个就是新业务,业务转型比较难以支撑。

\

下面讲一下架构的理念和方法,第一是紧扣核心业务,IT的规划架构必须支撑核心业务,必须以业务的战略蓝图为基础,业务有三年、五年规划,根据核心业务来规划信息化系统核心应用。

第二先做减法后做加法,分布实施,这是我几十年搞信息化的经验,跟很多同行交流,很多CIO也有同感。实际上有一个浅显的道理,IT上系统是管理的改进,是管理的提升。在做信息化的过程中,业务部门提需求的时候,经常会要求一步到位,一下子上一个完美的系统,但是,实际上行不通。在上系统之前,管理水平是不高的,说不定管理水平还相当低,假如我们反过来讲,IT一步到位做好系统了,业务部门一步到位用起来了,那么你的管理水平就很高了,这是违背常理的,本来水平很低,通过上一个系统,一下子就很高水平,怎么可能呢?这是不可能的,仅仅通过一个系统,管理水平是不可能突飞猛进的。所以我们绝大部分企业,做任何系统一定是先做减法,后做加法,分布实施,但是很多企业特别容易犯这种错误。要求一步到位,不管是有意还是无意,实际是给自己挖坑。当然,也有企业能做到一步到位,比如西门子,西门子的新公司实施SAP,从顾问进场到上线,只要一个月时间,常规实施SAP一般都要7个月,但西门子就能做到一个月上线,原因是西门子的规范化、标准化做得非常到位,管理水平也已经相当高了,才能做到,全世界没几家公司能做这点,所以绝大部分企业还必须先做减法后做加法。

第二个就是平台化,前面多多少少提到这一点,我们现在很多企业现在还是用原码开发,一行行代码堆的方式,这个方法确实值得商榷。平台的优点非常多,第一个好处是开发周期短,我们的CRM系统是比较复杂的,有三四十个模块,如下图,包括PC端和手机端,在平台上开发,3个月就全部完成,然后测试,很快上线。

\

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

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

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

\

下面给大家分享的是推进的误区,第一个就是信息化只能领先管理半步,在信息化的过程中,最理想的状态就是信息化领先管理半步。就是说信息化领先管理半步,系统上线后,管理水平自然就提升半步,然后信息化系统优化改进,再领先半步,如此一步一个脚印往前走,拉动管理的改进和管理的提升。我们前面讲,要先做减法后做加法也是跟这个相关,不可能本来管理水平很低,上一个系统管理水平就飞跃提升,那是不现实的,逐步提升稳步提升才具有可操作性。

第二点跟第一点是相关的,不能一味追求完美,追去全面。当然不能怪业务部门,业务部门提需求希望一步到位,对他来说是合理的,但是作为IT来说,要合理的引导他们,告诉他们可以这么提,我们规划也可以规划,但一定是分布实施,分步上线,否则即使提供了一步到位的系统,业务部门也不可能一下子全功能使用。追求全面缺乏可操作性,现实中失败的案例太多。除非管理水平已经很高,一步到位才有可能,但是大部分企业不是那样,管理水平没有那个高度,否则信息化水平也不是这样,两者是相辅相成的。

第三点不多讲,老板说功能都买了,为啥没有用起来,实际上购买是万里长征第一步,真正有价值的还是实施过程,但实施过程是艰难的。

第四点,不是业务部门所有的需求IT都要照做,系统的补丁不能乱打。前面提到的那家定制企业案例,就跟这个相关了,他们就是完全响应业务的需求,补丁乱打,然后造成了系统的Bug太多。我们公司前期也有一个例子,我们的业务主要是零售,以前工程很少,这两年工程快速发展,今年会更多。工程的量上来之后,为了便于管理,系统对工程单的管理也要精细化,工程部门提了一个要求,一个订单分批发货,但我们现有的ERP逻辑是一个订单、一次下单,一次入库、一次发货,不能拆单,因为零售的一个订单就是一个柜子,怎么可能拆开呢?但工程不一样,一个订单几百套、几千套柜子,覆盖很多栋楼,一栋楼建好,先发一批货过去安装,甚至一个单元好了,先把这一单元的货发过去,工程这个需求是合理的。但是假如我们ERP更改拆单逻辑,不是不可能,但是一方面ERP底层逻辑的更改必须慎重,一旦改不好,就会造成系统的不稳定,二来工作量也很大,这里必须强调架构思维,ERP的底层逻辑更改,相当于对ERP动了一个中大型手术,系统跟人一样,不能随便动手术,要好好地呵护。

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

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

前面提到的那家定制公司,一开始架构虽然做的不是很好,如果后面运维有架构思维,系统每一个补丁打的都比较谨慎,都比较规范,都符合架构理念,后面也不会有那么多问题,也不需要20多个人来运维。

下面一个比较简单,线下流程不能原样搬到线上,这个大家都了解,信息化就是流程再造的过程,不多解释。

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

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

最后一个也是比较重要的,就是核心系统,不能完全依靠外部顾问,内部团队一定要有把控能力,因为对于核心的应用,核心的系统,一定支撑的是核心业务,核心业务有优化,有改进,有新需求,响应必须快,依靠外部顾问,不是总能做到。

第二外部顾问对业务的理解肯定不如我们自己人,一定是我们自己对自己的业务更理解、吃的更透,所以新的需求来了,他对需求的理解,以及解决方案的设计,一定更合理更实用。

\

架构的重点就简单带过,第一个是应用的架构,应用是分两个层面:一是总体应用规划,有哪些应用,哪一些是核心应用,什么时候实施什么样的应用,二是应用项目实施的过程中,项目本身也需要架构,项目的运维过程也要有架构。

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

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

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

编辑:田苗
关键字:     大数据  数据规划  数据架构  云服务  云应用   
活动 直播间  | CIO智行社

分享到微信 ×

打开微信,点击底部的“发现”,
使用“扫一扫”即可将网页分享至朋友圈。