|
中科软件股份有限公司是中国科学院软件所实施知识创新试点工程的产物,是研究所的技术研究及开发主体转制的结果。中科软件股份有限公司总部设在北京,注册资本金7500万元,是专门从事计算机软件研发、应用、服务的智能密集型高新技术企业,以大型应用软件开发和计算机系统集成为核心,集自主开发的行业通用软件产品、嵌入式软件系列产品、网络信息安全软件产品、大型网络应用软件组合平台和中间件软件产品及应用工具于一体,涵盖了系统软件、支撑软件、行业应用软件各个层次,并可为大型应用系统工程提供全方位支持。拥有多年从事软件工程实施、国内外合作开发及推广的丰富经验。其中,自主开发的保险行业通用软件 保险业务综合管理信息系统 是国内第一个功能强大险种管理齐全的大型应用系统,它以其卓越的功能、广阔的市场前景,于1996-1998年连续三年被中国软件行业协会推荐为优秀软件产品,1996年国家科技部等六部委授予 国家级新产品 证书。1997年获中科院科技进步二等奖,1999年获国家科技进步奖三等奖。目前这个产品及其升级版本已在全国推广使用。自主开发的行业通用软件产品还广泛涉及金融、邮政、新闻媒体、烟草和石化领域;智能大厦及智能小区信息系统得到广泛的推广应用;大型网络系统集成应用遍及众多行业;公司参与研制的铁路客票自助售票机已通过铁道部的技术鉴定,正在推向市场。
核保核赔管理是保险业为了防范风险、增强自身竞争力而提出的一种新的管理模式,它是对国内原有保险业经营管理模式的一种重要的补充。对于一个保险企业来说,实行核保核赔是其经营管理走向现代化的标志之一,是保险企业的管理体系实现以客户为中心,走向集中化管理而迈出的关键性的一步。在技术高速发展的今天,计算机和网络在保险业中的应用日益普及,大范围(例如省级单位之内)的保险业务数据在计算机上的集中实时处理已经实现。作为针对前台业务进行管理的核保核赔系统,需要有很高的实时性和灵活性,这样才能在保证对客户的服务质量不断提高的同时,又能降低企业的经营风险。
该公司开发的核保核赔系统具有如下特点:
独立性:
核保核赔管理系统是一套独立的计算机应用系统,可以单独运行,通过其数据接口与其它业务系统发生关系。
业务性:
核保核赔管理系统在管理上是和各前台业务系统紧密联系的,可以根据前台业务处理模式的变化而调整自身的功能,即保持着与业务系统的同步发展。
灵活性:
系统采用模块化设计,数据接口简单而有效,可以快速实现与任何一个前台业务系统的挂接,以及与特定的业务系统中任一险种的挂接。
实时性:
提供良好的网络支持,实现在线异地核保核赔,集中和分布式处理相结合,保证给客户提供快速、准确、优质的服务。
有效性:
同风险防范系统相结合,可以准确而高效地发现承保、理赔过程中潜在的风险,杜绝如机动车辆保险中“一车多赔”等现象的发生;通过分级管理制度,既能做到层层把关,又可以明晰职责,减少冗余环节,提高核保核赔的效率。
易用性:
核保核赔系统采用工作流的设计思想,核保核赔任务自动流转并提交至更高一级;通过声音和文字的提示,各级核保核赔员可以非常方便地获知自己当前的任务,获取所有相关业务信息,做出准确的判断、处理。
易维护性:
核保核赔系统采用工作流的设计思想,核保核赔任务自动流转并提交至更高一级;通过声音和文字的提示,各级核保核赔员可以非常方便地获知自己当前的任务,获取所有相关业务信息,做出准确的判断、处理。
于1996-1998年连续三年被中国软件行业协会推荐为优秀软件产品,1996年国家科技部等六部委授予 国家级新产品 证书。1997年获中科院科技进步二等奖,1999年获国家科技进步奖三等奖。
是不是这个公司有政府背景?
今天搜索了一下,好像还是颇有几个公司用的中科软的产品,不过,该公司的网站似乎在2003年初停止了更新。
itpub里面有人批评过其业务系统,焦点好像在于只适用于小公司。
不过,现在很多新成立的公司规模都不大。
除了规模,在其他方面,例如灵活性,是否确实有一些长处呢?
不太对! 新开发的基于J2ee架构的核心业务系统真只是适用于小公司。因为有示例:picc上海分公司只敢启用部分支公司用这套系统;大地公司现在是焦头烂额,只能升级硬件,有什么用,升级后,最多还能撑一到2年,又会主机告急。因为数据库容量和风险螺旋增长机制告诉我们,完全由oracle数据库来进行存储过程管理和大部分的逻辑处理的结果,只能是无穷尽的98%的CPU占用(haha ,也不知道分析的对否?)
但中科软的实力还是在4gl+informix ,您看PICC是不是大公司,他们的系统就是中科软的!
好像也听到过其他的j2ee的环境下被迫把部分业务逻辑移到数据库的案例,不过不是亲手参与,也不能说是否一种普遍现象。
按照中科软的官方网站,好像应该是picc青岛分公司。
嘿嘿,这个只能说明开发商的对j2ee的大规模应用还缺乏经验而已。
当然把业务逻辑都往后台数据库放的话,至少目前还是一个比较快而且稳定的做法。
如果只是依赖j2ee来处理业务逻辑,.....嘿,我看是危险....
听说现在ebao已把部分的逻辑转移到数据库端了,只是听说而已!
这个不是听说,就是这样了,stored procedure对处理大规模的数据,至少目前没有其他更好的技术方案来替代。
最初由 baoxian119 发布
[B]不太对! 新开发的基于J2ee架构的核心业务系统真只是适用于小公司。因为有示例:picc上海分公司只敢启用部分支公司用这套系统;大地公司现在是焦头烂额,只能升级硬件,有什么用,升级后,最多还能撑一到2年,又会主机告急。因为数据库容量和风险螺旋增长机制告诉我们,完全由oracle数据库来进行存储过程管理和大部分的逻辑处理的结果,只能是无穷尽的98%的CPU占用(haha ,也不知道分析的对否?)
但中科软的实力还是在4gl+informix ,您看PICC是不是大公司,他们的系统就是中科软的! [/B]
这种说法,我认为缺少根据,
但中科软的实力还是在4gl+informix ,您看PICC是不是大公司,他们的系统就是中科软的!
4gl+informix 不就是oracle+pl/sql吗?既然informix 可以支持,没有理由理由说oracle不能支撑的。至少oracle的扩展性不比informix 差不?
[B]
4gl+informix 不就是oracle+pl/sql吗?既然informix 可以支持,没有理由理由说oracle不能支撑的。至少oracle的扩展性不比informix 差不?[/B]
分析的有道理。
一种可能的情况是,在j2ee中作了一些东西以后,情况变得比较尴尬。
另外,性能除了和平台有关,还和设计有关。在同港的平台设计的系统,处理能力可能大不一样。 |
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
|