取消
搜索历史
热搜词
视频
活动
创新2.0
I T
产业
当前位置:首页 >产经•城市 > 产经 > 工业4.0 > 正文
我乐家居CIO陈红:如何解决信息系统架构的痛点?
来源:ENI经济和信息化网  作者:陈红 2019-06-05 10:56:54
企业信息系统的架构要服务于企业自身核心业务,从实用性出发,从自身管理水平出发,循序渐进,分步实施,才能解决痛点,达到企业需求,建成宏伟的信息化大厦。

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

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

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端和手机端都非常好用,测评题目能随便定义,评测对象指定范围,比如经理级,上下级等可以随便定义,不但如此,连经销商都能用。这个就是有好平台的结果,主数据在前期都准备充分,比较完善,开发平台也比较成熟,所以在平台上做这么一个小应用就非常快,而且实用。

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

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

编辑:田苗
关键字:     信息化  智能化  信息系统  我乐家居  陈红   
活动 直播间  | CIO智行社

分享到微信 ×

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