IT业务系统（精选十篇）
IT业务系统 篇1
1 进程多维监控
本文从多个角度,实现对应用程序多维监控,并通过SHELL编程、SQL语句,来进行对一个IT应用系统监控,具体是对一个应用程序进程来进行有效监控。多维监控指的是对一个应用程序进程的运行状态、日志状态、交易模拟、积压监控四个维度来实现有效监控;通过信息采集实现对监控信息的及时收集;通过参数配置来实现监控的灵活调整;通过告警触发实现对告警信息实时展现。
1.1 进程状态
从操作系统层面来监控应用进程是否正常运行,异常情况中有可能导致运行的进程异常终止,此时就需要从此角度来实现对应用进程运行有效的监控,从而判断应用进程是否终止,具体可以通过操作系统查看进程命令进行判断,比如UNIX系统中的PS命令。
1.2 日志状态
对日志更新时间、更新内容进行监控,其中日志更新时间表示日志正常更新后时间变化,某些异常情况下,进程虽然运行,但是内部已经无法在正常处理交易数据,表面现象是日志不再进行更新,从而说明进程运行异常,所以通过判断日志文件最后更新时间与其我们的经验值进行比较,超过规定时间,则可认为应用进程异常或者其他程序异常,导致无交易数据产生。其中更新内容表示日志的文本内容中产生某些异常提示信息,这些提示信息我们可以提前进行定义,定时对更新的日子内容进行过滤错误关键字,如果发现出现错误关键字,从而说明应用运行异常,为了提高监控的效率,仅对新增的日志内容进行检索,此时我们可以通过设置一个日志行计数器,每次检索范围为上次检索最后值到目前日志行数。
1.3 交易模拟
定时使用外挂程序使用真实数据自动对系统软件进程进行交互,同时收集每个处理步骤的时间,通过对一个真实的业务交易进行监控,获取目前系统处理情况,包括系统运行是否正常(是否出现异常情况)、处理效率是否下降(与一个合理值进行比较后),从而实现站在一个用户角度来发现系统问题,此监控角度又称业务监控,相关对进程状态和日志监控来看是具体生产活动行为的监控,丰富了监控层面。外挂程序一般可以依据接口规范进行编写配合系统软件编写或者采用第三方的模拟软件。
1.4 积压监控
目前很多系统进程的交易数据都会涉及到数据库系统,且多个进程配合进行处理,比如,前一个进程将数据处理完毕后,插入到数据库系统中保存,又另一进程通过定时调度的方式进行读取前一进程的数据,进行处理,处理完毕后,更新记录的处理时间,通过对进程状态、日志状态、交易模拟三个方面监控都是正常,及系统运行正常,但是处理效率较低,此时就需要对进程间的数据处理效率进行监控,如果记录的存在多条未处理,则说明出现了异常情况,导致处理效率下降,此时需要及时介入进行检查。通过对数据库中中间处理表的数据进行统计,可以有效获取到目前未处理完毕的交易总数,从而判断系统是否存在问题。
1.5 信息采集
即对多维监控产生的信息进行信息采集,将采集的信息进行数据库入库,具体实现上每个监控程序可以部署在不同的监控节点主机上,然后通过操作系统的rsh命令将收集的信息统一发送到指定服务器上,实现了监控节点可以灵活扩充,对于每个监控节点定义一个唯一的名称进行区别即可。
2 参数配置和告警触发
参数配置,为了方便及时更新各种告警值的范围,将系统监控值配置到数据库中,依据实际的情况将采集的信息与配置的参数值进行比较,符合条件的信息将生成告警信息。比如监控时间、超时值定义、日志大小、日志内容、设置还可以将具体的监控点涉及到人员手机号码作为一个参数。
告警触发,通过对监控信息进行条件比对,实现对信息的过滤,并将符合条件的信息进行展现,可以通过Web页面的方式展现,也可以通过手机短信的方式进行展现,对于已经展现的数据或者已经发送告警手机短信的信息,系统可以进行状态变更,避免重复生成。主要可以通过编写定时轮训的程序对采集的监控信息与配置参数进行进行条件比对,把符合条件的信息生产告警信息,及时通知到维护人员或者主管人员,使其及时发现系统隐患。
3 结束语
IT系统的稳定运行确保了生产活动顺利进行,本文通过对IT系统的系统软件进程监控方法进行了说明,从四个维度说明对进程监控,包括进程状态、日志状态、交易模拟、积压监控,并通过真实的脚本程序进行实现说明,并包括对信息处理和告警的生成、参数配置进行说明,从而实现一个初级的应用进程监控体系,通过此方法实现,不仅可以减少相关资金费用投入,也更能适应各行业应用进程的特点。
参考文献
[1]Sobell M G.Linux命令、编辑器与Shell编程[M].杨明军,王凤芹,译.北京:清华大学出版社,2007.
[2]富尔斯汀.Oracle PL/SQL最佳实践[M].龚波,译.北京:机械工业出版社,2009.
IT业务蓝图规划 篇2
为什么要实施IT业务蓝图
【从中国企业信息化建设客观现实看系统实施成功率不高】 许多企业的信息化项目久拖不决，无法按期交付
软件系统实现功能与企业实际管理需求脱节，客户对实施的满意度低 【企业信息化应用层次低】
大多数企业信息化系统仍停留在经营业务操作层面的应用，企业高层决策所需要的信息却淹没在海量信息中，低层面的信息化应用无法吸引企业高层的参与，无法得到企业高层对信息化的长期支持
许多企业只是上了进销存和财务，生产的深度应用，成本管理、SCM、CRM、BI都没有实现，信息化对管理体系优化，使企业真正成为学习型组织支持不大。【客户抱怨比较多】
由于软件没有解决客户实际应用需求，客户抱怨多
软件不能支持企业管理的持续进步，无法与客户形成长期合作的战略合作关系
IT业务蓝图规划做什么
IT业务蓝图规划是通过对实施过程中业务蓝图规划方法的提升，即运用业务流程优化找到客户关键问题，有针对性的明确信息化提高客户管理水平的内容，确定项目目标，规避项目风险，帮助实施顾问提高项目交付质量，是真正保证客户价值的有效工具。
运用价值链模版解析客户经营特点和关键问题，通过流程优化找到解决问题途径，对组织、流程、信息化实现提出建设性意见。
明确信息化系统支撑管理优化的关键点，确定客户需求，界定项目边界。评估信息化建设风险及系统上线充分必要条件，提出应对措施。
根据企业实际状况及管理基础工作水平，本着总体规划分步实施的原则，确定实施步骤，明确项目管理重点。
IT业务蓝图的核心是业务流程优化
影响企业的三股力量就是：顾客（Customer）、竞争（Competition）和变化（Change）, 简称为“3C”。
企业业务流程优化着力点一般集中在四个方面。第一，建立面向客户的流程，强化和提升与 客户满意度有关的业务流程，剔除对客户无价值的流程，以更低的成本、更快的速度提交客 户满意的产品和服务；第二，通过规范的业务流程降低企业的经营风险；第三，通过流程优 化优化企业资源配置，降低成本；第四，缩短工作完成时间，提高企业整体运作效率，提高 市场响应速度。业务流程优化的实施
【战略分析与确认】
市场生产经营环境分析、行业特点、竞争要素分析、竞争对手分析； 企业愿景和发展战略、为实现企业战略必备的能力、核心流程分析； 分析客户的抱怨、寻找企业管理的关键要素。【客户需求分析】
目前服务对顾客需求的满足程度、哪些顾客需求目前企业不能满足、哪些服务顾客认为是不需要的、与竞争对手相比，你的服务所处的位置； 流程的关键指标、指标的重要性；
客户需求到流程功能的转换、确定新流程要实现的功能。【流程设计】
现有流程描述、找出现有流程与客户需求的差异； 流程中各活动的时间、成本分析；
区分增值活动、非增值的必要活动和非增值活动；应用ESIA方法进行新流程设计、提出新流程实施方案、建立新流程。【流程重建】
按照新流程的要求设置组织和工作岗位、部门和岗位职责描述；
确定新流程执行过程的关键控制点、建立与流程配套的管理制度、建立规范的作业手册； 培训，评价和考核。【与信息系统衔接】
新流程对信息系统的要求、确定支持新流程的技术手段、信息系统需求分析； 确定信息系统实施前的准备、依赖于或不依赖于信息系统实施完成的流程功能的界定；与信息系统开发及项目实施的衔接。
动向集团:业务驱动IT 篇3
作为一家上市公司，动向集团却很少为消费者所知，但该集团旗下的“Kappa”品牌享誉业界。动向集团完全拥有该品牌在中国内地、中国香港、中国澳门及日本的所有权，负责Kappa的设计、研发、生产和销售。
“原来动向集团只有30多人，在大开间办公室工作，信息化的需求并不迫切。”动向集团IT运维经理刘学锋说，现在集团500多人，生产规模在扩大，市场环境也在变化，必须采用IT手段提高企业核心竞争力。在此目标下，集团先后实施了一系列业务管理系统。
相比其他服装品牌的信息化，动向集团与众不同之处在于协同管理平台。这不是简单的OA，而是将财务、ERP等信息抽取出来，造就集团的协作一体化平台。有了这个平台，动向集团足够有信心做好内部管理，从而造就品牌优势。
赋予品牌含义
Kappa原是意大利品牌，强调“青春、活力”的品牌内涵，上世纪90年代进入中国后，交给北京动向公司代理。北京动向公司由李宁集团控股80％。经过几年的代理，李宁集团决定放弃该品牌。时任李宁集团总经理陈义红买下北京动向，并于2006年成为Kappa在中国等区域的全部权益持有人，随后于2008年成为Kappa日本品牌的所有人。
在刘学锋看来，现在品牌、渠道的竞争日趋成熟，服装企业的下一个竞争点在零售。举例说，某服装品牌从设计到成品送到店铺，最快用12天时问。这么短的供应链，不仅取决于常规材料的复用比例，用以压缩供应链上游周期，更在于供应链下游对消费者需求的精准把握。“传统的供应链是9到12个月，而现在服装作为时尚的消费品，越快越好。这就需要服装公司懂得消费者，及时获得一手的零售终端信息。”
动向集团不做直营销售，以经销商、加盟店为主，区域再分一级总代和分销商。为了了解门店的销售，IT需要及时采集零售终端的信息。零售终端数据采集的有效性和准确性一直是品牌公司最为关注的零售指标之一，动向集团要求信息采集必须真实可靠。
这些年服装企业流行“轻公司”：无设计、无生产，只有品牌和营销。动向集团不是这样的“轻公司”，动向集团准确地说是“轻资产”运作的集团公司，是以终端销售、自主研发、设计、生产为主的品牌运营公司。比如收购日本Phenix公司及其相关品牌，就是看重日本的设计研发能力。
对于销售渠道向网络延伸的趋势，动向集团也在积极应对。2009年与淘宝合作，仅在“光棍节”当天，营业额就达到400万元，去年则突破千万元大关。刘学锋认为，与实体店相比，网络销售也要强调消费者体验。“在传统的销售渠道中，消费者看重购物体验，如舒适度和价格。而在网上，IT平台的价值除了表现在快速发货、了解销售状况之外，没有办法提升更多的附加值。所以，集团在与成熟网商合作的同时，也在积极探索新的电子商务模式。”
让协作平台创造价值
动向集团的信息化产品众多，包括ERP、OA、DRP、WMS等，基本以ERP为核心，构建了集团的IT应用系统。
一般来说，OA是办公平台，负责办公的流程，但是动向集团的OA平台发挥的功能远不止这些。
“以前集团财务审核量最多的是日常费用的支出。每次报销需要填表，财务检验票据真实性之后再给老板签字。当时我们就想，如何在OA平台上实现审核，将管理职责划清楚，保障财务的真实性，让老板从具体的、琐碎的事情中解脱出来?”刘学锋回忆说，基于管理的需求，集团采用鼎捷的软件平台，开始对OA逐步升级。
“协同平台发展到今天，最终的驱动力来源于管理的效率、效益和管理精细化。”刘学锋解释说，管理的效率是指如何快速地对管理的各个环节做出响应；管理的效益是将过去软性的管理指标量化，从流程中发现效益；精细化管理，通过协同平台很容易将精细化管理的战略落地，如财务现金管理制度的审核权限管理等。
按照刘学锋的设想，从效率到效益再到精细化之后，协作平台最终要为公司的战略服务，成为实现创新的一个平台和工具。“到目前为止，协同平台承载了100多个管理流程，集团管理被充分地落实与执行。在集团不断发展的过程中，管理的精细度不断增加，而管理的效率却没有降低。”
“要有一种意识，让IT成为利润中心，而不是成本中心。”刘学锋说，IT越来越需要分析“产出比”。由于IT不像销售那样直接为集团带来营收，通常很难被管理层认知，“因此，分析IT的投入产出尤为重要，说句话，要让集团了解到，IT的投资回报是什么?这种回报可以是直接降低运营成本，也可以降低隐形的管理成本，而无论用什么样的核算方法，总之，要让管理层看到IT的价值是什么。”
刘学锋总结说，动向的价值转换也经历了一个摸索的过程，以前是“IT驱动业务”，现在是“业务驱动IT”。比较幸运的是，动向的管理层对信息化的认知比较超前，也比较支持信息化建设。所以，动向集团的IT最终将从后台走向前台，成为企业核心竞争力的重要指标之一。
链接
四个阶段走向集成
引入IT治理理念保障业务连续性 篇4
2010年反复无常的市场环境和激增的经营压力, 使得企业面临着更多的挑战。当前企业的业务运营日益依赖于网络和IT技术, 使得源于IT系统运行中断而导致关键业务中断的风险也随之而来。因此, 越来越多的企业将注意力从灾难发生之后的业务恢复, 转移到如何保持企业关键业务连续性上。
那么, 该如何建立高效的保障业务连续性的系统呢?
一是业务影响分析, 制定所需防范的灾难范围。简单地说, 业务影响分析主要是识别出企业的关键业务活动对这些关键业务活动所能容忍的业务最长中断时间, 并对这些业务所依赖的要素进行分析, 最后按照恢复的优先级排序确定关键活动。二是风险分析, 明确需要防范的灾难类型。通过风险分析, 明确IT系统需要承受的灾难类型, 并对诸如系统故障、硬件故障、数据受损、火灾及地震等各种意外情况采取合适的备份和保护方案。同时, 针对不同的灾难风险等级, 它们的防范策略应该不尽相同。三是依据业务关键程度, 设定灾难容忍时间指标层次。必须明确, 当IT系统发生意外而无法工作时, 依据业务停顿所造成的损失程度, 设定用户对于IT系统发生故障的最大容忍时间, 这也是设计IT治理业务连续性方案的重要技术指标。四是成本控制, 平衡风险等级和业务连续性的关系。业务连续性应当根据业务恢复的总体成本对最关键的应用进行权衡。五是业务连续恢复方案, 不能光建不练。制定好IT治理业务连续恢复计划后, 并不是万事大吉和束之高阁, 因为不经过演练的计划方案无异于纸上谈兵。测试和演练是非常有必要的, 而且这也是有效的IT治理必不可少的一步。
IT业务员实训报告 篇5
通过3个月的实习我终于可以成为广州南方嘉顿科技有限公司的一名正式员工了，内心有说不出的高兴。因为3个月以来，我觉得这间公司是一间管理科学，制度明确，企业文化比较好的一间公司，是一间让我有发展空间的公司，以下是我3个月来的实训报告。
首先让我来介绍一下我们公司，嘉顿科技于一九九四年成立，致力于目前飞速发展的IT行业，现拥有专业维修工程师400余人。主营各类打印机及原装耗材、电脑的维护和网络设备维护以及优质的IT设备的外包服务。已经取得了CANON、FUJIXEROX、EpSON、FUJITSU、Hp、STAR等多家国际知名品牌的授权维修代理，并从美国引进了具有国际先进水平的生产线，专业生产激光打印机耗材及配件。集团充分利用国内外不断涌现的高新技术，通过先进且符合我国国情的经营管理方法，培养了一批高素质的技术、管理人才及优秀的生产队伍。自成立以来,一直遵循“绿色办公”的理念，始终坚持遵守“3R”原则即Recycle(可回收循环）、Refill(可重填墨水）和Reuse(可重复使用），努力倡导“绿色打印”，引导用户进入理性消费状态，使用环保耗材，共建绿色家园。嘉顿作为再制造业的一员，不断提高产品品质，缩小并接近与原装耗材的差距，降低经营成本，创造健康和谐的高效办公环境。集团充分利用国内外不断涌现的高新技术，通过先进且符合我国国情的经营管理方法，培养了一批高素质的技术、管理人才及优秀的生产队伍。自成立以来,一直遵循“绿色办公”的理念，始终坚持遵守“3R”原则即Recycle(可回收循环）、Refill(可重填墨水）和Reuse(可重复使用），努力倡导“绿色打印”，引导用户进入理性消费状态，使用环保耗材，共建绿色家园。嘉顿作为再制造业的一员，不断提高产品品质，缩小并接近与原装耗材的差距，降低经营成本，创造健康和谐的高效办公环境。
我是以业务代表的身份参加实习的，这个职位的主要任务是为公司开拓一些新客户，为公司创造更大的利润；维护老客户，增加他们对公司产品的的忠诚度，这是对一名实习业务代表的基本要求。实习过程主要分2个部分，第一部分的公司培训，第二就是实习了。公司规定实习生进入公司都要经过2个星期的培训，培训的主要内容有介绍公司的发展历程，基本状况，公司产品，性能，业务范围和一些平时与客户沟通的技巧与问题的处理方法。在培训期间我认真学习，结合自己在学校里学的专业知识，认真领会，感到受益匪浅。经过2个月的培训，我已经基本领会培训的内容了，虽然还没有经过实践，但是我相信在以下的实习时间内我会学以致用的。
经过2个星期的培训我实习的时间终于到了，不过公司分配我首先要在办公室学会打电话，用电话和客户联系，暂时还不用出去跑业务。开始我还以为电话很简单，不以为然。可是到我真正打电话过去的时候，就不知道该首先说什么，再说什么，面对客户的问题怎么样才可以有效的回答，怎样才可以让客户接受我们公司的产品，这样一天下来我都没有一个成功，要不就是没有兴趣，要不就是早早地就挂了电话。不过好在我有一班好同事和老板，他们看我气馁了，就不厌其烦地教我，耐心的指导我，经过几天的失败我终于用电话谈成一个有兴趣的客户了。
学会用电话与客户沟通后，我就开始出去与客户面对面沟通了。平时在公司都是在公司与客户用电话沟通，都看不到大家的表情，所以都不是那么紧张，可是当我第一次出去面对客户的时候，看到客户，和客户谈起来就不那么自在了，多少少少都有点紧张，当他问他需要什么功能要求用什么打印机的时候，我居然记不起来，还支支吾吾的，还要看书，那可想而知那笔生意肯定是失败了。汲取了第一次失败后我总结了原因，首先我对公司的产品性能还没有熟透，当客户问起来的时候还没有及时的回答出来，第二就是紧张，不过我相信经过几次，紧张的心理我是可以克服的，第三就是不够自信，说话要果断，回答要清楚，这样才可以给客户信心，总结了这些，我就按照这些去做，果然，效果出来了，还做成了好几单生意。现在我面对客户我再也不紧张了，还畅所欲言，和客户沟通也有了一定的技巧。
现在在公司我都是通过电话去联系客户，在电话上先和他们谈，如果他们有兴趣的话我再出去和他们面对面的交谈。出去和客户交谈，我们首先要注意自己的着装，最好的正装，这样的话给的感觉就是专业人士，再次就是要注意交谈的技巧，要懂得他们的心理，懂得他们的需要，要达到双赢，这样的关系才可以长久，最后是要懂得灵活地处理问题，当你去到一个客户的那里，可能之前有别的公司的人去过了，而且还开了价，这样的话你开的价比他们低，当然是不亏本的情况下出价，这样那笔生意就是你的了，又或者你的客户叫你去检查机器，而你又不大会的情况下，你可以说这样的机器复杂，在这里很难修好，最好就是给你带回公司修理，再帮你看看还有没有其他地方坏的一起修好，这样给你客户的感觉你是一名专业的，为客户着想的业务员，这样那位客户对公司的忠诚度就大大提高了。
总揽全局:IT投资和业务战略 篇6
在最理想的情况下，CIO和其他的主管应根据整体业务战略来对IT投资进行评估，从而获得最大的回报并满足所有重要的IT投资和业务需求关系。
然而在现实世界中，往往有很多因素交织在一起，单个IT项目往往被当成真空项目，组织没有从这个项目所存在的大环境中进行通盘考虑。这种做法所导致的结果是，产生了一个会引起诸多问题的孤立的决策过程。
问题出在哪里?
举个例子来说，当提到IT相关的安全问题决策时，许多公司都会做最坏的打算。他们往往更加关注那些可能会给组织带来巨大灾难的事件，并引用以前发生过的一些案例，最后使用一种最安全的投资方式，而不是对这些事件做一个更好的、基于事实的评估。
这种逻辑存在的首要问题是，安全失控所带来的成本影响没有同安全失控的概率联系起来。换句话说，虽然IT安全系统的瘫痪会给组织带来巨大的损失，但是这个事件的实际风险却没有被考虑进去。
其次，规避安全问题的方案往往没有考虑消除风险的所有相关投资。组织往往会从防火墙和病毒扫描系统开始，来证明这个投资对预防全面和不可避免的安全瘫痪的必要性。但是很快的，一些其他方面的投资需求又冒了出来，例如入侵检测、反入侵软件、数字认证等等。所有的这些相关投资实际上都在解决相同的问题，而且每种投资都是基于预防全面的安全失控问题上进行考察的。当诸如此类的投资无休止的节节攀升时，管理层就可能质疑IT安全基本业务案例的有效性了。
何地、何时进行投资，以及多少投资才能够避免系统瘫痪所造成的损失，必须要通盘考虑所有的安全方案和相关的预算。问题不在于值不值得追加新的防火墙投资，从而避免全面的安全失控，而是在于cIO们必须要发问：“我们是否把钱花在应该花的地方，从而使我们在面对安全问题时更加自信。”
一个好业务案例的因素
以下四方面的因素，能够帮助组织对IT投资的业务案例进行通盘的考虑。
净现值
今天，许多组织所用的都是最基本的“ROI(投资回报率)”，它是简单的用预期总利润除以预期总成本。虽然这种计算方法的透明度非常高，但是它确实是过于简单，以至于连一些真实的决策信息都不能传递。而NPV(净现值)这种计算方法要比ROI好，是因为一个项目在整个生命周期内的价值。例如，NPV这种方法，通过计算某个项目在第一年里投出去的资金，然后计算这个项目在第二年和第三年的盈利，就可以看出某个项目在长期内是否优于某个短期的小项目一一我们假定这个组织有足够的意愿和资金来等待这个回报。
回报
所谓回报，就是指在多少时间内能够收回投资，并提供一种衡量风险的方法和作为对NPV分析的一种检验方式。虽然长期目标很重要，但是有时一个组织不可能用太久的时间等待其资金的回笼。在对业务环境有所了解的基础上，管理层就必须知道一些关于长期投资的知识，他们还需要知道投资的回报期以正确的评估出投资风险。
机会成本
另外一个关键因素是机会成本--它计算出哪些投资由于消耗了太多的资源而不宜进行。如果IT需要一个离散性的预算，把预算花在一个能够产生1百万元净现值并在一年后可以收到的项目上，和一个能够产生5百万元净现值却在半年后就可以收回的项目上来说，从机会成本的角度讲，后者更具优势。虽然这一点看起来是十分显而易见，但是实际中，经理们往往将决策间看成是独立的、互补相干的过程，从而会丧失许多对多种选择进行联合决策的机会。例如，是对ERP系统的薄弱部分进行投资升级，还是雇佣10多个开发者进行开发，对于这个问题，公司应该把它当作一个业务案例的一部分来进行考虑。忽视机会成本，也许用下面这句话来进行阐述是最精辟不过了：“我们很希望今年就做这件事情，但是我们实在是没有预算了。”
软收益
最后，“软收益”是指一个项目对一些定量的指标，如生产率、远景和员工士气，或者那些用具体的金钱很难衡量的指标的影响的度量。虽然经常遭到忽视，但软收益的意义确实非同寻常。据观察，一些大的、运作得很好的组织却保留一些陈旧的桌面技术，而不是采用最佳的实践方式，其原因在于管理层没能意识到，也不能量化硬件更新对运行新的应用系统、提高生产效率、减少维护成本和提高用户满意度上的收益。如果管理层不知道如何定义衡量软收益的尺度，软收益可能在实际中被大大低估。例如，分担终端用户的负担，比如减少终端拥护处理问题和系统崩溃的负担，所带来的软收益是非常巨大的，但是它却很难用节约的小时数来度量，除非已有现成的度量尺度可以遵循以及可以应用现成的行业实践方式。
度量结果
衡量实际投资与原来预期的出入可以保证业务案例的有效性。NPV实现了吗?回报率呢?原来的估计和实际结果有多大的出入?造成这些出入的根本原因何在?在机会成本、软收益和业务联盟的讨论中，哪几点被证明是正确的?
融合化行业应用业务的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.