文章 - 212 评论 - 33 收藏 - 0 粉丝 - 11 访问量 - 239429

 ——连明源

在介绍协同平台的应用特点和技术特点之前,我们应该首先理解现有的各种单一系统的应用特点和技术特点,如传统的PDMSCMMESSRM以及SRM系统等等。只有这样,我们才能更好地认识协同平台和单一系统的区别。如果大家熟悉单一系统的发展历史和应用场景,应该可以得出这样的结论,那就是,绝大多数单一系统主要是以提升执行层的作业效率为目的的,所以,根据前面介绍的内容,我们不会认为 单一系统能够为企业的管理转型提供足够的技术支持。在这里,作者甚至认为,从应用特点和技术特点来看,ERPCRM这两个具有企业级流程系统特征的大型应用系统也应归入传统的单一系统类别。相信会有很多人怀疑作者的这一观点,但不管这样,我们还是先来认识单一系统的各种特点,以便展开进一步的讨论。


1 、系统架构层面的局限性

实际上,关于单一系统架构的紧耦合的特点,早已不是一个需要多费口舌的话题,这也是为什么出现中间件、出现SOA概念的最直接的原因。这里只是稍作归纳,以便针对性地给出关于协同平台架构的特点说明。简单地说,从开发方式上来说,单一系统是采用传统的编码方式完成的,在面临系统整合的需求时,单一系统必须通过开发各种接口程序方能实现系统之间的信息交互。这种紧耦合的特点,对于开发人员来说,没有任何灵活性可言。尤其是对于程序的调整和升级来说,我们必须通过解读代码本身来识别变更的影响,并据此做出繁琐的调整。由此,也可得出这样的结论,单一系统对于业务变革而言,显然没有任何灵活性可言。这种基于传统编码方式的系统架构自然属于需要逐渐淘汰的对象,代之以出现的就是基于标准组件化开发方式的系统架构,也就是所谓的面向服务的系统架构的理念。问题是,这种所谓的SOA系统架构理念似乎迟迟不能落地,这其中到底有怎样的玄机呢?关于这一点,请读者参考第七章《上层中间件的加速作用》的相关内容。


2、 系统应用层面的局限性

    关于单一系统缺乏灵活性的解释需要很多复杂的IT知识支撑,作者认为,在推动企业管理转型的过程中,我们的决策人员只需充分掌握这一事实皆可,无须对此刨根问底。但我们应该充分理解单一系统在应用层面的诸多限制作用,因为,只有这样,我们才能充分理解为什么我们一定要提出所谓企业级协同平台的概念。为了容易理解,我们不妨回忆一下自己在实际应用过程中的经验,如果大家都经常使用单一系统,则一定熟悉如下一些单一系统的应用场景,当我们需要进行相应的作业时,我们会:

  1.  手工登录所需访问的系统

  2.  手工从界面中选择需要操作的功能模块(也许是某个流程)

  3.  手工从模块菜单中继续选择操作子模块直到进入最终的操作界面(也许是某个流程的操作节点)

  4.  手工进行各种手工操作(相当于执行流程节点的各项活动,如、查询、提交、退出等)

  5.  手工选择跳转到其他模块并再次重复类似操作(转向其他业务流程操作)

  6.  手工退出系统

  7.  手工选择登陆其他所需访问的单一系统查找是否存在需要自己处理的业务

  8.  再次重复上述类似的各种手工操作

上述过程便是目前绝大多数企业IT应用的典型场景,虽然已经实现了系统化,但作业人员依然需要不停地进行人为的搜索 人为的判断和手工操作,必须不知疲倦地在不同的界面中来回跳转,或者一会儿要处理系统之外的流程节点的工作,一会儿又要处理系统内流程的节点任务,总之,你无法在一个相对集中的环境内及时完成各种协同作业任务。如你每天必须在多个单一系统中执行任务,天长日久,你一定会发现自己实际上只是一个反复点击菜单的作业机器人而已,所谓的计算机智能,对你而言,实际上只是一种子虚乌有的想象罢了。大家真正运用大脑工作的时间,实际上,非常非常有限。

如我们对上述场景进行再次抽象总结,我们可以发现大量的人工操作和人工判断时间发生在不同的业务流程节点之间,或发生在不同的操作界面之间。因为我们办公人员都有可能在不同流程的不同节点,接受上游传递过来的协同作业任务,而这些流程又是散布在不同的系统之中,或根本就没有实现系统化操作,所以我们不得不在不同的作业环境之中来回折腾,我们必须花费很多的时间进行各种无用的操作。如你对系统操作不够熟练,或你被其他事务纠缠,或因事务繁杂,你无法把握事务的轻重缓急,则稍有懈怠,就有可能发生我们多次提到的协同作业的失控问题。从管理层一侧来看,传统的单一系统,基本都不会考虑为管理人员设置专用于企业级流程监控的功能模块,这主要还不是系统技术的限制,而是由于在专业化管理时代缺乏这种监控企业级流程协同状态的强烈需求。所以,传统的单一系统的作业场景便是典型的非协同化作业场景,它是长期专业化分工演变至今的必然结果。即使是最为时髦的ERP系统,不也是这样一种作业场景吗?所以,作者从来不认为当前的很多ERP系统是一种理想的企业级协同平台,虽然,它已基本实现了把各种断片流程连接成一个完整流程的目的。所以,从实际应用效果来看,单一系统显然在提升协同管理能力方面具有很大的局限性。

 
3 、系统技术层面的局限性

请大家放心,这里介绍的技术层面的局限性,并不涉及深奥的IT概念,仍旧是从应用层面来描述的客观事实。大家一定都了解,所谓的计算机管理系统,无非是由如下几部分组成,后台的数据库、前台的操作界面以及必要的工作流。单一系统通常只有一个存储管理信息的数据库,如ACCESSORACLE数据库等。即具有单一数据库的特点。而所谓工作流,常常是一些内嵌在系统内部的审批流程,这些审批流程都只能处理单一的表单,所以,这样的流程通常只能用于特定的部门或特定的角色,至于各种操作界面,由于技术限制,单一系统的界面都是根据不同的业务需要单独编程开发的,无法实现界面的自由组合,所以也就不能随时根据业务发展的需要,为业务人员配置具有集中作业特点的操作界面。但这三者之中,数据库的唯一性是最主要的技术特点,也可说是单一系统的主要特征。也就是说,无论是工作流所处理的数据,还是操作界面所处理的数据,它们都只能流向系统内部的单一格式的数据库。如需要向外传输或发放,则必须通过定制的接口开发才能实现。总之,上述单一系统的技术特点似乎在告诉我们这样一个事实,那就是单一系统总是给人一种独家独院、孤芳自赏的感觉,缺乏一种对外开放、自由扩展的境界。这一特点,对于需要根据市场的变化,及时调整跨部门、跨平台、跨地域协同作业流程的企业来说,当然具有很大的技术上的局限性。 


4 、系统方案设计层面的局限性

我们知道,几乎所有的单一系统方案都是面向企业执行层的,也就是说,是面向不同的作业岗位而设计的,实际上,从各种已经成型的系统上,我们可以非常直观地感受到这一点。例如,虽然,很多系统的界面操作就是某个作业流程节点上的某项操作,但正如前面介绍的那样,这些操作都被分散在一个一个孤立的界面之中,好像是系统设计人员故意要为难我们执行层的操作人员一样,操作人员必须不停地点击鼠标,才能把属于自己的操作界面找出来。实际上,这是因为软件人员在设计这些操作界面时,并没有建立按角色配置集中的任务操作界面的意识,而是习惯地按业务分类进行界面设计,这样的界面开发方案显然不利于作业流程的快速流转。这是因为在这些系统方案的设计目标中,主要考虑的是作业本身,即考虑的是流程中某个“点”的作业方式,并没有把流程的流转方式、业务协同方式以及过程控制方式作为主要设计对象。另外,有些不同界面的操作之间具有相互传输数据和交接任务的作用,本来这种节点之间的信息交互,一般都有时间上的紧迫性,但不知是什么缘故,传统的设计方法却总是无视这种对于流程之间的信息交互服务功能的设计需求,所以单一系统在信息协同方面具有很大的局限性。当然,更普遍的问题是,单一系统的操作界面都是从一开始就被固化了的,缺乏根据流程作业内容进行功能配置重组的灵活性,为此,当业务内容变化时,业务人员不可能期待业务系统也能随之变化,只好暂时通过调整系统外的作业内容来解决问题了。

总之,以上单一系统的局限性主要体现在流程作业的交接方式和信息协同方式方面,同时又缺乏应对业务变革的灵活性。所以,根据前面我们讨论的内容,我们应该清楚,单一系统对于企业管理转型的推进作用是十分有限的,尤其是对于十分重视信息系统能力升级的大型企业而言,单一系统在技术上的局限性,确实是一个亟需解决的难题。


更多信息请关注:www.china-soa.com

发表于: 2014-08-19 15:06 阅读(570) 评论(0) 收藏 好文推荐

发表评论(网友发言只代表个人观点,不代表本网站观点或立场。)

您尚未登录,请先【登录或注册