科技工作业务流程描述

2024-05-10

科技工作业务流程描述(通用8篇)

篇1:科技工作业务流程描述

一、业务流程定义:

该流程描述了科技项目(科技活动、新产品开发项目、产品标准管理等)的制订、审批、执行、管理的整体流程。

二、业务流程图:(见附图)

三、业务流程描述:

1.1投资部根据市科技部门和集团领导的要求,收办有关的科技活动通知、制定相应的工作计划。责任人:投资部经理

1.2分管领导根据通知或计划内容,确定是否需要进行该科技活动或项目。责任人:集团分管领导

1.3下属企业根据科技活动通知或科技工作计划,布置相关工作,填写有关材料。责任人:企业分管领导

2.1投资部在限定日期内,对下属企业整理的科技活动材料或计划进行汇总,同时排出集团整体工作安排。责任人:投资部经理

2.2分管领导对详细的科技计划内容进行审核,同时对整个活动或项目进行批示,确定内容、资金、时间进度等。责任人:集团分管领导

2.3投资部对批示后的材料进行备案登记,同时将有关材料报市科技部门审核。责任人:科技主办

2.4市科技部门对集团上报材料进行审核,给出审核结果。责任人:市科技部门负责人

3.1下属企业具体实施通过的科技活动或项目。责任人:企业分

管领导

3.2投资部负责对整个实施过程进行监督,确保按计划内容和进度完成活动或项目。责任人:科技主办

3.3市科技部门对活动或项目结果进行考核评定,提出有关考核意见。责任人:市科技部门负责人

4.1投资部根据市科技部门的反馈情况,在集团范围内进行工作总结,同时向分管领导、下属企业、市科技部门进行工作汇报,宣布此次活动或项目结束。责任人:投资部经理

篇2:科技工作业务流程描述

1)收集将定稿的核心资料连同需要递交的资料交接给文案部,文案根据收集整理的递交资料清单安排翻译; 2)文案开始填写表格,整合要递交的一套中文素材给组长审核,并根据审核意见修改; 3)文案将一套中文素材给Melvin审核,并根据审核意见修改资料(有时候需要收集修改核心资料)4)文案跟收集确认客户费用到账后,安排房评、购汇 5)文案检查客户的签字文件

6)文案检查返回的公证翻译,打印整理,待客户费用到账后安排公证;待公证返回后检查公证书,安排相应修改; 7)文案检查返回的非公证翻译,打印整理;

8)文案校对收集制作的报表,并且制作审计报告附注,安排翻译并检查,待客户费用到账后安排出纸质报告;

9)文案检查返回的房评电子版,安排出纸质报告;

10)文案将需要递交一套中英文资料整合好,安排复印留底、递交、归档,并负责收集齐第三方票据转交给收集同事

二、安排翻译:(公证类翻译5至7个工作日内完成,非公证类翻译10至15个工作日内完成)

1、根据收集同事的递交资料清单将需要翻译的资料按照公证和非公证分类,列翻译清单;

2、将需要翻译的资料拿给复印同事(现为行政部的Sophia)安排复印;

3、将复印好的文件整理好,每份文件用曲别针装订整齐,连同翻译清单一起,拿给翻译部主管Seven(请务必确认无缺页或漏掉复印的文件)

4、翻译部同事会将翻译好的中文材料返回给收集人员,相应的英文翻译件放在192.168.0.1shareSe7en 戚丽媛,将检查后的英文翻译件打印出来,放在相应中文文件的上面

5、一个客户的所有翻译都完成后,需要及时跟Seven确认最终的翻译费金额以及翻译费明细,开具翻译费发票(需要收集同事提前跟客户确认发票抬头),收集同事会跟客户结算费用 备注:一般情况下翻译需要安排两次以上,要求大家每次安排翻译的时候都需要列一份翻译清单,每次返回的翻译件都需要跟清单核对,避免遗漏。

文案递送材料注意事项 1.递送文件前,请务必确认无缺页或漏掉复印的文件 2.涉及到客户公司名称的文件,如营业执照等,请务必确定客户公司是否有英文对应名称,如:官网,公司章,名片。或文案填写申请表时,是否已经有明确的公司翻译,如有请在递交材料告知翻译部 3.请将材料公证与非公证文件分开 4.每份材料请务必用曲别针别好,以免材料太多发生丢失或日后漏翻现象 5.每份递送翻译部的文件请贴上标签,须注明:客户姓名(+配偶姓名)-所做项目-文案英文名称(所属部门)6.若查询翻译进度,可进入共享192.168.0.1shareSe7en 戚丽媛翻译流程表(流程表每天不定时更新)7.查询校对进度,可进入192.168.0.1shareSe7en 戚丽媛翻译部工作流程 查看翻译部组织结构图。8.如果翻译部的文件返回文案手中,文案人员进行了最后校审,请务必替换一份至192.168.0.1shareSe7en 戚丽媛 ;以免日后再次翻译该客户文件发生同样问题导致重复修改,谢谢!9.客户翻译工作结束后,若需开具发票,请到财务部领取翻译费开票通知书,自行填好对应信息找翻译部主管签字完后,交还给财务部即可。

三、填写表格:参照《魁省申请表填写指导》、《联邦申请表填写指导》(魁省表格半个至一个工作日内完成,联邦表格一个半至两个工作日内完成)

四、五、安排房产评估:(电子版报告4个工作日内完成,纸质版报告7个工作日内完成,待客户第三方费用到账后再安排)

1、安排房产评估需要的资料清单:

《房屋所有权证》复印件(请务必扫描清晰,页数齐全)《国有土地使用证》复印件(如有)

《商品房买卖合同》复印件(有土地出让年限)【购房发票】复印件 【契税票】复印件

【委托方的身份证(或户口本)】复印件,结婚证复印件(如果跟配偶共有的话)。中文素材一套整合:7个工作日内 【共有权人的身份证(或户口本)】复印件 【共有权证】复印件(有所占比例)有出租的,请提供【租赁合同】

有贷款已还清的,请提供还清证明复印件

房屋照片:

小区环境照片一张(如有小区名称,一并照下)楼号照片一张 单元门照片一张 居室门照片一张

各房间照片(客厅、卧室、卫生间、厨房等各一张)

2、填写“审计、评估通知书”(需要收集同事提前跟客户确认发票抬头),经主管签字批准后,把通知书交给财务部负责同事(现为Catherine杨燕)

3、将房产评估所需要的资料扫描,将房屋照片集中放到一个word文档里,再建一个word文档写明房评注意事项(如房产评估值的要求、贷款是否还清、报告出具时间要求等),一起放入Catherine的共享里,注:如果资料里缺少某些文件,请先跟Catherine确认该文件是否一定需要,再酌情跟客户沟通。

4、房产评估所收到资料后,会按要求出具评估报告电子版,Catherine会将电子版发给文案同事

5、文案同事仔细审核电子版房产评估报告,如果发现错误信息需要改正并标注,并把改正后的电子版发给Catherine。改正后,事务所会再次发电子版给我们,检查无误后,安排出正式纸质版报告。正式报告返回后,也要检查一下,看是否有错,有的话,也要及时给Catherine安排更改

6、注:有时候在安排正式房评前需要先了解该房产的大概市值情况,可以让事务所做一个预评估,按按以下格式填写房产信息(尽量填写完整),发给Catherine: 询问评估值格式样本:

客户姓名:***(魁省or联邦)房产1:

具体地址:某省某市某区41号2栋1单元10室 小区名称:某某小区 房屋面积:**平米 购买时间:**** 购买价格:总价:***万,单价:***万 房屋类型:住宅/商铺/写字楼 车库:有/无

贷款:有/无,是否还完清 租赁:有/无,租金多少钱 周边小区、商场等名称:

六、购买汇票(待客户第三方费用到账后再安排)

1、客户汇款后,收集同事需要跟财务部负责同事确认款项是否到账(现为Sunny),并及时通知客户和文案同事。

2、文案同事在确认客户费用到账后,填写“购汇票申请书”,经收款人(一般为收集同事)签字、主管签字批准后,将购汇票申请书交给财务部负责同事(现为Judy)

3、案子递交之前,从Judy处领取汇票原件

七、检查客户的签字文件

1、魁省需要客户签字的文件有(此处基金文件指国民银行):

a)主申请人和配偶申请表格:P13(主申请人、配偶和18岁以上子女在同一份表格上签字)和P14(主申请人和配偶在同一份表格上签字)b)22岁以上子女表格(如有):P5(22岁以上子女签字)和P6(22岁以上子女和主申请人在同一份表格上签字)c)基金协议:P8(主申请人签字在Investor’s Name处签字,需要签3份)

注:这份文件需要基金公司和客户两方签字,一般基金公司会先把他们签好字的P8快递给我们(在主管处领取),我们直接让客户在基金公司已签好的P8上签字即可 d)自述书(Narrative Document):中英文的最后一页(主申请人和配偶各签一份)

注:如果申报了配偶资产,配偶也需要提交ND e)基金授权书:P2(主申请人在Investor Candidate’s Signature处签字,需要签3份)

注:witness处需要我司收集人员签字,permanent address填写我司地址 f)律师授权书:P2(主申请人在Signature of the mandator处签字,最好签2份)

g)附件配偶声明:只需填写Declaration by spouse部分,主申请人在Signature of the principal applicant处签字,配偶在Signature of the spouse accompanying the principal applicant处签字 h)前配偶不反对子女移民的声明(如有):前配偶签字 i)魁省基金附件(国民银行,一般称Appendix 4):主申请人在Investor Candidate’s Signature处签字,需要签3份

如果子女已经独立,不需要单独填表,也不用准备签字文件 j)

2、联邦需要客户签字的文件有:

1)Schedule 1:P4(主申请人、配偶和18岁以上子女各签一份)

2)5406家属表:主申请人、配偶和18岁以上子女各签一份

注:Section A下面的签字是填表人确认没有配偶时才需要签;Section B下面的签字是填表人确认没有孩子时才需要签;Section D是确认签字项,填表人必须要签字。3)Supplement to Schedule 1:配偶和18岁以上子女各签一份

4)5476代理表:P2(主申请人和配偶在同一份表格上的Section D部分签字,第一个方框主申请人签字,第二个方框配偶签字;18岁以上子女单独填表单独在Section D部分的第一个方框签字)

注:这份文件需要代理(现在是佟炜)和客户两方签字,一般佟炜签好字的P2会先快递给我们(在主管处领取),我们直接让客户在佟炜已签好的P2上签字即可 5)宣誓书:中英文的最后一页(主申请人和配偶各签一份)

6)基金IA(Investor’s Acknowledgement):主申请人在Signature of Investor处签字,需要签3份 注:这份文件需要基金公司和客户两方签字,一般基金公司会先把他们签好字的IA快递给我们(在主管处领取),我们直接让客户在基金公司已签好的IA上签字即可 7)前配偶不反对子女移民的声明(如有):前配偶签字 8)不随行家庭成员声明(如有):主申请人签字

9)如果子女已经独立,不需要单独填表,也不用准备签字文件

3、将需要客户签字的文件打印出来,在需要签字的地方贴上标签(如:请XX先生签字、请XX女士签字),快递给客户签字

八、安排公证:(10至15个工作日内完成,待客户第三方费用到账后再安排)

1、每份需要公证的文件都先准备三份中英文复印件,每份复印件都是中文在上英文在下的顺序,分别用曲别针别上,把三份复印件用曲别针或小夹子固定在一起,以免和其它文件混淆。做无罪、未婚及没有出生医学证明孩子的出生公证时,填写单子,注意单子上一定要盖有红章,否则公证处不给做公证,另外做未婚公证时需要3张照片。

2、在每份文件首页用便签纸写明需要公证的内容,以便公证处准确的出具公证词。一般需要公证的内容有:复印件和原件内容一致;中英文相符;XX章属实或XX签字属实。(注意章的内容要与文件上的完全一致)

3、将需要公证的文件和公证词都准备好后,把需要公证的文件清单和相应金额填在递交公证申报表(需要收集同事提前跟客户确认发票抬头)上,经收款人(一般为收集同事)和主管签字后,与相应的文件一起交到行政部负责同事处(现为Minas),由Minas统一送到公证处。

4、公证做好后,Minas会返回给我们一式两份的公证书,我们需要检查两份公证书的复印件是否完整无误,中英文的公证词是否正确,中文公证词的落款是否有公证员和公证处的章,公证书上是否有公证处的钢印,如有问题及时让Minas拿到公证处修改。修改公证书时,不需要填写单子,只需把需要修改的公证书及要修改的内容交给行政部的Minas即可。备注:一般情况下,公证需要安排两次以上,要求大家每次安排公证的时候都需要列一份公证清单,每次返回的公证件都需要跟清单核对,避免遗漏。

九、安排审计:(中文电子版报告2个工作日内完成,纸质版报告7个工作日内完成,待客户第三方费用到账后再安排)

1、将报表制作思路填入审计报告审核checklist中(收集负责处理)

2、参照模板,修改正文及附注

3、中文报表及附注准备好后,按分组安排校对,校对人填写审计报告审核checklist中的校对记录。按照校对记录修改中文一套

4、中文一套完成后,安排翻译部进行翻译

5、翻译返回后,仔细检查。中英文一套检查好以后,填写“审计、评估通知书”(需要收集同事提前跟客户确认发票抬头),经主管签字批准后,把通知书交给财务部负责同事(现为Catherine),并将一套电子版审计内容发至Catherine邮箱yangyan@globevisa.com.cn

6、正式报告返回后,也要检查一下,看是否有错,有的话,也要及时给Catherine安排更改。

十、安排基金出Broker Statement(BS,基金声明)-魁省

1、通知组长需要安排出BS,并将以下资料交给组长:申请表、ND的复印件,客户签好字的基金协议、基金授权书原件,填写好的BS样本(空白的BS模板在组长处领取)

2、组长将需要签BS的客户资料整理好之后拿给客户支持部同事,同时告知需要基金公司过来签BS的时间。

3、组长将基金公司签署好的BS交给文案负责人员,文案负责人员需仔细核对,如有问题及时返回给客户支持部安排修改。组长负责登记每次签BS的客户名单。

4、如果基金公司那边时间安排不了,可以直接把整套案子,连同三份基金协议、基金授权书、Appendix 4的原件一起快递给Mandeville律师那边,由他们直接安排签BS并递交案子。(此条仅适用于国民银行)

5、注意:客户在基金协议上的签字日期要比基金公司的签字日期提前至少5天,但可以跟表格签字日期不是同一天;基金公司的签字日期要比递交案子日期提前至少5天,但要比表格签字日期晚。

十一、安排基金填写IA的签字日期-联邦

1、通知组长需要安排基金来签IA上的日期,并将以下资料交给组长:所有表格、PA护照(需要写上truce copy字样)的复印件;基金IA的原件三份

2、组长将需要签IA日期的客户资料整理好之后拿给客户支持部同事,同时告知需要基金公司过来签IA的时间。

3、组长将基金公司签署好的IA交给文案负责人员,文案负责人员需仔细核对,如有问题及时返回给客户支持部同事安排修改组长负责登记每次签IA的客户名单。

4、如果基金公司那边时间安排不了,可以直接把整套案子,连同三份IA原件一起快递给Mandeville律师那边,由他们直接安排签IA并递交案子。(此条仅适用于国民银行)

5、注意:客户在基金IA上的签字日期和表格上的签字日期要比基金公司IA日期提前至少5天,基金公司日期要比递交案子日期提前至少5天。

十二、审核、修改(4个工作日内完成)

十三、递交、留底(递交后3个工作日内完成)

1、将需要递交的文件复印一套留底,一定要注意留底的文件跟递交的文件是一致的,并且是清晰的;

2、将需要递交的文件装订整理好,注意整齐美观。整套文件装订整理好之后拿给客户支持部负责同事,由她们负责递交。

3、将留底资料扫描,并将扫描后的资料打孔,放入黑色档案夹中,在标签上写清楚文件内容(如:XXX魁省留底,XXX联邦留底,XXX魁省第一次补料留底,etc)。

4、将案子制作过程中涉及的该客户电子版资料以及留底资料扫描件按照按表格、翻译、房评、费用清单、管理文件、核心文件、签字文件、扫描留底、其他分类,建一个以该客户姓名为文件名的文件夹,按照所申请的项目放入:192.168.0.1魁省联邦留底$

5、案子递交之后,需要单独整理一套给基金的资料,准备好之后用活页袋装好,交给客户支持部负责同事

魁省:申请表、BS、ND、PA护照的复印件;基金协议、基金POA、基金Appendix 4的原件各一份

联邦:所有表格、PA护照(需要写上truce copy字样)的复印件;基金IA的原件一份

注:

1)北京联邦案例较少,此处不予详细说明。文中所示联邦均指香港联邦。

篇3:小额贷款审批业务流程的服务描述

1 小额贷款审批流程的特点

在小额贷款审批流程中, 贷款申请提出贷款申请, 贷款审批者接收申请后, 首先进行贷款资格审核, 如果符合要求, 则继续对申请者的信用资质进行审核, 否则, 将返回不通过信息给申请者。对于信用资质符合要求的申请者, 则需要进行贷款额度, 利息, 期限, 预付款数量的试计算, 并将结果返回给申请者。具体地说, 小额贷款审批业务流程包括贷款申请, 贷款资格审核, 信用审核, 贷款决策, 返回结果等活动。如果贷款资格审核或信用审核没有通过, 流程都将直接结束。从流程描述可以看出, 小额贷款流程具有以下特点:

(1) 需要调用外部系统所提供的资源, 如信用审批活动中所需要的信息就来自于相关的信息征集单位。传统的数据征集方法是由信用提供者定期提供定量的通过专线提供信用信息, 则审批时间就会大大加长。

(2) 流程参与者角分散, 小额贷款流程的参与者有贷款申请者, 贷款审批者, 信用提供者等角色, 来自于不同的单位, 使用不同的操作系统, 这就造成了小额贷款审批所使用的信用数据来自于不同提供者, 数据来源的分散, 数据类型和数据格式很难得到统一, 造成了很大的工作成本。另外, 来自于不同单位的业务流程也很难协调。虽然中国人民银行公布了企业和个人征信数据元标准, 将征信系统中所使用到的一些数据列举出来作为标准数据, 但是由于信用征集对象复杂, 信用的提供者并不一定能够及时的提供相关信息, 这就是造成的信用信息的不准确和提供的不及时。

因此, 小额贷款流程需要协调来自于不同系统的资源, 在最短时间内, 完成审批活动, 才能最大限度地满足客户的要求。基于面向服务的观点, 可以将某项业务看作是服务的组合, 并且借助服务注册与查询等技术, 使服务成为可以在互联网上直接使用的公共资源。随着Web 3.0技术, 越来越多的服务可以注册到网上, 个人征信数据元标准的公布, 解决了基本信用数据名称和格式上的一致, 面向服务和Web Service等技术的成熟, 使用者可以方便的方位服务资源, 增加信用数据的准确性和访问及时性。而小额贷款审批活动的特点也决定了贷款流程适合采用面向服务架构。

2 相关技术介绍

本文所涉及到的技术为WSDL和BPEL语言。WSDL是用XML编写的网络服务语言, WSDL是在具有Web Service的基础上, 以一定标准的格式, 来描述某个Web Service, 如规定服务的位置, 描述此服务提供的操作, 使之可以在服务SOAP标准协议的框架下, 注册到服务中心, 由服务使用者调用。WSDL文档利用等元素来描述某个Web Service。指示服务同外部资源的接口, 可定义服务包含的活动;指示服务所使用的各项信息, 如输入信息和输出信息;定义服务中所使用数据的数据类型。为服务所绑定的SOAP协议。

BPEL用于指定基于Web服务的业务流程行为。BPEL提供了一种XML注释和语义, BPEL通过指定顺序来编排Web服务, 这对服务集合的调用来说意义深远。BPEL使用合作伙伴的交互方式, 针对每个服务分配了合作伙伴的责任。合作伙伴可以将服务提供给流程, 也可以向流程请求服务, 或者参与到流程的双向交互中。您可以使用它来描述指定合作伙伴的公共接口和可执行流程的。根据使用需求, BPEL有很多中类型, 现在应用比较多的BPEL4WS语言。在BPEL中, 服务按照调用顺序被排列在标记内。同WSDL一样, BPEL通过标记来定义流程中所使用的变量。在BPEL中还定义了标记来标识输入和输出服务。并且通过来激活服务。BPEL还提供了来完成服务之间的条件判断, 循环等顺序操作。BPEL也可以通过捆绑相应的协议, 注册到互联网上, 并通过流程驱动引擎等流程管理工具调动相应的服务。使用者只要可以上网, 就可以完成流程的使用。

3 服务建模

服务是为满足用户的使用需求, 对业务活动和数据的封装。使用者不需要知道服务的具体内容就可以像使用产品一样使用服务。这样就增加了服务的可重用性和可组合性, 降低了系统开发的成本。

通过第2小节的描述可以看出, 小额贷款审批流程包含以下活动。贷款申请, 贷款资格审核, 信用审核, 返回结果。小额贷款审批流程在客户端接收使用者输入的指令, 查找并激活其它系统所提供的相关服务, 通过对返回值的分析, 最后得出结果, 决定是否放款或放款的金额, 利息等。小额贷款审批流程的参与者众多, 从使用角度可将其划分为贷款审批员, 贷款申请者, 还有与之交互的其它系统。贷款申请者提交贷款申请, 贷款审批员接受申请后, 在其它信用提供系统中查询信息, 经过处理, 得出贷款金额。不同的参与者希望使用合适的服务来满足需求。根据服务的范围最小原则, 可以将小额贷款审批流程概括分别是贷款申请, 贷款资格审核, 信用审核, 信用提供 (不同信用提供者的信用提供服务接口相同, 因此可以视为同一个服务) , 返回结果等5个服务。贷款申请服务接收并处理输入信息, 审批流程由贷款审批申请活动触发。

(1) 贷款申请服务

贷款申请活动的主要作用为接收贷款申请信用。贷款申请信息指示出贷款对象的基本信息, 包括贷款者姓名, 身份证号, 贷款金额, 贷款用途等。将其用LoanRequest表示。

(2) 贷款资格审核服务

贷款资格审核是贷款系统自身所提供的服务, 贷款资格审核是根据贷款申请信息, 调用贷款者详细信息, 如企业规模, 企业资产情况, 用款项目等内容, 在根据预设的资格评价指标, 对贷款者自身信息和项目信息进行审核, 如果审核通过, 则触发信用审核服务, 如果没通过则触发返回结果服务。贷款资格审核为同步服务, 因为向资格审核服务传送申请信息, 触发资格审核服务, 审核完成后, 返回结果, 只有审核成功后, 才启动后续服务。

(3) 信用审核服务

当贷款资格预审通过后, 则调用信用审核服务。信用审核服务需要使用外部信用提供者所提供的信用信息。经过对信息的审核后, 返回结果。信用审核服务为异步服务。因为信用审核需要调用外部系统所提供的服务。而信用提供者并不只局限于一家, 因此并不一定要等待所有的信用提供者返回结果, 才进行下一步操作。信用审核服务的输入信息为

Credit Check Request, 返回信息为CrediAuditResponse。

(4) 信用提供服务

信用提供服务为外部信用提供者供应。由信用审核服务所调用, 主要返回根据信用审核服务所提供的信用查询信息。信用提供服务的输入信息的CreditRequest, 返回信息为CreditResponse.。

(5) 返回结果服务

返回结果为信贷管理系统所提供的服务, 根据贷款资格审核信息和信用审核信息, 返回是否允许贷款信息, 同时计算出贷款金额, 还款年限, 批次, 每次还款的本金和利息等内容。返回服务的输出信息为LoanResponse。

3 BPEL流程描述

从以上服务模型中可以分析出来, 小额贷款流程是一个包含条件判断的顺序流程。因为组成业务流程的基本单位是服务, 对于服务的描述是业务流程表示的第一步, 我们以贷款申请服务的描述为例, 来表示贷款流程的基本服务。

从上边贷款申请服务的WSDL描述中, 可以看出该服务中处理消息为”LoanRequest”, 并且提供”LoanRequest”服务。

BPEL是通过服务组合起来, 服务之间具有激活关系, 并通过接口传递信息。以下服务内容类似。根据BPEL4WS的语法规则, 我们将小额贷款流程描述如下:

5 结束语

通过以上内容, 本文使用BPEL语言描述了小额贷款审批流程。该流程可以自动调用贷款的申请处理, 信用查询等操作, 将流程本身所提供的服务和信用提供者所提供的服务用网络可以理解的语言表示出来, 再通过BPEL流程引擎调用服务组合, 则可跨越系统和数据格式的限制, 完成跨系统的服务调用。但是也涉及到如下一些问题, 比如BPEL现在还不是W3C标准, 虽然得到了Oracle和IBM等厂商的极力推广, 但是由于标准, 价格, 技术等条件的限制, 还不能在广大服务使用和提供者中普及, 但是随着Web3.0技术的推广, 标准的完善, 一定会得到广泛的应用。

摘要:基于SOA思想, 使用BPEL和WSDL等面向服务语言, 定义并描述小额贷款系统中的相关流程, 并建模服务, 使系统能够调用不同的角色提供的服务, 为贷款流程的跨系统工作提供一定的技术基础。

关键词:流程,服务,BPEL,WSDL

参考文献

[1]RogerL.Costello..]BPEL实例教程.http://www.ibm.cn/developworker

[2]迟国泰.个人信用卡信用风险评价体系与模型研究[J].同济大学学报, 2006 (4) :557-559

[3]夏虹.基于概念格的语义Web服务匹配研究[J].北京邮电大学学报, 2006 (6) .

[4]陈湘丽.商业银行信用风险的测度框架研究.武汉理工大学学报, 2008 (9) :165-168

篇4:组织间流程结构及描述模型研究

关键词:组织间流程;组织间关系;业务流程;流程集成

一、 引言

企业的经营核心包含多种要素,如业务流程、员工、组织结构和策略,而其中最重要的要素就是业务流程。詹姆斯·钱匹认为,尽管其它三个要素也是十分重要的,“…但是,其重要性最终应取决于作为整个业务流程的补充所能发挥的作用。从长期的观点来看,业务流程决定了企业的价值”。为了使组织在变革的环境和激烈的竞争中获胜,管理者不能再仅仅从职能的角度去看待组织,还需要从流程角度去分析组织。根据Davenport的以活动为中心的流程理论,可以把业务流程定义为:一系列逻辑相关的为取得预定业务目标的可执行任务(也可称之为活动)。从这个定义来看,流程建模包含有两部分的内容,其一是流程描述,即从整体上对整个流程的组成活动以及活动之间的逻辑顺序进行定义;其二是制定流程在执行过程中遵循的各种规则,根据预先制定的这些规则,可以动态地改变流程的执行路径。

以上有关业务流程的定义,是在过去业务流程主要由企业独立运作的背景下得出的。随着电子商务的发展以及外包业务的迅猛增加,全球一体化运作的趋势日益普及,人们对跨越组织边界的业务流程进行管理的需求越来越紧迫。从20世纪90年代后期开始,出现了在组织间合作关系背景下,为了实现创造共同价值,将若干关联组织的业务流程集成为公共的组织间流程的发展趋势。组织之间的合作关系又简称为组织间关系,而组织间流程则描述了合作组织之间彼此依赖的公共活动。参照Davenport对流程的定义,我们将组织间流程理解为:由若干合作组织业务流程集成而来的,一系列逻辑相关的为取得预定共同业务目标的可执行任务。

由于合作组织具有产权独立和地理分散的特点,组织间关系始终运行于一个动态的、分布式环境中。组成组织间关系的若干拥有各种异构信息资源的独立实体,从组织结构上看是对等的,为了合作,他们通过不断地交换活动信息来实现协调运作。传统的中央流程控制模式适合于一个单独的企业,尽管组成流程的任务可能是分布式的,即企业的整体流程由分布在各部门的多个子流程组成,但是在流程最高管理层存在一个中央流程引擎,负责统一规划、协调和同步每个子流程的任务组成和执行步骤。而在组织间流程管理中,参与流程合作的各成员组织不可能采用中央流程管理模式,因为他们各自的流程不仅隐藏在防火墙后面,而且由于各个组织是高度自治和自利倾向的,出于信息保密的需要,他们并不愿意共享所有的流程信息。因此,组织间流程必然是基于流程集成的松耦合的协同流程结构。

二、 组织间流程的特征

由于组织间流程的出现为流程管理研究开启了崭新的视野,许多研究者开始对组织间流程的特征进行研究。为了实现成员组织业务流程协同的目的,Dayal等人认为,组织间流程必须具备若干特定功能:为了保证业务流程的集成,需要为所有成员组织建立一个统一的和标准化的协同交互平台,即存在一个公共的被所有成员组织认同的业务流程元模型及流程描述语言;为了使成员组织更容易理解公共流程的运作,需要建立一个公共的流程描述机制;为了便于成员组织相互了解和参与流程执行,需要建立一个传递和搜索成员组织相关信息和技能特点的信息发布机制。再从实施过程来看,组织间流程管理具有以下几个方面的特点:

(1)要求有一个协调机制,使所有参与者对流程的定义和执行达成协议,如业务流程描述、数据交换格式。为此,需要建立一个公共的、标准的流程数据库。

(2)具有一个划分子流程的流程管理功能,能够在地理分布的流程执行者中起到协同作用。

(3)每个成员组织独立地决定他愿意在公共流程中扮演的角色,设计相应的角色流程定义以及执行控制方式并向所有成员发布。

(4)每个成员应该有一个用来规划、拆分和控制它所承担任务的协同流程管理器,其目的是在他所承担的公共流程部分和其内部流程之间进行协调。此外,不同成员之间还通过各自的协同流程管理器进行互操作,如交换流程数据、彼此通知各自的流程执行进展情况等等。

在实际应用中,供应链合作联盟是最常见和最广泛的组织间关系。为了促进上下游企业的有效合作,必须在供应链合作组织中建立能够良好运作的组织间流程,为此,一些研究者通过对供应链联盟组织的合作过程进行分析,来研究组织间流程具有的特征。例如,Rupp和Ristic在研究解决牛鞭效应问题时认为,为了有效减少库存和提高运输效率,合作企业之间需要建立紧密的合作关系,这种合作关系必须建立在各成员企业的业务流程高度集成的基础之上。然而,组织间业务流程的集成问题远比组织内部分布式流程管理问题复杂得多,流程集成过程中还存在许多问题有待解决。以供应链为例,组织间业务流程的集成过程必须解决的问题有:

(1)改进信息通讯效率。组织之间的合作首先要求能够迅捷、清晰地传递各种信息,为了提高信息交换的时效性和减少信息理解的歧义性,要求在组织之间传递的信息结构尽量结构化。

(2)减少信息不确定性。供应链上游企业需要从下游企业获取市场需求变动信息,由于牛鞭效应的存在导致信息失真加剧,产生极大的信息不确定性。与之类似,组织间关系中成员组织也需要从其它伙伴组织获取信息,大量二手信息的存在使每个成员组织都处在较大的不确定性环境中。因此,组织间流程集成时必须提高信息的准确性,减少信息不确定性。

(3)支持异构信息技术环境。由于过去几十年信息技术的发展非常迅速,而成员组织的营运经历又各不相同,他们独自建立的支持业务流程的信息技术环境存在较大差异。为了保证信息交互的有效性,要求在流程集成过程中解决信息技术异构的问题。

(4)建立开放和动态的结构。组织的经营过程是一个动态的过程,如果只支持一个固定的流程模式是没有意义的。组织间流程的运行环境比组织内部流程的运行环境更加复杂,在实施中更加动态易变,外界因素对任意一个成员组织的影响都可能给组织间流程的运作产生新的变化,导致整个组织间流程不得不进行调整甚至重新设计。因此,组织间流程要求能够支持动态变化,在变化发生时,以最小的代价重新配置整个系统。同时组织间流程需要具有一定的开放性,以便能够容易地接纳新成员,或者加入到其它网络中。

此外,在运作层,Liu和Shen认为组织间合作关系的本质是通过参与者业务流程的集成而实现的。由于组织间的合作涉及到多个产权独立实体之间的流程集成,因此,相对组织内部的流程管理,组织间流程存在以下矛盾:(1)流程信息共享:为了实现组织间关系在流程级的有效合作,要求成员组织之间必须频繁地交换流程信息,公开和发布必要的流程进展状态,使其它合作伙伴做出预期的响应。(2)流程信息隐藏:尽管詹姆斯·钱匹提出跨越组织边界的合作关系应该坚持“极度开放原则”,呼吁成员组织之间开放一切业务流程。但是在实际运作中,为了保留自治性和竞争力,参与合作的企业仍然需要隐藏其商业机密,如内部的流程结构。

三、 组织间业务流程的描述模型

从支持业务流程角度出发,流程管理系统一般需要提供3种基本功能:(1)建立阶段功能:主要包含业务流程的定义、子流程的划分和相关活动逻辑顺序的定义和建模功能。(2)运行阶段的控制功能:在一定的运行环境下,执行业务流程,并完成每个子流程中各活动遵循的约束条件判断、活动执行路径安排和调度功能。(3)运行阶段人机交互功能:为了保证用户参与流程的执行和控制,需要在流程执行过程中提供用户与IT应用工具之间的交互操作功能。

与传统流程相比,大多数组织间流程不存在一个端到端的流程控制,因此需要考虑流程之间的交互操作性。然而,当前组织间流程在交互操作方面还存在许多有待解决的问题,如成员组织局部流程执行的自治性问题;流程控制策略变动性问题;成员组织保护自身流程机密性问题;各种软硬件异构性削弱交互操作能力;缺乏跨组织访问流程资源的方法。

由此可见,组织间流程是一个复杂的涉及多个实体重复交互操作的系统,单独从一个侧面难以实现有效的描述,必须从多个角度来考察才能全面地描述其业务流程集成过程。为了完整描述组织间流程,可以从成员组织、资源分配、业务流程和信息交互这四个方面来对组织间流程进行综合分析。如图1所示,一个组织间流程描述模型由组织视图、资源视图、流程视图和信息视图及其相互之间的联系组成,每一个视图分别从不同的侧面描述组织间流程的结构。用形式化表述语言,可以将组织间流程IOProcess表示为一个四元组:{Org-view,Res-view,Proc-view,Info-view},其中,Org-view指的是组织视图,Res-view是资源视图,Proc-view是流程视图,Info-view是信息视图。

1. 组织视图。Org-view描述组成组织间关系的成员组织和成员组织之间的联系,成员组织是产权独立的组织实体,自愿参与组织间合作,在组织间关系中承担相应的角色,执行一定的流程任务。Org-view主要描述全体成员组织、承担的角色及组织与角色之间的关系,Org-view= {ORG,ROLE,C},其中,ORG表示成员组织集合,ROLE表示角色集合,C表示成员组织与角色的对应关系。

每个成员组织org i∈ORG,i=1,...,n,n为参与组织间流程的成员组织数量。org i可以表示为{name,type,int,other},其中,name是成员组织的名称;type表达成员组织所属的类型,如制造商、部件供应商或物流企业等;int则定义了该成员组织参与组织间流程的接口,可以是某个部门,也可以是具体的人员;other用来定义其它相关元素。

每个角色role j∈ROLE,j=1,...,m,m为负责组织间流程中子流程的角色数量。role j={name,obl,other},其中,name描述角色的名称;obl则说明了该角色在组织间流程中承担的职责;other同样用来定义其它相关元素。

对应关系C描述了所有可能的成员组织与角色之间的对应关系,C={org i,role j|org i∈ORG,role j∈ROLE,i= 1,...,n,j=1,...,m}

2. 流程视图。流程视图描述组织间流程中以活动为中心的公共业务流程,它定义了组织间流程中所有的活动以及这些活动之间的逻辑关系。流程视图Res-view是一个二元组,其中,A是活动集,任意一个活动a∈A可以表示为{name,stat,SC,res,info},name是该活动的名称,stat反映了活动当前的状态,状态的类型有初始、就绪、执行、挂起和终止等。SC表示该活动的启动条件,根据SC的评价结果来决定是否启动该活动。Res和info是该活动执行所需要的资源和信息,分别取自于资源视图和信息视图。

D是依赖关系集。一个依赖关系表示为dep(a,b,c),a,b∈A,条件c表示判定能否从活动a进入到活动b的限制条件,如时间、事件等。在工作流管理联盟(WFMC)制定的标准文档中,定义了6种基本的活动逻辑关系:串行、与分支、与连接、或分支、或连接、循环。根据这6种基本逻辑关系,可以描述活动间的执行路径。

3. 资源视图。资源是组织间关系运作必不可少的物质因素,只有分配了必备的资源,活动才能够得以执行。资源视图描述了组织间流程使用的资源类型以及资源实体的属性。资源从广义上说包含活动执行所涉及的所有物质实体,可以是活动的执行者、执行活动所需的设备、物料,或者是活动执行后产生的新的资源。这里,本文所指的资源实体主要是除了人力资源以外的活动执行所需要的资源。Res-view={RES},资源实体res k∈RES,k=1,...,h,h为组织间流程使用的资源总数。res k={name,type,number},其中,name是资源的名称,type是资源的类型,number是该资源的数量。

4. 信息视图。组织间流程的任务执行过程以及组织间关系的维持都需要信息的支持,信息视图就是从信息处理的角度来描述组织间流程中的数据结构特征和信息交互关系。从信息处理的角度来看,组织间的业务流程是若干活动执行者进行信息处理和信息交流的系统,换言之,可以把组织间合作关系归结为信息共享和信息交换的关系。一方面,活动在执行前和执行过程中需要获取必要的流程数据,同时,活动执行的结果也会产生相应的流程数据。这些数据要求以统一的方式进行管理,而且能够被所有成员组织访问。另一方面,在组织间合作关系中,信息往往为各个成员组织专有,成员组织出于自身利益的考虑,可能只进行一定程度的信息交流,即存在信息自主性。此外,信息交互还是一个动态过程,通常情况下,成员组织经过多次信息交互过程改进信息共享程度,不断调整相互之间的合作状态。总之,无论是从组织间流程的角度还是从组织间合作关系较大看,成员组织之间的合作能否取得成功很大程度上取决于信息共享和信息交互的程度。因此,本文考虑建立公共的信息视图来统一描述组织间流程使用的各种流程数据和信息流向。

5. 视图之间的联系。组织间流程模型中各个视图之间存在密切的联系。组织视图管理的是能够承担某项角色的组织,流程视图管理的是某个角色执行的活动,两个视图之间通过角色联系起来。流程视图指定活动的执行者为某个角色,而不是固定的组织。而组织视图给每个成员组织分配特定的角色,根据分配的角色确定该成员组织负责执行的流程活动。资源视图负责管理公共资源,为了保证任务的执行,资源视图给流程视图中的活动分配必要的资源。同时,资源视图受组织视图的支配,每一个资源实体都有与之对应的成员组织,该成员组织负责对此资源实体的使用和维护。信息视图的信息来源于组织视图、流程视图和资源视图中的数据结构及数据关系。一方面,信息视图负责管理组织间流程使用的所有数据和信息,在结构上表现为若干个数据库。另一方面,信息视图还为组织视图提供成员组织交互操作的平台,定义了一系列信息交换和信息发布机制。

四、 结语

由于组织间流程集成了多个产权独立组织的流程,因此,相对于组织内部流程,组织间流程更加强调信息交互以及子流程之间的协调,同时,在流程集成过程中还存在信息共享和信息隐藏的矛盾。此外,从处理的信息结构看,组织间流程处理的流程信息既有可事先定义的任务安排,又有在执行过程中为应对各种变化条件而动态定义的半结构化流程信息。正因为其复杂性,为了完整描述组织间流程,需要从包括成员组织、资源分配、业务流程和信息交互等多个视角进行综合分析。

参考文献:

1. 詹姆斯.钱匹.企业X再造.北京:中信出版社, 2002.

2. 梅绍祖,Teng,J.流程再造:理论、方法和技术.北京:清华大学出版社,2004.

3. Davenport, T.H., Short, J.E. The new indu- strial engineering: information technology and business redesign. Sloan Management Review,1991, 31(4):11-27.

4. Chen, Q., Hsu, M. Inter-enterprise colla- borative business process management. IEEE,2001: 253-260.

基金项目:中央基本科研业务费项目“在线口碑传播对城市品牌塑造的影响:机制、效果及对策研究”(项目号:2010221053);福建省社会科学规划一般项目“网络口碑有效性综合测度系统研究”(项目号:2011B223)。

作者简介:黄士凡,厦门大学管理学院财务系博士生;张耕,厦门大学国际经济与贸易系副教授,厦门大学管理学博士。

篇5:业务助理工作职责描述

图片处理:根据专利报件要求及时对专利外观图片进行处理编辑。

文件制作:助理协助顾问整理要提交申请的专利或商标文件。

报件文件审查:对于客户递交的报件,文件进行检查及提醒代理人与客户沟通补充的其他文件,以提交流程部进行申报。

篇6:业务助理工作职责描述

2. 根据业务部年度销售计划,分解季度、月度销售目标,拿下订单,完成目标;

3. 负责区域市场客户的应收账款的催收工作,并协助做好呆账催收处理;

4. 处理客户异议和投诉,以提高客户满意度,建立良好的客户关系;

篇7:外贸业务助理工作职责描述

2、执行推广方案,产品线的规划,包括产品的上下架等;

3、每日对商品询价数据进行监控、分析、管理;

4、客户订单跟进和发货;

篇8:科技工作业务流程描述

1 业务构件描述

各个行业的企业总有一些核心业务,长久保持不变,新时期的新业务基本上都是围绕核心业务展开。但是业务的扩展和IT技术的发展始终是一对矛盾的存在,如何重用原有的技术成果去描述常变的业务需求,是当前软件开发行业内所关心的话题。

就企业信息化领域而言,企业和业务包含几个重要要素:业务术语、业务流程、业务活动、业务表单、组织机构等。这些要素相互作用实现企业特定的目标。业务术语代表着领域化数据,是业务的数据来源;业务流程和业务活动代表着用户与系统之间有规律地交互,是业务的语义体现;业务表单代表着用户同数据之间的交互,是业务的交互接口。三者之间互相作用,完成一项特定的业务需求。至于组织机构,可以认为是业务术语的一个子集。

所以提出一套方法:对业务进行抽象分解,抽取出最核心的部分并使用统一的格式去描述,再把他们封装成基础颗粒(构件),定义向外提供的服务,在上述基础工作之上,就可以定义出具有不同功能甚至不同版本的构件,将它们部署在一个架构之上去运作完成指定的业务,从而应对当前企业信息化领域的业务需求挑战。在企业信息化领域对企业业务进行层次化划分为数据模块,流程模块,用户界面3部分。

1.1 业务数据

数据模块是企业信息化领域数据特征的抽象,用于描述一组数据的概念和定义。使用概念建模的方法:现实世界中存在各种概念,本质不同的属性集合,换言之不同的属性,依据一定规律或规则,形成的集合是概念。数据是企业信息内容积累的重点,建立业务数据库对业务概念重用有着重要作用。

业务数据作为业务构件的底层支撑部件,需要提供服务来供构件其他部分或者其他构件去调用。对其进行逻辑封装,将操作封装成业务服务发布出去。另一方面,通过映射逻辑操作,将概念和所属属性映射至持久层中去,这也是数据持久化的途径。

业务数据用于描述企业业务里包含的丰富的概念知识,它是整个业务模型的语义基础,可以规范和约束业务所处理的数据。为数据赋予语义,不仅可以促进企业知识的重用和共享,还可为企业数据交换和集成带来好处。

1.2 业务流程

企业信息化核心职责是企业集成化、协同一体化,关键是实现商务流程系统和商务数据的互相协同。企业信息化领域的施工模块划分,一般以一项完整的流程作为划分的依据,因为它包含最小的独立可执行业务信息。并且在实际开发中,业务数据一般相对稳定,业务流程则是随需求常变的,故将业务流程当作构件中的一部分。

业务流程就是业务页面在不同用户之间流转。业务流程分为:业务活动,业务动作和业务规则,它建立在业务数据承载基础之上。

业务活动是业务流程的一个环节,每一个业务流程是通过处理一个个业务活动来展开的。它是状态的集合,另一方面也是用户访问的基本单位。利用业务活动这个载体,通过其传递、流转体现了企业协同交互功能。

业务功能,也可以理解为业务动作。它被业务活动引用去实现特定的业务操作,换言之它解决了业务流程中做什么和怎么做的问题。在开展业务活动时,参与者根据自己的权限进行受限范围内的操作。

业务规则,表示业务流程与业务活动中的丰富规则,它使流程在业务需求下恰当运行。业务流程有启动规则、流程合并规则。通过启动规则,可以确定流程在什么情况下启动以及如何启动。流程合并规则规定多个流程实例如何并行处理,方便大量流程的共同处理。业务活动之间通过连接弧、逻辑环节、条件环节等连接,这样规定了各项活动之间的先后关系和逻辑关系。最后每个业务活动上可以制定执行规则,转发规则,回退规则,时间规则等。

1.3 用户界面

用户界面和业务两部分之间完全独立的,他们之间通过服务接口交互。用户界面通过技术框架去实现同表单数据、业务流程之间的松耦合。它分为4部分:数据+格式+动作+规则。

数据部分定义了包含在表单中的数据,并规定了用户提交时如何处理数据。数据可以是数据模块中的概念,流程上下文数据,静态数据等;格式指数据如何在表单中布局以及采用什么构件来表现数据等。现在广泛使用的是xbl(界面构件),xforms(界面具体展现)等技术规范;在用户界面中,可以定义各种业务动作,也可以调用数据模块或者流程模块中定义的业务动作,采用事件驱动架构进行业务动作的响应;数据规则的检查,包括计算、约束、必须、只读等;最后还需要胶水层代码以实现一些简单业务逻辑。

2 业务构件拼接组合

类似于对家具的各个零件部分进行组合、拆装来进行家具的搭建。下面对业务构件的组合以及拼接部署进行讨论。

2.1 业务构件封装

能否对软件开发进行更为有效的分工,降低程序员重复单件工作的成本,是衡量软件技术能否在复用性上取得突破的根本准则。因此提出,用户界面、业务流程、业务数据以及彼此之间提供的动作服务的集合,称之为业务宏构件,如图3所示。

业务数据提供数据库表的映射服务;业务流程提供流程服务供流程引擎调用操作;用户界面提供界面服务供用户访问及交互。业务流程为语义执行核心,一方面通过技术框架中的容器同业务数据绑定,另一方面通过REST服务同用户界面发生关联。3部分均支持事件驱动框架提供业务服务供其他宏构件调用导入。最后提供系统管理服务,对宏构件进行部署、注册、注销等管理操作。注意一个业务构件可以由多个业务数据,多个业务流程,多个用户界面组成。

2.2 构件服务接口描述

由图3中可以看出,构件提供出的服务大致分为3类:界面服务,数据逻辑服务,业务动作服务。服务的接口规范基于WSDL(Web Service Description Language),而且也提供Java接口,这样使用业务构件的客户端可以选择使用WSDL接口或Java接口。服务接口类型具体采用哪种调用关系则主要是考虑性能、接口复杂度、耦合性等问题:不同构件之间可以通过 REST 服务进行调用;一个业务构件内部,业务构件和公共模块之间的调用实现 API 调用。

由于涉及到业务构件内外的调用,因此需要制定专门的绑定信息。这些绑定信息包括了目标服务或者源服务的调用方式,位置信息,调用的方法等。常用绑定方法有JMS绑定和Web Service绑定等。

2.3 构件的可配置化部署

文献[4]中提出了一套基于构件的软件配置管理系统模型。使用XML语言进行构件之间的配置描述,需要描述的部分大概有:构件的类库组成;描述构件暴露的服务;构件域描述,描述系统可用节点,互联接信息和桥接信息;逻辑构件映射成物理构件服务过程等。构件调用关系如果想实现自动绑定(Auto-wiring),还需要在标签中加入Autowire属性等标签。

系统架构彻底可配置化,要求框架本身构件也必须像业务构件一样可定制、可配置。这就需要一个微内核配置文件。框架本身构件也是靠配置这个微内核的配置文件达到组合使用或更换个别零件。

2.4 构件架构的实现

依照前述讨论内容,现假设存在多个业务功能不同的构件,为使他们彼此之间协同工作组成一个完整的信息系统,文献[5]提出了一个可拓展的集成式构件描述框架。这里结合CCM(Corba Component Model)标准和企业信息化领域的业务问题,提出一套构件框架模型,如图4所示。

业务服务总线是体系架构的核心,它负责缓存数据,统一数据格式,进行服务的引用调度,启动相应流程引擎,页面引擎等核心功能。

将跟每一个业务构件紧密相关的部分单独作为一个构件,即公共服务构件。业务构件和公共构件使用一个数据库,通过相关标准实现整合。公共服务构件包含组织管理、菜单管理、流程管理、系统管理、报表打印等。业务构件则由用户定制并部署至平台架构中,类似插件一样进行工作。

例如对会议管理部分进行分析。按照流程进行划分,可分为会议通知,会议记录,会议结果处理3个具有独立流程的部分,所以每部分作为一个宏构件进行设计。以会议通知为例分析,要求发起人填写会议信息并分发至参会人员并得到回执。流程包括3个环节:创建会议信息、分发通知、发送回执。业务流程从流程库中选择简单无分支流程类型,对环节进行命名和简单删减以符合流程要求,业务数据从本体库中选取会议本体,可依据企业需求选择所需子集,业务页面选择主表流式布局。接下来进行3部分之间的连接配置以及特色业务服务实现。主要包括:(1)页面技术构件同数据源属性之间的绑定。(2)页面业务服务实现流程各个环节执行者、分派模式等规则设定。(3)同组织机构构件交互的规则设定。(4)部署执行配置。最后通过Osgi技术将3部分资源以及配置信息打包封装,植入构架中运行。

以上为会议通知这一宏构件制造过程,若流程需求发生变化,只需对其流程环节进行轻微修改;若表单需求发生变化,只需对用户界面布局进行改变;若业务需求发生变化,只需对响应业务服务进行修改编码。三者之间彼此耦合度低,影响不大。这样就能将维护局限在宏构件中,甚至还可加入版本机制,增强复用度。

3 结束语

在对当今企业信息化领域分析的基础上,提出宏构件概念,借鉴CCM标准,对构件的拼接部署方法进行了讨论,提出了基于宏构件的业务架构平台,为企业信息化领域构件化开发提供一种可行的解决方法。

参考文献

[1]ZHU S Y,QIAN L Q,SU W M.Software engineering technol-ogy conspectus[M].Beijing:Science Press,2002.

[2]徐玮,尹宝林,李昭原.企业信息系统业务构件设计研究[J].软件学报,2003(7):2-3.

[3]孟凡超,战德臣,徐晓飞.基于领域业务模型的可重用构件设计方法[J].计算机集成制造系统,2006(12):98-101.

[4]张路,谢冰,梅宏,等.基于构件的软件配置管理技术研究[J].电子学报,2001,29(1):267-276.

上一篇:人民路中段隔离带花坛改造设计方案说明下一篇:忠诚履行职责