转载我在QQ上跟人讨论的有关集成的话题,供大家批评指正

标签:集成

访客:28192  发表于:2013-06-27 10:33:36

未经对方许可,所以多少有点不厚道,我只贴我的一些观点上来,并简述对方的问题吧。

对方所在公司,所处的行业是非传统行业,目前在尝试做集成时遇到了一些商务与技术问题,他们自己也有了一些想法,比如想搭建一个基础平台,也想做审批流的集成,想让我给点建议。我说我能力有限只能出些馊主意,于是就有了下面的观点:

”昨天的问题,我说说站在我的角度上的看法吧
我一般把集成分为3个层面,即业务集成,数据集成,系统集成。业务集成可以不意味着真正的系统层面的交互,比如一个OrderToCash的端到端业务流程,可能会跨越至少2套系统,必须销售与财务核算,这种情况只要处理好不同关节节点的输入输出,即可比较顺畅的完成这个业务流程,未必一定要进行系统交互,当然系统交互有很多优势,也可避免很多风险。所以业务集成或者叫业务串联是一切系统集成的基础;
数据集成往往建立在业务集成的基础上,还是拿上面的案例举例,从简化操作、规避风险的角度出发,让销售系统中的Shipping、Invoice等自动生成为财务核算系统中的AR凭证,并且实现交互,这时业务流程中的数据流输入输出将更加清晰且规避了人为操作失误的风险,提升效率等等,目前大多数系统层面的集成是体现在类似这种关键业务数据交互的基础上,实现起来也不是很困难,无论是商务层面还是业务层面,但费用是一定会有的;
系统集成其实我觉得是一种理想的状态,或者说在实现了业务集成与数据集成基础上才考虑,比如在统一的平台上管理供应商及客户,其他业务系统只是调用等等,这种情况,不可否认是对业务流程的执行有利的,但实现起来局限性很强,除了要有合适的产品,技术层面更是要厂家提供核心层的东西,总之成本很高。
所以,你们说集成,首先要想清楚为什么要集成,集成到哪个层面。非普通行业,注定ERP级的集成应用不会是主流,主流可能是核心业务应用+通用职能应用,比如一套或者几套农业业务系统+财务核算+人力资源+OA,比较理性的做法,是先梳理业务流程进而做到业务层面的集成,选型时考虑好未来的数据级集成的计划,有针对性的增加选型的条件,比如开放API等等。
最后说说你说的基础平台、BI、工作流等等。我猜想你说的基础平台更多层面上的目的是主数据共享甚至业务信息发布,比如流程审批,这个可以有,就是实现起来比较复杂,后期很可能会陷入开发的死循环,我不确定世面上有很成熟的产品;BI这个,从业务分析的角度出发,通常的数据库是OLAP的,更多的是提炼不同业务系统的业务数据然后进行分析与展示,当然大前提是业务层的集成,数据口径的统一;工作流的统一,可以考虑BPM产品,贵的K2,便宜的G2;最后,系统交互与集成不要直接数据库层的直接交互,就算有回滚机制也不行,需要利用中间件产品,比如基于ESB的Oracle Fusion。

最后说,这个投入真的不低,千万级是有的,给我的感觉是可能还没想好如何着手去做,而集成可能是一个大目标,这个目标也需要有计划的分级实现,往往集成的一大阻碍除了商务上,还有业务成熟度的问题。如果是我,我会比较理智的看集成。”

摆出看法之后其实我心里没啥底,系统集成是个大的话题,每个人的角度与思路都未必一致,出于对对方负责的角度,想跟大家简单讨论一下,博采众长。争取能最大限度帮到对方也帮到自己。

评论(4)

您可以在评论框内@您的好友一起参与讨论!

<--script type="text/javascript">BAIDU_CLB_fillSlot("927898");