IT业务

IT业务（精选十篇）

IT业务 篇1

2010年反复无常的市场环境和激增的经营压力, 使得企业面临着更多的挑战。当前企业的业务运营日益依赖于网络和IT技术, 使得源于IT系统运行中断而导致关键业务中断的风险也随之而来。因此, 越来越多的企业将注意力从灾难发生之后的业务恢复, 转移到如何保持企业关键业务连续性上。

那么, 该如何建立高效的保障业务连续性的系统呢?

一是业务影响分析, 制定所需防范的灾难范围。简单地说, 业务影响分析主要是识别出企业的关键业务活动对这些关键业务活动所能容忍的业务最长中断时间, 并对这些业务所依赖的要素进行分析, 最后按照恢复的优先级排序确定关键活动。二是风险分析, 明确需要防范的灾难类型。通过风险分析, 明确IT系统需要承受的灾难类型, 并对诸如系统故障、硬件故障、数据受损、火灾及地震等各种意外情况采取合适的备份和保护方案。同时, 针对不同的灾难风险等级, 它们的防范策略应该不尽相同。三是依据业务关键程度, 设定灾难容忍时间指标层次。必须明确, 当IT系统发生意外而无法工作时, 依据业务停顿所造成的损失程度, 设定用户对于IT系统发生故障的最大容忍时间, 这也是设计IT治理业务连续性方案的重要技术指标。四是成本控制, 平衡风险等级和业务连续性的关系。业务连续性应当根据业务恢复的总体成本对最关键的应用进行权衡。五是业务连续恢复方案, 不能光建不练。制定好IT治理业务连续恢复计划后, 并不是万事大吉和束之高阁, 因为不经过演练的计划方案无异于纸上谈兵。测试和演练是非常有必要的, 而且这也是有效的IT治理必不可少的一步。

IT业务分析岗位职责 篇2

2.联系业务部门，收集需求，界定系统范围。

3.协助系统范围研究和业务流程再造，提供IT解决方案。

4.帮助业务部门了解IT解决方案的功能和局限性，协助差异分析和解决方法。

5.负责项目管理，包括分包和外包的范围及管理。

6.负责系统配置、数据清理、测试、用户培训和上线后支持。

7.和用户部门确定和开发满足业务需求的流程,分析和改进现有的流程。

8.有效评估各种IT方案以满足业务需求。

9.准备和实施用户培训。

10.严格按照规范进行应用系统升级和更改。

实施“高效IT”,推动业务成功 篇3

马自达北美分公司的IT系统需要支持北美地区1,100多名内部业务用户，800家经销商的16,000多名用户和日本总部指定的全球项目。但随着数据的“爆炸性”增长，其IT系统出现了一些“结构性失衡”，极大地影响了IT系统效率。首先，存储性能和存储容量失衡。马自达IT基础架构服务部经理Kai Sookwongse介绍说：“旧存储体系结构有充足的存储容量，但是无法提供我们支持虚拟化所需的性能。”第二，服务器虚拟化和存储虚拟化的应用水平失衡。马自达存储虚拟化水平相对较低，无法为服务器虚拟化提供强有力支持。由于IT系统存在一系列问题，IT部门只能将大量精力用于维护200多台物理服务器和存储设备的日常运行，没有更多精力规划IT系统和更好地支持业务部门。

针对这种“结构性失衡”而引发的效率低下，戴尔帮助马自达设计并升级了IT系统。作为核心解决方案，马自达部署了具有自动分层存储功能的智能化的戴尔Compellent系统。该存储平台的第1层采用9个固态硬盘，运行VMware和高性能数据库。第2层使用15K光纤驱动器，用于性能相对较低的数据库，并支持一些SAP应用程序。第3层采用7,200转/分钟的驱动器，用作只读存储；此外，在存储平台的前端，戴尔还部署了4台先进的PowerEdge R710服务器。在这些服务器上，戴尔安装了VMware虚拟化管理程序，虚拟出数十台虚拟机，以此来运行SAP等一系列重要应用。

这种智能化的存储后台和虚拟化的应用前台，全面提升了马自达IT系统的效率。第一，戴尔Compellent可以实现存储性能和容量的均衡。戴尔Compellent采用分层存储技术，高性能固态硬盘可以满足最高读写需求，大容量驱动器可以提供海量存储空间。分层存储还可以确保更低的TCO（总体拥有成本）。第二，戴尔Compellent和戴尔PowerEdge服务器的完美配合，实现了更优化的虚拟IT环境。采用基于SAN的虚拟化的服务器和存储体系结构，马自达大幅提升了应用程序性能。“戴尔Compellent SAN提高了VMware性能，让关键存储资产发挥了最大价值。”Sookwongse介绍说，“现在，我们实现了80%-400%的性能提升。像SAP这样的关键应用程序比在物理服务器上运行得还好。”新的高效IT可将每年用于服务器的费用降低60%。由于系统改进和整体效率提升，企业可以将节省的精力用于创新和为业务部门提供更好的支持。例如，该部门正在扩展对新型移动应用程序的支持。“我们最近发布了一款供代理商在销售过程中使用的iPad应用程序，销售工作要求我们具备应变能力”马自达CIO DiMarzio说，“戴尔Compellent系统为我们提供了必要的竞争优势，让我们能够推出适合在移动环境中使用的创新性应用程序，在市场上抢占先机。”

从具体的数字和技术人员的表述中我们可以看出，在“高效IT”理念指导下而建成的全新的IT平台，确实为马自达注入了一股活力和动力，它不仅提高了IT系统的性能，降低了成本，更是提高了马自达的敏捷度。汽车行业的竞争日益激烈，而马自达和戴尔联手建设的全新IT平台，无疑能够让马自达更灵活地应对市场的变化，在竞争中取得持续的成功。

IT业务 篇4

IBM的“3A5步”智慧分析洞察方法在金融、医疗、制造、零售、公共、保险等等领域已有深刻的实践。如今引入教育领域, 以期对中小学校长管理有启发意义。

“3A5步”智慧分析洞察动态路线图

掌控信息 (Align) :全面收集、整合、掌控信息。如, 大数据平台、分析型数据仓库及非结构化数据、流数据等新型数据的处理和掌控。

获悉洞察 (Anticipate) :提取洞察并预测。如, 财务绩效管理、商业智能、预测分析、内容分析和风险分析。

采取行动 (Act) :优化决策成就业务绩效。通过将掌握的信息通过分析获取洞察, 用于决策平台或决策流程中, 帮助企业业务人员和CXO等决策者实现业务绩效的优化。

学习 (Learn) :从每一次业务结果中获得学习和反馈, 改善基于信息的决策流程。以Watson为例, 从信息证据和行动结果中进行学习, 在每次迭代中获取更智慧的解决方案。

转型 (Transform) :制定清晰的分析战略, 结合行业经验和既有案例, 缔造突破性业务成果。通过确定业务的优先级分析目标、清晰一致的策略, 找到新的方法、业务创新模式;通过已经有的行业解决方案和其他客户的最佳实践, 识别新的业务机会和价值。

不管是在IT层面还是在业务层面, 智慧的分析洞察都将企业传统的管理模式提升至一个新的范畴:将深厚的市场经验和前瞻的创新理念相结合, 整合软件、硬件、咨询服务、研究等各领域的技能和资产, 帮助企业优化业务流程, 驱动更快、更智慧的决策和行动, 最终实现高利润的成长。

智慧的分析洞察与校园信息化建设

自二十世纪初期科学管理理论产生至今, 学校管理经历了一个从企业管理大量“引进”的过程, 企业管理对学校管理理论与实践的发展产生了重要影响。在信息化的今天, 企业管理信息化的经验对校园信息化建设来说具有较高的借签意义。

IT行业业务员工作总结 篇5

IT行业业务员工作总结1

转眼间，时间又过去近半年了，在今后的工作我要自觉加强学习，逐步提高自己的理论水平和业务能力;做到脚踏实地，提高工作主动性，在点滴实践中完善提高自己;继续提高自身修养，强化为人民服务的宗旨意识。新的一年里，在镇党委政府的关怀与培养下，我会进一步严格要求自己，争取更大的进步。

前半年，投入了大量的精力，保证了业务扩充，使其发展势头越来越好，其中，对公业务迅速增加，已经成为主要业务，决定了其日后业务主要发展方向。资金方面，仍然靠整合资源，筹措资金来解决，情况已经大为改善，要保持良好的节奏，才能顺利开展工作。

目前，IT产业已经到了关键时期，要在三年内全面完成行业整合，但此举是一个艰难的过程，需消耗大量的财力和精力，要求自身必须务实而行，以求产业生存。

下半年，工作仍需积极探索，要从以下几点出发，确保所有计划顺利进行。

一、要学会掌控产业链。

要从产业链的中心向头向尾扩充，找到切入点，市场已经决定了自身该做哪些产品，哪些业务，这非常重要，以目前而言，实力不均以掌控链主。做不了链主，就要以一个关键点的方式来出现，来应对同行的竞争，市场的排斥。

二、思路决定方向，战略决定未来，结构决定结果。

1、现如今竞争如此激烈，企业要做一个定位，要在整个这个IT市场中你作为什么角色去生存?批发、零售、还是对公，有条件的整合，没有条件舍弃。经济形势变化千幻莫测，长远的计划会直接影响发展方向，就像年初确立的“三一计划一样”，一年一进度。

2、要做一个长远的战略，要确立使命，企业生存的意义，为了盈利，那是必然。但仍需，要把IT产业像种子一样散播在美丽富饶的巴彦淖尔大地上，用IT，为巴彦淖尔市农业发展做出贡献，这才是最终的目标。

3、自身的结构要学会扩充，IT产业是一种规模化经营的企业，要学会去如何实现规模化经营。结构的发展，必然会影响结果，从最初的经营开始，就要去学会管理，即使没有规模，要养成良好的财务，严格的工作制度，才能使自身又快又好发展。

三、要做好政府的秘书，该找市场找市场，该找市长找市长。

政府的各类政策，直接影响着自身的发展，从招标，投标的采购，到税收，工商行政管理，已经说明了自身与它不可分割的联系，要做一个遵纪守法的企业，养成良好的对公工作态度，争取没有各类违法罚款的行为。

四、学习仍是当务之急。

要加强学习，扬长避短，学习别人的长处，尽量改善自己的短处。从今开始，坚持继续收听并观看《巴彦淖尔新闻联播》，畅读《黄河晚报》，闲暇之余，对《诗经》，《资治通鉴》等，要做有效的计划学习，才能使身心得到有效的升华，对以后的生活和工作，起到举足轻重的作用。

五、良好的工作方式，仍然是影响全面发展的因素之一。

已入深夏，白天的时间较多，决定即日起，工作时间扩充为晚上9点，争取全面加班，处理完当天的所有事情。现因盲目扩大，已导致工作一人无法做完，要学会合理的利用时间，才是真正做到工作的关键。今年是艰苦奋斗之年，要确立艰苦奋斗之精神，完成当天所有工作计划，才能保证全年的工作计划，影响长远的计划。

六、严格制定作息时间制度。

工作逐渐增多，学会合理休息和工作也是重点问题之一。每天早晚牛奶一杯必须切实落实，按季度补充钙锌也非常关键。争取早睡早起，保持每日8个小时的睡眠。应酬方面，喝酒选择为啤酒，对于自身健康有着较大的影响。

七、人生大事，崇尚坚持。

就如同我像昨日一样，喜欢你，没道理，我想，时间会证明一切，已经开始全面计划，争取我的幸福，如同我走向光明之路一样，总有那么一天.....IT行业业务员工作总结2

从12月初到现在，我已经在公司工作近1个月了。这段时间我收获了很多，对于我从学生到一个职业人的转变具有重要意义。

作为一个应届毕业生初来公司，刚开始很担心不知如何与同事共处、如何做好工作。因为公司的这些业务是我以前从未接触过的，而且和我的专业知识相差也比较大。但是这一个月以来，在公司宽松融洽的工作氛围下，经过项目经理和同事的悉心关怀和耐心指导，我很快的完成了从学生到职员的转变，在较短的时间内适应了公司的工作环境，也基本熟悉了项目的整个工作流程，最重要的是接触和学习了不少的相关业务知识，很好地完成了项目交予的任务，做好了自己的本职工作，使我的工作能力和为人处世方面都取得了不小的进步。

在这里对一个月的工作和生活做一下总结，可从中发现自己的缺点和不足，在以后的工作中加以改进，以提高自己的工作水平。

在这一个月的工作和生活中，我一直严格要求自己，遵守公司的各项规章制度。尽心尽力，履行自己的工作职责，认真及时做好领导布置的每一项任务。当然我在工作中还存在一定的问题和不足，比如：对业务不太熟悉，处理问题不能得心应手，工作经验方面有待提高;对相关知识情况了解的还不够详细和充实，掌握的技术手段还不够多;需要继续学习以提高自己的知识水平和业务能力，加强分析和解决实际问题的能力;同时团队协作能力也需要进一步增强等。对于这些不足，我会在以后的日子里虚心向周围的同事学习，专业和非专业上不懂的问题虚心请教，努力丰富自己，充实自己，寻找自身差距，拓展知识面，不断培养和提高充实自己的工作动手能力，把自己业务素质和工作能力进一步提高。也希望请领导和同事对我多提要求，多提建议，使我更快更好的完善自己，更好的适应工作需要。

这里我要特别感谢部门经理XXX对我的入职指引和帮助，感谢他对我工作中出现的失误进行提醒和指正。作为应届毕业生初入职场，在工作中难免出现一些差错需要同事的批评和监督。但这些经历也让我不断成熟，在以后处理各种问题时考虑得更加全面。现在的我同老员工相比，在工作经验和能力上都有很大差距，工作和生活上不懂的问题应虚心向同事请教学习，以不断充实自己。

同时感谢XX对我们的业务指导以及XXX的每一次技术培训。由于我们是个IT公司，我清楚地了解良好的业务素质和技术水平是做好本质工作的前提和必要条件。

在公司的这段时间里，我学到了很多，感悟了很多。看到公司良好的发展势头，我深深地感到骄傲和自豪，因此我更加迫切的实现自己的奋斗目标，体现自己的价值，和公司共同成长。我一定会用谦虚的态度和饱满的热情做好我的本职工作，为公司创造价值，同公司一起展望美好的未来!

IT行业业务员工作总结3

首先，非常高兴能够加入xx科技有限公司这个大家庭，感谢郑总给我这么一个好的能够尽情施展自己才华的发展平台，谢谢!

20xx年11月14日，我怀着一颗忐忑的心加入了xx，说实话，我心里面没底。以前，我从来没有从事过IT行业，更不要说销售投影机。但是，经过一个礼拜培训后，参加实战第一个礼拜，我就卖出去了自己进入IT行业的第一件产品，并在之后连续成交了几单生意，顿时，我有信心了，加入鹏威公司发展自己的事业，我的决定没错!

下面，请允许我对我这段时间的工作进行简单的总结和分析，希望各位领导和同事能给予指正。

一、工作业绩

截止20xx年12月31日，我总计开发有效客户x家，上门拜访客户x次，每天坚持打电话 30个以上，完成销售x万元。我这段时间的销售业绩不理想，跟各位公司的前辈销售人员比起来，我感觉万分惭愧，但是知耻而后勇，我会在以后的工作中加倍努力，向前辈们学习，勇创佳绩。业绩不理想，我觉得主要有一下几个原因：

1、刚进入IT行业，对产品和行业知识不熟悉，在以后的工作中，我会努力学习，提升自己的内功

2、本身工作经验不够丰富，跟客户沟通和谈判的技巧不够，造成人为失单，今后的工作中，我会多向前辈学习，多多自我总结，提升自己的销售能力。

3、不够勤快，我在今后的工作中，一定客服自己心中的魔鬼，全身心投入到工作中，增加自己的工作量，都说勤能补拙，我相信，在来年，我一定能创造出更好的成绩

4、我个人认为还有一些市场原因，根据客户的信息反馈，年底了，商家都忙着清理库存，不愿意再用现金向外面调货，从而造成我们销售困难，而且客户手上有些单子，也会拖到年后再交货

二、事务性工作

1、严格遵守公司的规章制度，服从公司领导的安排

2、参加了公司一个礼拜的培训，同期，并对市场进行了一番调查和摸底，我觉得我收获了很多

3、经常帮助公司其他同事处理一些应急事件，比如送货、送文件、帮助看门市等

4、轮流主持早会，训练了自己的组织能力和应变能力

三、应收账款

我严格执行了公司的财务制度，截止20xx年12月31日，我的应收账款回收率为100%，在来年的工作中，我会继续严格执行公司财务制度，保证公司的资金安全。

四、个人心得

1、电话营销技巧：打电话之前，一定要组织好自己的语言，不要紧张，也不能激动。跟客户沟通时，一定要调理清晰，并要严格遵循公司的报价原则。当客户态度不是很友好时，我们要懂得随时调整自己的心情，不能被客户左右了我们自己的情绪

2、客户拜访技巧：初次拜访客户，一定要坚持谦卑的态度，递送名片时，一定要双手奉上，多说一些恭维的话。在进行商业洽谈时，一定要头脑清醒，立场鲜明，不能被客户左右了自己的思想，该坚持的原则必须坚持，否则，后面的工作我们会非常被动

3、客户讯息搜集：除了公司提供的专业杂志和企业黄页以外，我还通过网络和朋友搜集了很多客户讯息，开发出了不少的客户，我觉得在这方面我们一定要把自己的眼界方款，这样我们的市场才会无穷大

4、客户管理：我将自己的客户进行了分类归档，特别是加了QQ好友的客户，我进行了重要、次要和一般三个级别的分类，对重要客户进行重点开发和培养，提高了我的工作效率

5、其它心得体会：

五、个人建议

1、我觉得公司应该给我们多进行一些培训，不管是产品知识或者营销技巧，这样会大大加快我们业务员的成长

2、我们由于是职场新人，对财务这块不是很熟悉，我希望公司才能抽点时间对我们进行一些必要的财务知识培训，避免我们犯财务上的低级错误

综上，是我这段时间的工作总结和一点心得体会，不足之处，请各位领导和同事指正，谢谢!

IT行业业务员工作总结4

各位领导、亲爱的同事们：

大家下午好。

紧张而有序的一年又要过去了，忙碌的一年里，在领导及各部门各同事的帮助下，我顺利地完成了本年度的工作。为了今后更好地工作，总结经验、完善不足，本人就本年度的工作总结如下：

我先谈一下我们工作成就，及时响应了各部门的电脑软件、硬件、邮件、网络、打印机的维护。尽可能的降低设备使用故障率，在其出现故障的时候，并做到了能在当地解决就当地解决，不能当地解决的也在最短的时间内给予了解决……

回顾一年来的工作，在思想上、学习上、工作上取得了新的进步，我也认识到自己的不足之处：、因为简单的问题重复出现重复解决，可能到位不及时;自己的思路还很窄对现代网络技术的发展认识的不够全面，自己对新技术掌握速度还不够快……针对这些问题，我有以下解决方案……

总结了过去，方能展望未来!最后说说明年的工作计划，辞旧迎新，在总结本年度工作的同时，针对自己不足之处，我对明年工作也提出了初步设想：

在继续完善公司网络的同时，加强理论和业务知识学习，不断提高自身综合素质水平。把工作做到更好;对公司所有电脑设备进行统一计算机名称，和ip实现远程管理，维护。提升工作效率、领导交办的每一项工作，分清轻重缓急，科学安排时间，按时、按质、按量完成任务……

在我入职的近一年，我在公司学到了很多，学会了如何处事，如何与他人更好的交流等等。我在做好自己本职的同时，也学习了公司的一些相关的文化，在我觉得，公司在茁壮的成长，像雨后的春笋，展速度飞快，犹如刚发射的火箭直冲云霄。这些新的现象是因为共同的努力而创造的，我也希望用自己的这份微薄的力为公司和为自己创造一个更好的未来。

总之，感谢领导对我的信任与支持，我将尽心尽责、全力以赴地把工作做好!努力工作，快乐生活!

当IT遭遇业务部门的“劲敌” 篇6

之前,谈及信息化价值,人们说得比较多的是,信息化离不开业务。而今,倒是很多业务部门意识到自己越来越离不开信息化了。这个观念不仅仅是IT人的常识,更在逐步成为很多行业的业务主管和业务人员的常识。

遗憾的是,即便业务部门具备了一定的信息化冲动和意识,非但没有让IT部门感到热血沸腾,反倒是给IT部门制造出更大的压力,业务部门自己直接招标采购IT解决方案,漠视IT部门的存在;直到项目上马一段时间之后,机器需要修理、系统需要升级维护、数据需要共享,才会想起,这件麻烦事还是应该交给IT部门来处理。诸如此类的业务部门与IT 部门貌合神离的尴尬现象,在各个行业都不同程度地存在。

以往,当绝大多数人还不懂得电脑、不知道信息化为何物时,CIO最郁闷的事情莫过于孤掌难鸣、知音难觅。如今,为何人人懂得使用电脑之后,信息化依然举步维艰?根本原因在于部门争利。

一些比较强势的业务部门,尤其不希望有外来力量的“侵犯”。尤其是对于一些与业务结合十分紧密的信息系统,更是没有IT部门“沾边”的份。而本来,作为有着丰富信息化工程项目管理与选型经验的IT部门,可以帮助业务部门提高这一过程的决策效率,并从长远角度促进和保证业务信息化成效。

偌大一个IT部门成为业务部门的盲区,原因有诸多方面,但分析起来,主要有如下两种典型情形:

其一,业务部门地位举足轻重,习惯割据一方。这样的部门往往属于组织内的“当家花旦”,领导十分倚重和偏爱。这种资源无比强大的部门,自然对“玩转”电脑之类的活,感到不在话下。实在不行,就是无非多花几个钱的事儿。在这种情形下,业务部门对IT部门的存在完全是召之即来,挥之即去,对IT部门的态度也是可有可无,爱理不理。

其二,业务部门过度地强调业务而轻视IT。业务部门领导的重视,本来对于促进信息化是一件无比重要的事情。但是,业务部门对于IT本身的认知所限,往往倾向于关注解决业务本身的问题,而忽略在解决业务问题的过程中,如何综合考虑发挥IT的价值。

对于希望有所作为的CIO来说,以上任何一种情形的存在,对自己都是难以名状的耻辱。毕竟,信息化从来都是遵循整体规划、分布实施的铁律。如果不能从组织整体对信息化进行全盘规划和驾驭,后续所生的烦恼将不胜枚举。最典型的就是许多行业烟囱式信息系统、信息孤岛,这至今依然是信息主管们要着力应对的一大“天敌”。

融合化行业应用业务的IT支撑体系 篇7

随着移动互联网的高速发展, 行业应用产品的应用范围不断扩大, 电信运营商也将行业应用业务看作新的增长点, 作为重点的增值业务进行推广。为了占据有利的市场地位, 电信运营商加大了对行业应用的投入, 大力推动行业应用的创新开发和规模推广。IT支撑作为行业应用业务运营的信息化实现手段, 是推动行业应用规模发展的必要条件。然而, 随着行业应用的创新发展, 行业应用出现了明显的融合化特点, 它融合了移动网络、互联网、终端技术及各种信息新技术, 同时融合了政企客户与公众客户的需求, 使业务变得更加复杂, 为了适应这些融合化的新要求, 我们需要思考新的IT支撑体系。

2 融合化行业应用业务分析

2.1 业务特点

行业应用是通过与合作伙伴的深入合作, 将运营商的网络资源、通讯能力、应用系统等集成到政企客户的生产过程当中, 从而提升客户信息化的综合性电信业务。传统的行业应用一般基于互联网, 如网络传真、企业邮箱等, 而且一般只涉及政企客户, 但随着各种技术的综合发展, 特别是3G网络、无线宽带、智能终端等技术发展, 融合化行业应用应运而生, 它有三个主要业务特点:第一, 一个行业应用产品中融合了多种网络能力, 如短信、彩信、定位、语音通话等, 这些网络能力统一由应用平台集中控制, 协同各种业务能力为用户提供全方位的通讯服务;第二, 一个行业应用融合了多种用户终端设备 (手机、平版电脑、PC等等) , 用户可以在不同终端完成不同操作, 用户在一个终端上完成的操作结果能及时在另一种终端展现, 应用数据同步通过应用平台集中控制;第三, 一个行业应用中融合了政企客户需求与员工个人需求, 应用产品在业务实现和客户支持服务上要同时满足政企客户及员工个人的要求, 在应用功能和应用数据处理权限方面要对企业与个人有所区分, 在受理、开通、计费、结算, 客服等支撑服务上也要对企业和个人提供差异化服务, 并管理好两者的关联关系。

2.2 业务实现

融合化行业应用的业务实现涉及五个层面, 包括应用层、平台层、能力层、网络层和终端层, 各层有机结合, 通过紧密交互实现业务, 如图1所示:

应用层包含各种实现了行业领域业务功能的应用平台, 包括产品型应用和定制型应用;平台层包含业务管理平台, 它实现对应用平台的统一管理, 一般分为业务管理子系统和能力接入网关两部分;能力层包含各种业务能力引擎, 包括行业短信、行业彩信、行业定位等等, 应用平台对能力引擎的访问统一由能力接入网关控制;网络层包含各种基础性通讯网络设施, 如CDMA2000网络、PSTN网络、互联网等, 用户通过各种网络实现到应用平台的接入;终端层包含各种移动终端设备, 如手机、平板电脑、笔记本电脑等, 终端设备一般会安装与应用平台相匹配的客户端应用程序。

3 融合化行业应用IT支撑要求

根据TMF (电信管理论坛) 提出的e TOM (扩展的电信运营模型) , 电信运营应具备包括战略、基础设施与产品、运营、企业管理三大部分业务流程框架, 如图2:

其中, 在运营部分, FAB (实施、保障、计费) 是电信运营商向客户提供的核心服务, 也是运营商IT支撑的主要内容。对于融合化行业应用业务, 这三个方面的具体要求如下:

(1) 实施服务 (Fulfillment)

要求提供融合化行业应用的受理与开通服务, 能及时、正确地为客户提供行业应用产品, 跟踪政企客户定单的处理状态, 确保定单按时完成。由于融合化行业应用的用户包括企业管理者和大量的普通员工个人, 运营商要同时满足企业与个人的服务需求, 所以要求支持企业与个人分别订购模式, 同时向企业和个人提供受理与开通服务。为了支持企业与个人的客户服务, 要求支持双向查询, 即通过企业可以查询其下个人信息, 通过个人也可以查询到企业信息。另外, 由于政企客户往往会代表全体员工统一办理业务, 所以要求支持个人加入行业应用的批量受理。又由于一个应用可能涉及多种网络及平台、多种终端设备等, 所以开通服务要及时完成多种业务能力、应用平台的开通、多种客户端软件的安装等, 控制各个开通点的开通次序, 并进行全程测试后提交用户使用。

(2) 保障服务 (Assurance)

要求提供融合化行业应用的故障申告服务, 确保行业应用满足功能和性能要求。不论故障申告是来自企业代表还是其下员工, 都要求运营商提供7×24小时报障受理服务, 并协调处理直至故障恢复。融合化行业应用的故障除了涉及网络问题, 更多的会涉及业务能力、应用平台及终端上客户端应用程序的问题, 如功能问题、性能问题、数据问题等。由于应用平台和客户端应用程序主要由合作伙伴开发提供, 所以故障处理要充分考虑合伙伙伴的参与, 通过运营商与合伙伙伴紧密合作, 尽快恢复应用的正常运行。

(3) 计费服务 (Billing)

要求提供融合化行业应用的计费与结算服务, 能准确地生成政企客户和个人客户的帐单, 处理收费, 提供帐单查询等, 能准确地生成与合作伙伴的结算报表等。根据业务营销策略的不同要求, 要求支持多种计费模式, 如按使用量计费、按授权数计费、按实际用户数量计费等。根据行业应用的特点, 要求支持功能费、通信费等周期性费用收取以及开发费、集成费等一次性费用的收取。根据政企客户的不同要求, 要求支持企业统一付费、企业与个人分别付费等付费模式, 能够区分企业和个人缴纳的不同费用。在结算方面, 根据运营商与合伙伙伴的合作协议, 要求支持按绝对金额、按业务使用量、按用户数量等多种分成规则进行结算, 支持在一个行业应用中多个合作伙伴的结算等。

4 融合化行业应用IT支撑体系

融合化行业应用IT支撑新体系的构建主要包括: (1) 设计统一针对融合化需求的业务模型; (2) 在各专业支撑系统中增加支持融合化行业应用的新功能; (3) 建立业务端到端的自动化支撑流程。

4.1 业务模型

与传统的行业应用不同, 在对融合化行业应用的支撑服务中必须处理好政企客户和个人客户在众多方面的关联关系。在业务开通方面, 企业与个人的开通有严格的先后次序, 企业的开通必须在个人开通之前完成。在产品功能方面, 企业管理员与员工使用的功能既有联系又有区别, 比如企业管理员可以设置员工的操作权限、查询员工的应用数据、向员工发送任务指令等, 而员工只能使用职责范围内的功能和数据。在计费帐务方面, 个人使用手机进行私人通信, 也通过手机使用行业应用来参与企业生产活动, 所以手机产生的通信费用中既有个人消费部分也有因公消费部分, 如果运营商不能很好区分这两部分的通信费用, 企业与个人也难以处理通讯费用问题。我们可以采用以下业务模型来表达行业应用中的政企客户 (集团) 与个人员工 (成员) 之间的各种关系, 包括用户关系、帐务关系、客户间关系, 如图3。

在用户关系上, 第一, 行业应用包括企业产品与个人产品, 企业产品提供给企业订购, 生成企业用户, 个人产品提供给个人订购, 生成个人用户, 企业用户与个人用户之间建立群子关系;第二, 行业应用个人用户与移动用户建立依赖关系。在支付关系上, 企业帐户与行业应用个人用户、移动用户可以建立代付关系, 根据客户需求指定企业可代付的费用项目, 企业可以代付行业应用个人用户产生的费用, 也可以代付业务能力使用费, 如短信费、定位费等。在客户间关系上, 企业客户与个人客户之间建立企业与员工的组织关系, 即机构与成员之间的关系。

4.2 支撑系统新功能

根据融合化行业应用对IT支撑的新要求, 各个专业的现有IT支撑系统需要增加针对融合化行业应用的新功能, 如图4:

在融合化行业应用的支撑中, 各专业系统的功能分工如下:

(1) 客户关系管理系统负责完成融合化行业应用的受理, 生成客户订单并跟踪订单处理状态, 支持企业与个人分别订购、个人的批量受理以及企业与个人的双向查询等功能;

(2) 服务开通系统负责将融合化行业应用的客户订单分解为服务定单、工单, 并跟踪和报告工单完成情况;

(3) 网络激活系统负责根据融合化行业应用工单要求完成应用平台与业务能力的自动激活;

(4) 客服系统负责提供融合化行业应用业务咨询信息, 并受理企业与个人关于行业应用的故障申告;

(5) 服务保障系统负责接受融合化行业应用的故障修复请求, 通过监测故障、服务质量评估等手段实现故障的快速定位分析和服务恢复, 运营商与合伙伙伴可以通过服务保障系统协同工作, 尽快解决客户问题;

(6) 网管系统负责完成融合化行业应用相关的业务管理平台、应用平台、业务能力平台的监控、告警管理和性能管理;

(7) 话单采集系统负责从融合化行业应用的业务管理平台采集话单数据, 完成校验后提供给后续处理系统;

(8) 计费帐务系统负责完成针对融合化行业应用中企业与个人的计费帐务处理, 包括话单预处理、批价、帐务处理、欠费管理、销账管理等;

(9) 结算系统负责完成运营商与合作伙伴的结算, 支持一个行业应用中与多个合作伙伴、不同合作伙伴采用不同分成方式的结算功能;

(10) 运营数据仓储系统负责存储融合化行业应用短期的运营数据, 提供统一的行业应用运营数据视图, 生产行业应用相关报表等;

(11) 企业数据仓库系统负责对融合化行业应用的业务数据进行抽取、清洗、加工、整理, 并加载到数据仓库中, 然后建立各类专题应用的数据集市, 以便进行行业应用的经营分析。

4.3 关键支撑流程

4.3.1 受理开通

受理开通流程是运营商接受客户业务订购并完成服务提供的过程。融合化行业应用的受理开通流程如图5。

在第一阶段, 在客户关系管理系统中受理企业客户的订购, 产生企业订单, 然后向服务开通系统发送企业开通请求, 服务开通系统生成服务定单, 并通过网络激活系统与业务管理平台完成企业在应用平台以及业务能力的开通。在第二阶段, 在客户关系管理系统中受理个人客户的订购, 产生个人订单, 然后完成开通。在个人受理时, 需要提供个人关联的企业信息, 客户关系管理系统自动建立个人客户与企业客户、企业用户与个人用户、企业帐户与个人用户之间的关联关系。

4.3.2 计费结算

计费结算流程是面向客户的计费与帐务处理以及面向合作伙伴的结算处理过程。对于行业应用, 计费与帐务面向的客户包括企业客户和个人客户, 结算面向的是参与融合化行业应用开发、部署、维护或内容提供的合作伙伴。计费结算流程如图6:

在第一阶段, 业务管理平台按照统一格式产生行业应用话单, 话单采集系统按采集话单, 然后提供给计费帐务系统。在第二阶段, 计费帐务系统对话单进行批价处理及合帐处理, 并根据企业与个人享有的优惠规则进行折扣处理, 根据付费模式要求生成企业客户和个人客户的应付帐单。帐务处理完成后, 计费帐务系统向结算系统提供结算单, 结算系统根据预设的结算规则对结算单进行计算, 产生各个合作伙伴的应结费用, 形成结算报表。

4.3.3 服务保障

服务保障流程是用户向运营商提出故障申告到故障修复的过程。对于融合化行业应用, 服务保障同时面向企业客户和个人客户。服务保障流程如图7。

在第一阶段, 客服系统受理故障申告及进行预处理。在第二阶段, 客服系统生成保障单并发送给服务保障系统。若故障可用自动方式修复, 则服务保障系统通过网络激活系统、业务管理平台完成应用修复;若故障需要人工处理, 则服务保障系统生成人工修复工单, 由维护人员线下完成应用修复。为了统一故障管理, 提升故障的修复效率, 可将合作伙伴的运维队伍嵌入到运营商的保障体系, 通过服务保障系统直接向合伙伙伴派发故障修复工单。

5 结束语

为了支持行业应用的融合化发展, 运营商需要构建一套完整、高效的IT支撑体系。本文在研究对融合化行业应用的业务特点及业务实现的基础上, 分析了融合化行业应用对IT支撑的新要求, 并提出了面向融合化行业应用的IT支撑体系。希望本文能为融合化行业应用业务的IT支撑建设提供一些有用参考。

摘要：首先对融合化行业应用的业务特点及业务实现架构进行了研究, 然后分析融合化行业应用业务对IT支撑的要求, 最后提出面向融合化行业应用的IT支撑体系。

关键词：行业应用,融合化,业务模型,IT支撑

参考文献

[1]周丽莎林玮平粱峥等.电信政企行业应用产品定义方法研究.电信科学, 2010, 11:110~115

[2]中国电信.CTG-MBOSS CRM2.2规范集.2010, 3

[3]中国电信.中国电信计费模型2.8规范集.2009, 10

[4]中国电信.CTG-MBOSS OSS2.8规范集.2010, 3

[5]电信管理论坛.增强的电信运营图 (eTOM) , 中信出版社, 2003, 4

[6]陈龙.电信运营支撑系统 (第2版) .人民邮电出版社, 2007, 8

[7]苗来生乔伟.运营与业务支撑系统技术需求和方案设计指南.清华大学出版社, 2003, 11

IT业务 篇8

近年来,IT企业竞争加剧,为了扩大项目规模和降低项目成本,IT企业(发包方)开始将有限的资源集中于核心业务,而将非核心业务全部或部分委托外部企业(承包商)去完成,以上就是IT企业项目外包的行为。随着IT企业项目外包业务越来越多,产生的项目不能正常完工和回款的现象也大量增加,严重影响了企业正常运营,产生了巨大的财务风险。本文从内部控制的角度对IT企业项目外包业务的财务风险进行探讨。

二、IT企业项目外包业务的财务风险形式

(一)项目外包业务基础工作中产生的财务风险

(1)财务风险意识欠缺。由于项目外包业务在我国企业开展的时间不长,在IT企业的经营管理活动中,各级管理人员对项目外包业务的财务风险意识较薄弱,应对项目外包业务的财务风险控制措施也不到位,在财务管理工作中缺乏对该业务过程全流程的财务风险控制制度建设,日常工作中不注重对该业务财务风险的规避策略的正确使用,对财务风险只采用接受和拒绝的简单管理办法;同时,对IT企业的风险承受能力也不进行科学评估,一旦发生了严重的违约行为,发包方将陷入财务风险中。另外,由于项目外包活动的管理和监督难的特点,外包项目长期不能完工,使发包方垫付给承包商的资金被承包商长期占用或者最终用户方不能正常回款,影响发包方的正常现金流入,造成发包方资金利息支出的增加或资金链的断裂,从而增加财务成本或产生财务风险,甚至导致企业倒闭。

(2)管理架构与岗位职责欠缺。由于外包项目无人监管或监管不严,易产生商业贿赂等舞弊行为。信息与反馈机制不畅,导致发包方与最终用户方失去接触和沟通的机会,从而使发包方失去对外包项目和承包商的控制;同时,因为信息不对称,使承包商优先获得项目过程中的信息,进一步采取有损项目成果的行为,从而会降低用户满意度,影响发包方的信誉和造成损失。

(3)制度与流程欠缺。设计外包方案时没有规则可言,易将核心业务外包,而使发包方竞争力下降,出现业务受损或人才流失。由于审批不规范或不严格,使项目外包决策出现不当而产生财务风险。同时,因为未建立一套健全有效的全流程的关于项目外包业务的财务风险控制措施,所以不能准确反映外包项目的实物和资金的流转和变化过程,发包方会产生资产流失;而且,项目外包业务的会计处理方法不正确,也会使财务报告反映的信息不准确,从而产生财务风险。

(二)项目外包业务工作过程中产生的财务风险

(1)设计外包方案方面。设计的外包方案出现内容不完整时,会使项目外包活动不成功。外包方案不具备可行性时,对业务过程的监控不严,会导致服务质量低劣,出现违约行为,给发包方造成严重损失。财务负责人未参与项目外包的决策评价工作,未进行合理审核或正确判断时,会使项目外包后降低不了成本,不符合成本效益原则,则达不到项目外包的目的。实施方案未按规定的权限和程序审批时,也会产生财务风险。

(2)承包商选择方面。承包商主体资格的合法性不符,会导致陷入法律纠纷而使发包方遭受损失。选择与发包方的核心业务存在竞争关系或潜在竞争关系的承包商,会使发包方的核心业务遭受威胁。如果承包方将业务又私自转包和分包,产生的违约风险就会增大。长期依赖个别承包商,会使其滋生自满情绪或认为发包方缺乏技术专家,进而抬高价格或提供较差的服务,会对发包方的项目外包业务产生不利影响。如果项目外包的价格不合理,成本过高会不符合成本效益原则,导致难以发挥项目外包的优势。

(3)合同签订方面。对于项目外包方案中识别出的重要财务风险,未采取有效的风险应对策略;在合同的内容、权利和义务、质量标准、费用结算标准、保密事项、违约责任等合同条款方面未能针对项目外包业务重要风险做出明确的约定,都会导致项目陷入合同纠纷和诉讼,从而产生财务风险。

(4)实施准备方面。项目外包业务的准备工作不充分或未落实到位,未要求组建专门的管理团队,未明确建立一套健全有效的对实施全过程的财务风险的控制模式和措施,都会影响对外包项目实施全过程的有效监管,从而不能降低成本和控制风险,会导致难以实现项目外包的目标,产生财务风险。

(5)实施过程方面。因需求变更增加的成本和沟通过程复杂造成隐形成本的增加等都会造成外包项目成本的攀升,导致不符合成本效益原则。对费用结算的审核不严,会导致资金的损失。对业务过程的监控不严,会导致相关商业秘密的泄露;同时,承包方出现未按照合同要求提供产品就会引发违约事件,甚至遭受重大损失。如果因市场变化等原因导致承包商无法履行义务,也会使项目活动出现中断。对形成的各类资料的管理和保管不严,也会使项目工作无法接续或无法维权。

(6)验收决算与评价方面。如果验收决算进度和外包项目的交付成果的进度不一致,验收的流程规定不合理,验收的标准确定的不具体和不清晰,都会使验收决算和评价阶段产生财务风险。验收决算过程中外包项目造价不实或拖延项目时间等也都会使外包项目成本增加。验收决算中发现异常情况没有及时处理,没有根据验收决算进行评价工作或虽进行评价,但没有调整承包商的信誉水平和对项目外包业务管理制度和流程进行改进和优化,也会产生财务风险。

三、IT企业项目外包业务的财务风险控制

(一)项目外包业务基础工作中财务风险控制

(1)增强财务风险意识,提高财务风险的防范能力。发包方要加强对承包商的信誉水平的评估,要按评估的级次对不同水平的承包商设置不同的管理和付款方式。同时,要在科学评估的基础上建立全流程的财务风险预警防范体系,在辨识、评价和分析各类财务风险的基础上提出合理的财务风险规避策略,要综合运用分散法、回避法、转嫁法和降低法等风险规避办法,合理规避财务风险。

(2)建立管理架构与明确岗位职责。从企业整体上提升管理水平,按照内部控制制度的要求建立项目外包业务的管理架构和岗位职责,要创新制度和流程,并且需要员工支持和掌握完整的监管方法,才能对风险防患于未然。要建立项目外包业务的岗位负责制,明确各部门和各岗位的设置和权责等;要做到办理项目外包业务的部门和岗位的设置及权责符合内部控制制度的制约和牵制原则,防止单个部门或岗位能决策外包项目整个过程的情况。

项目管理部要负责制度等的拟定,要对项目外包设计方案、选定承包商和签订合同进行审批;要负责对过程资料的保管和对项目外包业务工作的指导、检查和监督;要负责牵头建立“项目外包业务的信息管理平台”,作为各部门间的使用和共享平台,以便有效降低信息流风险。

财务部要负责项目外包业务的会计记录、核算和监督工作;要负责成本效益分析和费用结算审核等工作;要参与方案编写、承包方选择、合同签订、决算验收和评价等工作;要负责建立财务风险预警防范体系,贯穿该业务决策和实施的全过程;要负责牵头建立一套健全有效的全流程的财务风险控制措施。

采购部要负责建立和完善科学的承包商评估、准入和淘汰体系来提供合格的候选承包商清单;要负责和承包商的合同签订和执行付款等日常管理工作,要维护“项目外包业务的信息管理平台”;要牵头组织遴选承包商、验收评估和对承包商的信誉水平评估等工作;。

业务部门要负责本部门的项目外包设计方案的申请;要负责组建外包项目管理团队,设置项目经理制度;要负责对最终用户方的沟通协调和对承包商的指导、监督、资料的签署、付款的申请和决算验收评价等工作;要牵头在公司各项制度和管理流程的基础上,结合具体外包项目的特点,制定具体外包项目的管理模式和工作流程等工作。

(3)制定公司制度与规范管理流程。一是制定项目外包业务的授权审批制度和管理流程。要明确发包方内部各部门和各岗位在项目外包业务中审批的权限、责任及相关管理流程等。要明确各级人员审批时不得超越权限;要明确对于重大外包项目要由董事会级别的决策机构最终审批通过,对于普通外包项目,应当由董事长或总经理最终审批通过。二是制定项目外包业务的工作制度和管理流程。要明确项目外包业务活动的各阶段和相应的工作规范;要明确什么业务是发包方的非核心业务,要从成本效益原则出发去确认外包项目的方案;要明确不能将核心业务外包;要划分重大外包项目和普通外包项目的标准,合理确定不同的审批流程;要明确项目外包业务的决算验收和评价的办法,保证承包方最终提供的产品与项目外包合同的约定保持一致;要明确索赔、法律维权、收款,追究责任人责任和终止索赔等办法。三是制定项目外包业务的财务风险控制措施和会计业务处理的制度及管理流程。要建立财务风险控制措施,要依托“项目外包业务的信息管理平台”,确保每个外包项目施工及财务相关资料的完整性,指定专人保管和归档,以备向最终用户方主张收款权利和向承包商进行追诉时能提供合法的证据,维护发包方利益;对于项目外包过程中发包方借给承包商使用的资产、项目外包的合同诉讼产生的影响等所有涉及发包方资产的变动,都要依据书面凭证,及时报财会负责人审核后,进行恰当的会计处理,并在财务报告中进行必要的披露;同时,财务部门还要按照谨慎性处理原则,出台外包风险准备金等制度。四是制定项目外包业务的员工培训制度。发包方对管理项目外包业务的员工要进行培训,使其掌握项目外包业务的各项制度和管理流程,确保员工都能正确使用外包业务的监管方法,以便防范项目外包业务的财务风险。

(二)项目外包业务工作过程中全流程的财务风险控制

(1)设计外包方案方面。要严格按照各项制度的规定来设计具体外包项目的方案,在保证方案完整的基础上对方案的重要方面进行深入评审,要具备可操作性;要让财务负责人参与对方案的审查和对外包项目的经济效益做出合理评价,要将外包项目在外包情况下和自营情况下的不同的收益和风险进行比较,保证外包方案的合理;方案中还要吸收外部专业人员提出的合理化建议;方案要按规定的程序审批,要明确对于重大外包项目的方案要由董事会级别的决策机构最终审批通过,对于普通外包项目的方案,报董事长或总经理最终审批通过后实施。

(2)选择承包商方面。承包商须拥有合法合规的主体资格,信用和财务状况良好,内部控制完备,具备专业胜任能力和质量承诺能达到发包方的预期要求,能有效解决发包方问题的企业。日常工作中采购部要按期公布合格的候选承包商清单。要与他们成为战略性合作伙伴,签订合作协议,要持续跟踪调查他们的专业资质、技术实力、服务能力和对知识产权保护方面的力度和效果等,要考察他们与本发包方是否存在直接竞争或潜在竞争关系,要对候选承包商所做的业务根据评价情况进行考核,要作为对候选承包商淘汰、更换和信誉水平评估的依据。当有外包项目时,在公司的候选承包商中按照三公的竞争原则,采用招标和比价等各种方式,择优确定承包商,要充分了解候选承包方的情况,要充分考察候选承包方从事类似项目的成功案例和业界评价,最好到候选承包商以前的用户去实地了解;也可以要求候选承包商提供项目人员的职业履历和专业技能,甚至进行面试;可以让对方做详细的项目演示,展示其对项目的工作管理流程和质量管理情况等,特别是对于候选承包商的承诺和报价明细等,务必进行认真的测算分析,降低外包成本,切实做到项目外包后的成本在保证质量的情况下低于自营方式的成本。

(3)签订合同方面。对于项目外包方案中识别出的财务风险,要在合同中进行相关约定,进行降低或规避。在合同的内容方面,要明确承包方提供的产品名称、技术参数、设计标准、提供数量和服务费用等细节;在合同的权利和义务方面,要明确发包方有权评估和获得项目的实施进度、效果和相关的数据等信息,有权督促承包商改进工作方法,承包商有义务主动的将外包项目进展情况和存在的问题汇报给发包方,并主动和有效的解决问题;在合同的质量标准方面,要明确承包方要达到的最低要求的标准及须采取的应急补救性方法;在费用结算方面,要确定付款的条件、时间和金额;在合同的保密方面,要明确约定承包商须承担保密义务的具体内容和时间,要约定发包方有权修正保密条款;在费用结算标准方面,要合理确定项目外包分阶段费用结算金额、付款条件和付款时间等;在违约责任方面,要规定违约条件和承担的违约金额,在条款设计上既要符合相关标准又要体现一定灵活性,以便适应业务的变化;对于涉及较高专业技术的合同,应当组织技术等相关专业人员参与谈判工作。

(4)实施准备方面。对项目外包业务实施活动不进行有效的监督和控制是许多外包项目不成功的重要因素,所以,必须建立切实可行的监控措施,贯穿于外包项目的全过程,由双方的管理团队及最终用户方定期举行会议,对承包商的执行合同情况进行持续跟踪,以合同为标准,开展日常绩效评价和定期考核,一旦发现偏离合同目标等情况,应及时要求调整改进。要做好与承包商的对接和配合工作,双方都要组建专门的管理团队,共同梳理工作阶段,共同制定项目作业流程,确定信息渠道,编制操作指引,双方共同遵守,要明确每个过程中的分工和沟通等基本要求,才能保证项目外包业务的合同条款得到贯彻执行,发包方也不会对承包商失去控制。要让承包方充分了解发包方的质量要求和工作方式,从项目一开始就要监控外包项目的业务质量。

(5)实施过程方面。要加强成本管控,获得成本节约,要始终把符合成本效益原则作为进行继续外包或终止外包决策的重要依据。要做好费用的结算工作,在向承包方结算费用时,财务部门要准确掌握进度,要按照合同,取得验收决算报告等相关付款依据,严格按照合同约定办理审批程序,依据公司预算和计划,在支付手续完整的情况下及时付款。要加强对业务过程的监控,要防止相关商业秘密的泄露;同时,要建立应急处理机制,对项目外包业务的各种意外情况要做出估计,确定替代方案,避免出现意外后使发包方的项目活动中断。在有确凿证据能证明项目外包业务的合同无法履行的,应及时终止合同,防止财务风险或损失扩大化。已造成发包方损失的,可以按照合同进行索赔。要加强项目外包业务形成的各类商业信息资料和项目施工资料的存档工作。

(6)验收决算与评价方面。要根据承包方项目外包后交付成果进度的不同,确定一次性或分阶段的不同的验收决算方式。要以项目外包合同为依据,结合外包项目的日常绩效评价和定期考核的工作成果,编制出验收标准。要组织相关部门的相关人员,严格对照验收标准进行测试和验收决算,并出具验收决算报告,财务部门要依据合同和工程文档来审核决算金额和决算时间点等。验收决算过程中发现的问题,要查明原因,及时处理,并开展整改和索赔等工作。同时,要在验收决算工作后对本次项目外包是否完成当初的外包设计方案做出总体评价,并要记入承包商的信誉水平体系中,同时,可以对项目外包业务的制度和管理流程进行改进和优化。

摘要：当前,IT企业为了扩大项目规模和降低项目成本进行了大量的项目外包业务活动,导致项目不能正常完工和回款而产生巨大的财务风险。本文对产生财务风险的原因、控制思路和项目不同阶段产生的财务风险的形式进行探讨,提出建立一套健全有效的全流程财务风险控制措施,以加强财务风险的控制,确保企业的正常运营。

关键词：IT企业,项目外包业务,财务风险,内部控制

参考文献

[1]樊颖:《后金融危机时代服务外包企业对财务风险防范研究》,《财税统计》2011年第6期。

[2]黄大军:《企业工程项目财务风险管理浅析》,《管理纵横》2014年第6期。

IT与业务匹配中的信息化冲突探索 篇9

一、文献综述

(一)IT与业务匹配

Luftman(2003)将IT与业务匹配定义为:将IT以一种恰当和及时的方式,适应与企业战略、目标和需求。IT与业务匹配的发展经历了战略思想萌芽期、战略规划冲击期、战略目标匹配期、战略匹配期和跨组织匹配期等阶段,主要研究可划分为“内容”、“过程”和“评价”三个主要方面。其中,Henderson和Venkatraman(1993)提出了经典的战略匹配成熟度(Strategic Alignment Maturity,SAM)模型,为IT与业务匹配提供了主要架构,Luftman等(1997,2000)在SAM模型的基础上对IT与业务匹配的六个维度和五等级做了进一步研究。同时,不少学者对如何促进IT与业务匹配也做了大量研究,如Reich和Benbasat(1996,2000)通过案例分析认为,首席执行官(CEO)和CIO相互理解彼此的目标和规划有助于IT与业务匹配,认为IT与业务的沟通、IT与业务的联系、共享知识和成功的IT历史影响匹配。Luftman和Kempaiah(2000;2007)将IT与业务的沟通作为IT与业务匹配成熟度的测度模型的六个标准之一。Kearns和Lederer(2003)通过实证分析得出,CIO参与业务规划和CEO参与IT战略规划有利于促进IT和业务规划之间的关系,从而促进IT与业务匹配。Chan和Sabherwal等(2006)从防卫者(defender)、勘探者(prospector)和分析者(analyzer)三种战略规划类型实证分析,得出共享知识、先前IS成功、组织规模和环境不确定性对匹配的影响。Kearns(2006)从基于资源观的角度分析了IT与业务匹配的背景和结果,指出IT经理参与业务规划和业务经理参与IT战略规划是促进IT与业务匹配的方式,而高层管理的IT知识对参与有正向影响。Preston(2008)从高层管理团队的角度论述共享理解对IT匹配的影响,并认为共享语言、CIO的业务知识和高层管理团队的信息系统知识等对促进共享理解有正向作用。

(二)企业信息化冲突

组织冲突的研究始于20世纪60年代,1967年Pondy发表了“组织冲突;概念与模型”一文,初步奠定了组织冲突理论基础,Thomas(1976)发展了冲突的过程模型和结构模型。Darling等研究认为,冲突源于各种因素,在目标、期望、价值、行动方式以及关于怎样把握环境的理解上存在差异是不可避免的,而且人们将难以预计的未来因素加入到这些差异中去的时候,冲突就更加激烈和无所不在了。对冲突的理解也经历了从传统的观点到人类关系的观点和互动的观点的转变,人们对待冲突从消极到积极的转变见(表1),大量实证研究表明:适度的冲突,即可以保持组织的活力,又可以提高组织、生产率水平。国外企业信息化冲突的研究始于20世纪80年代,1981年Halsey研究认为管理科学和信息系统领域之间的冲突已经被发展了,他建议人们认识两个领域的相似和区别,并重视信息系统领域的冲突。Robey和Franz等(1989)认为信息系统开发项目促成了组织的成员进入到一个具有潜在冲突的过程中,项目组的冲突管理是非常重要的,但往往被系统开发忽略了。Smith和Mc Keen(1992)研究认为,信息系统和用户部门之间关系通常被描绘为缺乏信任,四个冲突的根源被识别为:关于计算机化控制的意见分歧;区别在目标和经理时间表不一致;缺乏可测量的益处;在系统开发期间的角色和责任的分歧。美国南明尼苏达大学的Trimmer,Kenneth James在他的博士论文中讨论了跨职能团队的信息化冲突,他认为冲突是跨职能团队一个固有组成部分,冲突和分为感性冲突和实质冲突。这两种类型可能导致团队满意度水平降低,也可能导致团队生存能力和团队整体效率水平的降低。冲突,特别是实质或面向任务的冲突的决议,是功能良好和有发展团队的特征。国内企业信息化冲突的研究起步较晚,丁祥海等(2003)将信息化冲突分为技术冲突和利益冲突,技术冲突可以通过专家协商的和利用知识库解决,高诚毅(2005)从组织管理角度对信息化冲突产生的根源及对策进行了初步探讨,唐东平(2005)从ERP实施角度分析了信息化冲突特点,提出冲突管理模型及对策,屈丽萍等(2006)从项目管理视角对企业信息化冲突进行了研究,提出了一些解决冲突的办法。温池洪等(2008)认为,只有破解信息化冲突,才能保证企业信息化的成功实施,达到提升企业竞争能力的效果。

注:据Robbins(2001)和Su,L.Y.(2005)整理

二、企业信息化冲突的原因、形式及其关系

(一)企业信息化冲突的原因

企业本质是一个系统,部门之间存在着密切的相互协作关系,存在着高度的依赖性。部门间的相互依赖是部门冲突的必要条件,当互依关系伴随认知差异或者目标分歧出现,或者互依关系限制了各方的行为、欲望或产出,冲突很容易产生。IT与业务匹配不仅涉及流程的再造和系统的开发,更涉及到伴随着信息化的深入而引起企业方方面面的变革,匹配过程中冲突产生的直接原因有三个方面在:一是由于IT与业务匹配引起业务流程变更,造成业务部门间冲突的产生。IT与业务匹配是一个由不匹配到匹配、由低级匹配到高级匹配而不断深入发展的过程,这一过程势必会引起企业业务流程的不断重组和改进,不管是应用企业业务重组理论进行全面重新设计,还是应用过程管理理论的方法进行局部改善提高,必定要和企业业务产生关联。因此,IT与业务匹配过程,往往是一个新旧流程交替更迭的过程,因业务流程变更而引起业务部门之间以及业务与IT部门之间资源进行重新分配,将是一个冲突不断产生并被不断解决的过程。二是由于IT部门和业务部门对彼此认知上的差异,引起IT部门和业务部门间冲突的产生。IT与业务匹配是IT或业务不断调整自身适应对方的过程,基于IT部门和业务部门对彼此认知上的差异和不同,二者在哪个部门应该做如何调整等方面不可避免存在差异,且因自身调整带来本部门工作量的增加会将差异激变成冲突。IT部门需要不断调整信息系统来适应业务的需要,业务部门需要调整流程适应IT的需要,流程调整往往会给业务部门人员带来工作上的改变,而一些企业的业务部门凭借自己是企业收入的来源而拒绝习惯上的调整,将IT与业务部门的匹配“踢回”给IT部门,让IT部门修改信息系统来适应业务的需求,因此,双方因认知上差异和实际工作会引起IT和业务部门间的冲突。三是IT与业务合作中跨部门机构的冲突。在IT与业务匹配过程中,企业往往会组建一个临时或较长期的组织机构来协调跨部门的合作。这个机构的内在机制不可能很完善,管辖权模糊,组成人员成分复杂,来自不同的公司、部门,他们之间存在差异,但又互相依赖,这样必然存在着公司与公司之间、部门与部门之间、个人与个人之间的利益相互冲突。利益冲突的管理比较难,但非常重要,关系实施的成败。假如利益冲突处理不好,IT与业务匹配过程就会遭遇很大的阻力,甚至受到抵制,或者迫于压力采取应付的态度。

(二)企业信息化冲突的形式及其关系

国外学者更多地将冲突划分为任务冲突和关系冲突,如Amason(1996)将高层管理团队(Top managementteam,TMT)冲突分为认知冲突和情绪冲突,并认为,认知冲突往往引起TMT成员之间的分歧,并由此激发情绪冲突,这表明认知冲突和情绪冲突往往是同时出现在团队中的。Jehn(1997)将冲突分为任务型冲突和关系型冲突。Trimmer和Collins等(2000)将信息系统开发中的冲突划分为人际关系冲突和任务冲突。Barki和Jon(2001)根据冲突产生的原因不同,可以将冲突分为技术冲突和利益冲突两类。Mooney和Holahan等(2007)通过对信息系统开发中的人际冲突及管理实证分析得出,人际冲突可以由意见不一致、干预和负面情绪来反映,冲突管理对系统开发结果有正向影响,但并不缓和人际冲突对结果的影响。换句话说,人际冲突无论如何被管理或解决都被认为是负面的。丁祥海等(2003)、温池洪和毕新华(2008)从冲突产生的原因层次划分为技术冲突和管理冲突两类。综上所述,我们可以将IT与业务匹配中的冲突划分为两种类型:任务冲突和关系冲突,其中任务冲突,可称为认知冲突或技术冲突,是指有关任务内容方面的争议,包括在观点、想法和意见上的分歧,这类冲突往往由于技术方面原因而产生,如系统冲突、设计冲突、时间冲突、数据冲突等;而关系冲突,可称为情绪冲突或管理冲突,指团队成员中存在人际关系不和,包括团队成员中存在的关系紧张、生气、厌恶等,往往来源于各个不同利益主体之间的冲突,如权限分配的冲突、组织角色的冲突等的利益冲突。Trimmer和Collins等(2000)认为,人际关系冲突对小组任务和关系有负面影响,而任务冲突对小组任务有积极影响。丁祥海和唐任仲(2003)认为,技术冲突和利益冲突相互关联,技术冲突的解决可能引发利益冲突,利益冲突的解决也可能引发技术冲突。工作和任务有关的多元化问题会带来任务冲突,而任务冲突的激化会造成关系冲突(因为生气等负面情绪导致的人际冲突)。Tjosvold和Hui等(2003)研究表明,任务冲突对组织业绩的影响取决于任务类型、任务间的相互关系以及团队规范化程度等因素。以上分析我们可以得出假设1:

H1:IT与业务匹配中的冲突可划分为任务冲突和关系冲突,其中,任务冲突和IT与业务匹配正相关,关系冲突和IT与业务匹配负相关

Simons和Peterson(2000)总结了西方实证研究结果,都发现了任务冲突与关系冲突的相关性。陈晓萍(2005)则认为,中国文化中容易将人和事混为一谈,不能将二者完全从认知层面分离开。反过来说,一旦团队内产生了冲突,冲突各方更加容易将任务冲突归因于关系冲突。因此,对于中国背景下的企业,任务冲突更可能引起的负面情感反应。郎淳刚和席酉民等(2007)认为,不能简单地将西方冲突研究的结论推演到中国情境之下。相对于西方人,中国人的社会心理特点是注重面子,尽量避免直接冲突。通过以上的讨论,可以认为这种相关性在中国情境下同样成立,甚至会更显著。由此得到假设2:

H2:任务冲突会引发关系冲突,二者具有很高的相关性

三、企业信息化冲突的化解与冲突模型

(一)企业信息化冲突的化解

IT与业务匹配中的信息化冲突可划分为任务冲突和关系冲突,其中,任务冲突有利于匹配,而关系冲突会破坏匹配。因此,我们的对冲突的管理关键在于如何缓解或化解任务冲突向关系冲突的转变。Harnbrick(1994)提出行为整合概念,是指团队成员从事共同合作中互动的程度,主要有三个要素:信息交换的质量和数量;合作行为;共同制定决策。IT与业务匹配本身就是IT和业务的互动关系,且Mooneyand Holahan等(2007)证实,通过行为整合可以减弱认知冲突转向情绪冲突。因此,IT与业务匹配的过程也可看作是化解信息化冲突的一种途径和方式。从Harnbrick提出的行为整合三要素来看,IT与业务匹配中的很多机制或影响因素符合行为整合的特征,如Feeny和Edwards等(1992)强调CEO和CIO的关系,Kearns(2003)认为CIO参与业务计划、CEO参与IT计划对IT匹配有重要影响,Reich和Benbasat(2000)认为IT与业务的沟通、IT与业务的联系等影响短期匹配等,其中的IT与业务沟通符合Harnbrick三要素中的第一要素信息交换,通过IT与业务沟通可以提高IT部门和业务部门信息交换的质量和数量,消除沟通上的认知障碍。而IT与业务的联系符合Harnbrick三要素中的第二要素合作行为。Lederer和Mendelow(1989)认为高层管理的支持对IT与业务匹配有重要影响,Teo和Ang(1999)认为高层管理、沟通、IT部门的响应等因素是相互依存的背景和前景前因的混合,Luftman和Papp等(1999)主张IT参与业务战略、业务经理对IT的支持以及高层管理者对IT与业务匹配的重视和支持,Baker(2004)建议强有力的领导等。丁祥海等(2003)、唐东平(2005)认为,目前提出的“一把手实施原则”主要是针对关系冲突的,是想让“一把手”的权威来协助解决利益冲突。因此要作好冲突管理首先要争取得到上层领导的直接支持。其中的“一把手”或高层领导的支持是为了用权威来协助解决利益冲突,或者说避免任务冲突引起关系冲突,也作为行为整合的内容之一。肖静华(2007)中提出更多的企业通过设立IT部门与业务部的有效互动机制,来促进信息技术与业务流程和管理的融合,如通过关键用户参与信息系统开发和应用过程来建立信息技术与管理的互动,也称为“请进来”方式,将信息技术人员分配到相关业务部门长期合作来建立信息技术与管理的互动,也称为“走出去”方式,在信息技术部门配置一定数量熟悉业务流程的人员来建立信息技术与管理的互动,根据信息技术项目的特点和需要,有的项目采取关键用户参与的“请进来”方式,有的项目采取信息技术人员长期在业务部门工作的方式来实现信息技术与管理互动。企业的IT培训以及这些互动机制主要是加强IT与业务的合作以及提高共同制定决策的行为,这和Harnbrick中第二、三要素较一致,也可看作是行为整合的具体内容之一。因此,得到假设3:

H3:IT与业务的沟通、IT与业务的联系、高层领导支持、企业IT培训以及互动机制等的行为整合是任务冲突转向关系冲突的调节变量

(二)企业信息化冲突模型

综上所述,我们可以得出以下四个主要结论(或研究假设),即企业IT与业务匹配中信息化冲突的概念模型参见(图1)。第一,IT与业务匹配中的冲突的起源来自于因流程变更引起的业务部门间冲突、因认知差异引起的IT部门与业务部门间的冲突,以及IT与业务合作中的跨部门冲突。第二,IT与业务匹配中的冲突可划分为任务冲突和关系冲突,其中,任务冲突和IT与业务匹配正相关,而关系冲突和IT与业务匹配负相关。第三,任务冲突会引发关系冲突,二者具有很高的相关性。第四,IT与业务的沟通、IT与业务的联系、高层领导支持、企业IT培训以及互动机制等的行为整合是任务冲突转向关系冲突的调节变量。

四、结论

在对现有文献整理基础上,对IT与业务匹配中信息化冲突产生的原因进行了较为系统的分析,将信息化冲突划分为任务冲突和关系冲突两种类型,并对二者之间的关系进行了论述。最后,作者从行为整合角度给出了解决信息化冲突的关键途径,并获得上述四个结论。其中,结论二、三和四有待实证检验,因此,也可以称为信息化冲突模型中的假设。本文主要关注IT部门和业务部门之间的信息化冲突,因此,不包括一些引起个人冲突的因素,如Eisenhardt、Jehn等提出的人口统计变量(性别、年龄和民族等)、认知水平(“受教育水平”等),以及Collins James和Porras Jerry(1996),Meglino和Ravlin(1998)提出的TMT成员的价值观差异等因素。此外,本文主要关注企业内部的跨部门冲突,对企业或组织间的如供应链成员之间的信息化冲突问题,以及与外部竞争环境相关的领导风格等因素,均有待于进一步的探讨。

摘要：信息化冲突是企业信息技术(IT)与业务匹配中普遍存在的重要障碍之一。本文在对现有文献整理基础上,对IT与业务匹配中信息化冲突产生的原因进行了系统的分析,将信息化冲突划分为任务冲突和关系冲突两种类型,并对二者之间的关系进行了分析。从行为整合角度给出了解决信息化冲突的途径。

IT业务 篇10

关键词：用例,业务流程再造,需求分析

0 引言

息系统项目开发中需求分析的重要地位不言而喻,在需求阶段出现的错误会一直延续到系统的设计阶段和实施阶段,其结果往往是为纠正错误付出昂贵的代价甚至导致项目失败。然而如何才能确定客户的需求却是困扰系统分析师的首要难题,我们往往很难通过简单的询问客户来真正了解到客户所需要的内容。因为很多时候客户一开始也只有一些初步的功能要求,给不出明确的想法,一个流传盛广的冷笑话是:“我知道这就是我所要求的信息系统,但是它不是我想要的。”

1 用例与需求分析

在RUP中用例被定义为“由一组用例实例构成,每个实例是系统所执行的一系列活动,以此产生对特定参与者具有价值的可观察结果。”它被用于说明系统的参与者使用系统以实现某些目标,广泛应用于需求的发现和记录。一般认为用例主要是说明系统如何工作的功能性需求或行为需求,它是以参与者为中心,从参与者的角度来描述它要做的工作,并分析这些工作之间是如何交互的,既所谓用例驱动的过程方法。

用例强调了需求分析的两个态度:一是关注系统的用户或参与者来编写需求,询问其目标和典型情况;另一个是关注理解参与者所考虑的有价值结果。有价值的可观察结果对用户来说正是系统的实现目标,通常和业务用例直接对应。同时,我们还应该注意到用例是由参与者发起的,不存在没有参与者的用例,用例不应该自动启动,也不应该主动启动另一个用例。

在信息系统开发中需求分析过程大致可以分为三个阶段:理解应用域(业务建模),建立概念模型阶段和系统建模。其中业务建模的目标是通过用例模型的建立来描述用户需求,需求规格说明书通常在这个阶段产生;而概念模型阶段是系统分析员采用面向对象的方法来分析业务用例的过程,业务架构通常在这个阶段产生;最后,系统建模是将用户的业务需求转化为计算机实现的过程,系统架构通常在这个阶段形成雏形(在系统分析阶段确定)。从这三个阶段我们可以看出,用例分析是需求分析阶段的核心,我们需要在用例中包含满足所有涉众关注点的事物。

那么,信息系统开发中该如何来确定用例的参与者,发现用例,完成用例的场景描述呢?通常的做法,系统分析师首先会定义“涉众”,可能包括投资人、项目发起人、项目管理者、项目执行者、第三方、相关法律法规和客户等。再在此基础上确定系统的用户,即用例的参与者,问他们类似的问题:你工作主要做什么?这件事是谁交待办的?做完了你需要通知或传送给谁吗?做这件事情你都需要填写些什么表格吗?把这些问题的答案汇集起来就是业务用例。这是目前广泛采用的一种获取用例的有效方式,系统分析师再配合参与者的业务代表进一步就可以完成业务用例文本情节的描述,这种描述方式是完全站在参与者的角度,强调了用户的目标和观点。

然而,如果新系统相对于旧系统的业务发生了调整,作为参与者业务代表并不总是清楚自己在新系统中将完成哪些工作,难免有“不识庐山真面目,只缘身在此山中”的困惑,这时按前面的方法获取用例和用例的场景还有效吗?

2 IT项目的业务流程再造

业务流程再造(BPR)是随着信息时代的到来而产生的一场技术管理革命。在20世纪90年代,作为最早倡导BPR理论的学者之一,美国麻省理工学院教授迈克尔·哈默(Michael Hammer)教授,在《企业再造》(Reengineering the Corporation)一书中对“业务流程再造”是这样定义的:“从根本上重新思考并彻底重新设计业务流程,以实现在关键业绩上,如成本、质量、服务和响应速度上,取得突破性的进展。”[1]

2.1 BPR的几个主要着眼点

BPR以业务流程为对象,从客户的需求出发,对业务流程进行根本性的再思考和彻底的再设计;以信息技术和人员组织为动力,以求达到企业关键性能指标和业绩的巨大提高和改善,从而保证企业战略目标的实现。

通常,我们可以从以下几个方面考虑到BPR的实施。

(1)满足用户需求变化而对业务流程要做的改变;(2)由于计算机处理与人工处理的不同特点,为了发挥计算机处理的优势,避免计算机处理可能产生的问题而需要考虑的业务流程变化;(3)适应信息在计算机系统及其网络中存储与传递的需要,而产生的业务流程革兴;(4)为了提高效率,创造效益,采用计算机系统及其网络支持下才可能有效应用的现代管理原理、方法与模型,而创新的业务流程。

2.2 BPR的主要方法

BPR作为一种重新设计工作方式、设计工作流程的思想,是具有普遍意义的,但在具体做法上,必须根据本企业的实际情况来进行。其中一些主要方法有:

2.2.1 合并相关工作或工作组

如果一项工作被分成几个部分,而每一部分再细分,分别由不同的人来完成,那么每一个人都会出现责任心不强、效率低下等现象。而且,一旦某一环节出现问题,不但不易于查明原因,更不利整体的工作进展。在这种情况下,企业可以把相关工作合并或把整项工作都由一个来完成,这样,既提高了效率,又使工人有了工作成就感,从而鼓舞了士气。如果合并后的工作仍需几个人共同担当或工作比较复杂,则成立团队,由团队成员共同负责一项从头到尾的工作,还可以建立数据库,信息交换中心,来对工作进行指导。在这种工作流程中,大家一起拥有信息,一起出主意想办法,能够更快更好地做出正确判断。

2.2.2 工作流程的各个步骤按其自然顺序进行

在传统的组织中,工作在细分化了的组织单位间流动,一个步骤未完成,下一步骤开始不了,这种直线化的工作流程使得工作时间大为加长。如果按照工作本身的自然顺序,是可以同时进行或交叉进行的。这种非直线化工作方式可大大加快工作速度。

2.2.3 根据同一业务在不同工作中的地位设置不同工作方式

传统的作法是,对某一业务按同一种工作方式处理,因此要对这项业务设计出在最困难最复杂中的工作中所运用的处理方法,把这种工作方法运用到所有适用于这一业务的工作过程中。这样做,存在着很大的学杂费,因此,可以根据不同的工作设置出对这一业务的若干处理方式,这样就可以大大提高效率,也使工作变得简捷。

2.2.4 模糊组织界线

在传统的组织中,工作完全按部门划分。为了使各部门工作不发生磨擦,又增加了许多协调工作。因此BPR可以使严格划分的组织界线模糊甚至超越组织界线。

从以上BPR的着眼点和主要方法我们可以看出,业务流程的再造导致传统的工作岗位设置和工作内容都有可能发生改变。而原来的业务人员并不能全面的了解自己在目标系统中所做的工作,这种情况下依然从参与者出发来完成用例分析就会得到不完整、不全面的用例及其描述。比如企业人工方式下的账务处理会计人员需要根据记账凭证做记总账、明细账、日记账等的记账处理以及编写会计报表,在实现计算机会计信息系统后基于对系统数据冗余和数据一致性的控制,业务流程再造后系统中仅设科目余额表,不再有对应于各种账簿或报表的文件,会计人员也就没有了“记账”,“编制报表”等用例或者用例情节发生了较大改变。

3 以业务为中心的用例分析过程

有些系统分析师认为基于流程的分析不是面向对象的,所以要“深恶痛绝”。笔者认为这是一种误解,以“业务为中心”的分析过程不单要从参与者的角度微观的去了解,还要从宏观的业务整体上去把握,把微观的业务整合起来以发现其中的缺失用例,保证用例分析的完整。特别是在完成业务流程再造以后,更需要在领域专家的帮助下根据新的业务流程完成岗位设置,分析业务用例,明确业务之间的联系。

以业务为中心的用例分析还在于最大限度保证业务用例的完整和独立性。比如会计在对临时凭证文件的记录进行录入、修改、删除时,每一个都是一个可以获得有价值观察结果的活动系列组合,而且也都是一个参与者(会计)发起的动作,那么是确定为三个业务用例呢?还是作为一个“临时凭证维护”用例?显然,会计人员首先要录入了会计凭证然后才能修改或者删除,它们结合起来才是完整的业务用例,会计人员的业务目标应该是对录入系统的临时凭证文件进行维护。在RUP中,用例驱动的含义是,一个用例就是一个分析单元,设计单元,开发单元,测试单元甚至部署单元。因此,把紧密关联的业务分成多个独立部分去实施是高成本的,高风险的。

3.1 活动图与业务建模

UML是OOA/D中最常使用的建模工具,它提供活动图来帮助对业务过程、工作流、数据流和复杂算法进行建模。相比于传统的业务流程图它具有更强的表达能力,能同时表示控制流和数据流以及业务的参与者。

我们通过活动图可视化的手段来帮助客户理解其复杂业务过程,而泳道(swimlane)有助于观察多个参与者以及业务过程中涉及的并行动作。在活动图建模方面应当注意以下几点:

(1)活动图通常对于非常复杂的业务过程建模具有价值,对当前的业务流程建模完成后,客户就可以可视化地变更和优化业务过程,完成业务流程再造。(2)活动图可以分级,分层。从高层的较抽象,但图形清晰、简洁,到底层的细节扩展,有助于划分子业务和反映底层的实现细节。(3)应当尽量保持同一级活动图中所有动作节点的抽象水平一致。

在用例分析中,将泳道所涉及的参与者和泳道中的业务联系起来就可以明确业务流程再造后参与者的行为需求或功能需求,反过来也帮助用户明确地认识到新系统使他们可以做些什么,这些是不是他们想要的。

3.2 发现和定义业务实体

业务建模后需要从中提取出实体类,业务实体一般来说就是调研时用户所提供的各类表单或报表,但在很多情况下,并非每一份表单就是一个业务实体,所有业务表单也不一定涵盖全了所有业务实体。很多系统分析员声称业务实体的发现过程是全凭经验的,到底有哪些业务实体,靠经验进行提取。如果只是靠经验,那么这个分析过程就无法验证和迭代,事实上RUP的需求分析每一步都应该是可以验证和迭代的。

我们知道在表达业务场景活动图中的每个活动通常都表述为一个动作加一个动作的受体,这个动作的受体就是我们要寻找的业务实体。比如“审核临时凭证”,“更新科目余额表”等,其中“临时凭证”、“科目余额表”这些名词就是业务实体。再根据场景分析这些业务实体之间的关系。实际上就是大家都熟悉的ER模型,但是与数据库建模的视角还是有所差别的。数据库ER模型要受到数据关系范式的限制,而业务实体ER模型则不必理会这种限制,只要与现实物体符合就好了。并且在面向对象方法中,为了从概念上简化ER转化成对象类的需要,对二元的多对多联系通常也要引进联系体,变成两个一对多联系。

3.3 用例契约

契约是优秀的需求分析或OOA工具,能够详细描述系统操作(就领域模型对象而言)所需的变化,而无需描述这些操作是如何完成的。用例契约使用前置和后置条件的形式,描述对象的详细变化,并作为系统操作的结果。用例契约可以视为UP用例模型的一部分,因为它对用例指出的系统操作的效用提供了更详细的分析。

用例契约的编写和业务规则有着紧密联系,我们可以把业务规则分为三大类:

3.3.1 全局规则,这种规则一般与所有用例都相关而不是与特

定用例相关,例如参与者要操作用例必须获得相应的授权,用例的操作与授权级别相关,或者用户在系统中的所有操作都要被记录下来等等。这类规则一般与具体的业务功能性要求没有直接关系。有时候,这类规则也被写到软件架构文档中。

3.3.2 交互规则。这种规则产生于用例场景当中,例如当提交一

份定单时,哪些数据是必须填写的,用户身份是否合法。当然也包括一般理解上的业务流程流转规则等,例如金额大于一万元的定单被定为VIP定单进入特殊流程等。这类规则一般要写到用例契约中。交互规则实际上还有两个是比较特殊的,一个是前置条件,即用例满足什么条件才能启动;另一个是后置条件,即用例结束后会产生哪些后果。

3.3.3 是内禀规则。所谓内禀规则是指业务实体本身具备的规

则,并且不因为外部的交互而变化的规则。例如,每张定单至少要有一件商品,同一类商品数量不能大于5件等。同时也包括大家所熟悉的数据效验规则,例如身份证号必须是15或18位,邮编必须是6位等等。这类规则是业务实体的内在规则,因此应该写到领域模型文档中。

一般来说,全局规则很难从用户处调研得来,通常这方面是用户的盲点。这主要是由有经验的系统分析员,或架构师以及客户方的IT部门(如果有的话),从业务特点、应用环境、行业规定、法律规章等等方面去总结,再求得客户方的认可。交互规则从用例场景而来,每一个场景,场景中每一个交互的过程可能都隐含着规则。这就需要与客户多讨论。交互规则最主要的来源是业务提出者和业务管理者,最好不要去找业务执行者。内禀规则是针对业务实体的,因此要对每个业务实体的属性进行罗列,并找出它们的规则。内禀规则最主要的来源是业务执行者,需求人员应该更多的去与他们交流。

4 总结

目前,在我国企业IT项目的实施过程通常也伴随着企业业务流程再造的过程,采用以业务为中心的用例分析方法,对获得这类项目的行为需求是行之有效的。以业务为中心并不违背客户驱动的开发过程,它是从业务宏观视角到参与者视角的分析过程,保证了用例分析的完整和系统性。

参考文献

[1]张立厚,莫赞,张延林,陶雷.管理信息系统开发与管理[M].北京:清华大学出版社,2008.1.

[2][美]Stephen R.Schach著,韩松,邓迎春,译.面向对象与传统软件工程——统一过程的理论与实践[M].北京:机械工业出版社,2006.2.